Sunday, 2018-12-09

*** tpb has joined #timvideos00:00
*** TheAssassin has quit IRC00:23
*** TheAssassin has joined #timvideos00:24
mithrotannewt: Should I rebase my current valentyusb work on top of your latest develop branch?00:54
tannewtya, I would. we're not quite that far with circuitpython but I think its improved00:55
mithroxobs / tannewt / tinyfpga / tmmmcci: What do you think the best way to detect a reset is?02:39
xobsmithro: does it matter?02:44
mithroxobs: What do you mean?02:44
xobsThough you could always treat a change in the "address" packet as a reset.02:45
xobsBy that, I mean what problem are you trying to solve by looking for a reset?02:45
mithroxobs: When moving from a host to a VM apparently a reset is issued - the fact the old bootloader doesn't detect / handle this means it can't be used in a VM apparently?02:46
xobsIt looks like a "reset" is an SE0 state for > 10ms.02:47
xobsBut a reset state should also cause you to get a SETUP packet with an address of 0, which is also a pretty clear sign.02:47
mithrotannewt: As far as I can see, the hardware _should_ be raising pending after a zero length packet on both in and out interfaces...02:48
mithrotannewt: I have unittests which say this is true, so going to test on hardware now02:48
xobsThe only other time you see SE0 is at the end of a packet for 2 cycles, so if you see SE0 for 3+ cycles you can probably treat that as a reset.02:54
mithrotannewt: This is what I'm currently getting;03:12
tpbTitle: Snippet | IRCCloud (at
tannewtmithro: busy at the moment. I may have time to look tomorrow or later tonight03:16
mithrotannewt: So, from what I can see it seems like the status packet is scheduled to be received *after* I have already received it....04:17
tannewtdo you have a dedicated buffer for it now?04:18
mithrotannewt: no04:20
tannewtis the dcd layer queueing up the receive?04:20
mithrotannewt: yes, but the host has already sent it by that time...04:21
tannewtright, thats why its better to have a dedicated buffer04:22
tannewtsince you can get one at any time04:22
mithrotannewt: status packet -- not setup packet04:22
tannewtI'd think it'd be ok to nak it until ready04:23
tannewtonly setup is really critical I think04:23
mithroHrm... my tinyusb_bx won't stay in bootloader mode any more....04:28
mithro[14707.263140] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead04:30
mithroIt scares me how easy it is to cause the USB host hardware to lock up...04:37
xobsmithro: is a state machine getting into a bad state?04:41
mithroAhh ha! As a status packet never writes/reads data, it doesn't trigger the NAK path04:44
*** rohitksingh has joined #timvideos04:57
mithrotannewt: This is where I'm up too now06:03
tpbTitle: Snippet | IRCCloud (at
mithroSeems to be dieing on a split descriptor transfer....06:03
mithrotannewt: I think we are probably taking to long to respond06:10
tpbTitle: Snippet | IRCCloud (at
mithroGetting a setup packet right after the descriptor06:11
mithroWhat descriptor would be 75 bytes long?06:14
xobsmithro: I seem to recall you need to respond very quickly.06:15
tannewtI doubt it’s a time thing. Data transfers are pretty forgiving06:17
tannewtAs long as you nak06:17
tannewtThe config descriptor could be that long06:18
mithrotannewt: See the decode above -- it gets the DATA1 and then the following up is a SETUP?06:19
mithrodescriptor idx 0 ptr 2005a9e0 len 4b06:19
mithrostart xfer d:i e:0 l:64 b:10000104  ..06:19
mithrodcd_poll ep0  in complete 6406:19
mithrostart xfer d:i e:0 l:11 b:10000104  ..06:19
mithrotinyusb was expecting to send 11 more bytes...06:19
xobsmithro: it's fine for the host to abort the transfer early.06:20
tannewtHow many did the setup packet ask for?06:21
mithrousb_packet-1: DATA0 [ 80 06 00 02 00 00 09 00 ]06:22
mithroI think....06:22
mithroep0 out got setup g:8 w:8 80 6 0 2 0 0 9 006:23
xobsIt's asking for the configuration descriptor, which could be long.06:25
xobsOne thing to look out for -- is the endianness of wTotalLength correct?06:26
mithroI'm wondering that...06:28
mithrowireshark says the wLength should be 906:29
tannewtI had to swap one of the tusb things to support big endian when I was working on it06:31
tannewtmithro, are you going to be debugging for a while longer? I can probably go get setup06:34
mithrotannewt: Probably06:35
xobsmithro: that's just the maximum amount of data it'll request.06:35
tannewtkk, I'll head up06:36
mithrotannewt: Just pushed everything06:38
tannewtkk, getting into the env06:44
tannewtlooks like its naking setup packets06:53
tannewtit was resilient to it though06:55
mithrotannewt: Did you rebuild the gateware?06:56
tannewtah maybe not06:56
tannewtI skipped to make image I think06:56
mithroI think the issue is06:56
mithro      len       = ((tusb_desc_configuration_t const*) desc_data)->wTotalLength;06:56
mithrowireshark is telling me that the computer is expecting wLength==9, but tinyusb is saying it's 0x4b long...06:57
tannewtis it trying to send 0x4b though?06:57
tannewtit should cap at the packet limit06:58
mithroIt  is trying to send a 64 byte packet, followed by a 11 byte packet...06:58
tannewtyup, I see what you are seeing07:02
tannewtyup, looks like a bug07:06
mithrotannewt: where is the bug? :-P07:06
tannewtit works ok in circuitpython, let me dig into the history07:07
tannewtits an endian issue07:16
tannewtthe length in the setup struct is wrong so its not capping the descriptor lengh07:16
mithrotannewt: Fix?07:17
tannewtfix it when we queue the setup packet07:17
tannewtor do we need to change the struct definition?07:19
mithrotannewt: not sure...07:20
tannewtlooks like usb is little endian over the wire07:20
tannewtare we stuck with an lm32?07:21
xobsI think it would be best to use tole16() and friends in endian.h07:22
tpbTitle: USB: setup packet endianness · Issue #478 · libopencm3/libopencm3 · GitHub (at
tannewtthat makes it way more complicated because you need to do that for every field in the usb structures07:23
xobsIf the structures don't change, another option is to hardcode the descriptors as uint8_t[]07:25
tannewtits not the descriptors I'm worried about its all of the protocol messages that worry me07:27
mithroI wonder if we can just use __attribute__ ((scalar_storage_order="littleendian"))07:27
tannewtcould try it07:27
mithrotannewt: Where is the correct place?07:29
tannewtsrc/common/tusb_types.h I think07:29
tpbTitle: Snippet | IRCCloud (at
mithrotannewt: Needs to be __attribute__((scalar_storage_order("little-endian"),packed))07:31
tannewtk, now I think its hitting my previous fixes and breaking07:33
mithroI'm getting07:33
mithro<artificial>:(.text.startup.main+0x2bc): undefined reference to `__bswapsi2'07:33
tannewtit built for me07:34
tpbTitle: Snippet | IRCCloud (at
tannewtwrong setup value now07:34
mithrotannewt: I wonder why you are not getting the error I am?07:37
tannewtya, weird07:37
xobssounds like you're using different libc.a files07:37
xobsActually, __bswapsi2 sounds more like libgcc.a07:38
tannewttinyusb is commit c5bd7b1c26f141a6ed768e48553ea3aa9d00da0407:39
tannewtits getting further but the trace is really noisy from not acking the setup packed07:39
tpbTitle: Snippet | IRCCloud (at
mithroYeah looks like07:41
tannewtI think it may have enumerated07:42
tannewtI'm on Arch linux which might change things too07:44
tannewthrm, got it now actually07:45
tannewtwhen I tried to change everything07:45
tannewtundefined reference to `__bswapsi2'07:45
mithrotannewt: do a "conda install gcc-lm32-elf-newlib"07:46
mithrotannewt: Then add a -lgcc to hw/bsp/valentyusb/board.mk07:46
mithroHrm, my tinyusb is failing on reading....07:48
tannewtundo the little endian change in tusb_common.h07:48
tannewtthe call is uses to extract the high and low bytes07:49
mithroI think I may have run out of spi flash space?08:01
tpbTitle: Snippet | IRCCloud (at
tannewtwhat did you change?08:03
mithrotannewt: I added the -lgcc apparently...08:03
tannewtah, I didn't need to add it08:03
mithrotannewt: Which structures did you add the attribute too?08:04
tannewtall of them by changing ATTR_PACKED macro to include it08:05
mithrooh, how did you get past the __bswapsi2 issue?08:05
tannewtI installed the lib you said but didn't add -lgcc08:05
mithrotannewt: Can you commit and push your version?08:06
mithroAlso tell me how big your Firmware section is?08:07
tpbTitle: GitHub - tannewt/tinyusb at endian (at
tpbTitle: Snippet | IRCCloud (at
mithroHrm... I'm less smaller?08:10
tannewtweird that our toolchains seem different08:14
mithrotannewt: Nope, getting the same now I have your version08:14
mithroand its programming fine again....08:14
tannewtk, perfect08:14
tpbTitle: Snippet | IRCCloud (at
tannewtI think the string descriptors are broken08:15
xobs"config index 0 descriptor too short (expected 19200, got 75)" Endianness sucks08:15
xobsStill, almost there!08:16
* tannewt flips table and will do it myself08:18
tannewtor not :-)08:20
*** rohitksingh has quit IRC08:24
*** rohitksingh has joined #timvideos08:24
mithrotannewt: That is with your version of the code....08:28
tannewtwhat do you mean?08:29
mithrotannewt: The enumeration above with the length error08:29
tannewtI bet its similar to the problem with string descriptors08:30
tannewtthe macro that gens it places the first bytes wrong08:31
tpbTitle: Snippet | IRCCloud (at
tannewtit'd be way easier to use this on a little endian core08:32
mithrotannewt: Why is it doing that?08:34
tannewtdoing what?08:34
mithrotannewt: Mundging things into a uint8_t ?08:35
tannewtthat bit is an array of uint16_t because thats how strings are encoded08:35
xobstannewt: why isn't it treating it as a uint8_t instead of casting it to a uint16_t?08:37
mithroIn theory we could just apply the attribute to that array08:37
mithro          char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };08:39
mithroBut I can't figure out how to apply that inside your macro08:40
tannewtplease stop saying its "your" code. its not mine. I did not write it. its open source its as much mine as it is yours08:41
mithroconst uint16_t __attribute__((scalar_storage_order("little-endian"))) []08:42
mithrowell, I'm giving up for the night08:48
xobsmithro: where is your repo?08:48
tpbTitle: GitHub - mithro/litex-buildenv at tinyusb-work (at
mithroexport PLATFORM=tinyfpga_bx CPU_VARIANT=lite TARGET=usb FIRMWARE=tinyusb08:49
mithromkdir -p build/tinyfpga_bx_usb_lm32.lite//software/tinyusb/08:49
mithroln -s $PWD/third_party/valentyusb/third_party/tinyusb/examples/device/cdc_msc_hid/build-valentyusb/valentyusb-firmware.bin build/tinyfpga_bx_usb_lm32.lite//software/tinyusb/firmware.bin08:49
xobsThanks.  I'll take a look at it when I'm in the office, in about 18 hours.  If you don't spend more time poking at it on Sunday :)08:50
mithro(in third_party/valentyusb/third_party/tinyusb) make -C examples/device/cdc_msc_hid BOARD=valentyusb clean && make -C examples/device/cdc_msc_hid BOARD=valentyusb08:50
mithroxobs: Currently only testing on the tinyfpga_bx08:50
xobsI see.  More luts.08:51
mithroxobs: But no SPRAM08:51
tannewtcould we use a little endian core instead?09:03
tannewtall of the multi-byte descriptor values are backwards09:04
tannewtok, I got the descriptor correct09:47
tannewtmy ATTR_PACKED changed was wrong it was the wrong attribute name09:47
tannewtI pushed to
tpbTitle: GitHub - tannewt/tinyusb at endian (at
tannewtit gets to where linux requests the high speed descriptor and tinyusb tries to respond with a stall09:48
tannewtok, got it past the stall by queueing another setup rx10:13
tannewtI think its failing in the cdc layer10:13
tannewtand the string descriptor endianness is wrong too10:13
tannewtbedtime for me10:13
tannewt(well past it)10:14
*** rohitksingh has quit IRC12:20
*** sb0_ has joined #timvideos15:22
tmmmcciLooks like good progress, sorry, was head down on something else.15:46
*** rohitksingh has joined #timvideos17:07
*** rohitksingh has quit IRC17:19
*** techman83 has quit IRC22:06
*** techman83 has joined #timvideos22:07
*** ChanServ sets mode: +v techman8322:07
*** Kripton has quit IRC22:29
*** Kripton has joined #timvideos22:30
*** Lavos has joined #timvideos22:48
*** Lavos has quit IRC23:01
*** Lavos has joined #timvideos23:01
*** Lavos has quit IRC23:02
*** Lavos has joined #timvideos23:03
*** Lavos has quit IRC23:04
*** Lavos has joined #timvideos23:04
*** Lavos has joined #timvideos23:06
*** Lavos has joined #timvideos23:07
*** Lavos has quit IRC23:08
*** Lavos has joined #timvideos23:09
*** Lavos has quit IRC23:10
*** Lavos has joined #timvideos23:10
*** Lavos has joined #timvideos23:12
*** Lavos has joined #timvideos23:13
*** Lavos has quit IRC23:14
*** Lavos has joined #timvideos23:15
mithrotannewt: morning! Will look at what you have in a second23:15
mithrotannewt: Guess, it is time to add stall support23:31
tannewtDedicated setup buffer would clean up traces a bunch23:34
*** Kripton has quit IRC23:37

Generated by 2.13.1 by Marius Gedminas - find it at!