Комментарии (10)

1. 

   slonopotamus

   01.03.2016 09:03

   #8787759

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

   
   

   1. 

      Frantony

      01.03.2016 12:41

      #8788045

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

      
      Полностью согласен! Я так и написал — на реальной плате запуск будет более хлопотным чем на 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 устройств в широкой продаже.
      
      А уж нетиповые ситуации потребуют нетиповых же мер.
      

1. 

   Acid_Jack

   01.03.2016 11:30

   #8787945

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

   
   

   1. 

      Frantony

      02.03.2016 01:13

      #8788883

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

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

      
      

      1. 

         Acid_Jack

         02.03.2016 18:29

         #8790837

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

         
         

         1. 

            Frantony

            03.03.2016 00:17

            #8791473

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

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

            
            

            1. 

               Acid_Jack

               03.03.2016 00:20

               #8791485

               Да.

               
               

               1. 

                  Frantony

                  03.03.2016 00:35

                  #8791523

                  Мда...
                  

                  
                  

                  1. 

                     Acid_Jack

                     03.03.2016 00:45

                     #8791541

                     Ладно, виноват. Читал через слово.
                     Получилось как в анекдоте про блондинку с вопросом «да или нет» :)
                     
                     Цель — получение рабочей операционной системы на железке с процом не самой популярной архитектуры.
                     
                     Я свой гуруплаг накататывал с нуля раза 3–4. И таких «гамаков с противогазами» себе не придумывал.

                     
                     

                     1. 

                        Frantony

                        08.03.2016 15:50

                        #8797105

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

                        
                        Внешняя цель подмечена правильно, хотя согласиться с тем, что речь идёт про процы не самой популярной архитектуры не могу; подозреваю, что 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 на реальной плате.