summaryrefslogtreecommitdiff
path: root/arch/avr32
diff options
context:
space:
mode:
authorBin Meng <bmeng.cn@gmail.com>2016-05-11 07:45:03 -0700
committerBin Meng <bmeng.cn@gmail.com>2016-05-23 15:18:00 +0800
commit6aef68dc36bc93e1c32c1f7119b580f5eda92182 (patch)
tree2c4b95f5b29c5751eb465986ce9655fb9f6c19a7 /arch/avr32
parent644a76742c85ae8bbdd9fcd00d06b7099015d593 (diff)
downloadu-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