Discuss about the boot flash update of dbau1200 Development Board

// ================================================ ========================================
// TITLE:
// Discuss the Boot Flash update of DBAU1200 Development Board
// AUTHOR:
// Norains
// DATE:
// Tuesday 15-0000l-2008
// Environment:
// RMI Development Board + YAMON
// ================================================ ========================================
After many people get the RMI DBAU1200 Development Board, it is estimated that the first step is to wait to update the boot flash. If you carefully read the RMI Alchemy Processors AutoBoot Boot Loader User's Guide, you may be confused about the different erased addresses of boot flash and parameter flash. The former erases BFD00000 in YAMON, while the latter erases BDC00000.

Before explaining this, let's take a look at the mips cpu. In a 32-bit mips cpu, the memory address of the program is divided into four areas. Traditionally, they are: kuseg, kseg0, kseg1, and kseg2.

The address space of these four regions is as follows:
Kseg2: 0xC0000000 ~ 0 xFFFFFFFF
Kseg1: 0xA0000000 ~ 0 xBFFFFFFF
Kseg0: 0x80000000 ~ 0x9FFFFFFF
Kuseg: 0x00000000 ~ 0x7FFFFFFF


Except that the kuseg can only be used in the core mode, the other three can be accessed in the user mode. The physical addresses of kseg0 and kseg1 are the same. The only difference is that kseg0 has a cache and kseg1 does not. Note that kseg0.

As mentioned above, kseg0 and kseg1 map the corresponding physical address, so how can we convert the program address to a physical address? For kseg0, only the highest bits need to be cleared, and these addresses are converted to physical addresses. For kseg1, the maximum three bits are cleared.

Kseg1 is the only address space that can work normally after the system is restarted, and 0xBFC00000 is the entry vector after the system is restarted! In other words, the first address executed after cpu reset is 0xBFC00000!

Now let's follow the instruction manual to see how to install Stand-Alone AutoBoot.

1. Boot flash already contains yamon bootloader. Switch the S11 switch to the not dot position and restart the Development Board to start it from boot flash.

2. Because nor flash can only write 0, FLASH: yamon> erase bdc00000 20000 is erased before writing data.

3. Move S11 to the dot position.

4. Save the REC file. Yamon> load db1__booter_standalone.rec

Steps 1st, 2, and 3 are okay. Step 3rd wondered why the erased address is 0xbdc00000? According to the document, the address 0xbdc00000 is calculated as follows: 0x1dffffff-0x3fffff = 0x1dc00000 = 0xbdc00000

0x1dffffff is the physical address of flash. We need to know that the physical addresses of boot flash and parameter flash can be switched through S11:

S11: Not dot
Boot rom (nor flash): 0x1E000000 ~ 0x1FFFFFFF
PARAMETER (nor flash): 0x1C000000 ~ 0x1DFFFFFF

S11: DOT
Boot rom (nor flash): 0x1C000000 ~ 0x1DFFFFFF
PARAMETER (nor flash): 0x1E000000 ~ 0x1FFFFFFF

So why do we need to subtract 0x3FFFFF from the TOP address of PARAMETER? How does 0x3FFFFF come from?

Leave 0x3FFFFF aside. Let's take a look at the erased address: 0xBDC00000. When s11 is not dot, what is this address when it is DOT?

We can calculate: 0x1FFFFFFF-0x3FFFFF = 0x1FC00000

0x1FC00000 is it very familiar? Yes, that is, 0xBFC00000 is the program address corresponding to kseg1, that is, the entry vector of CPU reset! In this way, it is clear why the address of the erased PARAMETER in not dot is 0xBDC00000, and the value subtracted is 0x3FFFFF!

Next, let's look at how to update YAMON-Invoked AutoBoot in the document.

The procedure is as follows:
1. YAMON> erase BFD00000 20000
2. YAMON> load db1__booter.rec
3. YAMON> go BFD00000
4. YAMON> set start "go BFD00000"

Why is the erased address 0xBFD00000 when we update YAMON, instead of 0xBDC00000 like parameter flash?

The answer is described in RMI Alchemy Au1200 Processor-Based System Windows CE 5.0 Build Guide: This address is 1 MB above the MIPS reset exception vector, 0xBFC00000, which allows the boot monitor (YAMON) and CLI to coexist, and significantly CES the opportunity of corrupting Flash and rendering the development board non-bootable.

Obviously, it is mainly for the two to coexist with yamon. When operating according to the document, there should be two yamon in Boot flash, and the addresses they store are 0xbdc00000 and 0xbfd00000 respectively. After the CPU reset, it will jump to 0xbdc00000 to execute the first yamon, and then the first yamon will jump to 0xbfd00000 to execute the second yamon. This completes the purpose of updating yamon and reduces the possibility of non-bootable.

Not only can yamon be saved to 0xbfd00000, but other bootloaders such as eboot can also be illustrated in the same way. This is a convenient means for peers without simulators.