| *** tpb has joined #litex | 00:00 | |
| *** Dolu has joined #litex | 00:12 | |
| *** Dolu1990 has quit IRC | 00:15 | |
| *** Dolu has quit IRC | 00:35 | |
| *** Dolu has joined #litex | 00:51 | |
| *** Dolu has joined #litex | 01:05 | |
| *** Dolu1990 has joined #litex | 01:06 | |
| *** Dolu has left #litex | 01:15 | |
| *** Dolu1990 has quit IRC | 01:15 | |
| *** Dolu has joined #litex | 01:16 | |
| *** Dolu has quit IRC | 01:18 | |
| *** Dolu has joined #litex | 01:20 | |
| xobs | Just a heads up: I have a Rust-based Wishbone bridge that I'm working on. Currently it can act as a basic devmem2, and can also act as a Wishbone bridge (just like litex_server). Though right now it's only for USB. | 04:46 |
|---|---|---|
| xobs | Now I'm working on having it act as a gdbserver for Vex, too, which would eliminate the need to run openocd and litex_server together. | 04:47 |
| futarisIRCcloud | daveshah: Is the "liteeth f0009800.mac: Failed to get IRQ" the interrupt stuff you mentioned you mentioned about 20 hours ago? | 05:13 |
| keesj | so rust is then running on the host pc and directly talking to usb using the kernel API ? | 06:42 |
| keesj | e.g. urb's | 06:42 |
| keesj | remind me of https://github.com/blacksphere/blackmagic/wiki | 06:43 |
| tpb | Title: Home · blacksphere/blackmagic Wiki · GitHub (at github.com) | 06:43 |
| xobs | keesj: most of the magic is in the `libusb_control_transfer()` function, which is part of libusb. Such a bridge already exists in litex, but I'm still not sure how to set up pyusb on Windows. | 06:56 |
| xobs | By porting the bridge to Rust, I have a single executable I can share with people that requires no installation, supporting libraries, or drivers. | 06:56 |
| keesj | I have been dealing with windows and usb but that was really a while ago. just like with linux libusb0.1 v.s. libusb1.0 I think that windows had similar problems. but.. does you implementation despend a c library (libusb or does it perform the call itself directly?) | 06:59 |
| keesj | (I also haven been dealing with libusb on linux and the libusb on android that are just wrappers around the kernel interface) | 07:00 |
| xobs | It turns out that with build.rs, it's possible to statically link the c libraries. | 07:00 |
| xobs | Using libusb-sys, they actually just dump the libusb source into the libusb-sys directory and define various CPP flags, then add individual C files and generate an output library, which then gets linked to the resulting rlib. | 07:02 |
| xobs | libusb has a winusb backend, so yes, libusb is still just a wrapper around the individual kernel interface. | 07:02 |
| futarisIRCcloud | xobs: If you keep going, eventually you'll end up with something like https://github.com/ufrisk/MemProcFS / https://github.com/ufrisk/LeechCore/ ... | 07:03 |
| tpb | Title: GitHub - ufrisk/MemProcFS: The Memory Process File System (at github.com) | 07:03 |
| keesj | It is just that with GPL even lgpl statically linking does put some requiremetns on your code about https://github.com/libusb/libusb/wiki/FAQ#What_is_the_libusb_license | 07:05 |
| tpb | Title: FAQ · libusb/libusb Wiki · GitHub (at github.com) | 07:05 |
| keesj | https://stackoverflow.com/questions/10130143/gpl-lgpl-and-static-linking | 07:06 |
| tpb | Title: open source - GPL/LGPL and Static Linking - Stack Overflow (at stackoverflow.com) | 07:06 |
| xobs | futarisIRCcloud: I'm not sure what advantages that brings, but it looks possible? | 07:08 |
| keesj | yea.. don' worry ... be happy. | 07:09 |
| xobs | keesj: I can definitely see that being an issue. fortunately, the API barrier is pretty clear-cut, so if I wanted to swap out the LGPL part for something else that's definitely doable. Plus, it's open source already, so that part is compatible at least. | 07:10 |
| keesj | I was looking at https://github.com/adamgreig/ffp yesterday or a few days ago (also rust I think) | 07:12 |
| tpb | Title: GitHub - adamgreig/ffp: fpga/flash programmer (at github.com) | 07:12 |
| keesj | https://github.com/adamgreig/ffp/tree/master/firmware/src/hal/usb | 07:12 |
| tpb | Title: ffp/firmware/src/hal/usb at master · adamgreig/ffp · GitHub (at github.com) | 07:12 |
| xobs | handy! I wonder if anyone has gotten Rust building for RISC-V yet... | 07:14 |
| futarisIRCcloud | Mainly for fuzzing devices. | 07:14 |
| futarisIRCcloud | https://github.com/rust-embedded/riscv | 07:14 |
| tpb | Title: GitHub - rust-embedded/riscv: Low level access to RISC-V processors (at github.com) | 07:14 |
| futarisIRCcloud | Actually, it went upstream a few months ago... | 07:15 |
| keesj | futarisIRCcloud: what do you mean by "Mainly for fuzzing devices?" | 07:16 |
| xobs | futarisIRCcloud: oh cool! I see riscv32imc-unknown-elf target. | 07:16 |
| futarisIRCcloud | In response to xobs above... Being able to grab memory on a running system, is what ufrisk is doing on Windows machines. | 07:17 |
| futarisIRCcloud | https://github.com/rust-embedded/wg#the-riscv-team | 07:17 |
| tpb | Title: GitHub - rust-embedded/wg: Coordination repository of the embedded devices Working Group (at github.com) | 07:17 |
| futarisIRCcloud | I saw someone running rust in UEFI a few months ago... | 07:19 |
| futarisIRCcloud | https://oxidizeconf.com/sessions/risc-v/ looks interesting. | 07:21 |
| tpb | Title: RISC-V and Rust: Embedded Systems Done Right | Oxidize Berlin Conference (at oxidizeconf.com) | 07:21 |
| daveshah | futarisIRCcloud: yes, that's the same problem | 07:34 |
| daveshah | The driver for the LiteX interrupt controller needs to be integrated and added to the DTS | 07:35 |
| *** Dolu1 has joined #litex | 09:05 | |
| *** Dolu1 has joined #litex | 09:07 | |
| keesj | for the logic analyzer.. I am grabing the data from the serdes into a 4 bit signal. what trick can I used to flatten it again? | 09:28 |
| keesj | can I perform 4 ticks per sample or similar e.g. https://i.imgur.com/JRjhRrO.png | 09:39 |
| _florent__ | keesj: you can just use a converter: https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/stream.py#L282 | 10:15 |
| tpb | Title: litex/stream.py at master · enjoy-digital/litex · GitHub (at github.com) | 10:15 |
| _florent__ | in your case: | 10:17 |
| _florent__ | data_converter = Converter(4, 20) | 10:17 |
| _florent__ | write the data with data_converter.sink valid/ready/data in 4 bit format | 10:18 |
| _florent__ | and it will generate data on data_converter.source valid/ready/data in 30 bit format | 10:19 |
| *** futarisIRCcloud has quit IRC | 10:37 | |
| keesj | I also "discovered" that the analyzer can write in sigrok format.. pretty cool | 10:38 |
| *** Dolu1 has quit IRC | 10:41 | |
| keesj | I don't understand :( | 11:05 |
| keesj | why do I want to go to 20 bits/end up with 30 bits | 11:08 |
| Dolu | Znc would be one package to try as soon the ethernet is working ^.^ https://github.com/buildroot/buildroot/tree/master/package/znc | 12:49 |
| tpb | Title: buildroot/package/znc at master · buildroot/buildroot · GitHub (at github.com) | 12:49 |
| daveshah | Dolu: I had the Lynx web browser running on the old Vex/LiteX setup with buildroot (using a rootfs on NFS to avoid a big initrd) | 13:01 |
| Dolu | daveshah: Hoo damned XD Honnestly, i don't know you and others managed to get the old VexRiscv running linux. It realy wasn't implemented with it as a goal, and missed many features XD | 13:32 |
| daveshah | It was such a horrible hack tbh | 13:33 |
| daveshah | The new, proper setup is about 10-20x faster | 13:33 |
| *** keesj has quit IRC | 20:22 | |
| *** keesj has joined #litex | 20:24 | |
| *** futarisIRCcloud has joined #litex | 23:24 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
