| *** tpb has joined #litex | 00:00 | |
| *** shuffle2 has quit IRC | 01:10 | |
| *** HoloIRCUser1 has joined #litex | 01:10 | |
| *** HoloIRCUser has quit IRC | 01:12 | |
| *** Degi has quit IRC | 02:30 | |
| *** Degi has joined #litex | 02:32 | |
| *** HoloIRCUser has joined #litex | 03:37 | |
| *** HoloIRCUser1 has quit IRC | 03:39 | |
| *** HoloIRCUser1 has joined #litex | 04:32 | |
| *** HoloIRCUser has quit IRC | 04:35 | |
| *** captain_morgan4 has quit IRC | 04:59 | |
| *** captain_morgan4 has joined #litex | 05:00 | |
| *** _florent_ has quit IRC | 05:38 | |
| *** _florent_ has joined #litex | 05:38 | |
| *** _whitelogger has quit IRC | 06:09 | |
| *** _whitelogger has joined #litex | 06:11 | |
| *** kgugala_ has quit IRC | 06:39 | |
| *** kgugala_ has joined #litex | 06:39 | |
| futarisIRCcloud | Hmm. So the https://github.com/SymbiFlow/symbiflow-examples example for Arty, comes up at 60 MHz, and 115200 baud for the serial port? | 07:19 |
|---|---|---|
| tpb | Title: GitHub - SymbiFlow/symbiflow-examples: Examples designs for showing different ways to use SymbiFlow toolchains. (at github.com) | 07:19 |
| *** kgugala has joined #litex | 07:41 | |
| *** kgugala_ has quit IRC | 07:44 | |
| *** HoloIRCUser has joined #litex | 07:53 | |
| *** HoloIRCUser1 has quit IRC | 07:55 | |
| *** HoloIRCUser1 has joined #litex | 08:29 | |
| *** HoloIRCUser has quit IRC | 08:33 | |
| *** kgugala_ has joined #litex | 09:37 | |
| *** kgugala has quit IRC | 09:40 | |
| futarisIRCcloud | Has anyone here tried Linux on Litex on the Arty board in the last few months, and can point me at working revisions etc? | 09:50 |
| *** Skip has joined #litex | 11:07 | |
| futarisIRCcloud | keesj & daveshah: I hit that bug in openocd (from the distro) for Ubuntu 18.04 LTS today too (on a fresh install). It's why the litex installation instructions recommend installing openocd from source. | 11:32 |
| *** HoloIRCUser has joined #litex | 11:39 | |
| *** HoloIRCUser1 has quit IRC | 11:43 | |
| *** tucanae47 has quit IRC | 12:32 | |
| *** flammit has quit IRC | 12:32 | |
| *** Claude has quit IRC | 12:32 | |
| *** tucanae47 has joined #litex | 12:33 | |
| *** flammit has joined #litex | 12:33 | |
| *** Claude has joined #litex | 12:33 | |
| *** kgugala has joined #litex | 12:51 | |
| *** kgugala has quit IRC | 12:53 | |
| *** kgugala has joined #litex | 12:53 | |
| *** kgugala_ has quit IRC | 12:54 | |
| _florent_ | keesj: if you want to avoid lib conflict issues, instead of sourcing manually the Vivado settings, before building your target, you can do: export LITEX_ENV_VIVADO=/opt/Xilinx/Vivado/20XY.X | 13:04 |
| futarisIRCcloud | Building latest linux-on-litex-vexriscv with Vivado 2020.1 | 13:04 |
| _florent_ | keesj: the scripts will do the sourcing just before running Vivado, and it will allow you yo use OpenOCD with --load after the build | 13:04 |
| _florent_ | keesj: i switched the default programmer to OpenOCD on 7-Series, since a lot faster than Vivado for loading and flashing bitstreams | 13:05 |
| _florent_ | but you can still use Vivado programmer: | 13:06 |
| _florent_ | from litex.build.xilinx.programmer import VivadoProgrammer | 13:06 |
| _florent_ | p = VivadoProgrammer() | 13:06 |
| _florent_ | p.load_bitstream("build/arty/gateware/top.bit") | 13:06 |
| _florent_ | futarisIRCcloud: i did some test on Arty today with linux-on-litex-vexriscv, i'll share my bitstream | 13:09 |
| _florent_ | https://usercontent.irccloud-cdn.com/file/RHuMqMSo/arty_linux_on_litex_vexriscv_serial%2Bethernet.zip | 13:11 |
| somlo | _florent_: as of right now, I can force rocket to boot from sdcard if I hardcode a `return 0;` here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/liblitesdcard/spisdcard.c#L273 | 13:12 |
| tpb | Title: litex/spisdcard.c at master · enjoy-digital/litex · GitHub (at github.com) | 13:12 |
| _florent_ | futarisIRCcloud: this is the bitstream i tested, but there is only serial+ethernet enabled | 13:12 |
| somlo | adding printf statements is tricky, as the routines appear to be called with some weird interleaving pattern, and I get word salad on stdout :) | 13:12 |
| somlo | so I'm not quite sure when that function is called and from where, and why it returns STA_NOINIT when it *should* return 0 | 13:13 |
| futarisIRCcloud | Is there a sdcard PMOD that I can buy that you are using with linux-on-litex-vexriscv ? | 13:14 |
| _florent_ | somlo: do you still have the manual init in boot.c? | 13:14 |
| _florent_ | futarisIRCcloud: i'm using this one: https://store.digilentinc.com/pmod-microsd-microsd-card-slot/ | 13:15 |
| tpb | Title: Pmod MicroSD: microSD Card Slot - Digilent (at store.digilentinc.com) | 13:15 |
| _florent_ | connected on JB | 13:15 |
| somlo | _florent_: no, this is with strictly upstream code (plus/minus the hardcoded `return 0` in disk_status() | 13:16 |
| somlo | tried adding printf statements to disk_status() and disk_initialize(), but they get interleaved in weird ways and I couldn't figure out what the actual sequence is, and what happens during disk_initialize | 13:17 |
| _florent_ | somlo: can you try to do a disk_initialize here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/boot.c#L601? | 13:19 |
| tpb | Title: litex/boot.c at master · enjoy-digital/litex · GitHub (at github.com) | 13:19 |
| *** HoloIRCUser1 has joined #litex | 13:33 | |
| *** HoloIRCUser has quit IRC | 13:36 | |
| somlo | _florent_: nope, still getting a file read error | 13:44 |
| somlo | I'm really ambivalent about the new fat code, btw. Between the weird redefined uint return types, and the non-obvious call tree, it's not much fun to troubleshoot :( | 13:45 |
| futarisIRCcloud | Ok. My fresh build of the latest HEAD of linux-on-litex-vexriscv seems to be working on arty. Doing a serial upload of firmware now, at around 86KB/s. | 13:47 |
| _florent_ | somlo: FatFs is used on very various embedded systems, it's also used in Barebox | 13:47 |
| futarisIRCcloud | The LED blink pattern is very pretty. | 13:47 |
| futarisIRCcloud | Ok. Single Core linux-on-litex-vexrisv HEAD running 'dhrystone 1000000' at 100MHz gives: | 13:59 |
| futarisIRCcloud | Dhrystones per Second: 40192.9 | 13:59 |
| futarisIRCcloud | 40192.9 / 1757 = 22.8759 DMIPS @ 100 MHz or 0.22 DMIPS/MHz ... Seems a little slower than it should be. | 14:04 |
| daveshah | Could be compiler optimisation related? | 14:04 |
| *** HoloIRCUser has joined #litex | 14:31 | |
| *** HoloIRCUser1 has quit IRC | 14:33 | |
| keesj | _florent_: thanks for the info! I will update my script | 15:03 |
| futarisIRCcloud | And running a single core on litex_vexriscv_smp HEAD running 'dhrystone 1000000' at 100MHz gives: | 15:23 |
| futarisIRCcloud | Dhrystones per Second: 71839.1 | 15:23 |
| futarisIRCcloud | About 41 DMIPS @ 100 MHz, or 0.41 DMIPS/MHz. | 15:24 |
| futarisIRCcloud | Four instances on a 4c, gives around 64-65k per core. | 15:25 |
| futarisIRCcloud | 150 DMIPS total (roughly) | 15:27 |
| futarisIRCcloud | Biggest difference between the two seems to be Memspeed. Reads at 458 Mbps on smp. Reads at 327 Mbps on single. | 15:40 |
| _florent_ | futarisIRCcloud: in the SMP repo, each CPU can have 2 dedicated LiteDRAM native ports whereas in the single repo the CPU is has 2 wishbone interface connected to the main wishbone bus | 15:47 |
| _florent_ | futarisIRCcloud: in the SMP repository, are you testing the 4c variant or mp4c? | 15:47 |
| _florent_ | futarisIRCcloud: 4c has 2 LiteDRAM ports for the Cluster, while mp4c has 2 LiteDRAM ports per CPU | 15:48 |
| _florent_ | futarisIRCcloud: but not sure mp4c is fitting on the Arty | 15:48 |
| _florent_ | we still have to make it more resource efficiant | 15:48 |
| _florent_ | efficient | 15:49 |
| felix_ | wasn't the only limitation of the AXI bus that you aren't allowed to make a processor core that uses the ARM ISA and uses the AXI bus and calls it AXI? IIRC the workaround was to call the bus something else in that one case | 17:58 |
| Finde | I think it was something like that too felix_ | 18:41 |
| *** proteusguy has quit IRC | 19:57 | |
| *** proteusguy has joined #litex | 20:09 | |
| awordnot | does anybody know why a .vcd waveform produced by migen's run_simulation would produce `state` and `next_state` variables 40-bit wide with seemingly random values in them? | 20:38 |
| awordnot | i'm just using the standard FSM module with 5 states, and I can see the states are ordered sequentially in the outputted verilog | 20:39 |
| awordnot | running the simulation with nmigen instead (using the compatibility layer) produces a waveform with valid states. Gonna assume that's a bug in migen then | 20:52 |
| *** CarlFK has joined #litex | 21:10 | |
| *** captain_morgan48 has joined #litex | 23:08 | |
| *** HoloIRCUser1 has joined #litex | 23:12 | |
| *** HoloIRCUser has quit IRC | 23:14 | |
| *** captain_morgan48 has quit IRC | 23:38 | |
| *** captain_morgan48 has joined #litex | 23:43 | |
| *** captain_morgan48 is now known as captain_morgan | 23:46 | |
| *** captain_morgan4 has quit IRC | 23:46 | |
| futarisIRCcloud | https://twitter.com/sam210723/status/1270995084226379776 | 23:55 |
| *** HoloIRCUser has joined #litex | 23:56 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!