u-boot environments, esp. when boards are shared across multiple
users, can get pretty large and time consuming to visually parse.
The grepenv command this patch adds can be used in lieu of printenv
to facilitate searching. grepenv works like printenv but limits
its output only to environment strings (variable name and value
pairs) that match the user specified substring.
the following examples are on a board with a 5313 byte environment
that spans multiple screen pages:
Example 1: summarize ethernet configuration:
=> grepenv eth TSEC
etact=FM1@DTSEC2
eth=FM1@DTSEC4
ethact=FM1@DTSEC2
eth1addr=00:E0:0C:00:8b:01
eth2addr=00:E0:0C:00:8b:02
eth3addr=00:E0:0C:00:8b:03
eth4addr=00:E0:0C:00:8b:04
eth5addr=00:E0:0C:00:8b:05
eth6addr=00:E0:0C:00:8b:06
eth7addr=00:E0:0C:00:8b:07
eth8addr=00:E0:0C:00:8b:08
eth9addr=00:E0:0C:00:8b:09
ethaddr=00:E0:0C:00:8b:00
netdev=eth0
uprcw=setenv ethact $eth;setenv filename p4080ds/R_PPSXX_0xe/rcw_0xe_2sgmii_rev2_high.bin;setenv start 0xe8000000;protect off all;run upimage;protect on all
upuboot=setenv ethact $eth;setenv filename u-boot.bin;setenv start eff80000;protect off all;run upimage;protect on all
upucode=setenv ethact $eth;setenv filename fsl_fman_ucode_P4080_101_6.bin;setenv start 0xef000000;protect off all;run upimage;protect on all
usdboot=setenv ethact $eth;tftp 1000000 $dir/$bootfile;tftp 2000000 $dir/initramfs.cpio.gz.uboot;tftp c00000 $dir/p4080ds-usdpaa.dtb;setenv bootargs root=/dev/ram rw console=ttyS0,115200 $othbootargs;bootm 1000000 2000000 c00000;
=>
Example 2: detect unused env vars:
=> grepenv etact
etact=FM1@DTSEC2
=>
Example 3: reveal hardcoded variables; e.g., for fdtaddr:
=> grepenv fdtaddr
fdtaddr=c00000
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr
=> grep $fdtaddr
fdtaddr=c00000
my_boot=bootm 0x40000000 0x41000000 0x00c00000
my_dtb=tftp 0x00c00000 $prefix/p4080ds.dtb
nohvboot=tftp 1000000 $dir/$bootfile;tftp 2000000 $dir/$ramdiskfile;tftp c00000 $dir/$fdtfile;setenv bootargs root=/dev/ram rw ramdisk_size=0x10000000 console=ttyS0,115200;bootm 1000000 2000000 c00000;
=>
This patch also enables the grepenv command by default on
corenet_ds based boards (and repositions the DHCP command
entry to keep the list sorted).
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>
The non-reentrant versions of the hashtable functions operate on a single
shared hashtable. So if two different people try using these funcs for
two different purposes, they'll cause problems for the other.
Avoid this by converting all existing hashtable consumers over to the
reentrant versions and then punting the non-reentrant ones.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This implementation is based on code from uClibc-0.9.30.3 but was
modified and extended for use within U-Boot.
Major modifications and extensions:
* hsearch() [modified / extended]:
- While the standard version does not make any assumptions about
the type of the stored data objects at all, this implementation
works with NUL terminated strings only.
- Instead of storing just pointers to the original objects, we
create local copies so the caller does not need to care about the
data any more.
- The standard implementation does not provide a way to update an
existing entry. This version will create a new entry or update an
existing one when both "action == ENTER" and "item.data != NULL".
- hsearch_r(): Instead of returning 1 on success, we return the
index into the internal hash table, which is also guaranteed to be
positive. This allows us direct access to the found hash table
slot for example for functions like hdelete().
* hdelete() [added]:
- The standard implementation of hsearch(3) does not provide any way
to delete any entries from the hash table. We extend the code to
do that.
* hexport() [added]:
- Export the data stored in the hash table in linearized form:
Entries are exported as "name=value" strings, separated by an
arbitrary (non-NUL, of course) separator character. This allows to
use this function both when formatting the U-Boot environment for
external storage (using '\0' as separator), but also when using it
for the "printenv" command to print all variables, simply by using
as '\n" as separator. This can also be used for new features like
exporting the environment data as text file, including the option
for later re-import.
- The entries in the result list will be sorted by ascending key
values.
* himport() [added]:
- Import linearized data into hash table. This is the inverse
function to hexport(): it takes a linear list of "name=value"
pairs and creates hash table entries from it.
- Entries without "value", i. e. consisting of only "name" or
"name=", will cause this entry to be deleted from the hash table.
- The "flag" argument can be used to control the behaviour: when
the H_NOCLEAR bit is set, then an existing hash table will kept,
i. e. new data will be added to an existing hash table;
otherwise, old data will be discarded and a new hash table will
be created.
- The separator character for the "name=value" pairs can be
selected, so we both support importing from externally stored
environment data (separated by NUL characters) and from plain text
files (entries separated by newline characters).
- To allow for nicely formatted text input, leading white space
(sequences of SPACE and TAB chars) is ignored, and entries
starting (after removal of any leading white space) with a '#'
character are considered comments and ignored.
- NOTE: this means that a variable name cannot start with a '#'
character.
- When using a non-NUL separator character, backslash is used as
escape character in the value part, allowing for example fo
multi-line values.
- In theory, arbitrary separator characters can be used, but only
'\0' and '\n' have really been tested.
Signed-off-by: Wolfgang Denk <wd@denx.de>
