| *** tpb has joined #litex | 00:00 | |
| *** lf has quit IRC | 00:40 | |
| *** lf has joined #litex | 00:40 | |
| *** esden has quit IRC | 01:51 | |
| *** esden has joined #litex | 01:53 | |
| *** Degi_ has joined #litex | 03:36 | |
| *** proteusguy has quit IRC | 03:38 | |
| *** Degi has quit IRC | 03:38 | |
| *** Degi_ is now known as Degi | 03:38 | |
| *** proteusguy has joined #litex | 03:51 | |
| *** Bertl is now known as Bertl_zZ | 06:22 | |
| *** shorne has quit IRC | 09:04 | |
| *** shorne has joined #litex | 09:15 | |
| geertu | Zguig: thx, but "./litex_setup.py update" doesn't make a difference (did it before, too) | 09:52 |
|---|---|---|
| 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. | 10:10 |
| geertu | Melkhior: thx, ./make.py --board=orangecrab --cpu-count=1 --build | 10:11 |
| *** kgugala_ has joined #litex | 10:16 | |
| *** kgugala has quit IRC | 10:19 | |
| geertu | Melkhior: trying to execute your bit of python, sbt was not installed. | 10:23 |
| geertu | After installing sbt, the linux-on-vexriscv build step generates the missing file automatically. | 10:25 |
| *** kgugala has joined #litex | 10:30 | |
| geertu | Warning: Max frequency for clock '': 57.68 MHz (FAIL at 64.00 MHz) | 10:31 |
| geertu | Still, it boots, incl. Linux. thx! | 10:31 |
| *** kgugala_ has quit IRC | 10:32 | |
| geertu | clock '$glbnet$sys_clk' | 10:33 |
| *** kgugala_ has joined #litex | 10:34 | |
| *** kgugala has quit IRC | 10:34 | |
| *** Melkhior has joined #litex | 10:59 | |
| *** ambro718 has joined #litex | 11:01 | |
| *** kgugala has joined #litex | 11:04 | |
| *** kgugala_ has quit IRC | 11:07 | |
| *** kgugala has quit IRC | 11:31 | |
| *** kgugala has joined #litex | 11:32 | |
| *** Melkhior has quit IRC | 11:55 | |
| *** Melkhior has joined #litex | 11:55 | |
| geertu | Melkhior: thx, issue was that sbt was not installed. | 13:02 |
| *** x4o has joined #litex | 13:12 | |
| x4o | good day. how do i generate verilog for litex with etherbone frontend? | 13:12 |
| x4o | *liteeth | 13:13 |
| Melkhior | geertu good to know :-) | 13:20 |
| 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 | 13:29 |
| 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) | 13:29 |
| Melkhior | I've also rebuilt rootfs.cpio in latest buildroot for both - but the associated kernel image is *big*: | 13:29 |
| Melkhior | -rw-r--r--. 1 dolbeau2 dolbeau 25735552 Jan 31 08:18 /home/dolbeau2/LITEX/buildroot-rv32/output/images/Image | 13:29 |
| Melkhior | -rw-r--r--. 1 dolbeau2 dolbeau 13324288 Jan 30 10:19 /home/dolbeau2/LITEX/buildroot-rv64/output/images/Image > | 13:29 |
| 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) | 13:29 |
| Melkhior | And the rootfs.cpio won't work with the older Image ('FATAL: kernel too old' ...) | 13:29 |
| geertu | Melkhior: To fix the large kernel, you need https://github.com/geertu/linux/commit/d7894d2d078e5e255fa2e0e8bd3739079a854b39 and https://github.com/geertu/linux/commit/44d9a61725d2eb26228ba8e14bcdd16dbbb0e777 | 13:31 |
| Melkhior | OK thanks | 13:31 |
| geertu | (from my litex-v5.11 branch) | 13:31 |
| Melkhior | I was on the litex-rebase branch from https://github.com/litex-hub/linux.git | 13:32 |
| Melkhior | i'll try with yours | 13:32 |
| geertu | Melkhior: That one is for rocket, linux-on-vexriscv has a few extra patches | 13:33 |
| geertu | https://github.com/litex-hub/linux-on-litex-vexriscv/tree/master/buildroot/patches/linux | 13:33 |
| x4o | kindly requesting help with generating verilog for etherbone+liteeth | 13:33 |
| Melkhior | x4o From a previous discussion (https://freenode.irclog.whitequark.org/litex/2021-01-16), there's a generator for LiteEth | 13:36 |
| Melkhior | https://github.com/enjoy-digital/liteeth/blob/master/liteeth/gen.py | 13:36 |
| tpb | Title: #litex on 2021-01-16 — irc logs at whitequark.org (at freenode.irclog.whitequark.org) | 13:36 |
| Melkhior | @x4o you can generate the verilog from one of the examples like this: | 13:38 |
| Melkhior | python3 gen.py ../examples/wishbone_mii.yml | 13:38 |
| Melkhior | Beyond that I don't know ... | 13:39 |
| x4o | that generates just the liteeth core. found it. i want the etherbone frontend with liteeth ... backend? | 13:39 |
| x4o | i see this: | 13:40 |
| x4o | https://github.com/enjoy-digital/liteeth/blob/617400fe9e5b902e6bfd39a7c32ef5b255bc10c0/liteeth/frontend/etherbone.py | 13:40 |
| x4o | it's not used in gen.py. looks lite there' a test for etherbone, but no generation script | 13:42 |
| Melkhior | geertu Using your branch solves my problem, 7 MiB kernel that boots fine my dual-core VexRiscV SoC :-) | 13:44 |
| Melkhior | Changed the following: | 13:44 |
| Melkhior | #BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/litex-hub/linux.git" | 13:44 |
| Melkhior | #BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="litex-rebase" | 13:44 |
| Melkhior | #BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_10=y | 13:44 |
| Melkhior | BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/geertu/linux.git" | 13:44 |
| Melkhior | BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="litex-v5.11" | 13:44 |
| Melkhior | BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_11=y | 13:44 |
| geertu | Melkhior: happy to hear that! | 13:45 |
| Melkhior | @geertu Another good news - at last, the micro-sd card is accessible in Linux !!!:-) :-) :-) | 13:47 |
| Melkhior | root@buildroot:~# mount /dev/mmcblk0p1 /mnt ; ls -l /mnt/Image* | 13:47 |
| Melkhior | -rwxr-xr-x 1 root root 7054792 Jan 31 2021 /mnt/Image | 13:47 |
| Melkhior | -rwxr-xr-x 1 root root 6145908 Jan 30 2021 /mnt/Image_old | 13:47 |
| Melkhior | Thanks everyone:-) :-) | 13:48 |
| Melkhior | Maybe my hardware isn't broken after all! | 13:48 |
| 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 :-) | 13:53 |
| *** carlomaragno has quit IRC | 13:56 | |
| *** x4o has quit IRC | 13:57 | |
| *** miek has quit IRC | 13:57 | |
| *** carlomaragno has joined #litex | 13:57 | |
| *** miek has joined #litex | 13:58 | |
| 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 | 14:09 |
| *** Melkhior has quit IRC | 14:09 | |
| *** Melkhior has joined #litex | 14:12 | |
| Melkhior | oups, actually CONFIG_STRICT_KERNEL_RWX=y in my RV64 build! so the patch won't help I guess | 14:16 |
| Melkhior | with =n, the RV64 image drops to < 6 MiB :-) | 14:18 |
| *** Bertl_zZ is now known as Bertl | 15:01 | |
| ius | is anyone else seeing memory corruption issues on recent(?) linux/vexriscv-smp builds? | 15:40 |
| 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) | 15:46 |
| ius | board is acorn, sample kernel output: https://p.6core.net/p/uVYThfx2kr1AKdBpYHC5YiUN | 15:47 |
| ius | never seen a kernel OOPS, it's always a userspace process (busybox, initscript, getty) | 15:48 |
| geertu | ius: What's L1_CACHE_SHIFT in arch/riscv/include/asm/cache.h? | 17:13 |
| somlo | anyone know what primitive I'm looking for if I wanted to instantiate an ecp5 jtag module, similar to what's being done for xilinx here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/jtag.py#L46 ? | 17:54 |
| 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... | 17:57 |
| 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) | 18:11 |
| ius | also, non-smp (ie. --cpu-count 1) seems fine with the same kernel.. | 18:12 |
| daveshah | somlo: yep it's JTAGG, there are a few examples floating around | 18:19 |
| daveshah | e.g. https://github.com/SpinalHDL/SpinalHDL/blob/b6ae0a74d2d5838d16fadb6978da77d5e9709ec1/lib/src/main/scala/spinal/lib/com/jtag/lattice/ecp5/JtagTap.scala | 18:20 |
| 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" :) | 18:20 |
| somlo | daveshah: thanks, looking at the scala thing you linked right now, maybe they shed some light on what the pins actually do... | 18:21 |
| daveshah | there's another verilog example here https://github.com/emard/ulx3s-misc/blob/20d81f0c8cb51381115d0633f328dfcb69651d7a/examples/jtag_slave/hdl/top/top_jtagg_slave.v | 18:22 |
| *** Melkhior has quit IRC | 18:43 | |
| 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) | 18:56 |
| somlo | 3. examples drive both JTDO1 and JTDO2 together | 18:56 |
| daveshah | The TMS input is intended to be a top level pin only, it can't be connected to fabric | 18:57 |
| daveshah | I think the different TDOs are the two different supported instructions | 18:57 |
| somlo | and 4. I'm working on understanding how JCE1 and JCE2 are related to bscane's CAPTURE pin :) | 18:58 |
| daveshah | I'm not sure about that tbh | 19:02 |
| 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 | 19:03 |
| somlo | one more thing -- the JTAGG has a clock input, BSCANE2 does not. I should probably drive that clock input with *something*... | 19:14 |
| 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 | 19:33 |
| somlo | oh, ok then, that's easy :) | 19:40 |
| *** Bertl is now known as Bertl_oO | 19:49 | |
| 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. | 20:06 |
| *** hansfbaier has joined #litex | 20:35 | |
| *** hansfbaier1 has joined #litex | 20:42 | |
| *** hansfbaier1 has quit IRC | 20:44 | |
| *** hansfbaier1 has joined #litex | 20:46 | |
| *** hansfbaier has quit IRC | 20:46 | |
| *** hansfbaier1 has quit IRC | 20:56 | |
| *** hansfbaier has joined #litex | 20:57 | |
| *** hansfbaier has joined #litex | 21:00 | |
| *** hansfbaier has quit IRC | 21:05 | |
| *** hansfbaier has joined #litex | 21:05 | |
| 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... | 21:18 |
| *** hansfbaier has quit IRC | 21:24 | |
| *** hansfbaier has joined #litex | 21:26 | |
| *** hansfbaier has quit IRC | 21:36 | |
| *** hansfbaier has joined #litex | 21:36 | |
| *** hansfbaier has quit IRC | 21:37 | |
| *** hansfbaier has joined #litex | 21:38 | |
| *** hansfbaier has quit IRC | 21:45 | |
| *** hansfbaier has joined #litex | 21:46 | |
| *** hansfbaier1 has joined #litex | 22:00 | |
| *** hansfbaier has quit IRC | 22:02 | |
| *** hansfbaier1 has quit IRC | 22:02 | |
| *** hansfbaier has joined #litex | 22:03 | |
| *** hansfbaier has quit IRC | 22:09 | |
| *** hansfbaier has joined #litex | 22:10 | |
| *** hansfbaier has joined #litex | 22:12 | |
| *** hansfbaier has quit IRC | 22:13 | |
| *** hansfbaier has joined #litex | 22:15 | |
| *** hansfbaier has quit IRC | 22:18 | |
| *** hansfbaier has joined #litex | 22:20 | |
| *** hansfbaier has joined #litex | 22:22 | |
| *** hansfbaier has joined #litex | 22:23 | |
| 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) | 23:10 |
| somlo | on the trellisboard, I correctly get 1073741824 (0x40000000), and on the nexys4ddr and versa5g boards I also correctly get 134217728 (0x08000000, or 128M) | 23:11 |
| somlo | did I just get lucky, or is there a bug in the platform and/or target file for ecpix5? | 23:12 |
| daveshah | I think the ecpix5 might actually be 512MB | 23:17 |
| *** hansfbaier1 has joined #litex | 23:18 | |
| *** hansfbaier has quit IRC | 23:20 | |
| *** hansfbaier1 has quit IRC | 23:20 | |
| zyp | «4Gb (256MB) of DDR3L RAM» must be a typo, considering 4G/8 = 512M | 23:21 |
| daveshah | Yep | 23:21 |
| zyp | according to the schematics, the memory is a 256Mx16 part | 23:22 |
| zyp | so 512MB it is :) | 23:23 |
| somlo | whoo, nice! :) | 23:32 |
| 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... | 23:33 |
| 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) | 23:45 |
| somlo | wonder if it's broken, or if I'm clueless... | 23:45 |
| *** hansfbaier has joined #litex | 23:46 | |
| 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... | 23:46 |
| somlo | guess that was a short experiment :( | 23:47 |
| 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 | 23:52 |
| somlo | and the connector broke clean off at the slightest attempt to unplug the microusb cable, awesome, now I have a broken pcb | 23:52 |
| somlo | ok, that's the end of my adventures with ecpix5, and $250 down the drain. fun weekend. | 23:53 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!