1. 26 Jun, 2015 1 commit
    • Joe Hershberger's avatar
      Move default y configs out of arch/board Kconfig · c9bb942e
      Joe Hershberger authored
      Some archs/boards specify their own default by pre-defining the config
      which causes the Kconfig system to mix up the order of the configs in
      the defconfigs... This will cause merge pain if allowed to proliferate.
      Remove the configs that behave this way from the archs.
      A few configs still remain, but that is because they only exist as
      defaults and do not have a proper Kconfig entry. Those appear to be:
      Signed-off-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      [trini: rastaban, am43xx_evm_usbhost_boot, am43xx_evm_ethboot updates,
      drop DM_USB from MSI_Primo81 as USB_MUSB_SUNXI isn't converted yet to DM]
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
  2. 04 Jun, 2015 4 commits
  3. 30 Apr, 2015 7 commits
  4. 18 Apr, 2015 4 commits
    • Simon Glass's avatar
      sandbox: Move CONFIG_SYS_VSNPRINTF to Kconfig · 8156345d
      Simon Glass authored
      Move this over to Kconfig and tidy up.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      Kconfig: Move CONFIG_BOOTSTAGE to Kconfig · ee2b2434
      Simon Glass authored
      Move CONFIG_BOOT_STAGE and its associated options to Kconfig. Adjust
      existing users and code.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Masahiro Yamada's avatar
      dm: select CONFIG_DM* options · 58d423b8
      Masahiro Yamada authored
      As mentioned in the previous commit, adding default values in each
      Kconfig causes problems because it does not co-exist with the
      "depends on" syntax.  (Please note this is not a bug of Kconfig.)
      We should not do so unless we have a special reason.  Actually,
      for CONFIG_DM*, we have no good reason to do so.
      Generally, CONFIG_DM is not a user-configurable option.  Once we
      convert a driver into Driver Model, the board only works with Driver
      Model, i.e. CONFIG_DM must be always enabled for that board.
      So, using "select DM" is more suitable rather than allowing users to
      modify it.  Another good thing is, Kconfig warns unmet dependencies
      for "select" syntax, so we easily notice bugs.
      Actually, CONFIG_DM and other related options have been added
      without consistency: some into arch/*/Kconfig, some into
      board/*/Kconfig, and some into configs/*_defconfig.
      This commit prefers "select" and cleans up the following issues.
      [1] Never use "CONFIG_DM=n" in defconfig files
      It is really rare to add "CONFIG_FOO=n" to disable CONFIG options.
      It is more common to use "# CONFIG_FOO is not set".  But here, we
      do not even have to do it.
      Less than half of OMAP3 boards have been converted to Driver Model.
      Adding the default values to arch/arm/cpu/armv7/omap3/Kconfig is
      weird.  Instead, add "select DM" only to appropriate boards, which
      eventually eliminates "CONFIG_DM=n", etc.
      [2] Delete redundant CONFIGs
      Sandbox sets CONFIG_DM in arch/sandbox/Kconfig and defines it again
      in configs/sandbox_defconfig.
      Likewise, OMAP3 sets CONFIG_DM arch/arm/cpu/armv7/omap3/Kconfig and
      defines it also in omap3_beagle_defconfig and devkit8000_defconfig.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
    • Simon Glass's avatar
      dm: x86: spi: Convert ICH SPI driver to driver model · ba457562
      Simon Glass authored
      Convert this driver over to use driver model. Since all x86 platforms use
      it, move x86 to use driver model for SPI and SPI flash. Adjust all dependent
      code and remove the old x86 spi_init() function.
      Note that this does not make full use of the new PCI uclass as yet. We still
      scan the bus looking for the device. It should move to finding its details
      in the device tree.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  5. 17 Apr, 2015 1 commit
    • Simon Glass's avatar
      x86: Add support for panther (Asus Chromebox) · 51e9dad2
      Simon Glass authored
      Support running U-Boot as a coreboot payload. Tested peripherals include:
      - Video (HDMI and DisplayPort)
      - SATA disk
      - Gigabit Ethernet
      - SPI flash
      USB3 does not work. This may be a problem with the USB3 PCI driver or
      something in the USB3 stack and has not been investigated So far this is
      disabled. The SD card slot also does not work.
      For video, coreboot will need to run the OPROM to set this up.
      With this board, bare support (running without coreboot) is not available
      as yet.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  6. 28 Mar, 2015 1 commit
  7. 12 Feb, 2015 2 commits
  8. 06 Feb, 2015 6 commits
  9. 13 Jan, 2015 6 commits
  10. 19 Dec, 2014 1 commit
  11. 14 Dec, 2014 1 commit
  12. 25 Nov, 2014 1 commit
  13. 21 Nov, 2014 5 commits
    • Simon Glass's avatar
      x86: Rename chromebook-x86 to coreboot · fe5b9b44
      Simon Glass authored
      Rename this vendor since it is intended to be used on any platform where
      coreboot runs at reset and then loads U-Boot.
      So far it is only tested on link. When other boards are supported it is
      likely that we will need to move to multiple board names, all under the
      'coreboot' vendor. So while it would be possible to remove the vendor for
      now, that would be short-sighted.
      Suggested-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      x86: ivybridge: Implement SDRAM init · 65dd74a6
      Simon Glass authored
      Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in
      the board directory and the SDRAM SPD information in the device tree. This
      also needs the Intel Management Engine (me.bin) to work. Binary blobs
      everywhere: so far we have MRC, ME and microcode.
      SDRAM init works by setting up various parameters and calling the MRC. This
      in turn does some sort of magic to work out how much memory there is and
      the timing parameters to use. It also sets up the DRAM controllers. When
      the MRC returns, we use the information it provides to map out the
      available memory in U-Boot.
      U-Boot normally moves itself to the top of RAM. On x86 the RAM is not
      generally contiguous, and anyway some RAM may be above 4GB which doesn't
      work in 32-bit mode. So we relocate to the top of the largest block of
      RAM we can find below 4GB. Memory above 4GB is accessible with special
      functions (see physmem).
      It would be possible to build U-Boot in 64-bit mode but this wouldn't
      necessarily provide any more memory, since the largest block is often below
      4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large
      ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit
      kernels directly so this does not pose a limitation in that area. Also there
      are probably parts of U-Boot that will not work correctly in 64-bit mode.
      The MRC is one.
      There is some work remaining in this area. Since memory init is very slow
      (over 500ms) it is possible to save the parameters in SPI flash to speed it
      up next time. Suspend/resume support is not fully implemented, or at least
      it is not efficient.
      With this patch, link boots to a prompt.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      x86: chromebook_link: Implement CAR support (cache as RAM) · 70a09c6c
      Simon Glass authored
      Add support for CAR so that we have memory to use prior to DRAM init.
      On link there is a total of 128KB of CAR available, although some is
      used for the memory reference code.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      x86: Build a .rom file which can be flashed to an x86 machine · fce7b276
      Simon Glass authored
      On x86 machines U-Boot needs to be added to a large ROM image which is
      then flashed onto the target board. The ROM has a particular format so it
      makes sense for U-Boot to build this image automatically. Unfortunately
      it relies on binary blobs so we cannot require this for the default
      build as yet.
      Create a u-boot.rom output file for this purpose.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      x86: Add chromebook_link board · 8ef07571
      Simon Glass authored
      This board is a 'bare' version of the existing 'link 'board. It does not
      require coreboot to run, but is intended to start directly from the reset
      This initial commit has place holders for a wide range of features. These
      will be added in follow-on patches and series. So far it cannot be booted
      as there is no ROM image produced, but it does build without errors.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>