Enable uboot to support the SD startup

Enable uboot to support the SD startup

-- Figo 2009-8-13

The uboot code used here is not the uboot Code officially released by uboot, but a uboot version s3c-u-boot-1.1.6 customized for Samsung. The author of the Code includes Samsung programmers and denx employees.

This version supports SD boot, but the default is NAND boot. to enable it to support uboot, you need to do the following:

 

1. Although uboot is supported, the uboot code is not called the SD startup mode, but the movinand startup mode. This option is available in incluede/configs/smdk6410.h, so close the NAND startup in this file and enable movinand to start it:

// # Define config_boot_nor

// # Define config_boot_nand

Comment on NAND startup

# Define config_boot_movinand

Start movinand

// # Define config_boot_onenand

// # Define config_boot_onenand_irom

# Define config_nand

// # Define config_onenand

# Define config_movinand

Enable the movinand option to enable uboot to support the movinand operation.

 

2. If you just make the above changes, it is still not enough. During running, you will find that uboot will die at a certain time, in fact, this is because in uboot, we assume that smdk6410 is started from ch0 When SD is used, but the board on the hand is started through compaction, therefore, SD cannot be detected in ch0 when the 8 K code copied to the SRAM is run, and the code in SD cannot be copied to the SDRAM. Modify hsmmc_channel to 1 in receivede/movi. h.

 

3. If the u-boot.bin compiled after the above modification is directly written to SD through irom_fusing_tools, there is no way to start, you need to run the following command for processing:

 

Cat u-boot.bin> temp

Cat u-boot.bin> temp

Split-B 256 k temp

Music Video xAA u-boot_256k.bin

Split-B 8 K u-boot.bin

Music Video xAA u-boot_8k.bin

Cat u-boot_256k.bin> u-boot_mmc.bin

Cat u-boot_8k.bin> u-boot_mmc.bin

 

After these processes, the u-boot.bin content is actually repeat once (to ensure that it reaches 256 K, if this bin is smaller, it may need to repeat 3, 4 times until it exceeds K ), the first 256 K made of u-boot_256k.bin, and then the first 8 K made of u-boot_8k.bin, and finally the u-boot_256k.bin + u-boot_8k.bin into a K + 8 K size file u-boot_mmc.bin, this file before the 256k is the u-boot_256k.bin and then 8k is the u-boot_8k.bin. Write the u-boot_mmc.bin to the SD card through irom_fusing_tools to start the system. Why is this binfile processed? The following analyzes the source code of irom_fusing_tools and uboot to reveal its origins.

 

You can download the irom_fusing_tools source code from the Internet. After you press the Start Control of the software, you first read the first sector of the SD card, that is, the MBR sector of the disk, determine whether a disk is in the FAT32 format (this is why the SD used for startup must be formatted in the FAT32 format), and then obtain the total number of sectors total_secotr, and burn the binfile to be written to the disk. The sector is total_sector-2-size_of_image/512. Here, total_sector is the total number of sectors of the disk; size_of_image/512 is the number of sectors to be occupied by the binfile (this is based on 512 as the sector size, so the SD card with a larger sector cannot be used, the current large-capacity SD may use 2 K or even 4 K sectors, unless this program is modified and the program is modified in uboot synchronously); 2 is the reserved two sectors, the source code of uboot needs to be analyzed as to why the two sectors should be retained. The following will be further elaborated.

 

In the SD startup mode, the irom program bl0 in the kernel runs first, and the content of 16 sectors starting from the last 18 sectors in the kernel is copied to the 8 k sram in the kernel, that is steppingstone, and then jump to the beginning address of this SRAM to start running, the 8 K code is actually the last 8 K of the above u-boot_mmc.bin file, is also the beginning of the u-boot.bin 8 K code, this code is also called BL1. When you jump from bl0 to BL1, uboot takes over the CPU. The uboot entry is at start. s file, CPU/start. s has the following code: # ifdef config_boot_movinand LDR sp, _ text_phy_base BL movi_bl2_copy B after_copy # endif, which is the key to implementing SD startup. After that, execute movi_bl2_copy. This function is responsible for completely copying the uboot in SD to SDRAM. At this time, the complete uboot is also called bl2, and this function actually calls the following function: copymovitomem (hsmmc_channel, movi_bl2_pos, kernel, (uint *) bl2_base, movi_init_required); hsmmc_channel is the SD/MMC channel number, and the memory is ch0 by default, so you need to modify this.

 

Movi_bl2_pos indicates that the data to be copied is located in the Start slice of SD. The calculation method is as follows. First, the total number of slice of this SD is obtained, then subtract the number of slice occupied by bl2 of 0.5 K and BL1 of 8 K, and then subtract the number of slice occupied by efuse of K and retention zone of K. The SD slice is also defined as B. Here we can see that irom_fusing_tools exactly corresponds to SD card processing. There is another question: how does the total number of slice total get? From the perspective of the program, it is read from the address (tcm_base-0x4). As for how total is put here, you can only find the answer from the bl0 code. Movi_bl2_blkcnt is the number of slices to be copied, which is defined as 256 K, which is why the u-boot.bin must be converted to a K file. Bl2_base is the destination address, that is, the address in SDRAM. It is defined as 0x57e00000, which is the last 2 m of the 128 m sdram. Because MMU has not been opened so far, the physical address is used here.

 

The meaning of the parameter movi_init_required is that there is no data description for the moment. The copymovitomem function is defined as follows:

# Define copymovitomem (a, B, c, d, e) (INT (*) (INT, uint, ushort, uint *, INT )) (* (uint *) (tcm_base + 0x8) (a, B, c, d, e ))

This definition actually calls the function pointer at the address tcm_base + 0x8, where the value of tcm_base is 0x0c004000. There is no information to explain what the address is. After bl2 is copied, it will jump to the C language function start_armboot of bl2 to run. The subsequent running process does not need to be analyzed.