IPOD (ALL MODELS) iFlash Adapter Issues [SOLVED!?]

[speachy]

Update: in my limited testing, data corruption unfortunately still seems to occur on an iPod video when doing USB transfers in Rockbox.

Instead of disabling DMA altogether, did you try setting ATA_MAX_UDMA to 1 ?

(in rockbox/firmware/target/arm/pp/ata-target.h)

I'd hate to disable DMA for all PP-based targets...

[chris_s]

Update: in my limited testing, data corruption unfortunately still seems to occur on an iPod video when doing USB transfers in Rockbox.

Instead of disabling DMA altogether, did you try setting ATA_MAX_UDMA to 1 ?

(in rockbox/firmware/target/arm/pp/ata-target.h)

I'd hate to disable DMA for all PP-based targets...

I have yet to try that.. My only experience so far on the latest build has been with DMA either enabled or disabled completely . Even disabling DMA didn't seem to help on the iPod Video using an iFlash adapter and SD card, whereas the iPod 4G remains surprisingly (i.e. completely) stable in that configuration with DMA disabled! I may try setting ATA_MAX_UDMA to 1 next.

iPod 4G:
   - hard disk:
      - DMA enabled: Data corruption occurs intermittently
      - DMA disabled: stable

   - CF:
      - DMA enabled: Data corruption occurs intermittently
      - DMA disabled: stable

   - iFlash + SD
      - DMA enabled: untested
      - DMA disabled: stable
   

iPod Video (limited testing):
   - hard disk
      - DMA enabled: apparently stable
      - DMA disabled: untested

   - CF:
      - untested

   - iFlash + SD
      - DMA enabled: Data corruption occurs when testing Rockbox USB transfer
      - DMA disabled: Data corruption occurs when testing Rockbox USB transfer
   

[speachy]

ATA/USB connectivity is provided by the core PP SoC.   But the 4G series uses a PP5020, and the 5G uses a PP5021 (which rockbox considers the same as a 5022)

From a software perspective, rockbox tweaks a few things between the 5020 and 5022 (to do with the clocking hierarchy) but otherwise treats the SoCs as incidentical.

Another thing worth trying -- disable dynamic cpu reclocking -- firmware/export/config/ipodvideo.h

#define CPU_FREQ      11289600
#define HAVE_ADJUSTABLE_CPU_FREQ

Comment out HAVE_ADJUSTABLE_CPU_FREQ and set CPU_FREQ to 30000000  (30MHz) as a first step. 

[b0hoon]

Hi.

This reminds me of: https://forums.rockbox.org/index.php/topic,32247.0.html. I don't remember exactly what kind of fix it was, maybe it's some sort of back to the bug, after updating the toolchain. However nobody tested this on modified players then. I mean with the adapters. Just my loose thoughts.

[chris_s]

Thanks! Results using UDMA 1 on the iPod 4G are very encouraging. I've been trying hard to cause data corruption, but everything seems perfectly stable so far. Will report back if I notice anything in daily usage. 

I’m looking forward to testing this on an iPod Video soon. Could be a few days to weeks though.

iPod 4G:
   - hard disk:
      - UDMA 2: Data corruption occurs intermittently
      - UDMA 1: stable
      - DMA disabled: stable

   - CF:
      - UDMA 2: Data corruption occurs intermittently
      - UDMA 1: stable
      - DMA disabled: stable

   - iFlash + SD
      - UDMA 2: untested (likely unstable)
      - UDMA 1: stable
      - DMA disabled: stable

[eicca]

Do these issues include the iFlash CF-SD adapter? I'm running an iPod Mini 2G with a 256GB SD card. Apple firmware gives 20 hours of playback, but Rockbox only gives 5 at best. It completely ruined my plans for this iPod. I've tried a whole bunch of different release versions and settings combinations and cannot get any improvement.

This is the second Mini I've tried. Both have been horrendous for Rockbox battery life.

I have my own thread on this in the hardware section but nobody is helping me out.

[speachy]

I suspect what's going on here is that the "disable use of ATA powersave when the ATA device doesn't claim to support it" fix for data corruption completely disables all powersaving on the ATA interface -- including turning off its power supply when not needed.

The thing is we relied on those powersave commands to positively tell us that it is _safe_ to turn off the power.  Without that, we don't have any way of being sure that the device isn't doing something in the background, beyond "wait for what we hope is long enough".

(this kill-power-after-we-think-it's-safe thing is what led to the massive corruption with the iflash adapters)

[Telehubis]

I’m looking forward to testing this on an iPod Video soon. Could be a few days to weeks though.

My adapter will arrive soon - how to test data transfer corruption?

[chris_s]

I’m looking forward to testing this on an iPod Video soon. Could be a few days to weeks though.

My adapter will arrive soon - how to test data transfer corruption?

In the case of the iPod video and the iFlash adapter, in my experience, it was enough to transfer a few dozen gigs of music (using the USB mode built-in to Rockbox, not using the original firmware) and check afterwards whether the database can be built successfully. Then randomly try to play a few songs from beginning to end without them skipping. Since that already failed for me, I'd see that as a good sign if it worked,  after which I suppose you could get a bit more ‘scientific’ by comparing the checksum of every copied file for example (or maybe someone has a better suggestion). Finally I would just simulate normal usage of the device and see if it remains stable and whether a file system check returns any errors after you've performed lots of restarts / re-shuffling and saving playlists  etc.

As an aside, the iPod 4G continues to be stable in daily usage with the fastest transfer mode set to UDMA 1. Really happy with that!

[eicca]

...iFlash CF-SD adapters....? Anyone........?