0

I'm trying to analyze and understand an embedded system that runs linux.

I'm pretty new to linux boot process, embedded linux etc, so I have to learn a lot but prefer learning by doing. So analyzing a system is the way I try to understand all this. I already got some insight and learnt a lot in just looking at the bootmsg, checking some scripts and provided files (firmware) and trying to understand what's going on by just searching for answers here and elsewhere in the net. This might also be the reason for some wrong expressions I might use, I hope you can understand anyways. Atm I am not able to ask the creator of this system directly, so I hope you might help me out with some answers here.

So the System got a SOC (Marvell Armada-370 88F6707-A1) with some Flash (128 MiB - Hynix NAND (HY27U1G8F2BTR)) and DRAM (512 MB) and seems to load the bootload U-Boot from SPI flash (1MB).

As mentioned above as U-Boot is used as bootloader which then loads some Linux version 3.2.34. I think I already understand quite a bit of the general boot process here, but got some questions depending the provided bootargs.

Following is an excerpt of the printenv command (U-Boot environment)

image_name=uImage
mtdids=nand0=nand0
mtdparts=mtdparts=nand0:8m(kernel),6m(Initrd),-(rootfs)
select0=nand info
load0=nand read.e 0x02000000 0 360000
loadr0=nand read.e 0x04000000 800000 300000
boot=bootm 0x02000000 0x4000000
bootcmd=run beep select0 load0 loadr0 boot || run beep beep beep errled
bootargs=console=ttyS0,115200 root=ubi0:rootfs ubi.mtd=3,2048 initrd=0x12000000 rootfstype=ubifs
beep=beep

I see that they load the kernel and compressed ramdisk content into ram load0=nand read.e 0x02000000 0 360000 and loadr0=nand read.e 0x04000000 800000 300000. The kernel at start looks at 0x04000000 for the ramdisk_image and uncompresses to use the content for initial rootfs. Then the usual process with linuxrc / init begins... at the end the normal file system from nand (here rootfs partition of ubi device 0) is loaded as stated in kernel command line (root=ubi0:rootfs ubi.mtd=3,2048 rootfstype=ubifs). This is what I understood is happening here and might be pretty straight forward.

What I'm wondering now is the following bootargs part initrd=0x12000000. I don't quite get why they provide a different address here when we already let the kernel know about the real of the compressed ramdisk (as a second parameter of bootm). I started the system with and without this parameter and it seems there are no differences.

As in my understanding of reading about that initrd= argument is that it seems to do the same as the second parameter that is already passed to bootm, it tells the kernel where to find an initrd to load the initial rootfs.

Could anyone explain why we here pass two different locations to an initrd to the kernel? Is this just some obsolete stuff that was forgotten to remove or is there a reason for?

Thanks in advance for your help. I hope I haven't missed anything and the question wasn't already answered here somewhere, but I couldn't find anything.

edit-2:
Thanks to @sawdust in the comments I understood better what actually is going on here and saw the importance to add some more information to the question so an answer will be clearer to understand.

Here is a short excerpt of the bootmsg

 > bootm 0x02000000 0x4000000
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   Linux-3.2.34
   Created:      2013-08-15   4:18:54 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3464064 Bytes =  3.3 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 04000000 ...
   Image Name:
   Created:      2013-09-10  10:38:37 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    3030739 Bytes =  2.9 MB
   Load Address: 12000000
   Entry Point:  12000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

I also always missed some information in this part of bootm that might have already gave a hint on what's happening here. And might have in correlation to the presence of same address should have lead to the path of answer.

edit-1: Added some more information about the hardware
edit-2: Added bootmsg for more information

Phela
  • 1
  • 2
  • `So the System got a SOC` Please be more specific. What system? What SOC? What manufacturer? What model? Which revision? Of course, how boot works is _very_ specific to whatever you have there, so you have to specify it. – KamilCuk Dec 04 '21 at 13:25
  • @KamilCuk Provided some more information although I don't think this should matter for that specific question. Most hardware related stuff is abstracted by using the already running bootloader. Only the address space might be related to the specific hardware here. – Phela Dec 04 '21 at 16:28
  • You're conflating the container (ramdisk) with the contents that go into the container. The command line parameter `initrd=...` does specify the starting memory location for the initial ramdisk. This ramdisk will be an empty filesystem. The 2nd argument of the U-Boot `bootm` command is for an archive file (in this case a **tar** file, possibly compressed). This is not a ramdisk or an image of a ramdisk, but rather a file that needs to be un-tarred to extract the files to populate the ramdisk. – sawdust Dec 04 '21 at 19:56
  • @sawdust I think I understand what you are saying. Thanks to that information I just found some important information that I have always missed and should have provided if I would have known about the importance of them. The second parameter of `bootm` specifies the location of a ramdisk image, BUT `bootm` also reads the load and entry point addresses from the header of that special archive file and in my case THIS states exactly the same address as the `initrd=` parameter. `bootm` also provides those parameter to the kernel. Will add those and more later in better formatted way. Thanks a lot. – Phela Dec 05 '21 at 06:58

0 Answers0