1. 24 Jul, 2013 1 commit
  2. 03 Nov, 2011 1 commit
  3. 16 Jul, 2010 1 commit
    • Becky Bruce's avatar
      83xx/85xx/86xx: LBC register cleanup · f51cdaf1
      Becky Bruce authored
      Currently, 83xx, 86xx, and 85xx have a lot of duplicated code
      dedicated to defining and manipulating the LBC registers.  Merge
      this into a single spot.
      
      To do this, we have to decide on a common name for the data structure
      that holds the lbc registers - it will now be known as fsl_lbc_t, and we
      adopt a common name for the immap layouts that include the lbc - this was
      previously known as either im_lbc or lbus; use the former.
      
      In addition, create accessors for the BR/OR regs that use in/out_be32
      and use those instead of the mismash of access methods currently in play.
      
      I have done a successful ppc build all and tested a board or two from
      each processor family.
      Signed-off-by: default avatarBecky Bruce <beckyb@kernel.crashing.org>
      Acked-by: default avatarKim Phillips <kim.phillips@freescale.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      f51cdaf1
  4. 12 Jun, 2009 1 commit
  5. 29 Oct, 2008 1 commit
  6. 18 Oct, 2008 1 commit
  7. 24 Sep, 2008 1 commit
  8. 12 Jun, 2008 1 commit
    • Becky Bruce's avatar
      Change initdram() return type to phys_size_t · 9973e3c6
      Becky Bruce authored
      This patch changes the return type of initdram() from long int to phys_size_t.
      This is required for a couple of reasons: long int limits the amount of dram
      to 2GB, and u-boot in general is moving over to phys_size_t to represent the
      size of physical memory.  phys_size_t is defined as an unsigned long on almost
      all current platforms.
      
      This patch *only* changes the return type of the initdram function (in
      include/common.h, as well as in each board's implementation of initdram).  It
      does not actually modify the code inside the function on any of the platforms;
      platforms which wish to support more than 2GB of DRAM will need to modify
      their initdram() function code.
      
      Build tested with MAKEALL for ppc, arm, mips, mips-el. Booted on powerpc
      MPC8641HPCN.
      Signed-off-by: default avatarBecky Bruce <becky.bruce@freescale.com>
      9973e3c6
  9. 04 Mar, 2008 1 commit
  10. 08 Jan, 2008 3 commits
  11. 17 Aug, 2007 1 commit
    • Kim Phillips's avatar
      mpc83xx: implement board_add_ram_info · bbea46f7
      Kim Phillips authored
      add board_add_ram_info, to make memory diagnostic output more
      consistent. u-boot banner output now looks like:
      
      DRAM:  256 MB (DDR1, 64-bit, ECC on)
      
      and for boards with SDRAM on the local bus, a line such as this is
      added:
      
      SDRAM: 64 MB (local bus)
      
      also replaced some magic numbers with their equivalent define names.
      Signed-off-by: default avatarKim Phillips <kim.phillips@freescale.com>
      bbea46f7
  12. 02 Mar, 2007 1 commit
    • Paul Gortmaker's avatar
      mpc83xx: U-Boot support for Wind River SBC8349 · 91e25769
      Paul Gortmaker authored
      I've redone the SBC8349 support to match git-current, which
      incorporates all the MPC834x updates from Freescale since the 1.1.6
      release,  including the DDR changes.
      
      I've kept all the SBC8349 files as parallel as possible to the
      MPC8349EMDS ones for ease of maintenance and to allow for easy
      inspection of what was changed to support this board.  Hence the SBC8349
      U-Boot has FDT support and everything else that the MPC8349EMDS has.
      
      Fortunately the Freescale updates added support for boards using CS0,
      but I had to change spd_sdram.c to allow for board specific settings for
      the sdram_clk_cntl (it is/was hard coded to zero, and that remains the
      default if the board doesn't specify a value.)
      
      Hopefully this should be mergeable as-is and require no whitespace
      cleanups or similar, but if something doesn't measure up then let me
      know and I'll fix it.
      
      Thanks,
      Paul.
      91e25769
  13. 04 Nov, 2006 3 commits
  14. 20 Apr, 2006 1 commit
  15. 16 Apr, 2006 1 commit
  16. 16 Mar, 2006 2 commits
  17. 14 Mar, 2006 1 commit
  18. 13 Jan, 2006 1 commit
  19. 12 Jan, 2006 1 commit
  20. 11 Jan, 2006 1 commit
  21. 01 Aug, 2005 1 commit
  22. 28 Jul, 2005 1 commit