Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Script to automatically download and install rockbox firmware

Re: Script to automatically download and install rockbox firmware

From: Nix <nix_at_esperi.org.uk>
Date: Mon, 14 May 2007 23:06:04 +0100

On 14 May 2007, Menachem Shapiro verbalised:
> I would love to get feedback on the script, as well as any help
> regarding udev integration. I tried different things using
> ATTRS{idProduct} and ATTRS{idVendor}
> [http://www.rockbox.org/twiki/bin/view/Main/DeviceDetection], but it
> is the first time I have ever tried messing around with udev, and I
> couldn't get it to work.

Regarding udev integration, what did you try?

You can determine the right keys to use fairly easily because udev can
tell you most of what to do. Find your device's block device, and try,
e.g.

# udevinfo -a -p /sys/block/sdc

(I have some SCSI disks on this machine so sda and sdb were already
taken; the iPod got sdc).

You get a bunch of output, structured into blocks.

All but the latest udev releases (098 and later) can only match single
blocks (`looking at...' sections) at once, so all the keys have to come
from one block. The key names also differ in udev 098 and later, but the
names given by udevinfo will always be correct for your udev release.

,----
| Udevinfo starts with the device specified by the devpath and then
| walks up the chain of parent devices. It prints for every device
| found, all possible attributes in the udev rules key format.
| A rule to match, can be composed by the attributes of the device
| and the attributes from one single parent device.
|
| looking at device '/block/sdc':
| KERNEL=="sdc"
| SUBSYSTEM=="block"
| DRIVER==""
| ATTR{stat}==" 23044 7258 30475 1022020 3331 1475 660281 40332280 0 1063280 41354300"
| ATTR{size}=="58605120"
| ATTR{removable}=="1"
| ATTR{range}=="16"
| ATTR{dev}=="8:32"

This block (corresponding to the block device itself) is probably not worth matching against.

| looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0/host9/target9:0:0/9:0:0:0':
| KERNELS=="9:0:0:0"
| SUBSYSTEMS=="scsi"
| DRIVERS=="sd"
| ATTRS{ioerr_cnt}=="0x0"
| ATTRS{iodone_cnt}=="0x7af6"
| ATTRS{iorequest_cnt}=="0x7af6"
| ATTRS{iocounterbits}=="32"
| ATTRS{timeout}=="30"
| ATTRS{state}=="running"
| ATTRS{rev}=="1.62"
| ATTRS{model}=="iPod "
| ATTRS{vendor}=="Apple "
| ATTRS{scsi_level}=="0"
| ATTRS{type}=="0"
| ATTRS{queue_type}=="none"
| ATTRS{queue_depth}=="1"
| ATTRS{device_blocked}=="0"
| ATTRS{max_sectors}=="240"

This one looks more interesting: it's the iPod's SCSI interface, and
it's a block device (SUBSYSTEMS=scsi is a bit of a giveaway). It's not
actually a *mountable* device as such, but it owns all the partitions so
a match against it will get fired for all its children (the individual,
mountable partitions) as well. I match against this via

SUBSYSTEMS=="scsi", ATTRS{model}=="iPod", ATTRS{vendor}=="Apple", KERNEL=="sd?2", SYMLINK+="ipod", GROUP="dosdisks"

and, well, bingo, I now have a /dev/ipod symlink. Add a RUN= key to that
and you should be home free. `udevtest' can be useful to see what would happen
if you plugged the iPod in; `udevmonitor' can be useful to spy on udev and
see what *does* happen.

| looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0/host9/target9:0:0':
| KERNELS=="target9:0:0"
| SUBSYSTEMS==""
| DRIVERS==""
|
| looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0/host9':
| KERNELS=="host9"
| SUBSYSTEMS==""
| DRIVERS==""
|
| looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0':
| KERNELS=="1-1:1.0"
| SUBSYSTEMS=="usb"
| DRIVERS=="usb-storage"
| ATTRS{modalias}=="usb:v05ACp1209d0001dc00dsc00dp00ic08isc06ip50"
| ATTRS{bInterfaceProtocol}=="50"
| ATTRS{bInterfaceSubClass}=="06"
| ATTRS{bInterfaceClass}=="08"
| ATTRS{bNumEndpoints}=="02"
| ATTRS{bAlternateSetting}==" 0"
| ATTRS{bInterfaceNumber}=="00"

These blocks are probably also not worth matching on, not least because they
don't correspond to disks, so if you tried to make a SYMLINK to them you'd
get a symlink to a USB endpoint device: not so terribly useful to mount!

| looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1':
| KERNELS=="1-1"
| SUBSYSTEMS=="usb"
| DRIVERS=="usb"
| ATTRS{serial}=="000A27001566DEDA"
| ATTRS{product}=="iPod"
| ATTRS{manufacturer}=="Apple"
| ATTRS{quirks}=="0x0"
| ATTRS{maxchild}=="0"
| ATTRS{version}==" 2.00"
| ATTRS{devnum}=="21"
| ATTRS{speed}=="12"
| ATTRS{bMaxPacketSize0}=="64"
| ATTRS{bNumConfigurations}=="1"
| ATTRS{bDeviceProtocol}=="00"
| ATTRS{bDeviceSubClass}=="00"
| ATTRS{bDeviceClass}=="00"
| ATTRS{bcdDevice}=="0001"
| ATTRS{idProduct}=="1209"
| ATTRS{idVendor}=="05ac"
| ATTRS{bMaxPower}=="500mA"
| ATTRS{bmAttributes}=="c0"
| ATTRS{bConfigurationValue}=="1"
| ATTRS{bNumInterfaces}==" 1"
| ATTRS{configuration}==""

This looks potentially useful, but again, the SUBSYSTEMS is a usb
endpoint. There's no point trying to mount this.

| looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1':
| KERNELS=="usb1"
| SUBSYSTEMS=="usb"
| DRIVERS=="usb"
| ATTRS{serial}=="0000:00:04.2"
| ATTRS{product}=="UHCI Host Controller"
| ATTRS{manufacturer}=="Linux 2.6.21.1-skas3-v9-pre9 uhci_hcd"
| ATTRS{quirks}=="0x0"
| ATTRS{maxchild}=="2"
| ATTRS{version}==" 1.10"
| ATTRS{devnum}=="1"
| ATTRS{speed}=="12"
| ATTRS{bMaxPacketSize0}=="64"
| ATTRS{bNumConfigurations}=="1"
| ATTRS{bDeviceProtocol}=="00"
| ATTRS{bDeviceSubClass}=="00"
| ATTRS{bDeviceClass}=="09"
| ATTRS{bcdDevice}=="0206"
| ATTRS{idProduct}=="0000"
| ATTRS{idVendor}=="0000"
| ATTRS{bMaxPower}==" 0mA"
| ATTRS{bmAttributes}=="e0"
| ATTRS{bConfigurationValue}=="1"
| ATTRS{bNumInterfaces}==" 1"
| ATTRS{configuration}==""
|
| looking at parent device '/devices/pci0000:00/0000:00:04.2':
| KERNELS=="0000:00:04.2"
| SUBSYSTEMS=="pci"
| DRIVERS=="uhci_hcd"
| ATTRS{msi_bus}==""
| ATTRS{broken_parity_status}=="0"
| ATTRS{enable}=="1"
| ATTRS{modalias}=="pci:v00001106d00003038sv00000925sd00001234bc0Csc03i00"
| ATTRS{local_cpus}=="1"
| ATTRS{irq}=="10"
| ATTRS{class}=="0x0c0300"
| ATTRS{subsystem_device}=="0x1234"
| ATTRS{subsystem_vendor}=="0x0925"
| ATTRS{device}=="0x3038"
| ATTRS{vendor}=="0x1106"
|
| looking at parent device '/devices/pci0000:00':
| KERNELS=="pci0000:00"
| SUBSYSTEMS==""
| DRIVERS==""
`----

And by this point you're not even looking at devices on the iPod: these
are host PC devices.

Anyway, I hope you see the general trick of it. It's quite easy to get
used to once you've managed to get a few things working :)

-- 
`In the future, company names will be a 32-character hex string.'
  --- Bruce Schneier on the shortage of company names
Received on 2007-05-15

Page was last modified "Jan 10 2012" The Rockbox Crew
aaa