Thursday, 2019-05-02

*** tpb has joined #tomu00:00
*** stv0g has quit IRC00:03
*** futarisIRCcloud has joined #tomu00:38
tpbTitle: sw: usb-desc: fix usb version · im-tomu/[email protected] · GitHub (at
futarisIRCcloudSo it was the USB version?00:51
xobsfutarisIRCcloud: partly00:52
xobsNow it enumerates when I use a hub.00:52
xobsPlugged directly into my laptop, or plugged in via the Beagle, I don't see any packets at all.00:52
futarisIRCcloudA USB 3.0 port on your laptop?  Do you get any packets from a VM?00:55
xobsI don't have any vm installed. I should try that, you're right.00:57
xobsThe hub is a USB 3.0 hub, though.00:57
futarisIRCcloudNot sure if you will be able to passthrough anything, if it doesn't enumerate though...00:58
xobsI'll definitely need a scope.01:00
futarisIRCcloudAnd it only happens on Windows on the laptop? Did you try booting Linux from a USB drive?01:01
xobsNo, I'll try that. I also have access to other Windows laptops I can try out.01:03
*** kapa has joined #tomu01:07
kapaHello guys, it's again, me.01:13
futarisIRCcloudI've got a ...01:13
tpbTitle: Adafruit USB Isolator - 100mA Isolated Low/Full Speed USB ID: 2107 - $34.95 : Adafruit Industries, Unique & fun DIY electronics and kits (at
kapaTrying to make tomu work with gl-sergei/u2f-token.01:14
kapadid someone meet this issue:01:14
kapaI run: ./u2fcli reg --challenge complexChallengeGoesHere --appid https://mdp.im01:14
kaparesponse is:01:15
kapaRegistering, press the button on your U2F device #1 [unknown U2F-token (EFM32)]01:15
kapaat tomu red led start to flash fast with some impulse01:15
kapawhen I touch it, red light become solid and after around 1 second I got: Error registering with device: u2fhid: error reading response, read timed out01:16
kapain console01:16
kapaI also noticed another strange thing: If I do nnot generate & inject key, when I try to register: it flashes just 3-4 times and stops01:25
kapawhen I inject key, it flashes for a long time01:25
*** johnhmay has quit IRC01:26
kapaany advice how can I debug that ?01:26
*** kapa_ has joined #tomu01:40
*** kapa has quit IRC01:42
*** kapa_ is now known as kapa01:42
kapaI changed timeout to 10 seconds, but no luck, still the same. It looks like tomu doesn't reply on request01:43
kapabtw: is gl-sergey (author of u2f firmware for Tomu) here ?01:44
xobsI'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 #tomu01:56
kapaxobs: which firmware did you try ?02:06
tpbTitle: GitHub - gl-sergei/u2f-token: u2f token firmware for stm32f103 and efm32hg boards (at
xobskapa: this was ages ago, when setting up the Tomu Crowd Funding campaign.02:07
kapaor ?02:07
tpbTitle: chopstx/u2f at efm32 · im-tomu/chopstx · GitHub (at
xobsThe second one02:07
xobsWhich, if I understand right, is deprecated in favor of the first one.02:07
kapaBoth of them have the same author02:08
kapaBut, they work differently ...02:08
kapasecond firmware is not recognised as a valid u2f token ..02:09
kapahowever 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
kapaops, it's from first firmware02:09
kapanope, its from second. Sorry for confusion02:10
kapaanyway: xobs , do you know how can I debug it ?02:10
xobskapa: 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
kapaThank you for you reply, xobs!02:13
xobskapa: best of luck!02:20
xobsWell, I did plug it into a different Windows machine, and it Just Worked.02:20
futarisIRCcloudxobs: Weird. Maybe try on your laptop with a USB 2.0 extension cable (if you have one).02:23
xobsfutarisIRCcloud: The USB beagle is kinda a USB 2.0 extension cable, since it doesn't do 3.0.02:24
xobsAnd 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
xobsThe scope will tell all.02:26
*** emeb has quit IRC02:44
tpbTitle: WCID Devices · pbatard/libwdi Wiki · GitHub (at
tpbTitle: ETW in the Windows 7 USB core stack - Microsoft Tech Community - 270689 (at
tpbTitle: Answering the question "What's wrong with my device?" using USB trace messages - Microsoft Tech Community - 270697 (at
xobsfutarisIRCcloud: you're very good at this02:54
kapaBTW: I resolved my problem with Tomu and U2F token.03:04
kapaProblem was in luck of documentation03:04
xobsYay!  What was the solution?03:04
kapaso I had to resolving visa RTFS method :)03:05
kapaCUSTOM_ATTESTATION_CERT=1 need to add this flag when you compile firmware03:05
kapaI also created issue about that03:06
*** kapa has quit IRC03:16
*** johnhmay has quit IRC03:31
*** johnhmay has joined #tomu03:33
xobsThanks for the bug report!04:02
xobsfutarisIRCcloud: 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
futarisIRCcloudxobs: Yep. Sounds like a hardware / gateware issue.  A USB 1.1, 2.0 or USB 3.0 hub will mask the issue.04:05
futarisIRCcloudThe only other quick test is to check VBUS levels...04:06
xobsThat would seem to mesh with what I'm seeing, where no traffic flows.04:15
xobsSo how does a host decide that a device has finished reset?  I guess I really do need a scope here.04:15
futarisIRCcloudIf the USB bus is held in reset (both DP/DN low), does the gateware remove the pullup and re-assert it?04:25
xobsNo it does not.  Is that a requirement?  (I'm trying to find that in the spec)04:25
tpbTitle: USB in a NutShell - Chapter 2 - Hardware (at
tpbTitle: USB Made Simple - Part 3 (at
xobsIt looks like only HS devices remove the pullup during reset during enumeration.04:29
xobsI'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
futarisIRCcloudLooking quickly at:
tpbTitle: fomu-hardware/schematic.pdf at master · im-tomu/fomu-hardware · GitHub (at
futarisIRCcloudThe pullup resistor isn't actually switched on/off.  It's driven by the FPGA?04:40
xobsIt's either driven or tristated.04:41
futarisIRCcloudxobs: Section & Table 7-2 ...04:43
futarisIRCcloudSection 7.1.704:44
xobsWe ought to be meeting those timings, though.04:46
*** rohitksingh_work has joined #tomu05:03
futarisIRCcloudWhat's usb_pullup_out_write() for?05:08
xobsIt enables or Tristates the pullup05:09
futarisIRCcloudShouldn't it just be usb_pullup_out_write(1) all the time?05:10
futarisIRCcloud(except when rebooting / restarting)05:11
tpbTitle: foboot/usb-epfifo.c at master · im-tomu/foboot · GitHub (at
xobsIt should be. We should be setting it in usbConnect() and clearing it in usbDisconnect()05:12
xobsusb_connect() is called fairly early on.05:13
futarisIRCcloudIf 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
xobsGood suggestion. I'll try that tomorrow, or at the hack fest on Friday.05:18
futarisIRCcloudOk. Sounds like it is one of a: power-up / reset / timing / noise related issue.05:20
xobsYes, and this hub is particularly sensitive to it.05:21
xobsI 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 #tomu05:21
ewenxobs: 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
xobsewen: will do! I'll write one tomorrow. Thanks for the suggestion.05:24
ewenWelcome!  Thanks :-)05:24
xobsI'm going to head to bed now. Night, all!05:25
*** AmosSam has left #tomu05:51
*** ewen has quit IRC05:56
futarisIRCcloudxobs: Night05:59
futarisIRCcloudIs usbalex here?05:59
tpbTitle: Refactored RX pipeline to get rid of excessive delay from MultiReg fi… · usbalex/[email protected] · GitHub (at
tpbTitle: valentyusb - Parts - Google Drawings (at
tntfutarisIRCcloud: it's alexhw[m]06:01
tntfutarisIRCcloud: what's the question ?06:01
*** AmosSam has joined #tomu06:07
*** johnhmay has quit IRC07:13
*** johnhmay has joined #tomu07:13
*** stv0g has joined #tomu08:39
*** stv0g has quit IRC08:45
*** stv0g has joined #tomu08:46
*** m_w has quit IRC08:46
*** stv0g has quit IRC08:51
*** stv0g has joined #tomu08:52
alexhwfutarisIRCcloud: It's me.09:04
*** stv0g has quit IRC09:05
*** stv0g has joined #tomu09:12
*** futarisIRCcloud has quit IRC09:17
*** stv0g has quit IRC09:39
*** stv0g has joined #tomu09:44
*** stv0g has quit IRC09:59
*** stv0g has joined #tomu10:00
*** stv0g has quit IRC10:10
*** stv0g has joined #tomu10:10
*** stv0g has quit IRC10:14
*** futarisIRCcloud has joined #tomu10:15
*** stv0g has joined #tomu10:15
*** kerel_ has joined #tomu10:26
*** kerel has quit IRC10:27
*** m_w has joined #tomu10:49
*** m_w has quit IRC10:56
alexhwtnt/xobs: I updated the pull request. The rx pipeline looks pretty much like the lower diagram now.11:30
tntalexhw: ah nice. That's really how it should be.11:59
*** stv0g has quit IRC12:15
*** stv0g has joined #tomu12:17
*** rohitksingh_work has quit IRC12:46
xobsalexhw, 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
tntxobs: 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 PR13:49
alexhwxobx: NAKs might be due to o_pkt_end is asserted before last data byte goes out of the fifo.13:51
xobsSame issue with just the first two commits.13:52
alexhwI added a check to wait for shifter.o_put before setting o_pkt_end.13:52
alexhwRunning all tests takes a lot of time though ...13:52
alexhwI can push it, testing on hw is probably faster.13:53
xobsYeah.  Weird that synthesis is faster than Python tests.13:53
xobsAnd yeah, simulation works just fine.  Hmm...13:53
tntyeah, 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 #tomu13:54
alexhwtnt: Thats probably the more standard compliant check. I don't expect any issues by waiting for first se0 though.13:56
xobsWith the latest change, it no longer NAKs, and in fact doesn't respond at all.13:58
xobsBefore it would ACK the SETUP packet and NAK the data packet.13:58
alexhwxobx: Ok, I'll look into it in more detail.13:59
xobsalexhw: one interesting thing I see:14:19
xobsI believe the SETUP packet is there, it's just prefixed by 3 extra bytes.14:19
xobsI modified the bootloader to reply with the packet that it received, and got this:14:20
* xobs uploaded an image: image.png (22KB) < >14:20
*** stv0g has quit IRC14:22
tntC3 would be DATA0 PID14:26
xobsRight, the first byte of the SETUP DATA0 packet14:26
tnt01 is the sync pattern after nrzy14:26
xobsSo just need to drop two bytes.  Which sounds like CRC16.14:27
tntno idea where the first and last 00 would come from.14:27
xobsLast 00 just comes from me printing out excess data.14:28
tntoh ok.14:28
alexhwI wrongly assumed nrzi.o_se0 would be there before the shifter is finished with the last packet. Last commit fixes that.14:29
alexhwThere might still be an issue with start of packet detection then though.14:30
xobsOkay, so with the latest patch from alexhw, it's back to what it was earlier, where there are three extra bytes.14:34
xobsIf 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) < >14:34
alexhwxobs: The problem now seems RxPacketDetect not geting reset.14:40
*** stv0g has joined #tomu14:40
alexhwSo 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
alexhwThe detection logic in put into should have gone into RxPacketDetect in the first place. I'll put it there and debug it.14:49
tpbTitle: Release Renode 1.7 · renode/renode · GitHub (at
mithroFomu target support with LiteX and VexRiscv14:57
xobsOoh, fancy!14:58
alexhwxobs: You might try out the latest changes. Hopefully I thought of all the edge cases now.15:29
alexhwBtw. 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
xobsUsually I just run the ones in the cpu/epfifo directory. Though I thought all of the rx tests work too.15:38
alexhwOne 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 malformed15:42
alexhwalso quite a lot of tx/ and sm/ tests fail.15:42
*** emeb has joined #tomu15:55
xobsalexhw: 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
xobsBut I don't see errors in enumeration anymore.16:07
alexhwxobs: Good, I will have a look a the failing unittests later.16:25
xobsSo 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 IRC16:47
*** stv0g has quit IRC17:23
*** emeb has quit IRC18:19
*** emeb has joined #tomu18:20
*** stv0g has joined #tomu18:27
*** rohitksingh has quit IRC20:30
*** m_w has joined #tomu21:06

Generated by 2.13.1 by Marius Gedminas - find it at!