Rockbox

Karl: Have you had any more time to work on this?

I have not worked on it since I left for China and started the m:robe port. My JTAG cable, desktop system (with a parallel port), and the gigabeat with the JTAG interface connected is still in storage. Once I finally move everything out I plan on working on it again. Are you interested in trying it out? There's some work that will need to be done to the way the bootloader is built, but I think that it was pretty close in terms of hardware initialization. If you want pointers on setting up a JTAG interface I would be happy to help.

I'd like to see this finished, but I have no time for it at the moment. And when I get time I'm still committed for the WMA decoder improvements. Thank you for the offer though.

Over a year since the last code update. This adds some more functionality to the flash writer and some error checking (more is needed). The Gigabeat F is now able to boot from flash and shutdown with the included diff. I still do not recommend using this till I am able to get the MD5 sums working so that the code can verify the flash image that will be patched has been tested in hardware. I also need to test this on players other than my JTAG setup. It is /relatively/ safe to use for the backup and restore functions but I would recommend sticking to the backup feature till more error checking is added. This also features dual boot functionality. Note that the MD5sum function reboots the player (I have not traced this bug yet).

Add some needed error checking to make sure that sectors are not erased/patched without data present when "Install Rockbox bootloader" is run.

I'm very excited to see work being done on this again. Thanks for your hard work Karl!

Thanks for the encouragement, it helps me keep interest :). This update adds more of the needed error checking. The timeouts need to be updated/fixed and MD5sum is still not working so I pulled it from the menu for now. All of the other routines work pretty well, but I still do not recommend using this without a JTAG setup. The main code updates needed for dual boot and proper shutdown are now in SVN.

Here is the latest version of the flash writer. I have tested this with version 3.02 FW and 2.0 FW. 95% of the checks are in place to protect the flash. These are the missing checks that I would like to add:
1) A check to make sure that the charger is plugged in and the player is mostly charged (>80%?).
2) An MD5 sum check after the flash is patched to double check to make sure that it matches a known bootloader release (a byte for byte verification is already done so this is redundant, but can't hurt…).
3) An MD5 sum on the bootloader.bin file to make sure that an untested bootloader is not being written.

There are checks in place to make sure that:
1) An untested OF flash image is not patched
2) A backup of the OF flash is made before attempting a patch
3) The bootloader image is present before attempting to patch the flash (or restore)
4) The bootloader image is not too large for the sector it is being stored on
5) There were no writing or reading errors.

I still need to do the timings properly for writing/erasing the flash. Currently the code does not have any timeouts so if there is a bad flash device it will never stop trying to write to it or erase it.

Once I have the timings right I think this will be acceptable for others to use for flashing (honestly at this point it's pretty safe already), but ideally I would like to get the rest of the checks desired in the code first.

For now though if anyone wants to start making sure their flash image is up to par they can run the "Check flash MD5 (version)" menu option. If an abort message comes up then I need a copy of the flash to verify that it will patch cleanly. A backup can be made by running "Backup Flash and MD5sum". Do not use "Restore Flash Backup" or "Install Rockbox bootloader" until the proper timings are added since these two operations do the erasure and writing to the flash.

I attempted doing the MD5 sum check and I got the ABORT error so here is my backup.bin.

Thanks again for all of your hard work Karl. I'm incredibly excited for this.

Thanks for providing this, I will verify this image's functionality. For the purpose of the flash writer digests do you know which version of the firmware you have on your player? Did you run any of the flash hacks that were provided by shoora? If so I have a backup image of a clean v3.02 image that I will post so people can restore back to a fresh image. If you didn't run any of shoora's hacks do you happen to have a copy of your original GBSYSTEM folder? I am trying to collect full backups of all the different firmware revisions.

Yes, I did do some flash hacks that shoora provided. I'll try and do a clean install of the v3.02 firmware.

Don't worry about doing a clean install; I have a copy of the original 3.02 firmware image and the GBSYSTEM associated with it. I will put a copy that can be used with the restore function once I get the proper timing implemented which shouldn't be too long.

Well, I couldn't find a copy of 3.02 but I did find 3.00 so I installed that instead. I got the same MD5 abort message. I've attached the necessary files. If you want the GBSYSTEM folder, I'll have to e-mail it to you because it's 10mb when compressed and flyspray won't allow more than 2mb.

Thanks again Karl.

   backup.bin (1 MiB)
   backup.md5 (0 KiB)

Sorry for the delay, here is the latest version of the flashwriter. It now does MD5 hashes after patching the flash with a known bootloader. It also checks the hash of the bootloader to ensure that a fully tested file is being used to patch. The only thing that I need to add is a check to make sure that a charger is present.

Kyle, I tested your backup.bin on this version and it works fine on the two players I tested. At this point I think the code is as safe as it can get aside from the charger check. Just make sure you pay close attention while running the program to verify that everything applied clean and there were no errors. Dual booting works, but you have to flip the power switch off and then on before it will go to the OF (press menu then power (may have to hold it for a couple of seconds)). I have added a charging screen to the bootloader and it checks to see if hold is on.

I don't expect any, but if you have any trouble while flashing (as in errors) keep the player plugged into the wall and e-mail me to let me know, we can figure out a quick fix if needed.

I have been using this for a couple of weeks now on my players and I have not had any trouble, the player appears to be shutting down properly.

Also note, that if someone has a hacked flash, or an untested flash they can use the backup.bin that Kyle posted in their root directory to run the Restore flash backup command. This will flash the V 3.0 original firmware image to the player.

I tried it out and it worked perfectly. I got a little confused about dual booting but I realized you have to rename FWIMG01.DAT.ORIG back to FWIMG01.DAT.

Thank's a lot Karl! I really like the super fast booting. It's really nice and it works great.

Thanks for all of your hard work on this.

Karl, I would like to try this later. I just need to place this in the source tree and add to SOURCES, right? I have an unmodified flash, so it seems I can immediately use the plugin to write the bootloader.bin to flash. I'm very excited to try this!

Success! Boot time is much faster. Will this make it into SVN soon?

Justin,

Sorry for the delayed response. Thanks for testing this I really appreciate it. I have a new version that adds a wakeup alarm feature as well which I want to release before committing. The checks that are in this code are extremely strict so I need to have a final bootloader build done with, hopefully, the wakeup alarm before committing this to SVN. If I can get motivated I think a commit could be done soon though. Which version of the OF bootloader do you have out of curiosity? Did you run into any quirks or was the process pretty smooth? If you have any suggestions on improvements I would be interested since I want to make this as error-proof as possible.

Thanks again,
Karl

I see. A wake up alarm will definitely be a nice feature. :)

I ended up having to Restore with the posted backup.bin as the version I had in flash was reported as untested (I believe it was 3.02). After that, the process went smoothly.

Assuming that I want to flash a new bootloader, I should use the bootloader.bin that's located in the bootloader subdirectory of my build directory, right? Then, I assume I need to Restore an unmodified, tested OF bootloader as I did before and do the update again from there. Correct?

Heh. That message looks insistent for some reason. Please don't take it that way. :)

I'm very happy for this improvement!

One thing I have noticed that I will have to test further. Currently, changing the line selector colors (for gradient selector bar) does not appear to work initially. However, once you back out to the main menu the selector colors change successfully. I haven't gone back to the OF bootloader to see if the behavior is different yet. I guess that's the next thing to test. Do either of you see similar behavior?

No worries, I didn't take it that way. If you want to write a new bootloader.bin file to your player you will have to restore till before flashing till a final release is made. After that I plan to start adding hashes for the flashed, patched bootloaders. If you want to compile your own bootloader you will have to define ENABLE_DEV and then the writer will not stop when the hashes don't match. You will get quite a few abort messages from the tool, but it will continue as if they didn't happen. The flashwriter checks the hash of the flashed firmware, the bootloader, and the final patched, flashed firmware. If any of these don't match known hashes the tool will either abort or try to restore the flash. I have not seen the bug and I would be really surprised if it is caused by running from flash, but it would be worth double checking against the old bootloader.

Here is the last build of the bootloader I think I will make unless there are features to be added or bugs to be fixed. You will need to build with this updated version of the flash writer as well. This bootloader build supports the wakeup alarm. You will need to #define HAVE_RTC_ALARM in config-gigabeat.h and build a normal build to use the wakeup alarm. I am not sure how exactly to handle the feature in the menu since it will not work for people that do not have the flashed bootloader which is the majority of people right now. Enabling it by default in user builds could create confusion.

   bootloader.bin (53.1 KiB)

I think adding a define for those of us who have a flashed bootloader is fine for now.

I'll restore back to the OF bootloader, test to see if the line-selector-color behavior is any different (just for the sake of testing), then update to the newest bootloader (with new gigabeat_flash plugin, of course). Thanks so much for your work on this!

Well, I have flashed with the new bootloader, cleared settings, built a fresh build with the alarm enabled and I still have that strange issue with the line selector colours. I don't really change them much, so I don't know when my player started doing this. Weird.

On topic, I assume that the RTC just tells the bootloader to boot the player. If I want music to play when it starts then it seems that I should set the start screen to resume playing. I won't use it as my alarm until I have a bit of a play with it. ;)

The RTC clock alarm doesn't care what your starting screen is. It will boot the player and try to resume playback. As long as you have a current playlist and are not at the very end of it the player will boot and start playing where you left off.

I also included what I think will be the last version of the flashwriter tool. It checks the battery life (you must be charged at least to 75%) and it makes sure that the charger is connected before it lets you perform any operations that involve erasing/writing to the flash. I also cleaned up the messages.

   gigabeat_flash.c (19.7 KiB)

I get these backups

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

I just flashed mine too. It works like a charm.

My firmware was modified so I had to restore kyle's backup.bin.
Check flash MD5, Backup flash and MD5 hash, Restore flash backup and Install/Update bootloader all worked as intended.

Thanks for your work.

P.S: I couldn't get Dual boot to work though (even after switching the power off). I can get a garbled screen of the OF when the hold is on (by pressing menu and power) but whatever I do I can't get the OF to boot (I made sure to rename the firmware file FWIMG01.DAT from .orig) . Maybe it has to do that I have a modified version of the original firmware.

Here is my backup etc.

P.S. Great work - this is so much faster :)

   backup.bin-AEP (1 MiB)
   backup.md5-AEP (0.1 KiB)

Karl: Are you going to commit this?

Long delay again..

Thanks for the testing everyone. Michael, I am planning on committing this, I had one more feature that I wanted to finish that gave the gigabeat a boot screen based on the OF flash image along with a feature to change the boot image in flash. This requires some modification to the checksum that I am performing, the boot screen change code works in the flasher and the bootloader now handles it ok, I just haven't changed the checksum calculation. This allows the bootloader to be built identically between the flashable version and the non-flashable version since right now when I make the flash builds I ifdef 0 the section in the lcd code that copies/translates the old framebuffer code when initializing the LCD.

Thanks for the tesitng Alex, Alexander, and Frank. I'll include the backups that you provided in the commit.

Alexander, the modified firmware shouldn't effect it, I wonder if there's a problem mixing the hard drive fw image versions and the flash image. I've only tried dual booting with the same flash/hard drive version. The corrupt screen that you see when hold is enabled is because the firmware flasher overwrites some of the image locations including the hold warning in the OF. I will add/modify a check for hold in crt0.s since I didn't think of the condition that menu, power, and hold are on. One thing to make sure is that you are holding menu/power long enough. It has tripped me up a couple of times since the OF delay is so long.

I noticed that the Rockbox bootloader isn't aware of the remote. I used to be able to start Rockbox by holding the Play/Pause button on the remote for 5 seconds. I think this is the standard behavior for both the Gigabeat F and S since my new S60 does this with the remote. I find this to be a nice option for certain situations, like keeping the player in a backpack. Is this likely to make it in?

Here's an updated version that works with a current build. It worked great on my Gigabeat F40.

   gigabeat_flash.c (19.5 KiB)

Could anyone write something like a readme/manual for this? i'd be eager to test it myself, but i have no clue how to go about it… i have three gigabeat F devices so one them can get bricked, not a big deal.

Karl: Any new progress with this patch?

Hi, I attempted to use this, but I'm a bit concerned that it tells me that my firmware is untested.

I tried it on two different F40's. Both were rebuilt - came with harddrives that had a corrupt gbsystem folder. One of them i know i installed v3.00 on after finding a v2.0 gbsystem folder to get it up and running with the OF.

The other one, I'm not sure which version of the OF it had initially. I overwrote the gbsystem folder with the minimal firmware files. After getting the 'abort' message i performed the same procedure i had with my first to get the v3.00 OF installed (dump on the v2.x gbsystem, run v3.00 updater) and then re-rockboxed it.

So, both of my F40's should have the same version of the flash loader, right? Well, I have three backups with three different md5sums.

I decided to live dangerously and update the plugin to accept the checksum on my (unrecognised) F20 OF (attached). It works.

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

Another failed checksum on my F40

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

I followed Frank's lead and lived dangerously. Works fine. :D

Thanks again, just have to get used to the instant boot :) Today I was holding the button again for 3 seconds without looking at the player.

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

Here are backups from my Gigabeat F10.

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

finally, i've also been able to do this… i also got the failed checksum error on my f40, but i think i'll do it anyway.
here are my files.

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

I compiled the writer, but my gigabeat is also not recognized. I have attached the files. How exactly do i edit the tool to accept my md5?

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

Karl, it's been more than a year since you weighed in on committing this. Can we get an update on the status of this patch? Will it ever be committed?

Any update on this patch ?
CFP.

My gigabeat wasn't recognized. I've attached the files.
CFP.

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

Another Gigabeat (F60, as the previous one).
CFP.

   backup.md5 (0.1 KiB)
   backup.bin (1 MiB)

I got a new Gigabeat F40 and the hash isn't recognized. Attaching backups.

   backup.md5 (0.1 KiB)
   backup.bin (1 MiB)

I used the known good backups to flash to a known version. Now I have fast boot on both F40s. :)

It would be great to get this into SVN!

It looks like there is a unique encryption key, unique register setup, some type of manufacturing activation, or combination of that is done for the players.

Each image has a small amount of unique data starting around offset 0xF_8000. There is a unique 16 bit value at offset 0xF_8678, 0xF_9FFE, and then there is a large portion of image specific data starting at 0xF_A000 which continues to at least 0xF_BFFF. At 0xF_C000 there is what looks like a version string, but the spaces between the ASCII characters use unique values. Finally, the last 16 bit value in flash appears to be unique per image.

Those sections of data are messing up the MD5 hash calculation which is used verify that the image has been tested. It should be easy enough to change the calculation and put the new hashes in the tool.

My suspicion is that this is for the SAT encryption, but I don't really know.

In any case using the working images creates clones. It wouldn't surprise me if someone could move SAT encrypted tracks from one player to another after copying the flash.

But then, does it mean that it would be reasonably safe to try and install it on my DAP? How would I need to modify the code to have it accept my hash?

Ok, I flashed both my Gigabeats, and it worked perfectly \o/. Karl, this plugin rocks :)

It is safe to use the plugin to write the flash image Kyle submitted with the restore operation. Once that is done you can put the bootloader in flash. All of the other images that people have submitted should also work, but the hash calculation is too strict because each image has that unique data.

I am glad you like the plugin :).

It's just great

The plugin no longer builds on recent SVN versions. I get this error message now when building:

http://pastie.org/1339003

Delete the PLUGIN_HEADER line and add a "static" in front of "inline" for the inline functions
That leaves only the signed/unsigned warning

Updated with Nils' advice; the plugin now builds with only the warning he mentioned.

Perhaps someone with a little more knowledge of how to get rid of the signed/unsigned warning can tackle that?

   gigabeat_flash.c (19.6 KiB)

Attached is the backup of my F40's flash, backed up with the latest plugin revision.

The hash isn't recognized by the plugin.

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

Hi, attached are the backup.bin and md5 from my Toshiba Gigabeat F60 (I had to use Kyle Kamperschroer (Phalangees)'s v3 backups in order to pass the checks performed by the gigabeat_flash plugin, before being able to flash the "fast" bootloader.bin).

To Justin Hannigan (Chronon): I confirm that long-pressing the play/pause button on the wired remote does not switch on the device anymore.

Just out of interest, am I correct in thinking that in order to return to the original "slow" bootloader, I simply use the plugin again and flash Kyle's backup? (or mine, actually)
I guess that the plugin will flash the full 1MB backup even though the actual bootloader binary is only ~54KB, right?

Many thanks, and cheers! :)
Dan

gigabeat_flash.c
http://www.rockbox.org/tracker/task/7505?getfile=22981

bootloader.bin
http://www.rockbox.org/tracker/task/7505?getfile=17823

Kyle's v3 backups:

backup.bin
http://www.rockbox.org/tracker/task/7505?getfile=17591

backup.md5
http://www.rockbox.org/tracker/task/7505?getfile=17592

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)

Follow-up to my post above:

The alarm clock works great :)

After I set the alarm clock in "settings", I just start some music (i.e. I play the song that I want to be woken-up / alerted with), I then immediately long-press the power button to turn the device off, and when the device boots again the aforementioned song starts playing automatically. Magical ;) The alarm does nothing when the device is already running, but I guess that's the expected behaviour, as per the Rockbox documentation: " If the player is turned on again before the alarm occurs, the alarm will be cancelled.".

I added the following code to ./rockbox/firmware/export/config/gigabeatfx.h (and I did a "make reconf + clean" in order to regenerate the language packs):

/* Define if the device can wake from an RTC alarm */
#define HAVE_RTC_ALARM

Cheers, Dan

Hi, attached are the backup.bin and md5 from my Toshiba Gigabeat F40 (see more detailed results for my F60, two posts above this one).

   backup.bin (1 MiB)
   backup.md5 (0.1 KiB)