1. 09 Jun, 2009 1 commit
  2. 08 Jun, 2009 1 commit
  3. 04 Jun, 2009 1 commit
  4. 03 Jun, 2009 3 commits
    • Wolfgang Denk's avatar
      Redundant Environment: protect full sector size · dfcd7f21
      Wolfgang Denk authored
      
      
      Several boards used different ways to specify the size of the
      protected area when enabling flash write protection for the sectors
      holding the environment variables: some used CONFIG_ENV_SIZE and
      CONFIG_ENV_SIZE_REDUND, some used CONFIG_ENV_SECT_SIZE, and some even
      a mix of both for the "normal" and the "redundant" areas.
      
      Normally, this makes no difference at all. However, things are
      different when you have to deal with boards that can come with
      different types of flash chips, which may have different sector
      sizes.
      
      Here we may have to chose CONFIG_ENV_SECT_SIZE such that it fits the
      biggest sector size, which may include several sectors on boards using
      the smaller sector flash types. In such a case, using CONFIG_ENV_SIZE
      or CONFIG_ENV_SIZE_REDUND to enable the protection may lead to the
      case that only the first of these sectors get protected, while the
      following ones aren't.
      
      This is no real problem, but it can be confusing for the user -
      especially on boards that use CONFIG_ENV_SECT_SIZE to protect the
      "normal" areas, while using CONFIG_ENV_SIZE_REDUND for the
      "redundant" area.
      
      To avoid such inconsistencies, I changed all sucn boards that I found
      to consistently use CONFIG_ENV_SECT_SIZE for protection. This should
      not cause any functional changes to the code.
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Cc: Paul Ruhland
      Cc: Pantelis Antoniou <panto@intracom.gr>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Gary Jennejohn <garyj@denx.de>
      Cc: Dave Ellis <DGE@sixnetio.com>
      Acked-by: default avatarStefan Roese <sr@denx.de>
      dfcd7f21
    • Ilya Yanok's avatar
      mmc: it's safe to ignore mmc_send_if_cond() return value · b81830f6
      Ilya Yanok authored
      
      
      Return value of mmc_send_if_cond() can be safely ignored (as it is
      done in Linux). This makes older cards work with MXC MCI controller.
      
      Signed-off-by: default avatarIlya Yanok <yanok@emcraft.com>
      b81830f6
    • Stefan Roese's avatar
      cfi_mtd: Fix bug in last sector detection · dba6fcf6
      Stefan Roese authored
      
      
      This patch now enabled this cfi-mtd wrapper to correctly detect and
      erase the last sector in an NOR FLASH device.
      
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      dba6fcf6
  5. 02 Jun, 2009 7 commits
  6. 29 May, 2009 2 commits
  7. 28 May, 2009 2 commits
    • Wolfgang Denk's avatar
    • Stefan Roese's avatar
      jffs2/mtdparts: Fix problem with usage from JFFS2 and MTDPARTS together · 76b5883d
      Stefan Roese authored
      
      
      Currently using JFFS2 with MTDPARTS enabled doesn't work. This is because
      mtdparts_init() is available in both files, cmd_mtdparts.c and
      cmd_jffs2.c. Please note that in the original cmd_jffs2.c file (before
      the jffs2/mtdparts command/file split those 2 different versions
      already existed. So this is nothing new. The main problem is that the
      variables "current_dev" and "current_partnum" are declared in both
      files now. This doesn't work.
      
      This patch now changes the names of those variable to more specific
      names: "current_mtd_dev" and "current_mtd_partnum". This is because
      this patch also changes the declaration from static to global, so
      that they can be used from both files.
      
      Please note that my first tests were not successful. The MTD devices
      selected via mtdparts are now accessed but I'm failing to see the
      directory listed via the "ls" command. Nothing is displayed. Perhaps
      I didn't generate the JFFS2 image correctly (I never used JFFS2 in
      U-Boot before). Not sure. Perhaps somebody else could take a look at
      this as well. I'll continue looking into this on Monday.
      
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Detlev Zundel <dzu@denx.de>
      Cc: Ilya Yanok <yanok@emcraft.com>
      Cc: Renaud barbier <renaud.barbier@ge.com>
      76b5883d
  8. 26 May, 2009 1 commit
  9. 23 May, 2009 3 commits
  10. 20 May, 2009 5 commits
  11. 19 May, 2009 1 commit
    • Graf Yang's avatar
      Blackfin: fix timer_init()/timer_reset() · ec01481d
      Graf Yang authored
      
      
      The timer_init() function was not using the right csync instruction, nor
      was it doing it right after disabling the core timer.
      
      The timer_reset() function would reset the timestamp, but not the actual
      timer, so there was a common edge case where get_timer() return a jump of
      one timestamp (couple milliseconds) right after resetting.  This caused
      many functions to improperly timeout right away.
      
      Signed-off-by: default avatarGraf Yang <graf.yang@analog.com>
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      ec01481d
  12. 16 May, 2009 3 commits
  13. 15 May, 2009 10 commits