On Mon, Dec 19, 2022 at 06:10:51PM +0000, dima.pasechnik@xxxxxxxxxxx wrote: > On Mon, Dec 19, 2022 at 04:29:34PM +0000, dima.pasechnik@xxxxxxxxxxx wrote: > > On Mon, Dec 19, 2022 at 04:00:29PM +0100, Greg KH wrote: > > > On Mon, Dec 19, 2022 at 12:57:43PM +0000, dima.pasechnik@xxxxxxxxxxx wrote: > > > > this is a popular in UK education board: https://microbit.org/ > > > > - the currently sold (Version 2) one. It does on the same USB 3 things: > > > > mass storage, ACM, and serial. Serial appears unknown to the kernel. > > > > > > > > With Linux kernel 6.0.8 on x86_54, and various USB serial drivers installed, upon plugging into USB > > > > port, I see in dmesg: > > > > > > > > [45460.035306] usb 1-3: new full-speed USB device number 10 using xhci_hcd > > > > [45460.166959] usb 1-3: New USB device found, idVendor=0d28, idProduct=0204, bcdDevice=10.00 > > > > [45460.166965] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > > > > [45460.166967] usb 1-3: Product: BBC micro:bit CMSIS-DAP > > > > [45460.166968] usb 1-3: Manufacturer: Arm > > > > [45460.166970] usb 1-3: SerialNumber: 9905360200052833525e24a702a68552000000006e052820 > > > > [45460.172168] usb-storage 1-3:1.0: USB Mass Storage device detected > > > > [45460.172538] scsi host1: usb-storage 1-3:1.0 > > > > [45460.173203] cdc_acm 1-3:1.1: ttyACM0: USB ACM device > > > > [45460.175258] hid-generic 0003:0D28:0204.0005: hiddev96,hidraw0: USB HID v1.00 Device [Arm BBC micro:bit CMSIS-DAP] on usb-0000:00:14.0-3/input3 > > > > [45460.175581] usbserial_generic 1-3:1.4: The "generic" usb-serial driver is only for testing and one-off prototypes. > > > > [45460.175585] usbserial_generic 1-3:1.4: Tell linux-usb@xxxxxxxxxxxxxxx to add your device to a proper driver. > > > > [45460.175587] usbserial_generic 1-3:1.4: device has no bulk endpoints > > > > [45460.175818] usbserial_generic 1-3:1.5: The "generic" usb-serial driver is only for testing and one-off prototypes. > > > > [45460.175821] usbserial_generic 1-3:1.5: Tell linux-usb@xxxxxxxxxxxxxxx to add your device to a proper driver. > > > > [45460.175823] usbserial_generic 1-3:1.5: generic converter detected > > > > > > Is there some script adding this device id to the generic driver such > > > that you are binding to this device? Did the script come with the > > > device? > > > > It didn't bind to a /dev/ttyUSB* device, even if I manually loaded the corresponding modules. > > Then I read somewhere I had to do > > > > echo 0d28 0204 >/sys/bus/usb-serial/drivers/generic/new_id > > > > (the numbers there are VID and PID of the board) > > to make it recognisible by the driver. 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" :) > > 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? > 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. thanks, greg k-h
