Embedded Linux boot process 1.5-from bootrom to xloader

-- By fecen

Http://blog.csdn.net/ffee/archive/2008/10/17/3092973.aspx
Start to view the xloader_entry Code Previously, I would like to summarize the process from the power-on of the chip to the start of running xloader code. This is a process that I currently understand and may differ from each other. It will be improved later.
After the system is powered on, the PC register is first set to an address corresponding to the Code in bootrom. Bootrom is a small storage area integrated into the chip, which usually solidify a piece of startup code. As for the address space occupied by bootrom, the definition of each chip may be different. For details, refer to the memory map section in the chip user manual. In Memory plus, Bootrom is located in the 16 M address range from 0xff000000 to 0xffffffff . Of course, the bootrom size is not necessarily so big. This is just to say that you have used these places for you. The exact amount you have used depends on your own. It is enough. It is 32 kb in memory plus.
So bootrom has such a large address area that can be used. Which address will be redirected to when the system powers on to execute the code? This depends on the CPU definition. For arm926ejs used in connector plus, it is defined as follows: Following reset, the ARM core starts to fetch instructions either from 0x00000000 or 0xffff0000 depending on the signal level of vinithi * input signal to ARM core. if after reset vinithi signal level is low then ARM core will start fetching code from address 0x00000000 otherwise ARM core will start fetching code from 0xffff0000. so there must be some executable code accessible from either of this address. in an embedded system, this requires some nonvolatile memory usually Rom or flash to be present.
That is to say, the address of the First Command obtained after the ARM core is reset depends on the vinithi signal input to the ARM core. If the vinithi signal input to the ARM core is low, the ARM core obtains the first command from the address 0x00000000. If the input vinithi signal to the arm is high, then it obtains the first command to be executed from the 0xffffff0000 address.
In the memory Plus System (because the memory plus system contains two arm cores, the control of the system is completely on arm1 at the initial startup of the system. At this time, the arm2 core is unavailable. Therefore, the ARM Kernel we call is the arm1 core. After the system reset, The vinithi signal sent to the ARM kernel is a high level. Therefore, in our system, the system will go to the address after power-on 0xffff0000 Obtain the first command to be executed.
We found that, 0xffff0000 is located within the bootrom address range mentioned above. Therefore, the first code in bootrom must be at 0xffff0000. After the system is started, the first command to be executed will be obtained from 0xffff0000. Then, we will proceed according to the pre-defined process of bootrom. We cannot see the code at bootrom (we call it firmware, that is, the code is fixed in the chip when the chip leaves the factory), so we can only describe it according to the description in the document.
In bootrom of Kernel plus, three functions are provided (the functions provided by bootrom in other boards or chips should be similar ):
1. boot the system from nor serial flash
2. boot system from NAND Flash
3. boot or update the system from USB
Among the three features, we will not talk about 3rd of them for the moment, because this is the most important use at the beginning (except for bootrom, there is neither xloader nor U-boot ), it is used to burn xloader image or uboot image to the corresponding flash.
We are mainly concerned with 1st and 2nd features. In essence, there should be no difference between nand flash Boot and nor serial FLASH Boot. The main difference is that the two flash read/write methods are different (In addition, another important difference between them is that nor can be addressable in bytes, that is, it can run directly on nor. Program Instead of copying it to ram, but NAND is block-Addressing and cannot directly run programs on it. However, for memory plus, whether it is nor or nand, the method is to copy the corresponding code to ram first ), therefore, the loading process may be different when the Flash content is loaded to the corresponding address in the memory. For our system, we use nor flash. Therefore, we will focus on the analysis of the system boot from nor serial flash. For details about the differences between nor flash and NAND Flash, refer to the reference at the end of this article. Article .
When bootrom starts executing the program, if it is set to boot from nor (several signals can be provided to the platinum plus chip, the combination of these signals can specify the bootrom function, for details, refer to the chip manual). bootrom will first check whether uboot exists at the first sector of flash, that is, sector 0th, if it exists, you can directly jump to the uboot code for execution (because the program can be directly run on the NOR ). Therefore, we can directly jump from bootrom to uboot to execute code without xloader (the method is to directly write the uboot image to the sector of Flash 0th ). But we didn't do this. We placed another layer of xloader before uboot, which can improve the flexibility of the system.
Then, how does bootrom determine whether there is a uboot image in Flash 0th? In fact, the method is very simple. The uboot image consists of two parts:Source code The destination file (ELF File) generated by compilation. The other part is a 64-byte image header. In this image header, this image has the name attribute, magic number attribute, and load address attribute. We will analyze the attributes in detail in subsequent articles. This part of the image header is a combination of a tool program called mkimage and the target ELF file generated by the previous compilation link to generate a uboot image. The image header is located at the beginning 64 bytes of the uboot image, followed by the elf target file. Bootrom checks whether an image exists at a certain position by using one or more fields in the 64-byte image header. Bootrom will first read the content of the first 64 bytes for judging the sector in Flash 0th, then, determine whether the name attribute is an agreed value ("uboo" or "uboot" depends on the Implementation Convention). If it is determined that it is an agreed value, this indicates that uboot image exists on sector 0; otherwise, it is deemed that the image does not exist.
Obviously, there is no uboot in our implementation scheme, because we have placed a layer of xloader on it.
Therefore, when bootrom finds that uboot does not exist in Flash sector 0, it will use the same method to determine whether xloader image exists in it (similarly, xloader image will also have an image header, in fact, the structure of the image header of xloader image is exactly the same as that of the image header of uboot image). if it determines that xloader image exists, it loads the xloader image to the address of the specified SRAM (because the external memory SDRAM has not been initialized, so it is unavailable, do you still remember the ddr_init we analyzed in xloader? Yes, the SDRAM is initialized there, so the xloader is not ready yet, and the SDRAM is even less likely to be initialized. Because each user may use different SDRAM, the initialization of SDRAM cannot be executed in bootrom. Therefore, at this time, only 8 K of SRAM integrated into the chip is available, so the xloader code must be very short), then jump to the address to execute, and the control is handed over to xloader. Starting from here, we will start to execute the xloader code, that is, the code at the _ start label we initially analyzed. So how does bootrom know the address at which xloader image is loaded to the SRAM? How can I jump to this address after loading? The answer to the question is still the image header. As we said just now, there is an attribute called load address in the header attribute, which is the address agreed by bootrom and xloader. After bootrom reads the load address attribute in the xloader header, it loads the xloader elf part to this address and jumps to the address specified by the load address to execute the code. The load address is specified by xloader. It is embodied in the text_base parameter in the makefile of xloader. This parameter will overwrite xloader as the LD parameter when xloader uses ld for link. the code running start address specified in the LDR file, which is used to describe the xloader command execution start address (through the LD parameter-T xloader. LDS-ttext $ (text_base) to specify). In addition, this text_base will also be passed to the mkimage tool program, so that when xloader image is the most used, set the load address attribute in the image header correctly. In this way, the entire process will be perfect.
Of course, if bootrom does not find xloader image at flash sector 0, then it will try to boot from NAND Flash (provided that the function mode of bootrom is set to allow boot from NAND at the same time ). If it cannot be found, the system will enter an endless loop.
After the control of the program is successfully handed over to xloader, It is the code section that we are currently analyzing.
In the subsequent sections, we will proceed with the analysis step by step.
References:
Nor/Nand
Http://blog.sina.com.cn/s/blog_53d5935e010006fl.html

 

TIPS:

The CPU of the Marvell rd88f6282a board is alsoArm926ejs,

Bootrom is located in the address range of 1 m from 0xfff0 0000 to 0 xFFFF FFFF

After the reset, the CPU runs from 0 xFFFF 0000, Which is exactly within the bootrom space.

After verifying the header information, initialize the DDR according to the DDR Parameter

If it is not from the nor boot, copy the uboot to dram to run

 

ARM processor links:

http://www.arm.com/products/processors/index.php