Originally, the start-up section is not a complicated thing, but if I want to explain it clearly, I really don't know how to organize it. After all, there is a difference between written and spoken language. I hope the simple things don't make me talk too complicated!
There are generally three system files on the Arm board - bootloader (uboot), kernel (uImage) and root file system (rootfs). After the arm board is powered on, start it in the order of uboot->kernel->rootfs. Since there are multiple storage media on the development board, the three files can be placed on any media that can be stored, thus resulting in multiple startup methods for the files. This article will discuss that the above three files correspond to different startup configurations in different storage locations.
Generally, there will be flash (Nor or NAND), mmc, emmc, sd card, etc. on the development board. System files can be programmed on any of them, so it corresponds to unreasonable startups. In the development process, it is often necessary to modify the kernel or modify the application program. It will be troublesome to re-program the storage medium on the board after each modification. Therefore, to facilitate debugging, uImage and rootfs can also be booted from the network, that is, nfs boot. But uboot can only boot from onboard media.
The startup process is actually to first copy the file to be started from the storage location to the memory space, and then run it in the memory. Therefore, the so-called different locations start, that is, copy from different locations.
Let's take the startup of the development board as an example to introduce the process and method of starting the three files from different locations. The development board I am using has emmc and two sd cards. We will introduce them in order of startup.
The first is to start uboot. Uboot is the first to start among the three system files, and its copying work is determined by the firmware in the cpu. The firmware supports copying uboot from several locations, and it can be stored in several locations. As for where to start each startup, it is determined by the hardware DIP switch, and the corresponding DIP code can be found in the development board manual. Before starting, copy the uboot binary file to the corresponding medium. There are two different ways to program, as follows:
1. The uboot binary file is copied to emmc, which is done by the download tool software of the chip supplier;
2. Copying to the SD card is done under linux through the dd command.
After the programming is completed, turn the boot dial to the corresponding position to start uboot.
Then introduce the kernel file (uImange) and the startup of rootfs. As mentioned above, uImage and rootfs can be copied to kernel boot from emmc, sd card or nfs. The specific startup location is determined by the content passed by the parameters in uboot. The contents of these parameters have hard-coded values in uboot, and you can also enter the command input interface during the uboot startup phase, and modify the values of these parameters to change the startup position. (Author: Wai Su)
After entering the uboot command interface, enter the following command, modify the startup parameters, and restart.
setenv loadaddr 0x10800000
setenv bootargs_base 'setenv bootargsconsole=ttymxc0,115200'
setenv bootargs_mmc 'setenv bootargs${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 ip=dhcp'
setenv bootcmd_mmc 'run bootargs_basebootargs_mmc;mmc dev 1;mmc read ${loadaddr} 0x800 0x2000;bootm'
setenv bootcmd 'run bootcmd_mmc'
saveenv
run bootcmd
After entering the command, restart the development board, and the system can be started according to the parameters set in the above command.
Let's analyze the meaning of the boot parameters entered in the uboot stage, so that the readers can modify the relevant content and let the board start from the position they need.
First introduce a few commands. It is the setenv command seen most above, which is used to set or delete an environment variable. When setenv is followed by only one parameter, the parameter must be an existing variable name, and the variable will be deleted after entering the command and press Enter; when setenv is followed by multiple parameters, the first parameter will be used as an environment variable, followed by Other parameters as the value or content of the variable.
The second command mmc to explain. Type mmc in the uboot command interface, press Enter, and you can see its multiple usages:
Usage:
mmc read addr blk# cnt
mmc write addr blk# cnt
mmc erase blk# cnt
mmc rescan
mmc part - lists available partition on currentmmc device
mmc dev [dev] [part] - show or set current mmcdevice [partition]
mmc bootpart [dev] [part] - show or set bootpartition
mmc list - lists available devices
Explain a few of the usages:
mmc read addr blk# cnt is used to read the contents of the hard disk (emmc/sd) into the memory. Where addr refers to the starting address of the target location in the memory, blk# refers to the block number of the starting storage block of the copied content, and cnt refers to the number of blocks to be copied. Generally, the size of each block is 512 bytes.
mmc dev [dev] [part] - show or set current mmc device [partition] Show or set the current device. The command mmc dev is to display which device is currently; mmc dev # means to set "#" as the current device.
The third command saveenv means to save environment variables. After the environment variable is set, use this command to save, and the next restart will start according to the last saved setting, so there is no need to set it again.
Finally, the run command is more obvious, the meaning of "run". Usually added before a variable whose content is an executable command.
Let me explain the variables again. In the above parameter setting command, the parameters bootargs and bootcmd are the parameters of uboot, and their functions and names cannot be changed. Others are user-defined variables and their names can be changed. Among them, bootargs represents the parameters passed to the kernel by uboot; bootcmd is the command sequence automatically loaded by the system when uboot starts. If after setting the startup parameters, you want the system to start automatically according to the setting method next time, you must set the statement of copying and starting the kernel to the value of bootcmd, otherwise the kernel cannot be automatically loaded and started at the next startup. (Author's supplement)
After introducing the important commands and uboot environment variables, let's look at the above startup parameter setting command line:
setenv loadaddr 0x10800000
setenv bootargs_base 'setenv bootargsconsole=ttymxc0,115200'
setenv bootargs_mmc 'setenv bootargs${bootargs} root=/dev/mmcblk0p1 rootwait rwvideo=mxcfb1:dev=ldb,LDB-XGA,if=RGB666video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 ip=dhcp'
setenv bootcmd_mmc 'run bootargs_basebootargs_mmc;mmc dev 1;mmc read ${loadaddr} 0x800 0x2000;bootm'
setenv bootcmd 'run bootcmd_mmc'
saveenv
run bootcmd
According to the above explanation of commands and parameters, after doing some variable substitutions, you can see that there are only two things done here, one is to set the value of the environment variable bootargs, and the other is to set the value of bootcmd and save it. The value of bootargs is passed to the kernel to initialize some devices and start rootfs; the value of bootcmd is used to start the kernel, that is, the automatically loaded command sequence. (The last sentence of run bootcmd is to start, it is no longer a setting command.)
The reason why so many custom variables are used in the above commands is that the command line input of some debugging tools cannot be too long, so the intermediate custom variables are used to shorten the length of the command line input at one time. We replace unnecessary custom variables and analyze their content.
setenv bootargs console=ttymxc0,115200root=/dev/mmcblk0p1 rootwait rw video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24ip=dhcp
setenv bootcmd 'mmc dev 1;mmc read0x10800000 0x800 0x2000;bootm'
saveenv
run bootcmd
After replacing the custom variables, you can see that the parameter setting is actually the work of assigning two system environment variables. The following is a detailed analysis of the content of each variable.
The assignment to bootargs is related to rootfs startup. The content is a large string, and different items are separated by spaces, and multiple items separated by spaces can also be regarded as multiple parameters.
The first item is console=ttymxc0, 115200 is to select the console and set the baud rate.
The middle items root=/dev/mmcblk0p1 rootwait rw is to set root=/dev/mmcblk0p1 to the rootfs startup location, which means to mount rootfs from the p1 partition of the device mmcblk0. So which device is mmcblk0? Since the file system is mounted after the kernel is started, and the Linux distribution method will be installed after the kernel is started to assign names to existing devices, so the devices can be distinguished accordingly. On the development board I am using, emmc is the mmcblk0 device, and the sd installation and mounting sequence are in the rear. If SD cards are inserted into multiple card slots before the system is started, the system will assign the device name number in turn by the interface number where the SD card slot is installed. For example, two sd card slots, slot2 and slot3 (corresponding to the bus number), start with only one sd, no matter which slot is mmcblk1; but when both are inserted into sd, the one in slot2 is mmcblk1 and the one in slot3 It is mmcblk2. Ok, so far, it is clear which device to mount rootfs from. The last two parameters, rw is to declare the startup permission, that is, to start in read-write mode; rootwait means to wait for the device /dev/mmcblk0p1 to be ready before trying to mount the rootfs. Without this parameter, the Linux kernel may try to mount the rootfs before the storage device is ready when it starts up. At this time, the mount must fail, and then the startup will fail.
The last few parameters, video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 ip=dhcp, are to do some device initialization, mainly for video Device and network, for embedded systems that do not need video equipment, this item can be set, and ip can also be set separately.
Then there is the setting of the second environment variable bootcmd, which is mainly related to kernel startup.
setenv bootcmd 'mmc dev 1;mmc read0x10800000 0x800 0x2000;bootm'
Set the bootcmd content as a sequence of commands, surrounded by single quotes, and separated by semicolons.
According to the explanation of the mmc command above, the first command mmc dev 1 means to set dev 1 as the current device. This is where uImage is launched (copied). On the development board I use, dev 1 refers to the sd card placed in slot 2 of the card slot. Since the linux kernel is not started, the device name cannot be determined according to the linux allocation method. On the development board I use, dev 2 is the sd card placed in slot 3 of the card slot, and dev3 is emmc. Modify this sentence accordingly to change the kernel boot location.
You should understand the meaning of mmc read 0x10800000 0x800 0x2000, that is, copy the 0x2000 storage blocks starting from block number 0x800 on the storage device to the space starting from 0x10800000 in memory.
bootm is also the uboot command, which is used to load an operating system image that uboot can recognize.
Above, the meaning of the command to modify the startup parameters in the uboot phase and then change the startup location has been discussed. The reader can modify it accordingly, and each file of the system is started from the corresponding location. In addition, the nfs part has time to enter.
This is only a personal summary, it is an honor to be helpful to you! - Author's supplement