x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM
authorBin Meng <bmeng.cn@gmail.com>
Wed, 11 May 2016 14:45:03 +0000 (07:45 -0700)
committerBin Meng <bmeng.cn@gmail.com>
Mon, 23 May 2016 07:18:00 +0000 (15:18 +0800)
commit6aef68dc36bc93e1c32c1f7119b580f5eda92182
tree2c4b95f5b29c5751eb465986ce9655fb9f6c19a7
parent644a76742c85ae8bbdd9fcd00d06b7099015d593
x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM

Per ACPI spec, during ACPI OS initialization, OSPM can determine
that the ACPI hardware registers are owned by SMI (by way of the
SCI_EN bit in the PM1_CNT register), in which case the ACPI OS
issues the ACPI_ENABLE command to the SMI_CMD port. The SCI_EN bit
effectively tracks the ownership of the ACPI hardware registers.

However since U-Boot does not support SMI, we report all 3 fields
in FADT (SMI_CMD, ACPI_ENABLE, ACPI_DISABLE) as zero, by following
the spec who says: these fields are reserved and must be zero on
system that does not support System Management mode.

U-Boot seems to behave in a correct way that the ACPI spec allows,
at least Linux does not complain, but apparently Windows does not
think so. During Windows bring up debugging, it is observed that
even these 3 fields are zero, Windows are still trying to issue SMI
with hardcoded SMI port address and commands, and expecting SCI_EN
to be changed by the firmware. Eventually Windows gives us a BSOD
(Blue Screen of Death) saying ACPI_BIOS_ERROR and refuses to start.

To fix this, turn on the SCI_EN bit by ourselves. With this patch,
now U-Boot can install and boot Windows 8.1/10 successfully with
the help of SeaBIOS using legacy interface (non-UEFI mode).

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
arch/x86/include/asm/acpi_table.h
arch/x86/lib/acpi_table.c