[U-Boot] [PATCH 5/5] New implementation for internal handling of environment variables.

[Wolfgang Denk <wd@denx.de>]

Dear Kim Phillips,

In message <20100719193825.120ebf29.kim.phillips@freescale.com> you wrote:
>
> > - It would be nice if we could add wildcard support for environment
> >   variables; this is needed for variable name auto-completion,
> >   but it would also be nice to be able to say "printenv ip*" or
> >   "printenv *addr*"
> 
> you were right - a grepenv/findenv/'env search' substring
> implementation on top of this looks to be at least as expensive as a
> full export operation :/

Expensive in terms of what?  Code size? Probably not. It all boils
down to running strstr() over all entries...

> >  int var_complete(int argc, char * const argv[], char last_char, int maxv, char *cmdv[])
> >  {
> > +#if 0 /* need to reimplement */
> 
> ouch - this is u-boot's most useful feature :)

He. We should probably run a poll for UMUF :-)

> It would be good to know boot time overhead the initial import function
> makes, esp. in terms of number of boot-time accesses to the
> environment...

I don't see any significant changes on the systems I tested...

Example TQM5200:

MPC5200 at 400 MHz, 16 KiB environment size, ~2 KiB used:

relevant env settings:

nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}  
addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1  
addcons=setenv bootargs ${bootargs} console=${console},${baudrate}  
net_nfs=tftp ${kernel_addr_r} ${bootfile}; tftp ${fdt_addr_r} ${fdt_file}; run nfsargs addip addcons; bootm ${kernel_addr_r} - ${fdt_addr_r}  
bootcmd=run net_nfs  

old: U-Boot 2010.03-00167-g6e5fb4e (Apr 27 2010 - 15:37:15)
new: U-Boot 2010.06-00208-g7151bce-dirty (Jul 18 2010 - 00:36:48)

   old   new
 0.000   0.000 U-Boot 2010.03-00167-g6e5fb4e (Apr 27 2010 - 15:37:15)   
 0.000   0.000  
 0.000   0.000 CPU:   MPC5200B v2.2, Core v1.4 at 396 MHz  
 0.000   0.000        Bus 132 MHz, IPB 132 MHz, PCI 66 MHz  
 0.040   0.040 Board: TQM5200S (TQ-Components GmbH)  
 0.040   0.040        on a STK52xx carrier board  
 0.040   0.040 I2C:   85 kHz, ready  
 0.040   0.040 DRAM:  64 MB  
 0.080   0.080 FLASH: 32 MB  
 0.120   0.130 In:    serial  
 0.120   0.130 Out:   serial  
 0.120   0.130 Err:   serial  
 0.160   0.130 Net:   FEC ETHERNET  
 0.420   0.400 POST i2c PASSED  
 0.440   0.440 POST cpu PASSED  
 0.920   0.920 IDE:   Bus 0: OK   
 0.920   0.920   Device 0: Model: HITACHI_DK23DA-20 Firm: 00J2A0A1 Ser#: 12Y0MN  
 0.920   0.920             Type: Hard Disk  
 0.920   0.920             Capacity: 19077.1 MB = 18.6 GB (39070080 x 512)  
 2.840   2.871   Device 1: not available  
 2.840   2.871 SRAM:  512 kB  
 4.840   4.860 PS/2:  No device found  
 5.840   5.880 Kbd:   reset failed, no ACK  
 5.880   5.880
 5.880   5.880 Type run flash_nfs to mount root filesystem over NFS   
 5.880   5.880
10.880  10.880 Hit any key to stop autoboot:  0   
12.520  12.480 Using FEC ETHERNET device  
...
13.480  13.361 Bytes transferred = 7275 (1c6b hex)  
13.640  13.400 ## Booting kernel from Legacy Image at 00400000 ...  
13.640  13.400    Image Name:   Linux-2.6.32-rc5-01449-g2c33dca  
...
13.960  13.720 ## Flattened Device Tree blob at 00600000  
13.960  13.720    Booting using the fdt blob at 0x600000  
14.960  13.720    Uncompressing Kernel Image ... OK  
15.040  14.760 [    0.000000] Using mpc5200-simple-platform machine description  
15.040  14.760 [    0.000000] Linux version 2.6.32-rc5-01449-g2c33dca (wd at pollux.denx.de) (gcc version 4.2.2) #1 Mon Nov 2 09:31:00 CET 2009  
...

As you can see, there are stages where the new code is a bit slower
(20...40 milliseconds, which is close to the resolution of the
measurement), but in this specific test we win some 280 milliseconds;
if you exclude the 5 seconds boot delay that's some 2.7%. I don't
think it's worth mentioning, but at least it's not worse than the old
code.


I haven't tested many boards, especially not for timing. If you have
additional input it will be welcome.

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
"If you own a machine, you are in turn owned by it,  and  spend  your
time serving it..."    - Marion Zimmer Bradley, _The Forbidden Tower_