<shenki>
hello! i am attempting to boot linux on vexriscv in verilator, and it has been sitting on "--========== Booting Linux =============--" for several minutes
<shenki>
is there a way to see what is going on under the hood?
freeemint has quit [Remote host closed the connection]
<xobs>
john_k: I didn't include Python because I assume the user has a Python on their system already. If I were to include a Python I'd want one statically linked against musl at least.
freemint has joined #litex
<guan>
has anyone here gotten linux-on-litex-vexriscv working on the versa ecp5 board? using the prebuilt bitstream, my lxterm says "[LXTERM] Starting...." and then stops
<guan>
i'm on a mac, i can get blinky and other stuff working on the board fine, and it says "svf file programmed successfully"; there are two tty's associated with the FTDI chip, i'm using the first one
freemint has quit [Ping timeout: 245 seconds]
freemint has joined #litex
freemint has quit [Remote host closed the connection]
freemint has joined #litex
<shenki>
guan: i'm trying to get the same going on arty
<guan>
shenki: oh that reminds me, i also tried on an arty, same result iirc :-)
<guan>
the README says speed is 1e6 (1 MHz?), I wonder where to check if that’s correct
<shenki>
yeah. iw wonder when this last worked
<shenki>
_florent_: when did you last have the vexriscv linux booting?
<shenki>
[ 0.000000] Linux version 5.0.13 (joel@voyager) (gcc version 8.3.0 (Buildroot 2019.11-git-00298-g5c9e9ef10087)) #1 Tue Sep 17 22:24:09 ACST 2019
<shenki>
root@buildroot:~# dmesg |head
<shenki>
futarisIRCcloud: yes!
<futarisIRCcloud>
Cool
<shenki>
does someone have a git tree with the linux kernel patches?
CarlFK has joined #litex
<_florent_>
shenki: i think you had an issue with emulator.bin, i need to add compilation of emulator when building the board
<_florent_>
shenki: i'll try to do that now, otherwise, i'm using linux-on-litex-vexriscv regularly to check we don't have regressions on LiteX and the cores
<tpb>
Title: linux 5.0 on vexriscv on arty · GitHub (at gist.github.com)
<_florent_>
shenki: i saw the warning on linux 5.0, but the behaviour was clearly different depending the dtb i was providing, so even if there is a warning, the kernel seems to use the dtb
<daveshah>
guan: you want to use the second tty on the Versa for serial comms, the first is for programming
<shenki>
that subsystem is about reset lines for IP blocks
<shenki>
for when you have a GPIO that keeps a bit of IP in reset when it's not being used
<futarisIRCcloud>
Whoops. :P
<shenki>
you are not the first person to make that assumption
<shenki>
it looks like there are a pair of drivers that do use it for resetting the CPU
<shenki>
register_restart_handler is where lots of SoCs register their reboot handler
<shenki>
lots appear to put their driver in drivers/power/reset
<_florent_>
shenki: in case you want to customize the .dts for that, in json2dts.py, you will get the csr reset address for the CPU with: d["csr_registers"]["ctrl_reset" ]["addr"]
<shenki>
cool. I'll cook up a patch
<_florent_>
great, thanks!
<shenki>
_florent_: can we use gdb on the host to debug code on the FPGA?
<xobs>
shenki: You can use the uart bridge, USB bridge, SPI bridge... basically any bridge ought to work.
<shenki>
hey xobs. i am on the arty, so i'll try uart to start with
<xobs>
Sure. Just enable the bridge, map the debug region, and run "wishbone-tool -u [/dev/serial-port] -s gdb"
<_florent_>
shenki: since the uart is already used by linux, maybe it would be easier to use a USB<-->Serial module on a PMOD and do a UART wishbone bridge with it
<xobs>
You might also want to add "--bind-addr 0.0.0.0" if you're debugging it from a different machine.
<xobs>
And I'd imagine the uart is somewhat similar.
<_florent_>
shenki: i'm preparing a patch for soc_linux to add a UART wishbone bridge
<shenki>
thanks
<shenki>
xobs: I'm intrigued by RandomFrimwareROM. What did you do there?
<xobs>
shenki: I filled the ROM with random data, then as part of `fomu-flash` I look for that data and replace it on the fly.
<xobs>
It's similar to what `icebram` does. I think xilinx has similar options.
<xobs>
If you want to bundle the software in the image itself, it's very handy. Litex seems to prefer having a bios that calibrates DDR, and then stores firmware XIP on SPI following the bitstream image.
<shenki>
so it gives you a magic number to search and replace with the actual firmware image?
<xobs>
Correct. If it was something like all zeroes or ones, or a repeating pattern, you wouldn't know which bits of the input file you're looking at.
<_florent_>
shenki: just change tx/rx mapping to what is used on your pmod
<_florent_>
before trying gdb with it you can try to access some CSRs or Wishbone regions with wishbone-tool
<xobs>
Yeah, depending on your mapping you can examine ROM data by looking at offset 0.
<shenki>
ok, thanks
<xobs>
Oh, I thought triple quotes """ in Python trimmed whitespace, but I guess that's not true by default. (Currently trying to do something with the CSRField documentation)
<xobs>
I suppose that's fine if it gets passed to Markdown, which will reformat it anyway.
rohitksingh has quit [Ping timeout: 245 seconds]
<_florent_>
xobs: i was also thinking about that. Keeping the whitespace allow the code to be clean, but is maybe not convenient for the documentation. If the documentation can handle that that would be nice.
<xobs>
florent: Markdown shouldn't care, so let's keep it like it is.
<mithro>
Textwrap.deindent
<kgugala>
hi all
<kgugala>
xobs: We have released the first version of USB test suite based on your work in valentyusb
<xobs>
It needs more documentation around the modules themselves, and probably could use a reference table up top. And more vertical space.
<xobs>
But the idea is there!
<xobs>
It has real address offsets, field tables, and multiple csr types. I just only had the one timer module in the system.
<guan>
daveshah _florent_: ah thanks, i just tried the second tty with same results, it just gets stuck at "[LXTERM] Starting...". nothing else shows up (even after i hit enter). this is using the prebuilt bitstream. i'll try from a linux box later.
freemint has joined #litex
<guan>
i should dig out the logic analyzer and see what's actually going across the uart pins
forksand has quit [Ping timeout: 276 seconds]
forksand has joined #litex
<daveshah>
xobs: those autogenerated docs are very nice!
<daveshah>
guan: yeah, could be an odd baud rate issue or something
<guan>
daveshah: is soc_linux.py:56 the only place i have to change to make it slower? (+ the command line argument for lxterm)
<daveshah>
I think that's it
<somlo>
mithro: re. PR 260, Rocket has a built-in L1 cache, so arguably it might be worth spending fpga bram on just making that bigger, instead of also having a LiteX l2 in front of the sdram controller
<somlo>
if I'm not mistaken, l2 is the *only* cache for most of the 32-bit CPUs LiteX supports, there is no L1 on any of them (might be wrong about that, appreciate someone kicking me if that's the case :)
<mithro>
somlo: The L2 cache is shared between DMA controllers and the CPU, which can be good / can be bad depending on time
<mithro>
kgugala / xobs: Did you see https://github.com/JohnDMcMaster/usbrply ? Convert a .pcap file (captured USB packets) to Python or C code that replays the packets in the .pcap file
<tpb>
Title: GitHub - JohnDMcMaster/usbrply: Replay USB messages from Wireshark (.cap) files (at github.com)
<mithro>
Done by a person who was on my team a while back but I totally didn't know about it until 2 days ago
<somlo>
ok, so I have to understand how dma will fit into my plan of just connecting the SDRAM data path to the appropriate rocket axi master port
freemint has quit [Remote host closed the connection]
freemint has joined #litex
freemint has quit [Remote host closed the connection]
freemint has joined #litex
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 252 seconds]
CarlFK has joined #litex
rohitksingh has joined #litex
<_florent_>
xobs: sorry just back but i really like the generated documentation
rohitksingh has quit [Ping timeout: 245 seconds]
<somlo>
_florent_: re. litedram commit d93dded, may I suggest printing the actual values of the mismatched width values: https://pastebin.com/UzETkgqT