# HOWTO use iRiver iFP players w/UMS firmware with 2.6 kernel

## Thalion

I thought it was a wise idea to write this 'cause the original thread where the solution was posted is quite long and cluttered with screen dumps and all that. Here is just a simple instruction which will (hopefully) make your player work without the need for ifp-line and other third-party tools.

First, grab the iFP UMS firmware from their website (http://www.iriver.com) if you haven't already. If you use ifp-line, you can perform the upgrade as follows:

```

# ifp firmupdate FIRMWARE.HEX 

```

BE WARNED: if anything goes wrong, you WON'T be able to revert this change from Linux with 2.6 kernel (you simply won't be able to upload the non-UMS firmware on it), so make sure you have a PC with Windows or 2.4-based Linux nearby (or in dual boot).

Now the kernel. Most likely you already have it lying somewhere in /usr/src/linux-2.6.x, with /usr/src/linux symlinked to it. If not, then emerge it (and don't forget to make the symlink!). I've tested the patch with development-sources-2.6.1, so I'm not sure it works with patched versions (gentoo, love or whatever). So if it works for you, tell the others! =)

Here goes the patch. Copy&paste the following code and save it as /usr/src/ifp-ums-2.6.patch:

```

--- linux/include/scsi/scsi_devinfo.h.orig   2004-01-06 01:00:29.000000000 +0100

+++ linux/include/scsi/scsi_devinfo.h   2004-01-06 20:15:50.036892568 +0100

@@ -19,4 +19,5 @@

 #define BLIST_MS_SKIP_PAGE_08   0x2000   /* do not send ms page 0x08 */

 #define BLIST_MS_SKIP_PAGE_3F   0x4000   /* do not send ms page 0x3f */

 #define BLIST_USE_10_BYTE_MS   0x8000   /* use 10 byte ms before 6 byte ms */

+#define BLIST_NORMB        0x10000   /* Known to be not removable */

 #endif

--- linux/drivers/scsi/scsi_scan.c.orig   2004-01-06 01:00:29.000000000 +0100

+++ linux/drivers/scsi/scsi_scan.c   2004-01-06 20:10:19.731106680 +0100

@@ -536,7 +536,8 @@

       sdev->online = FALSE;

    }

 

-   sdev->removable = (0x80 & inq_result[1]) >> 7;

+   sdev->removable = (((0x80 & inq_result[1]) >> 7) &&

+      !(*bflags & BLIST_NORMB));

    sdev->lockable = sdev->removable;

    sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) == 2);

 

--- linux/drivers/scsi/scsi_devinfo.c.orig   2004-01-06 01:00:29.000000000 +0100

+++ linux/drivers/scsi/scsi_devinfo.c   2004-01-06 20:13:46.890613648 +0100

@@ -183,6 +183,7 @@

    {"SGI", "TP9500", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

    {"MYLEX", "DACARMRB", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

    {"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

+   {"iRiver", "iFP Mass Driver", NULL, BLIST_NORMB},

    { NULL, NULL, NULL, 0 },

 };

 

```

Make sure the lines don't wrap. Now open the terminal, go to /usr/src, and from there run:

```

# patch -p0 < ifp-ums-2.6.patch

```

It should not complain (if it does, then either you're doing something wrong or your kernel is not compatible, or maybe you're doing it on 2.6.2 and the kernel guys have already fixed it by then). Then, cd linux, and rebuild and install the kernel as usual (make clean seems to be unneeded). After reboot, you can try to mount your player. It should be the device /dev/sda (note: not /dev/sda1!) if it is the only UMS device plugged. As root, do:

```

# mkdir /mnt/player

# mount /dev/sda /mnt/player

# ls /mnt/player

```

If this doesn't tell you anything about "bad superblock", than it should work from now on.

Hope this helps

----------

## numerodix

I first tried mounting my player without this and I got the superblock error. But the patch wouldn't work, neither with gentoo-dev-sources-2.6.1 nor development-sources-2.6.1-rc1... I always get this output:

```
#  patch -p0 < ifp-ums-2.6.patch 

patching file linux/include/scsi/scsi_devinfo.h

Hunk #1 FAILED at 19.

1 out of 1 hunk FAILED -- saving rejects to file linux/include/scsi/scsi_devinfo.h.rej

patching file linux/drivers/scsi/scsi_scan.c

Hunk #1 FAILED at 536.

1 out of 1 hunk FAILED -- saving rejects to file linux/drivers/scsi/scsi_scan.c.rej

patching file linux/drivers/scsi/scsi_devinfo.c

Hunk #1 FAILED at 183.

1 out of 1 hunk FAILED -- saving rejects to file linux/drivers/scsi/scsi_devinfo.c.rej

```

----------

## Thalion

Are you sure you have /usr/src/linux symlinked to the kernel you 're patching?

Also, try vanilla 2.6.1 final - that's what I tested it on. As I said, I'm not sure gentoo-dev-sources will work.

----------

## numerodix

Yes, I did have that setup at the time of testing. 

Do you know if this is something that might be included in a newer kernel release?

----------

## funkmankey

patch also failed here, against 2.6.2-rc1-mm3 -- dnno why, the source files look similar enough that there should not be a problem.

anyway, I modified the few lines manually, rebuilt, and now my 180T is working just fine as a usb storage device. thanks!

----------

## pilla

Moved from H&L

----------

## tamran

The patch worked on gentoo-dev-sources 2.6.2

----------

## unfo-

I've 2.6.5 kernel from kernel.org and it's worked fine except for 

```
bash-2.05b# patch -p0 < ifp-ums-2.6.patch

patching file linux/include/scsi/scsi_devinfo.h

Hunk #1 FAILED at 19.

1 out of 1 hunk FAILED -- saving rejects to file linux/include/scsi/scsi_devinfo.h.rej

patching file linux/drivers/scsi/scsi_scan.c

Hunk #1 FAILED at 536.

1 out of 1 hunk FAILED -- saving rejects to file linux/drivers/scsi/scsi_scan.c.rej

patching file linux/drivers/scsi/scsi_devinfo.c

Hunk #1 FAILED at 183.

1 out of 1 hunk FAILED -- saving rejects to file linux/drivers/scsi/scsi_devinfo.c.rej

bash-2.05b#
```

I have a iFP-190TC with 1.11 UMS.

I've tried also the trick of changing the '0x10000' to '0x12000' which was mentioned in another thread, but it failed also.

when I plug the device in tail -f /var/log/messages shows:

```

Apr 20 23:02:52 baileys Attached scsi removable disk sda at scsi2, channel 0, id 0, lun 0

Apr 20 23:02:52 baileys Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0,  type 0

Apr 20 23:02:52 baileys usb-storage: queuecommand called

Apr 20 23:02:52 baileys usb-storage: *** thread awakened.

Apr 20 23:02:52 baileys usb-storage: Bad LUN (0:1)

Apr 20 23:02:52 baileys usb-storage: scsi cmd done, result=0x40000

Apr 20 23:02:52 baileys usb-storage: *** thread sleeping.

... [[This continues from Bad LUN (0:1)  to Bad LUN (0:7)]]

Apr 20 23:02:52 baileys USB Mass Storage device found at 4

```

And when I try to mount:

```

bash-2.05b# mount -t vfat /dev/sda /mnt/usb

mount: /dev/sda: can't read superblock

```

I've built most SCSI-related things, which could remotely relate to USB-devices, as modules and also most of the USB-support is built into the kernel.

Any suggestions?

// unfo-

----------

## mank

Here's how I got the wonderful iFP-390T working  as USB Mass Storage  :Smile: 

ISSUE 1: Iriver's iFP-390T does not work with kernel-2.6 out of the box due to some issues with current SCSI/USB code in kernel 2.6

The error I got was: 'Unable to read device/partition'

To resolve this issue apply the patch below on kernel 2.6. Recompile the kernel with scsi-emulation/USB etc.

```

--- linux/include/scsi/scsi_devinfo.h.orig   2004-01-13 04:03:19.000000000 +0100

+++ linux/include/scsi/scsi_devinfo.h   2004-01-13 04:12:19.509266640 +0100

@@ -19,4 +19,5 @@

 #define BLIST_MS_SKIP_PAGE_08   0x2000   /* do not send ms page 0x08 */

 #define BLIST_MS_SKIP_PAGE_3F   0x4000   /* do not send ms page 0x3f */

 #define BLIST_USE_10_BYTE_MS   0x8000   /* use 10 byte ms before 6 byte ms */

+#define BLIST_NORMB               0x10000 /* Known to be not removable */

 #endif

--- linux/drivers/scsi/scsi_scan.c.orig   2004-01-13 04:03:19.000000000 +0100

+++ linux/drivers/scsi/scsi_scan.c   2004-01-13 04:13:07.728936136 +0100

@@ -536,7 +536,8 @@

       sdev->online = FALSE;

    }

 

-   sdev->removable = (0x80 & inq_result[1]) >> 7;

+   sdev->removable = (((0x80 & inq_result[1]) >> 7) &&

+      !(*bflags & BLIST_NORMB));

    sdev->lockable = sdev->removable;

    sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) == 2);

 

--- linux/drivers/scsi/scsi_devinfo.c.orig   2004-01-13 04:03:19.000000000 +0100

+++ linux/drivers/scsi/scsi_devinfo.c   2004-01-13 04:13:40.591940200 +0100

@@ -183,6 +183,7 @@

    {"SGI", "TP9500", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

    {"MYLEX", "DACARMRB", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

    {"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

+   {"iRiver", "iFP Mass Driver", NULL, BLIST_NORMB},

    { NULL, NULL, NULL, 0 },

 };

```

To apply this patch, copy the above code to file 'filename.patch' and save the file in /usr/src. Then issue the following command: patch -p0 < filename.patch

Boot with the new kernel.

ISSUE 2: After I got iFP to mount properly, all I could see inside the FS was junk characters. 

This is believe is due to non-standard FAT partition. 

To resolve this, delete all the partitions in iFP with gnu fdisk and recreate a VFAT partition with gnu fdisk. Next, format this partition with mkfs.vfat (use -I option).

--mank

Please note that I used iFP-390T on kernel-2.6.4 and have played with iFP for only an hour.

----------

## numerodix

Has anyone else had noticed that sometimes when you replace your songs with new one, the new songs will occasionally switch the the old songs (in the middle of playback) that are supposed to have been erased? Apparently sometimes overwriting files isn't entirely successful and the files "underneath" still remain in part. I'm speculating on the reason here but what else could it be?

Anyway, I've been using mostly linux lately and I can't quite say if that might be it but it certainly has been trying to get the player to connect properly, it seems windows handles the fat filesystems a lot better. Speaking of fs, is it supposed to be fat or fat32?

Anyway, to remedy this fragmentation problem I tried erasing the whole memory with a simple

dd if=/dev/zero of=/dev/sda bs=1024k

which writes zero's on the drive. I then copied file onto it and so far no anomalies but I would hate to find out I have to do this everytime I want to replace my songs.

----------

## unfo-

 *mank wrote:*   

> 
> 
> To resolve this issue apply the patch below on kernel 2.6. Recompile the kernel with scsi-emulation/USB etc.
> 
> ```
> ...

 

As I pointed in my posting, I've tried this patch and it resolved in errors and I've yet to have gotten this to work  :Sad: 

----------

## unfo-

I got my iRiver functioning with my 2.6.5 kernel when I edited the files mentioned in the patch manually.

I just added the {"iRiver..... line to the end of the list and changed those other things in the appropriate lines.

make & boot & onto happiness  :Smile: 

thanks a bunch all

----------

## fasaxc

Just filed a bug report for this problem. Hopefully we wont have to patch any more. https://bugs.gentoo.org/show_bug.cgi?id=56802

-Shaun

----------

## fasaxc

Here's how to fix if you get gibberish files on the player. (after patching the kernel)

WARNING: you will lose all the data on the player

First log out of kde etc and drop to a console (this ensures no program is accessing the player while we format it). And su to root. 

```
su
```

If you have the player mounted say in /mnt/player/ then unmount it now

```
 umount /mnt/player 
```

Now be sure you know which device node your player is connected to, if you have no scsi or other usb disks connected it will most likely be /dev/sda. The following will tell you what sd? devices are connected. 

```
 cd /dev/ && ls sd* 
```

The one we're looking for will just be sda, sdb or sdc etc. There will be no accompanying sda1, sda2 etc.

Now assuming sda is the correct node we need to run fdisk to delete the partitions on the disk.

```
fdisk /dev/sda
```

Press d then enter then 1 to delete partition 1 then

Press d then enter then 2 to delete partition 2 then

Press d then enter then 3 to delete partition 1 then

Press d then enter to delete partition 4

then press w then enter to exit.

Now run cfdisk to create the new partition

```
cfdisk /dev/sda
```

Select new with the arrow keys and enter, then 'Primary' and I think leave  the size as is. 

Select 'TYPE' and checge to 06 (ie FAT16)

Select 'write' to write and exit the program.

Now run mkfs.vfat to make a new file system on the disk (emerge sys-fs/dosfstools). (the -I is neccessary to make mkfs treat the sda node as if it were a sda1 node which is the usual convention for partitions)

```
mkfs.vfat /dev/sda -I
```

Now mount the file system straight away (assuming /mnt/player exists), move to it's folder and create the tuner and voice folders. Then unmount again

```
mount /dev/sda /mnt/player

cd /mnt/player

mkdir tuner

mkdir voice

cd /

umount /mnt/player
```

Now remove the player and reattatch to see if it all worked.

On a side note -- if you use udev you can reconfigure your device nodes so the player always appears as say /dev/iriver-player even if you have several usb drives installed eg a dig. camera, card reader etc.

See http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html#lilogrub

for how to enable udev.

Then put this in /etc/udev/rules.d/10-local.rules

```
# IRiver

BUS="scsi", SYSFS{model}="iFP Mass Driver", KERNEL="sd?", NAME="%k", SYMLINK="iriver-player%n"
```

----------

## CybeRDukE

Hi,

i just want to mention that 2 days ago, the ums firmware with OGG has been released.

and i created a patch for the current gentoo-dev-sources (2.6.7-r12). here we go

```
diff -Nru linux-2.6.7-gentoo-r12.org/drivers/scsi/scsi_devinfo.c linux/drivers/scsi/scsi_devinfo.c

--- linux-2.6.7-gentoo-r12.org/drivers/scsi/scsi_devinfo.c      2004-08-07 23:20:29.000000000 +0200

+++ linux/drivers/scsi/scsi_devinfo.c   2004-08-07 23:44:39.535972056 +0200

@@ -155,6 +155,7 @@

        {"IOMEGA", "Io20S         *F", NULL, BLIST_KEY},

        {"INSITE", "Floptical   F*8I", NULL, BLIST_KEY},

        {"INSITE", "I325VM", NULL, BLIST_KEY},

+        {"iRiver", "iFP Mass Driver", NULL, BLIST_NORMB},

        {"LASOUND", "CDX7405", "3.10", BLIST_MAX5LUN | BLIST_SINGLELUN},

        {"MATSHITA", "PD-1", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},

        {"Medion", "Flash XL  MMC/SD", "2.6D", BLIST_FORCELUN},

diff -Nru linux-2.6.7-gentoo-r12.org/drivers/scsi/scsi_scan.c linux/drivers/scsi/scsi_scan.c

--- linux-2.6.7-gentoo-r12.org/drivers/scsi/scsi_scan.c 2004-08-07 23:20:29.000000000 +0200

+++ linux/drivers/scsi/scsi_scan.c      2004-08-07 23:43:54.629798832 +0200

@@ -565,7 +565,7 @@

         */ 

 

        sdev->inq_periph_qual = (inq_result[0] >> 5) & 7;

-       sdev->removable = (0x80 & inq_result[1]) >> 7;

+       sdev->removable = (((0x80 & inq_result[1]) >> 7) && !(*bflags & BLIST_NORMB));

        sdev->lockable = sdev->removable;

        sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) == 2);

 

diff -Nru linux-2.6.7-gentoo-r12.org/include/scsi/scsi_devinfo.h linux/include/scsi/scsi_devinfo.h

--- linux-2.6.7-gentoo-r12.org/include/scsi/scsi_devinfo.h      2004-08-07 23:20:29.000000000 +0200

+++ linux/include/scsi/scsi_devinfo.h   2004-08-07 23:42:45.819259624 +0200

@@ -24,4 +24,5 @@

 #define BLIST_REPORTLUN2       0x20000 /* try REPORT_LUNS even for SCSI-2 devs

                                           (if HBA supports more than 8 LUNs) */

 #define BLIST_NOREPORTLUN      0x40000 /* don't try REPORT_LUNS scan (SCSI-3 devs) */

+#define BLIST_NORMB             0x80000 /* Known to be not removable */

 #endif

```

i had to assign a new value for the BLIST_NORMB definition, but seems to work here.

now have fun using ogg and linux   :Razz: 

----------

## gazoombo

Yay!!

The earlier patch had been getting rejected for a while, and I didn't have time to manually fix it. Thanks for the new patch, and the heads-up on the new firmware I've been waiting for.  :Very Happy: 

----------

## PinkyDaemon

Just for you to know: With kernel linux-2.6.8-gentoo-r3 the player seems to be detected correctly as /dev/sda without patching. I had the same playback-problems as stated below (player skips to old songs which are supposed to be deleted). A solution seems to be the "sync" option in the fstab file (slow but seems to work perfectly)

prost,

PinkyDaemon

----------

## gazoombo

Yes, 2.6.8 added support for this device (finally!). When I mount it I always manually sync it before unmounting, just in case.

----------

## Estariel

hi... i have it somewhat working but need some advice... (ifp 390 T)

i use a 2.6.8 kernel so i didn't have to patch it.

if i plug in the device for the first time after a reboot, it gets detected correctly (dmesg says that). I can then mount it and transfer songs to it. 

Now i have two problems: 

- Some OGG files encoded at quality 7 only play for about 12 seconds on the player. the player will then play the next song.

I assume there is some highest possible bitrate and my q7 songs have a higher bitrate than that. Is there some way to convert them to Q4? i don't want to have to insert each CD again...

- I cannot unmount the player. the system always states that the dive was "busy". Thus, i have to just plug it off.

If i try to reattach the player, it doesn't get recoginzed any more. (dmesg doesn't show a thing, but the /dev/sda device node vanishes)

I have to reboot the system to be able to reattach the player. this is my biggest problem, so please help me there...

thanks!

----------

## Sastraxi

Try something like ogg123 | oggenc?

----------

## gazoombo

About the unmounting, make sure that no users are 'in' or browsing the mounted filesystem. Also you may have to wait for the drive to sync when you unmount (USB 1.1 takes a while to xfer data).

----------

## kamagurka

i always thought iRiver players were simply recognised as generic USB Mass Storage; why all this higgelty piggelty?

also, why would i need special firmware?

----------

## kpoman

hi all!

i am running linux 2.6.8.1-mm4, and it worked great (wasn't working with previous kernels) so it rocks !!!

but  have a question, because i want to upgrade the firmware; last time i upgraded my firmware, i found out that the new one wouldnt allow "line-in" recording with 96kbps or higher ! that sucks !!! 

i think they did that to disallow piracy; but it is a very bad idea, because i use my iriver to record my music group and i want higher quality (256kbps) so, i dont know if i should upgrade to the last one (ums + ogg + mp3) ... 

can someone tell me please what is the higher bitrate i can set when using line-in ?

thanks a lot (dont wanna upgrade then downgrade, last time i did i almost killed my player)

----------

## badchien

 *kamagurka wrote:*   

> i always thought iRiver players were simply recognised as generic USB Mass Storage; why all this higgelty piggelty?
> 
> also, why would i need special firmware?

 I think it depends on the model. My iFP390T came with "Managed" firmware meaning you can only upload/download files to it using an iriver provided app in windows or mac os.   Also for both managed and UMS there is either the MP3/WMA/ASF version or the MP3/OGG version because the player can't support all the formats at once. I switched to the UMS MP3/OGG firmware which makes the device behave like any other UMS device and therefore makes it accessible in Linux so I can upload my OGGs.

 *kpoman wrote:*   

> hi all!...
> 
> can someone tell me please what is the higher bitrate i can set when using line-in ?

 I don't think you said which model you have? Anyway I have a iFP390T with the latest UMS-OGG firmware (v1.22) from 06 August 2004 and I can confirm that the line-in bitrate is limited to no higher than 96kbs for 44.1MHz. I haven't used line-in recording yet, but I agree, this sucks.

----------

## kpoman

yes, what a lame tech solution for disallowing mp3 piracy; they really badly suck for that :/

we just have to keep with the old firmware in order to record "decently" ... REVOLUTION NOW !!!

----------

## gazoombo

From the UMS 1.11 firmware changelog:

 *Quote:*   

> To decrease the distortion of the recorded sounds files (i.e. Voice Recording file, FM Radio file and Line-In Recording), the highest bit rate has been limited to 96Kbps. It will be upgraded through firmware upgrade in the future. 
> 
> 

 

They have good reason for doing this (not to stop piracy silly), but apparently haven't gotten around to fixing it yet.

----------

