1. 13 Jul, 2009 1 commit
    • Po-Yu Chuang's avatar
      issue write command to base for JEDEC flash · b4db4a76
      Po-Yu Chuang authored
      
      
      For JEDEC flash, we should issue word programming command relative to
      base address rather than sector base address. Original source makes
      SST Flash fails to program sectors which are not on the 0x10000 boundaries.
      
      e.g.
      SST39LF040 uses addr1=0x5555 and addr2=0x2AAA, however, each sector
      is 0x1000 bytes.
      
      Thus, if we issue command to "sector base (0x41000) + offset(0x5555)",
      it sends to 0x46555 and the chip fails to recognize that address.
      
      This patch is tested with SST39LF040.
      Signed-off-by: default avatarPo-Yu Chuang <ratbert@faraday-tech.com>
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      b4db4a76
  2. 03 Jun, 2009 1 commit
    • 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
  3. 04 Apr, 2009 1 commit
  4. 23 Mar, 2009 1 commit
  5. 19 Mar, 2009 1 commit
  6. 11 Feb, 2009 1 commit
  7. 05 Feb, 2009 3 commits
    • Stefan Roese's avatar
      cfi_flash: Fix typo in cfi_flash.c · e1fb6d0d
      Stefan Roese authored
      
      
      Patch "flash/cfi_flash: Use virtual sector start address, not phys"
      introduced a small typo and compilation warning for systems with CFI
      legacy support (e.g. hcu4). This patch fixes it.
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      e1fb6d0d
    • Stefan Roese's avatar
      cfi_flash: Silence compilation warning · ec21d5cf
      Stefan Roese authored
      
      
      Patch "flash/cfi_flash: Use virtual sector start address, not phys"
      introduced a small compilation warning. This patch fixes it.
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      ec21d5cf
    • Becky Bruce's avatar
      flash/cfi_flash: Use virtual sector start address, not phys · 09ce9921
      Becky Bruce authored
      
      
      include/flash.h was commented to say that the address in
      flash_info->start was a physical address.  However, from u-boot's
      point of view, and looking at most flash code, it makes more
      sense for this to be a virtual address.  So I corrected the
      comment to indicate that this was a virtual address.
      
      The only flash driver that was actually treating the address
      as physical was the mtd/cfi_flash driver.  However, this code
      was using it inconsistently as it actually directly dereferenced
      the "start" element, while it used map_physmem to get a
      virtual address in other places.  I changed this driver so
      that the code which initializes the info->start field calls
      map_physmem to get a virtual address, eliminating the need for
      further map_physmem calls.  The code is now consistent.
      
      The *only* place a physical address should be used is when defining the
      flash banks list that is used to initialize the flash_info struct,
      usually found in the board config file.
      Signed-off-by: default avatarBecky Bruce <beckyb@kernel.crashing.org>
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      09ce9921
  8. 04 Feb, 2009 1 commit
  9. 26 Jan, 2009 3 commits
  10. 24 Nov, 2008 4 commits
  11. 31 Oct, 2008 1 commit
    • Wolfgang Denk's avatar
      CFI Driver: Fix "flash not ready" problem · 9abda6ba
      Wolfgang Denk authored
      
      
      This patch fixes a problem on systems where the NOR flash is attached
      to a 64 bit bus.  The toggle bit detection in flash_toggle() is based
      on the assumption that the same flash address is read twice without
      any other interjacent flash accesses.  However, on 32 bit systems the
      function flash_read64() [as currently implemented] does not perform
      an atomic 64 bit read - instead, this is broken down into two 32 bit
      read accesses on addresses "addr" and "addr + 4".  So instead of
      reading a 64 bit value twice from "addr", we see a sequence of 4 32
      bit reads from "addr", "addr + 4", "addr", and "addr + 4".  The
      consequence is that flash_toggle() fails to work.
      
      This patch implements a simple, but somewhat ugly solution, as it
      avoids the use of flash_read64() in this critical place (by breaking
      it down manually into 32 bit read operations) instead of rewriting
      flash_read64() such to perform atomic 64 bit reads as one could
      expect.  However, such a rewrite would require the use of floating
      point load operations, which becomes pretty complex:
      
      	save MSR;
      	set Floating Point Enable bit in MSR;
      	use "lfd" instruction to perform atomic 64 bit read;
      	use "stfd" to store value to temporary variable on stack;
      	load u64 value from temporary variable;
      	restore saved MSR;
      	return u64 value;
      
      The benefit-cost ratio of such an implementation was considered too
      bad to actually attempt this, especially as we can expect that such
      an implementation would not only have a bigger memory footprint but
      also cause a performance degradation.
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      9abda6ba
  12. 18 Oct, 2008 1 commit
  13. 13 Oct, 2008 1 commit
  14. 02 Oct, 2008 1 commit
    • Mike Frysinger's avatar
      cfi_flash: do not reset flash when probe fails · 2215987e
      Mike Frysinger authored
      
      
      The CFI flash driver starts at flash_init() which calls down into
      flash_get_size().  This starts by calling flash_detect_cfi().  If said
      function fails, flash_get_size() finishes by attempting to reset the
      flash.  Unfortunately, it does this with an info->portwidth set to 0x10
      which filters down into flash_make_cmd() and that happily smashes the
      stack by sticking info->portwidth bytes into a cfiword_t variable that
      lives on the stack.  On a 64bit system you probably won't notice, but
      killing the last 8 bytes on a 32bit system usually leads to a corrupt
      return address.  Which is what happens on a Blackfin system.
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      2215987e
  15. 10 Sep, 2008 2 commits
  16. 09 Sep, 2008 1 commit
  17. 20 Aug, 2008 2 commits
  18. 12 Aug, 2008 1 commit
  19. 08 Aug, 2008 1 commit
  20. 06 Aug, 2008 2 commits
  21. 17 Jul, 2008 1 commit
  22. 15 Jul, 2008 1 commit
  23. 19 Jun, 2008 1 commit
    • Stefan Roese's avatar
      cfi-flash: Fix problem in flash_toggle(), busy was not detected reliably · fb8c061e
      Stefan Roese authored
      
      
      This patch simplifies flash_toggle() (AMD commandset), which is used to
      detect if a FLASH device is still busy with erase/program operations. On
      800MHz Canyonlands/Glacier boards (460EX/GT) the current implementation
      did not detect the busy state reliably, resulting in non erased sectors
      etc. This patch now simplifies this function by "just" comparing the
      complete data-word instead of ANDing it with the command-word (0x40)
      before the compatison. It is done the same way in the Linux implementation
      chip_ready() in cfi_cmdset_0002.c.
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      fb8c061e
  24. 03 Jun, 2008 3 commits
  25. 25 Apr, 2008 1 commit
    • Matthias Fuchs's avatar
      cfi-flash: Add CFG_FLASH_AUTOPROTECT_LIST · c63ad632
      Matthias Fuchs authored
      
      
      This patch adds a configurable flash auto protection list that can be used
      to make U-Boot protect flash regions in flash_init().
      
      The idea has been discussed on the u-boot mailing list starting
      on Nov 18th, 2007.
      
      Even this patch brings a new feature it is used as a bugfix for 4xx
      platforms where flash_init() does not completely protect the
      monitor's flash range in all situations.
      
      U-Boot protects the flash range from CFG_MONITOR_BASE to
      (CFG_MONITOR_BASE + monitor_flash_len  - 1) by default. This does not
      include the reset vector at 0xfffffffc.
      
      Example:
      #define CFG_FLASH_AUTOPROTECT_LIST {{0xfff80000, 0x80000}}
      
      This config option will auto protect the last 512k of flash that
      contains the bootloader on board like APC405 and PMC405.
      Signed-off-by: default avatarMatthias Fuchs <matthias.fuchs@esd-electronics.com>
      c63ad632
  26. 12 Apr, 2008 1 commit
  27. 29 Mar, 2008 1 commit
    • Daniel Hellstrom's avatar
      MTD/CFI: flash_read64 is defined a weak function (for SPARC) · 97bf85d7
      Daniel Hellstrom authored
      
      
      SPARC has implemented __raw_readq, it reads 64-bit from any 32-bit address.
      SPARC CPUs implement flash_read64 which calls __raw_readq.
      
      For current SPARC architectures (LEON2 and LEON3) each read from the
      FLASH must lead to a cache miss. This is because FLASH can not be set
      non-cacheable since program code resides there, and alternatively disabling
      cache is poor from performance view, or doing a cache flush between each
      read is even poorer.
      
      Forcing a cache miss on a SPARC is done by a special instruction "lda" -
      load alternative space, the alternative space number (ASI) is processor
      implementation spcific and can be found by including <asm/processor.h>.
      Signed-off-by: default avatarDaniel Hellstrom <daniel@gaisler.com>
      97bf85d7
  28. 28 Mar, 2008 1 commit