Edit #2: Aaaand it's solved:


echo 18d1 5014 > /sys/bus/usb-serial/drivers/generic/new_id


triggers creation of /dev/ttyUSB0 ... 5 , several of which spew console log...

Example spew on boot. (Looks like RK's UART..?)

Edit: apparently they're USB lines! When connected as D-/D+ through a USB B-connector, to a Linux box, we get a device that enumerates with this descriptor.

The Asus C101PA is supposedly able to bring out its UART via a specially-made USB-C cable.

Google's WWW offers a "WinAmp playlist"-style taunting mention of this magical cable, but no schematics or even any info whatsoever regarding pinout.

A few folks on the Net hint at the possible use in this device of something called "debug accessory mode", a feature of the USB-C standard.

So, looking at the standard:

It would appear that we have, at least, the "strapping" with which to trigger the desired "debug accessory mode."

And so, tying contacts "CC" and "VCON" (i.e. CC1 and CC2, per the standard, but go and figure this out...) to ground via 5.1K resistors:

Theoretically a UART should appear on SBU1 and SBU2 "side band" contacts given by the USB-C expander board.

And we plug this barbaric device into the C101PA (FWIW -- in "dev mode", though this should not make any difference whatsoever if the UART is indeed connected to the RK3399 CPU directly.)

But in actual practice -- no dice. Logic analyzer shows a burst of something vaguely UART-like on SBU1, but only when the plug is inserted (and not, e.g., on boot, which is where one actually needs the debug UART!) And this vaguely UART-like signal, is not Rockchip's 1500000-baud TTY (logic analyzer shows missing stop bits regardless of what baud rate is picked.) And throwing bytes into /dev/ttyS2 (Rockchip UART under the sad Chromebook linux) has no effect on SBU1/SBU2.

Nothing interesting happens on reset, either.

Dear reader, do you know the secret of Google's "Suzy-Q" (aka "Debug Accessory Mode") magic cable? If you do -- tell me!
(it's a USB UART! see top of page.)