Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: initfamfs - busybox - kernel
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Linux
Hoodwin
Вот какая загвоздка. Имеем линукс для платформы 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, пересобирай снова все ядро...
Dron_Gus
Зачем busybox'у собранное ядро?
Hoodwin
Вот это еще одна загадка, на которую я пока не имею ответа. Пока что можно констатировать как факт, что при каждом вызове make product пересобирается busybox, даже если само ядро не пересобирается. Но главная грабля в том, что initramfs встраивается в объектный модуль ядра через установку опции в конфиге при сборке ядра, а не как отдельный таргет. А было бы удобнее так:
1) Собрать ядро
2) Собрать BB
3) собрать прочие файлы для наполнения initramfs
4) сделать образ rootfs
5) Прилинковать образ initramfs к ядру.
sasamy
Цитата(Hoodwin @ Dec 5 2013, 14:42) *
Может быть есть более прямой способ сборки?


Любая сборочная система к которой не приложили руки китайцы из TI. То что вы описываете - это либо ошибка в их make-файле, либо непонимание для чего и что нужно, либо какой-то кривущий костыль специфичный для их процессора. Кстати ядро можно перелинковать с настоящим cpio архивом без извратов которые вы делаете с подстановкой "фейкового" архива, в ядре всегда автоматом создается "пустышка" для initramfs если не указан путь к cpio архиву (или путь к корню ФС - совсем не обязательно создавать cpio архив самому).
Hoodwin
1) Вообще то там чаще индусы попадаются sm.gif
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.
sasamy
Цитата(Hoodwin @ Dec 5 2013, 23:38) *
3) Кривизна в Makefile восходит к самому ядру, как мне кажется.


вам кажется, потому что Linux вы познаете по кривым SDK. Вы возьмите архив ядра, соберите его вручную и посмотрите что происходит, сейчас у вас - неправильная трактовка прочитанной документации в голове, кривой SDK на руках и придуманные проблемы sm.gif
Hoodwin
Ну, допустим. Тогда объясните на пальцах, как правильно делать то?

Зачем вообще было делать систему, чтобы initramfs нужно было именно влинковывать в объектный модуль ядра? Почему нельзя было его просто прицепить к концу ядра, приделав к нему сигнатуру, и потом просто пошарить за хвостом загрузочного образа? Идеологически это было бы даже более гибко - собрал образ ядра, и потом по мере необходимости настроил любой вариант rootfs.
sasamy
Цитата(Hoodwin @ Dec 6 2013, 00:07) *
Ну, допустим. Тогда объясните на пальцах, как правильно делать то?


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

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

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


Я не уверн что так нельзя сделать - надо посмотреть, по крайней мере блоб device tree можно так приклеивать (сделано специально для старых загрузчиков не поддерживающих загрузку DTB).
Hoodwin
Ну не выходит то, что при сборке с нуля ядра со встроенным 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);
        ...
sasamy
Цитата(Hoodwin @ Dec 6 2013, 00:45) *
Вы мне предлагаете еще один способ в ручном режиме разруливать этот казус?


Ручного там только добавить в 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.
Hoodwin
Так вот засада то в том, что для линковки ядра с нужным архивом нужно внести параметр CONFIG_INITRAMFS_SOURCE в .config и вызвать make. А когда make видит, что у ядра поменялся .config, то он начинает его заново собирать целиком.

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

так вот главный вопрос, откуда загружать? Основная ценность initramfs для меня именно в том, что он встроен в ядро и поднимает минимально необходимый набор инструментов до того, как примонтированы все прочие источники данных. То есть это тестовое ядро, которое можно грузить с TFTP и пускать на нем все программы, подмонтировав NFS, если нужно.
sasamy
Цитата(Hoodwin @ Dec 6 2013, 01:03) *
Так вот засада то в том, что для линковки ядра с нужным архивом нужно внести параметр CONFIG_INITRAMFS_SOURCE в .config и вызвать make.


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

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


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

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


А вы пробовали ? почему то когда я дописываю в конфиге CONFIG_INITRAMFS_SOURCE у меня только линкуется с этим архивом без пересборки sm.gif
Dron_Gus
Что у Вас за загрузчик? Если что-то не очень кастрированнное, то ему можно отдельно подпихнуть два образа - ядра и initramfs. А еще можно склеить их вместе с помошью mkimage.
Hoodwin
U-Boot 2012.04.01 (Feb 07 2013 - 18:10:09)
Dron_Gus
Цитата(Hoodwin @ Dec 6 2013, 13:09) *
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.
krux
почитайте
http://www.linuxfromscratch.org/lfs/view/stable/
и потом
http://cross-lfs.org/files/BOOK/2.1.0/view/
все зависимости, которые требуются для *nix и ядра - там описаны.

если вы видите что-то, что серьезно отличается по идеологии - то это с вероятностью 99% костыль для специфичной платформы.

зы. на автоматическую сборку не надейтесь. У разработчиков популярных дистрибутивов для кросс-компиляции тонны самописных полукостыльных дистрибутивозависимых скриптов в закромах, которыми это делается.
Hoodwin
ну то, что это самодельный дистрибутив, оно понятно. Просто в общем и целом, оно собирается и работает. И я не ставлю задачу переделать все это совсем правильно, просто по мере возникновения проблем пытаюсь их распрямлять по мере сил. В основном это касается ветки arch/c6x, где многие вещи сделаны были неправильно, заточены под отладки TI в ущерб повторного использования ядер для других плат. Но кое-что уже удалось распрямить.
Tarbal
Цитата(Hoodwin @ Dec 6 2013, 00:07) *
Ну, допустим. Тогда объясните на пальцах, как правильно делать то?

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



В этой книжке написано кто на ком стоял. Вроде есть более новое издание. Поищите ее, чтобы скачать. Я скачиваю книжки при помощи eMule. Он сам находит. Не скачивайте архивы. Там в основном вирусы.
http://www.freesoftwaremagazine.com/articl...ed_linux_primer
Hoodwin
Есть у меня такая книжка. Правда издания 2006 года.

Стал было читать linux from scratch, что krux советовал. Но там совсем занудно, и не наш случай. Мы не можем собирать с нуля binutils и другие вещи для архитектуры c6x. Зато они уж есть собранные. То есть, очевидно, книжку надо читать выборочно, а конкретно про initramfs в оглавлении ничего нет.
Tarbal
Цитата(Hoodwin @ Dec 12 2013, 18:37) *
Есть у меня такая книжка. Правда издания 2006 года.

Стал было читать linux from scratch, что krux советовал. Но там совсем занудно, и не наш случай. Мы не можем собирать с нуля binutils и другие вещи для архитектуры c6x. Зато они уж есть собранные. То есть, очевидно, книжку надо читать выборочно, а конкретно про initramfs в оглавлении ничего нет.


В книжке, что я дал вот что написано:
Код
6.5. Using initramfs
initramfs is a relatively new (Linux 2.6) mechanism for executing early user space programs. It is
conceptually similar to initrd, as described in the previous section. Its purpose is also similar: to
enable loading of drivers that might be required before mounting the real root file system. However,
it differs in significant ways from the initrd mechanism.
The technical implementation details differ significantly between initrd and initramfs. For example,
initramfs is loaded before the call to do_basic_setup(),
[9] which provides a mechanism for loading
firmware for devices before its driver has been loaded. For more details, the Linux kernel
documentation for this subsystem is relatively up-to-date. See
[9] do_basic_setup is called from .../init/main.c and calls do_initcalls(). This causes driver module initialization
routines to be called. This was described in detail in Chapter 5 and shown in Listing 5-10.
.../Documentation/filesystems/ramfs-rootfs-initramfs.txt.
From a practical perspective, initramfs is much easier to use. initramfs is a cpio archive, whereas
initrd is a gzipped file system image. This simple difference contributes to the easy of use of
initramfs. It is integrated into the Linux kernel source tree and is built automatically when you build
the kernel image. Making changes to it is far easier than building and loading a new initrd image.
Listing 6-13 shows the contents of the Linux kernel .../usr directory, where the initramfs image is
built. The contents of Listing 6-13 are shown after a kernel has been built.
Listing 6-13. Kernel initramfs Build Directory
$ ls -l
total 56
-rw-rw-r-- 1 chris chris 834 Mar 25 11:13 built-in.o
-rwxrwxr-x 1 chris chris 11512 Mar 25 11:13 gen_init_cpio
-rw-rw-r-- 1 chris chris 10587 Oct 27 2005 gen_init_cpio.c
-rw-rw-r-- 1 chris chris 512 Mar 25 11:13 initramfs_data.cpio
-rw-rw-r-- 1 chris chris 133 Mar 25 11:13 initramfs_data.cpio.gz
-rw-rw-r-- 1 chris chris 786 Mar 25 11:13 initramfs_data.o
-rw-rw-r-- 1 chris chris 1024 Oct 27 2005 initramfs_data.S
-rw-rw-r-- 1 chris chris 113 Mar 25 11:13 initramfs_list
-rw-rw-r-- 1 chris chris 1619 Oct 27 2005 Kconfig
-rw-rw-r-- 1 chris chris 2048 Oct 27 2005 Makefile
The file initramfs_list contains a list of files that will be included in the initramfs archive. The
default for recent Linux kernels looks like this:
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
dir /root 0700 0 0
This produces a small default directory structure containing the /root and /dev top-level directories,
as well as a single device node representing the console. Add to this file to build your own initramfs.
You can also specify a source for your initramfs files via the kernel-configuration facility. Enable
INITRAMFS_SOURCE in your kernel configuration and point it to a location on your development
workstation; the kernel build system will use those files as the source for your initramfs image.
The final output of this build directory is the initramfs_data_cpio.gz file. This is a compressed
archive containing the files you specified (either through the initramfs_list or via the
INITRAMFS_SOURCE kernel-configuration option). This archive is linked into the final kernel image. This
is another advantage of initramfs over initrd: There is no need to load a separate initrd image at
boot time, as is the case with initrd.


http://www.cs.rit.edu/~mjh/books/EmbeddedLinuxPrimer.pdf
Hoodwin
Tarbal
Ну и как этот текст помогает решить исходную проблему, описанную вначале темы?

Напомню, с помощью CONFIG_INITRAMFS_SOURCE уже готовый архив cpio линкуется к ядру, и становится встроенным массивом данных, начиная с __initramfs_start и до __initramfs_end. Вот кусок из init/initramfs.c:
Код
static int __init populate_rootfs(void)
{
        char *err = unpack_to_rootfs(__initramfs_start,
                         __initramfs_end - __initramfs_start);


Так вот, мне для тестовой системы нужен rootfs с busybox И еще кучей драйверов и софта, а make их собирается делать после сборки ядра, и возникает порочный круг. Порочный круг дает два эффекта:
1) При сборке системы с нуля оно не может собрать ядро.
2) При внесении изменений в состав rootfs они попадают в загрузочный образ ядра только со второго раза.
И вот никто в двух словах не может объяснить, как это победить на уровне makefile, а не придумывать разные ручные хаки.

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

Нынешние Makrefile-ы писаны людьми, которые вообще портировали линукс на платформу c6x. Я их кое где поправил, чтобы собиралось мое ядро, а не только для TI-ных EVM, но в целом они работоспособные. И я не склонен считать их "криворукими китайцами", которые не знают как должен выглядеть правильный порядок сборки ядра.
sasamy
Цитата(Hoodwin @ Dec 13 2013, 01:22) *
И вот никто в двух словах не может объяснить, как это победить на уровне makefile, а не придумывать разные ручные хаки.


То что вы описывали
Цитата
А было бы удобнее так:
1) Собрать ядро
2) Собрать BB
3) собрать прочие файлы для наполнения initramfs
4) сделать образ rootfs
5) Прилинковать образ initramfs к ядру.


в нормальных системах сборки именно так и работает - что тут еще объяснять ?

http://git.buildroot.net/buildroot/tree/linux/linux.mk#n172
http://git.buildroot.net/buildroot/tree/fs...nitramfs.mk#n10
http://git.buildroot.net/buildroot/tree/linux/linux.mk#n312
"rebuild" в данном случае означает простую линковку с образом настоящей корневой вместо фейковой - полной пересборки ядра не происходит на последнем этапе.

Цитата
Например, если бы можно было rootfs пришивать в конец ядра, а не влинковывать


и это тоже далется по щелчку пальца - вы же не читаете что вам пишут

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


стоит погуглить mkimage multi image - куча ссылок как их создавать
http://www.isysop.com/unpacking-and-repack...t-uimage-files/

осталось посмотреть на параметр ядра
http://lxr.free-electrons.com/source/Docum...eters.txt#L1206

и что произойдет если вместо рамдиска ядро обнаружит там initramfs
http://lxr.free-electrons.com/source/Docum...tramfs.txt#L217

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


Чтобы правильно сделать - это же думать надо, а они делают "лишь бы что-то работало". Видел я техасовские SDK для их давинчей, ерунда полная - набор кривых make-файлов, такое ощущение что их писали школьники - настолько примитивно сделано.
Hoodwin
sasamy

1) У меня проблема в том, что образ ядра грузится по TFTP, а параметр initrd, который Вы упоминаете, описан как filename, который содержит образ рамдиска. То, что с 2.6 можно туда тоже подпихнуть initramfs, я прочитал, но непонятно, как ядро найдет по этому имени что-то, если образ загружен по tftp. Обычный initrd в дескотоповой системе ссылается на /boot/inird-..., и ядро, видимо как-то монтирует сам boot раздел. В моем случае такого раздела нет, и поэтому это вариант я пока не смотрел.

2) Образ uImage с двумя файлами внутри уже интереснее. Из примера следует, что образ рамдиска встроен в uImage в виде второго файла. Однако пока непонятен механизм, как ядро узнает о наличии этого образа? Насколько я понимаю, ядро само по себе не обучено взаимодействовать с u-boot. Наоборот, U-boot скармливает ядру необходимые опции. А тут речь идет о том, как научить ядро находить по имени, подставленному в initrd=, собственно файл с образом initramfs.

3) Вот этот вот комментарий (http://git.buildroot.net/buildroot/tree/linux/linux.mk#n172)
Цитата
# As the kernel gets compiled before root filesystems are
# built, we create a fake cpio file. It'll be
# replaced later by the real cpio archive, and the kernel will be
# rebuilt using the linux26-rebuild-with-initramfs target
.

доказывает, что проблема существует, и что ядро действительно надо собирать дважды через его собственные Makefile-ы, чтобы получить результат. То есть эта "ерунда" из ядра произрастает, а все кто вокруг как-то под это подстраиваются. c6x еще на предыдущей ступени развития в этой части.

4) Любой большой проект включает в себя этапы, в соответствии с которыми что-то делается фундаментально и сразу, а что-то упрощенно, как временная мера, просто потому, что сразу на все ресурсов не хватает. Наша задача - разобраться в том, что есть, и развить то, что нам необходимо. Все в детстве писают в штаны, но потом все налаживается.
sasamy
Цитата(Hoodwin @ Dec 13 2013, 10:02) *
1) У меня проблема в том, что образ ядра грузится по TFTP, а параметр initrd, который Вы упоминаете, описан как filename


У вас проблема со чтением
Цитата
initrd= [BOOT] Specify the location of the initial ramdisk


где вы тут filename увидели ? к тому же с u-boot этот параметр будет не нужен (зря я про него упомянул), он автоматически передаст адрес рамдиска ядру через загрузочный тег при загрузке имиджа командой bootm
http://www.simtec.co.uk/products/SWLINUX/f...cle.html#d0e383

по какому адресу расположить этот образ в памяти можно задать в параметрах mkimage при создании образа рамдиска, но скорей всего даже этого не надо будет - u-boot сам вычислит расположение рамдиска так как информация где расположены файлы в multi-file имидже у него есть.

там как раз описан еще метод про который я предполагал что он есть:
Цитата
make ARCH=arm help
...
Architecture specific targets (arm):
* zImage - Compressed kernel image (arch/arm/boot/zImage)
Image - Uncompressed kernel image (arch/arm/boot/Image)
* xipImage - XIP kernel image, if configured (arch/arm/boot/xipImage)
uImage - U-Boot wrapped zImage
bootpImage - Combined zImage and initial RAM disk
(supply initrd image via make variable INITRD=<path>)

...


Цитата
ядро действительно надо собирать дважды

дважды запускать сборку нужно если нужны динамические модули ядра - чтобы они оказались в корневой ФС нужно их сначала собрать, а потом слинковать ядро с этой ФС - какой "фатальный недостаток" вы в этом увидели ?
Hoodwin
sasamy

Цитата
У вас проблема со чтением
Цитата
initrd= [BOOT] Specify the location of the initial ramdisk

где вы тут filename увидели ?


У Вас проблема с культурой общения. Что-то мешает вести себя менее заносчиво?

Конкретно про filename прочитал тут:
https://wiki.debian.org/Initrd

Цитата
initrd kernel parameter

The initrd=filename kernel parameter Specify the location of the initial ramdisk (which can be either a plain 2.4's initrd or a 2.6's initramfs).


проблема не в том, как трактовать описание initrd, а в том, как по этому параметру ядро найдет образ initramfs, если оно само загружено по tftp.

Я не уверен, что нынешняя сборка linux для c6x и текущая сборка u-boot поддерживает передачу образа initrd через указатель. Не видел этого в исходниках.
sasamy
Цитата
Конкретно про filename прочитал тут:


с наскоку не могу найти в доках но через этот параметр можно передать физической адрес в памяти и размер рамдиска
initrd=phys_addr_offset,size
по крайней мере на архитектуре arm

Цитата
Я не уверен, что нынешняя сборка linux для c6x и текущая сборка u-boot поддерживает передачу образа initrd через указатель. Не видел этого в исходниках.


задайте этот вопрос лучше сотрудникам TI
Dron_Gus
Цитата(Hoodwin @ Dec 13 2013, 13:45) *
Я не уверен, что нынешняя сборка linux для c6x и текущая сборка u-boot поддерживает передачу образа initrd через указатель. Не видел этого в исходниках.

В чем проблема проверить?
Еще раз приведу формат команды bootm:
Код
bootm <Linux uImage address> <mkimage wrapped ramdisk address> <device tree (dtb) address>
Hoodwin
Да проверю, конечно. Просто сейчас текучки много, не хватает времени глубоко копать. Дело в том, что bootm передает управление в кастомную функцию (arch/c6x/lib/bootm.c):
Код
int do_bootm_linux(int flag, int argc, char * const argv[],
        bootm_headers_t *images)
{
        void (*kernel)() = (void *)images->ep;
        char *commandline = getenv("bootargs");
        if (commandline) {
                char *dst = (char *)images->ep + 0x1000;
                strncpy(dst, commandline, 1023);
                dst[1023] = 0;
        }
        {
                unsigned int *ptr = (unsigned int *)0xc1f00000;
                ptr[0] = 0x64000001; /*TAG_SOL*/
                ptr[1] = 0; /*size SOL*/
                ptr[2] = 0x64000002; /*TAG_EOL*/
                ptr[3] = 0;
        }
        asm("MVKL .S1 0x54694265,A4");
        asm("MVKH .S1 0x54694265,A4");
        asm("MVKL .S2 0xc1f00000,B4");  // это бред
        asm("MVKH .S2 0xc1f00000,B4"); // это тоже бред
        kernel();
        printf("after kernel\n");
        return 1;
}


То есть, как видно, ничего оно никуда не передает, только комстроку копирует. А вот как сказать ядру, что есть еще какие-то данные я пока не знаю. Это через тэги над сделать, или указателем в регистре?
Dron_Gus
Цитата(Hoodwin @ Dec 16 2013, 16:08) *
Да проверю, конечно. Просто сейчас текучки много, не хватает времени глубоко копать. Дело в том, что bootm передает управление в кастомную функцию (arch/c6x/lib/bootm.c):
Код
int do_bootm_linux(int flag, int argc, char * const argv[],
        bootm_headers_t *images)
{
        void (*kernel)() = (void *)images->ep;
        char *commandline = getenv("bootargs");
        if (commandline) {
                char *dst = (char *)images->ep + 0x1000;
                strncpy(dst, commandline, 1023);
                dst[1023] = 0;
        }
        {
                unsigned int *ptr = (unsigned int *)0xc1f00000;
                ptr[0] = 0x64000001; /*TAG_SOL*/
                ptr[1] = 0; /*size SOL*/
                ptr[2] = 0x64000002; /*TAG_EOL*/
                ptr[3] = 0;
        }
        asm("MVKL .S1 0x54694265,A4");
        asm("MVKH .S1 0x54694265,A4");
        asm("MVKL .S2 0xc1f00000,B4");  // это бред
        asm("MVKH .S2 0xc1f00000,B4"); // это тоже бред
        kernel();
        printf("after kernel\n");
        return 1;
}


То есть, как видно, ничего оно никуда не передает, только комстроку копирует. А вот как сказать ядру, что есть еще какие-то данные я пока не знаю. Это через тэги над сделать, или указателем в регистре?

Почитайте про ATAG'и. Там, где у вам написано "бред" как раз и идет передача указателя на атаги. А чуть выше они заполняются. Где-то там вам надо добавить еще один ATAG, указывающий на initrd.
И посмотрите как это сделано на других архитектурах. ARM хороший пример.
Hoodwin
А, ну я там подписал в комментарии "бред", так как адрес то напрямую в коде писать нельзя, он зависит от SOC, под который собирается U-BOOT. Предыдущий автор его написал в таком стиле конкретно под свой C6745, а я пока не занимался причесыванием этого кода. К счастью, он попадает в SDRAM в моем случае.

Про ARM почитаю, спасибо за ссылку.
Hoodwin
Вот я смотрю в своем ядре (2.6.34), тэги для рамдиска только для ARM и реализованы, больше нигде нет.

Какой вообще статус этого кода? Вот я залез в git для ядра 3.10, там организация исходного кода тэгов отличается от того, что есть у меня.
(https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/kernel?id=refs/tags/v3.10.24)

например, в 2.6.34 еще есть какие-то намеки на работу с тегами для c6x, а в 3.10 там уже ничего нет, во всяком случае в setup_arch никаких намеков не осталось.
Dron_Gus
Вполне может быть, что и не прижилось. Я работаю в основном с армами. Есть архитектуры, где исторически параметры ядру передаются по-другому.
Hoodwin
Ладно, пока решил перенести код с армов, там вполне себе развитый набор тегов как в ядре, так и в u-boot.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.