| *** tpb has joined #litex | 00:00 | |
| futarisIRCcloud | mithro / _florent_ : https://content.riscv.org/wp-content/uploads/2018/12/zephyr-tensorflow-lite-risc-v.pdf | 01:26 |
|---|---|---|
| mithro | futarisIRCcloud: Yes, I talk to the AntMico team frequently | 01:28 |
| futarisIRCcloud | I want to get Linux and Zephyr running on my Arty board this weekend. _florent_ , Do I just have to update the Vexrisc.v like antmicro did? https://github.com/enjoy-digital/litex/commit/d54a8ebd1bf89dca3f292405c2d03f366f91a3f5 ... | 01:41 |
| mithro | futarisIRCcloud: Not sure | 01:44 |
| futarisIRCcloud | mithro: Did the Zephyr stuff go into litex-buildenv? | 01:45 |
| futarisIRCcloud | https://camo.githubusercontent.com/b9df90a8fb31da16e0e357f0509c9da6ff318a75/68747470733a2f2f646f63732e676f6f676c652e636f6d2f64726177696e67732f642f652f32504143582d3176544c565158776b483370355a764e2d376e494d7852584f79464573673278355f79726433775245773376615772334d632d5f50376b66546265512d2d424e306b35566a5167784863686c69796e6f2f7075623f773d3133393826683d383338 | 01:46 |
| mithro | futarisIRCcloud: Not yet | 01:57 |
| *** futarisIRCcloud has quit IRC | 05:16 | |
| xobs | I mentioned this in #tomu, but I managed to a Wishbone bridge added to the Fomu USB stack, so now I'm adding USB support to litex_server. That's the last piece to getting real-time gdb support for the vexriscv softcore over USB. | 05:37 |
| _florent_ | Hi xobs, i saw it yesterday in #tomu, great! | 05:38 |
| keesj | I Have a tomu ordered a fomu and finished my up5k based design yesterday.. I now need to implement flashing over usb. where .. is the fomu stack? | 06:24 |
| keesj | https://github.com/im-tomu/foboot? | 06:26 |
| tpb | Title: GitHub - im-tomu/foboot: Bootloader for Fomu (at github.com) | 06:26 |
| keesj | I see.. the protocol is mostly implemented in c | 06:33 |
| *** futarisIRCcloud has joined #litex | 09:21 | |
| _florent_ | futarisIRCcloud: here is the updated procedure to run Zephyr: https://github.com/enjoy-digital/zephyr-on-litex-vexriscv (i created a pull request to merge it to antmicro's repo) | 09:27 |
| tpb | Title: GitHub - enjoy-digital/zephyr-on-litex-vexriscv (at github.com) | 09:27 |
| futarisIRCcloud | _florent_: Thanks. I assume it works fine for you? Did you try using ethernet to load the binary over tftp (in hardware)? | 09:46 |
| futarisIRCcloud | https://github.com/antmicro/litex-linux-riscv/issues/2#issuecomment-475525447 | 09:46 |
| tpb | Title: LiteEth driver · Issue #2 · antmicro/litex-linux-riscv · GitHub (at github.com) | 09:46 |
| xobs | keesj I didn't see this here, sorry. Yes, for now I just use DFU because it's easy and only requires one endpoint. | 10:07 |
| xobs | Eventually we'd like to implement UF2, but first things first. | 10:08 |
| xobs | Speaking of which, right now I'm running into this annoying thing in that the Wishbone bus locks up when I put the CPU into reset. That shouldn't happen. | 10:08 |
| _florent_ | futarisIRCcloud: i tested only tested in simulation with https://github.com/enjoy-digital/zephyr-on-litex-vexriscv#simulation | 10:09 |
| tpb | Title: GitHub - enjoy-digital/zephyr-on-litex-vexriscv (at github.com) | 10:09 |
| futarisIRCcloud | Ok | 10:09 |
| _florent_ | futarisIRCcloud: do you have trouble getting netboot working on hardware? | 10:09 |
| futarisIRCcloud | I haven't tested it yet. I will let you know if it works (or not). | 10:09 |
| xobs | This is strange. I can write the "CPU HALT" bit all day, but as soon as I set "CPU HALT", I can read from Wishbone exactly once. The second time I read, the connection hangs. | 11:25 |
| xobs | However, I /can/ halt the CPU, read exactly once, then unhalt the CPU, and it will keep on working. | 11:26 |
| xobs | Perhaps this is a vexriscv-related issue. Weird, though, that I don't see this happen with the UART bridge. | 11:28 |
| xobs | Hmm... I wonder if I'm not misunderstanding the vexriscv "cmd_ready" port. Maybe that's only applicable to injected instructions, and not applicable to things like "halt". | 12:00 |
| keesj | Well. I am wondering what you should expect. the litex "system" only supports a single cpu (doing the wb master) | 12:14 |
| keesj | unless there is a multi-master wishbone crossbar it might just work as designed[tm]. | 12:15 |
| keesj | Somewhere that would be a bit supprizing because it would mean dma or similar will be hard to implement but still. | 12:15 |
| xobs | keesj: it supports multiple masters, I thought. Or maybe I just got lucky in the past. | 12:34 |
| xobs | Ordinarily I use Ethernet or the UART to debug the CPU, both of which are Wishbone masters. | 12:34 |
| _florent_ | xobs: yes it supports multi-masters | 12:35 |
| _florent_ | xobs: are you able to run your code on a larger FPGA where you would be able to add debug in it around the SoC you are building? (standalone litescope for example) | 12:36 |
| xobs | _florent_: that would be wonderful. unfortunately that would mean moving to an Artix board, which would change an awful lot. It's really a shame that the top-of-the-line ICE40UP part only has 5K LUTs. | 12:37 |
| futarisIRCcloud | xobs / _florent_ : Is this ok? https://github.com/im-tomu/foboot/blob/wishbone-debug/hw/foboot-bitstream.py#L401 | 12:39 |
| tpb | Title: foboot/foboot-bitstream.py at wishbone-debug · im-tomu/foboot · GitHub (at github.com) | 12:39 |
| futarisIRCcloud | I didn't see anything like: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_core.py#L389 | 12:40 |
| tpb | Title: litex/soc_core.py at master · enjoy-digital/litex · GitHub (at github.com) | 12:40 |
| _florent_ | xobs: ah ok i see... | 12:40 |
| xobs | futarisIRCcloud: I adapted that bit from https://github.com/timvideos/litex-buildenv/blob/master/gateware/spi_flash.py#L37 | 12:40 |
| tpb | Title: litex-buildenv/spi_flash.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 12:41 |
| _florent_ | xobs: so the issue only happens if you do your access while the CPU is running? | 12:41 |
| xobs | _florent_: no, weirdly, it only happens when I HALT the CPU. I can read and write all of RAM just fine when the CPU is running. | 12:42 |
| xobs | I can manipulate CSRs all day and it works fine. I can scribble over RAM and it's fine. The instant I set the "haltIt" bit on the CPU debug bus, I get exactly one "read", and then I can't read any more. | 12:43 |
| xobs | It seems as though I can write, though. | 12:43 |
| _florent_ | xobs: sorry i'm not really aware of the architecture, but the CPU is not involved in the Wishbone bridge right? | 12:43 |
| xobs | It looks like I can write because eventually I can set the "clearHaltIt" bit and it comes back to life. | 12:43 |
| futarisIRCcloud | I don't see anything about wishbone timeouts ... | 12:44 |
| xobs | _florent_: no, it's not involved in Wishbone, aside from the fact that it's a wishbone master. | 12:44 |
| _florent_ | xobs: and when the wishbone is stuck, the CPU is still running fine? | 12:45 |
| xobs | _florent_: I think the CPU is halted. | 12:46 |
| xobs | Okay, I just verified: when the CPU is halted, it's only reads that break. Writes still work fine. | 12:46 |
| _florent_ | xobs: ok interesting, so it means ack are still generated for writes but no longer for reads | 12:47 |
| xobs | I can't debug the system yet, but I do have an LED that's using the ICE40 LED controller hard macro. So it's pulsing. | 12:47 |
| _florent_ | xobs: do you have external pins you can use? that would be intesting to look at the wishbone stb/ack pins | 12:47 |
| xobs | I have the "LED Enable" signal hooked up to a CSR, and I can still toggle that even when it's in this state. So that's how I know that writes work but reads do not. | 12:48 |
| xobs | _florent_: I do have external pins. That's a good idea. I'll give that a try. | 12:48 |
| _florent_ | ok, i'm just going to look at the code to see what signal we would output | 12:48 |
| _florent_ | in the first time, that would be interesting to confirm that for write we still have the wishbone ack, but not for reads | 12:49 |
| xobs | Whoops. I didn't realize I've been committing to my branch and not mithro's fork. | 12:51 |
| xobs | Anyway, the bridge in question is at https://github.com/xobs/valentyusb/blob/master/valentyusb/usbcore/cpu/usbwishbonebridge.py | 12:51 |
| tpb | Title: valentyusb/usbwishbonebridge.py at master · xobs/valentyusb · GitHub (at github.com) | 12:51 |
| xobs | I really like the "_ce" pattern that _florent_ uses in state machines. | 12:52 |
| _florent_ | xobs: when you set the clearHaltIt, both CPU and wishbone come back to life or only the CPU? | 12:58 |
| xobs | _florent_: both come back to life. | 12:58 |
| xobs | Making me think the CPU is doing something strange with Wishbone. But it's odd that I'm only seeing it on the USB bridge, and not on the other bridges I've tried. | 12:58 |
| _florent_ | ah yes, maybe the CPU is halt when doing a wishbone access | 13:01 |
| _florent_ | so you'll be able to do only one access with the bridge, but then the round robin will lock... | 13:01 |
| _florent_ | but that doesn't explain why writes are working... | 13:02 |
| _florent_ | first thing would be to expose the stb/ack on this: https://github.com/xobs/valentyusb/blob/master/valentyusb/usbcore/cpu/usbwishbonebridge.py#L15 | 13:04 |
| tpb | Title: valentyusb/usbwishbonebridge.py at master · xobs/valentyusb · GitHub (at github.com) | 13:04 |
| _florent_ | just to see if you really have the ack for writes, and not for reads, regarding the results we could connect the debug pins to something else | 13:05 |
| xobs | _florent_: that's good thinking! I have it hooked up now. Let me get it into the failure state and see. | 13:06 |
| xobs | Okay, now /that/ is interesting. Even in the "failed" state, STB/ACK still fire on reads. Which means something else is holding it back. That's good, and it points back to something in my bridge code. | 13:08 |
| xobs | Maybe it has something to do with the event/interrupts? | 13:09 |
| _florent_ | good for the stb/ack results | 13:10 |
| _florent_ | are you using event/interrupts in your wishbone bridge? | 13:11 |
| xobs | no event/interrupts in the wishbone bridge, but they are used in the module that it's attached to. | 13:12 |
| _florent_ | can you point to the code for that? | 13:14 |
| xobs | _florent_: I don't entirely understand it, but the event stuff happens at https://github.com/xobs/valentyusb/blob/master/valentyusb/usbcore/cpu/epfifo.py#L36 | 13:16 |
| tpb | Title: valentyusb/epfifo.py at master · xobs/valentyusb · GitHub (at github.com) | 13:16 |
| _florent_ | xobs: ah ok, but isn't the CPU managing that? (and halting it would stop this?) | 13:17 |
| xobs | That's the theory. | 13:17 |
| xobs | The idea is that the `debug_packet_detected` signal would override normal behavior. | 13:18 |
| xobs | And it's almost doing that. Except when the CPU is halted. | 13:18 |
| _florent_ | so when it's hanging, the read commands still arrives to the wishbone? | 13:21 |
| _florent_ | maybe we should focus on the difference between writes and reads | 13:22 |
| _florent_ | for a write, do you have a respond from the USB? or is it just posted? | 13:22 |
| xobs | That's a good point. Actually, that's a super good point. | 13:26 |
| xobs | When the CPU is halted, bus traffic is cut in half. | 13:26 |
| xobs | So it responds quicker. | 13:26 |
| xobs | Writes look for a USB packet start, but reads just look for the end. Maybe if I change it so that it looks for a start first, that'll fix it. | 13:26 |
| _florent_ | or maybe debug_packet_detected is not valid for the entire transaction? | 13:29 |
| xobs | And with that, it works. | 13:33 |
| xobs | _florent_: you're a genius. | 13:33 |
| _florent_ | xobs: what have you changed? the duration of debug_packet_detected? | 13:34 |
| xobs | No, all I did was change the state machine so that, after a successful read, it first waits for a USB packet to *start*. | 13:34 |
| xobs | Previously it was waiting for the packet to *end*, which works just fine if your read took long enough that the previous packet finished. | 13:34 |
| xobs | If the bus is busy, then the read can take long enough for the previous packet to finish. Then we raise the "ACK" flag, and the next packet starts. | 13:35 |
| xobs | If the bus is idle, then the response comes way before the packet finishes, so I was raising the "ACK" flag. When I got the "end packet" flag, that flag was actually for the "address" packet, and not for the "did you get the address packet?" token. | 13:37 |
| xobs | I guess the moral of the story is that an idle bus is super fast. | 13:38 |
| _florent_ | ok, cool if it works :) | 13:39 |
| xobs | _florent_: this is all I changed: https://github.com/xobs/valentyusb/commit/785ecb7bb7d0822824971f2359475416c77d2e32 | 13:39 |
| tpb | Title: usbwishbonebridge: fix the case where the bus is idle · xobs/valentyusb@785ecb7 · GitHub (at github.com) | 13:39 |
| _florent_ | xobs: just curious, how much time does it take to generates your design? | 13:40 |
| xobs | Let's find out. Note that my computer is 25% loaded with a game running in the background. | 13:42 |
| xobs | 290 seconds | 13:46 |
| _florent_ | ok thanks | 13:52 |
| futarisIRCcloud | The best / worse bugs are always small changes like that... | 13:53 |
| xobs | Well that's fun. Now I can debug the USB connection over the USB connection. Whee! | 13:56 |
| futarisIRCcloud | xobs: Lol. | 13:56 |
| futarisIRCcloud | Did you check what the power usage is when the CPU is running vs stopped? | 13:57 |
| xobs | futarisIRCcloud: I haven't, no. Mostly because I suspect the FPGA power usage is in the ~10 mA range, and the LED/regulators probably burn more than that. | 13:58 |
| xobs | _florent_: I created a PR for the change. I tried to make it small. I'd like to document the protocol. Where should I do that? | 14:07 |
| xobs | Also, it tries to reconnect to the USB device. That's important because during program startup, it resets the USB connection. So I made it transparently reconnect. | 14:08 |
| _florent_ | xobs: thanks, maybe you can document the protocol in the comm_usb file? | 14:18 |
| xobs | _florent_: sure. let me make some changes first. | 14:28 |
| *** futarisIRCcloud has quit IRC | 17:01 | |
| *** futarisIRCcloud has joined #litex | 23:48 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!