Rockbox with 128GB and 256GB SSD drives (iAudio X5 and others)

[sixthofmay]

I searched here and the IRC archives and found that stock Rockbox supports 28bit addressing and that to support > 128GB that LBA48 support needs to be compiled into Rockbox, and also possibly into the bootloader. I also found that for your PC to see > 128GB via the USB connection, that the USB to ATA bridge chip in the player must support LBA48. Not having a LBA48 bridge, it is possible to compile in support for multiple partitions, transfer files to the partition visible to your PC (?), and then use the copy/paste functions within Rockbox on your player to get your files into the other partition(s).

Someone correct me if the above is incorrect.

In my case, I would like to get a 128GB or 256GB SSD into a Cowon iAudio X5. I currently run one with the Martwin adapter and 32GB Kingston compact flash and I've filled it up with FLAC rips. I like flash memory because of the greatly extended runtimes I get.

Photofast has recently released 128GB and 256GB 1.8" 5mm thick PATA IDE 50 pin Toshiba style interface SSDs (they also have zif versions):
http://www.photofastuk.com/engine/shop/category/G-Monster+1.8+50pin+IDE+V4

According to the wiki, the X5 uses a CY7C68310 USB to ATA bridge:
http://www.rockbox.org/wiki/pub/Main/DataSheets/CY7C68310.pdf

In the datasheet I found on page 4 "ATA/ATAPI-6 specification-compliant–provides support for mass storage devices larger than 137GB", which suggests to me that the X5 does indeed have LBA48 support, so multiple partitions wouldn't be needed. Correct?

To use the 128GB SSD, it should work with the stock Rockbox build.
To use the 256GB SSD, a X5 Rockbox build with LBA48 support would be needed.
Correct?

I would like to get 256GB into the X5, but have no experience with creating Rockbox builds. I do have programming experience on the PC and various microcontrollers, and I'll do the necessary research and reading, but does anyone have any tips? Especially about if the bootloader needs to be modified. I don't want to brick my X5...

My starting point in the learning curve:
http://www.rockbox.org/wiki/BigDisk

[torne]

Yup, all looks right

Building Rockbox is not difficult (there are step-by-step instructions on the wiki) and enabling LBA48 is a one line change.

I don't think you can brick the X5, at least not without really trying to. The built in bootloader has a USB mode which can be used to recover from a bad Rockbox image or Rockbox bootloader.

[sixthofmay]

Ok thanks for the info, and a big thank you to all the developers of Rockbox. What you all have created is mostly magic to me and Rockbox has greatly expanded my portable listening experience.

After much reading and some hair pulling (newbie figuring out vmware, linux, svn usage and compiling, and the somewhat undocumented scramble command for making the bootloader file work), I have a 256GB Photofast SSD working in my X5 using #define HAVE_LBA48 in iaudiox5.h.

But I'm having an issue with disk spindown. After it spinsdown, it takes 18 seconds to spin back up should I select a different audio track from the file browser or skip to the  next track. Interestingly, playback of a whole album folder is without any pauses between tracks or within songs.

So the issue seems to happen when it's spundown and starting a track from the file browser or skipping to the next. I have watched the buffers on the debug screen while playing, and I can see that it refills the usefl buffer immediately when it gets low. So something different is happening when spinning back up from the file browser, than when spinning up to refill the buffer.

Also the issue happens on just navigating folders if directory caching is disabled. It also manifests itself on shutdown, which takes 18 seconds before it'll continue the shutdown. Sometimes it hits the 20 second shutdown time limit (saw that limit in one of the source files), and Rockbox forces a hard shutdown (I know this because a loud pop occurs when an ungraceful shutdown happens).

And finally I suspect it's happening on bootup, as the bootloader hangs (after displaying the battery voltage) for 18 seconds. It's not really an issue since I only boot up once a day typically, but may be another clue in solving the puzzle.

If you want to easily experience the issue (with a CF or SSD modded X5), disable directory caching, set the spindown time to 3 seconds, and wait more than 3 seconds when navigating between folder levels or starting songs playing. Painful it is..

Anyway... I have partially fixed it by setting the spindown to 254 seconds, but would like to completely disable spindown.

BTW, I have the same issue on the two X5 compact flash conversions I've done (Kingston Elite Pro 16GB and 32GB). I set spindown to 254 seconds with directory caching enabled on both those and it was tolerable because the delay was only 5 seconds.

I'm posting all this not to criticize, but with the hope that it'll help track down the issue, what with more and more folks doing these sorts of upgrades.

After studying the IRC chat archives, it looks like adding this to my iaudiox5.h would disable spindown:
#define HAVE_FLASH_STORAGE

I'm I on the right path?

Edit:
Ok I tried it.. that was ugly. Bunch of errors during the compile..
I use Notepad++ for editing and had it show all characters to ensure only a LF was added at the end of the line.

If I take the #define HAVE_FLASH_STORAGE line out, then make clean, run the ../tools/configure again selecting 30 for the X5 and a Normal build, then make, it builds ok (minus the change I want).

As a sanity check, I added the #define HAVE_FLASH_STORAGE back in and repeated the above, and it repeated back all the errors.

Here's a sample and the full output is in the attached file:
CC apps/settings.c
CC apps/settings_list.c
/home/user/rbt/apps/settings_list.c:861: error: `LANG_MP3BUFFER_MARGIN' undeclared here (not in a function)
/home/user/rbt/apps/settings_list.c:861: error: initializer element is not constant
/home/user/rbt/apps/settings_list.c:861: error: (near initialization for `settings[66].lang_id')
/home/user/rbt/apps/settings_list.c:861: error: initializer element is not constant
/home/user/rbt/apps/settings_list.c:861: error: (near initialization for `settings[66].default_val')
/home/user/rbt/apps/settings_list.c:861: warning: missing initializer
/home/user/rbt/apps/settings_list.c:861: warning: (near initialization for `(anonymous)[0].<anonymous>')
/home/user/rbt/apps/settings_list.c:861: error: initializer element is not constant
/home/user/rbt/apps/settings_list.c:861: error: (near initialization for `settings[66].<anonymous>')
/home/user/rbt/apps/settings_list.c:861: warning: missing initializer
/home/user/rbt/apps/settings_list.c:861: warning: (near initialization for `settings[66].<anonymous>')
/home/user/rbt/apps/settings_list.c:861: error: initializer element is not constant
/home/user/rbt/apps/settings_list.c:861: error: (near initialization for `settings[66]')
/home/user/rbt/apps/settings_list.c:873: error: `LANG_SPINDOWN' undeclared here (not in a function)

Edit2:
Ok this was conflictng:
#define HAVE_DISK_STORAGE

After I removed it and left the #define HAVE_FLASH_STORAGE in place, in compiled fine.
I guess you can't have both flashdisk and harddisk in the same X5 (duh..hehe).

Alas... it did remove the Disk spindown option in the settings, but it has no effect on the topic issue, and actually seems to be using the default 5 seconds to spindown.

I'm going to bed...

(Mods: if this isn't the appropriate forum for this thread, please move it)

[pixelma]

I can only say that I have no problems with a 128GB SSD (also Photofast series) in my M5 which is the same as the X5 in this regard (and my brother is using a 64GB SSD in his X5 without a problem). Disk access is fast enough even on track skip and when accessing the file browser after a while so that I deliberately turned dircache off. Since I'm mostly using flac now, re-buffering needs to happen in every track and on every manual track skip usually (because a common flac file is bigger than the 16MB RAM these Iaudios have) and it's quick for me.

As you found out defining HAVE_FLASH_STORAGE doesn't help you and just hides the menu setting. With the above said, I don't know what's going on for you and it's curious that you see the same on two CF-modded X5s.

Could you state the exact revision number you based your build on? If you have any other modifications except LBA48 support, tell us too. It could also help if you post your config.cfg (you can find it in the .rockbox folder), in case you use some setting that cause the delays for you which I don't use.

[sixthofmay]

Here are the builds, and I just retested the CF ones (with settings at maxpain, ie. dir cache off, 3 sec spindown):
X5 16GB r19569 delays 2 seconds on spinup, installed with rbutil
X5 32GB v3.4 delays 5 seconds on spinup, installed with rbutil
X5 256GB r25335 delays 18 seconds on spinup, manual install, Rockbox and bootloader built with the VMWare development image, no mods except the LBA48

config.cfg contents from the 256GB when at maxpain:
# .cfg file created by rockbox r25335M-100325 - http://www.rockbox.org

volume: -35
bass: 4
treble: 10
backlight timeout: 120
backlight timeout plugged: 120
idle poweroff: 60
battery capacity: 1100
volume fade: off
disk spindown: 3

With HAVE_FLASH_STORAGE defined and HAVE_DISK_STORAGE not defined, I noticed that during playback, when the buffers needed to be replenished, the 18 second delay occurred each time. Also the antiskip buffer menu item was gone. I searched the sources for both those defines and the behaviors I observed kind of made sense.

So I removed the HAVE_FLASH_STORAGE and put back the HAVE_DISK_STORAGE in iaudiox5.h.

Lots of searching/reading the sources and IRC chats led me to these keywords:
ata_sleepnow
call_storage_idle_notifys
ide_power_enable
ata_perform_sleep
storage_enable
HAVE_ATA_POWER_OFF
ata_power_on
poweroff
sleeping

On a hunch that powering up the SSD is what was taking so long, and that sleep mode was working ok, I commented out the HAVE_ATA_POWER_OFF in iaudiox5.h.

So the only two changes for the 256GB SSD in iaudiox5.h are to add the #define HAVE_LBA48, and comment out the #define HAVE_ATA_POWER_OFF.

And the result is that all the issues (except slow boot) are gone. Shutsdown in about 2 seconds now too.

I retimed the hang on boot, and it's actually 18 seconds from the moment of power on, and about 16 seconds after it hangs on the battery voltage display. I also see an 18 second delay when plugging in the USB cable from the PC until the X5 says Connected (and the drive letter shows up about 5 seconds later).
Edit: I wanted to add that the bootloader flashing process did have a worrisome long delay before it began, and yeah 18 second delay sounds about right. I also noticed that when plugging in the AC adapter to charge it takes, guess what, 18 seconds before the display says Charging. 

Which all tells me that this SSD takes 18 seconds to power up. It's probably doing a power on self test or something.., and the large amount of flash onboard takes time.

So the slow bootloader issue I don't think anything can be done, but I'm sure happy to have solved the usability issues!

Here's my final config.cfg file contents:

# .cfg file created by rockbox r25335M-100328 - http://www.rockbox.org

volume: -35
bass: 4
treble: 10
backlight timeout: 120
backlight timeout plugged: 120
idle poweroff: 60
battery capacity: 1100
volume fade: off
disk spindown: 3
show filename exts: on
dircache: on

Note I did leave dircache on as it does make it slightly speedier browsing (instead of just fast, it's instant).
Spindown at 3, since in ata.c it looks like it does invoke the sleep function from this setting, and the SSD has no apparent delay waking up from sleep.

When I get a chance, I'm going to make a build for my 32GB CF X5 without the #define HAVE_ATA_POWER_OFF and see if that eliminates the 5 second spinup delay.

[amiconn]

Now that is really odd - an SSD that causes 18 seconds delay on power up. Maybe we're doing something slightly wrong wrt LBA48? Another possible reason would be a firmware problem of this specific SSD. So far nobody else reported excessive disk power-up times, neither for classic harddrives nor for SSD or CF. Power-up delay should be <1 second.

I do have an SSD modded iAudio X5 myself (64GB PhotoFast G-Monster V1), as well as a CF-modded iPod Mini G2. Both work like a charm with stock rockbox builds, i.e. including disk poweroff. pixelma has an SSD modded iAudio M5 (128GB PhotoFast G-Monster V2), also not having problems.

What SSD version do you have? You could also test whether there is a problem in the LBA48 support by installing a build without LBA48 support. You would also need to repartition the drive so the first partition stays below the 128GiB limit (of course that means you would have to copy the music again) for a full test.

[BdN3504]

I have a 256GB Photofast SSD working in my X5

1.8 50pin IDE V4 256GB. That's what she said.

[sixthofmay]

I have a 256GB Photofast SSD working in my X5

1.8 50pin IDE V4 256GB. That's what she said.

Yup that's the drive. Oh, I'm a he.

Ok here's one better than trying to figure out if the Rockbox LBA48 routines have a bug by repartitioning, rebuilding, copying gigs of files- I eliminated the X5 from the equation by doing some comparisons to other drives plugging into my PC through my frankenstein USB to microata adapter (electronics from an AMS Venus USB IDE drive enclosure from 2005, and a 3.5" to 2.5" adapter plugged into a 2.5" to microata adapter).

To keep some sanity, I rebooted my PC and had no other programs running and ran each test twice, safely removing each time. I used a stopwatch to measure. For the frankendapter tests, I started the clock the instant I powered up the frankendapter. For the X5 256GB subpack test, I started the clock first and plugged in the USB cable the moment it hit 10 seconds (otherwise I would need to grow a third hand...), and subtracted 10 seconds from the total. I stopped the clock for each test the moment the drive letter showed up in Windows Explorer (I'm running XP).

5.3sec frankendapter + Toshiba 20GB MK2006GAL
6.5sec frankendapter + 32GB Kingston Elite Pro CF/32GB-S2 Martwin CF-microata
6.5sec frankendapter + 80GB Samsung HS082B libmart.co.kr AN-ZIF219 zif to microata
23.4sec frankendapter + PhotoFast 256GB 1.8" G-Monster-50 IDE V4 SSD
Hopefully somewhat scientific and useful...

And for reference:
28.2sec X5 through subpack with the PhotoFast 256GB installed

Considerably slower with the SSD eh? And I think it rules out Rockbox and its LBA48 routines as being an issue.

If subtract the Photofast from the average of the faster drives (6.1 sec), all going through the frankendapter I get:
23.4-((6.5+6.5+6.5)/3) = 17.3 seconds, and in the ball park of my other observations.

Some pics:
Ack! What's that old thing doing in there..original battery that I forgot was still there...During my tests Monday and Tuesday, I did get about 14 hours playing FLACs before there was around 20% battery left (I was getting about 6 hours on the 80GB Samsung that lived in this X5 last month):


Ahh.. new CS-SFM3SL 1100mAh:


And installed:


Frankendapter:


The drives:


256GB SSD label closeup:


256GB SSD installed:


Info display. Hey you say that looks like my 240GB MK1214GAH upgrade I did to my X5L last week. Well it seems Photofast counts 16GB of spare sectors in the total (click the link). It's actually a 240GB SSD acording to Guiformat which reported it as 240GB... which is still the largest 1.8" 5mm SSD I'm aware of so I'm not complaining:


Edit:
Here's the output of Guiformat:
GuiFormat version 1.01 x86 Windows version 0501 32 bit
Size : 240GB 469756602 sectors
512 Bytes Per Sector, Cluster size 32768 bytes
Volume ID is 19f6:1f22
32 Reserved Sectors, 57330 Sectors per FAT, 2 fats
7338154 Total clusters
7338153 Free Clusters
Formatting drive K:\:...
Clearing out 114756 sectors for Reserved sectors, fats and root cluster...
Wrote 58755072 bytes in 2.30 seconds, 24.32 Megabytes/sec
Initialising reserved sectors and FATs...
Done

I'm going to check with Dvnation (where I bought it from) also Photofast and see if they are aware of the slow power up times. And do some googling to see if this happens with any other SSDs.

I would think a power on self test of the whole drive's space would be a good thing (I don't know if that's what it's doing, just guessing, yeah the drive may actually be defective in some way...). I would think it's possible the hardware can tell when a sector is going bad and reallocate before any data is lost. With 16GB of spare sectors they must be expecting to have to do quite a bit of reallocation over the life of the drive, and it would be pretty crappy if it only reallocated after it tells you it can't read the sector, right? Going to have to do some googling...

Edit2, 4-1-2010:
I'm thinking there's a firmware bug related to the transfer mode stepdown handshake...

I pulled the drive out of the X5 for the 3rd time for more tests tonight. I forgot about the 1.8" USB to microata case I have. So I tested it on that too, with no change in power up slowness. I also tested the X5 and the two adapters on my laptop's USB with no change.

What I know: The X5's CY7C68310 (ISD-300LP) is UDMA4, the PL-2506C in the 1.8" case is UDMA4, and the frankendapter's CY7C68300B is also UDMA4. The 256GB SSD is UDMA6.

So I hooked up the SSD with the frankenchangers and an 80 conductor IDE cable to my main PC (built in 2007) which has UDMA6 IDE ports. And there was NO DELAY on SSD detection or boot!

I then hooked it to a 2004 era PC's IDE port which has only UDMA4 support. It does the IDE detection about 10 seconds into boot and if it doesn't see the drive it continues on. I pressed the delete key to get into the bios, which showed no SSD. At that point I ctrl-alt-del rebooted (no power cycle, and more than 18sec elapsed since last powerup), and the drive was detected on the next go round. I shut off the power and repeated the test two more times to confirm.

Oh, I was able to get hdparm to talk to the drive when connected to my main PC motherboard IDE port. Firmware revision is VATP1281. I checked:
http://www.photofast.tw/forum/index.asp
..for new firmware for the V4 series but there's none.

The hdparm version available online for Windows is from 2007 and doesn't have the -d option which disables DMA. I tried the -X paramenter to try changing the transfer mode and got:

hdparm -X udma5 hde

hde:
 setting xfermode to 69 (UltraDMA mode5)
 HDIO_DRIVE_CMD(setxfermode) failed: Function not implemented

And also tried setting pio4 with the same error. Rockbox uses pio4 right?

Hey maybe that's the issue... The function to change transfer modes is not implemented in the firmware... which makes this SSD with a legacy interface troublesome for legacy devices....

If something like that is the issue, I guess the SSD has a slow limp-home handshake mode, to keep trying lower speeds until communication is established.

I might try the Knoppix live CD which has a newer version of hdparm which may have the -d option and see what it does. I don't think it's a permanent change though, so moots the ability to change it after powerup...(someone correct me if I'm wrong).

I searched the various notebook user forums, and couldn't find anyone who has tried the V4 256GB drive. There are a bunch of folks using the 128GB version though without issue. Could be they all have UDMA6 notebooks, or the issue isn't in the 128GB version, or I just have a bum SSD.

So there you have it...

Edit3: 4-6-2010
I decided to test on another PC and then contacted dvnation with the info about the USB adapters (the X5 is technically an adapter too) and PC troubles, who contacted Photofast, and Photofast emailed me a link to some new SSD firmware. After upgrading, booting is quicker now and the USB adapters are quicker too. It's late now, but I'll do more tests tomorrow and use the stopwatch and also try the build with the powerdown feature enabled to determine if the disabling of that is still needed.

Edit4: 4-7-2010
Ok here are the times with firmware revision VATP1295:
17.3 seconds for the drive letter to show up in Windows Explorer.

11.4 seconds from X5 powerup until it continues past the battery voltage display.

Considerably faster than before, but still slow compared to everything else. But you know what folks? This is somewhat bleeding edge technology. No one else make a 256GB (ok 240..) 1.8" 5mm thick drive that I'm aware of, spinning platters or SSD. AND with a PATA microata connector. So I'm ok with it.

I moved off the .rockbox I have been running the past few days that has the "#define HAVE_ATA_POWER_OFF" commented out, and moved back on the .rockbox that has the "#define HAVE_ATA_POWER_OFF" compiled in. I put the spindown at 3 seconds and turned directory caching off (maxpain). And it's somewhat less painful using than with the old SSD firmware. But still painful nonetheless... taking 11.4 seconds to browse to the next disk folder level or skip to the next track. So move the good .rockbox back on (HAVE_ATA_POWER_OFF commented out) and all good now. Except for higher power consumption of course, but still less power than harddisk.

I'm still determining the maximum runtime, as my new battery I put in a few days ago was defective and went to 0 volts while sitting on my bench not hooked to anything (during my joystick changeout surgery this past weekend (in the Repairs and Upgrades forum)), so I have another new battery in now and testing.

When I first did this upgrade (with the old SSD firmware), and while troubleshooting, I went into the "View disk info" in the debug section. For "Spinup time" It said like 18000 something ms. Which made no sense because it's a SSD right? I saw that the Size calculation is wrong (appears to be doing LBA28 calcs), so I figured the Spinup time displayed was wrong too. But it wasn't.

I've determined that Rockbox appears to measure that Spinup time when it does its first disk access (after Rockbox has powered it down once the boot has completed).

With the HAVE_ATA_POWER_OFF compiled in and with the new SSD firmware, it says 11320 ms.
With HAVE_ATA_POWER_OFF commented out, it says 40 ms. Ding ding ding...

That's how come it doesn't skip even with HAVE_ATA_POWER_OFF compiled in and a long spinup time. It knows how long the drive takes to spinup, so it just compensates by powering up appropriately depending on what it measured. And it does the same when playing through to the next track and so on. But when the user commands a different track, Rockbox has to wait for the spinup before it can do anything (developers- correct me if my observation is not correct).

So the summary is, for this 256GB drive, get the VATP1295 firmware (or newer) from Photofast if your drive has an older version. They said to run the updater a from a pure DOS environment (they said FreeDOS works fine). I copied the files to a floppy, then booted onto a Win98 boot floppy (selected no CD-ROM drivers) and ran the .bat file. They didn't mention interface in the email, but to be safe use one of the motherboard's IDE ports (not a USB to ATA adapter or enclosure (or through the X5)).

And comment out or delete the "#define HAVE_ATA_POWER_OFF" from the iaudiox5.h. And if you skipped the first part of this thread, you need to add into that file "#define HAVE_LBA48". And compile a bootloader too and use the scramble tool on the bin file (../tools/scramble -iaudiox5 bootloader.bin x5_fw.bin), and flash that to the X5 (copy x5_fw.bin to the FIRMWARE folder, safely remove, plugin your charger, and wait 11.4 seconds for it to start flashing). I'm going to write up a proper step-by-step how-to for the X5 and put it in the Repairs and Upgrades forum since this thread obviously got way too messy... 

[goffa]

amazing guys! Any chance the 256gb drive is small enough to fit into an x5l?

If so ... my 120gb gigabeast might take a back seat ...

[pixelma]

I think so. The 128GB SSD I talked about sits nicely in my M5L, without disconnecting the second battery or so (the M5(L)s uses the same shells as the X5(L)s, just in a different colour). If you look at the links provided in the original post, the site states the same dimensions for all three SSDs (mine's also from that series).

[xlarge]

Just plopped this
http://www.photofast.tw/products/ssd.html#50idev4
in to my x5 and it works with 3.6 just fine.

I haven't done any performance tests yet.