[devel] grub FDT patch (grub versus Baikal-M)

[devel] grub FDT patch (grub versus Baikal-M)

[Alexey Sheplyakov]

Добрый день!

Некоторые компьютеры (например, на основе SoC Baikal-M) оснащены UEFI,
но для загрузки и работы Linux ядра требуется device tree. grub-mkconfig
(версия 2.02-alt25, самая свежая на момент написания) создает для таких
компьютеров заведомо нерабочий grub.cfg, в котором отсутствует директива
'devicetree'. Причина в том, что grub-mkconfig ищет dtb файл с именем
'foundation-v8.dtb'. Для решения этой проблемы был предложен патч, чтобы
имя dtb файла брать из переменной GRUB_FDT_LINUX (которую можно задать
в /etc/sysconfig/grub2):

http://git.altlinux.org/people/antohami/packages/?p=grub.git;a=blob;f=grub-2.02-support-GRUB_FDT_LINUX.patch;h=575c664e265219297a980650ef747f8a63037653;hb=5741e6cdb26580ecc366cc6ec8c4f7d07f400e8e

Однако майнтейнер пакета grub отказался принять этот патч. В связи с
этим у меня вопрос: почему намертво зашивать имя dtb файла в скрипт
grub-mkconfig -- хорошо, а брать это имя из конфигурационного файла --
плохо?

Заранее благодарю за ответ,
    Алексей

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Anton Farygin]

On 31.03.2020 12:44, Alexey Sheplyakov wrote:
> Однако майнтейнер пакета grub отказался принять этот патч. В связи с
> этим у меня вопрос: почему намертво зашивать имя dtb файла в скрипт
> grub-mkconfig -- хорошо, а брать это имя из конфигурационного файла --
> плохо?

Если отправить это изменение в апстрим - то мы узнаем, что такое хорошо 
и что такое плохо в данном случае.

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Anton Farygin]

On 31.03.2020 15:41, Aleksey Novodvorsky wrote:
>
>
>
> вт, 31 мар. 2020 г., 15:33 Anton Farygin <rider@basealt.ru 
> <mailto:rider@basealt.ru>>:
>
>     On 31.03.2020 12:44, Alexey Sheplyakov wrote:
>     > Однако майнтейнер пакета grub отказался принять этот патч. В связи с
>     > этим у меня вопрос: почему намертво зашивать имя dtb файла в скрипт
>     > grub-mkconfig -- хорошо, а брать это имя из конфигурационного
>     файла --
>     > плохо?
>
>     Если отправить это изменение в апстрим - то мы узнаем, что такое
>     хорошо
>     и что такое плохо в данном случае.
>
>
> Антон, а все ли патчи нашего grub отправляли в апстрим? И что узнали?

Если этот патч в апстриме, то его мы тоже приложим. Но grub на мне, а я 
не помню, что бы ко мне кто-то с этим вопросом обращался.

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Антон Мидюков]

31.03.2020 20:15, Anton Farygin пишет:
> On 31.03.2020 15:41, Aleksey Novodvorsky wrote:
>>
>>
>>
>> вт, 31 мар. 2020 г., 15:33 Anton Farygin <rider@basealt.ru 
>> <mailto:rider@basealt.ru>>:
>>
>>     On 31.03.2020 12:44, Alexey Sheplyakov wrote:
>>     > Однако майнтейнер пакета grub отказался принять этот патч. В 
>> связи с
>>     > этим у меня вопрос: почему намертво зашивать имя dtb файла в 
>> скрипт
>>     > grub-mkconfig -- хорошо, а брать это имя из конфигурационного
>>     файла --
>>     > плохо?
>>
>>     Если отправить это изменение в апстрим - то мы узнаем, что такое
>>     хорошо
>>     и что такое плохо в данном случае.
>>
>>
>> Антон, а все ли патчи нашего grub отправляли в апстрим? И что узнали?
>
> Если этот патч в апстриме, то его мы тоже приложим. Но grub на мне, а 
> я не помню, что бы ко мне кто-то с этим вопросом обращался.

Дело было в devel-sbc@:

https://lists.altlinux.org/pipermail/devel-distro/2019-December/001845.html

Получил отрицательный отзыв об этой идеи от Сергея Большакова:

https://lists.altlinux.org/pipermail/devel-distro/2019-December/001852.html

Были надежды, что прошивку научат предоставлять dtb ядру. Поэтому 
выжидали. Надежды так пока и не оправдались.

По конкретике. Зачаток поддержки devicetree в конфиге был вот в этом патче:

http://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=grub-2.02-sb-0005-Make-10_linux-work-with-our-changes-for-linux16-and-.patch;h=11b6e2b0259709e1c4c78701163d61eb6b5517a6;hb=2dfa3c486dea760b421124dcae735674f204f9da

Если бы этого зачатка не было, я бы и не развил эту идею. Патч то этот 
апстримный?

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

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Антон Мидюков]

31.03.2020 21:03, Антон Мидюков пишет:
>>> [...]
>
> Дело было в devel-sbc@: 

В devel-distro@, извиняюсь. Что видно по ссылкам дальнейшим.

[...]

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

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Anton Farygin]

On 31.03.2020 17:03, Антон Мидюков wrote:
>
> http://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=grub-2.02-sb-0005-Make-10_linux-work-with-our-changes-for-linux16-and-.patch;h=11b6e2b0259709e1c4c78701163d61eb6b5517a6;hb=2dfa3c486dea760b421124dcae735674f204f9da 
>
>
> Если бы этого зачатка не было, я бы и не развил эту идею. Патч то этот 
> апстримный? 

Ну отправьте изменения в апстрим. Сергею виднее, я тут ему полностью 
доверяю.

Патч не апстримный конечно же. Он попал в mainline grub'а ?

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Alexey Sheplyakov]

On Tue, Mar 31, 2020 at 09:03:28PM +0700, Антон Мидюков wrote:

> Дело было в devel-sbc@:
> 
> https://lists.altlinux.org/pipermail/devel-distro/2019-December/001845.html
> 
> Получил отрицательный отзыв об этой идеи от Сергея Большакова:
> 
> https://lists.altlinux.org/pipermail/devel-distro/2019-December/001852.html
> 
> Были надежды, что прошивку научат предоставлять dtb ядру. Поэтому выжидали.
> Надежды так пока и не оправдались.

Даже если научат, то 

1) не факт, что вшитый dtb будет правильный
2) не факт, что уже выпущенные желязяки возможно обновить
3) не факт, что встроенный dtb подойдет для более новых ядер
   (чем, например, 4.9.x), или для open source драйверов (например,
   panfrost)

Возможность передать другой dtb через загрузчик сильно облегчает жизнь
в этих ситуациях.

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Alexey Sheplyakov]

On Tue, Mar 31, 2020 at 09:03:28PM +0700, Антон Мидюков wrote:

> По конкретике. Зачаток поддержки devicetree в конфиге был вот в этом патче:
> 
> http://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=grub-2.02-sb-0005-Make-10_linux-work-with-our-changes-for-linux16-and-.patch;h=11b6e2b0259709e1c4c78701163d61eb6b5517a6;hb=2dfa3c486dea760b421124dcae735674f204f9da
> 
> Если бы этого зачатка не было, я бы и не развил эту идею. Патч то этот
> апстримный?

Нет, это патч из RHEL 7.1:

https://github.com/rhboot/grub2/commit/024e7b139cc65bc945ace4c1b3bd0547d07b7314

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Alexey Sheplyakov]

On Tue, Mar 31, 2020 at 07:35:12PM +0400, Alexey Sheplyakov wrote:
> On Tue, Mar 31, 2020 at 09:03:28PM +0700, Антон Мидюков wrote:
> 
> > По конкретике. Зачаток поддержки devicetree в конфиге был вот в этом патче:
> > 
> > http://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=grub-2.02-sb-0005-Make-10_linux-work-with-our-changes-for-linux16-and-.patch;h=11b6e2b0259709e1c4c78701163d61eb6b5517a6;hb=2dfa3c486dea760b421124dcae735674f204f9da
> > 
> > Если бы этого зачатка не было, я бы и не развил эту идею. Патч то этот
> > апстримный?
> 
> Нет, это патч из RHEL 7.1:
> 
> https://github.com/rhboot/grub2/commit/024e7b139cc65bc945ace4c1b3bd0547d07b7314

А в RHEL 8 его переделали аналогично обсуждаемому патчу:

https://github.com/rhboot/grub2/commit/2e702754c5dc8e0858fb16797a396411ebfb22e0

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Dmitry V. Levin]

On Tue, Mar 31, 2020 at 06:58:50PM +0300, Aleksey Novodvorsky wrote:
> вт, 31 мар. 2020 г., 18:51 Alexey Sheplyakov <asheplyakov@basealt.ru>:
> > On Tue, Mar 31, 2020 at 07:35:12PM +0400, Alexey Sheplyakov wrote:
> > > On Tue, Mar 31, 2020 at 09:03:28PM +0700, Антон Мидюков wrote:
> > >
> > > > По конкретике. Зачаток поддержки devicetree в конфиге был вот в этом патче:
> > > >
> > http://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=grub-2.02-sb-0005-Make-10_linux-work-with-our-changes-for-linux16-and-.patch;h=11b6e2b0259709e1c4c78701163d61eb6b5517a6;hb=2dfa3c486dea760b421124dcae735674f204f9da
> > > >
> > > > Если бы этого зачатка не было, я бы и не развил эту идею. Патч то этот
> > > > апстримный?
> > >
> > > Нет, это патч из RHEL 7.1:
> > >
> > https://github.com/rhboot/grub2/commit/024e7b139cc65bc945ace4c1b3bd0547d07b7314
> >
> > А в RHEL 8 его переделали аналогично обсуждаемому патчу:
> >
> > https://github.com/rhboot/grub2/commit/2e702754c5dc8e0858fb16797a396411ebfb22e0
> 
> Мне кажется, что использовать патч RHEL 8  не зазорно.

Рельные патчи бывают разные, но этот патч ничем не хуже большой пачки
других рельных патчей тех же авторов, уже приложенных в этом пакете.

При том количестве сторонних патчей, приложенных в этом пакете, отсылка
в апстрим производит впечатление первого попавшегося предлога послать
подальше.


-- 
ldv

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Антон Мидюков]

31.03.2020 22:58, Aleksey Novodvorsky пишет:
> вт, 31 мар. 2020 г., 18:51 Alexey Sheplyakov <asheplyakov@basealt.ru>:
>
>> On Tue, Mar 31, 2020 at 07:35:12PM +0400, Alexey Sheplyakov wrote:
>>> On Tue, Mar 31, 2020 at 09:03:28PM +0700, Антон Мидюков wrote:
>>>
>>>> По конкретике. Зачаток поддержки devicetree в конфиге был вот в этом
>> патче:
>>>>
>> http://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=grub-2.02-sb-0005-Make-10_linux-work-with-our-changes-for-linux16-and-.patch;h=11b6e2b0259709e1c4c78701163d61eb6b5517a6;hb=2dfa3c486dea760b421124dcae735674f204f9da
>>>> Если бы этого зачатка не было, я бы и не развил эту идею. Патч то этот
>>>> апстримный?
>>> Нет, это патч из RHEL 7.1:
>>>
>>>
>> https://github.com/rhboot/grub2/commit/024e7b139cc65bc945ace4c1b3bd0547d07b7314
>>
>> А в RHEL 8 его переделали аналогично обсуждаемому патчу:
>>
>>
>> https://github.com/rhboot/grub2/commit/2e702754c5dc8e0858fb16797a396411ebfb22e0
> Мне кажется, что использовать патч RHEL 8  не зазорно.
Если он даёт желаемое поведение, можно использовать и его. Правда 
поломаем обновление тем, кто использует предыдущие наши сборки.

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

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Sheplyakov <asheplyakov-SLA8ab5CrdUvJsYlp49lxw@public.gmane.org> writes:

 > On Tue, Mar 31, 2020 at 09:03:28PM +0700, Антон Мидюков wrote:
 >> Дело было в devel-sbc@:
 >> 
 >> https://lists.altlinux.org/pipermail/devel-distro/2019-December/001845.html
 >> 
 >> Получил отрицательный отзыв об этой идеи от Сергея Большакова:
 >> 
 >> https://lists.altlinux.org/pipermail/devel-distro/2019-December/001852.html
 >> 
 >> Были надежды, что прошивку научат предоставлять dtb ядру. Поэтому выжидали.
 >> Надежды так пока и не оправдались.

 > Даже если научат, то 

 > 1) не факт, что вшитый dtb будет правильный
 > 2) не факт, что уже выпущенные желязяки возможно обновить
 > 3) не факт, что встроенный dtb подойдет для более новых ядер
 >    (чем, например, 4.9.x), или для open source драйверов (например,
 >    panfrost)

 > Возможность передать другой dtb через загрузчик сильно облегчает жизнь
 > в этих ситуациях.

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

-- 

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Антон Мидюков]

01.04.2020 17:31, Sergey Bolshakov пишет:
>>>>>> "Alexey" == Alexey Sheplyakov <asheplyakov-SLA8ab5CrdUvJsYlp49lxw@public.gmane.org> writes:
>   > On Tue, Mar 31, 2020 at 09:03:28PM +0700, Антон Мидюков wrote:
>   >> Дело было в devel-sbc@:
>   >>
>   >> https://lists.altlinux.org/pipermail/devel-distro/2019-December/001845.html
>   >>
>   >> Получил отрицательный отзыв об этой идеи от Сергея Большакова:
>   >>
>   >> https://lists.altlinux.org/pipermail/devel-distro/2019-December/001852.html
>   >>
>   >> Были надежды, что прошивку научат предоставлять dtb ядру. Поэтому выжидали.
>   >> Надежды так пока и не оправдались.
>
>   > Даже если научат, то
>
>   > 1) не факт, что вшитый dtb будет правильный
>   > 2) не факт, что уже выпущенные желязяки возможно обновить
>   > 3) не факт, что встроенный dtb подойдет для более новых ядер
>   >    (чем, например, 4.9.x), или для open source драйверов (например,
>   >    panfrost)
>
>   > Возможность передать другой dtb через загрузчик сильно облегчает жизнь
>   > в этих ситуациях.
>
> Подобные аргументы легко развернуть в обратную сторону --
> не факт, что после того, как биос всё же приведут к приличному виду,
> система с таким костылём вообще загрузится; способа же откатить
> это изменение на установленных системах вы не предложили.

В grub можно интерактивно при загрузке удалить строку devicetree и 
загрузиться.

После чего удалить из /etc/sysconfig/grub2 строку с параметром 
GRUB_FDT_LINUX и сделать:

update-grub

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

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Alexey Sheplyakov]

On Wed, Apr 01, 2020 at 02:32:11PM +0700, Антон Мидюков wrote:
> 31.03.2020 22:58, Aleksey Novodvorsky пишет:
> > вт, 31 мар. 2020 г., 18:51 Alexey Sheplyakov <asheplyakov@basealt.ru>:
> > 
> > > On Tue, Mar 31, 2020 at 07:35:12PM +0400, Alexey Sheplyakov wrote:
> > > > On Tue, Mar 31, 2020 at 09:03:28PM +0700, Антон Мидюков wrote:
> > > > 
> > > > > По конкретике. Зачаток поддержки devicetree в конфиге был вот в этом
> > > патче:
> > > > > 
> > > http://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=grub-2.02-sb-0005-Make-10_linux-work-with-our-changes-for-linux16-and-.patch;h=11b6e2b0259709e1c4c78701163d61eb6b5517a6;hb=2dfa3c486dea760b421124dcae735674f204f9da
> > > > > Если бы этого зачатка не было, я бы и не развил эту идею. Патч то этот
> > > > > апстримный?
> > > > Нет, это патч из RHEL 7.1:
> > > > 
> > > > 
> > > https://github.com/rhboot/grub2/commit/024e7b139cc65bc945ace4c1b3bd0547d07b7314
> > > 
> > > А в RHEL 8 его переделали аналогично обсуждаемому патчу:
> > > 
> > > 
> > > https://github.com/rhboot/grub2/commit/2e702754c5dc8e0858fb16797a396411ebfb22e0
> > Мне кажется, что использовать патч RHEL 8  не зазорно.
> Если он даёт желаемое поведение, можно использовать и его.

У RHEL немного другие соглашения о том, куда устанавливать dtb файлы:
/boot/dtb-`uname -r`. У нас: /lib/devicetree/dtb-`uname -r`, и симлинк
/boot/dtb на самую свежую версию (по аналогии с /boot/vmlinuz).

Потому RHEL патч все равно надо адаптировать, и в итоге получается такой
же патч (с точностью до имени переменной), как и предложенный ранее
http://git.altlinux.org/tasks/243217/gears/1200/git?p=git;a=blob;f=grub-2.02-support-GRUB_FDT_LINUX.patch;h=575c664e265219297a980650ef747f8a63037653;hb=5741e6cdb26580ecc366cc6ec8c4f7d07f400e8e

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Alexey Sheplyakov]

On Wed, Apr 01, 2020 at 01:29:43PM +0300, Aleksey Novodvorsky wrote:

> Обсудил с sbolshakov@.
> Проблема в том, что в случае обновления bios с целью стандартизации, -- а
> оно вроде намечено БЭ, -- система не загрузится.

Не вполне верное утверждение. Если UEFI выдает такое же FDT, какое
записано на диске, никакой разницы нет, и система загрузится. Если UEFI
выдает несовместимое FDT, то ядро все равно не загрузится (независимо от
того, патчили grub или нет).

> Какие варианты я вижу:
> 1. Спросить у БЭ об их намерениях касательно прошивки этой платы при ее
> запуске в production. Будет стандартизация или нет.
> 2. Сейчас в любом случае собрать в стороне grub с предложенным патчем и
> использовать в сборках для этой платы с предупреждением на вики.

Он и так "собран в стороне", но после первого же обновления grub система
не загрузится (т.к. в grub.cfg не будет строчки `devicetree`).

> всего несколько десятков и релиза у нас нет, сильно не навредим.
> 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

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Evgeny Sinelnikov]

Добрый день,

я бы хотел поддержать Атона и Алексея в впросе принятия патча для
поддержки нестандартного железа и опции 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)

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Антон Мидюков]

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

Возможность использования dtb, соответствующего ядру, может пригодиться 
при использовании режима загрузки u-boot + grub-efi на одноплатниках. По 
сути это будет аналог тому, что у нас есть сейчас: u-boot + 
extlinux.conf, в котором указан дефолтный путь для поиска dtb. Но, 
должен признать, менее удобный в том плане, что придётся привязываться к 
одноплатнику в конфиге. Но привязку можно делать на этапе установки 
u-boot скриптом alt-rootfs-installer, например.

Предоставление на одноплатниках с aarch64 возможности использовать 
grub-efi выглядит отличным решением, так как это повышает удобство 
загрузки. Можно интерактивно поменять параметры загрузки, выбрать ядро, 
с которым грузиться. Сейчас большинство пользователей, пока им не 
скажешь, не знают, что на этапе загрузки одноплатника можно выбрать 
ядро, с которым грузиться. grub привычен пользователям десктопных 
Линуксов ( о! да здесь всё как на PC!). А потому использование grub на 
одноплатниках облегчает пользователям их использование.

[...]

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

Re: [devel] grub FDT patch (grub versus Baikal-M)

[Sergey Bolshakov]

>>>>> "Антон" == Антон Мидюков <midyukov-anton-k+OT61UuxXo@public.gmane.org> writes:

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

 > Возможность использования dtb, соответствующего ядру, может
 > пригодиться при использовании режима загрузки u-boot + grub-efi на
 > одноплатниках. По сути это будет аналог тому, что у нас есть сейчас:
 > u-boot + extlinux.conf, в котором указан дефолтный путь для поиска
 > dtb. Но, должен признать, менее удобный в том плане, что придётся
 > привязываться к одноплатнику в конфиге. Но привязку можно делать на
 > этапе установки u-boot скриптом alt-rootfs-installer, например.

 > Предоставление на одноплатниках с aarch64 возможности использовать
 > grub-efi выглядит отличным решением, так как это повышает удобство
 > загрузки. Можно интерактивно поменять параметры загрузки, выбрать
 > ядро, с которым грузиться. Сейчас большинство пользователей, пока им
 > не скажешь, не знают, что на этапе загрузки одноплатника можно выбрать
 > ядро, с которым грузиться. grub привычен пользователям десктопных
 > Линуксов ( о! да здесь всё как на PC!). А потому использование grub на
 > одноплатниках облегчает пользователям их использование.

 > [...]

Не вижу препятствий.
Только вот грузить в такой схеме dtb из grub бессмысленно и даже вредно,
поскольку при этом теряется вся информация, которую первичный загрузчик
(u-boot) передаёт ядру, модифицируя свой экземпляр dtb в памяти, grub же
просто заменит (иначе он не умеет, да и не может) на исходный вариант
с диска.

--