[devel-sbc] UEFI и Raspberry Pi

[Alexey V. Vissarionov]

On 2020-05-11 18:24:53 +0700, Антон Мидюков wrote:

 >>>> edk2 - это полноценный UEFI, который позволяет грузить с
 >>>> флешки гибридные ISO-образы. А это полноценные live,
 >>>> инсталляторы, rescue.
 >> Все эти "полноценные live, инсталляторы, rescue" можно сделать
 >> просто на базе USB-флешки, безо всяких ISO-образов. Но тут, как
 >> всегда, "есть нюансы".
 >>>> Чем и интересен.
 >>> +1
 >> -1
 >> Вероятность того, что кто-то подключит сидюк к мелкому
 >> компутеру, пренебрежимо мала [...]
 >> Вероятность того, что этот сидюк будет использоваться в
 >> качестве загрузочного накопителя - еще меньше.
 > Речь про гибридные ISO, которые пишутся на USB-флешку.

Я понял.

 > Мы их уже собираем,

Я в курсе. Но они уже практически изжили себя - оптических приводов
практически не осталось даже на писюшатине, а без них образы ISO9660
никому не вперлись.

 > поддержка RPi будет за компанию.

"Безобразно, зато единообразно"? По-моему, немного не тот случай...

 > Это позволит снизить нагрузку на релиз-менеджеров. Также это
 > позволит тестировать образы не в qemu, а хоть на каком-то железе,
 > тем, у кого нет нормального железа aarch64 + EFI.

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

Не будут они ничего тестировать. Их вполне устраивает "шибко сильное
колдунство", если оно доступно "из коробки" и не требует постоянного
присмотра, чтобы можно было оставить ту же малину в дачном домике на
зиму, а перед выездом из города залезть на нее по SSH и сказать ей
включить обогреватели (то есть, разумеется, GPIO 17 и 18 на ногах 11
и 12, к которым подключены оптосимистор MOC3042 и симистор BTA41), и
при этом не бояться устроить в этом самом домике пожар.

 >>> Честно говоря, загрузка с USB мне кажется плюсом. Это серьезный
 >>> шаг к унификации
 >> для EFI-загрузки с USB нужна унификация содержимого ПЗУ на платах
 >> (пусть хотя бы на уровне "найти USB-флешку, найти на ней активный
 >> раздел с типом 0xEF и файловой системой FAT32, прочитать в память
 >> файл EFI/Boot/bootaa64.efi и передать ему управление"). Кто этим
 >> будет заниматься - я не знаю: производителям железяк это не нужно,
 >> производителям SoC тем более.
 > Этим занимаются разработчики u-boot, edk2 и ядра.

И U-boot, и edk2, и ядро требуют как минимум какого-то начального
загрузчика в ПЗУ. В случае с той же малиной-4 он тупой и умеет только
грузить start4.elf; на малине-3 он еще тупее и грузит bootcode.bin, и
уже он в свою очередь грузит start.elf

И уже после этой проприетарщины (которая сама по себе грузится в два,
а то и в три этапа) можно загрузить ядро. Не очень удобно, но вполне
функционально (см. выше про типового малинопользователя). Добавить
U-boot - можно (исключительно во имя унификации), но в большинстве
случаев излишне. EFI в виде edk2 на флешке - смешно. Grub - идиотизм.

 > От нас требуется только добавить нужные для загрузки модули ядра
 > в propagator (initrd).

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

Начнем с того, когда и для чего придумали initrd. Было это во времена,
когда единственным сменным накопителем были дискеты, объем которых был
чуть больше мегабайта, и загрузку системы приходилось осуществлять в
два этапа: сначала с одного диска грузилось минимальное ядро (лишь бы
поместилось на флоп), а потом со второго диска подгружался initrd с
дополнительными модулями ядра и минимальным userspace для дальнейшей
установки. Таким образом еще четверть века назад можно было поставить
Linux-систему на вполне типовой 80386SX/4M/120M/SVGA/NE2k :-)

Сейчас же initrd нужен только в двух случаях - для rescue-систем и для
сетевой загрузки. Что, в общем-то, одно и то же: в обоих случаях нельзя
пользоваться локальными накопителями (жесткими дисками).

Это не отменяет возможность использовать ядерные модули: они прекрасно
хранятся в корневом разделе, а все необходимое для доступа к нему есть
внутри ядра (покажите мне идиота, который соберет современное ядро без
CONFIG_SATA_AHCI=y, без CONFIG_USB_STORAGE=y или без CONFIG_EXT4_FS=y).
Более того: компоненты ядра, которым нужны блобы firmware, лучше всего
собирать именно модулями, так как эти блобы грузятся опять же с корня.

А вот поддержку сетевых адаптеров лучше вкомпилячивать в ядро: сильно
помогает от страшных сообщений в ядерном логе про пустой пул энтропии.

Ну и на закуску: некоторые ядерные компоненты по-разному работают при
сборке модулями и при вкомпилячивании внутрь ядра. Мой любимый пример:
при CONFIG_MD=y "открывается" доступ к параметру CONFIG_MD_AUTODETECT,
позволяющему грузиться с RAID-1 и обращаться к любым другим устройствам
SoftRAID без использования mdadm для их сборки и запуска.

В общем, люди, которые пишут ядро, заметно умнее людей, которые пишут
костыли для userspace, не сумев прочитать документацию :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net