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@google.com> wrote:
On Fri, Jul 17, 2015 at 2:45 PM, ron minnich <rminnich@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@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot