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

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

[dima.pasechnik]

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

Hello,

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@vger.kernel.org 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@vger.kernel.org to add your device to a proper driver.
[45460.175823] usbserial_generic 1-3:1.5: generic converter detected
[45460.175905] usb 1-3: generic converter now attached to ttyUSB0
[45461.175731] scsi 1:0:0:0: Direct-Access     MBED     VFS              0.1  PQ: 0 ANSI: 2
[45461.176279] sd 1:0:0:0: [sdb] 131200 512-byte logical blocks: (67.2 MB/64.1 MiB)
[45461.176480] sd 1:0:0:0: [sdb] Write Protect is off
[45461.176484] sd 1:0:0:0: [sdb] Mode Sense: 03 00 00 00
[45461.176659] sd 1:0:0:0: [sdb] No Caching mode page found
[45461.176661] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[45461.186409]  sdb:
[45461.186439] sd 1:0:0:0: [sdb] Attached SCSI removable disk

Best regards,
Dmitrii
www.pasechnik.info

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

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

[Greg KH]

On Mon, Dec 19, 2022 at 12:57:43PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> Hello,
> 
> 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@vger.kernel.org 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@vger.kernel.org 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?

How well does it work?  Why did the developer choose to use this generic
driver instead of a real one?

> [45460.175905] usb 1-3: generic converter now attached to ttyUSB0

It is not unknown, seems to bind here, but does it work?

thanks,

greg k-h

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

[dima.pasechnik]

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

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@cs.ox.ac.uk 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@vger.kernel.org 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@vger.kernel.org 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.

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...

> How well does it work?  Why did the developer choose to use this generic
> driver instead of a real one?
I don't know, I followed the advice in dmesg, which sounds as if it's
not a "real" driver.

Best,
Dmitrii
> 
> > [45460.175905] usb 1-3: generic converter now attached to ttyUSB0
> 
> It is not unknown, seems to bind here, but does it work?
> 
> thanks,
> 
> greg k-h

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

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

[dima.pasechnik]

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

On Mon, Dec 19, 2022 at 04:29:34PM +0000, dima.pasechnik@cs.ox.ac.uk 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@cs.ox.ac.uk 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@vger.kernel.org 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@vger.kernel.org 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.
> 
> 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.

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.

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).

HTH
Dmitrii


> 
> > How well does it work?  Why did the developer choose to use this generic
> > driver instead of a real one?
> I don't know, I followed the advice in dmesg, which sounds as if it's
> not a "real" driver.
> 
> Best,
> Dmitrii
> > 
> > > [45460.175905] usb 1-3: generic converter now attached to ttyUSB0
> > 
> > It is not unknown, seems to bind here, but does it work?
> > 
> > thanks,
> > 
> > greg k-h



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

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

[Greg KH]

On Mon, Dec 19, 2022 at 06:10:51PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> On Mon, Dec 19, 2022 at 04:29:34PM +0000, dima.pasechnik@cs.ox.ac.uk 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@cs.ox.ac.uk 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@vger.kernel.org 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@vger.kernel.org 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

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

[dima.pasechnik]

[-- 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 --]

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

[Alan Stern]

On Mon, Dec 19, 2022 at 10:20:48PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> 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*

It might help if you post the output of "lsusb -v" for this device.

Alan Stern

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

[dima.pasechnik]

[-- Attachment #1.1: Type: text/plain, Size: 400 bytes --]

On Mon, Dec 19, 2022 at 06:36:47PM -0500, Alan Stern wrote:
> 
> It might help if you post the output of "lsusb -v" for this device.
Please see attached; I also attached the output for an older version of
this board (V1). The one we talk about is V2. Both versions have the
same VID, and, weirdly, the same PID (internally they aren't binary
compatible, even)

HTH
Dima

> 
> Alan Stern

[-- Attachment #1.2: current board (v2) --]
[-- Type: text/plain, Size: 8708 bytes --]

Bus 001 Device 009: ID 0d28:0204 NXP ARM mbed
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x0d28 NXP
  idProduct          0x0204 ARM mbed
  bcdDevice           10.00
  iManufacturer           1 Arm
  iProduct                2 BBC micro:bit CMSIS-DAP
  iSerial                 3 9905360200052833525e24a702a68552000000006e052820
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x00a2
    bNumInterfaces          6
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              8 USB_MSC
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         1
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               4 mbed Serial Port
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              4 mbed Serial Port
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          2
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        1
        bSlaveInterface         2 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              5 mbed Serial Port
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              6 CMSIS-DAP v1
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      33
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      3 
      bInterfaceProtocol      0 
      iInterface              7 WebUSB: CMSIS-DAP
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        5
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              9 CMSIS-DAP v2
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0039
  bNumDeviceCaps          2
  Platform Device Capability:
    bLength                24
    bDescriptorType        16
    bDevCapabilityType      5
    bReserved               0
    PlatformCapabilityUUID    {3408b638-09a9-47a0-8bfd-a0768815b665}
      WebUSB:
        bcdVersion    1.00
        bVendorCode     33
        iLandingPage     0 
  Platform Device Capability:
    bLength                28
    bDescriptorType        16
    bDevCapabilityType      5
    bReserved               0
    PlatformCapabilityUUID    {d8dd60df-4589-4cc7-9cd2-659d9e648a9f}
    CapabilityData[0]    0x00
    CapabilityData[1]    0x00
    CapabilityData[2]    0x03
    CapabilityData[3]    0x06
    CapabilityData[4]    0x4a
    CapabilityData[5]    0x01
    CapabilityData[6]    0x20
    CapabilityData[7]    0x00
Device Status:     0x0000
  (Bus Powered)

[-- Attachment #1.3: old board (v1) --]
[-- Type: text/plain, Size: 7577 bytes --]

Bus 001 Device 010: ID 0d28:0204 NXP ARM mbed
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x0d28 NXP
  idProduct          0x0204 ARM mbed
  bcdDevice           10.00
  iManufacturer           1 ARM
  iProduct                2 BBC micro:bit CMSIS-DAP
  iSerial                 3 9901000051114e45005f80130000004e0000000097969901
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x008b
    bNumInterfaces          5
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              8 USB_MSC
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         1
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               4 mbed Serial Port
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              4 mbed Serial Port
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          2
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        1
        bSlaveInterface         2 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              5 mbed Serial Port
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              6 CMSIS-DAP
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      33
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      3 
      bInterfaceProtocol      0 
      iInterface              7 WebUSB: CMSIS-DAP
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0039
  bNumDeviceCaps          2
  Platform Device Capability:
    bLength                24
    bDescriptorType        16
    bDevCapabilityType      5
    bReserved               0
    PlatformCapabilityUUID    {3408b638-09a9-47a0-8bfd-a0768815b665}
      WebUSB:
        bcdVersion    1.00
        bVendorCode     33
        iLandingPage     0 
  Platform Device Capability:
    bLength                28
    bDescriptorType        16
    bDevCapabilityType      5
    bReserved               0
    PlatformCapabilityUUID    {d8dd60df-4589-4cc7-9cd2-659d9e648a9f}
    CapabilityData[0]    0x00
    CapabilityData[1]    0x00
    CapabilityData[2]    0x03
    CapabilityData[3]    0x06
    CapabilityData[4]    0xaa
    CapabilityData[5]    0x00
    CapabilityData[6]    0x20
    CapabilityData[7]    0x00
Device Status:     0x0000
  (Bus Powered)

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

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

[Greg KH]

On Tue, Dec 20, 2022 at 01:08:59PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> On Mon, Dec 19, 2022 at 06:36:47PM -0500, Alan Stern wrote:
> > 
> > It might help if you post the output of "lsusb -v" for this device.
> Please see attached; I also attached the output for an older version of
> this board (V1). The one we talk about is V2. Both versions have the
> same VID, and, weirdly, the same PID (internally they aren't binary
> compatible, even)

That's horrible, someone should talk to the vendor here and get them to
at least bump the device id.

Anyway, I don't see a "serial" device here, just use the cdc-acm driver
and all should be ok, right?  Is there any missing functionality that
you feel is required that only the usb-serial api can provide?

thanks,

greg k-h

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

[dima.pasechnik]

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

On Fri, Dec 23, 2022 at 03:50:26PM +0100, Greg KH wrote:
> On Tue, Dec 20, 2022 at 01:08:59PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> > On Mon, Dec 19, 2022 at 06:36:47PM -0500, Alan Stern wrote:
> > > 
> > > It might help if you post the output of "lsusb -v" for this device.
> > Please see attached; I also attached the output for an older version of
> > this board (V1). The one we talk about is V2. Both versions have the
> > same VID, and, weirdly, the same PID (internally they aren't binary
> > compatible, even)
> 
> That's horrible, someone should talk to the vendor here and get them to
> at least bump the device id.

The vendor is ARM (https://www.arm.com/) - I guess Linux Foundation is a good "someone"
to talk to the vendor in this case.

Can PID be bumped up by a firmware update?


> 
> Anyway, I don't see a "serial" device here, just use the cdc-acm driver
> and all should be ok, right?  Is there any missing functionality that
> you feel is required that only the usb-serial api can provide?
Not at this point, no. Perhaps I'll resurrect this if I find something
out.

Best,
Dmitrii

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

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

[Greg KH]

On Fri, Dec 23, 2022 at 11:51:48PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> On Fri, Dec 23, 2022 at 03:50:26PM +0100, Greg KH wrote:
> > On Tue, Dec 20, 2022 at 01:08:59PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> > > On Mon, Dec 19, 2022 at 06:36:47PM -0500, Alan Stern wrote:
> > > > 
> > > > It might help if you post the output of "lsusb -v" for this device.
> > > Please see attached; I also attached the output for an older version of
> > > this board (V1). The one we talk about is V2. Both versions have the
> > > same VID, and, weirdly, the same PID (internally they aren't binary
> > > compatible, even)
> > 
> > That's horrible, someone should talk to the vendor here and get them to
> > at least bump the device id.
> 
> The vendor is ARM (https://www.arm.com/) - I guess Linux Foundation is a good "someone"
> to talk to the vendor in this case.

I do not understand here, are you asking me to talk to someone?  If so,
great, who?  If not, who are you asking?

> Can PID be bumped up by a firmware update?

Depends on how the hardware was designed.  Most can, some can not.  Is
the hardware design and firmware source available anywhere?

thanks,

greg k-h

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

[dima.pasechnik]

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

On Sat, Dec 24, 2022 at 07:53:54AM +0100, Greg KH wrote:
> On Fri, Dec 23, 2022 at 11:51:48PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> > On Fri, Dec 23, 2022 at 03:50:26PM +0100, Greg KH wrote:
> > > On Tue, Dec 20, 2022 at 01:08:59PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> > > > On Mon, Dec 19, 2022 at 06:36:47PM -0500, Alan Stern wrote:
> > > > > 
> > > > > It might help if you post the output of "lsusb -v" for this device.
> > > > Please see attached; I also attached the output for an older version of
> > > > this board (V1). The one we talk about is V2. Both versions have the
> > > > same VID, and, weirdly, the same PID (internally they aren't binary
> > > > compatible, even)
> > > 
> > > That's horrible, someone should talk to the vendor here and get them to
> > > at least bump the device id.
> > 
> > The vendor is ARM (https://www.arm.com/) - I guess Linux Foundation is a good "someone"
> > to talk to the vendor in this case.
> 
> I do not understand here, are you asking me to talk to someone?  If so,
> great, who?  If not, who are you asking?
> 
> > Can PID be bumped up by a firmware update?
> 
> Depends on how the hardware was designed.  Most can, some can not.  Is
> the hardware design and firmware source available anywhere?
As far I know, firmware comes from
https://tech.microbit.org/software/runtime/

As to why these V1 and V2 happened to get the same product ID, perhaps
my colleague Mike, in CC, who teaches a course using this board,  knows more.

Cheers
Dima

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

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

[Mike Spivey]

Not seeing all of the discussion, I'm not sure what the underlying 
problem might be.  So just a few remarks that might be helpful, given 
what I can recall during Christmas in deepest Yorkshire.

-- Mike

(i) I'm sure the identical USB id's are deliberate; the intention is 
that higher-level tools will assemble version-independent binaries that 
can be uploaded to either device in the same way. Dima and I are 
preparing lower-level programs that will only work on one board or the 
other -- actually, if things go according to plan, we will use only the 
V1 board this year.  You could get in touch with the micro:bit 
foundation, but they won't change this.

(ii) I don't believe I've had any difficulty communicating with either 
board using recent versions of PyOCD, given an appropriate udev rule -- 
the same rule for both devices.  I think PyOCD probes for the processor 
it is talking to -- nRF51 or nRF52 -- or you can tell it on the comand line.

(iii) The micro:bit is what I call a two-chip eval board, with the 
target processor running arbitrary code on the bare metal, and a 
separate serial/programming/debugging chip that runs firmware that is 
usually not changed.  That's in contrast to the kind of one-chip board 
where the target processor has some kind of USB-based bootloader on it.  
The separate chip on the micro:bit is a Freescale KL25, I believe, and a 
bit more powerful than the nRF51 target chip on the V1.  I believe the 
firmware is open source and can be replaced through some kind of 
bootstrap ritual -- perhaps involving pressing the reset button while 
plugging in the device.

On 25/12/2022 11:08, dima.pasechnik@cs.ox.ac.uk wrote:
> On Sat, Dec 24, 2022 at 07:53:54AM +0100, Greg KH wrote:
>> On Fri, Dec 23, 2022 at 11:51:48PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
>>> On Fri, Dec 23, 2022 at 03:50:26PM +0100, Greg KH wrote:
>>>> On Tue, Dec 20, 2022 at 01:08:59PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
>>>>> On Mon, Dec 19, 2022 at 06:36:47PM -0500, Alan Stern wrote:
>>>>>> It might help if you post the output of "lsusb -v" for this device.
>>>>> Please see attached; I also attached the output for an older version of
>>>>> this board (V1). The one we talk about is V2. Both versions have the
>>>>> same VID, and, weirdly, the same PID (internally they aren't binary
>>>>> compatible, even)
>>>> That's horrible, someone should talk to the vendor here and get them to
>>>> at least bump the device id.
>>> The vendor is ARM (https://www.arm.com/) - I guess Linux Foundation is a good "someone"
>>> to talk to the vendor in this case.
>> I do not understand here, are you asking me to talk to someone?  If so,
>> great, who?  If not, who are you asking?
>>
>>> Can PID be bumped up by a firmware update?
>> Depends on how the hardware was designed.  Most can, some can not.  Is
>> the hardware design and firmware source available anywhere?
> As far I know, firmware comes from
> https://tech.microbit.org/software/runtime/
>
> As to why these V1 and V2 happened to get the same product ID, perhaps
> my colleague Mike, in CC, who teaches a course using this board,  knows more.
>
> Cheers
> Dima

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

[Greg KH]

On Mon, Dec 19, 2022 at 10:20:48PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> 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/

Yes, they are a little different and the main point here is your device
says it is a ACM-compliant device, so just use that tty device node to
talk to it.  That is the standard for talking serial protocols to USB
devices.

By forcing the device to the generic usb-serial driver, you are saying
"this random endpoint is really a tty pass-through device" is that the
case?  Why would you have both a ACM and a pass-through set of endpoints
in the same USB device?

> 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

Those are not USB-serial devices :)

Seeing those device nodes is one thing, did you connect to the ttyUSBX
device nodes and talk to the device properly?

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

And I think that is the usb-serial connect to this device.

> 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*

There is no "proper" ttyUSB type of device.  That set of drivers was
created because there was no USB standard for usb-serial devices way
back in the day so people made custom chips for them with custom
protocols.  Then people realized this was a bad thing and came up with
the USB ACM spec so that you would NOT have to write a custom kernel
driver for their devices.

So if this device does need to be controlled by the usb-serial driver,
what chip is in it and what protocol does it talk?  As Alan said, the
output of `lsusb -v` for the device would be helpful.

> > > 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.

Are there specs on this chip anywhere?

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

There is no "one set" of serial USB commands to talk.  The article you
point to is not really correct.  ACM devices are NOT always modems,
often they are just manufacturers wanting to not have to write custom
kernel drivers, as USB originally was designed.

> 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?

USB is not for "real-time" devices :)

> > > 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. 

If ttyACM0 works, use it!  Why do you need anything else here?

thanks,

greg k-h

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

[dima.pasechnik]

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

On Tue, Dec 20, 2022 at 07:57:28AM +0100, Greg KH wrote:
> On Mon, Dec 19, 2022 at 10:20:48PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> > 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/
> 
> Yes, they are a little different and the main point here is your device
> says it is a ACM-compliant device, so just use that tty device node to
> talk to it.  That is the standard for talking serial protocols to USB
> devices.
> 
> By forcing the device to the generic usb-serial driver, you are saying
> "this random endpoint is really a tty pass-through device" is that the
> case?  Why would you have both a ACM and a pass-through set of endpoints
> in the same USB device?
> 
> > 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
> 
> Those are not USB-serial devices :)
> 
> Seeing those device nodes is one thing, did you connect to the ttyUSBX
> device nodes and talk to the device properly?
> 
> > Needless to say, there is also /dev/ttyACM0 popping up - so this part
> > of the communication is OK.
> 
> And I think that is the usb-serial connect to this device.
> 
> > 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*
> 
> There is no "proper" ttyUSB type of device.  That set of drivers was
> created because there was no USB standard for usb-serial devices way
> back in the day so people made custom chips for them with custom
> protocols.  Then people realized this was a bad thing and came up with
> the USB ACM spec so that you would NOT have to write a custom kernel
> driver for their devices.
> 
> So if this device does need to be controlled by the usb-serial driver,
> what chip is in it and what protocol does it talk?  As Alan said, the
> output of `lsusb -v` for the device would be helpful.
> 
> > > > 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.
> 
> Are there specs on this chip anywhere?
See https://tech.microbit.org/hardware/ 
(choose V2.2X there)
I have nRF52833-QDAA (there is also a different option)

here is "details" on the board itself (describing firmware, I suppose)

# DAPLink Firmware - see https://daplink.io
Build ID: alpha9-189-g5dd23001 (gcc)
Unique ID: 9905360200052833525e24a702a68552000000006e052820
HIC ID: 6e052820
Auto Reset: 1
Automation allowed: 0
Overflow detection: 0
Incompatible image detection: 1
Page erasing: 0
Daplink Mode: Interface
Interface Version: 0256
Bootloader Version: 0256
Git SHA: 5dd23001a7a3199d74870790049d6686e183316c
Local Mods: 0
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0xa60a7780
Interface CRC: 0x0bac75fa
Remount count: 0
URL: https://microbit.org/device/?id=9905&v=0256


------------------------------------------
Here are the specs for V1 version (not the current, V2 one -these are above) - see my reply
to Alan with lsusb details on this.

https://spivey.oriel.ox.ac.uk/digisys/The_BBC_micro:bit#Microcontroller_chip
https://www.nordicsemi.com/Products/nRF51822

And "details" from the board:

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 9901000051114e45005f80130000004e0000000097969901
HIC ID: 97969901
Auto Reset: 1
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0249
Bootloader Version: 0243
Git SHA: 9c5fd81e6545d00b7f7c21ca9d8577dbd6a5fed2
Local Mods: 0
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0x32eb3cfd
Interface CRC: 0xcdb7b2a3
Remount count: 0
URL: https://microbit.org/device/?id=9901&v=0249

HTH
Dima


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

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

[Alan Stern]

On Tue, Dec 20, 2022 at 02:50:17PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
> See https://tech.microbit.org/hardware/ 
> (choose V2.2X there)
> I have nRF52833-QDAA (there is also a different option)

Under the "USB Communications" section, that page says:

USB classes supported	Mass Storage Class (MSC)
			Communications Device Class (CDC)
			CMSIS-DAP HID & WinUSB
			WebUSB CMSIS-DAP HID

You already know about the MSC and CDC classes.  The other two appear to 
be versions of a CMSIS-DAP HID protocol, which is clearly not a serial 
communications protocol since it is HID.

So it looks like you aren't missing anything.

> here is "details" on the board itself (describing firmware, I suppose)
> 
> # DAPLink Firmware - see https://daplink.io
> Build ID: alpha9-189-g5dd23001 (gcc)
> Unique ID: 9905360200052833525e24a702a68552000000006e052820
> HIC ID: 6e052820
> Auto Reset: 1
> Automation allowed: 0
> Overflow detection: 0
> Incompatible image detection: 1
> Page erasing: 0
> Daplink Mode: Interface
> Interface Version: 0256
> Bootloader Version: 0256
> Git SHA: 5dd23001a7a3199d74870790049d6686e183316c
> Local Mods: 0
> USB Interfaces: MSD, CDC, HID, WebUSB

Which agrees with the information on the web site.  I have no idea what 
WebUSB is supposed to be.  In the lsusb output it doesn't have any 
resources -- in particular, no endpoints -- so all of its communications 
must occur over endpoint 0.

> Bootloader CRC: 0xa60a7780
> Interface CRC: 0x0bac75fa
> Remount count: 0
> URL: https://microbit.org/device/?id=9905&v=0256

The dmesg log in your original message showed you were trying to bind 
the usb-serial generic driver to interfaces 4 and 5.  But interface 4 is 
the WebUSB thing which, whatever it is, certainly isn't a serial 
interface.  And interface 5 is another HID interface; it calls itself 
CMSIS-DAP v2.  It sounds like an updated form of the other CMSIS-DAP HID 
interface.  It probably would have bound to the HID driver if you hadn't 
told the usb-serial driver to control it.

In short, there's no reason at all to expect the micro:bit board to give 
rise to a ttyUSB device.

Alan Stern

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

[Dima Pasechnik]

On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
>On Tue, Dec 20, 2022 at 02:50:17PM +0000, dima.pasechnik@cs.ox.ac.uk wrote:
>> See https://tech.microbit.org/hardware/ 
>> (choose V2.2X there)
>> I have nRF52833-QDAA (there is also a different option)
>
>Under the "USB Communications" section, that page says:
>
>USB classes supported	Mass Storage Class (MSC)
>			Communications Device Class (CDC)
>			CMSIS-DAP HID & WinUSB
>			WebUSB CMSIS-DAP HID
>
>You already know about the MSC and CDC classes.  The other two appear to 
>be versions of a CMSIS-DAP HID protocol, which is clearly not a serial 
>communications protocol since it is HID.
>
>So it looks like you aren't missing anything.
>
>> here is "details" on the board itself (describing firmware, I suppose)
>> 
>> # DAPLink Firmware - see https://daplink.io
>> Build ID: alpha9-189-g5dd23001 (gcc)
>> Unique ID: 9905360200052833525e24a702a68552000000006e052820
>> HIC ID: 6e052820
>> Auto Reset: 1
>> Automation allowed: 0
>> Overflow detection: 0
>> Incompatible image detection: 1
>> Page erasing: 0
>> Daplink Mode: Interface
>> Interface Version: 0256
>> Bootloader Version: 0256
>> Git SHA: 5dd23001a7a3199d74870790049d6686e183316c
>> Local Mods: 0
>> USB Interfaces: MSD, CDC, HID, WebUSB
>
>Which agrees with the information on the web site.  I have no idea what 
>WebUSB is supposed to be.

WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)

https://en.wikipedia.org/wiki/WebUSB


>  In the lsusb output it doesn't have any 
>resources -- in particular, no endpoints -- so all of its communications 
>must occur over endpoint 0.
>
>> Bootloader CRC: 0xa60a7780
>> Interface CRC: 0x0bac75fa
>> Remount count: 0
>> URL: https://microbit.org/device/?id=9905&v=0256
>
>The dmesg log in your original message showed you were trying to bind 
>the usb-serial generic driver to interfaces 4 and 5.  But interface 4 is 
>the WebUSB thing which, whatever it is, certainly isn't a serial 
>interface.  And interface 5 is another HID interface; it calls itself 
>CMSIS-DAP v2.  It sounds like an updated form of the other CMSIS-DAP HID 
>interface.  It probably would have bound to the HID driver if you hadn't 
>told the usb-serial driver to control it.
>
>In short, there's no reason at all to expect the micro:bit board to give 
>rise to a ttyUSB device.

Thanks for the advice, much appreciated.

Best,
Dmitrii

>
>Alan Stern

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

[Alan Stern]

A bit off to the side from the main point of this thread, but...

On Thu, Dec 22, 2022 at 10:32:09AM +0000, Dima Pasechnik wrote:
> 
> 
> On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
> >> USB Interfaces: MSD, CDC, HID, WebUSB
> >
> >Which agrees with the information on the web site.  I have no idea what 
> >WebUSB is supposed to be.
> 
> WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)
> 
> https://en.wikipedia.org/wiki/WebUSB

The Wikipedia article agrees with you that WebUSB is a JavaScript API.  
As such, it is used for communication between web browsers and 
JavaScript programs.  Not for communication between programs and USB 
devices.  So I don't understand why a USB device needs to be concerned 
about it.

Alan Stern

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

[Dmitrii Pasechnik]

On Thu, Dec 22, 2022 at 04:24:55PM -0500, Alan Stern wrote:
> A bit off to the side from the main point of this thread, but...
> 
> On Thu, Dec 22, 2022 at 10:32:09AM +0000, Dima Pasechnik wrote:
> > 
> > 
> > On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
> > >> USB Interfaces: MSD, CDC, HID, WebUSB
> > >
> > >Which agrees with the information on the web site.  I have no idea what 
> > >WebUSB is supposed to be.
> > 
> > WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)
> > 
> > https://en.wikipedia.org/wiki/WebUSB
> 
> The Wikipedia article agrees with you that WebUSB is a JavaScript API.  
> As such, it is used for communication between web browsers and 
> JavaScript programs.

No, it's used by browsers (which  run JavaScript code in them) to
communicate with USB hardware. Or, if you like,
standalone JavaScript programs to communicate with USB hardware. 
Let me copy from the wiki here:

---------------------------------
A Universal Serial Bus, or a USB is an industry standard [...]
WebUSB is a set of API calls that enable access to these hardware
devices from web pages. WebUSB is developed by the World Wide Web
Consortium(W3C).[1] The webUSB API provides a safe, and developer
familiar means of communication to edges devices from web pages. The
webUSB API integrates into existing USB libraries and shortens the
development cycle for integrating new devices into the web environment
by not needing to wait for browser support for these devices.

Early versions of webUSB came out around as an alternative to Flash,
Chrome Serial, and other custom approaches to connecting browsers to
hardware. WebUSB aims to solve the four goals of any interface being;
fast to make, cross platform, look good, accessibility.

>  Not for communication between programs and USB 
> devices.  So I don't understand why a USB device needs to be concerned 
> about it.

I hope the above explains.

HTH
Dmitrii

> 
> Alan Stern

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

[Alan Stern]

On Fri, Dec 23, 2022 at 12:58:41PM +0000, Dmitrii Pasechnik wrote:
> On Thu, Dec 22, 2022 at 04:24:55PM -0500, Alan Stern wrote:
> > A bit off to the side from the main point of this thread, but...
> > 
> > On Thu, Dec 22, 2022 at 10:32:09AM +0000, Dima Pasechnik wrote:
> > > 
> > > 
> > > On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > >> USB Interfaces: MSD, CDC, HID, WebUSB
> > > >
> > > >Which agrees with the information on the web site.  I have no idea what 
> > > >WebUSB is supposed to be.
> > > 
> > > WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)
> > > 
> > > https://en.wikipedia.org/wiki/WebUSB
> > 
> > The Wikipedia article agrees with you that WebUSB is a JavaScript API.  
> > As such, it is used for communication between web browsers and 
> > JavaScript programs.
> 
> No, it's used by browsers (which  run JavaScript code in them) to
> communicate with USB hardware. Or, if you like,
> standalone JavaScript programs to communicate with USB hardware. 
> Let me copy from the wiki here:
> 
> ---------------------------------
> A Universal Serial Bus, or a USB is an industry standard [...]
> WebUSB is a set of API calls that enable access to these hardware
> devices from web pages. WebUSB is developed by the World Wide Web
> Consortium(W3C).[1] The webUSB API provides a safe, and developer
> familiar means of communication to edges devices from web pages. The
> webUSB API integrates into existing USB libraries and shortens the
> development cycle for integrating new devices into the web environment
> by not needing to wait for browser support for these devices.
> 
> Early versions of webUSB came out around as an alternative to Flash,
> Chrome Serial, and other custom approaches to connecting browsers to
> hardware. WebUSB aims to solve the four goals of any interface being;
> fast to make, cross platform, look good, accessibility.
> 
> >  Not for communication between programs and USB 
> > devices.  So I don't understand why a USB device needs to be concerned 
> > about it.
> 
> I hope the above explains.

Actually, it's ambiguous.

The article says that WebUSB is an API used by JavaScript programs when 
they want to interact with a USB device.  Which means it is something 
that JavaScript programs can know about and interact with.  Fine.

But the article doesn't say what happens on the device's side of the 
conversation.  Does the WebUSB framework use some special messages when 
communicating with a USB device, so it will only work with devices which 
support WebUSB's protocol, or does it use plain ordinary USB messages 
which any USB device will support?

To put it another way, do USB devices need to have specialized firmware 
in order to be compatible with WebUSB, or will WebUSB work with all USB 
devices?  If the latter is true then why does the BBC micro:bit device 
have a special WebUSB interface?  Does the extra interface provide some 
sort of device-specific information which WebUSB can make use of but 
which isn't essential?

Alan Stern

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

[Dmitrii Pasechnik]

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

On Fri, Dec 23, 2022 at 09:52:50AM -0500, Alan Stern wrote:
> On Fri, Dec 23, 2022 at 12:58:41PM +0000, Dmitrii Pasechnik wrote:
> > On Thu, Dec 22, 2022 at 04:24:55PM -0500, Alan Stern wrote:
> > > A bit off to the side from the main point of this thread, but...
> > > 
> > > On Thu, Dec 22, 2022 at 10:32:09AM +0000, Dima Pasechnik wrote:
> > > > 
> > > > 
> > > > On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > > >> USB Interfaces: MSD, CDC, HID, WebUSB
> > > > >
> > > > >Which agrees with the information on the web site.  I have no idea what 
> > > > >WebUSB is supposed to be.
> > > > 
> > > > WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)
> > > > 
> > > > https://en.wikipedia.org/wiki/WebUSB
> > > 
> > > The Wikipedia article agrees with you that WebUSB is a JavaScript API.  
> > > As such, it is used for communication between web browsers and 
> > > JavaScript programs.
> > 
> > No, it's used by browsers (which  run JavaScript code in them) to
> > communicate with USB hardware. Or, if you like,
> > standalone JavaScript programs to communicate with USB hardware. 
> > Let me copy from the wiki here:
> > 
> > ---------------------------------
> > A Universal Serial Bus, or a USB is an industry standard [...]
> > WebUSB is a set of API calls that enable access to these hardware
> > devices from web pages. WebUSB is developed by the World Wide Web
> > Consortium(W3C).[1] The webUSB API provides a safe, and developer
> > familiar means of communication to edges devices from web pages. The
> > webUSB API integrates into existing USB libraries and shortens the
> > development cycle for integrating new devices into the web environment
> > by not needing to wait for browser support for these devices.
> > 
> > Early versions of webUSB came out around as an alternative to Flash,
> > Chrome Serial, and other custom approaches to connecting browsers to
> > hardware. WebUSB aims to solve the four goals of any interface being;
> > fast to make, cross platform, look good, accessibility.
> > 
> > >  Not for communication between programs and USB 
> > > devices.  So I don't understand why a USB device needs to be concerned 
> > > about it.
> > 
> > I hope the above explains.
> 
> Actually, it's ambiguous.
> 
> The article says that WebUSB is an API used by JavaScript programs when 
> they want to interact with a USB device.  Which means it is something 
> that JavaScript programs can know about and interact with.  Fine.
> 
> But the article doesn't say what happens on the device's side of the 
> conversation.  Does the WebUSB framework use some special messages when 
> communicating with a USB device, so it will only work with devices which 
> support WebUSB's protocol, or does it use plain ordinary USB messages 
> which any USB device will support?
> 
> To put it another way, do USB devices need to have specialized firmware 
> in order to be compatible with WebUSB, or will WebUSB work with all USB 
> devices?  If the latter is true then why does the BBC micro:bit device 
> have a special WebUSB interface?  Does the extra interface provide some 
> sort of device-specific information which WebUSB can make use of but 
> which isn't essential?

here is what I could find about the device side of WebUSB: https://web.dev/build-for-webusb/
Basically, WebUSB support offers some extras, e.g. one can get a
specific pop-up with a URL in it (supplied by the board) in the web browser as
the device is plugged in the USB port.

Also, on the software side, this: https://developer.chrome.com/articles/usb/
is more informative than the Wikipedia article.
And here is how WebUSB-capable device is meant to talk ot the machine
it's plugged in: https://wicg.github.io/webusb/#webusb-platform-capability-descriptor

HTH,
Dmitrii

> 
> Alan Stern

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

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

[Alan Stern]

On Fri, Dec 23, 2022 at 11:41:03PM +0000, Dmitrii Pasechnik wrote:
> On Fri, Dec 23, 2022 at 09:52:50AM -0500, Alan Stern wrote:
> > On Fri, Dec 23, 2022 at 12:58:41PM +0000, Dmitrii Pasechnik wrote:
> > > On Thu, Dec 22, 2022 at 04:24:55PM -0500, Alan Stern wrote:
> > > > A bit off to the side from the main point of this thread, but...
> > > > 
> > > > On Thu, Dec 22, 2022 at 10:32:09AM +0000, Dima Pasechnik wrote:
> > > > > 
> > > > > 
> > > > > On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > > > >> USB Interfaces: MSD, CDC, HID, WebUSB
> > > > > >
> > > > > >Which agrees with the information on the web site.  I have no idea what 
> > > > > >WebUSB is supposed to be.
> > > > > 
> > > > > WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)
> > > > > 
> > > > > https://en.wikipedia.org/wiki/WebUSB
> > > > 
> > > > The Wikipedia article agrees with you that WebUSB is a JavaScript API.  
> > > > As such, it is used for communication between web browsers and 
> > > > JavaScript programs.
> > > 
> > > No, it's used by browsers (which  run JavaScript code in them) to
> > > communicate with USB hardware. Or, if you like,
> > > standalone JavaScript programs to communicate with USB hardware. 
> > > Let me copy from the wiki here:
> > > 
> > > ---------------------------------
> > > A Universal Serial Bus, or a USB is an industry standard [...]
> > > WebUSB is a set of API calls that enable access to these hardware
> > > devices from web pages. WebUSB is developed by the World Wide Web
> > > Consortium(W3C).[1] The webUSB API provides a safe, and developer
> > > familiar means of communication to edges devices from web pages. The
> > > webUSB API integrates into existing USB libraries and shortens the
> > > development cycle for integrating new devices into the web environment
> > > by not needing to wait for browser support for these devices.
> > > 
> > > Early versions of webUSB came out around as an alternative to Flash,
> > > Chrome Serial, and other custom approaches to connecting browsers to
> > > hardware. WebUSB aims to solve the four goals of any interface being;
> > > fast to make, cross platform, look good, accessibility.
> > > 
> > > >  Not for communication between programs and USB 
> > > > devices.  So I don't understand why a USB device needs to be concerned 
> > > > about it.
> > > 
> > > I hope the above explains.
> > 
> > Actually, it's ambiguous.
> > 
> > The article says that WebUSB is an API used by JavaScript programs when 
> > they want to interact with a USB device.  Which means it is something 
> > that JavaScript programs can know about and interact with.  Fine.
> > 
> > But the article doesn't say what happens on the device's side of the 
> > conversation.  Does the WebUSB framework use some special messages when 
> > communicating with a USB device, so it will only work with devices which 
> > support WebUSB's protocol, or does it use plain ordinary USB messages 
> > which any USB device will support?
> > 
> > To put it another way, do USB devices need to have specialized firmware 
> > in order to be compatible with WebUSB, or will WebUSB work with all USB 
> > devices?  If the latter is true then why does the BBC micro:bit device 
> > have a special WebUSB interface?  Does the extra interface provide some 
> > sort of device-specific information which WebUSB can make use of but 
> > which isn't essential?
> 
> here is what I could find about the device side of WebUSB: https://web.dev/build-for-webusb/
> Basically, WebUSB support offers some extras, e.g. one can get a
> specific pop-up with a URL in it (supplied by the board) in the web browser as
> the device is plugged in the USB port.
> 
> Also, on the software side, this: https://developer.chrome.com/articles/usb/
> is more informative than the Wikipedia article.
> And here is how WebUSB-capable device is meant to talk ot the machine
> it's plugged in: https://wicg.github.io/webusb/#webusb-platform-capability-descriptor

Those are very helpful, thank you.

Interestingly, none of those documents mentions anything about having a 
special WebUSB interface in the configuration.  The WebUSB information 
on a device is accessed using standard or vendor-specific control 
messages with the device (not an interface) as recipient.  So the 
question of why the micro:bit has a WebUSB interface remains a 
mystery...

Alan Stern

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

[Jó Ágila Bitsch]

> On Fri, Dec 23, 2022 at 11:41:03PM +0000, Dmitrii Pasechnik wrote:
> > On Fri, Dec 23, 2022 at 09:52:50AM -0500, Alan Stern wrote:
> > > On Fri, Dec 23, 2022 at 12:58:41PM +0000, Dmitrii Pasechnik wrote:
> > > > On Thu, Dec 22, 2022 at 04:24:55PM -0500, Alan Stern wrote:
> > > > > A bit off to the side from the main point of this thread, but...
> > > > > 
> > > > > On Thu, Dec 22, 2022 at 10:32:09AM +0000, Dima Pasechnik wrote:
> > > > > > 
> > > > > > 
> > > > > > On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > > > > >> USB Interfaces: MSD, CDC, HID, WebUSB
> > > > > > >
> > > > > > >Which agrees with the information on the web site.  I have no idea what 
> > > > > > >WebUSB is supposed to be.
> > > > > > 
> > > > > > WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)
> > > > > > 
> > > > > > https://en.wikipedia.org/wiki/WebUSB
> > > > > 
> > > > > The Wikipedia article agrees with you that WebUSB is a JavaScript API.  
> > > > > As such, it is used for communication between web browsers and 
> > > > > JavaScript programs.
> > > > 
> > > > No, it's used by browsers (which  run JavaScript code in them) to
> > > > communicate with USB hardware. Or, if you like,
> > > > standalone JavaScript programs to communicate with USB hardware. 
> > > > Let me copy from the wiki here:
> > > > 
> > > > ---------------------------------
> > > > A Universal Serial Bus, or a USB is an industry standard [...]
> > > > WebUSB is a set of API calls that enable access to these hardware
> > > > devices from web pages. WebUSB is developed by the World Wide Web
> > > > Consortium(W3C).[1] The webUSB API provides a safe, and developer
> > > > familiar means of communication to edges devices from web pages. The
> > > > webUSB API integrates into existing USB libraries and shortens the
> > > > development cycle for integrating new devices into the web environment
> > > > by not needing to wait for browser support for these devices.
> > > > 
> > > > Early versions of webUSB came out around as an alternative to Flash,
> > > > Chrome Serial, and other custom approaches to connecting browsers to
> > > > hardware. WebUSB aims to solve the four goals of any interface being;
> > > > fast to make, cross platform, look good, accessibility.
> > > > 
> > > > >  Not for communication between programs and USB 
> > > > > devices.  So I don't understand why a USB device needs to be concerned 
> > > > > about it.
> > > > 
> > > > I hope the above explains.
> > > 
> > > Actually, it's ambiguous.
> > > 
> > > The article says that WebUSB is an API used by JavaScript programs when 
> > > they want to interact with a USB device.  Which means it is something 
> > > that JavaScript programs can know about and interact with.  Fine.
> > > 
> > > But the article doesn't say what happens on the device's side of the 
> > > conversation.  Does the WebUSB framework use some special messages when 
> > > communicating with a USB device, so it will only work with devices which 
> > > support WebUSB's protocol, or does it use plain ordinary USB messages 
> > > which any USB device will support?
> > > 
> > > To put it another way, do USB devices need to have specialized firmware 
> > > in order to be compatible with WebUSB, or will WebUSB work with all USB 
> > > devices?  If the latter is true then why does the BBC micro:bit device 
> > > have a special WebUSB interface?  Does the extra interface provide some 
> > > sort of device-specific information which WebUSB can make use of but 
> > > which isn't essential?
> > 
> > here is what I could find about the device side of WebUSB: https://web.dev/build-for-webusb/
> > Basically, WebUSB support offers some extras, e.g. one can get a
> > specific pop-up with a URL in it (supplied by the board) in the web browser as
> > the device is plugged in the USB port.
> > 
> > Also, on the software side, this: https://developer.chrome.com/articles/usb/
> > is more informative than the Wikipedia article.
> > And here is how WebUSB-capable device is meant to talk ot the machine
> > it's plugged in: https://wicg.github.io/webusb/#webusb-platform-capability-descriptor
> 
> Those are very helpful, thank you.
> 
> Interestingly, none of those documents mentions anything about having a 
> special WebUSB interface in the configuration.  The WebUSB information 
> on a device is accessed using standard or vendor-specific control 
> messages with the device (not an interface) as recipient.  So the 
> question of why the micro:bit has a WebUSB interface remains a 
> mystery...
> 
> Alan Stern

I may be able to shed some light on this:

TLDR:

There are 2 separate "serial" interfaces, one to control via the normal OS character device,
and one to connect to via a browser.

More details:

The reason for this additional interface is that WebUSB does not have any facilities
to detach the kernel driver, so once the kernel claimed a specific interface, say
/dev/ttyACM0, it is no longer accessible to WebUSB. (It would still be able to access the
serial port via WebSerial, but that browser feature is newer than WebUSB.)

The way out for Micro:bit and many similar boards, is to provide an additional vendor-specific
interface, that provides the same functionality as serial/ACM, but uses different class
descriptors, so the kernel doesn't claim it and a Javascript application can access it.
Therefore, you can access the device via the browser AND via /dev/ttyACM0.

This allows more flexibility for the user to use either mechanism.

Therefore, it would actually defeat the purpose, if the OS claimed that extra serial interface
itself, as the browser could no longer claim it.

Then again, the better way to implement this specific feature would probably for the website
to use WebSerial to access the serial port instead.

Incidentally, I posted a patch yesterday, that would allow Linux-based USB gadgets to
announce it's WebUSB landing page URL via a device capability BOS descriptor and a 
WebUSB-defined vendor specific call. This implements the optional device side parts of WebUSB,
that enables better discoverability from the user side.

Note: To access a device through WebUSB, it is not strictly necessary to change anything on
the device side. Just make sure you have permissions and the kernel didn't claim the interface
already. The browser also requires explicit user interaction to allow access.

(In current Chrome, the feature to show the popup on device insertion is behind a flag:
chrome://flags/#enable-webusb-device-detection)

Best regards,
Jó