Re: [coreboot] cbfs alignment

[Stefan Reinauer]

* ron minnich  [150717 21:45]:
> 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 statement is true for coreboot tables. CBFS files are aligned
to 64 bytes by default.

You can see if your compiler supports -mno-unaligned-access which will
get rid of the problem for you.
> We can fix it, with an ugly macro, but ... what's the right move here?

1. The cleanest solution would be to have our read32/write32 functions
   exist in aligned and unaligned versions and using the latter for
   accesses to packed data structures. Also the most intrusive, in the
   code base
2. Enable -mno-unaligned-access. 
3. Enable some mechanism in the CPU that will take care of unaligned
   accesses. That's what we do on ARM
4. Write an exception handler that takes care of the problem for you.

Stefan

cbfs alignment

[Julius Werner]

-mno-unaligned-access is ARM32 only, unfortunately. You'd have to
convince GCC developers to generalize it.
> This statement is true for coreboot tables. CBFS files are aligned to 64 bytes by default.

The problem is that the CBFS stage and payload headers themselves
contain inherently misaligned 64-bit values. I guess if the compiler
was really smart it could stack-allocate a struct { u32 a; u64 b; }
__attribute__((packed)) structure at an odd 4-byte boundary, but it
doesn't currently seem to do that (and neither does cbfstool for the
in-ROM structs).