Rockbox General > Rockbox General Discussion
Latest Rockbox not working on Nano
Llorean:
You say "Why should I make Rockbox work?"
You also said you're interested in a working Rockbox. This seems contradictory. We could be more evil, and remove all links to any working build to force people to help us fix this thing. We don't go that far.
But if everybody immediately skips over the problems and just downloads an earlier build that works, like you intend to do, NOBODY will work on fixing it, ever. So thank you for choosing to opt out of helping, just like everybody else, and helping to insure that this problem will never get any better.
Skaffen:
I can understand that it's frustrating/annoying for developers to be told by an end user that they "must" or "should" do something when it's a free open source product (in this case fix a bug that affects a small portion of users without a clear pattern explaining why), however telling end users that if they want the problem solved they should learn programming seems a little off.
I'm sure that it's not a generally held belief that end users should fix bugs they uncover or put up with it - it's probably more an expression of frustration that this issue doesn't seem to be manfesting on any nanos in the hands of someone equipped to try get to the bottom of it combined with users treating it a bit like something they paid for rather than something they got for free.
Some questions I raised on the tracker that no-one commented on (perhaps they were stupid questions *shrug*):
1) Why, if the PPC chip in the nano is specc'd to 80Mhz, was it originally not run at that speed? It seems odd to run at a slower speed for so long for no reason, so I'm assuming there was a reason.
2) Do we know what speed Apple run the chip at in the Nanos with their firmware? Do they definitely run it at the full 80Mhz?
Looking at http://www.rockbox.org/irc/reader.pl?date=20060327 it seems that a decision was taken at that time to stick with 75Mhz because of possible problems IPL (ipodlinux?) had spotted with running it over 75Mhz.
I see from a later thread that there was a discussion between Llorean and amiconn about the nano problems http://www.rockbox.org/irc/reader.pl?date=20070728 ... But there's not really been much anyone's been able to do since?
I guess it's left that either someone with a nano that exhibits the problems learns about programming ipod hardware or sends the nano to someone who knows about programming ipod hardware?
From reading the threads it seems it's not unprecidented that a chip in a player has a lower stable max Mhz than the quoted spec for the chip. It also seems that it might not be known for sure exactly what the nano chip specification is - to quote "The PP5021 is a PP5022 internally, probably just not specified for the full 100MHz" (it may be that there's more concrete information since that discussion, of course).
Of course if Apple's OS runs the CPU at the full 80mhz then that's a clear indication that the problems with rockbox are because the hardware (of which flash is a part) can't handle it if initialised/accessed the way the Apple OS does, but if apple do run it at less than 80mhz then maybe they have a good reason for it - and it may well be that there is no ide timing problem or other thing that be overcome in the software because the hardware package overall is not designed to run at that speed (as with graphics cards some people can run them faster than designed without problems, of course).
GodEater:
--- Quote from: Skaffen on October 15, 2007, 03:16:24 PM ---I can understand that it's frustrating/annoying for developers to be told by an end user that they "must" or "should" do something when it's a free open source product (in this case fix a bug that affects a small portion of users without a clear pattern explaining why), however telling end users that if they want the problem solved they should learn programming seems a little off.
--- End quote ---
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.
This is exactly how *I* first became an active member of Rockbox, when I found the 80GB iPod was not supported. No-one else was working on finding out how - so I had to if I wanted Rockbox working on mine. As it happens, eventually it was LinusN who figured out the problem - but I'd done several months worth of work of finding all the things that weren't the issue to help him narrow down the issue. So perhaps someone doing that sort of work is all that it will take, and it will filter out all the cruft to a point where a current Rockbox dev will go "Ah ha - it's probably this", and find the fix.
Complaining that it doesn't work and whining that you want it put it back just because it's currently in a state that doesn't work on your Nano is not the way to get it fixed.
Llorean:
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.
2) There's not a good way for knowing how fast or slow the Apple OS runs the chip without a lot of reverse engineering work. Frankly, it also doesn't matter of Apple does or doesn't, if they don't it may simply prove that their code never chooses to run at that speed (it's apparently common in DAP firmwares to have a table of speeds for different bitrate and formats, and use one that's just slightly faster than the maximum necessary rather than our preferred approach of changing speeds between a boosted and unboosted state to save battery life) and not anything about the stability of that speed.
As was noted, it's internally identical to a 100mhz chip, but we chose 80mhz because that's the speed of the slowed iPod core we know of.
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.
nas:
--- Quote from: Llorean on October 15, 2007, 04:57:44 PM ---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.
--- End quote ---
I would say that 80MHz is working properly on *some* Nano devices. Maybe something else needs to be done to make it work on all devices or maybe some cannot handle it. Your argument for not reverting to 75MHz is not too convincing.
--- Quote ---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.
--- End quote ---
What makes you say that? The problems I see look like processor problems due to overclocking or overheating. Anyhow, hurray for open source. Here's a build based on that latest SVN source http://python.ca/nas/rockbox/ with only the maximum clockrate changed to 75MHz. At least people with non-working nanos can test all the changes that happened since r14004.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version