| *** tpb has joined #timvideos | 00:00 | |
| *** TheAssassin has quit IRC | 00:23 | |
| *** TheAssassin has joined #timvideos | 00:24 | |
| mithro | tannewt: Should I rebase my current valentyusb work on top of your latest develop branch? | 00:54 |
|---|---|---|
| tannewt | ya, I would. we're not quite that far with circuitpython but I think its improved | 00:55 |
| mithro | xobs / tannewt / tinyfpga / tmmmcci: What do you think the best way to detect a reset is? | 02:39 |
| xobs | mithro: does it matter? | 02:44 |
| mithro | xobs: What do you mean? | 02:44 |
| xobs | Though you could always treat a change in the "address" packet as a reset. | 02:45 |
| xobs | By that, I mean what problem are you trying to solve by looking for a reset? | 02:45 |
| mithro | xobs: 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 |
| xobs | It looks like a "reset" is an SE0 state for > 10ms. | 02:47 |
| xobs | But 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 |
| mithro | tannewt: 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 |
| mithro | tannewt: I have unittests which say this is true, so going to test on hardware now | 02:48 |
| xobs | The 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 |
| mithro | tannewt: This is what I'm currently getting; | 03:12 |
| mithro | https://www.irccloud.com/pastebin/eacX3nGZ/ | 03:12 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 03:12 |
| tannewt | mithro: busy at the moment. I may have time to look tomorrow or later tonight | 03:16 |
| mithro | tannewt: 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 |
| tannewt | do you have a dedicated buffer for it now? | 04:18 |
| mithro | tannewt: no | 04:20 |
| tannewt | is the dcd layer queueing up the receive? | 04:20 |
| mithro | tannewt: yes, but the host has already sent it by that time... | 04:21 |
| tannewt | right, thats why its better to have a dedicated buffer | 04:22 |
| tannewt | since you can get one at any time | 04:22 |
| mithro | tannewt: status packet -- not setup packet | 04:22 |
| tannewt | ah | 04:22 |
| tannewt | I'd think it'd be ok to nak it until ready | 04:23 |
| tannewt | only setup is really critical I think | 04:23 |
| mithro | Hrm... 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 dead | 04:30 |
| mithro | It scares me how easy it is to cause the USB host hardware to lock up... | 04:37 |
| xobs | mithro: is a state machine getting into a bad state? | 04:41 |
| mithro | Ahh ha! As a status packet never writes/reads data, it doesn't trigger the NAK path | 04:44 |
| *** rohitksingh has joined #timvideos | 04:57 | |
| mithro | tannewt: This is where I'm up too now | 06:03 |
| mithro | https://www.irccloud.com/pastebin/br8mbSxg/ | 06:03 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 06:03 |
| mithro | Seems to be dieing on a split descriptor transfer.... | 06:03 |
| mithro | tannewt: I think we are probably taking to long to respond | 06:10 |
| mithro | https://www.irccloud.com/pastebin/HofDBCYM/ | 06:11 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 06:11 |
| mithro | Getting a setup packet right after the descriptor | 06:11 |
| mithro | What descriptor would be 75 bytes long? | 06:14 |
| xobs | mithro: I seem to recall you need to respond very quickly. | 06:15 |
| tannewt | I doubt it’s a time thing. Data transfers are pretty forgiving | 06:17 |
| tannewt | As long as you nak | 06:17 |
| tannewt | The config descriptor could be that long | 06:18 |
| mithro | tannewt: See the decode above -- it gets the DATA1 and then the following up is a SETUP? | 06:19 |
| mithro | descriptor idx 0 ptr 2005a9e0 len 4b | 06:19 |
| mithro | start xfer d:i e:0 l:64 b:10000104 .. | 06:19 |
| mithro | dcd_poll ep0 in complete 64 | 06:19 |
| mithro | start xfer d:i e:0 l:11 b:10000104 .. | 06:19 |
| mithro | tinyusb was expecting to send 11 more bytes... | 06:19 |
| xobs | mithro: it's fine for the host to abort the transfer early. | 06:20 |
| tannewt | How many did the setup packet ask for? | 06:21 |
| mithro | usb_packet-1: DATA0 [ 80 06 00 02 00 00 09 00 ] | 06:22 |
| mithro | I think.... | 06:22 |
| mithro | ep0 out got setup g:8 w:8 80 6 0 2 0 0 9 0 | 06:23 |
| xobs | It's asking for the configuration descriptor, which could be long. | 06:25 |
| xobs | One thing to look out for -- is the endianness of wTotalLength correct? | 06:26 |
| mithro | I'm wondering that... | 06:28 |
| mithro | wireshark says the wLength should be 9 | 06:29 |
| tannewt | I had to swap one of the tusb things to support big endian when I was working on it | 06:31 |
| tannewt | mithro, are you going to be debugging for a while longer? I can probably go get setup | 06:34 |
| mithro | tannewt: Probably | 06:35 |
| xobs | mithro: that's just the maximum amount of data it'll request. | 06:35 |
| tannewt | kk, I'll head up | 06:36 |
| mithro | tannewt: Just pushed everything | 06:38 |
| tannewt | kk, getting into the env | 06:44 |
| tannewt | looks like its naking setup packets | 06:53 |
| tannewt | https://usercontent.irccloud-cdn.com/file/65a5Xpb3/Screen%20Shot%202018-12-08%20at%2010.47.03%20PM.png | 06:53 |
| tannewt | it was resilient to it though | 06:55 |
| mithro | tannewt: Did you rebuild the gateware? | 06:56 |
| tannewt | ah maybe not | 06:56 |
| tannewt | I skipped to make image I think | 06:56 |
| mithro | I think the issue is | 06:56 |
| mithro | len = ((tusb_desc_configuration_t const*) desc_data)->wTotalLength; | 06:56 |
| mithro | wireshark is telling me that the computer is expecting wLength==9, but tinyusb is saying it's 0x4b long... | 06:57 |
| tannewt | is it trying to send 0x4b though? | 06:57 |
| tannewt | it should cap at the packet limit | 06:58 |
| mithro | It is trying to send a 64 byte packet, followed by a 11 byte packet... | 06:58 |
| tannewt | yup, I see what you are seeing | 07:02 |
| tannewt | yup, looks like a bug | 07:06 |
| mithro | tannewt: where is the bug? :-P | 07:06 |
| tannewt | it works ok in circuitpython, let me dig into the history | 07:07 |
| tannewt | its an endian issue | 07:16 |
| tannewt | the length in the setup struct is wrong so its not capping the descriptor lengh | 07:16 |
| mithro | tannewt: Fix? | 07:17 |
| tannewt | fix it when we queue the setup packet | 07:17 |
| tannewt | or do we need to change the struct definition? | 07:19 |
| mithro | tannewt: not sure... | 07:20 |
| tannewt | looks like usb is little endian over the wire | 07:20 |
| tannewt | are we stuck with an lm32? | 07:21 |
| xobs | I think it would be best to use tole16() and friends in endian.h | 07:22 |
| tannewt | https://github.com/libopencm3/libopencm3/issues/478 | 07:22 |
| tpb | Title: USB: setup packet endianness · Issue #478 · libopencm3/libopencm3 · GitHub (at github.com) | 07:22 |
| tannewt | that makes it way more complicated because you need to do that for every field in the usb structures | 07:23 |
| xobs | If the structures don't change, another option is to hardcode the descriptors as uint8_t[] | 07:25 |
| tannewt | its not the descriptors I'm worried about its all of the protocol messages that worry me | 07:27 |
| mithro | I wonder if we can just use __attribute__ ((scalar_storage_order="littleendian")) | 07:27 |
| tannewt | could try it | 07:27 |
| mithro | tannewt: Where is the correct place? | 07:29 |
| tannewt | src/common/tusb_types.h I think | 07:29 |
| tannewt | https://www.irccloud.com/pastebin/eXzlNh0L/ | 07:30 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 07:30 |
| mithro | tannewt: Needs to be __attribute__((scalar_storage_order("little-endian"),packed)) | 07:31 |
| tannewt | k, now I think its hitting my previous fixes and breaking | 07:33 |
| mithro | I'm getting | 07:33 |
| mithro | <artificial>:(.text.startup.main+0x2bc): undefined reference to `__bswapsi2' | 07:33 |
| tannewt | it built for me | 07:34 |
| tannewt | https://www.irccloud.com/pastebin/CHqRCc6H/ | 07:34 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 07:34 |
| tannewt | wrong setup value now | 07:34 |
| mithro | tannewt: I wonder why you are not getting the error I am? | 07:37 |
| tannewt | ya, weird | 07:37 |
| xobs | sounds like you're using different libc.a files | 07:37 |
| xobs | Actually, __bswapsi2 sounds more like libgcc.a | 07:38 |
| tannewt | tinyusb is commit c5bd7b1c26f141a6ed768e48553ea3aa9d00da04 | 07:39 |
| tannewt | its getting further but the trace is really noisy from not acking the setup packed | 07:39 |
| tannewt | https://www.irccloud.com/pastebin/jnN4pEyJ/ | 07:40 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 07:40 |
| mithro | Yeah looks like | 07:41 |
| tannewt | I think it may have enumerated | 07:42 |
| tannewt | I'm on Arch linux which might change things too | 07:44 |
| tannewt | hrm, got it now actually | 07:45 |
| tannewt | when I tried to change everything | 07:45 |
| tannewt | undefined reference to `__bswapsi2' | 07:45 |
| mithro | tannewt: do a "conda install gcc-lm32-elf-newlib" | 07:46 |
| mithro | tannewt: Then add a -lgcc to hw/bsp/valentyusb/board.mk | 07:46 |
| tannewt | kk | 07:47 |
| mithro | Hrm, my tinyusb is failing on reading.... | 07:48 |
| tannewt | undo the little endian change in tusb_common.h | 07:48 |
| tannewt | the call is uses to extract the high and low bytes | 07:49 |
| mithro | I think I may have run out of spi flash space? | 08:01 |
| mithro | https://www.irccloud.com/pastebin/ilxKQtIg/ | 08:02 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 08:02 |
| tannewt | what did you change? | 08:03 |
| mithro | tannewt: I added the -lgcc apparently... | 08:03 |
| tannewt | ah, I didn't need to add it | 08:03 |
| mithro | tannewt: Which structures did you add the attribute too? | 08:04 |
| tannewt | all of them by changing ATTR_PACKED macro to include it | 08:05 |
| mithro | oh, how did you get past the __bswapsi2 issue? | 08:05 |
| tannewt | I installed the lib you said but didn't add -lgcc | 08:05 |
| mithro | tannewt: Can you commit and push your version? | 08:06 |
| tannewt | sure | 08:07 |
| mithro | Also tell me how big your Firmware section is? | 08:07 |
| tannewt | https://github.com/tannewt/tinyusb/tree/endian | 08:09 |
| tpb | Title: GitHub - tannewt/tinyusb at endian (at github.com) | 08:09 |
| tannewt | https://www.irccloud.com/pastebin/XYgwH0Qq/ | 08:09 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 08:09 |
| mithro | Hrm... I'm less smaller? | 08:10 |
| tannewt | weird that our toolchains seem different | 08:14 |
| mithro | tannewt: Nope, getting the same now I have your version | 08:14 |
| mithro | and its programming fine again.... | 08:14 |
| tannewt | k, perfect | 08:14 |
| mithro | https://www.irccloud.com/pastebin/uIZ9ahI0/ | 08:15 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 08:15 |
| tannewt | I think the string descriptors are broken | 08:15 |
| xobs | "config index 0 descriptor too short (expected 19200, got 75)" Endianness sucks | 08:15 |
| mithro | yeap | 08:16 |
| xobs | Still, almost there! | 08:16 |
| * tannewt flips table and will do it myself | 08:18 | |
| tannewt | s/myself/himself | 08:18 |
| tannewt | or not :-) | 08:20 |
| *** rohitksingh has quit IRC | 08:24 | |
| *** rohitksingh has joined #timvideos | 08:24 | |
| mithro | tannewt: That is with your version of the code.... | 08:28 |
| tannewt | what do you mean? | 08:29 |
| mithro | tannewt: The enumeration above with the length error | 08:29 |
| tannewt | ah | 08:30 |
| tannewt | I bet its similar to the problem with string descriptors | 08:30 |
| tannewt | the macro that gens it places the first bytes wrong | 08:31 |
| tannewt | https://www.irccloud.com/pastebin/3wK2bM47/ | 08:31 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 08:31 |
| tannewt | it'd be way easier to use this on a little endian core | 08:32 |
| mithro | tannewt: Why is it doing that? | 08:34 |
| tannewt | doing what? | 08:34 |
| mithro | tannewt: Mundging things into a uint8_t ? | 08:35 |
| tannewt | that bit is an array of uint16_t because thats how strings are encoded | 08:35 |
| xobs | tannewt: why isn't it treating it as a uint8_t instead of casting it to a uint16_t? | 08:37 |
| mithro | In theory we could just apply the attribute to that array | 08:37 |
| mithro | char stack[10000] __attribute__ ((section ("STACK"))) = { 0 }; | 08:39 |
| mithro | But I can't figure out how to apply that inside your macro | 08:40 |
| tannewt | please stop saying its "your" code. its not mine. I did not write it. its open source its as much mine as it is yours | 08:41 |
| mithro | const uint16_t __attribute__((scalar_storage_order("little-endian"))) [] | 08:42 |
| mithro | well, I'm giving up for the night | 08:48 |
| xobs | mithro: where is your repo? | 08:48 |
| mithro | https://github.com/mithro/litex-buildenv/tree/tinyusb-work | 08:48 |
| tpb | Title: GitHub - mithro/litex-buildenv at tinyusb-work (at github.com) | 08:48 |
| mithro | export PLATFORM=tinyfpga_bx CPU_VARIANT=lite TARGET=usb FIRMWARE=tinyusb | 08:49 |
| mithro | mkdir -p build/tinyfpga_bx_usb_lm32.lite//software/tinyusb/ | 08:49 |
| mithro | ln -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.bin | 08:49 |
| xobs | Thanks. 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=valentyusb | 08:50 |
| mithro | xobs: Currently only testing on the tinyfpga_bx | 08:50 |
| xobs | I see. More luts. | 08:51 |
| mithro | xobs: But no SPRAM | 08:51 |
| tannewt | could we use a little endian core instead? | 09:03 |
| tannewt | all of the multi-byte descriptor values are backwards | 09:04 |
| tannewt | ok, I got the descriptor correct | 09:47 |
| tannewt | my ATTR_PACKED changed was wrong it was the wrong attribute name | 09:47 |
| tannewt | I pushed to https://github.com/tannewt/tinyusb/tree/endian | 09:47 |
| tpb | Title: GitHub - tannewt/tinyusb at endian (at github.com) | 09:47 |
| tannewt | it gets to where linux requests the high speed descriptor and tinyusb tries to respond with a stall | 09:48 |
| tannewt | ok, got it past the stall by queueing another setup rx | 10:13 |
| tannewt | I think its failing in the cdc layer | 10:13 |
| tannewt | and the string descriptor endianness is wrong too | 10:13 |
| tannewt | bedtime for me | 10:13 |
| tannewt | (well past it) | 10:14 |
| *** rohitksingh has quit IRC | 12:20 | |
| *** sb0_ has joined #timvideos | 15:22 | |
| tmmmcci | Looks like good progress, sorry, was head down on something else. | 15:46 |
| *** rohitksingh has joined #timvideos | 17:07 | |
| *** rohitksingh has quit IRC | 17:19 | |
| *** techman83 has quit IRC | 22:06 | |
| *** techman83 has joined #timvideos | 22:07 | |
| *** ChanServ sets mode: +v techman83 | 22:07 | |
| *** Kripton has quit IRC | 22:29 | |
| *** Kripton has joined #timvideos | 22:30 | |
| *** Lavos has joined #timvideos | 22:48 | |
| *** Lavos has quit IRC | 23:01 | |
| *** Lavos has joined #timvideos | 23:01 | |
| *** Lavos has quit IRC | 23:02 | |
| *** Lavos has joined #timvideos | 23:03 | |
| *** Lavos has quit IRC | 23:04 | |
| *** Lavos has joined #timvideos | 23:04 | |
| *** Lavos has joined #timvideos | 23:06 | |
| *** Lavos has joined #timvideos | 23:07 | |
| *** Lavos has quit IRC | 23:08 | |
| *** Lavos has joined #timvideos | 23:09 | |
| *** Lavos has quit IRC | 23:10 | |
| *** Lavos has joined #timvideos | 23:10 | |
| *** Lavos has joined #timvideos | 23:12 | |
| *** Lavos has joined #timvideos | 23:13 | |
| *** Lavos has quit IRC | 23:14 | |
| *** Lavos has joined #timvideos | 23:15 | |
| mithro | tannewt: morning! Will look at what you have in a second | 23:15 |
| mithro | tannewt: Guess, it is time to add stall support | 23:31 |
| tannewt | Dedicated setup buffer would clean up traces a bunch | 23:34 |
| *** Kripton has quit IRC | 23:37 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
