Зачем использовать uImage вместо zImage
Я пытаюсь понять разницу между zImage и uImage.
С другой стороны, zImage — это сжатый Image , он не содержит адреса загрузки и точки входа (как я думаю, поправьте меня, если я ошибаюсь), но также может загружать U-Boot это с помощью bootz .
В этом случае зачем использовать uImage вместо zImage ?
Мне любопытно узнать, каковы форматы zImage и uImage, не могли бы вы предложить несколько ссылок?
2 ответа
Насколько я понимаю, uImage можно получить, запустив mkimage на изображении
Ваше понимание верно лишь отчасти.
uImage может содержать любой тип файла и не ограничивается файлом Image Linux. На самом деле, это вряд ли (несжатый) файл изображения (поскольку это не обычный вариант make ).
С другой стороны, zImage — это сжатое изображение, оно не содержит адреса загрузки и точки входа (что я думаю, поправьте меня, если я [sic] ошибаюсь)
Вы ошибаетесь, zImage действительно содержит адрес загрузки ядра и точку входа. Адрес загрузки необходим для того, чтобы распаковать Образ ядра в правильный адрес RAM. Точка входа ядра необходима для его выполнения после распаковки.
При сборке Image и zImage для ARM файлы Makefile используют
Что должно переводиться в начало физической памяти + 0x8000.
Сам zImage (то есть программа самоизвлечения) является PIC, позиционно-независимым кодом. ZImage может быть загружен в любом месте ОЗУ и выполнен по его первому адресу, то есть его точкой входа является его адрес загрузки.
В этом случае зачем использовать uImage вместо zImage?
Для более старых версий U-Boot выбора не было, поскольку команда bootz могла быть недоступна для ядер Linux.
В настоящее время это может быть субъективный выбор.
Обратите внимание, что в сообществе ядра Linux было некоторое недовольство поддержкой U-Boot в ядре. IOW, если бы некоторые люди добились своего, у меня сложилось впечатление, что вы не смогли бы создать uImage из основного источника.
Мне [sic] любопытно узнать, каковы форматы zImage и uImage, не могли бы вы предложить несколько ссылок?
Макет zImage по существу определяется спецификацией компоновщика.
Для ARM см. arch / arm /boot/compressed/vmlinux.lds.S.
Обратите внимание, что _magic_start содержит бессмысленный адрес загрузки. Это также упоминается в разделе 5 статьи Винсента Сандерса Загрузка ARM Linux
Обратите внимание, однако, что требования к загрузке ARM были заменены документацией Рассела Кинга. / arm / Загрузка
Макет uImage — это просто заголовок U-Boot плюс файл изображения, каким бы он ни был.
(Надеюсь, ничто из того, что я написал, не противоречит тому, что написал Том Рини.)
Это не совсем так. В то время как «устаревший» заголовок u-boot, который используется для создания того, что обычно называется uImage, может быть любым, включая изображение, находящееся в arch / arm / boot / Image, чаще всего это файл zImage. Это связано с тем, что исторически не существовало поддержки прямой загрузки zImage в U-Boot, и поскольку zImage не предоставляет контрольной суммы для данных, uImage имеет crc32 доступного содержимого.
Источник
Зачем использовать uImage вместо zImage
Я пытаюсь понять разницу между zImage и uImage.
В моем понимании uImage получается при запуске mkimage в Image и в результате он добавляет оболочку U-Boot (я не знаю, что именно в ней содержится) который содержит заголовок плюс адрес загрузки и точка входа и, возможно, «дополнительная информация», которую я не знаю.
С другой стороны, zImage является сжатым Image , он не содержит адрес загрузки и точку входа (что я думаю, исправьте меня, если я ошибаюсь), но также U-Boot может загрузить его, используя bootz
В этом случае зачем использовать uImage вместо zImage
Мне интересно узнать, какие форматы zImage и uImage, не могли бы вы предложить несколько ссылок?
2 ответа
В моем понимании uImage получается при запуске mkimage на изображении
Ваше понимание верно только отчасти.
uImage может содержать любой тип файла и не ограничивается файлом Image в Linux. Фактически, это не будет (несжатый) файл изображения (поскольку это не обычный параметр make ).
С другой стороны, zImage — это сжатое изображение, оно не содержит адрес загрузки и точку входа (что я думаю, поправьте меня, если я не прав [sic])
Вы не правы, zImage содержит адрес загрузки ядра и точку входа. Адрес загрузки необходим для того, чтобы распаковать образ ядра в правильный адрес RAM. Точка входа в ядро необходима для его выполнения после распаковки.
При сборке Image и zImage for ARM файлы Makefile используют
который должен переводиться в начало физической памяти + 0x8000.
Сам zImage (то есть программа самораспаковки) — это PIC, независимый от позиции код. ZImage может быть загружен в любое место в ОЗУ и выполнен по первому адресу, то есть его точкой входа является адрес загрузки.
В этом случае зачем использовать uImage вместо zImage?
Для более старых версий U-Boot выбора не было, поскольку команда bootz могла быть недоступна для ядер Linux.
В наше время это может быть субъективный выбор.
Обратите внимание на то, что в сообществе разработчиков ядра Linux были некоторые возмущения по поводу поддержки U-Boot в ядре. Если бы некоторые люди поступили по-своему, у меня сложилось впечатление, что вы не сможете создать uImage из основного источника.
Мне [sic] интересно узнать, каковы форматы zImage и uImage. Не могли бы вы предложить несколько ссылок?
Компоновка zImage в основном определяется спецификацией компоновщика.
Для ARM см. arch /arm /boot/compressed/vmlinux.lds.S .
Обратите внимание, что _magic_start содержит бессмысленный адрес загрузки. Это также упоминается в разделе 5 загрузки Винсента Сандерса а>
Обратите внимание, что требования по загрузке ARM были заменены Документация /рука /Загрузка
Макет uImage — это просто заголовок U-Boot плюс файл изображения, что бы это ни было.
(Надеюсь, ничто из написанного мной не противоречит тому, что написал Том Рини.)
Источник
Русские Блоги
Разница между zImage и uImage
После того как ядро скомпилировано (make), генерируются два файла: Image и zImage, где Image — это файл образа ядра, а zImage — сжатый файл образа ядра, Image — около 4 МБ, а zImage — менее 2 МБ.
Так что же такое UImage? Это специальный файл образа для uboot, который добавляет 64-байтовый «заголовок» перед zImage, указывая версию ядра, место загрузки, время генерации, размер и другую информацию, его 0x40 ничем не отличается от zImage.
Как создать файл uImage?
Сначала найдите файл mkimage в каталоге / tools в uboot, скопируйте его в каталог system / usr / local / bin, а затем завершите рабочий инструмент. Затем запустите make uImage в каталоге ядра. В случае успеха вы можете найти файл uImage в каталоге arch / arm / boot /, который на 64 байта больше, чем zImage.
С описанием заголовка uImage u-boot знает информацию о соответствующем образе. Если заголовка нет, вам нужно вручную установить эти параметры самостоятельно.
U-boot U означает «универсальный».
zImage — это сжатый файл образа, обычно используемый в ARM Linux. uImage — это специальный файл образа для загрузки U. Это «заголовок» длиной 0x40 перед zImage, указывающий тип, место загрузки и время генерации этого файла образа. Размер и другая информация. Другими словами, если вы начинаете прямо с позиции uImage 0x40, между zImage и uImage нет никакой разницы. Кроме того, ядро Linux2.4 не поддерживает uImage. Ядро Linux2.6 добавляет большую поддержку встроенным системам, но также необходимо настроить генерацию uImage. Я расскажу об этом позже.
Разница между несколькими файлами ядра Linux:
1. vmlinux, самый оригинальный файл ядра, скомпилированный, несжатый.
2. zImage — это файл, сжатый gzip vmlinux.
3. bzImage, bz означает «большой zImage», не сжатый с помощью bzip2. Разница между ними заключается в том, что zImage распаковывает ядро в низкоуровневую память (первые 640 КБ), а bzImage распаковывает ядро в высокопроизводительную память (более 1 МБ). Если ядро относительно маленькое, вы можете использовать zImage или bzImage. Если оно больше, вы должны использовать bzImage.
4. uImage, специальный файл образа для U-boot, перед zImage добавлен тег длиной 0x40.
5. vmlinuz — это копия файла bzImage / zImage или ссылка на bzImage / zImage.
6. initrd — это сокращение от «начальный ramdisk». Обычно используется для временной загрузки оборудования до состояния, когда фактическое ядро vmlinuz может взять на себя и продолжить загрузку
Обычно после генерации vmlinux ядро сжимается в zImage, а сжатым каталогом является kernel / arch / arm / boot.
Загруженный на флэш-память сжатый файл zImage, zImage состоит из сжатого vmlinux и программы распаковки,
Глядя на таблицу данных 2440, обнаруживается, что базовый адрес карты памяти равен 0x3000 0000, так откуда же взялся 0x30008000?
В ядре документа kernel / Document / arm / Загрузочный файл:
Кажется, что 32K (0x8000) пространство используется под изображением для хранения таблицы страниц ядра,
0x30008000 — это начальный адрес ядра 2440 в ОЗУ. Отсюда и этот адрес.
Например, используйте U-Boot для запуска ядра Linux
Источник
Исследуем OpenWRT: чем отличаются образы uImage и sysupgrade
В комментариях к статье “Прошиваем роутер Upvel UR-313N4G на OpenWRT” между вашим покорным слугой и уважаемым Maysoft завязался спор насчет различий в структуре образов uImage и sysupgrade прошивки OpenWRT. Я обещал Maysoft разобраться в проблеме, и вот перед вами эта статья.
Как известно, в каталоге загрузок OpenWRT доступны, по большей части, прошивки двух типов — uImage и sysupgrade, например:
Официальный FAQ пишет об их различиях весьма скупо:
What is the difference between the different image formats?
a factory image is one built for the bootloader flasher or stock software flasher
a sysupgrade image (previously named trx image) is designed to be flashed from within openwrt itself
The two have the same content, but a factory image would have extra header information or whatever the platform needs. Generally speaking, the factory image is to be used with the OEM GUI or OEM flashing utilities to convert the device to OpenWrt. After that, use the sysupgrade images.
Согласно документации, содержание образов идентично, за исключением того, что в образе factory присутствуют дополнительные заголовки, чтобы этот образ можно было прошить через Web-интерфейс оригинальной прошивки.
Отлично, сравним размер прошивок:
openwrt-15.05-rc3-ramips-rt305x-dir-320-b1-initramfs-uImage.bin — 3253035 байт.
openwrt-15.05-rc3-ramips-rt305x-dir-320-b1-squashfs-sysupgrade.bin — 3407876 байт.
Ого, прошивка sysupgrade почти на 140 Кб больше uImage, а по документации они должны быть примерно одного размера, причем uImage за счет этой самой “extra header information” — немного больше.
Конечно, достаточно посмотреть в сборочные скрипты, чтобы понять, чем различаются uImage и sysupgrade-образы, но это, согласитесь, неспортивно. Сегодня мы будем анализировать прошивки “в лоб”, как будто у нас нет исходников, а уже в конце заглянем в сборочные скрипты, чтобы подтвердить наши догадки.
Основным средством анализа прошивок на данный момент является утилита binwalk, доступная под Linux. Переименуем файлы прошивок покороче, чтобы нам было удобнее, и начнем анализ.
Кажется, вся прошивка представляет собой образ uImage — в начале следует заголовок длиной 64 (0x40) байт, а вслед за нам — поток данных, сжатый алгоритмом LZMA, размером 3252971 байт. Сложим 64 и 3252971, получим 3253035 байт, то есть размер скачанного образа. Следовательно, кроме образа uImage в файле больше ничего нет. Binwalk умеет распаковывать найденные LZMA-потоки. В принципе, можно вручную отрезать от файла первые 64 байта и распаковать остаток командой lzma -d, но зачем, когда есть такой удобный инструмент?
Посмотрим, что у нас получилось
Файл с именем 40 (смещение в исходном файле) — и есть распакованный поток. Натравим на него binwalk:
А здесь у нас что-то, на первый взгляд, непонятное — binwalk обнаружил ядро Linux по смещению 0x2AEB14 и три сжатых потока данных, следующих за ядром. Дело в том, что binwalk для анализа использует эвристики и то, что получается у него на выходе — не истина в последней инстанции, а информация к размышлению.
Здравый смысл подсказывает, что ядро должно начинаться со смещения 0, а сжатый поток — быть один и содержать initramfs — начальную файловую систему, загружаемую в RAM. О том же говорит и документация на ядро:
What is initramfs?
— All 2.6 Linux kernels contain a gzipped «cpio» format archive, which is extracted into rootfs when the kernel boots up. After extracting, the kernel checks to see if rootfs contains a file «init», and if so it executes it as PID 1.
Populating initramfs:
— The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary. By default, this archive is empty (consuming 134 bytes on x86).
Здесь же упоминается и формат потока — CPIO.
Посмотрим, что binwalk сможет извлечь из нашего образа:
Итак, успешно распаковался только поток по смещению 33E2C8. Если мы все правильно делаем, то это должен быть CPIO-контейнер с файловой системой:
В конце архива мы видим файл с именем TRAILER. который. согласно документации, является меткой конца архива.
Значит, структура прошивки initramfs-uImage такова:
Теперь возьмемся за образ squashfs-sysupgrade. Из названия следует, что в образе содержится (кроме ядра) файловая система squashfs. Посмотрим, так ли это:
Возьмемся за арифметику: 64 + 1142606 (image size) = 1142670, как раз по этому смещению начинается образ squashfs, а заканчивается он по смещению 1142670 + 2221946 = 3364616. Размер образа, между тем, 3407876 байт, значит, у нас есть еще 3407876 — 3364616 = 43260 байт неидентифицированной информации. Посмотрим, что там, hexdump’ом
Тут явно какая-то заглушка. Вернемся к ней позднее.
Посмотрим, что у нас в каталоге с распакованным образом:
Распакуем LZMA-поток по смещению 40:
Здесь у нас ядро Linux и небольшой initramfs-образ с четырьмя файлами. Остальное, видимо, переместилось в образ squashfs:
Действительно, основная файловая система содержится в образе squashfs.
Теперь разберемся с заглушкой в конце образа. Есть подозрение, что она как-то относится к ФС JFFS2, потому что при прошивке образа sysupgrade и последующей загрузке в dmesg появляются строки:
а при прошивке и загрузке образа uImage этих строк нет. Поиск в “ванильном“ ядре по этим строкам ничего не дает, а вот в дереве исходных кодов OpenWRT такие строки есть:
Ага, вот и наша заглушка 0xDEADCODE. Если драйвер JFFS2 находит эту метку, то он считает ее концом предыдущей файловой системы и стирает все, начиная с нулевого байта метки и заканчивая концом накопителя. Таким образом сама метка также затирается.
После этого драйвер создает на этом месте новый экземпляр JFFS2.
Итак, получается следующая структура образа:
Таким образом:
- uImage содержит минимально необходимый функционал для запуска OpenWRT и за счет этого его структуру можно легко изменить так, чтобы она проходила проверки на корректность в Web-интерфейсах оригинальных прошивок.
- Sysupgrade устроен сложнее и использует Linux-специфичные инструменты — SquashFS и JFFS2.
- Оба типа образов не содержат начального загрузчика (и не должны)
- При прошивке через начальный загрузчик (через UART или аварийное восстановление) можно сразу шить sysuprade.
- При прошивке через mtd_write, если эта утилита доступна через telnet из официальной прошивки, также можно сразу шить sysupgrade.
В заключении заглянем сборочные скрипты OpenWRT, чтобы убедиться в своих выводах. Начнем с файла /target/linux/ramips/Makefile. Но если вы думаете, что это обычный GNU Makefile, то это не так. Вот как описывают улучшенный Makefile сами разработчики:
Looking at one of the package makefiles, you’d hardly recognize it as a makefile. Through what can only be described as blatant disregard and abuse of the traditional make format, the makefile has been transformed into an object oriented template which simplifies the entire ordeal.
Кажется, сборка образа запускается в строке 564:
Цель BuildFirmware/Default8M описана в строках 195 и 196:
Она состоит из двух позиций: squashfs и initramfs. Цели BuildFirmware/OF и BuildFirmware/OF/initramfs описаны в том же файле чуть выше
По имени цели MkImageLzmaDtb можно догадаться, что она создает образ uImage по описанию из DTS-файла. Для цели BuildFirmware/OF/initramfs к этому образу добавляется раздел initramfs с основной файловой системой, после чего образ копируется в выходной каталог. Для цели BuildFirmware/OF исходный образ обрабатывается функцией MkImageSysupgrade, которая с помощью команды “cat” прицепляет к нему раздел squashfs, а затем, взывает функцию prepare_generic_squashfs, определенную в файле image.mk.
А утилита padjffs2, написанная на C, записывает отметку 0xDEADCODE в конец файла образа:
В общем, мир OpenWRT прекрасен и удивителен, особенно доставляют комментарии типа:
# The real magic happens inside these templates
Источник
