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

[Wolfgang Denk]

Dear Steven Stallion,

In message <CAGGHmKH3W6SQSwG3qKJHQmRaxS7ZRVJmbLw_anvgNA61=pcevw at mail.gmail.com> you wrote:
>
> > "bootm" has a well-known an documented API: it takes up to three
> > arguments: kernel address, ramdisk address, and device tree address.
> > Nothing else.
> 
> Is there a reason that this should only be used by Linux? The changes
> I have submitted follow the same behavior as NetBSD. VxWorks and QNX
> also have their own quirks that don't follow the same path/usage as
> Linux.

Agreed.  But this should be documented, then.

> The usage seems to indicate this is a valid approach:
> 
> Usage:
> bootm [addr [arg ...]]
> 
> If this is such a contentious change, I'm happy to drop it. I was
> following the NetBSD approach since it was the most similar. It would
> be a shame to let it go - it's useful.

Please do not misunderstand me - all I'm asking is to document the
exact behaviour.

Personally, I consider the interface a bad design, especially the
different handling (or ignorance) of the "bootargs" setting depending
on the number of arguments.  But I agree that this has already crept
in.  It's a pity yo want to use exactly this interface, but it's you
who has to use (and suffer from) it, so I won;t really block it.  I've
raised my concerns, that's all.

> >> 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 ...
> 
> This would only happen if a user did not configure the loader appropriately.

...which is just a typo away.

> >> 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?
> 
> Plan 9 was traditionally loaded from FAT on PC architectures. Much of
> that support still exists today. Typically, a small FAT partition
> exists, which houses the kernel and the configuration (plan9.ini).
> With U-Boot, to emulate this behavior a fatload would be issued to
> copy the file to the proper location. This allows users to modify
> their configuration and reboot without having to drop into the U-Boot
> shell.

You can still do this with U-Boot.  I see no problems here.

> If do_plan9_bootm writes a NUL byte if no bootargs are defined, this
> would break the fatload method.

Oops?  I cannot parse this.

> > 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.
> 
> It's known to both the producer and consumer, but can change during
> development. Having it compiled in also means that you do not have
> quick access to the value to use for a fatload, though this is a minor
> annoyance.

I disagree.  It appears that when you load a kernel image, there is no
way to find out what the required confaddr would be.  You have to know
it.  If you have several images with different settings, you always
have to know exactly what is what.  That's not exactly a robust (nor
intelligent) setup.

> > 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.
> 
> It's a known address for known kernels but needs to have the
> flexibility to change without a recompile. Personal feelings aside,
> this is how the kernel handles configuration at boot - I can only do
> so much.

I don't know about Plan 9, but is there no way to pass this
information to the boot loader?  For example, if you were using a
device tree, you could ncode it there, so UBoot could pick it up.
Alternatively, you could use FIT images and include an extra blob with
information (and if it's just the confaddr environment setting) for
use in U-Boot, etc. ...

> I very much want these changes (or an acceptable version of them) to
> go upstream. Most users tend to just hack up U-Boot for the boards
> they use and maintain private forks, but I would like to see better
> support in both directions. I'm happy to keep a fork, but these
> changes do not seem onerous, especially given that other operating
> systems that are already supported follow this exact behavior.

I do not intend to block this - I'm just pointing out issues I'm
anticipating.

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
"It may be that our role on this planet is not to worship God but  to
create him."                                       - Arthur C. Clarke