Latest Rockbox not working on Nano

[Llorean]

Please put unsupported builds in the unsupported build forum as per the posting guidelines.

Your statements make little sense.

1) In purely processor intensive procedures, the problem has not shown up in testing. Suggesting strongly it's not just the processor.

2) The person who knows most about it thinks it's ATA timing. As every problem seems to involve a read from the flash, this corroborates his hypothesis very strongly.

Between these two facts, it looks very likely the processor isn't the problem, but rather the problem is with the use of other hardware that is highlighted by the new CPU speed setting.

That would mean "80mhz is working properly, but something else never was and we just couldn't see it clearly before." This is especially further highlighted by the people who've reverted to a build from before the clock changes and said "I'm still noticing some instability" as it suggests, to me, that the problem was always there and perhaps just infrequent enough for people to assume it was "free software is always a little bit buggy" or something similar.

What evidence do you have to suggest that the problem occurs specifically in the processor and not in any other hardware? One problem I see here is that people are jumping to conclusions. Correlation does not imply (in the definition of the word pertaining to structure logic) causation. But people seem to think it does. "The problem showed up with the 80mhz change, therefor it must BE the 80mhz change" is not a logically sound statement. "The problem showed up with the 80mhz change, so the 80mhz change makes it more visible" is, but people seem to be disinterested in actually spending time doing thorough testing.

For example, you could device a test that runs the cpu boosted for a long period, but doesn't hit the disk, and see if you experience a data abort.

[Skaffen]

I disagree. While we're of course happy that a lot of people find Rockbox useful - the project is not about providing end users with a product, and never has been. Bugs that don't exist on a developer's hardware are impossible to fix - and there's no incentive for a Rockbox developer with a working Nano to revert it to some old code for what, to them, is no good reason. So the only way to get a fix for this issue is for someone who HAS the bug to get a clue, and try to help fix it.

I understand that it's not about providing end-users with a product; however when end-users report bugs often rockbox developers do fix them. It's just in this case the bug is such that it can't be reproduced at the moment on the hardware owned by anyone with the skills to take a look into it. When someone whines and you set that out to them they'll be clearer on the situation and not alienated (hopefully). Of course if they continue to wail, by all means set fire to them

What's partly muddied it in the minds of end-users is that it was working on their nano for ages and now after a change it's not.

1) The PP chip was originally run at 75 mhz because we had not yet discovered the right way to clock it to 80mhz, simple as that. I think that's a very reasonable reason for not doing it yet: We didn't know how to do it the right way. We still had more to learn about the chips first. The problems over 75 came from incomplete knowledge, but we have someone who spent time investigating and figured out what needed to be done to set it to 80 properly.

Presumably it wasn't technically that it couldn't be set to 80mhz before (as I would guess if you can set it to 75mhz you knew how to specify the speed), but that setting it to 80mhz instead of 75mhz with the initialisation technique known at the time caused instability on a wider range of hardware? Why 75mhz rather than, say 70mhz? Has 80mhz been now chosen as the max speed because that's the advertised top core speed of the PP5020 chip and because it seemed to be stable at that speed when tried at that speed by the developers on their hardware? I'm only asking in case there's anything about the original choice that could inform the discussion about the current issue.

And again, the problem doesn't happen in the processor: If we were running the processor faster than it is supposed to be safe to run, you would see different symptoms.

By processor you mean the core I'm guessing (just to be clear) - I'm not a hardware guy so I don't know if the whole PP5021C-TDF chip can be referred to as a processor, but from glancing at the published spec I see it is a system on a chip with a lot of bits besides the two microprocessors. I guess when people are talking in this thread they need to be careful when reading what people have said to be sure if they're referring to the processor core or referring to the PP5021C-TDF chip as a whole.

If the clock rate of the core affects the functioning of other components within the PP5021C-TDF chip (such as the interface to flash) then it's possible that while the core can be clocked at 80Mhz the PP5021C-TDF as a whole cannot cope with 80Mhz. Of course it could also be the flash hardware outside. Or it could be a problem in the rockbox code not initialising things quite right still or a timing issue in the rockbox code.

If it is just a hardware issue then if people were (as you point out) seeing slight instability even before the clock change then maybe 75 is still too fast for it. (Were they seeing this at 75Mhz or 78Mhz as I think it went from 75 to 78 at some point before going to 80?). The thing is dual core isn't it - can the core speeds set to different speeds and are they usually in rockbox?

To be clear - I'm not saying it is a hardware-can't-cope-with-the-speed issue rather than an issue with the rockbox code (i.e. something that can only be fixed by restricting core speed vs something that could be fixed with the right code), just that from what's said so far both are possibilities and neither can be ruled out.

I'm not sure how one would prove if it's a bug in the IDE timing code or an extra initialisation problem vs unstable part of PP5021C-TDF chip at high core speeds vs unstable external part of nano hardware (flash) when core is at high speeds.

[Llorean]

By "processor" I did in fact mean the core. Of which until recently we were only using a single of the two.

My point was more or less the same as yours "we can't know what's going on until more testing is done, but everyone seems more interested in leaping to conclusions" but I do believe that evidence suggests it's not the CPU core itself at fault, but rather some other part of the SOC or some other hardware, and that the problem is brought out by the new clock settings (also note the use of the word "suggests").

As for the 78 to 80mhz change, it happened over a very short period, and also came with some new clock setup code I believe, which I believe there's a high confidence in being "right".

As for the 75 mhz, I don't know the history of that, but I believe it was chosen by the iPodLinux guys as "The fastest speed they're stable at" but I'm not sure.

[danhibiki]

I'm jumping back on this topic again, Rockbox still doesn't work properly here, but this version running at 75MHz seems to bem running fine. At least it boots and finds my partitions

That would mean "80mhz is working properly, but something else never was and we just couldn't see it clearly before." This is especially further highlighted by the people who've reverted to a build from before the clock changes and said "I'm still noticing some instability" as it suggests, to me, that the problem was always there and perhaps just infrequent enough for people to assume it was "free software is always a little bit buggy" or something similar.

Actually, I brought up some issue with Rockbox a long time ago that's in some way related to this, as you can see it here:
http://forums.rockbox.org/index.php?topic=3279.msg23435#msg23435

At that time, everyone thought that my device was defective (and maybe it is, because I think it's the most affected Nano on this topic, the only one with similar behaviours as mine is void303).

I wish I could send my iPod to some developer, but I'm from Brazil and I don't think it's the easiest solution to send my Nano to Europe. Getting it back could be troublesome too, because of import taxes and stuff like that.

Maybe I could help with debugging or something like that, I do have intermediate skills in C, but I have no knowledge on hardware programming, this is the main problem for me.

[Skaffen]

I'm jumping back on this topic again, Rockbox still doesn't work properly here, but this version running at 75MHz seems to bem running fine. At least it boots and finds my partitions

Actually, I brought up some issue with Rockbox a long time ago that's in some way related to this, as you can see it here:
http://forums.rockbox.org/index.php?topic=3279.msg23435#msg23435

At that time, everyone thought that my device was defective (and maybe it is, because I think it's the most affected Nano on this topic, the only one with similar behaviours as mine is void303).

Do you have the same problems with the 75mhz max build that nas put up as you had with the version you reported on the topic above? I ask because I believe there have been other changes (initialisation method in particular) since you reported the problem back in 2006. It's not clear from your post if you've tested that the build nas has put up (which is built from a fairly recent codebase with only the max clock rate changed to 75mhz) exhibits the same problem as you had with the build you were running at the time of the forum post you made last year - your only comment that it runs better than the 80mhz build.

I wonder how many nano users who experience problems with the 80mhz build have ever run other applications that require a decent amount of processor time while also having music playing back before the move to 80mhz.

BTW the irony of this amused me when I found a thread about overclocking (I appreciate there's probably a good reason for the stance to have changed - I'm not having a dig by quoting it!):

Different PP chips are rated at different levels. The ones Rockbox use are rated for either 80, 100, or "Unknown, but the chip is believed to be similar to the 100", if I recall.

We stop at 75, and there should be no reason to "need" to go higher than this.

[embrion]

1. Nice quote, unfortunately there are no answers.
2. Some guy from the Rockbox mailing list said he'd like to  lend his problematic Nano just like Devs suggested. Ppls recommended him, to catch one of them at IRC. It was some time ago, so has any Dev been contacted?

[WauloK]

So it looks like there can't ever be a resolution for us Nano owners? ...

[sadffffff]

purely as an observation (im one of the lucky ones who had never had any problems with the nano):

the other day i left my nano in the car in the hot sun, when i came back to play it there was lots of distortion, a little scrambling, and the music sped up and slowed down while playing mp3s. i held it out the window to cool it off as i was driving and even while cold it did not fix the problem, i had to restart the player and then it went away. (also note that my rb build is several months old, so dont take this as an observation on a recent build incase anything has changed. i will post back with the version)

(edit: Version: r14203-070805)

[mitchelln]

Has this problem been fixed? My 1st gen Nano is doing the "No partition found" thing. I just upgraded it from a July build that was working fine. I have searched this forum for a solution and carefully re-read the install guide in case something has changed.
I've tried upgrading the bootloader, ipodcatcher v2.0 shows the partition okay:
[INFO] Scanning disk devices...
[INFO] Ipod found - 1st Generation Nano ("winpod") - /dev/sdc
[INFO] Reading partition table from /dev/sdc
[INFO] Sector size is 512 bytes
[INFO] Part    Start Sector    End Sector   Size (MB)   Type
[INFO]    0              63        160649        78.4   Empty (0x00)
[INFO]    1          160656       3984119      1866.9   W95 FAT32 (0x0b)
[INFO] Ipod model: 1st Generation Nano ("winpod")

I've reformatted the FAT32 partition and unzipped .rockbox into the root folder again with no luck. Basically I've tried everything I can think of. I'm running r15469-071105
Anybody got any ideas? How has it got so broken like this? Rockbox had been running for over a year on my Nano with no problems. My Nano is now useless

UPDATE
I have just installed the http://python.ca/nas/tmp/rockbox-nano-14986.zip version and my Nano now fires up fine. So I can be added to the dud 80MHz club.
I don't understand this. Why can't there be a release with the clock set lower to help us out? You know, be nice to each other instead of arguing? I ran Rockbox all the time for months without problems before.  

[AlexP]

I don't understand this. Why can't there be a release with the clock set lower to help us out? You know, be nice to each other instead of arguing? I ran Rockbox all the time for months without problems before.  

This has been answered many times.  Principally it is if we cover up the issue rather than fix it properly it will not get fixed.  The problem is not thought to be caused by the increase in clock rate, just exposed by it.  I know it is inconvenient for some users, but rockbox hasn't officially been released, and if everyone just ignores the problem it won't get fixed.

[mitchelln]

I don't understand this. Why can't there be a release with the clock set lower to help us out? You know, be nice to each other instead of arguing? I ran Rockbox all the time for months without problems before.  

This has been answered many times.  Principally it is if we cover up the issue rather than fix it properly it will not get fixed.  The problem is not thought to be caused by the increase in clock rate, just exposed by it.  I know it is inconvenient for some users, but rockbox hasn't officially been released, and if everyone just ignores the problem it won't get fixed.

I understand, but I also believe you cannot leave it totally broken for many weeks like this. It renders Rockbox completely unusable on affected Nano's. Surely some middle ground can be found here? Perhaps a config item? Just saying "Someone needs to post their Nano to a developer" isn't going to get us far. Like I say, I used Rockbox for many months without problems.

[AlexP]

Just saying "Someone needs to post their Nano to a developer" isn't going to get us far.

Just in the same way that putting it back to how it was isn't going to get us very far.

You can edit the code and build your own one  to reduce the clock speeds if you really want.  I don't know whether a config item would work, but I'm pretty sure it is unlikely to happen either way.

I do sympathise with you, and I'm not the one who takes any decision either way, I'm just explaining the position and the reasons behind it to you.

[mitchelln]

Just saying "Someone needs to post their Nano to a developer" isn't going to get us far.

Just in the same way that putting it back to how it was isn't going to get us very far.

You can edit the code and build your own one  to reduce the clock speeds if you really want.  I don't know whether a config item would work, but I'm pretty sure it is unlikely to happen either way.

I do sympathise with you, and I'm not the one who takes any decision either way, I'm just explaining the position and the reasons behind it to you.

I think you guys are coming at this from a very technogeek angle. Most people won't have the means or skillset to do their own custom builds. So they will just not use Rockbox. This is not good for the project.

Is there any technical reason why this could not be a config item? It could default to the lower clock rate when booting up, then read the config item and switch to the higher speed if it's been set. If it fails you merely then have to mount the disk and change the setting back. The lucky people with tolerant Nano's could then choose to use the higher rate and the people like me can still use Rockbox.  A practical solution to a technical problem IMHO. At least every Nano owner could then benefit from Rockbox.

I was pretty upset when I thought I'd lost the use of it after I upgraded today. Rockbox is too cool to allow politics to lock out loads of potential users surely.

Just explaining my position

[GodEater]

I think you guys are coming at this from a very technogeek angle. Most people won't have the means or skillset to do their own custom builds. So they will just not use Rockbox. This is not good for the project.

How is it not good for the project ? As has been stated many times - Rockbox is not a product looking for users - it's a project written by some nice people who happen to share that work with the rest of the world for no charge whatsoever. No-one is owed a build that just happens to work for them at the expensive of fixing this the right way.

I was pretty upset when I thought I'd lost the use of it after I upgraded today. Rockbox is too cool to allow politics to lock out loads of potential users surely.

It's not politics - it's about doing things properly.

[mitchelln]

How is it not good for the project ? As has been stated many times - Rockbox is not a product looking for users - it's a project written by some nice people who happen to share that work with the rest of the world for no charge whatsoever. No-one is owed a build that just happens to work for them at the expensive of fixing this the right way.

What a strange attitude. I would have thought you would have liked as many people as possible to enjoy Rockbox. It's a great project. It might also encourage loads of new people to contribute if they like it. I don't expect that much and I certainly don't demand anything. Nothing has happened on this problem for weeks and I am suggesting a practical work around that will make a lot of people very happy. Surely this is a good thing?
So what about this config idea of mine? Possible or not possible at a technical level?