On Mon, Apr 24, 2017 at 11:38 AM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 21 April 2017 at 08:24, Bin Meng <bmeng...@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...@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 <s...@chromium.org> >
applied to u-boot-x86/next, thanks! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
