Single-board computer software development discussions
 help / color / mirror / Atom feed
* [devel-sbc] UEFI и Raspberry Pi
  @ 2020-05-08 16:07 ` Антон Мидюков
  2020-05-08 17:20   ` Сергей Бессонов
  2020-05-11  7:50   ` Антон Мидюков
  0 siblings, 2 replies; 23+ messages in thread
From: Антон Мидюков @ 2020-05-08 16:07 UTC (permalink / raw)
  To: devel-sbc

Доброго времени суток

Продолжаю делиться информацией о продвижении проекта по созданию 
полноценного UEFI для Raspberry Pi 3 и 4.

Начну с того, что собирать собственную сборку стало не актуально. 
Проекты оперативно релизятся на github:

https://github.com/pftf/RPi3

https://github.com/pftf/RPi4

Минус: нельзя сделать одну сборку для обеих плат. За прошедшие пару 
месяцев было несколько релизов.

Важные изменения:

1. Из обеих сборок убрали встроенные dtb файлы. Была починена загрузка 
сторонних dtb, теперь работает загрузка оверлеев.

Как следствие на Raspberry Pi 3 работает 3D-ускорение и изменение 
разрешения экрана, если прописать в config.txt:

dtoverlay=vc4-kms-v3d

Проверено на ядре un-def.

2. На Raspberry Pi 4 в режиме deveicetree можно включить подддержку 4 ГБ 
оперативной памяти. Но в режиме devicetree грузятся только ядра rpi-un и mp.

Загрузка с SD-карты всё также не работает. У ядра rpi-un цвета 
инвертированы. Если прописать в config.txt:

dtoverlay=vc4-fkms-v3d

то доступные разрешения экрана: 1024x768, 800x600, 640x480; цвета 
отображаются нормально, 3D ускорение программное.

У обоих ядер работает ethernet, не работают wi-fi и звук. SD-карта работает.

3. Теперь нормально работает последовательная консоль

Помимо этого попробовал грузиться с u-boot в режиме UEFI, т.е. через 
grub-efi. С последней версией dtb:

https://github.com/raspberrypi/firmware/raw/master/boot/bcm2711-rpi-4-b.dtb

Удалось загрузиться только с ядром rpi-un. Но в отличие от edk2 работает 
wi-fi, нет проблемы с инверсией цветов. Но также не работает звук.

Если использовать более старую dtb, то не работает usb, но грузятся 
другие ядра.

Так что процесс идёт, успехи есть.

P.s.: Только сейчас увидел, что письмо в devel-distro заслал до этого :-]

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-08 16:07 ` [devel-sbc] UEFI и Raspberry Pi Антон Мидюков
@ 2020-05-08 17:20   ` Сергей Бессонов
  2020-05-11  8:01     ` Антон Мидюков
  2020-05-11  7:50   ` Антон Мидюков
  1 sibling, 1 reply; 23+ messages in thread
From: Сергей Бессонов @ 2020-05-08 17:20 UTC (permalink / raw)
  To: devel-sbc

Доброго!

В Пт, 08/05/2020 в 23:07 +0700, Антон Мидюков пишет:
> Доброго времени суток
> 
> Продолжаю делиться информацией о продвижении проекта по созданию 
> полноценного UEFI для Raspberry Pi 3 и 4.
> 
> 2. На Raspberry Pi 4 в режиме deveicetree можно включить подддержку 4
> ГБ 
> оперативной памяти. Но в режиме devicetree грузятся только ядра rpi-
> un и mp.
> 
> Загрузка с SD-карты всё также не работает.

Позавчера весьма удивился, что Oracle (и CentOS), оказывается, делает
образ Oracle Linux для Raspberry Pi.

И он грузится с SD карты через UEFI, и там доступно 4Гб, я попробовал.

https://www.oracle.com/linux/downloads/linux-arm-downloads.html

-- 
Сергей Бессонов

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-08 16:07 ` [devel-sbc] UEFI и Raspberry Pi Антон Мидюков
  2020-05-08 17:20   ` Сергей Бессонов
@ 2020-05-11  7:50   ` Антон Мидюков
    2020-05-11  9:01     ` Denis Pynkin
  1 sibling, 2 replies; 23+ messages in thread
From: Антон Мидюков @ 2020-05-11  7:50 UTC (permalink / raw)
  To: devel-sbc

08.05.2020 23:07, Антон Мидюков пишет:
> Доброго времени суток
>
> Продолжаю делиться информацией о продвижении проекта по созданию 
> полноценного UEFI для Raspberry Pi 3 и 4.
>
> Начну с того, что собирать собственную сборку стало не актуально. 
> Проекты оперативно релизятся на github:
>
> https://github.com/pftf/RPi3
>
> https://github.com/pftf/RPi4
>
> Минус: нельзя сделать одну сборку для обеих плат. [...]

Я собрал новый edk2 для Raspberry Pi 3 и 4 и обновил архив с обоими UEFI:

http://nightly.altlinux.org/sisyphus-aarch64/alpha/RPi_EFI.zip

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-08 17:20   ` Сергей Бессонов
@ 2020-05-11  8:01     ` Антон Мидюков
  2020-05-11  8:07       ` Сергей Бессонов
  0 siblings, 1 reply; 23+ messages in thread
From: Антон Мидюков @ 2020-05-11  8:01 UTC (permalink / raw)
  To: devel-sbc

09.05.2020 00:20, Сергей Бессонов пишет:
> Доброго!
>
> В Пт, 08/05/2020 в 23:07 +0700, Антон Мидюков пишет:
>> Доброго времени суток
>>
>> Продолжаю делиться информацией о продвижении проекта по созданию
>> полноценного UEFI для Raspberry Pi 3 и 4.
>>
>> 2. На Raspberry Pi 4 в режиме deveicetree можно включить подддержку 4
>> ГБ
>> оперативной памяти. Но в режиме devicetree грузятся только ядра rpi-
>> un и mp.
>>
>> Загрузка с SD-карты всё также не работает.
> Позавчера весьма удивился, что Oracle (и CentOS), оказывается, делает
> образ Oracle Linux для Raspberry Pi.
>
> И он грузится с SD карты через UEFI, и там доступно 4Гб, я попробовал.
>
> https://www.oracle.com/linux/downloads/linux-arm-downloads.html

Я посмотрел на RPi4. Там u-boot в режиме UEFI грузит grub-efi. В grub 
можно только при помощи последовательного порта двигаться, нет 
возможности грузиться с USB. wi-fi из коробки не доступен (доступен ли 
вообще, надо проверять). Ну и это типа серверная сборка, надо графику 
ставить. Suse предлагает такой же тип загрузки, но с графикой.

Мы тоже можем использовать такой тип загрузки. В конце первого письма я 
именно про неё и писал:

08.05.2020 21:51, Антон Мидюков пишет:
> Помимо этого попробовал грузиться с u-boot в режиме UEFI, т.е. через 
> grub-efi. С последней версией dtb:
>
> https://github.com/raspberrypi/firmware/raw/master/boot/bcm2711-rpi-4-b.dtb 
>
>
> Удалось загрузиться только с ядром rpi-un. Но в отличие от edk2 
> работает wi-fi, нет проблемы с инверсией цветов. Но также не работает 
> звук.
>
> Если использовать более старую dtb, то не работает usb, но грузятся 
> другие ядра. 

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-11  8:01     ` Антон Мидюков
@ 2020-05-11  8:07       ` Сергей Бессонов
  2020-05-11  8:19         ` Антон Мидюков
  0 siblings, 1 reply; 23+ messages in thread
From: Сергей Бессонов @ 2020-05-11  8:07 UTC (permalink / raw)
  To: devel-sbc

В Пн, 11/05/2020 в 15:01 +0700, Антон Мидюков пишет:
> 09.05.2020 00:20, Сергей Бессонов пишет:
> > Доброго!
> > 
> > В Пт, 08/05/2020 в 23:07 +0700, Антон Мидюков пишет:
> > > Доброго времени суток
> > > 
> > > Продолжаю делиться информацией о продвижении проекта по созданию
> > > полноценного UEFI для Raspberry Pi 3 и 4.
> > > 
> > > 2. На Raspberry Pi 4 в режиме deveicetree можно включить
> > > подддержку 4
> > > ГБ
> > > оперативной памяти. Но в режиме devicetree грузятся только ядра
> > > rpi-
> > > un и mp.
> > > 
> > > Загрузка с SD-карты всё также не работает.
> > Позавчера весьма удивился, что Oracle (и CentOS), оказывается,
> > делает
> > образ Oracle Linux для Raspberry Pi.
> > 
> > И он грузится с SD карты через UEFI, и там доступно 4Гб, я
> > попробовал.
> > 
> > https://www.oracle.com/linux/downloads/linux-arm-downloads.html
> 
> Я посмотрел на RPi4. Там u-boot в режиме UEFI грузит grub-efi. В
> grub 
> можно только при помощи последовательного порта двигаться, нет 
> возможности грузиться с USB. wi-fi из коробки не доступен (доступен
> ли 
> вообще, надо проверять). Ну и это типа серверная сборка, надо
> графику 
> ставить. Suse предлагает такой же тип загрузки, но с графикой.
> 
> Мы тоже можем использовать такой тип загрузки. В конце первого письма
> я 
> именно про неё и писал:

Я так понял из предыдущего письма, при этом не получается загрузиться с
SD карты, а Oracle грузится с неё.

> 08.05.2020 21:51, Антон Мидюков пишет:
> > Помимо этого попробовал грузиться с u-boot в режиме UEFI, т.е.
> > через 
> > grub-efi. С последней версией dtb:
> > 
> > https://github.com/raspberrypi/firmware/raw/master/boot/bcm2711-rpi-4-b.dtb 
> > 
> > 
> > Удалось загрузиться только с ядром rpi-un. Но в отличие от edk2 
> > работает wi-fi, нет проблемы с инверсией цветов. Но также не
> > работает 
> > звук.
> > 
> > Если использовать более старую dtb, то не работает usb, но
> > грузятся 
> > другие ядра. 
-- 
Сергей Бессонов

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-11  8:07       ` Сергей Бессонов
@ 2020-05-11  8:19         ` Антон Мидюков
    0 siblings, 1 reply; 23+ messages in thread
From: Антон Мидюков @ 2020-05-11  8:19 UTC (permalink / raw)
  To: devel-sbc

11.05.2020 15:07, Сергей Бессонов пишет:
> В Пн, 11/05/2020 в 15:01 +0700, Антон Мидюков пишет:
>> 09.05.2020 00:20, Сергей Бессонов пишет:
>>> Доброго!
>>>
>>> В Пт, 08/05/2020 в 23:07 +0700, Антон Мидюков пишет:
>>>> Доброго времени суток
>>>>
>>>> Продолжаю делиться информацией о продвижении проекта по созданию
>>>> полноценного UEFI для Raspberry Pi 3 и 4.
>>>>
>>>> 2. На Raspberry Pi 4 в режиме deveicetree можно включить
>>>> подддержку 4
>>>> ГБ
>>>> оперативной памяти. Но в режиме devicetree грузятся только ядра
>>>> rpi-
>>>> un и mp.
>>>>
>>>> Загрузка с SD-карты всё также не работает.
>>> Позавчера весьма удивился, что Oracle (и CentOS), оказывается,
>>> делает
>>> образ Oracle Linux для Raspberry Pi.
>>>
>>> И он грузится с SD карты через UEFI, и там доступно 4Гб, я
>>> попробовал.
>>>
>>> https://www.oracle.com/linux/downloads/linux-arm-downloads.html
>> Я посмотрел на RPi4. Там u-boot в режиме UEFI грузит grub-efi. В
>> grub
>> можно только при помощи последовательного порта двигаться, нет
>> возможности грузиться с USB. wi-fi из коробки не доступен (доступен
>> ли
>> вообще, надо проверять). Ну и это типа серверная сборка, надо
>> графику
>> ставить. Suse предлагает такой же тип загрузки, но с графикой.
>>
>> Мы тоже можем использовать такой тип загрузки. В конце первого письма
>> я
>> именно про неё и писал:
> Я так понял из предыдущего письма, при этом не получается загрузиться с
> SD карты, а Oracle грузится с неё.

Через u-boot можно загрузиться только с SD-карты. Через edk2 можно 
загрузиться только через USB.

Это совершенно разные загрузчики. u-boot предоставляет минимальную 
совместимость с UEFI, только чтобы grub-efi загрузить. edk2 - это 
полноценный UEFI, который позволяет грузить с флешки гибридные 
ISO-образы. А это полноценные live, инсталляторы, rescue. Чем и интересен.

На RPi3 edk2 уже можно использовать. Всё работает не хуже, чем через 
u-boot. Можно скачать iso-образ стартеркита (aarch64) и установить его. 
Например, на SD-карту или USB жёсткий диск. Дополнительно только нужно 
отключить ждущий режим, он не работает ни где и ни у кого, насколько мне 
известно.

>> 08.05.2020 21:51, Антон Мидюков пишет:
>>> Помимо этого попробовал грузиться с u-boot в режиме UEFI, т.е.
>>> через
>>> grub-efi. С последней версией dtb:
>>>
>>> https://github.com/raspberrypi/firmware/raw/master/boot/bcm2711-rpi-4-b.dtb
>>>
>>>
>>> Удалось загрузиться только с ядром rpi-un. Но в отличие от edk2
>>> работает wi-fi, нет проблемы с инверсией цветов. Но также не
>>> работает
>>> звук.
>>>
>>> Если использовать более старую dtb, то не работает usb, но
>>> грузятся
>>> другие ядра.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  @ 2020-05-11  8:23       ` Антон Мидюков
    0 siblings, 1 reply; 23+ messages in thread
From: Антон Мидюков @ 2020-05-11  8:23 UTC (permalink / raw)
  To: devel-sbc

11.05.2020 15:07, Aleksey Novodvorsky пишет:
> пн, 11 мая 2020 г., 10:50 Антон Мидюков <midyukov-anton@ya.ru>:
>
>> 08.05.2020 23:07, Антон Мидюков пишет:
>>> Доброго времени суток
>>>
>>> Продолжаю делиться информацией о продвижении проекта по созданию
>>> полноценного UEFI для Raspberry Pi 3 и 4.
>>>
>>> Начну с того, что собирать собственную сборку стало не актуально.
>>> Проекты оперативно релизятся на github:
>>>
>>> https://github.com/pftf/RPi3
>>>
>>> https://github.com/pftf/RPi4
>>>
>>> Минус: нельзя сделать одну сборку для обеих плат. [...]
>> Я собрал новый edk2 для Raspberry Pi 3 и 4 и обновил архив с обоими UEFI:
>>
>> http://nightly.altlinux.org/sisyphus-aarch64/alpha/RPi_EFI.zip
> Спасибо, Антон!
>
> Что теперь не работает?  :)
Это те же самые UEFI только нашей сборки. Изменение только в том, что 
этот архив подходит сразу для RPi3 и RPi4.  Также в config.txt прописан 
оверлей для включения 3D на RPi3.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  @ 2020-05-11  8:53           ` Alexey V. Vissarionov
  2020-05-11  9:12           ` Антон Мидюков
  1 sibling, 0 replies; 23+ messages in thread
From: Alexey V. Vissarionov @ 2020-05-11  8:53 UTC (permalink / raw)
  To: Single-board computer software development discussions

On 2020-05-11 11:35:28 +0300, Aleksey Novodvorsky wrote:

 > И ещё. Есть ли возможность сборки 32-битных armh- образов для
 > тех же RPI 3 и 4? Последнее полезно для отладки образов armh

Теоретически - да, можно. На практике - как минимум на RPi4 будет
недоступна часть памяти (максимум 3 Гб) и не будет работать USB.

На RPi3 оно, скорее всего, заработает (там всего 1 Гб ОЗУ и USB
сделан через встроенный огрызок), но смысла в такой системе лично
я не вижу: поэкспериментировать можно с более дешевыми (и при этом
заметно менее кривыми) железяками на каком-нибудь AllWinner (что
вижу, про то пою: у меня тут Banana Pi R1 на A20 и Orange Pi PC на
H3 пасутся).

 > на типовых массовых железках, которыми являются RPI*.

Массовых? Ну, может быть...

Типовых? Я бы эти кривулины так не назвал. В отличие, например,
от железяк на AllWinner, AMLogic, Huawei, MediaTek и RockChip.


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


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-11  7:50   ` Антон Мидюков
  @ 2020-05-11  9:01     ` Denis Pynkin
  2020-05-11  9:16       ` Антон Мидюков
  1 sibling, 1 reply; 23+ messages in thread
From: Denis Pynkin @ 2020-05-11  9:01 UTC (permalink / raw)
  To: Single-board computer software development discussions

On Mon, May 11, 2020 at 02:50:40PM +0700, Антон Мидюков wrote:
> 08.05.2020 23:07, Антон Мидюков пишет:
> > Продолжаю делиться информацией о продвижении проекта по созданию 
> > полноценного UEFI для Raspberry Pi 3 и 4.
> >
> > Начну с того, что собирать собственную сборку стало не актуально. 
> > Проекты оперативно релизятся на github:
> >
> > https://github.com/pftf/RPi3
> >
> > https://github.com/pftf/RPi4
> >
> > Минус: нельзя сделать одну сборку для обеих плат. [...]
> 
> Я собрал новый edk2 для Raspberry Pi 3 и 4 и обновил архив с обоими UEFI:
> 
> http://nightly.altlinux.org/sisyphus-aarch64/alpha/RPi_EFI.zip

Такой вопрос -- откуда взяты bcm-271*.dtb файлы? Из официального firmware
репозитория? Или самостоятельно делали с помощью Альтовской
инфраструктуры?

Как раз начал возиться с Rpi3/4, правда у нас u-boot в приоритете.

--
wbr,d4s


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
    2020-05-11  8:53           ` Alexey V. Vissarionov
@ 2020-05-11  9:12           ` Антон Мидюков
    1 sibling, 1 reply; 23+ messages in thread
From: Антон Мидюков @ 2020-05-11  9:12 UTC (permalink / raw)
  To: devel-sbc

11.05.2020 15:35, Aleksey Novodvorsky пишет:
> пн, 11 мая 2020 г., 11:23 Антон Мидюков <midyukov-anton@ya.ru>:
>
>> 11.05.2020 15:07, Aleksey Novodvorsky пишет:
>>> пн, 11 мая 2020 г., 10:50 Антон Мидюков <midyukov-anton@ya.ru>:
>>>
>>>> 08.05.2020 23:07, Антон Мидюков пишет:
>>>>> Доброго времени суток
>>>>>
>>>>> Продолжаю делиться информацией о продвижении проекта по созданию
>>>>> полноценного UEFI для Raspberry Pi 3 и 4.
>>>>>
>>>>> Начну с того, что собирать собственную сборку стало не актуально.
>>>>> Проекты оперативно релизятся на github:
>>>>>
>>>>> https://github.com/pftf/RPi3
>>>>>
>>>>> https://github.com/pftf/RPi4
>>>>>
>>>>> Минус: нельзя сделать одну сборку для обеих плат. [...]
>>>> Я собрал новый edk2 для Raspberry Pi 3 и 4 и обновил архив с обоими
>> UEFI:
>>>> http://nightly.altlinux.org/sisyphus-aarch64/alpha/RPi_EFI.zip
>>> Спасибо, Антон!
>>>
>>> Что теперь не работает?  :)
>> Это те же самые UEFI только нашей сборки. Изменение только в том, что
>> этот архив подходит сразу для RPi3 и RPi4.  Также в config.txt прописан
>> оверлей для включения 3D на RPi3.
>>
> Так что не работает на rpi4, кроме 3d?

edk2 для RPi4 позволяет грузиться в двух режимах: devicetree и ACPI 
(дефолт).

В режиме ACPI имеем:

- ограничение оперативной памяти в 3 ГБ

- не работют ни wi-fi, ни ethernet

- не работает SD-карта

- не работает аудио

- не работает 3D

- зато грузятся все наши ядра, кроме rpi-un, собранного без поддержки 
ACPI (пробовали ему включить ACPI, загрузился, но плюсов от этого не было)

В режиме devicetree:

- доступны все 4 ГБ оперативной памяти

- доступна SD-карта

- не работает wi-fi, работает ethernet

- не работает аудио

- не работает 3D

- грузятся только ядра mp и rpi-un. У rpi-un наблюдается инверсия 
цветовой гаммы.

> Можем ли мы перейти на эту схему для сборок продуктов на стабильных бранчах?

edk2 для RPi4 не готово. Поддержку в ISO-образы добавить необходимо. 
Пока можно будет рекомендовать только для RPi3. Как будет готова edk2 
для RPi4, скорее всего наши уже постаревшие сборки ISO, будут на нём 
полноценно грузиться и работать.

Пока стоит смотреть связку u-boot +EFI. У некоторых других дистрибутивов 
она работает. Надо разбираться, почему у нас с этим проблемы.

> И ещё. Есть ли возможность сборки 32-битных armh- образов для тех же RPI 3
> и 4? Последнее полезно для отладки образов armh на типовых массовых
> железках, которыми являются RPI*.
>
На RPi3 нет никаких проблем со сборкой на armh. Текущие профили 
дистрибутивов могут не собираться только из-за отсутствия каких-то 
пакетов в репозитории для armh. А так они уже готовы для этого.

На RPi4 у меня пока не получилось загрузиться с ядром mp. Возможно, 
стоит собрать ядро rpi-un для armh, тогда можем делать сборки и для armh 
идентичные сборкам для aarch64.

На armh, насколько мне известно, связка u-boot + EFI не работает. Там 
всё равно надо использовать u-boot+extlinux.conf. edk2 для RPi 3 на armh 
также не доступен.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-11  9:01     ` Denis Pynkin
@ 2020-05-11  9:16       ` Антон Мидюков
  0 siblings, 0 replies; 23+ messages in thread
From: Антон Мидюков @ 2020-05-11  9:16 UTC (permalink / raw)
  To: devel-sbc

11.05.2020 16:01, Denis Pynkin пишет:
> On Mon, May 11, 2020 at 02:50:40PM +0700, Антон Мидюков wrote:
>> 08.05.2020 23:07, Антон Мидюков пишет:
>>> Продолжаю делиться информацией о продвижении проекта по созданию
>>> полноценного UEFI для Raspberry Pi 3 и 4.
>>>
>>> Начну с того, что собирать собственную сборку стало не актуально.
>>> Проекты оперативно релизятся на github:
>>>
>>> https://github.com/pftf/RPi3
>>>
>>> https://github.com/pftf/RPi4
>>>
>>> Минус: нельзя сделать одну сборку для обеих плат. [...]
>> Я собрал новый edk2 для Raspberry Pi 3 и 4 и обновил архив с обоими UEFI:
>>
>> http://nightly.altlinux.org/sisyphus-aarch64/alpha/RPi_EFI.zip
> Такой вопрос -- откуда взяты bcm-271*.dtb файлы? Из официального firmware
> репозитория? Или самостоятельно делали с помощью Альтовской
> инфраструктуры?

Взяты официальные, последние. Я ориентируюсь на официальные сборки edk2 
для малин:
https://github.com/pftf/RPi3
https://github.com/pftf/RPi4

Стараюсь частично им соответствовать.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  @ 2020-05-11 10:10               ` Дмитрий Терехин
  2020-05-11 11:11                 ` Alexey V. Vissarionov
  2020-05-11 10:16               ` Антон Мидюков
  2020-05-11 11:07               ` Alexey V. Vissarionov
  2 siblings, 1 reply; 23+ messages in thread
From: Дмитрий Терехин @ 2020-05-11 10:10 UTC (permalink / raw)
  To: Single-board computer software development discussions

Добрый день!

11.05.2020, 12:24, "Aleksey Novodvorsky" <aen@basealt.ru>:
> пн, 11 мая 2020 г., 12:12 Антон Мидюков <midyukov-anton@ya.ru>:
>> 11.05.2020 15:35, Aleksey Novodvorsky пишет:
>>> пн, 11 мая 2020 г., 11:23 Антон Мидюков <midyukov-anton@ya.ru>:
>>>
>>>> 11.05.2020 15:07, Aleksey Novodvorsky пишет:
>>>>> пн, 11 мая 2020 г., 10:50 Антон Мидюков <midyukov-anton@ya.ru>:
>>>>>
>>>>>> 08.05.2020 23:07, Антон Мидюков пишет:
>>>>>>> Доброго времени суток
>>>>>>>
>>>>>>> Продолжаю делиться информацией о продвижении проекта по созданию
>>>>>>> полноценного UEFI для Raspberry Pi 3 и 4.
>>>>>>>
>>>>>>> Начну с того, что собирать собственную сборку стало не актуально.
>>>>>>> Проекты оперативно релизятся на github:
>>>>>>>
>>>>>>> https://github.com/pftf/RPi3
>>>>>>>
>>>>>>> https://github.com/pftf/RPi4
>>>>>>>
>>>>>>> Минус: нельзя сделать одну сборку для обеих плат. [...]
>>>>>> Я собрал новый edk2 для Raspberry Pi 3 и 4 и обновил архив с обоими
>>>> UEFI:
>>>>>> http://nightly.altlinux.org/sisyphus-aarch64/alpha/RPi_EFI.zip
>>>>> Спасибо, Антон!
>>>>>
>>>>> Что теперь не работает?  :)
>>>> Это те же самые UEFI только нашей сборки. Изменение только в том, что
>>>> этот архив подходит сразу для RPi3 и RPi4.  Также в config.txt прописан
>>>> оверлей для включения 3D на RPi3.
>>>>
>>> Так что не работает на rpi4, кроме 3d?
>>
>> edk2 для RPi4 позволяет грузиться в двух режимах: devicetree и ACPI
>> (дефолт).
>>
>> В режиме ACPI имеем:
>>
>> - ограничение оперативной памяти в 3 ГБ
>>
>> - не работют ни wi-fi, ни ethernet
>>
>> - не работает SD-карта
>>
>> - не работает аудио
>>
>> - не работает 3D
>>
>> - зато грузятся все наши ядра, кроме rpi-un, собранного без поддержки
>> ACPI (пробовали ему включить ACPI, загрузился, но плюсов от этого не было)
>>
>> В режиме devicetree:
>>
>> - доступны все 4 ГБ оперативной памяти
>>
>> - доступна SD-карта
>>
>> - не работает wi-fi, работает ethernet
>>
>> - не работает аудио
>>
>> - не работает 3D
>>
>> - грузятся только ядра mp и rpi-un. У rpi-un наблюдается инверсия
>> цветовой гаммы.
>
> Ядра можно собрать как угодно, но пока это явно не то.
>>> Можем ли мы перейти на эту схему для сборок продуктов на стабильных бранчах?
>>
>> edk2 для RPi4 не готово. Поддержку в ISO-образы добавить необходимо.
>> Пока можно будет рекомендовать только для RPi3. Как будет готова edk2
>> для RPi4, скорее всего наши уже постаревшие сборки ISO, будут на нём
>> полноценно грузиться и работать.
>>
>> Пока стоит смотреть связку u-boot +EFI. У некоторых других дистрибутивов
>> она работает. Надо разбираться, почему у нас с этим проблемы.
> Да.
> У кого работает?

Видел такое в SUSE.
Образ http://download.opensuse.org/ports/aarch64/tumbleweed/images/openSUSE-Tumbleweed-ARM-XFCE-raspberrypi4.aarch64-2020.03.25-Snapshot20200414.raw.xz
Насколько я понял по логу загрузки последовательность такая: firmware, U-Boot, EFI, GRUB, ядро

С уважением
Дмитрий Терёхин

>>> И ещё. Есть ли возможность сборки 32-битных armh- образов для тех же RPI 3
>>> и 4? Последнее полезно для отладки образов armh на типовых массовых
>>> железках, которыми являются RPI*.
>>>
>> На RPi3 нет никаких проблем со сборкой на armh. Текущие профили
>> дистрибутивов могут не собираться только из-за отсутствия каких-то
>> пакетов в репозитории для armh. А так они уже готовы для этого.
>
> Отлично.
> Там нет chromium. И не будет.
>> На RPi4 у меня пока не получилось загрузиться с ядром mp. Возможно,
>> стоит собрать ядро rpi-un для armh,
>
> Стоит.
>
> 2gremlin@: какое ядро armh взлетит на rpi4?
>
>> тогда можем делать сборки и для armh
>> идентичные сборкам для aarch64.
>  Ок.
>
>> На armh, насколько мне известно, связка u-boot + EFI не работает. Там
>> всё равно надо использовать u-boot+extlinux.conf. edk2 для RPi 3 на armh
>> также не доступен.
>
> Ok.
>
>> --
> Rgrds, Алексей
> ,
>
> _______________________________________________
> devel-sbc mailing list
> devel-sbc@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-sbc


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
    2020-05-11 10:10               ` Дмитрий Терехин
@ 2020-05-11 10:16               ` Антон Мидюков
    2020-05-11 11:07               ` Alexey V. Vissarionov
  2 siblings, 1 reply; 23+ messages in thread
From: Антон Мидюков @ 2020-05-11 10:16 UTC (permalink / raw)
  To: devel-sbc

11.05.2020 16:23, Aleksey Novodvorsky пишет:
> пн, 11 мая 2020 г., 12:12 Антон Мидюков <midyukov-anton@ya.ru>:
>
>> 11.05.2020 15:35, Aleksey Novodvorsky пишет:
>> [...] 
>>> Можем ли мы перейти на эту схему для сборок продуктов на стабильных
>> бранчах?
>>
>> edk2 для RPi4 не готово. Поддержку в ISO-образы добавить необходимо.
>> Пока можно будет рекомендовать только для RPi3. Как будет готова edk2
>> для RPi4, скорее всего наши уже постаревшие сборки ISO, будут на нём
>> полноценно грузиться и работать.
>>
>> Пока стоит смотреть связку u-boot +EFI. У некоторых других дистрибутивов
>> она работает. Надо разбираться, почему у нас с этим проблемы.
>>
> Да.
> У кого работает?

Fedora и Suse.

[...]

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  @ 2020-05-11 10:53             ` Alexey V. Vissarionov
  2020-05-11 11:24               ` Антон Мидюков
  0 siblings, 1 reply; 23+ messages in thread
From: Alexey V. Vissarionov @ 2020-05-11 10:53 UTC (permalink / raw)
  To: Single-board computer software development discussions

On 2020-05-11 11:48:36 +0300, Aleksey Novodvorsky wrote:

 >> Через u-boot можно загрузиться только с SD-карты. Через edk2
 >> можно загрузиться только через USB.
 >>
 >> Это совершенно разные загрузчики. u-boot предоставляет
 >> минимальную совместимость с UEFI, только чтобы grub-efi
 >> загрузить.
 >> edk2 - это полноценный UEFI, который позволяет грузить с
 >> флешки гибридные ISO-образы. А это полноценные live,
 >> инсталляторы, rescue.

Все эти "полноценные live, инсталляторы, rescue" можно сделать
просто на базе USB-флешки, безо всяких ISO-образов. Но тут, как
всегда, "есть нюансы".

 >> Чем и интересен.

 > +1

-1

Вероятность того, что кто-то подключит сидюк к мелкому компутеру,
пренебрежимо мала (хотя на том же BPi-R1 есть SATA прямо на плате).
Вероятность того, что этот сидюк будет использоваться в качестве
загрузочного накопителя - еще меньше.

Даже на писюшатине они практически вымерли. Вот захожу я по адресу
https://www.citilink.ru/catalog/mobile/notebooks/ и среди параметров
поиска вижу прекрасное соотношение вариантов:

  Оптический привод: DVD - 73, без привода 1020.

Крупный ретейлер что-то знает о предпочтениях покупателей? :-)

Это именно ноутбучная категория, причем есть еще две: ультрабуки
и трансформеры (у которых сидюков не бывает в принципе).

Поэтому остаются флешки - как SD/MMC, так и USB. И тут начинается
самое интересное.

 > Честно говоря, загрузка с USB мне кажется плюсом. Это серьезный
 > шаг к унификации и пользовательских свойств, и технологии
 > разработки/сборки. Вопрос только в выравнивания сборки RPI 4
 > по багам.

Далеко не только.

Дело в процессе загрузки. Когда процессор стартует, ему доступны
только те устройства, которые есть у него на борту (процессоров как
таковых уже давно нет, они все в той или иной мере SoC, System on
Chip) - это немного ПЗУ, немного ОЗУ (килобайты), интерфейсы I2C и
SPI, ногодрыжество (GPIO)... и все. Про внешние устройства ничего
не известно, и как с ними работать - в общем случае непонятно.

Однако "есть один нюанс", который сильно упрощает жизнь: почти все
современные ПЗУ умеют работать по SPI, а реализовать его предельно
просто - по одному проводу отправляем (или, наоборот, принимаем)
синхроимпульс, по второму передаем один бит данных, по третьему
принимаем один бит встречных данных. Провода и сигналы называются,
соответственно, SCK (clock), SDO (data out; также MOSI) и SDI
(data in; также MISO); добавляем питание (VCC), общий (GND) и выбор
устройства (CS, chip select) - все, можно работать. А самое главное,
в таком режиме умеют работать и SD/MMC-флешки: пусть медленно, зато
единообразно. В общем, есть место, где хранится информация о том,
что у нас есть и как с ним работать.

А вот USB-хосты унифицированы только с одной стороны - той, куда
подключается периферия. Там все хорошо: более 20 лет существует
стандарт https://www.usb.org/sites/default/files/usbmassbulk_10.pdf
Но нам-то интересна та часть, которая находится со стороны SoC... и
там полнейший зоопарк.

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


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


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
    2020-05-11 10:10               ` Дмитрий Терехин
  2020-05-11 10:16               ` Антон Мидюков
@ 2020-05-11 11:07               ` Alexey V. Vissarionov
  2 siblings, 0 replies; 23+ messages in thread
From: Alexey V. Vissarionov @ 2020-05-11 11:07 UTC (permalink / raw)
  To: Single-board computer software development discussions

On 2020-05-11 12:23:55 +0300, Aleksey Novodvorsky wrote:

 > 2gremlin@: какое ядро armh взлетит на rpi4?

Да хрен его знает... Если первое время забить на USB - можно любое
5.6+ использовать.


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


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-11 10:10               ` Дмитрий Терехин
@ 2020-05-11 11:11                 ` Alexey V. Vissarionov
  0 siblings, 0 replies; 23+ messages in thread
From: Alexey V. Vissarionov @ 2020-05-11 11:11 UTC (permalink / raw)
  To: Single-board computer software development discussions

On 2020-05-11 13:10:21 +0300, Дмитрий Терехин wrote:

 > Видел такое в SUSE.
 > Насколько я понял по логу загрузки последовательность такая:
 > firmware, U-Boot, EFI, GRUB, ядро

Десять раз вокруг ноги, через плечо и в сапоги...


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


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-11 10:53             ` Alexey V. Vissarionov
@ 2020-05-11 11:24               ` Антон Мидюков
  2020-05-12 13:51                 ` Alexey V. Vissarionov
  0 siblings, 1 reply; 23+ messages in thread
From: Антон Мидюков @ 2020-05-11 11:24 UTC (permalink / raw)
  To: devel-sbc

11.05.2020 17:53, Alexey V. Vissarionov пишет:
> On 2020-05-11 11:48:36 +0300, Aleksey Novodvorsky wrote:
>
>   >> Через u-boot можно загрузиться только с SD-карты. Через edk2
>   >> можно загрузиться только через USB.
>   >>
>   >> Это совершенно разные загрузчики. u-boot предоставляет
>   >> минимальную совместимость с UEFI, только чтобы grub-efi
>   >> загрузить.
>   >> edk2 - это полноценный UEFI, который позволяет грузить с
>   >> флешки гибридные ISO-образы. А это полноценные live,
>   >> инсталляторы, rescue.
>
> Все эти "полноценные live, инсталляторы, rescue" можно сделать
> просто на базе USB-флешки, безо всяких ISO-образов. Но тут, как
> всегда, "есть нюансы".
>
>   >> Чем и интересен.
>
>   > +1
>
> -1
>
> Вероятность того, что кто-то подключит сидюк к мелкому компутеру,
> пренебрежимо мала (хотя на том же BPi-R1 есть SATA прямо на плате).
> Вероятность того, что этот сидюк будет использоваться в качестве
> загрузочного накопителя - еще меньше.
Речь про гибридные ISO, которые пишутся на USB-флешку. Мы их уже 
собираем, поддержка RPi будет за компанию. Это позволит снизить нагрузку 
на релиз-менеджеров. Также это позволит тестировать образы не в qemu, а 
хоть на каком-то железе, тем, у кого нет нормального железа aarch64 + EFI.
>   > Честно говоря, загрузка с USB мне кажется плюсом. Это серьезный
>   > шаг к унификации и пользовательских свойств, и технологии
>   > разработки/сборки. Вопрос только в выравнивания сборки RPI 4
>   > по багам.
>
> Далеко не только.
>
> [...]
>
> Соответственно, для EFI-загрузки с USB нужна унификация содержимого
> ПЗУ на платах (пусть хотя бы на уровне "найти USB-флешку, найти на
> ней активный раздел с типом 0xEF и файловой системой FAT32, прочитать
> в память файл EFI/Boot/bootaa64.efi и передать ему управление"). Кто
> этим будет заниматься - я не знаю: производителям железяк это не
> нужно, производителям SoC тем более.
Этим занимаются разработчики u-boot, edk2 и ядра. От нас требуется 
только добавить нужные для загрузки модули ядра в propagator (initrd).

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  @ 2020-05-11 20:25                   ` Сергей Бессонов
    2020-05-12  8:23                   ` Антон Мидюков
  2020-05-12 14:14                   ` Alexey V. Vissarionov
  2 siblings, 1 reply; 23+ messages in thread
From: Сергей Бессонов @ 2020-05-11 20:25 UTC (permalink / raw)
  To: devel-sbc

В Пн, 11/05/2020 в 22:41 +0300, Aleksey Novodvorsky пишет:
> 
> 
> 
> пн, 11 мая 2020 г., 13:16 Антон Мидюков <midyukov-anton@ya.ru>:
> > 11.05.2020 16:23, Aleksey Novodvorsky пишет:
> > > пн, 11 мая 2020 г., 12:12 Антон Мидюков <midyukov-anton@ya.ru>:
> > >
> > >> 11.05.2020 15:35, Aleksey Novodvorsky пишет:
> > >> [...] 
> > >>> Можем ли мы перейти на эту схему для сборок продуктов на
> > стабильных
> > >> бранчах?
> > >>
> > >> edk2 для RPi4 не готово. Поддержку в ISO-образы добавить
> > необходимо.
> > >> Пока можно будет рекомендовать только для RPi3. Как будет готова
> > edk2
> > >> для RPi4, скорее всего наши уже постаревшие сборки ISO, будут на
> > нём
> > >> полноценно грузиться и работать.
> > >>
> > >> Пока стоит смотреть связку u-boot +EFI. У некоторых других
> > дистрибутивов
> > >> она работает. Надо разбираться, почему у нас с этим проблемы.
> > >>
> > > Да.
> > > У кого работает?
> > 
> > Fedora и Suse.
> 
> Там другие проблемы:
> 
> https://en.opensuse.org/HCL:Raspberry_Pi4
> 
> 
> Rgrds, Алексей

Судя по dmesg: https://pastebin.com/sZ8KrFgu

В вышеупомянутом Oracle Linux также используется U-Boot+EFI+Grub.

И там тоже не работают WiFi, но там работает звук. Pulse не ставил,
впрочем.


> > [...]
> > 
> > _______________________________________________
> > devel-sbc mailing list
> > devel-sbc@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel-sbc
-- 
Сергей Бессонов

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
    2020-05-11 20:25                   ` Сергей Бессонов
@ 2020-05-12  8:23                   ` Антон Мидюков
  2020-05-12 14:14                   ` Alexey V. Vissarionov
  2 siblings, 0 replies; 23+ messages in thread
From: Антон Мидюков @ 2020-05-12  8:23 UTC (permalink / raw)
  To: devel-sbc

12.05.2020 02:41, Aleksey Novodvorsky пишет:
> пн, 11 мая 2020 г., 13:16 Антон Мидюков <midyukov-anton@ya.ru>:
>
>> 11.05.2020 16:23, Aleksey Novodvorsky пишет:
>>> пн, 11 мая 2020 г., 12:12 Антон Мидюков <midyukov-anton@ya.ru>:
>>>
>>>> 11.05.2020 15:35, Aleksey Novodvorsky пишет:
>>>> [...]
>>>>> Можем ли мы перейти на эту схему для сборок продуктов на стабильных
>>>> бранчах?
>>>>
>>>> edk2 для RPi4 не готово. Поддержку в ISO-образы добавить необходимо.
>>>> Пока можно будет рекомендовать только для RPi3. Как будет готова edk2
>>>> для RPi4, скорее всего наши уже постаревшие сборки ISO, будут на нём
>>>> полноценно грузиться и работать.
>>>>
>>>> Пока стоит смотреть связку u-boot +EFI. У некоторых других дистрибутивов
>>>> она работает. Надо разбираться, почему у нас с этим проблемы.
>>>>
>>> Да.
>>> У кого работает?
>> Fedora и Suse.
>>
> Там другие проблемы:
>
> https://en.opensuse.org/HCL:Raspberry_Pi4

1. usb-host у ядра rpi-un в таком режиме работает

2. Неработающие сетевая загрузка, загрузка с usb и клавиатура в grub - 
это общая проблема u-boot

3. Звук у ядра rpi-un в таком режиме не работает

Другие наши ядра грузиться не хотят.

В следующей сборке ядер std-def и un-def будет включен ряд опций, 
которые должны улучшить совместимость с одноплатниками. Посмотрим, 
смогут ли новые сборки std-def и un-def загрузиться.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  @ 2020-05-12  8:39                       ` Сергей Бессонов
  0 siblings, 0 replies; 23+ messages in thread
From: Сергей Бессонов @ 2020-05-12  8:39 UTC (permalink / raw)
  To: devel-sbc

В Вт, 12/05/2020 в 00:24 +0300, Aleksey Novodvorsky пишет:
> 
> 
> пн, 11 мая 2020 г., 23:25 Сергей Бессонов <aceler@yandex.ru>:
> > В Пн, 11/05/2020 в 22:41 +0300, Aleksey Novodvorsky пишет:
> > > 
> > > 
> > > 
> > > пн, 11 мая 2020 г., 13:16 Антон Мидюков <midyukov-anton@ya.ru>:
> > > > 11.05.2020 16:23, Aleksey Novodvorsky пишет:
> > > > > пн, 11 мая 2020 г., 12:12 Антон Мидюков <midyukov-anton@ya.ru
> > >:
> > > > >
> > > > >> 11.05.2020 15:35, Aleksey Novodvorsky пишет:
> > > > >> [...] 
> > > > >>> Можем ли мы перейти на эту схему для сборок продуктов на
> > > > стабильных
> > > > >> бранчах?
> > > > >>
> > > > >> edk2 для RPi4 не готово. Поддержку в ISO-образы добавить
> > > > необходимо.
> > > > >> Пока можно будет рекомендовать только для RPi3. Как будет
> > готова
> > > > edk2
> > > > >> для RPi4, скорее всего наши уже постаревшие сборки ISO,
> > будут на
> > > > нём
> > > > >> полноценно грузиться и работать.
> > > > >>
> > > > >> Пока стоит смотреть связку u-boot +EFI. У некоторых других
> > > > дистрибутивов
> > > > >> она работает. Надо разбираться, почему у нас с этим
> > проблемы.
> > > > >>
> > > > > Да.
> > > > > У кого работает?
> > > > 
> > > > Fedora и Suse.
> > > 
> > > Там другие проблемы:
> > > 
> > > https://en.opensuse.org/HCL:Raspberry_Pi4
> > > 
> > > 
> > > Rgrds, Алексей
> > 
> > Судя по dmesg: https://pastebin.com/sZ8KrFgu
> > 
> > В вышеупомянутом Oracle Linux также используется U-Boot+EFI+Grub.
> > 
> > И там тоже не работают WiFi, но там работает звук. Pulse не ставил,
> > впрочем.
> 
> Неработающий WiFi это блогер, конечно. 
> А в Ubuntu pulse? 
> Звук надо у нас чинить. 

В Ubuntu Pulse.

> Rgrds, Алексей
> 
> > 
> > 
> 
> _______________________________________________
> devel-sbc mailing list
> devel-sbc@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-sbc
-- 
Сергей Бессонов

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-11 11:24               ` Антон Мидюков
@ 2020-05-12 13:51                 ` Alexey V. Vissarionov
  2020-05-12 14:31                   ` Антон Мидюков
  0 siblings, 1 reply; 23+ messages in thread
From: Alexey V. Vissarionov @ 2020-05-12 13:51 UTC (permalink / raw)
  To: Single-board computer software development discussions

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


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
    2020-05-11 20:25                   ` Сергей Бессонов
  2020-05-12  8:23                   ` Антон Мидюков
@ 2020-05-12 14:14                   ` Alexey V. Vissarionov
  2 siblings, 0 replies; 23+ messages in thread
From: Alexey V. Vissarionov @ 2020-05-12 14:14 UTC (permalink / raw)
  To: Single-board computer software development discussions

On 2020-05-11 22:41:44 +0300, Aleksey Novodvorsky wrote:

 >>> У кого работает?
 >> Fedora и Suse.
 > Там другие проблемы:
 > https://en.opensuse.org/HCL:Raspberry_Pi4

 >>>>> The following features are not working yet:
 >>>>> USB hosts

Хи-хи... мы тоже очень любим VIA VL805 :-)

 >>>>> Network boot from U-Boot/Grub

Решаемо, но зачем?
Если есть U-boot - значит, есть флешка.
Если есть флешка - можно прямо с нее и грузиться.

 >>>>> USB keyboard in Grub

Опять-таки VL805.
Для U-boot можно сделать... но опять же, зачем?

 >>>>> No sound via jack or HDMI

Можно CM109 подключить через USB... а, ну да - VL805.


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


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [devel-sbc] UEFI и Raspberry Pi
  2020-05-12 13:51                 ` Alexey V. Vissarionov
@ 2020-05-12 14:31                   ` Антон Мидюков
  0 siblings, 0 replies; 23+ messages in thread
From: Антон Мидюков @ 2020-05-12 14:31 UTC (permalink / raw)
  To: devel-sbc

12.05.2020 20:51, 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
> никому не вперлись.

И тем не менее дистрибутивостроители-идиоты продолжают собирать именно ISO.

>   > поддержка RPi будет за компанию.
>
> "Безобразно, зато единообразно"? По-моему, немного не тот случай...
Почему безобразно? На RPi3 работает вполне полноценно. В случае проблем 
можно загрузиться с Rescue и восстановить систему. Или загрузиться с 
live. Или организовать установку по сети. Или ещё что только 
заблагорассудится. Всё как на PC с UEFI. И опять таки подчеркну. Мне 
гораздо удобнее ISO образы проверять на rpi3, чем в qemu.
>   > Это позволит снизить нагрузку на релиз-менеджеров. Также это
>   > позволит тестировать образы не в qemu, а хоть на каком-то железе,
>   > тем, у кого нет нормального железа aarch64 + EFI.
>
> Ээээ... дяденька, давно ли вы видели настоящего живого пользователя?
> А типового пользователя малинобананы? А разницу между ними понимаете?
> А чем малинопользователь отличается от админа?
Я про себя. Мне это действительно нужно. У меня нет железа aarch64 с UEFI.
> Не будут они ничего тестировать. Их вполне устраивает "шибко сильное
> колдунство", если оно доступно "из коробки" и не требует постоянного
> присмотра, чтобы можно было оставить ту же малину в дачном домике на
> зиму, а перед выездом из города залезть на нее по 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 - идиотизм.
В Red Hat и Suse одни идиоты...
>   > От нас требуется только добавить нужные для загрузки модули ядра
>   > в propagator (initrd).
>
> Нужные для загрузки модули ядра лучше вкомпилячить внутрь ядра. Вот
> зарекался кого-либо чему-то учить, но, похоже, прилется сделать еще
> одно исключение...
Если это ядро, которое должно грузиться на огромном множестве устройств, 
то не нужно. После установки make-initrd добавит только нужные модули.
> Начнем с того, когда и для чего придумали initrd. Было это во времена,
> когда единственным сменным накопителем были дискеты, объем которых был
> чуть больше мегабайта, и загрузку системы приходилось осуществлять в
> два этапа: сначала с одного диска грузилось минимальное ядро (лишь бы
> поместилось на флоп), а потом со второго диска подгружался initrd с
> дополнительными модулями ядра и минимальным userspace для дальнейшей
> установки. Таким образом еще четверть века назад можно было поставить
> Linux-систему на вполне типовой 80386SX/4M/120M/SVGA/NE2k :-)
>
> Сейчас же initrd нужен только в двух случаях - для rescue-систем и для
> сетевой загрузки. Что, в общем-то, одно и то же: в обоих случаях нельзя
> пользоваться локальными накопителями (жесткими дисками).

Да, конечно. Только придётся вкомпиливать очень и очень много модулей, 
если цель охватить как можно больше разновидностей плат.

> Это не отменяет возможность использовать ядерные модули: они прекрасно
> хранятся в корневом разделе, а все необходимое для доступа к нему есть
> внутри ядра (покажите мне идиота, который соберет современное ядро без
> CONFIG_SATA_AHCI=y, без CONFIG_USB_STORAGE=y
Ядра std-def и un-def.
> [...]

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2020-05-12 14:31 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-08 16:07 ` [devel-sbc] UEFI и Raspberry Pi Антон Мидюков
2020-05-08 17:20   ` Сергей Бессонов
2020-05-11  8:01     ` Антон Мидюков
2020-05-11  8:07       ` Сергей Бессонов
2020-05-11  8:19         ` Антон Мидюков
2020-05-11 10:53             ` Alexey V. Vissarionov
2020-05-11 11:24               ` Антон Мидюков
2020-05-12 13:51                 ` Alexey V. Vissarionov
2020-05-12 14:31                   ` Антон Мидюков
2020-05-11  7:50   ` Антон Мидюков
2020-05-11  8:23       ` Антон Мидюков
2020-05-11  8:53           ` Alexey V. Vissarionov
2020-05-11  9:12           ` Антон Мидюков
2020-05-11 10:10               ` Дмитрий Терехин
2020-05-11 11:11                 ` Alexey V. Vissarionov
2020-05-11 10:16               ` Антон Мидюков
2020-05-11 20:25                   ` Сергей Бессонов
2020-05-12  8:39                       ` Сергей Бессонов
2020-05-12  8:23                   ` Антон Мидюков
2020-05-12 14:14                   ` Alexey V. Vissarionov
2020-05-11 11:07               ` Alexey V. Vissarionov
2020-05-11  9:01     ` Denis Pynkin
2020-05-11  9:16       ` Антон Мидюков

Single-board computer software development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel-sbc/0 devel-sbc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel-sbc devel-sbc/ http://lore.altlinux.org/devel-sbc \
		devel-sbc@lists.altlinux.org devel-sbc@lists.altlinux.ru devel-sbc@lists.altlinux.com
	public-inbox-index devel-sbc

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel-sbc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git