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