iPod
19 August 2004

Summary
  • 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
Hints
  • Use the mount point /media/ipod instead of /mnt/ipod (update version 0.85.0-1)
  • 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
    • Look for Oskar Sandberg's sbp2 on 2.6 bugreports
  • Some file locations:
    • cd /sys/bus/ieee1394/devices/fw-host0/
    • cat /proc/bus/ieee1394/devices
    • cat /proc/scsi/scsi
    • cd /sys/devices/
Guides
  • Attaching the iPod
  • Using the iPod
    • use grip to encode to mp3
      • the ipod uses the metatags
      • you should encode MP3 files from an album all together, or else you will lose the album track-numbering information
      • you should use convenient filenames (such as track07.mp3) instead of naming the files after the tracks
    • GtkPod ReadMe
Software
  • Debian
    • easytag or tagtool (for mass tagging)
    • id3v2 (CLI tag editor)
    • libid3tag0
      • Changelog (in .80): Added support for syncing contacts and calendar from existing applications to the iPod (on iTunesDB export and/or via the Tools-menu). The sync is done by calling external scripts. Only one script is included so far: kaddressbook_ipod. Please submit more for inclusion into the next release.
  • iPodSlave
  • ourTunes -- a Java-based implementation of iTunes that lets you download files from a local user group
  • Adam at StoneTable is a high-level hacker working on ipod stuff in Aug 04 -- check out the news
  • The rhythmbox player for Gnome supports the ipod
  • Linux on iPod (the OS)
  • Software list at iPodLounge
  • Mephis has support out of the box as of 10 Aug 2004
Hardware
  • Some iPods have USB2 -- Tord's does not
  • Only some PC firewire ports will charge the iPod (not 4-pin ones)
  • Firewire support is likely more robust with 6-pin ports (but works fine with 4)
Installation history

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.

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