Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35035 )
Change subject: arch/x86: Implement RESET_VECTOR_IN_RAM ......................................................................
Patch Set 9: Code-Review+1
(2 comments)
https://review.coreboot.org/c/coreboot/+/35035/8/src/arch/x86/early_dram.ld File src/arch/x86/early_dram.ld:
https://review.coreboot.org/c/coreboot/+/35035/8/src/arch/x86/early_dram.ld@... PS8, Line 37: *(.near_reset_vector); Does this work? I did some tests using the same code but with the regular below 4G bootblock and it needed KEEP(), but I'm not really sure why.
https://review.coreboot.org/c/coreboot/+/35035/8/src/arch/x86/early_dram.ld@... PS8, Line 27: /* : * .near_reset_vector is used to position code that must be reachable : * from the reset vector. For a program size <= 64KB, this happens by : * default, however with > 64KB it is artificially enforced. : */ : _NEAR_RESET_VECTOR = CONFIG_ROMSTAGE_ADDR + CONFIG_RAM_RESET_VECTOR_STAGE_SIZE - 0x100; : _RESET_VECTOR = CONFIG_ROMSTAGE_ADDR + CONFIG_RAM_RESET_VECTOR_STAGE_SIZE - 0x10; : : . = _NEAR_RESET_VECTOR; : .near_reset_vector . : { : *(.near_reset_vector); : }
Hmm, sure. AFAIK there's never been a need to worry about it because bootblock is never more than 64K. Do you think that's worth considering (or in the future)? coreboot still essentially allows systems with two different types of bootblocks, and I'm not currently using reset16.ld at all. I'm just trying to picture how things would need to change to make it happen, and whether that ultimately makes things more confusing for the reader.
Currently you have either a romcc top aligned bootblock that uses a custom linker script or the C_ENVIRONMENT_BOOTBLOCK which uses arch/x86/memlayout.ld. The latter one has a predefined size that currently goes only go up to 64KiB, but with this code placing the 16 to 32 bit entry at a fixed point allows it to grow beyond 64KiB. This is currently not a problem as 64KiB is enough but it's nice to know the solution is there.