Debian вместо Android для всех устройств | только для разрабов и людей, которые шарят



Реп: (12)
Здравствуйте! Наверняка я не единственный, у кого была идея полностью заменить Android на Linux на мобильном устройстве. Мотивов к этому может быть много - гибкость Linux, возможность сменить граф. оболочку, лёгкость (для слабых устройств), но ИМХО самый ключевой козырь Linux - постоянная обновляемость. В отличие от ПК, где обновления ОС зависят только от её разработчика, на мобильных устройствах обновления ПО зависят от вендоров самих устройств. А всё из-за того, что ПК у нас архитектуры x86(_64), и у них существуют стандарты аппаратуры IBM PC и загрузки BIOS/UEFI. А на мобильных устройствах у нас архитектура ARM, которая является лишь стандартом набора команд процессора. В результате на ПК мы имеем стандартный механизм загрузки, предоставляющий интерфейсы для контроля базового оборудования без драйверов со стороны ОС, что позволяет (в случае с Linux), загружать ядро без необходимости его пересборки под каждое устройство.

Сразу встаёт вопрос - "а как же дрова на остальное оборудование, не поднятое BIOS/UEFI?" В Debian/Ubuntu присутствует хитрое решение этой проблемы - система DKMS. Она позволяет единожды написать драйвер в виде модуля ядра, соответствующего формату dkms, и при обновлении ядра она автоматически оптимизирует драйвер под новую версию ядра. Таким образом, обновления ОС Debian на ПК не зависят от вендора самого ПК.

На ARM мы не имеем самого главного - стандарта загрузочной системы. На каждую плату - свой минимальный загрузчик, и для запуска на ней ядро Linux требует пропатчивания вендором, в результате обновления ядра вешаются на вендора устройства, и, зачастую отсутствуя, отключают нас от обновлений самой системы. Но мало кто знает, что под ARM тоже существует стандартный UEFI. Мною с моим RPi 3 B+ было доказано, что UEFI + Debian + DTB + DKMS = Debian ARM Anytime Upgrade.

Напрашивается закономерный вопрос: если бы мы имели UEFI под все ARM устройства, мы бы имели постоянно обновляемый Debian под все устройства?

По сути да, есть небольшая проблема с дровами, но насколько я понял при наличии навыков их можно достать из дерева исходников ядра (и даже автоматизировать этот процесс). Соответственно, самая сложная часть - UEFI. Был когда-то неплохой проект EFIDroid, позволявший собирать UEFI под все устройства с Little Kernel (т. е. все qcom устройства), но ввиду отсутствия каких-либо финансирования или поддержки автора был заброшен, причём в процессе перехода на новый способ без LK (т. к. в новых qcom устройствах его уже не используют), в результате все репозитории оказались в нерабочем состоянии. Я откатил их до рабочих версий, но так ничего и не завелось (проект-то так и остался pre-alpha). Собственно, я и создал эту тему, чтобы вынести свой вопрос на общее обозрение - есть ли люди, которые знакомы с автором EFIDroid, имеющие рабочие варианты, или знающие, есть ли автора новый вариант EFIDroid (без lk), или прочие разработчики или программисты, которые знакомы с EDK II, или у которых есть другие способы портирования UEFI на ARM(64) устройства, если в наличии только kernel source code tree для них? Есть ли вообще кто-то, кто этим интересуется и в этом "шарит"? Хотелось бы систематизировать всю имеющуюся информацию, и, возможно, даже выйдет что-то собрать.

К слову, что уже есть:
  • Сам Debian
  • 3 Qualcomm устройства: Nubia Z17 Mini, Xiaomi Redmi Note 4X 3/32 и Xiaomi Redmi 5, а также исходники ядер для этих устройств
  • Raspberry Pi и UEFI для него - https://github.com/andreiw/RaspberryPiPkg
  • Понимание механизмов загрузки LK, UEFI
  • EDK II - https://github.com/efidroid/edk2
  • "Полурабочая" версия EFIDroid (работает)- https://yadi.sk/d/uf0OViClkzWX1A
  • Непротестированная версия UEFI под Redmi Note 5 (работает всё, кроме вывода графики)
  • EFIDroid для Nubia Z17 Mini

Что хочется поиметь:
  • Работающий UEFI Debian хотя бы под одно из имеющихся у меня устройств
  • Умение запускать 64-битное ядро Linux через 32-битный UEFI


А также, если у кого-то есть способ загружать неизменённое ядро Debian на ARM устройствах, пишите сюда.

Сообщение отредактировал Edk2Arm - 30.06.19, 18:44
Причина редактирования: UEFI частично заведён



Реп: (115)
* Edk2Arm, А с какой модели проца, нету lk? И если собрать старый efidroid под 32бит процессор с lk, то получится запустить x86 дистрибктив?



Реп: (12)
* Drakonknayt, написано же - для тех кто шарит. Не путайте 32 бита и x86. LK исчез с момента выхода Snapdragon 835 в поколениях 6xx/8xx. x86 - архитектура компьютеров, а для ARM(64) мобилок с UEFI есть Debian armhf/arm64. EFIDroid сейчас застрял в таком состоянии, что его система сборки уже настроена наполовину на сборку нового решения (без lk), а утилиты для решения с LK вврезаны, а самого решения нет!



Реп: (115)
* Edk2Arm, видел ваши слова, что откатив efidroid всеравно не заработало. Значит теоретически можно завести efidroid под старые процы с lk?
Ну благодаря практике, чтению и общению с более "продвинктыми" людьми, люди начинают шарить. Если хотите, чтобы в этой теме не появлялся "оффтоп новичка", можем перейти в qms.

Сообщение отредактировал Drakonknayt - 15.06.19, 12:35



Реп: (12)
* Drakonknayt, ладно, я не про это. Да, в теории можно, но у меня не вышло. Пытался связаться с главным разрабом - не вышло. Там смотрите как всё происходит - EDK II для сборки под плату <Board> требует использования <Board>Pkg, а в EFIDroid есть такая фигня интересная - LittleKernelPkg - EDK II под все платы с Little Kernel. Но не всё так безоблачно - чтобы это всё пахало нужен не просто LK, а специальный LK со вкомпилированным uefiapi, на котором всё и стопорится, ибо он требует какой-то там разметки памяти аж из TrustZone. На GitHub у EFIDroid в разделе Issues есть решение для msm8994, но откуда там взят адрес 0x06d00000 это хз, там боюсь tz на дизассемблер тащить придётся



Реп: (138)
* Edk2Arm,
Как быть ошибка при сборке lk
error: ‘strncat’ specified bound 1 equals source length [-Werror=stringop-overflow=]
670 | strncat(filename, "/", 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

исправил
memcpy

Сообщение отредактировал Sony Xperia_98 - 06.02.20, 20:53



Реп: (12)
* Sony Xperia_98, полный лог (от возврата в bash 20 строк наверх)



Реп: (12)
* Sony Xperia_98,
ls -l /home/FaraS/Загрузки/efidroid/out/device/asus/ze550kl/lk_kernel/fdt_out



Реп: (12)
* Sony Xperia_98, они не копируются - dtbefidroidify берёт файлы из fdt_out и патчит их, а патченные кладёт в fdtpatched_out, возможно он русские пути не понимает



Реп: (138)
Edk2Arm @ 15.06.19, 19:38 *
возможно он русские пути не понимает
возможно, ну я примерно так себе и предоставлял, что пропитанные туда и кидаются. Попробую без кириллицы



Реп: (138)
* Edk2Arm, попробовал все также)



Реп: (12)
* Sony Xperia_98, у тебя strace есть?



Реп: (138)
* Edk2Arm, да



Реп: (12)
* Sony Xperia_98, тогда
strace /home/FaraS/Загрузки/efidroid/out/host/dtbtools/dtbefidroidify /home/FaraS/Загрузки/efidroid/out/device/asus/ze550kl/lk_kernel/fdt_out /home/FaraS/Загрузки/efidroid/out/device/asus/ze550kl/lk_kernel/fdtpatched_out 1 qcom



Реп: (12)
* Sony Xperia_98, а если просто
/home/FaraS/Загрузки/efidroid/out/host/dtbtools/dtbefidroidify



Реп: (138)
* Edk2Arm, может попробовать собрать другим компилятором. Clang к примеру или другой версией gcc



Реп: (12)
* Sony Xperia_98, мне нужен usage без strace



Реп: (12)
* Sony Xperia_98, странно, у меня всё компилируется. Скинь свой boot.img



Реп: (138)
* Edk2Arm, окей, кстати это boot.img от кастомной прошивки) miui на основе cm) мб сток ядро попробовать

Сообщение отредактировал Sony Xperia_98 - 21.06.19, 17:20



Реп: (12)
* Sony Xperia_98, лучше используй boot.img от стока


Полная версия   Текстовая версия

Помощь   Правила

Сейчас: 28.03.24, 23:44