All of lore.kernel.org
 help / color / mirror / Atom feed
From: dima.pasechnik@cs.ox.ac.uk
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Subject: Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
Date: Tue, 20 Dec 2022 14:50:17 +0000	[thread overview]
Message-ID: <Y6HLqYpxwT+v3BgX@hilbert> (raw)
In-Reply-To: <Y6Fc2Fz8w4KoX952@kroah.com>

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

  reply	other threads:[~2022-12-20 14:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y6HLqYpxwT+v3BgX@hilbert \
    --to=dima.pasechnik@cs.ox.ac.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.