1. 13 11月, 2015 1 次提交
  2. 05 8月, 2015 3 次提交
  3. 15 7月, 2015 1 次提交
  4. 04 6月, 2015 1 次提交
  5. 17 4月, 2015 1 次提交
  6. 24 1月, 2015 2 次提交
  7. 13 1月, 2015 4 次提交
  8. 19 12月, 2014 3 次提交
  9. 25 11月, 2014 8 次提交
  10. 21 11月, 2014 5 次提交
    • S
      x86: ivybridge: Implement SDRAM init · 65dd74a6
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      65dd74a6
    • S
      x86: chromebook_link: Enable GPIO support · 437c2b7c
      Simon Glass 提交于
      Enable GPIO support and provide the required GPIO setup information to
      the driver.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      437c2b7c
    • S
      x86: ivybridge: Enable PCI in early init · 6e5b12b6
      Simon Glass 提交于
      Enable PCI so we can access devices that need to be set up before relocation.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      6e5b12b6
    • S
      x86: Build a .rom file which can be flashed to an x86 machine · fce7b276
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      fce7b276
    • S
      x86: Add chromebook_link board · 8ef07571
      Simon Glass 提交于
      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
      vector.
      
      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: NSimon Glass <sjg@chromium.org>
      8ef07571