On Mon, Jun 03, 2019 at 12:17:43PM -0700, Palmer Dabbelt wrote:
> 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.

Right.  While I'm sure there's room for improvement, the distro_bootcmd
stuff was borne out of working with the distro folks to get what was
needed so they could Just Install on whatever SBC the user had.

And the EBBR spec (which in turn, roughly, is a subset of UEFI) intends
to make that more formal still.

As long as we can avoid <long list of problems I've personally had doing
things on x86_64> I think that's a good thing, overall.

-- 
Tom