Comments 10
К сожалению, на практике все далеко не так просто. Например, в дебиане отсутствуют пакеты для целевой архитектуры. Или в ядре отсутствует поддержка имеющейся платы, а заодно и трех-четырех периферийных устройств.
0
К сожалению, на практике все далеко не так просто.
Полностью согласен! Я так и написал — на реальной плате запуск будет более хлопотным чем на 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 устройств в широкой продаже.
А уж нетиповые ситуации потребуют нетиповых же мер.
0
Что-то я не понял, а зачем такой изврат?
У деба есть готоые бинарные пакеты с софтом и ядрами для целой пачки архитектур, включая ARM (Hard Float и EABI) и MIPS (прямой и обратный порядок байт).
Лично у меня есть почти embedded-система в виде GuruPlug с ARM'овским процессором от Kirkwood.
Никакого изврата с QEMU и кросскомпиляцией. Тупо залил корневую ФС и ядро из официального репозитория в соответствующие разделы NAND и всё.
У деба есть готоые бинарные пакеты с софтом и ядрами для целой пачки архитектур, включая ARM (Hard Float и EABI) и MIPS (прямой и обратный порядок байт).
Лично у меня есть почти embedded-система в виде GuruPlug с ARM'овским процессором от Kirkwood.
Никакого изврата с QEMU и кросскомпиляцией. Тупо залил корневую ФС и ядро из официального репозитория в соответствующие разделы NAND и всё.
0
Никакого изврата с QEMU и кросскомпиляцией. Тупо залил корневую ФС и ядро из официального репозитория в соответствующие разделы NAND и всё.
Ну ведь образ, который надо тупо заливать в соответствующие разделы NAND, он ведь как-то делается.
В публикации как раз описывается, что делать если готовые ФС и/или ядро не подходят или вообще не существуют.
0
Образ делается debootstrap'ом, как и у автора.
Ядро в моём конкретном случае нужно только преобразовать в специальный формат для U-Boot-загрузчика (uImage насколько я помню). Но без перекомплиции. Просто скачать, распаковать, преобразовать штатными дебиновскими утилитами.
Я почему и зацепился, потому как усилий на порядок меньше получается.
Ну а если в репозитрии нет нужной архитектуры, тогда да, согласен.
Ядро в моём конкретном случае нужно только преобразовать в специальный формат для U-Boot-загрузчика (uImage насколько я помню). Но без перекомплиции. Просто скачать, распаковать, преобразовать штатными дебиновскими утилитами.
Я почему и зацепился, потому как усилий на порядок меньше получается.
Ну а если в репозитрии нет нужной архитектуры, тогда да, согласен.
0
Образ делается debootstrap'ом, как и у автора.
Ядро в моём конкретном случае нужно только преобразовать в специальный формат для U-Boot-загрузчика (uImage
насколько я помню). Но без перекомплиции. Просто скачать, распаковать, преобразовать штатными дебиновскими
утилитами.
Я почему и зацепился, потому как усилий на порядок меньше получается.
Для достижения какой цели "усилий на порядок меньше получается"?
0
Да.
0
Мда...
0
Ладно, виноват. Читал через слово.
Получилось как в анекдоте про блондинку с вопросом «да или нет» :)
Цель — получение рабочей операционной системы на железке с процом не самой популярной архитектуры.
Я свой гуруплаг накататывал с нуля раза 3–4. И таких «гамаков с противогазами» себе не придумывал.
Получилось как в анекдоте про блондинку с вопросом «да или нет» :)
Цель — получение рабочей операционной системы на железке с процом не самой популярной архитектуры.
Я свой гуруплаг накататывал с нуля раза 3–4. И таких «гамаков с противогазами» себе не придумывал.
0
Цель — получение рабочей операционной системы на железке с процом не самой популярной архитектуры.
Внешняя цель подмечена правильно, хотя согласиться с тем, что речь идёт про процы не самой популярной архитектуры не могу; подозреваю, что 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 на реальной плате.
0
Sign up to leave a comment.
RISC'овый Debian под QEMU