From: <idc-dragon_at_gmx.de>
Date: Mon, 28 Jul 2003 14:19:15 +0200 (MEST)

Up to now there are 5 people affected and have been emailing me, so I'd like
to take my elaborations into the public.

Player/Recorder/FM have identical boot ROM code within the CPU, which is why
flashing in priciple works alike for all of them. This 64KB embedded ROM
contains only a small piece of code (about 2 KB) which can either boot from UART
(like I exploited for my first tries) or descramble an image from flash. For
Recorder and FM this is a ~8kB piece of code which contains a second level
bootloader and a monitor program we don't know much about, for players this is
the full software.
More details in an older posting of mine, especially the bottom part:
http://rockbox.haxx.se/mail/archive/rockbox-archive-2003-06/0287.shtml

My flash content replaces this by my own bootloader which does F1-check and
decompression of either image. My bootloader is the part hooked into the
structures which the boot ROM expects, it gets descrambled and executed. After
that, it's freestyle.

However, there is a variant of the boot ROM spotted on a few boxes (some
recorders with 1.28 firmware) which works different. My flash plugin fails for
good reason, the structures in the flash are different, it doesn't find the
expected layout. The boot ROM is completely different. I ran some simulations
on this. It already contains the loader with the monitor (unscrambled this
time), which the other models pull from flash. There is no UART boot any more,
my safety net won't work for these. But it would probably be possible to use
the built-in monitor for flashing if we find out how, so this would be the new
safety net here.

I'd prefer to have this safety net established first, before trying to flash
with an adapted plugin. The flash content is in parts similar to the other,
so I can guess how to hook in my bootloader and author a firmware for those,
but I woudn't try blindly. Otherwise you have very strong motivation to find
out how the monitor works, if everything but that is dead...

For these boxes, flash start will be slower because they can't avoid the
Archos loader. This has at least a 1 second timeout waiting for that "SRL"
command, dunno what else it does afterwards. Maybe this adds to still the same
startup time if it's within the HD spinup.

In summary, the affected people need a developer in their rows to go ahead
with this. I can aid you with what I have and what tools I was using, but my
motivation and time is too limited to do the reverse engineering again for
these boxes.

Jörg

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!

Received on 2003-07-28