1. 06 Feb, 2016 1 commit
  2. 19 Jan, 2016 1 commit
  3. 21 Nov, 2014 1 commit
    • Simon Glass's avatar
      fdt: Allow ft_board_setup() to report failure · e895a4b0
      Simon Glass authored
      This function can fail if the device tree runs out of space. Rather than
      silently booting with an incomplete device tree, allow the failure to be
      detected.
      
      Unfortunately this involves changing a lot of places in the code. I have
      not changed behvaiour to return an error where one is not currently
      returned, to avoid unexpected breakage.
      
      Eventually it would be nice to allow boards to register functions to be
      called to update the device tree. This would avoid all the many functions
      to do this. However it's not clear yet if this should be done using driver
      model or with a linker list. This work is left for later.
      Signed-off-by: 's avatarSimon Glass <sjg@chromium.org>
      Acked-by: 's avatarAnatolij Gustschin <agust@denx.de>
      e895a4b0
  4. 13 Sep, 2014 1 commit
  5. 30 Jul, 2014 2 commits
    • Masahiro Yamada's avatar
      Add board MAINTAINERS files · 93d4334f
      Masahiro Yamada authored
      We have switched to Kconfig and the boards.cfg file is going to
      be removed. We have to retrieve the board status and maintainers
      information from it.
      
      The MAINTAINERS format as in Linux Kernel would be nice
      because we can crib the scripts/get_maintainer.pl script.
      
      After some discussion, we chose to put a MAINTAINERS file under each
      board directory, not the top-level one because we want to collect
      relevant information for a board into a single place.
      
      TODO:
      Modify get_maintainer.pl to scan multiple MAINTAINERS files.
      Signed-off-by: 's avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Suggested-by: 's avatarTom Rini <trini@ti.com>
      Acked-by: 's avatarSimon Glass <sjg@chromium.org>
      93d4334f
    • Masahiro Yamada's avatar
      kconfig: add board Kconfig and defconfig files · dd84058d
      Masahiro Yamada authored
      This commit adds:
       - arch/${ARCH}/Kconfig
          provide a menu to select target boards
       - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
          set CONFIG macros to the appropriate values for each board
       - configs/${TARGET_BOARD}_defconfig
          default setting of each board
      
      (This commit was automatically generated by a conversion script
      based on boards.cfg)
      
      In Linux Kernel, defconfig files are located under
      arch/${ARCH}/configs/ directory.
      It works in Linux Kernel since ARCH is always given from the
      command line for cross compile.
      
      But in U-Boot, ARCH is not given from the command line.
      Which means we cannot know ARCH until the board configuration is done.
      That is why all the "*_defconfig" files should be gathered into a
      single directory ./configs/.
      Signed-off-by: 's avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Acked-by: 's avatarSimon Glass <sjg@chromium.org>
      dd84058d
  6. 25 Nov, 2013 2 commits
  7. 01 Nov, 2013 1 commit
  8. 14 Oct, 2013 1 commit
  9. 20 Aug, 2013 1 commit
  10. 24 Jul, 2013 1 commit
  11. 27 Nov, 2012 1 commit
    • Andy Fleming's avatar
      8xxx: Change all 8*xx_DDR addresses to 8xxx · e76cd5d4
      Andy Fleming authored
      There were a number of shared files that were using
      CONFIG_SYS_MPC85xx_DDR_ADDR, or CONFIG_SYS_MPC86xx_DDR_ADDR, and
      several variants (DDR2, DDR3). A recent patchset added
      85xx-specific ones to code which was used by 86xx systems.
      After reviewing places where these constants were used, and
      noting that the type definitions of the pointers assigned to
      point to those addresses were the same, the cleanest approach
      to fixing this problem was to unify the namespace for the
      85xx, 83xx, and 86xx DDR address definitions.
      
      This patch does:
      
      s/CONFIG_SYS_MPC8.xx_DDR/CONFIG_SYS_MPC8xxx_DDR/g
      
      All 85xx, 86xx, and 83xx have been built with this change.
      Signed-off-by: 's avatarAndy Fleming <afleming@freescale.com>
      Tested-by: 's avatarAndy Fleming <afleming@freescale.com>
      Acked-by: 's avatarKim Phillips <kim.phillips@freescale.com>
      e76cd5d4
  12. 29 Jul, 2012 1 commit
  13. 11 Jan, 2012 7 commits
    • Paul Gortmaker's avatar
      sbc8548: Fix up local bus init to be frequency aware · e2b363ff
      Paul Gortmaker authored
      The code here was copied from the mpc8548cds support, and it
      wasn't using the CONFIG_SYS_LBC_LCRR define, and was just
      unconditionally setting the LCRR_EADC bit.  Snooping with a
      hardware debugger also showed we had LCRR_DBYP set, since we were
      setting it based on a read of an uninitialized lcrr read via
      clkdiv.  Borrow from the code in the tqm85xx.c support to add
      LBC frequency aware masking of these bits.
      
      This change will correct reliability issues associated with trying
      to use the 128MB of LBC 100MHz SDRAM on this board.  Thanks to
      Keith Savage for assistance in diagnosing the root cause of this.
      Signed-off-by: 's avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      e2b363ff
    • Paul Gortmaker's avatar
      sbc8548: enable support for hardware SPD errata workaround · 3e3262bd
      Paul Gortmaker authored
      Existing boards by default have an issue where the LBC SDRAM
      SPD EEPROM and the DDR2 SDRAM SPD EEPROM both land at 0x51.
      
      After the hardware modification listed in the README is made,
      then the DDR2 SPD EEPROM appears at 0x53.  So this implements
      a board specific get_spd() by taking advantage of the existing
      weak linkage, that 1st tries reading at 0x53 and then if that
      fails, it falls back to the old 0x51.
      
      Since the old dependency issue of "SPD implies no LBC SDRAM"
      gets removed with the hardware errata fix, remove that restriction
      in the code, so both LBC SDRAM and SPD can be selected.
      Signed-off-by: 's avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      3e3262bd
    • Paul Gortmaker's avatar
      sbc8548: relocate fixed ddr init code to ddr.c file · 2a6b3b74
      Paul Gortmaker authored
      Nothing to see here, just a relocation of the fixed ddr init
      sequence to live in the actual ddr.c file itself.
      Signed-off-by: 's avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      2a6b3b74
    • Paul Gortmaker's avatar
      sbc8548: Make enabling SPD RAM configuration work · 7e44f2b7
      Paul Gortmaker authored
      Previously, SPD configuration of RAM was non functional on
      this board.  Now that the root cause is known (an i2c address
      conflict), there is a simple end-user workaround - remove the
      old slower local bus 128MB module and then SPD detection on the
      main DDR2 memory module works fine.
      
      We make the enablement of the LBC SDRAM support conditional on
      being not SPD enabled.  We can revisit this dependency as the
      hardware workaround becomes available.
      
      Turning off LBC SDRAM support revealed a couple implict dependencies
      in the tlb/law code that always expected an LBC SDRAM address.
      
      This has been tested with the default 256MB module, a 512MB
      a 1GB and a 2GB, of varying speeds, and the SPD autoconfiguration
      worked fine in all cases.
      
      The default configuration remains to go with the hard coded
      DDR config, so the default build will continue to work on boards
      where people don't bother to read the docs.  But the advantage
      of going to the SPD config is that even the small default module
      gets configured for CL3 instead of CL4.
      Signed-off-by: 's avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      7e44f2b7
    • Paul Gortmaker's avatar
      sbc8548: Fix LBC SDRAM initialization settings · 5f4c6f0d
      Paul Gortmaker authored
      These were cloned from the mpc8548cds platform which has
      a different memory layout (1/2 the size).  Set the values
      by comparing to the register file for the board used during
      JTAG init sequence:
      
      	LSDMR1		0x2863B727	/* PCHALL */
      	LSDMR2		0x0863B727	/* NORMAL */
      	LSDMR3		0x1863B727	/* MRW    */
      	LSDMR4		0x4063B727	/* RFEN   */
      
      This differs from what was there already in that the RFEN is
      not bundled in all four steps implicitly, but issued once
      as the final step.
      
      The other difference seen when comparing vs. the register file init,
      is that since the memory is split across /CS3 and /CS4, the dummy
      writes need to go to 0xf000_0000 _and_ to 0xf400_0000.
      
      We also rewrite the final LBC SDRAM inits as macros, as there is
      no real need for them to be a local variable that is modified
      on the fly at runtime.
      Signed-off-by: 's avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      5f4c6f0d
    • Paul Gortmaker's avatar
      sbc8548: enable ability to boot from alternate flash · f0aec4ea
      Paul Gortmaker authored
      This board has an 8MB soldered on flash, and a 64MB SODIMM
      flash module.  Normally the board boots from the 8MB flash,
      but the hardware can be configured for booting from the 64MB
      flash as well by swapping CS0 and CS6.  This can be handy
      for recovery purposes, or for supporting u-boot and VxBoot
      at the same time.
      
      To support this in u-boot, we need to have different BR0/OR0
      and BR6/OR6 settings in place for when the board is configured
      in this way, and a different TEXT_BASE needs to be used due
      to the larger sector size of the 64MB flash module.
      
      We introduce the suffix _8M and _64M for the BR0/BR6 and the
      OR0/OR6 values so it is clear which is being used to map what
      specific device.
      
      The larger sector size (512k) of the alternate flash needs
      a larger malloc pool, otherwise you'll get failures when
      running saveenv, so bump it up accordingly.
      Signed-off-by: 's avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      f0aec4ea
    • Paul Gortmaker's avatar
      sbc8548: relocate 64MB user flash to sane boundary · 3fd673cf
      Paul Gortmaker authored
      The current situation has the 64MB user flash at an awkward
      alignment; shifted back from 0xfc00_0000 by 8M, to leave an 8MB hole
      for the soldered on boot flash @ EOM.  But to switch to optionally
      supporting booting off the 64MB flash, the 64MB will then be mapped
      at the sane address of 0xfc00_0000.
      
      This leads to awkward things when programming the 64MB flash prior
      to transitioning to it -- i.e. even though the chip spans from
      0xfb80_0000 to 0xff7f_ffff, you would have to program a u-boot image
      into the two sectors from 0xfbf0_0000 --> 0xfbff_ffff so that it was
      in the right place when JP12/SW2.8 were switched to make the 64MB on
      /CS0. (i.e. the chip is only looking at the bits in mask 0x3ff_ffff)
      
      We also have to have three TLB entries responsible for dealing with
      mapping the 64MB flash due to this 8MB of misalignment.
      
      In the end, there is address space from 0xec00_0000 to 0xefff_ffff
      where we can map it, and then the transition from booting from one
      config to the other will be a simple 0xec --> 0xfc mapping.  Plus we
      can toss out a TLB entry.
      
      Note that TLB0 is kept at 64MB and not shrunk down to the 8MB boot
      flash; this means we won't have to change it when the alternate
      config uses the full 64MB for booting, in TLB0.
      Signed-off-by: 's avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      3fd673cf
  14. 11 Nov, 2011 1 commit
  15. 15 Oct, 2011 1 commit
  16. 04 Apr, 2011 2 commits
  17. 14 Jan, 2011 4 commits
  18. 17 Nov, 2010 1 commit
    • Sebastien Carlier's avatar
      Switch from archive libraries to partial linking · 6d8962e8
      Sebastien Carlier authored
      Before this commit, weak symbols were not overridden by non-weak symbols
      found in archive libraries when linking with recent versions of
      binutils.  As stated in the System V ABI, "the link editor does not
      extract archive members to resolve undefined weak symbols".
      
      This commit changes all Makefiles to use partial linking (ld -r) instead
      of creating library archives, which forces all symbols to participate in
      linking, allowing non-weak symbols to override weak symbols as intended.
      This approach is also used by Linux, from which the gmake function
      cmd_link_o_target (defined in config.mk and used in all Makefiles) is
      inspired.
      
      The name of each former library archive is preserved except for
      extensions which change from ".a" to ".o".  This commit updates
      references accordingly where needed, in particular in some linker
      scripts.
      
      This commit reveals board configurations that exclude some features but
      include source files that depend these disabled features in the build,
      resulting in undefined symbols.  Known such cases include:
      - disabling CMD_NET but not CMD_NFS;
      - enabling CONFIG_OF_LIBFDT but not CONFIG_QE.
      Signed-off-by: 's avatarSebastien Carlier <sebastien.carlier@gmail.com>
      6d8962e8
  19. 14 Nov, 2010 1 commit
    • Peter Tyser's avatar
      fsl: Clean up printing of PCI boot info · 8ca78f2c
      Peter Tyser authored
      Previously boards used a variety of indentations, newline styles, and
      colon styles for the PCI information that is printed on bootup.  This
      patch unifies the style to look like:
      
      ...
      NAND:  1024 MiB
      PCIE1: connected as Root Complex
                 Scanning PCI bus 01
              04  01  8086  1010  0200  00
              04  01  8086  1010  0200  00
              03  00  10b5  8112  0604  00
              02  01  10b5  8518  0604  00
              02  02  10b5  8518  0604  00
              08  00  1957  0040  0b20  00
              07  00  10b5  8518  0604  00
              09  00  10b5  8112  0604  00
              07  01  10b5  8518  0604  00
              07  02  10b5  8518  0604  00
              06  00  10b5  8518  0604  00
              02  03  10b5  8518  0604  00
              01  00  10b5  8518  0604  00
      PCIE1: Bus 00 - 0b
      PCIE2: connected as Root Complex
                 Scanning PCI bus 0d
              0d  00  1957  0040  0b20  00
      PCIE2: Bus 0c - 0d
      In:    serial
      ...
      Signed-off-by: 's avatarPeter Tyser <ptyser@xes-inc.com>
      CC: wd@denx.de
      CC: sr@denx.de
      CC: galak@kernel.crashing.org
      8ca78f2c
  20. 18 Oct, 2010 2 commits
    • Wolfgang Denk's avatar
      Makefile: move all Power Architecture boards into boards.cfg · 2ae18241
      Wolfgang Denk authored
      Clean up Makefile, and drop a lot of the config.mk files on the way.
      
      We now also automatically pick all boards that are listed in
      boards.cfg (and with all configurations), so we can drop the redundant
      entries from MAKEALL to avoid building these twice.
      Signed-off-by: 's avatarWolfgang Denk <wd@denx.de>
      2ae18241
    • Wolfgang Denk's avatar
      Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE · 14d0a02a
      Wolfgang Denk authored
      The change is currently needed to be able to remove the board
      configuration scripting from the top level Makefile and replace it by
      a simple, table driven script.
      
      Moving this configuration setting into the "CONFIG_*" name space is
      also desirable because it is needed if we ever should move forward to
      a Kconfig driven configuration system.
      Signed-off-by: 's avatarWolfgang Denk <wd@denx.de>
      14d0a02a
  21. 20 Jul, 2010 1 commit
  22. 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: 's avatarBecky Bruce <beckyb@kernel.crashing.org>
      Acked-by: 's avatarKim Phillips <kim.phillips@freescale.com>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      f51cdaf1
  23. 04 Nov, 2009 1 commit
  24. 27 Oct, 2009 1 commit
  25. 03 Oct, 2009 3 commits