* usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
@ 2022-12-19 12:57 dima.pasechnik
2022-12-19 15:00 ` Greg KH
0 siblings, 1 reply; 23+ messages in thread
From: dima.pasechnik @ 2022-12-19 12:57 UTC (permalink / raw)
To: linux-usb
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-19 12:57 usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised dima.pasechnik
@ 2022-12-19 15:00 ` Greg KH
2022-12-19 16:29 ` dima.pasechnik
0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2022-12-19 15:00 UTC (permalink / raw)
To: dima.pasechnik; +Cc: linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-19 15:00 ` Greg KH
@ 2022-12-19 16:29 ` dima.pasechnik
2022-12-19 18:10 ` dima.pasechnik
0 siblings, 1 reply; 23+ messages in thread
From: dima.pasechnik @ 2022-12-19 16:29 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-19 16:29 ` dima.pasechnik
@ 2022-12-19 18:10 ` dima.pasechnik
2022-12-19 18:25 ` Greg KH
0 siblings, 1 reply; 23+ messages in thread
From: dima.pasechnik @ 2022-12-19 18:10 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-19 18:10 ` dima.pasechnik
@ 2022-12-19 18:25 ` Greg KH
2022-12-19 22:20 ` dima.pasechnik
0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2022-12-19 18:25 UTC (permalink / raw)
To: dima.pasechnik; +Cc: linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-19 18:25 ` Greg KH
@ 2022-12-19 22:20 ` dima.pasechnik
2022-12-19 23:36 ` Alan Stern
2022-12-20 6:57 ` Greg KH
0 siblings, 2 replies; 23+ messages in thread
From: dima.pasechnik @ 2022-12-19 22:20 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-19 22:20 ` dima.pasechnik
@ 2022-12-19 23:36 ` Alan Stern
2022-12-20 13:08 ` dima.pasechnik
2022-12-20 6:57 ` Greg KH
1 sibling, 1 reply; 23+ messages in thread
From: Alan Stern @ 2022-12-19 23:36 UTC (permalink / raw)
To: dima.pasechnik; +Cc: Greg KH, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-19 22:20 ` dima.pasechnik
2022-12-19 23:36 ` Alan Stern
@ 2022-12-20 6:57 ` Greg KH
2022-12-20 14:50 ` dima.pasechnik
1 sibling, 1 reply; 23+ messages in thread
From: Greg KH @ 2022-12-20 6:57 UTC (permalink / raw)
To: dima.pasechnik; +Cc: linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-19 23:36 ` Alan Stern
@ 2022-12-20 13:08 ` dima.pasechnik
2022-12-23 14:50 ` Greg KH
0 siblings, 1 reply; 23+ messages in thread
From: dima.pasechnik @ 2022-12-20 13:08 UTC (permalink / raw)
To: Alan Stern; +Cc: Greg KH, linux-usb
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-20 6:57 ` Greg KH
@ 2022-12-20 14:50 ` dima.pasechnik
2022-12-20 19:57 ` Alan Stern
0 siblings, 1 reply; 23+ messages in thread
From: dima.pasechnik @ 2022-12-20 14:50 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-20 14:50 ` dima.pasechnik
@ 2022-12-20 19:57 ` Alan Stern
2022-12-22 10:32 ` Dima Pasechnik
0 siblings, 1 reply; 23+ messages in thread
From: Alan Stern @ 2022-12-20 19:57 UTC (permalink / raw)
To: dima.pasechnik; +Cc: Greg KH, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-20 19:57 ` Alan Stern
@ 2022-12-22 10:32 ` Dima Pasechnik
2022-12-22 21:24 ` Alan Stern
0 siblings, 1 reply; 23+ messages in thread
From: Dima Pasechnik @ 2022-12-22 10:32 UTC (permalink / raw)
To: Alan Stern, dima.pasechnik; +Cc: Greg KH, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-22 10:32 ` Dima Pasechnik
@ 2022-12-22 21:24 ` Alan Stern
2022-12-23 12:58 ` Dmitrii Pasechnik
0 siblings, 1 reply; 23+ messages in thread
From: Alan Stern @ 2022-12-22 21:24 UTC (permalink / raw)
To: Dima Pasechnik; +Cc: dima.pasechnik, Greg KH, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-22 21:24 ` Alan Stern
@ 2022-12-23 12:58 ` Dmitrii Pasechnik
2022-12-23 14:52 ` Alan Stern
0 siblings, 1 reply; 23+ messages in thread
From: Dmitrii Pasechnik @ 2022-12-23 12:58 UTC (permalink / raw)
To: Alan Stern; +Cc: Greg KH, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-20 13:08 ` dima.pasechnik
@ 2022-12-23 14:50 ` Greg KH
2022-12-23 23:51 ` dima.pasechnik
0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2022-12-23 14:50 UTC (permalink / raw)
To: dima.pasechnik; +Cc: Alan Stern, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-23 12:58 ` Dmitrii Pasechnik
@ 2022-12-23 14:52 ` Alan Stern
2022-12-23 23:41 ` Dmitrii Pasechnik
0 siblings, 1 reply; 23+ messages in thread
From: Alan Stern @ 2022-12-23 14:52 UTC (permalink / raw)
To: Dmitrii Pasechnik; +Cc: Greg KH, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-23 14:52 ` Alan Stern
@ 2022-12-23 23:41 ` Dmitrii Pasechnik
2022-12-31 19:49 ` Jó Ágila Bitsch
0 siblings, 1 reply; 23+ messages in thread
From: Dmitrii Pasechnik @ 2022-12-23 23:41 UTC (permalink / raw)
To: Alan Stern; +Cc: Greg KH, linux-usb
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-23 14:50 ` Greg KH
@ 2022-12-23 23:51 ` dima.pasechnik
2022-12-24 6:53 ` Greg KH
0 siblings, 1 reply; 23+ messages in thread
From: dima.pasechnik @ 2022-12-23 23:51 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Stern, linux-usb
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-23 23:51 ` dima.pasechnik
@ 2022-12-24 6:53 ` Greg KH
2022-12-25 11:08 ` dima.pasechnik
0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2022-12-24 6:53 UTC (permalink / raw)
To: dima.pasechnik; +Cc: Alan Stern, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
@ 2022-12-31 19:49 ` Jó Ágila Bitsch
0 siblings, 0 replies; 23+ messages in thread
From: Alan Stern @ 2022-12-24 16:00 UTC (permalink / raw)
To: Dmitrii Pasechnik; +Cc: Greg KH, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-24 6:53 ` Greg KH
@ 2022-12-25 11:08 ` dima.pasechnik
2022-12-25 18:52 ` Mike Spivey
0 siblings, 1 reply; 23+ messages in thread
From: dima.pasechnik @ 2022-12-25 11:08 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Stern, linux-usb, Mike.Spivey
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
2022-12-25 11:08 ` dima.pasechnik
@ 2022-12-25 18:52 ` Mike Spivey
0 siblings, 0 replies; 23+ messages in thread
From: Mike Spivey @ 2022-12-25 18:52 UTC (permalink / raw)
To: dima.pasechnik, Greg KH; +Cc: Alan Stern, linux-usb
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
@ 2022-12-31 19:49 ` Jó Ágila Bitsch
0 siblings, 0 replies; 23+ messages in thread
From: Jó Ágila Bitsch @ 2022-12-31 19:49 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, gregkh, Dmitrii Pasechnik
> 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ó
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2022-12-31 19:49 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-19 12:57 usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised dima.pasechnik
2022-12-19 15:00 ` Greg KH
2022-12-19 16:29 ` dima.pasechnik
2022-12-19 18:10 ` dima.pasechnik
2022-12-19 18:25 ` Greg KH
2022-12-19 22:20 ` dima.pasechnik
2022-12-19 23:36 ` Alan Stern
2022-12-20 13:08 ` dima.pasechnik
2022-12-23 14:50 ` Greg KH
2022-12-23 23:51 ` dima.pasechnik
2022-12-24 6:53 ` Greg KH
2022-12-25 11:08 ` dima.pasechnik
2022-12-25 18:52 ` Mike Spivey
2022-12-20 6:57 ` Greg KH
2022-12-20 14:50 ` dima.pasechnik
2022-12-20 19:57 ` Alan Stern
2022-12-22 10:32 ` Dima Pasechnik
2022-12-22 21:24 ` Alan Stern
2022-12-23 12:58 ` Dmitrii Pasechnik
2022-12-23 14:52 ` Alan Stern
2022-12-23 23:41 ` Dmitrii Pasechnik
2022-12-24 16:00 ` Alan Stern
2022-12-31 19:49 ` Jó Ágila Bitsch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.