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