Attention is currently required from: Arthur Heymans, Julius Werner, Jérémy Compostella, Kapil Porwal, Nico Huber, Patrick Rudolph.
1 comment:
Patchset:
The big difference is binary compatibility. Of course you can start with
something and then maintain the code. But if we want to start with binary
compatibility and maintain binary compatibility (e.g. your very first 2024
payload binary stays compatible with any new coreboot build), then we need
to start with something strictly defined (or it could get rather messy).I've put my thoughts into an email[1]. The gist of it is that I don't
see any disadvantage in trunking, rather advantages. Please share your
thoughts, especially, why the trunking should be avoided.[1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/AVDVXTQVHEHRYRKU5VFZ534ULEEF526I/
Thank you for your response and the valuable discussion.
I'd like to clarify that we don't need to introduce a new standard for x86_64 support in libpayload/payload. We're already following the System V AMD64 ABI, which is the standard convention on most Unix-like systems. For adding 64-bit flow we need to ensure that existing 32-bit model is also backward compatible.
Here's my proposed outline for the next steps:
- Feature/Functional Verification: Thoroughly test the transition from pure 32-bit mode to pure 64-bit mode, ensuring all functionality is preserved.
- Mixed Mode Compatibility: Investigate whether we can support scenarios like booting a 32-bit payload with a 64-bit coreboot, or vice versa.
- Code Review and Refinement: I greatly appreciate Arthur and Patrick R's initial review and streamlining efforts. Further review will help identify areas for optimization and potential issues.
During my work, I didn't encounter a 64-bit exception hence, ignore that it's incomplete. This hasn't caused problems in my testing so far, but it's a critical area to address.
- Completing the 64-bit Boot Flow: If you're interested in contributing, please consider helping with the code review (#3) or implementing the missing feature (exception handling functionality etc.). This will ensure our 64-bit boot flow is as robust as the 32-bit one.Please share your thoughts, especially, why the trunking should be avoided.As per Intel next generation platform guideline, the 32-bit boot is considered legacy and wish to ensure the boot flow follows 64-bit mode completely.
We have seen cases where the below 4GB memory might be exhausted with more SoC IP req and we need to use 64-bit mode of entry.
If we like to keep trunking it might solve the problem for short term but we really need to have pure-64 support to work on Intel next gen device (starting with PTL). We have blocked entire PTL upstream until we finish 64-bit mode using upstream coreboot/payload.
I hope it clarifies the doubt.
Additionally, depthcharge the payload for CrOS has compatibility dependency w/ libpayload meaning, we can't build 64-bit depthcharge.elf w/o 32-bit libpayload image hence, we need to ensure both are getting compiled using same toolchain.
To view, visit change 81960. To unsubscribe, or for help writing mail filters, visit settings.