Change Details

The Google Security Chip (its Cr50 firmware) on Chromebooks offers [[ https://chromium.googlesource.com/chromiumos/platform/ec/+/master/docs/case_closed_debugging_cr50.md | Closed Case Debugging ]] via a special USB cable. usbconfig looks like: P326 The UARTs on this device are handled in Linux by `usb-serial-simple`. The simplest of the USB serial drivers on FreeBSD seems to be `ugensa`, and searching on the internet confirms that it's supposed to be generic (though sadly there's no description in the tree, even digging through git log for that file does not reveal anything interesting). Unfortunately, at first I was stuck with the device resetting itself as soon as I opened the serial port. I've spent a whole evening wondering what the hell was wrong (looking at the bus in Wireshark and only finding a `URB_COMPLETE` `Cancelled` packet). Then I wrote a Python script using py36-libusb1 that simply reads the bulk endpoint… and I saw the expected console output. Looking more carefully at what was "not simple" in ugensa revealed the "clear stall at first run" block, which turned out to be the culprit. --- - is the clear stall thing needed for any actual devices? Clearly, Linux does not do this in the "simple" generic serial driver… maybe it should be a quirk of the devices that need it? - maybe the device description should be set to something generic? currently it picks up the string for the first of the serial ports: ``` ugensa0: <Shell> on usbus0 ugensa0: Found 3 serial ports. ``` but "Shell" does not apply to the whole device, it applies to the first port `cuaU0.0`, while `cuaU0.1` is "AP" and `cuaU0.2` is "EC".

The Google Security Chip (its Cr50 firmware) on Chromebooks offers [[ https://chromium.googlesource.com/chromiumos/platform/ec/+/master/docs/case_closed_debugging_cr50.md | Closed Case Debugging ]] via a special USB cable. usbconfig looks like: P326 The UARTs on this device are handled in Linux by `usb-serial-simple`. The simplest of the USB serial drivers on FreeBSD seems to be `ugensa`, and searching on the internet confirms that it's supposed to be generic (though sadly there's no description in the tree, even digging through git log for that file does not reveal anything interesting). ~~Unfortunately, at first I was stuck with the device resetting itself as soon as I opened the serial port. I've spent a whole evening wondering what the hell was wrong (looking at the bus in Wireshark and only finding a `URB_COMPLETE` `Cancelled` packet). Then I wrote a Python script using py36-libusb1 that simply reads the bulk endpoint… and I saw the expected console output. Looking more carefully at what was "not simple" in ugensa revealed the "clear stall at first run" block, which turned out to be the culprit.~~ There was a bug in this device, but it was fixed in firmware 0.3.24. --- maybe the device description should be set to something generic? currently it picks up the string for the first of the serial ports: ``` ugensa0: <Shell> on usbus0 ugensa0: Found 3 serial ports. ``` but "Shell" does not apply to the whole device, it applies to the first port `cuaU0.0`, while `cuaU0.1` is "AP" and `cuaU0.2` is "EC".

The Google Security Chip (its Cr50 firmware) on Chromebooks offers [[ https://chromium.googlesource.com/chromiumos/platform/ec/+/master/docs/case_closed_debugging_cr50.md | Closed Case Debugging ]] via a special USB cable. usbconfig looks like: P326 The UARTs on this device are handled in Linux by `usb-serial-simple`. The simplest of the USB serial drivers on FreeBSD seems to be `ugensa`, and searching on the internet confirms that it's supposed to be generic (though sadly there's no description in the tree, even digging through git log for that file does not reveal anything interesting). ~~Unfortunately, at first I was stuck with the device resetting itself as soon as I opened the serial port. I've spent a whole evening wondering what the hell was wrong (looking at the bus in Wireshark and only finding a `URB_COMPLETE` `Cancelled` packet). Then I wrote a Python script using py36-libusb1 that simply reads the bulk endpoint… and I saw the expected console output. Looking more carefully at what was "not simple" in ugensa revealed the "clear stall at first run" block, which turned out to be the culprit.~~ There was a bug in this device, but it was fixed in firmware 0.3.24. --- - is the clear stall thing needed for any actual devices? Clearly, Linux does not do this in the "simple" generic serial driver… maybe it should be a quirk of the devices that need it? - maybe the device description should be set to something generic? currently it picks up the string for the first of the serial ports: ``` ugensa0: <Shell> on usbus0 ugensa0: Found 3 serial ports. ``` but "Shell" does not apply to the whole device, it applies to the first port `cuaU0.0`, while `cuaU0.1` is "AP" and `cuaU0.2` is "EC".