Предполагая, что вы не можете напрямую загрузиться в систему Linux, как вы делаете начальную загрузку?


0

Каковы действительные шаги, если предположить, что у вас был набор заголовочных файлов c, которые описывали устройства отображения памяти в вашей системе, чтобы сделать начальное работающее ядро? Я знаю, что все просто загружаются с живого CD / USB-накопителя и т. Д., Но как получился первый загрузчик?

РЕДАКТИРОВАТЬ: я должен отметить, что я действительно говорю об устройствах ARM, я получаю основы загрузки через BIOS на типичной машине, но допустим, мы говорим о пользовательском устройстве?


BIOS - это то, что определяет конкретное устройство для загрузочного кода, а загрузочный код (загрузчик) - это то, что загружает ОС, которая затем заботится обо всем остальном. BIOS «знает», где искать из-за отраслевых стандартов. Пользовательское устройство будет либо соответствовать отраслевым стандартам, либо иметь собственный BIOS, который определяет собственный процесс загрузки и где искать загрузочный код. Вы спрашиваете, как сделать BIOS, загрузчик или ядро?
txtechhelp

Ну, на самом деле я работаю с FPGA серии Zynq 7000. БИОСа нет, и я уже прочитал немного больше, у него есть основной загрузчик, который ожидает найти перепрошитый загрузчик первой стадии, который загружает загрузчик второй стадии в драм и выполняет его. Хитрость здесь в том, чтобы создать этот FSBL и иметь достаточно информации для загрузки кросс-скомпилированного ядра.
MrMowgli

Ответы:


1

как появился первый загрузчик?

Сборка (написание и кросс-компиляция) программы начальной загрузки не так сложна, как кажется.

Я должен отметить, что я действительно говорю об устройствах ARM, я получаю основы загрузки через BIOS на типичной машине, но допустим, мы говорим о специальном устройстве?

BIOS, на который вы ссылаетесь, по сути является соглашением для ПК. (CP / M также имел BIOS, но он не обязательно находится в энергонезависимой памяти.) Процессоры ARM обычно не имеют или не используют BIOS.

Типичный процессор ARM, используемый сегодня, интегрируется с периферийными устройствами в одну микросхему, называемую SoC Система на чипе. Основная память, например DRAM и энергонезависимое хранилище, например Вспышки NAND, как правило, являются внешними по отношению к SoC для максимальной гибкости проектирования. Но, как правило, имеется небольшое (возможно, 128 КБ) встроенное ПЗУ (постоянное запоминающее устройство) для инициализации минимальных системных компонентов для начала операций начальной загрузки. Сброс процессора всегда будет вызывать выполнение этого загрузочного ПЗУ. (Это ПЗУ действительно доступно только для чтения и не может быть изменено. Код маскируется в кремнии во время изготовления чипа.)

Каждый поставщик SoC имеет свой собственный метод начальной загрузки для загрузки и запуска ОС. Некоторые используют аппаратное связывание, считывающее контакты GPIO, чтобы определить источник следующего этапа последовательности начальной загрузки. Другой поставщик может использовать упорядоченный список памяти и устройств для поиска программы начальной загрузки. Другой метод заключается в переходе к встроенному ПО во флэш-памяти NOR, которое может быть выполнено напрямую (т.е. XIP, выполнить на месте).

Одной из проблем начальной загрузки системы, которая использует DRAM для основной памяти, является ее аппаратная инициализация. Контроллер памяти DRAM должен быть инициализирован, прежде чем код может быть загружен в DRAM и выполнен. Так где же находится этот код инициализации, поскольку он не может быть в основной памяти?
У каждого поставщика есть свое решение. Некоторые требуют, чтобы данные конфигурации памяти были сохранены в энергонезависимой памяти для доступа к загрузочному ПЗУ. Некоторые SoC имеют встроенную SRAM (которая не требует инициализации, как DRAM) для выполнения небольшой программы начальной загрузки. Некоторые SoC используют NOR flash для хранения программы начальной загрузки XIP.

Как только программа начальной загрузки инициализирует DRAM, можно использовать основную память для загрузки следующего этапа загрузки. Это может быть сложная утилита загрузки, такая как U-Boot, или (если способна программа начальной загрузки) ядро ​​Linux. Обратите внимание, что может быть несколько программ начальной загрузки или этапов, которые были выполнены между сбросом процессора до выполнения ОС.

Требования к загрузке ядра Linux ARM изложены в следующем документе: http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
Более старые версии Linux ARM использовали список ATAG для передачи базовой информации о конфигурации в ядро. Современные версии предоставляют полную конфигурацию платы с использованием скомпилированного двоичного файла дерева устройств.

Очевидно, что вопрос "как сделать бутстрап?" нельзя ответить без каких-либо оговорок.

Как и в BIOS ПК, загрузочные ПЗУ SoC являются проприетарными и не выпускаются (если вы не подпишете NDA, если вообще). Но большинство других загрузочных кодов выпускается под лицензией GPL или аналогичной, и их легко получить.


ДОПОЛНЕНИЕ

Поскольку вы сейчас упоминаете, что используете Zynq 7000 (который использует Xilinx SoC), у Xilinx есть видеоурок по Как создать загрузочный образ Linux ,
Это видео подтверждает то, что я уже написал:
1. Xilinx SoC имеет встроенный загрузочный диск (который технически является первым этапом, но чаще игнорируется или описывается как нулевой этап).
2. Существуют «контакты режима» для указания источника программы начальной загрузки для следующего этапа.
3. Загрузочное ПЗУ загружает во встроенную SRAM программу начальной загрузки (которая технически является второй стадией, но часто называется «первой» стадией), называемой FSBL. Эта программа инициализирует DRAM и загружает следующий этап, U-Boot.
4. U-Boot запускается из DRAM и загружает ядро ​​Linux.

Видео демонстрирует, что исходный код FSBL можно загрузить с сайта Xilinx и перекрестную компиляцию за несколько шагов Здесь нет «Трюк» как вы утверждаете. Сборка представляет собой простую конфигурацию и кросс-компиляцию, которую я нахожу проще / проще, чем типичный пакет приложения.

Возможно, ваше заблуждение основано на неоднозначности загрузочного носителя, то есть источник (ы) загрузочных образов не был (не) указан. Видео упоминает флэш-память NAND и SD-карту как возможные загрузочные устройства.
Загрузочное ПЗУ предназначено для чтения образа FSBL с исходного носителя в соответствии с настройками выводов режима.

FSBL (если он похож на другие используемые мной загрузчики) предназначен для чтения U-Boot с настроенного исходного носителя. Нет альтернативы времени выполнения.

U-Boot пытается соответствовать своему имени («универсальный») и может быть настроен (используя переменные среды) для загрузки изображений (и сценариев) с различных устройств. Также есть интерактивная опция.

Также смотрите вики Xilinx на Zynq Linux , который заявляет, что «полную информацию о загрузке Zynq можно найти в Техническое справочное руководство ».


Хорошо, ссылка была очень информативной, спасибо! Определенно объяснил, как это изображение сопоставляется с адресом памяти без сжатия и запуска. Таким образом, хитрость заключается в кросс-компиляции загрузочного образа с соответствующей областью памяти, загружая достаточно аппаратной поддержки, чтобы получить полный образ.
MrMowgli

Путаница действительно связана с тем фактом, что FPGA в этом случае может определять свои собственные аппаратные устройства, и есть файл карты памяти, специфичный для программируемой логики. Первоначальный вопрос связан с идеей о том, как в первую очередь происходит кросс-компиляция на основе универсальной сторонней платы с различными компонентами и запоминающими устройствами. Я думаю, что ваша ссылка хорошо объясняет это. Однако для плат Zynq вам также понадобятся DTB-файлы и битовые файлы для программируемого слоя.
MrMowgli
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.