Latest Rockbox not working on Nano

[AlexP]

We (I use we in inverted comma's mainly meaning I) would like as many people as possible to enjoy the project, but that doesn't mean compromising and using a fudge instead of a proper fix.  Rockbox is written by coders primarily for themselves.  If other people enjoy it brilliant, and we do our best to help people enjoy it (how many people spend time coding and fixing features they never use, or spend ages helping people on these boards?).  However we don't want to put if half-arsed fudges when we know it isn't the real fix.

You said you suggested a work around, and that is all it is.  "We" want to do it the right way, not hide it with a work around.  As I have said before, personally I am rather ambivalent on this particular issue as it is a rather major problem, not just an annoyance (I suspect I would feel more strongly if I had a Nano).  I can see both sides of the arguement, and really do sympathise.  However, that is the current position of the "project" (such as it has one).

So what about this config idea of mine? Possible or not possible at a technical level?

I don't know.

[Llorean]

It's possible, but it 100% defeats the purpose. If it defaults to the non-bug case, why don't we just comment out the buggy setting, and ALWAYS have it in the non-bug case, and not fudge around with a config setting? It's essentially the same thing.

If the problem is not bothering people, the priority goes from "Somebody really needs to fix this" to "Oh, it'll keep until someone gets around to it."

Technical skills are something learned, not something genetic. Saying "Most of us don't have the technical skills to make our own build" means the exact same thing as "This isn't important enough for us to take a half hour to learn to do what is necessary to make our own limited workaround, so we feel YOU should cover up the problem instead of us having to spend a wee bit of time learning something."

Making your own build is probably less complicated than half the tasks you do on your computer anyway, and that's assuming you're someone who's computer experience is limited to web browsing, Microsoft Word, and email checking. It may look complicated because they're things you've never done before, but once you've done it once it's apparent how simple the basic process is, and that's all you'll need.


As for a question of politics: It's not. It's entirely possible that a temporary fix will go in some day, but if that ever happens it makes it drastically more likely there never will be a permanent fix, or at least it will happen a long time away.

Bugs shouldn't be covered up in pre-release software. You're again making the assumption that you're a "user" and you can choose to call yourself that, but in reality you're a tester. You downloaded a testing version, and if you choose to treat it like a release version, we can't really stop you, and if you choose not to help with testing, feedback, and development, nobody can force you to do that. But how you choose to use the software doesn't magically mean that you have become the new target audience.

Yes, it'd be nice to have more people using it. But it'd be nice to have them using a properly working software, rather than an ever growing pile of hacks and workarounds where bugs haven't been and now can't be fixed the right way, as that results in even worse software in the end. So bugs should be visible, then fixed, rather than hacked away as quickly as possible and forgotten until your software is so patchwork that the interplay of hacks makes it nearly impossible to maintain.

[mitchelln]

The thing is, this might be a physical rather than a software issue. You could very well be setting all the chip registers just fine. It could be though that there is an issue of the PCB out there that has a layout problem that causes timing faults. Nothing you then do in software will fix it. This is  a surprisingly common problem. In such cases the only way to proceed is to provide a work around. Otherwise nobody with that particular version of the PCB will ever get their device to work. The problem is you'll never get Apple to admit that there's a faulty version of the PCB out there. Who knows, their firmware might detect the PCB version and ramp the clock down slightly. Without cracking open loads of Nano's we'll never know.
So if this is the case and it is a hardware bug, what do you suggest? Do nothing?

I truly applaud your purist software ideals, but as a hardware engineer I know practicality sometimes is required in such cases. My suggestion seems simple and sensible to me.

[GodEater]

Then take the time to learn how to supply your own workaround if that's what you want.

[mitchelln]

Then take the time to learn how to supply your own workaround if that's what you want.

Just trying to help all those poor Nano owners who can no longer run Rockbox. I am lucky enough to have the skill set to be able to code this, other mere mortals have not.
Now the question is, if I do provide this workaround, will it be accepted into the Rockbox code base?

[GodEater]

No - as has been said many times.

People that want a workaround for this will have to do it themselves. If you wish to provide an unsupported build for those who can't / won't take the time to learn how to do it themselves, then you may host it in the Unsupported Builds forum.

[mitchelln]

No - as has been said many times.

People that want a workaround for this will have to do it themselves. If you wish to provide an unsupported build for those who can't / won't take the time to learn how to do it themselves, then you may host it in the Unsupported Builds forum.

Okay. I'll do that. It's been nice to meet such a friendly bunch of people.
Is there a thread that discusses the clock rate change from 75 to 80MHz and why it was done?
Thanks!

[pixelma]

There already is one that provides this in the unsupported builds forum... It seems to be updated in regular intervals as well.

Search is your friend.

[GodEater]

Is there a thread that discusses the clock rate change from 75 to 80MHz and why it was done?
Thanks!

Yes. This one.

See this post : http://forums.rockbox.org/index.php?topic=11504.msg100225#msg100225

[mitchelln]

There already is one that provides this in the unsupported builds forum... It seems to be updated in regular intervals as well.

Search is your friend.

I can't actually find why the clock was upped to 80MHz. Was it based on a paper spec or reverse engineering, for example?

[GodEater]

Llorean's post answers that question - please read it.

[mitchelln]

Llorean's post answers that question - please read it.

We both must've been replying at the same time, so I didn't see your link. Thanks for heads up.

[mitchelln]

Okay. I've had time to read the whole multi-page post now. I have to say that I do find it odd what has gone on here. From what I can see, the clock was upped to 80MHz for no real solid reason other than "technically and theoretically it can be done". People then reported that is caused problems and the change was not reverted. This is the first time I've seen this happen on Rockbox.

As an embedded hardware engineer, I have to say that this has all the classic symptoms of a device that is being clocked beyond it's limit. I cannot see anything to disprove this. Later Nano's probably cope due to a different PCB issue or a later batch of core (later batches always tend to overclock better). When you overclock a chip you will get all sorts of weird behaviour. It will upset bus and memory timings that may make it look like another part is at fault. The very fact that this has gone unfixed for many weeks indicates to me that this is hardware related. Just my professional opinion

Thanks to Neil Schemenauer for providing a 75MHz build. It works great on my Nano.

[Llorean]

We know that the PP502x series chips used in iPods either have a speed of 80mhz or 100mhz. We chose 80 as a maximum rather than clock different iPods at different speeds.

Whatever the problem is seems not to be with the clock speed itself, but as I've said, with timing relative to some other piece of hardware in the device.

If it truly, truly is a hardware fault that prevents certain devices from working, then coding a fix for it isn't a workaround any more: It's a fix.

Until such time as it's actually identified what's wrong, 80mhz is known to be a speed that is valid for the processor, and evidence suggests the problem is actually in other hardware in the device not being used quite properly.

One of the biggest benefits of going from 75mhz to 80mhz: Music is less likely to skip when the device is under load. Evidence is very, very strong that this processor speed is supported, and plenty of signs suggest it's other hardware in the device is the problem, but as of yet there's no firm evidence that it's a hardware fault, and it could very easily be a case of us not initializing or communicating with that other hardware right yet.

If we do establish though  that the only way to keep these Nanos from crashing is to clock it down, rest assured, it will be done. Our intent isn't to screw over users, it's to get things fixed properly.

As I've said, users have now reported going back to 75mhz and still experiencing these bugs when their device gets too hot, and some have revealed that their device would occasionally glitch like this in the past with them thinking that it was more just "Rockbox isn't done yet" than anything they should be reporting, so signs suggest rather strongly that just clocking back to 75mhz isn't going to fix it, just put it in hiding again, and if anything should be done it should be someone investigating the actual problem and looking for a _full_ fix rather than one that goes from "Some people experience it" to merely "Only a few people experience it" because then you're just choosing to screw over less people for your own personal benefits rather than actually concentrate on fixing the problem.

So I think you can see why I favour a real fix: I'd rather the problem be gone for good, and properly fixed.

[mitchelln]

Great response Llorean. Thanks