| *** tpb has joined #tomu | 00:00 | |
| *** stv0g has quit IRC | 00:03 | |
| *** futarisIRCcloud has joined #tomu | 00:38 | |
| futarisIRCcloud | xobs: https://github.com/im-tomu/foboot/commit/9c7db8a84a9253b8de23a313e787fc071df45add | 00:51 |
|---|---|---|
| tpb | Title: sw: usb-desc: fix usb version · im-tomu/foboot@9c7db8a · GitHub (at github.com) | 00:51 |
| futarisIRCcloud | So it was the USB version? | 00:51 |
| xobs | futarisIRCcloud: partly | 00:52 |
| xobs | Now it enumerates when I use a hub. | 00:52 |
| xobs | Plugged directly into my laptop, or plugged in via the Beagle, I don't see any packets at all. | 00:52 |
| futarisIRCcloud | A USB 3.0 port on your laptop? Do you get any packets from a VM? | 00:55 |
| xobs | I don't have any vm installed. I should try that, you're right. | 00:57 |
| xobs | The hub is a USB 3.0 hub, though. | 00:57 |
| futarisIRCcloud | Not sure if you will be able to passthrough anything, if it doesn't enumerate though... | 00:58 |
| xobs | I'll definitely need a scope. | 01:00 |
| futarisIRCcloud | And it only happens on Windows on the laptop? Did you try booting Linux from a USB drive? | 01:01 |
| xobs | No, I'll try that. I also have access to other Windows laptops I can try out. | 01:03 |
| *** kapa has joined #tomu | 01:07 | |
| kapa | Hello guys, it's again, me. | 01:13 |
| futarisIRCcloud | I've got a https://www.adafruit.com/product/2107 ... | 01:13 |
| tpb | Title: Adafruit USB Isolator - 100mA Isolated Low/Full Speed USB ID: 2107 - $34.95 : Adafruit Industries, Unique & fun DIY electronics and kits (at www.adafruit.com) | 01:13 |
| kapa | Trying to make tomu work with gl-sergei/u2f-token. | 01:14 |
| kapa | did someone meet this issue: | 01:14 |
| kapa | I run: ./u2fcli reg --challenge complexChallengeGoesHere --appid https://mdp.im | 01:14 |
| kapa | response is: | 01:15 |
| kapa | Registering, press the button on your U2F device #1 [unknown U2F-token (EFM32)] | 01:15 |
| kapa | at tomu red led start to flash fast with some impulse | 01:15 |
| kapa | when I touch it, red light become solid and after around 1 second I got: Error registering with device: u2fhid: error reading response, read timed out | 01:16 |
| kapa | in console | 01:16 |
| kapa | I also noticed another strange thing: If I do nnot generate & inject key, when I try to register: it flashes just 3-4 times and stops | 01:25 |
| kapa | when I inject key, it flashes for a long time | 01:25 |
| *** johnhmay has quit IRC | 01:26 | |
| kapa | any advice how can I debug that ? | 01:26 |
| *** kapa_ has joined #tomu | 01:40 | |
| *** kapa has quit IRC | 01:42 | |
| *** kapa_ is now known as kapa | 01:42 | |
| kapa | I changed timeout to 10 seconds, but no luck, still the same. It looks like tomu doesn't reply on request | 01:43 |
| kapa | btw: is gl-sergey (author of u2f firmware for Tomu) here ? | 01:44 |
| xobs | I've not done much with u2f beyond verifying that it worked. I do remember it being finicky, mostly due to permissions and also Firefox support. | 01:50 |
| *** johnhmay has joined #tomu | 01:56 | |
| kapa | xobs: which firmware did you try ? | 02:06 |
| kapa | https://github.com/gl-sergei/u2f-token | 02:07 |
| tpb | Title: GitHub - gl-sergei/u2f-token: u2f token firmware for stm32f103 and efm32hg boards (at github.com) | 02:07 |
| xobs | kapa: this was ages ago, when setting up the Tomu Crowd Funding campaign. | 02:07 |
| kapa | or https://github.com/im-tomu/chopstx/tree/efm32/u2f ? | 02:07 |
| tpb | Title: chopstx/u2f at efm32 · im-tomu/chopstx · GitHub (at github.com) | 02:07 |
| xobs | The second one | 02:07 |
| xobs | Which, if I understand right, is deprecated in favor of the first one. | 02:07 |
| kapa | Both of them have the same author | 02:08 |
| kapa | But, they work differently ... | 02:08 |
| kapa | second firmware is not recognised as a valid u2f token .. | 02:09 |
| kapa | however in logs it like that: | 02:09 |
| kapa | [ 1565.576602] usb 1-4: New USB device found, idVendor=0483, idProduct=cdab [ 1565.576607] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1565.576611] usb 1-4: Product: U2F-token (EFM32) | 02:09 |
| kapa | ops, it's from first firmware | 02:09 |
| kapa | nope, its from second. Sorry for confusion | 02:10 |
| kapa | anyway: xobs , do you know how can I debug it ? | 02:10 |
| xobs | kapa: I don't have any suggestions, sorry. I'm not familiar with the state of U2F in general, and from what I gather it's evolving. | 02:11 |
| kapa | Thank you for you reply, xobs! | 02:13 |
| xobs | kapa: best of luck! | 02:20 |
| xobs | Well, I did plug it into a different Windows machine, and it Just Worked. | 02:20 |
| futarisIRCcloud | xobs: Weird. Maybe try on your laptop with a USB 2.0 extension cable (if you have one). | 02:23 |
| xobs | futarisIRCcloud: The USB beagle is kinda a USB 2.0 extension cable, since it doesn't do 3.0. | 02:24 |
| xobs | And I'm fairly sure it's not a cabling issue, since I've tried other devices attached to the LA and they work. | 02:26 |
| xobs | The scope will tell all. | 02:26 |
| *** emeb has quit IRC | 02:44 | |
| futarisIRCcloud | https://github.com/pbatard/libwdi/wiki/WCID-Devices | 02:48 |
| futarisIRCcloud | https://pete.akeo.ie/2011/03/troubleshooting-usb-device-development.html | 02:48 |
| tpb | Title: WCID Devices · pbatard/libwdi Wiki · GitHub (at github.com) | 02:48 |
| futarisIRCcloud | https://techcommunity.microsoft.com/t5/Microsoft-USB-Blog/ETW-in-the-Windows-7-USB-core-stack/ba-p/270689 | 02:49 |
| tpb | Title: ETW in the Windows 7 USB core stack - Microsoft Tech Community - 270689 (at techcommunity.microsoft.com) | 02:49 |
| futarisIRCcloud | https://techcommunity.microsoft.com/t5/Microsoft-USB-Blog/Answering-the-question-quot-What-s-wrong-with-my-device-quot/ba-p/270697 | 02:50 |
| tpb | Title: Answering the question "What's wrong with my device?" using USB trace messages - Microsoft Tech Community - 270697 (at techcommunity.microsoft.com) | 02:50 |
| xobs | futarisIRCcloud: you're very good at this | 02:54 |
| kapa | BTW: I resolved my problem with Tomu and U2F token. | 03:04 |
| kapa | Problem was in luck of documentation | 03:04 |
| xobs | Yay! What was the solution? | 03:04 |
| kapa | so I had to resolving visa RTFS method :) | 03:05 |
| kapa | CUSTOM_ATTESTATION_CERT=1 need to add this flag when you compile firmware | 03:05 |
| kapa | e,g: make TARGET=TOMU CUSTOM_ATTESTATION_CERT=1 | 03:05 |
| kapa | I also created issue about that | 03:06 |
| *** kapa has quit IRC | 03:16 | |
| *** johnhmay has quit IRC | 03:31 | |
| *** johnhmay has joined #tomu | 03:33 | |
| xobs | Thanks for the bug report! | 04:02 |
| xobs | futarisIRCcloud: So I managed to get ETW up and running. The actual error appears to be "Port Reset Timed Out", which makes me think we're not doing something right from an electrical perspective. The hub masks this. | 04:03 |
| futarisIRCcloud | xobs: Yep. Sounds like a hardware / gateware issue. A USB 1.1, 2.0 or USB 3.0 hub will mask the issue. | 04:05 |
| futarisIRCcloud | The only other quick test is to check VBUS levels... | 04:06 |
| xobs | That would seem to mesh with what I'm seeing, where no traffic flows. | 04:15 |
| xobs | So how does a host decide that a device has finished reset? I guess I really do need a scope here. | 04:15 |
| futarisIRCcloud | If the USB bus is held in reset (both DP/DN low), does the gateware remove the pullup and re-assert it? | 04:25 |
| xobs | No it does not. Is that a requirement? (I'm trying to find that in the spec) | 04:25 |
| futarisIRCcloud | https://www.beyondlogic.org/usbnutshell/usb2.shtml | 04:28 |
| tpb | Title: USB in a NutShell - Chapter 2 - Hardware (at www.beyondlogic.org) | 04:28 |
| futarisIRCcloud | http://www.usbmadesimple.co.uk/ums_3.htm | 04:28 |
| tpb | Title: USB Made Simple - Part 3 (at www.usbmadesimple.co.uk) | 04:28 |
| xobs | It looks like only HS devices remove the pullup during reset during enumeration. | 04:29 |
| xobs | I've seen some noise on the line, and I'm not sure what's causing it. I'm going to guess the hub inside this laptop is seeing that, and is thinking that it's not honoring reset. | 04:30 |
| futarisIRCcloud | Looking quickly at: https://github.com/im-tomu/fomu-hardware/blob/master/hacker/releases/v0.0-19-g154fecc/schematic.pdf | 04:39 |
| tpb | Title: fomu-hardware/schematic.pdf at master · im-tomu/fomu-hardware · GitHub (at github.com) | 04:39 |
| futarisIRCcloud | The pullup resistor isn't actually switched on/off. It's driven by the FPGA? | 04:40 |
| xobs | It's either driven or tristated. | 04:41 |
| futarisIRCcloud | xobs: Section 7.1.5.1 & Table 7-2 ... | 04:43 |
| futarisIRCcloud | Section 7.1.7 | 04:44 |
| xobs | We ought to be meeting those timings, though. | 04:46 |
| *** rohitksingh_work has joined #tomu | 05:03 | |
| futarisIRCcloud | What's usb_pullup_out_write() for? | 05:08 |
| xobs | It enables or Tristates the pullup | 05:09 |
| futarisIRCcloud | Shouldn't it just be usb_pullup_out_write(1) all the time? | 05:10 |
| futarisIRCcloud | (except when rebooting / restarting) | 05:11 |
| futarisIRCcloud | https://github.com/im-tomu/foboot/blob/master/sw/src/usb-epfifo.c#L80 | 05:12 |
| tpb | Title: foboot/usb-epfifo.c at master · im-tomu/foboot · GitHub (at github.com) | 05:12 |
| xobs | It should be. We should be setting it in usbConnect() and clearing it in usbDisconnect() | 05:12 |
| xobs | usb_connect() is called fairly early on. | 05:13 |
| futarisIRCcloud | If you're testing on a non-hacker board, like EVT, I'd assign one of those buttons to soft reset from inside foboot, and see if it enumerates then. I assume the hard reset when powered, doesn't work... | 05:17 |
| xobs | Good suggestion. I'll try that tomorrow, or at the hack fest on Friday. | 05:18 |
| futarisIRCcloud | Ok. Sounds like it is one of a: power-up / reset / timing / noise related issue. | 05:20 |
| xobs | Yes, and this hub is particularly sensitive to it. | 05:21 |
| xobs | I wouldn't be surprised if putting a scope on it was enough to get it working, even if it's high impedence. | 05:21 |
| *** ewen has joined #tomu | 05:21 | |
| ewen | xobs: mithro: random thought: it might be worth posting a Fomu progress update. IIRC both USB enumeration / MicroPython port, and "at LatchUp" are news. | 05:24 |
| ewen | (AFAICT last update posted was a month ago.) | 05:24 |
| xobs | ewen: will do! I'll write one tomorrow. Thanks for the suggestion. | 05:24 |
| ewen | Welcome! Thanks :-) | 05:24 |
| xobs | I'm going to head to bed now. Night, all! | 05:25 |
| *** AmosSam has left #tomu | 05:51 | |
| *** ewen has quit IRC | 05:56 | |
| futarisIRCcloud | xobs: Night | 05:59 |
| futarisIRCcloud | Is usbalex here? | 05:59 |
| futarisIRCcloud | https://github.com/usbalex/valentyusb/commit/6c4dacf3b4c3db9359ee9273448f9349d58f0e33 | 05:59 |
| tpb | Title: Refactored RX pipeline to get rid of excessive delay from MultiReg fi… · usbalex/valentyusb@6c4dacf · GitHub (at github.com) | 05:59 |
| futarisIRCcloud | https://docs.google.com/drawings/d/1olpdWXglPGzJdW_R1DwWviBumlCetyuSZjl-luO_Xe8/edit | 05:59 |
| tpb | Title: valentyusb - Parts - Google Drawings (at docs.google.com) | 05:59 |
| tnt | futarisIRCcloud: it's alexhw[m] | 06:01 |
| tnt | futarisIRCcloud: what's the question ? | 06:01 |
| *** AmosSam has joined #tomu | 06:07 | |
| *** johnhmay has quit IRC | 07:13 | |
| *** johnhmay has joined #tomu | 07:13 | |
| *** stv0g has joined #tomu | 08:39 | |
| *** stv0g has quit IRC | 08:45 | |
| *** stv0g has joined #tomu | 08:46 | |
| *** m_w has quit IRC | 08:46 | |
| *** stv0g has quit IRC | 08:51 | |
| *** stv0g has joined #tomu | 08:52 | |
| alexhw | futarisIRCcloud: It's me. | 09:04 |
| *** stv0g has quit IRC | 09:05 | |
| *** stv0g has joined #tomu | 09:12 | |
| *** futarisIRCcloud has quit IRC | 09:17 | |
| *** stv0g has quit IRC | 09:39 | |
| *** stv0g has joined #tomu | 09:44 | |
| *** stv0g has quit IRC | 09:59 | |
| *** stv0g has joined #tomu | 10:00 | |
| *** stv0g has quit IRC | 10:10 | |
| *** stv0g has joined #tomu | 10:10 | |
| *** stv0g has quit IRC | 10:14 | |
| *** futarisIRCcloud has joined #tomu | 10:15 | |
| *** stv0g has joined #tomu | 10:15 | |
| *** kerel_ has joined #tomu | 10:26 | |
| *** kerel has quit IRC | 10:27 | |
| *** m_w has joined #tomu | 10:49 | |
| *** m_w has quit IRC | 10:56 | |
| alexhw | tnt/xobs: I updated the pull request. The rx pipeline looks pretty much like the lower diagram now. | 11:30 |
| tnt | alexhw: ah nice. That's really how it should be. | 11:59 |
| *** stv0g has quit IRC | 12:15 | |
| *** stv0g has joined #tomu | 12:17 | |
| *** rohitksingh_work has quit IRC | 12:46 | |
| xobs | alexhw, tnt: I tried it on real hardware, and it beautifully NAKs everything. It's as though it's not getting valid data. But the tokens are at least getting recognized... | 13:45 |
| tnt | xobs: can you try the version without the whole move to 48M ? (and just the 'valid' gating and new activity detector). I think it's just the first 2 commits from the PR | 13:49 |
| xobs | Building... | 13:51 |
| alexhw | xobx: NAKs might be due to o_pkt_end is asserted before last data byte goes out of the fifo. | 13:51 |
| xobs | Same issue with just the first two commits. | 13:52 |
| alexhw | I added a check to wait for shifter.o_put before setting o_pkt_end. | 13:52 |
| alexhw | Running all tests takes a lot of time though ... | 13:52 |
| alexhw | I can push it, testing on hw is probably faster. | 13:53 |
| xobs | Yeah. Weird that synthesis is faster than Python tests. | 13:53 |
| xobs | And yeah, simulation works just fine. Hmm... | 13:53 |
| tnt | yeah, rx_act might fall a bit early. In theory packet end is "SE0 SE0 J" and maybe it expect to see the full sequence. | 13:54 |
| *** rohitksingh has joined #tomu | 13:54 | |
| alexhw | tnt: Thats probably the more standard compliant check. I don't expect any issues by waiting for first se0 though. | 13:56 |
| xobs | With the latest change, it no longer NAKs, and in fact doesn't respond at all. | 13:58 |
| xobs | Before it would ACK the SETUP packet and NAK the data packet. | 13:58 |
| alexhw | xobx: Ok, I'll look into it in more detail. | 13:59 |
| xobs | alexhw: one interesting thing I see: | 14:19 |
| xobs | I believe the SETUP packet is there, it's just prefixed by 3 extra bytes. | 14:19 |
| xobs | I modified the bootloader to reply with the packet that it received, and got this: | 14:20 |
| * xobs uploaded an image: image.png (22KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/TwxftofrprQEWjBZTfhwnOVu > | 14:20 | |
| *** stv0g has quit IRC | 14:22 | |
| tnt | C3 would be DATA0 PID | 14:26 |
| xobs | Right, the first byte of the SETUP DATA0 packet | 14:26 |
| tnt | 01 is the sync pattern after nrzy | 14:26 |
| xobs | So just need to drop two bytes. Which sounds like CRC16. | 14:27 |
| tnt | no idea where the first and last 00 would come from. | 14:27 |
| xobs | Last 00 just comes from me printing out excess data. | 14:28 |
| tnt | oh ok. | 14:28 |
| alexhw | I wrongly assumed nrzi.o_se0 would be there before the shifter is finished with the last packet. Last commit fixes that. | 14:29 |
| alexhw | There might still be an issue with start of packet detection then though. | 14:30 |
| xobs | Okay, so with the latest patch from alexhw, it's back to what it was earlier, where there are three extra bytes. | 14:34 |
| xobs | If I manually remove those three bytes, it actually enumerates, but I sitll see corrupted packets occasionally. | 14:34 |
| * xobs uploaded an image: image.png (94KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/kEBUCzVlttTIbdjpIDqCljJO > | 14:34 | |
| alexhw | xobs: The problem now seems RxPacketDetect not geting reset. | 14:40 |
| *** stv0g has joined #tomu | 14:40 | |
| alexhw | So the bitstuff remover and rx shifter stay 'on' after the packet has ended. That explains getting the data at the beginning of the next packet. | 14:44 |
| alexhw | The detection logic in put into pipeline.py should have gone into RxPacketDetect in the first place. I'll put it there and debug it. | 14:49 |
| mithro | https://github.com/renode/renode/releases/tag/v1.7 | 14:57 |
| tpb | Title: Release Renode 1.7 · renode/renode · GitHub (at github.com) | 14:57 |
| mithro | Fomu target support with LiteX and VexRiscv | 14:57 |
| xobs | Ooh, fancy! | 14:58 |
| alexhw | xobs: You might try out the latest changes. Hopefully I thought of all the edge cases now. | 15:29 |
| alexhw | Btw. is there a list if tests that are expected to fail / known bitrot? Currently I run all the tests in xobs/valentyusb and compare it with results of test in my working directory. | 15:31 |
| xobs | Usually I just run the ones in the cpu/epfifo directory. Though I thought all of the rx tests work too. | 15:38 |
| alexhw | One rx/clock_test is failing (Others indicate failure, too, but that is due to wrong comparison function (ouput vs. 'j'+actual_output)) and rx/pipeline_test: test_usb2_sof_stuffed_mid input sequence was malformed | 15:42 |
| alexhw | also quite a lot of tx/ and sm/ tests fail. | 15:42 |
| *** emeb has joined #tomu | 15:55 | |
| xobs | alexhw: it does look much better, but I still need to strip three bytes off the front. And as soon as I download something over DFU it fails. | 16:07 |
| xobs | But I don't see errors in enumeration anymore. | 16:07 |
| alexhw | xobs: Good, I will have a look a the failing unittests later. | 16:25 |
| xobs | So there are still three extra bytes during SETUP packets, and some invalid data during... something, I haven't figured it out yet. | 16:32 |
| *** futarisIRCcloud has quit IRC | 16:47 | |
| *** stv0g has quit IRC | 17:23 | |
| *** emeb has quit IRC | 18:19 | |
| *** emeb has joined #tomu | 18:20 | |
| *** stv0g has joined #tomu | 18:27 | |
| *** rohitksingh has quit IRC | 20:30 | |
| *** m_w has joined #tomu | 21:06 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!