Что такое общие структуры для файлов прошивки?

Question

Я полный n00b во встроенном программировании. Предположим, я создаю прошивку, используя компилятор. Результатом этой операции является файл, в который будет свернута (я думаю) флэш-память MCU, такого как ARM или AVR.

Мой вопрос:Какие общие структуры (если таковые имеются) используются для таких сгенерированных файлов, содержащих прошивку?

Я пришел от разработки настольных и я понимаю, что, например, для Windows, компилятор, скорее всего, генерировать PE или PE +, в то время как Unix-подобные системы я могу получить ELF и COFF, но понятия не имеют, для встраиваемых систем.

Я также понимаю, что это сильно зависит от многих факторов (компилятор, ISA, поставщик MCU, ОС и т. Д.), Поэтому я в порядке с хотя бы одним примером.

---

Update: Я до голосовать все ответы, обеспечивающие примеры используемых структур и выбрать тот, который я чувствую лучшие обзоры о состоянии искусства.

Answer 1

Большинство инструментов выводят либо ELF, либо COFF, либо что-то подобное, что может в конечном итоге сводиться к файлу HEX/bin.

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

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

Answer 2

В конечном счете данные, записанные в ПЗУ, как правило, представляют собой только код и постоянные данные, из которых составлено ваше приложение, и, следовательно, не имеют никакой структуры, кроме, возможно, сегментированы в код и данные и, возможно, пользовательские сегменты, если вы их создали , Структура в этом смысле определяется сценарием компоновщика или конфигурацией, используемой для сборки кода. Файл, содержащий этот код/​​данные, может быть необработанным двоичным кодом или закодированным двоичным форматом, таким как Intel Hex или Motorola S-Record, например.

Как правило, ваша инструментальная цепочка будет генерировать файл объектного кода, который содержит не только код/​​данные, но также символическую и отладочную информацию для использования отладчиком. В этом случае, когда выполняется отладчик, он загружает код цели (как в случае с двоичным файлом выше) и информацию об символе/отладке на хост, чтобы разрешить отладку на уровне источника. Эти файлы могут быть в формате файла целевого объекта, специфичного для инструментальной цепочки, но часто являются стандартными «открытыми» форматами, такими как ELF. Однако строго компоненты метаданных объектного файла не являются частью прошивки , так как они не загружаются в цель.

Answer 3

Файл прошивки: Executable and Linkable File, обычно обрабатываемый двоичным (.bin) или текстовым изображенным двоичным (.hex).

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

Оттуда выполняется ваш код, поэтому у вас есть код запуска (обычно файл startup.s), который будет настраивать часы, регистры указателя стека, векторную таблицу, загружать раздел данных в ОЗУ (ваш инициализированные переменные), очистить нулевой инициализированный раздел, возможно, вам захочется скопировать код в ОЗУ и перейти к копии, чтобы избежать запуска кода из FLASH (может быть быстрее на некоторых платформах) и т. д.

При работе с операционной системой все эти варианты и ресурсы платформы не контролируют код пользователя, там вы можете ссылаться только на библиотеки ОС и использовать предоставленный API для выполнения действий на низком уровне. Встраиваемый, это 100% -ный код пользователя, вы получаете доступ к оборудованию и управляете его ресурсами.

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

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

Основным отличием является адресация памяти в двоичном файле firwmare, обычно адреса - physical RAM address, так как на большинстве микроконтроллеров нет функции сопоставления памяти. Это прозрачно для пользователя, компилятор будет абстрагировать его.

Другим существенным отличием является указатель стека, код пользователя OS не резервирует память для стека сам по себе, для этого он передает на ОС. Когда на прошивке вы должны сделать это в коде пользователя по той же причине, что и раньше, нет среднего человека, чтобы управлять им для вас. Сценарий компоновщика компилятора зарезервирует соответственно папку Stack and Heap, и в вашем файле .map будет символ stack_pointer, который позволит вам узнать, на что указывает. Вы не найдете его в файлах карты программы ОС.