This is my uboot environment variable setting. Under this setting, I can run the initram kernel (download from memory to nandflash and then run), but when running the nfs root file system, I keep getting various errors. After looking up a lot of information, I guess there is something wrong with the parameters that uboot passes to the linux kernel, that is, there is something wrong with the bootargs setting.
#printenv
bootargs=noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0,115200 rootfstype=yaffs2 rw mem=64M
bootcmd=nand read 0x32000000 0x60000 0x300000; bootm 0x32000000
bootdelay=3
baudrate=115200
ethaddr=08:00:3e:26:0a:5b
ipaddr=192.168.1.110
serverip=192.168.1.100
netmask=2 55.255.255.0
stdin=serial
stdout=serial
stderr=serialethact
=dm9000
#setenv ...
#saveenv ...
#bdinfo can view machine code and other information
So after checking the information, I started to set the bootargs parameters:
In order to facilitate program testing and other tasks, the use of the nfs root file system can complete the program testing work without burning the root file system to the flash, so set bootargs to enable it to support nfs root file system startup.
#setenv bootargs 'root=/dev/nfs rw nfsroot=10.103.4.216:/nfsroot/rootfs ip=10.103.4.211 console=ttySAC0'
#saveenv
#tftp 31000000 uImage
#bootm 31000000
The startup information is as follows:
…
s3c2440-sdi s3c2440-sdi: running at 0kHz (requested: 0kHz).
s3c2440
-sdi s3c2440-sdi: running at 198kHz (requested: 198kHz).
s3c2440- sdi s3c2440-sdi: running at 198kHz (requested: 198kHz).
s3c2440-sdi s3c2440-sdi: powered down.
eth0: link down
IP-Config: Guessing netmask 255.0.0.0
IP-Config: Complete:
device=eth0, addr=10.103 .4.211, mask=255.0.0.0, gw=255.255.255.255,
host=10.103.4.211, domain=, nis-domain=(none),
bootserver=255.255.255.255, rootserver=10.103.4.216, rootpath=
Looking up port of RPC 100003/ 2 on 10.103.4.216
eth0: link up, 10Mbps, half-duplex, lpa 0x0021
Looking up port of RPC 100005/1 on 10.103.4.216
VFS: Mounted root (nfs filesystem) on device 0:11.
Freeing init memory: 128K
Processing /etc/profile... Done
#
Finally, the kernel started normally and the nfs root file system was successfully mounted (the initram root file system burned into nandflash could not start normally at this time, and it was necessary to change back to the original settings above). The environment variables at this time are as follows:
[u-boot@lhc]#printenv
bootdelay=3
baudrate=115200
netmask=255.255.255.0
ethact=dm9000
ethaddr=00:01:02:03:04:05
ipaddr=10.103.4.211
serverip=10.103.4.216
bootcmd=nand read 31000000 200000 600000;bootm 31000000
bootargs=root=/dev/nfs rw nfsroot=10.103.4.216:/nfsroot/rootfs ip=10.103.4.211 console=ttySAC0
stdin=serial
stdout=serial
stderr=serial
Environment size: 324/131068 bytes
*************************************************** *************************************************** *************************************************** **********************************************
The following content is online information
*************************************************** *************************************************** *************************************************** **********************************************
The u-boot has been compiled, but it is not so simple to use it. The u-boot environment variables are often set incorrectly, resulting in kernel startup failure.
The u-boot environment variables are the key to using u-boot. They can be defined by you, but some of them are commonly used and are conventional. Some are defined by u-boot itself. Changing these names will cause errors. The following table lists some commonly used environment variables:
Environment variables |
describe |
bootdelay |
The number of seconds to wait before executing an automatic start |
baudrate |
The baud rate of the serial console |
netmask |
Netmask of the Ethernet interface |
ethaddr |
Ethernet card physical address |
bootfile |
Default download file |
bootargs |
Boot parameters passed to the kernel |
bootcmd |
Commands executed at autostart |
serverip |
Server IP address |
ipaddr |
Local IP address |
stdin |
Standard input device |
stdout |
Standard output device |
stderr |
Standard error facility |
The above are just some of the most basic environment variables. Please note that there are no environment variables in the board originally. u-boot will have some basic environment variables by default. After you execute saveenv, the environment variables will be saved to flash for the first time. After that, your modification and saving of environment variables are based on the operation of the environment variables saved in flash.
There are two U-boot environment variables worth noting: bootcmd and bootargs.
* bootcmd
As mentioned earlier, bootcmd is a set of commands that are executed by default during automatic startup. Therefore, you can define various different configurations and parameter settings for different environments in the current environment, and then set bootcmd to the parameters that you often use.
* bootargs
Bootargs is the most important environment variable. It can even be said that the entire environment variable is set around bootargs. There are many types of bootargs. We usually only use a few of them. If you are interested, you can read this article for a complete description: http://blog.chinaunix.net/u2/79570/showart_1675071.html. Bootargs is very flexible. Different combinations of kernel and file system will have different settings. You can even write it directly into the kernel without setting bootargs (you can do this in the kernel configuration options). These reasons lead to the difficulty in using bootargs.
The following introduces the commonly used parameters of bootargs. There are many types of bootargs, and with the development of the kernel, some new parameters will appear, making the settings more flexible and diverse.
A. root
Used to specify the location of rootfs. Common situations are:
root=/dev/ram rw
root=/dev/ram0 rw
Please note that the above two settings are universal. I have tested that even root=/dev/ram1 rw and root=/dev/ram2 rw are also possible. Some people on the Internet say that in some cases it is not universal, that is, it must be set to ram or ram0, but I have not encountered it yet and further confirmation is needed. If it doesn't work, you can try them one by one.
root=/dev/mtdx rw
root=/dev/mtdblockx rw
root=/dev/mtdblock/x rw
root=31:0x
The above are universal in certain cases. Of course, this depends on whether your current system supports it. However, mtd is a character device, and mtdblock is a block device. Sometimes you have to try them one by one to see if the current system supports the above. However, root=/dev/mtdblockx rw is more universal. In addition, if you can specify the device name directly, then you can also use the device number of this device.
root=/dev/nfs
This command is used when the file system is based on nfs. Of course, after specifying root=/dev/nfs, you also need to specify nfsroot=serverip:nfs_dir, which indicates the directory on which host the file system is located.
B. rootfstype
This option needs to be used together with root. Generally, if the root file system is ext2, it doesn't matter whether this option is used or not. However, if it is jffs2, squashfs, etc., you need rootfstype to specify the type of file system, otherwise the root partition will not be mounted.
C. console
console=tty
console=ttyS
console=ttySAC
I was conslve = ttySAC0
D. mem
mem=xxM specifies the memory size, which is not required
E. ramdisk_size
ramdisk=xxxxx Not recommended
ramdisk_size=xxxxx recommended
The above two can tell the ramdisk driver the size of the created ramdisk. The default size is 4M (8M by default for s390). You can check Documentation/ramdisk.txt to find the relevant description. However, ramdisk=xxxxx is no longer mentioned in the new version of the kernel and is not recommended.
F. initrd, noinitrd
When you do not use ramdisk to boot the system, you need to use the noinitrd parameter, but if you use it, you need to specify initrd=r_addr,size, where r_addr indicates the location of initrd in memory and size indicates the size of initrd.
G. init
init specifies the first script that runs after the kernel is started. Usually, init=/linuxrc or init=/etc/preinit. The content of preinit usually creates console, null device nodes, runs init program, mounts some file systems, etc. Please note that many beginners think that init=/linuxrc is a fixed way of writing. In fact, /linuxrc refers to the linuxrc script under the / directory, which is usually just a link.
H. mtdparts
mtdparts=fc000000.nor_flash:1920k(linux),128k(fdt),20M(ramdisk),4M(jffs2),38272k(user),256k(env),384k(uboot)
For this parameter to work, the kernel's mtd driver must be supported, that is, when configuring the kernel, you need to select Device Drivers ---> Memory Technology Device (MTD) support ---> Command line partition table parsing.
The format of mtdparts is as follows:
Previous article:S3C2440 FCLK, HCLK, PCLK configuration
Next article:S3C6410 LCD Overlay Test Program
Recommended ReadingLatest update time:2024-11-23 08:01
- Naxin Micro and Xinxian jointly launched the NS800RT series of real-time control MCUs
- How to learn embedded systems based on ARM platform
- Summary of jffs2_scan_eraseblock issues
- Application of SPCOMM Control in Serial Communication of Delphi7.0
- Using TComm component to realize serial communication in Delphi environment
- Bar chart code for embedded development practices
- Embedded Development Learning (10)
- Embedded Development Learning (8)
- Embedded Development Learning (6)
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
- Intel promotes AI with multi-dimensional efforts in technology, application, and ecology
- ChinaJoy Qualcomm Snapdragon Theme Pavilion takes you to experience the new changes in digital entertainment in the 5G era
- Infineon's latest generation IGBT technology platform enables precise control of speed and position
- Two test methods for LED lighting life
- Don't Let Lightning Induced Surges Scare You
- Application of brushless motor controller ML4425/4426
- Easy identification of LED power supply quality
- World's first integrated photovoltaic solar system completed in Israel
- Sliding window mean filter for avr microcontroller AD conversion
- What does call mean in the detailed explanation of ABB robot programming instructions?
- STMicroelectronics discloses its 2027-2028 financial model and path to achieve its 2030 goals
- 2024 China Automotive Charging and Battery Swapping Ecosystem Conference held in Taiyuan
- State-owned enterprises team up to invest in solid-state battery giant
- The evolution of electronic and electrical architecture is accelerating
- The first! National Automotive Chip Quality Inspection Center established
- BYD releases self-developed automotive chip using 4nm process, with a running score of up to 1.15 million
- GEODNET launches GEO-PULSE, a car GPS navigation device
- Should Chinese car companies develop their own high-computing chips?
- Infineon and Siemens combine embedded automotive software platform with microcontrollers to provide the necessary functions for next-generation SDVs
- Continental launches invisible biometric sensor display to monitor passengers' vital signs
- 【Application】How to better simplify industrial site acquisition control?
- Common overvoltage protection devices
- Application analysis of CC1310 low power consumption advantage
- I am currently using powerSTEP01 to drive a 86mm stepper motor. Does anyone have a driver for this chip?
- [AT-START-F403A Review] Part 2: Environment setup is very simple
- The structure and grinding of fully automatic soybean milk machine
- Introduction to low voltage NAND flash
- Various secondary circuit diagrams and their explanations
- Input DC/DC controller drives N-channel MOSFET and can provide up to 20A current
- Latching current sink responds to narrow trigger pulses