| #
aff2523f |
| 01-Jan-2015 |
Simon Glass <sjg@chromium.org> |
x86: Add support for MTRRs
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,
x86: Add support for MTRRs
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: Simon Glass <sjg@chromium.org>
show more ...
|
| #
8f9052fd |
| 30-Dec-2014 |
Bin Meng <bmeng.cn@gmail.com> |
pci: Make pci apis usable before relocation
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 assi
pci: Make pci apis usable before relocation
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: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| #
b9206e61 |
| 15-Dec-2014 |
Tom Rini <trini@ti.com> |
Merge git://git.denx.de/u-boot-x86
|
| #
bceb9f0f |
| 12-Dec-2014 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Support Intel FSP initialization path in start.S
Per Intel FSP architecture specification, FSP provides 3 routines for bootloader to call. The first one is the TempRamInit (aka Cache-As-Ram ini
x86: Support Intel FSP initialization path in start.S
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: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| #
746667f1 |
| 24-Nov-2014 |
Tom Rini <trini@ti.com> |
Merge git://git.denx.de/u-boot-x86
Conflicts: arch/x86/cpu/Makefile
Signed-off-by: Tom Rini <trini@ti.com>
|
| #
65dd74a6 |
| 13-Nov-2014 |
Simon Glass <sjg@chromium.org> |
x86: ivybridge: Implement SDRAM init
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
x86: ivybridge: Implement SDRAM init
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: Simon Glass <sjg@chromium.org>
show more ...
|
| #
1b4f25ff |
| 13-Nov-2014 |
Simon Glass <sjg@chromium.org> |
x86: ivybridge: Add support for early GPIO init
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
x86: ivybridge: Add support for early GPIO init
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: Simon Glass <sjg@chromium.org>
show more ...
|
| #
8e0df066 |
| 13-Nov-2014 |
Simon Glass <sjg@chromium.org> |
x86: ivybridge: Add early init for PCH devices
Many PCH devices are hard-coded to a particular PCI address. Set these up early in case they are needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| #
7430f108 |
| 13-Nov-2014 |
Simon Glass <sjg@chromium.org> |
x86: Support use of PCI before relocation
Add support for using PCI before SDRAM is available, using early malloc() and global_data.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin M
x86: Support use of PCI before relocation
Add support for using PCI before SDRAM is available, using early malloc() and global_data.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
show more ...
|
| #
258b1357 |
| 09-Nov-2014 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Save TSC frequency in the global data
Return the saved TSC frequency in get_tbclk_mhz().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon
x86: Save TSC frequency in the global data
Return the saved TSC frequency in get_tbclk_mhz().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
show more ...
|
| #
52f952bf |
| 09-Nov-2014 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Do CPU identification in the early phase
The CPU identification happens in x86_cpu_init_f() and corresponding fields are saved in the global data for later use.
Signed-off-by: Bin Meng <bmeng.
x86: Do CPU identification in the early phase
The CPU identification happens in x86_cpu_init_f() and corresponding fields are saved in the global data for later use.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
show more ...
|
| #
f67cd51e |
| 06-Nov-2014 |
Simon Glass <sjg@chromium.org> |
x86: Save the BIST value on reset
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
x86: Save the BIST value on reset
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: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
show more ...
|
| #
326ea986 |
| 31-Jul-2013 |
Stefano Babic <sbabic@denx.de> |
Merge git://git.denx.de/u-boot-arm
Conflicts: board/freescale/mx6qsabrelite/Makefile board/freescale/mx6qsabrelite/mx6qsabrelite.c include/configs/mx6qsabrelite.h
Signed-off-by: Stefano Babic <s
Merge git://git.denx.de/u-boot-arm
Conflicts: board/freescale/mx6qsabrelite/Makefile board/freescale/mx6qsabrelite/mx6qsabrelite.c include/configs/mx6qsabrelite.h
Signed-off-by: Stefano Babic <sbabic@denx.de>
show more ...
|
| #
8b485ba1 |
| 25-Jul-2013 |
Albert ARIBAUD <albert.u.boot@aribaud.net> |
Merge branch 'u-boot/master' into u-boot-arm/master
|
| #
1a459660 |
| 08-Jul-2013 |
Wolfgang Denk <wd@denx.de> |
Add GPL-2.0+ SPDX-License-Identifier to source files
Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
|
| #
d8819f94 |
| 11-Jun-2013 |
Simon Glass <sjg@chromium.org> |
x86: Support tracing function
Some changes are needed to x86 timer functions to support tracing. Add these so that the feature works correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| #
76b40ab4 |
| 11-Mar-2013 |
Tom Rini <trini@ti.com> |
Merge u-boot/master into u-boot-ti/master
In master we had already taken a patch to fix the davinci GPIO code for CONFIG_SOC_DM646X and in u-boot-ti we have additional patches to support DA830 (whic
Merge u-boot/master into u-boot-ti/master
In master we had already taken a patch to fix the davinci GPIO code for CONFIG_SOC_DM646X and in u-boot-ti we have additional patches to support DA830 (which is CONFIG_SOC_DA8XX && !CONFIG_SOC_DA850). Resolve these conflicts manually and comment the #else/#endif lines for clarity.
Conflicts: arch/arm/include/asm/arch-davinci/gpio.h drivers/gpio/da8xx_gpio.c
Signed-off-by: Tom Rini <trini@ti.com>
show more ...
|
| #
f697d528 |
| 28-Feb-2013 |
Simon Glass <sjg@chromium.org> |
x86: Support relocation of FDT on start-up
With CONFIG_OF_CONTROL we may have an FDT in the BSS region. Relocate it up with the rest of U-Boot to keep the rest of memory free.
Signed-off-by: Simon
x86: Support relocation of FDT on start-up
With CONFIG_OF_CONTROL we may have an FDT in the BSS region. Relocate it up with the rest of U-Boot to keep the rest of memory free.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| #
bc2df1af |
| 28-Feb-2013 |
Simon Glass <sjg@chromium.org> |
x86: Permit bootstage and timer data to be used prior to relocation
It is useful to be able to access the timer before U-Boot has relocated so that we can fully support bootstage.
Add new global_da
x86: Permit bootstage and timer data to be used prior to relocation
It is useful to be able to access the timer before U-Boot has relocated so that we can fully support bootstage.
Add new global_data members to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| #
9cd9b34d |
| 23-Feb-2013 |
Stefano Babic <sbabic@denx.de> |
Merge branch 'master' of git://git.denx.de/u-boot-arm
|
| #
9a32084e |
| 04-Feb-2013 |
Kim Phillips <kim.phillips@freescale.com> |
Merge branch 'master' of git://git.denx.de/u-boot
|
| #
43cff66e |
| 13-Dec-2012 |
Simon Glass <sjg@chromium.org> |
x86: Use generic global_data
Move x86 over to use generic global_data.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| #
6cb49c13 |
| 13-Dec-2012 |
Simon Glass <sjg@chromium.org> |
x86: Remove reset_status, relocoff from global_data
These fields are not used on x86, so punt them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| #
5a35e6c4 |
| 13-Dec-2012 |
Simon Glass <sjg@chromium.org> |
x86: Move gd_addr into arch_global_data
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Add arch/x86/cpu/cpu.c changes after Graeme's commen
x86: Move gd_addr into arch_global_data
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Add arch/x86/cpu/cpu.c changes after Graeme's comments] Signed-off-by: Tom Rini <trini@ti.com>
show more ...
|
| #
df4aa625 |
| 13-Dec-2012 |
Simon Glass <sjg@chromium.org> |
x86: Remove gdt_addr from arch_global_data
Remove this unused field.
Signed-off-by: Simon Glass <sjg@chromium.org>
|