Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36612 )
Change subject: arch/x86: Link .bss and .data in in-CAR stages ......................................................................
Patch Set 2:
(1 comment)
https://review.coreboot.org/c/coreboot/+/36612/1/src/arch/x86/assembly_entry... File src/arch/x86/assembly_entry.S:
https://review.coreboot.org/c/coreboot/+/36612/1/src/arch/x86/assembly_entry... PS1, Line 36: #if !ENV_STAGE_HAS_DATA_SECTION
- We should provide an indicator that provides the semantics you are desiring so it's clear in the code.
The reason I say the above is that it is possible to get data sections in XIP code but we'd need an entry in this path to copy from spi into CAR where the data section resides. In this patch you just want to enable the data section outright since data (and potentially bss) can just move entirely with the program itself during relocation. I think it's helpful to call out those scenarios explicitly with a macro that makes sense while reading the code.
So if I understand it correctly it should deal with
- moving sections like .bss from car.data in the cbfs stage when not running XIP
- adding a .data section to early X86 stages (except bootblock)
- improve some semantics in rules.h
in different CL?
I think we need clear semantics from the get-go:
1. Does this stage have .bss section? 1a. Did this stage have its .bss cleared prior to running? 2. Does this stage have .data section?
Those need to be answered in both linking as well as runtime. With those richer sets of semantics we can make things easier to implement and follow. And, of course, different behaviors fall out from XIP/non-XIP. The picasso boot flow also has an interesting component: romstage has bss and data, but bss isn't cleared from the loader.