<somlo_>
wish the nexys4ddr had two ethernet ports... too bad --with-etherbone and --with-ethernet are mutually exclusive :)
<daveshah>
there might be an ethernet pmod around?
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 - https://znc.in]
feldim2425 has joined #litex
<daveshah>
(*not* the NIC100 thats some silly SPI ethernet thing, but I'm sure I've seen a proper RMII or similar one before)
<somlo_>
thanks! (honestly, in retrospect I feel like I should have been able to come up with that idea *eventually*) -- but I'm not in a very sharp frame of mind right now :D
<somlo_>
I'll order a pmod and do some hacking, should make for a much less painful litescope debugging experience...
<daveshah>
looks like there are some LAN8720 modules out there that should work with liteeth
<daveshah>
don't know if anyone has actually tested one yet though
<_florent_>
somlo_: but using an additional PMOD is also a nice way to decouple things/issues.
<somlo_>
_florent_: I'll check out the hybrid mode (one already has to modify the target files to instrument them for litescope, so a bit more hackery while at it should be ok)
<somlo_>
it's just that I have a lot of moving parts (bitstream changes x kernel sdcard driver changes) and not having netboot capabilities leads to lots of plugging and unplugging of the sdcard to copy updated boot.bin images to it... Wanted to streamline my workflow before I really dive in and test my new-found skills with litescope :D
<acathla>
but the port is already opened by litex_server for the litexscope thing
<acathla>
I'll try again soon...
<_florent_>
litex_server accepts multiple clients
<acathla>
litex_term can use litex_server?
<_florent_>
that's very useful to avoid mixing things in scripts :)
<_florent_>
it's recent but yes
<somlo_>
_florent_: can I keep using "screen /dev/ttyUSBX" or do I have to use litex_term via litex_server to access the console ?
<somlo_>
i.e., will there be an additional /dev/ttyUSBXYZ device for litescope debugging, or (probably this, since you already mentioned multiplexing) it's all multiplexed over the same serial link (console *and* litescope transfers) ?
<_florent_>
somlo_: in you case I was suggesting adding a second UART dedicated to the bridge (through a PMOD)
<somlo_>
ah
<somlo_>
so I'll need extra pmod hardware either way
<_florent_>
just that it's probably easier than adding a second ethernet
<somlo_>
have a (link to) a component handy? The ethernet pmod thing I ordered shows delivery by mid-February, so maybe I can find a pmod-uart thing that ships faster, and use whichever one I get first :)
<somlo_>
acathla: I remember now seeing that and ignoring it, I was on a mission to set it up over ethernet :)
<somlo_>
but yeah, digikey stuff is likely to win the shipping race, so I'll likely end up using the uart method for "real" debugging :)
<_florent_>
somlo_: ah another option: generate your SoC with uart_name=jtag_uart, then use litex_term jtag_uart and use the default serial for uartbone, does not require an additional PMOD :)
<somlo_>
so that would be multiplexing the console and litescope data over the same serial link?
<Zguig>
Hi all, trying to understand and use litex, here are some questions I have:
<Zguig>
1. When I start the sim.py of linux-on-litex-vexriscv, with prebuild stuff, my Linux boot "hangs" at "[ 0.014830] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns". I waited some quite long time for me. Shoudl I just be patient and wait for hours?
<Zguig>
2. When I try to generate the bitstream for ecpix5 board (./make.py --board=ecpix5 --cpu-count=1 --build), I always got a timing issue with 1 path: Warning: Max frequency for clock '$glbnet$sdrio_clk': 69.76 MHz (FAIL at 75.01 MHz). Max I could get is 71MHz. Is it a known issue? Should I just ignore the warning and program the board?
<Zguig>
3. Do you have any tutorial for implementing a custom core to advice? I want to rewrite and finalize this project I worked some time ago and was passing more time to fight with or1k stuff than working on the added value I have. Basically, I want to do a wishbone controlled generic RX/TX. There are some functions written in VHDL that I want to port to litex (and some new to be done/finished).The closest example I could find is the liteth core.
<somlo_>
oh wait, do I already have two serial devices in play over the same serial cable (the jtag used to program the board, and the "regular" serial console uart)? And here I'd be re-using the jtag for actual console i/o, and the "normal" serial uart for litescope purposes?
<somlo_>
wonder what changes I'd have to make to the DT to get BBL and linux to play along (probably reflected in the csr.csv file)
<acathla>
somlo_, what's your board?
<somlo_>
nexys4ddr
<somlo_>
I have /dev/ttyUSB0 (presumably the jtag), and I use console over /dev/ttyUSB1
<acathla>
On a versa_ecp5 there are ttyUSB0 and USB1, USB0 disappear after FPGA being configure, and USB1 as console too
<somlo_>
guess what _florent_ suggested is to *reuse* /dev/ttyUSB0 (jtag) for the console, and dedicate the "regular" uart to litescope/uart-bone
<acathla>
cool
<somlo_>
acathla: sadly my stuff won't fit on a versa (rocket chip with mmu to run "real" linux)
<acathla>
because I failed at using ethernet
<somlo_>
I can barely fit a non-MMU bare-metal-only rocket on the versa
<acathla>
Wow. I try to use a versa_ecp5 because my design + debug is too big for an iCE40up5K :)
<somlo_>
ethernet works great (for litescope) on the nexys, but that in turn means I can't netboot the kernel, which means I have to screw around moving the microSD card back and forth between the board and my laptop to update the kernel+bbl I'm trying to boot and debug, in conjunction with the bitstream/gateware I'm *also* trying to debug at the same time :)
<somlo_>
It's significantly bigger than the 45k ecp5 (or even the 85k ecp5). Rough guesstimate is that I can fit about three times as much "gateware" on the artix7 provisioned on the nexys (with vivado) as I can fit stuff on the 85k ecp5 (with yosys/trellis/nextpnr)
<somlo_>
and I know that because the fpu-less rocket soc occupies about 80% of the ecp5-85k, and the fpu is about twice as big as everything else, and I can fit the fpu-in-gateware based rocket on the nexys
<somlo_>
I'm really not qualified to be saying all this stuff though, I never really sat down to do a systematic study of how much logic I can fit on each type of chip :)
<somlo_>
I think I have the A7-100T version (of the older nexys4ddr board), i.e. the one with the larger capacity
<somlo_>
or maybe that was the only kind of nexys4ddr, and now the a7 has a "cheap" option that's new, I don't really know for sure...
<acathla>
Oh, ok, A7-100 means it's the equivalent of 100 old style cells
<acathla>
_florent_, that's nice, "litex_term crossover" uses directly the running litex_server. It would be nice if it was visible with --help option.
<acathla>
And it's faster than wishbone-tool -s terminal
<_florent_>
Zguig: Hi, it seems the simulation is indeed not going to the Linux prompt:
<_florent_>
I'll have a look, it could be related to the clock frequencies passed in the .dts
<_florent_>
for the ecpix5, I don't remember the timings results, but you can try to lower the clock or disable SDCard/Ethernet if you want more margin
<_florent_>
we don't have yet a tutorial to integrate a custom core, but Betrusted is a good example project for that
<_florent_>
somlo_: yes I was suggesting reusing /dev/ttyUSB0 (JTAG) as a JTAG UART
<cr1901_modern>
_florent_: Will you be around in 5 minutes? I had an error w/ linux-on-litex that I don't understan
<cr1901_modern>
but I need to rerun it to get the error
<_florent_>
somlo_: the only change required to your SoC is passing --uart-name=jtag_uart and then use litex_term jtag_uart (and have OpenOCD installed)
<_florent_>
cr1901_modern: Hi, yes I'll be around
<cr1901_modern>
Awesome I'm building now... as soon as device-tree-compiler installs
<cr1901_modern>
(is this a new dep? Don't seem to remember that last I built)
<cr1901_modern>
HeAP Placer Time: 32.10s Wow, that's the longest I've ever seen nextpnr take. It must be working
<cr1901_modern>
(If daveshah sees this: I'm not being too serious. Still pretty fast.)
<cr1901_modern>
_florent_: Okay, I can't duplicate the error this time around. And I found the original error: http://ix.io/2KBL
<cr1901_modern>
This was with "python3 make.py --board orangecrab --build" on Dec 31st. Seems in the past 3 weeks whatever bug I saw is gone.
<cr1901_modern>
Now gonna upload the firmware/see what happens
<somlo_>
_florent_: haven't yet used litex_term -- is it a wrapper around openocd, and if so, am I supposed to program the board through it as well as access the console, or is that a separate (direct) openocd command as I've been using it so far (with console on ttyUSB1)?
<cr1901_modern>
somlo_: litex_term is a terminal app like minicom
<cr1901_modern>
the reason you use it to program boards is that litex BIOS looks for a special ASCII string that tells the BIOS to send a binary over the serial port
<cr1901_modern>
and litex_term knows how to send that special ASCII string to commence programming
<cr1901_modern>
(it's a string that a user is very unlikely to type themselves)
<somlo_>
cr1901_modern: ok, so I would *not* use it to program the board's *bitstream*, only software as an *alternative* to sdcard/tftp boot, etc.
<cr1901_modern>
Yes
<cr1901_modern>
Every board that litex supports should support that boot mode (send over serial)
<somlo_>
what confused me was _florent_'s suggestion to use it with the `port` argument set to "jtag" and the "need to have openocd installed"
<cr1901_modern>
I'm not familiar w/ using openocd w/ jtag, so I'm not sure what _florent_ means there
<somlo_>
I'm supposed to use console-over-jtag to free up my "regular" uart for litescope debugging
<cr1901_modern>
err sorry, not familiar w/ litex and openocd*
<cr1901_modern>
Oh, it might be possible to send UART traffic over the JTAG port
<Zguig>
Hi _florent_, thanks for your feedbacks. Regarding to my last question (an example advice), the TX part was semi-functional and all the RX has to be done. I have to admit that VHDL writing makes me going a bit crazy/with headaches... So I search more an example to write from scratch a litex core (and not encapsulate the existing one like the betrusted project did).
<cr1901_modern>
and litex_term knows how to connect to openocd as well
<cr1901_modern>
to interpret UART traffic sent over the JTAG port
<cr1901_modern>
but even in that case, you're _not_ using litex_term to program the bitstream
<somlo_>
and my obvious attempt to connect `screen /dev/ttyUSB0` (i.e., the jtag device) instead of the "regular" ttyusb1 (the "usual" serial port) didn't work, so I'm assuming there's some magic serial-over-jtag encapsulation that a regular minicom/screen/whatever terminal program wouldn't be capable of
<cr1901_modern>
Correct- that "magic" is what litex_term will be doing I think. Nothing prevents someone from adding it to other terminal programs
<cr1901_modern>
I started adding serial boot to another terminal, but am holding off on that project for now
<somlo_>
right, so I am openocd-ing the bitstream as before; then, I'm using litex-term to drive openocd to tunnel serial traffic to the "jtag uart" :)
<cr1901_modern>
yes
<somlo_>
cr1901_modern: ok, that makes sense -- just trying to mentally place all the moving parts into their rightful little boxes :)
<somlo_>
thanks!
<cr1901_modern>
Yw
<cr1901_modern>
Now if you're running into issues w/ using UART-over-JTAG, well I've never used that, so I don't think I can help :P.
<somlo_>
then I'll wait for the digikey shipment of my external 2nd (pmod) uart :D
Zguig has quit [Remote host closed the connection]
somlo_ has quit [Remote host closed the connection]
_florent_ has quit [Ping timeout: 260 seconds]
_florent_ has joined #litex
somlo has joined #litex
<cr1901_modern>
_florent_: This doesn't seem good: http://ix.io/2MCo
<cr1901_modern>
What might be causing this (orangecrab, default settings)
<somlo>
_florent_: after programming a "--uart-name jtag_uart" bitstream to the nexys4ddr board, it appears to wait until I connect with "litex_term jtag_uart" before it starts the self-test and boot sequence
<somlo>
is that expected?
<somlo>
otherwise looks like it's working OK, now on to bridging litescope over the "regular" uart
<acathla>
somlo, I have the same behaviour with a normal uart
<cr1901_modern>
I would say that's expected- the firmware stops while the transmit buffer is full
<cr1901_modern>
and the banner will certainly take up the buffer
<somlo>
I *think* I remember it progressing independently with the normal uart, but then again, I usually had that open in screen or minicom
<somlo>
I seem to remember that, if I did NOT have minicom open right during/after the openocd bitstream push, I'd later find it fully booted, at the linux busybox prompt
<somlo>
now with the jtag uart, if I connect to it 20 minutes after pushing the bitstream with openod, it starts booting right then and there, clearly having waited for me
<somlo>
not a problem, just different from what (I think) I saw before
<somlo>
but so far so good, I now have an open UART to try to use for litescope.
<cr1901_modern>
_florent_: For some reason when I reset my board when UART_POLLING is not defined _and_ I'm using a USB uart, the UART stops receiving characters properly (transmitting unaffected). Is this a known bug?
<cr1901_modern>
somlo: Maybe you can teach me something... is JTAG UART a separate second UART you attach to a litex design?
<cr1901_modern>
IIRC, add_uart() in soc.py is sugar for manually adding a UART that the BIOS expects to exist. If you add a second UART for debugging the first UART, as is my intent, I'm on my own lmao
Zambyte has joined #litex
<zyp>
somlo, I figure the normal uart doesn't have flow control, so it'll just transmit regardless of whether anybody is listening or not