Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36418 )
Change subject: [NOT FOR MERGE]: Demo adding near_reset_vector symbol ......................................................................
Patch Set 1:
(3 comments)
https://review.coreboot.org/c/coreboot/+/36418/1/src/cpu/x86/16bit/entry16.i... File src/cpu/x86/16bit/entry16.inc:
https://review.coreboot.org/c/coreboot/+/36418/1/src/cpu/x86/16bit/entry16.i... PS1, Line 44: .type _start16bit, @function
With SIPI_VECTOR_IN_ROM _start16bit alignment has to be enforced. […]
Is it not? The .align 4096 is sitting up there still on line 37.
https://review.coreboot.org/c/coreboot/+/36418/1/src/cpu/x86/16bit/reset16.l... File src/cpu/x86/16bit/reset16.ld:
https://review.coreboot.org/c/coreboot/+/36418/1/src/cpu/x86/16bit/reset16.l... PS1, Line 20: _ROMTOP If we are going to define this symbol here we should remove it from line 30?
https://review.coreboot.org/c/coreboot/+/36418/1/src/cpu/x86/16bit/reset16.l... PS1, Line 21: _NEAR_RESET_VECTOR
Well it can't be any higher. […]
The function is aligned to 4096 so yes, it will just pad things, but I don't think the linker will link with those 2 constraints (is that what jenkins was complaining about?).
I believe one needs to align down program counter to 4KiB based on CONFIG(SIPI_VECTOR_IN_ROM) option.
the other thing to incorporate correctly is the fit pointer. It lives at 0xffffffc0 and occupies 8 bytes. It's linker definition is being included conditionally (src/cpu/intel/fit/fit.ld), but this code should not collide with it.
That and we have this default which can encroach on all kinds of stuff as it seems to but up against 0xffffff40 in not the cleanest way: config ID_SECTION_OFFSET
-------hex -------default 0x80
I think the linkers are currently limiting in that they always assume an increasing program counter which we actually want to allocate downwards for these types of things. I ran into this problem trying to get data sections to work in CAR stages that I never fully solved.
That said, I'm thinking we should manually allocate these sections? We're trying to compose everything through #includes (src/arch/x86/memlayout.ld and src/arch/x86/bootblock.ld), but that might be the wrong approach. I'm not sure what the linker will do w/o having a strarting program address but then specify these higher addresses later. I'm beginning to wonder that we should specify alignment constraints for the associated sections, link at a low enough address and then relocate to the final destination. This is what we did for XIP romstage, but we've left bootblock the same. I'm thinking we should go down a different route so we can work around the linker limitations. Thoughts?