Rockbox

My Archos Recorder V2 uses the v3 bootloader for Recorder V2 with ROM. (When I dump flash, internal_rom_2000000-203FFFF.bin matches firmware_v2.bin in http://download.rockbox.org/bootloader/archos/flash-recorderv2-v3.zip up to 0×7000, except for one byte at 0xFC. The stuff after 0×7000 is the main Rockbox image flashed via rockbox_flash, and the one byte is a “hardware mask value” which is kept by firmware_flash.c. This means my bootloader and BootBox are both the same as in that file.)

I wonder what code was used to compile the bootloader. I see svn tags for various bootloaders, but no tag that might be the v3 Archos bootloader. The second image seems to be r18960. I don’t see a revision string in the decompressed BootBox image. The BootBox code I examined seems to match r18960.

The rescue boot function (hold F1, press on, loading /ajbrec.ajz) works perfectly as long as external power is not connected.

If F1 is held down while plugging in the a charger, The result is “ATA error: -11”. When I release F1, I get:
*PANIC*
storage: -11
and the red LED blinks. This behaviour is due to the charging_screen() being skipped and storage_init() failing in bootbox/main.c.

I suspect the charging screen exits because charger_inserted() is used, and it depends on probing from power_thread(). In r20634, apps/main.c was changed to use (power_input_status() & POWER_INPUT_MAIN_CHARGER), and I think this change also needs to be made in BootBox. The use of charger_inserted() in charging_screen() should not be dangerous because the button_get_w_tmo(HZ/2) should allow power_thread() to run and properly set power_thread_inputs. Note that r17955 fixes the usb_detect() line in BootBox. That fix would have to be backported if compiling the bootloader from some earlier versions. I expect the same issue exists on all BootBox targets with charging which are compiled from the same code. (Only Ondios don’t have charging.)

In flash/bootloader/bootloader.c, targets with hard drives turn off IDE power if the charger is inserted. For example, here is PLATFORM_FM:
if (ReadADC(0) < 0x1FF) /* charger plugged? */
{ /* switch off the HD, else a flat battery may not start */
Before r25593, ide_powered() always returned true, so ata_init() did not execute ide_power_enable(true). This problem should exist on V2 and FM Recorders, and Players which are able to control HD power. The V1 Recorder defines HAVE_ATA_POWER_OFF. On it, ata_init() should succeed, and the rescue boot should continue normally. Ondios should be unaffected.

On the V2 and FM Recorders and the player, charging is hardware controlled, so it should continue while the error is displayed. The V1 Recorder has Rockbox controlled charging, but it shouldn’t panic. The only problem is that turning on the disk when battery level is very low. This is not a big problem, because susceptible targets have removable AA batteries.

If F1 is held down while plugging in USB, the disk spins up, and I see
Rockbox
Rescue boot
This hangs until I remove the USB cable. At that point, the rescue boot continues, and it is successful.

This behaviour is consistent with staying in the while (usb_detect() == USB_INSERTED) loop in BootBox main(), but not getting button_get_w_tmo(HZ/10) == SYS_USB_CONNECTED. The loop condition seems fine because usb_detect() reads directly from the hardware. The problem seems to be that F1, which has to be pressed for running BootBox, is also the key Rockbox normally uses to ignore USB connection. So, usb_tick() posts to usb_queue. When usb_thread() gets that, it finds (button_status() & ~USBPOWER_BTN_IGNORE) == USBPOWER_BUTTON) and it doesn’t do the queue_broadcast(SYS_USB_CONNECTED, 0) that main() is expecting. This problem should only exist on the FM and V2 Recorders, because they HAVE_USB_POWER and assign F1 to both functions. If BootBox was built with r29889 or later, the problem would also appear on the Ondios, because only USBPOWER_BTN_IGNORE is used in the check.

It is possible to get into BootBox USB mode. When you insert the USB cable, you have to hold F1 down long enough for the bootloader to see it, but you must release it before usb_thread() in BootBox sees it. It’s not too difficult, but I recommend always ensuring that you have either a known-good boot file on disk or a known-good second image in flash. This means change one at a time, and test it before changing the other.

I am intentionally leaving severity and priority at the default values, because these errors shouldn’t matter during normal use, and recovery is possible even with these bugs.

A short explanation of contents of the bootloader flash image:

The first part is the bootloader itself. The main code is located in flash/bootloader/. It just does a bit of hardware initialization, lets you choose to run the first or second image decompresses the image if necessary, and then jumps to it. It also contains MiniMon, for recovery over a serial connection. There is no need to change this part of the flash.

The second part is BootBox. It is an extremely stripped-down version of Rockbox used for recovery in case of problems. It offers a charging screen, USB mode, and ability to load a boot file such as /ajbrec.ajz. The problems I described are in BootBox.

The third part is the second image, which is loaded by default. It can be a compressed Rockbox image or RomBox. During a normal Rockbox install via rockbox_flash, only the second image is changed. The bootloader and BootBox remain unaltered, enabling recovery if something goes wrong.

Update:

The bootloader in the v3 flash images corresponds to 66f496c (r18970 from trunk). I was able to build identical FM and player bootloaders using recent version c5f772c.

BootBox and the full version of Rockbox in the flash images might be from the v3.0 branch, because errors prevent a successful build of r18960 from the trunk. I’m not able to confirm the exact versions.

BootBox can be built by choosing (B)ootloader when running configure. The resulting binary has gotten bigger. Here are sizes:
v3.0.1-final: bin=36488 ucl=25260
c5f772c: bin=39964 ucl=27812
The c5f772c BootBox plus the bootloader cannot fit in the area before 0×7000.

The build already uses -ffunction-sections and -fdata-sections via EXTRA_DEFINES in Makefile, from configure, and -Wl,–gc-sections via BOOTBOXLDOPTS from tools/root.make. It may be possible to save a bit more space via -flto ( FS#12431 ), but I expect some code would have to be removed manually.

A BootBox build also wouldn’t work now because RoLo uses core alloc, and there’s no call to core_allocator_init(). Excluding buflib would save space. There may be other bugs. I guess BootBox has not been tested in a long time.