u-boot.git/arch/x86/include/asm/global_data.h, branch v2018.09

SPDX: Convert all of our single license tags to Linux Kernel style

2018-05-07T13:34:12Z

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

dm: x86: Allow TSC timer to be used before DM is ready

2017-09-16T06:57:44Z

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 Reviewed-by: Bin Meng

x86: acpi: Fix Windows S3 resume failure

2017-05-17T09:11:46Z

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 Reviewed-by: Simon Glass Tested-by: Stefan Roese

x86: baytrail: Conditionally report S3 in the ACPI table

2017-05-17T09:11:46Z

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 Reviewed-by: Simon Glass Tested-by: Stefan Roese

x86: Store and display previous sleep state

2017-05-17T09:11:46Z

Add one member in the global data to store previous sleep state, and display the state during boot in print_cpuinfo(). Signed-off-by: Bin Meng Reviewed-by: Simon Glass Tested-by: Stefan Roese

x86: Move turbo_state to global_data

2017-02-07T05:07:26Z

To avoid using BSS in SPL before SDRAM is set up, move this field to global_data. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: Move pirq_routing_table to global_data

2017-02-07T05:07:23Z

To avoid using BSS in SPL before SDRAM is set up, move this field to global_data. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: Support global_data on x86_64

2017-02-06T03:38:46Z

At present this is just an ordinary variable. We may consider making it a fixed register in the future. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: Prepare configuration tables in dedicated high memory region

2016-05-23T07:18:00Z

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 Reviewed-by: Simon Glass

x86: broadwell: Add support for SDRAM setup

2016-03-17T02:27:26Z

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 Acked-by: Bin Meng