Fixes an issue with Vivado which crashes with SIGSEGV when building litex-buildenv at:
cc003bef3a
and litex bumped to 4a18b828bc,
with options:
CPU=mor1kx; CPU_VARIANT=linux; PLATFORM=arty; FIRMWARE=linux; TARGET=net
The only difference in Verilog is that we avoid creating new Interface and doing
`new_interface.connect(interface)`, so this shouldn't make any difference, but
this somehow generates the error in Vivado (tested on v2018.3 and v2019.2).
- Make sure MOSI is latched on start, MISO is stable during Xfer (last value).
- Allow clk_divider down to 2.
- improve test errors reporting with hex() on AssertEqual.
For example:
{
"Image": "0x40000000",
"bootargs": {
"r1": "0x12345678",
}
}
will copy Image to 0x40000000 and set r1 to 0x12345678.
By default, r1,r2,r3 are set to 0 and addr is the address if the last loaded image, so:
{
"Image": "0x40000000",
"rootfs.cpio": "0x40800000",
"rv32.dtb": "0x41000000",
"emulator.bin": "0x41100000",
}
is equivalent to:
{
"Image": "0x40000000",
"rootfs.cpio": "0x40800000",
"rv32.dtb": "0x41000000",
"emulator.bin": "0x41100000",
"bootargs": {
"r1": "0x00000000",
"r2": "0x00000000",
"r3": "0x00000000",
"addr": "0x00000000",
}
}
Otherwise we have at least an extra addition in the loop
which squews the result compared to the read loop.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
In a couple of places, memtest uses %x to print a pointer which
is illegal (and could be problematic on 64-bit). Use %p instead.
Additionally, use %ld when printing longs
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Testing on nexys4ddr and rocket, approximately 12 iterations of the
timeout loop (using `busy_wait(1)`) are needed to receive a "ready"
response from the SDcard, assuming a "warm" reset where the card has
already been previously initialized.
If the SDcard is ejected and re-inserted, or if the board is "cold-reset"
(e.g., reprogrammed via openocd vs. a simple push of the reset button),
it takes approximately 450 iterations before the SDCard responds with a
"ready" message.
In either case, a timeout of 10 is insufficient. This patch increases
the busy-wait to 10, and the timeout loop counter to 128, which should
cover most cases.
Additionally, make a few minor cosmetic improvements.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>