ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Evgeny Sinelnikov <sin@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] grub FDT patch (grub versus Baikal-M)
Date: Tue, 7 Apr 2020 15:55:54 +0400
Message-ID: <CAK42-Grwyv2o-RZ_Pd_cBcO3wpvGWb1drJmfPeVH9Hj_6tTSzg@mail.gmail.com> (raw)
In-Reply-To: <CAGvFrt3MFQuuEY=Mb=X4OoA-mkU+uDud3jMP7r6pCq3BDiaAZw@mail.gmail.com>

Добрый день,

я бы хотел поддержать Атона и Алексея в впросе принятия патча для
поддержки нестандартного железа и опции GRUB_FDT_LINUX.

Аргументы у меня следующие:
- этот патч не добавляет никаких сайдэффектов в стандартных
конфигурациях, только добавляет соответствующий функционал;
- аналогичные патчи имеются в других дистрибутивах;
- отсылка к тому, что данный патч придуман только для одной
нестандартной железки и больше никогда не понадобиться как только её
"починят", выглядит в высшей степени не убедительно.

Дело в том, что аналогичные пачти в других дистрах появились не из-за
платы от БЭ, а соответственно таких железок более одной и они разные.
Ну, и время ожидания аппаратно-программного решения не имеет никаких
определённых сроков, поэтому закладываться на это совершенно
бесмысленно.

Ну, у и меня, технически, такой же вопрос, что и у Алексея: "Почему
прибитая в grub гвоздями константа вида 'foundation-v8.dtb' - это
нормально, а переменная GRUB_FDT_LINUX, которая позволит её задать -
это нечто не нормальное?"

Я предлагаю поменять контекст этого вопроса. Проблема не в поддержке
baikal-M. Проблема в том, что grub у нас не поддерживает загрузку
нестандартного железа. И я не очень понимаю почему мы своей волей
должны заставлять разработчиков аппаратных средств исправлять их
железо (делать его более стандартным), намеренно отказываясь от
поддержки этого железа.

Аргумент вида "поддержка нестандартного железа" - дорогая штука,
вполне себе рабочий аргумент. Ну, не в данном же случае.



пт, 3 апр. 2020 г. в 15:49, Aleksey Novodvorsky <aen@basealt.ru>:
>
>
>
>
>
> пт, 3 апр. 2020 г., 14:34 Alexey Sheplyakov <asheplyakov@basealt.ru>:
>>
>> On Wed, Apr 01, 2020 at 01:29:43PM +0300, Aleksey Novodvorsky wrote:
>>
>> > Обсудил с sbolshakov@.
>> > Проблема в том, что в случае обновления bios с целью стандартизации, -- а
>> > оно вроде намечено БЭ, -- система не загрузится.
>>
>> Не вполне верное утверждение. Если UEFI выдает такое же FDT, какое
>> записано на диске, никакой разницы нет, и система загрузится. Если UEFI
>> выдает несовместимое FDT, то ядро все равно не загрузится (независимо от
>> того, патчили grub или нет).
>>
>> > Какие варианты я вижу:
>> > 1. Спросить у БЭ об их намерениях касательно прошивки этой платы при ее
>> > запуске в production. Будет стандартизация или нет.
>
>
> Давайте с этим определимся в любом случае. Пока еще далеко до релиза платы и мы можем постараться согласовать свои действия с бэ, а, возможно, и повлиять на их решения.
> Пока ни одной платы не продано и раньше лета вряд ли будет.
> Нашу сборку будут смотреть только бэ, несколько OEM и Астра.
>
>
>> > 2. Сейчас в любом случае собрать в стороне grub с предложенным патчем и
>> > использовать в сборках для этой платы с предупреждением на вики.
>>
>> Он и так "собран в стороне", но после первого же обновления grub система
>> не загрузится (т.к. в grub.cfg не будет строчки `devicetree`).
>
>
> Если не поставить его на hold.
>>
>>
>> > всего несколько десятков и релиза у нас нет, сильно не навредим.
>> > 3. Если стандартизации не будет и далее, то патчить  grub.
>> > 4. Если будет, то делать релизный образ с обычным grub
>> > 5. Что-то другое?
>>
>> Патч сам по себе не приводит к появлению директивы `devicetree` в grub.cfg.
>> Для этого еще переменную GRUB_FDT_LINUX в /etc/sysconfig/grub2 задать надо.
>> Потому проще было бы смержить патч, а после "стандартизации" убрать эту
>> переменную (из соответствующего mkimage-profile).
>>
>> Уже установленные системы (все 3) при любом варианте прийдется обновлять
>> особым образом.  При варианте 4):
>>  а) снять с hold и обновить grub
>>  б) запустить upgrade-grub
>>
>> При варианте 5 (который я предлагаю):
>>  а) закомментировать GRUB_FDT_LINUX в /etc/sysconfig/grub2
>>  б) запустить update-grub
>
>
> Rgrds, Алексей
>
>
>>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)

  parent reply	other threads:[~2020-04-07 11:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31  9:44 Alexey Sheplyakov
2020-03-31 12:33 ` Anton Farygin
2020-03-31 13:15     ` Anton Farygin
2020-03-31 14:03       ` Антон Мидюков
2020-03-31 14:09         ` Антон Мидюков
2020-03-31 14:27         ` Anton Farygin
2020-03-31 15:32         ` Alexey Sheplyakov
2020-04-01 10:31           ` Sergey Bolshakov
2020-04-01 10:39             ` Антон Мидюков
2020-03-31 15:35         ` Alexey Sheplyakov
2020-03-31 15:51           ` Alexey Sheplyakov
2020-03-31 18:47               ` Dmitry V. Levin
2020-04-01  7:32               ` Антон Мидюков
2020-04-03 11:09                 ` Alexey Sheplyakov
2020-04-03 11:33                   ` Alexey Sheplyakov
2020-04-07 11:55                       ` Evgeny Sinelnikov [this message]
2020-04-08  3:54                         ` Антон Мидюков
2020-04-09 15:52                           ` Sergey Bolshakov

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=CAK42-Grwyv2o-RZ_Pd_cBcO3wpvGWb1drJmfPeVH9Hj_6tTSzg@mail.gmail.com \
    --to=sin@altlinux.org \
    --cc=devel@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

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/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 devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

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


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