| *** tpb has joined #litex | 00:00 | |
| *** lf_ has joined #litex | 00:31 | |
| *** lf has quit IRC | 00:31 | |
| *** ambro718 has quit IRC | 01:38 | |
| *** rj_ has joined #litex | 01:54 | |
| *** rj_ has quit IRC | 02:14 | |
| somlo | is there a good "man page" equivalent for migen's "Record" ? Somehow it isn't mentioned in the migen documentation, and reading through genlib/record.py isn't really straightforward... | 02:25 |
|---|---|---|
| *** rj_ has joined #litex | 02:26 | |
| *** rj_ has quit IRC | 02:33 | |
| *** rj_ has joined #litex | 02:33 | |
| *** rj_ has quit IRC | 02:50 | |
| *** Degi_ has joined #litex | 03:56 | |
| *** Degi has quit IRC | 03:58 | |
| *** Degi_ is now known as Degi | 03:58 | |
| *** Bertl is now known as Bertl_zZ | 05:02 | |
| *** futarisIRCcloud has quit IRC | 05:18 | |
| *** _whitelogger has quit IRC | 06:18 | |
| *** _whitelogger has joined #litex | 06:20 | |
| *** tpb has joined #litex | 07:09 | |
| *** Melkhior has joined #litex | 07:43 | |
| geertu | Melkhior: You're right. An OrangeCrab with a dual-core SPARC CPU would be about half as fast as the 125 KEUR SS1000 when I was at university | 09:21 |
| Melkhior | @geertu Maybe not a fully loaded SS1000, they were able to fit 8 SuperSPARC... though I don't think they were > 50 MHz as standard, or perhaps in the 1000E? | 09:34 |
| Melkhior | You probably stlll need a bigger FPGA than that, if only to fit the FPUs... but we're getting there! | 09:34 |
| Melkhior | @Finde T1 is V9 so 64 bits, and openpiton targets quite a few cores... an interesting project, but another one that may require a (too) big FPGA... | 09:35 |
| Melkhior | Anyway this week-end I finally ran out of space: needed 100.47% of my A7-35k to fit the dual-VexRiscv LiteX with all my extra instructions! | 09:36 |
| Melkhior | Now I know why hardware people worry about space and sharing resources and won't write HW like it's just regular SW :-) | 09:36 |
| Melkhior | Another funny thing about the sd-card Linux driver on my board: it was working fine to read test binaries of the sd-card in SMP mode. Then I ran out of space and used a single core... and the binaries would be randomly corrupted and unusable! Mounting/md5sum/unmounting would have been a decent RNG : -) Disabled some instructions to save space, went | 10:09 |
| Melkhior | back to dual-core, and now the sd-card works again in Linux (it's working no matter what to read the Image and rootfs in either UP or SMP from the firmware). | 10:09 |
| *** ambro718 has joined #litex | 10:19 | |
| *** Melkhior has quit IRC | 10:38 | |
| *** Melkhior has joined #litex | 10:43 | |
| *** ambro718 has quit IRC | 10:54 | |
| *** Bertl_zZ is now known as Bertl | 11:41 | |
| somlo | Melkhior: re. sdcard in linux, (assuming you're using the same driver that's currently in the litex-rebase branch of litex-hub/linux) | 11:49 |
| somlo | what happens if you increase max_blk_count to e.g., 2 here: https://github.com/litex-hub/linux/blob/litex-rebase/drivers/mmc/host/litex_mmc.c#L414 ? | 11:49 |
| Melkhior | I'm using @geertu 's kernel v5.11 ATM | 11:49 |
| Melkhior | @somlo will try that next time I try a UP kernel | 11:50 |
| Melkhior | s/kernel/bitstream/ | 11:51 |
| Melkhior | with two (VexRiscv) cores it seems to always work... | 11:51 |
| somlo | Melkhior: not sure which version of the sdcard driver is in geertu's 5.11 kernel (wondering/hoping it's the same) | 11:53 |
| geertu | somlo: somlo: It's based on a rebase of your tree from a while ago | 12:01 |
| geertu | somlo: Compared to your current tree, it lacks recent updates to "LiteX: driver for LiteSDCard (mmc)". But I haven't really used the SDcard, except for a quick heck if it works (i.e. dd | hexdump ) | 12:04 |
| geertu | s/heck/check/ | 12:04 |
| *** tucanae47 has quit IRC | 13:26 | |
| *** flammit has quit IRC | 13:26 | |
| *** carlomaragno has quit IRC | 13:26 | |
| *** alanvgreen has quit IRC | 13:26 | |
| *** rohitksingh has quit IRC | 13:26 | |
| *** esden has quit IRC | 13:26 | |
| *** daveshah has quit IRC | 13:26 | |
| *** tannewt has quit IRC | 13:27 | |
| *** davidlattimore has quit IRC | 13:27 | |
| *** ric96 has quit IRC | 13:27 | |
| *** Claude has quit IRC | 13:27 | |
| *** y2kbugger has quit IRC | 13:27 | |
| *** levi has quit IRC | 13:27 | |
| *** sorear has quit IRC | 13:27 | |
| *** tucanae47 has joined #litex | 13:27 | |
| *** carlomaragno has joined #litex | 13:28 | |
| *** alanvgreen has joined #litex | 13:28 | |
| *** esden has joined #litex | 13:28 | |
| *** davidlattimore has joined #litex | 13:28 | |
| *** ric96 has joined #litex | 13:28 | |
| Melkhior | Speaking of cheap FPGA - would Litex be able to work with the MAX10 and peripherals in this $37 board: <https://www.arrow.com/en/products/deca/arrow-development-tools> ? That's really, really cheap for 512 MiB of RAM ! But I don't know that litedram would support it (or any of the other peripherals...) | 13:29 |
| *** sorear has joined #litex | 13:29 | |
| *** flammit has joined #litex | 13:29 | |
| *** rohitksingh has joined #litex | 13:29 | |
| *** y2kbugger has joined #litex | 13:29 | |
| *** daveshah has joined #litex | 13:31 | |
| *** tannewt has joined #litex | 13:31 | |
| *** Claude has joined #litex | 13:31 | |
| *** levi has joined #litex | 13:31 | |
| Melkhior | Well this board has a 10M50DAF484C6G, the supported de10nano uses a 10M50DAF484C7G - just a speed grade difference ? So it would be a peripheral issue... | 13:32 |
| Melkhior | s/de10nano/de10lite/ | 13:33 |
| somlo | geertu: might be worth me trying to apply whatever is in *your* tree and not in litex_rebase to the latter, so we can all work from the same tree... e.g., litex_rebase's first five patches are the stuff that's currently winding its way upstream via shorne's tree; I know there's at least one of your patches in the same situation, so we should throw it on top of that pile in litex-rebase... | 13:34 |
| somlo | maybe also add a vexriscv-specific defconfig to make it easy to build... | 13:36 |
| geertu | somlo: Sure. I've just rebased my local tree to v5.11-rc7, but haven't pushed it out, as it contains some more wip. | 13:36 |
| somlo | and/or for whatever CPU you most frequently use | 13:36 |
| geertu | somlo: I have a litex_vexriscv_defconfig in my tree; -) | 13:36 |
| geertu | I don't use it myself, though. | 13:36 |
| somlo | geertu: this should all hopefully get easier once the fundamentals are upstream and all we're left with are device drivers and defconfigs :) | 13:37 |
| geertu | somlo: You're still at v5.11-rc6? | 13:39 |
| somlo | I'm at whatever was current in upstream yesterday (currently 108 commits behind torvalds:master) | 13:40 |
| *** FFY00 has joined #litex | 13:40 | |
| somlo | I have it so that I can just rebase litex-rebase whenever I fetch an updated master | 13:40 |
| geertu | Melkhior: I pushed out my rebase to v5.11-rc7, minus my wip | 13:41 |
| geertu | somlo: It's easier for other people if you stick to tagged bases | 13:42 |
| geertu | Melkhior: For me, "dd if=/dev/mmcblk0 count=10 | hexdump -C" always gives the same output | 13:43 |
| geertu | (vexriscv-smp with 1 core) | 13:44 |
| somlo | we can make that choice, but the cool thing is we don't *have* to -- nothing litex-specific currently in litex-rebase is tied to a specific version or rc or anything... | 13:44 |
| geertu | somlo: Some of the fixes I had in my tree are now in rc7 | 13:44 |
| somlo | the only occasional merge conflict is related to surrounding context lines in a makefile or Kconfig here and there, when other drivers get added upstream -- and last time that happened two months ago :) | 13:45 |
| geertu | somlo: sure, for the LiteX drivers | 13:45 |
| somlo | right -- keeping litex drivers up to date w.r.t. the latest kernel is what "litex-rebase" is meant to do | 13:49 |
| Melkhior | @geertu It also works for me if I have two cores - at least that's what appear to be the case... single core corrupts data:-( So I run dual, I still can fit my tests so far | 13:49 |
| geertu | Melkhior: strange. Perhaps it works for me because of Warning: Max frequency for clock '$glbnet$sys_clk': 56.46 MHz (FAIL at 64.00 MHz) | 13:50 |
| geertu | ;-) | 13:50 |
| Melkhior | Currently running VexRiscv @96 MHz as 100 MHz wasn't reliable anymore with too many instructions | 13:51 |
| somlo | Melkhior: are you getting any errors from the sdcard driver e.g. "command failed, status 2" or similar? | 13:54 |
| Melkhior | @somlo Not sure, I don't think so but I'm not 100% certain... I didn't thoroughly investigate, switched back to dual-core to check if that was still working, it was, so I suck with that :-) | 13:55 |
| Melkhior | I'll have to check next time I try single-core | 13:55 |
| somlo | because for me (single-core rocket) I get perfect behavior on bare-metal bios, and lots of timeouts and breakage when I try to enable multi-block transfers -- and it all seems somehow timing related | 13:57 |
| somlo | and, intuitively, your dual-core-works story seems to suggest that the sdcard hardware likes to enjoy one CPU's full undivided "attention" somehow (don't laugh, I'm trying to form a hypothesis here, rubbing my remaining two brain cells together :) | 13:58 |
| somlo | and I had to increase the default SDPHY timeouts here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1483 | 14:00 |
| somlo | by adding "SDPHY(sdcard_pads, self.platform.device, self.clk_freq, cmd_timeout=10e-1, data_timeout=10e-1)" | 14:00 |
| somlo | to get the single-block/cmd17-only linux sdcard driver to stop running into command/data/dma timeouts | 14:01 |
| Melkhior | @somlo not laughing, some weird timing issues that are masked by the dual-core being more available is what I was guessing as well. It also works fine in the BIOS with single- and dual- VexRiscv (but not single Rocket...) | 14:01 |
| somlo | still no good idea why that still won't improve multi-block (cmd-18) behavior, if I try to turn that on :( | 14:01 |
| somlo | single rocket works great for me in the bios (on nexys4ddr with vivado, but also on the trellis board and ecpix5). But under linux it's even more flakey on ecp5 than on xilinx | 14:02 |
| *** Melkhior has quit IRC | 15:02 | |
| *** Melkhior has joined #litex | 15:10 | |
| somlo | Melkhior: I even disabled interrupts while in litex_request() (in the sdcard driver, single-core rocket), but that didn't seem to help | 15:11 |
| *** Melkhior has quit IRC | 15:23 | |
| somlo | so I guess there's no way around doing it with "Maximum Effort (TM)" and undertanding everything about the underlying litesdcard FSMs, streams, migen records, the whole nine yards... | 15:30 |
| *** Melkhior has joined #litex | 15:37 | |
| Melkhior | _florent_ If I read correctly https://github.com/enjoy-digital/litedram, there's no generic DDR3 PHY, it's always FPGA-specific, so as there's is none for the MAX10 the memory on the Deca board would not work with litedram ? | 15:41 |
| Melkhior | @somlo Yes, but I don't have the skill to debug the sd-card... I still can use it to boot much faster than serial & load binaries w/o recreating the rootfs, I'm already quite happy with that | 15:44 |
| somlo | Melkhior: that's nice (honestly happy for you, honestly not being sarcastic) :) Sadly for me, I want to boot Fedora on ecpix5 and/or the trellisboard, and it's still too slow for that :D | 16:06 |
| somlo | I managed to mount, chroot to /mnt, and run nextpnr-ecp5 and yosys, but it takes like 5 minutes for the binaries to load from sdcard and execute :) | 16:08 |
| Melkhior | @somlo ouch:-) to completely self-host the Rocket build I suppose ? Impressive achievement even if it's not fast :-) | 16:09 |
| somlo | Melkhior: http://www.contrib.andrew.cmu.edu/~somlo/BTCP/#sec_5 :) | 16:10 |
| tpb | Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu) | 16:10 |
| Melkhior | Yes I know the project, that's what got me interested in LiteX in the first place :-) | 16:11 |
| somlo | the example uses spi-mode sdcard, but "native" litesdcard is only significantly faster on bare metal, and about as slow under linux... Which is why that's my current obsession :) | 16:11 |
| Melkhior | I have a profesionnal interest in RISC-V so I follow the news | 16:11 |
| somlo | and yeah, once I can build bitstream from source on the board for which I'm building it, I can retire (or sell out and become a $$$$ consultant, or whatever, wouldn't matter anymore :D :D) | 16:12 |
| Melkhior | :-) | 16:12 |
| somlo | it's a bucket list thing, you see :D | 16:13 |
| Melkhior | ... and then you can go back to OSX in QEMU/KVM;-) that was a while ago... | 16:14 |
| Melkhior | ... or do a macox-on-litex-microwatt, the circle would be complete :-) | 16:15 |
| somlo | heh, digging through the edk2 sources is a traumatic experience, would not recommend it if *fun* is what you're after... | 16:16 |
| *** mikeK_de10nano has joined #litex | 16:40 | |
| mikeK_de10nano | hello | 16:41 |
| *** tannewt has quit IRC | 18:24 | |
| *** tannewt has joined #litex | 18:25 | |
| *** esden has quit IRC | 18:25 | |
| *** esden has joined #litex | 18:25 | |
| *** kgugala has joined #litex | 18:35 | |
| *** kgugala_ has quit IRC | 18:38 | |
| mikeK_de10nano | hello | 18:46 |
| mikeK_de10nano | OK, So I fianlly got Litex to compile for the DE10-nano. But I cannot seem to load it from the litex build scripts?? | 18:47 |
| mikeK_de10nano | Info: Quartus Prime Convert_programming_file was successful. 0 errors, 0 warnings | 18:48 |
| mikeK_de10nano | Info: Peak virtual memory: 313 megabytes | 18:48 |
| mikeK_de10nano | Info: Processing ended: Mon Feb 8 13:46:00 2021 | 18:48 |
| mikeK_de10nano | Info: Elapsed time: 00:00:01 | 18:48 |
| mikeK_de10nano | Info: Total CPU time (on all processors): 00:00:01 | 18:48 |
| mikeK_de10nano | Error (213013): Programming hardware cable not detected | 18:48 |
| mikeK_de10nano | Traceback (most recent call last): | 18:48 |
| mikeK_de10nano | File "litex-boards/litex_boards/targets/de10nano.py", line 143, in <module> | 18:48 |
| mikeK_de10nano | main() | 18:48 |
| mikeK_de10nano | File "litex-boards/litex_boards/targets/de10nano.py", line 140, in main | 18:48 |
| mikeK_de10nano | prog.load_bitstream(os.path.join(builder.gateware_dir, soc.build_name + ".sof")) | 18:48 |
| mikeK_de10nano | File "/home/mikek/Documents/Cyclone5_SOC/Litex_directory/litex/litex/build/altera/programmer.py", line 19, in load_bitstream | 18:48 |
| mikeK_de10nano | self.call(["quartus_pgm", | 18:48 |
| mikeK_de10nano | File "/home/mikek/Documents/Cyclone5_SOC/Litex_directory/litex/litex/build/generic_programmer.py", line 100, in call | 18:48 |
| mikeK_de10nano | raise OSError(msg) | 18:48 |
| mikeK_de10nano | OSError: Error occured during USBBlaster's call, please check: | 18:48 |
| mikeK_de10nano | - USBBlaster installation. | 18:48 |
| mikeK_de10nano | - access permissions. | 18:48 |
| mikeK_de10nano | But I am able to load it with the Quartus_pgmw gui Window with the SOF file that was created from litex. | 18:49 |
| mikeK_de10nano | I am using intel_FGPA_lite, Or Quartus version 20.1, Any info on how to start to troubleshoot? Thanks! MikeK | 18:49 |
| mikeK_de10nano | Jtagconfig Works completely fine. Able to see the DE10-nano board. | 18:50 |
| mikeK_de10nano | 1) DE-SoC [1-4] | 18:50 |
| mikeK_de10nano | 4BA00477 SOCVHPS | 18:50 |
| mikeK_de10nano | 02D020DD 5CSEBA6(.|ES)/5CSEMA6/.. | 18:50 |
| *** kgugala has quit IRC | 19:10 | |
| *** kgugala has joined #litex | 19:10 | |
| *** Melkhior has quit IRC | 19:20 | |
| *** Bertl is now known as Bertl_oO | 19:52 | |
| nickoe | _florent_: Why is the litex main repo not under the litex-hub org? | 20:00 |
| mikeK_de10nano | OK I figured out my Programming problem! the correct Command is "quartus_pgm -c 1 --mode=JTAG --operation="p;de10nano.sof@2"" | 21:03 |
| mikeK_de10nano | So Anybody can help me with the pull request? Thanks! :) | 21:04 |
| nickoe | _florent_: why is this called bscan_spi_.. https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/arty.py#L329 ? I mean -- why the spi part? | 21:06 |
| nickoe | or is that becasue that is intended to program the spi flash instead of just loading the bitstream to the fpga? | 21:18 |
| nickoe | getting closer to migrate to the latest litex... | 21:33 |
| *** mikeK_de10nano has quit IRC | 21:49 | |
| *** mikeK_de10nano has joined #litex | 21:56 | |
| mikeK_de10nano | fixed the Programming Python file. How can I do a Pull Request? | 21:57 |
| mikeK_de10nano | Fixed DE10Nano programmer.py file. Line 15 should be: def __init__(self, cable_name="DE-SoC", device_id=2): | 21:58 |
| nickoe | Hmm, it looks like sphinxcontrib-wavedrom is not instealled with the build script | 22:04 |
| nickoe | mikeK_de10nano: ? I guess you just do a pull request. | 22:04 |
| nickoe | ok, finally running synth agian | 22:16 |
| zyp | mikeK_de10nano, never done one before? | 22:17 |
| zyp | to do a github pull request, you fork the repo, push the changes to a branch in your fork and then open a pull request from that branch | 22:18 |
| zyp | when you do the git push you'll get a message with a direct url to open the pull request | 22:19 |
| nickoe | _florent_: uhh wii, finally the LEDChaser works :D | 22:20 |
| nickoe | but memtest failed this time around | 22:20 |
| nickoe | but I better commit as is. | 22:20 |
| nickoe | Not the pretties, but it is there.. https://github.com/litex-hub/litex-boards/compare/master...nickoe:mars_ax3 | 22:24 |
| nickoe | now I wonder why the ram does not work, it worked with the stuff I had in the litex-buildenv stuff | 22:24 |
| nickoe | that is https://github.com/nickoe/litex-buildenv/tree/mars_ax3 | 22:25 |
| nickoe | but I also tried to "update" to the way the ram was setp for the arty. | 22:25 |
| nickoe | current output for completeness, https://dpaste.com/BK3EAAQWV | 22:29 |
| tpb | Title: dpaste: BK3EAAQWV (at dpaste.com) | 22:29 |
| nickoe | What could I have forgot? | 22:29 |
| *** daveshah has quit IRC | 23:03 | |
| *** ric96 has quit IRC | 23:04 | |
| *** daveshah has joined #litex | 23:04 | |
| *** ric96 has joined #litex | 23:04 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!