1. 12 Jan, 2015 2 commits
  2. 11 Jan, 2015 4 commits
  3. 10 Jan, 2015 2 commits
  4. 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: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Tested-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      75d7a0d7
  5. 08 Jan, 2015 15 commits
  6. 07 Jan, 2015 5 commits
  7. 06 Jan, 2015 6 commits