]> git.sur5r.net Git - u-boot/commit
x86: acpi: Fix Windows S3 resume failure
authorBin Meng <bmeng.cn@gmail.com>
Fri, 21 Apr 2017 14:24:47 +0000 (07:24 -0700)
committerBin Meng <bmeng.cn@gmail.com>
Wed, 17 May 2017 09:11:46 +0000 (17:11 +0800)
commit5ae5aa931042bb4163c6343a3cba65e95d90205a
tree0eb3a11a1fbbf38ff707c22debf54d912094b185
parent68769ebcbc892c85e9a1ffff09bbc6e4877f2d1f
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>
arch/x86/cpu/cpu.c
arch/x86/include/asm/acpi_s3.h
arch/x86/include/asm/global_data.h
arch/x86/lib/acpi_s3.c