Uboot Analysis of Start.s 1

Note: This article is to learn the notes of teacher Zhu's course collation, based on uboot-1.3.4 and s5pc11x analysis.

By the Uboot.lds link script, we know that the entry of the entire program depends on where the entry declaration is.

ENTRY (_start)

So the file where the _start symbol is located is the starting file for the entire program, and the code where the _start is located is the starting code for the entire program.
Contents of _start in Start.s:

. globl _start
_start:b   Reset

At the beginning of the START.S is the inclusion of the header file:

#include <config.h>
#include <version.h>
#if defined (CONFIG_ENABLE_MMU)
#include <asm/ proc/domain.h>
#endif
#include <regs.h>

#include <config.h>:config.h is in the Include directory, which is the automatically generated file during configuration (see Mkconfig script). The content of this file actually contains a header file:

#include <configs/x210_sd.h> "

Therefore, #include <config.h> is: include/configs/x210_sd.h, this file is a lot of macros, the entire uboot migration configuration file. For example, the above Config_enable_mmu can go to the X210_sd.h file to find out if there is a definition.

#include <version.h>: Included in Include/version.h is the phrase "version_autogenerated.h", which is automatically generated during configuration. Inside is a line of content: #define U_boot_version "U-boot 1.3.4". The value of the macro u_boot_version defined here is a string, and the version number information in the string is derived from the configuration value in makefile. This macro in the program will be called, in the Uboot startup process will be the serial port to print out the Uboot version number, that version number information is from this.

#include <asm/proc/domain.h>:asm directory is not a native directory in the Uboot, Uboot does not have this directory. The ASM directory is a symbolic link created at the time of configuration, and the actual point is asm-arm (see uboot mkconfig Script analysis below). and proc points to the PROC-ARMV directory, the final actual file is: Include/asm-arm/proc-armv/domain.h

#include <regs.h>: This header file is also automatically generated during the configuration process, pointing to include/s5pc110.h.

From the analysis you can see the role of the symbolic link created in the previous configuration, and if no such symbolic link is compiled, it will not work at all because the header file cannot be found. (So Uboot cannot configure compilation under Windows shared folders because there are no symbolic links in windows)

thinking: why start. s does not directly contain asm-arm/proc-armv/domain.h, but uses asm/proc/domain.h.

This design is mainly for portability. Because if it is directly contained, start. s file and CPU architecture (and hardware), portability is poor. For example, I want to transplant the uboot into the MIPS architecture, then start. All header files in the S source code contain all to be modified. After we have used the symbolic link, start. The source code in s does not have to be changed, only need to change the specific hardware configuration, change the direction of the symbolic link created, you can have portability. The first 16 bytes of the boot code

#if defined (CONFIG_EVT1) &&!defined (config_fused). Word 0x2000. Word 0x0. Word 0x0
    . Word 0x0
#endif

. Word is a pseudo-assembly directive of the GNU Assembly, which is equivalent to an int type. There are 4. Word, which occupies a total of 16 bytes.

When the SD card starts/nand the entire image is started and a 16-byte check head is required. (Mkv210image.c is to calculate this check head). A 16-byte check head (Irom Application Note) is not required if the USB boot is started directly by means of the download.

The 16 bytes of this placeholder only guarantee that the official image's head does have 16 bytes, but the 16-byte content is not correct, or the checksum needs to be computed and then refilled later. Construction of anomaly vector table

. globl _start
_start:b   reset
    ldr pc, _undefined_instruction
    ldr pc, _software_interrupt
    Ldr pc, _ Prefetch_abort
    Ldr pc, _data_abort
    ldr pc, _not_used
    ldr pc, _irq
    ldr pc, _fiq

The exception vector table is hardware-based, and the software only implements it with reference to the hardware design. Each exception in the exception vector table should be handled, or the exception is actually run. But in the uboot not very meticulous handling of various anomalies. The following are the handling functions of these vector exceptions entry address:

_undefined_instruction:
    . Word undefined_instruction  #函数
_software_interrupt:
    . Word software_ Interrupt
_prefetch_abort:
    . Word prefetch_abort
_data_abort:
    . Word data_abort
_not_used:
    . Word not_used
_IRQ:
    . Word IRQ
_fiq:
    . Word Fiq

The code for the reset exception is: b Reset, so that the valid code that is actually executed after the CPU reset is the code at reset, so the reset symbol is where the code in the real sense begins. Where reset is a label, below the START.S there are:

/* The actual reset code*/
Reset:/
    * Set the CPU to SVC32 mode and IRQ & FIQ disable*//
    * Previous 4 sentences are commented out */
  @;mrs   r0,cpsr
    @;bic   r0,r0, #0x1f
    @;orr r0,r0   , #0xd3
    @;msr   cpsr,r0
    msr Cpsr_c, #0xd3       @ I & F Disable, mode:0x13-svc

In fact, the ARM CPU will enter the SVC mode by default when it resets, but it is also used in the software to set it to SVC mode. The CPU is always in SVC mode when the entire uboot is working.

_end_vect:
    . BALIGNL 16,0xdeadbeef

. BALIGNL 16,0xdeadbeef. This instruction is to make the current address 16 bytes aligned, if the current address is not aligned automatically go back to the address until the alignment, and the back of the memory to be used to fill with 0xdeadbeef. 0xdeadbeef This is a hexadecimal number, this number is very interesting, just formed the English dead beef These two words, literally mean bad beef.

_text_base:
    . Word   text_base

Text_base is the Text_base value written in makefile configuration phase, which is actually the link address of the uboot that we specified at the time of the link.

_text_phy_base:
    . Word   cfg_phy_uboot_base #uboot在DDR中的物理地址

Cpu_init_crit

Cpu_init_crit:
    bl disable_l2cache/              * prohibit L2 cache*/
    bl set_l2cache_auxctrl_cycle    /*L2 Cache Related initialization */
    BL Enable_l2cache/               * Enable L2 cache*//


   * Invalidate L1 icache
   and dcache*/mov r0, #0                  @ set up for mcr
  
   MCR P15, 0, R0, C8, C7, 0   @ invalidate tlbs
   MCR p15, 0, R0, C7, C5, 0   @ invalidate icache
   /*disable M  MU Stuff and caches*/
   MRC P15, 0, R0, C1, C0, 0
   Bic r0, R0, #0x00002000     @ clear bits (--v-)
   Bic r0, R0, #0x00000007     @ clear bits 2:0 (-cam)
   Orr r0, R0, #0x00000002     @ set bit 1 (--a-) Align
   Orr R0, R0, #0x00000800     @ set bit (Z---) BTB
   mcr p15, 0, R0, C1, C0, 0
  

Why the BIC and ORR instructions above are executed 2 times in succession. Because 0x2007 and 0x802 are both illegal and immediate numbers, they cannot be manipulated directly.
The above steps are related to the CPU cache and the MMU, do not have to look closely, probably know. Boot Media Selection

  /* Read Booting information */
        LDR r0, =pro_id_base         
        ldr R1, [R0, #OMR_OFFSET]/     * r1=0xe0000004 */
        BIC R2, R 1, #0xffffffc1 NAND BOOT */
    CMP R2, #0x0        @ 512B 4-cycle/ 
                        * NAND The page size is 512b,4 instruction cycle */
    Moveq   R3, #BOOT_NA ND

    cmp R2, #0x2        @ 2KB 5-cycle
    moveq   R3, #BOOT_NAND

    cmp R2, #0x4        @ 4KB 5-cycle   8-bit ECC/  
                       * NAND has a page size of 4kb,5 instruction cycle, 8-bit ECC check */
    moveq   R3, #BOOT_NAND

    cmp R2, #0x6        @ 4KB 5-cycle   16-bit ECC
    moveq   R3, #BOOT_NAND

    cmp R2, #0x8        @ onenand Mux
    moveq   R3, #BOOT_ONENAND /

    * SD/MMC boot */
    cmp     R2, #0xc
    moveq   R3, #BOOT_MMCSD/ 

    * NOR BOOT */
    CMP     R2, # 0x14
    Moveq   R3, #BOOT_NOR   

Inside the x210 there is a register (the address is 0xe0000004), and the value in this register determines who the actual boot media is. The value in this register is automatically set by the hardware based on the settings of the OM pin. A number is stored in the R2 register, which represents the different boot media and then stores the corresponding value in the R3, which is later reserved.

The following analysis is shown in: Uboot's START.S Analysis 2