[U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9

[Wolfgang Denk]

Dear Steven,

In message <CAGGHmKH2NsDoQjBRUcb5XjSjcUOYfcO6CZ8MsjtXDsHh6P6PoQ at mail.gmail.com> you wrote:
>
> Hmm. Are you arguing against supporting command line arguments to bootm, or
> that bootm should copy these arguments to bootargs prior to boot? This has
> actually been very useful to test changes without having to update my
> bootargs environment variable.

"bootm" has a well-known an documented API: it takes up to three
arguments: kernel address, ramdisk address, and device tree address.
Nothing else.

If you want to implement a different interface, this should at least
be documented - but then I doubt if this should be named "bootm".  If
I use it with 3 arguments, I expect the well-known behaviour, on all
systems.

> Where is the best place to document the behavior, README? The code looks as
> though it's common, but unfortunately it's not. plan9.ini(8) requires that
> arguments be terminated with a newline, the NetBSD loader uses spaces.

A readme in doc/ is OK, too.

> > How does it detect if there are valid arguments (versus random crap)
> > in the memory range starting at "confaddr"?  I can see no checksum or
> > similar?
> 
> Some ports (such as OMAP) will stop once it encounters the first non-ASCII
> character. In general, the parsing for the configuration is fairly strict
> and is only a small risk if a user configures the system incorrectly.

Hm.  This is just a subterfuge for there is no security at all, and
you are invoking undefined behaviour ...

> There is also something subtle in not specifying confaddr (or bootargs for
> that matter). Many ports support loading configuration from a FAT file
> system. U-Boot would be no different.

I don't see what this has to do with it?

> > But then makes no sense to use a "confaddr" environment variable for
> > this - the user has no real choice of setting this variable: either it
> > matches the fixed CONFADDR value, in which case it works, or it is
> > different, in which case it will silently fail.  This is bad.
> > I think you should use a CONFIG_SYS_CONFADDR constant instead.
> 
> Ah, this is another subtlety. CONFADDR can change depending on the kernel
> you are booting. Some ports use as much as 64K to store configuration.
> Having to recompile U-Boot and reflash based on a kernel change would add a
> lot of complication and frustration. Having confaddr also makes it somewhat
> simpler to write a generic boot command which will do a fatload rather than
> use bootargs.

You have no way to check for valid data, and you have no way to know
the correct address, because it is neither fixed nor known to both
the producer and the consumer?  I'm sorry, but this is crap.

> Is there a better method to allow confaddr to change without forcing a
> re-compile, or duplication if a user decides to do a fatload rather than
> define bootargs?

I'm sorry, but it appears this design is completely borked, so how
should I answer this?  If you have no way to know the correct
adddress, and the consumer has no way to verify the data it recives,
it's all just trial and error.  Not exactly a robust design, that is.

> --485b395e78db9b448d04de92b574
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">On Fri, Jun 7, 2013 at 1:16 AM, Wolfgang Denk <span dir=3D=
> "ltr">&lt;<a href=3D"mailto:wd at denx.de" target=3D"_blank">wd at denx.de</a>&gt=
> ;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
> lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
> #ccc solid;padding-left:1ex">

Can you PLEASE stop sending HTML?  Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All men should freely use those seven words which have the  power  to
make any marriage run smoothly: You know dear, you may be right.