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 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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
