On Sat, Oct 19, 2019 at 9:42 AM Arthur Heymans <[email protected]> wrote:
> Hi > > Currently all stages that need cbmem need an implementation of a > cbmem_top function. On platforms with fully open source coreboot code it > is generally not a problem to link in all stages the code reading the > hardware registers to figur out where the top of lower memory is. On FSP > platforms this proves to be painful and using the value provided by the > FSP-M HOB is to be preferred. Next stages don't have access to this > variable since CAR is gone. EBDA is used to pass it on to next stages. > > The problem with this is that EBDA also need to be written on S3 as one > cannot assume it to be still there. Writing things on S3 is always > fragile as it could overwrite other things set up by something else. > > One possible solution is to back up the area it's going to write to in > romstage in cbmem and restoring it on the ramstage, but writing to cbmem > on S3 resume is just moving the problem to a different place and likely > makes things even worse... > > One other idea I could come up with is to make the cbmem_top pointer an > argument to the relocatable stages needing it (postcar and ramstage). > This would unify all cbmem_top implementation in those stages and should > be more robust on S3 resume as on S3 resume the ramstage is typically > fetched from RAM (cbmem or tseg stage cache). > That's the same thing as effectively providing a register ABI between the stages passing information to it. I'm not sure EBDA is necessarily bad in practice. It's typically reserved. What specific issues are you concerned with EBDA? > Any thoughts? > > Arthur Heymans > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
