Uboot Transplant Preparation Four

Source: Internet
Author: User


Introduction to the second part of the start_armboot (void) function
1. In UBOOT/LIB_ARM/BOARD.C from 327-798. This is not all, because there are other functions called inside.
2. Why is a function so long, not divided into two or three functions? The main reason for this function is the second phase of the Uboot launch.
3. Macro analysis: What should be done in the second phase of uboot? In general terms, the first phase of the Uboot is primarily to initialize some components inside the SOC (e.g., watchdog, clock,) and then initialize the DDR and complete the relocation. By macro analysis, the second phase of Uboot is to initialize the remaining parts that have not yet been initialized. It is mainly SOC external hardware (such as Inand, Nic Chip ...) uboot some things of itself (uboot command, uboot environment variable). Then finally initialize the necessary things after entering the uboot command line ready to accept the command.
4. Where does the second phase of Uboot end? Uboot automatically runs after startup to print out a lot of information (which is the information that Uboot prints when the first and second phases are constantly initialized). The uboot then enters the countdown BootDelay second and executes the bootcmd corresponding start command.
5. If the user does not intervene, the bootcmd will be executed to enter the auto-start kernel process. (Uboot will die); At this point the user can press ENTER to break Uboot's auto-start into the uboot command line. Then Uboot has been working on the command line.
6. The command line of the Uboot is a dead loop in which the body repeats itself, receives commands, parses commands, and executes commands, which is uboot final destination.

2.6.2 start_armboot (void)
1. init_fnc_t,
typedef int (init_fnc_t) (void); This is a function type.
Init_fnq_ptr is a double-function pointer, recalling the high-level C language; The two-pointer function has 2 (one of which is used to point to a pointer), and the other is used to point to an array of pointers. So the init_func_ptr here points to an array of function pointers.
3. Declare_global_data_ptr
#define DECLARE_GLOBAL_DATA_PTR Register volatile gd_t *gd asm ("R8") defines a global variable named GD, which is a pointer type that accounts for 4 bytes. The variable is represented by a volatile modification, and the register is modified to indicate that the variant should be placed as far as possible into the register, and the following ASM ("R8") is a syntax supported by GCC, meaning to place GD in the register R8.
Comprehensive analysis, DECLARE_GLOBAL_DATA_PTR is defined as a global variable to be placed in the register R8. The name is GD, and the type is a pointer to the gd_t type variable.
Why is it defined as register? Because this global variable (GD) is a very important global variable in uboot (it is accurate to say that the global variable is a struct, there is a lot of content, the content of which is composed of the structure is commonly used in uboot all the global variables), this GD is often accessed in the program, Therefore, in the Register to improve efficiency. Therefore purely operational efficiency considerations, independent of functional requirements.
gd_t definition in include/asm-arm/global_data.h defines a lot of global variables, which are used throughout the uboot, one of the bd_t type pointers to a bd_t type of variable, this BD is the board-level information structure of the Development Board, There are a number of hardware-related parameters, such as baud rate, IP address, machine code, DDR memory distribution.

2.6.3 Memory usage Arrangement
1. Why to allocate memory declare_global_data_ptr can only define a pointer, that is, GD in these global variables are not allocated memory, we use GD to allocate memory before, otherwise GD is just a wild pointer.
2.GD and BD need memory, memory is not currently managed (because there is no operating system to manage memory uniformly), large amount of DDR memory is free to use (as long as the memory address directly to access memory). But because uboot in the next many operations also need a large amount of attached memory, so the use of memory here in line with the principle of good, compact arrangement, all of us in the uboot need to have an overall plan.
2.6.3.2 Memory Arrangement
1.uboot Area: cfg_uboot_base-xx length is the actual length of the UBOOT
2. Heap area: Cfg_malloc_len length of 1040KB
3. Stack: The length is cfg_stack_size actual 512KB
4.gd length is sizeof (gd_t), actual 36 bytes.
5.bd length is sizeof (bd_t), which is about 44 bytes.
6. Memory interval in order to prevent errors caused by high-version gcc optimizations.
2.6.4 Start_armboot Analysis 2
2.6.4.1 for loop execution init_sequence
1.init_sequence is an array of function pointers that stores a number of function pointers, all of which are directed to the init_fnc_t type (the feature is that the receive parameter is the void type, and the return value int). Init_sequence is initialized at the time of definition, and the function pointers that are initialized are some function names. Init_fnc_ptr is a double function pointer that can point to init_sequence, an array of function pointers. Using a For loop is definitely going to go through this array of function pointers (the purpose of the traversal is to execute all the functions in the array of function pointers in turn), thinking: How do I traverse an array of function pointers? There are 2 kinds, the first is also the most common one, with the subscript to traverse, with the number of array elements to cut off.
The second, not commonly used, but also can be, is the array of valid elements at the end of a flag, a traversal to the standard can be cut-off. (a bit like the idea of a string). We used the second idea here, because the array is full of function pointers, so we chose NULL as the flag, and we iterate from the beginning.
The return value of these functions of init_fnc_t is defined in the same way that the function execution is returned 0 correctly and is suspended. From the analysis of the hang function, it is known that the Uboot initialization process can not make any errors when initializing the board-level hardware, as long as there is an error to terminate the entire startup, unless there is no way to restart the Development Board.
These functions in init_sequence are all kinds of hardware initialization at the board level.
2.6.4.2 Cpu_init
Look at the name. This function should be initialized within the CPU. So it's empty.
2.6.4.3 Board_init
Board_init is in Uboot/board ..... Inside. Declare_global_data_ptr here is declared to use GD convenience, you can see the declaration of GD to define a macro reason is that we have to go everywhere to use GD, it is necessary to declare everywhere, the definition of macro is more convenient.
Nic initialization. CONFIG_DRIVER_DM9000 This macro is defined in the TQ210.h, this macro is used to configure the Development Board of the network card, dm9000_pre_init () This function is the corresponding DM9000 NIC initialization function, the Development Board migration Uboot, If you are porting a network card, the main work is here. This function is mainly the network card's Gpio and the configuration of the port, not the driver, because the driver of the network card is ready-made, the porting is not required to change the driver, the key is the basic initialization here, because these basic initialization is hardware-related.
2.6.5 Start_armboot Analysis 3
2.6.5.1 gd->bd->bi_arch_number = Mach_type;
1) Bi_arch_number is an element in the Board_info, meaning: The machine code of the Development Board. The so-called machine code is a unique number that Uboot gives to the Development Board. The main function of the machine code is to match the complementing between the uboot and the kernel. The hardware of each device in the embedded device is customized and cannot be used universally. This tells us that the kernel image of this board porting must not download another development Board, otherwise it can not start, even if the boot does not work properly, there are many hidden dangers. So Linux makes a setup, and makes a unique number (machine code) for each Development board. And then uboot,linux the kernel has a software maintenance machine code number. Then the development Board, Uboot,linux three than the machine code, if the machine code on the boot, otherwise it will not start, (because the software think I and this hardware is not suitable). Mach_ The type is defined in TQ210.h, the value is 2456, and there is no special meaning, but the current Development Board corresponding to the number, this number represents the TQ210 the Development Board of the machine code, in the future, the Development Board of the Linux kernel transplanted on the machine code must also be 2456, otherwise start up. The machine code configured in Uboot will be passed to the Linux kernel as part of the Uboot to the Linux kernel, and the kernel boot process will be compared to the received machine code, and the machine code of its own, if equal to start, if not equal to not start. Theoretically, the machine code of a Development Board cannot be arbitrarily determined by itself. Theoretically, there is the right to issue this machine code. Only Uboot official, all we do a development board and Transplant Uboot, in theory should be submitted to uboot official audit and issue the machine code (as if it is free). But the domestic development Board basically did not apply. (mainly because the domestic developers do not have English, and foreign open source community less contact). Are their own random number, random number of the problem is likely and other people's number, but as long as the guarantee uboot and kernel in the number is consistent, will not affect their Development Board start.

Gd->bd->bi_boot_params = (phys_sdram_1+0x100);
Another major element in Board_info, Bi_boot_params, represents the memory address of the Uboot to the Linux kernel when it starts. Also say that uboot to the Linux kernel when the transfer of the message: Uboot in advance to prepare the parameters (string: Bootargs) at an address in memory (Bi_boot_params), The uboot then launches the kernel (Uboot actually passes the parameters directly through the Register r0 R1 R2 when the kernel is booted, and one of the registers is Bi_boot_params). After the kernel starts to read from the register, Bi_boot_params will know what the parameters Uboot give us in memory. Then go to the memory of the place to find Bootargs.
It is calculated that the Bi_boot_params value in TQ210 is 0x20000100, and the memory address is allocated for kernel communication. So when using memory in other parts of uboot, be careful not to let it drown.

Background: The configuration of the DDR.
In addition to the initial board_init of the NIC, the remaining 2 lines are used to initialize the DDR.
Note: Here the initialization DDR and assembler phase Lowlevel_init initialize the DDR, which was the initialization of the hardware at that time, so that the DDR can begin to work. There are some DDR-related property configurations in the software architecture, and the initialization of address settings is purely software-level. Software hierarchy The reason for initializing DDR, for Uboot, how did he know how many DDR memory on the board, the starting address, the length of each piece of information? In the design of Uboot, a simple and direct and effective way, the programmer in the porting Uboot to a development board, the programmer in TQ210.h use the macro definition to configure the board DDR memory information, and then uboot just read this information. (There is actually another way of thinking: that is, Uboot reads hardware information from code to guide the DDR configuration, but Uboot does not.) In fact, the bios of the PC uses this. )
The standard macro definitions are used in the tq210.h544 line to configure DDR-related parameters. The main configuration is that there are several pieces of DDR memory, the starting address of each DDR, and the length. Here the configuration information we use in the Uboot code in memory can be extracted from the use of this (imagine Uboot used in memory is not directly used in the address number, are defined by the macro).
2.6.6 Start_armboot Analysis 4
2.6.6.1 Interrupt_init Look at the name function is related to interrupt initialization, but actually not, actually this function is used to initialize the timer (the actual use of the Timer4). Bare Metal said: 210 A total of 5 PWM timers, wherein the TIMER0-TIMER3 has a corresponding PWM signal output pin, and Timer4 no pin, unable to output the PWM waveform. The TIMER4 is not designed to output PWM waveforms (no pins, no TCMPB registers), and this timer is used for timing. Timer4 used to use 2 registers when timing: TCNTB4 TCNTO4. A number is saved in the TCNTB, this number is the timing, (each time is determined by the clock, in fact, is determined by the 2-level clock divider). Our timing is simply to put the timing time/reference time = number, this number into the TCNTB can be. We can read the time through the Tcnto register is reduced to 0, read to 0 and know the time has arrived. Use Timer4 to schedule, because there is no interrupt support. So the CPU can not do other things at the same time, the CPU can only use polling method to constantly view the Tcnto register to know the timing time is not. Therefore, Timer4 timing can not achieve micro-parallelism. Uboot in the timing is through the Timer4 to time, so uboot in the timing can not do other things. (In consideration, it is typical to implement timing in Bootdelay,bootdelay and check that user input is implemented by polling, originally referring to the keys in the key section of the bare metal). The Interrupt_init function sets the Timer4 setting to 10ms. The key part is the GET_PCLK function gets the Pclk_psys clock frequency of the system setup, then sets TCFG0 and TCFG1 to divide, then calculates the value to be written in TCNTB when set to 10ms, writes it to TCNTB, Then set it to Autoreload mode, and then the timer starts to run out.
Summary: When learning this function, pay attention to the differences between the standard code and the previous bare-metal code, and focus on learning to: access the Register by defining the structure, and automatically calculate the setting value by function to set the timer.

2.6.6.2 Env_init
1.env_init, the name is known as the initialization associated with the environment variable. Why there are many env_init functions, the main reason is that Uboot supports a variety of boot media (such as the NORFLASH,NANDFLASH,INAND,SD card ...) where we usually start the environment variable env place. And the various media access operation Env method is different. Therefore, Uboot supports the Env operation method in various media. All a lot of env_xxx start with the C file, the actual one to use according to their own Development board to use the storage media to be determined. (These env_xxx.c at the same time only one will work, other things can not go in.) The macros configured by TQ210.h determine who is included. For TQ210, we should look at the ENV_MOVI.C function. After a basic analysis, this function simply initializes or judges the Uboot env that is maintained in memory (judging if there are any environment variables that can be used). Currently we do not have the environment variable SD card to the relocate in the DDR, so the current environment variable is not available. Calling Env_relocate in the Start_armboot function does not make the environment variable read from the SD card.

2.6.7 Start_armboot Analysis 5
1. Init_baudrate look at the name is the initial serial communication baud rate.
The 2.getenv_r function reads the value of the environment variable, reads the value of "baudrate" in the environment variable with the GETENV function (note that the value read is a string type), and then uses the Simple_strtoul function to convert the string to a number-formatted baud rate.
The rule at 3.baudrate initialization is to read the value of the environment variable "baudrate" in the environment variable first. If the read succeeds, the value is used as an environment variable, recorded in Gd->baudrate and Gd->bd->i_baudrate, and if the read is unsuccessful, the value of config_baudrate in TQ210.h is used as the baud rate.

2.6.7.2 Srial_init
1. Initialize the serial port (question: start. s called the Lowlevel_init. S has already used the assembly to initialize the serial port, and here is how to initialize it? Are the two initializations duplicated or are they different? )
As you can see in 2.SI, there are many derial_init functions in uboot, and we use the Serial_init function in UBOOT/CPU/S5PC11X/SERIAL.C.
2. Come in and find out that the Serial_init function actually did nothing. Because the serial port has been initialized in the assembly phase, the hardware register is no longer initialized.

2.6.8 Start_armboot Analysis 6
2.6.8.1 Console_init_f
Console_init_f is the first stage of initialization of the console console, the F represents the first phase of initialization, R for the second phase initialization, sometimes the initialization function cannot be completed together, the middle must be mixed with some code, so the complete initialization of a module is divided into 2 stages. (The 734 lines of start_armboot in our uboot are initialized with Console_init_r.) )
Console_init_f in Uboot/common/console.c, is only for gd->have_console = 1;

2.6.8.2 Display_banner function
1.dispaly_banner used for serial output display Uboot logo
2.display_banner using the printf function to the serial port output version_string This string, then the above analysis indicates that Console_init_f does not have an initialization number console how can printf?
3. By tracing the implementation of printf, Discover printf->pusts, and the puts function will determine whether the console is initialized in the current uboot, if the console initialization is good, then call fputs complete serial port send If the console has not yet been initialized, it will call Serial_puts (in the call SERIAL_PUTC direct operation of the serial port register for content delivery).
4. The console is also output through the serial port, the non-console is also through the serial port output, what is the console, and what is the difference between the console? In fact, the analysis code will find that the console is a software virtual out of the device, the device has a dedicated communication function (send receive ... , the console's communication functions are eventually mapped to the hardware's communication functions. In fact, the communication function of the console in Uboot is directly mapped to the communication function of the hardware serial port, that is to say, there is no essential difference in uboot with the useless controller. However, in other systems, the communication functions of the console can be mapped to hardware communication functions using software to do some intermediate optimizations, such as buffering mechanisms. The console in the operating system uses a buffer mechanism, all the times we have printf content, but the screen does not see the output information, because it is buffered, we output the information is only in the console buffer, buffer has not been flushed to the hardware output device, Especially when outputting the LCD screen of the device.
6.u_boot_version the definition was not found in the Uboot source code. This variable is actually defined in makefile and then generated at compile time with a macro definition in the include/autogenerated.h.

2.6.8.3 Print_cpuinfo
During the 1.uboot boot process:

All of this information is pirnt_cpuinfo printed.
2. Looking back at arm bare metal in the clock configuration chapter of the content, compared to the function called here to calculate the various clocks, their own analysis of the principle of the Code and implementation method, this is learning.
2.6.9 Start_armboot Analysis 7
1. Checkboard look at the name is check, confirm the meaning of the Development Board. The function is to check which development Board is on the current board and print out the name of the Development Board.
2.INIT_FUNC_I2C This function is not actually executed. If in the future our Development Board wants to expand the i²c to connect the hardware, then configures the corresponding macro in the next TQ210.h to turn on.

2.6.9.3 Uboot Learning Practice
1. Make changes to the Uboot source code (modify the content according to your own understanding and analysis).
2.make Distclean then make tq210_config and make
3. Compile to get u-boot.bin, then go to burn. The burning method of the bare metal in the third part of Linux under the use of DD command to burn write method to burn.
4. Burn the writing process:
First step: Enter the Sd_fusing directory.
Step Two: Make clean
Step three: Make
Fourth step: Insert SD card, ls/dev/sd* get SD card in Ubuntu device number (generally/DEV/SDB, note SD card to link to virtual machine in Ubuntu)
Fifth step:./sd_fusing.sh/dev/sdb
Summary: Uboot is a huge and complex point of the bare-metal program, we can completely debug him. The debugging method is to follow the above steps, according to their own analysis of the code and understanding of the code changes, and then recompile the burn run, according to the results of the operation to learn.

2. 6.10 Start_armboot Analysis 8
2.6.10.1 Dram_init: Look at the first name is about the DDR initialization, doubt: The assembly phase has already initialized the DDR or else can not relocate to the second part of the operation, how to initialize DDR here?
Dram_init is assigning values to GD->BD for the global variables in the DDR configuration section, allowing GD->BD data to record the configuration information for the current Development Board's DDR so that memory is used in Uboot.
From our code, it is actually initializing the GD->BD->BI_DRAM structure array.
2.6.10.2 Display_dram_config
1. The name means printing the configuration information for the DRAM. In the startup message: (DRAM:1G) is printed in this function. Think: How do I know Uboot's DDR configuration information in the Uboot run? A command in Uboot called Bdinfo, which prints out the values of all the hardware-related global variables recorded in the GD->BD, so you can learn about the configuration information for the DDR.

2.6.10.3 init_sequence Summary
1. Both the initialization of board-level hardware and the initialization of data structures in GD GD->BD. For example: NIC initialization, machine code (gd->bd->bi_arch_number), kernel-pass DDR address (gd->bd->bi_boot_params), Timer4 initialized to 10ms once, baud rate setting (gd- >bd->bi_baudrate and Gd->baudrate), console first stage initialization (Gd->have_console set to 1), Print uboot boot information, print CPU-related setup information, Check and print the current board name, DDR configuration information Initialization (Gd->bd->bi_dram), and print the total DDR capacity.

2.6.11 Start_armboot Analysis 9
1. Although Nandflash and Norflash are Flash, the general Nandflash will be referred to as Nandflash NAND instead of flash, generally speaking flash refers to the norflash. Here 2 lines of code are norflash related.
2.flash_init performs the initialization of the corresponding Norflash in the Development Board, Display_flash_config printing is also norflash configuration information flash:8 MB is printed here. But in fact there is no norflash in the TQ210. So these two lines of code can be removed. (I don't know why I didn't get rid of it.) The reason for guessing is that it is possible to remove these two lines of code and cause other places to work abnormally and take the time to transplant the debugs, without actually removing any other effects except for the fact that 8MB Flash is not actually displayed. )
CONFIG_VFD is a display related, this is the uboot in the LCD display related, this is the uboot of the LCD display software architecture. But in fact we use LCD instead of using Uboot to set up this software architecture, we ourselves added an LCD display section in the back.
2.6.11.2 Mem_malloc_init
1. This function is used to initialize the heap manager of the Uboot.
2.uboot maintains a heap of memory in its own right, and is sure to have a code to manage this heap of memory. With these things uboot you can also malloc,free this set of mechanisms to apply for memory and free memory. We have reserved 896KB of memory for the heap in DDR memory.
2.6.11.3 code practice, remove Flash line not.
Conclusion: Add Config_noflash macro after the compilation error, the code is not good, the inclusion of the file is not controlled by this macro, so the transplant people will be directly left out of the tube.
2.6.12 Start_armboot Analysis 10
1. Unique initialization of the Development Board: MMC initialization
Starting with 421 lines, the Development Board is unique in its initialization. Samsung uses a set of uboot at the same time to meet a number of models of the Development Board, and then here the different development boards own unique some of the initialization of the written here. Compile the Mate Config_xxx macro with the # if condition to select a specific development board.
TQ210 from 510 lines, is its related configuration. Mmc_initialize look at the name should be MMC related to some of the basic initialization, is actually used to initialize the SOC internal SD/MMC controller. The function is inside the UBOOT/DRIVERS/MMC.C.
The operation of hardware in Uboot (such as network card, SD card) is implemented by borrowing drivers from the Linux kernel, and a drivers folder underneath the Uboot root directory is a variety of drive source files that are migrated from the Linux kernel.
Mmc_initialize is an MMC initialization function that is independent of the specific hardware architecture, and all code that uses the schema calls this function to complete the MMC initialization. MMC calls the Board_mmc_init () and Cpu_mmc_init () to complete the specific hardware of the MMC controller initialization work.
Cpu_mmc_init in/uboot/cpu/s5pc11x/cpu.c, the driver code in DRIVERS/MMC/S3C_MMCXXX.C is called indirectly to initialize the hardware MMC controller. This is a lot of layering, layered thinking must have, otherwise completely confused.
2.6.13 Start_armboot Analysis 11
1.env_relocate is the relocation of the environment variable, completing the task of reading the environment variable from the SD card into the DDR.
2. Where do environment variables come from? There are some (8) separate sectors of the SD card that are stored as environment variables. But when we burned/deployed the system, we just burned the uboot partition, the kernel partition and the Rootfs partition, never burned the env partition, all when we burned the system first boot the env partition is empty, This start uboot attempt to go to the SD card env partition read environment variable failure (after reading back to do CRC check failure), we uboot choose from uboot Internal code set of the default environment variables to use (this is the default environment variable). This runtime of the default environment variable is read into the environment variable in the DDR, then written to (or perhaps written by you savenv, or uboot is designed to write the env partition of the SD card the first time the default environment variable is read). Then the next time you boot up, the uboot will read the environment variable from the env partition of the SD card into the DDR, which is
The real code to relocate env from the SD card to the DDR is done in the ENV_RELOCATE_SPEC internal movi_read_env.

2.6.14 Start_armboot Analysis 12
1.IP address, MAC address determines that the IP address of the board is maintained in GD->BD and is derived from environment variables. The getenv function is used to get the IP address in string format. The IP address of the string format is then converted into a dotted decimal format in string format using STRING_TO_IP.
The 2.IP address consists of 4 numbers from 0-255, so the simplest way to store an IP address in a program is a unsigend int. But it is not this type that humans can easily understand, but the dotted decimal type. These two types can be converted to each other.
2.devices_init
Look at the name is the initialization of the device, where the device refers to the Development Board of hardware equipment. The device that is initialized here is the drive device, and this function is derived from the drive frame. Many devices in the uboot are driven by direct porting of the Linux kernel (such as network cards, SD cards), and the driver in the Linux kernel has the appropriate device initialization function. The Linux kernel has a devices_init during startup (the name is not necessarily exactly, but almost), and the function is to centralize the execution of various hardware-driven init functions.
This function of Uboot is actually transplanted from the Linux kernel, and its function is to execute all the inherited from the Linux kernel.

4. Jumptable_init jumptable Jump table, itself is a function pointer array, which records the function name of many functions. Look at this. To implement a function pointer to a specific function of the mapping relationship, in the future through the Jump table function pointers can execute the specific function. This is actually using C language to implement object-oriented programming. There are many such tricks in the Linux kernel. The analysis found that the jump table was only assigned and never referenced, so it was not used in Uboot.

2.6.14 Start_armboot Analysis 13
1.console_init_r Console_init_f is the first stage of the console initialization, Console_init_r is the second phase of initialization. The first phase did not do anything substantive, and the second phase of initialization only started the substance.
There are many functions of the same name in 2.uboot, using the SI tool to index to the wrong function. Automatic indexing to the wrong, the real but did not find at all.
3.console_init_r is the initialization of the console's purely software architecture. (that is, to populate the console-related data structure with the corresponding values), it is the initialization of the pure software configuration type.
The 4.uboot console actually does not have a meaningful conversion, it is directly called the serial communication function. So there's no difference between using the console.

5. Enable_interrupts look at the name should be interrupt initialization code. This refers to the enable of the total interrupt flag bit in the CPSR. Because we do not use interrupts in our uboot, we do not define CONFIG_USE_IRQ macros, so this function here is empty shell.
6. A common occurrence in uboot is to determine whether a macro defines a code that is inside a function, depending on whether it is defined to be conditional compilation. There are 2 solutions in Uboot to deal with this scenario: scenario One: Use conditional compilation at the calling function, and then actually fully provide the code for the function body. Scenario two; called directly at the calling function, and then provides 2 function bodies at the function body, one with an entity is a shell.
2.6.15.3 loadaddr bootfile Two environment variables
Both of these environment variables are kernel-initiated and refer to the values of the two environment variables when starting the Linux kernel.
2.6.15.4 Board_late_init Look at the name this function is the Development board level of some initialization is relatively late, is the late initialization. All of the later initialization is initialized, and some of the rest must be initialized here. The side illustrates that the development board level of hardware software initialization is over. For TQ210, this function is empty.

2.6.16 Start_armboot Analysis
1.eth_initialize look at the name should be the network card related initialization, this is not the SOC and Nic Chip link on the SOC side of the initialization, but some initialization of the NIC chip itself. For TQ210, this function is empty.


The third part is recorded with the Tang
What exactly is 1.uboot and the kernel uboot is a bare-metal program.
The essence of Uboot is a bare-metal program with a complex point. There is no essential difference between every bare-metal program we learn in arm bare metal.
Arm bare Metal Part 16th wrote a simple shell, which is actually a mini-uboot.
2. The kernel itself is also a "Bare Metal program"
The operating system kernel itself is a bare-metal program, and Uboot, and other bare-metal programs are not fundamentally different.
The difference is that the operating system after the operation of the software into the kernel layer and application layer, layered after the two tiers of permissions, memory access and the management of device operations more granular (the kernel can easily access a variety of hardware, and the application can only restrict access to hardware and memory address).
Intuitively, the image of Uboot is u-boot.bin. The image of a Linux system is zimage, and these two things are actually two bare-metal program images. From a system start point of view, the kernel is actually a large complex point bare-metal program.

2.7.1.3 deployed in a specific partition on the SD card
A complete software + hardware embedded system, at rest, Bootloader,kernel,rootfs and other necessary software are stored in the form of a mirror in the boot media, the runtime is running in DDR memory, regardless of storage media. The above 2 states are stable, the 3rd state is the dynamic process, that is, from the stationary state to the operating state of the process, that is, the start-up process.
The dynamic start-up process is a gradual move from the SD card to the DDR memory, and run the startup code for the related hardware initialization and the establishment of the software architecture, and finally achieve a stable state of the runtime.
At rest u-boot.bin zimage roots are in the SD card, they can not freely exist anywhere SD card, it is necessary to partition the SD card, and then the various images have their own partitions, so that during the boot process uboot, the kernel and so on know where to find who. (the partition tables in Uboot and kernel must be consistent), consistent with the actual partition of the SD card.

The 2.7.1.4 runtime must first be loaded into the DDR at the link address
Uboot the second stage (the entire uboot mirror) is loaded to the 0xc3e00000 address of the DDR during the first phase of the relocation, this address is the Uboot link address. The kernel also has similar requirements, uboot boot the kernel when the memory from the SD card read into the DDR (in fact, is the relocation process), can not be arbitrarily placed, must be placed at the core of the link address, or not start up. For example, the kernel link address we use is 0x20008000.

2.7.1.5 boot parameters required for kernel boot
1. The uboot is started unconditionally and starts from scratch.
2. The kernel does not boot automatically start completely from zero, the kernel starts to help others, uboot to assist the kernel to relocate (from SD card to DDR), Uboot also provide the kernel with boot parameters.
2.7.2 starts the kernel first step and loads the kernel into the DDR.
Uboot to start the kernel, it is divided into 2 steps, the first step is to load the kernel image from the boot media into the DDR, and the second step is to start the kernel image in the DDR.
(Kernel code does not consider relocation at all, because the kernel knows there will be uboot and the like to load itself into the DDR link address, so the kernel is directly from the link address at the beginning of the run)

2.7.2.1 where is the static kernel image?
1. SD card/inand/nand/norflash, etc.: Raw partition
The various mirrors are on the SD card during normal boot, so the uboot only needs to read the kernel image from the SD card's kernel partition to the DDR. Read the command to use Uboot to read (for example, the Inand version of TQ210 is the NAND command).
2. This boot mode to load DDR, using the command NAND read kernel 30008000. Where kernel refers to the kernel partition in the Uboot (which is an area range in the SD card specified in the Uboot, which is designed to hold the kernel partition).
3. Tftp NFS and other network download mode from the remote server to obtain the mirror
Uboot also supports remote boot, that is, the kernel image is not burned to the board's SD card, but is placed on the host's server, and then needs to be started when the uboot from the server to download the image to the Development Board of the DDR.

Analysis Summary: The final result is to the kernel image to a specific address in the DDR, regardless of how the kernel image to the DDR, the above 2 ways have advantages, the product will be set to boot from the SD card, TFTP download remote boot This way is generally used to develop

Uboot Transplant Preparation Four

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.