ARM startup code (1): Introduction

Many friends who are engaged in embedded systems have no problem writing code, but when they debug on the board at the end, they hang up. The reason is that there are problems with the chip's startup address, startup mode, and the connection between the bootloader and the operating system. Let's talk about this issue today.

What do we care about most for a new processor? It is not whether it supports the C compiler or whether there is a good development environment. From the perspective of a programmer, to fully understand a new processor, you must understand two things: a) the memory model of the new processor; b) the interrupt mode and interrupt source of the new processor, etc. Take ARM's AT91SAM9260 as an example.

An ARM chip may have N different startup methods, supporting startup from SPI flash, Norfalsh, nandflash, on-chip ROM, etc. Some operating systems, such as vxworks and ecos, also support these various startup methods. If you don't understand the memory model, you will think that these methods are completely different. But from the perspective of experienced embedded software engineers, these methods are actually extensions of one method. After all ARMs are powered on, they enter SVC mode, disable interrupts, and use ARM instructions to execute code from 0x0.

Let's examine a question. What bus do SP flash and Nandflash use? SPI and 8Bit or 16bit, can we access the contents of spi flash and nandflash by simple assignment and address in the code? No, to read spi flash/nandflash and write spi flash/nandflash, we must first write the command, then prepare the buffer and refresh the data. All of these cannot be completed by simply using an LDR or STR instruction to access the storage unit. Professionally speaking, SPI flash/nandflash is not uniformly addressed with the system. After power-on, ARM executes from 0x0, and it is impossible to obtain the data at 0x0 in a complicated way, but only through simple bus actions. In other words, it is a fantasy to want to directly use spiflash/nandflash to start ARM... Why can some ARM use spiflash/nandflash to start the system? AT91SAM9260 is such a chip.


Let's take a look at the chip storage structure of AT91SAM9260: 0x0~0x0FFF FFFF is internal memories, that is, the memory inside the chip. 0x0~ 0x0F FFFF is boot memory, 0x10 0000 to 0x10 7FFF is ROM. 0x20 0000~0x20 0FFF is SRAM0, 0x30 0000 ~ 0x30 0FFF is SRAM1. What is boot memory? Boot memory is an idle address. SRAM0 and ROM can be mapped to this address, that is, use the control register to select ROM and SRAM0 to map to the boot memory location. If you access the address of the boot memory, you are accessing the ROM or SRAM0 address content mapped to that location. For example, if the boot memory maps SRAM0, accessing the location of 0x10 is equivalent to the location of 0x20 0010. Once the chip is powered on, the default mapping is ROM. What is ROM? It turns out that it is a boot code defined by ATMEL for 9260, which is fixed in the factory. It will look for Dataflash (a flash of ATMEL) and load the bootloader from the flash, or look for nandflash or norflash and load the bootloader.

ARM starts to execute from memory 0x0 when it is powered on, and 9260 maps rom to the location of boot memory, that is, the code in rom is executed. Load the bootloader from the peripheral. This process is smooth. Boot memory is often seen in arm7 to solve the problem of ARM startup and exception vector. It is a perfect solution.

At this point, we understand that in fact, ARM bare metal cannot load applications from nandflash/spi flash/uart/network, etc., and we must tell ARM the method. In other words, we must write a program to tell ARM from which port and what method can load the correct code into the memory. After understanding this, we need to figure out the address, that is, what to load to what location. In fact, this problem is not complicated. The key is to distinguish some concepts clearly.

1. Our code is loaded into the chip's uniformly addressed location, and this address is visible throughout the chip.

2. 
   

3. Our code is stored on non-uniformly programmed devices such as spi flash/nand flash. Where does the address of the code on these devices start? In fact, this address is no longer a uniformly programmed address for ARM. The programmer only needs to understand it, write the driver, and load it from the specified location. If the manufacturer has already written the driver, this address is fixed. For programmers, writing code to nand flash/spi flash is no longer arbitrary because the starting address in the driver cannot be changed.

4. 
   

5. The format of the loaded code. If it is in raw binary format, refer to 1). But if it is an elf file, it will be a little more complicated: the elf file contains where each piece of data is loaded into the chip, but no matter what, the idea is the same, loading the appropriate code into the specific location of the chip.

The locations of these addresses are also different. The Bootloader can configure the location where the target is loaded, the location where the target code is obtained, and the method for obtaining the target code; the link script of the tool chain can modify the location of each segment (data segment, code segment). The hardware chip select signal also determines the location of the device's unified addressing. Therefore, when designing ARM startup code, you cannot look at the chip data in isolation, but need to consider it from a unified and global perspective.