Arthur Heymans 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:
(1 comment)
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 21: _NEAR_RESET_VECTOR
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?
I like that approach. It would remove the need to specify the bootblock size. Are alignments something that can be/ are taken care of when relocating the program?