On Mon, 03 Jun 2019 10:02:57 PDT (-0700), trini@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@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 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