Page MenuHomeFreeBSD

ugensa: add support for Google Cr50 (GSC) Closed Case Debugging UART interfaces
Needs ReviewPublic

Authored by greg_unrelenting.technology on Tue, Oct 1, 7:38 PM.

Details

Reviewers
phk
hselasky
Group Reviewers
Contributor Reviews (base)
Summary

The Google Security Chip (its Cr50 firmware) on Chromebooks offers 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".

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

imp added inline comments.Wed, Oct 2, 3:04 AM
sys/dev/usb/serial/ugensa.c
216

I'd prefer a better comment here too.

217

This needs to be wrapped at 80 columns

244

I'd be quite interested to see what hps has to say about this...
But I kinda suspect we do need it at least for some devices (I know we need it for other devices I've messed with, but those werent gensa devices).

hselasky added inline comments.Wed, Oct 2, 8:50 PM
sys/dev/usb/serial/ugensa.c
244

USB BULK packets are transferred using a data toggle of 0 or 1. If there is a mismatch when you open the connection, then the first piece of data is lost. I recommend you leave these in. If the device does not support these, then this is an indication that the device is broken! Please add a quick for this.

hselasky added inline comments.Wed, Oct 2, 8:59 PM
sys/dev/usb/serial/ugensa.c
217

Code should look like this:

if (uaa->info.match_flag_int_subclass &&
<4spaces>iface->idesc->bInterfaceSubClass != uaa->info.bInterfaceSubClass)
<tab>continue;

Likely this Google device is not USB certified. FreeBSD has a usbtest in src under tools. And others have the command verifier:
https://www.usb.org/document-library/usb20cv-x64-bit-ver-15100

See sys/dev/usb/quirk * for info how to add a new quirk.

If you can use libusb that would be the best. We also have cuse (character device in user-space) and maybe a simple tool we can add to base to wrap any bulk endpoint into a character device is possible too.

greg_unrelenting.technology marked an inline comment as done.Thu, Oct 3, 9:17 AM

Likely this Google device is not USB certified

Yeah, it's a debug interface for developers, why would they bother.

The code on the device that complains about the thing is commented as /* Something we need to add support for? */ :D
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/tags/cr50_v4.5/chip/g/usb.c#835

sys/dev/usb/serial/ugensa.c
217

hmm, uaa->info is usbd_lookup_info, not usb_device_id

hselasky added inline comments.Thu, Oct 3, 9:24 AM
sys/dev/usb/serial/ugensa.c
217

My point is bInterfaceSubClass=0 is also valid. So you need some kind of additional flag for this, probably via the driver info.

Likely this Google device is not USB certified

Yeah, it's a debug interface for developers, why would they bother.
The code on the device that complains about the thing is commented as /* Something we need to add support for? */ :D
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/tags/cr50_v4.5/chip/g/usb.c#835

Would you mind poking these guys? Can the firmware for this device be upgraded?

--HPS