diff options
author | Bin Meng <bmeng.cn@gmail.com> | 2016-05-11 07:45:03 -0700 |
---|---|---|
committer | Bin Meng <bmeng.cn@gmail.com> | 2016-05-23 15:18:00 +0800 |
commit | 6aef68dc36bc93e1c32c1f7119b580f5eda92182 (patch) | |
tree | 2c4b95f5b29c5751eb465986ce9655fb9f6c19a7 /arch/avr32 | |
parent | 644a76742c85ae8bbdd9fcd00d06b7099015d593 (diff) | |
download | u-boot-imx-6aef68dc36bc93e1c32c1f7119b580f5eda92182.zip u-boot-imx-6aef68dc36bc93e1c32c1f7119b580f5eda92182.tar.gz u-boot-imx-6aef68dc36bc93e1c32c1f7119b580f5eda92182.tar.bz2 |
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>
Diffstat (limited to 'arch/avr32')
0 files changed, 0 insertions, 0 deletions