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

Bin Meng bmeng.cn at gmail.com
Tue Apr 25 01:51:02 UTC 2017


Hi Simon,

On Mon, Apr 24, 2017 at 11:38 AM, Simon Glass <sjg at chromium.org> wrote:
> 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?
>

Will prepare another patch to change this globally.

Regards,
Bin


More information about the U-Boot mailing list