#define _PAGE_ Rockbox in Flash - FAQ and User Manual #include "head.t"
by Jörg Hohensohn aka [IDC]Dragon
1. What is this about?
2. How is it working?
3. Is it dangerous?
4. Will it work for me?
5. How do I flash the firmware?
6. How do I bring in a current / my personal build of Rockbox?
7. Known issues, limitations
This package contains tools to update the flash content of Archos Jukebox Recorder / FM.
Some terminology I'm gonna use in the following: Firmware means the flash ROM content as a whole. Image means one operating software started from there. By reprogramming the firmware we can boot much faster. Archos has a pathetic boot loader, versus the boot time for rockbox is much faster than the disk spinup, in fact it has to wait for the disk. Your boot time will be as quick as a disk spinup. In my case, that's 3 seconds from powerup until resuming playback.
The replaced firmware will host a bootloader and 2 images. I use data compression to make this possible. The first is the "permanent" backup, not to be changed any more. The second is the default one to be started, the first is only used when you hold the F1 key during start. Like supplied here, the first image is the original Archos firmware, the second is a current build of Rockbox. This second image is meant to be reprogrammed, it can contain anything you like, if you prefer, you can program the Archos firmware to there, too.
I supply two programming tools:
I will provide more technical details in the future, as well as my non-user tools. There's an authoring tool which composed the firmware file with the bootloader and the 2 images, the bootloader project, the plugin sources, and the tools for the UART boot feature: a monitor program for the box and a PC tool to drive it.
Yes, certainly, like programming a mainboard BIOS, CD/DVD drive firmware, mobile phone, etc. If the power fails, your chip breaks while programming or most of all the programming software malfunctions, you'll have a dead box. And I take no responsibility of any kind, you do that at your own risk. However, I tried as carefully as possible to bulletproof this code. The new firmware file is completely read before it starts programming, there are a lot of sanity checks. If any fails, it will not program. Before releasing this, I have checked the flow with exactly these files supplied here, starting from the original firmware in flash. It worked reliably for me, there's no reason why such low level code should behave different on your box.
There's one ultimate safety net to bring back boxes with even completely garbled flash content: the UART boot mod, which in turn requires the serial mod. It can bring the dead back to life, with that it's possible to reflash completely from the outside, even if the flash is completely erased. I used that during development, else Rockbox in flash wouldn't have been possible. Most of the developing effort went into this tooling. So people skilled to do these mods don't need to worry. The others may feel unpleasant using the first tool for reflashing the firmware.
To comfort you a bit again: The flash tools are stable since a while. I use them a lot and quite careless meanwhile, even reflashed while playing. However, I don't generally recommend that. ;-)
About the safety of operation: Since we have dual boot, you're not giving up the Archos firmware. It's still there when you hold F1 during startup. So even if Rockbox from flash is not 100% stable for everyone, you can still use the box, reflash the second image with an updated Rockbox copy, etc.
The flash chip being used by Archos is specified for 100,000 cycles (in words: one hundred thousand), so you don't need to worry about that wearing out.
You need two things:
I'm using the new plugin feature to run the flasher code. There's not really a wrong path to take, however here's a suggested step by step procedure:
The second image is the working copy, the "rockbox_flash.rock" plugin from this package reprograms it. I suggest to place the plugin to where you keep the others, "/.rockbox/rocks/". The plugin needs to be consistant with the Rockbox plugin API version, otherwise it will detect mismatch and won't run.
It currently requires an exotic input, a UCL-compressed image, because that's my internal format. UCL is a nice open-source compression library I found and use. The decompression is very fast and less than a page of C-code. The efficiency is even better than Zip with maximum compression, cooks it down to about 58% of the original size. For details on UCL, see: http://www.oberhumer.com/opensource/ucl/
Linux users will have to download it from there and compile it, for Win32 and Cygwin I can do that, so the executables are in the package. The sample program from that download is called "uclpack". We'll use that to compress "rockbox.bin" which is the result of the compilation. If flashing becomes very popular, this could be a part of the build process.
Don't flash any "old" builds which don't have the latest coldstart ability I brought into cvs these days. They won't boot. These instructions refer to builds from cvs state 2003-07-10 on.
Here are the steps:
The latest ATA init fixes seemed to have solved early adopter's problems. However, the wait for the harddisk is longer, you're unlikely to reach the 3 seconds boot time. I hope it will improve one day again. If there should still be ATA errors on startup, use F1-On for the Archos image. Then you can either reprogram the original firmware from your backup, or live with F1-On until a better Rockbox build resolves it, or program the Archos software in the second image, too.
Loading the original Archos firmware via rolo may hang, if Rockbox is started from flash. This is some initialization problem which I hope to fix, rolo-ing Rockbox versions works OK. If you feel homesick, hold F1 during powerup.
The behavior with plugged charger differs from original: the box starts when you plug it in (no charging screen). You can't power it off while the charger is plugged in, instead it kindof restarts in an odd way, can give ATA init errors in this case. This is not harmful, sortof reminds to unplug before powering off.
Rockbox currently insists on starting the HD before doing anything useful. This can be a problem if the batteries are deeply discharged and too weak to power up the HD, preventing rockbox to start up and charge them. Current workaround is to hold F1 while plugging in, this gives the Archos charging screen. #include "foot.t"