[U-Boot] [PATCH v2 09/18] x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM

[Bin Meng]

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 at gmail.com>
---

Changes in v2: None

 arch/x86/include/asm/acpi_table.h |  3 +++
 arch/x86/lib/acpi_table.c         | 26 ++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/arch/x86/include/asm/acpi_table.h b/arch/x86/include/asm/acpi_table.h
index ff4802a..56aa282 100644
--- a/arch/x86/include/asm/acpi_table.h
+++ b/arch/x86/include/asm/acpi_table.h
@@ -296,6 +296,9 @@ struct acpi_mcfg_mmconfig {
 	u8 reserved[4];
 };
 
+/* PM1_CNT bit defines */
+#define PM1_CNT_SCI_EN		(1 << 0)
+
 /* These can be used by the target port */
 
 void acpi_fill_header(struct acpi_table_header *header, char *signature);
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 989cf7d..a9fe243 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -12,6 +12,7 @@
 #include <dm.h>
 #include <dm/uclass-internal.h>
 #include <asm/acpi_table.h>
+#include <asm/io.h>
 #include <asm/lapic.h>
 #include <asm/tables.h>
 
@@ -301,6 +302,25 @@ static void acpi_create_mcfg(struct acpi_mcfg *mcfg)
 	header->checksum = table_compute_checksum((void *)mcfg, header->length);
 }
 
+static void enter_acpi_mode(int pm1_cnt)
+{
+	/*
+	 * PM1_CNT register bit0 selects the power management event to be
+	 * either an SCI or SMI interrupt. When this bit is set, then power
+	 * management events will generate an SCI interrupt. When this bit
+	 * is reset power management events will generate an SMI interrupt.
+	 *
+	 * Per ACPI spec, it is the responsibility of the hardware to set
+	 * or reset this bit. OSPM always preserves this bit position.
+	 *
+	 * U-Boot does not support SMI. And we don't have plan to support
+	 * anything running in SMM within U-Boot. To create a legacy-free
+	 * system, and expose ourselves to OSPM as working under ACPI mode
+	 * already, turn this bit on.
+	 */
+	outw(PM1_CNT_SCI_EN, pm1_cnt);
+}
+
 /*
  * QEMU's version of write_acpi_tables is defined in
  * arch/x86/cpu/qemu/fw_cfg.c
@@ -400,5 +420,11 @@ u32 write_acpi_tables(u32 start)
 
 	debug("ACPI: done\n");
 
+	/*
+	 * Other than waiting for OSPM to request us to switch to ACPI mode,
+	 * do it by ourselves, since SMI will not be triggered.
+	 */
+	enter_acpi_mode(fadt->pm1a_cnt_blk);
+
 	return current;
 }
-- 
1.8.2.1