SD-MUX-CTRL(1)

💖 SD-MUX-CTRL 💖 (sd-mux-ctrl) — straight outta the SD MUX User Manual

okay so bestie, sit down, hydrate, put ur phone on do-not-disturb, because today we're controlling multiple sd-mux devices and honestly? it's giving main character energy for your test bench. 🌸

---

✨ NAME ✨

sd-mux-ctrl — the control software for sd-mux devices. that's it. that's the whole vibe. 🎀

---

✨ SYNOPSIS ✨

like, here's how you summon her:

sd-mux-ctrl [-liuortdspcmvexn?] [-l|--list] [-i|--info] [-u|--status]
[-o|--show-serial] [-r|--set-serial=STRING] [-t|--init] [-d|--dut]
[-s|--ts] [-p|--pins=INT] [-c|--tick] [-y|--dyper1=STRING]
[-z|--dyper2=STRING] [-m|--tick-time=INT] [-v|--device-id=INT]
[-e|--device-serial=STRING] [-x|--vendor=INT] [-a|--product=INT]
[-k|--device-type=STRING] [-n|--invert] [-?|--help] [--usage]

---

✨ DESCRIPTION ✨

sd-mux-ctrl is the tool for controlling multiple sd-mux devices. her + the device together support these four actions, no cap:

1. connect the SD card to a DUT (Device Under Test) or to a TS (Test Server)
2. connect one USB port to the DUT or the TS
3. power the connected DUT off/on
4. reset the connected DUT by power-disconnecting and then reconnecting it after a specified timeout

now here's the tea about brand-new devices 🫖 — after manufacturing, every fresh sd-mux device has its VENDOR ID set to 0x0403, which is the ID of FTDI, the company whose chip (FT245RL) the device is based on. before its first real use, the device should be given a unique serial number. to do that, you gotta run the --set-serial command. --set-serial writes additional information, and one of those things is the VENDOR ID. and since then? the device can be used without the --vendor option — which was necessary up until the correct VENDOR ID got set. periodt. 💅

---

✨ OPTIONS ✨

• -m, --tick-time — set the period (in milliseconds) for the --tick command. ⏱️
• -v, --device-id — point at the device to be used with the selected command. the argument for this option is an integer number which is the ID of the wanted device. you can find it in the result of the --list command. this method is not recommended for common usage 😬 because the ID may change after disconnecting and reconnecting devices. it may be helpful in particular situations where the serial number is not a reliable way of addressing the device.
• -e, --device-serial — point at the device to be used with the selected command. the argument is a string which is the serial number of the wanted device. you can find it in the result of the --list command too. this is the recommended way of addressing devices. 👑
• -x, --vendor — set the VENDOR ID of the devices that sd-mux-ctrl is gonna use. default value is 0x04e8, which is assigned to SAMSUNG Electronics Company. and heads up: the default PRODUCT ID is equal to 0x6001 — the default FTDI value.
• -a, --product — set the PRODUCT ID of the devices that sd-mux-ctrl is gonna use. default value is 0x6001.
• -k, --device-type — set the device type of the sd-mux. it can be either "sd-mux" or "sd-wire". this setting is how one type of SD-MUX gets told apart from another. "sd-mux" is the standard, full-sized SD-MUX board type, while "sd-wire" is the miniaturized version of SD-MUX whose functionality is reduced to SD card multiplexing only. 🦋
• -n, --invert — invert the bits given in the argument of the --pins command. useful for debugging purposes. 🐛
• -h, --help — print the short help and exit.
• --usage — print the list of commands and options and exit.

---

✨ COMMANDS ✨

-l, --list

print the list of all connected sd-mux devices and exit. it takes optional --vendor --product arguments that let you use other VENDOR and PRODUCT IDs than the default ones. the default value is 0x04e8:6001, which belongs to SAMSUNG Electronics Company. VENDOR and PRODUCT IDs are what get used to discover all the connected sd-mux devices. this is very important in the post-production (sd-mux device) phase, before first use. 🔍

-i, --info

print detailed information about the selected device (--device-serial). a sample output of this command:

VID:     0x04e8
PID:     0x6001
Release: 0x0600
Bus Powered:  90 mA
Manufacturer: SRPOL
Product:      sd-mux
Serial:       odroid_u3_1
Checksum      : ea57
Internal EEPROM
PNP: 1
Channel A has Mode UART VCP
C0 Function: TXLED
C1 Function: RXLED
C2 Function: TXDEN
C3 Function: PWREN
C4 Function: SLEEP

and ngl, the shape of this output depends on the libftdi library, so it may change along with library changes. not our fault, not our problem, that's just the vibe. 🫶

-u, --status

print the current state of the selected device. example command with output:

$ sd-mux-ctrl --status --device-serial odroid_u3_1
USB connected to: DUT
SD connected to: DUT
$

or, alternatively:

$ sd-mux-ctrl --status --device-serial odroid_u3_1
Device not initialized!
$

that second one is what you get when the device isn't initialized after connecting to a host. 😭

-o, --show-serial

print the serial number of the selected device. use --device-id to select the wanted device. this command outputs only the serial number, without end of line. so it's useful actually only for scripts, bestie — it's a scripting girlie. example command with output:

[sd-mux-ctrl-0.0.1]$ sudo sd-mux-ctrl --device-id=0 --show-serial
minnow_max_1[sd-mux-ctrl-0.0.1]$

see how the prompt is glued to the serial? yeah. no newline. that's the bit. 💀

-r, --set-serial

set the serial number of the selected device. use --device-id or --device-serial to select the wanted device. the following example changes the device's serial number from AL018T40 to odroid_u3_1:

[rpm]$ sudo sd-mux-ctrl --device-serial=AL018T40 --vendor=0x403 --set-serial=odroid_u3_1

and okay, the --set-serial command does actually a little bit more than setting a serial number. it also writes new values of VENDOR ID, Product and Manufacturer. VENDOR ID (VID) gets set to 0x04e8 (SAMSUNG Electronics Company), Product gets set to sd-mux, and Manufacturer gets set to SRPOL — which is a short name of Samsung R&D Poland. so yeah, one command, whole glow-up. ✨

-t, --init

set the connected device into a well defined state. after powering up, an sd-mux device is in a random state. 😵‍💫 the SD card and USB may be connected either to the DUT or to the TS. SD card and USB are not tied together, so one of them may be connected to the DUT while the other one is connected to the TS. all combinations are possible.

the most important thing here is power steering. since we use a bistable, two-coil relay, we have to make sure that in the stable state both coils are disconnected from power. unfortunately, after connecting sd-mux to a USB host, the state of the power control lines is unknown, so we have to set them into the correct one. the init command powers off the DUT and connects USB and SD card to the TS. example:

[rpm]$ sudo sd-mux-ctrl --device-serial=odroid_u3_1 --init

-d, --dut

connect the USB port and SD card to a DUT (Device Under Test) and power it on. after executing this command, the DUT should start and load the image from the SD card mounted in the sd-mux device. 🚀

⚠️ note that some devices won't (re)start after execution of this command. this is caused by the SD multiplexer chip. when SD is connected to TS, then it is actually connected to the USB SD card reader. the reader powers up the SD card and some part of the voltage is transmitted to the DUT through the SD mux chip. to force a restart, one must invoke the --tick command after --dut is executed. Odroid U3 is an example of a device with such behavior. 🙈

$ sudo sd-mux-ctrl --device-serial=odroid_u3_1 --dut
$ sudo sd-mux-ctrl --device-serial=odroid_u3_1 --tick

-s, --ts

connect the USB port and SD card to a TS (Test Server) and power off the DUT (Device Under Test). after executing this command, the SD card is connected to the SD card reader at the TS side.

$ sudo sd-mux-ctrl --device-serial=odroid_u3_1 --ts

-p, --pins

set the FTDI chip (FT245RL) pins to a given state. --pins takes an 8 bit word as an argument, and the optional --invert argument inverts all bits in that given word. this value — after the optional inverting — is written to the FT245RL D0-D7 pins. 🔌

$ sudo sd-mux-ctrl --device-serial=odroid_u3_1 --pins=0x69 --invert

-c, --tick

disconnect power from the Device Under Test and reconnect again after 1000 ms. if --tick-time is used, then that 1000ms gets replaced with the number of milliseconds given in the --tick-time argument. ⏰

$ sudo sd-mux-ctrl --device-serial=odroid_u3_1 --tick --tick-time=2000

-y, --dyper1

disconnect or connect the terminals of the dynamic jumper. the argument "on" connects them, and "off" disconnects them.

$ sudo sd-mux-ctrl --device-serial=odroid_u3_1 --dyper1 on

-z, --dyper2

disconnect or connect the terminals of the dynamic jumper. the argument "on" connects them, and "off" disconnects them.

$ sudo sd-mux-ctrl --device-serial=odroid_u3_1 --dyper2 on

---

✨ AUTHOR ✨

Adam Malinowski <a.malinowsk2@partner.samsung.com>. 🫶

---

✨ REPORTING BUGS ✨

please, report bugs to Adam Malinowski <a.malinowsk2@partner.samsung.com>. don't be shy, he wants to know. 🐛💌

---

and that's the whole page bestie, you ate 💅✨ this one came from the Tizen crew, March 2018 edition of the SD MUX User Manual — go forth and multiplex responsibly. 🎀🦋💖