Attention is currently required from: Arthur Heymans, Julius Werner, Jérémy Compostella, Kapil Porwal, Patrick Rudolph, Subrata Banik.
2 comments:
Patchset:
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.
Have you read the System V AMD64 ABI? It's for user-space programs and seems
rather complex to apply to our case. Do you mean its function calling convention
only maybe? That would seem ok to me to use. But we need more, like memory mapping.
[...]
- 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.
I would like to help with the review. But without a decision about the general
direction, it's very expensive. I see already patching forth and back because
now and then somebody shows up with a different opinion, and reactions to this
before a consensus is found. I'm afraid I don't have the time to follow when
people seem to be running in circles.
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.
It strengthens my doubt. AFAICT, coreboot is coreboot and successful because it
didn't follow Intel guidelines. What architecture is this PTL? You mananaged to
create a situation where memory was exhausted, I believe you, but how can we tell
without details if this affects upstream coreboot?
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.
I don't understand. What is this "32-bit libpayload image" that you need? I
guess everybody compiles libpayload and the payload with the same toolchain.
Patchset:
Personally, I don't think the two entry points are really worth it. I'd posit that while compatibility of newer coreboot versions to older payloads is nice and something we have preserved for a long time, compatibility of older coreboot with newer payloads gets broken regularly anyway and not something people really care about. Basically every time we add a new coreboot table entry (which happens a lot), that's usually to communicate something to the payload that it requires (and it won't work right and often hang without it), and I don't recall anybody ever complaining about that.
Can you give an example where something like this hit x86 payloads in general? I
just scrolled through the last 5 years of coreboot_tables.h and couldn't see
anything. Maybe I'll try later if I find the time.
In practice I think that while payloads may be binaries that get reused after a coreboot update, the people who do build their own payload also tend to build their own coreboot anyway (and keep their payload repo synced to whatever coreboot branch they're planning to use it with, not ToT).
I just happen to work on a project where we need to update our payloads of
older products and we plan to make it one ToT payload without touching all the
coreboots. That's just an example that these things are happening, it doesn't
say anything about 64-bit payloads, because we're not making it 64-bit rn.
However, it's the stable nature and ecosystem of x86 that makes this possible
without much hassle.
To view, visit change 81960. To unsubscribe, or for help writing mail filters, visit settings.