Single-board computer software development discussions
 help / color / mirror / Atom feed
From: "Антон Мидюков" <midyukov-anton@ya.ru>
To: devel-sbc@lists.altlinux.org
Subject: Re: [devel-sbc] UEFI и Raspberry Pi
Date: Tue, 12 May 2020 21:31:05 +0700
Message-ID: <276030cf-dd9f-7131-5f8c-64a1a0ef60f5@ya.ru> (raw)
In-Reply-To: <20200512135158.GO24180@altlinux.org>

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>



  reply	other threads:[~2020-05-12 14:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 16:07 ` Антон Мидюков
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                   ` Антон Мидюков [this message]
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       ` Антон Мидюков

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=276030cf-dd9f-7131-5f8c-64a1a0ef60f5@ya.ru \
    --to=midyukov-anton@ya.ru \
    --cc=devel-sbc@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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