Каковы реальные шаги, если предположить, что у вас был набор заголовочных файлов c, которые описывали устройства отображения памяти в вашей системе, чтобы сделать начальное работающее ядро? Я знаю, что все просто загружаются с живого CD/USB-накопителя и т.д., Но как получился первый загрузчик?
РЕДАКТИРОВАТЬ: я должен отметить, что я говорю об устройствах ARM на самом деле, я получаю основы загрузки через BIOS на типичной машине, но допустим, мы говорим о пользовательском устройстве?
как появился первый загрузчик?
Сборка (написание и кросс-компиляция) программы начальной загрузки не так сложна, как кажется.
Я должен отметить, что я действительно говорю об устройствах 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. Загрузочное ПЗУ загружает программу начальной загрузки (которая технически является второй стадией, но часто описывается как "первая" стадия), называемая FSBL, во встроенную SRAM. Эта программа инициализирует DRAM и загружает следующий этап, U-Boot.
4. U-Boot запускается из DRAM и загружает ядро Linux.
Видео демонстрирует, что исходный код FSBL можно загрузить с сайта Xilinx и выполнить кросс-компиляцию за несколько шагов. Там нет "трюк", как вы утверждаете. Сборка представляет собой простую конфигурацию и кросс-компиляцию, которую я нахожу проще / проще, чем типичный пакет приложения.
Возможно, ваше замешательство основано на неоднозначности загрузочного носителя, то есть источник (ы) загрузочных образов не был (не) указан. Видео упоминает флэш-память NAND и SD-карту как возможные загрузочные устройства.
Загрузочное ПЗУ предназначено для чтения образа FSBL с исходного носителя, как настроено с помощью выводов режима.
FSBL (если он похож на другие загрузочные системы, которые я использовал) создан для чтения U-Boot с настроенного исходного носителя. Нет альтернативы времени выполнения.
U-Boot пытается соответствовать своему имени ("универсальный") и может быть настроен (используя переменные среды) для загрузки изображений (и сценариев) с различных устройств. Также есть интерактивная опция.
Также см. Вики Xilinx на Zynq Linux, где говорится, что «полную информацию о загрузке Zynq можно найти в Техническом справочном руководстве ».
