Warner Losh wrote:
On Sun, Feb 2, 2020 at 12:32 PM Denver Hull <[email protected]
<mailto:[email protected]>> wrote:
Hans Petter Selasky wrote:
> On 2019-12-20 13:54, Denver Hull wrote:
>> Hans Petter Selasky wrote:
>>> On 2019-12-19 01:11, Denver Hull wrote:
>>>> Hello,
>>>>
>>>> I have several different microcontroller boards that are
supposed
>>>> to appear as storage devices when plugged in. They work fine on
>>>> Linux systems, but on FreeBSD 11.3 and 12.1 they don't show
up at
>>>> all. Here's what dmesg shows for one of them:
>>>>
>>>> ugen1.3: <Adafruit Industries LLC PyPortal> at usbus1
>>>> umodem0 on uhub1
>>>> umodem0: <CircuitPython CDC control> on usbus1
>>>> umodem0: data interface 1, has no CM over data, has no break
>>>> umass3 on uhub1
>>>> umass3: <CircuitPython Mass Storage> on usbus1
>>>> umass3: SCSI over Bulk-Only; quirks = 0x0000
>>>> umass3:5:3: Attached to scbus5
>>>> uaudio0 on uhub1
>>>> uaudio0: <CircuitPython Audio> on usbus1
>>>> uaudio0: No playback.
>>>> uaudio0: No recording.
>>>> uaudio0: MIDI sequencer.
>>>> uaudio0: No HID volume keys found.
>>>> ums2 on uhub1
>>>> ums2: <CircuitPython HID> on usbus1
>>>> ums2: 16 buttons and [XYZ] coordinates ID=2
>>>> (da3:umass-sim3:3:0:0): got CAM status 0x44
>>>> (da3:umass-sim3:3:0:0): fatal error, failed to attach to device
>>>> g_access(944): provider da3 has error 6 set
>>>> g_access(944): provider da3 has error 6 set
>>>> g_access(944): provider da3 has error 6 set
>>>> g_access(944): provider da3 has error 6 set
>>>> g_access(944): provider da3 has error 6 set
>>>>
>>>> There's a definite delay after the last ums message. I used
>>>> camcontrol debug in single user mode on a bare 12.1 system to
get a
>>>> little more information about what was happening. It looks
like the
>>>> initial Inquiry and Test Unit Ready commands succeed, but the
next
>>>> Mode Sense command times out, as well as all subsequent
commands.
>>>> There are several seconds of inactivity between retries, and
>>>> there's no sense data, so I'm assuming that indicates timeout.
>>>>
>>>> At this point I'm not sure how best to proceed to get these
devices
>>>> to work, so any help will be appreciated.
>>>>
>>>
>>> Did you try setting one or more quirks for these devices using
>>> usbconfig?
>>>
>>> UQ_MSC_NO_TEST_UNIT_READY
>>> UQ_MSC_NO_RS_CLEAR_UA
>>> UQ_MSC_NO_START_STOP
>>> UQ_MSC_NO_GETMAXLUN
>>> UQ_MSC_NO_INQUIRY
>>> UQ_MSC_NO_INQUIRY_EVPD
>>> UQ_MSC_NO_PREVENT_ALLOW
>>> UQ_MSC_NO_SYNC_CACHE
>>> UQ_MSC_SHUTTLE_INIT
>>> UQ_MSC_ALT_IFACE_1
>>> UQ_MSC_FLOPPY_SPEED
>>> UQ_MSC_IGNORE_RESIDUE
>>> UQ_MSC_WRONG_CSWSIG
>>> UQ_MSC_RBC_PAD_TO_12
>>> UQ_MSC_READ_CAP_OFFBY1
>>> UQ_MSC_FORCE_SHORT_INQ
>>>
>>> If you run "usbdump -i usbusX -f Y -s 65536 -vvv" you might
see the
>>> last failing SCSI command. X.Y are numbers after ugen for your
device.
>>>
>>> Likely your device has a software bug in its USB/SCSI
>>> implementation, which is quite common unfortunately.
>>>
>>> --HPS
>>>
>> After I sent the previous message I did try
>> UQ_MSC_NO_TEST_UNIT_READY. Although the system reports "quirks =
>> 0001", the initial TUR is still being issued during the probe
>> sequence. I tried the usbdump command you suggested, and I can
>> clearly see where the timeouts are, and frames that begin with
"USBC"
>> seem to contain a SCSI CDB. But there's a lot of other stuff in
>> between that I haven't been able to figure out, so I've attached a
>> sample. Hopefully it will help.
>>
>
> Hi,
>
> All the USBC's are raw SCSI commands, which use the following
layout:
>
>> /* Command Block Wrapper */
>> typedef struct {
>> uDWord dCBWSignature;
>> #define CBWSIGNATURE 0x43425355
>> uDWord dCBWTag;
>> uDWord dCBWDataTransferLength;
>> uByte bCBWFlags;
>> #define CBWFLAGS_OUT 0x00
>> #define CBWFLAGS_IN 0x80
>> uByte bCBWLUN;
>> uByte bCDBLength;
>> #define CBWCDBLENGTH 16
>> uByte CBWCDB[CBWCDBLENGTH];
>> } __packed umass_bbb_cbw_t;
>
> We had a SoC to add support for the usbdump format to wireshark:
>
> https://wiki.freebsd.org/SummerOfCode2017/usbdump-wireshark
>
> You might find that useful.
>
> My first suspicion is that your device is not fully USB class
> compliant, and that's why it is STALLING and failing to recover.
>
> --HPS
>
>
I checked on a Linux system, and the negotiation follows a slightly
different pattern, but as far as I can see, the biggest difference is
that Linux uses 6 byte Mode Sense commands instead of 10 byte. I
wonder
if that's all that's making the device choke? How hard would it
be to
change things to use 0x1a instead of 0x5a temporarily?
Alternatively, I
could see if I can figure out how to issue arbitrary SCSI commands on
Linux. I used to have something for that purpose that worked on a
variety of platforms, but it's been ages since I needed it. In any
case, I'll attach the Linux wireshark trace. The negotiation
seems to
begin at frame 2331.
There's a DA_Q_NO_6_BYTE quirk, but that does rather the opposite of
what I think is needed here.
and we use it here:
* RBC devices don't have to support READ(6), only READ(10).
*/
if (softc->quirks & DA_Q_NO_6_BYTE || SID_TYPE(&cgd->inq_data)
== T_RBC)
softc->minimum_cmd_size = 10;
else
softc->minimum_cmd_size = 6;
but there's a way to override:
* Load the user's default, if any.
*/
snprintf(tmpstr, sizeof(tmpstr),
"kern.cam.da.%d.minimum_cmd_size",
periph->unit_number);
TUNABLE_INT_FETCH(tmpstr, &softc->minimum_cmd_size);
so you could try setting the tunable
kern.cam.da.X.minimum_cmd_size="6" in /boot/loader.conf (where X is
the drive the system assigns) and see if that changes the wireshark
output to be closer to Linux or not...
I'm unsure if we have a direct way to ask if it's RBC or not...
Warner
Sorry about the long delay. This sounded promising and I had high hopes
for it, but it didn't help. The difficulty begins before the da device
is created. It looks like once the initial 10 byte Mode Sense is issued
the device becomes unresponsive and everything goes downhill from
there. That's clearly a problem with the device, but I'm pretty sure
that on Linux it recovers if I send it a 10 byte Mode Sense. When I get
a chance I'll see if I can capture what Linux is doing to recover from that.
I've started looking at the boot code for these boards, which appears to
be derived from Atmel's SAM-BA. Two of the boards I have work fine, but
they have a very old version of the bootloader. I updated all the other
boards with the latest version, but that didn't change anything. At
this point I'm still setting up something to be able to build that code.
Thanks,
Denver
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
