*** tpb has joined #tomu | 00:00 | |
mithro | tnt: If you want to include the program in the bitstream, you only have a small amount of space... | 00:00 |
---|---|---|
tnt | mithro: ah yeah. I solved that by having a tiny spi reader that populates the spram then releases the picrorv32 resets. | 00:01 |
mithro | tnt: We were looking at if there is an option to store in the nvcm as a failsafe bootloader | 00:02 |
tnt | Ah yeah, right, I remember that. | 00:03 |
*** ptotter[m] has quit IRC | 00:19 | |
*** ptotter[m] has joined #tomu | 00:20 | |
xobs | mithro: lots of little things. The output pipeline has a three-cycle delay (state transition to SENDING, filling the shift register, and filling the bit stuffer). I hoisted the "start sending" to an earlier state and created a sync pulse generator that eliminated those delays. | 00:42 |
xobs | There were also a ton of CDC shift registers, which shouldn't be required if usb_12 and usb_48 are derived from the same clock source and are synchronous. | 00:42 |
tnt | xobs: I'm kind of curious is you manage to repond within the 6.5 bit time spec of if you're a bit longer ? | 00:43 |
xobs | I'm going to re-install the unififo today and see if I can't figure it out that way. Use that to tune it so that I get clean signals from the host, then remove the host and send transmissions to an oscilloscope to make sure that it's coming out the way we expect. | 00:44 |
xobs | tnt: hmm? Can you rephrase the question please? | 00:44 |
tnt | xobs: so when the host sent you a packet and you must repond, (bus turn around), you have 6.5 bit to go from the SE0->J transition that the host made to you making a J->K transition. | 00:46 |
xobs | Correct | 00:46 |
xobs | As I understand it, you get one more than that, because you get one bit cycle after the SE0->J because it's actually driving "J". | 00:47 |
futarisIRCcloud | xobs: Is https://github.com/xobs/valentyusb/commits/xobs-usb12 the latest? | 00:55 |
tpb | Title: Commits · xobs/valentyusb · GitHub (at github.com) | 00:55 |
xobs | futarisIRCcloud: that's the latest version of the hardware, yes. | 00:56 |
xobs | I should move my git repositories to github... | 00:57 |
tnt | is the sw stack somewhere ? | 00:57 |
xobs | tnt: I'm just putting that together. It's a few disparate repos right now. | 00:58 |
tnt | Ok great. Curious to see if I can easily adapt it to my needs :) | 01:03 |
xobs | tnt: you can give https://github.com/xobs/foboot a try. Very untested. I just merged two repos together. | 01:26 |
tpb | Title: GitHub - xobs/foboot: FPGA-half (at github.com) | 01:26 |
xobs | Also, I need to rush off now. Back in about two hours. | 01:26 |
xobs | It's still very much in the "me doing experiments" stage. | 01:28 |
xobs | The hw dir generates Bitstreams without a valid rom, but you can use the "-l" to switch on fomu-flash to load a replacement rom. | 01:30 |
xobs | (I really should write this all up, maybe once it's working.) | 01:40 |
*** xkapastel has quit IRC | 03:47 | |
xobs | Okay, time to get back into it. | 04:04 |
xobs | So strange. `usb_obuf_empty_read()` is 1 (indicating there isn't any more data to read), and `usb_ev_pending_read()` is also 1 (indicating there is more data to read)? | 05:43 |
xobs | I'm going to make another register and read the number of USB packets that have been received. That way I know who is lying. | 05:45 |
*** futarisIRCcloud has quit IRC | 06:14 | |
*** xkapastel has joined #tomu | 06:18 | |
xobs | Guess there's an issue where the "pending" value defaults to 1, and doesn't go to 0 until you actually receive a USB packet. | 06:58 |
xobs | The good news is that those lovely SOF packets are fantastic for testing link integrity, and the CRC5 is passing on every packet I receive. Which means the bit unstuffing is working as it should. | 06:59 |
xobs | Ah. It would help if I only accepted data when the USB block is enabled. Turns out "SE0" happens an awful lot when the pullup is not enabled, and things aren't getting driven... | 07:15 |
*** AmosSam has left #tomu | 08:29 | |
*** AmosSam has joined #tomu | 08:29 | |
xobs | And after looking at the output with an oscilloscope, I can determine that the output is completely wrong. Gues I didn't understand how Migen state machines work. | 08:46 |
*** hl has joined #tomu | 08:59 | |
*** xkapastel has quit IRC | 09:05 | |
MadHacker | xobs: "Completely wrong" is at least a reproducible bug with known effects and no intermittent behaviours. :) | 09:20 |
xobs | MadHacker: That's true! And I can now whittle away at it. Hooray. | 09:21 |
xobs | I think maybe part of the problem is that clk12, which is derived from clk48, is offset by 1/4 of a cycle. | 10:04 |
*** awe001 has joined #tomu | 10:29 | |
*** futarisIRCcloud has joined #tomu | 10:49 | |
xobs | That's not it. | 10:53 |
xobs | This seems like a metastability problem, which shouldn't happen since these signals come from the same clock. | 10:54 |
xobs | Plus, something is inserting a transition where there isn't one. I'm sending all zeroes, but somehow it's adding a 1. | 10:55 |
*** AmosSam has left #tomu | 10:57 | |
*** AmosSam has joined #tomu | 10:57 | |
xobs | I think what's going on is that the data that the shifter sees may change on the last bit (or the second-to-last bit) because we're not keeping a copy anymore. | 11:41 |
xobs | Ah, or it could be due to the fact that the NRZI "bit-done" signal is coming from a different clock domain that's slightly offset. | 11:42 |
xobs | It's a shame I need to stop debugging this for the night. I feel that I have many good threads to pull on. And this is very obviously the reason that the USB stack isn't working like it should. I think that once I solve this problem, the USB bootloader should come together very quickly. | 11:43 |
*** AmosSam has left #tomu | 11:47 | |
*** AmosSam has joined #tomu | 11:47 | |
*** AmosSam has left #tomu | 12:23 | |
*** AmosSam has joined #tomu | 12:27 | |
*** awe001 has quit IRC | 14:11 | |
*** awe00 has joined #tomu | 14:12 | |
*** xkapastel has joined #tomu | 14:22 | |
*** futarisIRCcloud has quit IRC | 15:19 | |
*** AmosSam has left #tomu | 15:40 | |
*** AmosSam has joined #tomu | 15:42 | |
*** xkapastel has quit IRC | 17:01 | |
*** AmosSam has left #tomu | 18:00 | |
*** AmosSam has joined #tomu | 18:02 | |
*** andi- has quit IRC | 18:44 | |
*** andi- has joined #tomu | 18:44 | |
tnt | The sw/ dir seems to be a mix of a _lot_ of projects :) | 18:50 |
*** awe00 has quit IRC | 18:52 | |
*** xkapastel has joined #tomu | 21:01 | |
*** im-tomu has left #tomu | 21:39 | |
*** im-tomu has joined #tomu | 21:39 | |
*** asante has quit IRC | 22:03 | |
*** awe00 has joined #tomu | 22:39 | |
tnt | Damn, the host are pretty agressive retying SETUP ... like if I didn't have space for it now, I might not have space for it 10us later FFS, just retry on the next frame or so. | 23:01 |
*** awe00 has quit IRC | 23:06 | |
*** xkapastel has quit IRC | 23:11 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!