- Status Closed
- Percent Complete
- Task Type Bugs
- Category Bootloader
- Assigned To No-one
- Operating System Coldfire-based
- Severity Critical
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#7533 - SVN bootloader fails to boot rockbox (H100 & H300)
I just tried to flash my H115 with an SVN bootloader (r14180M-070726). It compiled cleanly and produced a valid hex file, which flashed okay on the device.
Fortunately all the crucial parts of the bootloader work. USB bootloader mode and OF loader work just fine. It is just that when you try to start rockbox bootloader will hang in the process of it.
After some debugging (putting printfs all over the place) I discovered that the bootloader hangs in ata.c, function ata_hard_reset(void) just after the call to the ata_reset() function. It seems that it hangs on the SET_REG call.
I can’t debug more on it because obviously I don’t know what I am doing and flashing again and again the unit is very tiring and risky.
Edit: Today I tested to flash an SVN bootloader on my H300 and I get exactly the same behaviour as the H115. It seems that something is wrong, and it is not target dependant.
2007-10-02 07:55
Reason for closing: Fixed
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
I committed LinusN's patch.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
As the edited first post says, the same behavior applies to H300 too.
this looks like the same thing that happens to my h380 (h340 with new disk)… some IDE stuff not ok?
By the way the last known working revision is r12547.
That sounds really odd. This is the change from r12547 to r12548:
Index: bootloader/main.c
— bootloader/main.c (revision 12547)
+++ bootloader/main.c (revision 12548)
@@ -41,8 +41,7 @@
#include “file.h” #include “uda1380.h” #include “eeprom_settings.h” -
-#include “pcf50606.h” +#include “rbunicode.h” #include “common.h”
#include <stdarg.h>
r12548 is ok here, must be a later mod… I’ll keep looking!
OK, after a lot of flashing I conclude that this was broken in r14015 (but worked in r14014).
Reverting http://svn.rockbox.org/viewvc.cgi/trunk/firmware/export/config.h?r1=14014&r2=14015 (thus re-enabling CPU frequency switching) fixes the H300 bootloader for me with current SVN. So, there’s some code in ata_init() that’s failing without CPU frequency switching…
Funny, why wouldn’t bootloaders use frequency switching?
Well, the issue here is that the ATA timing parameters are set by cpu_set_frequency() on the Coldfire targets.
Line 188 in bootloader/iriver_h300.c:
The change in config.h removes the call to set_cpu_frequency() and the ATA (and other peripherals, like I2C and timers) are not set up correctly.
Here is a patch that solves the problem in much the same way as on the PortalPlayer targets. I have tested it on iriver H140 and iAudio X5, and it works fine. I’d like someone to test it on H300 before committing.
Hi Linus, works fine here on H300. Commit away!
Quote:
“That sounds really odd. This is the change from r12547 to r12548”
I should have clarified that this revision was the last I tested with success, sorry for the confusion.
Thanks Linus for looking into this. I will try to flash it right away.
Success! It works like a charm now.
I just flashed revision 14811 with Linus’ patch provided.
Like Steve said. “Commit away!”
I was scared to hell though, at the first boot I got an exception error! (Can’t replicate anymore)
just tested this patch with a clean svn and it works fine.
commit and release…