Part of the whole SD card mux game involves finding the card reader the SD card for a particular board is plugged into.
Following a lead provided by Zygmunt, it seems that you can address devices by USB topology by looking in /sys/bus/usb/devices/ -- for example, the front right USB port on my laptop seems to correspond to a directories called "1-1.2" and "1-1.2:1.0" in here, the back left port corresponds to "3-1" and "3-1:1.0" and a particular port on a USB hub plugged into the front left USB port seems to correspond to "2-1.2.3" and "2-1.2.3:1.0". So this seems to be reasonably straightforward (although I don't know if the mapping is necessarily stable across reboots or kernel upgrades -- seems like it should be though).
The next fun is mapping this directory to a block device. Poking finds that (with the card reader plugged into the last location mentioned above) the directory at:
/sys/bus/usb/devices/2-1.2.3:1.0/host31/target31:0:0/31:0:0:0/block/
contains a directory called 'sdb' and indeed the sd card is mounted as /dev/sdb. Playing around shows that the 31 here is a number that gets incremented each time you plug/unplug the reader (or maybe any USB device). So this suggests that we could address the card reader in this port as "2-1.2.3:1.0" and to e.g. run l-m-c targetting the card in the reader, we should look at
/dev/$(ls /sys/bus/usb/devices/${address}/host*/target*/*:0:0:0/block)
which seems like it would work but frankly also seems like a total hack.
Do any of you know if this can be done in a cleaner way?
Cheers, mwh
On Tue, Apr 24, 2012 at 6:57 AM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Part of the whole SD card mux game involves finding the card reader the SD card for a particular board is plugged into.
Following a lead provided by Zygmunt, it seems that you can address devices by USB topology by looking in /sys/bus/usb/devices/ -- for example, the front right USB port on my laptop seems to correspond to a directories called "1-1.2" and "1-1.2:1.0" in here, the back left port corresponds to "3-1" and "3-1:1.0" and a particular port on a USB hub plugged into the front left USB port seems to correspond to "2-1.2.3" and "2-1.2.3:1.0". So this seems to be reasonably straightforward (although I don't know if the mapping is necessarily stable across reboots or kernel upgrades -- seems like it should be though).
I would think it's very risky to hope that we can identify the ports this way across reboots. I hoped maybe we could identify individual USB controllers across reboots ... in that sense we could plug in one controler for each board... but then checking lsbusb -vv on my two PCI USB controllers I get:
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced H ost Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo Device 21da Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >
SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f262a000 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> Kernel driver in use: ehci_hcd
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo Device 21da Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0 Interrupt: pin A routed to IRQ 23 Region 0: Memory at f2629000 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> Kernel driver in use: ehci_hcd
I cannot spot anything that feels safe to assume staying the same across reboots :/... at best check with the #linaro-kernel friends to get a negative on this idea quick :).
+Zach to see if he's thought about this
On 04/23/2012 11:57 PM, Michael Hudson-Doyle wrote:
Part of the whole SD card mux game involves finding the card reader the SD card for a particular board is plugged into.
Following a lead provided by Zygmunt, it seems that you can address devices by USB topology by looking in /sys/bus/usb/devices/ -- for example, the front right USB port on my laptop seems to correspond to a directories called "1-1.2" and "1-1.2:1.0" in here, the back left port corresponds to "3-1" and "3-1:1.0" and a particular port on a USB hub plugged into the front left USB port seems to correspond to "2-1.2.3" and "2-1.2.3:1.0". So this seems to be reasonably straightforward (although I don't know if the mapping is necessarily stable across reboots or kernel upgrades -- seems like it should be though).
The next fun is mapping this directory to a block device. Poking finds that (with the card reader plugged into the last location mentioned above) the directory at:
/sys/bus/usb/devices/2-1.2.3:1.0/host31/target31:0:0/31:0:0:0/block/contains a directory called 'sdb' and indeed the sd card is mounted as /dev/sdb. Playing around shows that the 31 here is a number that gets incremented each time you plug/unplug the reader (or maybe any USB device). So this suggests that we could address the card reader in this port as "2-1.2.3:1.0" and to e.g. run l-m-c targetting the card in the reader, we should look at
/dev/$(ls /sys/bus/usb/devices/${address}/host*/target*/*:0:0:0/block)
which seems like it would work but frankly also seems like a total hack.
Do any of you know if this can be done in a cleaner way?
Cheers, mwh
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On Tue, Apr 24, 2012 at 4:59 PM, Andy Doan andy.doan@linaro.org wrote:
+Zach to see if he's thought about this
Zach and me talked with many others, many times about this and for roughly the last 6 month there have been many ideas and proposals coming up that didn't do the trick.
Hence, I concur that the only real way - without improving the sd mux to identify itself through something like EPROM (which we don't really want to do) - is to move to a satellite approach in the spirit of zachs pitch on how a box that offers sdcard muxing and power measurement could look like (with some refinements) :).
W dniu 24.04.2012 19:05, Alexander Sack pisze:
On Tue, Apr 24, 2012 at 4:59 PM, Andy Doan andy.doan@linaro.org wrote:
+Zach to see if he's thought about this
Zach and me talked with many others, many times about this and for roughly the last 6 month there have been many ideas and proposals coming up that didn't do the trick.
Hence, I concur that the only real way - without improving the sd mux to identify itself through something like EPROM (which we don't really want to do) - is to move to a satellite approach in the spirit of zachs pitch on how a box that offers sdcard muxing and power measurement could look like (with some refinements) :).
\o/
I'm trying to do that with Arduino (well, I'm just starting given the lack of time) but I think we can do it in under 100€ range for a single device with USB connection to any machine. Arduino has enough resources to manage one slave device (currently doing serial mux + power control).
Thanks ZK
linaro-validation@lists.linaro.org
-
Alexander Sack -
Andy Doan -
Michael Hudson-Doyle -
Zygmunt Krynicki