tpb has quit [Remote host closed the connection]
tpb has joined #litex
shenki has joined #litex
<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?
<CarlFK> it worked when I gave a talk
<tpb> Title: July 2019 Meeting of ChicagoLUG (at
freeemint has joined #litex
freemint has quit [Ping timeout: 245 seconds]
<shenki> guan: I got it to work just now, using linux-on-litex-vexriscv and the prebuild kernel/dtb/rootfs
CarlFK has quit [Remote host closed the connection]
CarlFK has joined #litex
rohitksingh has quit [Ping timeout: 265 seconds]
_whitelogger has joined #litex
<futarisIRCcloud> shenki: Have you tried with a kernel / dtb / rootfs that you built on your system?
CarlFK has quit [Remote host closed the connection]
rohitksingh has joined #litex
<shenki> uroot@buildroot:~# uname -a
<shenki> Linux buildroot 5.0.13 #1 Tue Sep 17 22:24:09 ACST 2019 riscv32 GNU/Linux
<shenki> [ 0.000000] No DTB passed to the kernel
<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
<_florent_> guan: maybe you can give a try on the versa/arty with the prebuilt bistreams/images:
<tpb> Title: GitHub - litex-hub/linux-on-litex-vexriscv-prebuilt: Prebuilt bitstreams / linux images for litex-on-litex-vexriscv repository (at
<_florent_> guan: just to verify everything is correct on the hardware side
<_florent_> guan: when the bitstream is loaded and you open litex_term, you should be able to interact with the bios
<shenki> _florent_: ok. I have the hardware working now, so that looks good for testing
<shenki> _florent_: i rebased the linux patches on 5.3 and it fails to boot. it looks like with the 5.0 kernel it wasn't getting a dtb, but it is with 5.3?
<tpb> Title: linux 5.3 on vexriscv on arty · GitHub (at
<tpb> Title: linux 5.0 on vexriscv on arty · GitHub (at
<_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
<shenki> okay
<_florent_> shenki: i know we had issues with linux 5.1:
<tpb> Title: force buildroot commit rev to 982a61b6adabbcd68a0eb9ad1e348a732915e9e4 by futaris · Pull Request #20 · litex-hub/linux-on-litex-vexriscv · GitHub (at
<shenki> ok. that looks buildroot/userspace related
forksand has quit [Ping timeout: 276 seconds]
<shenki> _florent_: do we have a watchdog or something that can reset the CPU?
forksand has joined #litex
<shenki> being able to type 'reboot' and have it reset the CPU would be handy :)
<_florent_> shenki: there is a CSR to reset the cpu yes, and was also thinking about adding reboot support:
<tpb> Title: Add reboot support · Issue #45 · litex-hub/linux-on-litex-vexriscv · GitHub (at
<_florent_> if you know how to do that in linux, here we just need to write 1 to CSR_CTRL_RESET_ADDR to reboot the CPU
<shenki> Oh, we have that in hardware already?
<shenki> I can write the linux driver for it
<_florent_> yes it's already there :)
<shenki> _florent_: cool. how do we make it show up in the device tree?
<_florent_> i can add it if you tell me what structure need to be added to the device tree for that
<shenki> that's the wrong kind of reset
<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, 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?
<_florent_> shenki: i've not used it (yet), but i know others are using it, xobs created a tool for that:
<tpb> Title: GitHub - xobs/wishbone-utils: Utilities for working with a Wishbone bridge (at
<shenki> ah. mithro was telling me about this the other day
<shenki> do I need to add something to the hardware design?
<_florent_> but to use it, you will need to use linux+debug variant instead of linux:
<tpb> Title: linux-on-litex-vexriscv/ at master · litex-hub/linux-on-litex-vexriscv · GitHub (at
<_florent_> yes ^ :)
<shenki> :D
<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" if you're debugging it from a different machine.
<shenki> xobs: okay
<xobs> wishbone-tool binaries are at -- though I've never had the occasion to test the s390x versions.
<tpb> Title: Release v0.3.2: travis: disable tests on ppc64le · xobs/wishbone-utils · GitHub (at
<shenki> that is amusing. i wonder if i could find a machine on the work network to test them with
<shenki> _florent_: do you have a snippet for to use a pmod?
<xobs> shenki: I'm not sure about _florent_, but I'd imagine pmod is a Connector, which i haven't found any good documentation on.
<xobs> I did, however, manage to get it working here:
<tpb> Title: foboot/ at foboot-2 · im-tomu/foboot · GitHub (at
<tpb> Title: foboot/ at foboot-2 · im-tomu/foboot · GitHub (at
<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: here is how to add the a serial bridge on pmod:
<_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
<kgugala> xobs: you can take a look on this here
<tpb> Title: GitHub - antmicro/usb-test-suite-build (at
<xobs> kgugala: Oh wow. Cool!
<kgugala> xobs: please take a look and comment/open issues
<kgugala> xobs: right now we want to make this more generic so more IPs can be tested + we want to add enumeration tests
<kgugala> xobs: like full enumeration process in different OSes
<xobs> That's huge.
<xobs> I always tell people to test with Windows, because it's always the pickiest. But if that can be codified that's even better.
<kgugala> It will be some work, but I think useful
<futarisIRCcloud> kgugala: Looks good.
CarlFK has quit [Remote host closed the connection]
_whitelogger has joined #litex
<_florent_> kgugala: nice
<john_k[m]> xobs: understood re: python in tool chain. I raised the issue since it was there in 1.3 but missing in later builds
<john_k[m]> Will re-test a bit today
<xobs> Here's a first draft of what I have in mind for generating reference manuals:
<tpb> Title: TIMER0_LOAD3 doctest documentation (at
<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 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 ? 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
<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:
<tpb> Title: [Diff] diff --git a/litedram/frontend/ b/litedram/frontend/ inde - (at
<somlo> and thanks for the explanation re. l2_cache as an alternative "UpConverter" :)
CarlFK has quit [Quit: Leaving.]
rohitksingh has joined #litex
Dolu has quit [Ping timeout: 258 seconds]
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 246 seconds]
Dolu has joined #litex