This is needed to specify timing constraints on some Lattice Diamond
library specials, like the EHXPLLL.
To keep backwards compatibility we allow the directive to still be a
single string. If it's not, we assume it's an iterable.
Well, at least PicoRV32-specific. Turns out there is no RISC-V
specification for simple microcontroller-like interrupts, so PicoRV32
implements its' own based on custom opcodes.
It's somewhat esoteric, and for example doesn't offer a global interrupt
enable/disable. For this we implement a thin wrapper in assembly and
then expose it via a few helpers in irq.h.
Modified flashboot() to skip copy to main ram if there is no main
ram, and instead execute in place out of SPI flash. (For this to
work the linker .ld will also need to redirect references to be
inside the SPI flash mapping.)
Swaps hard coded PORT_OUT in tftp.c for parameter on the tftp_get()
and tftp_put() functions. Allow TFTP_SERVER_PORT used by BIOS to be
set at compile time from compiler defines.
Otherwise you can't override the UART with another UART, you get an
error like;
```
File "/home/tansell/github/timvideos/HDMI2USB-litex-firmware/third_party/litex/litex/soc/integration/soc_core.py", line 176, in __init__
interrupt, mod_name, interrupt_rmap[interrupt]))
AssertionError: Interrupt vector conflict for IRQ 2, user defined uart conflicts with SoC inbuilt uart
```
Increases the initial delay step into the valid read window as
with the original delay I was not getting out of the noisy
transition window, as evidenced by seeing read delay windows
of only 8 LSB ~10% of the time, leading to failing memory
tests
It is useful to support slightly different variants of the CPU
configurations. This adds a "cpu_variant" option.
For the mor1k we now have the default mor1k configuration and the
"linux" variant which enables the features needed for Linux support on
the mor1k.
Currently there are no variants for the lm32, but we will likely add a
"tiny" variant for usage on the iCE40.
Previously we would wait the same number of iterations as it took us to
receive the first data block after sending the request. When using the
build in tftp server in qemu, the first wait loop succeeds (and thus
breaks when 'i' is still 0.
Since the counter was never reset between the first and second data
block, under qemu the tftp_get call would fail before ever checking if
we have received the second block of data.
Now that we initialise 'i' to 12M, we ensure that we wait the same
amount of time for the second data block as it previously did for the
third (and subsequent) blocks.
Sergiusz Bazanski
Florent Kermarrec
Ewen McNeill
William D. Jones
Tim Ansell
Felix Held
Chris Ballance
Tim 'mithro' Ansell
Greg Darke