From: <idc-dragon_at_gmx.de>
Date: Fri, 23 May 2003 01:10:50 +0200 (MEST)

Hello Flashboxers,

thanks to all of the many contributors. Like you may have seen from the
posts, the vast majority (90%)of the people would be able to flash the boxes. I
collected 41 answers, only 4 of them don't get a value. 2 of them are player,
the other 2 recorders. All participating FMs (8) were successful. I have
only a few player votes, because I did the player code a couple of days later.
Overall, the only seen ID was BF D6, means Archos seems to use no other parts
than SST.

One of the 4 unlucky guys is me. Does anybody have access to a SST39VF020 in
the TSOP package (actually, SST39VF040 for twice the size preferred, so I
can switch), or a broken box that could be scrapped for parts?

Meanwhile, I'm analyzing the boot ROM which is part of the CPU. This can't
get erazed and may be a viable way to revive a mis-flashed box, something I'm
really worried about before releasing this to the public. It is easy to write
flash routines within Rockbox, but any whoopsie may lock you out
permanently.

Archos seems to have a UART boot code in the ROM, such that they can program
or test the CPU boards in manufacturing. The boot loader goes to this mode
when all 3 of the LCD lines are pulled low. A bit impractical, I agree. They
probably have the CPU board out and then it's all on one connector.
The UART input is the remote pin, the output is normally not connected,
unless you did the gdb mod. Strictly speaking the output is optional to the boot
procedure, not really required. It just adds safety to the built-in boot
because all bytes are acknowledged. The initial baudrate is nearly 2400 baud. The
boot procedure is roughly and preliminary as follows:

- Bring the 3 lines down and power the box up
- The boot code expects to receive a single byte which gets written directly
into the baud rate register. This gives the option to work with higher speed
thereafter.
- After this, all received bytes get echoed and are expected to be
acknowledged with a nonzero byte. If the echo byte is not what the host has send, he
can request to redo the byte with a zero answer.
- The next 4 bytes are a 32 bit value, the length of the boot "payload".
- The next 4 bytes are a 32 bit value, the start address of the payload,
where to store it (only IRAM possible by then, I reckon).
- Payload (as many bytes as specified with the length)
- Execution command byte 0xFF if this image should be started
- The first 32 bit word of the payload has to contain the execution address.
The boot code will read that word and jump the contained address.

If this piece of ROM code actually works (so far I've only roughly simulated
it, and there's two lines in it which I don't like, hope they have no bug in
it), we can inject a small piece of code, like the next level boot loader.
It could use the remote pin bidirectionally and contain a safe protocol to
transfer a flash image. A first test would be to transfer an LED blinking
program or such.

The main challenge for the non-hardware people would be how to pull the LCD
low. Writing a multi-stage boot and flash code is a challenge, far more than
flashing from Rockbox. But I want to have a fail-safe way. So I don't dare to
release a flashing option within rockbox.

The next big question is: what should we actually flash? Next I'll be
looking at how the boot ROM starts the flash. It seems like another encounter with
a descrambling code. I do know that the Firmware gets copied to RAM and runs
there, probably for speed reasons. If we know how a Flash image is
constructed, we can do our own.

The final challenge for Rockbox is to be compiled for a flash image. We
probably need some more initialization code, a different runtime address, and on
a sidenote now _we_ need to look for a .ajz firmware file on the disk and
start that, like the Archos firmware did.

So far with the news from the flash front,
Jörg

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

Received on 2003-05-23