Some information about booting ARM Linux
I am trying to understand the details of booting Linux on hand architecture. I have searched a lot on the internet and have figured out some of the details so far, although I feel like every time I read the article it brings in many other new terms and it complicates things. I have two boards with linux, olimex 9261 and beaglebone black. My experience with embedded systems is particularly good, but haven't played too much with linux (other than some user-space programs and char drivers in the kernel).
Here are my questions:
On one board, I have the following uboot output (linux 2.6.30):
bootargs=mem=64M console=ttyS0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2
bootcmd= cp.b 0xC0042000 0x22000000 0x00199954; bootm 0x22000000
The board has 64MB of RAM (mapped to 0x20000000), 512MB nand flash (no match found yet), and 2MB of data (mapped to 0xc0000000).
What I don't understand here:
- Why is there mem = 64 in bootargs? Shouldn't it be listed as ATAG or DTB?
- why is the console passed as an argument when we pass the control to the kernel? Kernel using tty already configured by uboot?
- initrd vs rootfs. This is still not clear to me. I know that initrd can be included in the kernel as a block device or a separate image for which uboot has to pass the address data to the kernel (true?). Can we have a kernel without initrd enabled + another filesystem like jffs2 from which the kernel will run the rest of the drivers? Actually, I cannot understand the complete information about the filesystem used by the kernel at boot. In this setup I have 4 files: uImage, bootstrap, env.bin, and jffs2 filesystem. So there is no initrd. How it works? And how is the process of rooting the filesystem specified in the above downloads? In my opinion, the kernel should first get the jffs2 filesystem and then grab the image found in / dev / mtdblock 1 and mount it. Perhaps my understanding is wrong.Actually this interaction between kernel and filesystem is something that I don't seem to understand. In the above bootcmd, the kernel is copied from nand to sdram, then bootm jumps to it. But how does the kernel find jffs at boot time? I see this output line at boot time: VFS: Installed root (jffs2 filesystem) on device 31: 1.
I found the following in the board's user manual:
WARNING. Due to the error, loading AT91SAM9261 chips from NAND flash is not supported.
...
512MB NAND Flash (seen as a silicon disk in Linux).
- After compiling the kernel, I noticed that System.map does not have all symbols. I have checked vmlinux and it is the same. Does anyone know why? Maybe the compiler is misconfigured?
Thanks a lot Daniel.
source to share
- mem = 64 - I suppose it might be required before the device tree can be loaded. Probably no.
- tty - but how can the kernel know which tty has been configured by the bootloader? There must be some kind of configuration, either passed in, or compiled, or just the default setting.
- initrd (or initramfs) versus nothing - initrd is a very small user-space that can be. enter password for decryption, wait for USB device with rootfs to be connected or whatever. Everything can work without this, just be sure to compile all the necessary modules to boot from rootfs. If I recall correctly, initramfs was introduced as a replacement for initrd a few years ago. This is a CPIO archive packed inside the kernel and this may be what you see when "no initrd"
source to share
Most of your questions can be answered by reading the documentation that comes with the Linux source. Some key files:
- core-parameters.txt
- hand /booting.txt
Please review them as they will have information that is relevant to your version of Linux.
On one board, I have the following uboot output (linux 2.6.30):
Kernel 2.6.30 preconfiguration device trees for ARM.
why is there mem = 64 in bootargs? Shouldn't it be given as ATAG or DTB?
There are two mechanisms. ATAGS is more flexible as it can specify multiple non-contiguous memory banks. The idea is that the boot code can examine the memory and provide it using ATAGS . This is theory. This is often difficult to do, so letting the user specify mem = 64 is much easier to implement. If there are two types of board, one with 64MB and one with 128MB, the user must provide a command line to use the extra memory.
Why is the console passed as an argument when we pass control to the kernel? Kernel using tty already configured by uboot?
Some devices have multiple serial ports. Some kernels may use the "u-boot" port for something else. HDSPA modem, printer, etc. Linux kernel and u-boot consoles may differ. This is a feature. I often use / dev / null as my console. Hardware is often scarce enough to provide an extra serial port. You might be in luck that your hardware people don't consider software free.
initrd vs rootfs.
You can boot directly into the filesystem (rootfs), but all code and mechanisms for finding code must be inside the Linux image. Even if they are (JFFS2 / NAND), you can end up in corrupt root systems as NAND wears out. The first 128MB of NAND is usually of higher quality. You can put Linux here with an initrd that can restore the underlying filesystem. For other boot devices, there may be no direct device boot, and complex decisions can be made into the initrd image. Often times initrd takes much less time to mount, and you can do some things faster. Finally, you can load different modules and then block the loading of the module in the initrd.
You can use rootfs directly. It's easier to implement. Initrd is much more flexible and powerful. You might want to migrate from JFFS2 to Ubi / UbiFS. If you don't have an initrd, then this is almost impossible (at least much harder to implement).
In this setup I have 4 files: uImage, bootstrap, env.bin and jffs2 filesystem. So there is no initrd.
UImage may have initrd installed. It is mounted as a ramdisk and after that switch_root
unmounts (and to the new / final rootfs), then the memory can be freely used. However, there is no initrd information on your command line, so you probably don't have it.
In my understanding, the kernel must first get the jffs2 filesystem and then grab the image found in / dev / mtdblock 1 and mount it. Perhaps my understanding is wrong. Actually this interaction between kernel and filesystem is something that I don't seem to understand. In the above bootcmd, the kernel is copied from nand to sdram, then bootm jumps to it. But how does the kernel find jffs at boot time? I see this output line at boot time: VFS: Installed root (jffs2 filesystem) on device 31: 1.
You have information to find your device; root=/dev/mtdblock1
, and you told him the type of filesystem; rootfstype=jffs2
... The disadvantage is init=/sbin/init
. You can read about this in kernel-parameters.txt for your Linux. After installing JFFS2, the init code looks for a process to start. This is the parent process of everything and it will start executing many different processes. This is usually init , but you can specify init=/bin/sh
and you only have a shell to start with. This can be a good way to develop an initrd image as you can only test scripts with one process.
After compiling the kernel, I noticed that System.map does not have all symbols. I have checked vmlinux and it is the same. Does anyone know why? Maybe the compiler is misconfigured?
System.map is really only external functions and data. It doesn't include every feature. In fact, some functions may not exist due to the inner lining.
WARNING. Due to errors when loading AT91SAM9261 chips from NAND flash memory is not supported.
I am guessing this is a u-boot boot problem.
source to share