When playing with CPUs and variants, users previously had to do a rm -rf build to ensure
a proper software build. Various developers already lost time on it so it's important
to handle it directly in the Builder which is now the case.
-litex_json2dts_linux (previously litex_json2dts).
-litex_json2dts_zephyr (previously litex_zephyr_dts_generator).
-litex_json2renode (previously litex_renode_generator).
litex_json2dts_zephyr and litex_json2renode are now also directly exposed.
- Fix compilation in sdram.c.
- Fix warnings.
- Move Sequential/Random mode printf to memtest.
- Reduce SPI Flash test size (Testing full SPI Flash makes the boot too long, especially in random mode).
Without this change, when `.data` section size wasn't multiple
of word size, `data_loop` in crt0 was jumping over `_edata` and
continued looping. As it works on words and right now 64 bit CPUs
are biggest ones supported - alignment is now 8 bytes.
Also removed `- 4` from stack address, as it needs to be aligned
to 16 bytes on RISC-V.
The current code only works with a memory bus because otherwise
"generate_cluster_name" doesn't get called.
Cluster_name is only needed in the finalize phase.
Therefore, the name will now be generated just before its usage.
Verifiable with:
litex_sim --cpu-type vexriscv_smp (should be broken before this commit)
RISC-V requires stack to be aligned to 16 bytes.
1d5384e669/riscv-elf.md?plain=1#L183
Right now, in bios/linker.ld, `_fstack` is being set to 8 bytes
before the end of sram region.
```
PROVIDE(_fstack = ORIGIN(sram) + LENGTH(sram) - 8);
```
Removing ` - 8` makes it aligned to 16.
Also there are changes in crt0.S for vexriscv,
vexriscv_smp and cv32e40p.
Code that was setting up stack, was adding 4 to its address
for some reason.
Removing it makes it aligned to 8 bytes, and with change in
bios/linker.ld to 16 bytes.
It also fixes `printf` with long long integers on 32bit
CPUs ([relevant issue](https://github.com/riscv/riscv-gcc/issues/63)).
A regular CPU can provides specific mapping constraints and we are overriding provided mapping
with these constraints.
The case of CPUNone is different and we can do the opposite: Give priority to User's mapping.
For the regular CPU case, the override was done silently, it is now logged during the build.
- Rename optional #define and allow defining them externally.
- Add comments.
- Rename FLASH_CHIP_MX25L12833F_QUAD to SPIFLASH_MODULE_QUAD_CAPABLE.
- Rename FLASH_CHIP_MX25L12833F_QPI to SPIFLASH_MODULE_QPI_CAPABLE.
The instructions used for QUAD/QPI are probably different between chips, we could
imagine providing them through the LiteX integration based on the passed SPI Flash
module.
One small FPGAs running the BIOS from SPI Flash, the default divisor of 9 was slowing down too
much BIOS boot time (It was OK on reboot after liblitespi auto-calibration). Reduce the default
divisor to avoid this.
The implementation was causing regressions on actual designs, rework done:
- Only keep a common iteration loop as before.
- Add iteration on CLKO dividers (to fall in the VCO range).
- Do the iterations as before, if while doing it we find a clock suitable for feedback: just use it.
- If no feedback clock has been found: create it (if at least one free output available, if not raise an error).
Florent Kermarrec
Michal Sieron
Filip Kokosinski
David Sawatzke
Christian Klarhorst
Mateusz Holenko
Dan Callaghan
Jędrzej Boczar
developandplay