applet: explore ideas for testing usb 2.0 data with Glasgow

[TomKeddie]

applet: explore ideas for testing usb 2.0 data with Glasgow

[whitequark]

I understand that this is frustrating but unless explicitly limited, open source tends to creep in scope until the maintainers fold. I will preventively limit the scope to avoid that. I think I made the board easily hackable for anyone who wants to do that with the understanding that they are completely on their own.

[whitequark]

To keep my workload as a maintainer manageable I would strongly prefer to avoid supporting any third party frameworks on Glasgow hardware even if it is something as nice as Luna. I will close this issue because of this.

[TomKeddie]

Thanks @whitequark I was expecting this kind of thing would come to Glasgow with support for external applets, we not expecting this to be in tree. I understand your need to stay focussed. I have some more stuff to document that I'd like to add here (if you don't mind). If nothing else, to aid someone in the future that might want to build usb test on Glasgow.

[TomKeddie]

Not frustrated, a good call on your part I think.

[whitequark]

The LVDS bank in particular is essentially something that exists because @marcan didn't want any FPGA I/O to go to waste. It is not even going to be 100% tested (I think, this might not be final) and it will go away in future revs.

[TomKeddie]

Agreed, I used lvds as a PoC for the logic and nothing else. My next comment was to be about resolving whether this is possible for the test interface. I'm not sure it is. Measuring the latency on the direction change would be valuable to other protocols I feel, this was where I was headed.

[TomKeddie]

(am leaving this here for future explorers).

The real challenge for driving the usb data lines directly with the glasgow test interface will be the direction control on the level converters. I've modified luna to wire out the direction control to pins and used them to drive the test interface (A[0:2]) with this change to the platform definition.

        DirectUSBResource(0, d_p="A1", d_n="A2", pullup="B3", d_p_oe="C7", d_n_oe="C8", attrs=Attrs(IO_STANDARD="SB_LVCMOS33")

There are signs of life but it's not clean. The messages are corrupt are the enumeration fails.

[788582.485186] usb 2-4.7.4: new high-speed USB device number 79 using ehci-pci
[788582.593700] usb 2-4.7.4: New USB device found, idVendor=03fd, idProduct=000f, bcdDevice= 0.00
[788582.593704] usb 2-4.7.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0

[rwhitby]

This is all good for me to hear and understand. I was contemplating putting D+/D- switchable pull-up/down on the Glasgow USB-PD board I'm designing (https://github.com/rwhitby/glasgow-addons/tree/usbp-pd-addon/hardware/usb-pd-addon) but this discussion is now dampening that contemplation and pushing me towards just making the USB-PD board easily connectable to a supported Luna board (Glasgow/USB-PD handles the USB-PD side, Luna handles the USB data side).