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