[U-Boot-Users] New commands

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Leonid wrote:
> On Wednesday, May 16, 2007 5:26 AM Wolfgang Denk:
>>> Because command identification are 64bit value and U-BOOT has 63 
>>> commands now. 
>>> We need extend unsigned long long value.
> 
>> Unfortunately the C standard does not define any longer integer data
>> types that can be used directly in the C preprocessor.
> 
>>> What proper solution is?
> 
>> Get rid of the existing coee and come up with a completely new
>> implementation. But this is a non-trivial task.
> 
> There is actually an approach in place, virtually converting single
> u-boot command into root of command tree. See for example how "nand"
> command (or shall I say "nand" tree?) is implemented. Wolfgang, do you
> approve this way of doing or it had sneaked into u-boot "illegally"?
> 
> Of course, this is only half-solution which can provide temporary
> relief. As a matter of fact, I'm using it myself for my proprietary
> commands.
> 
> In my mind, there are two (not mutually excluding) generic ways to
> proceed (backward compatibility will be preserved of course meaning old
> scripts will be still working).
> 
> 1) Strictly hierarchical "CISCO-like" CLI instead of "flat" u-boot
> scheme. There are several existing implementations of such CLI which can
> be used.
> 
> 2) Further advance of "bash"-like shell (hush is used in u-boot right
> now). Existing shell lacks many features one is used to see in
> Linux/Unix shells. It's highly questionable though whether it makes
> sense to add u-boot specific commands in there, making u-boot shell
> scripts incompatible with Linux ones. 
> 
> Best regards,
> 
> Leonid.

Hi Leonid,

I think you are missing the fundamental part of the problem: u-boot uses 
a #defined bitmap to enable and disable commands at compile time.  The 
#defined bitmap can hold, at most, 64 bits and 63 of those bits are 
used.  The fundamental limitation stems from the desire to 
enable/disable commands at compile time in conjunction with how many 
bits gcc (actually, the preprocessor) supports for #if conditional 
compilation.  There are also implicit desires to use & and | to combine 
the #defined bit flags.

This has come up a couple of times, but no good solution has shaken out.

At one time I proposed simply creating a second set of 64 bit command 
enable/disable #defines, but Wolfgang wasn't too keen on that solution. 
  I really cannot think of any other way to maintain the current method 
of compile-time selection and add expansion.  Discussion thread here:
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/24647>

I personally sidestepped the issue by enabling and disabling my new 
"fdt" command based on whether CONFIG_OF_LIBFDT was defined or not, 
thereby not needing to use the last command control bit in the #define.

gvb