1. 30 Apr, 2012 1 commit
  2. 06 Mar, 2012 1 commit
  3. 17 Dec, 2010 1 commit
    • Lei Wen's avatar
      onenand: add yaffs write command · 41c86240
      Lei Wen authored
      Yaffs image require to use the oob to store some info, so when we
      burn the yaffs image, we need to also write the image's oob part
      into flash.
      
      This patch add addition suffix to onenand write to give the uboot
      the power to directly burn the yaffs image to onenand.
      Signed-off-by: default avatarLei Wen <leiwen@marvell.com>
      41c86240
  4. 07 Dec, 2010 1 commit
  5. 29 Oct, 2010 1 commit
  6. 27 Oct, 2010 1 commit
  7. 23 Oct, 2010 1 commit
  8. 24 Jul, 2010 1 commit
  9. 04 Jul, 2010 1 commit
    • Wolfgang Denk's avatar
      Make sure that argv[] argument pointers are not modified. · 54841ab5
      Wolfgang Denk authored
      The hush shell dynamically allocates (and re-allocates) memory for the
      argument strings in the "char *argv[]" argument vector passed to
      commands.  Any code that modifies these pointers will cause serious
      corruption of the malloc data structures and crash U-Boot, so make
      sure the compiler can check that no such modifications are being done
      by changing the code into "char * const argv[]".
      
      This modification is the result of debugging a strange crash caused
      after adding a new command, which used the following argument
      processing code which has been working perfectly fine in all Unix
      systems since version 6 - but not so in U-Boot:
      
      int main (int argc, char **argv)
      {
      	while (--argc > 0 && **++argv == '-') {
      /* ====> */	while (*++*argv) {
      			switch (**argv) {
      			case 'd':
      				debug++;
      				break;
      			...
      			default:
      				usage ();
      			}
      		}
      	}
      	...
      }
      
      The line marked "====>" will corrupt the malloc data structures and
      usually cause U-Boot to crash when the next command gets executed by
      the shell.  With the modification, the compiler will prevent this with
      an
      	error: increment of read-only location '*argv'
      
      N.B.: The code above can be trivially rewritten like this:
      
      	while (--argc > 0 && **++argv == '-') {
      		char *arg = *argv;
      		while (*++arg) {
      			switch (*arg) {
      			...
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Acked-by: default avatarMike Frysinger <vapier@gentoo.org>
      54841ab5
  10. 05 May, 2010 1 commit
    • Frans Meulenbroeks's avatar
      cmd_onenand.c: moved to standard subcommand handling · 8cd85282
      Frans Meulenbroeks authored
      On the fly also fixed the following things:
      - write help talked about a parameter oob, but that one was not used, so
        removed it from the help message.
      - the test command also allowed a force subcommand but didn't use it.
        eliminated the code.
      - do_onenand made static
      - do_onenand contained
      	int blocksize;
      	...
      	mtd = &onenand_mtd;
      	this = mtd->priv;
      	blocksize = (1 << this->erase_shift);
        As blocksize was not used the last two statements were unneeded so
        removed them.
        The first statement (mtd = ....) assigns to a global. Not sure if it
        is needed, and since I could not test this, left the line for now
      Signed-off-by: default avatarFrans Meulenbroeks <fransmeulenbroeks@gmail.com>
      8cd85282
  11. 08 Dec, 2009 1 commit
  12. 07 Jul, 2009 1 commit
  13. 12 Jun, 2009 2 commits
    • Wolfgang Denk's avatar
      General help message cleanup · a89c33db
      Wolfgang Denk authored
      Many of the help messages were not really helpful; for example, many
      commands that take no arguments would not print a correct synopsis
      line, but "No additional help available." which is not exactly wrong,
      but not helpful either.
      
      Commit ``Make "usage" messages more helpful.'' changed this
      partially. But it also became clear that lots of "Usage" and "Help"
      messages (fields "usage" and "help" in struct cmd_tbl_s respective)
      were actually redundant.
      
      This patch cleans this up - for example:
      
      Before:
      	=> help dtt
      	dtt - Digital Thermometer and Thermostat
      
      	Usage:
      	dtt         - Read temperature from digital thermometer and thermostat.
      
      After:
      	=> help dtt
      	dtt - Read temperature from Digital Thermometer and Thermostat
      
      	Usage:
      	dtt
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      a89c33db
    • Stefan Roese's avatar
      mtd: Update MTD infrastructure to support 64bit device size · 8d2effea
      Stefan Roese authored
      This patch brings the U-Boot MTD infrastructure in sync with the current
      Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size
      support and a resync of the mtdpart.c file which has seen multiple fixes
      meanwhile.
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Kyungmin Park <kmpark@infradead.org>
      8d2effea
  14. 28 Jan, 2009 2 commits
  15. 23 Jan, 2009 1 commit
  16. 21 Aug, 2008 1 commit
  17. 12 Aug, 2008 2 commits
  18. 10 Aug, 2008 1 commit
    • dirk.behme@googlemail.com's avatar
      OneNAND: Remove base address offset usage · aa5ffa16
      dirk.behme@googlemail.com authored
      While locally preparing some U-Boot patches for ARM based OMAP3 boards, some
      using OneNAND and some using NAND, we found some differences in OneNAND and
      NAND command address handling.
      
      As this might confuse users (it already confused us), we like to align OneNAND
      and NAND address handling.
      
      The issue is that cmd_onenand.c subtracts the onenand base address from the
      addresses you type into the u-boot command line so, unlike nand, you can't
      use addresses relative to the start of the onenand part e.g. this won't work:
      
      onenand read 82000000 280000 400000
      
      you have to use:
      
      onenand read 82000000 20280000 400000
      
      Looking at recent git, the only board currently using OneNAND is Apollon, and
      for this the OneNAND base address is 0 (apollon.h)
      
      #define	CFG_ONENAND_BASE	0x00000000
      
      so patch below won't break any existing boards and will align OneNAND and NAND
      handling on boards where OneNAND base address is != 0.
      Signed-off-by: default avatarSteve Sakoman <sakoman@gmail.com>
      Signed-off-by: default avatarManikandan Pillai <mani.pillai@ti.com>
      Signed-off-by: default avatarDirk Behme <dirk.behme@gmail.com>
      aa5ffa16
  19. 13 Jul, 2008 1 commit
  20. 14 Apr, 2008 1 commit
  21. 17 Sep, 2007 1 commit