summaryrefslogtreecommitdiff
path: root/arch/x86/include/asm/global_data.h
Commit message (Collapse)AuthorAgeLines
* x86: Store the GDT pointer in global_dataSimon Glass2015-04-29-0/+1
| | | | | | | | | When we start up additional CPUs we want them to use the same Global Descriptor Table. Store the address of this in global_data so we can reference it later. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Implement a cache for Memory Reference Code parametersSimon Glass2015-01-24-0/+3
| | | | | | | | | | | The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Save mtrr support flag in global dataBin Meng2015-01-23-6/+7
| | | | | | | | CPUID (EAX 01H) returns MTRR support flag in EDX bit 12. Probe this flag in x86_cpu_init_f() and save it in global data. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add support for MTRRsSimon Glass2015-01-13-0/+15
| | | | | | | | | | | | | | 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>
* pci: Make pci apis usable before relocationBin Meng2015-01-12-1/+0
| | | | | | | | | | | | | | 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>
* x86: Support Intel FSP initialization path in start.SBin Meng2014-12-13-0/+3
| | | | | | | | | | | | | | | | | 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>
* x86: ivybridge: Implement SDRAM initSimon Glass2014-11-21-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* x86: ivybridge: Add support for early GPIO initSimon Glass2014-11-21-0/+1
| | | | | | | | | | | | | | 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>
* x86: ivybridge: Add early init for PCH devicesSimon Glass2014-11-21-0/+8
| | | | | | | 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>
* x86: Support use of PCI before relocationSimon Glass2014-11-21-0/+1
| | | | | | | | 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>
* x86: Save TSC frequency in the global dataBin Meng2014-11-21-0/+1
| | | | | | | | 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>
* x86: Do CPU identification in the early phaseBin Meng2014-11-21-0/+5
| | | | | | | 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>
* x86: Save the BIST value on resetSimon Glass2014-11-21-0/+1
| | | | | | | | | | 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>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-24-17/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* x86: Support tracing functionSimon Glass2013-06-26-1/+1
| | | | | | | 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>
* x86: Support relocation of FDT on start-upSimon Glass2013-03-04-0/+1
| | | | | | | 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>
* x86: Permit bootstage and timer data to be used prior to relocationSimon Glass2013-03-04-0/+3
| | | | | | | | | 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>
* x86: Use generic global_dataSimon Glass2013-02-04-34/+3
| | | | | | Move x86 over to use generic global_data. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Remove reset_status, relocoff from global_dataSimon Glass2013-02-01-2/+0
| | | | | | These fields are not used on x86, so punt them. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Move gd_addr into arch_global_dataSimon Glass2013-02-01-2/+1
| | | | | | | | 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>
* x86: Remove gdt_addr from arch_global_dataSimon Glass2013-02-01-1/+0
| | | | | | Remove this unused field. Signed-off-by: Simon Glass <sjg@chromium.org>
* Add architecture-specific global dataSimon Glass2013-02-01-2/+8
| | | | | | | | | | | | | We plan to move architecture-specific data into a separate structure so that we can make the rest of it common. As a first step, create struct arch_global_data to hold these fields. Initially it is empty. This patch applies to all archs at once. I can split it if this is really a pain. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Add back cold- and warm-boot flagsGabe Black2012-12-06-0/+6
| | | | | | | | | | | | | 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: Simon Glass <sjg@chromium.org>
* x86: Add an fdt pointer to the global data structureGabe Black2012-11-30-0/+1
| | | | | | | | This change adds a pointer to the global data structure in x86 to point to the device tree. This mirrors an identical pointer in ARM. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Add some missing includesGabe Black2012-11-28-0/+2
| | | | | | | | | I suspect these includes were usually available because something else included them earlier or because they were brought in transitively. Change-Id: I6aae2ac94dc792eac6febb4345e8125f69f70988 Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Put global data on the stackGraeme Russ2012-11-28-1/+0
| | | | | | | | | | Putting global data on the stack simplifies the init process (and makes it slightly quicker). During the 'flash' stage of the init sequence, global data is in the CAR stack. After SDRAM is initialised, global data is copied from CAR to the SDRAM stack Signed-off-by: Graeme Russ <graeme.russ@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Forward declare gd_tGraeme Russ2012-11-28-3/+5
| | | | | | | | So it can be used as a type in struct global_data and remove an ugly typecast Signed-off-by: Graeme Russ <graeme.russ@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de>
* x86: Change global data baudrate to intSimon Glass2012-10-19-1/+1
| | | | | | | This doesn't need to be a long, so change it. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@ti.com>
* global_data: unify global flag definesMike Frysinger2012-08-09-13/+1
| | | | | | | All the global flag defines are the same across all arches. So unify them in one place, and add a simple way for arches to extend for their needs. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* x86: Use fs for global dataGraeme Russ2012-01-04-7/+14
| | | | | | | | | | | | | | | | | | | | | | 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
* sc520: Create arch asm-offsetsGraeme Russ2011-11-29-19/+0
| | | | Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
* x86: Punt cold- and warm-boot flagsGraeme Russ2011-11-29-2/+0
| | | | | | | Nobody uses them anyway Signed-off-by: Graeme Russ <graeme.russ@gmail.com> Acked-by: Mike Frysinger <vapier@gentoo.org>
* console: Implement pre-console bufferGraeme Russ2011-10-05-0/+3
| | | | | | | | | | | | | 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.
* x86: Rename i386 to x86Graeme Russ2011-04-13-0/+102
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
generated by cgit v1.1 at 2024-11-14 16:33:23 +0000