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

From: Tom Rini <trini@konsulko.com>
To: Troy Benjegerdes <troy.benjegerdes@sifive.com>
Cc: "Dany Nativel" <dany.nativel@sifive.com>,
	"Andreas Schwab" <schwab@suse.de>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	u-boot <U-Boot@lists.denx.de>,
	"Björn Töpel" <bjorn.topel@gmail.com>,
	"Karsten Merker" <merker@debian.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>
Subject: Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
Date: Mon, 3 Jun 2019 13:02:57 -0400	[thread overview]
Message-ID: <20190603170257.GF7705@bill-the-cat> (raw)
In-Reply-To: <8D6E3ACE-7AA9-49F9-BF35-15777E7D47CF@sifive.com>

[-- Attachment #1.1: Type: text/plain, Size: 2563 bytes --]

On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote:
> 
> 
> > On Jun 3, 2019, at 5:49 AM, Andreas Schwab <schwab@suse.de> wrote:
> > 
> > On Mai 29 2019, Karsten Merker <merker@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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv