Загрузка Linux на платформе ARM

Обсудим на платформах ARM. Из чего строятся такие платформы. Когда мы включаем плату и в системе установлен Linux, запускается последовательность включения платы. Какие еще компоненты необходимы для загрузки Linux на любой платформе ARM?

Описание

Платформа ARM — это плата, основанная на архитектуре ARM. На рынке есть много производителей, которые разрабатывают платформы на основе этой архитектуры. Как правило, платформа ARM состоит из следующих строительных блоков:

1. CPU / SOC: это основной процессор на платформе. Компоненты имеют внутренние компоненты, такие как Cache, SCU и т. Д.
2. Внутренняя s-RAM: это RAM, которая присутствует в SOC. Размер этой памяти ограничен и составит несколько килобайт.
3. Внешняя DDR: это внешняя оперативная память, которая имеет значительный размер по сравнению с внутренней оперативной памятью. Эта память действует как оперативная память для ЦП. Как правило, это несколько ГБ, в зависимости от конструкции системы.
4. Загрузочное устройство: это внешнее постоянное запоминающее устройство, используемое для хранения образов программного обеспечения, необходимых системе для загрузки. Несколько примеров компонентов: загрузчики, образ Linux, корневая файловая система. Эти 3 компонента являются основными компонентами, необходимыми любой системе для загрузки Linux. Примером загрузочных устройств являются EMMC, устройства флэш-памяти NV, SD-карта, USB-накопитель и т. Д. Эти устройства могут использоваться для загрузки только в том случае, если система поддерживает загрузку с этого носителя. Немногие системы имеют несколько вариантов загрузки, которыми можно управлять с помощью ремней или DIP-переключателей. Можно выбрать любой требуемый тип загрузки и запрограммировать образы на загрузочный носитель. Программирование загрузочных образов может быть выполнено с помощью какого-либо внешнего программатора, например, инструмента dediprog.

Образы для загрузки системы

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

Программирование образов на загрузочное устройство

После того, как у нас есть образы, готовые к загрузке на платформе, нам нужно записать / запрограммировать образы на загрузочном устройстве. Там должна быть инструкция, доступная от поставщика, или любой программист HW может быть использован для программирования образов на загрузочное устройство. Примером такого программиста является Dediprog.

Dediprog — это инструмент, который можно использовать для программирования флеш-образа на NV Flash. Это случай режима загрузки Flash. Перемычки или конфигурация необходимы для включения загрузки с флэш-памяти при наличии нескольких загрузочных устройств.

Снимок Дедипрога:

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

Загрузку Linux можно рассматривать в несколько этапов:

1. Фаза загрузочного ПЗУ
2. Загрузка загрузчика Первой ступени
3. Загрузка загрузчика второй ступени, обычно это u-boot.
4. Загрузка Linux
5. Монтирование rootfs и выполнение сценариев инициализации Linux до прихода консоли входа в систему.

Давайте теперь подробно обсудим все эти этапы загрузки.

Фаза загрузочного ПЗУ

На этом этапе нет доступа к внешней DDR, все выполнение должно выполняться во внутренней S-RAM. Как только система включается, код загрузочного ПЗУ инициализирует интерфейс загрузки, а затем загружает загрузчик первой ступени. Когда загрузчик доступен во внутренней ОЗУ и готов к выполнению, управление передается загрузчику первого этапа.

Загрузка загрузчика первого этапа

Сразу после включения платы доступ к внешней оперативной памяти для ЦП отсутствует. Выполнение начинается с вектора сброса. Вектор сброса — это место, откуда ЦП начинает выполнение первых инструкций программирования. На данном этапе доступна только внутренняя оперативная память. Позже инициализируется внешняя DDR, а затем загрузчик второй ступени извлекается с загрузочного носителя и загружается в инициализированную внешнюю DDR, а контроллер передается загрузчику второй ступени, то есть u-boot.

Загрузка загрузчика второго этапа или U-boot

Это минимальное программное обеспечение, необходимое для настройки среды, необходимой ядру Linux перед загрузкой. В среде u-boot включены различные драйверы и аппаратные интерфейсы. Этот загрузчик предоставляет командную строку, и, следовательно, мы можем изменять несколько конфигураций во время выполнения. Основная цель этого этапа — подготовить установку / плату для ядра Linux. На этом этапе образ Linux можно получить из нескольких доступных вариантов. Образ Linux можно загрузить через любой интерфейс из разных интерфейсов. На этом этапе загружается образ ядра Linux и передается управление выполнением загрузчику.

Загрузка Linux

После второго этапа загрузчик скопировал образ Linux на внешний DDR. Он передаст управление выполнением образу Linux. Как только образ Linux начинает загружаться, начинается инициализация всех устройств / периферийных устройств на плате. Он инициализирует всю подсистему, включая все контроллеры и устройства. После того, как на этом этапе инициализированы все драйверы и устройства и ядро ​​Linux работает с максимально возможной производительностью.

После загрузки или инициализации драйверов выполняется поиск устройства rootfs. Расположение устройства Rootfs также можно настроить или изменить в параметрах командной строки Linux. Параметры командной строки для Linux — это переменные среды в среде u-boot, поэтому обновление местоположения устройства rootfs — это всего лишь модификация переменной среды в u-boot. В среде u-boot доступна и другая информация.

Несколько примеров: расположение процесса инициализации, размер памяти, включение devmem, увеличение уровней логирования ядра и т. Д. Некоторые другие варианты переменных среды u-boot доступны для облегчения других пользовательских случаев в u-boot. Например, назначение IP-адреса в u-boot выполняется с помощью переменной окружения.

Монтирование rootfs и выполнение сценариев инициализации Linux:

Устройство Rootfs ищется и монтируется, а затем ищется процесс инициализации в устройстве rootfs. После того, как образ инициализации найден, управление передается процессу инициализации после вызова процесса инициализации. Это первый процесс пользовательского пространства, который начинает выполнение. Как только init получает управление, он инициализирует службы пользовательского пространства, выполняя сценарии инициализации.

Все демоны запускаются, и службы системного уровня запускаются либо при выполнении служб инициализации, представленных в / etc /, либо, если система является системой на основе systemctl, тогда все службы запускаются в соответствии с указаниями, упомянутыми для системы systemctl. После запуска всех служб запускается программа оболочки, которая создает для пользователя приглашение сеанса входа в систему.

Пользователь может использовать эту командную консоль для запроса различных служб из ядра Linux.

Теперь давайте посмотрим журналы загрузки системы Linux, которые продемонстрируют этап загрузки, который мы обсуждали до сих пор. Обратите внимание, что это не полные журналы. Я удалил несколько строк между ними, так как это огромные бревна. Не имеет отношения к теме, поэтому я только что предоставил журналы, относящиеся к нашему обсуждению.

Примечание. Фаза загрузочного ПЗУ не может быть отслежена в журналах, так как UART на этом этапе недоступен.

Booting of the First stage boot loader:
U-Boot SPL 2019.04 (Aug 17 2021 — 18:33:14 +0000)
Trying to boot from RAM

Booting of second stage boot loader or u-boot:
U-Boot 2019.04(Aug 17 2021 — 18:33:14 +0000)
SOC: AST2600-A1
RST: Power On
LPC Mode: SIO:Enable : SuperIO-2e
Eth: MAC0: RMII/NCSI, MAC1: RMII/NCSI, MAC2: RMII/NCSI, MAC3: RMII/NCSI
Model: vendor BMC
DRAM:  already initialized, 1008 MiB (capacity:1024 MiB, VGA:16 MiB), ECC off
PCIE-0: Link down
MMC:   emmc_slot0@100: 0
Loading Environment from SPI Flash… SF: Detected n25q256a with page size 256 Bytes, erase size 4 KiB, total 32 MiB
*** Warning — bad CRC, using default environment

In:    serial@1e784000
Out:   serial@1e784000
Err:   serial@1e784000
Model: vendor BMC
eeprom eth2addr : EA=aa:bb:cc:dd:de:e0
BMC eth2addr=aa:bb:cc:dd:de:e3
Net:   ftgmac100_probe — NCSI detected
eth2: ftgmac@1e670000ftgmac100_probe — NCSI detected

Warning: ftgmac@1e690000 (eth3) using random MAC address — fa:12:fb:ca:bc:ff
, eth3: ftgmac@1e690000
Hit any key to stop autoboot:  2  1  0
## Loading kernel from FIT Image at 20100000 …
Using ‘conf-1’ configuration
Trying ‘kernel-1’ kernel subimage
Description:  Linux kernel
Type:         Kernel Image

.
.
.
.
Compression:  uncompressed
Data Start:   0x2067e1c4
Data Size:    54387 Bytes = 53.1 KiB
Architecture: ARM
Verifying Hash Integrity … OK
Booting using the fdt blob at 0x2067e1c4
Loading Kernel Image … OK
Loading Ramdisk to 8fbe0000, end 8ffffbf0 … OK
Loading Device Tree to 8fbcf000, end 8fbdf472 … OK

Booting Linux:
Starting kernel …

[    0.000000] Booting Linux on physical CPU 0xf00
[    0.000000] Linux version 5.1.3.sdk-v00.05.07 (cienauser@haxv-srathore-2) (gcc version 8.3.0 (Buildroot 2019.05-rc2)) #3 SMP Sun Aug 29 14:19:01 UTC 2021
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: AST2600 A1 EVB
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Reserved memory: created CMA memory pool at 0xbb000000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node video, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0xb7000000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node rvas, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0xb6e00000, size 2 MiB
[    0.000000] OF: reserved mem: initialized node ssp_memory, compatible id shared-dma-pool
[    0.000000] Reserved memory: created DMA memory pool at 0xb6d00000, size 1 MiB
.
.
.
.

[    1.184367] 0x000000000000-0x0000000f0000 : «u-boot»
[    1.191246] 0x0000000f0000-0x000000100000 : «u-boot-env»
[    1.198363] 0x000000100000-0x000002060000 : «fit»
[    1.203661] mtd: partition «fit» extends beyond the end of device «bmc» — size truncated to 0x1f00000
[    1.215347] vendor-smc 1e620000.spi: bus_width 2, Using 50 MHz SPI frequency
[    1.223375] vendor-smc 1e620000.spi: n25q256a (32768 Kbytes)
[    1.229723] vendor-smc 1e620000.spi: CE1 window [ 0x22000000 — 0x24000000 ] 32MB
[    1.237996] vendor-smc 1e620000.spi: CE2 window [ 0x24000000 — 0x30000000 ] 192MB
[    1.246357] vendor-smc 1e620000.spi: read control register: [203c0441]
[    1.316884] vendor-smc 1e630000.spi: bus_width 2, Using 50 MHz SPI frequency
[    1.324821] vendor-smc 1e630000.spi: unrecognized JEDEC id bytes: 00 00 00 00 00 00
[    1.333384] vendor-smc 1e630000.spi: chip 0 does not exist.
.
.
.
[    1.631342] uhci_hcd: USB Universal Host Controller Interface driver
[    1.638622] platform-uhci 1e6b0000.usb: Detected 2 ports from device-tree
[    1.646217] platform-uhci 1e6b0000.usb: Enabled vendor implementation workarounds
[    1.664722] platform-uhci 1e6b0000.usb: Generic UHCI Host Controller
[    1.671844] platform-uhci 1e6b0000.usb: new USB bus registered, assigned bus number 2
[    1.680671] platform-uhci 1e6b0000.usb: irq 42, io mem 0x1e6b0000
[    1.687977] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.01
[    1.697237] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.705311] usb usb2: Product: Generic UHCI Host Controller
[    1.711542] usb usb2: Manufacturer: Linux 5.1.3.sdk-v00.05.07 uhci_hcd
[    1.718824] usb usb2: SerialNumber: 1e6b0000.usb
[    1.724589] hub 2—0:1.0: USB hub found
[    1.728830] hub 2—0:1.0: 2 ports detected
[    1.734689] usbcore: registered new interface driver usb-storage
[    1.753347] vendor_vhub 1e6a0000.usb-vhub: Initialized virtual hub in USB2 mode
[    1.762327] i2c /dev entries driver
[    1.767491] i2c_new_vendor 1e78a080.i2c-bus: NEW-I2C: i2c-bus [0]: adapter [100 khz] mode [2]
.
.
.
[    2.960181] Freeing unused kernel memory: 1024K
[    2.970760] mmcblk0: mmc0:0001 R1J57L 27.5 GiB
[    2.976119] mmcblk0boot0: mmc0:0001 R1J57L partition 1 16.0 MiB
[    2.983067] mmcblk0boot1: mmc0:0001 R1J57L partition 2 16.0 MiB
[    2.989980] mmcblk0rpmb: mmc0:0001 R1J57L partition 3 128 KiB, chardev (246:0)
[    2.999275]  mmcblk0: p1
[    3.012035] Checked W+X mappings: passed, no W+X pages found

Mounting of rootfs and execution of Linux init scripts
[    3.018367] Run /sbin/init as init process

Заключение

Мы подробно рассмотрели полный процесс загрузки Linux с примерами журналов. Мы также обсудили различные строительные блоки загрузки Linux. Также были обсуждены некоторые другие предварительные условия, необходимые для загрузки Linux. В загрузку Linux на любой процессорной плате ARM входят различные этапы, все этапы подробно обсуждались и сопоставлены с примерами журналов загрузки. Этого обсуждения достаточно, чтобы дать общее представление о загрузке Linux в системах ARM.