Поймите, очевидно, дублированный initrd встроенной системы

#linux #embedded-linux #boot #u-boot #initrd

#линукс #встроенный-linux #ботинок #u-образный ботинок #initrd

Вопрос:

Я пытаюсь проанализировать и понять встроенную систему, работающую под управлением Linux.

Я довольно новичок в процессе загрузки Linux, встроенном linux и т. Д., Поэтому мне приходится многому учиться, но я предпочитаю учиться на практике. Поэтому анализ системы-это способ, которым я пытаюсь все это понять. Я уже получил некоторое представление и многому научился, просто взглянув на bootmsg, проверив некоторые сценарии и предоставленные файлы (прошивку) и пытаясь понять, что происходит, просто ища ответы здесь и в других местах в сети. Это также может быть причиной некоторых неправильных выражений, которые я мог бы использовать, надеюсь, вы все равно поймете. Банкомат Я не могу напрямую спросить создателя этой системы, поэтому я надеюсь, что вы могли бы помочь мне с некоторыми ответами здесь.

Таким образом, система получила SOC (Marvell Armada-370 88F6707-A1) с некоторой вспышкой (128 Мбайт — Hynix NAND (HY27U1G8F2BTR)) и DRAM (512 Мбайт) и, похоже, загружает загрузочную загрузку с флэш-памяти SPI (1 Мбайт).

Как упоминалось выше, поскольку U-Boot используется в качестве загрузчика, который затем загружает некоторые Linux version 3.2.34. , я думаю, что уже довольно хорошо понимаю общий процесс загрузки здесь, но у меня есть некоторые вопросы в зависимости от предоставленного bootargs .

Ниже приводится выдержка из printenv команды (среда U-загрузки)

 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  

Я вижу, что они загружают ядро и сжимают содержимое ramdisk в оперативную load0=nand read.e 0x02000000 0 360000 память и loadr0=nand read.e 0x04000000 800000 300000 . Ядро при запуске 0x04000000 ищет изображение ramdisk_ и распаковывает его, чтобы использовать содержимое для начальных корневых файлов. Затем начинается обычный процесс с linuxrc / init … в конце загружается обычная файловая система из nand (здесь раздел rootfs устройства ubi 0), как указано в командной строке ядра ( root=ubi0:rootfs ubi.mtd=3,2048 rootfstype=ubifs ). Это то, что, как я понял, происходит здесь, и может быть довольно прямолинейным.

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:
Благодаря @sawdust в комментариях я лучше понял, что на самом деле здесь происходит, и увидел важность добавления дополнительной информации к вопросу, чтобы ответ был понятнее для понимания.

Вот краткий отрывок из bootmsg

 gt; 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.  

Я также всегда пропускал некоторую информацию в этой части bootm , которая, возможно, уже давала намек на то, что здесь происходит. И, возможно, в связи с наличием одного и того же адреса должен был привести к пути ответа.


правка-1: Добавлена дополнительная информация об оборудовании
правка-2: Добавлена bootmsg дополнительная информация

Комментарии:

1. So the System got a SOC Пожалуйста, будьте более конкретны. Какая система? Какой СОК? Какой производитель? Какая модель? Какая редакция? Конечно, то, как работает загрузка, очень специфично для того, что у вас там есть, поэтому вы должны это указать.

2. @KamilCuk Предоставил дополнительную информацию, хотя я не думаю, что это должно иметь значение для этого конкретного вопроса. Большинство материалов, связанных с оборудованием, абстрагируется с помощью уже запущенного загрузчика. Только адресное пространство может быть связано с конкретным оборудованием здесь.

3. Вы объединяете контейнер (диск оперативной памяти) с содержимым, которое помещается в контейнер. Параметр командной строки initrd=... действительно указывает начальную ячейку памяти для начального диска оперативной памяти. Этот диск оперативной памяти будет пустой файловой системой. 2-й аргумент команды U- bootm Boot предназначен для архивного файла (в данном случае файла tar , возможно, сжатого). Это не диск оперативной памяти или изображение диска оперативной памяти, а скорее файл, который необходимо удалить, чтобы извлечь файлы для заполнения диска оперативной памяти.

4. @опилки Я думаю, что понимаю, о чем ты говоришь. Благодаря этой информации я только что нашел некоторые важные сведения, которые я всегда пропускал и должен был предоставить, если бы знал о их важности. Второй параметр bootm указывает местоположение образа диска оперативной памяти, но bootm также считывает адреса точек загрузки и входа из заголовка этого специального архивного файла, и в моем случае это указывает точно такой же адрес, initrd= что и параметр. bootm также предоставляет эти параметры ядру. Добавлю их и многое другое позже в лучшем формате. Большое спасибо.