[coreboot] cbfs alignment

ron minnich rminnich at gmail.com
Fri Jul 17 22:27:25 CEST 2015


bummer. We're going to have to add marshalling code to cbfs, to copy
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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150717/6fe83ee2/attachment.html>


More information about the coreboot mailing list