FS#7505 - Gigabeat Flashwriter
Attached to Project:
Rockbox
Opened by Karl Kurbjun (kkurbjun) - Sunday, 29 July 2007, 15:24 GMT
Last edited by Karl Kurbjun (kkurbjun) - Monday, 24 November 2008, 06:53 GMT
Opened by Karl Kurbjun (kkurbjun) - Sunday, 29 July 2007, 15:24 GMT
Last edited by Karl Kurbjun (kkurbjun) - Monday, 24 November 2008, 06:53 GMT
|
Details** WARNING **
This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. Even though there are preventative measures in place this flashwriter plugin may erase your flash and leave you with a broken player. Please be careful and pay special attention to the messages given when using this tool. *IN THE UNLIKELY EVENT THAT THE TOOL ERRORS WHILE FLASHING IT WILL TRY TO RESTORE THE BACKUP. *IF RESTORE FAILS AND THE TOOL GIVES AN ERROR MESSAGE STATING NOT TO TURN THE PLAYER OFF PLUG THE PLAYER INTO THE CHARGER AND POST A MESSAGE HERE. (DO NOT LET THE PLAYER TURN OFF)! This plugin erases a sector of the flash and then rewrites it with the file bootloader.bin. It then modifies (read/modify/erase/write) the first sector and patches the reset vector to point to the code in bootloader.bin. The flash can be accessed at 0x04000000, and it is 1 MB in length. This still needs testing. It is safe to erase and write to the sector located at 0x04050000 (actually the latest version uses 0x040A0000). This area is only used for visual images. This has been tested with 2.00, 3.00, and 3.02 firmware. If the program shows an ABORT message when running Check flash MD5 (version) please backup the flash and upload the backup.bin and backup.md5 files here. This will only work with original releases; please do not upload previously hacked images. If you upload a file please include the version number. |
This task depends upon
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.
Thanks again for all of your hard work Karl. I'm incredibly excited for this.
Thanks again Karl.
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.
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.
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 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.
I'm very happy for this improvement!
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!
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. ;)
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.
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.
P.S. Great work - this is so much faster :)
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 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.
here are my files.
CFP.
CFP.
CFP.
It would be great to get this into SVN!
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.
I am glad you like the plugin :).
http://pastie.org/1339003
That leaves only the signed/unsigned warning
Perhaps someone with a little more knowledge of how to get rid of the signed/unsigned warning can tackle that?
The hash isn't recognized by the plugin.
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
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