1. 13 Jan, 2015 22 commits
  2. 12 Jan, 2015 10 commits
  3. 11 Jan, 2015 4 commits
  4. 10 Jan, 2015 2 commits
  5. 09 Jan, 2015 2 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