Attention is currently required from: Arthur Heymans, Julius Werner, Jérémy Compostella, Kapil Porwal, Nico Huber.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/81960?usp=email )
Change subject: arch/x86: Enable long mode entry into payload for x86_64 support ......................................................................
Patch Set 1:
(1 comment)
File src/arch/x86/boot.c:
https://review.coreboot.org/c/coreboot/+/81960/comment/456af28a_b0396e2d : PS1, Line 25: if (CONFIG(PAYLOAD_X86_64_SUPPORT)) {
AIUI, the payload handover and the coreboot tables are the most important ABI pieces of coreboot. Making this a compile-time option would mean that the resulting coreboot is suddenly incompatible to all prior (x86) payload builds. So, shouldn't this be decided at runtime, maybe based on information from CBFS?
Is it not a fact that using a 64-bit toolchain to compile the libpayload is also a static piece of information? If so, then why are we not allowing a configuration to also enter LB in the desired 64-bit mode instead of limiting it to 32-bit?
Currently, the default/non-configurable decision about LB entry is always in protected mode.
This CL allows for one more option where 64-bit direct entry is also possible, hence all of the following options are now valid:
- 64-bit CB / 32-bit LB (using protected mode)
- 64-bit CB / 64-bit LB (using long mode)
- 32-bit CB / 32-bit LB
If we are relying on the runtime information about coreboot operational mode and using this information to decide whether to jump into LB, then wouldn't that limit #1 (where a protected mode entry into the libpayload is not possible while using 64-bit coreboot)? Perhaps not everyone wishes to use a 64-bit payload, so it would be better to keep those selections static based on the selection of payload mode.
If you are thinking that coreboot in 64-bit mode would break the compatibility with other 32-bit mode payload if we are selecting this Kconfig explicitly then we can choose two below means
1. choose this Kconfig from mainboard rather than SOC directly 2. allow this kconfig only select for chromeos booting (hence, only applies to depthcharge payload)