From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Wed, 16 May 2007 14:42:24 -0400 Subject: [U-Boot-Users] New commands In-Reply-To: <406A31B117F2734987636D6CCC93EE3C017BA168@ehost011-3.exch011.intermedia.net> References: Your message of "Wed, 16 May 2007 12:46:46 +0200."<2572.4738-30809-160003137-1179312406@seznam.cz> <20070516122613.3889B353AF1@atlas.denx.de> <406A31B117F2734987636D6CCC93EE3C017BA168@ehost011-3.exch011.intermedia.net> Message-ID: <464B5090.9020106@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: 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