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

[Steven Stallion]

On Fri, Jun 7, 2013 at 2:57 PM, Wolfgang Denk <wd at denx.de> wrote:
> 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.

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.

> 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.

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.

>> 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.

>> 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.

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

>> 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.

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.

>> 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.

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 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.

Cheers,

Steve