Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-17 08:43:07 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/x86/include/asm/global_data.h

166 lines
4.2 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
/* SPDX-License-Identifier: GPL-2.0+ */
* Patch by Daniel Engström, 13 Nov 2002: Add support for i386 architecture and AMD SC520 board * Patch by Pierre Aubert, 12 Nov 2002: Add support for DOS filesystem and booting from DOS floppy disk
2002-11-18 00:14:45 +00:00
/*
Make getenv() work before relocation. So far, getenv() would work before relocation is most cases, even though it was not intended to be used that way. When switching to a hash table based implementation, this would break a number of boards. For convenience, we make getenv() check if it's running before relocation and, if so, use getenv_f() internally. Note that this is limited to simple cases, as we use a small static buffer (32 bytes) in the global data for this purpose. For this reason, it is also not a good idea to convert all current uses of getenv_f() into getenv() - some of the existing use cases need to be able to deal with longer variable values, so getenv_f() is still needed and recommended for use before relocation. Signed-off-by: Wolfgang Denk <wd@denx.de>
2010-07-24 18:22:02 +00:00
* (C) Copyright 2002-2010
* Patch by Daniel Engström, 13 Nov 2002: Add support for i386 architecture and AMD SC520 board * Patch by Pierre Aubert, 12 Nov 2002: Add support for DOS filesystem and booting from DOS floppy disk
2002-11-18 00:14:45 +00:00
* Wolfgang Denk, DENX Software Engineering, wd@denx.de.
*/
#ifndef __ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
Add architecture-specific global data 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>
2012-12-13 20:48:30 +00:00
#ifndef __ASSEMBLY__
x86: Move the GDT into global_data Rather than keeping track of the Global Descriptor Table in its own memory we may as well put it in global_data with everything else. As a first step, stop using the separately allocated GDT. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-11 02:44:31 +00:00
#include <asm/processor.h>
x86: Add a new global_data member for the cache record At present we reuse the mrc_output char * to also point to the cache record after it has been set up. This is confusing and doesn't save much data space. Add a new mrc_cache member instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:05 +00:00
#include <asm/mrccache.h>
x86: Move the GDT into global_data Rather than keeping track of the Global Descriptor Table in its own memory we may as well put it in global_data with everything else. As a first step, stop using the separately allocated GDT. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-11 02:44:31 +00:00
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>
2014-11-13 05:42:23 +00:00
enum pei_boot_mode_t {
PEI_BOOT_NONE = 0,
PEI_BOOT_SOFT_RESET,
PEI_BOOT_RESUME,
};
x86: broadwell: Add support for SDRAM setup Broadwell uses a binary blob called the memory reference code (MRC) to start up its SDRAM. This is similar to ivybridge so we can mostly use common code for running this blob. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:26 +00:00
struct dimm_info {
uint32_t dimm_size;
uint16_t ddr_type;
uint16_t ddr_frequency;
uint8_t rank_per_dimm;
uint8_t channel_num;
uint8_t dimm_num;
uint8_t bank_locator;
/* The 5th byte is '\0' for the end of string */
uint8_t serial[5];
/* The 19th byte is '\0' for the end of string */
uint8_t module_part_number[19];
uint16_t mod_id;
uint8_t mod_type;
uint8_t bus_width;
} __packed;
struct pei_memory_info {
uint8_t dimm_cnt;
/* Maximum num of dimm is 8 */
struct dimm_info dimm[8];
} __packed;
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>
2014-11-13 05:42:28 +00:00
struct memory_area {
uint64_t start;
uint64_t size;
};
struct memory_info {
int num_areas;
uint64_t total_memory;
uint64_t total_32bit_memory;
struct memory_area area[CONFIG_NR_DRAM_BANKS];
};
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>
2015-01-01 23:18:07 +00:00
#define MAX_MTRR_REQUESTS 8
/**
* A request for a memory region to be set up in a particular way. These
* requests are processed before board_init_r() is called. They are generally
* optional and can be ignored with some performance impact.
*/
struct mtrr_request {
int type; /* MTRR_TYPE_... */
uint64_t start;
uint64_t size;
};
x86: Update mrccache to support multiple caches With Apollo Lake we need to support a normal cache, which almost never changes and a much smaller 'variable' cache which changes every time. Update the code to add a cache type, use an array for the caches and use a for loop to iterate over the caches. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:07 +00:00
/**
* struct mrc_output - holds the MRC data
*
* @buf: MRC training data to save for the next boot. This is set to point to
* the raw data after SDRAM init is complete. Then mrccache_setup()
* turns it into a proper cache record with a checksum
* @len: Length of @buf
* @cache: Resulting cache record
*/
struct mrc_output {
char *buf;
uint len;
struct mrc_data_container *cache;
};
Add architecture-specific global data 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>
2012-12-13 20:48:30 +00:00
/* Architecture-specific global data */
struct arch_global_data {
x86: Move the GDT into global_data Rather than keeping track of the Global Descriptor Table in its own memory we may as well put it in global_data with everything else. As a first step, stop using the separately allocated GDT. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-11 02:44:31 +00:00
u64 gdt[X86_GDT_NUM_ENTRIES] __aligned(16);
x86: Save mtrr support flag in global data 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>
2015-01-22 03:29:40 +00:00
struct global_data *gd_addr; /* Location of Global Data */
uint8_t x86; /* CPU family */
uint8_t x86_vendor; /* CPU vendor */
uint8_t x86_model;
uint8_t x86_mask;
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>
2014-11-09 14:18:56 +00:00
uint32_t x86_device;
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>
2013-02-28 19:26:12 +00:00
uint64_t tsc_base; /* Initial value returned by rdtsc() */
x86: timer: Use a separate flag for whether timer is inited At present the value of the timer base is used to determine whether the timer has been set up or not. It is true that the timer is essentially never exactly 0 when it is read. However 'time 0' may indicate the time that the machine was reset so it is useful to be able to denote that. Update the code to use a separate flag instead. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Aiden Park <aiden.park@intel.com> Reviewed-by: Aiden Park <aiden.park@intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-21 03:37:47 +00:00
bool tsc_inited; /* true if tsc is ready for use */
dm: x86: Allow TSC timer to be used before DM is ready With bootstage we need access to the timer before driver model is set up. To handle this, put the required state in global_data and provide a new function to set up the device, separate from the driver's probe() method. This will be used by the 'early' timer also. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-09-06 01:49:46 +00:00
unsigned long clock_rate; /* Clock rate of timer in Hz */
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>
2013-02-28 19:26:15 +00:00
void *new_fdt; /* Relocated FDT */
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>
2014-11-06 20:20:10 +00:00
uint32_t bist; /* Built-in self test value */
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>
2014-11-13 05:42:23 +00:00
enum pei_boot_mode_t pei_boot_mode;
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>
2014-11-13 05:42:24 +00:00
const struct pch_gpio_map *gpio_map; /* board GPIO map */
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>
2014-11-13 05:42:28 +00:00
struct memory_info meminfo; /* Memory information */
x86: broadwell: Add support for SDRAM setup Broadwell uses a binary blob called the memory reference code (MRC) to start up its SDRAM. This is similar to ivybridge so we can mostly use common code for running this blob. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:26 +00:00
struct pei_memory_info pei_meminfo; /* PEI memory information */
x86: Add new slimbootloader CPU type This slimbootloader CPU type is to enable U-Boot as a payload which runs on top of Slim Bootloader (https://github.com/slimbootloader). The Slim Bootloader is designed with multi-stage architecture for the execution from reset vector to OS booting, and supports QEMU, Apollolake, Whiskeylake and Coffeelake platforms consuming Intel FSP (https://github.com/IntelFsp) for silicon initialization including CAR and memory initialization. The Slim Bootloader generates new HOB (Hand Off Block) which are serial port info, memory map info, performance data info and so on, and passes it to a Payload. U-Boot as a payload will use these HOB information for basic initialization such as serial console. As an initial commit, - Add CONFIG_SYS_SLIMBOOTLOADER to enable slimbootloader CPU type - Add new arch/x86/cpu/slimbootloader directory with minimum codes - Get hob_list pointer from Slim Bootloader Signed-off-by: Aiden Park <aiden.park@intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-08-03 08:30:12 +00:00
#ifdef CONFIG_USE_HOB
x86: Save mtrr support flag in global data 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>
2015-01-22 03:29:40 +00:00
void *hob_list; /* FSP HOB list */
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>
2014-12-12 13:05:31 +00:00
#endif
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>
2015-01-01 23:18:07 +00:00
struct mtrr_request mtrr_req[MAX_MTRR_REQUESTS];
int mtrr_req_count;
x86: Save mtrr support flag in global data 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>
2015-01-22 03:29:40 +00:00
int has_mtrr;
x86: Update mrccache to support multiple caches With Apollo Lake we need to support a normal cache, which almost never changes and a much smaller 'variable' cache which changes every time. Update the code to add a cache type, use an array for the caches and use a for loop to iterate over the caches. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:07 +00:00
/* MRC training data */
struct mrc_output mrc[MRC_TYPE_COUNT];
x86: Add support for passing tables into U-Boot The EFI stub provides information to U-Boot in a table. This includes the memory map which is needed to decide where to relocate U-Boot. Collect this information in the early init code and store it in global_data. Fix up the BIST code at the same time since we don't have it when booting from EFI and can assume it is 0. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-04 18:33:57 +00:00
ulong table; /* Table pointer from previous loader */
x86: Move turbo_state to global_data To avoid using BSS in SPL before SDRAM is set up, move this field to global_data. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:04:17 +00:00
int turbo_state; /* Current turbo state */
x86: Move pirq_routing_table to global_data To avoid using BSS in SPL before SDRAM is set up, move this field to global_data. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:04:16 +00:00
struct irq_routing_table *pirq_routing_table;
i2c: designware: Avoid using static data Drivers are not allowed to use static data since they may be used in SPL where BSS is not available. It is possible that driver model may provide support for numbering devices in the future. But for now, move this to global_data. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:41:41 +00:00
int dw_i2c_num_cards; /* Used by designware i2c driver */
x86: Prepare configuration tables in dedicated high memory region Currently when CONFIG_SEABIOS is on, U-Boot allocates configuration tables via normal malloc(). To simplify, use a dedicated memory region which is reserved on the stack before relocation for this purpose. Add functions for reserve and malloc. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-05-11 14:44:59 +00:00
#ifdef CONFIG_SEABIOS
u32 high_table_ptr;
u32 high_table_limit;
#endif
x86: baytrail: Conditionally report S3 in the ACPI table When U-Boot is built without ACPI S3 support, it should not report S3 in the ACPI table otherwise when kernel does STR it won't work. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
2017-04-21 14:24:33 +00:00
int prev_sleep_state; /* Previous sleep state ACPI_S0/1../5 */
x86: acpi: Fix Windows S3 resume failure U-Boot sets up the real mode interrupt handler stubs starting from address 0x1000. In most cases, the first 640K (0x00000 - 0x9ffff) system memory is reported as system RAM in E820 table to the OS. (see install_e820_map() implementation for each platform). So OS can use these memories whatever it wants. If U-Boot is in an S3 resume path, care must be taken not to corrupt these memorie otherwise OS data gets lost. Testing shows that, on Microsoft Windows 10 on Intel Baytrail its wake up vector happens to be installed at the same address 0x1000. While on Linux its wake up vector does not overlap this memory range, but after resume kernel checks low memory range per config option CONFIG_X86_RESERVE_LOW which is 64K by default to see whether a memory corruption occurs during the suspend/resume (it's harmless, but warnings are shown in the kernel dmesg logs). We cannot simply mark the these memory as reserved in E820 table because such configuration makes GRUB complain: unable to allocate real mode page. Hence we choose to back up these memories to the place where we reserved on our stack for our S3 resume work. Before jumping to OS wake up vector, we need restore the original content there. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
2017-04-21 14:24:47 +00:00
ulong backup_mem; /* Backup memory address for S3 */
x86: fsp: Allow remembering the location of FSP-S FSP-S is used by the notify call after it has been used for silicon init. To avoid having to load it again, add a field to store the location. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:21 +00:00
#ifdef CONFIG_FSP_VERSION2
struct fsp_header *fsp_s_hdr; /* Pointer to FSP-S header */
#endif
x86: apl: Fix save/restore of ITSS priorities The FSP-S changes the ITSS priorities. The code that tries to save it before running FSP-S and restore it afterwards does not work as U-Boot relocates in between the save and restore. This means that the driver data saved before relocation is lost and the new driver just sees zeroes. Fix this by allocating space in the relocated memory for the ITSS data. Save it there and access it from the driver after relocation. This fixes interrupt handling on coral. Also drop the log_msg_ret() in irq_first_device_type() since this function can be called speculatively in places where we are not sure if there is an interrupt controller of that type. The resulting log errors are confusing when there is no error. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
2020-07-17 03:22:30 +00:00
void *itss_priv; /* Private ITSS data pointer */
x86: Store the coreboot table address in global_data At present this information is used to locate and parse the tables but is not stored. Store it so that we can display it to the user, e.g. with the 'bdinfo' command. Note that now the GD_FLG_SKIP_LL_INIT flag is set in get_coreboot_info(), so it is always set when booting from coreboot. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
2020-07-17 03:22:34 +00:00
ulong coreboot_table; /* Address of coreboot table */
x86: Record the start and end of the tables The ACPI tables are special in that they are passed to EFI as a separate piece, independent of other tables. Also they can be spread over two areas of memory, e.g. with QEMU we end up with tables kept in high memory as well. Add new global_data fields to hold this information and update the bdinfo command to show the table areas. Move the rom_table_end variable into the loop that uses it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2023-07-16 03:39:10 +00:00
ulong table_start; /* Start address of x86 tables */
ulong table_end; /* End address of x86 tables */
ulong table_start_high; /* Start address of high x86 tables */
ulong table_end_high; /* End address of high x86 tables */
Record the position of the SMBIOS tables Remember where these end up so that we can pass this information on to the EFI layer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2023-09-20 03:00:15 +00:00
ulong smbios_start; /* Start address of SMBIOS table */
Add architecture-specific global data 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>
2012-12-13 20:48:30 +00:00
};
console: Implement pre-console buffer 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.
2011-09-01 00:48:27 +00:00
#endif
* Patch by Daniel Engström, 13 Nov 2002: Add support for i386 architecture and AMD SC520 board * Patch by Pierre Aubert, 12 Nov 2002: Add support for DOS filesystem and booting from DOS floppy disk
2002-11-18 00:14:45 +00:00
x86: Use generic global_data Move x86 over to use generic global_data. Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:49:27 +00:00
#include <asm-generic/global_data.h>
#ifndef __ASSEMBLY__
x86: Support global_data on x86_64 At present this is just an ordinary variable. We may consider making it a fixed register in the future. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:03:59 +00:00
# if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
x86: Allow use of global_data with EFI 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: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-07-31 15:31:35 +00:00
x86: Support global_data on x86_64 At present this is just an ordinary variable. We may consider making it a fixed register in the future. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:03:59 +00:00
/* TODO(sjg@chromium.org): Consider using a fixed register for gd on x86_64 */
x86: Allow use of global_data with EFI 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: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-07-31 15:31:35 +00:00
#define gd global_data_ptr
#define DECLARE_GLOBAL_DATA_PTR extern struct global_data *global_data_ptr
# else
trace: Use notrace for short The attribute syntax is quite verbose. Use the macro provided for this purpose. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-12-21 23:08:15 +00:00
static inline notrace gd_t *get_fs_gd_ptr(void)
x86: Use fs for global data 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
2011-12-31 11:58:15 +00:00
{
gd_t *gd_ptr;
x86: Support global_data on x86_64 At present this is just an ordinary variable. We may consider making it a fixed register in the future. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:03:59 +00:00
#if CONFIG_IS_ENABLED(X86_64)
asm volatile("fs mov 0, %0\n" : "=r" (gd_ptr));
#else
x86: Use fs for global data 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
2011-12-31 11:58:15 +00:00
asm volatile("fs movl 0, %0\n" : "=r" (gd_ptr));
x86: Support global_data on x86_64 At present this is just an ordinary variable. We may consider making it a fixed register in the future. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:03:59 +00:00
#endif
x86: Use fs for global data 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
2011-12-31 11:58:15 +00:00
return gd_ptr;
}
#define gd get_fs_gd_ptr()
x86: Place global data below stack before entering C By reserving space for the Global Data immediately below the stack during assembly level initialisation, the C declaration of the static global data can be removed, along with the 'RAM Bootstrap' function. This results in cleaner code, and the ability to pass boot-up flags from assembler into C
2010-10-07 09:03:29 +00:00
x86: Tidy up global_data flags 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: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-07-31 15:31:28 +00:00
#define DECLARE_GLOBAL_DATA_PTR
x86: Allow use of global_data with EFI 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: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-07-31 15:31:35 +00:00
# endif
x86: Tidy up global_data flags 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: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-07-31 15:31:28 +00:00
x86: Place global data below stack before entering C By reserving space for the Global Data immediately below the stack during assembly level initialisation, the C declaration of the static global data can be removed, along with the 'RAM Bootstrap' function. This results in cleaner code, and the ability to pass boot-up flags from assembler into C
2010-10-07 09:03:29 +00:00
#endif
* Patch by Daniel Engström, 13 Nov 2002: Add support for i386 architecture and AMD SC520 board * Patch by Pierre Aubert, 12 Nov 2002: Add support for DOS filesystem and booting from DOS floppy disk
2002-11-18 00:14:45 +00:00
#endif /* __ASM_GBL_DATA_H */
Reference in a new issue Copy permalink