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).
Any thoughts?
Arthur Heymans
Arthur Heymans wrote:
Writing things on S3 is always fragile as it could overwrite other things set up by something else.
..
Any thoughts?
Isn't the classic solution here to reserve the memory area in ACPI?
But maybe the EBDA region is already covered by another reservation, which coreboot can't very well overwrite?
//Peter
On Sat, Oct 19, 2019 at 9:42 AM Arthur Heymans arthur@aheymans.xyz 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 -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Aaron Durbin via coreboot coreboot@coreboot.org writes:
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?
EBDA typically also holds the RSDP. SeaBIOS sometimes relocates the RSDP when it needs more place. Rewriting the RSDP during S3 resume can (and did in the past) overwrite the RSDP and break S3.
I found that passing cbmem_top via the function argument option (on stack on x86, in registers on arm, aarch64, x86_64) of the program loader could be an universal method of handing off the cbmem_top pointer. With very little code at the start of ramstages only one cbmem_top implementation is needed for all arch during those stages.
See some working POC on arm, x86, x86_64 here: https://review.coreboot.org/c/coreboot/+/36143/ https://review.coreboot.org/c/coreboot/+/36144 https://review.coreboot.org/c/coreboot/+/36145/
Any thoughts?
Arthur Heymans _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Aaron Durbin -
Arthur Heymans -
Peter Stuge