Attention is currently required from: Arthur Heymans, Julius Werner, Jérémy Compostella, Kapil Porwal, Nico Huber, Patrick Rudolph.
View Change
1 comment:
Patchset:
Patch Set #2:
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.
To view, visit change 81960. To unsubscribe, or for help writing mail filters, visit settings.
Gerrit-Project: coreboot
Gerrit-Branch: main
Gerrit-Change-Id: Ic5e6f0af11c05e8b075b8c20880c012747a1df9b
Gerrit-Change-Number: 81960
Gerrit-PatchSet: 11
Gerrit-Owner: Subrata Banik <subratabanik@google.com>
Gerrit-Reviewer: Arthur Heymans <arthur@aheymans.xyz>
Gerrit-Reviewer: Julius Werner <jwerner@chromium.org>
Gerrit-Reviewer: Jérémy Compostella <jeremy.compostella@intel.com>
Gerrit-Reviewer: Kapil Porwal <kapilporwal@google.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply@coreboot.org>
Gerrit-CC: David Hendricks <david.hendricks@gmail.com>
Gerrit-CC: Matt DeVillier <matt.devillier@gmail.com>
Gerrit-CC: Nico Huber <nico.h@gmx.de>
Gerrit-CC: Patrick Rudolph <patrick.rudolph@9elements.com>
Gerrit-CC: Werner Zeh <werner.zeh@siemens.com>
Gerrit-Attention: Nico Huber <nico.h@gmx.de>
Gerrit-Attention: Patrick Rudolph <patrick.rudolph@9elements.com>
Gerrit-Attention: Jérémy Compostella <jeremy.compostella@intel.com>
Gerrit-Attention: Kapil Porwal <kapilporwal@google.com>
Gerrit-Attention: Julius Werner <jwerner@chromium.org>
Gerrit-Attention: Arthur Heymans <arthur@aheymans.xyz>
Gerrit-Comment-Date: Mon, 22 Apr 2024 15:46:31 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Nico Huber <nico.h@gmx.de>
Comment-In-Reply-To: Subrata Banik <subratabanik@google.com>
Gerrit-MessageType: comment