1. 05 Aug, 2015 2 commits
    • Simon Glass's avatar
      x86: Allow use of global_data with EFI · 8f3b9694
      Simon Glass authored
      
      
      On x86 the global_data pointer is provided through a somewhat-bizarre and
      x86-specific mechanism: the F segment register is set to a pointer to the
      start of global_data, so that accesses can use this build-in register.
      
      When running as an EFI application we don't want to mess with the Global
      Descriptor Table (GDT) and there is little advantage (in terms of code size)
      to doing so.
      
      Allow global_data to be a simple variable in this case.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      8f3b9694
    • Simon Glass's avatar
      x86: Tidy up global_data flags · 83ec7de3
      Simon Glass authored
      
      
      These flags now overlap some global ones. Adjust the x86-specific flags to
      avoid this. Since this requires a change to the start.S code, add a way for
      tools to find the 32-bit cold reset entry point. Previously this was at a
      fixed offset.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      83ec7de3
  2. 30 Apr, 2015 1 commit
  3. 24 Jan, 2015 2 commits
  4. 13 Jan, 2015 2 commits
    • Simon Glass's avatar
      x86: Add support for MTRRs · aff2523f
      Simon Glass authored
      
      
      Memory Type Range Registers are used to tell the CPU whether memory is
      cacheable and if so the cache write mode to use.
      
      Clean up the existing header file to follow style, and remove the unneeded
      code.
      
      These can speed up booting so should be supported. Add these to global_data
      so they can be requested while booting. We will apply the changes during
      relocation (in a later commit).
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      aff2523f
    • Bin Meng's avatar
      pci: Make pci apis usable before relocation · 8f9052fd
      Bin Meng authored
      
      
      Introduce a gd->hose to save the pci hose in the early phase so that
      apis in drivers/pci/pci.c can be used before relocation. Architecture
      codes need assign a valid gd->hose in the early phase.
      
      Some variables are declared as static so change them to be either
      stack variable or global data member so that they can be used before
      relocation, except the 'indent' used by CONFIG_PCI_SCAN_SHOW which
      just affects some print format.
      Signed-off-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      8f9052fd
  5. 14 Dec, 2014 1 commit
    • Bin Meng's avatar
      x86: Support Intel FSP initialization path in start.S · bceb9f0f
      Bin Meng authored
      
      
      Per Intel FSP architecture specification, FSP provides 3 routines
      for bootloader to call. The first one is the TempRamInit (aka
      Cache-As-Ram initialization) and the second one is the FspInit
      which does the memory bring up (like MRC for other x86 targets)
      and chipset initialization. Those two routines have to be called
      before U-Boot jumping to board_init_f in start.S.
      
      The FspInit() will return several memory blocks called Hand Off
      Blocks (HOBs) whose format is described in Platform Initialization
      (PI) specification (part of the UEFI specication) to the bootloader.
      Save this HOB address to the U-Boot global data for later use.
      Signed-off-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      bceb9f0f
  6. 21 Nov, 2014 7 commits
    • 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>
      65dd74a6
    • Simon Glass's avatar
      x86: ivybridge: Add support for early GPIO init · 1b4f25ff
      Simon Glass authored
      
      
      When not relying on Coreboot for GPIO init the GPIOs must be set up
      correctly. This is currently done statically through a rather ugly method.
      As the GPIOs are figured out they can be moved to the device tree and set
      up as needed rather than all at the start.
      
      In this implementation, board files should call ich_gpio_set_gpio_map()
      before the GPIO driver is used in order to provide the GPIO information.
      We use the early PCI interface so that this driver can now be used before
      relocation.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      1b4f25ff
    • Simon Glass's avatar
      x86: ivybridge: Add early init for PCH devices · 8e0df066
      Simon Glass authored
      
      
      Many PCH devices are hard-coded to a particular PCI address. Set these
      up early in case they are needed.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      8e0df066
    • Simon Glass's avatar
      x86: Support use of PCI before relocation · 7430f108
      Simon Glass authored
      
      
      Add support for using PCI before SDRAM is available, using early malloc()
      and global_data.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      7430f108
    • Bin Meng's avatar
      x86: Save TSC frequency in the global data · 258b1357
      Bin Meng authored
      
      
      Return the saved TSC frequency in get_tbclk_mhz().
      Signed-off-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      Tested-by: default avatarSimon Glass <sjg@chromium.org>
      258b1357
    • Bin Meng's avatar
      x86: Do CPU identification in the early phase · 52f952bf
      Bin Meng authored
      
      
      The CPU identification happens in x86_cpu_init_f() and corresponding
      fields are saved in the global data for later use.
      Signed-off-by: default avatarBin Meng <bmeng.cn@gmail.com>
      52f952bf
    • Simon Glass's avatar
      x86: Save the BIST value on reset · f67cd51e
      Simon Glass authored
      
      
      The built in self test value is available in register eax on start-up. Save
      it so that it can be accessed later. Unfortunately we must wait until the
      global_data is available before we can do this, so there is a little bit of
      shuffling to keep it around.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      f67cd51e
  7. 24 Jul, 2013 1 commit
  8. 26 Jun, 2013 1 commit
  9. 04 Mar, 2013 2 commits
  10. 04 Feb, 2013 1 commit
  11. 01 Feb, 2013 4 commits
  12. 06 Dec, 2012 1 commit
    • Gabe Black's avatar
      x86: Add back cold- and warm-boot flags · 91d82a29
      Gabe Black authored
      
      
      These were removed, but actually are useful.
      
      Cold means that we started from a reset/power on.
      Warm means that we started from another U-Boot.
      
      We determine whether u-boot on x86 was warm or cold booted (really if
      it started at the beginning of the text segment or at the ELF entry point).
      We plumb the result through to the global data structure.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      91d82a29
  13. 30 Nov, 2012 1 commit
  14. 28 Nov, 2012 3 commits
  15. 19 Oct, 2012 1 commit
  16. 09 Aug, 2012 1 commit
  17. 04 Jan, 2012 1 commit
    • Graeme Russ's avatar
      x86: Use fs for global data · 9e6c572f
      Graeme Russ authored
      Use the base address of the 'F' segment as a pointer to the global data
      structure. By adding the linear address (i.e. the 'D' segment address) as
      the first word of the global data structure, the address of the global data
      relative to the 'D' segment can be found simply, for example, by:
      
      	fs movl 0, %eax
      
      This makes the gd 'pointer' writable prior to relocation (by reloading the
      Global Desctriptor Table) which brings x86 into line with all other arches
      
      NOTE: Writing to the gd 'pointer' is expensive (but we only do it
      twice) but using it to access global data members (read and write) is
      still fairly cheap
      
      --
      Changes for v2:
       - Rebased against changes made to patch #3
       - Removed extra indent
       - Tweaked commit message
      9e6c572f
  18. 29 Nov, 2011 2 commits
  19. 05 Oct, 2011 1 commit
    • Graeme Russ's avatar
      console: Implement pre-console buffer · 9558b48a
      Graeme Russ authored
      Allow redirection of console output prior to console initialisation to a
      temporary buffer.
      
      To enable this functionality, the board (or arch) must define:
       - CONFIG_PRE_CONSOLE_BUFFER - Enable pre-console buffer
       - CONFIG_PRE_CON_BUF_ADDR - Base address of pre-console buffer
       - CONFIG_PRE_CON_BUF_SZ - Size of pre-console buffer (in bytes)
      
      The pre-console buffer will buffer the last CONFIG_PRE_CON_BUF_SZ bytes
      Any earlier characters are silently dropped.
      9558b48a
  20. 13 Apr, 2011 1 commit
  21. 12 Feb, 2011 3 commits
  22. 26 Oct, 2010 1 commit
    • Wolfgang Denk's avatar
      Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value · 25ddd1fb
      Wolfgang Denk authored
      
      
      CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not
      being able to use "sizeof(struct global_data)" in assembler files.
      Recent experience has shown that manual synchronization is not
      reliable enough.  This patch renames CONFIG_SYS_GBL_DATA_SIZE into
      GENERATED_GBL_DATA_SIZE which gets automatically generated by the
      asm-offsets tool.  In the result, all definitions of this value can be
      deleted from the board config files.  We have to make sure that all
      files that reference such data include the new <asm-offsets.h> file.
      
      No other changes have been done yet, but it is obvious that similar
      changes / simplifications can be done for other, related macro
      definitions as well.
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Acked-by: default avatarKumar Gala <galak@kernel.crashing.org>
      25ddd1fb