method and analysis of modifying start-up parameters in U-boot start-up stage

Author: Wai Bu

This is not a complicated thing to start with, but to be simple and clear, I really don't know how to organize it. After all, words are different from sound language. I hope the simple things don't make me talk too complicated.

ARM board system files typically have three--bootloader (uboot), Kernel (uimage), and Root file systems (ROOTFS). After power on the arm board, start in order of Uboot->kernel->rootfs. Since there are a variety of storage media on the board, three files can be placed on any media that can be stored, resulting in a variety of file startup methods. This article discusses that the above three files correspond to different boot configurations of the storage location.

The General Development Board will have Flash (Nor or NAND), MMC,EMMC,SD card and so on. System files can be burned in any one of these, so it will not be able to start. In the development process, sometimes need to change the kernel, or modify the application, if each time after the modification of the storage media on the board, it will be more troublesome. Therefore, to facilitate debugging, Uimage and Rootfs can also boot from the network, that is, NFS boot. However, the uboot can only be booted from the on-board media.

The start-up process is actually a file that will start before it is copied from the storage location to the memory space and then run in memory. So the so-called different positions start, that is, copy from different locations.

Let's take the Development board as an example to introduce the process methods of three files starting from different locations. I use EMMC and two SD cards on the Development Board. We follow the boot order, which is described in turn.

The first is the Uboot boot. Uboot is the first boot in three system files, and the copy work is determined by the firmware in the CPU. The firmware supports copying Uboot from several locations, which can be stored in several locations. As for each boot specific from where to start, the hardware dial switch determines that the corresponding dial code in the Development Board manual can be found. Before starting, copy the Uboot binaries to the corresponding media. There are two different methods of burning, as follows:

1. uboot binary file Copy to eMMC, is through the chip vendor's download tool software burning write completed;

2. Copy to SD card is done under Linux, via DD command.

After the burn is completed, dial to the corresponding location to start the uboot.

The kernel file (uimange) and the Rootfs start are then introduced. As mentioned above, uimage and Rootfs can boot from the eMMC, SD card, or NFS copy to the kernel. The specific boot location is determined by the contents of the parameters in the Uboot. The contents of these parameters have a dead value in Uboot, or you can change the starting position by entering the command input interface during the Uboot startup phase and modifying the values of these parameters. (Author: Wai BU)

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 the command has been entered, restart the board to start the system according to the parameters set out in the above command.

Let's analyze the meaning of the start-up parameters of the uboot stage input so that the reader can modify the relevant content so that the board can be started from the position it needs.

First, several commands are introduced. is the setenv command that you see above, which is used to set or delete an environment variable. When the setenv is followed by only one parameter, the argument must be an existing variable name, the variable is deleted when the input command returns, and when there are more than one argument after the setenv, the first parameter after that is used as the environment variable, and the other parameter as the value or content of the variable.

The second command to interpret is MMC. Enter MMC in the Uboot command interface, and you can see multiple uses of it:

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 some of these uses:

MMC Read addr blk# cnt is used to read the contents of the hard disk (EMMC/SD) into memory. Where addr refers to the target location starting address in memory, blk# refers to the block number of the original storage block of the copied content, CNT refers to the number of blocks to be copied. Generally, the size of each block is 512byte.

MMC dev [Dev] [part]-Show or set current MMC device [partition] Displays or sets the device. The command MMC Dev is the current device that shows which Device;mmc dev #意为设置 "#" is currently.

The third command, saveenv, is the meaning of saving environment variables. When the environment variable is set, it is saved with the instruction, and the next reboot is started with the last saved setting, so you don't have to set it again.

Finally, the Run command is more obvious, "run" meaning. It is generally added to a variable that contains the executable command.

Let's try to explain the variables. In the above parameter setting command, Parameters Bootargs and Bootcmd are uboot parameters, their functions and names cannot be changed, others are user-defined variables and can change their names. Where Bootargs represents the parameters passed to the kernel by Uboot, Bootcmd is the sequence of commands that the system automatically loads when Uboot starts. If you set the startup parameters and want the system to automatically start the next time, you must set the copy and boot kernel statements to the value of Bootcmd, or the next boot cannot automatically load and start the kernel. (The author Wai Bu)

After introducing the important commands and the UBOOT environment variables, let's take a look at the startup parameter Settings command line above:

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 command and parameter explanation, do some variable substitution, you can see that only two things are done here, one is to set the environment variable Bootargs value, and the second is to set the value of Bootcmd, and save. Where the value of Bootargs is passed to the kernel, used to initialize some devices and start rootfs;bootcmd values used to start the kernel, which is the sequence of commands that are automatically loaded. (the last sentence of run Bootcmd is the start, no longer the Setup command.) ）

The reason for using so many custom variables for these commands is that some debug tools command line input cannot be too long, so use intermediate custom variables to shorten the number of command lines for one-time input. We replace unnecessary custom variables and then analyze their contents.

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 you replace the custom variable, you can see that the parameter setting is actually doing the work of assigning values to the two system environment variables. The following specific analysis of the variables worth the content.

The assignment to Bootargs is related to Rootfs startup. Content is a large string, separated by a space between items, or a number of items separated by spaces as multiple parameters.

The first item is console=ttymxc0,115200 is to select the operator station and set the baud rate.

The middle of several items Root=/dev/mmcblk0p1 rootwait rw, is the ROOTFS boot location setting ROOT=/DEV/MMCBLK0P1 refers to the mmcblk0 partition mounted P1 from the device rootfs. So what device is Mmcblk0? Because the file system is mounted after the kernel is started, the kernel will install Linux allocation method to assign the name to the existing device, so the device can be differentiated. I use the Development Board, eMMC that is the MMCBLK0 device, SD installation mount sequence in turn back row. If more than one card slot is plugged into the SD card before the system starts, the system will install the interface number of the SD card slot and assign the device name in succession. For example, two SD card slots, Slot2 and SLOT3 (corresponding bus number), only one SD start, regardless of which slot is MMCBLK1, but two are inserted in the SD, in Slot2 mmcblk1,slot3 is MMCBLK2. Ok, so now, from which device to mount the ROOTFS is already clear. The following two parameters, RW is the declaration of the start permission, that is, read-write mode, rootwait is waiting for the device/DEV/MMCBLK0P1 device is ready to attempt to mount Rootfs. Without this parameter, the Linux kernel may attempt to mount the Rootfs when the storage device is not ready, and if it does not, the boot fails.

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 devices and networks, for the embedded system does not need video equipment can not set this, IP can also be set separately.

Then is the second environment variable bootcmd settings, 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, separated by semicolons.

Following the instructions for MMC commands above, the first command MMC Dev 1, which means that the dev 1 is set to the current device. This is where the uimage start (copy). On the development Board I'm using, dev 1 refers to the SD card placed in the card slot Slot2. Because the Linux kernel does not start here, the device name cannot be determined according to the Linux allocation method. On the development Board I'm using, the Dev 2 is the SD card placed in the card slot slot3, and the Dev3 is eMMC. You can change the kernel boot location by modifying the sentence accordingly.

MMC read 0x10800000 0x800 0x2000 This sentence should be understood, will be on the storage device from the block number 0x800 the beginning of the 0x2000 storage block of things copied to the memory 0x10800000 the beginning of the space.

Bootm is also the uboot command for loading an operating system image that uboot can recognize.

Above, has been finished in the Uboot stage to modify the startup parameters, and then change the start position of the command meaning, the reader can correspond to the changes, the system files from the corresponding location to start. In addition the NFS portion, which has the time in addition enters.

This is a personal summary and it is an honor to be there for you. --the author's compensation