Kyösti Mälkki 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:
(1 comment)
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 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); : }
Right. It's been a while since I've dealt with the romcc one. […]
I think the restriction today (and in the future) is that reset16, entry16 and entry32 (.inc) all need to reside in the top 64 KiB (for !RESET_VECTOR_IN_RAM). Since we fall from entry32.inc to bootblock_crt0.S without a jump, this would effectively make bootblock_pre_c_entry the first symbol that could be outside top 64 KiB. My reasoning is that it is at the end of entry32.inc where linear mode addressing is completely set up.
Whether cache_as_ram.S is linked in the top 64 KiB should not matter. These assembly parts would probably all fit in the top 4 KiB (unless there are FIT or something else consuming same space), adding some section-statements should achieve this if ever necessary.