This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#7510 - iPod Nano (with 1.3.1 firmware) - broken playback since r14004
Attached to Project:
Rockbox
Opened by Evgeniy (tralivali) - Tuesday, 31 July 2007, 19:36 GMT+2
Last edited by Paul Louden (Llorean) - Tuesday, 20 November 2007, 02:57 GMT+2
Opened by Evgeniy (tralivali) - Tuesday, 31 July 2007, 19:36 GMT+2
Last edited by Paul Louden (Llorean) - Tuesday, 20 November 2007, 02:57 GMT+2
|
DetailsiPod Nano does not play music: it skips audiofiles after 2-3-5 seconds of playback, hangs sporadically, produces terrible glitches.
Nowadays (builds ~~14100) the situation is even deeper: my Nano hangs after 5-7 seconds of playback. Reproducible with Apple Software 1.3.1. The problem became apparent in 14004 SVN by Jens Arnold: 26 Jul 15:07 "Clean up PP502x CPU clock setup code and use the full 80MHz when boosted." The bug cannot be reproduced on 14003 and earlier builds. Here is the discussion: http://forums.rockbox.org/index.php?topic=11817.0 http://forums.rockbox.org/index.php?topic=11504.msg89211#msg89211 |
This task depends upon
This means it's technically a problem Rockbox has always had (that we depend on the flash loader's hardware setup steps) but that has only become apparent now (and I believe is something that would have needed to be fixed for Rockbox to ever run from flahs anyway). Previously it was simply asymptomatic.
We need you to go into System->Debug->Disk Info and copy the following:
Model:
Firmware :
PIO modes:
Cycle times:
IORDY support:
IORDY disable:
Model: SST55LD019K-45-C-MWE
Firmware: ADBA41KB
PIO Modes: 0 1 2 3 4
Cycle times: 120ms/120ns
IORDY support: yes
IORDY disable: no
Model: SCT14(square)D009K)4%,(square)-IWE
IORDY Support: yes
IORDY disable: no
Cycle times: 120ns/120ns
PIO modes: 0 1 2 3 4
Firmware: @(square)BA40J(square)
Some kind of data corruption here.
r13762 and rockbox-test1 available on http://forums.rockbox.org/index.php?action=dlattach;topic=11504.0;attach=1907
Model: SST55LD019K-45-C-MWE
IORDY Support: yes
IORDY disable: no
Cycle times: 120ns/120ns
PIO modes: 0 1 2 3 4
Firmware: ADBA40KA
Don't know what changed on rockbox-test1, but it seems to be on the right direction.
Firmware: ADABA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Firmware: ADBA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
the latest Rockbox builds (r14240-070808) without any problems so far.
As I have been running Rockbox for more than a year on my Nano I guess the problem is ether with newer Nanos.
Or some thing else like an over heating problem. Could it be that the raise in clock rate without properly setting up
the PP chip is resulting in people who use their nano on hot places of at high CPU loads having over head issues?
Anyway here's all the info about my Nano.
Info from Apple OS About screen
Capacity 3.7GB
Version 1.3
S/N YM613SXTTK2
Model MA107ZP
Format Windows
Rockbox System->Debug->View Disk Info:
Model: SST55LD019K-45-C-MWE
Firmware : ADBA14KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Info From Apple SO:
Capacity: 1.8GB
Version: 1.2
Model:MA099FB
Info From Rockbox:
Model: SST55LD019K-45-C-MWE
Firmware: ADBA41KB
PIO Modes: 0 1 2 3 4
Cycle times: 120ms/120ns
IORDY support: yes
IORDY disable: no
Info from Apple OS:
Version: 1.1
Model: MA005DK
And from Rockbox (r14251-070809):
Model: SST55LD019K-45-C-MWE
Firmware: ADBA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Apple:
Capacity 3.7GB
Version 1.3
S/N 6U6063VSTK2
Model MA107FB
Format Windows
Rockbox:
Model: SST55LD019K-45-C-MWE
Firmware : ADBA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
model st55ld019k-45-... (unable to read... out of screen)
firmware adba41kb
(size 3906Mb)
piomode 0 1 2 3 4
cycle time 120ns 120ns
iordy support yes
iordy disable no
Firmware: ADBA40KA
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120NS
IORDY support: yes
IORDY disable: no
Just to make sure its as close as possible on the 2GB nano I used ipodpatcher -r bootpartition.bin and ipodpatcher -rf filename.ipod, then on the 4GB nano ipodpatcher -w bootpartition.bin and ipodpatcher -wf filename.ipod and then and copied the .rockbox folder as is, but still have the same problems. both use Apple Firmware 1.3.1
View disk info
--------------
Same on both
Model: SST55LD019K-45-C-MWE
Spinup time: 0 ms
Noise mgmt: unsupported
Read-aheadL enabled
PIO modes: 0 1 2 3 4
Cycle times 120ns/120ns
IORDY support: yes
IORDY disable: no
Cluster size: 4096 bytes
2GB Nano - Works
Firmware: ADBA42KC
Size: 1953 MB
Free: 96 MB
Power mgmt: unsupported
4GB Nano - Doesn't
Firmware: ADBA40KA
Size: 3906 MB
Feee: 3751 MB
Power mgmt: enabled
View HW Info
------------
Same
PP version: PP5022C
2GB Nano - Works
HW rev: 0x000C0006
Est. clock (kHz): 30674
4GB Nano - Doesn't
HW rev: 0x000C0005
Est. clock (kHz): 30677
[Hardware info]
HW rev: 0X000C0006
PP version :PP5022C
Est clock(kHz): 30675
Rockbox was stable until about 070726. Now "Data abort" keeps occurring at the following addresses:
0002F5F0 on entering the Settings menu, and while scrolling the main menu
40001350 while scrolling the main menu and during shutting down.
I'm not using any voice files.
I'd like to point out that the problems are much more prominent when playing back vorbis files. Mp3's are quite ok but vorbis playback typically produces data abort within few seconds time.
Also, this phenomena is sporadic, sometimes the player works just fine for 10-15 minutes and then starts to act up. Very weird.
With the latest builds I get "undefined instruction" or "data error" after 3sec of playback and hangs.
[Hardware info]
HW rev: 0x000C0005
PP version: PP5022C
Est. clock (kHz): 29821
[Disk info]
Model: SST55LD019K-45-C-MWE
Firmware: ADBA40KA
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Cluster size: 4096 bytes
[Disk info]
Model: SST55LD019K-45-C... (off-screen?)
Firmware: ADBA42KC
PIO MOdes:0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDI disable: no
not using voice files
[hw info]
HW rev: 0x000C0005
PP version: PP5022C
Est. clock (kHz): 29826
[disk info]
Model:SST55LD019K-45-C-MW... (offscreen)
Firmware: ADBA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Just now I tried playing songs with my nano having been turned off overnight and got the repeated pattern of it being fine for 5-10 minutes before I start to notice some audio glitches which get progressively worse. With the glitching happening I tried a hard reset of the nano (cycle hold button, hold down menu plus centre button) and once rockbox had started up again I got errors in the UI font (seems to vary how it messes up or even if it messes up after each hard reset) and consistently when trying to play a song I get "Data abort at 01F02058" or "Data abort at 01F02AB0" or some such - the address given seems to vary each time however. The navigation of the menus and of the file system seems to work fine (even when the font is corrupted I recognise the pattern of item lengths showing it's still browsing fine).
I then tried turning the nano off for 5-10 minutes and starting again it plays fine for about 5-6 minutes before glitching creeps into the audio again.
I guess the pattern of behaviour I've seen would tally with something having changed in the more recent rockbox builds such that as my nano warms up through playback these audio glitches and other misbehaviours start to occur. I'll do some more testing later after I've charged the battery to see if warming the nano accelerates the glitching starting.
[Rockbox build]
r14660-070910
[from About in apple firmware]
Capacity 3.7GB
Version 1.1
Model MA005FB
[hw info]
HW rev: 0x000C0005
PP version: PP5022C
Est. clock (kHz): 30671
[disk info]
Model: SST55LD019K-45-C-MWE
Firmware: ADBA40KA
Size: 3906 MB
Spinup time: 0 ms
Power mgmt: enabled
Noise mgmt: unsupported
Read-ahead: enabled
PIO modes: 0 1 2 3 4
Cycle times 120ns/120ns
IORDY support: yes
IORDY disable: no
Cluster size: 4096 bytes
[from Apple firmware]
Version 1.2
S/N YM611PAMUPR
Model MA352DK
Format Windows
Rockbox version r14675-070912
[HW Info]
HW rev: 0x000C0006
PP version: PP5022C
Est. clock (khz): 30671
Has anyone tried reverting back to an older bootloader and rockbox revision?
James
Better grab it before it gets removed.
As for "broken bootloader", the version of the bootloader available for download hasn't changed for some time. It isn't updated frequently, so I'm curious why you keep repeating the bootloader is broken: Are you compiling your own bootloader instead of following the official instructions?
It is very, VERY important that we collect facts, not extrapolations, so document every version number of things you change.
Today I tried upgrading my nano to apple firmware 1.3.1 (required iPod reset) and then installed rockbox bootloader 1.1. I then put on rockbox r14660-070910 and had the same glitch behaviour reoccur. I then reverted back to r13720-070626 (as I have it around still) and the glitch behaviour went away. So on my nano at least the apple firmware version and rockbox bootloader version are not related to the problem. As per my earlier comment on my nano there seems to be a temperature factor in the glitches.
Pure speculation: I would guess that some relatively recent change in rockbox for the nano has lead to it hitting an instability in some aspect of nano hardware that only affects maybe some hardware revisions or maybe only even some batches of hardware components within some nanos. In some cases where the stability is borderline temperature of the hardware comes into play instead of the glitches happening all the time.
Model: SST55LD019K-45-C-MWE
Firmware : ADBA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
I have data abort errors every time I read an mpc, ogg, flac file (very fast) or mp3 file (after a minute). Updated bootloader and firmware, no effect. Cleaned disk and fresh install (bootloader from ipodpatcher 27may2007, firmware beginning of september, crash, firmware 13990, crash). Formatted disk and tried both builds, crash. Formatted disk under winxp, tried new apple firmware, rockboxed again (latest or 13990) again crash.
After a crash, I have always problems cleaning the disk, some files won't be deleted (root under linux). Lots of filesystem errors in syslog ( FAT: Did not find valid FSINFO signature.). The ipod works well under the original firmware (it's the first time I have tried it since I bought the player 18 months ago). But no flac, no musepack...
- lives in the EU
- reliably suffers this problem, with the latest bootloader
- is willing to lend their Nano to a Rockbox dev
If so, speak up!
Then I upgraded the bootloader with the current bootloader. Still worked, yay.
Then I made the mistake of trying current firmware... no go. Won't even play, just moves from song to song randomly or just crashes.
So I downgrade back to R13390 (of which I made sure to make a backup before upgrading to current), and ta-da: EVEN IT DOESN'T WORK.
I'm at a loss here.
I put my ipod to a refrigerator for 5 minutes and it 'works' after it for 20 minutes well!
It works fine with the 20070725 release, but crashes with all of the August onward releases.
This *shouldn't* be a problem as the Nano's PP5021C CPU is specced for 80MHz...
No, but the crashes occur instantly as soon as switched on. Above reports take a few minutes before crashes occur. I concede it may be instantly overheating, but gut feeling says not.
I live in the EU and I'm willing to lend my iPod if transport fees can be arranged. I tried contacting amiconn and received no answer, I'll try the IRC tonight.
Regarding Steve's comment of:
> It's very possible that revision 14004 (on 26th July 2007) will allow the Nano to get a little hotter as it increases the max CPU speed from 78MHz to 80MHz.
A small increase in heat from the increased max CPU speed would not necessarily be the cause of the problem on those nanos where there seems to be a heat factor in the glitching even if the change from 78Mhz to 80Mhz is what's introduced the glitching - it may be that running the CPU at that slightly higher speed makes some nanos unstable and the degree to which they're unstable is temperature sensitive. The increase in internal component temperatures after playing music for 5 minutes may be the same at 80Mhz as at 78Mhz it's just that at 80Mhz the problem nanos have become sensitive to that temperature increase (and in more severe cases the nanos are sensitive to ambient temperature so glitch right off the bat). Is it known if apple run the chip at the full 80Mhz? Is there a reason why it was previously run in nano rockbox at 78Mhz instead of the full 80Mhz (in the pre-14004 builds, which didn't show this glitching)?
Another thought is if the timing of anything else in the nano is tied to the CPU speed then it may be that the CPU speed increase isn't causing a problem for the CPU but for another component it communicates with (I know nothing about nano hardware though so if it's a silly thought please do ignore it!).
Once the glitching on playback starts it gets progressively worse the longer the nano is running, but the rockbox menu interface and file browsing show no problems at all. If it were specifically the CPU misbehaving would more than just playback crash?
If I restart rockbox (I tend to use a hard reset when there's glitching to ensure a clean slate) the firmware seems to load ok but there seem to be glitches happening in some or all of: the theme, the font, codec loading, possibly settings loading and music files. From what I've seen (though I could do further exploration) the menu interface itself is fine (if sometimes rendered unreadable by font issues, although the length of the menu items seems to correspond with what they were before). This also perhaps points to it not being the CPU misbehaving.
Maybe the data it's loading being corrupted once the problems start to manifest? So a theory for my nano...
- I start it from cold with the recent firmwares and the problem isn't occuring.
- As the nano's components warm up through playback the problem starts to occur introducing errors in data read from flash (presumably rockbox caches some things, so the theme components, settings and codec are cached, so any that had already been loaded and cached don't get corrupted)
- If the nano is given a reset the setting (CPU speed?) that's leading to this behaviour is cleared, the bootloader itself perhaps doesn't set this setting so the firmware loads fine, the firmware then sets the setting (CPU speed?) that's leading to this behaviour and as the nano is still warm it then gets random errors in data it then reads from flash (frequency of errors being affected by temperature still) so if it loads the theme, ui font, settings, codecs, and of course music data still after that point then all those have the potential to suffer corruption.
On nanos that are totally robust regardless of temperature then they're just more robust hardware revisions or runs perhaps and aren't affected by the change with r14004. On nanos that glitch from the start with these firmwares their hardware just can't tolerate the change that was made with r14004 leading to the data corrupting. In between there are those that can just about tolerate the change until they warm up. If the only change made in r14004 related to the nano is to boost the CPU speed then it would (naturally) seem likely that the change in CPU speed is not tolerated on all nano hardware for some reason and that could be down to the CPU itself or perhaps more likely some component the CPU talks to (loading data from flash maybe based on looking at the behaviour as I've done).
As before I should say I know zilch about nano hardware, I don't work with hardware, so it's all speculation based on trying to look for patterns so what I'm suggesting could be rubbish :)
In order to try to rule out the change from 78Mhz to 80Mhz, I built r14004 with two changes:
-#define CPUFREQ_MAX 78000000
+#define CPUFREQ_MAX 80000000
and
- PLL_CONTROL = 0x8a121403; /* (20/3 * 24MHz) / 2 */
+ PLL_CONTROL = 0x8a020000 | 8 | (25 << 8); /* (24/8)*25 = 75MHz */
The modified r14004 appears to be running without problems. I'll keep testing.
-#define CPUFREQ_MAX 80000000
+#define CPUFREQ_MAX 78000000
Model: SST55LD019K-45-C-MW (cut off)
Firmware: ADBA40KA
Size: 3906 MB
Free: 3655 MB
Spinup time: 0ms
Power mgmt: enabled
Noise mgmt: unsupported
Read-ahead: enabled
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Cluster size: 4096 bytes
I have pasted my specific changes here: http://pastebin.com/m7359de0f
The ipod was making strange clicking sounds playing oggs or mp3s, with the font corruption and data errors after reset. After the patch, it's now playing for 15 minutes without any clicking.
One other data point, was anyone noticing a 3-5 second pause accessing the ipod over USB after the clicking starts?
http://python.ca/nas/tmp/rockbox-nano-14986.zip
new ipodpatcher was not enough, but Neil Schemenauer's changes (r14986 + patch) seem to work on my ipod also (great to be able to hear more than 5 minutes of music on that thing)
Thanks !
In /firmware/export/config.h change line 400 from:
#if CONFIG_CPU == PP5020
to:
#if CONFIG_CPU == PP5020 || defined (IPOD_NANO)
Rebuild the core firmware. I just wonder if SWP becomes unstable. Indulge me. :)
Someone meantioned in the forum that the bug might not be CPU related. Is there a recommended CPU stress test for Rockbox? I was planning to try running the chess program.
Firmware : ADBA42KC
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Rockbox Version: r15106-071014
Undefined instruction at 400162F0 (0) during playback.
Installing http://python.ca/nas/tmp/rockbox-nano-14986.zip seems to solve the issue.
I live in France, and I can lend my iPod Nano 1G (black) to a rockbox developer who live in EU.
Hope that helps.
Even with r13390 I got glitching after long playback time (>2 hours) or when heating the device (holding it in my hand for 10min is enough).
Installing Neil Schemenauers build fixes the problems for me.
Maybe a "safe mode"-switch could be added in the options that sets max. speed to 75MHz - with this recent builds would be usable again w/o additional patching.
My Ipod played fine for 2 hours yesterday while holding it in my hand. With 80MHz I get glitching after holding the Ipod in my hand for 10 minutes.
Jay: What other patches did you apply? Maybe you should just try the binary that Neil supplied (clean the Ipod (at least the .rockbox-folder) before extracting it).
After loading rockbox.ipod i get a message:
No partition found, insert usb and fix it.
Model:SST55LD019K-45-C-MWE
Firmware :ADBA42KC
PIO modes:0 1 2 3 4
Cycle times:120ns/120ns
IORDY support:Yes
IORDY disable:no
With a modified build it runs.
02-11-2007-1/firmware/target/arm/system-pp502x.c:
case CPUFREQ_MAX:
#elif (CONFIG_CPU == PP5022) || (CONFIG_CPU == PP5024)
- PLL_CONTROL = 0x8a121403; /* (20/3 * 24MHz) / 2 */
+ PLL_CONTROL = 0x8a020000 | 8 | (25 << 8); /* (24/8)*25 = 75MHz */
case CPUFREQ_NORMAL:
#elif (CONFIG_CPU == PP5022) || (CONFIG_CPU == PP5024)
- PLL_CONTROL = 0x8a220501; /* (5/1 * 24MHz) / 4 */
+ PLL_CONTROL = 0x8a020000 | 8 | (20 << 8); /* (24/8)*20 = 60MHz */
This means:
Core is running at the following speeds:
normal:60 Mhz
max: 75 Mhz
normal will possibily work at 30 Mhz, but this is just for testing.
As this far, i'm using rockbox on nano for about 15 mins now, without a problem.
i'm going to test if the nano can run on 30/80 Mhz now.
i'm going to test if this is stable...
02-11-2007-1/firmware/target/arm/system-pp502x.c:
case CPUFREQ_MAX:
#elif (CONFIG_CPU == PP5022) || (CONFIG_CPU == PP5024)
- PLL_CONTROL = 0x8a121403; /* (20/3 * 24MHz) / 2 */
+ PLL_CONTROL = 0x8a020000 | 24 | (80 << 8); /* (24/24)*80 = 80MHz */
case CPUFREQ_NORMAL:
#elif (CONFIG_CPU == PP5022) || (CONFIG_CPU == PP5024)
- PLL_CONTROL = 0x8a220501; /* (5/1 * 24MHz) / 4 */
+ PLL_CONTROL = 0x8a020000 | 24 | (30 << 8); /* (24/24)*30 = 30MHz */
Patch:
Index: firmware/target/arm/system-pp502x.c
===================================================================
--- firmware/target/arm/system-pp502x.c (revision 15632)
+++ firmware/target/arm/system-pp502x.c (working copy)
@@ -182,6 +182,7 @@
MLCD_SCLK_DIV = 0x00000001; /* Mono LCD bridge serial clock divider */
#endif
#if CONFIG_CPU == PP5020
+ IDE0_CFG &=~(0x10000000); /* clear > 65MHz bit */
PLL_CONTROL = 0x8a020a03; /* 10/3 * 24MHz */
PLL_STATUS = 0xd19b; /* unlock frequencies > 66MHz */
PLL_CONTROL = 0x8a020a03; /* repeat setup */
@@ -207,6 +208,7 @@
scale_suspend_core(false);
udelay(500); /* wait for relock */
#elif (CONFIG_CPU == PP5022) || (CONFIG_CPU == PP5024)
+ IDE0_CFG |= (0x10000000); /* Set CPU > 65MHz bit */
PLL_CONTROL = 0x8a220501; /* (5/1 * 24MHz) / 4 */
scale_suspend_core(false);
udelay(250);
Index: firmware/target/arm/system-pp502x.c
===================================================================
--- firmware/target/arm/system-pp502x.c (revision 15632)
+++ firmware/target/arm/system-pp502x.c (working copy)
@@ -178,6 +178,7 @@
case CPUFREQ_MAX:
CLOCK_SOURCE = 0x10007772; /* source #1: 24MHz, #2, #3, #4: PLL */
DEV_TIMING1 = 0x00000303;
+ IDE0_CFG |= (0x10000000); /* Set CPU > 65MHz bit */
#ifdef IPOD_MINI2G
MLCD_SCLK_DIV = 0x00000001; /* Mono LCD bridge serial clock divider */
#endif
@@ -199,6 +200,7 @@
case CPUFREQ_NORMAL:
CLOCK_SOURCE = 0x10007772; /* source #1: 24MHz, #2, #3, #4: PLL */
DEV_TIMING1 = 0x00000303;
+ IDE0_CFG &=~(0x10000000); /* clear > 65MHz bit */
#ifdef IPOD_MINI2G
MLCD_SCLK_DIV = 0x00000000; /* Mono LCD bridge serial clock divider */
#endif
@@ -229,6 +231,7 @@
#ifdef IPOD_MINI2G
MLCD_SCLK_DIV = 0x00000000; /* Mono LCD bridge serial clock divider */
#endif
+ IDE0_CFG &=~(0x10000000); /* clear > 65MHz bit */
PLL_CONTROL &= ~0x80000000; /* disable PLL */
cpu_frequency = CPUFREQ_DEFAULT;
PROC_CTL(CURRENT_CORE) = 0x4800001f; nop;
How did you discover this fix? Well done.
While my device plays video fine with the IDE0 patch, it would be helpful if you'd provide a little more information. For example, if videos aren't listed in "supported" files, there's something really wrong with your build since your viewers list file is screwed up...
But it's good to see that it worked for some people =]
While untouched, it seems never switch to 80 mhz, always works at 30 mhz. Boost ratio: 0%, boost count: 0.
Evgeniy, is that a bad thing? Does it work otherwise (all codecs work fine)? It should bump up during play.
But, as I understood, the bug was introduced when a developer tried to get Ipod work at 80 mhz at peak times.
Now it simply works at 30 mhz...
But it saves settings! :)
That's the exact same kind of statement that had people constantly complaining that our problem was that we were running it at 80mhz, when we kept trying to tell them it lay in *other* device initialization most likely.
If you're only experiencing the problem so far during bootup, it could simply be that the processor is at a different speed during bootup than it has been the few times you've clicked on the file in the filetree, or several other possibilities, which could happen outside bootup but are simply more likely to (or guaranteed to) during boot and haven't happened *yet* when you manually try.
So, be careful when making speculation.
I'd suggest anyone testing this patch fully reformat and restore their iPod using iTunes, then reinstall Rockbox using only this version. The Nano bug seems to have been able to cause data corruption when writing, and it'll be hard otherwise to know if any problems you're experiencing are residual from that (even if older builds do NOT show these problems, that doesn't necessarily mean your disk isn't corrupted at all) or are because things aren't fixed yet.
Thanks a lot oblib!
Index: firmware/target/arm/system-pp502x.c
===================================================================
--- firmware/target/arm/system-pp502x.c (revision 15653)
+++ firmware/target/arm/system-pp502x.c (working copy)
@@ -178,6 +178,7 @@
case CPUFREQ_MAX:
CLOCK_SOURCE = 0x10007772; /* source #1: 24MHz, #2, #3, #4: PLL */
DEV_TIMING1 = 0x00000303;
+ IDE0_CFG |= (0x10000000); /* Set CPU > 65MHz bit */
#ifdef IPOD_MINI2G
MLCD_SCLK_DIV = 0x00000001; /* Mono LCD bridge serial clock divider */
#endif
@@ -199,6 +200,7 @@
case CPUFREQ_NORMAL:
CLOCK_SOURCE = 0x10007772; /* source #1: 24MHz, #2, #3, #4: PLL */
DEV_TIMING1 = 0x00000303;
+ IDE0_CFG &=~(0x10000000); /* clear > 65MHz bit */
#ifdef IPOD_MINI2G
MLCD_SCLK_DIV = 0x00000000; /* Mono LCD bridge serial clock divider */
#endif
@@ -229,6 +231,7 @@
#ifdef IPOD_MINI2G
MLCD_SCLK_DIV = 0x00000000; /* Mono LCD bridge serial clock divider */
#endif
+ IDE0_CFG &=~(0x10000000); /* clear > 65MHz bit */
PLL_CONTROL &= ~0x80000000; /* disable PLL */
cpu_frequency = CPUFREQ_DEFAULT;
PROC_CTL(CURRENT_CORE) = 0x4800001f; nop;
Index: firmware/target/arm/ata-pp5020.c
===================================================================
--- firmware/target/arm/ata-pp5020.c (revision 15653)
+++ firmware/target/arm/ata-pp5020.c (working copy)
@@ -44,7 +44,7 @@
{
/* From ipod-ide.c:ipod_ide_register() */
IDE0_CFG |= (1<<5);
- IDE0_CFG &=~(0x10000000); /* cpu < 65MHz */
+ IDE0_CFG |= (0x10000000); /* cpu > 65MHz */
IDE0_PRI_TIMING0 = 0x10;
IDE0_PRI_TIMING1 = 0x80002150;
please help!