u-boot transplantation on at91rm9200

Porting u-boot on at91rm9200

================== Preparation ================
1. Read the chapter about "boot program" in at91rm9200 official document
to have a general understanding of the boot process of at91rm9200.
at91rm9200 boot flow chart
Device Setup
|
|
Boot SPI DataFlash Boot --> Download from DataFlash --> run
|
|
TWI EEPROM Boot --> Download from EEPROM --> run
|
|
Parallel Boot --> Download from 8-bit Device -->run
|
| Xmodem protocol
| |---DBGU Serial Download ---------------------> run
|____|
| DFU protocol
|-----USB download -----------------------> run

at91rm9200 has two boot modes: on-chip boot and off-chip boot, which are controlled by a jumper.

1> Off-chip booting Execute the boot program burned in the flash.
2> On-chip booting The at91rm9200 has a 128k on-chip ROM, which has a bootloader and uploader. When booting on the chip, the uploader is started, and the uploader turns on the xmodem protocol and waits for the user to upload the program. The uploaded program will be loaded into the on-chip SRAM, remapped, and then the PC jumps to the on-chip SRAM to execute the uploaded user program.

Note: The on-chip SRAM is only 16k, excluding the 3-4k on-chip boot program that occupies some data space, so the size of the downloaded program is limited to 12k.

2. Development board hardware configuration
This development board hardware ATMEL recommends hardware
SDRAM 8MB 32MB
Flash 1MB 8MB      
Note: The Flash chip is also different, which means the driver needs to be rewritten.

3. Transplantation ideas
The official at91rm9200DK u-boot Flash Programming Solutions document provides the following solutions.

There is no boot program on the development board flash, so you can only use the on-chip boot method to load a small program within 12k to the internal SRAM to run. After this small program initializes SDRAM, it downloads u-boot to SDRAM to run (u-boot is greater than 12k), and the pc jumps to the u-boot position of SDRAM to run u-boot.
After u-boot starts, use u-boot's own flash burning command to burn itself to flash, and then you can start from the off-chip flash.

The official document does not burn u-boot.bin directly, but burns two files, boot.bin and u-boot.gz.
The reason will be explained later.

=====================Transplantation=====================
1. Transplantation of loader.bin
The official loader.bin will start xmodem to receive u-boot when SRAM is started, but xmodem receives data incorrectly.

After checking its source code, I found that it used the service interface function in the fixed ROM, and I didn't see where the problem was.

So I prepared to write loader.bin by myself. In the development package provided by at91rm9200, there is a AT91RM9200-GettingStarted-ADS1_2-1_1.zip, which uses the Arm Developer Suite 1.2 compiler. It is a simple hello world program, which can be run after a try.

(Note: For ADS compiled programs, variables must be defined at the beginning of main. Defining them later will cause compilation errors.)

Use AT91RM9200-GettingStarted-ADS1_2-1_1.zip as the starting point to write loader.bin.
Lader.bin has three main functions: initializing SDRAM, starting xmodem to receive u-boot and write it to SDRAM, and pc jumping to SDRAM to run.

AT91RM9200-GettingStarted-ADS1_2-1_1 already has SDRAM and other initializations in init_ram.c.

The implementation of xmodem
only needs the receiving part, and the sending part can be done with tools such as "HyperTerminal" under Windows.
First find the protocol document, familiarize yourself with the protocol, and look at the existing xmodem protocol source code. The protocol itself is not complicated, but its handshake part is a bit tricky to implement.

The receiving end needs to continuously send the character "C" to the serial port (note that xmodem has 3 versions, and the hyperterminal corresponds to xmodem-crc16). After receiving "C", the sending end sends the data SOH and the first data packet.

After the receiver detects SOH, it stops sending "C" and starts processing data. The official loader starts a time service, sending a "C" every 1s. I used a lazy algorithm here.

    while(Getchar()!=AT91C_XMODEM_SOH)
    {
        if (0xFFFF==++n )
        {
            SendChar(AT91C_XMODEM_CRCCHR);
            n=0;
        }
    }

Getchar() and GetWaitchar() are added. GetWaitchar waits until data is received from the serial port.
Obviously, it cannot be used in the above algorithm, which will cause busy waiting. So I changed Getchar() to be used only here.
The handshake is solved, and there is no problem with the subsequent processing.     03/10/01 HI     :     Creation     ; ----------------------------------------------------------------------------------------------

AREA                reset , CODE , READONLY     EXPORT Jump Jump mov pc ,                 r0 END                ​                ​​        ​                 ;--------------------------------------------------------------------------------- In main, use the following function to jump Jump((unsigned int)AT91C_UBOOT_BASE_ADDRESS); In the debugging process of the loader , the xmodem part can transfer a debugging file. After transferring it, send all of it back to the serial port. You can judge whether it works normally by looking at the returned information.

When writing to SDRAM, you still need to write and then read to see if they are consistent. I was stuck here for a long time and found that every 2 addresses could not be used. Later, I found that the SDRAM was not initialized, that is, InitSDRAM() in init_ram.c was invalid. It was normal after rewriting.

Jump test requires a executable program to be passed into the memory to judge. I used the previously compiled 1.1.4 u-boot to pass it in, but there was no response. It may be that the jump is wrong or the u-boot is wrong. After all, u-boot has not been modified. A flash of inspiration came to me, and I changed to u-boot-1.0.0 to try it. The u-boot prompt appeared, which means that the jump is OK.

2. u-boot transplantation
The compilation of u-boot requires ELDK (Embedded Linux Development Kit)
ELDK is a cross-development environment under linux, so you need to install linux. Here, the virtual machine vmware is used to install linux (red hat 9.0), and vmware tools are installed to facilitate data exchange with windows.

For Linux version selection and installation of ELDK, please refer to "The DENX U-Boot and Linux Guide (DULG) for TQM8xxL".

Here, arm-2005-03-06.iso is downloaded and installed.
Note that the environment variables of ELDK are set correctly, otherwise compilation will fail.

Read the README document carefully before compiling u-boot .
at91rm9200 is already supported by u-boot.
Compile as follows
#cd u-boot.xxx (xxx represents the version number)
#make at91rm9200dk_config
#make all.
It will be very slow in the map. It takes 3 minutes to compile u-boot in the virtual machine on my AMD64 3000+.

Starting
from 1.1.2, u-boot has the code to initialize SDRAM and copy itself to SDRAM for running, while previous versions do not have this function. The solution provided by the official document is for versions before 1.1.2. In fact, the u-boot in the official development package is 0.3.1.

After my test, I found that the directly compiled u-boot1.0.0 can run, but 1.1.4 has no response.
It seems that the latest is not necessarily the best. So I chose u-boot1.0.0 to transplant.

u-boot modification
    u-boot is also written for ATMEL recommended gametes, so it needs to be modified.
Modify
Board/at91rm9200dk/config.mk
TEXT_BASE = 0x21f00000
to
TEXT_BASE = 0x20700000 (u-boot will be loaded into the high end of SDRAM)

Modify
include/configs/at91rm9200dk.h
#define PHYS_SDRAM_SIZE 0x2000000 /* 32 megs */
to
#define PHYS_SDRAM_SIZE 0x800000 /* 8 MB */

#define PHYS_FLASH_SIZE 0x200000 /* 2 megs main flash */
to
#define PHYS_FLASH_SIZE 0x100000 /* 1MB main flash */

Another place to modify is Board/at91rm9200dk/flash.c.
Refer to your own flash chip datasheet and modify the driver.
Pay attention to maintaining the consistency of the function interface. Among them, several functions that will be called externally are
unsigned long flash_init (void)
void flash_print_info (flash_info_t *info)
int flash_erase (flash_info_t *info, int s_first, int s_last)
int write_buff (flash_info_t *info, uchar *source, ulong Base, ulong nbytes)

As long as the interface consistency of these functions is guaranteed, their implementation methods do not necessarily have to refer to the original mode.
flash_info_t *info is actually not needed.
In addition, it is better to remove the automatic identification function of the flash chip. It is very likely that other FLASH of the same type will be used instead during the production process.

Recompile u-boot, and then test the flash driver with u-boot's flinfo, md and cp.b commands.

After everything is normal, the u-boot part is completed.
The u-boot package is
#gzip –c u-boot.bin > u-boot.gz

3. Transplantation of boot.bin
First look at the source code of boot.bin. It also uses the ELDK development environment. I used the cross development environment installed previously to compile and an error occurred. . . It prompted an ld command error. It may be incompatible with the development environment. Replace it with cross-2.95.3.zip in the official package and the compilation passed.

Modify the following two items in main.c
#define SRC 0x10010000 (the location where u-boot.gz will be burned into flash)
#define DST 0x20700000 (the location where u-boot.gz is loaded into SDRAM after being decompressed, and keep it the same as in the loader)

Similarly, modify AT91F_InitSDRAM() in initboot.c, and the modification is the same as the loader.

Compile
#make all

and burn it into the flash test
    chip to start, load loader.bin
    , and then use loader.bin to load u-boot to run.
    
The following is the operation under the u-boot prompt
u-boot > loadb 20000000
--------------Use the kermit protocol to load the boot.bin file to the 20000000 address of SDRAM-----
u-boot > cp.b 20000000 10000000 xxx 
 (After the file is loaded in the previous step, the number of downloaded bytes will be displayed, and xxx is the hexadecimal representation of the number of bytes)
Next, burn u-boot.gz
u-boot > loadb 20000000
u-boot > cp.b 20000000 10010000 xxx

Disconnect the jumper on the board and start the development board off-chip. After a few seconds, u-boot starts.
This is the end of u-boot transplantation.