1. 13 Jan, 2015 14 commits
  2. 12 Jan, 2015 10 commits
  3. 11 Jan, 2015 4 commits
  4. 10 Jan, 2015 2 commits
  5. 09 Jan, 2015 6 commits
    • Alexey Brodkin's avatar
      arc: introduce "mdbtrick" target · 4c8c485a
      Alexey Brodkin authored
      MetaWare debugger (MDB) is still used as a primary tool for interaction
      with target via JTAG. Moreover some very advanced features are not yet
      implemented in GDB for ARC (and not sure if they will be implemnted
      sometime soon given complexity and rare need for those features for
      common user).
      
      So if we're talking about development process when U-Boot is loaded in
      target memory not by low-level boot-loader but manually through JTAG
      chances are high developer uses MDB for it.
      
      But MDB doesn't support PIE (position-independent executable) - it will
      refuse to even start - that means no chance to load elf contents on
      target.
      Then the only way to load U-Boot in MDB is to fake it by:
        1. Reset PIE flag in ELF header
           This is simpe - on attempt to open elf MDB checks header and if it
      doesn't match its expectation refuces to use provided elf.
        2. Strip all debug information from elf
           If (1) is done then MDB will open elf but on parsing of elf's debug
      info it will refuse to process due to debug info it cannot understand
      (symbols with PIE relocation).
      
      Even though it could be done manually (I got it documented quite a while
      ago here http://www.denx.de/wiki/U-Boot/ARCNotes
      
      ) having this automated
      way is very convenient. User may build U-Boot that will be loaded on
      target via MDB saying "make mdbtrick".
      
      Then if we now apply the manipulation MDB will happily start and will
      load all required sections into the target.
      
      Indeed there will be no source-level debug info available. But still MDB
      will do its work on showing disassembly, global symbols, registers,
      accessing low-level debug facilities etc.
      
      As a summary - this is a pretty dirty hack but it simplifies life a lot
      for us ARc developers.
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Tom Rini <trini@ti.com>
      Cc: Wolfgang Denk <wd@denx.de>
      4c8c485a
    • Masahiro Yamada's avatar
      mtd: nand: do not scan BBT after scrub · ab37b76d
      Masahiro Yamada authored
      
      
      Currently, "nand scrub" runs chip->scan_bbt at the end of
      nand_erase_opts() even if NAND_SKIP_BBTSCAN flag is set.
      
      It violates the intention of NAND_SKIP_BBTSCAN.
      
      Move NAND_SKIP_BBTSCAN flag check to nand_block_checkbad() so that
      chip->scan_bbt() is never run if NAND_SKIP_BBTSCAN is set.
      
      Also, unset NAND_BBT_SCANNED flag instead of running chip->scan_bbt()
      right after scrub.  We can be lazier here because the BBT is scanned
      at the next call of nand_block_checkbad().
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Scott Wood <scottwood@freescale.com>
      ab37b76d
    • Masahiro Yamada's avatar
      mtd: nand: Mark the BBT as scanned prior to calling scan_bbt again · bf80ee6e
      Masahiro Yamada authored
      Commit 35c204d8 (nand: reinstate lazy bad block scanning)
      broke NAND_BBT_USE_FLASH feature.
      
      Its git-log claimed that it reinstated the change as by commit
      fb49454b ("nand: reinstate lazy bad block scanning"), but it moved
      "chip->options |= NAND_BBT_SCANNED" below "chip->scan_bbt(mtd);".
      
      It causes recursion if scan_bbt does not find a flash based BBT
      and tries to write one, and the attempt to erase the BBT area
      causes a bad block check.
      
      Reinstate commit ff49ea89
      
       (NAND: Mark the BBT as scanned prior to
      calling scan_bbt.).
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Rostislav Lisovy <lisovy@merica.cz>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Scott Wood <scottwood@freescale.com>
      bf80ee6e
    • Masahiro Yamada's avatar
      mtd: nand: revive "nand scrub" command · 756963d7
      Masahiro Yamada authored
      Since commit ff94bc40
      
       (mtd, ubi, ubifs: resync with Linux-3.14),
      the "nand scrub" command has not been working.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Heiko Schocher <hs@denx.de>
      756963d7
    • Stefan Agner's avatar
      arm: vf610: fix boot from SD-card · b188067f
      Stefan Agner authored
      Boot from SD-card (and probably also from NAND) was broken since
      commit d6d07a9b
      
       ("arm: vf610: add NAND support for vf610twr").
      It looks like the increased size of U-Boot lead to a situation
      where the boot ROM overwrote its own stack/heap while loading
      U-Boot from the SD-card to the SRAM. However, U-Boot worked fine
      when loaded through USB serial loader directly into SRAM. It
      looks like loading from SD-card uses other stack/heap location
      then the serial loader (or maybe no stack or heap at all).
      This fix moves U-Boot to gfxRAM, which is 512kB in size and is not
      used by the boot ROM nor the SD-card loader of it.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Acked-by: default avatarBill Pringlemeir <bpringlemeir@nbsps.com>
      b188067f
    • Stefan Agner's avatar
      arm: build arch memset/memcpy in Thumb2 mode · 75d7a0d7
      Stefan Agner authored
      
      
      Resynchronize memcpy/memset with kernel 3.17 and build them in
      Thumb2 mode (unified syntax). Those assembler files can be built
      and linked in ARM mode too, however when calling them from Thumb2
      built code, the stack got corrupted and the copy did not succeed
      (the exact details have not been traced back). However, the Linux
      kernel builds those files in Thumb2 mode. Hence U-Boot should
      build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set.
      
      To build the files without warning, some assembler instructions
      had to be replaced with their UAL compliant variant (thanks
      Jeroen for this input).
      
      To build the file in Thumb2 mode the implicit-it=always option need
      to be set to generate Thumb2 compliant IT instructions where needed.
      We add this option to the general AFLAGS when building for Thumb2.
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Tested-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      75d7a0d7
  6. 08 Jan, 2015 4 commits
    • Tom Rini's avatar
      f10d86d3
    • Fabio Estevam's avatar
      mx25: Fix boot hang by avoiding vector relocation · 906d6fe3
      Fabio Estevam authored
      Since commit 3ff46cc4
      
       ("arm: relocate the exception vectors") mx25pdk
      hangs like this:
      
      CPU:   Freescale i.MX25 rev1.2 at 399 MHz
      Reset cause: WDOG
      Board: MX25PDK
      I2C:   ready
      DRAM:  64 MiB
      (hangs)
      
      Add a specific relocate_vectors macro that skips the vector relocation, as the
      i.MX25 SoC does not provide RAM at the high vectors address (0xFFFF0000), and
      (0x00000000) maps to ROM.
      
      This allows mx25 to boot again.
      Acked-By: default avatarBill Pringlemeir <bpringlemeir@nbsps.com>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      906d6fe3
    • Peng Fan's avatar
      imx:mx6sxsabresd support qspi AHB read · adc0fabf
      Peng Fan authored
      
      
      Add CONFIG_SYS_FSL_QSPI_AHB in header file to enable AHB in driver.
      In order to count the time, add CONFIG_CMD_TIME.
      
      Using AHB read can improve the the read speed about 30%.
      
      AHB read:
      => time sf read 0x8f800000 0 100000
      SF: 1048576 bytes @ 0x0 Read: OK
      time: 0.174 seconds
      
      => time sf read 0x8f800000 1000000 100000
      SF: 1048576 bytes @ 0x1000000 Read: OK
      time: 0.174 seconds
      
      IP read:
      => time sf read 0x8f800000 0 100000
      SF: 1048576 bytes @ 0x0 Read: OK
      time: 0.227 seconds
      
      => time sf read 0x8f800000 1000000 100000
      SF: 1048576 bytes @ 0x1000000 Read: OK
      time: 0.227 seconds
      
      Note:
      Quad read is not supported in driver, now. In my side, using AHB and Quad read
      can achieve about 16MB/s. Anyway, I have plan to reimplement the driver using
      DTB and DM, then make the code cleaner and more feature can be added.
      Signed-off-by: default avatarPeng Fan <Peng.Fan@freescale.com>
      Reviewed-by: default avatarJagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
      adc0fabf
    • Peng Fan's avatar
      qspi:fsl implement AHB read · 5f7f70c1
      Peng Fan authored
      
      
      The QSPI controller in i.MX 6SoloX and Vybrid supports reading data using
      IP register and AHB bus.
      
      The original driver only supports reading data from IP interface. The IC
      team suggests to use AHB read which is faster then IP read. Using AHB read,
      we can directly memcpy, a "missed" access to the buffer will cause the
      controller to clear the buffer and use the SEQID stored in bfgencr register
      to initiate a read from flash device.
      
      Since AHB bus is 64 bit width, we can not set MCR register using 32bit. In
      order to minimize code change, redefine QSPI_MCR_END_CFD_LE to 64bit Little
      endian but not 32bit Little endia.
      
      Introduce a new configuration option CONFIG_SYS_FSL_QSPI_AHB. If want to
      use AHB read, just define CONFIG_SYS_FSL_QSPI_AHB. If not, just ignore it.
      Actually if Vybrid is migrated to use AHB read, this option can be removed and
      IP read function can be discared. The reason to introduce this option
      is that only i.MX SOC is tested in my side, no Vybrid platform for me.
      
      In spi_setup_slave, the original piece code to set AHB is deleted, since
      Vybrid platform does not use this to intiate AHB read. Instead, add
      qspi_init_ahb_read function if defined CONFIG_SYS_FSL_QSPI_AHB.
      Signed-off-by: default avatarPeng Fan <Peng.Fan@freescale.com>
      Reviewed-by: default avatarJagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
      5f7f70c1