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

[Tom Rini]

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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190603/5e79b636/attachment.sig>