Patch Set 13:

Patch Set 13:

Patch Set 13:

Do you have other cases than AMD UMA that needs to stash romstage information into BSS prior to initial CBMEM setup? I think this is a bit overkill for that purpose.

Initially there was a use case for skylake and newer but that went away.

Thinking of it: migrating a structure to cbmem, updating pointers during romstage to migrated data in cbmem and initializing the datastructures in ramstage is quite common and a little error-prone. Would it make sense to abstract that away with something like:
persistent_storage_init(void *pointer_to_data, sizeofdata, CBMEM_ID)?

Sounds good to me. I might want to take that even further, noting that some (timestamps, console, usbdebug) start their lives already in bootblock and have to be explicitly defined in car.ld currently.

It would require some linker script wrapping to achieve it, but I think it would be nice to be able to tag such structures with, let's call it CAR_PERSIST, and they would magically get migrated all the way to CBMEM. I think Julius insisted such symbols must resolve at build-time, so we would need to find a way to lock the symbol locations inside CAR, across the stages, while other sections (.bss) can grow and shrink.

That sounds nice, but how to make sure that the symbols in (I assume you have a new region for it in which CAR_PERSISTS goes?) the new region are the same across pre-ram stages? That would somehow require to use some of the bootblock symbols in verstage and romstage. Sounds a bit hacky to do 'nm' and parse output into something to be included by memlayout.ld of romstage & ramstage?

View Change

To view, visit change 36291. To unsubscribe, or for help writing mail filters, visit settings.