RISC'овый Debian под QEMU

[slonopotamus]

К сожалению, на практике все далеко не так просто. Например, в дебиане отсутствуют пакеты для целевой архитектуры. Или в ядре отсутствует поддержка имеющейся платы, а заодно и трех-четырех периферийных устройств.

[Frantony]

К сожалению, на практике все далеко не так просто.

Полностью согласен! Я так и написал — на реальной плате запуск будет более хлопотным чем на QEMU.

Например, в дебиане отсутствуют пакеты для целевой архитектуры.

Что значит "отсутствуют пакеты для целевой архитектуры"? Если для конкретной архитектуры пакеты совсем отсутствуют — тогда и вовсе не стоит говорить о существовании Debian для этой архитектуры. Вот к примеру, для RISC-V, AFAIK, Debian'а пока и нет.

А если же имеется в виду, что для MIPS/ARM нет некоторых пакетов, которые доступны для других архитектур, то да,
такая проблема есть.

На одной из моих машин с Debian в режиме Multiarch подключены сразу архитектуры i386 и mips, и я решил сравнить количество пакетов из testing main:

    $ cat /var/lib/apt/lists/ftp.ru.debian.org_debian_dists_testing_main_binary-i386_Packages | grep ^Package | sed "s/^Package: //" > /tmp/packages_list_i386
    $ cat /var/lib/apt/lists/ftp.ru.debian.org_debian_dists_testing_main_binary-mips_Packages | grep ^Package | sed "s/^Package: //" > /tmp/packages_list_mips
    $ wc -l /tmp/packages_list_*
    47430 /tmp/packages_list_i386
    45914 /tmp/packages_list_mips
    93344 total

Получается, что для mips полторы тыщёнки пакетов не доложили! Впрочем, это меньше четырёх процентов числа пакетов для i386.

С другой стороны часть пакетов для mips отсутствует по объективным причинам — ну не нужны на mips loadlin и lilo.
Кроме того, я просмотрел список отсутствующих для mips пакетов — из тех которые у всех на слуху я встретил пожалуй что только один — tomboy, остальные — это какие-то узкоспециальные пакеты, которых среднему пользователю особо и не жаль.

Или в ядре отсутствует поддержка имеющейся платы, а заодно и трех-четырех периферийных устройств.

Тут бы конкретную ситуацию обсуждать, а не все осуществимые возможности. Что значит "в ядре отсутствует поддержка"? В каком именно ядре? Если нет рабочего ядра linux, или ядро есть, но не поддерживает очень нужную периферию, то тут и говорить не о чем — либо ядро дописывать либо бросить всё как есть.

Если же речь идёт о ядре с kernel.org, то да, далеко не у всех разработчиков хватает сил/времени/желания на продвижение своих изменений ядра в kernel.org.

Самый типовой сценарий (то есть без учёта крайностей), запуска Debian на реальной плате по мотивом обсуждаемой публикации представляется мне так:

• для выбранной платы есть поддержка в ядре linux (неважно с kernel.org или с openwrt.org, или откуда ещё);
• производятся разборки по поводу того, как ядро будет попадать в плату и запускаться (припомощи штатного загрузчика, через EJTAG-ли или каким ещё чудом);
• собираем требуемое ядро;
• собираем образ rootfs Debian, как описано в публикации;
• обеспечиваем попадание Debian rootfs на плату (записываем на встроенный накопитель, на внешнюю USB-флешку, планируем грузиться в режиме nfsroot или каким ещё волшебным образом);
• запускам ядро с Debian rootfs;
• PROFIT!

Думаю, этот сценарий подходит для большинства плат разработчика (devboard) или поддерживаемых openwrt устройств в широкой продаже.

А уж нетиповые ситуации потребуют нетиповых же мер.

[Acid_Jack]

Что-то я не понял, а зачем такой изврат?
У деба есть готоые бинарные пакеты с софтом и ядрами для целой пачки архитектур, включая ARM (Hard Float и EABI) и MIPS (прямой и обратный порядок байт).
Лично у меня есть почти embedded-система в виде GuruPlug с ARM'овским процессором от Kirkwood.
Никакого изврата с QEMU и кросскомпиляцией. Тупо залил корневую ФС и ядро из официального репозитория в соответствующие разделы NAND и всё.

[Frantony]

Никакого изврата с QEMU и кросскомпиляцией. Тупо залил корневую ФС и ядро из официального репозитория в соответствующие разделы NAND и всё.

Ну ведь образ, который надо тупо заливать в соответствующие разделы NAND, он ведь как-то делается.

В публикации как раз описывается, что делать если готовые ФС и/или ядро не подходят или вообще не существуют.

[Acid_Jack]

Образ делается debootstrap'ом, как и у автора.
Ядро в моём конкретном случае нужно только преобразовать в специальный формат для U-Boot-загрузчика (uImage насколько я помню). Но без перекомплиции. Просто скачать, распаковать, преобразовать штатными дебиновскими утилитами.

Я почему и зацепился, потому как усилий на порядок меньше получается.

Ну а если в репозитрии нет нужной архитектуры, тогда да, согласен.

[Frantony]

Образ делается debootstrap'ом, как и у автора.
Ядро в моём конкретном случае нужно только преобразовать в специальный формат для U-Boot-загрузчика (uImage
насколько я помню). Но без перекомплиции. Просто скачать, распаковать, преобразовать штатными дебиновскими
утилитами.

Я почему и зацепился, потому как усилий на порядок меньше получается.

Для достижения какой цели "усилий на порядок меньше получается"?

[Acid_Jack]

Да.

[Frantony]

Мда...

[Acid_Jack]

Ладно, виноват. Читал через слово.
Получилось как в анекдоте про блондинку с вопросом «да или нет» :)

Цель — получение рабочей операционной системы на железке с процом не самой популярной архитектуры.

Я свой гуруплаг накататывал с нуля раза 3–4. И таких «гамаков с противогазами» себе не придумывал.

[Frantony]

Цель — получение рабочей операционной системы на железке с процом не самой популярной архитектуры.

Внешняя цель подмечена правильно, хотя согласиться с тем, что речь идёт про процы не самой популярной архитектуры не могу; подозреваю, что ARM как раз и является самой популярной архитектурой, см., например, новость, про то, что отметка в 50 млрд поставленных СБИС с ядром ARM преодолена в феврале 2014 года. Сравните оценки IDC по продажам в 2015 году PC (308 млн устройств) и смартфонов (1429 млн устройств); кроме смартфонов есть ещё много всяких интересных устройств, которые трудно заподозрить в использовании процессоров x86...

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

Дело в том, что публикация получилась на основе моего опыта по работе со студентами и молодыми сотрудниками, которых надо было обучать навыкам разработки ПО для не x86-процессоров: как подготавливать инструментальную ЭВМ, как настраивать инструментальные средства, как собирать и запускать ПО на целевой ЭВМ. Таким образом, публикацию, нужно рассматривать не только как рецепт для решения конкретной практической задачи, но и как учебный материал, дающий читателю некоторые начальные навыки, которые ему пригодятся когда потребуется вносить правки в ядро linux, писать baremetal ПО или даже править QEMU.

Ядро в моём конкретном случае нужно только преобразовать в специальный формат для U-Boot-загрузчика (uImage
насколько я помню). Но без перекомплиции. Просто скачать, распаковать, преобразовать штатными дебиновскими
утилитами.

В начале публикации было сказано: Debian rootfs отвязана от конкретной платы и SoC, а вот ядро linux может быть привязано к SoC и даже плате. Соответственно компоненты rootfs не грех скачать и готовые; ядро же можно скачать готовое, а можно получить из какого-то другого источника. В дальнейшем изложении эта мысль проиллюстрирована сборкой ядра с нужными опциями, тем более, что выполнить десяток коротких команд в консоли — дело не сложное. А уж с методической точки зрения лишнее упражнение по сборке ядра — только на пользу.

Я почему и зацепился, потому как усилий на порядок меньше получается.

Публикация, как говорится в начале, рассказывает о том, как можно при помощи debootstrap установить, а затем как при помощи QEMU запустить ОС Debian для ЭВМ с процессорами MIPS и ARM. Но нигде не обещается выполнить всё перечисленное с минимальными усилиями; изложение построено так, чтобы

• материал был интересен как можно большему кругу читателей (поэтому рассказано и про MIPS и про ARM; поэтому и используется эмулятор, а не реальная плата);
• были зацепки для дальнейших модификаций — чтобы можно пройти по рекомендованному в публикации маршруту, убедиться, что всё работает, а затем что-нибудь поменять: toolchain, ядро, rootfs, QEMU, сценарий загрузки; в конце концов, можно и осуществить запуск Debian на реальной плате.