[U-Boot] [RFC 0/3] uboot-doc User's Manual Generation Tool
Hello all,
I've been working on writing a User's Manual generation tool, and before
I get too far I'd like to see if this is something the U-Boot community
would be interested in.
The thought was that everyone needs to develop User's Manuals for their
customers, and there's no reason for us all to reinvent the wheel for
each product we create. I've written a Perl script, uboot-doc, which is
very loosely based on the kernel-doc documentation creator in Linux.
(Take it easy on my Perl, this is my first script.) The specific syntax
is described in uboot-doc, but the parser takes formatted comments with
@'s and converts the information into DocBook XML. The DocBook XML can be
used to generate HTML, XHTML, PDFs, and text, and can be extended to change
formatting and appearance. The static portions of the manual are taken
from .tmpl files in the doc/manual/ directory, which have basic
precompiler support (#ifdef, #else, #endif) and support for accessing
system environment variables (${TOPDIR}, for example) and any value
found in autoconf.mk, (@CONFIG_BAUDRATE, for example). All template
files in doc/manual/ can be over-ridden by a board specific file in
board/$BOARDDIR/manual. For example, doc/manual/manual.tmpl would be
over-ridden by board/$BOARDDIR/manual/manual.tmpl.
General Control Flow:
C pre-processor -> doc_stream.pl : pre-processed code gets everything but
comments with an @ stripped away
doc_stream.pl -> autoconf_doc.txt : "interesting" comments get sent to this
file
autoconf_doc.txt -> uboot-doc : file is parsed and comments are turned to XML
*.tmpl -> uboot-doc : template files are processed into XML
*.xml -> xsltproc : XML is converted into desired output format
*.fo -> fop : (PDFs only) fo files are translated to PDF
Steps to compile your very own manual (using Ubuntu package names):
1) Install xsltproc. I'm using version
1.1.24-2ubuntu2. If you've got no desire to make text, html, xhtml, or
pdf you don't need this tool.
2) Install docbook-xsl. I'm using version
1.73.2.dfsg.1-5. If you've got no desire to make text, html, xhtml, or
pdf you don't need this tool.
3) FOP needs to be installed with hyphenation support, which is not
available from Synaptic or apt-get. Use the instructions from
http://www.linuxfromscratch.org/blfs/view/svn/pst/fop.html to install
your version of FOP (yes, you do need OFFO and JAI). You will need to
install ant if you don't already have it (1.7.1-0ubuntu2).
If you've got no desire to make a PDF, you don't need this tool.
4) If you follow the steps above, the default values of DOCBOOK_XSL_DIR,
XSLT_PROCESSOR, and FO_PROCESSOR should be correct. If you decided to
try to go it your own, set them accordingly. DOCBOOK_XSL_DIR points to
your Docbook stylesheet directory, XSLT_PROCESSOR points to the default
program which compiles XML into it's various forms, and FO_PROCESSOR
points the the default program for turning FO images into PDFs.
5) Once you have the tools installed, you should be able to compile a
manual. This documentation feature was tested on the X-ES's XPedite5370.
make XPEDITE5370_config
make {xml/html/xhtml/pdf/text}
Note: text doesn't work yet as I believe there is an issue with the
docbook style sheets (or possibly how I'm using them). It's being looked
into. Something about varlistentries not belonging in varlists? I dunno.
The doc/manual directory also includes a PDF style sheet (uboot_manual.xsl).
By creating your own book_info.tmpl, you can add a company logo
and an address to the cover page. By default these two are left out. It is also
possible to create a completely new style sheet to customize your manual look.
Similarly, HTML output can be customized using CSS. The results of this output
as well as the HTML output can be found on the X-ES website:
www.xes-inc.com/sources/u-boot/index.html
www.xes-inc.com/sources/u-boot/xpedite5370.pdf
Note that I've defined a "mediaobject" and "address" in my custom
board/xes/xpedite5370/book_info.tmpl to place the address and company logo
on the cover page.
I see several advantages to adopting this scheme.
- Documentation should be easier to keep in sync with code
- DocBook XML output can be used to generate webpages, PDFs, text, etc,
which are all extensible
- People don't have to reinvent the wheel when writing documentation
- Source code ends up being thouroughly commented
These patches are just meant to be an example of how in-code documentation
could be used. You'll also notice there are many warnings regarding variables
the manual is referencing which aren't defined yet. I wanted to get some
feedback before diving in too far. What do others think? Is this worth
pursuing?
Thanks,
John
John Schmoller (3):
uboot-doc: Initial support of user documentation generator
uboot-doc: Add example support for uboot-do
[U-Boot] [RFC 2/3] uboot-doc: Add example support for uboot-doc
Add support to a small subset of commands, environment variables, and POSTs. These are meant to show the syntax and capabilities of the uboot-doc parser. Signed-off-by: John Schmoller --- common/cmd_i2c.c| 71 ++- common/cmd_mem.c| 45 +++- common/cmd_net.c| 30 - common/env_common.c | 35 + post/tests.c| 16 +++ 5 files changed, 192 insertions(+), 5 deletions(-) diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c index 8f0fc9e..14d394c 100644 --- a/common/cmd_i2c.c +++ b/common/cmd_i2c.c @@ -1297,7 +1297,70 @@ int do_i2c(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[]) } /***/ - +/** + * @cmd: i2c speed + * @sect: I2C + * @param[or]: speed - target I2C bus speed + * @desc: Show or set I2C bus speed + */ +/** + * @cmd: i2c dev + * @sect: I2C + * @param[or]: dev - I2C device to make current + * @desc: Show or set current I2C bus + */ +/** + * @cmd: i2c md + * @sect: I2C + * @param: chip - I2C address of desired device + * @param: address[.0, .1, .2] - Address into I2C device + * @param[or]: # of objects - Numer of bytes to read + * @desc: Read from I2C device + */ +/** + * @cmd: i2c mm + * @sect: I2C + * @param: chip - I2C address of desired device + * @param: address[.0, .1, .2] - Address into I2C device + * @desc: Write to I2C device (auto-incrementing) + */ +/** + * @cmd: i2c mw + * @sect: I2C + * @param: chip - I2C address of desired device + * @param: address[.0, .1, .2] - Address into I2C device + * @param: value - Value to write to I2C address + * @param[or]: count - Number of bytes to write + * @desc: Write to I2C device (fill) + */ +/** + * @cmd: i2c nm + * @sect: I2C + * @param: chip - I2C address of desired device + * @param: address[.0, .1, .2] - Address into I2C device + * @desc: Write to I2C device (constant address) + */ +/** + * @cmd: i2c crc32 + * @sect: I2C + * @param: chip - I2C address of desired device + * @param: address[.0, .1, .2] - Address into I2C device + * @param: count - Number of bytes to CRC + * @desc: Computes the CRC32 checksum of an address range + */ +/** + * @cmd: i2c probe + * @sect: I2C + * @desc: Shows all the devices on the I2C bus + */ +/** + * @cmd: i2c loop + * @sect: I2C + * @param: chip - I2C address of desired device + * @param: address[.0, .1, .2] - Address into I2C device + * @param: # of objects - Number of bytes to loop over + * @desc: Looping read of device. Never returns. + */ U_BOOT_CMD( i2c, 6, 1, do_i2c, "I2C sub-system", @@ -1317,6 +1380,12 @@ U_BOOT_CMD( "i2c reset - re-init the I2C Controller\n" "i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device" #if defined(CONFIG_CMD_SDRAM) +/** + * @cmd: isdram + * @sect: I2C + * @param: chip - I2C address of desired device + * @desc: Prints SDRAM configuration information + */ "\n" "i2c sdram chip - print SDRAM configuration information" #endif diff --git a/common/cmd_mem.c b/common/cmd_mem.c index cdf8c79..2276a1a 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -1169,20 +1169,61 @@ int do_unzip ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) /**/ +/** + * @cmd: md + * @sect: Memory + * @param[or]: address - memory location to display + * @param[or]: objs - Number of objects to display + * @desc: The md command displays memory contents both as hexadecimal and + * ASCII data. The last displayed memory address and the value of the + * count argument are remembered, so when you enter md again without + * arguments it will automatically continue at the next address, and use + * the same count again. + * + * If invoked as md or md.l, data is displayed as 32-bit long words. If + * invoked as md.w or md.b instead, 16-bit words or 8-bit bytes are used, + * respectively. + */ U_BOOT_CMD( md, 3, 1, do_mem_md, "memory display", "[.b, .w, .l] address [# of objects]" ); - +/** + * @cmd: mm + * @sect: Memory + * @param[or]: address - memory location to modify + * @desc: The mm command is a method to interactively modify memory contents. + * It will display the address and current contents and then prompt for + * user input. If you enter a legal hexadecimal number, this new value + * will be written to the address. Then, the next address will be + * prompted. If you don't enter any value and just press ENTER, then the + * contents of this address will remain unchanged. The command stops as + * soon as you enter any data that is not a hex number. + * + * If invoked as mm or mm.l, data is displayed as 32-bit long words. If + * invoked as mm.w or mm.b instead, 16-bit words or 8-bit bytes
[U-Boot] [RFC 3/3] xpedite5370: Add uboot-doc support
Add uboot-doc support to the XPedite5370. Incorporates
templates to override the defaults and includes memory
maps.
Signed-off-by: John Schmoller
---
board/xes/xpedite5370/manual/book_info.tmpl| 52 ++
board/xes/xpedite5370/manual/booting_linux.tmpl| 179
board/xes/xpedite5370/manual/booting_vxworks.tmpl | 166 ++
board/xes/xpedite5370/manual/manual.tmpl | 30
board/xes/xpedite5370/manual/redundant_images.tmpl | 50 ++
board/xes/xpedite5370/manual/scripting.tmpl| 168 ++
include/configs/XPEDITE5370.h | 47 +
7 files changed, 692 insertions(+), 0 deletions(-)
create mode 100644 board/xes/xpedite5370/manual/book_info.tmpl
create mode 100644 board/xes/xpedite5370/manual/booting_linux.tmpl
create mode 100644 board/xes/xpedite5370/manual/booting_vxworks.tmpl
create mode 100644 board/xes/xpedite5370/manual/manual.tmpl
create mode 100644 board/xes/xpedite5370/manual/redundant_images.tmpl
create mode 100644 board/xes/xpedite5370/manual/scripting.tmpl
diff --git a/board/xes/xpedite5370/manual/book_info.tmpl
b/board/xes/xpedite5370/manual/book_info.tmpl
new file mode 100644
index 000..3e6ec85
--- /dev/null
+++ b/board/xes/xpedite5370/manual/book_info.tmpl
@@ -0,0 +1,52 @@
+
+
+
+ ${BOARD} U-Boot Manual
+ U-Boot User's Manual
+ U-Boot version: ${VERSION}
+ ${BOARD}
+ ${DATE}
+
+Extreme Engineering Solutions, Inc.
+3225 Demming Way, Suite 120
+Middleton,
+WI
+53562-1408
+USA
+Phone: (608) 833-1155
+Fax: (608) 827-6171
+Web: http://xes-inc.com
+E-mail: sa...@xes-inc.com
+
+
+
+
+
+
+
+
+ U-Boot is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2 of
+ the License, or (at your option) any later version.
+
+
+
+ U-Boot is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place, Suite 330
+ Boston, MA 02111-1307
+ USA
+
+
+
+
+
diff --git a/board/xes/xpedite5370/manual/booting_linux.tmpl
b/board/xes/xpedite5370/manual/booting_linux.tmpl
new file mode 100644
index 000..d026d1b
--- /dev/null
+++ b/board/xes/xpedite5370/manual/booting_linux.tmpl
@@ -0,0 +1,179 @@
+
+
+http://docbook.org/ns/docbook";
+xmlns:xi="http://www.w3.org/2001/XInclude";>
+ Booting Linux
+
+
+
+Booting Linux with U-Boot
+
+ Booting Linux
+ The following is intended to be a Quick Start guide for booting a
+ Linux kernel. More information can be found in your Linux Manual.
+
+
+ Your Linux kernel can be booted from either RAM or from Flash.
+ Images booted from RAM will need to be downloaded from the network
+ using tftp
+ on every reset. Images booted from Flash will be copied from Flash to
+ RAM automatically.
+
+
+
+ Booting from RAM
+ To boot an image from RAM, you will need to have your Linux
+ kernel and Flat Device Tree image on a TFTP server. See
+
+ Networking for more information about
+ TFTP and TFTP servers. Next, you will need to set up your
+
+ network environment variables to point to
+ your TFTP server.
+#ifdef CONFIG_CMD_DHCP
+ You can use a DHCP server to accomplish this if
+ your network has one set up using the
+ dhcp command.
+#endif
+ Set osfile
+ to the path to your Linux kernel on your TFTP server and set
+ fdtfile
+ to the path to your Flat Device Tree image on your TFTP server.
+ Finally,
+ type run
+
+ bootcmd_net to download and boot your
+ Linux kernel. This option assumes you are booting an NFS file system.
+
+
+ Your console input/output should look something like this.
+
+=> run bootcmd_net
+Enet starting in 1000BT/FD
+Speed: 1000, full duplex
+Using eTSEC1 device
+TFTP from server 10.52.0.33; our IP address is 10.52.250.134; sending through
gateway 10.52.0.1
+Filename '/home/jschmoller/uImage-XPedite5370-S2.6.23.17-fsl_r1'.
+Load address: 0x100
+Loading: *###
+#
+#
+##
[U-Boot] [PATCH] flash: Fix CFI buffer size bug
Fix bug introduced by 9c048b523413ae5f3ff34e00cf57569c3368ab51.
The cfi_flash.c driver cast the flash buffer size to a uchar in
flash_write_cfibuffer(). On some flash parts, (tested on Numonyx
part PC32F512M29EWH), the buffer size is 1KB. Remove the cast to
uchar to enable buffer sizes to be larger.
Signed-off-by: John Schmoller
---
drivers/mtd/cfi_flash.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 12647ef..1152629 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -971,7 +971,7 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
#endif
flash_write_cmd(info, sector, offset, AMD_CMD_WRITE_TO_BUFFER);
cnt = len >> shift;
- flash_write_cmd(info, sector, offset, (uchar)cnt - 1);
+ flash_write_cmd(info, sector, offset, cnt - 1);
switch (info->portwidth) {
case FLASH_CFI_8BIT:
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] env: Group environment variables
This patch groups environment variables using a non-invasive protocol. Grouping is achieved by setting a "grouping" variable to a string of variables, and setting the master grouping variable, "env_groups" to the list of these grouping variables. For instance, setenv net ipaddr netmask gatewayip serverip setenv boot bootcmd bootdelay bootargs setenv env_groups net boot would print 4 variables grouped under net, 3 variables grouped under boot, and the rest of the variables grouped under "other". If env_groups is not defined, print behaves normally. Signed-off-by: John Schmoller --- I'm interesetd in seeing peoples opinions of this implementation of grouping environment variables. My major concerns about this implementation are 1) Using parse_line() requires placing several potentially large char array (CONFIG_SYS_CBSIZE in size) on the stack. Parse_line() does seem to be the right tool for the job, though. 2) Trying to figure out which enviroment variables have already been printed in groups is less than elegant. Currently, it's a brute-force approach of looking through every entry until a variable is found in a group or not. Suggestions for cleaner algorithms here would be appreciated. Implementation notes: If env_groups is defined, none of the grouping variables will be printed. This seemed to clutter up the printenv output. Grouping environment variables will almost certainly lead to a reqirement for bumping up CONFIG_SYS_MAXARGS. Example output: => printenv === pci variables === pci1inboundmembus=0x pci1inboundmemphys=0x pci1inboundmemsize=0x0800 pci1outboundmembus=0x8000 pci1outboundmemphys=0x8000 pci1outboundmemsize=0x4000 pci1outboundiobus=0x pci1outboundiophys=0xe800 pci1outboundiosize=0x0080 pci2outboundmembus=0xc000 pci2outboundmemphys=0xc000 pci2outboundmemsize=0x1000 === boot variables === bootcmd_flash1=run set_bootargs; bootm 0xfef0 - 0xfff0 bootcmd_flash2=run set_bootargs; bootm 0xf6f0 - 0xf7f0 bootcmd=tftp 1000 home/jschmoller/vxWorks.st;bootvx bootdelay=3 bootfile=/home/shared/pxe/pxelinux.0 bootcmd_net=run set_bootargs; $download_cmd $osaddr $osfile; if test $? -eq 0; then if test -n $fdtaddr; then $download_cmd $fdtaddr $fdtfile; if test $? -eq 0; then bootm $osaddr - $fdtaddr; else; echo FDT DOWNLOAD FAILED; fi; else; bootm $osaddr; fi; else; echo OS DOWNLOAD FAILED; fi; === prog variables === prog_uboot1=$download_cmd $loadaddr $ubootfile; if test $? -eq 0; then protect off 0xfff8 +8; erase 0xfff8 +8; cp.w $loadaddr 0xfff8 4; protect on 0xfff8 +8; cmp.b $loadaddr 0xfff8 8; if test $? -ne 0; then echo PROGRAM FAILED; else; echo PROGRAM SUCCEEDED; fi; else; echo DOWNLOAD FAILED; fi; prog_uboot2=$download_cmd $loadaddr $ubootfile; if test $? -eq 0; then protect off 0xf7f8 +8; erase 0xf7f8 +8; cp.w $loadaddr 0xf7f8 4; protect on 0xf7f8 +8; cmp.b $loadaddr 0xf7f8 8; if test $? -ne 0; then echo PROGRAM FAILED; else; echo PROGRAM SUCCEEDED; fi; else; echo DOWNLOAD FAILED; fi; ubootfile=home/jschmoller/u-boot.bin prog_os1=$download_cmd $osaddr $osfile; if test $? -eq 0; then erase 0xfef0 +$filesize; cp.b $osaddr 0xfef0 $filesize; cmp.b $osaddr 0xfef0 $filesize; if test $? -ne 0; then echo OS PROGRAM FAILED; else; echo OS PROGRAM SUCCEEDED; fi; else; echo OS DOWNLOAD FAILED; fi; prog_os2=$download_cmd $osaddr $osfile; if test $? -eq 0; then erase 0xf6f0 +$filesize; cp.b $osaddr 0xf6f0 $filesize; cmp.b $osaddr 0xf6f0 $filesize; if test $? -ne 0; then echo OS PROGRAM FAILED; else; echo OS PROGRAM SUCCEEDED; fi; else; echo OS DOWNLOAD FAILED; fi; osfile=/home/user/board.uImage osaddr=0x100 prog_fdt1=$download_cmd $fdtaddr $fdtfile; if test $? -eq 0; then erase 0xfff0 +$filesize;cp.b $fdtaddr 0xfff0 $filesize; cmp.b $fdtaddr 0xfff0 $filesize; if test $? -ne 0; then echo FDT PROGRAM FAILED; else; echo FDT PROGRAM SUCCEEDED; fi; else; echo FDT DOWNLOAD FAILED; fi; prog_fdt2=$download_cmd $fdtaddr $fdtfile; if test $? -eq 0; then erase 0xf7f0 +$filesize;cp.b $fdtaddr 0xf7f0 $filesize; cmp.b $fdtaddr 0xf7f0 $filesize; if test $? -ne 0; then echo FDT PROGRAM FAILED; else; echo FDT PROGRAM SUCCEEDED; fi; else; echo FDT DOWNLOAD FAILED; fi; fdtfile=/home/user/board.dtb fdtaddr=c0 === net variables === ## Error: "ipaddr" not defined netmask=255.255.0.0 serverip=10.52.0.33 gatewayip=10.52.0.1 ethaddr=00:17:3c:00:5f:30 ethact=eTSEC1 === board variables === serial#=02091009 board_cfg=90030065B-1 board_rev=SB === junk variables === ## Error: group "junk" not defined === other variables === baudrate=115200 loads_echo=1 preboot= autoload=yes download_cmd=tftp console_args=console=ttyS0,115200 root_args=root=/dev/nfs rw misc_args=ip=on set_bo
Re: [U-Boot] [RFC] env: Group environment variables
On Wed, 2009-11-04 at 13:55 -0400, Mike Frysinger wrote: > On Wednesday 04 November 2009 11:34:12 John Schmoller wrote: > > This patch groups environment variables using a non-invasive protocol. > > Grouping is achieved by setting a "grouping" variable to a string of > > variables, and setting the master grouping variable, "env_groups" to > > the list of these grouping variables. > > > > For instance, > > setenv net ipaddr netmask gatewayip serverip > > setenv boot bootcmd bootdelay bootargs > > setenv env_groups net boot > > > > would print 4 variables grouped under net, 3 variables grouped under > > boot, and the rest of the variables grouped under "other". If env_groups > > is not defined, print behaves normally. > > > > Signed-off-by: John Schmoller > > --- > > I'm interesetd in seeing peoples opinions of this implementation of > > grouping environment variables. My major concerns about this > > implementation are > > my main concern is bloat. while i guess it would make nicer `printenv`, i'm > not going to use it. so please put it behind a config option so it doesnt > waste space on all boards. I can certainly do that. It is a requested feature on the U-Boot task list[1], so I didn't think that was needed, but I'll do it if that's what people want. John [1] http://www.denx.de/wiki/U-Boot/TaskEnvironmentGroups ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] env: Group environment variables
On Wed, 2009-11-04 at 16:36 -0400, Mike Frysinger wrote: > On Wednesday 04 November 2009 13:17:12 John Schmoller wrote: > > On Wed, 2009-11-04 at 13:55 -0400, Mike Frysinger wrote: > > > On Wednesday 04 November 2009 11:34:12 John Schmoller wrote: > > > > This patch groups environment variables using a non-invasive protocol. > > > > Grouping is achieved by setting a "grouping" variable to a string of > > > > variables, and setting the master grouping variable, "env_groups" to > > > > the list of these grouping variables. > > > > > > > > For instance, > > > > setenv net ipaddr netmask gatewayip serverip > > > > setenv boot bootcmd bootdelay bootargs > > > > setenv env_groups net boot > > > > > > > > would print 4 variables grouped under net, 3 variables grouped under > > > > boot, and the rest of the variables grouped under "other". If > > > > env_groups is not defined, print behaves normally. > > > > > > > > Signed-off-by: John Schmoller > > > > --- > > > > I'm interesetd in seeing peoples opinions of this implementation of > > > > grouping environment variables. My major concerns about this > > > > implementation are > > > > > > my main concern is bloat. while i guess it would make nicer `printenv`, > > > i'm not going to use it. so please put it behind a config option so it > > > doesnt waste space on all boards. > > > > I can certainly do that. It is a requested feature on the U-Boot task > > list[1], so I didn't think that was needed, but I'll do it if that's > > what people want. > > sure, i'm not saying people other than me dont want it, just that i dont > think > it's something you can call "core required functionality". Wolfgang's call > of > course, but i'd like to see it behind a CONFIG (preferably disabled by > default). Will do. I'll wait to see if anyone has any other comments about implementation before resending. John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] env: Group environment variables
On Thu, 2009-11-05 at 20:57 +0100, Wolfgang Denk wrote: > > > 2) Trying to figure out which enviroment variables have already been printed > > in groups is less than elegant. Currently, it's a brute-force approach of > > looking through every entry until a variable is found in a group or not. > > Suggestions for cleaner algorithms here would be appreciated. > > The repeated scanning and comparing doesn't make much sense to me. > Probably it makes more sense to use a more suitable data structure > here. How about performing a linear scan of the environment only > once and convert it into a more easily processable data structure, say > a hash table or a binary tree or whatever, and then operate on this. > Here you can easily add additional flags like a pointer which group the > variable belongs to (if any). > > Also, this would make it easier for example to print a sorted list. > > Eventually we should _always_ do that, i. e. replace the standard > copy operation as done in env_relocate*() by a function that not only > copies the environment, but converts it into a new internal > representation. This might be beneficial to accelerate access to > variables, too. This is an excellent suggestion. I'll see what I can whip up. > > => print only a list of groups > > > If env_groups is defined, none of the grouping variables will be printed. > > This seemed to clutter up the printenv output. > > I don't think this is a wise decision. Having "magic" variables which > cannot be seen an idea I dislike. I think the standard "printenv" > (without args) should print the grouping variables as first block. Ok, I'll group the grouping variables into a group of their own. > Also, it would be nice if "prontenv" now would allow to print a group, > i. e. in your example something as "printenv net pci" should be > supported. This is already (accidentally :) supported. a "printenv $net" would do just what you state. > > Grouping environment variables will almost certainly lead to a reqirement > > for > > bumping up CONFIG_SYS_MAXARGS. > > ...which raises the question why there is such a static limit in the > first place. Yes, it was trivial to implement, but maybe this can be > improved? Artificial limits on line lengths and numbers of arguments > are a nice thing - to remove :-) > > > Best regards, > > Wolfgang Denk John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] env: Group environment variables
On Thu, 2009-11-05 at 23:37 +0100, Wolfgang Denk wrote: > Dear John, > > In message <1257452739.8937.1166.ca...@johns> you wrote: > > > > > Also, it would be nice if "prontenv" now would allow to print a group, > > > i. e. in your example something as "printenv net pci" should be > > > supported. > > > > This is already (accidentally :) supported. a "printenv $net" would do > > just what you state. > > Um.. this is not what I mean. So, a "printenv net" would print ipaddr netmask gatewayip serverip A "printenv $net" would print ipaddr=10.52.0.133 netmask=255.255.0.0 gatewayip=10.52.0.1 serverip=10.52.0.33 Do you mean something other than either of those? John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RSA Signed images/configs issue
Hello all,
I've been playing around with signed FIT images and I found some unexpected
behavior.
I was hoping to get some input on whether this behaves as expected or whether
there's
an issue that needs resolving.
I have a board where I am attempting to sign both the config and image nodes of
a FIT
image. I am using two separate keys, one to sign the config, one the images. I
am using
mkimage to set these keys as required. I have found that if I require
config.key for
configs and image.key for images, I boot successfully. But if I have U-Boot
require the
same keys but sign my config node with image.key, this also boots, but prints
RSA failed to verify: -22
This seems like unintended behavior to me. If I have config.key as the required
key for
configs, booting should not succeed if I have my image signed with another
valid key. If
I'm thinking about this correctly, it would mean only one key would need to be
compromised
to infiltrate an image where multiple keys should be required. Can someone
validate my
thinking, or explain what I'm doing/thinking wrong? The patch for this
particular
issue, if indeed it is an issue, is fairly simple.
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 0d548f8..2e7c226 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -230,8 +230,7 @@ int rsa_verify(struct image_sign_info *info,
if (info->required_keynode != -1) {
ret = rsa_verify_with_keynode(info, hash, sig, sig_len,
info->required_keynode);
- if (!ret)
- return ret;
+ return ret;
}
/* Look for a key that matches our hint */
Thanks,
John
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p3060: Add SoC related support for P3060 platform
Hello Kumar, > From: Shengzhou Liu > > Add P3060 SoC specific information:cores setup, LIODN setup, etc > > The P3060 SoC combines six e500mc Power Architecture processor cores > with > high-performance datapath acceleration architecture(DPAA), CoreNet > fabric > infrastructure, as well as network and peripheral interfaces. > > Signed-off-by: Shengzhou Liu > Signed-off-by: Kumar Gala > --- > +#elif defined(CONFIG_PPC_P3060) > +#define CONFIG_MAX_CPUS 8 I admit that I don't know anything about the P3060, but from your commit log above and Freescale standard naming conventions, shouldn't CONFIG_MAX_CPUS be 6? Thanks, John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] cmd history: Match history buffer size to console buffer
Match history buffer size to console buffer size. History buffer size
was hard coded to 256, artificially limiting the command buffer size.
The history buffer now tracks CONFIG_SYS_CBSIZE.
Signed-off-by: John Schmoller
---
common/main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/main.c b/common/main.c
index 2a75550..7ac657f 100644
--- a/common/main.c
+++ b/common/main.c
@@ -526,7 +526,7 @@ void reset_cmd_timeout(void)
#define CTL_CH(c) ((c) - 'a' + 1)
-#define MAX_CMDBUF_SIZE256
+#define MAX_CMDBUF_SIZECONFIG_SYS_CBSIZE
#define CTL_BACKSPACE ('\b')
#define DEL((char)255)
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 0/2] Remove CONFIG_SYS_MAXARGS
The first patch removes CONFIG_SYS_MAXARGS, replacing the staticly defined array with a malloc'd array of the appropriate size. When a function has no upper argument limit (ie, was set to CONFIG_SYS_MAXARGS), it is now set to 0 to indicate this fact. Argument count is now unlimited, within reason and malloc buffer size. The second patch removes cmdtp->maxargs and moves the checks to the individual command functions. Since most functions do bounds checking anyway, it's a a fairly cheap task (sometimes free) to remove this bounds check in common/main.c. In addition, it's more intuitive (in my opinion) if all bounds checking is done in only one place for each function. The second patch also creates a CMD_ERR_USAGE return value, which prints usage when returned. The overall effect of this patch is to reduce code size by an average of 200-250 bytes and, I feel, make things a bit cleaner. I'm looking for comments on these two patches as they are quite invasive, and will definitly cause problems for those people who maintain their own code out-of-tree. They may also require an additional amount of testing. John Schmoller (2): cmd: Remove CONFIG_SYS_MAXARGS command: Remove maxargs from command structure board/BuS/EB+MCF-EV123/EB+MCF-EV123.c |8 +- board/BuS/eb_cpux9k2/cpux9k2.c|5 +- board/MAI/AmigaOneG3SE/cmd_boota.c|6 +- board/MAI/menu/cmd_menu.c |6 +- board/amcc/acadia/cmd_acadia.c|8 +- board/amcc/luan/luan.c|5 +- board/amcc/makalu/cmd_pll.c | 11 +-- board/amcc/taihu/lcd.c| 31 +++--- board/amcc/taihu/taihu.c | 22 ++--- board/amcc/taihu/update.c |5 +- board/amcc/taishan/lcd.c | 48 ++ board/amcc/taishan/showinfo.c | 15 +++- board/amcc/taishan/update.c |5 +- board/amcc/yucca/cmd_yucca.c |8 +- board/amirix/ap1000/ap1000.c | 21 +++- board/amirix/ap1000/powerspan.c |4 +- board/barco/barco.c | 15 +-- board/bc3450/cmd_bc3450.c | 44 + board/bf537-stamp/cmd_bf537led.c |2 +- board/cm-bf527/gpio.c |5 +- board/cm-bf537e/flash.c |5 +- board/cm-bf537u/flash.c |5 +- board/cm5200/cmd_cm5200.c |2 +- board/delta/delta.c |5 +- board/digsy_mtc/cmd_mtc.c | 48 - board/esd/ar405/ar405.c | 20 +++-- board/esd/cms700/cms700.c |5 +- board/esd/common/auto_update.c|5 +- board/esd/common/cmd_loadpci.c|5 +- board/esd/common/lcd.c|8 +- board/esd/common/xilinx_jtag/micro.c |8 +- board/esd/cpci2dp/cpci2dp.c |5 +- board/esd/cpci405/cpci405.c | 14 ++- board/esd/cpci5200/cpci5200.c |5 +- board/esd/cpci750/cpci750.c | 10 ++- board/esd/dasa_sim/cmd_dasa_sim.c |8 +- board/esd/du440/du440.c | 34 +-- board/esd/hh405/hh405.c |5 +- board/esd/ocrtc/cmd_ocrtc.c | 10 ++- board/esd/pci405/cmd_pci405.c |5 +- board/esd/pci405/pci405.c |8 +- board/esd/pf5200/pf5200.c | 15 +++- board/esd/plu405/plu405.c |5 +- board/esd/pmc405de/pmc405de.c | 21 +++- board/esd/pmc440/cmd_pmc440.c | 58 +++- board/esd/tasreg/tasreg.c | 45 - board/esd/vme8349/caddy.c |8 +- board/esd/voh405/voh405.c |5 +- board/evb64260/zuma_pbb.c | 15 +++- board/fads/fads.h |1 - board/freescale/common/pixis.c|9 +- board/freescale/common/sys_eeprom.c |9 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |8 +- board/g2000/g2000.c | 15 +++- board/hymod/bsp.c | 10 +- board/inka4x0/inkadiag.c | 31 +++--- board/keymile/common/keymile_hdlc_enet.c | 10 ++- board/keymile/km_arm/km_arm.c | 11 +-- board/lwmon/lwmon.c | 15 ++-- board/lwmon5/kbd.c|5 +- board/lwmon5/lwmon5.c | 11 +-- board/micronas/vct/smc_eeprom.c | 15 +++- board/mpl/common/common_util.c|3 +- board/mpl/mip405/cmd_mip405.c |5 +- bo
[U-Boot] [PATCH 1/2] console: Fix console buffer overrun
When CONFIG_SYS_CBSIZE equals MAX_CMDBUF_SIZE, a command string of maximum length will overwrite part of the history buffer, causing the board to die. Expand the console_buffer and hist_lines buffer by one character each to hold the missing NULL char. Signed-off-by: John Schmoller --- common/main.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/common/main.c b/common/main.c index 10d8904..2a75550 100644 --- a/common/main.c +++ b/common/main.c @@ -68,7 +68,7 @@ static int abortboot(int); #undef DEBUG_PARSER -charconsole_buffer[CONFIG_SYS_CBSIZE]; /* console I/O buffer */ +charconsole_buffer[CONFIG_SYS_CBSIZE + 1]; /* console I/O buffer */ static char * delete_char (char *buffer, char *p, int *colp, int *np, int plen); static char erase_seq[] = "\b \b"; /* erase sequence */ @@ -546,7 +546,7 @@ static int hist_cur = -1; unsigned hist_num = 0; char* hist_list[HIST_MAX]; -char hist_lines[HIST_MAX][HIST_SIZE]; +char hist_lines[HIST_MAX][HIST_SIZE + 1]; /* Save room for NULL */ #define add_idx_minus_one() ((hist_add_idx == 0) ? hist_max : hist_add_idx-1) -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/2] cmd: Remove CONFIG_SYS_MAXARGS
CONFIG_SYS_MAXARGS is an arbitrary limit on the number of arguments which can be input at the command line. Remove that arbitrary limit. Setting maxargs in the cmdtp to 0 will result in the ability to enter as many arguments as you can hold in CONFIG_SYS_CBSIZE. Signed-off-by: John Schmoller --- board/amcc/makalu/cmd_pll.c |2 +- board/esd/du440/du440.c |4 +- board/fads/fads.h |1 - board/freescale/common/pixis.c|4 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |2 +- board/pxa255_idp/pxa_idp.c|2 +- common/cmd_boot.c |2 +- common/cmd_bootm.c|4 +- common/cmd_diag.c |2 +- common/cmd_display.c |2 +- common/cmd_echo.c |2 +- common/cmd_help.c |4 +- common/cmd_mp.c |2 +- common/cmd_nand.c |2 +- common/cmd_nvedit.c |8 ++-- common/cmd_onenand.c |2 +- common/cmd_test.c |6 ++-- common/command.c | 36 ++--- common/hush.c |5 ++- common/kgdb.c |2 +- common/main.c | 41 +++-- cpu/arm_cortexa8/mx51/clock.c |2 +- cpu/mpc512x/diu.c |2 +- cpu/mpc512x/iim.c |2 +- include/command.h |2 +- include/common.h |4 ++- 26 files changed, 71 insertions(+), 76 deletions(-) diff --git a/board/amcc/makalu/cmd_pll.c b/board/amcc/makalu/cmd_pll.c index 9bae67e..5cadb4a 100644 --- a/board/amcc/makalu/cmd_pll.c +++ b/board/amcc/makalu/cmd_pll.c @@ -236,7 +236,7 @@ ret: } U_BOOT_CMD( - pllalter, CONFIG_SYS_MAXARGS, 1,do_pll_alter, + pllalter, 0, 1,do_pll_alter, "change pll frequence", "pllalter - change pll frequence \n\n\ ** New freq take effect after reset. ** \n\ diff --git a/board/esd/du440/du440.c b/board/esd/du440/du440.c index 111cce5..0c3d976 100644 --- a/board/esd/du440/du440.c +++ b/board/esd/du440/du440.c @@ -841,7 +841,7 @@ int do_time(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) return ret; } U_BOOT_CMD( - time, CONFIG_SYS_MAXARGS, 1, do_time, + time, 0, 1, do_time, "run command and output execution time", "" ); @@ -891,7 +891,7 @@ int do_gfxdemo(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) return 0; } U_BOOT_CMD( - gfxdemo,CONFIG_SYS_MAXARGS, 1, do_gfxdemo, + gfxdemo,0, 1, do_gfxdemo, "demo", "" ); diff --git a/board/fads/fads.h b/board/fads/fads.h index 4ab4b26..c7d2b2d 100644 --- a/board/fads/fads.h +++ b/board/fads/fads.h @@ -140,7 +140,6 @@ #defineCONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ #endif #defineCONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) /* Print Buffer Size */ -#defineCONFIG_SYS_MAXARGS 16 /* max number of command args */ #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot Argument Buffer Size*/ #define CONFIG_SYS_LOAD_ADDR 0x0010 diff --git a/board/freescale/common/pixis.c b/board/freescale/common/pixis.c index 7210512..b4b5d78 100644 --- a/board/freescale/common/pixis.c +++ b/board/freescale/common/pixis.c @@ -354,7 +354,7 @@ int pixis_set_sgmii(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) } U_BOOT_CMD( - pixis_set_sgmii, CONFIG_SYS_MAXARGS, 1, pixis_set_sgmii, + pixis_set_sgmii, 0, 1, pixis_set_sgmii, "pixis_set_sgmii" " - Enable or disable SGMII mode for a given TSEC \n", "\npixis_set_sgmii [TSEC num] \n" @@ -550,7 +550,7 @@ pixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) U_BOOT_CMD( - pixis_reset, CONFIG_SYS_MAXARGS, 1, pixis_reset_cmd, + pixis_reset, 0, 1, pixis_reset_cmd, "Reset the board using the FPGA sequencer", "pixis_reset\n" "pixis_reset [altbank]\n" diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c index 4186a2e..6b8fd28 100644 --- a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c +++ b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c @@ -138,7 +138,7 @@ int mpc8610diu_init_show_bmp(cmd_tbl_t *cmdtp, } U_BOOT_CMD( - diuf
[U-Boot] [RFC 0/2 v2] Remove CONFIG_SYS_MAXARGS
The first patch removes CONFIG_SYS_MAXARGS, replacing the staticly defined array with a malloc'd array of the appropriate size. When a function has no upper argument limit (ie, was set to CONFIG_SYS_MAXARGS), it is now set to 0 to indicate this fact. Argument count is now unlimited, within reason and malloc buffer size. The second patch removes cmdtp->maxargs and moves the checks to the individual command functions. Since most functions do bounds checking anyway, it's a a fairly cheap task (sometimes free) to remove this bounds check in common/main.c. In addition, it's more intuitive (in my opinion) if all bounds checking is done in only one place for each function. The second patch also creates a CMD_ERR_USAGE return value, which prints usage when returned. The overall effect of this patch is to reduce code size by an average of 200-250 bytes and, I feel, make things a bit cleaner. I'm looking for comments on these two patches as they are quite invasive, and will definitly cause problems for those people who maintain their own code out-of-tree. They may also require an additional amount of testing. Changes since v1: - Made 2/2 a subset of the changes of the real patch so it can be submitted to the mailing list and isn't too large. - Found a change in 2/2 that should have been in 1/2. John Schmoller (2): cmd: Remove CONFIG_SYS_MAXARGS command: Remove maxargs from command structure board/amcc/makalu/cmd_pll.c |2 +- board/esd/du440/du440.c |4 +- board/fads/fads.h |1 - board/freescale/common/pixis.c|4 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |2 +- board/pxa255_idp/pxa_idp.c|2 +- common/cmd_boot.c |2 +- common/cmd_bootm.c|4 +- common/cmd_diag.c |2 +- common/cmd_display.c |2 +- common/cmd_echo.c |2 +- common/cmd_eeprom.c |7 +- common/cmd_elf.c | 18 -- common/cmd_help.c |4 +- common/cmd_i2c.c | 75 +--- common/cmd_mp.c |2 +- common/cmd_nand.c |2 +- common/cmd_nvedit.c |8 +- common/cmd_onenand.c |2 +- common/cmd_test.c |6 +- common/command.c | 37 ++--- common/hush.c | 10 +-- common/kgdb.c |2 +- common/lcd.c |5 +- common/main.c | 58 --- cpu/arm_cortexa8/mx51/clock.c |2 +- cpu/mpc512x/diu.c |2 +- cpu/mpc512x/iim.c |2 +- include/command.h | 22 --- include/common.h |4 +- 30 files changed, 137 insertions(+), 158 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/2 v2] cmd: Remove CONFIG_SYS_MAXARGS
CONFIG_SYS_MAXARGS is an arbitrary limit on the number of arguments which can be input at the command line. Remove that arbitrary limit. Setting maxargs in the cmdtp to 0 will result in the ability to enter as many arguments as you can hold in CONFIG_SYS_CBSIZE. Signed-off-by: John Schmoller --- Since v1: - Moved a change from 2/2 to this patch so both compile cleanly independently. board/amcc/makalu/cmd_pll.c |2 +- board/esd/du440/du440.c |4 +- board/fads/fads.h |1 - board/freescale/common/pixis.c|4 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |2 +- board/pxa255_idp/pxa_idp.c|2 +- common/cmd_boot.c |2 +- common/cmd_bootm.c|4 +- common/cmd_diag.c |2 +- common/cmd_display.c |2 +- common/cmd_echo.c |2 +- common/cmd_help.c |4 +- common/cmd_mp.c |2 +- common/cmd_nand.c |2 +- common/cmd_nvedit.c |8 ++-- common/cmd_onenand.c |2 +- common/cmd_test.c |6 ++-- common/command.c | 37 +++--- common/hush.c |5 ++- common/kgdb.c |2 +- common/main.c | 41 +++-- cpu/arm_cortexa8/mx51/clock.c |2 +- cpu/mpc512x/diu.c |2 +- cpu/mpc512x/iim.c |2 +- include/command.h |2 +- include/common.h |4 ++- 26 files changed, 72 insertions(+), 76 deletions(-) diff --git a/board/amcc/makalu/cmd_pll.c b/board/amcc/makalu/cmd_pll.c index 9bae67e..5cadb4a 100644 --- a/board/amcc/makalu/cmd_pll.c +++ b/board/amcc/makalu/cmd_pll.c @@ -236,7 +236,7 @@ ret: } U_BOOT_CMD( - pllalter, CONFIG_SYS_MAXARGS, 1,do_pll_alter, + pllalter, 0, 1,do_pll_alter, "change pll frequence", "pllalter - change pll frequence \n\n\ ** New freq take effect after reset. ** \n\ diff --git a/board/esd/du440/du440.c b/board/esd/du440/du440.c index 111cce5..0c3d976 100644 --- a/board/esd/du440/du440.c +++ b/board/esd/du440/du440.c @@ -841,7 +841,7 @@ int do_time(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) return ret; } U_BOOT_CMD( - time, CONFIG_SYS_MAXARGS, 1, do_time, + time, 0, 1, do_time, "run command and output execution time", "" ); @@ -891,7 +891,7 @@ int do_gfxdemo(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) return 0; } U_BOOT_CMD( - gfxdemo,CONFIG_SYS_MAXARGS, 1, do_gfxdemo, + gfxdemo,0, 1, do_gfxdemo, "demo", "" ); diff --git a/board/fads/fads.h b/board/fads/fads.h index 4ab4b26..c7d2b2d 100644 --- a/board/fads/fads.h +++ b/board/fads/fads.h @@ -140,7 +140,6 @@ #defineCONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ #endif #defineCONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) /* Print Buffer Size */ -#defineCONFIG_SYS_MAXARGS 16 /* max number of command args */ #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot Argument Buffer Size*/ #define CONFIG_SYS_LOAD_ADDR 0x0010 diff --git a/board/freescale/common/pixis.c b/board/freescale/common/pixis.c index 7210512..b4b5d78 100644 --- a/board/freescale/common/pixis.c +++ b/board/freescale/common/pixis.c @@ -354,7 +354,7 @@ int pixis_set_sgmii(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) } U_BOOT_CMD( - pixis_set_sgmii, CONFIG_SYS_MAXARGS, 1, pixis_set_sgmii, + pixis_set_sgmii, 0, 1, pixis_set_sgmii, "pixis_set_sgmii" " - Enable or disable SGMII mode for a given TSEC \n", "\npixis_set_sgmii [TSEC num] \n" @@ -550,7 +550,7 @@ pixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) U_BOOT_CMD( - pixis_reset, CONFIG_SYS_MAXARGS, 1, pixis_reset_cmd, + pixis_reset, 0, 1, pixis_reset_cmd, "Reset the board using the FPGA sequencer", "pixis_reset\n" "pixis_reset [altbank]\n" diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c index 4186a2e..6b8fd28 100644 --- a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c +++ b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c @@ -13
[U-Boot] [RFC 2/2 v2] command: Remove maxargs from command structure
Remove maxargs from the command structure and move bounds checking
to individual functions.
This is a subset of the changes created by the real patch, and is for
reviewing only, and not applying. The real patch is much too large for
the mailing list.
Signed-off-by: John Schmoller
---
Since v1:
- This patch is now a subset of the real patch. It is now small enough to
be posted.
common/cmd_eeprom.c |7 ++---
common/cmd_elf.c| 18
common/cmd_i2c.c| 75 +++
common/hush.c | 11 ++-
common/kgdb.c |2 +-
common/lcd.c|5 +++-
common/main.c | 19 +
include/command.h | 22 +--
8 files changed, 71 insertions(+), 88 deletions(-)
diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c
index 519b510..b645f97 100644
--- a/common/cmd_eeprom.c
+++ b/common/cmd_eeprom.c
@@ -104,8 +104,7 @@ int do_eeprom ( cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
}
- cmd_usage(cmdtp);
- return 1;
+ return CMD_ERR_USAGE;
}
#endif
@@ -422,7 +421,7 @@ void eeprom_init (void)
#ifdef CONFIG_SYS_I2C_MULTI_EEPROMS
U_BOOT_CMD(
- eeprom, 6, 1, do_eeprom,
+ eeprom, 1, do_eeprom,
"EEPROM sub-system",
"read devaddr addr off cnt\n"
"eeprom write devaddr addr off cnt\n"
@@ -430,7 +429,7 @@ U_BOOT_CMD(
);
#else /* One EEPROM */
U_BOOT_CMD(
- eeprom, 5, 1, do_eeprom,
+ eeprom, 1, do_eeprom,
"EEPROM sub-system",
"read addr off cnt\n"
"eeprom write addr off cnt\n"
diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index 63f6fe7..26fa346 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -64,10 +64,13 @@ int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
/* -- */
int rcode = 0;
- if (argc < 2)
+ if (argc == 1) {
addr = load_addr;
- else
+ } else if (argc == 2) {
addr = simple_strtoul (argv[1], NULL, 16);
+ } else {
+ return CMD_ERR_USAGE;
+ }
if (!valid_elf_image (addr))
return 1;
@@ -107,10 +110,13 @@ int do_bootvx (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
* If we don't know where the image is then we're done.
*/
- if (argc < 2)
+ if (argc == 1) {
addr = load_addr;
- else
+ } else if (argc == 2) {
addr = simple_strtoul (argv[1], NULL, 16);
+ } else {
+ return CMD_ERR_USAGE;
+ }
#if defined(CONFIG_CMD_NET)
/* Check to see if we need to tftp the image ourselves before starting
*/
@@ -311,13 +317,13 @@ unsigned long load_elf_image (unsigned long addr)
/* == */
U_BOOT_CMD(
- bootelf, 2, 0, do_bootelf,
+ bootelf, 0, do_bootelf,
"Boot from an ELF image in memory",
" [address] - load address of ELF image."
);
U_BOOT_CMD(
- bootvx, 2, 0, do_bootvx,
+ bootvx, 0, do_bootvx,
"Boot vxWorks from an ELF image",
" [address] - load address of vxWorks ELF image."
);
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 62cbd33..d4d07e5 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -168,10 +168,8 @@ int do_i2c_md ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
alen = i2c_dp_last_alen;
length = i2c_dp_last_length;
- if (argc < 3) {
- cmd_usage(cmdtp);
- return 1;
- }
+ if (argc < 3)
+ return CMD_ERR_USAGE;
if ((flag & CMD_FLAG_REPEAT) == 0) {
/*
@@ -193,10 +191,8 @@ int do_i2c_md ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
for (j = 0; j < 8; j++) {
if (argv[2][j] == '.') {
alen = argv[2][j+1] - '0';
- if (alen > 4) {
- cmd_usage(cmdtp);
- return 1;
- }
+ if (alen > 4)
+ return CMD_ERR_USAGE;
break;
} else if (argv[2][j] == '\0')
break;
@@ -269,10 +265,8 @@ int do_i2c_mw ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
int count;
int j;
- if ((argc < 4) || (argc > 5)) {
- cmd_usage(cmdtp);
- return 1;
- }
+ if ((argc < 4) ||
Re: [U-Boot] [RFC 2/2 v2] command: Remove maxargs from command structure
On Fri, 2010-03-12 at 14:58 -0600, Kim Phillips wrote: > On Fri, 12 Mar 2010 13:25:31 -0600 > John Schmoller wrote: > > > +/* > > + * Command Errors: > > + */ > > +#define CMD_ERR_USAGE 256 > > + > > can we just use something like -EINVAL instead of reinventing the error > codes wheel? The problem with a negative return value, at least as far as I can tell, is that hush will print "exit not allowed from main input shell." run_list_real() returns -2 if the called functions return is < -1, and -2 means exit. If I'm misinterpreting something, let me know. I don't see any problem with using positive EINVAL, though, I didn't notice it existed. John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] several problems with ethernet on MCF5445x
On Tue, 2010-03-23 at 15:50 +0100, w.weg...@astro-kom.de wrote: > Dear list, > > I am trying to get ethernet to work on my custom MCF54455 board > and having some trouble. > > I have a DP83848J PHY connected in MII mode to each of the FEC0 > and FEC1 ports (seperate MDIO connection). Both PHYs are set to > address 0x0. *) Are you sure this is what you want? From the data sheet: Strapping PHY Address 0 puts the part into Isolate Mode. When in the MII isolate mode, the DP83848J does not respond to packet data present at TXD[3:0], TX_EN inputs and presents a high impedance on the TX_CLK, RX_CLK, RX_DV, RX_ER, RXD[3:0], COL, and CRS outputs. When in Isolate mode, the DP83848J will continue to respond to all management transactions. John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/2 v2] Remove CONFIG_SYS_MAXARGS
On Fri, 2010-04-09 at 23:04 +0200, Wolfgang Denk wrote: > Dear John Schmoller, > > In message you wrote: > > The first patch removes CONFIG_SYS_MAXARGS, replacing the staticly defined > > array with a malloc'd array of the appropriate size. When a function has no > > upper argument limit (ie, was set to CONFIG_SYS_MAXARGS), it is now set to 0 > > to indicate this fact. Argument count is now unlimited, within reason and > > malloc buffer size. > > > > The second patch removes cmdtp->maxargs and moves the checks to the > > individual > > command functions. Since most functions do bounds checking anyway, it's a > > a fairly cheap task (sometimes free) to remove this bounds check in > > common/main.c. In addition, it's more intuitive (in my opinion) if all > > bounds > > checking is done in only one place for each function. The second patch also > > creates a CMD_ERR_USAGE return value, which prints usage when returned. The > > overall effect of this patch is to reduce code size by an average of 200-250 > > bytes and, I feel, make things a bit cleaner. > > > > I'm looking for comments on these two patches as they are quite invasive, > > and > > will definitly cause problems for those people who maintain their own code > > out-of-tree. They may also require an additional amount of testing. > > Did you actually run MAKEALL after applying the patches? > > I tried to get a feeling for the impact on the memory footprint, but > it doesn't work for me. I get tons of error messages like these: > I did run MAKEALL on ppc and arm. So, either something must have changed or you're seeing these errors on an arch I don't have a compiler set up for. Are you seeing these errors on all arches or just on a specific arch? I'll try to get to this as soon as I can. John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] POST Problems on MPC8[5/6]xx
Hello all, I'm seeing issues on our MPC8[5/6]xx products in relation to POST testing. I see that the POST word is stored in a spare, unused register in the PIC, but this register seems to be cleared during interrupt_init() when the PIC is reset. This means that I am seeing the POST_ROM tests run (pre interrupt_init()) but the word then gets blown away and the POST_RAM tests do not run (post interrupt_init()). I browsed through the MPC8572 UM and didn't see any obvious replacements for TFRR that wouldn't be reset. Do others see this issue? Freescale guys, are you aware of some other register we can use? Thanks, John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
