When shipping MNT RKX7, I pre-flash the SPI flash with a LiteX bitfile
for testing. cmd_spiflash had regressed because of changed SPIFLASH defines
and didn't offer the write functions anymore. This commit fixes that, and
adds convenience functions:
- flash_erase_range <offset> <count (bytes)>
- flash_from_sdcard <filename>
The latter reuses some boot code to copy the contents of the specified
file from the boot FAT partition on the SD card to SPI flash (i.e.
a bitstream).
commit 3fa3080e introduced an additional address length paramater to
i2c_write to support non 8bit memory addresses.
But the parameter wasn't added to the call of i2c_write in i2c_send_init_cmds.
This commit fixes the issue by adding the address length parameter to
the call of i2c_write.
The naming convention for LiteX Rocket variants has become overly
complex. Simplify it while at the same time adding more flexibility.
There is a new set of instances of varying main RAM memory bus port
width (1x (64bit), 2x (128bit), 4x (256bit), and 8x (512bit)), of
each of the following principal LiteX specific Rocket models:
- small: (rv64imac, no MMU, no S, no FPU)
- medium: (rv64imac, adds MMU and S-mode)
- linux: (rv64imafdc, adds FPU, supports linux distros)
- full: (rv64imafdcbkph[+], adds hypervisor support)
NOTE: before adding H support, the feature set of the old `full`
model is now represented by the `linux` model. The old `linux`
did not use to have an FPU, and is now available as `medium`.
In addition to the range of memory port widths, each model
will be instantiated in 1, 2, 4, and 8 core variants. The
naming convention is `LitexConfig_<model>_<num_cores>_<mem_width>`.
E.g. `LitexConfig_full_8_2` for an 8-core full model with
a 128bit main RAM AXI port. On the build command line, this
example would look like:
...
--cpu-type rocket --cpu-variant full \
--cpu-num-cores 8 --cpu-mem-width 2 \
...
There are a total of 4 * 4 * 4 = 64 (sub-)variants: each of the four
principal models can be fitted with one of four core counts, and one
of four memory bus widths.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
Resolves the error:
cpu/rocket/irq.h:23: Error: unrecognized opcode `csrr a4,mstatus',
extension `zicsr' required
Rocket and cva6 missed this in commit 0e2a1b54a4 as they are 64bit
CPUs, and that change only updated the 32bit CPUs.
Tested with litex_sim and riscv64-unknown-elf-ld 2.40-2+4+b1 (Debian
Bookworm).
Signed-off-by: Joel Stanley <joel@jms.id.au>
Without this, reset was never being asserted which caused problems on
hardware (probably because the CPU started running while the rest of the
SoC had reset asserted...)
Signed-off-by: gatecat <gatecat@ds0.me>
Florent Kermarrec
Lukas F. Hartmann
Hans Baier
dasdgw
Gabriel Somlo
Joel Stanley
Tim Paine
Gwenhael Goavec-Merou
gatecat
Lasse Dalegaard
Jeremy Herbert