A little endian machine will interpret this as a slice with the wrong byte order.
One solution is to byte-swap the entire binary before flash (e.g. modify artiq_mkfs.py). It is a somewhat clean solution as long as the flash content need not be modified, which brings us into the next part.
Modifying the flash
To make our {"foo": "1"} understandable by Rust (or other platforms), the bytes needs to be rewritten into the following hexdump.
(Note: The terminating 0xffs might need to be padded to align with 16 bytes, but for the sake of simplicity, let's ignore the termination all together.)
Suppose the flash is to be modified on runtime, e.g. append one more entry {"bar": "2"}. One naive solution is to write the binary representation from address 0x0a onward, the following might be the result.
(With the encoding beyond "bar" omitted, this should give a clear enough picture.)
Modifying existing code to fit this case is totally doable. However, adding little endian support to the SPI flash would be a cleaner solution.
Notes
I think there are too many "set little-endian if it uses vexriscv, otherwise big-endian" statements (including previous patches e.g. #117), should we refactor the endianness argument at some point?
Changes
dqsubsignal in the platform)Issue with flashing a byte-swapped binary
111 byte-swaps the BIOS binary into little-endian, if the target CPU was configured with
vexriscv.Although it ensure the instructions read from SPI flash is with the correct endianness, configuring the flash becomes messy.
Configure for read
This can be demonstrated with reference to
artiq_mkfs, suppose we have an entry of{"foo": "1"}in the flash with swapped endianness.A little endian machine will interpret this as a slice with the wrong byte order.
One solution is to byte-swap the entire binary before flash (e.g. modify
artiq_mkfs.py). It is a somewhat clean solution as long as the flash content need not be modified, which brings us into the next part.Modifying the flash
To make our
{"foo": "1"}understandable by Rust (or other platforms), the bytes needs to be rewritten into the following hexdump.(Note: The terminating
0xffs might need to be padded to align with 16 bytes, but for the sake of simplicity, let's ignore the termination all together.) Suppose the flash is to be modified on runtime, e.g. append one more entry{"bar": "2"}. One naive solution is to write the binary representation from address0x0aonward, the following might be the result.(With the encoding beyond
"bar"omitted, this should give a clear enough picture.)Modifying existing code to fit this case is totally doable. However, adding little endian support to the SPI flash would be a cleaner solution.
Notes
I think there are too many "set little-endian if it uses vexriscv, otherwise big-endian" statements (including previous patches e.g. #117), should we refactor the endianness argument at some point?