In some SoCs where UART's PHY is managed externally (ex through a Bridge) we don't
necessarily want the UART TX to wait for the PHY to be ready (and then stall the
CPU) but just want to let the CPU print the UART and will just connect when useful
and handle backpressure when connected.
This is now possible by calling add_auto_tx_flush method, ex in the SoC:
self.uart.add_auto_tx_flush(sys_clk_freq)
Fix gcc warnings: use 'unsigned long' to represent memory addresses,
and remove 'static' from the definition of 'cdelay()', as it is called
from multiple C files.
FemtoRV is a minimalist RISC-V CPU with design process documented and
available at https://github.com/BrunoLevy/learn-fpga.
This CPU is a very nice way to discover/learn RISC-V and this LiteX support
can be useful to learn how to integrate a custom CPU with LiteX.
With this support, FemtoRV is now directly usable with LiteX Sim:
$litex_sim --cpu-type=femtorv
This should also enable its use on all boards (> 50) available in LiteX-Boards
repository (but hasn't been tested yet), ex:
$python3 -m litex_boards.targets.digilent_arty --cpu-type=femtorv --build
As discussed in #909, in some specific cases, it can be interesting to be able
to keep the CPU in reset while the rest of the SoC is still operating (ex the
peripherals/bridges).
With theses changes, the old behaviour is preserved to do a full SoC Reset (at
the exception that writing a 1 is now mandatory) and a separate field specific
to the CPU reset is added.
The SoC Reset is a pulse (otherwise the system would be stuck in Reset) while
the CPU Reset is based on the register value (so can be pulse or hold).
Before this patch, the loop would finish with lowest_div either set to the first failing value
or 0 even if it succeeded with 0. Fix it so that if all tests pass, it’ll end up being -1 before
the incrementation.
This patch also skips retesting the original value. If the retest failed, lowest_div would be incremented past the original value and could potentially wrap around.
* resolve issue #862 add description to soc.svd
The issue is that with no description provided it simply would
not put out a description tag, which breaks compatibility with
other programs.
Insert a somewhat useful default description including a timestamp
and the words "LiteX SoC".
* I2S fix: sample SYNC on the correct edge
The original Tx path implementation samples SYNC on the falling
edge, out of convenience with the fact that teh data must also
change on the falling edge.
This works OK, until you have a CODEC which has a ~40ns max
delay spec on the SYNC, and also has a slightly asymmetric
SYNC edge (the SYNC signal is also the WCLK or LRCLK depending on
which docs you read). The SYNC by spec is supposed to change
on the falling edge, and this extra delay is enough to cause
the SYNC to introduce occassional bit or frame shifts into
the audio.
This fix samples the SYNC on the rising edge, but still
changes the data on the falling edge, thus allowing for
implementations where SYNC has quite loose timings relative
to everything else (as is the case on the TLV320AIC3200)
I am working on testing out the patches from:
https://github.com/litex-hub/linux/pull/8
These linux patches take advantage of the sdcard interrupt to track when
transfers finish. However, it seems the interrupt is not being
connected to the CPU.
This patch does that by allowing us to directly register and
EventManager module with the irq handler.
With recent BIOS changes the default rom size on the mor1kx built just
passes over the 64k boundary and the build fails. Since the 128K
default is a soft limit and the ROM gets resized to the actual ROM
requirements this should be relatively safe.
Note, that if a RW rom is configured the full 128kb will be allocated.
Fixes: #893
When passed as str, the timing dict will be extracted from litex.soc.cores.video.video_timings.
When passed as tuple, custom dict will be directly passed to VTG.
The linker does not actually recognise -nodefaultlibs, that is a compiler
option.
Prior to binutils 2.36, ld treated -nodefaultlibs as a string of short
options and ignored them as unrecognised. Starting from binutils 2.36, it
reports an error instead:
riscv64-unknown-elf-ld: Error: unable to disambiguate: -nodefaultlibs (did you mean --nodefaultlibs ?)
See also: https://sourceware.org/bugzilla/show_bug.cgi?id=27050Fixes#825.
Adding wraps around capability will have to be discussed, if implemented this has to
be done very carefully since there are no relation between the total delay that can
be compensated through the I/O-DELAYs and the SDRAM clock period.
As implemented, it also produced confusing values in the logs:
m0:0 m1:0
Read leveling:
m0, b0: |00000000000000000000000000000000| delays: -
m0, b1: |00000000000011111111111111100000| delays: 19+-07
m0, b2: |00000000000000000000000000001111| delays: 14+-17
m0, b3: |00000000000000000000000000000000| delays: -
m0, b4: |00000000000000000000000000000000| delays: -
m0, b5: |00000000000000000000000000000000| delays: -
m0, b6: |00000000000000000000000000000000| delays: -
m0, b7: |00000000000000000000000000000000| delays: -
best: m0, b01 delays: 19+-07
m1, b0: |00000000000000000000000000000000| delays: -
m1, b1: |00000000000011111111111111000000| delays: 19+-07
m1, b2: |00000000000000000000000000001111| delays: 15+-17
m1, b3: |00000000000000000000000000000000| delays: -
m1, b4: |00000000000000000000000000000000| delays: -
m1, b5: |00000000000000000000000000000000| delays: -
m1, b6: |00000000000000000000000000000000| delays: -
m1, b7: |00000000000000000000000000000000| delays: -
best: m1, b01 delays: 19+-07
Switching SDRAM to hardware control.
--> 14+-17 and 15+-17 are confusing.
This is useful for long-running commands generally and in particular
for those without any data transfer, such as erase. It is a
level-sensitive interrupt because that makes it a little harder to
lose interrupts due to incorrect programming.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Bit 2 of the command register now tells the controller to wait while
the card is indicating that it is busy (by pulling the DAT0 line low).
The card can do this for commands 7 and 12 and app command 41 (and
also for commands 20, 28, 29, 38 and 43, but we don't use those here.)
This sets bit 2 for those commands.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The issue is that with no description provided it simply would
not put out a description tag, which breaks compatibility with
other programs.
Insert a somewhat useful default description including a timestamp
and the words "LiteX SoC".
Not sure why nobody else saw this, but sometime in the last month's
patches sphinx started throwing an error when building docs for
the timer block. The problem is that the body and title are 'None'
and the doc code tries to invoke methods on None.
Changing the doc methodology to AutoDoc and explicitly creating the intro
section fixes this.
RAMXilinx was not infered correctly on Intel/Altera devices, we now have an Intel/Altera specific
implementation and could add other specific implementations in the future if required.
i2c@f0000800: '#address-cells' is a required property
From schema: Documentation/devicetree/bindings/i2c/litex,i2c.yaml
i2c@f0000800: '#size-cells' is a required property
From schema: Documentation/devicetree/bindings/i2c/litex,i2c.yaml
Fix this by adding the missing properties.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
gpio@f0003000: 'gpio-controller' is a required property
From schema: Documentation/devicetree/bindings/gpio/litex,gpio.yaml
gpio@f0003000: '#gpio-cells' is a required property
From schema: Documentation/devicetree/bindings/gpio/litex,gpio.yaml
Fix this by adding the missing properties.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
mmc@f0006800:reg:0: [4026558464, 256, 4026560512, 256, 4026562560, 256, 4026564608, 256] is too long
From schema: dt-schema/dtschema/schemas/simple-bus.yaml
mmc@f0006800:reg:0: [4026558464, 256, 4026560512, 256, 4026562560, 256, 4026564608, 256] is too long
From schema: dt-schema/dtschema/schemas/reg.yaml
Fix this by grouping the tuples in the "reg" property using angle
brackets.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
serial@f0001000: 'device_type' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/serial/litex,liteuart.yaml
Fix this by dropping the offending property.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
interrupt-controller@f0c00000: compatible:0: 'sifive,plic-1.0.0' is not one of ['sifive,fu540-c000-plic', 'canaan,k210-plic']
From schema: Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
interrupt-controller@f0c00000: compatible:1: 'sifive,plic-1.0.0' was expected
From schema: Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
interrupt-controller@f0c00000: '#address-cells' is a required property
From schema: Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
Fix this by correcting the order of the compatible values, and adding
the missing #address-cells property.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Assuming "#[address|size]-cells = <1>", both of the following are
equivalent:
reg = <start1 size1>, <start2 size2>, ..., <startN sizeN>;
reg = <start1 size1 start2 size2 ... startN sizeN>;
The second form appears more widely used and popular, including in
the output of json2dts.py, with the exception of the mac0 node, which
uses the first form. This patch makes output generated for mac0
consistent with that for other DT nodes.
Un-allocated CSRs were already automatically detected so when un-allocated we can just
simply allocate them automatically instead of raising an error. This also allows
simplifying user's code since self.csr.add/self.add_csr will no longer be required.
This commit adds support for enabling interupts in switches module.
Declaring switches as GPIOIn module with with_irq=True
will make dts generation add correct interrupt controller definition.
Also, if SWITCHES_NGPIO constant is defined it will be used to
specify correct number of gpios in dts.
example:
self.submodules.switches = GPIOIn(pads=switches_pads, with_irq=True)
self.add_csr("switches")
self.irq.add("switches", use_loc_if_exists=True)
self.add_constant("SWITCHES_NGPIO", len(switches_pads))
The endianess swapping code caused the core to diverge from microwatt resulting in:
- The xics tests not working as-is: https://github.com/antonblanchard/microwatt/blob/master/tests/xics/xics.h
- byte writes writing to the incorrect byte
This removes endianswapping and minimizes the delta from upstream for the xics irq.h header.
Ex of instance:
from litex.soc.cores import gpio
gpio_in_pads = Signal(16)
self.submodules.gpio_in = gpio.GPIOIn(gpio_in_pads, with_irq=True)
self.add_csr("gpio_in")
Adds the new LiteX's VideoTerminal core to the SoC:
self.submodules.videophy = VideoVGAPHY(platform.request("vga"), clock_domain="vga")
self.add_video_terminal(phy=self.videophy, timings="800x600@60Hz", clock_domain="vga")
This is useful for un-usual boot sequences where the binaries are not
loaded directly by the BIOS but externally (over a bridge for example).
Example of use:
$litex_sim
$litex_bare_metal_demo --build-path=build/sim
$litex_sim --ram-init=demo.bin
Press Esc during the LiteX boot.
litex> help
LiteX BIOS, available commands:
flush_cpu_dcache - Flush CPU data cache
crc - Compute CRC32 of a part of the address space
ident - Identifier of the system
help - Print this help
serialboot - Boot from Serial (SFL)
romboot - Boot from ROM
reboot - Reboot
boot - Boot from Memory
mem_speed - Test memory speed
mem_test - Test memory access
mem_copy - Copy address space
mem_write - Write address space
mem_read - Read address space
mem_list - List available memory regions
litex>
litex> mem_list
Available memory regions:
ROM 0x00000000 0x8000
SRAM 0x01000000 0x2000
MAIN_RAM 0x40000000 0x10000000
CSR 0x82000000 0x10000
litex>
litex> boot 0x40000000
Executing booted program at 0x40000000
--============= Liftoff! ===============--
LiteX minimal demo app built Feb 24 2021 11:30:05
Available commands:
help - Show this command
reboot - Reboot CPU
donut - Spinning Donut demo
litex-demo-app>
The CrossoverUART was in fact a particular UART connected to a second UART. Being able
to have access to multiple UARTs over a Bridge can be useful for several purposes, ex:
SoC0 --> UART0 + JTAGBone + litex_term bridge --bridge-name=UART0
SoC1 --> UART1 +--> SoC --> UARTBone --> LiteX-Server + litex_term bridge --bridge-name=UART1
SoC2 --> UART2 + EtherBone + litex_term bridge --bridge-name=UART2
LedChaser without PWM:
self.submodules.leds = LedChaser(
pads = platform.request_all("user_led"),
sys_clk_freq = sys_clk_freq)
self.add_csr("leds")
Add PWM to it (with default values: 50% duty cycle):
self.leds.add_pwm()
Add PWM with custom default values (25% duty cycle here):
self.leds.add_pwm(default_width=128, default_period=1024)
Then adjust brightness dynamically from the BIOS or your software:
$cat csr.csv:
csr_register,leds_out,0x82003000,1,rw
csr_register,leds_pwm_enable,0x82003004,1,rw
csr_register,leds_pwm_width,0x82003008,1,rw
csr_register,leds_pwm_period,0x8200300c,1,rw
Set PWM to 0%:
$mem_write 0x82003008 0
Set PWM to 25%:
$mem_write 0x82003008 256
Set PWM to 50%:
$mem_write 0x82003008 512
Set PWM to 75%:
$mem_write 0x82003008 768
Set PWM to 100%:
$mem_write 0x82003008 1024
You can also only use default values and disable CSR is dynamic configuration is not
required (with_csr=False) or adjust PWM period if want to use a specific PWM period
in your system.
When the system/bus clock frequency is an exact power-of-2 multiple of
the desired sdcard frequency, we can drive the latter at the "maximum"
speed via the "perfect" divider. That sometimes turns out too fast, so
in order to be conservative, we double the divider, thus halving the
resulting sdclock.
This allows the Linux driver in single-block mode (cmd17-only) to
operate solidly, without running into timeouts from LiteSDCard FSMs.
FIXME: multi-block (cmd18) transfers still time out, so revisit this
after some additional debugging.
Use irqs dict and "rise", "fall" strings instead of Enums:
Ex: pads=Signal(8), irqs={} : 8-bit Input, No IRQ.
pads=Signal(8), irqs={0: "rise", 7: "fall"}: 8-bit Input, rising IRQ on 0, falling IRQ on 1.
Also simplify the logic.
Change wording of demo README to make it more clear what the process is
and how things related. This should help the newcomer and it still
usefull for the triained.
Change the command example to be more copy paste friendly.
Fixes#814
In order for mor1kx to run an SMP kernel shadow registers must be
enabled. This patch adds two new variants:
- linux+smp - basic linux + smp support
- linux+smp+fpu - linux with FPU and smp support
puts() and putsnonl() are very similar, and can share code.
Reduce code size by making the former call the latter.
Impact for a RISC-V build:
$ size console.o.orig console.o
text data bss dec hex filename
868 0 12 880 370 console.o.orig
832 0 12 844 34c console.o
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
When building with --cpu-type=mor1kx:
litex/soc/software/bios/readline.c: In function 'readline':
litex/soc/software/bios/readline.c:271:3: warning: case label value exceeds maximum value for type [-Wswitch-outside-range]
271 | case KEY_END:
| ^~~~
litex/soc/software/bios/readline.c:297:3: warning: case label value exceeds maximum value for type [-Wswitch-outside-range]
297 | case KEY_DEL:
| ^~~~
litex/soc/software/bios/readline.c:281:3: warning: case label value exceeds maximum value for type [-Wswitch-outside-range]
281 | case DEL:
| ^~~~
The C standard does not specify the signedness of "char", hence this
depends on the implementation. On e.g. RISC-V, "char" is unsigned, but
on OpenRISC, it is signed.
Fix this by making the "ichar" variable explicitly unsigned.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
When building the linux-on-litex-vexriscv documentation with Sphinx
v1.8.5:
Sphinx error:
master file linux-on-litex-vexriscv/build/orangecrab/doc/contents.rst not found
The default value of "master_doc" was changed from "contents" to "index"
in Sphinx v2[1]. As the LiteX doc system creates "index.rst", it thus
fails to build with Sphinx v1.x.
Explicitly configure "master_doc" to "index", to make it work with all
versions of Sphinx, regardless of the default.
[1] https://www.sphinx-doc.org/ca/latest/usage/configuration.html?highlight=master_doc
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
When using a non-default VexRiscv cluster config, the netlist for that
config needs to be generated. This requires sbt to be installed.
If sbt is missing, an error message is printed:
sh: 1: sbt: not found
This message may easily be lost in the noise, as the build continues, and fails
later with:
ERROR: Can't open input file `litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/VexRiscvLitexSmpCluster_Cc1_Iw32Is4096Iy1_Dw32Ds4096Dy1_Ood_Wm.v' for reading: No such file or directory
Make the root cause more visible by raising an OSError, and aborting the
build.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
ex reading/writing to scratch register over jtagbone:
In the SoC:
self.add_jtagbone()
Open LiteX Server:
litex_server --jtag
Do the MMAP accesses:
./litex_cli --read 0x4
0x12345678
./litex_clk --write 0x4 0x5aa55aa5
./litex_cli --read 0x4
0x5aa55aa5
If the environment variable TRIPLE is defined, use its value as the
highest priority candidate. Useful for testing new cross-compilers,
or selecting among toolchains in a different priority than the built-in
list.
Now all format issues are fixed, tag all functions taking printf()-style
format specifiers with "__attribute__((format(printf, ...))", enabling
format string checks ("-Wall" includes "-Wformat").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
To fix compiler warnings of the following type:
warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'foo *' [-Wformat=]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
To fix compiler warnings of the following type:
warning: format '%x' expects argument of type 'unsigned int', but argument has type 'long unsigned int' [-Wformat=]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
litex/soc/software/liblitesdcard/sdcard.c: In function 'sdcard_read':
litex/soc/software/liblitesdcard/sdcard.c:476:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
sdblock2mem_dma_base_write((uint64_t) buf);
^
litex/soc/software/liblitesdcard/sdcard.c: In function 'sdcard_write':
litex/soc/software/liblitesdcard/sdcard.c:507:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
sdmem2block_dma_base_write((uint64_t) buf);
^
When casting a pointer (32-bit or 64-bit, depending on the platform) to
a 64-bit integer, an intermediate cast to "uintptr_t" should be used to
avoid warnings like the above.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
There is no need to use "unsigned long" for small numbers related to the
number of characters in a line. Use "unsigned int" instead.
This allows us to drop the casts when calling putnstr(), and fixes compiler
warnings on 64-bit for callsites where the casts were missing:
warning: field precision specifier '.*' expects argument of type 'int', but argument 2 has type 'long unsigned int'
Reported-by: Gabriel Somlo <gsomlo@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
The sizeof operator returns "size_t", which is defined to be "unsigned
int" on 32-bit, and "unsigned long" on 64-bit.
Format it using "%zu", to fix compiler warnings of the following type on
64-bit:
warning: format '%d' expects argument of type 'int', but argument has type 'long unsigned int' [-Wformat=]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
On 64-bit:
litex/soc/software/bios/cmds/cmd_bios.c: In function 'crc_handler':
litex/soc/software/bios/cmds/cmd_bios.c:110:30: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
printf("CRC32: %08x", crc32((unsigned char *)addr, length));
^
Fix this by using the appropriate types (uintptr_t and size_t) for
memory addresses and sizes, which are defined to 32-bit or 64-bit,
depending on the platform.
Note that the specified length must still be smaller than 4 GiB on
64-bit, or it will be truncated, as the crc32() function is currently
limited to a 32-bit size anyway.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
On 64-bit:
litex/soc/software/bios/boot.c: In function 'serialboot':
litex/soc/software/bios/boot.c:216:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
writepointer = (char *) get_uint32(&frame.payload[0]);
^
When casting from a 32-bit integer to a pointer (32-bit or 64-bit,
depending on the platform), an intermediate cast to "uintptr_t" should
be used to avoid warnings like the above.
Note that using a 32-bit integer is OK, even on 64-bit, as this is
specified by the boot protocol.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
To fix compiler warnings of the following type:
warning: format '%lu' expects argument of type 'long unsigned int', but argument has type 'unsigned int' [-Wformat=]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
To fix compiler warnings of the following type:
warning: zero-length gnu_printf format string [-Wformat-zero-length]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Set the PRINTF_SPECIAL flag when printing pointers, so they are prefixed
by "0x", to match glibc behavior.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
As per convention, the types of size_t, ptrdiff_t, intptr_t, and
uintptr_t should be based on "long" or "int" depending on the platform
(32-bit or 64-bit).
This fixes compiler warnings of the following type:
litex/soc/software/liblitesdcard/sdcard.c: In function 'sdcard_read':
litex/soc/software/liblitesdcard/sdcard.c:476:39: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
sdblock2mem_dma_base_write((uint64_t)(uintptr_t) buf);
^
Reported-by: Gabriel Somlo <gsomlo@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
The value of ULONG_MAX should depend on the size of "long".
While at it:
- Add missing "UL" and "U" suffixes to large unsigned values,
- Make INT_MIN and SHRT_MIN explicitly negative,
- Use decimal instead of hexadecimal values, for easier comparison
with /usr/include/limits.h.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
__WORDSIZE is defined by glibc, not by the compiler. Hence it is never
defined for us, and checking __WORDSIZE to determine the size of "long"
thus causes subtle misbehavings.
Fix this by checking for the presence of __LP64__ instead.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
It's probably better not mixing uploading/flashing utilities. Flashing should be
done with the proper bootloader (as we are doing on Fomu/OrangeCrab for example).
Keeping board definition files directly in LiteX is no longer useful since we are already relying on board
definitions files from LiteX-Boards (https://github.com/litex-hub/litex-boards) in various benches/projects
and having definitions files directly in LiteX creates confusion/additional work.
For projects using board definition files from LiteX, the litex.boards import can just be replaced with litex_boards:
from litex.boards.platforms import kc705
from litex_boards.platforms import kc705
- shorten args description.
- avoid mixing initrd_start/initrd_start_offset: just use initrd_start and indicate it's relative.
- others minor cleanups.
This is needed as my initrd size is much larger than the default 8mb.
Also, sometimes the kernel I build is also large, so its good to be
able to move the initrd starting position.
Issue #748
This is useful to know the memory regions available and use the mem_xy commands
on them:
List the memory regions:
litex> mem_list
Available memory regions:
ROM 0x00000000 0x8000
SRAM 0x01000000 0x2000
MAIN_RAM 0x40000000 0x10000000
CSR 0x82000000 0x10000
Test 0x1000 bytes of MAIN_RAM:
litex> mem_test 0x40000000 0x1000
Memtest at 0x40000000 (4KiB)...
Write: 0x40000000-0x40001000 4KiB
Read: 0x40000000-0x40001000 4KiB
Memtest OK
Test speed on 0x1000 bytes of MAIN_RAM:
litex> mem_speed 0x40000000 0x1000
Memspeed at 0x40000000 (4KiB)...
Write speed: 352KiB/s
Read speed: 288KiB/s
My thought is that if we are running linux the FPGA should be able to
handle these extra instruction's footprint. Also, since we are running
on linux there may be any kind of software running on the CPU, so allow
handling these instructions.
FPU is added bia a new +fpu extension.
But really, I am running GLIBC tests and they run faster with this
enabled.
Allow sharing same json file between serial boot and Ethernet/SDCard/SATAboot:
boot.json:
{
"Image": "0x40000000",
"rv32.dtb": "0x40ef0000",
"rootfs.cpio": "0x41000000",
"opensbi.bin": "0x40f00000"
}
If boot.json and images are located in images directory, using lxterm --images=images/boot.json
will now work.
Used to demonstrates how to easily create baremetal apps, boot to it with LiteX and
also ease litex_term testing.
To build it: export BUILD_DIR=xxyy/litex/litex/boards/targets/build/arty && make
To load it: lxterm /dev/ttyUSB1 --kernel=demo.bin
--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
[LXTERM] Received firmware download request from the device.
[LXTERM] Uploading demo.bin to 0x40000000 (9264 bytes)...
[LXTERM] Upload complete (9.8KB/s).
[LXTERM] Booting the device.
[LXTERM] Done.
Executing booted program at 0x40000000
--============= Liftoff! ===============--
LiteX minimal demo app built Dec 10 2020 17:13:02
Available commands:
help - Show this command
reboot - Reboot CPU
led - Led demo
donut - Spinning Donut demo
litex-demo-app> led
Led demo...
Counter mode...
Shift mode...
Dance mode...
litex-demo-app> donut
Donut demo...
$$$$$@@@@@
$##########$$$$$$$$
###*!!!!!!!!!***##$$$$$$
***!!====;;;;===!!**###$$$$#
**!===;;;:::::;:===!!**####$##
!*!!==;;:~-,,.,-~::;;=!!**#######!
!!!!=;:~-,.......-~::==!!***#####*
!!!!==;~~-.........,-:;==!!***###**!
!**!!=;:~-... ..-:;=!!!********!
;!*#####*!!;. ~:;==!!!******!!=
:!*###$$$$#*! :;==!!!!!****!!!=;
~=!*#$$$@@@$$##!!!!!!!!!!!!****!!!!=;
;=!*#$$$@@@@$$#*******!*!!*!!!!!==;~
-;!*###$$$$$$$###******!!!!!!!===;~
-;!!*####$#####******!!!!!!==;;:-
,:=!!!!**#**#***!!!!!!!====;:~,
-:==!!!*!!*!!!!!!!===;;;:~-
.~:;;========;=;;:::~-,
.--~~::::~:~~--,.
litex-demo-app>
should have no impact on normal operation, the path is
only for registering addresses that are correlated with
ECC errors as reported by the OPI device.
