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> But can you use a #define for the 0x1000 address? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
