[U-Boot] [PATCH v2 20/22] x86: acpi: Fix Windows S3 resume failure

[Simon Glass]

Hi Bin,

On 21 April 2017 at 08:24, Bin Meng <bmeng.cn at gmail.com> wrote:
> 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 at gmail.com>
>
> ---
>
> Changes in v2:
> - new patch "Fix Windows S3 resume failure"
>
>  arch/x86/cpu/cpu.c                 |  8 +++++--
>  arch/x86/include/asm/acpi_s3.h     | 16 +++++++++++++
>  arch/x86/include/asm/global_data.h |  1 +
>  arch/x86/lib/acpi_s3.c             | 48 ++++++++++++++++++++++++++++++++++++++
>  4 files changed, 71 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass <sjg at chromium.org>

But can you use a #define for the 0x1000 address?

Regards,
Simon