|
Rockbox mail archiveSubject: more boot research, and a hidden flash loader for gdb usersmore boot research, and a hidden flash loader for gdb users
From: <idc-dragon_at_gmx.de>
Date: Wed, 11 Jun 2003 07:51:17 +0200 (MEST) 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!Received on 2003-06-11 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |