[U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed

[Palmer Dabbelt]

On Mon, 03 Jun 2019 10:02:57 PDT (-0700), trini at konsulko.com wrote:
> On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote:
>> 
>> 
>> > On Jun 3, 2019, at 5:49 AM, Andreas Schwab <schwab at suse.de> wrote:
>> > 
>> > On Mai 29 2019, Karsten Merker <merker at debian.org> wrote:
>> > 
>> >> Mainline U-Boot already uses the distro bootcmd environment for
>> >> the qemu "virt" machine and it works well.
>> > 
>> > The distro_bootcmd doesn't work for the sifive platform yet because it
>> > doesn't set the correct MAC address for booting.
>> > 
>> > Andreas.
>> > 
>> 
>> Before we go an use distro_bootcmd and drag in a bunch of legacy stuff 
>> we really should not be using, can we make some kind of effort to decide
>> what the design goals and boot flow should look like instead using the 
>> default legacy behavior of a bunch of hard to read and maintain CPP
>> macros?
>
> I feel like you're calling "what everyone agreed on and uses today"
> legacy just because it already exists.  It is a bit complex because
> devices are so complex, rather than it having to support one-off
> situations or similar things people usually call "legacy".

The goal in RISC-V land is to avoid inventing our own stuff, particularly when
there's an agreed upon way of doing things.  As far as I can tell the users
(ie, distros) all want this distro_bootcmd stuff because it's what already
works in ARM land.  While I'm not really a bootloader guy, the general
arguments in favor of distro_bootcmd appaer to be "we tried it some other ways
and that was a mess, but this way works".  That is a really strong argument to
me.

>> The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’.
>> 
>> What good does it do linux distros on RiscV to keep using the old boot
>> script format, rather than just load a text file and use ‘env import’? Is there
>> some benefit to this? Do we gain something from the .scr format, like
>> maybe cryptographic signature support?
>
> Writing things out in script format ends up being more natural (and
> easier to understand) than writing things out in environment format.
> This is why while I wish the "uEnv.txt" hook had become more popular and
> widely used, at this point I also understand why it wasn't.  Doing
> a=foo
> b=bar
> c=baz
> magic_name=do this;do that
>
> Was not easier nor more understandable than:
> setenv a foo
> setenv b bar
> setenv c baz
> do this; do that
>
>> How do we want to support secure boot into Debian, Fedora, and Suse,
>> and does distro_bootcmd have a way to do this, or can we come up with
>> some improvement that doesn’t depend on trying to do all the work in
>> CPP macros and U-boot runtime scripts?
>
> I think the general answer about "secure boot" is that distros want
> "UEFI secure boot".  And I want to make sure that's done in such a way
> that things like user-owned secure boot aren't any more difficult than
> vendor secured boot.  It seems like making use of existing secure boot
> mechanisms has set aside as, well, I don't want to throw snark around
> myself, so I'll refrain from speculating.
>
> -- 
> Tom