Rockbox

Tasklist

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, 17:36 GMT
Last edited by Paul Louden (Llorean) - Tuesday, 20 November 2007, 01:57 GMT
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System iPod Nano
Severity Medium
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 12
Private No

Details

iPod 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

Closed by  Paul Louden (Llorean)
Tuesday, 20 November 2007, 01:57 GMT
Reason for closing:  Fixed
Comment by Paul Louden (Llorean) - Tuesday, 31 July 2007, 18:50 GMT
Just to add details, the current theory seems to be that this issue is caused by IDE timing concerns (at least, last time I talked to amiconn). We have trusted the flash bootloader and don't do any configuration ourselves in that area (I've been told) and if 1.3 / 1.3.1 change how the Apple OS handles this it could be (and possibly likely is) the cause of these problems.

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.
Comment by Paul Louden (Llorean) - Tuesday, 31 July 2007, 20:04 GMT
Update: We need new information. 1.3 does not seem to be the correlating factor (I've upgraded my iPod and at least for now seem to be having no problems.)

We need you to go into System->Debug->Disk Info and copy the following:
Model:
Firmware :
PIO modes:
Cycle times:
IORDY support:
IORDY disable:
Comment by Evgeniy (tralivali) - Tuesday, 31 July 2007, 22:30 GMT
View disk info:

Model: SST55LD019K-45-C-MWE
Firmware: ADBA41KB
PIO Modes: 0 1 2 3 4
Cycle times: 120ms/120ns
IORDY support: yes
IORDY disable: no
Comment by danhibiki (danhibiki) - Wednesday, 01 August 2007, 04:34 GMT
r14107

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.
Comment by Tan Yu Sheng (Farpenoodle) - Wednesday, 01 August 2007, 11:41 GMT
Model: SST55LD019K-45-C-MWE
Firmware: ADABA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Comment by Matthias Schlaipfer (mze) - Tuesday, 07 August 2007, 16:07 GMT
Model: SST55LD019K-45-C-MWE
Firmware: ADBA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no
Comment by Douglas Valentine (Dwyloc) - Wednesday, 08 August 2007, 09:40 GMT
I just wanted to add my self to the list with Llorean of people running version 1.3.1 of the Apple firmware and
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
Comment by Diogo (couves) - Wednesday, 08 August 2007, 17:21 GMT
I have a Nano with 1.2 Apple Firmware and I'm having the same problem

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
Comment by Erkka Kettunen (Siku) - Thursday, 09 August 2007, 20:21 GMT
I'm having same problems and I have the version 1.1 of Apple's firmware. Here's some details:

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
Comment by Florin Popescu (florinp3) - Friday, 10 August 2007, 13:19 GMT
I'm too having the problem described here.

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
Comment by Steve Bavin (pondlife) - Friday, 10 August 2007, 15:09 GMT
A report from "neoliv" on the forum:

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
Comment by wILL (war59312) - Sunday, 12 August 2007, 01:27 GMT
Model: SST55LD019K-45-C-MWE

Firmware: ADBA40KA

PIO modes: 0 1 2 3 4

Cycle times: 120ns/120NS

IORDY support: yes

IORDY disable: no
Comment by Jay (Jay) - Sunday, 12 August 2007, 22:24 GMT
I have 2 iPod Nanos one works and one doesn't. I've been using the GB nano for about a year with Rockbox, the 4GB just starting to try.
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
Comment by Douglas Valentine (Dwyloc) - Monday, 13 August 2007, 11:46 GMT
The Hardware info for my working 4GB Nano is

[Hardware info]
HW rev: 0X000C0006
PP version :PP5022C
Est clock(kHz): 30675
Comment by Paul Louden (Llorean) - Sunday, 19 August 2007, 21:02 GMT
Are any of you using voice, or more specifically *not* using voice, and do not have a voice file on your player?
Comment by Evgeniy (tralivali) - Sunday, 19 August 2007, 21:09 GMT
I'm not using voice, nor having voice files.
Comment by Florin Popescu (florinp3) - Monday, 20 August 2007, 07:08 GMT
Neither am I.
Comment by David Bennett (first500) - Monday, 20 August 2007, 10:53 GMT
I AM using voice files (english.voice) and the Rockbox version is 20070820 r14396. The voice file is the same date. I have a 4gb Nano, but I do not know how to give further info about my Nano

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.
Comment by wILL (war59312) - Monday, 20 August 2007, 18:40 GMT
I am NOT using any .voice files.
Comment by danhibiki (danhibiki) - Monday, 20 August 2007, 20:31 GMT
Not using voice
Comment by Tero Auvinen (ave) - Tuesday, 21 August 2007, 06:23 GMT
I have a non-working 2 GB nano with 0x000C0005 HW rev.

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.
Comment by joe kohlsdorf (tradie) - Tuesday, 21 August 2007, 08:17 GMT
Same Problem here with my 4GB Nano.
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
Comment by Rick (bospaadje) - Sunday, 26 August 2007, 21:03 GMT
I'm having the same problem on my 4G nano (primarily with flac and large mp3 files, audible glitches and skipping tracks after playing such a file for a few seconds, briefly displaying "codec error" - when i go back to the track it failed on before, it will sometimes play fine except for a few glitches, sometimes skip forward again).

[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
Comment by Martti Roitto (maraz) - Monday, 27 August 2007, 10:54 GMT
http://forums.rockbox.org/index.php?topic=12326.msg93272#msg93272 Could this be the reason? Because, really, my nano works just fine now that it's not hellishly hot.

[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
Comment by Tero Auvinen (ave) - Monday, 27 August 2007, 17:41 GMT
"Me too". When the device gets hot, the problem is much worse.
Comment by Matt Hoskins (Skaffen) - Tuesday, 11 September 2007, 19:07 GMT
I've been running r13720-070626 for a while without any problems on my nano. I do update it every so often though and decided to stick on the latest build yesterday. After about 5-10 minutes of playback I started to get audio glitches. I shut the nano down with the intention of looking on the website as to whether it was a known problem today and spotted this and the related discussion threads.

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
Comment by Jouni Rinne (l33tmmx) - Wednesday, 12 September 2007, 12:10 GMT
I have basically the same problem on my 1G black 1st gen nano, except I'm unable to play ANY files for ANY length (ogg or mp3) on it, using current builds. I originally installed Rockbox on it at early April '07 (unfortunately I don't remember the version, neither do I have a backup :( ), that version worked fine. Unfortunately I had the bright idea to try an upgrade... I was unable to play anything on the upgraded version, just got the 'undefined instruction' and 'codec error'-type errors described above. I then resetted the device via Itunes (to firmware version 1.3.1) and tried again; no luck. Then I downgraded firmware to 1.2 and tried again; no luck this time, either...

[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
Comment by Martti Roitto (maraz) - Wednesday, 12 September 2007, 12:50 GMT
I still have the same problem on r13390. I'm thinking it might be power management related, since there was a case above which had no support for power mgmt and ran fine. We need more data (apple firmware version, hardware info, power mgmt status, rockbox build and bootloader version) to determine the true cause.

Has anyone tried reverting back to an older bootloader and rockbox revision?
Comment by Jay (Jay) - Wednesday, 12 September 2007, 13:37 GMT
I've reverted back to r13762 Bootloader and Rockbox and its been running fine (for over a week).

James
Comment by Martti Roitto (maraz) - Wednesday, 12 September 2007, 14:34 GMT
Forgive me for going a bit off-topic here, but where can I find this bootloader?
Comment by wILL (war59312) - Wednesday, 12 September 2007, 17:55 GMT
That would be http://download.rockbox.org/daily/ipodnano/rockbox-ipodnano-20070726.zip .

Better grab it before it gets removed.
Comment by wILL (war59312) - Wednesday, 12 September 2007, 17:56 GMT
No sorry that is r13990 which is the latest known build to work correctly. So yes the bootloader for the nano broke on 20070727.
Comment by wILL (war59312) - Wednesday, 12 September 2007, 18:00 GMT
And sorry can everyone who is effected by this please click on Add Vote towards the top of the screen. Right now there are only three votes. But of course it appears many more of us are effected than just 3. Not like it matters much since they can look at the comments but I know some developers sort by vote count (and other things of course) when looking for bugs they need to fix. Just a thought.. Thanks!
Comment by Martti Roitto (maraz) - Wednesday, 12 September 2007, 18:49 GMT
Isn't that the firmware, not the bootloader?
Comment by Daniel Stenberg (bagder) - Wednesday, 12 September 2007, 20:55 GMT
FYI: voting doesn't help at all as nobody cares about them.
Comment by Paul Louden (Llorean) - Thursday, 13 September 2007, 03:23 GMT
Developers don't care about vote count, it's completely pointless.

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?
Comment by Martti Roitto (maraz) - Thursday, 13 September 2007, 07:17 GMT
No, I'm merely pointing out my problems began when updating the bootloader and the firmware. Obviously the firmware is not solely at fault here since r13990 does not work for me.
Comment by Paul Louden (Llorean) - Thursday, 13 September 2007, 07:23 GMT
So, do you know for a fact that when you updated the bootloader it installed a newer one than you had before? What SVN revision is your current one, and what was your previous one?

It is very, VERY important that we collect facts, not extrapolations, so document every version number of things you change.
Comment by Evgeniy (tralivali) - Thursday, 13 September 2007, 07:27 GMT
If 13990 does not work for you, just update your bootloader. Several people I know solved their problems updating their bootloaders.
Comment by Martti Roitto (maraz) - Thursday, 13 September 2007, 08:55 GMT
I was using an ancient bootloader, no idea what version. Obviously the new firmware didn't work on it, so I had to upgrade. Will try updating bootloader again, but I fear it will be fruitless.
Comment by Matt Hoskins (Skaffen) - Thursday, 13 September 2007, 22:44 GMT
As per my comment yesterday I was running with apple firmware version 1.1 and saw the problems start when I went from rockbox r13720-070626 to r14660-070910. I was running 1.0 bootloader I think.

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.
Comment by Antoine (tinodeleste) - Sunday, 16 September 2007, 18:42 GMT
Hi,

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...
Comment by Björn Stenberg (zagor) - Monday, 24 September 2007, 09:45 GMT
Everyone with this problem, please run the latest ipodpatcher (http://download.rockbox.org/bootloader/ipod/ipodpatcher/) and install a new bootloader. That solved the problem for a person on IRC today, and we'd like to know if it solves it for everyone.
Comment by Erkka Kettunen (Siku) - Monday, 24 September 2007, 10:39 GMT
With the new bootloader everything seems to be working fine. I'll keep testing and I'll report back if any problems occur. But so far so good, thank you!
Comment by Michael Schnier (Mikelx215) - Monday, 24 September 2007, 11:36 GMT
New bootloader does NOT fix the problem for me. I'm testing with latest firmware, and it isn't working.
Comment by Michael Schnier (Mikelx215) - Monday, 24 September 2007, 11:37 GMT
By that, I mean it isn't fixing the problem.
Comment by Erkka Kettunen (Siku) - Monday, 24 September 2007, 11:43 GMT
Ok, after half an hour of testing the same problems seem to be back. So back to the square one...
Comment by Steve Bavin (pondlife) - Monday, 24 September 2007, 12:07 GMT
OK - is there anyone here who:
- 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!
Comment by Martti Roitto (maraz) - Monday, 24 September 2007, 12:14 GMT
I started out with R13390 with then-current bootloader - it worked almost perfectly, perhaps one listen out of a hundred would still skip.
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.
Comment by Rick (bospaadje) - Monday, 24 September 2007, 13:21 GMT
latest bootloader + firmware does not fix the problem here.
Comment by Evgeniy (tralivali) - Wednesday, 26 September 2007, 11:14 GMT
The problem is back, though not immediately - after 3-4 minutes.
Comment by Evgeniy (tralivali) - Wednesday, 26 September 2007, 11:17 GMT
Steve Bavin (pondlife)б unfortunately, I'm not in EU, though I would lend my IPod to a developer...
Comment by Evgeniy (tralivali) - Wednesday, 26 September 2007, 11:28 GMT
It seems that the problem is in overheating.

I put my ipod to a refrigerator for 5 minutes and it 'works' after it for 20 minutes well!
Comment by David Bennett (first500) - Thursday, 27 September 2007, 08:36 GMT
It's definitely not an overheating problem with my Nano.

It works fine with the 20070725 release, but crashes with all of the August onward releases.
Comment by Evgeniy (tralivali) - Thursday, 27 September 2007, 08:39 GMT
David, how can you say? Did you put it into a refrigerator with September releases?
Comment by Steve Bavin (pondlife) - Thursday, 27 September 2007, 08:46 GMT
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.

This *shouldn't* be a problem as the Nano's PP5021C CPU is specced for 80MHz...
Comment by David Bennett (first500) - Thursday, 27 September 2007, 09:05 GMT
"David, how can you say? Did you put it into a refrigerator with September releases?"

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.
Comment by Evgeniy (tralivali) - Thursday, 27 September 2007, 09:19 GMT
Then just try.
Comment by Florin Popescu (florinp3) - Thursday, 27 September 2007, 09:24 GMT
I get instant crashes too with anything besides MP3 (tried musepack, flac and ape). MP3s play with a lot of glitches. I'll try the refrigeretor tonight, but I don't think heat is the problem.

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.
Comment by Steve Bavin (pondlife) - Thursday, 27 September 2007, 09:26 GMT
Florin - instant crashes and glitches - sounds like you might not be running the latest bootloader...?
Comment by Florin Popescu (florinp3) - Thursday, 27 September 2007, 09:31 GMT
I've updated to the one in the link above after a full restore. Current build works as above, 13990 works fine.
Comment by Jay (Jay) - Saturday, 29 September 2007, 09:39 GMT
I've updated to the bootloader in the previous link but am still running the software r13762, on boot it manages to find my "hard drive" and starts to play songs without instant crash, usually I only update the bootloader and software at the same time so I never tried to run them on different versions. I'll try the player for a few days before upgrading the software.
Comment by Matt Hoskins (Skaffen) - Tuesday, 02 October 2007, 22:33 GMT
Just updated to latest build and latest bootloader, same behaviour as before with my nano. Playback starts off fine but after a while (5-7 minutes) I start to get glitches in the sound that get progressively worse. If I fully reset the nano once the glitches are very noticable then I can't even start songs playing after rockbox has rebooted (see my earlier comment for examples of the errors I see). Turning the nano off for 5-10 minutes is the only way to get it to behave again, but then once it's been playing for a little while it will start to glitch again. I'm going to downgrade again to a firmware version prior to r14004 :)

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!).
Comment by Matt Hoskins (Skaffen) - Wednesday, 03 October 2007, 09:08 GMT
Further thoughts I had overnight about the behaviour of my nano with the firmwares that cause it problems...

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 :)
Comment by Martti Roitto (maraz) - Wednesday, 03 October 2007, 09:16 GMT
It's clearly not a CPU problem, but closely related to disk I/O. I still have occasional glitches using r13390 (which rules out the clock speed change for me), should I downgrade even more?
Comment by Neil Schemenauer (nas) - Thursday, 04 October 2007, 05:57 GMT
Quite a bit of speculation here but not much testing. :-( Here's my 2 cents. First, r14004 seems to cause a problem on my nano. Cooling my device does seem to help. Before cooling I would usually get errors immediately after trying to play an MP3. After cooling it, it seems to run okay with the latest release. I know that even with an old version (r13???) I get errors if my Nano sits in the sun.

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.
Comment by Neil Schemenauer (nas) - Thursday, 04 October 2007, 05:59 GMT
Oops, that first mini-diff should be:

-#define CPUFREQ_MAX 80000000
+#define CPUFREQ_MAX 78000000
Comment by Terence Haddock (lazerdye) - Friday, 05 October 2007, 19:45 GMT
I have this sound problem with a 4GB black nano, and nas's changes seem to fix it! Here is my details:

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?
Comment by Neil Schemenauer (nas) - Saturday, 06 October 2007, 07:52 GMT
I'm been running r14986 + my changes all day without trouble. At least for my device, going back to 75Mhz seems to fix the problem. I've made the zip available in case other people would like to test.

http://python.ca/nas/tmp/rockbox-nano-14986.zip
Comment by Evgeniy (tralivali) - Saturday, 06 October 2007, 09:08 GMT
It seems it works!!!
Comment by Antoine (tinodeleste) - Wednesday, 10 October 2007, 12:45 GMT
Hi,

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 !

Comment by Michael Sevakis (MikeS) - Saturday, 13 October 2007, 07:34 GMT
This is an utter guess and is pulled from the dual core work and solved similar problems when using the COP on H10. I don't know if it will help but a test can't hurt.
Comment by Michael Sevakis (MikeS) - Saturday, 13 October 2007, 08:03 GMT
Here's a build with the previous patch applied as well.
Comment by Tero Auvinen (ave) - Saturday, 13 October 2007, 08:56 GMT
Tested the MikeS build. The problem is still there but on my device it seems a bit less severe now. No data aborts, only occasional skips and glitches during playback.
Comment by Michael Sevakis (MikeS) - Saturday, 13 October 2007, 09:00 GMT
Perhaps this model just needs moderately longer clock skips?
Comment by Tero Auvinen (ave) - Saturday, 13 October 2007, 19:00 GMT
I tried maxing out the clock skips, svn head + MikeS patch + 0xff skipvalues, problems are still there, this time I also got nasty hangs (undefined instruction).
Comment by Michael Sevakis (MikeS) - Saturday, 13 October 2007, 19:32 GMT
Was worth a shot anyway. I really think it should use 75MHz if that is stable so the builds are at least useable and the correct solution worked out in the meantime so Nano users are at least not denied use of the latest builds.
Comment by Justin Hannigan (Chronon) - Monday, 15 October 2007, 16:44 GMT
I think this could use some discussion. On the forums people are being told that the source will not be rolled back to utilize 75MHz clock. I am not sure of the proper course of action on this.
Comment by Gerd Steinwender (Spoonman) - Monday, 15 October 2007, 20:42 GMT
is it already clear what the reason for this bug is? i´m just a normal rockbox/nano user and can not help with the code, but i realy want to know when the actual build will be usable again and surely other users want that too. i think to roll back is not the best solution, but maybe the only way to get effort of other changes in the code.
Comment by Neil Schemenauer (nas) - Monday, 15 October 2007, 23:01 GMT
Here's a recent build with the clock reverted from 80MHz to 75Mhz: http://python.ca/nas/rockbox/ . Obviously, it would be good if someone could find the the reason why 80MHz doesn't work on some devices. Meanwhile, I think it's useful for Nano owners to be able to test all the changes that happened since r14004. Being able to run Rockbox is also nice. ;-)
Comment by Florin Popescu (florinp3) - Tuesday, 16 October 2007, 09:42 GMT
My Nano work fine with the clock set to 78 MHz (Neil's previous build), so I think there's no need to go to 75 MHz. 80 MHz causes noise on mp3 files and instant crashes when playing musepack or flac.
Comment by Tero Auvinen (ave) - Tuesday, 16 October 2007, 12:28 GMT
I'd like to add that my device still acts ouf at 78 MHz (when it gets warm) so I had to go down to 75 MHz.
Comment by Michael Sevakis (MikeS) - Tuesday, 16 October 2007, 12:32 GMT
Stupid test #2

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. :)
Comment by Gerd Steinwender (Spoonman) - Tuesday, 16 October 2007, 17:03 GMT
maybe an option should be built in somewhere to throotle cpu frequency by the user?
Comment by Tero Auvinen (ave) - Tuesday, 16 October 2007, 17:09 GMT
Consider yourself indulged; no help there, playback problems are present as before (at 80 MHz).
Comment by Laurens (AmbiquitY) - Tuesday, 16 October 2007, 18:04 GMT
I installed the build Neil Schemenauer (nas)gave (r14986 http://python.ca/nas/tmp/rockbox-nano-14986.zip) And everything is working PERFECT!! thanks so much!
Comment by Neil Schemenauer (nas) - Wednesday, 17 October 2007, 02:07 GMT
Just to clarify, the old code had the nano running at 75MHz, never at 78MHz. There was a bug in the old code that displayed the clock rate as 78000000 when it was actually running at 75MHz.

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.
Comment by Johan Euphrosine (proppy) - Wednesday, 17 October 2007, 16:09 GMT
Model: SST55LD019K-45-C-MWE
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.
Comment by Justin Hannigan (Chronon) - Wednesday, 17 October 2007, 16:35 GMT
That is helpful. I would suggest that you post a message to the developer mailing list and hang out in the #rockbox IRC channel for a bit and see if you can get in touch with someone. If I recall correctly, I think amiconn might have been interested in looking into this.
Comment by joe kohlsdorf (tradie) - Monday, 22 October 2007, 08:12 GMT
Additions to my comment from Tuesday, 21 August 2007:
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.
Comment by Matt Hoskins (Skaffen) - Monday, 22 October 2007, 08:32 GMT
Tradie, it sounds like you're saying that Neil Schemenauers build doesn't suffer from the glitching after long playback times or heating the device that r13390 did? I just want to double check that's what you're saying as if it's true as it may indicate that the changes to clock setup code amiconn made around the same time as the 80mhz change have at least improved stability at 75mhz on those nanos that can't handle 80mhz.
Comment by Jouni Rinne (l33tmmx) - Monday, 22 October 2007, 18:31 GMT
I can confirm that my 1GB black Nano - finally - works perfectly with nas's latest 75 MHz build. (http://python.ca/nas/rockbox/rockbox-r15073-nas.zip) :D. Thank you very much, I was about to throw the d**n iPod out of the window...
Comment by Jay (Jay) - Monday, 22 October 2007, 21:18 GMT
I've tried the patch file download from the url in post "Monday, 15 October 2007, 23:01 GMT" with version r15194, with a couple of other patches and my iPod that didn't work now works so I have two working ipods with the same software running. my hardware details for the version that works and the version that didn't are shown above post "Sunday, 12 August 2007, 22:24 GMT"
Comment by joe kohlsdorf (tradie) - Tuesday, 23 October 2007, 16:03 GMT
Skaffen: Yes, Neils build fixes those problems. I did not post it because I didn't have the time to check everything in detail.
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).
Comment by Jay (Jay) - Tuesday, 23 October 2007, 20:08 GMT
I was just saying everything works as it used to with Neil's patch
Comment by Gerd Steinwender (Spoonman) - Tuesday, 23 October 2007, 20:25 GMT
ok, seems to bee prooved that neil's build works pretty perfect (also for me), but what about fixing the problem? we can not expect that someone always makes a 75mhz build for affected users. hope the donated ipod is on the way to the right dev to solve this problem soon ;-)
Comment by William Peters (w1ll14m) - Saturday, 03 November 2007, 20:29 GMT
Same here,

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.
Comment by William Peters (w1ll14m) - Saturday, 03 November 2007, 20:40 GMT
so, i have my ipod running at 30/80 Mhz.

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 */
Comment by oblib (oblib__) - Friday, 16 November 2007, 04:23 GMT
I think I found the problem. There is a register called "IDE0 config" that has a bit which needs to be set if the CPU > 65 MHz. If I set the bit on CPUFREQ_MAX, and set it on CPUFREQ_NORMAL, my Nano works just fine. Easy!

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);

Comment by oblib (oblib__) - Friday, 16 November 2007, 05:38 GMT
Here's a file of the patch
Comment by oblib (oblib__) - Friday, 16 November 2007, 06:34 GMT
Try two. Ignore the above posts:

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;
Comment by Gerd Steinwender (Spoonman) - Friday, 16 November 2007, 08:49 GMT
could you make a build for us that do not have experience in compileing our own? i´d really love to betatest it...
Comment by oblib (oblib__) - Friday, 16 November 2007, 14:30 GMT
Oops, sorry that repost came from hitting "refresh." Here's a zip file.
Comment by Neil Schemenauer (nas) - Friday, 16 November 2007, 16:11 GMT
oblib, I kiss you. :-) Your fix seems to fix Rockbox on my device. I've been running it with the max clock at 80 MHz for a while now. I updated my page containing the 75 MHz unofficial builds (http://python.ca/nas/rockbox/) to include a build with your fix. Hopefully it can get some more testing.

How did you discover this fix? Well done.
Comment by Martti Roitto (maraz) - Friday, 16 November 2007, 16:27 GMT
My previously _very_ buggy nano now WORKS ABSOLUTELY PERFECTLY with nas's build, even when artificially heated. Thanks, oblib and nas - now to get this into the official build :)
Comment by Martti Roitto (maraz) - Friday, 16 November 2007, 17:18 GMT
... Well, except for the fact that the build simply refuses to save any settings (they're reset at boot no matter what) and videos won't play (mpegplayer doesn't even start nor are the videos listed with "supported" files), but these probably aren't due to the IDE0 fix.
Comment by Paul Louden (Llorean) - Friday, 16 November 2007, 20:37 GMT
Why do you say those probably aren't due to it? Are you using any other patches too for some reason?

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...
Comment by danhibiki (danhibiki) - Friday, 16 November 2007, 22:34 GMT
Tried Neil Schemenauer build with this new patch applied, but it didn't work on mine, same old "Partition not found" message, but again, my Nano is really weird :P

But it's good to see that it worked for some people =]
Comment by Martti Roitto (maraz) - Saturday, 17 November 2007, 00:43 GMT
Paul Louden: I've been using rev. 13390 for a long time, I have no idea whether the behavior is due to the recent official build Nas patched the working build out of or due to the IDE0 patch. Can't really say, because the recent builds really fsck up my nano due to the IDE0 bug.
Comment by oblib (oblib__) - Saturday, 17 November 2007, 00:53 GMT
Martti, do you get the same results with the rockbox.zip that I posted?
Comment by Martti Roitto (maraz) - Saturday, 17 November 2007, 01:57 GMT
oblib: I installed your patched version. Videos work fine now as does audio and everything else, but settings keep resetting to default on boot. I'm shutting down correctly and powering on without the hold switch on. I do not know whether this is related to the patch.
Comment by Evgeniy (tralivali) - Saturday, 17 November 2007, 10:54 GMT
Installed this build.
While untouched, it seems never switch to 80 mhz, always works at 30 mhz. Boost ratio: 0%, boost count: 0.
Comment by oblib (oblib__) - Saturday, 17 November 2007, 14:04 GMT
Martti, could you try the build from a freshly formatted drive? Once of the side effects of the old bugs I saw was that sometimes I could not delete a file. Maybe that's what's happening to your settings file -- it can't be overwritten. Does your old build still record settings?

Evgeniy, is that a bad thing? Does it work otherwise (all codecs work fine)? It should bump up during play.
Comment by Evgeniy (tralivali) - Saturday, 17 November 2007, 14:09 GMT
The codecs are fine.

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...
Comment by Martti Roitto (maraz) - Saturday, 17 November 2007, 14:22 GMT
oblib, yes, my r13390 does save settings. I did have some corrupted files when I installed - will format and try again.
Comment by Martti Roitto (maraz) - Saturday, 17 November 2007, 14:53 GMT
Okay, I'm done - and the installation is seemingly FUBAR. "No .rockbox directory - installation incomplete", even though the directory is there along with everything else. Rockbox shows no files on the disk even though everything seems perfectly in order in Windows. I switched back to r13390 and it works well (saves settings, etc) except for the occasional glitching in audio... after a few hours from now, at least. I've previously seen that switching builds does unimaginable things to the stability - right at this moment music is so glitchy that it's unlistenable, that is, if it even plays without crashing.

But it saves settings! :)
Comment by Martti Roitto (maraz) - Saturday, 17 November 2007, 14:55 GMT
Heh, I just took my device to the freezer and pressed the back cover against a wall for a couple seconds - and it works perfectly (with r13390 still). Heating really accentuates the problem. But unlike the ticket here says, the problem CAN be reproduced and IS present in pre-14003 builds.
Comment by oblib (oblib__) - Saturday, 17 November 2007, 15:05 GMT
Martti, can you join us on IRC?
Comment by oblib (oblib__) - Saturday, 17 November 2007, 16:41 GMT
This build sets both >50MHz and >65MHz flags. It is for maraz to see if it fixes his problem.
Comment by Martti Roitto (maraz) - Saturday, 17 November 2007, 17:07 GMT
Nope. Still not loading settings at startup. I did discover that they're loaded just fine if I just browse to .rockbox and select config.cfg, so the problem probably lies in the bootup procedure.
Comment by Paul Louden (Llorean) - Saturday, 17 November 2007, 20:25 GMT
Please, don't make assumptions like that the *problem* must lie in the bootup procedure just because it only shows up in the bootup procedure without more testing or evidence than just that.

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.
Comment by oblib (oblib__) - Saturday, 17 November 2007, 20:40 GMT
Another try for maraz: This sets the high CPU bit in the bitloader.
Comment by Paul Louden (Llorean) - Saturday, 17 November 2007, 20:44 GMT
Config loading isn't handled in the bootloader...
Comment by oblib (oblib__) - Saturday, 17 November 2007, 22:21 GMT
Alright, it looks like Maraz's problem is solved. Has anyone else tested the fix and had problems with it? Please let us know.
Comment by danhibiki (danhibiki) - Saturday, 17 November 2007, 22:34 GMT
This latest build seems to be running fine on my Nano too. Don't know yet in the long run, but it boots and plays songs correctly at least :)

Thanks a lot oblib!

Comment by oblib (oblib__) - Saturday, 17 November 2007, 23:09 GMT
Okay, here is the latest version of the patch. PLEASE post here if it does not work for you.

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;
Comment by Nicolas Pennequin (nicolas_p) - Sunday, 18 November 2007, 19:08 GMT
Please don't paste the patch content... attach it instead.
Comment by Neil Schemenauer (nas) - Sunday, 18 November 2007, 23:00 GMT
Here's oblib's patch as an attachment.
Comment by Gerd Steinwender (Spoonman) - Monday, 19 November 2007, 19:37 GMT
hey, seems like this build works fine, i had no chance to give it a try, but will do it this night and give a response then...
Comment by Gerd Steinwender (Spoonman) - Tuesday, 20 November 2007, 00:42 GMT
how do i install this? i expected to get full build like nas's is, but what to do with this "rockbox" file (no file extension) in the zip archive? i searched the .rockbox folder for such a file to replace...
please help!

Loading...