(go) embedded Linux boot process-----from bootrom to Xloader

--by Fecen

Before I start looking at Xloader_entry's code, I want to summarize the process of running the code from the chip to the start of the Xloader, which is a process I understand at the moment, which may be out of the way and be perfected later on.
When the system is power up, the PC register is first set to an address corresponding to the code inside the bootrom. The bootrom is a small piece of storage that is integrated inside the chip, which generally cures a startup code. As for the address space occupied by bootrom, the definition of each chip may vary, depending on the description of the memory Map section of the chip's user manual. In Spearplus, Bootrom is located in a 16M-sized address range from 0xff000000 to 0xFFFFFFFF. Of course, the size of the bootrom is not necessarily so big, it just says, these places for you to use, specific how much you use with your own, enough on the line. Inside the Spearplus is 32k.
So Bootrom has such a large area of the address can be used, the specific system when the power will jump to which address to execute code it? This depends on the definition of the CPU. For the Arm926ejs used in Spearplus, it is defined as: Following reset, the ARM core starts to fetch instructions either from 0x00000000 or 0 xFFFF0000 depending on the signal level of vinithi* input signal to ARM core. If after reset Vinithi signal level was low then ARM core would start fetching code from address 0x00000000 otherwise ARM Co Re would start fetching code from 0xffff0000. So there must is some executable code accessible from either of this address. In a embedded system, this requires some nonvolatile memory usually ROM or Flash to be present.
That is, the address of the first instruction that the arm core obtains after reset depends on a signal vinithi to the arm's core input, if the vinithi signal to arm is low at design time, Then the ARM core will retrieve the first instruction to be executed from the address of 0x00000000, whereas if the vinithi signal to arm is high, it will get the first instruction to be executed from the 0xffff0000 address.
In the Spearplus system (since the Spearplus system contains two arm cores, and the control of the system is completely on the ARM1 when the system is initially started, the ARM2 core is not available at this time, so at the back, we refer to the arm core as the ARM1 core), after the system reset , the vinithi signal to the arm core is a high level, so in our system, the system will go to the address 0xffff0000 to get the first instruction that it will execute after power-up.
We found that the 0xffff0000 is exactly within the address range of the bootrom mentioned above, so the first code in our bootrom must be located at 0xffff0000. This will take the first instruction that needs to be executed from 0xffff0000 after the system has been booted. After that, we will follow the pre-defined process of bootrom and go down. Because the code in the Bootrom (which we call firmware, which is solidified in the chip when the chip is shipped out), we cannot see it, so we can only describe it according to the description in the document.

In Spearplus's bootrom, there are three main functions (other boards or bootrom provided in the chip should also be similar):
1, from nor serial flash boot system
2. Booting the system from NAND flash
3. Booting or updating the system from USB
Of these three functions, the 3rd function we will not say, because this is the most important to use in the initial time (except Bootrom, there is no xloader and no u-boot case), used to xloader image or Uboot The image is burned to the corresponding flash.
Our main concern here is the 1th and 2nd functions. In essence, booting from NAND flash and booting from nor serial flash should be no different, the main thing is that the two types of flash read and write differently (in addition, there is a very important difference between them is that nor can be addressed by Byte, That is, it is possible to run the program directly on nor, without copying it into RAM, but the NAND is addressed by blocks and cannot be run directly on the program. But for Spearplus, either nor or NAND, it does this by copying the corresponding code into RAM first, so the loading process may be different when loading the content in Flash into the corresponding address in memory. And for our system, the use of NOR flash, so here is the focus of analysis from nor serial flash boot system situation. Specific nor flash and NAND flash differences can be referred to the article at the end of the reference.
Bootrom at the beginning of the execution of the program, if it is set to boot from nor (can provide several signals to the Spearplus chip, the combination of these signals can be specified bootrom function, specific reference chip manual), Then Bootrom will first in the flash of the first sector is also the No. 0 sector to check if there is a uboot exist, if there is a direct jump to Uboot code to execute (because on nor on the program can be directly run). Thus, we can not even need to xloader, and directly from the bootrom jump to Uboot Execution code (method is to write the uboot image directly to Flash No. 0 sector). But we did not, and we placed a layer of xloader before the uboot, which would improve the flexibility of the system.
Say here, then bootrom is how to judge in the flash in the No. 0 number sector there is no uboot image? In fact, the method is very simple, the whole uboot image has two parts, one part is the Uboot source code generated by the target file (elf file), the other part is a 64-byte image header, in this image header, There is the Name property of this image, the magic Number property, the load Address property, and so on, which we will analyze in detail in subsequent articles. This part of the image header is a combination of the target elf files produced by a tool program called Mkimage with the previously compiled link, resulting in the uboot image. The image header is located at the beginning of the uboot image at 64 bytes, followed by the elf target file. The bootrom is to determine whether an image exists in a location by one or several fields in the 64-byte image header. For the judge in Flash NO. 0 Sector,bootrom will read the first 64 bytes of the content, and then determine whether the Name property is the agreed value ("Uboo" or "UBOOT" depends on the implementation of the Convention), if the judgment is indeed the agreed value, That means that there is a uboot image on sector 0, otherwise it is not considered to exist.
Obviously, in our implementation, there is no uboot, because we have placed a layer of xloader on it.
Therefore, when Bootrom discovers that there is no uboot in Flash sector 0, it will use the same method to determine if there is a xloader image (also, the xloader image will have an image header, in fact, The structure of the image header of Xloader image is exactly the same as the structure of the image header of Uboot image, and if it determines the existence of xloader image, it will Xloader The image is loaded into the address of the specified SRAM (because the external memory SDRAM is not initialized at this time, so it is not available, remember the ddr_init we analyzed earlier in Xloader? Yes, the SDRAM is initialized there, so Xloader is not up yet, SDRAM is more unlikely to be initialized. Since the SDRAM used by each person may be different, the initialization of the SDRAM is not able to be performed within the bootrom. Therefore, only 8k SRAM that is internally integrated on the chip is available, so the Xloader code must be very short), and then jump to that address to execute, giving control to Xloader. From here, we begin to execute the code of Xloader, which is the code of the _start label we originally analyzed. So how does bootrom know which address xloader image should be loaded into the SRAM? How do you jump to this address after loading? The answer to the question is still in the image header, as we have just said, in the header properties, there is a property called the load address, which is the bootrom and Xloader agreed to the address. Bootrom after reading the properties of the load address in the Xloader header, the Xloader elf section is loaded into the address and then the code is executed at the address specified in the load address. This load address is specified by Xloader, which is embodied in the Text_base parameter in the makefile of Xloader, This parameter, when Xloader is linked using LD, will overwrite the starting address of the code specified in the Xloader.ldr file to indicate the execution start address of the xloader instruction (through the LD parameter-T Xloader.lds-ttext $ ( Text_base), in addition, this text_base is also passed to the Mkimage tool, making the XloadEr image, the property of the load address in the image header can be set correctly. In this way, the whole process is perfect.
Of course, if Bootrom does not find Xloader image at sector 0 of Flash, it will attempt to boot from NAND flash (provided that it is also set to allow booting from NAND while setting the Bootrom function mode). If it is not found again, then the system will enter a dead loop.

After successfully handing control of the program to Xloader, it is the part of the code that we are now analyzing.
The next section will be followed by a step-by-step analysis.

Reference article:
Nor/nand
Http://blog.sina.com.cn/s/blog_53d5935e010006fl.html

Reference:
1, embedded Linux boot process 1.5--from bootrom to Xloader
http://blog.csdn.net/ffee/article/details/3092973