On Mon, 03 Jun 2019 10:02:57 PDT (-0700), tr...@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 <sch...@suse.de> wrote:
>
> On Mai 29 2019, Karsten Merker <mer...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
