Как распаковать zimage для linux

Обновлено: 04.07.2024

repack-zImage.sh is a bash script for Linux which allows you to unpack a kernel image (zImage) for modification and repack it afterwards into a new working kernel image.

You don't need a kernel tree for this program nor a compiler. It should work with any zImage that contains an initramfs, for whatever phone, operating system or CPU architecture you like.

My main purpose when I wrote it was to modify the initramfs of leaked Samsung i5800 firmware for which no kernel source is available.

Put the unzipped script into some directory along your $PATH (e.g., /usr/local/bin). Put the unpacked files from initramfs_utils.zip into /usr/local/bin.

Then simply run 'repack-zImage.sh -u' with your zImage in the current directory and it will create a directory named 'zImage_unpacked' which contains the unpacked blocks of your zImage. Refer to the comments near the start of the program to identify which file corresponds to which fragment of the original zImage. (The file name of the zImage should be "zImage". If it isn't, pass it as the only non-option argument. The subdirectory's name will change accordingly.)

Most notably, there will be a directory 'initramfs' in there, which contains all files from the original initramfs in their original tree. You can modify the contents as you like, but keep in mind that your initramfs cannot grow larger than the space reserved for it in the original zImage. So you're restricted to relatively small changes which should, however, satisfy many needs. You always can call a script or executable on some other partition (including the SD card if already mounted) if you need more room for your modifications.

After your modifications are done, cd back to the directory which contains zImage and zImage_unpacked and run 'repack-zImage.sh -p' to start the packing process.

This will create a directory called 'zImage_packing' which contains your new zImage (and a zImage.tar for loaders like ODIN). It will emit (between others) one or two messages about a padding being done and about how many bytes were padded. This number (or the lower number of the two) is an indication about how many compressed bytes are left for further additions to the initrd.

If your initramfs (or some other modified part) grows too large, the script will abort with an appropriate error message.

In initramfs-utils.zip, three programs are provided. They should be copied to /usr/local/bin:
* cpio_set0. This is a slightly modified cpio (compiled for 32 bit Linux). repack-zImage.sh will run without it, but there may be slightly more room in your initramfs if you use the modified one. It sets all file times in the archive to 0 (epoch), thus yielding better and consistent compression results. Else, the size of the compressed initramfs will differ from invocation to invocation due to differing atimes. Put it somewhere along your $PATH (e.g., /usr/local/bin).
* gen_init_cpio and
* gen_initramfs_list.sh. These are utilities copied from a kernel tree and used to support creation of an initramfs (in certain modes).

'repack-zImage.sh --help' will output usage information.

Current Version: 6
2011-05-03
('repack-zImage.sh --version' will output version information.)

- added support for lzma compressed ramdisks (both directions)

Version 4
2011-02-17

The system I use first boots from stage 1 loader and then it calls u-boot. I want to discard u-boot and directly boot from stage 1 loader. Which type of kernel image do I have to use?

14k 1 1 gold badge 34 34 silver badges 45 45 bronze badges

1,681 4 4 gold badges 21 21 silver badges 33 33 bronze badges yeah I was using a wrong version of u-boot.elf to create the BOOT.bin

1 Answer 1

What is the difference between them?

Image: the generic Linux kernel binary image file.

zImage: a compressed version of the Linux kernel image that is self-extracting.

uImage: an image file that has a U-Boot wrapper (installed by the mkimage utility) that includes the OS type and loader information.
A very common practice (e.g. the typical Linux kernel Makefile) is to use a zImage file. Since a zImage file is self-extracting (i.e. needs no external decompressors), the wrapper would indicate that this kernel is "not compressed" even though it actually is.

Note that the author/maintainer of U-Boot considers the (widespread) use of using a zImage inside a uImage questionable:

Actually it's pretty stupid to use a zImage inside an uImage. It is much better to use normal (uncompressed) kernel image, compress it using just gzip, and use this as poayload for mkimage. This way U-Boot does the uncompresiong instead of including yet another uncompressor with each kernel image.

Which type of kernel image do I have to use?

You could choose whatever you want to program for.
For economy of storage, you should probably chose a compressed image over the uncompressed one.
Beware that executing the kernel (presumably the Linux kernel) involves more than just loading the kernel image into memory. Depending on the architecture (e.g. ARM) and the Linux kernel version (e.g. with or without DTB), there are registers and memory buffers that may have to be prepared for the kernel. In one instance there was also hardware initialization that U-Boot performed that had to be replicated.

ADDENDUM

I know that u-boot needs a kernel in uImage format.

That is accurate for all versions of U-Boot which only have the bootm command.
But more recent versions of U-Boot could also have the bootz command that can boot a zImage.

Мною разработаны средства под различные типы чипов (микроконтроллеров), имеющих различие в строении образов. По мере поступления информации я буду выкладывать ее Вам в соответствующем разделе. В разделе "Дополнительная информация" будут находиться ссылки на заметки (статьи), ОБЩИЕ для всех чипов.

Консольные средства для обработки прошивок и отдельных образов

- на основе Perl/Python скриптов, выполняющие несколько операций;
- отдельные приложения, выполняющие, как правило, одну-две функции.

стандартное, предназначенное для обработки одного экземпляра прошивки или набора образов устройства. На сегодня это версия RKwinTools_v1.4.0;
Pro, позволяющее работать параллельно с несколькими прошивками, используя принцип проектов. На сегодня это версия RKwinTools_Pro_v1.1

добавлена обработка разделов second, dtb образов Boot и Recovery;
обрабатываются образы Boot и Recovery, созданные архиваторами gzip, lzma, xz;
добавлена возможность выбора образа из списка при обработке;
при сборке параметры образов выбираются из файла конфигурации (cfg/*.cfg);
расширены функции работы через ADB.

выбрать исходный файл ROM-прошивки для обработки из списка имеющихся;
распаковать и запаковать ROM-прошивку в формате "RKFW" и "RKAF" с автоматическим определением формата;
распаковать образы Boot, Recovery. Поддерживаются форматы как "ANDROID", так и "KRNL" с автоматическим определением;
запаковать образы Boot и Recovery с выбором типа конечного образа (KRNL или ANDROID);
распаковать и запаковать образ Kernel;
распаковать и запаковать образ System типа jaffs и ext2-ext4 ;
преобразовать сжатый образ System типа sparse в ext4;
инициировать ROOT в образ system;
работать с устройством через ADB;
подсчитать контрольную сумму файла в формате md5.
читать руководство пользователя.

удалено копирование настроек при отказе во время сборки ROM.
исправлена ошибка при разборке образа system типа ext4.
добавлена сборка образа system типа ext4.
добавлен пункт меню для получения информации об образе system (9 - info system).

создать новый проект;
открыть проект, выбрав его из списка уже существующих;
сохранить проект в архив;
восстановить проект из архива;
удалить проект.

Используйте ее для общего ознакомления со средством, т.к. такая же находится в общем архиве.
Для варианта Pro: README_Pro_1.2.rar ( 5.23 КБ )

или в pdf формате RKwinTools_Pro_1.1.pdf ( 580.36 КБ )

Для стандартного варианта: README_133.rar ( 7.58 КБ )

Стандартный вариант: RKwinTools_v133.rar ( 5.86 МБ )

Программа редактирования параметров файла Parameter перенесена в тему Разметка памяти мобильных устройств. Теория и практика.

распаковать и запаковать образы Boot/Recovery с учетом секций second и dtb (дерево устройств);
производить сжатие/распаковку при помощи gzip, lzma, xz ;
распаковать и запаковать образы, содержащие файловые системы как jaffs типа, так и ext2-ext4;
провести конвертацию из sparse в ext4;
перед обработкой выбрать файл без его переименования.

распаковать и запаковать образы Boot/Recovery с учетом секций second;
производить сжатие/распаковку при помощи gzip, lzma, lz4, lzop, xz ;
распаковать и запаковать образы, содержащие файловые системы как jaffs типа, так и ext2-ext4;
провести конвертацию из sparse в ext4;
перед обработкой выбрать файл без его переименования.

Свежая версия для Win 7 MTwinTools_v0.7.7z ( 3.43 МБ )

Свежая версия для ХР ( благодаря пользователю ANT__)MTwinTools_v0.6.1_winxp.rar ( 4.16 МБ )

Предыдущие версии

Windows 7 и выше;
установка пакета .NET 4.0

разобрать/собрать прошивку *.qsb;
собрать "кусочные" файлы (типа system_0.img, cache_8.img) в целый;
разобрать/собрать boot/recovery. Поддерживаются образы x64, сжатые следующими архиваторами:
- gzip;
- lz4;
- lzma;
- lzop;
- xz;
посмотреть разметку прошивки.

Инструкция пользователя (такая же имеется и в архиве со средством):Readme_LenovoWinTools_v1.2.7z ( 5.24 КБ )

распаковать и запаковать образы Boot.img и Recovery.img типа "multi-file", "ramdisk", "script", "kernel";
распаковать и запаковать образ System.img типов yaffs, yaffs2, ext2-ext4;
конвертировать образ System.img типа sparse в ext4 (аналог simg2img);
добавить к файлам контрольную сумму в формате md5.

Приложение для разборки прошивки типа .APP
AppImageMaker.rar ( 6.57 КБ )

Для запуска используется командная строка вида:

sourceFile - полный путь и название файла прошивки. Например, d:\app\SR_APP_Update.app
destPath - полный путь к папке назначения, в которую будет произведена распаковка прошивки, например, f:\qwerty
key - ключ для получения дополнительной информации. Он может быть следующим:
/h, /?, --help - выводит справочную информацию о приложении.
Если никакой ключ не введен, то производится распаковка файла прошивки. Для этого должны быть введены имя с полным путем к файлу и путь к папке назначения. При отсутствии эта папка создается сама, а при наличии в нее перезаписываются имеющиеся там файлы.
Например, если команду ввести следующим образом:

AppImageMaker d:\app\SR_APP_Update.app f:\qwerty

то файл SR_APP_Update.app из папки d:\app будет распакован в папку f:\qwerty.
Если не введен путь к конечной папке (папке назначения), то она создается в той же папке, где находится приложение AppImageMaker, с именем "update" по-умолчанию. Например, строка вида:

AppImageMaker d:\app\SR_APP_Update.app

распакует указанный файл в папку с именем update, созданную рядом с приложением AppImageMaker.
Если не указать также путь и имя файла прошивки, то по-умолчанию для прошивки будет использоваться имя "Update.app". Например, если ввести строку вида:

AppImageMaker

то приложение будет искать файл с именем "Update.app" в папке рядом с ним. При наличии такого файла он будет распакован в тут же созданную папку "update".
Для особо любознательных есть еще один ключ "/crc". По нему в папку назначения параллельно с распакованными файлами прошивки будут записываться контрольные суммы этих файлов, найденные в прошивке в заголовках этих файлов, с расширением ".crc".

Приложение для разборки прошивок вида BIN, DZ, KDZ - LGwinTools_v1.03.7z ( 93.78 КБ )

/if:in_name (-if:) - имя файла прошивки для разборки, обязательный параметр;
/ip:in_path (-ip:) - имя папки с файлами прошивки для сборки, обязательный параметр;
/op:out_path (-op:) - папка выгрузки файлов при разборке или прошивки при сборке, обязательный параметр;
/di:pack (-di:) - режим работы. При pack - сборка прошивки, при отсутствии ключа разборка (по-умолчанию).
/h (-h, --help) - вызов справки.

1. Что делать, если я первый раз запускаю средство? Инструкция новичка
2.

У средства появились последователи, которые выпускают "модифицированные" под свои нужды варианты: And_pda

Программа распаковки образов ext2-ext4. Автор: And_pda

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

Полезная вещь - обратная связь! Причем не только в технике.
После общения с некоторыми пользователями средства RKwinTools я решил выложить инструкцию по прописыванию пути к папке в переменных среды Windows.

Инструкция по добавлению пути в переменные среды Windows

ВНИМАНИЕ. Внесенные изменения начнут действовать без перезагрузки компьютера при следующем вызове командной строки или запуске файлового менеджера.

Итак,
Операционная система Windows XP x86.
На рабочем столе выбираем ярлык «Мой компьютер», кликнув на нем правой кнопкой мыши, вызываем контекстное меню и выбираем в нем команду «Свойства». Откроется окно «Свойства системы».
Выбираем вкладку «Дополнительно».
Внизу слева нажимаем кнопку «Переменные среды». Откроется окно "Переменные среды".
В области «Системные переменные» находим переменную «Path» и, выделив ее, нажимаем на кнопку «Изменить».
В поле «Значение переменной:» в конце дописываем путь к необходимой папке, отделяя его от существующего значения «точкой с запятой». Например, «;D:\Cygwin».
Нажимаем «ОК» для записи пути и последовательно закрываем все открытые окна.

Операционная система Windows 7 x86.
Вариант 1.
По пути "Пуск"->"Компьютер", нажимаем правую кнопку мыши для выбора контекстного меню и выполняем команду "Свойства".
В открывшемся окне "Просмотр основных сведений о Вашем компьютере" выбираем слева пункт меню "Дополнительные параметры системы".
В открывшемся окне"Свойства системы" справа внизу нажимаем кнопку "Переменные среды".
В окне"Переменные среды" в области "Системные переменные" нужно найти и выделить переменную "Path", а затем нажать кнопку "Изменить. ".
В появившемся окне «Изменение системной переменной», в поле "Значение переменной" ДОПИСЫВАЕМ В КОНЕЦ путь к только что установленной папке Cygwin, например такой: ";Е:\Cygwin", ОБЯЗАТЕЛЬНО отделив его от существующего значения «точкой с запятой», и нажимаем кнопку "ОК" для сохранения значения.
Последовательно закрываем все остальные открытые окна, тоже нажимая кнопку "ОК", кроме окна просмотра основных сведений, которое закрывается "крестиком".
Вариант 2.
В любом свободном месте рабочего стола нажимаем правую кнопку мыши для вызова контекстного меню и выбираем команду «Персонализация». В открывшемся окне слева выбираем пункт меню «Панель управления - домашняя страница».
Откроется окно "Панель управления" для проведения настроек параметров Вашего компьютера.
В нем необходимо выбрать настройку «Система» и Вы попадете в окно просмотра основных свойств о Вашем компьютере, т.е. "Окно сведений о системе".
Дальнейшие действия описаны в пункте «Вариант 1».

P.S. Каждому ПО требуются средства отладки.
В моем случае тишина (не ошибки, не вывода в лог), - а в ответ тишина.
Просьба подумайте над этим вопросом.

Для начала я посмотрю устройство образа, а потом посмотрим, что нужно и можно сделать.

В ныне существующем готовом виде отвечу - НЕТ. не сможет.
А вообще - ничего невозможного нет.

Когда процессор ARM включен, его указатель регистра ПК указывает на начало фрагмента ПЗУ, встроенного в ИС.Этот фрагмент ПЗУ называется BROM (загрузочный диск), и система загружается через этот фрагмент BROM. Пространство BROM относительно невелико, обычно 32/64 КБ, и размер ShareRAM на ИС также отличается, поэтому процесс загрузки ИС также будет другим.
BROM будет хранить загрузочную программу при включении. Эта программа обычно содержит следующее содержимое:

Программа загрузки в BROM настраивается и разрабатывается производителем микросхемы. Он будет определять, входить ли в режим флэш-памяти или режим запуска в соответствии с другим оборудованием, а также определять, с какого носителя загружаться. Затем прочитайте загрузочную программу на MBREC с загрузочного носителя на ShareRAM и перейдите к выполнению. BROM доступен только для чтения и фиксируется при потоковой передаче SOC, поэтому в основном он не будет изменен после получения SOC, а все настраиваемые элементы реализованы в загрузчике.

2. Загрузка загрузчика (загрузка второй стадии):

Загрузка BROM, используемая в архитектуре ARM, немного похожа на загрузку BIOS под X86. Загрузка микропрограммы в BROM, как правило, не меняется. Начиная со второго этапа, она перешла в настраиваемый этап. Как правило, программа загрузки второго этапа Он будет помещен на раздел загрузочного носителя отдельно, мы называем его загрузочным разделом или разделом MBR (главный загрузочный раздел).
Мы можем разделить загрузку второго этапа на многоуровневую загрузку:
Например, он разделен на следующий трехуровневый процесс загрузки:
（1） firstMBRC
Загрузочная программа первого уровня должна соответствовать формату, необходимому для загрузки BROM. Она вызовет функцию драйвера в BROM, чтобы скопировать второй MBRRC в shareRAM для проверки и выполнения перехода. Это независимый код. , Как правило, используйте сборку, чтобы сделать.
（2） secondMBRC（uboot-spl）
Функция загрузочной программы второго уровня заключается в вызове функции драйвера в BROM для копирования mainMBRC в DDR для проверки и выполнения перехода. Второй этап может быть достигнут с помощью spl в uboot или с помощью собственного независимого кода.
（3） mainMBRC（uboot）
Третий уровень - основная загрузочная программа. Первые два уровня загрузки предназначены для загрузки mainMBRC. Его основная функция - отображение логотипа запуска, загрузка ядра, файловой системы dtb, rootfs и запуск. ядро. Обычно используйте uboot.
Итак, в загрузочном разделе мы должны запрограммировать три части загрузочного кода: mbrc, uboot-spl, uboot.

3. загрузочный загрузчик

Ядро, которое для запуска использует uboot, - это uImage. Это ядро состоит из двух частей, одна из которых является заголовком, а другая - настоящим ядром. Таким образом вы можете выразить uImage = uboot header + zImage.
Определение заголовка:

Нам нужно заботиться о том, чтобы:

ih_load - это адрес загрузки ядра, то есть там, где должно быть ядро до его запуска, ih_ep - это адрес входа в ядро, адрес входа и адрес загрузки могут совпадать.

Процесс загрузки ядра с помощью Uboot состоит в том, чтобы определить, как запустить ядро, прочитав bootcmd в переменной среды env. Например, uboot хочет прочитать раздел ядра с флэш-памяти nand по адресу памяти 0x30007FC0 и запустить ядро. Вы можете использовать следующую команду: bootcmd = nand read.jffs2 ядро 0x30007FC0, bootm 0x30007FC0. Ключом к запуску ядра является команда bootm.
Реализация команды bootm находится в функции do_bootm () в uboot:
Исходный файл: cmd_bootm.c

Сначала определите, следует ли за адресом загрузки команда bootm.Если параметр адреса загрузки не указан, адрес загрузки по умолчанию назначается для addr, в противном случае адрес, присоединенный к команде bootm, будет использоваться в качестве адреса загрузки. Затем ключ должен прочитать заголовок uboot с адреса загрузки и проанализировать его. Исходя из приведенной выше логики кода, мы видим, что он будет судить, согласован ли адрес загрузки, передаваемый ih_load и bootm в ubootheader, и, таким образом, различать два случая:

(1) Если оно отличается, ядро (zImage) с удаленным заголовком (64Byte) будет скопировано по адресу, указанному в ih_load, и ядро будет запущено из ih_ep. Следовательно, в этом случае ih_load и ih_ep должны быть одинаковыми.
(2) Если это то же самое, пусть он будет размещен там в целости и запускает ядро (zImage) из ih_ep. Следовательно, в этом случае существует разница заголовка uboot между адресом функции входа выполнения и адресом загрузки. Поэтому ih_ep = ih_load + 64Byte.

С учетом вышеизложенного знания, как нам установить адрес в заголовке uboot, фактически этот шаг заключается в использовании инструмента mkimage для указания адреса загрузки и рабочего адреса при создании uImage.

Есть две ситуации для создания зеркальных головок и загрузки адресов:
Первое:

Адрес загрузки совпадает с адресом входа, а адреса, стоящие за tftp и bootm, являются произвольными адресами (за исключением адреса, указанного -a).

Адрес записи составляет 64 байта после адреса загрузки, а адреса после tftp и bootm должны быть по адресу загрузки, указанному -a.

Как правило, мы привыкли использовать второй метод и загружать его по адресу, указанному -a, чтобы вам не приходилось беспокоиться об обработке загрузок, что экономит время запуска.

В приведенном выше do_bootm мы получили информацию, относящуюся к образу ядра, проанализировав заголовок uboot, который включает адрес входа в ядро, и на последнем этапе загрузки он перейдет к ядру для выполнения. Этот шаг реализован в функции do_bootm_linux (). Перейдите через указатель на функцию thekernel () с тремя параметрами к точке входа ядра (zImage) и начните выполнение. На этом этапе задача u-boot завершена, и управление полностью передано ядру (zImage).

do_bootm_linux (), определенный в arch \ arm \ lib \ bootm.c, потому что мы уже знаем адрес записи, поэтому просто перейдите к адресу записи, чтобы запустить ядро linux.

hdr-> ih_ep ---- Адрес точки входа, точка входа в ядро, указанная в uImage, помните ih_ep? Второй параметр - это идентификатор машины, машинный код, установленный ядром, и машинный код, установленный uboot, должен быть согласован для запуска ядра, а третий параметр - это первый адрес, который u-boot передает параметрам ядра, хранящимся в памяти.

4. Загрузка ядра

После загрузки при загрузке система начинает работать в zImage. zImage - это зеркальное отображение, которое включает в себя понимание кода сжатия и vmlinux, поэтому его выполнение можно разделить на три части, а именно распаковка zImage, ядро vmlinux начинает этап сборки, ядро vmlinux запускает этап языка C.

(1) декомпрессия zImage
(2) ядро начинает этап сборки
(3) Ядро запускает стадию языка c (start_kernel для создания первого процесса)

zImage распаковать
На этом этапе задействованы только три файла:
(1)arch/arm/boot/compressed/vmlinux.lds
(2)arch/arm/boot/compressed/head.S
(3)arch/arm/boot/compressed/misc.c
Сначала перейдите к функции start в head.S, чтобы начать выполнение. Вы можете увидеть конкретный процесс в сочетании с файлом lds. Этот раздел не представляет слишком много.

Ядро начинает этап сборки
(Ссылочный файл ссылок на этом этапе: arch / arm / kernel / vmlinux.lds)
Код для запуска фазы сборки начинается с arch / arm / kernel / head.S, а отправной точкой выполнения является функция stext. Функция ввода указывается с помощью ENTRY (stext) в vmlinux.lds. Следует отметить, что в сборочном .S-файле также есть макроопределение ENTRY, которое должно отображаться в паре с ENDPROC для обозначения определенной функции. Кроме того, раздел, в котором находится текущий код, также должен быть указан в файле .S, например:

__HEAD - это определение макроса, объявленное как раздел .head.text, а ENTRY и ENDPROC используются для определения функции stext. Соответствующий файл lds показан ниже, где _text является константой, определенной в lds, и разные связанные константы будут существовать в разных разделах, таких как константа _text в разделе .head.text, _stext и _ в разделе .text. константы etext:

Основными задачами, выполняемыми в этой части, являются проверка идентификатора процессора, проверка идентификатора компьютера, создание таблицы страниц инициализации, настройка среды выполнения кода C, переход к первой реальной функции C ядра start_kernel для запуска выполнения.
Этот этап включает в себя две важные структуры:

(1) Одним из них является struct proc_info_list, который в основном описывает информацию, связанную с процессором, структура определяется в файле arch / arm / include / asm / procinfo.h, а связанные функции и переменные находятся в файле arch / arm / mm / proc_xxx.S Определение и назначение, такие как файл arch / arm / mm / proc-v7.S, используется armv7.
(2) Другая структура - это структура struct machine_desc, которая описывает плату разработки или информацию о машине. Структура определена в файле arch / arm / include / asm / mach / arch.h, а ее определение функций и назначение переменных находятся на плате. Очень актуальный файл arch / arm / mach-s3c2410 / mach-smdk2410.c, который также является очень важным файлом для трансплантации ядра.

Этот этап обычно вызывается предыдущим кодом распаковки, и для входа на этот этап требуется:
MMU = off, D-cache = off, I-cache = dont care,r0 = 0, r1 = machine id.
Все списки идентификаторов машин сохраняются в файле arch / arm / tools / mach-types, и соответствующий файл заголовка будет сгенерирован в kernel / include / generate / mach-types.h во время компиляции. в. Ядро найдет соответствующую структуру struct machine_desc в соответствии с входящим идентификатором машины и использует функцию обратного вызова для запуска ядра.

Во время компиляции две структурные переменные, определенные выше, struct proc_info_list, будут связаны с сегментом между __proc_info_begin и __proc_info_end файла образа ядра vmlinux. struct machine_desc будет связана с сегментом между __arch_info_begin и __arch_info_end файла образа ядра vmlinux. Соответствуя * (. Proc.info.init) и * (. Arch.info.init) соответственно, вы можете обратиться к следующему сценарию подключения vmlinux.lds.

В конце этапа сборки он перейдет к этапу языка C. и продолжит запуск. В head-common.S инструкция b start_kernel переходит к коду C для выполнения.

Ядро запускает стадию языка Си
Функция входа языка C определена в kernel / init / main.c. Она запускает выполнение через функцию start_kernel. Она вызовет много функций, связанных с платформой. Определение этой части функции все еще находится в каталог kernel / arch / arm / mach-XXX.

Например, в определении машины вы можете использовать функцию, определенную для соответствующей машины в start_kernel:

Для платформы smdk2410 соответствующая структура machine_desc инициализируется в файле linux / arch / arm / mach-s3c2410 / mach-smdk2410.c:

Макрос MACHINE_START определяется в файле arch / arm / include / asm / mach / arch.h:

attribute((section(".arch.info.init"))) указывает, где структура будет сохранена в будущем.

Помните информацию в vmlinux.lds, упомянутую выше?

Таким образом, содержимое, определенное выше, будет размещено в этом сегменте между __arch_info_begin и __arch_info_end. Это позволяет явно найти структуру в файле сборки.

Далее кратко представим процесс запуска процессора следующим образом:
Для SMP загрузочный ЦП будет выполнять функцию cpu_init во время инициализации системы для инициализации ЦП. Конкретная последовательность вызовов: start_kernel—> setup_arch—> setup_processor—> cpu_init. Для других процессоров в системе загрузочный процессор инициализирует каждый оперативный процессор в конце инициализации системы. Конкретная последовательность вызова:

Функция __cpu_up связана с архитектурой процессора. Для ARM вызывающая последовательность

Читайте также: