Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: more boot research, and a hidden flash loader for gdb users
From: idc-dragon_at_gmx.de
Date: 2003-06-11


Hello,

(this is a long posting, reward for reading is a flash monitor, maybe the 3
swedes would like to make a research note from this?)

I've been analyzing how the JBR boots, starting from the boot ROM. For my
first findings, see:
http://rockbox.haxx.se/mail/archive/rockbox-archive-2003-05/0813.shtml

- The boot source is decided by reading port B bits 1-3 (later used to drive
the LCD). If all are pulled low, we will boot from UART as described in my
old posting. Any code can be injected, this what I would like to flash the box
from scratch.

- If not all are low, this 3-bit number decides which flash image to use.
Yes, there can be multiple, but for the firmware's I've seen they all point to
the same image. The first 4 bytes have to be "ARCH", otherwise it will just
blink the red LED for a while and then hibernate. Following that are image
destination and source pointers. Below is an explained dump of my recorder, your
mileage may vary:

0x02000000 0x41524348 the "ARCH" magic
0x02000004 0x09000000 destination of the image (DRAM)
0x02000008 0x02000100 source of image #1 in flash
0x0200000C 0x00002224 size of the image
0x02000010 0x02000100 source of image #2 in flash
0x02000014 0x00002224 size of the image
0x02000018 0x02000100 source of image #3 in flash
0x0200001C 0x00002224 size of the image
0x02000020 0x02000100 source of image #4 in flash
0x02000024 0x00002224 size of the image
0x02000028 0x02000100 source of image #5 in flash
0x0200002C 0x00002224 size of the image

- Next in the flash is a "patchlist", which is used to init the DRAM
controller. But it could be used for any other purpose as well. I would like to use
such a list entry to power up the harddisk as soon as possible during boot.
It seems that Archos didn't dare to code the DRAM init into the boot ROM,
wanted to be flexible for other RAM types. Quite I nice concept, they came up
with: It is a list of 8/16/32 bit values which will be ANDed/ORed/copied to a
given address, comes in triples of 32 bit values. The first is the "command"
and size info, second is the address, third is the value (left aligned if less
than 32 bit). The first hex digit of the command decides what to do (6=copy,
8=AND, 1=OR), the last digit gives the size of the operation (1=8bit,
2=16bit, 4=32bit). A zero command terminates the list. Below is my list, hope I made
no typos:

0x02000030 0x80000002 16 bit AND
0x02000034 0x05FFFFCA PACR register
0x02000038 0xFFFB0000 PA1 config

0x0200003C 0x10000002 16bit OR
0x02000040 0x05FFFFCA PACR register
0x02000044 0x00080000 PA1 config: /RAS

0x02000048 0x60000002 16bit copy
0x0200004C 0x05FFFFEE CASCR register
0x02000050 0xAFFF0000 CS1, CS3 config: /CASH. /CASL

0x02000054 0x10000002 16bit OR
0x02000058 0x05FFFFA0 BCR register
0x0200005C 0x80000000 DRAM enable, default bus

0x02000060 0x80000002 16 bit AND
0x02000064 0x05FFFFA2 WCR1 register
0x02000068 0xFDFD0000 1-cycle CAS

0x0200006C 0x60000002 16bit copy
0x02000070 0x05FFFFA8 DCR register
0x02000074 0x0E000000 CAS 35%, multiplexed, 10 bit row addr.

0x02000078 0x60000002 16bit copy
0x0200007C 0x05FFFFAC RCR register
0x02000080 0x5AB00000 refresh, 4 cycle waitstate

0x02000084 0x60000002 16bit copy
0x02000088 0x05FFFFB2 RTCOR register
0x0200008C 0x96050000 refresh constant

0x02000090 0x60000002 16bit copy
0x02000094 0x05FFFFAE RTCSR register
0x02000098 0xA5180000 phi/32

0x0200009C 0x00000000 end of list

- The last two 16 bit values before the image are the "mask" value at
address 0x020000FC and version at 0x020000FE, as already known. What's the mask
value used for?

- The relatively small image (8.5 kB) gets descrambled by the boot ROM,
using the known algorithm. The first 32 bit value of the image is treated as the
execution address, like with the UART boot payload.

This image is not the firmware yet. Instead, it seems to be mainly a flash
monitor. People who have done the gdb mod (having the bidirectional RS232) use
it) can use it. Set a terminal program to 115200 baud. When powered on, the
JBR displays this kind of greetmessage on the terminal, probably giving some
info about the image to be started next:

#SERIAL#scan soft = 00000000
soft=00000001
fin
file_chk = 00007367
calc_chk = 00007367
SoftAddress = 09046400
SoftSize = 0001BCF4

Notice there's about one second delay between displaying the "#SERIAL#"
string and the rest of the message. During this time, the monitor waits for a
command and then times out. The magic command is "SRL" including a carriage
return. Prepare this in the clipboard and fire it after the "#SERIAL#". With a
bit of practice it's very easy. If you managed, the root menu of the monitor
comes up like this, giving some options:

#SERIAL#SRL
************************
* LOADER *
************************

HLIDE version

Nov 30 2001
09:23:36
Ver : 1.16 JBR

UP (cr) : upload or program Flash
UP1 (cr) : upload or program Flash to space #1
UP2 (cr) : upload or program Flash to space #2
EXIT (cr) : exit serial connexion
MENU : display options
HRST : hard reset
SRST : soft reset
SPRO : start program in buffer
SOFT1 : set space #1 as firmware to load
SOFT2 : set space #2 as firmware to load
DUMP : rump memory

ROOT>

Interesting, eh? Hehe, there are even some typos in this. I haven't played
much with it, and I highly suggest caution in order not to lockup the box by
some wild flashing. "Luckily" I don't have an in-circuit flashable chip. The
upload seems to be in some checksummed format, as far as I've seen. The upload
quickly times out if no data follows. The dump command allows reading in the
flash and DRAM range.

So far with the latest,
Joerg

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



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa