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.
Restrict the clk/cmd scan to 1/2 tCK since the full scan is not required
and in some cases can compromise the calibration with the wrong best clk/cmd
value selection.
This should also allow using cmd_latency=0 in all cases.
rprinz08
Florent Kermarrec
Tim Ansell
Stafford Horne
Karol Gugala
Vadim Kaushan
Dolu1990
Piotr Binkowski
Samuel Lindemer
bunnie
Stéphane Gourichon