FS#7533 - SVN bootloader fails to boot rockbox (H100 & H300)

Attached to Project: Rockbox
Opened by Alexander Spyridakis (xaviergr) - Saturday, 04 August 2007, 16:10 GMT
Last edited by Steve Bavin (pondlife) - Tuesday, 02 October 2007, 07:55 GMT
Task Type Bugs
Category Bootloader
Status Closed
Assigned To No-one
Operating System Coldfire-based
Severity Critical
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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.
This task depends upon

Closed by  Steve Bavin (pondlife)
Tuesday, 02 October 2007, 07:55 GMT
Reason for closing:  Fixed
Additional comments about closing:  I committed LinusN's patch.
Comment by Alexander Spyridakis (xaviergr) - Sunday, 26 August 2007, 20:33 GMT
As the edited first post says, the same behavior applies to H300 too.
Comment by Peter D'Hoye (petur) - Saturday, 22 September 2007, 11:09 GMT
this looks like the same thing that happens to my h380 (h340 with new disk)... some IDE stuff not ok?
Comment by Alexander Spyridakis (xaviergr) - Saturday, 22 September 2007, 22:45 GMT
By the way the last known working revision is r12547.
Comment by Linus Nielsen Feltzing (linusnielsen) - Monday, 24 September 2007, 07:42 GMT
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>
Comment by Steve Bavin (pondlife) - Friday, 28 September 2007, 11:21 GMT
r12548 is ok here, must be a later mod... I'll keep looking!
Comment by Steve Bavin (pondlife) - Friday, 28 September 2007, 13:19 GMT
OK, after a lot of flashing I conclude that this was broken in r14015 (but worked in r14014).
Comment by Steve Bavin (pondlife) - Friday, 28 September 2007, 13:33 GMT
Reverting (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...
Comment by Linus Nielsen Feltzing (linusnielsen) - Monday, 01 October 2007, 08:53 GMT
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:

/* Set up waitstates for the peripherals */
set_cpu_frequency(0); /* PLL off */

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.
Comment by Linus Nielsen Feltzing (linusnielsen) - Monday, 01 October 2007, 10:14 GMT
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.
Comment by Steve Bavin (pondlife) - Monday, 01 October 2007, 10:36 GMT
Hi Linus, works fine here on H300. Commit away!
Comment by Alexander Spyridakis (xaviergr) - Monday, 01 October 2007, 15:10 GMT
"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.
Comment by Alexander Spyridakis (xaviergr) - Tuesday, 02 October 2007, 03:19 GMT
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)
Comment by Jonathan Gordon (jdgordon) - Tuesday, 02 October 2007, 04:10 GMT
just tested this patch with a clean svn and it works fine.
commit and release...