From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FUZZY_XPILL autolearn=no autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1589293867; bh=9YHm0vFrrvbi5vKjx33NVKj2waeHw3xEzDDoWMK+IwA=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=V0NM1M0HLQZvTuBSylIhG6zg2gHJLoaxrAQ+ilyfpOBLNjk+Rq098+bbS38yWvvo4 nGTTLMfrKaNBSaDL7GKLSwvvfUYOkJqnNRowoQXsBh2gtHMoLN1cj8altRxET3OAcr z1L4DlfmIcejPmCkBPImTOMO3MWI/Y6S6vbXSPDc= Authentication-Results: mxback29o.mail.yandex.net; dkim=pass header.i=@ya.ru To: devel-sbc@lists.altlinux.org References: <20193028-a0c3-5af8-9c77-a2ed70ca97f4@ya.ru> <238a9d0c-17f2-8cc7-1db2-983528dcd1b3@ya.ru> <63bb2c34-b668-907d-98db-dfbbb0b4b480@ya.ru> <20200511105337.GL24180@altlinux.org> <8704b89b-fa54-b5c5-ec6c-b026ae82e877@ya.ru> <20200512135158.GO24180@altlinux.org> From: =?UTF-8?B?0JDQvdGC0L7QvSDQnNC40LTRjtC60L7Qsg==?= Message-ID: <276030cf-dd9f-7131-5f8c-64a1a0ef60f5@ya.ru> Date: Tue, 12 May 2020 21:31:05 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200512135158.GO24180@altlinux.org> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [devel-sbc] =?utf-8?q?UEFI_=D0=B8_Raspberry_Pi?= X-BeenThere: devel-sbc@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Single-board computer software development discussions List-Id: Single-board computer software development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 14:31:09 -0000 Archived-At: List-Archive: 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. > [...] -- С уважением, Антон Мидюков