<geertu>
Zguig: thx, but "./litex_setup.py update" doesn't make a difference (did it before, too)
<geertu>
I recloned (--recursive) pythondata-cpu-vexriscv-smp, but the repo copy is the same, and thus it still fails. No local changes, except for one unrelatd litex change.
<geertu>
Melkhior: trying to execute your bit of python, sbt was not installed.
<geertu>
After installing sbt, the linux-on-vexriscv build step generates the missing file automatically.
kgugala has joined #litex
<geertu>
Warning: Max frequency for clock '': 57.68 MHz (FAIL at 64.00 MHz)
<geertu>
Still, it boots, incl. Linux. thx!
kgugala_ has quit [Ping timeout: 240 seconds]
<geertu>
clock '$glbnet$sys_clk'
kgugala_ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
Melkhior has joined #litex
ambro718 has joined #litex
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 264 seconds]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
Melkhior has quit [Quit: Connection closed]
Melkhior has joined #litex
<geertu>
Melkhior: thx, issue was that sbt was not installed.
x4o has joined #litex
<x4o>
good day. how do i generate verilog for litex with etherbone frontend?
<x4o>
*liteeth
<Melkhior>
geertu good to know :-)
<Melkhior>
Current status for me is that I can get both Rocket (single core) and VexRiscV (single, dual core) running on my board with the latest gits
<Melkhior>
The micro-sd card is reliable in SD-mode on VexRiscV ; it doesn't load from the BIOS w/ Rocket (SD-mode or SPI-mode) or w/ VexRiscV (SPI-mode only)
<Melkhior>
I've also rebuilt rootfs.cpio in latest buildroot for both - but the associated kernel image is *big*:
<Melkhior>
-rw-r--r--. 1 dolbeau2 dolbeau 25735552 Jan 31 08:18 /home/dolbeau2/LITEX/buildroot-rv32/output/images/Image
<Melkhior>
Weirdly, the rv32 is even larger than the rv64 one; and of course the rv32 Image doesn't work as it won't fit in 0x40000000-0x40ef0000 (tge DTB is at 0x40ef0000)
<Melkhior>
And the rootfs.cpio won't work with the older Image ('FATAL: kernel too old' ...)
<Melkhior>
@geertu Another good news - at last, the micro-sd card is accessible in Linux !!!:-) :-) :-)
<Melkhior>
root@buildroot:~# mount /dev/mmcblk0p1 /mnt ; ls -l /mnt/Image*
<Melkhior>
-rwxr-xr-x 1 root root 7054792 Jan 31 2021 /mnt/Image
<Melkhior>
-rwxr-xr-x 1 root root 6145908 Jan 30 2021 /mnt/Image_old
<Melkhior>
Thanks everyone:-) :-)
<Melkhior>
Maybe my hardware isn't broken after all!
<Melkhior>
... maybe I spoke too soon; reading seems 100% fine (I can md5sum all the large files like Image and rootfs.cpio to the proper value, anyway), but doing a cp seems to have locked up the system... anyway reading is a start :-)
carlomaragno has quit [Ping timeout: 272 seconds]
x4o has quit [Quit: Connection closed]
miek has quit [Ping timeout: 272 seconds]
carlomaragno has joined #litex
miek has joined #litex
<Melkhior>
@geertu The patches to limit the kernel size you mentioned, are they only for RV32 ? Just tried rebuilding buildroot for RV64 from your branch, Image is the same size as before
Melkhior has quit [Quit: Ping timeout (120 seconds)]
Melkhior has joined #litex
<Melkhior>
oups, actually CONFIG_STRICT_KERNEL_RWX=y in my RV64 build! so the patch won't help I guess
<Melkhior>
with =n, the RV64 image drops to < 6 MiB :-)
Bertl_zZ is now known as Bertl
<ius>
is anyone else seeing memory corruption issues on recent(?) linux/vexriscv-smp builds?
<ius>
i'm pretty sure i always have been seeing occasional segfaults on smp, but it feels like it's become even worse after updating my litex checkout (~3 weeks worth of commits)
<somlo>
there's a "JTAGG" blackbox module in /usr/share/yosys/ecp5/cells_bb.v that might be worth investigating, now that I decided to grep for jtag in the ecp5 library folder...
<ius>
geertu: 5 - i just picked your patch to make sure that wasn't the cause (in fact, now it's litex-rebase + the 4 patches provided separately for buildroot)
<ius>
also, non-smp (ie. --cpu-count 1) seems fine with the same kernel..
<daveshah>
somlo: yep it's JTAGG, there are a few examples floating around
<somlo>
oh great, the big lattice manual lists the signals, and literally punts with "most users would typically not use this component directly" :) Trying to figure out the equivalent signals to bscane2, and got tackled at "o_CAPTURE" :)
<somlo>
daveshah: thanks, looking at the scala thing you linked right now, maybe they shed some light on what the pins actually do...
Melkhior has quit [Quit: Ping timeout (120 seconds)]
<somlo>
daveshah: so far, comparing jtagg to bscane2, it appears that 1. reset output is active-low (bscane2 reset appears to be active-high); 2. there's no jtagg equivalent to bscane2's TMS *output* (there's a tms input, but none of the examples actually show it being used)
<somlo>
3. examples drive both JTDO1 and JTDO2 together
<daveshah>
The TMS input is intended to be a top level pin only, it can't be connected to fabric
<daveshah>
I think the different TDOs are the two different supported instructions
<somlo>
and 4. I'm working on understanding how JCE1 and JCE2 are related to bscane's CAPTURE pin :)
<daveshah>
I'm not sure about that tbh
<somlo>
I'm going to try to or the outputs and use that as the equivalent of CAPTURE, but I'm just throwing stuff at the wall to see if it'll stick :) I'll dig deeper if that (likely) ends up not working :D
<somlo>
one more thing -- the JTAGG has a clock input, BSCANE2 does not. I should probably drive that clock input with *something*...
<daveshah>
that's a notional top level pin, afaik, that can't be driven from fabric and is basically for simulation only and can just be left
<somlo>
oh, ok then, that's easy :)
Bertl is now known as Bertl_oO
<geertu>
ius: OK, haven't run SMP vexrisc yet, as the orangecrab FPGA is too small for 2 cores. SMP works on the 64-bit K210, though.
hansfbaier has joined #litex
hansfbaier1 has joined #litex
hansfbaier1 has quit [Read error: Connection reset by peer]
hansfbaier1 has joined #litex
hansfbaier has quit [Ping timeout: 264 seconds]
hansfbaier1 has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
<somlo>
daveshah: actually, the JTAGE and JTAGF blocks have slightly more informative documentation, which may plausibly apply to JTAGG as well (re. JCE1 and JCE2). So if I'm driving both JTDO inputs from the same signal, it may end up being appropriate to OR the two JCE outputs...
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier1 has joined #litex
hansfbaier has quit [Ping timeout: 240 seconds]
hansfbaier1 has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
<somlo>
screwing around with my new ecpix5, trying to build a rocket/litex for it. Noticed that in csr.csv I get "memory_region,main_ram,0x80000000,536870912,cached", which appears to suggest 512MB (536870912 == 0x20000000), rather than the expected 256MB (0x10000000)
<somlo>
on the trellisboard, I correctly get 1073741824 (0x40000000), and on the nexys4ddr and versa5g boards I also correctly get 134217728 (0x08000000, or 128M)
<somlo>
did I just get lucky, or is there a bug in the platform and/or target file for ecpix5?
<daveshah>
I think the ecpix5 might actually be 512MB
hansfbaier1 has joined #litex
hansfbaier has quit [Ping timeout: 264 seconds]
hansfbaier1 has quit [Read error: Connection reset by peer]
<zyp>
«4Gb (256MB) of DDR3L RAM» must be a typo, considering 4G/8 = 512M
<daveshah>
Yep
<zyp>
according to the schematics, the memory is a 256Mx16 part
<zyp>
so 512MB it is :)
<somlo>
whoo, nice! :)
<somlo>
now, I got it to power on by moving the jumper to "usb-c", but I get nothing in terms of usb devices detected (in dmesg) after I plug it in...
<somlo>
hmmm. board powers on but no usb anything (I get a bunch of FTDI stuff when I plug in the trellisboard, crickets when I plug in the ecpix5)
<somlo>
wonder if it's broken, or if I'm clueless...
hansfbaier has joined #litex
<somlo>
external power is 5V, so can't reuse the adapter from my versa, which is 12V, on the off chance that it gets "insufficient" power over the usb cable...
<somlo>
guess that was a short experiment :(
<somlo>
so there's a microusb "debug" port, I could power the card using *that* one (same as usb-c), still nothing in terms of ftdi jtag or serial devices
<somlo>
and the connector broke clean off at the slightest attempt to unplug the microusb cable, awesome, now I have a broken pcb
<somlo>
ok, that's the end of my adventures with ecpix5, and $250 down the drain. fun weekend.