Rudolf, thanks a lot for challenging me and clarifying the problem!
ron minnich wrote:
> Rudolf's point is crucial: "Challenge accepted. They aren't [self
> defining] because they are defined with ABI/compiler:"
>
> As Rudolf points out, we are defining a binary layout with a c
> compiler.
Arthur, your proposal would actually make things worse, surprisingly.
While your proposal would fix a problem, it would change the binary
layout, and create a problem.
Consider the case of a 10y old coreboot, with a modern kernel (Linux)
booting from it. How does linux parse the structures?
Hi,
On 19. 04. 22 11:42, Arthur Heymans wrote:
Nice catch!
Regardless of the upshot of this it's worth fixing this problem in the coreboot
tables implementation.
I'm not very knowledgeable on the topic but don't a lot of CPU ARCH support
unaligned pointer access in hardware but it slows
Dne 12. 04. 22 v 0:04 Peter Stuge napsal(a):
I propose that coreboot tables are a good alternative - fight me! :)
Challenge accepted. They aren't because they are defined with ABI/compiler:
- 64-bit data type alignment is different in 32-bit ABI (4 bytes) and different
in 64-bit ABI (8
ron minnich wrote:
> My goal was pretty simple: Kill the UEFI HOBs, and the FSP UPD, and
> put something better in their place. coreboot tables could easily
> replace HOBs, save that intel will never accept that;
Thanks, now I understand.
> but I don't see coreboot tables replacing UPD.
Why
My goal was pretty simple: Kill the UEFI HOBs, and the FSP UPD, and
put something better in their place. coreboot tables could easily
replace HOBs, save that intel will never accept that; but I don't see
coreboot tables replacing UPD.
[one might argue that what Intel will accept matters a lot
ron minnich wrote:
> peter, you are right about CBOR, and that says to me it does not
> really meet the original goal of self-describing data.
Hm, whose goal is that?
Anyway, using some data structure serialized in CBOR requires
defining the structure somewhere. Using coreboot tables requires
peter, you are right about CBOR, and that says to me it does not
really meet the original goal of self-describing data. But coreboot
tables, at least in my understanding, is also not self-describing.
Do you have some thoughts on a good format that is self-describing?
On Mon, Apr 11, 2022 at 3:05
Martin Roth via coreboot wrote:
> > Your concern is valid and I think a key point. CBOR may not be bad
> > over a socket, but such a complex and arbitrarily extensible format
> > is much too error prone to be a good technical choice during boot.
>
> So if the idea is to create a payload handoff
Apr 1, 2022, 05:43 by pe...@stuge.se:
> Arthur Heymans wrote:
>
>> The context here, was that I voiced some practical concerns about
>>
>> using CBOR as a handoff structure. LinuxBIOS or coreboot tables were
>> carefully designed to be very easy to parse.
>>
>
> Your concern is valid and I think
Hi,
Arthur Heymans wrote:
> I would like to add a few notes to the meeting notes to clarify things a
> bit better.
Thank you for that.
> So the only thing not 'practical' here is that UEFI teams don't have
> control over the handoff structure format that is inside coreboot and
> is used by
Hi
I would like to add a few notes to the meeting notes to clarify things a
bit better.
* In the coreboot meeting, it was suggested that we push to just use
> coreboot tables as they’re already supported in a number of
> payloads. This really isn’t practical however. Intel would
12 matches
Mail list logo
