Rockbox General > Rockbox General Discussion
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:
--- Quote from: GodEater on October 15, 2007, 04:13:32 PM ---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.
--- End quote ---
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.
--- Quote from: Llorean on October 15, 2007, 04:57:44 PM ---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.
--- End quote ---
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.
--- Quote from: Llorean on October 15, 2007, 04:57:44 PM ---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 ---
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 :)
--- Quote from: Llorean on October 15, 2007, 07:00:31 PM ---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.
--- End quote ---
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:
--- Quote from: danhibiki on October 16, 2007, 04:08:53 PM ---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).
--- End quote ---
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!):
--- Quote from: Llorean on March 23, 2007, 03:16:46 PM ---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.
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version