On Friday, July 17, 2015 03:32:43 PM Aaron Durbin wrote:
On Fri, Jul 17, 2015 at 3:27 PM, ron minnich rminnich@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.
Not really. It's OK to be extra careful when generating the CBFS headers, but it's also nice to have a clean simple format that can be easily parsed from assembly (haven't we seen that before?).
Long term, we might want to look at the benefits of consolidating the table format. At the very least, we shouldn't care enough about how gcc aligns things, that there's a multi-line comment about it.
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.
Well, similar schemes exist already (see nanopb).
Alex
Is there no way to make RISCV support unaligned accesses? There's a bunch of things in coreboot (and especially libpayload) that depend on it. I think that it generally makes code look much simpler (and run faster) if you can assume that it's supported across the board.
If we do need to make CBFS unaligned access aware, we should do it with some inline functions that fold into a simple read on the platforms that support them in hardware.
(Depending on how many such accesses you have and what your context switch costs are, it might also be feasible to emulate it in an exception handler... that way you wouldn't need to hunt down every single occurrence we've accumulated over the years.)
-
Julius Werner -
mrnuke