I just released an updated version with a fixed sansapatcher bug and includes the ability to dump hidden firmware partition with the up button (included in Rockbox bootloader a while back). This is probably useful for recovery purposes.

A patch against rockbox SVN is available on the site for anyone that wants the source.

Just as a note, all bootloaders that are not the binary built bootloader provided at download.rockbox.org are considered "unsupported builds." We provide a specific SVN revision compiled under specific condition so that we know what is to be expected because different versions of bootloader can have strange effects on the firmware (since some hardware initialization takes place there) so just like we don't support builds with patches, we don't support *any* bootloader or build running on a bootloader that isn't the one we provide, because we can't know that the bootloader isn't causing something strange to happen. Sometimes they're so quirky that even a different compiler version can completely break them, even when there are no changes to the code.

Just as a note, all bootloaders that are not the binary built bootloader provided at download.rockbox.org are considered "unsupported builds." We provide a specific SVN revision compiled under specific condition so that we know what is to be expected because different versions of bootloader can have strange effects on the firmware (since some hardware initialization takes place there) so just like we don't support builds with patches, we don't support *any* bootloader or build running on a bootloader that isn't the one we provide, because we can't know that the bootloader isn't causing something strange to happen. Sometimes they're so quirky that even a different compiler version can completely break them, even when there are no changes to the code.

Sorry... I didn't get it. Are you saying that using alternative/modified bootloaders like this reverse one is not recommended?

I just tried the reverse bootloader. It didn't work for me. (using a Sansa e280, no micro SD card).

It DID boot into the OF first, but I couldn't get it to boot into rockbox using either the left button OR the select button. FWIW, the initial Sansa screen came up, then the screen blanked, then showed the 'all text bootload screen', as I call it, then just booted into the OF.

I went back and reinstalled the normal bootloader and everything is fine again. (boots to rockbox first).

Followed the instructions on your page about:
"sansapatcher -a reversebl.mi4"

Sorry... I didn't get it. Are you saying that using alternative/modified bootloaders like this reverse one is not recommended?

You can do whatever you want, but don't report any bugs to us while using it. It's unsupported.

We can't fix bugs in other people's code, so don't expect us to, and don't come to us with them, basically. If you didn't download it from rockbox.org, it's not ours and we don't support it. Even if you *think* it's our part of the code causing the problem, test it with our version, and be using only our version any time we ask you for more information.

What does this do? I don't realy understand what you are talking about. I mean, I know it loads the origional Firmware by pressing Select, but is that all? Does it do anything else, or is it just an easier way of doing what we've been doing? I'm sorry, I just don't get why we actually need this.

According to the Original Post what it does is load the Original Firmware first and allows you to load the Rockbox firmware second by pressing the select button. With the official bootloader, Rockbox is loaded first.

I found this:In a nutshell is an idiom. It means “in a few words” or concisely. It is the act of summing up the facts in a brief manner but containing all the relevant information. It is something that is described in as few words as possible. Thus this idiom is used to introduce concise summary. It is a hyperbolic statement or expression.

I was able to reproduce the bug where Rockbox won't load. I was also able to produce it in my MultiBL. I suspect it has something to do with sansapatcher, since I didn't use that on the last version.

Update: I've isolated sansapatcher to be causing the problem. Placing the mi4 on the player and naming it PP5022.mi4 works just fine. This has me a bit confused. What exactly does sansapatcher do when you run it with the -a option? I was under the impression that that would do the same thing as putting the PP5022.mi4 file on the player.

This has me a bit confused. What exactly does sansapatcher do when you run it with the -a option? I was under the impression that that would do the same thing as putting the PP5022.mi4 file on the player.

When using the "-a" option you need to specify the name of the bootloader to install, ie.

Code:

sansapatcher.exe -a PP5022.mi4

If you don't use any options, sansapatcher will install the bootloader that is embedded in the program.

Basically, the firmware partition on the disk looks like this normally:
[FIRMWARE........]
When you -a an MI4 you get
[BOOTLOADER|FIRMWARE]
If you -a a different MI4 it overwrites the bootloader portion. But the firmware is kept there, and a properly working bootloader loads the firmware from the firmware partition. OF.MI4 or whatever it was called isn't used by the official version of Rockbox anymore, though support for it still exists it should never be necessary.

If you put PP5022.MI4 on the player, and it's *just* the bootloader, you get
[BOOTLOADER......] instead, without any firmware there, meaning it must load from the OF.MI4.

It's possible you've broken the ability to load from the firmware partition, but it's detecting the OF there, failing to load it, and crashing, when you're using sansapatcher.

So I am guessing that sansapatcher needs to be run without rockbox installed so that it can take the firmware that is currently on the player (OF) and move it to the firmware partition. This removes the need for the OF.bin file.

AHA! I looked back at the bootloader code and recognized this behavior in a part I had skimmed over before. When loading the Original firmware, first it checks the firmware partition, then tries OF.bin.

This leads me to a couple more questions:
How big is the firmware partition, and could several different firmwares be put on it?

The main advantage is that you can reformat your player and still be safe (have a USB mode, for example). But also, you've got if I recall 20mb of space being used so you might as well store the original firmware in it, rather than leaving it sitting around empty (or nearly so) with just the Rockbox bootloader.

That's the real advantage, simply safety (especially since we don't have our own USB mode). In fact once we have a USB mode of our own, you'll be able to sansapatcher -a rockbox.mi4 and put Rockbox there. You'll have to do it every time you want to update, but it will make boot time noticeably faster (or should).

But yes, Sansapatcher should ONLY be run on either a device that has only the retail firmware installed, or a device that has the retail firmware + a sansapatcher installed bootloader (sansapatcher will detect it, and remove it and then add the newer version, rather than just scooting it over some more).

So I am guessing that sansapatcher needs to be run without rockbox installed so that it can take the firmware that is currently on the player (OF) and move it to the firmware partition. This removes the need for the OF.bin file.

Not true. The OF is already in the 16 MB hidden partition.

You install rockbox the usually way (the rockbox firmware is located in the ".rockbox" directory.

Optionally you can place an unencrypted OF in the root directory of the player. This will speed up the loading the OF. You will probably should do this if you have installed Rockbox the old way.

Optionally you can place an unencrypted OF in the root directory of the player. This will speed up the loading process. You will probably should do this if you have installed Rockbox the old way.

I see no reference to this in the sansa Rockbox manual. Are you saying to run mi4code on the OF PP5022.mi4 to get PP5022.bin, and then put that on the root of the player?

Back to the ReverseBL: I figured out what I need to change in the code to get it to work with sansapatcher, and will get a new version out tomorrow. The fix won't work with the MultiBL, which is what I was referring to when I asked about several firmwares on the partition.