linux-automation / usbsdmux Goto Github PK

I use bmaptool to flash an image. Sometimes (20 % of runs) it runs into an input/output error:

bmaptool: ERROR: cannot synchronize '/dev/disk/by-id/usb-LinuxAut_sdmux_HS-SD_MMC_000000000540-0:0': Input/output error

Do you have a suggestion how to avoid that? Different SD card? Different USB cable?

This is a dump of the output from dmesg:

[10479.022032] usb 1-1.3.4.4.1: reset high-speed USB device number 12 using dwc_otg
[10479.163698] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[10479.163744] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 fb d0 00 00 00 08 00
[10479.163771] blk_update_request: I/O error, dev sdb, sector 16502784 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[10479.749861] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[10479.749912] sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x6 [current] 
[10479.749941] sd 1:0:0:0: [sdb] tag#0 ASC=0x28 ASCQ=0x0 
[10479.749970] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 01 40 80 00 00 08 00
[10479.749996] blk_update_request: I/O error, dev sdb, sector 82048 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[10479.750134] sd 1:0:0:0: [sdb] tag#0 device offline or changed
[10479.750156] blk_update_request: I/O error, dev sdb, sector 16502784 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[10479.750173] buffer_io_error: 52 callbacks suppressed
[10479.750189] Buffer I/O error on dev sdb4, logical block 512, async page read
[10479.750280] sd 1:0:0:0: [sdb] tag#0 device offline or changed
[10479.750300] blk_update_request: I/O error, dev sdb, sector 16498424 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[10479.750430] sd 1:0:0:0: [sdb] tag#0 device offline or changed
[10479.750451] blk_update_request: I/O error, dev sdb, sector 16498424 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[10479.750467] Buffer I/O error on dev sdb3, logical block 1026015, async page read

Hi folks,

Thanks for producing the sd-mux and this useful project to manage the device(s). I have written a REST API to allow a central machine host one or more devices which can then allow users or automation to use the mux without requiring accounts etc... with basic calls such as:

curl <host_name_or_ip>:5000/get/<mux_id>
curl <host_name_or_ip>:5000/set/<mux_id>/off
curl -X POST <host_name_or_ip>:5000/write/<mux_id> -F '[email protected]'
curl <host_name_or_ip>:5000/task/<mux_id>

I haven't posted the code on github yet as I need to do a bit of cleanup first. I think the code would do better here though then on my personal github account. Would you be interested in the code? It is fully functional, though maybe not the prettiest, but definitely a good starting point.

Hi,

I'm very happy with my USB-SD-Mux, thanks for making & selling it!
There are 2 things I'd be happy to see in a newer revision of the hardware:

• USB-C connector
• Reset GPIO / Open-Collector output

Being able to keep the DUT in reset would be sufficient for most of my applications and would save me from having to deal with controlling an external power supply or having to try and use a different USB-converter just for the reset line.

I might just hack my board to use an unused GPIO with an N-channel MOSFET to provide this functionality, but a clean solution would be preferred :)

Thanks!

I suggest to prepend the content of the LICENSE file to the individual files, as this would allow tooling to automatically detect the right license.

Ideally, we would also add an SPDX license identifier to each file header.

`tanureal@cryzen usbsdmux $ source venv/bin/activate

(venv) tanureal@cryzen usbsdmux $ sudo venv/bin/usbsdmux /dev/sda get
Traceback (most recent call last):
File "/home/tanureal/workspace/usbsdmux/venv/bin/usbsdmux", line 10, in
sys.exit(main())
File "/home/tanureal/workspace/usbsdmux/venv/lib/python3.10/site-packages/usbsdmux-0.2.1-py3.10.egg/usbsdmux/main.py", line 97, in main
File "/home/tanureal/workspace/usbsdmux/venv/lib/python3.10/site-packages/usbsdmux-0.2.1-py3.10.egg/usbsdmux/main.py", line 79, in main
File "/home/tanureal/workspace/usbsdmux/venv/lib/python3.10/site-packages/usbsdmux-0.2.1-py3.10.egg/usbsdmux/usbsdmux.py", line 55, in get_mode
File "/home/tanureal/workspace/usbsdmux/venv/lib/python3.10/site-packages/usbsdmux-0.2.1-py3.10.egg/usbsdmux/pca9536.py", line 73, in read_register
File "/home/tanureal/workspace/usbsdmux/venv/lib/python3.10/site-packages/usbsdmux-0.2.1-py3.10.egg/usbsdmux/usb2642i2c.py", line 413, in write_read_to
File "/home/tanureal/workspace/usbsdmux/venv/lib/python3.10/site-packages/usbsdmux-0.2.1-py3.10.egg/usbsdmux/usb2642i2c.py", line 335, in _call_IOCTL
OSError: [Errno 123] No medium found: '/dev/sda'

(venv) tanureal@cryzen usbsdmux $ ls -l /dev/sda
brw-rw---- 1 777 disk 8, 0 Dec 4 10:43 /dev/sda
`

If I run the installation/build as documented:

$ python3 -m venv venv
$ source venv/bin/activate
$ python setup.py install
$ sudo usbsdmux /dev/sg1 dut

I do not get the usbsdmux executable:

bash: usbsdmux: command not found

Can not find the file in venv/bin.

When /dev/sg0 is not present, usbsdmux asks:

Does /dev/sg0 really point to an USB-SD-Mux?
(multiple occurrences in usbsdmux/__main__.py)

Instead, this should read:

Does /dev/sg0 really point to a USB-SD-Mux?

(AFAIK, a trailing n for the indefinite article gets only appended, if the article is followed by a glottal stop ('), so: "an [']unbelievable feat", but "a universal treat")

Hi,
my software colleague just came over to me "he needs this to debug - will it fit?" - but the SD socket is not at the edge of the board I'm designing. Moving it to the edge will create a mess :-/
My proposal / request would be if you could use a Semi-Flexible PCB design and just leave a few millimeters of the SD connector tongue flexible - just to allow a slight bend.
The benefit for all other users would be the reduced stress onto the SD connector when a (compared to a simple SD card) PCB and heavy USB cable is added to the socket.
Thanks :)

Hi,
I'm currently using two (and soon three) usbsdmux in our CI pipeline. When switching to host mode, how can I know (despite manually checking the output of e.g. dmesg) where the device is mounted (/dev/sda, /dev/sdb, etc.)? Can I explicitly set a mount point?

Best regards
Marius

Hi,
I bought two USB-SD-Mux recently. I install usbsdmux and switched to host mode. It worked fine.
After I switched it to DUT mode, the test board (a Raspberry PI 4) doesn't detect the sdcard.
I can see the correct leds are on while switching between host and DUT mode.

Here is my output:
venv) atish@yoda:~$ cat /proc/scsi/sg/device_strs
NORELSYS 1081 0
LinuxAut sdmux HS-SD/MMC 2.09

(venv) atish@yoda:~$ ls -alrth /dev/sg*
crw-rw---- 1 root disk 21, 0 Jul 29 09:41 /dev/sg0
crw-rw---- 1 root disk 21, 1 Jul 29 18:53 /dev/sg1

(venv) atish@yoda:~$ sudo usbsdmux /dev/sg1 host

(venv) atish@yoda:~$ sudo fdisk -l

Disk /dev/sdb: 7.41 GiB, 7948206080 bytes, 15523840 sectors
Disk model: sdmux HS-SD/MMC
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xda84cd12

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 526335 524288 256M c W95 FAT32 (LBA)
/dev/sdb2 526336 15523806 14997471 7.2G 83 Linux

The red host led turns on as well.
(venv) atish@yoda:~$ sudo usbsdmux /dev/sg1 DUT

The green DUT led turns on as well. I have power cycled the DUT multiples times after this. But the RP4 doesn't detect the card.

I have tried several sdcards in both the USB-SD-Mux. The board detects the sdcard if inserted directly and works fine without any issues. Any suggestions what might be wrong ?

The provided udev rule does not match our device:

$ udevadm info -n /dev/sg2 -a
  looking at device '/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.3/3-1.3.1/3-1.3.1:1.0/host6/target6:0:0/6:0:0:0/scsi_generic/sg2':
    KERNEL=="sg2"
    SUBSYSTEM=="scsi_generic"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.3/3-1.3.1/3-1.3.1:1.0/host6/target6:0:0/6:0:0:0':
    KERNELS=="6:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{blacklist}==""
    ATTRS{device_blocked}=="0"
    ATTRS{device_busy}=="0"
    ATTRS{dh_state}=="detached"
    ATTRS{eh_timeout}=="10"
    ATTRS{evt_capacity_change_reported}=="0"
    ATTRS{evt_inquiry_change_reported}=="0"
    ATTRS{evt_lun_change_reported}=="0"
    ATTRS{evt_media_change}=="0"
    ATTRS{evt_mode_parameter_change_reported}=="0"
    ATTRS{evt_soft_threshold_reached}=="0"
    ATTRS{inquiry}==""
    ATTRS{iocounterbits}=="32"
    ATTRS{iodone_cnt}=="0x2e9a"
    ATTRS{ioerr_cnt}=="0x1a1"
    ATTRS{iorequest_cnt}=="0x2e9a"
    ATTRS{max_sectors}=="240"
    ATTRS{model}=="sdmux HS-SD/MMC "
    ATTRS{queue_depth}=="1"
    ATTRS{queue_type}=="none"
    ATTRS{rev}=="2.09"
    ATTRS{scsi_level}=="0"
    ATTRS{state}=="running"
    ATTRS{timeout}=="30"
    ATTRS{type}=="0"
    ATTRS{vendor}=="LinuxAut"

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.3/3-1.3.1/3-1.3.1:1.0/host6/target6:0:0':
    KERNELS=="target6:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.3/3-1.3.1/3-1.3.1:1.0/host6':
    KERNELS=="host6"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.3/3-1.3.1/3-1.3.1:1.0':
    KERNELS=="3-1.3.1:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb-storage"
    ATTRS{authorized}=="1"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bInterfaceClass}=="08"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bInterfaceProtocol}=="50"
    ATTRS{bInterfaceSubClass}=="06"
    ATTRS{bNumEndpoints}=="02"
    ATTRS{supports_autosuspend}=="1"

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.3/3-1.3.1':
    KERNELS=="3-1.3.1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{authorized}=="1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{bMaxPower}=="96mA"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bcdDevice}=="0209"
    ATTRS{bmAttributes}=="80"
    ATTRS{busnum}=="3"
    ATTRS{configuration}==""
    ATTRS{devnum}=="8"
    ATTRS{devpath}=="1.3.1"
    ATTRS{idProduct}=="4041"
    ATTRS{idVendor}=="0424"
    ATTRS{ltm_capable}=="no"
    ATTRS{manufacturer}=="Linux Automation GmbH"
    ATTRS{maxchild}=="0"
    ATTRS{product}=="usb-sd-mux_rev4.0"
    ATTRS{quirks}=="0x0"
    ATTRS{removable}=="fixed"
    ATTRS{serial}=="000000000343"
    ATTRS{speed}=="12"
    ATTRS{urbnum}=="25494"
    ATTRS{version}==" 1.10"

  …

The label on the device reads:

USB-SD-Mux
rev4  Nr.0343

And the QR code on the device label reads:

0044 30.2019 023800 USBSDMux rev4

I assume this udev rule has not been updated yet for devices shipped to customers?

This is work-in-progress

Branches debian and upstream must be kept separately, do not merge into master. See git-buildpackage documentation.

I started to work on a Debian package in sephalon/usbsdmux, debian branch. After #18 and #19 have been resolved, this can be finished and brought upstream.

While the comments in the code suggest that the device parameter should always point to a /dev/sg* there is no actual validation of the device path, so the utility will blindly run the ioctls against whatever path is given. While I have a hard time constructing a security issue out of a fixed set of ioctl calls, it certainly seems sloppy to not do any sanity checks.

I don't see any reason to allow paths outside of /dev, also validating that the given SG device is actually a usbsdmux seems appropriate as to not confuse unrelated SG devices with the usbsdmux specific ioctls if the user happens to specify the wrong device by accident or malice.

Is it possible to buy the USB-SD-Mux hardware as a commercial product? Or can one receive hardware samples for testing purposes (we'd be happy to share our results and contribute bug reports)? If none of this works, would you consider sharing the schematics/gerber files/BOM so we can build one by ourselves?

We are going to buy one or more USB-SD-Muxes anyway, but it would be the cherry on top, if you could support the following two things:

1. Let the user switch the microSD card between host and DUT using one (host/DUT) or two (host/DUT/off) GPIOs[1] as input. Even if it seems like just a minor convenience feature, it can speed up development significantly, depending on your development workflow and tests.

2. Control DUT's card-detect signal via a GPIO[1] as output. The usual way (and also present in our DUTs) seems to be that the DUT's CD signal is pulled high and, upon insertion of a microSD card, shorted to GND, so setting the GPIO to low upon switching the card to the DUT side should accommodate this feature easily.

If possible (via firmware update), implement both 1) and 2) via firmware, as this allows for quasi-autonomous (i.e. PC-free) operation of the USB-SD-Mux as a simple and quickly operable microSD card on/off switch.

[1] (preferrably exposed on a VIA or a trace, but we would also be willing to bend ultra-fine-pitch pins under the microscope)

The product identification section in the documentation does not match the label on our device; it reads:

USB-SD-Mux
rev4  Nr.0343

And the QR code on the device label does not match either; it reads:

0044 30.2019 023800 USBSDMux rev4

To simplify the installation, it would be nice to have an usbsdmux package on the Python Package Index.

#17 must be merged first. Metadata in setup.py should be completed according to the Python Packaging User Guide. The release should also be VCS-tagged accordingly.

In my attempt to switch the sdmux to dut mode, and also calling get,dut,client,host,off
I get the following error repeatdly:

usbsdmux /dev/sg0 host
Traceback (most recent call last):
  File "/home/john/Source/github.com/pengutronix/usbsdmux/venv/bin/usbsdmux", line 10, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/john/Source/github.com/pengutronix/usbsdmux/venv/lib64/python3.11/site-packages/usbsdmux-0.2.1-py3.11.egg/usbsdmux/__main__.py", line 76, in main
  File "/home/john/Source/github.com/pengutronix/usbsdmux/venv/lib64/python3.11/site-packages/usbsdmux-0.2.1-py3.11.egg/usbsdmux/usbsdmux.py", line 112, in mode_host
  File "/home/john/Source/github.com/pengutronix/usbsdmux/venv/lib64/python3.11/site-packages/usbsdmux-0.2.1-py3.11.egg/usbsdmux/usbsdmux.py", line 77, in mode_disconnect
  File "/home/john/Source/github.com/pengutronix/usbsdmux/venv/lib64/python3.11/site-packages/usbsdmux-0.2.1-py3.11.egg/usbsdmux/pca9536.py", line 106, in output_values
  File "/home/john/Source/github.com/pengutronix/usbsdmux/venv/lib64/python3.11/site-packages/usbsdmux-0.2.1-py3.11.egg/usbsdmux/pca9536.py", line 67, in _write_register
  File "/home/john/Source/github.com/pengutronix/usbsdmux/venv/lib64/python3.11/site-packages/usbsdmux-0.2.1-py3.11.egg/usbsdmux/usb2642i2c.py", line 469, in write_to
usbsdmux.usb2642i2c.I2cTransactionFailed: SCSI-Transaction ended with status 2. I2C-Transaction has probably failed.

I have loaded the sg kernel module.

I have tried cloning the project, running from source with venv as specified in the commisioning step.
Furthermore to isolate my distro, I tried running from inside a Docker container running Ubuntu 20 but the error is still there.

USB

I tried with to different USB cables, I also tried behind a USB hub, and directly to the USB 2.0 interface, and USB 3.0. Still the same issue.

System

Here is some info about my system:

OS: openSUSE Tumbleweed x86_64 
Kernel: 6.1.12-1-default 
Uptime: 29 days, 5 hours, 6 mins 
Packages: 4355 (rpm), 6 (flatpak), 1 (appimaged) 
Shell: zsh 5.9 
Resolution: 2560x1440, 2560x1440 
DE: Plasma 5.27.1 
WM: KWin 
Theme: [Plasma], Breeze [GTK2/3] 
Icons: [Plasma], breeze [GTK2/3] 
Terminal: konsole 
CPU: AMD Ryzen 7 2700X (16) @ 4.000GHz 
GPU: AMD ATI Radeon RX 470/480/570/570X/580/580X/590 
Memory: 8645MiB / 15917MiB 

The SDWire v1.4 uses the Microchop USB2640, which is currently supported by another software. How hard would it be to support this version too? I'm not a pythonist, that's why I am asking.

I am using your usb2642eeprom.py command line tool under ubuntu 19.04. Writing of the first 256 bytes works well but my I2C debugger notices that you do not write behind this.

I am aware that the manual clearly states that

The USB-SD-Mux is intended to be directly inserted into the SD card slot of a DUT.

However, we still have quite a lot of boards that only have regular SD card slots, but no microSD one. I did some experimentation and realized that

• a microSD to SD card adapter,
• a SanDisk Ultra microSD card and,
• deactivating high speed mode (broken-mmc-highspeed device tree property)

seems to be a reliable combination to use the USB-SD-Mux within a regular SD card slot.

However, this is a far from ideal situation with respect to ESD and reliability. Hence, I would like to ask if you have any plans to release an alternative USB-SD-Mux hardware version for regular SD card slots? Or do you have any other ideas how this scenario could be supported?

Hi,

Scenario

• Raspberry Pi 4B controls a custom hardware and therefore ejects, updates and injects its SD card via usbsdmux device
• On Raspberry Pi the udev rules are applied as described in this project's docs
• udev rules are working basically, the /dev/sg0 device is owned by root:plugdev when rules get applied manually or after restart
• The pi user is also in the plugdev group

System Information

# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

# cat /proc/cpuinfo
Model           : Raspberry Pi 4 Model B Rev 1.5

Error

Traceback (most recent call last):
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/bin/usbsdmux", line 8, in <module>
    sys.exit(main())
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/lib/python3.9/site-packages/usbsdmux/__main__.py", line 80, in main
    ctl = autoselect_driver(args.sg)
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/lib/python3.9/site-packages/usbsdmux/usbsdmux.py", line 48, in autoselect_driver
    with open(model_filename, "r") as fh:
PermissionError: [Errno 13] Permission denied: '/sys/class/scsi_generic/sg0/device/model'

Context and Explanation

The udev rules provide no access to /sys/class/scsi_generic/sg0/device/model, its owned by root:root, so user space access can't work like that. At least for the symbolic links as described in documentation they are also owned by root:root, but I found that this is possibly correct on linux systems (see here).
Documentation:

$ ls -l /dev/usb-sd-mux/
total 0
lrwxrwxrwx 1 root plugdev 6 Mar 31 11:21 id-000000000042 -> ../sg3
lrwxrwxrwx 1 root plugdev 6 Mar 27 00:33 id-000000000078 -> ../sg2
lrwxrwxrwx 1 root plugdev 6 Mar 24 09:51 id-000000000378 -> ../sg1

On my Raspberry Pi:

$ ls -l /dev/usb-sd-mux/
total 0
lrwxrwxrwx 1 root root 6 Mar 27 23:20 id-000000002002 -> ../sg0

Possible Solutions

• Maybe the udev rules should ensure that the plugdev group has permissions on relevant files, but it doesn't, at least for the PI
• I'd think there need to be another, maybe more manual option to select the correct driver for the device, but preferred would an automated selection, as implementation tries to provide.
• I didn't check yet if there are more things in code like this, otherwise I could imagine to workaround the main() and call the necessary stuff myself from my python scripts, but this package looks like your not interested in providing it as package than as binary program. So I'm not sure, if my workaround would be broken pretty soon. Do you follow the SemVer with your internally used API called from main()?

May you help me with this?