USB iPod
27 August 2005

Summary
  • Tord's new USB iPod attaches like a USB hard drive
  • Should be automated using udev and hotplug
  • Make sure it mounts using ehci-hcd
Guides
    • use grip to encode to mp3
      • the ipod uses the metatags
      • encode MP3 files from an album all together
        • otherwise you'll lose the album track-numbering information
      • use short filenames (such as track07.mp3)
        • don't name the files after the tracks
    • for bulk tagging, use easytag or tagtool
    • GtkPod ReadMe
      • uses /media/ipod instead of /mnt/ipod
    Software

    Installation history

    20 August 2004: how to connect a firewire iPod

    Summary, hints, guides, and software
    • Attaches on "modprobe ieee1394 && modprobe ohci1394"
    • Gtkpod mounts it and copies mp3 files with id3 tags and integrates them
    • Quit gtkpod to unmount before detaching and unplugging
    • Detaches on "rmmod sbp2 ohci1394 ieee1394 sd_mod scsi_mod"
    • Unplug the iPod before reattaching to allow it to reset

    • Permutations don't work -- the order of module insertion and removal must be followed
      • Successive mounts and unmounts tend to produce a noncooperative condition
      • Gtkpod has no problems mounting the device once it's attached
      • .gtkpod/gtkpod.in and gtkpod.out can be used to automate the attachment process
    • Sigillo does not use hotplug in SysV (see details), and has input core support modularized
      • Said about 2.4 but may apply to 2.6: "The entire firewire system in the kernel is more stable if all of your 'Input Core Support' (keyboard/ mouse/ all of it) stuff is modularized"
    • To reset iPod, switch hold button to HOLD, wait 5s, switch hold off, press menu and play buttons for few secons
    • "Sometime I have to reboot computer, not sure what's going on but even if I unload and reload all the relevant modules it cannot connect again (rescanning scsi doesn't find the disk), when I reboot it works OK..."
    • "Did you put the ipod in the dock or did you connect it using just the firewire?"
    • Linux IEEE 1394 user discussion list
    • Linux IEEE 1394 development list
    • Some file locations:
      • cd /sys/bus/ieee1394/devices/fw-host0/
      • cat /proc/bus/ieee1394/devices
      • cat /proc/scsi/scsi
      • cd /sys/devices/

    19 August 2004: copying over mp3 files

    After mounting the iPod (see below), I started gtkpod and told it the ipod is mounted on /mnt/ipod. In the gtkpod configuration I left the option of letting gtkpod handle mounting and unmounting of the ipod unchecked.

    On opening the ipod with gtkpod I got an error message saying that the file iPod_Control/iTunes/iTunesDB.ext could not be read, and that gtkpod therefore will not be using extended attributes. However, in my .gtkpod directory, that file is present.

    To copy from the iPod to harddrive, make sure you use "%a/%A/%T - %t.m4a" -- watch the caps.

    The iPodSlave page emphasizes that mp3 files destined for the iPod need id3 values for artist, album, title and tracknum. You can use a load of programs to set id3 tags; in principle xmms should do it one by one, but it failed for me.

    You can use xmms to enter mp3 tags -- just right-click on the song in the playlist and save.

    I used id3v2 like this (tagtool is simpler):
    General:
    man id3v2
    id3v2 -L   (list genres)
    Bulk:
    id3v2 -a "Colin Farish" *.mp3     (artist)
    id3v2 -A "By the Sound" *.mp3   (album)
    id3v2 -y 1998 *.mp3 (year)
    id3v2 -g 8 *.mp3 (genre jazz)
    id3v2 -a "Colin Farish" -A "By the Sound" -y 1998 -g 8 *.mp3 (combined)
    Individually:
    id3v2 -t "Song 01" track-01.mp3  (title)
    id3v2 -T 01 track-01.mp3   (track number -- mandatory!)
    id3v2 -t "Song 01" -T 01 track_01.mp3 (combined)
    I then pressed "Sync" in gtkpod and the files copied and integrated into the iPod. I tested afterwards that the file played fine -- no problems! The sound quality possibly seemed a bit iffy -- sounds better on Sigillo?

    19 August 2004: Attachment

    This is what you should be seeing:
    sbp2: $Rev: 1219 $ Ben Collins <[EMAIL PROTECTED]>
    ieee1394: raw1394: /dev/raw1394 device initialized
    ieee1394: Node added: ID:BUS[0-00:1023]  GUID[000a27000266158c]
    ieee1394: Node changed: 0-00:1023 -> 0-01:1023
    scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
    ieee1394: sbp2: Logged into SBP-2 device
    ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
      Vendor: Apple     Model: iPod              Rev: 1.50
      Type:   Direct-Access                      ANSI SCSI revision: 02
    sda: Spinning up disk.....ready
    SCSI device sda: 39063024 512-byte hdwr sectors (20000 MB)
    sda: test WP failed, assume Write Enabled
    sda: asking for cache data failed
    sda: assuming drive cache: write through
     sda: [mac] sda1 sda2 sda3
    Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
    Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
    Tord lent me the iPod to try on Sigillo, which now has hotplug turned off so I can control each step.

    I began by turning the iPod on and plugging it into the firewire port on Sigillo, without using the dock. I then issued as follows and monitored syslog with "tail -f /var/log/syslog":
    • modprobe ieee1394
      • Aug 19 13:58:19 sigillo kernel: ieee1394: Initialized config rom entry `ip1394'
    • modprobe ohci1394
      • Aug 19 14:00:56 sigillo kernel: ohci1394: fw-host0: OHCI-1394 1.1 
             (PCI): IRQ=[11]  MMIO=[e8002800-e8002fff]  Max Packet=[2048]
      Aug 19 14:00:57 sigillo kernel: ieee1394: Node added: ID:BUS[0-00:1023]  GUID[000a2700020befb2]
      Aug 19 14:00:57 sigillo kernel: ieee1394: Host added: ID:BUS[0-01:1023]  GUID[00c09f0000054c57]
      Aug 19 14:00:58 sigillo ieee1394.agent[1479]: ... no drivers for IEEE1394 
              product 0x000000/0x00005e/0x000001
      Aug 19 14:00:58 sigillo kernel: SCSI subsystem initialized
      Aug 19 14:00:58 sigillo kernel: sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
      Aug 19 14:00:58 sigillo kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
      Aug 19 14:00:59 sigillo kernel: ieee1394: sbp2: Logged into SBP-2 device
      Aug 19 14:00:59 sigillo kernel: ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
      Aug 19 14:00:59 sigillo ieee1394.agent[1455]:      sbp2: loaded sucessfully
      Aug 19 14:00:59 sigillo kernel:   Vendor: Apple     Model: iPod              Rev: 1.50
      Aug 19 14:00:59 sigillo kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
      Aug 19 14:00:59 sigillo scsi.agent[1505]: disk at /devices/pci0000:00/0000:00:0c.0/
             fw-host0/000a2700020befb2/000a2700020befb2-0/host0/0:0:0:0
      Aug 19 14:01:02 sigillo kernel: sda: Spinning up disk....ready
      Aug 19 14:01:02 sigillo kernel: SCSI device sda: 58595040 512-byte hdwr sectors (30001 MB)
      Aug 19 14:01:02 sigillo kernel: sda: test WP failed, assume Write Enabled
      Aug 19 14:01:02 sigillo kernel: sda: asking for cache data failed
      Aug 19 14:01:02 sigillo kernel: sda: assuming drive cache: write through
      Aug 19 14:01:02 sigillo kernel:  sda: sda1 sda2
      Aug 19 14:01:02 sigillo kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
    Wow. First try, from a live, running machine -- that's all it took! The sbp2 module loaded automatically with ohci1394, and the device was detected as an iPod and placed on sda1 and sda2. Of course this is in part thanks to the careful work I did of eliminating hotplug to prepare the ground for this.

    I created a /mnt/ipod directory and added this line to /etc/fstab:
    /dev/sda2  /mnt/ipod       vfat     defaults,uid=steen,gid=users,umask=000,noauto       0      0
    I issued
    mount /mnt/ipod
    and the ipod mounted; I verified the files were visible.

    After using gtkpod to copy files to the iPod, I issued
    umount /mnt/ipod
    The device unmounted with no complaints. I then issued,
    rmmod sbp2
    I guess I could have removed ieee1398 instead, or ohci1394. The iPod got a check mark for safe disconnect and syslog says,
    Aug 19 15:35:22 sigillo kernel: ieee1394: sbp2: Logged out of SBP-2 device
    So not a single problem.

    16 Auguest 2004 -- first attempts on muhammed

    Tord first plugged in the iPod and sent me the following error messages:
    ieee1394: Initialized config rom entry `ip1394'
    ohci1394: $Rev: 1223 $ Ben Collins <bcollins@debian.org>
    PCI: Found IRQ 11 for device 0000:02:01.2
    PCI: Sharing IRQ 11 with 0000:02:01.0
    PCI: Sharing IRQ 11 with 0000:02:01.1
    ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11]  MMIO=[f8fff000-f8fff7ff]  Max Packet=[2048]
    ohci1394: fw-host0: SelfID is inconsistent [0xffff008f/0xffc1ffff]
    ohci1394: fw-host0: SelfID is inconsistent [0xf0000200/0x606f1024]
    ohci1394: fw-host0: SelfID is inconsistent [0xb823c03f/0xc48006f1]
    ieee1394: SelfIDs failed root check
    ieee1394: Error in SelfID stage, resetting
    ieee1394: Error parsing configrom for node 0-00:1023
    ieee1394: Error parsing configrom for node 0-01:1023
    ieee1394: Host added: ID:BUS[0-00:1023]  GUID[374fc0002c79c410]
    ip1394: $Rev: 1224 $ Ben Collins <bcollins@debian.org>
    ip1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
    Although the ieee1394 module loads correctly, followed by the ohci1394 module, the latter fails to locate the firewire device correctly, giving a "SelfID is inconsistent" error.  That error is passed back to ieee1494, which ends up adding a host, but it's no use -- it's the ohci1394 that needs to see the device, and load sbp2. The host that is added is non-functional, afaics -- 
    ID:BUS[0-00:1023]  GUID[374fc0002c79c410]
    Is this a firewire device, but lacking the glue to SCSI?

    Here's my remote attempt -- Tord left the iPod plugged in and I found the following error messages:
    Aug 16 16:07:27 muhammed kernel: ieee1394: Initialized config rom entry `ip1394'
    Aug 16 16:07:27 muhammed kernel: SCSI subsystem initialized
    Aug 16 16:07:27 muhammed kernel: sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
    Aug 16 16:07:27 muhammed kernel: ohci1394: $Rev: 1223 $ Ben Collins <bcollins@debian.org>
    Aug 16 16:07:27 muhammed kernel: PCI: Found IRQ 11 for device 0000:02:01.2
    Aug 16 16:07:27 muhammed kernel: PCI: Found IRQ 11 for device 0000:02:01.2
    Aug 16 16:07:27 muhammed kernel: PCI: Sharing IRQ 11 with 0000:02:01.0
    Aug 16 16:07:27 muhammed kernel: PCI: Sharing IRQ 11 with 0000:02:01.1
    Aug 16 16:07:27 muhammed kernel: ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11]  MMIO=[f8fff$
    Aug 16 16:07:27 muhammed kernel: ieee1394: Host added: ID:BUS[0-00:1023]  GUID[374fc0002c79c410]
    Aug 16 16:07:27 muhammed kernel: ip1394: $Rev: 1224 $ Ben Collins <bcollins@debian.org>
    Aug 16 16:07:27 muhammed kernel: ip1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
    In this case, since muhammed was hotplugged, the modules load in the wrong sequence. First ieee1394 loads (correctly), but then the SCSI subsystem is loaded at once and sbp2 loads before ohci1394 -- resulting in the latter not acting as a glue between the SCSI and the firewire. A device does get attached -- the same one as above:
     ID:BUS[0-00:1023]  GUID[374fc0002c79c410]
    I found it on the /sys bus, first as a symlink in /sys/class/ieee1394:
    root@muhammed:/sys/class/ieee1394/374fc0002c79c410-0# l
    totalt 0
    lrwxrwxrwx  1 root root 0 2004-08-16 16:07 device -> 
    ../../../devices/pci0000:00/0000:00:1e.0/0000:02:01.2/fw-host0/374fc0002c79c410/374fc0002c79c410-0

    So the device itself is on /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.2/fw-host0/374fc0002c79c410/374fc0002c79c410-0 and contains the directory /device/ with these two files (and some others with zeroes?):
    cat device/specifier_id
    0x00005e

    cat /device/version
    0x000001
    Perhaps not terribly exciting. I unloaded sbp2 (but not ohci1394 or ieee1394) and tried to reload it with the suggested values:
    modprobe sbp2 sbp2_force_inquiry_hack=1

    Aug 16 17:48:45 muhammed kernel: sbp2: Unknown parameter `sbp2_force_inquiry_hack'
    Aug 16 17:48:45 muhammed kernel: sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
    It may be that sbp2 could still be loaded with these parameters if the order of modules is respected:
    Load modules in this order: ieee1394 ohci1394 spb2
    However, I didn't have to load sbp2 at all on Sigillo (see 19 August above). What you ran into here was that hotplug loads the modules in the wrong order; you could bugreport it.

    Software details

    iPodSlave
    an iPod IO slave

    home page and 0.6.1 announcement (15 aug 04):

    This release fixes build problems. Thanks to Pagz and jbaehr for their help. It also enhances compatibility with krusader: utilities will now get executed on double-click.

    This ioslave enables KIO aware apps like konqueror or amarok to access the Music stored on an Apple iPod. It further allows you to organize playlists.

    To have access to your iPod mount it (some distros do this automatically when the iPod gets plugged in) and open the URL "ipod:/". You'll get a list of 3 directories: Artists, Playlists and Utilities.

    You can copy songs from an Album to a playlist, move tracks between playlists or albums. You can also add new mp3 files to the collection. Be aware though that the changes you make aren't saved automatically to your iPod's database - use the "Synchronize" utility under ipod:/Utilities for this. Make sure though you have a backup copy of your original iTunesDB file. This file can be found under iPod_Control/iTunes/iTunesDB in the directory struture of your iPod. If you open the Synchronize utility it'll provide a link to this file that you just can drag and drop to a save place.



    		  

     

    CogWeb