Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System iPod Nano
  • Severity Medium
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 12
  • Private
Attached to Project: Rockbox
Opened by tralivali - 2007-07-31
Last edited by Llorean - 2007-11-20

FS#7510 - iPod Nano (with 1.3.1 firmware) - broken playback since r14004

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

Closed by  Llorean
2007-11-20 01:57
Reason for closing:  Fixed

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.

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:

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

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.

Model: SST55LD019K-45-C-MWE
Firmware: ADABA41KB
PIO modes: 0 1 2 3 4
Cycle times: 120ns/120ns
IORDY support: yes
IORDY disable: no

mze commented on 2007-08-07 16:07

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

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

Siku commented on 2007-08-09 20:21

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

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

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

Model: SST55LD019K-45-C-MWE

Firmware: ADBA40KA

PIO modes: 0 1 2 3 4

Cycle times: 120ns/120NS

IORDY support: yes

IORDY disable: no

Jay commented on 2007-08-12 22:24

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

The Hardware info for my working 4GB Nano is

[Hardware info]
HW rev: 0X000C0006
PP version :PP5022C
Est clock(kHz): 30675

Are any of you using voice, or more specifically *not* using voice, and do not have a voice file on your player?

I’m not using voice, nor having voice files.

Neither am I.

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.

I am NOT using any .voice files.

Not using voice

ave commented on 2007-08-21 06:23

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.

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

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

maraz commented on 2007-08-27 10:54

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

ave commented on 2007-08-27 17:41

“Me too”. When the device gets hot, the problem is much worse.

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

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

maraz commented on 2007-09-12 12:50

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?

Jay commented on 2007-09-12 13:37

I’ve reverted back to r13762 Bootloader and Rockbox and its been running fine (for over a week).

James

maraz commented on 2007-09-12 14:34

Forgive me for going a bit off-topic here, but where can I find this bootloader?

That would be http://download.rockbox.org/daily/ipodnano/rockbox-ipodnano-20070726.zip .

Better grab it before it gets removed.

No sorry that is r13990 which is the latest known build to work correctly. So yes the bootloader for the nano broke on 20070727.

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!

maraz commented on 2007-09-12 18:49

Isn’t that the firmware, not the bootloader?

Project Manager

FYI: voting doesn’t help at all as nobody cares about them.

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?

maraz commented on 2007-09-13 07:17

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.

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.

If 13990 does not work for you, just update your bootloader. Several people I know solved their problems updating their bootloaders.

maraz commented on 2007-09-13 08:55

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.

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.

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…

Project Manager
zagor commented on 2007-09-24 09:45

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.

Siku commented on 2007-09-24 10:39

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!

New bootloader does NOT fix the problem for me. I’m testing with latest firmware, and it isn’t working.

By that, I mean it isn’t fixing the problem.

Siku commented on 2007-09-24 11:43

Ok, after half an hour of testing the same problems seem to be back. So back to the square one…

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!

maraz commented on 2007-09-24 12:14

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.

latest bootloader + firmware does not fix the problem here.

The problem is back, though not immediately - after 3-4 minutes.

Steve Bavin (pondlife)б unfortunately, I’m not in EU, though I would lend my IPod to a developer…

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!

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.

David, how can you say? Did you put it into a refrigerator with September releases?

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…

“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.

Then just try.

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.

Florin - instant crashes and glitches - sounds like you might not be running the latest bootloader…?

I’ve updated to the one in the link above after a full restore. Current build works as above, 13990 works fine.

Jay commented on 2007-09-29 09:39

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.

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!).

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…

  1. I start it from cold with the recent firmwares and the problem isn’t occuring.
  2. 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)
  3. 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 :)

maraz commented on 2007-10-03 09:16

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?

nas commented on 2007-10-04 05:57

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.

nas commented on 2007-10-04 05:59

Oops, that first mini-diff should be:

-#define CPUFREQ_MAX 80000000
+#define CPUFREQ_MAX 78000000

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?

nas commented on 2007-10-06 07:52

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

It seems it works!!!

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 !

MikeS commented on 2007-10-13 07:34

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.

MikeS commented on 2007-10-13 08:03

Here’s a build with the previous patch applied as well.

ave commented on 2007-10-13 08:56

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.

MikeS commented on 2007-10-13 09:00

Perhaps this model just needs moderately longer clock skips?

ave commented on 2007-10-13 19:00

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

MikeS commented on 2007-10-13 19:32

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.

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.

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.

nas commented on 2007-10-15 23:01

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

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.

ave commented on 2007-10-16 12:28

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.

MikeS commented on 2007-10-16 12:32

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. :)

maybe an option should be built in somewhere to throotle cpu frequency by the user?

ave commented on 2007-10-16 17:09

Consider yourself indulged; no help there, playback problems are present as before (at 80 MHz).

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!

nas commented on 2007-10-17 02:07

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.

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.

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.

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.

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.

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…

Jay commented on 2007-10-22 21:18

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”

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

Jay commented on 2007-10-23 20:08

I was just saying everything works as it used to with Neil’s patch

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

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.

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 */

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 &=~(0×10000000); /* 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 |= (0×10000000); /* Set CPU > 65MHz bit */

       PLL_CONTROL  = 0x8a220501;  /* (5/1 * 24MHz) / 4 */
       scale_suspend_core(false);
       udelay(250);

Here’s a file of the patch

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 |= (0×10000000); /* 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 &=~(0×10000000); /* 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 &=~(0×10000000); /* clear > 65MHz bit */

       PLL_CONTROL &= ~0x80000000; /* disable PLL */
       cpu_frequency = CPUFREQ_DEFAULT;
       PROC_CTL(CURRENT_CORE) = 0x4800001f; nop;

could you make a build for us that do not have experience in compileing our own? i´d really love to betatest it…

Oops, sorry that repost came from hitting “refresh.” Here’s a zip file.

nas commented on 2007-11-16 16:11

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.

maraz commented on 2007-11-16 16:27

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

maraz commented on 2007-11-16 17:18

… 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.

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…

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 =]

maraz commented on 2007-11-17 00:43

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.

Martti, do you get the same results with the rockbox.zip that I posted?

maraz commented on 2007-11-17 01:57

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.

Installed this build.
While untouched, it seems never switch to 80 mhz, always works at 30 mhz. Boost ratio: 0%, boost count: 0.

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.

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…

maraz commented on 2007-11-17 14:22

oblib, yes, my r13390 does save settings. I did have some corrupted files when I installed - will format and try again.

maraz commented on 2007-11-17 14:53

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! :)

maraz commented on 2007-11-17 14:55

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.

Martti, can you join us on IRC?

This build sets both >50MHz and >65MHz flags. It is for maraz to see if it fixes his problem.

maraz commented on 2007-11-17 17:07

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.

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.

Another try for maraz: This sets the high CPU bit in the bitloader.

Config loading isn’t handled in the bootloader…

Alright, it looks like Maraz’s problem is solved. Has anyone else tested the fix and had problems with it? Please let us know.

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!

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 |= (0×10000000); /* 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 &=~(0×10000000); /* 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 &=~(0×10000000); /* 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 &=~(0×10000000); /* cpu < 65MHz */
+ IDE0_CFG |= (0×10000000); /* cpu > 65MHz */

   IDE0_PRI_TIMING0 = 0x10;
   IDE0_PRI_TIMING1 = 0x80002150;

Please don’t paste the patch content… attach it instead.

nas commented on 2007-11-18 23:00

Here’s oblib’s patch as an attachment.

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…

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing