Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised

[dima.pasechnik@cs.ox.ac.uk]

[-- Attachment #1: Type: text/plain, Size: 5444 bytes --]

On Mon, Dec 19, 2022 at 07:25:03PM +0100, Greg KH wrote:
[...]
> 
> That is only if you want to manually bind the generic driver to this
> device.  The kernel takes this and says "are you sure you want to do
> this, if so, email this address and talk to these developers" :)

One does need a dedicated /dev/ttyUSB. It is similar, but not
identical, to /dev/ttyACM. Cf. e.g.
https://rfc1149.net/blog/2013/03/05/what-is-the-difference-between-devttyusbx-and-devttyacmx/

And the board makes an effort to establish
a dedicated /dev/ttyUSB. Indeed, after I plugged the board in 21:35
and did "ls -l /dev/tty*" I saw

crw--w---- 1 root tty       4,  0 Dec 19 21:28 /dev/tty0
crw------- 1 dima tty       4,  1 Dec 19 21:35 /dev/tty1
crw--w---- 1 root tty       4, 10 Dec 19 21:28 /dev/tty10
crw--w---- 1 root tty       4, 11 Dec 19 21:28 /dev/tty11
...

- it's the Linux host that doesn't recognise this fact.
(it's not even seen in dmesg that something happened on /dev/tty1 -
probably a premature termination of something in the kernel)

Needless to say, there is also /dev/ttyACM0 popping up - so this part
of the communication is OK.

I think it's prudent that the kernel understands that it's a
a proper ttyUSB device, apparing as /dev/ttyUSB, and advertises it as
such. Without it, it's hard to detect it, and indeed, the only way I see
this,  without an active usbserial driver, is by the time shown next to 
/dev/tty*

> > > Unfortunately I can't easily tell you how it behaved without it,
> > > as it seems to be impossible to remove things there :-(
> > > https://unix.stackexchange.com/questions/463291/how-to-remove-device-id-from-manually-entered-usb-serial-driver
> > > Can it be wiped by reinstalling the kernel? I can do this...
> > 
> > OK, I removed the "new_id" by kernel reinstall, and
> > now all I get is the following:
> > 
> > [  176.427839] usb 1-3: new full-speed USB device number 5 using xhci_hcd
> > [  176.558808] usb 1-3: New USB device found, idVendor=0d28, idProduct=0204, bcdDevice=10.00
> > [  176.558825] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > [  176.558833] usb 1-3: Product: BBC micro:bit CMSIS-DAP
> > [  176.558839] usb 1-3: Manufacturer: Arm
> > [  176.558845] usb 1-3: SerialNumber: 9905360200052833525e24a702a68552000000006e052820
> > [  176.566864] hid-generic 0003:0D28:0204.0001: hiddev96,hidraw0: USB HID v1.00 Device [Arm BBC micro:bit CMSIS-DAP] on usb-0000:00:14.0-3/input3
> > [  177.727061] usb-storage 1-3:1.0: USB Mass Storage device detected
> > [  177.733180] scsi host0: usb-storage 1-3:1.0
> > [  177.733333] usbcore: registered new interface driver usb-storage
> > [  177.733607] cdc_acm 1-3:1.1: ttyACM0: USB ACM device
> > [  177.733646] usbcore: registered new interface driver cdc_acm
> > [  177.733648] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
> > [  177.739250] usbcore: registered new interface driver uas
> > [  178.752970] scsi 0:0:0:0: Direct-Access     MBED     VFS              0.1  PQ: 0 ANSI: 2
> > [  178.759252] sd 0:0:0:0: [sda] 131200 512-byte logical blocks: (67.2 MB/64.1 MiB)
> > [  178.759440] sd 0:0:0:0: [sda] Write Protect is off
> > [  178.759443] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
> > [  178.759611] sd 0:0:0:0: [sda] No Caching mode page found
> > [  178.759613] sd 0:0:0:0: [sda] Assuming drive cache: write through
> > [  178.769674]  sda:
> > [  178.769773] sd 0:0:0:0: [sda] Attached SCSI removable disk
> > 
> > As you see, no USB serial driver is loaded.
> > However, https://tech.microbit.org/software/daplink-interface/
> > tells you that there is a 2nd CPU on the board, aka "interface chip",
> > capable of UART.
> 
> And that would be the ttyACM0 device node, right?  Why not use just use that?
Actually, the "interface chip" is reponsible not only for ttyACM, but
for USB mass storage, and USB serial, all crammed in into the same
physical USB port.

ttyACM is a slightly different from serial USB device, understanding slightly different set
of commands. (as I wrote above)

An application might want to talk to the board on several virtual ports in
the same time, why not? If it's a real-time communication, say?

> > If I manually load the driver:
> > # insmod /lib/modules/6.0.8-gentoo-x86_64/kernel/drivers/usb/serial/usbserial.ko vendor=0x0d28 product=0x0204
> > and re-insert the USB connector, I see dmesg log as in my previous
> > message, and indeed, /dev/ttyUSB0 appears.
> 
> Yes, but does using that device node actually work?
> 
> > Well, perhaps, it's all supposed to work without a kernel module, hard
> > to say. It's however confusing that a /dev/tty1 (or some other number)
> > appears, but it's totally non-transparent that it is a USB connection
> > (no reflection of it in dmesg).
> 
> Again, try ttyACM0 and see if that works.

Yes, it does basic things, I can use web interface for
https://python.microbit.org/ to upload and run Python
(https://python.microbit.org/) programs on the board. I only know
Chromium talks to the board via webUSB (https://wicg.github.io/webusb/)
I don't know yet whether one can try several USB interfaces from it. 

I'll be teaching practicals to our 1st year CS students using these boards, they will tear me apart
in case I don't know the stuff. :-)
And not only practical bits, but theory as well.

Cheers,
Dima


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]