Перейти к содержанию
    

Вот какая загвоздка. Имеем линукс для платформы c6x, который собираем с rootfs в варианте min-root, который по сути содержит 1) busybox, 2) mtd-utils, 3) libc. При сборке с нуля возникает такая проблема.

Чтобы собрать cpio образ rootfs, нужно в него положить все бинарники, то есть, в том числе, busybox, libc*.so и пр. Чтобы собрать busybox нужно иметь собранное ядро. А когда ядро собирается в конфигурации с initramfs, то конфгурационный скрипт дописывает в ($BLD)/.config строчку CONFIG_INITRAMFS_SOURCE=<путь к cpio>. Ну и вот при первой сборке никакого cpio то и нет еще. Получается порочный круг, и вообще гладко ничего собрать нельзя.

 

Пока что изворачивались тем, что подкладывали вначале какой-нибудь левый min-root-c6x.cpio, чтобы пройти цепочку и собрать настоящий rootfs, но это все в ручном режиме, противоречить идее make.

 

Может быть есть более прямой способ сборки? Например, меня бы устроил вариант, когда сначала ядро собирается само по себе, а потом отдельным таргетом к нему пришивается initramfs, и я могу управлять моментом этого пришивания - после сборки busybox, mtf-utils,... -> rootfs. Но уж как-то странно, что это надо прописывать через .config. Изменил .config, пересобирай снова все ядро...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот это еще одна загадка, на которую я пока не имею ответа. Пока что можно констатировать как факт, что при каждом вызове make product пересобирается busybox, даже если само ядро не пересобирается. Но главная грабля в том, что initramfs встраивается в объектный модуль ядра через установку опции в конфиге при сборке ядра, а не как отдельный таргет. А было бы удобнее так:

1) Собрать ядро

2) Собрать BB

3) собрать прочие файлы для наполнения initramfs

4) сделать образ rootfs

5) Прилинковать образ initramfs к ядру.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может быть есть более прямой способ сборки?

 

Любая сборочная система к которой не приложили руки китайцы из TI. То что вы описываете - это либо ошибка в их make-файле, либо непонимание для чего и что нужно, либо какой-то кривущий костыль специфичный для их процессора. Кстати ядро можно перелинковать с настоящим cpio архивом без извратов которые вы делаете с подстановкой "фейкового" архива, в ядре всегда автоматом создается "пустышка" для initramfs если не указан путь к cpio архиву (или путь к корню ФС - совсем не обязательно создавать cpio архив самому).

Изменено пользователем sasamy

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1) Вообще то там чаще индусы попадаются :)

2) makefile писал француз, судя по имени.

3) Кривизна в Makefile восходит к самому ядру, как мне кажется. Вот если читать Documentation/filesystems/ramfs-rootfs-initramfs.txt, то там как раз и написано, что для сборки ядра вместе с initramfs нужно добавить в конфиг строчку CONFIG_INITRAMFS_SOURCE. Ну вот система сборки и подставляет туда путь к будущему cpio архиву. Но она не умеет собирать ядро дважды - до сборки cpio и после. Больше того, заказ на правку конфига отдается на откуп внешнему скрипту, который вкурочивает CONFIG_INITRAMFS_SOURCE в $(KOBJECTS)/.config. То есть, Makefile не знает, что делает это скрип, поэтому он не может понять, собирает он initramfs или нет, до или после cpio.

 

Пока что удалось сделать еще другой хак. Надо просто вначале собрать какое-нибудь ядро без initramfs. При этом rootfs cpio все равно создается, и может быть использован для дальнейшей сборки другого ядра с initramfs.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3) Кривизна в Makefile восходит к самому ядру, как мне кажется.

 

вам кажется, потому что Linux вы познаете по кривым SDK. Вы возьмите архив ядра, соберите его вручную и посмотрите что происходит, сейчас у вас - неправильная трактовка прочитанной документации в голове, кривой SDK на руках и придуманные проблемы :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, допустим. Тогда объясните на пальцах, как правильно делать то?

 

Зачем вообще было делать систему, чтобы initramfs нужно было именно влинковывать в объектный модуль ядра? Почему нельзя было его просто прицепить к концу ядра, приделав к нему сигнатуру, и потом просто пошарить за хвостом загрузочного образа? Идеологически это было бы даже более гибко - собрал образ ядра, и потом по мере необходимости настроил любой вариант rootfs.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, допустим. Тогда объясните на пальцах, как правильно делать то?

 

Я пока так и не понял - что у вас сейчас не выходит ? если правильно понял - вам достаточно создать пустой файл на месте будущего настоящего архива cpio (у вас ядро не собирается из-за того что оно не находит архив по указанному в конфиге пути потому что архив еще не готов ?)

 

touch /home/vasya/TISDK/out_bin/rootfs.cpio

 

Почему нельзя было его просто прицепить к концу ядра, приделав к нему сигнатуру, и потом просто пошарить за хвостом загрузочного образа?

 

Я не уверн что так нельзя сделать - надо посмотреть, по крайней мере блоб device tree можно так приклеивать (сделано специально для старых загрузчиков не поддерживающих загрузку DTB).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну не выходит то, что при сборке с нуля ядра со встроенным initramfs оно не собирается. Потому что нет Build/rootfs/min-root-c6x.cpio, который сам по себе является таргетом, и зависит от сборки busybox, mtd-utils, etc. А busybox сам зависит еще от сборки ядра. И в итоге начинает то оно сборку с rootfs, но закапывается в сборку ядра, однако, с выставленным конфигом для cpio. И облом. Вот и приходится разруливать в ручном режиме.

 

Вы мне предлагаете еще один способ в ручном режиме разруливать этот казус?

 

Судя по исходнику init/initramfs.c там именно берется массив из объектного модуля ядра:

extern char __initramfs_start[], __initramfs_end[];

...

static int __init populate_rootfs(void)
{
        char *err = unpack_to_rootfs(__initramfs_start,
                         __initramfs_end - __initramfs_start);
        ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы мне предлагаете еще один способ в ручном режиме разруливать этот казус?

 

Ручного там только добавить в make-файл эту строчку перед сборкой ядра и если нужно и дописать вызов сборки повторно уже после того как собран настоящий архив (если там этого не сделано), ядро слинкутся с этим архивом без полной пересборки - то что это изененный архив make обнаружит.

 

Судя по исходнику init/initramfs.c там именно берется массив из объектного модуля ядра:

 

initramfs можно было отдельно от образа ядра загружать через параметр initrd - это 100%.

 

https://www.kernel.org/doc/Documentation/fi...s-initramfs.txt

 

External initramfs images:

--------------------------

 

If the kernel has initrd support enabled, an external cpio.gz archive can also

be passed into a 2.6 kernel in place of an initrd. In this case, the kernel

will autodetect the type (initramfs, not initrd) and extract the external cpio

archive into rootfs before trying to run /init.

Изменено пользователем sasamy

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так вот засада то в том, что для линковки ядра с нужным архивом нужно внести параметр CONFIG_INITRAMFS_SOURCE в .config и вызвать make. А когда make видит, что у ядра поменялся .config, то он начинает его заново собирать целиком.

 

initramfs можно было отдельно от образа ядра загружать через параметр initrd - это 100%.

так вот главный вопрос, откуда загружать? Основная ценность initramfs для меня именно в том, что он встроен в ядро и поднимает минимально необходимый набор инструментов до того, как примонтированы все прочие источники данных. То есть это тестовое ядро, которое можно грузить с TFTP и пускать на нем все программы, подмонтировав NFS, если нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так вот засада то в том, что для линковки ядра с нужным архивом нужно внести параметр CONFIG_INITRAMFS_SOURCE в .config и вызвать make.

 

Заканчивайте эти рекурствные головоломки, а это вы тогда про что написали ?

 

Ну не выходит то, что при сборке с нуля ядра со встроенным initramfs оно не собирается. Потому что нет Build/rootfs/min-root-c6x.cpio,

 

если этот параметр пустой то и создавать ничего не надо - там без вопросов пустышка будет сформирована, об этом я вам в самом начале написал

 

А когда make видит, что у ядра поменялся .config, то он начинает его заново собирать целиком.

 

А вы пробовали ? почему то когда я дописываю в конфиге CONFIG_INITRAMFS_SOURCE у меня только линкуется с этим архивом без пересборки :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что у Вас за загрузчик? Если что-то не очень кастрированнное, то ему можно отдельно подпихнуть два образа - ядра и initramfs. А еще можно склеить их вместе с помошью mkimage.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

U-Boot 2012.04.01 (Feb 07 2013 - 18:10:09)

bootm <Linux uImage address> <mkimage wrapped ramdisk address> <device tree (dtb) address>

Соответственно ramdisk надо обернуть mkimage.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...