[coreboot] cbfs alignment

[Aaron Durbin]

On Fri, Jul 17, 2015 at 3:27 PM, ron minnich <rminnich at gmail.com> wrote:
> bummer. We're going to have to add marshalling code to cbfs, to copy


Ya. You'd need to fix cbfs as well is my guess.

> pointers from the architecture we're on to the architecture we're on, which
> was compiled by gcc for the architecture we're on, compiled on the
> architecture we're not on, to conform to rules for an architecture we're not
> on.
>
> goodbye, a = b
> hello, memcpy(&a, &b, sizeof(a));
> barf.

Ya. And since this is C it makes for some really annoying work. Now if
you write a spec that can be processed by a machine for all these
serialized structs we could generate code based on the CPU's
constraints.


>
> ron
>
> On Fri, Jul 17, 2015 at 1:23 PM Aaron Durbin <adurbin at google.com> wrote:
>>
>> On Fri, Jul 17, 2015 at 2:45 PM, ron minnich <rminnich at gmail.com> wrote:
>> > riscv is taking alignment traps reading cbfs.
>> >
>> > The issue is that 64-bit fields are 32-bit aligned, which fails many
>> > places.
>> >
>> > Thaminda found this comment:
>> >
>> >   * Since coreboot is usually compiled 32bit, gcc will align 64bit
>> >  * types to 32bit boundaries. If the coreboot table is dumped on a
>> >  * 64bit system, a uint64_t would be aligned to 64bit boundaries,
>> >  * breaking the table format.
>> >
>> > this is a real problem. Would have broken badly on Alpha, and breaks
>> > badly
>> > on RISCV.
>> >
>> > We can fix it, with an ugly macro, but ... what's the right move here?
>>
>> You mean how none of the structs in src/include/boot/coreboot_tables.h
>> have a packed attribute decorated on them? And they should be marked
>> packed since these are a serialized format. That's not really going to
>> help you.
>>
>> One thing you do is break up all uint64_t in that header to be a
>> struct of 2 uint32_t -- which is what lb_uint64 was for I assume. What
>> that means is the types all need to be marshalled properly, and you'd
>> have to do this as it is if RISC V doesn't support unaligned accesses.
>>
>> In general, coreboot has been largely written to assume unaligned
>> accesses are no big deal (thanks, x86!). Because of this architectures
>> like ARM *have* to get their MMUs up to enable normal memory so that
>> it can honor the "handle unaligned accesses".
>>
>> >
>> > ron
>> >
>> > --
>> > coreboot mailing list: coreboot at coreboot.org
>> > http://www.coreboot.org/mailman/listinfo/coreboot