* [U-Boot] [PATCH v2 01/22] x86: acpi: Add Kconfig option and header file for ACPI resume
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:33 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 02/22] x86: baytrail: acpi: Add APIs for determining/clearing sleep state Bin Meng
` (21 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
This introduces a Kconfig option for ACPI S3 resume, as well as a
header file to include anything related to ACPI S3 resume.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- fixed several nits in CONFIG_HAVE_ACPI_RESUME Kconfig help text
- return -EINVAL instead of -1 in acpi_sleep_from_pm1()
- add a function comment block for acpi_sleep_from_pm1()
arch/x86/Kconfig | 12 ++++++++
arch/x86/include/asm/acpi_s3.h | 64 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+)
create mode 100644 arch/x86/include/asm/acpi_s3.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9ead3eb..b568852 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -589,6 +589,18 @@ config GENERATE_ACPI_TABLE
endmenu
+config HAVE_ACPI_RESUME
+ bool "Enable ACPI S3 resume"
+ help
+ Select this to enable ACPI S3 resume. S3 is an ACPI-defined sleeping
+ state where all system context is lost except system memory. U-Boot
+ is responsible for restoring the machine state as it was before sleep.
+ It needs restore the memory controller, without overwriting memory
+ which is not marked as reserved. For the peripherals which lose their
+ registers, U-Boot needs to write the original value. When everything
+ is done, U-Boot needs to find out the wakeup vector provided by OSes
+ and jump there.
+
config MAX_PIRQ_LINKS
int
default 8
diff --git a/arch/x86/include/asm/acpi_s3.h b/arch/x86/include/asm/acpi_s3.h
new file mode 100644
index 0000000..78c53ea
--- /dev/null
+++ b/arch/x86/include/asm/acpi_s3.h
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2017, Bin Meng <bmeng.cn@gmail.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __ASM_ACPI_S3_H__
+#define __ASM_ACPI_S3_H__
+
+/* PM1_STATUS register */
+#define WAK_STS (1 << 15)
+#define PCIEXPWAK_STS (1 << 14)
+#define RTC_STS (1 << 10)
+#define SLPBTN_STS (1 << 9)
+#define PWRBTN_STS (1 << 8)
+#define GBL_STS (1 << 5)
+#define BM_STS (1 << 4)
+#define TMR_STS (1 << 0)
+
+/* PM1_CNT register */
+#define SLP_EN (1 << 13)
+#define SLP_TYP_SHIFT 10
+#define SLP_TYP (7 << SLP_TYP_SHIFT)
+#define SLP_TYP_S0 0
+#define SLP_TYP_S1 1
+#define SLP_TYP_S3 5
+#define SLP_TYP_S4 6
+#define SLP_TYP_S5 7
+
+enum acpi_sleep_state {
+ ACPI_S0,
+ ACPI_S1,
+ ACPI_S2,
+ ACPI_S3,
+ ACPI_S4,
+ ACPI_S5,
+};
+
+/**
+ * acpi_sleep_from_pm1() - get ACPI-defined sleep state from PM1_CNT register
+ *
+ * @pm1_cnt: PM1_CNT register value
+ * @return: ACPI-defined sleep state if given valid PM1_CNT register value,
+ * -EINVAL otherwise.
+ */
+static inline enum acpi_sleep_state acpi_sleep_from_pm1(u32 pm1_cnt)
+{
+ switch ((pm1_cnt & SLP_TYP) >> SLP_TYP_SHIFT) {
+ case SLP_TYP_S0:
+ return ACPI_S0;
+ case SLP_TYP_S1:
+ return ACPI_S1;
+ case SLP_TYP_S3:
+ return ACPI_S3;
+ case SLP_TYP_S4:
+ return ACPI_S4;
+ case SLP_TYP_S5:
+ return ACPI_S5;
+ }
+
+ return -EINVAL;
+}
+
+#endif /* __ASM_ACPI_S3_H__ */
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 01/22] x86: acpi: Add Kconfig option and header file for ACPI resume
2017-04-21 14:24 ` [U-Boot] [PATCH v2 01/22] x86: acpi: Add Kconfig option and header file for ACPI resume Bin Meng
@ 2017-04-26 7:33 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:33 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> This introduces a Kconfig option for ACPI S3 resume, as well as a
> header file to include anything related to ACPI S3 resume.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - fixed several nits in CONFIG_HAVE_ACPI_RESUME Kconfig help text
> - return -EINVAL instead of -1 in acpi_sleep_from_pm1()
> - add a function comment block for acpi_sleep_from_pm1()
>
> arch/x86/Kconfig | 12 ++++++++
> arch/x86/include/asm/acpi_s3.h | 64 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 76 insertions(+)
> create mode 100644 arch/x86/include/asm/acpi_s3.h
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 02/22] x86: baytrail: acpi: Add APIs for determining/clearing sleep state
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 01/22] x86: acpi: Add Kconfig option and header file for ACPI resume Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:33 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 03/22] x86: Add post codes for OS resume Bin Meng
` (20 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
This adds APIs for determining previous sleep state from ACPI I/O
registers, as well as clearing sleep state on BayTrail SoC.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/cpu/baytrail/acpi.c | 47 ++++++++++++++++++++++++++++++
arch/x86/include/asm/arch-baytrail/iomap.h | 24 +++++++++++++++
2 files changed, 71 insertions(+)
diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
index fa92d88..55ed7de 100644
--- a/arch/x86/cpu/baytrail/acpi.c
+++ b/arch/x86/cpu/baytrail/acpi.c
@@ -8,7 +8,9 @@
#include <cpu.h>
#include <dm.h>
#include <dm/uclass-internal.h>
+#include <asm/acpi_s3.h>
#include <asm/acpi_table.h>
+#include <asm/io.h>
#include <asm/ioapic.h>
#include <asm/mpspec.h>
#include <asm/tables.h>
@@ -187,3 +189,48 @@ void acpi_create_gnvs(struct acpi_global_nvs *gnvs)
else
gnvs->iuart_en = 0;
}
+
+#ifdef CONFIG_HAVE_ACPI_RESUME
+/*
+ * The following two routines are called at a very early stage, even before
+ * FSP 2nd phase API fsp_init() is called. Registers off ACPI_BASE_ADDRESS
+ * and PMC_BASE_ADDRESS are accessed, so we need make sure the base addresses
+ * of these two blocks are programmed by either U-Boot or FSP.
+ *
+ * It has been verified that 1st phase API (see arch/x86/lib/fsp/fsp_car.S)
+ * on Intel BayTrail SoC already initializes these two base addresses so
+ * we are safe to access these registers here.
+ */
+
+enum acpi_sleep_state chipset_prev_sleep_state(void)
+{
+ u32 pm1_sts;
+ u32 pm1_cnt;
+ u32 gen_pmcon1;
+ enum acpi_sleep_state prev_sleep_state = ACPI_S0;
+
+ /* Read Power State */
+ pm1_sts = inw(ACPI_BASE_ADDRESS + PM1_STS);
+ pm1_cnt = inl(ACPI_BASE_ADDRESS + PM1_CNT);
+ gen_pmcon1 = readl(PMC_BASE_ADDRESS + GEN_PMCON1);
+
+ debug("PM1_STS = 0x%x PM1_CNT = 0x%x GEN_PMCON1 = 0x%x\n",
+ pm1_sts, pm1_cnt, gen_pmcon1);
+
+ if (pm1_sts & WAK_STS)
+ prev_sleep_state = acpi_sleep_from_pm1(pm1_cnt);
+
+ if (gen_pmcon1 & (PWR_FLR | SUS_PWR_FLR))
+ prev_sleep_state = ACPI_S5;
+
+ return prev_sleep_state;
+}
+
+void chipset_clear_sleep_state(void)
+{
+ u32 pm1_cnt;
+
+ pm1_cnt = inl(ACPI_BASE_ADDRESS + PM1_CNT);
+ outl(pm1_cnt & ~(SLP_TYP), ACPI_BASE_ADDRESS + PM1_CNT);
+}
+#endif
diff --git a/arch/x86/include/asm/arch-baytrail/iomap.h b/arch/x86/include/asm/arch-baytrail/iomap.h
index 62a9105..ec4e9d5 100644
--- a/arch/x86/include/asm/arch-baytrail/iomap.h
+++ b/arch/x86/include/asm/arch-baytrail/iomap.h
@@ -35,6 +35,27 @@
#define PMC_BASE_ADDRESS 0xfed03000
#define PMC_BASE_SIZE 0x400
+#define GEN_PMCON1 0x20
+#define UART_EN (1 << 24)
+#define DISB (1 << 23)
+#define MEM_SR (1 << 21)
+#define SRS (1 << 20)
+#define CTS (1 << 19)
+#define MS4V (1 << 18)
+#define PWR_FLR (1 << 16)
+#define PME_B0_S5_DIS (1 << 15)
+#define SUS_PWR_FLR (1 << 14)
+#define WOL_EN_OVRD (1 << 13)
+#define DIS_SLP_X_STRCH_SUS_UP (1 << 12)
+#define GEN_RST_STS (1 << 9)
+#define RPS (1 << 2)
+#define AFTERG3_EN (1 << 0)
+#define GEN_PMCON2 0x24
+#define SLPSX_STR_POL_LOCK (1 << 18)
+#define BIOS_PCI_EXP_EN (1 << 10)
+#define PWRBTN_LVL (1 << 9)
+#define SMI_LOCK (1 << 4)
+
/* Power Management Unit */
#define PUNIT_BASE_ADDRESS 0xfed05000
#define PUNIT_BASE_SIZE 0x800
@@ -62,6 +83,9 @@
#define ACPI_BASE_ADDRESS 0x0400
#define ACPI_BASE_SIZE 0x80
+#define PM1_STS 0x00
+#define PM1_CNT 0x04
+
#define GPIO_BASE_ADDRESS 0x0500
#define GPIO_BASE_SIZE 0x100
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 03/22] x86: Add post codes for OS resume
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 01/22] x86: acpi: Add Kconfig option and header file for ACPI resume Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 02/22] x86: baytrail: acpi: Add APIs for determining/clearing sleep state Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 04/22] x86: fsp: acpi: Pass different boot mode to FSP init Bin Meng
` (19 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
This adds OS_RESUME (0x40) and RESUME_FAILURE (0xed) post codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/include/asm/post.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/post.h b/arch/x86/include/asm/post.h
index 6b774bd..f627663 100644
--- a/arch/x86/include/asm/post.h
+++ b/arch/x86/include/asm/post.h
@@ -31,10 +31,12 @@
#define POST_MRC 0x2f
#define POST_DRAM 0x30
#define POST_LAPIC 0x31
+#define POST_OS_RESUME 0x40
#define POST_RAM_FAILURE 0xea
#define POST_BIST_FAILURE 0xeb
#define POST_CAR_FAILURE 0xec
+#define POST_RESUME_FAILURE 0xed
/* Output a post code using al - value must be 0 to 0xff */
#ifdef __ASSEMBLY__
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 04/22] x86: fsp: acpi: Pass different boot mode to FSP init
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (2 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 03/22] x86: Add post codes for OS resume Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 05/22] x86: Store and display previous sleep state Bin Meng
` (18 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
When ACPI S3 resume is turned on, we should pass different boot mode
to FSP init instead of default BOOT_FULL_CONFIG.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/include/asm/acpi_s3.h | 18 ++++++++++++++++++
arch/x86/lib/fsp/fsp_common.c | 26 +++++++++++++++++++++++++-
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/acpi_s3.h b/arch/x86/include/asm/acpi_s3.h
index 78c53ea..ec05211 100644
--- a/arch/x86/include/asm/acpi_s3.h
+++ b/arch/x86/include/asm/acpi_s3.h
@@ -61,4 +61,22 @@ static inline enum acpi_sleep_state acpi_sleep_from_pm1(u32 pm1_cnt)
return -EINVAL;
}
+/**
+ * chipset_prev_sleep_state() - Get chipset previous sleep state
+ *
+ * This returns chipset previous sleep state from ACPI registers.
+ * Platform codes must supply this routine in order to support ACPI S3.
+ *
+ * @return ACPI_S0/S1/S2/S3/S4/S5.
+ */
+enum acpi_sleep_state chipset_prev_sleep_state(void);
+
+/**
+ * chipset_clear_sleep_state() - Clear chipset sleep state
+ *
+ * This clears chipset sleep state in ACPI registers.
+ * Platform codes must supply this routine in order to support ACPI S3.
+ */
+void chipset_clear_sleep_state(void);
+
#endif /* __ASM_ACPI_S3_H__ */
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
index 66a388d..cc42cad 100644
--- a/arch/x86/lib/fsp/fsp_common.c
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -6,6 +6,7 @@
#include <common.h>
#include <errno.h>
+#include <asm/acpi_s3.h>
#include <asm/io.h>
#include <asm/mrccache.h>
#include <asm/post.h>
@@ -78,6 +79,10 @@ static __maybe_unused void *fsp_prepare_mrc_cache(void)
int arch_fsp_init(void)
{
void *nvs;
+ int boot_mode = BOOT_FULL_CONFIG;
+#ifdef CONFIG_HAVE_ACPI_RESUME
+ int prev_sleep_state = chipset_prev_sleep_state();
+#endif
if (!gd->arch.hob_list) {
#ifdef CONFIG_ENABLE_MRC_CACHE
@@ -85,12 +90,31 @@ int arch_fsp_init(void)
#else
nvs = NULL;
#endif
+
+#ifdef CONFIG_HAVE_ACPI_RESUME
+ if (prev_sleep_state == ACPI_S3) {
+ if (nvs == NULL) {
+ /* If waking from S3 and no cache then */
+ debug("No MRC cache found in S3 resume path\n");
+ post_code(POST_RESUME_FAILURE);
+ /* Clear Sleep Type */
+ chipset_clear_sleep_state();
+ /* Reboot */
+ debug("Rebooting..\n");
+ reset_cpu(0);
+ /* Should not reach here.. */
+ panic("Reboot System");
+ }
+
+ boot_mode = BOOT_ON_S3_RESUME;
+ }
+#endif
/*
* The first time we enter here, call fsp_init().
* Note the execution does not return to this function,
* instead it jumps to fsp_continue().
*/
- fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, BOOT_FULL_CONFIG, nvs);
+ fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, boot_mode, nvs);
} else {
/*
* The second time we enter here, adjust the size of malloc()
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 05/22] x86: Store and display previous sleep state
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (3 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 04/22] x86: fsp: acpi: Pass different boot mode to FSP init Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 06/22] x86: baytrail: Conditionally report S3 in the ACPI table Bin Meng
` (17 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
Add one member in the global data to store previous sleep state,
and display the state during boot in print_cpuinfo().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- add a function comment block for acpi_ss_string()
- use a string array for sleep state string
- add a description for gd->arch.prev_sleep_state
- change to use debug() in default_print_cpuinfo()
arch/x86/cpu/cpu.c | 6 ++++++
arch/x86/include/asm/acpi_s3.h | 13 +++++++++++++
arch/x86/include/asm/global_data.h | 3 +++
arch/x86/lib/fsp/fsp_common.c | 1 +
4 files changed, 23 insertions(+)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 8fa6953..7222ec8 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -25,6 +25,7 @@
#include <errno.h>
#include <malloc.h>
#include <syscon.h>
+#include <asm/acpi_s3.h>
#include <asm/control_regs.h>
#include <asm/coreboot_tables.h>
#include <asm/cpu.h>
@@ -179,6 +180,11 @@ int default_print_cpuinfo(void)
cpu_has_64bit() ? "x86_64" : "x86",
cpu_vendor_name(gd->arch.x86_vendor), gd->arch.x86_device);
+#ifdef CONFIG_HAVE_ACPI_RESUME
+ debug("ACPI previous sleep state: %s\n",
+ acpi_ss_string(gd->arch.prev_sleep_state));
+#endif
+
return 0;
}
diff --git a/arch/x86/include/asm/acpi_s3.h b/arch/x86/include/asm/acpi_s3.h
index ec05211..10cedde 100644
--- a/arch/x86/include/asm/acpi_s3.h
+++ b/arch/x86/include/asm/acpi_s3.h
@@ -37,6 +37,19 @@ enum acpi_sleep_state {
};
/**
+ * acpi_ss_string() - get ACPI-defined sleep state string
+ *
+ * @pm1_cnt: ACPI-defined sleep state
+ * @return: a pointer to the sleep state string.
+ */
+static inline char *acpi_ss_string(enum acpi_sleep_state state)
+{
+ char *ss_string[] = { "S0", "S1", "S2", "S3", "S4", "S5"};
+
+ return ss_string[state];
+}
+
+/**
* acpi_sleep_from_pm1() - get ACPI-defined sleep state from PM1_CNT register
*
* @pm1_cnt: PM1_CNT register value
diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
index 4570bc7..7d5efea 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -99,6 +99,9 @@ struct arch_global_data {
u32 high_table_ptr;
u32 high_table_limit;
#endif
+#ifdef CONFIG_HAVE_ACPI_RESUME
+ int prev_sleep_state; /* Previous sleep state */
+#endif
};
#endif
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
index cc42cad..f2d50ac 100644
--- a/arch/x86/lib/fsp/fsp_common.c
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -82,6 +82,7 @@ int arch_fsp_init(void)
int boot_mode = BOOT_FULL_CONFIG;
#ifdef CONFIG_HAVE_ACPI_RESUME
int prev_sleep_state = chipset_prev_sleep_state();
+ gd->arch.prev_sleep_state = prev_sleep_state;
#endif
if (!gd->arch.hob_list) {
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 05/22] x86: Store and display previous sleep state
2017-04-21 14:24 ` [U-Boot] [PATCH v2 05/22] x86: Store and display previous sleep state Bin Meng
@ 2017-04-26 7:34 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:34 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Add one member in the global data to store previous sleep state,
> and display the state during boot in print_cpuinfo().
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - add a function comment block for acpi_ss_string()
> - use a string array for sleep state string
> - add a description for gd->arch.prev_sleep_state
> - change to use debug() in default_print_cpuinfo()
>
> arch/x86/cpu/cpu.c | 6 ++++++
> arch/x86/include/asm/acpi_s3.h | 13 +++++++++++++
> arch/x86/include/asm/global_data.h | 3 +++
> arch/x86/lib/fsp/fsp_common.c | 1 +
> 4 files changed, 23 insertions(+)
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 06/22] x86: baytrail: Conditionally report S3 in the ACPI table
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (4 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 05/22] x86: Store and display previous sleep state Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 07/22] x86: fsp: Mark memory used by U-Boot as reserved in the E820 table for S3 Bin Meng
` (16 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
When U-Boot is built without ACPI S3 support, it should not report
S3 in the ACPI table otherwise when kernel does STR it won't work.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/include/asm/arch-baytrail/acpi/sleepstates.asl | 2 ++
arch/x86/include/asm/global_data.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/arch-baytrail/acpi/sleepstates.asl b/arch/x86/include/asm/arch-baytrail/acpi/sleepstates.asl
index eb5ae76..5600723 100644
--- a/arch/x86/include/asm/arch-baytrail/acpi/sleepstates.asl
+++ b/arch/x86/include/asm/arch-baytrail/acpi/sleepstates.asl
@@ -8,6 +8,8 @@
*/
Name(\_S0, Package() {0x0, 0x0, 0x0, 0x0})
+#ifdef CONFIG_HAVE_ACPI_RESUME
Name(\_S3, Package() {0x5, 0x0, 0x0, 0x0})
+#endif
Name(\_S4, Package() {0x6, 0x0, 0x0, 0x0})
Name(\_S5, Package() {0x7, 0x0, 0x0, 0x0})
diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
index 7d5efea..b4ca473 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -100,7 +100,7 @@ struct arch_global_data {
u32 high_table_limit;
#endif
#ifdef CONFIG_HAVE_ACPI_RESUME
- int prev_sleep_state; /* Previous sleep state */
+ int prev_sleep_state; /* Previous sleep state ACPI_S0/1../5 */
#endif
};
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 07/22] x86: fsp: Mark memory used by U-Boot as reserved in the E820 table for S3
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (5 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 06/22] x86: baytrail: Conditionally report S3 in the ACPI table Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 08/22] x86: acpi: Add wake up assembly stub Bin Meng
` (15 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
U-Boot itself as well as everything that is consumed by U-Boot (like
heap, stack, dtb, etc) needs to be reserved and reported in the E820
table when S3 resume is on.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/Kconfig | 8 ++++++++
arch/x86/lib/fsp/fsp_dram.c | 12 ++++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b568852..5322eff 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -601,6 +601,14 @@ config HAVE_ACPI_RESUME
is done, U-Boot needs to find out the wakeup vector provided by OSes
and jump there.
+config STACK_SIZE
+ hex
+ depends on HAVE_ACPI_RESUME
+ default 0x1000
+ help
+ Estimated U-Boot's runtime stack size that needs to be reserved
+ during an ACPI S3 resume.
+
config MAX_PIRQ_LINKS
int
default 8
diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
index 8b880cd..1a7af57 100644
--- a/arch/x86/lib/fsp/fsp_dram.c
+++ b/arch/x86/lib/fsp/fsp_dram.c
@@ -92,5 +92,17 @@ unsigned install_e820_map(unsigned max_entries, struct e820entry *entries)
entries[num_entries].type = E820_RESERVED;
num_entries++;
+#ifdef CONFIG_HAVE_ACPI_RESUME
+ /*
+ * Everything between U-Boot's stack and ram top needs to be
+ * reserved in order for ACPI S3 resume to work.
+ */
+ entries[num_entries].addr = gd->start_addr_sp - CONFIG_STACK_SIZE;
+ entries[num_entries].size = gd->ram_top - gd->start_addr_sp + \
+ CONFIG_STACK_SIZE;
+ entries[num_entries].type = E820_RESERVED;
+ num_entries++;
+#endif
+
return num_entries;
}
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 08/22] x86: acpi: Add wake up assembly stub
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (6 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 07/22] x86: fsp: Mark memory used by U-Boot as reserved in the E820 table for S3 Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 09/22] x86: acpi: Add one API to find OS wakeup vector Bin Meng
` (14 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
This adds a wake up stub before jumping to OS wake up vector.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- add brackets around the second x in RELOCATED(x) macro
- word-wrap to use more columns
- change to use present tense in the comments
arch/x86/cpu/Makefile | 1 +
arch/x86/cpu/wakeup.S | 78 ++++++++++++++++++++++++++++++++++++++++++
arch/x86/include/asm/acpi_s3.h | 9 +++++
3 files changed, 88 insertions(+)
create mode 100644 arch/x86/cpu/wakeup.S
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
index 92a9023..e1c84ce 100644
--- a/arch/x86/cpu/Makefile
+++ b/arch/x86/cpu/Makefile
@@ -45,6 +45,7 @@ ifndef CONFIG_$(SPL_)X86_64
obj-$(CONFIG_SMP) += sipi_vector.o
endif
obj-y += turbo.o
+obj-$(CONFIG_HAVE_ACPI_RESUME) += wakeup.o
ifeq ($(CONFIG_$(SPL_)X86_64),y)
obj-y += x86_64/
diff --git a/arch/x86/cpu/wakeup.S b/arch/x86/cpu/wakeup.S
new file mode 100644
index 0000000..066c9b1
--- /dev/null
+++ b/arch/x86/cpu/wakeup.S
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2017, Bin Meng <bmeng.cn@gmail.com>
+ *
+ * From coreboot src/arch/x86/wakeup.S
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <asm/acpi_s3.h>
+#include <asm/processor.h>
+#include <asm/processor-flags.h>
+
+#define RELOCATED(x) ((x) - __wakeup + WAKEUP_BASE)
+
+#define CODE_SEG (X86_GDT_ENTRY_16BIT_CS * X86_GDT_ENTRY_SIZE)
+#define DATA_SEG (X86_GDT_ENTRY_16BIT_DS * X86_GDT_ENTRY_SIZE)
+
+ .code32
+ .globl __wakeup
+__wakeup:
+ /* First prepare the jmp to the resume vector */
+ mov 0x4(%esp), %eax /* vector */
+ /* last 4 bits of linear addr are taken as offset */
+ andw $0x0f, %ax
+ movw %ax, (__wakeup_offset)
+ mov 0x4(%esp), %eax
+ /* the rest is taken as segment */
+ shr $4, %eax
+ movw %ax, (__wakeup_segment)
+
+ /* Activate the right segment descriptor real mode */
+ ljmp $CODE_SEG, $RELOCATED(1f)
+1:
+ /* 16 bit code from here on... */
+ .code16
+
+ /*
+ * Load the segment registers w/ properly configured segment
+ * descriptors. They will retain these configurations (limits,
+ * writability, etc.) once protected mode is turned off.
+ */
+ mov $DATA_SEG, %ax
+ mov %ax, %ds
+ mov %ax, %es
+ mov %ax, %fs
+ mov %ax, %gs
+ mov %ax, %ss
+
+ /* Turn off protection */
+ movl %cr0, %eax
+ andl $~X86_CR0_PE, %eax
+ movl %eax, %cr0
+
+ /* Now really going into real mode */
+ ljmp $0, $RELOCATED(1f)
+1:
+ movw $0x0, %ax
+ movw %ax, %ds
+ movw %ax, %es
+ movw %ax, %ss
+ movw %ax, %fs
+ movw %ax, %gs
+
+ /*
+ * This is a FAR JMP to the OS waking vector.
+ * The C code changes the address to be correct.
+ */
+ .byte 0xea
+
+__wakeup_offset = RELOCATED(.)
+ .word 0x0000
+
+__wakeup_segment = RELOCATED(.)
+ .word 0x0000
+
+ .globl __wakeup_size
+__wakeup_size:
+ .long . - __wakeup
diff --git a/arch/x86/include/asm/acpi_s3.h b/arch/x86/include/asm/acpi_s3.h
index 10cedde..a06466c 100644
--- a/arch/x86/include/asm/acpi_s3.h
+++ b/arch/x86/include/asm/acpi_s3.h
@@ -7,6 +7,8 @@
#ifndef __ASM_ACPI_S3_H__
#define __ASM_ACPI_S3_H__
+#define WAKEUP_BASE 0x600
+
/* PM1_STATUS register */
#define WAK_STS (1 << 15)
#define PCIEXPWAK_STS (1 << 14)
@@ -27,6 +29,11 @@
#define SLP_TYP_S4 6
#define SLP_TYP_S5 7
+#ifndef __ASSEMBLY__
+
+extern char __wakeup[];
+extern int __wakeup_size;
+
enum acpi_sleep_state {
ACPI_S0,
ACPI_S1,
@@ -92,4 +99,6 @@ enum acpi_sleep_state chipset_prev_sleep_state(void);
*/
void chipset_clear_sleep_state(void);
+#endif /* __ASSEMBLY__ */
+
#endif /* __ASM_ACPI_S3_H__ */
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 08/22] x86: acpi: Add wake up assembly stub
2017-04-21 14:24 ` [U-Boot] [PATCH v2 08/22] x86: acpi: Add wake up assembly stub Bin Meng
@ 2017-04-26 7:34 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:34 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> This adds a wake up stub before jumping to OS wake up vector.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - add brackets around the second x in RELOCATED(x) macro
> - word-wrap to use more columns
> - change to use present tense in the comments
>
> arch/x86/cpu/Makefile | 1 +
> arch/x86/cpu/wakeup.S | 78 ++++++++++++++++++++++++++++++++++++++++++
> arch/x86/include/asm/acpi_s3.h | 9 +++++
> 3 files changed, 88 insertions(+)
> create mode 100644 arch/x86/cpu/wakeup.S
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 09/22] x86: acpi: Add one API to find OS wakeup vector
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (7 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 08/22] x86: acpi: Add wake up assembly stub Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-24 3:38 ` Simon Glass
2017-04-21 14:24 ` [U-Boot] [PATCH v2 10/22] x86: acpi: Resume OS if resume vector is found Bin Meng
` (13 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
This adds one API acpi_find_wakeup_vector() to locate OS wakeup
vector from the ACPI FACS table, to be used in the S3 boot path.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- add a function comment block for acpi_find_wakeup_vector()
arch/x86/include/asm/acpi_table.h | 10 ++++++
arch/x86/include/asm/tables.h | 1 +
arch/x86/lib/acpi_table.c | 72 +++++++++++++++++++++++++++++++++++++++
3 files changed, 83 insertions(+)
diff --git a/arch/x86/include/asm/acpi_table.h b/arch/x86/include/asm/acpi_table.h
index bbd80a1..20b906c 100644
--- a/arch/x86/include/asm/acpi_table.h
+++ b/arch/x86/include/asm/acpi_table.h
@@ -317,3 +317,13 @@ int acpi_create_madt_lapic_nmi(struct acpi_madt_lapic_nmi *lapic_nmi,
u32 acpi_fill_madt(u32 current);
void acpi_create_gnvs(struct acpi_global_nvs *gnvs);
ulong write_acpi_tables(ulong start);
+
+/**
+ * acpi_find_wakeup_vector() - find OS installed wake up vector address
+ *
+ * This routine parses the ACPI table to locate the wake up vector installed
+ * by the OS previously.
+ *
+ * @return: wake up vector address installed by the OS
+ */
+void *acpi_find_wakeup_vector(void);
diff --git a/arch/x86/include/asm/tables.h b/arch/x86/include/asm/tables.h
index d1b2388..9e8208b 100644
--- a/arch/x86/include/asm/tables.h
+++ b/arch/x86/include/asm/tables.h
@@ -15,6 +15,7 @@
* PIRQ routing table, Multi-Processor table and ACPI table.
*/
#define ROM_TABLE_ADDR 0xf0000
+#define ROM_TABLE_END 0xfffff
#define ROM_TABLE_ALIGN 1024
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 355456d..f118345 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -438,3 +438,75 @@ ulong write_acpi_tables(ulong start)
return current;
}
+
+static struct acpi_rsdp *acpi_valid_rsdp(struct acpi_rsdp *rsdp)
+{
+ if (strncmp((char *)rsdp, RSDP_SIG, sizeof(RSDP_SIG) - 1) != 0)
+ return NULL;
+
+ debug("Looking on %p for valid checksum\n", rsdp);
+
+ if (table_compute_checksum((void *)rsdp, 20) != 0)
+ return NULL;
+ debug("acpi rsdp checksum 1 passed\n");
+
+ if ((rsdp->revision > 1) &&
+ (table_compute_checksum((void *)rsdp, rsdp->length) != 0))
+ return NULL;
+ debug("acpi rsdp checksum 2 passed\n");
+
+ return rsdp;
+}
+
+void *acpi_find_wakeup_vector(void)
+{
+ char *p, *end;
+ struct acpi_rsdp *rsdp = NULL;
+ struct acpi_rsdt *rsdt;
+ struct acpi_fadt *fadt = NULL;
+ struct acpi_facs *facs;
+ void *wake_vec;
+ int i;
+
+ debug("Trying to find the wakeup vector...\n");
+
+ /* Find RSDP */
+ for (p = (char *)ROM_TABLE_ADDR; p < (char *)ROM_TABLE_END; p += 16) {
+ rsdp = acpi_valid_rsdp((struct acpi_rsdp *)p);
+ if (rsdp)
+ break;
+ }
+
+ if (rsdp == NULL)
+ return NULL;
+
+ debug("RSDP found@%p\n", rsdp);
+ rsdt = (struct acpi_rsdt *)rsdp->rsdt_address;
+
+ end = (char *)rsdt + rsdt->header.length;
+ debug("RSDT found at %p ends at %p\n", rsdt, end);
+
+ for (i = 0; ((char *)&rsdt->entry[i]) < end; i++) {
+ fadt = (struct acpi_fadt *)rsdt->entry[i];
+ if (strncmp((char *)fadt, "FACP", 4) == 0)
+ break;
+ fadt = NULL;
+ }
+
+ if (fadt == NULL)
+ return NULL;
+
+ debug("FADT found at %p\n", fadt);
+ facs = (struct acpi_facs *)fadt->firmware_ctrl;
+
+ if (facs == NULL) {
+ debug("No FACS found, wake up from S3 not possible.\n");
+ return NULL;
+ }
+
+ debug("FACS found at %p\n", facs);
+ wake_vec = (void *)facs->firmware_waking_vector;
+ debug("OS waking vector is %p\n", wake_vec);
+
+ return wake_vec;
+}
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 09/22] x86: acpi: Add one API to find OS wakeup vector
2017-04-21 14:24 ` [U-Boot] [PATCH v2 09/22] x86: acpi: Add one API to find OS wakeup vector Bin Meng
@ 2017-04-24 3:38 ` Simon Glass
2017-04-26 7:34 ` Bin Meng
0 siblings, 1 reply; 58+ messages in thread
From: Simon Glass @ 2017-04-24 3:38 UTC (permalink / raw)
To: u-boot
On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@gmail.com> wrote:
> This adds one API acpi_find_wakeup_vector() to locate OS wakeup
> vector from the ACPI FACS table, to be used in the S3 boot path.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - add a function comment block for acpi_find_wakeup_vector()
>
> arch/x86/include/asm/acpi_table.h | 10 ++++++
> arch/x86/include/asm/tables.h | 1 +
> arch/x86/lib/acpi_table.c | 72 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 83 insertions(+)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 09/22] x86: acpi: Add one API to find OS wakeup vector
2017-04-24 3:38 ` Simon Glass
@ 2017-04-26 7:34 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:34 UTC (permalink / raw)
To: u-boot
On Mon, Apr 24, 2017 at 11:38 AM, Simon Glass <sjg@chromium.org> wrote:
> On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@gmail.com> wrote:
>> This adds one API acpi_find_wakeup_vector() to locate OS wakeup
>> vector from the ACPI FACS table, to be used in the S3 boot path.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>
>> ---
>>
>> Changes in v2:
>> - add a function comment block for acpi_find_wakeup_vector()
>>
>> arch/x86/include/asm/acpi_table.h | 10 ++++++
>> arch/x86/include/asm/tables.h | 1 +
>> arch/x86/lib/acpi_table.c | 72 +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 83 insertions(+)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 10/22] x86: acpi: Resume OS if resume vector is found
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (8 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 09/22] x86: acpi: Add one API to find OS wakeup vector Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 11/22] x86: Add an early CMOS access library Bin Meng
` (12 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
In an S3 resume path, U-Boot does everything like a cold boot except
in the last_stage_init() it jumps to the OS resume vector.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/cpu/cpu.c | 8 ++++++++
arch/x86/include/asm/acpi_s3.h | 10 ++++++++++
arch/x86/lib/Makefile | 1 +
arch/x86/lib/acpi_s3.c | 26 ++++++++++++++++++++++++++
4 files changed, 45 insertions(+)
create mode 100644 arch/x86/lib/acpi_s3.c
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 7222ec8..f686ad4 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -26,6 +26,7 @@
#include <malloc.h>
#include <syscon.h>
#include <asm/acpi_s3.h>
+#include <asm/acpi_table.h>
#include <asm/control_regs.h>
#include <asm/coreboot_tables.h>
#include <asm/cpu.h>
@@ -204,6 +205,13 @@ __weak void board_final_cleanup(void)
int last_stage_init(void)
{
+#if CONFIG_HAVE_ACPI_RESUME
+ void *wake_vector = acpi_find_wakeup_vector();
+
+ if (wake_vector != NULL && gd->arch.prev_sleep_state == ACPI_S3)
+ acpi_resume(wake_vector);
+#endif
+
write_tables();
board_final_cleanup();
diff --git a/arch/x86/include/asm/acpi_s3.h b/arch/x86/include/asm/acpi_s3.h
index a06466c..b8d14f4 100644
--- a/arch/x86/include/asm/acpi_s3.h
+++ b/arch/x86/include/asm/acpi_s3.h
@@ -99,6 +99,16 @@ enum acpi_sleep_state chipset_prev_sleep_state(void);
*/
void chipset_clear_sleep_state(void);
+/**
+ * acpi_resume() - Do ACPI S3 resume
+ *
+ * This calls U-Boot wake up assembly stub and jumps to OS's wake up vector.
+ *
+ * @wake_vec: OS wake up vector
+ * @return: Never returns
+ */
+void acpi_resume(void *wake_vec);
+
#endif /* __ASSEMBLY__ */
#endif /* __ASM_ACPI_S3_H__ */
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index d1ad37a..21f59a0 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_INTEL_MID) += scu.o
obj-y += sections.o
obj-y += sfi.o
obj-y += string.o
+obj-$(CONFIG_HAVE_ACPI_RESUME) += acpi_s3.o
ifndef CONFIG_QEMU
obj-$(CONFIG_GENERATE_ACPI_TABLE) += acpi_table.o
endif
diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
new file mode 100644
index 0000000..f679c06
--- /dev/null
+++ b/arch/x86/lib/acpi_s3.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2017, Bin Meng <bmeng.cn@gmail.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <asm/acpi_s3.h>
+#include <asm/post.h>
+
+static void asmlinkage (*acpi_do_wakeup)(void *vector) = (void *)WAKEUP_BASE;
+
+static void acpi_jump_to_wakeup(void *vector)
+{
+ /* Copy wakeup trampoline in place */
+ memcpy((void *)WAKEUP_BASE, __wakeup, __wakeup_size);
+
+ printf("Jumping to OS waking vector %p\n", vector);
+ acpi_do_wakeup(vector);
+}
+
+void acpi_resume(void *wake_vec)
+{
+ post_code(POST_OS_RESUME);
+ acpi_jump_to_wakeup(wake_vec);
+}
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 10/22] x86: acpi: Resume OS if resume vector is found
2017-04-21 14:24 ` [U-Boot] [PATCH v2 10/22] x86: acpi: Resume OS if resume vector is found Bin Meng
@ 2017-04-26 7:34 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:34 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> In an S3 resume path, U-Boot does everything like a cold boot except
> in the last_stage_init() it jumps to the OS resume vector.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/cpu.c | 8 ++++++++
> arch/x86/include/asm/acpi_s3.h | 10 ++++++++++
> arch/x86/lib/Makefile | 1 +
> arch/x86/lib/acpi_s3.c | 26 ++++++++++++++++++++++++++
> 4 files changed, 45 insertions(+)
> create mode 100644 arch/x86/lib/acpi_s3.c
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 11/22] x86: Add an early CMOS access library
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (9 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 10/22] x86: acpi: Resume OS if resume vector is found Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 12/22] x86: fsp: Save stack address to CMOS for next S3 boot Bin Meng
` (11 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
This adds a library that provides CMOS (inside RTC SRAM) access
at a very early stage when driver model is not available yet.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/include/asm/early_cmos.h | 43 +++++++++++++++++++++++++++++++++
arch/x86/lib/Makefile | 1 +
arch/x86/lib/early_cmos.c | 51 +++++++++++++++++++++++++++++++++++++++
3 files changed, 95 insertions(+)
create mode 100644 arch/x86/include/asm/early_cmos.h
create mode 100644 arch/x86/lib/early_cmos.c
diff --git a/arch/x86/include/asm/early_cmos.h b/arch/x86/include/asm/early_cmos.h
new file mode 100644
index 0000000..cd2634d
--- /dev/null
+++ b/arch/x86/include/asm/early_cmos.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2017, Bin Meng <bmeng.cn@gmail.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __EARLY_CMOS_H
+#define __EARLY_CMOS_H
+
+/* CMOS actually resides in the RTC SRAM */
+#define CMOS_IO_PORT 0x70
+
+/**
+ * cmos_read8() - Get 8-bit data stored at the given address
+ *
+ * This reads from CMOS for the 8-bit data stored at the given address.
+ *
+ * @addr: RTC SRAM address
+ * @return: 8-bit data stored at the given address
+ */
+u8 cmos_read8(u8 addr);
+
+/**
+ * cmos_read16() - Get 16-bit data stored at the given address
+ *
+ * This reads from CMOS for the 16-bit data stored at the given address.
+ *
+ * @addr: RTC SRAM address
+ * @return: 16-bit data stored at the given address
+ */
+u16 cmos_read16(u8 addr);
+
+/**
+ * cmos_read32() - Get 32-bit data stored at the given address
+ *
+ * This reads from CMOS for the 32-bit data stored at the given address.
+ *
+ * @addr: RTC SRAM address
+ * @return: 32-bit data stored at the given address
+ */
+u32 cmos_read32(u8 addr);
+
+#endif /* __EARLY_CMOS_H */
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 21f59a0..fe00d75 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
endif
obj-y += cmd_boot.o
obj-$(CONFIG_SEABIOS) += coreboot_table.o
+obj-y += early_cmos.o
obj-$(CONFIG_EFI) += efi/
obj-y += e820.o
obj-y += gcc.o
diff --git a/arch/x86/lib/early_cmos.c b/arch/x86/lib/early_cmos.c
new file mode 100644
index 0000000..fa0b327
--- /dev/null
+++ b/arch/x86/lib/early_cmos.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2017, Bin Meng <bmeng.cn@gmail.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/*
+ * This library provides CMOS (inside RTC SRAM) access routines at a very
+ * early stage when driver model is not available yet. Only read access is
+ * provided. The 16-bit/32-bit read are compatible with driver model RTC
+ * uclass write ops, that data is stored in little-endian mode.
+ */
+
+#include <common.h>
+#include <asm/early_cmos.h>
+#include <asm/io.h>
+
+u8 cmos_read8(u8 addr)
+{
+ outb(addr, CMOS_IO_PORT);
+
+ return inb(CMOS_IO_PORT + 1);
+}
+
+u16 cmos_read16(u8 addr)
+{
+ u16 value = 0;
+ u16 data;
+ int i;
+
+ for (i = 0; i < sizeof(value); i++) {
+ data = cmos_read8(addr + i);
+ value |= data << (i << 3);
+ }
+
+ return value;
+}
+
+u32 cmos_read32(u8 addr)
+{
+ u32 value = 0;
+ u32 data;
+ int i;
+
+ for (i = 0; i < sizeof(value); i++) {
+ data = cmos_read8(addr + i);
+ value |= data << (i << 3);
+ }
+
+ return value;
+}
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 11/22] x86: Add an early CMOS access library
2017-04-21 14:24 ` [U-Boot] [PATCH v2 11/22] x86: Add an early CMOS access library Bin Meng
@ 2017-04-26 7:34 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:34 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> This adds a library that provides CMOS (inside RTC SRAM) access
> at a very early stage when driver model is not available yet.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
> arch/x86/include/asm/early_cmos.h | 43 +++++++++++++++++++++++++++++++++
> arch/x86/lib/Makefile | 1 +
> arch/x86/lib/early_cmos.c | 51 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 95 insertions(+)
> create mode 100644 arch/x86/include/asm/early_cmos.h
> create mode 100644 arch/x86/lib/early_cmos.c
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 12/22] x86: fsp: Save stack address to CMOS for next S3 boot
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (10 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 11/22] x86: Add an early CMOS access library Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:34 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 13/22] x86: Do not clear high table area for S3 Bin Meng
` (10 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
At the end of pre-relocation phase, save the new stack address
to CMOS and use it as the stack on next S3 boot for fsp_init()
continuation function.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- add a function comment block for fsp_save_s3_stack()
- check error on calling rtc_write32()
- add some comments about why calling cmos_read32() instead of rtc_
arch/x86/cpu/cpu.c | 8 ++++++++
arch/x86/include/asm/cmos_layout.h | 31 +++++++++++++++++++++++++++++++
arch/x86/include/asm/u-boot-x86.h | 13 +++++++++++++
arch/x86/lib/fsp/fsp_common.c | 38 +++++++++++++++++++++++++++++++++++++-
4 files changed, 89 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/include/asm/cmos_layout.h
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index f686ad4..f86eaa9 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -278,6 +278,14 @@ int reserve_arch(void)
high_table_reserve();
#endif
+#if defined(CONFIG_HAVE_ACPI_RESUME) && defined(CONFIG_HAVE_FSP)
+ /*
+ * Save stack address to CMOS so that at next S3 boot,
+ * we can use it as the stack address for fsp_contiue()
+ */
+ fsp_save_s3_stack();
+#endif
+
return 0;
}
#endif
diff --git a/arch/x86/include/asm/cmos_layout.h b/arch/x86/include/asm/cmos_layout.h
new file mode 100644
index 0000000..0a0a51e
--- /dev/null
+++ b/arch/x86/include/asm/cmos_layout.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2017, Bin Meng <bmeng.cn@gmail.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __CMOS_LAYOUT_H
+#define __CMOS_LAYOUT_H
+
+/*
+ * The RTC internal registers and RAM is organized as two banks of 128 bytes
+ * each, called the standard and extended banks. The first 14 bytes of the
+ * standard bank contain the RTC time and date information along with four
+ * registers, A - D, that are used for configuration of the RTC. The extended
+ * bank contains a full 128 bytes of battery backed SRAM.
+ *
+ * For simplicity in U-Boot we only support CMOS in the standard bank, and
+ * its base address starts from offset 0x10, which leaves us 112 bytes space.
+ */
+#define CMOS_BASE 0x10
+
+/*
+ * The file records all offsets off CMOS_BASE that is currently used by
+ * U-Boot for various reasons. It is put in such a unified place in order
+ * to be consistent across platforms.
+ */
+
+/* stack address for S3 boot in a FSP configuration, 4 bytes */
+#define CMOS_FSP_STACK_ADDR CMOS_BASE
+
+#endif /* __CMOS_LAYOUT_H */
diff --git a/arch/x86/include/asm/u-boot-x86.h b/arch/x86/include/asm/u-boot-x86.h
index d2d6039..d55455f 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -54,6 +54,19 @@ u32 isa_map_rom(u32 bus_addr, int size);
/* arch/x86/lib/... */
int video_bios_init(void);
+/* arch/x86/lib/fsp/... */
+
+/**
+ * fsp_save_s3_stack() - save stack address to CMOS for next S3 boot
+ *
+ * At the end of pre-relocation phase, save the new stack address
+ * to CMOS and use it as the stack on next S3 boot for fsp_init()
+ * continuation function.
+ *
+ * @return: 0 if OK, -ve on error
+ */
+int fsp_save_s3_stack(void);
+
void board_init_f_r_trampoline(ulong) __attribute__ ((noreturn));
void board_init_f_r(void) __attribute__ ((noreturn));
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
index f2d50ac..3397bb8 100644
--- a/arch/x86/lib/fsp/fsp_common.c
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -5,8 +5,12 @@
*/
#include <common.h>
+#include <dm.h>
#include <errno.h>
+#include <rtc.h>
#include <asm/acpi_s3.h>
+#include <asm/cmos_layout.h>
+#include <asm/early_cmos.h>
#include <asm/io.h>
#include <asm/mrccache.h>
#include <asm/post.h>
@@ -76,9 +80,36 @@ static __maybe_unused void *fsp_prepare_mrc_cache(void)
return cache->data;
}
+#ifdef CONFIG_HAVE_ACPI_RESUME
+int fsp_save_s3_stack(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ if (gd->arch.prev_sleep_state == ACPI_S3)
+ return 0;
+
+ ret = uclass_get_device(UCLASS_RTC, 0, &dev);
+ if (ret) {
+ debug("Cannot find RTC: err=%d\n", ret);
+ return -ENODEV;
+ }
+
+ /* Save the stack address to CMOS */
+ ret = rtc_write32(dev, CMOS_FSP_STACK_ADDR, gd->start_addr_sp);
+ if (ret) {
+ debug("Save stack address to CMOS: err=%d\n", ret);
+ return -EIO;
+ }
+
+ return 0;
+}
+#endif
+
int arch_fsp_init(void)
{
void *nvs;
+ int stack = CONFIG_FSP_TEMP_RAM_ADDR;
int boot_mode = BOOT_FULL_CONFIG;
#ifdef CONFIG_HAVE_ACPI_RESUME
int prev_sleep_state = chipset_prev_sleep_state();
@@ -107,6 +138,11 @@ int arch_fsp_init(void)
panic("Reboot System");
}
+ /*
+ * DM is not avaiable yet at this point, hence call
+ * CMOS access library which does not depend on DM.
+ */
+ stack = cmos_read32(CMOS_FSP_STACK_ADDR);
boot_mode = BOOT_ON_S3_RESUME;
}
#endif
@@ -115,7 +151,7 @@ int arch_fsp_init(void)
* Note the execution does not return to this function,
* instead it jumps to fsp_continue().
*/
- fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, boot_mode, nvs);
+ fsp_init(stack, boot_mode, nvs);
} else {
/*
* The second time we enter here, adjust the size of malloc()
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 12/22] x86: fsp: Save stack address to CMOS for next S3 boot
2017-04-21 14:24 ` [U-Boot] [PATCH v2 12/22] x86: fsp: Save stack address to CMOS for next S3 boot Bin Meng
@ 2017-04-26 7:34 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:34 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> At the end of pre-relocation phase, save the new stack address
> to CMOS and use it as the stack on next S3 boot for fsp_init()
> continuation function.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - add a function comment block for fsp_save_s3_stack()
> - check error on calling rtc_write32()
> - add some comments about why calling cmos_read32() instead of rtc_
>
> arch/x86/cpu/cpu.c | 8 ++++++++
> arch/x86/include/asm/cmos_layout.h | 31 +++++++++++++++++++++++++++++++
> arch/x86/include/asm/u-boot-x86.h | 13 +++++++++++++
> arch/x86/lib/fsp/fsp_common.c | 38 +++++++++++++++++++++++++++++++++++++-
> 4 files changed, 89 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/include/asm/cmos_layout.h
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 13/22] x86: Do not clear high table area for S3
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (11 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 12/22] x86: fsp: Save stack address to CMOS for next S3 boot Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-24 3:38 ` Simon Glass
2017-04-21 14:24 ` [U-Boot] [PATCH v2 14/22] x86: Adjust board_final_cleanup() order Bin Meng
` (9 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
When SeaBIOS is being used, U-Boot reserves a memory area to be
used for configuration tables like ACPI. But it should not be
cleared otherwise ACPI table will be missing.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch "Do not clear high table area for S3"
- drop patch "x86: fsp: Mark the first 64K low memory as reserved"
as it causes boot failure on GRUB
arch/x86/lib/coreboot_table.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/lib/coreboot_table.c b/arch/x86/lib/coreboot_table.c
index ceab3cf..b1b4cd9 100644
--- a/arch/x86/lib/coreboot_table.c
+++ b/arch/x86/lib/coreboot_table.c
@@ -6,6 +6,7 @@
#include <common.h>
#include <vbe.h>
+#include <asm/acpi_s3.h>
#include <asm/coreboot_tables.h>
#include <asm/e820.h>
@@ -19,7 +20,11 @@ int high_table_reserve(void)
gd->arch.high_table_ptr = gd->start_addr_sp;
/* clear the memory */
- memset((void *)gd->arch.high_table_ptr, 0, CONFIG_HIGH_TABLE_SIZE);
+#ifdef CONFIG_HAVE_ACPI_RESUME
+ if (gd->arch.prev_sleep_state != ACPI_S3)
+#endif
+ memset((void *)gd->arch.high_table_ptr, 0,
+ CONFIG_HIGH_TABLE_SIZE);
gd->start_addr_sp &= ~0xf;
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 13/22] x86: Do not clear high table area for S3
2017-04-21 14:24 ` [U-Boot] [PATCH v2 13/22] x86: Do not clear high table area for S3 Bin Meng
@ 2017-04-24 3:38 ` Simon Glass
2017-04-26 7:35 ` Bin Meng
0 siblings, 1 reply; 58+ messages in thread
From: Simon Glass @ 2017-04-24 3:38 UTC (permalink / raw)
To: u-boot
On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@gmail.com> wrote:
> When SeaBIOS is being used, U-Boot reserves a memory area to be
> used for configuration tables like ACPI. But it should not be
> cleared otherwise ACPI table will be missing.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - new patch "Do not clear high table area for S3"
> - drop patch "x86: fsp: Mark the first 64K low memory as reserved"
> as it causes boot failure on GRUB
>
> arch/x86/lib/coreboot_table.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 13/22] x86: Do not clear high table area for S3
2017-04-24 3:38 ` Simon Glass
@ 2017-04-26 7:35 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:35 UTC (permalink / raw)
To: u-boot
On Mon, Apr 24, 2017 at 11:38 AM, Simon Glass <sjg@chromium.org> wrote:
> On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@gmail.com> wrote:
>> When SeaBIOS is being used, U-Boot reserves a memory area to be
>> used for configuration tables like ACPI. But it should not be
>> cleared otherwise ACPI table will be missing.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>
>> ---
>>
>> Changes in v2:
>> - new patch "Do not clear high table area for S3"
>> - drop patch "x86: fsp: Mark the first 64K low memory as reserved"
>> as it causes boot failure on GRUB
>>
>> arch/x86/lib/coreboot_table.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 14/22] x86: Adjust board_final_cleanup() order
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (12 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 13/22] x86: Do not clear high table area for S3 Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 15/22] x86: apci: Change PM1_CNT register access to RMW Bin Meng
` (8 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
Call board_final_cleanup() before write_tables(), so that anything
done in board_final_cleanup() on a normal boot path is also done
on an S3 resume path.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/cpu/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index f86eaa9..c9fc7e4 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -205,6 +205,8 @@ __weak void board_final_cleanup(void)
int last_stage_init(void)
{
+ board_final_cleanup();
+
#if CONFIG_HAVE_ACPI_RESUME
void *wake_vector = acpi_find_wakeup_vector();
@@ -214,8 +216,6 @@ int last_stage_init(void)
write_tables();
- board_final_cleanup();
-
return 0;
}
#endif
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 15/22] x86: apci: Change PM1_CNT register access to RMW
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (13 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 14/22] x86: Adjust board_final_cleanup() order Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 16/22] x86: acpi: Make enter_acpi_mode() public Bin Meng
` (7 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
In enter_acpi_mode() PM1_CNT register is changed to PM1_CNT_SCI_EN
directly without preserving its previous value. Update to change
the register access to read-modify-write (RMW).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/lib/acpi_table.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index f118345..8be8120 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -306,6 +306,8 @@ static void acpi_create_mcfg(struct acpi_mcfg *mcfg)
static void enter_acpi_mode(int pm1_cnt)
{
+ u16 val = inw(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
@@ -320,7 +322,7 @@ static void enter_acpi_mode(int pm1_cnt)
* system, and expose ourselves to OSPM as working under ACPI mode
* already, turn this bit on.
*/
- outw(PM1_CNT_SCI_EN, pm1_cnt);
+ outw(val | PM1_CNT_SCI_EN, pm1_cnt);
}
/*
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 16/22] x86: acpi: Make enter_acpi_mode() public
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (14 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 15/22] x86: apci: Change PM1_CNT register access to RMW Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 17/22] x86: acpi: Refactor acpi_resume() Bin Meng
` (6 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
enter_acpi_mode() is useful on other boot path like S3 resume, so
make it public.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- add a function comment block for enter_acpi_mode()
arch/x86/include/asm/acpi_table.h | 9 +++++++++
arch/x86/lib/acpi_table.c | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/acpi_table.h b/arch/x86/include/asm/acpi_table.h
index 20b906c..e96409b 100644
--- a/arch/x86/include/asm/acpi_table.h
+++ b/arch/x86/include/asm/acpi_table.h
@@ -316,6 +316,15 @@ int acpi_create_madt_lapic_nmi(struct acpi_madt_lapic_nmi *lapic_nmi,
u8 cpu, u16 flags, u8 lint);
u32 acpi_fill_madt(u32 current);
void acpi_create_gnvs(struct acpi_global_nvs *gnvs);
+/**
+ * enter_acpi_mode() - enter into ACPI mode
+ *
+ * This programs the ACPI-defined PM1_CNT register to enable SCI interrupt
+ * so that the whole system swiches to ACPI mode.
+ *
+ * @pm1_cnt: PM1_CNT register I/O address
+ */
+void enter_acpi_mode(int pm1_cnt);
ulong write_acpi_tables(ulong start);
/**
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 8be8120..87a71ca 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -304,7 +304,7 @@ 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)
+void enter_acpi_mode(int pm1_cnt)
{
u16 val = inw(pm1_cnt);
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 16/22] x86: acpi: Make enter_acpi_mode() public
2017-04-21 14:24 ` [U-Boot] [PATCH v2 16/22] x86: acpi: Make enter_acpi_mode() public Bin Meng
@ 2017-04-26 7:35 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:35 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> enter_acpi_mode() is useful on other boot path like S3 resume, so
> make it public.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - add a function comment block for enter_acpi_mode()
>
> arch/x86/include/asm/acpi_table.h | 9 +++++++++
> arch/x86/lib/acpi_table.c | 2 +-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 17/22] x86: acpi: Refactor acpi_resume()
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (15 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 16/22] x86: acpi: Make enter_acpi_mode() public Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 18/22] x86: acpi: Turn on ACPI mode for S3 Bin Meng
` (5 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
To do something more in acpi_resume() like turning on ACPI mode,
we need locate ACPI FADT table pointer first. But currently this
is done in acpi_find_wakeup_vector().
This changes acpi_resume() signature to accept ACPI FADT pointer
as the parameter. A new API acpi_find_fadt() is introduced, and
acpi_find_wakeup_vector() is updated to use FADT pointer as the
parameter as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- add a function comment block for acpi_find_fadt()
arch/x86/cpu/cpu.c | 6 +++---
arch/x86/include/asm/acpi_s3.h | 5 +++--
arch/x86/include/asm/acpi_table.h | 11 ++++++++++-
arch/x86/lib/acpi_s3.c | 7 ++++++-
arch/x86/lib/acpi_table.c | 16 +++++++++++-----
5 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index c9fc7e4..dfe624f 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -208,10 +208,10 @@ int last_stage_init(void)
board_final_cleanup();
#if CONFIG_HAVE_ACPI_RESUME
- void *wake_vector = acpi_find_wakeup_vector();
+ struct acpi_fadt *fadt = acpi_find_fadt();
- if (wake_vector != NULL && gd->arch.prev_sleep_state == ACPI_S3)
- acpi_resume(wake_vector);
+ if (fadt != NULL && gd->arch.prev_sleep_state == ACPI_S3)
+ acpi_resume(fadt);
#endif
write_tables();
diff --git a/arch/x86/include/asm/acpi_s3.h b/arch/x86/include/asm/acpi_s3.h
index b8d14f4..1ad20f4 100644
--- a/arch/x86/include/asm/acpi_s3.h
+++ b/arch/x86/include/asm/acpi_s3.h
@@ -99,15 +99,16 @@ enum acpi_sleep_state chipset_prev_sleep_state(void);
*/
void chipset_clear_sleep_state(void);
+struct acpi_fadt;
/**
* acpi_resume() - Do ACPI S3 resume
*
* This calls U-Boot wake up assembly stub and jumps to OS's wake up vector.
*
- * @wake_vec: OS wake up vector
+ * @fadt: FADT table pointer in the ACPI table
* @return: Never returns
*/
-void acpi_resume(void *wake_vec);
+void acpi_resume(struct acpi_fadt *fadt);
#endif /* __ASSEMBLY__ */
diff --git a/arch/x86/include/asm/acpi_table.h b/arch/x86/include/asm/acpi_table.h
index e96409b..dd7a946 100644
--- a/arch/x86/include/asm/acpi_table.h
+++ b/arch/x86/include/asm/acpi_table.h
@@ -328,6 +328,15 @@ void enter_acpi_mode(int pm1_cnt);
ulong write_acpi_tables(ulong start);
/**
+ * acpi_find_fadt() - find ACPI FADT table in the sytem memory
+ *
+ * This routine parses the ACPI table to locate the ACPI FADT table.
+ *
+ * @return: a pointer to the ACPI FADT table in the system memory
+ */
+struct acpi_fadt *acpi_find_fadt(void);
+
+/**
* acpi_find_wakeup_vector() - find OS installed wake up vector address
*
* This routine parses the ACPI table to locate the wake up vector installed
@@ -335,4 +344,4 @@ ulong write_acpi_tables(ulong start);
*
* @return: wake up vector address installed by the OS
*/
-void *acpi_find_wakeup_vector(void);
+void *acpi_find_wakeup_vector(struct acpi_fadt *);
diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
index f679c06..e5cc3b0 100644
--- a/arch/x86/lib/acpi_s3.c
+++ b/arch/x86/lib/acpi_s3.c
@@ -6,6 +6,7 @@
#include <common.h>
#include <asm/acpi_s3.h>
+#include <asm/acpi_table.h>
#include <asm/post.h>
static void asmlinkage (*acpi_do_wakeup)(void *vector) = (void *)WAKEUP_BASE;
@@ -19,8 +20,12 @@ static void acpi_jump_to_wakeup(void *vector)
acpi_do_wakeup(vector);
}
-void acpi_resume(void *wake_vec)
+void acpi_resume(struct acpi_fadt *fadt)
{
+ void *wake_vec;
+
+ wake_vec = acpi_find_wakeup_vector(fadt);
+
post_code(POST_OS_RESUME);
acpi_jump_to_wakeup(wake_vec);
}
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 87a71ca..01d5b6f 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -460,18 +460,14 @@ static struct acpi_rsdp *acpi_valid_rsdp(struct acpi_rsdp *rsdp)
return rsdp;
}
-void *acpi_find_wakeup_vector(void)
+struct acpi_fadt *acpi_find_fadt(void)
{
char *p, *end;
struct acpi_rsdp *rsdp = NULL;
struct acpi_rsdt *rsdt;
struct acpi_fadt *fadt = NULL;
- struct acpi_facs *facs;
- void *wake_vec;
int i;
- debug("Trying to find the wakeup vector...\n");
-
/* Find RSDP */
for (p = (char *)ROM_TABLE_ADDR; p < (char *)ROM_TABLE_END; p += 16) {
rsdp = acpi_valid_rsdp((struct acpi_rsdp *)p);
@@ -499,6 +495,16 @@ void *acpi_find_wakeup_vector(void)
return NULL;
debug("FADT found@%p\n", fadt);
+ return fadt;
+}
+
+void *acpi_find_wakeup_vector(struct acpi_fadt *fadt)
+{
+ struct acpi_facs *facs;
+ void *wake_vec;
+
+ debug("Trying to find the wakeup vector...\n");
+
facs = (struct acpi_facs *)fadt->firmware_ctrl;
if (facs == NULL) {
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 17/22] x86: acpi: Refactor acpi_resume()
2017-04-21 14:24 ` [U-Boot] [PATCH v2 17/22] x86: acpi: Refactor acpi_resume() Bin Meng
@ 2017-04-26 7:35 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:35 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> To do something more in acpi_resume() like turning on ACPI mode,
> we need locate ACPI FADT table pointer first. But currently this
> is done in acpi_find_wakeup_vector().
>
> This changes acpi_resume() signature to accept ACPI FADT pointer
> as the parameter. A new API acpi_find_fadt() is introduced, and
> acpi_find_wakeup_vector() is updated to use FADT pointer as the
> parameter as well.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - add a function comment block for acpi_find_fadt()
>
> arch/x86/cpu/cpu.c | 6 +++---
> arch/x86/include/asm/acpi_s3.h | 5 +++--
> arch/x86/include/asm/acpi_table.h | 11 ++++++++++-
> arch/x86/lib/acpi_s3.c | 7 ++++++-
> arch/x86/lib/acpi_table.c | 16 +++++++++++-----
> 5 files changed, 33 insertions(+), 12 deletions(-)
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 18/22] x86: acpi: Turn on ACPI mode for S3
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (16 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 17/22] x86: acpi: Refactor acpi_resume() Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 19/22] x86: pci: Allow conditionally run VGA rom in S3 Bin Meng
` (4 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
Before jumping to OS waking up vector, we need turn on ACPI mode
for S3, just like what we do for a normal boot.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/lib/acpi_s3.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
index e5cc3b0..0b62b75 100644
--- a/arch/x86/lib/acpi_s3.c
+++ b/arch/x86/lib/acpi_s3.c
@@ -24,6 +24,9 @@ void acpi_resume(struct acpi_fadt *fadt)
{
void *wake_vec;
+ /* Turn on ACPI mode for S3 */
+ enter_acpi_mode(fadt->pm1a_cnt_blk);
+
wake_vec = acpi_find_wakeup_vector(fadt);
post_code(POST_OS_RESUME);
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 19/22] x86: pci: Allow conditionally run VGA rom in S3
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (17 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 18/22] x86: acpi: Turn on ACPI mode for S3 Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-24 3:38 ` Simon Glass
2017-04-21 14:24 ` [U-Boot] [PATCH v2 20/22] x86: acpi: Fix Windows S3 resume failure Bin Meng
` (3 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can
bypass executing VGA roms in S3.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2: None
arch/x86/Kconfig | 12 ++++++++++++
drivers/pci/pci_rom.c | 14 ++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5322eff..0cd981e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -601,6 +601,18 @@ config HAVE_ACPI_RESUME
is done, U-Boot needs to find out the wakeup vector provided by OSes
and jump there.
+config S3_VGA_ROM_RUN
+ bool "Re-run VGA option ROMs on S3 resume"
+ depends on HAVE_ACPI_RESUME
+ default y if HAVE_ACPI_RESUME
+ help
+ Execute VGA option ROMs in U-Boot when resuming from S3. Normally
+ this is needed when graphics console is being used in the kernel.
+
+ Turning it off can reduce some resume time, but be aware that your
+ graphics console won't work without VGA options ROMs. Set it to N
+ if your kernel is only on a serial console.
+
config STACK_SIZE
hex
depends on HAVE_ACPI_RESUME
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 57204c4..75fb093 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -35,8 +35,22 @@
#include <video_fb.h>
#include <linux/screen_info.h>
+#ifdef CONFIG_X86
+#include <asm/acpi_s3.h>
+DECLARE_GLOBAL_DATA_PTR;
+#endif
+
__weak bool board_should_run_oprom(struct udevice *dev)
{
+#if defined(CONFIG_X86) && defined(CONFIG_HAVE_ACPI_RESUME)
+ if (gd->arch.prev_sleep_state == ACPI_S3) {
+ if (IS_ENABLED(CONFIG_S3_VGA_ROM_RUN))
+ return true;
+ else
+ return false;
+ }
+#endif
+
return true;
}
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 19/22] x86: pci: Allow conditionally run VGA rom in S3
2017-04-21 14:24 ` [U-Boot] [PATCH v2 19/22] x86: pci: Allow conditionally run VGA rom in S3 Bin Meng
@ 2017-04-24 3:38 ` Simon Glass
2017-04-26 7:35 ` Bin Meng
0 siblings, 1 reply; 58+ messages in thread
From: Simon Glass @ 2017-04-24 3:38 UTC (permalink / raw)
To: u-boot
On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@gmail.com> wrote:
> Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can
> bypass executing VGA roms in S3.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> Changes in v2: None
>
> arch/x86/Kconfig | 12 ++++++++++++
> drivers/pci/pci_rom.c | 14 ++++++++++++++
> 2 files changed, 26 insertions(+)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 19/22] x86: pci: Allow conditionally run VGA rom in S3
2017-04-24 3:38 ` Simon Glass
@ 2017-04-26 7:35 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:35 UTC (permalink / raw)
To: u-boot
On Mon, Apr 24, 2017 at 11:38 AM, Simon Glass <sjg@chromium.org> wrote:
> On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can
>> bypass executing VGA roms in S3.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>> Changes in v2: None
>>
>> arch/x86/Kconfig | 12 ++++++++++++
>> drivers/pci/pci_rom.c | 14 ++++++++++++++
>> 2 files changed, 26 insertions(+)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 20/22] x86: acpi: Fix Windows S3 resume failure
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (18 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 19/22] x86: pci: Allow conditionally run VGA rom in S3 Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-24 3:38 ` Simon Glass
2017-04-21 14:24 ` [U-Boot] [PATCH v2 21/22] x86: minnowmax: Enable ACPI S3 resume Bin Meng
` (2 subsequent siblings)
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
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.cn@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(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index dfe624f..e13786e 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -278,13 +278,17 @@ int reserve_arch(void)
high_table_reserve();
#endif
-#if defined(CONFIG_HAVE_ACPI_RESUME) && defined(CONFIG_HAVE_FSP)
+#ifdef CONFIG_HAVE_ACPI_RESUME
+ acpi_s3_reserve();
+
+#ifdef CONFIG_HAVE_FSP
/*
* Save stack address to CMOS so that at next S3 boot,
* we can use it as the stack address for fsp_contiue()
*/
fsp_save_s3_stack();
-#endif
+#endif /* CONFIG_HAVE_FSP */
+#endif /* CONFIG_HAVE_ACPI_RESUME */
return 0;
}
diff --git a/arch/x86/include/asm/acpi_s3.h b/arch/x86/include/asm/acpi_s3.h
index 1ad20f4..86aec0a 100644
--- a/arch/x86/include/asm/acpi_s3.h
+++ b/arch/x86/include/asm/acpi_s3.h
@@ -29,6 +29,9 @@
#define SLP_TYP_S4 6
#define SLP_TYP_S5 7
+/* Memory size reserved for S3 resume */
+#define S3_RESERVE_SIZE 0x1000
+
#ifndef __ASSEMBLY__
extern char __wakeup[];
@@ -110,6 +113,19 @@ struct acpi_fadt;
*/
void acpi_resume(struct acpi_fadt *fadt);
+/**
+ * acpi_s3_reserve() - Reserve memory for ACPI S3 resume
+ *
+ * This copies memory where real mode interrupt handler stubs reside to the
+ * reserved place on the stack.
+ *
+ * This routine should be called by reserve_arch() before U-Boot is relocated
+ * when ACPI S3 resume is enabled.
+ *
+ * @return: 0 always
+ */
+int acpi_s3_reserve(void);
+
#endif /* __ASSEMBLY__ */
#endif /* __ASM_ACPI_S3_H__ */
diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
index b4ca473..93a80fe 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -101,6 +101,7 @@ struct arch_global_data {
#endif
#ifdef CONFIG_HAVE_ACPI_RESUME
int prev_sleep_state; /* Previous sleep state ACPI_S0/1../5 */
+ ulong backup_mem; /* Backup memory address for S3 */
#endif
};
diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
index 0b62b75..3175da8 100644
--- a/arch/x86/lib/acpi_s3.c
+++ b/arch/x86/lib/acpi_s3.c
@@ -9,6 +9,8 @@
#include <asm/acpi_table.h>
#include <asm/post.h>
+DECLARE_GLOBAL_DATA_PTR;
+
static void asmlinkage (*acpi_do_wakeup)(void *vector) = (void *)WAKEUP_BASE;
static void acpi_jump_to_wakeup(void *vector)
@@ -29,6 +31,52 @@ void acpi_resume(struct acpi_fadt *fadt)
wake_vec = acpi_find_wakeup_vector(fadt);
+ /*
+ * Restore the memory content starting from address 0x1000 which is
+ * used for the real mode interrupt handler stubs.
+ */
+ memcpy((void *)0x1000, (const void *)gd->arch.backup_mem,
+ S3_RESERVE_SIZE);
+
post_code(POST_OS_RESUME);
acpi_jump_to_wakeup(wake_vec);
}
+
+int acpi_s3_reserve(void)
+{
+ /* adjust stack pointer for ACPI S3 resume backup memory */
+ gd->start_addr_sp -= S3_RESERVE_SIZE;
+ gd->arch.backup_mem = gd->start_addr_sp;
+
+ gd->start_addr_sp &= ~0xf;
+
+ /*
+ * 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 (see acpi_resume() above).
+ */
+ if (gd->arch.prev_sleep_state == ACPI_S3)
+ memcpy((void *)gd->arch.backup_mem, (const void *)0x1000,
+ S3_RESERVE_SIZE);
+
+ return 0;
+}
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 20/22] x86: acpi: Fix Windows S3 resume failure
2017-04-21 14:24 ` [U-Boot] [PATCH v2 20/22] x86: acpi: Fix Windows S3 resume failure Bin Meng
@ 2017-04-24 3:38 ` Simon Glass
2017-04-25 1:51 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
0 siblings, 2 replies; 58+ messages in thread
From: Simon Glass @ 2017-04-24 3:38 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@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.cn@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 <sjg@chromium.org>
But can you use a #define for the 0x1000 address?
Regards,
Simon
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 20/22] x86: acpi: Fix Windows S3 resume failure
2017-04-24 3:38 ` Simon Glass
@ 2017-04-25 1:51 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
1 sibling, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-25 1:51 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Apr 24, 2017 at 11:38 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@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.cn@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 <sjg@chromium.org>
>
> But can you use a #define for the 0x1000 address?
>
Will prepare another patch to change this globally.
Regards,
Bin
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 20/22] x86: acpi: Fix Windows S3 resume failure
2017-04-24 3:38 ` Simon Glass
2017-04-25 1:51 ` Bin Meng
@ 2017-04-26 7:35 ` Bin Meng
1 sibling, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:35 UTC (permalink / raw)
To: u-boot
On Mon, Apr 24, 2017 at 11:38 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 21 April 2017 at 08:24, Bin Meng <bmeng.cn@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.cn@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 <sjg@chromium.org>
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 21/22] x86: minnowmax: Enable ACPI S3 resume
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (19 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 20/22] x86: acpi: Fix Windows S3 resume failure Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
2017-04-21 14:24 ` [U-Boot] [PATCH v2 22/22] x86: Document ACPI S3 support Bin Meng
2017-04-24 9:28 ` [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Stefan Roese
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
This turns on ACPI S3 resume for minnowmax board.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
configs/minnowmax_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig
index 8dac1d7..aa50e88 100644
--- a/configs/minnowmax_defconfig
+++ b/configs/minnowmax_defconfig
@@ -10,6 +10,7 @@ CONFIG_HAVE_VGA_BIOS=y
CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_GENERATE_ACPI_TABLE=y
+CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 22/22] x86: Document ACPI S3 support
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (20 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 21/22] x86: minnowmax: Enable ACPI S3 resume Bin Meng
@ 2017-04-21 14:24 ` Bin Meng
2017-04-26 7:35 ` Bin Meng
2017-04-24 9:28 ` [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Stefan Roese
22 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-21 14:24 UTC (permalink / raw)
To: u-boot
Now that we have ACPI S3 support on Intel MinnowMax board, document
some generic information of S3 and how to test it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- add some notes about testing S3 resume on Windows
- rebase on u-boot/master
doc/README.x86 | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86
index a38cc1b..c69dc1c 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -1014,12 +1014,12 @@ compile ACPI DSDT table written in ASL format to AML format. You can get
the compiler via "apt-get install iasl" if you are on Ubuntu or download
the source from [17] to compile one by yourself.
-Current ACPI support in U-Boot is not complete. More features will be added
-in the future. The status as of today is:
+Current ACPI support in U-Boot is basically complete. More optional features
+can be added in the future. The status as of today is:
* Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables.
* Support one static DSDT table only, compiled by Intel ACPI compiler.
- * Support S0/S5, reboot and shutdown from OS.
+ * Support S0/S3/S4/S5, reboot and shutdown from OS.
* Support booting a pre-installed Ubuntu distribution via 'zboot' command.
* Support installing and booting Ubuntu 14.04 (or above) from U-Boot with
the help of SeaBIOS using legacy interface (non-UEFI mode).
@@ -1027,9 +1027,6 @@ in the future. The status as of today is:
of SeaBIOS using legacy interface (non-UEFI mode).
* Support ACPI interrupts with SCI only.
-Features not supported so far (to make it a complete ACPI solution):
- * S3 (Suspend to RAM), S4 (Suspend to Disk).
-
Features that are optional:
* Dynamic AML bytecodes insertion at run-time. We may need this to support
SSDT table generation and DSDT fix up.
@@ -1046,6 +1043,21 @@ command from the OS.
For other platform boards, ACPI support status can be checked by examining their
board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y.
+The S3 sleeping state is a low wake latency sleeping state defined by ACPI
+spec where all system context is lost except system memory. To test S3 resume
+with a Linux kernel, simply run "echo mem > /sys/power/state" and kernel will
+put the board to S3 state where the power is off. So when the power button is
+pressed again, U-Boot runs as it does in cold boot and detects the sleeping
+state via ACPI register to see if it is S3, if yes it means we are waking up.
+U-Boot is responsible for restoring the machine state as it is before sleep.
+When everything is done, U-Boot finds out the wakeup vector provided by OSes
+and jump there. To determine whether ACPI S3 resume is supported, check to
+see if CONFIG_HAVE_ACPI_RESUME is set for that specific board.
+
+Note for testing S3 resume with Windows, correct graphics driver must be
+installed for your platform, otherwise you won't find "Sleep" option in
+the "Power" submenu from the Windows start menu.
+
EFI Support
-----------
U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
--
2.9.2
^ permalink raw reply related [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 22/22] x86: Document ACPI S3 support
2017-04-21 14:24 ` [U-Boot] [PATCH v2 22/22] x86: Document ACPI S3 support Bin Meng
@ 2017-04-26 7:35 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:35 UTC (permalink / raw)
To: u-boot
On Fri, Apr 21, 2017 at 10:24 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Now that we have ACPI S3 support on Intel MinnowMax board, document
> some generic information of S3 and how to test it.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - add some notes about testing S3 resume on Windows
> - rebase on u-boot/master
>
> doc/README.x86 | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support
2017-04-21 14:24 [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Bin Meng
` (21 preceding siblings ...)
2017-04-21 14:24 ` [U-Boot] [PATCH v2 22/22] x86: Document ACPI S3 support Bin Meng
@ 2017-04-24 9:28 ` Stefan Roese
2017-04-25 8:02 ` Bin Meng
22 siblings, 1 reply; 58+ messages in thread
From: Stefan Roese @ 2017-04-24 9:28 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 21.04.2017 16:24, Bin Meng wrote:
> This adds ACPI S3 (suspend to ram) resume capability in U-Boot.
> With S3 support within U-Boot, the board wakes up and resumes to
> OS very quickly.
>
> This so far is enabled and tested on Intel MinnowMax board. Please
> check README.x86 for how to test it with a plain Linux kernel.
> Linux (w/ or w/o SeaBIOS) and Windows 10 (w/ SeaBIOS) were tested.
>
> This series is available for testing at u-boot-x86/s3-working.
Thank you very much for working on this. I've started testing this
patchset on my congatec BayTrail SoM based board. Booting into
a v4.11-rc based kernel with serial console works just fine.
Suspend and resume work nicely and fast! :)
Booting Ubuntu 16.04 (kernel 4.4) with graphical interface seems to
have some (rare) problems though. When I boot into Ubuntu with the
correct "console=" configuration (log via serial console), suspend
/ resume seems to work fine as well - at least in the tests I did
so far. But when I don't provide this "console=" and use "quiet"
instead, resume does not seem to work reliably. Most of the times it
works just fine as well, but sometimes the graphical user interface
doesn't come up at all after resuming (display stays in power safe
mode). The U-Boot log is the same in both cases:
Jumping to OS waking vector 0009a1d0
And the POST debug byte is also identical (0x40).
Do you have any ideas, where this might come from? Could you
perhaps check this on MinnoxMax as well, if such a setup also
sometimes has problems with resuming? Is there anything that I could
do to test this on my platform?
Thanks,
Stefan
^ permalink raw reply [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support
2017-04-24 9:28 ` [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support Stefan Roese
@ 2017-04-25 8:02 ` Bin Meng
2017-04-25 8:51 ` Stefan Roese
0 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-25 8:02 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On Mon, Apr 24, 2017 at 5:28 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Bin,
>
> On 21.04.2017 16:24, Bin Meng wrote:
>>
>> This adds ACPI S3 (suspend to ram) resume capability in U-Boot.
>> With S3 support within U-Boot, the board wakes up and resumes to
>> OS very quickly.
>>
>> This so far is enabled and tested on Intel MinnowMax board. Please
>> check README.x86 for how to test it with a plain Linux kernel.
>> Linux (w/ or w/o SeaBIOS) and Windows 10 (w/ SeaBIOS) were tested.
>>
>> This series is available for testing at u-boot-x86/s3-working.
>
>
> Thank you very much for working on this. I've started testing this
> patchset on my congatec BayTrail SoM based board. Booting into
> a v4.11-rc based kernel with serial console works just fine.
> Suspend and resume work nicely and fast! :)
>
Thanks for testing!
> Booting Ubuntu 16.04 (kernel 4.4) with graphical interface seems to
> have some (rare) problems though. When I boot into Ubuntu with the
> correct "console=" configuration (log via serial console), suspend
> / resume seems to work fine as well - at least in the tests I did
> so far. But when I don't provide this "console=" and use "quiet"
> instead, resume does not seem to work reliably. Most of the times it
> works just fine as well, but sometimes the graphical user interface
> doesn't come up at all after resuming (display stays in power safe
> mode). The U-Boot log is the same in both cases:
>
I only have a pre-installed Ubuntu 14.04 hard disk which was installed
from U-Boot and SeaBIOS at the time when ACPI/SeaBIOS support was
added to U-Boot long time ago. So suspend/resume does not work with my
installation since I believe Ubuntu has lots of custom scripts for
helping suspend/resume. I've run the testing on this installation
though, and U-Boot did not even boot after I pressed the power button
which means my Ubuntu 14.04 might not even put the system into the
correct ACPI sleeping state. So I have to reinstall a new one.
So how about your Ubuntu 16.04 installation? Was it installed from
U-Boot? Or from original commercial BIOS? What do you mean by "display
stays in power safe mode"? Is it a black screen, or is it just
U-Boot's video output screen?
> Jumping to OS waking vector 0009a1d0
>
> And the POST debug byte is also identical (0x40).
>
These logs looks good. Nothing strange.
> Do you have any ideas, where this might come from? Could you
> perhaps check this on MinnoxMax as well, if such a setup also
> sometimes has problems with resuming? Is there anything that I could
> do to test this on my platform?
>
To match your env, I will install a 16.04 from U-Boot for testing. Can
you add the following kernel parameters for testing suspend/resume?
"console=ttyS0,115200 initcall_debug ignore_loglevel no_console_suspend"
Regards,
Bin
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support
2017-04-25 8:02 ` Bin Meng
@ 2017-04-25 8:51 ` Stefan Roese
2017-04-25 9:34 ` Bin Meng
0 siblings, 1 reply; 58+ messages in thread
From: Stefan Roese @ 2017-04-25 8:51 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 25.04.2017 10:02, Bin Meng wrote:
<snip>
>> Booting Ubuntu 16.04 (kernel 4.4) with graphical interface seems to
>> have some (rare) problems though. When I boot into Ubuntu with the
>> correct "console=" configuration (log via serial console), suspend
>> / resume seems to work fine as well - at least in the tests I did
>> so far. But when I don't provide this "console=" and use "quiet"
>> instead, resume does not seem to work reliably. Most of the times it
>> works just fine as well, but sometimes the graphical user interface
>> doesn't come up at all after resuming (display stays in power safe
>> mode). The U-Boot log is the same in both cases:
>>
>
> I only have a pre-installed Ubuntu 14.04 hard disk which was installed
> from U-Boot and SeaBIOS at the time when ACPI/SeaBIOS support was
> added to U-Boot long time ago. So suspend/resume does not work with my
> installation since I believe Ubuntu has lots of custom scripts for
> helping suspend/resume. I've run the testing on this installation
> though, and U-Boot did not even boot after I pressed the power button
> which means my Ubuntu 14.04 might not even put the system into the
> correct ACPI sleeping state. So I have to reinstall a new one.
>
> So how about your Ubuntu 16.04 installation? Was it installed from
> U-Boot? Or from original commercial BIOS?
Installed via original congatec BIOS.
> What do you mean by "display
> stays in power safe mode"? Is it a black screen, or is it just
> U-Boot's video output screen?
Blank screen and the monitor does not wake up from power-safe
mode. I see the log on the serial console, since I've changed the
environment (stdio) to not use the LCD as the console in U-Boot.
U-Boot uses the console as a splash screen instead.
>> Jumping to OS waking vector 0009a1d0
>>
>> And the POST debug byte is also identical (0x40).
>>
>
> These logs looks good. Nothing strange.
>
>> Do you have any ideas, where this might come from? Could you
>> perhaps check this on MinnoxMax as well, if such a setup also
>> sometimes has problems with resuming? Is there anything that I could
>> do to test this on my platform?
>>
>
> To match your env, I will install a 16.04 from U-Boot for testing. Can
> you add the following kernel parameters for testing suspend/resume?
>
> "console=ttyS0,115200 initcall_debug ignore_loglevel no_console_suspend"
Ah, this brings some infos. Here the resume log:
[ 49.810439] smpboot: CPU 3 is now offline
[ 49.828153] PM: Calling kvm_suspend+0x0/0x30 [kvm]
[ 49.833517] PM: Calling mce_syscore_suspend+0x0/0x20
[ 49.839072] PM: Calling ledtrig_cpu_syscore_suspend+0x0/0x20
[ 49.845404] PM: Calling acpi_processor_suspend+0x0/0x1e
[ 49.851255] PM: Calling timekeeping_suspend+0x0/0x2a0
[ 49.856925] PM: Calling irq_gc_suspend+0x0/0x70
[ 49.861992] PM: Calling save_ioapic_entries+0x0/0x90
[ 49.867738] PM: Calling i8259A_suspend+0x0/0x30
[ 49.872806] PM: Calling fw_suspend+0x0/0x20
[ 49.877484] PM: Calling lapic_suspend+0x0/0x1b0
��
U-Boot 2017.05-rc2-00122-gf6a9c0b4fd-dirty (Apr 24 2017 - 10:50:06 +0200)
CPU: x86_64, vendor Intel, device 30679h
DRAM: 4 GiB
MMC: ValleyView SDHCI: 0, ValleyView SDHCI: 1, ValleyView SDHCI: 2
SF: Detected w25q64cv with page size 256 Bytes, erase size 4 KiB, total 8 MiB
Model: congatec-QEVAL20-QA3-E3845
SCSI: SATA link 0 timeout.
Target spinup took 0 ms.
AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: 64bit ncq stag pm led clo pio slum part sxs
scanning bus for devices...
Device 0: (1:0) Vendor: ATA Prod.: SanDisk Ultra II Rev: X411
Type: Hard Disk
Capacity: 457862.8 MB = 447.1 GB (937703088 x 512)
Found 1 device(s).
Net: e1000: 00:13:95:1c:51:e8
eth0: e1000#0
Jumping to OS waking vector 0009a1d0
[ 49.882704] ACPI: Low-level resume complete
[ 49.887483] PM: Restoring platform NVS memory
[ 49.892361] PM: Calling bsp_resume+0x0/0x20
[ 49.897040] PM: Calling lapic_resume+0x0/0x2b0
[ 49.902035] PM: Calling irqrouter_resume+0x0/0x3f
[ 49.907297] PM: Calling i8259A_resume+0x0/0x30
[ 49.912393] PM: Calling i8237A_resume+0x0/0x90
[ 49.917434] PM: Calling ioapic_resume+0x0/0xa0
[ 49.922495] PM: Calling irq_gc_resume+0x0/0x60
[ 49.927464] PM: Calling irq_pm_syscore_resume+0x0/0x20
[ 49.933256] PM: Calling timekeeping_resume+0x0/0x200
[ 49.938844] PM: Calling acpi_processor_resume+0x0/0x5c
[ 49.944595] PM: Calling ledtrig_cpu_syscore_resume+0x0/0x20
[ 49.950829] PM: Calling mce_syscore_resume+0x0/0x30
[ 49.956291] PM: Calling mc_bp_resume+0x0/0x50
[ 49.961193] PM: Calling kvm_resume+0x0/0x40 [kvm]
[ 49.966523] Enabling non-boot CPUs ...
[ 49.990192] x86: Booting SMP configuration:
[ 49.994894] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 50.011048] cache: parent cpu1 should not be sleeping
[ 50.017239] CPU1 is up
[ 50.038380] smpboot: Booting Node 0 Processor 2 APIC 0x4
[ 50.054552] cache: parent cpu2 should not be sleeping
[ 50.060685] CPU2 is up
[ 50.082550] smpboot: Booting Node 0 Processor 3 APIC 0x6
[ 50.098820] cache: parent cpu3 should not be sleeping
[ 50.104972] CPU3 is up
[ 50.108534] ACPI: Waking up from system sleep state S3
[ 50.114576] calling 0000:00:00.0+ @ 2269, parent: pci0000:00
[ 50.114630] calling 0000:00:02.0+ @ 163, parent: pci0000:00
[ 50.114728] calling 0000:00:11.0+ @ 2265, parent: pci0000:00
[ 50.114759] calling 0000:00:12.0+ @ 2268, parent: pci0000:00
[ 50.114800] calling 0000:00:13.0+ @ 159, parent: pci0000:00
[ 50.114830] calling 0000:00:15.0+ @ 149, parent: pci0000:00
[ 50.114926] call 0000:00:15.0+ returned 0 after 86 usecs
[ 50.114942] calling 0000:00:17.0+ @ 149, parent: pci0000:00
[ 50.114979] calling 0000:00:1c.0+ @ 2267, parent: pci0000:00
[ 50.115003] calling 0000:00:1c.1+ @ 40, parent: pci0000:00
[ 50.115020] calling 0000:00:1c.2+ @ 2266, parent: pci0000:00
[ 50.115261] call 0000:00:1c.0+ returned 0 after 267 usecs
[ 50.115282] calling 0000:00:1c.3+ @ 2267, parent: pci0000:00
[ 50.115289] call 0000:00:1c.1+ returned 0 after 268 usecs
[ 50.115304] calling 0000:00:1d.0+ @ 40, parent: pci0000:00
[ 50.115409] calling 0000:00:1e.0+ @ 6, parent: pci0000:00
[ 50.115446] calling 0000:00:1e.1+ @ 158, parent: pci0000:00
[ 50.115465] call 0000:00:1c.3+ returned 0 after 171 usecs
[ 50.115482] calling 0000:00:1e.2+ @ 2271, parent: pci0000:00
[ 50.115487] calling 0000:00:1e.4+ @ 2267, parent: pci0000:00
[ 50.115689] calling 0000:00:1e.5+ @ 2270, parent: pci0000:00
[ 50.115748] call 0000:00:1e.5+ returned 0 after 51 usecs
[ 50.115759] calling 0000:00:1f.0+ @ 2270, parent: pci0000:00
[ 50.115804] call 0000:00:1f.0+ returned 0 after 38 usecs
[ 50.115813] calling 0000:00:1f.3+ @ 2270, parent: pci0000:00
[ 50.115899] call 0000:00:1f.3+ returned 0 after 77 usecs
[ 50.115907] calling 0000:04:00.0+ @ 2270, parent: 0000:00:1c.3
[ 50.129887] call 0000:00:1e.1+ returned 0 after 14073 usecs
[ 50.129890] call 0000:00:1e.2+ returned 0 after 14040 usecs
[ 50.129959] call 0000:00:1e.0+ returned 0 after 14181 usecs
[ 50.130106] call 0000:04:00.0+ returned 0 after 13839 usecs
[ 50.130142] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 50.130149] call 0000:00:1e.4+ returned 0 after 14290 usecs
[ 50.130151] call 0000:00:1d.0+ returned 0 after 14471 usecs
[ 50.130210] call 0000:00:17.0+ returned 0 after 14882 usecs
[ 50.130256] call 0000:00:13.0+ returned 0 after 15063 usecs
[ 50.130268] call 0000:00:11.0+ returned 0 after 15145 usecs
[ 50.130311] call 0000:00:12.0+ returned 0 after 15158 usecs
[ 50.130327] call 0000:00:02.0+ returned 0 after 15299 usecs
[ 50.359559] call 0000:00:00.0+ returned 0 after 16 usecs
[ 76.935630] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u8:7:2266]
[ 76.944393] Modules linked in: intel_rapl intel_soc_dts_iosf intel_powerclamp spi_pxa2xx_platform kvm_intel kvm irqbypass punit_atom_debug crct10dif_pclmul crc32_pclmul aesni_intel aes_x86_64 joydev input_leds lrw gf128mul glue_helper ablk_helper cryptd lpc_ich serio_raw pwm_lpss_pci spi_pxa2xx_pci pwm_lpss dw_dmac_pci dw_dmac_core shpchp 8250_fintek mac_hid nfsd auth_rpcgss nfs_acl lockd coretemp grace parport_pc ppdev lp parport sunrpc autofs4 hid_cherry usbhid hid mmc_block igb dca ptp i915 video drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci psmouse pps_core drm i2c_algo_bit sdhci_pci libahci sdhci fjes
[ 77.006747] CPU: 0 PID: 2266 Comm: kworker/u8:7 Not tainted 4.4.0-36-generic #55-Ubuntu
[ 77.015702] Hardware name: congatec conga-qeval20-qa3-e3845/conga-qeval20-qa3-e3845, BIOS 2017.05-rc2-00122-gf6a9c0b4fd-dirty 04/24/2017
[ 77.029429] Workqueue: events_unbound async_run_entry_fn
[ 77.035374] task: ffff8800628b0c80 ti: ffff880176dc8000 task.ti: ffff880176dc8000
[ 77.043746] RIP: 0010:[<ffffffff81085ad1>] [<ffffffff81085ad1>] __do_softirq+0x81/0x290
[ 77.052807] RSP: 0018:ffff88017fc03f28 EFLAGS: 00000206
[ 77.058747] RAX: ffff880176dcc000 RBX: 0000000000000000 RCX: 00000000000006e0
[ 77.066730] RDX: 0000000000000000 RSI: 0000000004208060 RDI: 00000000000006e0
[ 77.074704] RBP: ffff88017fc03f80 R08: ffff88017820e400 R09: ffff88017fc16d30
[ 77.082687] R10: 0000000000000020 R11: 0000000000000004 R12: 0000000000000246
[ 77.090669] R13: 00000000000000e2 R14: 000000000000002c R15: 000000000000000c
[ 77.098653] FS: 0000000000000000(0000) GS:ffff88017fc00000(0000) knlGS:0000000000000000
[ 77.107706] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 77.114132] CR2: 00007f7a3c016028 CR3: 0000000176cb5000 CR4: 00000000001006f0
[ 77.122115] Stack:
[ 77.124359] 042080607fc0ede8 ffff880176dcc000 00000000ffff0b90 ffffffff81f361c0
[ 77.132648] ffff88010000000a 000002827fc0d640 0000000000000000 0000000000000246
[ 77.140937] 00000000000000e2 000000000000002c 000000000000000c ffff88017fc03f90
[ 77.149226] Call Trace:
[ 77.151957] <IRQ>
[ 77.154107] [<ffffffff81085e53>] irq_exit+0xa3/0xb0
[ 77.159860] [<ffffffff81830a62>] smp_apic_timer_interrupt+0x42/0x50
[ 77.166969] [<ffffffff8182ed22>] apic_timer_interrupt+0x82/0x90
[ 77.173686] <EOI>
[ 77.175834] [<ffffffff8182da05>] ? _raw_spin_unlock_irqrestore+0x15/0x20
[ 77.183630] [<ffffffff81436269>] pci_bus_write_config_dword.part.7+0x59/0x70
[ 77.191614] [<ffffffff81436299>] pci_bus_write_config_dword+0x19/0x20
[ 77.198919] [<ffffffff8143c335>] pci_restore_config_dword+0x65/0xe0
[ 77.206029] [<ffffffff8143e1a2>] pci_restore_state.part.33+0x222/0x250
[ 77.213429] [<ffffffff8143e1e8>] pci_restore_state+0x18/0x20
[ 77.219858] [<ffffffff8144237f>] pci_pm_resume_noirq+0x2f/0xa0
[ 77.226480] [<ffffffff81442350>] ? pci_add_dynid+0xd0/0xd0
[ 77.232715] [<ffffffff81560ebe>] dpm_run_callback+0x4e/0x140
[ 77.239143] [<ffffffff81561060>] device_resume_noirq+0xb0/0x190
[ 77.245861] [<ffffffff8156115d>] async_resume_noirq+0x1d/0x50
[ 77.252378] [<ffffffff810a3208>] async_run_entry_fn+0x48/0x150
[ 77.259001] [<ffffffff8109a2c5>] process_one_work+0x165/0x480
[ 77.265526] [<ffffffff8109a62b>] worker_thread+0x4b/0x4c0
[ 77.271662] [<ffffffff8109a5e0>] ? process_one_work+0x480/0x480
[ 77.278381] [<ffffffff810a0808>] kthread+0xd8/0xf0
[ 77.283826] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
[ 77.291130] [<ffffffff8182e34f>] ret_from_fork+0x3f/0x70
[ 77.297168] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
[ 77.304460] Code: 00 c7 45 c8 0a 00 00 00 48 89 45 c0 65 48 8b 04 25 04 42 01 00 48 89 45 b0 65 c7 05 76 e6 f8 7e 00 00 00 00 fb 66 0f 1f 44 00 00 <b8> ff ff ff ff 49 c7 c4 c0 90 e0 81 0f bc 45 d4 83 c0 01 89 45
[ 104.983574] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u8:7:2266]
[ 104.992336] Modules linked in: intel_rapl intel_soc_dts_iosf intel_powerclamp spi_pxa2xx_platform kvm_intel kvm irqbypass punit_atom_debug crct10dif_pclmul crc32_pclmul aesni_intel aes_x86_64 joydev input_leds lrw gf128mul glue_helper ablk_helper cryptd lpc_ich serio_raw pwm_lpss_pci spi_pxa2xx_pci pwm_lpss dw_dmac_pci dw_dmac_core shpchp 8250_fintek mac_hid nfsd auth_rpcgss nfs_acl lockd coretemp grace parport_pc ppdev lp parport sunrpc autofs4 hid_cherry usbhid hid mmc_block igb dca ptp i915 video drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci psmouse pps_core drm i2c_algo_bit sdhci_pci libahci sdhci fjes
[ 105.054669] CPU: 0 PID: 2266 Comm: kworker/u8:7 Tainted: G L 4.4.0-36-generic #55-Ubuntu
[ 105.064986] Hardware name: congatec conga-qeval20-qa3-e3845/conga-qeval20-qa3-e3845, BIOS 2017.05-rc2-00122-gf6a9c0b4fd-dirty 04/24/2017
[ 105.078710] Workqueue: events_unbound async_run_entry_fn
[ 105.084655] task: ffff8800628b0c80 ti: ffff880176dc8000 task.ti: ffff880176dc8000
[ 105.093017] RIP: 0010:[<ffffffff81085ad1>] [<ffffffff81085ad1>] __do_softirq+0x81/0x290
[ 105.102075] RSP: 0018:ffff88017fc03f28 EFLAGS: 00000206
[ 105.108015] RAX: ffff880176dcc000 RBX: 0000000000000000 RCX: 00000000000006e0
[ 105.115998] RDX: 0000000000000000 RSI: 0000000004208060 RDI: 00000000000006e0
[ 105.123980] RBP: ffff88017fc03f80 R08: ffff88017820e400 R09: ffff88017fc16d30
[ 105.131963] R10: 0000000000000020 R11: 0000000000000004 R12: 0000000000000246
[ 105.139936] R13: 00000000000000e2 R14: 000000000000002c R15: 000000000000000c
[ 105.147920] FS: 0000000000000000(0000) GS:ffff88017fc00000(0000) knlGS:0000000000000000
[ 105.156963] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 105.163390] CR2: 00007f7a3c016028 CR3: 0000000176cb5000 CR4: 00000000001006f0
[ 105.171372] Stack:
[ 105.173615] 042080607fc0ede8 ffff880176dcc000 00000000ffff0b90 ffffffff81f361c0
[ 105.181905] ffff88010000000a 000002827fc0d640 0000000000000000 0000000000000246
[ 105.190194] 00000000000000e2 000000000000002c 000000000000000c ffff88017fc03f90
[ 105.198483] Call Trace:
[ 105.201212] <IRQ>
[ 105.203360] [<ffffffff81085e53>] irq_exit+0xa3/0xb0
[ 105.209112] [<ffffffff81830a62>] smp_apic_timer_interrupt+0x42/0x50
[ 105.216221] [<ffffffff8182ed22>] apic_timer_interrupt+0x82/0x90
[ 105.222938] <EOI>
[ 105.225086] [<ffffffff8182da05>] ? _raw_spin_unlock_irqrestore+0x15/0x20
[ 105.232870] [<ffffffff81436269>] pci_bus_write_config_dword.part.7+0x59/0x70
[ 105.240854] [<ffffffff81436299>] pci_bus_write_config_dword+0x19/0x20
[ 105.248159] [<ffffffff8143c335>] pci_restore_config_dword+0x65/0xe0
[ 105.255267] [<ffffffff8143e1a2>] pci_restore_state.part.33+0x222/0x250
[ 105.262667] [<ffffffff8143e1e8>] pci_restore_state+0x18/0x20
[ 105.269095] [<ffffffff8144237f>] pci_pm_resume_noirq+0x2f/0xa0
[ 105.275718] [<ffffffff81442350>] ? pci_add_dynid+0xd0/0xd0
[ 105.281951] [<ffffffff81560ebe>] dpm_run_callback+0x4e/0x140
[ 105.288379] [<ffffffff81561060>] device_resume_noirq+0xb0/0x190
[ 105.295099] [<ffffffff8156115d>] async_resume_noirq+0x1d/0x50
[ 105.301624] [<ffffffff810a3208>] async_run_entry_fn+0x48/0x150
[ 105.308247] [<ffffffff8109a2c5>] process_one_work+0x165/0x480
[ 105.314772] [<ffffffff8109a62b>] worker_thread+0x4b/0x4c0
[ 105.320908] [<ffffffff8109a5e0>] ? process_one_work+0x480/0x480
[ 105.327628] [<ffffffff810a0808>] kthread+0xd8/0xf0
[ 105.333083] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
[ 105.340386] [<ffffffff8182e34f>] ret_from_fork+0x3f/0x70
[ 105.346426] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
...
Thanks,
Stefan
^ permalink raw reply [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support
2017-04-25 8:51 ` Stefan Roese
@ 2017-04-25 9:34 ` Bin Meng
2017-04-25 11:11 ` Stefan Roese
0 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-25 9:34 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On Tue, Apr 25, 2017 at 4:51 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Bin,
>
> On 25.04.2017 10:02, Bin Meng wrote:
>
> <snip>
>
>>> Booting Ubuntu 16.04 (kernel 4.4) with graphical interface seems to
>>> have some (rare) problems though. When I boot into Ubuntu with the
>>> correct "console=" configuration (log via serial console), suspend
>>> / resume seems to work fine as well - at least in the tests I did
>>> so far. But when I don't provide this "console=" and use "quiet"
>>> instead, resume does not seem to work reliably. Most of the times it
>>> works just fine as well, but sometimes the graphical user interface
>>> doesn't come up at all after resuming (display stays in power safe
>>> mode). The U-Boot log is the same in both cases:
>>>
>>
>> I only have a pre-installed Ubuntu 14.04 hard disk which was installed
>> from U-Boot and SeaBIOS at the time when ACPI/SeaBIOS support was
>> added to U-Boot long time ago. So suspend/resume does not work with my
>> installation since I believe Ubuntu has lots of custom scripts for
>> helping suspend/resume. I've run the testing on this installation
>> though, and U-Boot did not even boot after I pressed the power button
>> which means my Ubuntu 14.04 might not even put the system into the
>> correct ACPI sleeping state. So I have to reinstall a new one.
>>
>> So how about your Ubuntu 16.04 installation? Was it installed from
>> U-Boot? Or from original commercial BIOS?
>
> Installed via original congatec BIOS.
>
>> What do you mean by "display
>> stays in power safe mode"? Is it a black screen, or is it just
>> U-Boot's video output screen?
>
> Blank screen and the monitor does not wake up from power-safe
> mode. I see the log on the serial console, since I've changed the
> environment (stdio) to not use the LCD as the console in U-Boot.
> U-Boot uses the console as a splash screen instead.
>
Since you were seeing black screen I guess your U-Boot was not running
the VGA BIOS for the Intel Baytrail IGD? The LCD driver is not the
Intel i915 graphics driver?
>>> Jumping to OS waking vector 0009a1d0
>>>
>>> And the POST debug byte is also identical (0x40).
>>>
>>
>> These logs looks good. Nothing strange.
>>
>>> Do you have any ideas, where this might come from? Could you
>>> perhaps check this on MinnoxMax as well, if such a setup also
>>> sometimes has problems with resuming? Is there anything that I could
>>> do to test this on my platform?
>>>
>>
>> To match your env, I will install a 16.04 from U-Boot for testing. Can
>> you add the following kernel parameters for testing suspend/resume?
>>
>> "console=ttyS0,115200 initcall_debug ignore_loglevel no_console_suspend"
>
> Ah, this brings some infos. Here the resume log:
>
> [ 49.810439] smpboot: CPU 3 is now offline
> [ 49.828153] PM: Calling kvm_suspend+0x0/0x30 [kvm]
> [ 49.833517] PM: Calling mce_syscore_suspend+0x0/0x20
> [ 49.839072] PM: Calling ledtrig_cpu_syscore_suspend+0x0/0x20
> [ 49.845404] PM: Calling acpi_processor_suspend+0x0/0x1e
> [ 49.851255] PM: Calling timekeeping_suspend+0x0/0x2a0
> [ 49.856925] PM: Calling irq_gc_suspend+0x0/0x70
> [ 49.861992] PM: Calling save_ioapic_entries+0x0/0x90
> [ 49.867738] PM: Calling i8259A_suspend+0x0/0x30
> [ 49.872806] PM: Calling fw_suspend+0x0/0x20
> [ 49.877484] PM: Calling lapic_suspend+0x0/0x1b0
> ��
>
> U-Boot 2017.05-rc2-00122-gf6a9c0b4fd-dirty (Apr 24 2017 - 10:50:06 +0200)
>
> CPU: x86_64, vendor Intel, device 30679h
> DRAM: 4 GiB
> MMC: ValleyView SDHCI: 0, ValleyView SDHCI: 1, ValleyView SDHCI: 2
> SF: Detected w25q64cv with page size 256 Bytes, erase size 4 KiB, total 8 MiB
> Model: congatec-QEVAL20-QA3-E3845
> SCSI: SATA link 0 timeout.
> Target spinup took 0 ms.
> AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
> flags: 64bit ncq stag pm led clo pio slum part sxs
> scanning bus for devices...
> Device 0: (1:0) Vendor: ATA Prod.: SanDisk Ultra II Rev: X411
> Type: Hard Disk
> Capacity: 457862.8 MB = 447.1 GB (937703088 x 512)
> Found 1 device(s).
> Net: e1000: 00:13:95:1c:51:e8
> eth0: e1000#0
> Jumping to OS waking vector 0009a1d0
> [ 49.882704] ACPI: Low-level resume complete
> [ 49.887483] PM: Restoring platform NVS memory
> [ 49.892361] PM: Calling bsp_resume+0x0/0x20
> [ 49.897040] PM: Calling lapic_resume+0x0/0x2b0
> [ 49.902035] PM: Calling irqrouter_resume+0x0/0x3f
> [ 49.907297] PM: Calling i8259A_resume+0x0/0x30
> [ 49.912393] PM: Calling i8237A_resume+0x0/0x90
> [ 49.917434] PM: Calling ioapic_resume+0x0/0xa0
> [ 49.922495] PM: Calling irq_gc_resume+0x0/0x60
> [ 49.927464] PM: Calling irq_pm_syscore_resume+0x0/0x20
> [ 49.933256] PM: Calling timekeeping_resume+0x0/0x200
> [ 49.938844] PM: Calling acpi_processor_resume+0x0/0x5c
> [ 49.944595] PM: Calling ledtrig_cpu_syscore_resume+0x0/0x20
> [ 49.950829] PM: Calling mce_syscore_resume+0x0/0x30
> [ 49.956291] PM: Calling mc_bp_resume+0x0/0x50
> [ 49.961193] PM: Calling kvm_resume+0x0/0x40 [kvm]
> [ 49.966523] Enabling non-boot CPUs ...
> [ 49.990192] x86: Booting SMP configuration:
> [ 49.994894] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [ 50.011048] cache: parent cpu1 should not be sleeping
> [ 50.017239] CPU1 is up
> [ 50.038380] smpboot: Booting Node 0 Processor 2 APIC 0x4
> [ 50.054552] cache: parent cpu2 should not be sleeping
> [ 50.060685] CPU2 is up
> [ 50.082550] smpboot: Booting Node 0 Processor 3 APIC 0x6
> [ 50.098820] cache: parent cpu3 should not be sleeping
> [ 50.104972] CPU3 is up
> [ 50.108534] ACPI: Waking up from system sleep state S3
> [ 50.114576] calling 0000:00:00.0+ @ 2269, parent: pci0000:00
> [ 50.114630] calling 0000:00:02.0+ @ 163, parent: pci0000:00
> [ 50.114728] calling 0000:00:11.0+ @ 2265, parent: pci0000:00
> [ 50.114759] calling 0000:00:12.0+ @ 2268, parent: pci0000:00
> [ 50.114800] calling 0000:00:13.0+ @ 159, parent: pci0000:00
> [ 50.114830] calling 0000:00:15.0+ @ 149, parent: pci0000:00
> [ 50.114926] call 0000:00:15.0+ returned 0 after 86 usecs
> [ 50.114942] calling 0000:00:17.0+ @ 149, parent: pci0000:00
> [ 50.114979] calling 0000:00:1c.0+ @ 2267, parent: pci0000:00
> [ 50.115003] calling 0000:00:1c.1+ @ 40, parent: pci0000:00
> [ 50.115020] calling 0000:00:1c.2+ @ 2266, parent: pci0000:00
> [ 50.115261] call 0000:00:1c.0+ returned 0 after 267 usecs
> [ 50.115282] calling 0000:00:1c.3+ @ 2267, parent: pci0000:00
> [ 50.115289] call 0000:00:1c.1+ returned 0 after 268 usecs
> [ 50.115304] calling 0000:00:1d.0+ @ 40, parent: pci0000:00
> [ 50.115409] calling 0000:00:1e.0+ @ 6, parent: pci0000:00
> [ 50.115446] calling 0000:00:1e.1+ @ 158, parent: pci0000:00
> [ 50.115465] call 0000:00:1c.3+ returned 0 after 171 usecs
> [ 50.115482] calling 0000:00:1e.2+ @ 2271, parent: pci0000:00
> [ 50.115487] calling 0000:00:1e.4+ @ 2267, parent: pci0000:00
> [ 50.115689] calling 0000:00:1e.5+ @ 2270, parent: pci0000:00
> [ 50.115748] call 0000:00:1e.5+ returned 0 after 51 usecs
> [ 50.115759] calling 0000:00:1f.0+ @ 2270, parent: pci0000:00
> [ 50.115804] call 0000:00:1f.0+ returned 0 after 38 usecs
> [ 50.115813] calling 0000:00:1f.3+ @ 2270, parent: pci0000:00
> [ 50.115899] call 0000:00:1f.3+ returned 0 after 77 usecs
> [ 50.115907] calling 0000:04:00.0+ @ 2270, parent: 0000:00:1c.3
> [ 50.129887] call 0000:00:1e.1+ returned 0 after 14073 usecs
> [ 50.129890] call 0000:00:1e.2+ returned 0 after 14040 usecs
> [ 50.129959] call 0000:00:1e.0+ returned 0 after 14181 usecs
> [ 50.130106] call 0000:04:00.0+ returned 0 after 13839 usecs
> [ 50.130142] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
> [ 50.130149] call 0000:00:1e.4+ returned 0 after 14290 usecs
> [ 50.130151] call 0000:00:1d.0+ returned 0 after 14471 usecs
> [ 50.130210] call 0000:00:17.0+ returned 0 after 14882 usecs
> [ 50.130256] call 0000:00:13.0+ returned 0 after 15063 usecs
> [ 50.130268] call 0000:00:11.0+ returned 0 after 15145 usecs
> [ 50.130311] call 0000:00:12.0+ returned 0 after 15158 usecs
> [ 50.130327] call 0000:00:02.0+ returned 0 after 15299 usecs
> [ 50.359559] call 0000:00:00.0+ returned 0 after 16 usecs
> [ 76.935630] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u8:7:2266]
> [ 76.944393] Modules linked in: intel_rapl intel_soc_dts_iosf intel_powerclamp spi_pxa2xx_platform kvm_intel kvm irqbypass punit_atom_debug crct10dif_pclmul crc32_pclmul aesni_intel aes_x86_64 joydev input_leds lrw gf128mul glue_helper ablk_helper cryptd lpc_ich serio_raw pwm_lpss_pci spi_pxa2xx_pci pwm_lpss dw_dmac_pci dw_dmac_core shpchp 8250_fintek mac_hid nfsd auth_rpcgss nfs_acl lockd coretemp grace parport_pc ppdev lp parport sunrpc autofs4 hid_cherry usbhid hid mmc_block igb dca ptp i915 video drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci psmouse pps_core drm i2c_algo_bit sdhci_pci libahci sdhci fjes
> [ 77.006747] CPU: 0 PID: 2266 Comm: kworker/u8:7 Not tainted 4.4.0-36-generic #55-Ubuntu
> [ 77.015702] Hardware name: congatec conga-qeval20-qa3-e3845/conga-qeval20-qa3-e3845, BIOS 2017.05-rc2-00122-gf6a9c0b4fd-dirty 04/24/2017
> [ 77.029429] Workqueue: events_unbound async_run_entry_fn
> [ 77.035374] task: ffff8800628b0c80 ti: ffff880176dc8000 task.ti: ffff880176dc8000
> [ 77.043746] RIP: 0010:[<ffffffff81085ad1>] [<ffffffff81085ad1>] __do_softirq+0x81/0x290
> [ 77.052807] RSP: 0018:ffff88017fc03f28 EFLAGS: 00000206
> [ 77.058747] RAX: ffff880176dcc000 RBX: 0000000000000000 RCX: 00000000000006e0
> [ 77.066730] RDX: 0000000000000000 RSI: 0000000004208060 RDI: 00000000000006e0
> [ 77.074704] RBP: ffff88017fc03f80 R08: ffff88017820e400 R09: ffff88017fc16d30
> [ 77.082687] R10: 0000000000000020 R11: 0000000000000004 R12: 0000000000000246
> [ 77.090669] R13: 00000000000000e2 R14: 000000000000002c R15: 000000000000000c
> [ 77.098653] FS: 0000000000000000(0000) GS:ffff88017fc00000(0000) knlGS:0000000000000000
> [ 77.107706] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 77.114132] CR2: 00007f7a3c016028 CR3: 0000000176cb5000 CR4: 00000000001006f0
> [ 77.122115] Stack:
> [ 77.124359] 042080607fc0ede8 ffff880176dcc000 00000000ffff0b90 ffffffff81f361c0
> [ 77.132648] ffff88010000000a 000002827fc0d640 0000000000000000 0000000000000246
> [ 77.140937] 00000000000000e2 000000000000002c 000000000000000c ffff88017fc03f90
> [ 77.149226] Call Trace:
> [ 77.151957] <IRQ>
> [ 77.154107] [<ffffffff81085e53>] irq_exit+0xa3/0xb0
> [ 77.159860] [<ffffffff81830a62>] smp_apic_timer_interrupt+0x42/0x50
> [ 77.166969] [<ffffffff8182ed22>] apic_timer_interrupt+0x82/0x90
> [ 77.173686] <EOI>
> [ 77.175834] [<ffffffff8182da05>] ? _raw_spin_unlock_irqrestore+0x15/0x20
> [ 77.183630] [<ffffffff81436269>] pci_bus_write_config_dword.part.7+0x59/0x70
> [ 77.191614] [<ffffffff81436299>] pci_bus_write_config_dword+0x19/0x20
> [ 77.198919] [<ffffffff8143c335>] pci_restore_config_dword+0x65/0xe0
> [ 77.206029] [<ffffffff8143e1a2>] pci_restore_state.part.33+0x222/0x250
> [ 77.213429] [<ffffffff8143e1e8>] pci_restore_state+0x18/0x20
> [ 77.219858] [<ffffffff8144237f>] pci_pm_resume_noirq+0x2f/0xa0
> [ 77.226480] [<ffffffff81442350>] ? pci_add_dynid+0xd0/0xd0
> [ 77.232715] [<ffffffff81560ebe>] dpm_run_callback+0x4e/0x140
> [ 77.239143] [<ffffffff81561060>] device_resume_noirq+0xb0/0x190
> [ 77.245861] [<ffffffff8156115d>] async_resume_noirq+0x1d/0x50
> [ 77.252378] [<ffffffff810a3208>] async_run_entry_fn+0x48/0x150
> [ 77.259001] [<ffffffff8109a2c5>] process_one_work+0x165/0x480
> [ 77.265526] [<ffffffff8109a62b>] worker_thread+0x4b/0x4c0
> [ 77.271662] [<ffffffff8109a5e0>] ? process_one_work+0x480/0x480
> [ 77.278381] [<ffffffff810a0808>] kthread+0xd8/0xf0
> [ 77.283826] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
> [ 77.291130] [<ffffffff8182e34f>] ret_from_fork+0x3f/0x70
> [ 77.297168] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
> [ 77.304460] Code: 00 c7 45 c8 0a 00 00 00 48 89 45 c0 65 48 8b 04 25 04 42 01 00 48 89 45 b0 65 c7 05 76 e6 f8 7e 00 00 00 00 fb 66 0f 1f 44 00 00 <b8> ff ff ff ff 49 c7 c4 c0 90 e0 81 0f bc 45 d4 83 c0 01 89 45
Thanks for the logs. Can you do the following before suspend and test again?
# echo 0 > /sys/power/pm_async
[snip]
Regards,
Bin
^ permalink raw reply [flat|nested] 58+ messages in thread
* [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support
2017-04-25 9:34 ` Bin Meng
@ 2017-04-25 11:11 ` Stefan Roese
2017-04-26 4:21 ` Bin Meng
0 siblings, 1 reply; 58+ messages in thread
From: Stefan Roese @ 2017-04-25 11:11 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 25.04.2017 11:34, Bin Meng wrote:
<snip>
>>> What do you mean by "display
>>> stays in power safe mode"? Is it a black screen, or is it just
>>> U-Boot's video output screen?
>>
>> Blank screen and the monitor does not wake up from power-safe
>> mode. I see the log on the serial console, since I've changed the
>> environment (stdio) to not use the LCD as the console in U-Boot.
>> U-Boot uses the console as a splash screen instead.
>>
>
> Since you were seeing black screen I guess your U-Boot was not running
> the VGA BIOS for the Intel Baytrail IGD?
My U-Boot configuration runs the VGA BIOS via the "preboot" env
command:
=> printenv preboot
preboot=load scsi 0:${ubuntu_part} ${loadaddr} /boot/logo/logo.bmp;bmp display ${loadaddr}
> The LCD driver is not the
> Intel i915 graphics driver?
In Linux it is. But in the resume case, the preboot env command is
not run, so this explains why the screen is not initialized by
U-Boot (again).
>>>> Jumping to OS waking vector 0009a1d0
>>>>
>>>> And the POST debug byte is also identical (0x40).
>>>>
>>>
>>> These logs looks good. Nothing strange.
>>>
>>>> Do you have any ideas, where this might come from? Could you
>>>> perhaps check this on MinnoxMax as well, if such a setup also
>>>> sometimes has problems with resuming? Is there anything that I could
>>>> do to test this on my platform?
>>>>
>>>
>>> To match your env, I will install a 16.04 from U-Boot for testing. Can
>>> you add the following kernel parameters for testing suspend/resume?
>>>
>>> "console=ttyS0,115200 initcall_debug ignore_loglevel no_console_suspend"
>>
>> Ah, this brings some infos. Here the resume log:
>>
>> [ 49.810439] smpboot: CPU 3 is now offline
>> [ 49.828153] PM: Calling kvm_suspend+0x0/0x30 [kvm]
>> [ 49.833517] PM: Calling mce_syscore_suspend+0x0/0x20
>> [ 49.839072] PM: Calling ledtrig_cpu_syscore_suspend+0x0/0x20
>> [ 49.845404] PM: Calling acpi_processor_suspend+0x0/0x1e
>> [ 49.851255] PM: Calling timekeeping_suspend+0x0/0x2a0
>> [ 49.856925] PM: Calling irq_gc_suspend+0x0/0x70
>> [ 49.861992] PM: Calling save_ioapic_entries+0x0/0x90
>> [ 49.867738] PM: Calling i8259A_suspend+0x0/0x30
>> [ 49.872806] PM: Calling fw_suspend+0x0/0x20
>> [ 49.877484] PM: Calling lapic_suspend+0x0/0x1b0
>> ��
>>
>> U-Boot 2017.05-rc2-00122-gf6a9c0b4fd-dirty (Apr 24 2017 - 10:50:06 +0200)
>>
>> CPU: x86_64, vendor Intel, device 30679h
>> DRAM: 4 GiB
>> MMC: ValleyView SDHCI: 0, ValleyView SDHCI: 1, ValleyView SDHCI: 2
>> SF: Detected w25q64cv with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>> Model: congatec-QEVAL20-QA3-E3845
>> SCSI: SATA link 0 timeout.
>> Target spinup took 0 ms.
>> AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
>> flags: 64bit ncq stag pm led clo pio slum part sxs
>> scanning bus for devices...
>> Device 0: (1:0) Vendor: ATA Prod.: SanDisk Ultra II Rev: X411
>> Type: Hard Disk
>> Capacity: 457862.8 MB = 447.1 GB (937703088 x 512)
>> Found 1 device(s).
>> Net: e1000: 00:13:95:1c:51:e8
>> eth0: e1000#0
>> Jumping to OS waking vector 0009a1d0
>> [ 49.882704] ACPI: Low-level resume complete
>> [ 49.887483] PM: Restoring platform NVS memory
>> [ 49.892361] PM: Calling bsp_resume+0x0/0x20
>> [ 49.897040] PM: Calling lapic_resume+0x0/0x2b0
>> [ 49.902035] PM: Calling irqrouter_resume+0x0/0x3f
>> [ 49.907297] PM: Calling i8259A_resume+0x0/0x30
>> [ 49.912393] PM: Calling i8237A_resume+0x0/0x90
>> [ 49.917434] PM: Calling ioapic_resume+0x0/0xa0
>> [ 49.922495] PM: Calling irq_gc_resume+0x0/0x60
>> [ 49.927464] PM: Calling irq_pm_syscore_resume+0x0/0x20
>> [ 49.933256] PM: Calling timekeeping_resume+0x0/0x200
>> [ 49.938844] PM: Calling acpi_processor_resume+0x0/0x5c
>> [ 49.944595] PM: Calling ledtrig_cpu_syscore_resume+0x0/0x20
>> [ 49.950829] PM: Calling mce_syscore_resume+0x0/0x30
>> [ 49.956291] PM: Calling mc_bp_resume+0x0/0x50
>> [ 49.961193] PM: Calling kvm_resume+0x0/0x40 [kvm]
>> [ 49.966523] Enabling non-boot CPUs ...
>> [ 49.990192] x86: Booting SMP configuration:
>> [ 49.994894] smpboot: Booting Node 0 Processor 1 APIC 0x2
>> [ 50.011048] cache: parent cpu1 should not be sleeping
>> [ 50.017239] CPU1 is up
>> [ 50.038380] smpboot: Booting Node 0 Processor 2 APIC 0x4
>> [ 50.054552] cache: parent cpu2 should not be sleeping
>> [ 50.060685] CPU2 is up
>> [ 50.082550] smpboot: Booting Node 0 Processor 3 APIC 0x6
>> [ 50.098820] cache: parent cpu3 should not be sleeping
>> [ 50.104972] CPU3 is up
>> [ 50.108534] ACPI: Waking up from system sleep state S3
>> [ 50.114576] calling 0000:00:00.0+ @ 2269, parent: pci0000:00
>> [ 50.114630] calling 0000:00:02.0+ @ 163, parent: pci0000:00
>> [ 50.114728] calling 0000:00:11.0+ @ 2265, parent: pci0000:00
>> [ 50.114759] calling 0000:00:12.0+ @ 2268, parent: pci0000:00
>> [ 50.114800] calling 0000:00:13.0+ @ 159, parent: pci0000:00
>> [ 50.114830] calling 0000:00:15.0+ @ 149, parent: pci0000:00
>> [ 50.114926] call 0000:00:15.0+ returned 0 after 86 usecs
>> [ 50.114942] calling 0000:00:17.0+ @ 149, parent: pci0000:00
>> [ 50.114979] calling 0000:00:1c.0+ @ 2267, parent: pci0000:00
>> [ 50.115003] calling 0000:00:1c.1+ @ 40, parent: pci0000:00
>> [ 50.115020] calling 0000:00:1c.2+ @ 2266, parent: pci0000:00
>> [ 50.115261] call 0000:00:1c.0+ returned 0 after 267 usecs
>> [ 50.115282] calling 0000:00:1c.3+ @ 2267, parent: pci0000:00
>> [ 50.115289] call 0000:00:1c.1+ returned 0 after 268 usecs
>> [ 50.115304] calling 0000:00:1d.0+ @ 40, parent: pci0000:00
>> [ 50.115409] calling 0000:00:1e.0+ @ 6, parent: pci0000:00
>> [ 50.115446] calling 0000:00:1e.1+ @ 158, parent: pci0000:00
>> [ 50.115465] call 0000:00:1c.3+ returned 0 after 171 usecs
>> [ 50.115482] calling 0000:00:1e.2+ @ 2271, parent: pci0000:00
>> [ 50.115487] calling 0000:00:1e.4+ @ 2267, parent: pci0000:00
>> [ 50.115689] calling 0000:00:1e.5+ @ 2270, parent: pci0000:00
>> [ 50.115748] call 0000:00:1e.5+ returned 0 after 51 usecs
>> [ 50.115759] calling 0000:00:1f.0+ @ 2270, parent: pci0000:00
>> [ 50.115804] call 0000:00:1f.0+ returned 0 after 38 usecs
>> [ 50.115813] calling 0000:00:1f.3+ @ 2270, parent: pci0000:00
>> [ 50.115899] call 0000:00:1f.3+ returned 0 after 77 usecs
>> [ 50.115907] calling 0000:04:00.0+ @ 2270, parent: 0000:00:1c.3
>> [ 50.129887] call 0000:00:1e.1+ returned 0 after 14073 usecs
>> [ 50.129890] call 0000:00:1e.2+ returned 0 after 14040 usecs
>> [ 50.129959] call 0000:00:1e.0+ returned 0 after 14181 usecs
>> [ 50.130106] call 0000:04:00.0+ returned 0 after 13839 usecs
>> [ 50.130142] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
>> [ 50.130149] call 0000:00:1e.4+ returned 0 after 14290 usecs
>> [ 50.130151] call 0000:00:1d.0+ returned 0 after 14471 usecs
>> [ 50.130210] call 0000:00:17.0+ returned 0 after 14882 usecs
>> [ 50.130256] call 0000:00:13.0+ returned 0 after 15063 usecs
>> [ 50.130268] call 0000:00:11.0+ returned 0 after 15145 usecs
>> [ 50.130311] call 0000:00:12.0+ returned 0 after 15158 usecs
>> [ 50.130327] call 0000:00:02.0+ returned 0 after 15299 usecs
>> [ 50.359559] call 0000:00:00.0+ returned 0 after 16 usecs
>> [ 76.935630] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u8:7:2266]
>> [ 76.944393] Modules linked in: intel_rapl intel_soc_dts_iosf intel_powerclamp spi_pxa2xx_platform kvm_intel kvm irqbypass punit_atom_debug crct10dif_pclmul crc32_pclmul aesni_intel aes_x86_64 joydev input_leds lrw gf128mul glue_helper ablk_helper cryptd lpc_ich serio_raw pwm_lpss_pci spi_pxa2xx_pci pwm_lpss dw_dmac_pci dw_dmac_core shpchp 8250_fintek mac_hid nfsd auth_rpcgss nfs_acl lockd coretemp grace parport_pc ppdev lp parport sunrpc autofs4 hid_cherry usbhid hid mmc_block igb dca ptp i915 video drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci psmouse pps_core drm i2c_algo_bit sdhci_pci libahci sdhci fjes
>> [ 77.006747] CPU: 0 PID: 2266 Comm: kworker/u8:7 Not tainted 4.4.0-36-generic #55-Ubuntu
>> [ 77.015702] Hardware name: congatec conga-qeval20-qa3-e3845/conga-qeval20-qa3-e3845, BIOS 2017.05-rc2-00122-gf6a9c0b4fd-dirty 04/24/2017
>> [ 77.029429] Workqueue: events_unbound async_run_entry_fn
>> [ 77.035374] task: ffff8800628b0c80 ti: ffff880176dc8000 task.ti: ffff880176dc8000
>> [ 77.043746] RIP: 0010:[<ffffffff81085ad1>] [<ffffffff81085ad1>] __do_softirq+0x81/0x290
>> [ 77.052807] RSP: 0018:ffff88017fc03f28 EFLAGS: 00000206
>> [ 77.058747] RAX: ffff880176dcc000 RBX: 0000000000000000 RCX: 00000000000006e0
>> [ 77.066730] RDX: 0000000000000000 RSI: 0000000004208060 RDI: 00000000000006e0
>> [ 77.074704] RBP: ffff88017fc03f80 R08: ffff88017820e400 R09: ffff88017fc16d30
>> [ 77.082687] R10: 0000000000000020 R11: 0000000000000004 R12: 0000000000000246
>> [ 77.090669] R13: 00000000000000e2 R14: 000000000000002c R15: 000000000000000c
>> [ 77.098653] FS: 0000000000000000(0000) GS:ffff88017fc00000(0000) knlGS:0000000000000000
>> [ 77.107706] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 77.114132] CR2: 00007f7a3c016028 CR3: 0000000176cb5000 CR4: 00000000001006f0
>> [ 77.122115] Stack:
>> [ 77.124359] 042080607fc0ede8 ffff880176dcc000 00000000ffff0b90 ffffffff81f361c0
>> [ 77.132648] ffff88010000000a 000002827fc0d640 0000000000000000 0000000000000246
>> [ 77.140937] 00000000000000e2 000000000000002c 000000000000000c ffff88017fc03f90
>> [ 77.149226] Call Trace:
>> [ 77.151957] <IRQ>
>> [ 77.154107] [<ffffffff81085e53>] irq_exit+0xa3/0xb0
>> [ 77.159860] [<ffffffff81830a62>] smp_apic_timer_interrupt+0x42/0x50
>> [ 77.166969] [<ffffffff8182ed22>] apic_timer_interrupt+0x82/0x90
>> [ 77.173686] <EOI>
>> [ 77.175834] [<ffffffff8182da05>] ? _raw_spin_unlock_irqrestore+0x15/0x20
>> [ 77.183630] [<ffffffff81436269>] pci_bus_write_config_dword.part.7+0x59/0x70
>> [ 77.191614] [<ffffffff81436299>] pci_bus_write_config_dword+0x19/0x20
>> [ 77.198919] [<ffffffff8143c335>] pci_restore_config_dword+0x65/0xe0
>> [ 77.206029] [<ffffffff8143e1a2>] pci_restore_state.part.33+0x222/0x250
>> [ 77.213429] [<ffffffff8143e1e8>] pci_restore_state+0x18/0x20
>> [ 77.219858] [<ffffffff8144237f>] pci_pm_resume_noirq+0x2f/0xa0
>> [ 77.226480] [<ffffffff81442350>] ? pci_add_dynid+0xd0/0xd0
>> [ 77.232715] [<ffffffff81560ebe>] dpm_run_callback+0x4e/0x140
>> [ 77.239143] [<ffffffff81561060>] device_resume_noirq+0xb0/0x190
>> [ 77.245861] [<ffffffff8156115d>] async_resume_noirq+0x1d/0x50
>> [ 77.252378] [<ffffffff810a3208>] async_run_entry_fn+0x48/0x150
>> [ 77.259001] [<ffffffff8109a2c5>] process_one_work+0x165/0x480
>> [ 77.265526] [<ffffffff8109a62b>] worker_thread+0x4b/0x4c0
>> [ 77.271662] [<ffffffff8109a5e0>] ? process_one_work+0x480/0x480
>> [ 77.278381] [<ffffffff810a0808>] kthread+0xd8/0xf0
>> [ 77.283826] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
>> [ 77.291130] [<ffffffff8182e34f>] ret_from_fork+0x3f/0x70
>> [ 77.297168] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
>> [ 77.304460] Code: 00 c7 45 c8 0a 00 00 00 48 89 45 c0 65 48 8b 04 25 04 42 01 00 48 89 45 b0 65 c7 05 76 e6 f8 7e 00 00 00 00 fb 66 0f 1f 44 00 00 <b8> ff ff ff ff 49 c7 c4 c0 90 e0 81 0f bc 45 d4 83 c0 01 89 45
>
> Thanks for the logs. Can you do the following before suspend and test again?
>
> # echo 0 > /sys/power/pm_async
Here you go:
[ 104.710546] smpboot: CPU 3 is now offline
[ 104.720268] PM: Calling kvm_suspend+0x0/0x30 [kvm]
[ 104.725632] PM: Calling mce_syscore_suspend+0x0/0x20
[ 104.731187] PM: Calling ledtrig_cpu_syscore_suspend+0x0/0x20
[ 104.737518] PM: Calling acpi_processor_suspend+0x0/0x1e
[ 104.743369] PM: Calling timekeeping_suspend+0x0/0x2a0
[ 104.749038] PM: Calling irq_gc_suspend+0x0/0x70
[ 104.754106] PM: Calling save_ioapic_entries+0x0/0x90
[ 104.759852] PM: Calling i8259A_suspend+0x0/0x30
[ 104.764921] PM: Calling fw_suspend+0x0/0x20
[ 104.769599] PM: Calling lapic_suspend+0x0/0x1b0
�
U-Boot 2017.05-rc2-00122-gf6a9c0b4fd-dirty (Apr 24 2017 - 10:50:06 +0200)
CPU: x86_64, vendor Intel, device 30679h
DRAM: 4 GiB
MMC: ValleyView SDHCI: 0, ValleyView SDHCI: 1, ValleyView SDHCI: 2
SF: Detected w25q64cv with page size 256 Bytes, erase size 4 KiB, total 8 MiB
Model: congatec-QEVAL20-QA3-E3845
SCSI: SATA link 0 timeout.
Target spinup took 0 ms.
AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: 64bit ncq stag pm led clo pio slum part sxs
scanning bus for devices...
Device 0: (1:0) Vendor: ATA Prod.: SanDisk Ultra II Rev: X411
Type: Hard Disk
Capacity: 457862.8 MB = 447.1 GB (937703088 x 512)
Found 1 device(s).
Net: e1000: 00:13:95:1c:51:e8
eth0: e1000#0
Jumping to OS waking vector 0009a1d0
[ 104.774820] ACPI: Low-level resume complete
[ 104.779598] PM: Restoring platform NVS memory
[ 104.784477] PM: Calling bsp_resume+0x0/0x20
[ 104.789157] PM: Calling lapic_resume+0x0/0x2b0
[ 104.794152] PM: Calling irqrouter_resume+0x0/0x3f
[ 104.799413] PM: Calling i8259A_resume+0x0/0x30
[ 104.804510] PM: Calling i8237A_resume+0x0/0x90
[ 104.809552] PM: Calling ioapic_resume+0x0/0xa0
[ 104.814613] PM: Calling irq_gc_resume+0x0/0x60
[ 104.819581] PM: Calling irq_pm_syscore_resume+0x0/0x20
[ 104.825374] PM: Calling timekeeping_resume+0x0/0x200
[ 104.830961] PM: Calling acpi_processor_resume+0x0/0x5c
[ 104.836714] PM: Calling ledtrig_cpu_syscore_resume+0x0/0x20
[ 104.842949] PM: Calling mce_syscore_resume+0x0/0x30
[ 104.848411] PM: Calling mc_bp_resume+0x0/0x50
[ 104.853312] PM: Calling kvm_resume+0x0/0x40 [kvm]
[ 104.858659] Enabling non-boot CPUs ...
[ 104.882349] x86: Booting SMP configuration:
[ 104.887046] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 104.903208] cache: parent cpu1 should not be sleeping
[ 104.909380] CPU1 is up
[ 104.930208] smpboot: Booting Node 0 Processor 2 APIC 0x4
[ 104.946181] cache: parent cpu2 should not be sleeping
[ 104.952121] CPU2 is up
[ 104.974291] smpboot: Booting Node 0 Processor 3 APIC 0x6
[ 104.990309] cache: parent cpu3 should not be sleeping
[ 104.996258] CPU3 is up
[ 104.999800] ACPI: Waking up from system sleep state S3
[ 105.005792] calling 0000:00:00.0+ @ 2365, parent: pci0000:00
[ 105.012277] call 0000:00:00.0+ returned 0 after 24 usecs
[ 105.018227] calling 0000:00:02.0+ @ 2365, parent: pci0000:00
[ 105.038022] call 0000:00:02.0+ returned 0 after 13022 usecs
[ 105.044270] calling 0000:00:11.0+ @ 2365, parent: pci0000:00
[ 105.066068] call 0000:00:11.0+ returned 0 after 14977 usecs
[ 105.072308] calling 0000:00:12.0+ @ 2365, parent: pci0000:00
[ 105.094119] call 0000:00:12.0+ returned 0 after 14988 usecs
[ 105.100367] calling 0000:00:13.0+ @ 2365, parent: pci0000:00
[ 105.122179] call 0000:00:13.0+ returned 0 after 14990 usecs
[ 105.128428] calling 0000:00:15.0+ @ 2365, parent: pci0000:00
[ 105.134909] call 0000:00:15.0+ returned 0 after 43 usecs
[ 105.140856] calling 0000:00:17.0+ @ 2365, parent: pci0000:00
[ 105.162230] call 0000:00:17.0+ returned 0 after 14563 usecs
[ 105.168479] calling 0000:00:1c.0+ @ 2365, parent: pci0000:00
[ 105.174981] call 0000:00:1c.0+ returned 0 after 62 usecs
[ 105.180932] calling 0000:00:1c.1+ @ 2365, parent: pci0000:00
[ 105.187430] call 0000:00:1c.1+ returned 0 after 58 usecs
[ 105.193378] calling 0000:00:1c.2+ @ 2365, parent: pci0000:00
[ 105.199874] call 0000:00:1c.2+ returned 0 after 60 usecs
[ 105.205824] calling 0000:00:1c.3+ @ 2365, parent: pci0000:00
[ 105.212321] call 0000:00:1c.3+ returned 0 after 57 usecs
[ 105.218279] calling 0000:00:1d.0+ @ 2365, parent: pci0000:00
[ 105.238461] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 105.245363] call 0000:00:1d.0+ returned 0 after 20129 usecs
[ 105.251607] calling 0000:00:1e.0+ @ 2365, parent: pci0000:00
[ 105.270418] call 0000:00:1e.0+ returned 0 after 12066 usecs
[ 105.276667] calling 0000:00:1e.1+ @ 2365, parent: pci0000:00
[ 105.298464] call 0000:00:1e.1+ returned 0 after 14973 usecs
[ 105.304712] calling 0000:00:1e.2+ @ 2365, parent: pci0000:00
[ 105.326515] call 0000:00:1e.2+ returned 0 after 14979 usecs
[ 105.332762] calling 0000:00:1e.4+ @ 2365, parent: pci0000:00
[ 105.354560] call 0000:00:1e.4+ returned 0 after 14976 usecs
[ 105.360807] calling 0000:00:1e.5+ @ 2365, parent: pci0000:00
[ 105.367278] call 0000:00:1e.5+ returned 0 after 34 usecs
[ 105.373228] calling 0000:00:1f.0+ @ 2365, parent: pci0000:00
[ 105.379686] call 0000:00:1f.0+ returned 0 after 24 usecs
[ 105.385640] calling 0000:00:1f.3+ @ 2365, parent: pci0000:00
[ 105.392149] call 0000:00:1f.3+ returned 0 after 73 usecs
[ 105.398101] calling 0000:04:00.0+ @ 2365, parent: 0000:00:1c.3
[ 105.418739] call 0000:04:00.0+ returned 0 after 13656 usecs
[ 105.425076] calling i8042+ @ 2365, parent: platform
[ 105.430627] call i8042+ returned 0 after 0 usecs
[ 105.435885] PM: noirq resume of devices complete after 429.458 msecs
[ 105.443164] calling 0000:00:02.0+ @ 2365, parent: pci0000:00
[ 105.457692] call 0000:00:02.0+ returned 0 after 7880 usecs
[ 105.463860] calling 0000:00:1e.0+ @ 2365, parent: pci0000:00
[ 105.470297] call 0000:00:1e.0+ returned 0 after 0 usecs
[ 105.476156] calling INT33FC:00+ @ 2365, parent: platform
[ 105.482442] byt_gpio INT33FC:00: restored pin 50 conf0 0x2003cc81
[ 105.489376] byt_gpio INT33FC:00: restored pin 73 conf0 0xf0fffff8
[ 105.496332] call INT33FC:00+ returned 0 after 13774 usecs
[ 105.502379] calling INT33FC:01+ @ 2365, parent: platform
[ 105.508417] byt_gpio INT33FC:01: restored pin 0 conf0 0x2003cd02
[ 105.515152] byt_gpio INT33FC:01: restored pin 1 conf0 0x2083cd02
[ 105.521889] byt_gpio INT33FC:01: restored pin 2 conf0 0x2003cc82
[ 105.528625] byt_gpio INT33FC:01: restored pin 3 conf0 0x2003cd02
[ 105.535360] byt_gpio INT33FC:01: restored pin 4 conf0 0x2003cd02
[ 105.542089] byt_gpio INT33FC:01: restored pin 5 conf0 0x2003cd02
[ 105.548851] byt_gpio INT33FC:01: restored pin 13 conf0 0x2003cd01
[ 105.555680] byt_gpio INT33FC:01: restored pin 14 conf0 0x2003cc81
[ 105.562560] call INT33FC:01+ returned 0 after 52786 usecs
[ 105.568609] calling INT33FC:02+ @ 2365, parent: platform
[ 105.574800] byt_gpio INT33FC:02: restored pin 27 conf0 0x2003cc80
[ 105.581719] call INT33FC:02+ returned 0 after 6892 usecs
[ 105.587849] PM: early resume of devices complete after 144.493 msecs
[ 105.594990] calling reg-dummy+ @ 2365, parent: platform
[ 105.600940] call reg-dummy+ returned 0 after 0 usecs
[ 105.606519] calling PNP0C0C:00+ @ 2365, parent: LNXSYSTM:00
[ 105.612846] call PNP0C0C:00+ returned 0 after 0 usecs
[ 105.618503] calling 0000:00:00.0+ @ 2365, parent: pci0000:00
[ 105.624945] call 0000:00:00.0+ returned 0 after 6 usecs
[ 105.630796] calling 0000:00:02.0+ @ 2365, parent: pci0000:00
[ 106.007582] call 0000:00:02.0+ returned 0 after 361049 usecs
[ 106.013934] calling 0000:00:11.0+ @ 2365, parent: pci0000:00
[ 106.022037] call 0000:00:11.0+ returned 0 after 1611 usecs
[ 106.028314] calling 0000:00:12.0+ @ 2365, parent: pci0000:00
[ 106.036356] call 0000:00:12.0+ returned 0 after 1527 usecs
[ 106.042609] calling 0000:00:13.0+ @ 2365, parent: pci0000:00
[ 106.064197] call 0000:00:13.0+ returned 0 after 14752 usecs
[ 106.070460] calling 0000:00:15.0+ @ 2365, parent: pci0000:00
[ 106.076912] call 0000:00:15.0+ returned 0 after 2 usecs
[ 106.082764] calling 0000:00:17.0+ @ 2365, parent: pci0000:00
[ 106.090939] call 0000:00:17.0+ returned 0 after 1684 usecs
[ 106.097131] calling 0000:00:1c.0+ @ 2365, parent: pci0000:00
[ 106.103588] call 0000:00:1c.0+ returned 0 after 19 usecs
[ 106.109536] calling 0000:00:1c.1+ @ 2365, parent: pci0000:00
[ 106.115982] call 0000:00:1c.1+ returned 0 after 11 usecs
[ 106.121932] calling 0000:00:1c.2+ @ 2365, parent: pci0000:00
[ 106.128383] call 0000:00:1c.2+ returned 0 after 12 usecs
[ 106.134331] calling 0000:00:1c.3+ @ 2365, parent: pci0000:00
[ 106.244499] pciehp 0000:00:1c.3:pcie04: Device 0000:04:00.0 already exists at 0000:04:00, cannot hot-add
[ 106.255143] pciehp 0000:00:1c.3:pcie04: Cannot add device at 0000:04:00
[ 106.262566] call 0000:00:1c.3+ returned 0 after 118738 usecs
[ 106.268909] calling 0000:00:1d.0+ @ 2365, parent: pci0000:00
[ 106.275452] call 0000:00:1d.0+ returned 0 after 101 usecs
[ 106.281498] calling 0000:00:1e.0+ @ 2365, parent: pci0000:00
[ 106.287935] call 0000:00:1e.0+ returned 0 after 1 usecs
[ 106.293785] calling 0000:00:1e.1+ @ 2365, parent: pci0000:00
[ 106.300219] call 0000:00:1e.1+ returned 0 after 0 usecs
[ 106.306069] calling 0000:00:1e.2+ @ 2365, parent: pci0000:00
[ 106.312505] call 0000:00:1e.2+ returned 0 after 0 usecs
[ 106.318355] calling 0000:00:1e.4+ @ 2365, parent: pci0000:00
[ 106.324795] call 0000:00:1e.4+ returned 0 after 5 usecs
[ 106.330646] calling 0000:00:1e.5+ @ 2365, parent: pci0000:00
[ 106.337088] call 0000:00:1e.5+ returned 0 after 5 usecs
[ 106.342939] calling 0000:00:1f.0+ @ 2365, parent: pci0000:00
[ 106.349365] call 0000:00:1f.0+ returned 0 after 0 usecs
[ 106.355214] calling 0000:00:1f.3+ @ 2365, parent: pci0000:00
[ 106.361648] call 0000:00:1f.3+ returned 0 after 0 usecs
[ 106.367500] calling 0000:04:00.0+ @ 2365, parent: 0000:00:1c.3
[ 106.374172] pcieport 0000:00:1c.3: System wakeup disabled by ACPI
[ 106.441673] call 0000:04:00.0+ returned 0 after 65835 usecs
[ 106.448075] calling INT0800:00+ @ 2365, parent: 0000:00:1f.0
[ 106.454513] call INT0800:00+ returned 0 after 0 usecs
[ 106.460176] calling PNP0C0C:00+ @ 2365, parent: platform
[ 106.466219] call PNP0C0C:00+ returned 0 after 0 usecs
[ 106.471878] calling LNXPWRBN:00+ @ 2365, parent: LNXSYSTM:00
[ 106.478312] call LNXPWRBN:00+ returned 0 after 0 usecs
[ 106.484070] calling 00:00+ @ 2365, parent: pnp0
[ 106.489240] call 00:00+ returned 0 after 0 usecs
[ 106.494410] calling 00:01+ @ 2365, parent: pnp0
[ 106.499578] call 00:01+ returned 0 after 0 usecs
[ 106.504751] calling 00:02+ @ 2365, parent: pnp0
[ 106.509929] call 00:02+ returned 0 after 10 usecs
[ 106.515211] calling 00:03+ @ 2365, parent: pnp0
[ 106.520385] rtc_cmos 00:03: System wakeup disabled by ACPI
[ 106.526527] call 00:03+ returned 0 after 5991 usecs
[ 106.531991] calling 00:04+ @ 2365, parent: pnp0
[ 106.537161] call 00:04+ returned 0 after 0 usecs
[ 106.542355] calling pcspkr+ @ 2365, parent: platform
[ 106.548011] call pcspkr+ returned 0 after 0 usecs
[ 106.553277] calling vesa-framebuffer.0+ @ 2365, parent: platform
[ 106.560098] call vesa-framebuffer.0+ returned 0 after 0 usecs
[ 106.566533] calling alarmtimer+ @ 2365, parent: platform
[ 106.572576] call alarmtimer+ returned 0 after 0 usecs
[ 106.578245] calling input0+ @ 2365, parent: PNP0C0C:00
[ 106.584094] call input0+ returned 0 after 0 usecs
[ 106.589363] calling input1+ @ 2365, parent: LNXPWRBN:00
[ 106.595311] call input1+ returned 0 after 0 usecs
[ 106.600578] calling serial8250+ @ 2365, parent: platform
[ 106.606625] call serial8250+ returned 0 after 2 usecs
[ 106.612324] calling Fixed MDIO bus.0+ @ 2365, parent: platform
[ 106.618952] call Fixed MDIO bus.0+ returned 0 after 0 usecs
[ 106.625193] calling usb1+ @ 2365, parent: 0000:00:1d.0
[ 106.631247] call usb1+ returned 0 after 195 usecs
[ 106.636539] calling i8042+ @ 2365, parent: platform
[ 106.645069] call i8042+ returned 0 after 2880 usecs
[ 106.650532] calling serio0+ @ 2365, parent: i8042
[ 106.655901] call serio0+ returned 0 after 3 usecs
[ 106.661209] calling serio1+ @ 2365, parent: i8042
[ 106.666580] call serio1+ returned 0 after 3 usecs
[ 106.671856] calling rtc0+ @ 2365, parent: 00:03
[ 106.677027] call rtc0+ returned 0 after 0 usecs
[ 106.682101] calling 1-1+ @ 2365, parent: usb1
[ 106.747570] call 1-1+ returned 0 after 58972 usecs
[ 106.753000] calling microcode+ @ 2365, parent: platform
[ 106.758960] call microcode+ returned 0 after 0 usecs
[ 106.764512] calling 1-1.2+ @ 2365, parent: 1-1
[ 106.830648] call 1-1.2+ returned 0 after 59525 usecs
[ 106.836238] calling 1-1.2.1+ @ 2365, parent: 1-1.2
[ 106.903067] call 1-1.2.1+ returned 0 after 59823 usecs
[ 106.908839] calling 1-1.2.1.4+ @ 2365, parent: 1-1.2.1
[ 106.974939] call 1-1.2.1.4+ returned 0 after 58742 usecs
[ 106.980907] calling ata1+ @ 2365, parent: 0000:00:13.0
[ 106.986768] call ata1+ returned 0 after 8 usecs
[ 106.991845] calling ata2+ @ 2365, parent: 0000:00:13.0
[ 106.997705] call ata2+ returned 0 after 6 usecs
[ 107.002772] calling host0+ @ 2365, parent: ata1
[ 107.007945] call host0+ returned 0 after 1 usecs
[ 107.013115] calling host1+ @ 2365, parent: ata2
[ 107.018287] call host1+ returned 0 after 0 usecs
[ 107.023459] calling 1-1.2.1.4.1+ @ 2365, parent: 1-1.2.1.4
[ 107.091641] call 1-1.2.1.4.1+ returned 0 after 60384 usecs
[ 107.097789] calling mmc0::+ @ 2365, parent: 0000:00:11.0
[ 107.103837] call mmc0::+ returned 0 after 0 usecs
[ 107.109105] calling mmc1::+ @ 2365, parent: 0000:00:12.0
[ 107.115151] call mmc1::+ returned 0 after 0 usecs
[ 107.120413] calling mmc2::+ @ 2365, parent: 0000:00:17.0
[ 107.126460] call mmc2::+ returned 0 after 0 usecs
[ 107.131731] calling input5+ @ 2365, parent: 0003:046A:0023.0001
[ 107.138470] call input5+ returned 0 after 12 usecs
[ 107.143856] calling controlD64+ @ 2365, parent: 0000:00:02.0
[ 107.150293] call controlD64+ returned 0 after 0 usecs
[ 107.155954] calling renderD128+ @ 2365, parent: 0000:00:02.0
[ 107.162390] call renderD128+ returned 0 after 0 usecs
[ 107.168049] calling card0+ @ 2365, parent: 0000:00:02.0
[ 107.174002] call card0+ returned 0 after 0 usecs
[ 107.179175] calling input6+ @ 2365, parent: 0003:046A:0023.0002
[ 107.185900] call input6+ returned 0 after 0 usecs
[ 107.191170] calling input7+ @ 2365, parent: 0003:046A:0023.0003
[ 107.197895] call input7+ returned 0 after 0 usecs
[ 107.203172] calling card0-VGA-1+ @ 2365, parent: card0
[ 107.209021] call card0-VGA-1+ returned 0 after 0 usecs
[ 107.214774] calling card0-DP-1+ @ 2365, parent: card0
[ 107.220539] call card0-DP-1+ returned 0 after 0 usecs
[ 107.226199] calling card0-HDMI-A-1+ @ 2365, parent: card0
[ 107.232342] call card0-HDMI-A-1+ returned 0 after 0 usecs
[ 107.238389] calling card0-DP-2+ @ 2365, parent: card0
[ 107.244140] call card0-DP-2+ returned 0 after 0 usecs
[ 107.249799] calling card0-HDMI-A-2+ @ 2365, parent: card0
[ 107.255941] call card0-HDMI-A-2+ returned 0 after 0 usecs
[ 107.262057] calling target1:0:0+ @ 2365, parent: host1
[ 107.267909] call target1:0:0+ returned 0 after 0 usecs
[ 107.273660] calling 1:0:0:0+ @ 2365, parent: target1:0:0
[ 107.279711] call 1:0:0:0+ returned 0 after 5 usecs
[ 107.279809] sd 1:0:0:0: [sda] Starting disk
[ 107.289764] calling mmc2:0001+ @ 2365, parent: mmc2
[ 107.306320] ata1: SATA link down (SStatus 0 SControl 300)
[ 107.318210] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 107.327916] ata2.00: configured for UDMA/133
[ 107.380517] call mmc2:0001+ returned 0 after 83052 usecs
[ 107.386512] calling parport_pc.888+ @ 2365, parent: platform
[ 107.392954] call parport_pc.888+ returned 0 after 0 usecs
[ 107.399026] calling coretemp.0+ @ 2365, parent: platform
[ 107.405077] call coretemp.0+ returned 0 after 0 usecs
[ 107.410764] calling pxa2xx-spi.0+ @ 2365, parent: 0000:00:1e.5
[ 107.417408] call pxa2xx-spi.0+ returned 0 after 9 usecs
[ 107.423277] calling input5::numlock+ @ 2365, parent: input5
[ 107.429624] call input5::numlock+ returned 0 after 0 usecs
[ 107.435773] calling input5::capslock+ @ 2365, parent: input5
[ 107.442221] call input5::capslock+ returned 0 after 0 usecs
[ 107.448473] calling input5::scrolllock+ @ 2365, parent: input5
[ 107.455112] call input5::scrolllock+ returned 0 after 0 usecs
[ 107.461553] calling iTCO_wdt.0.auto+ @ 2365, parent: 0000:00:1f.0
[ 107.468484] call iTCO_wdt.0.auto+ returned 0 after 0 usecs
[ 107.474653] PM: resume of devices complete after 1876.472 msecs
[ 107.663708] PM: Finishing wakeup.
[ 107.667482] Restarting tasks ... done.
[ 109.225751] igb 0000:04:00.0 ens3: igb: ens3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
I can't reproduce the resume problem with this pm_async setting
any more. At least all my 10 attempts were successful now.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support
2017-04-25 11:11 ` Stefan Roese
@ 2017-04-26 4:21 ` Bin Meng
2017-04-26 5:24 ` Stefan Roese
0 siblings, 1 reply; 58+ messages in thread
From: Bin Meng @ 2017-04-26 4:21 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On Tue, Apr 25, 2017 at 7:11 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Bin,
>
> On 25.04.2017 11:34, Bin Meng wrote:
>
> <snip>
>
>>>> What do you mean by "display
>>>> stays in power safe mode"? Is it a black screen, or is it just
>>>> U-Boot's video output screen?
>>>
>>> Blank screen and the monitor does not wake up from power-safe
>>> mode. I see the log on the serial console, since I've changed the
>>> environment (stdio) to not use the LCD as the console in U-Boot.
>>> U-Boot uses the console as a splash screen instead.
>>>
>>
>> Since you were seeing black screen I guess your U-Boot was not running
>> the VGA BIOS for the Intel Baytrail IGD?
>
> My U-Boot configuration runs the VGA BIOS via the "preboot" env
> command:
>
> => printenv preboot
> preboot=load scsi 0:${ubuntu_part} ${loadaddr} /boot/logo/logo.bmp;bmp display ${loadaddr}
>
>> The LCD driver is not the
>> Intel i915 graphics driver?
>
> In Linux it is. But in the resume case, the preboot env command is
> not run, so this explains why the screen is not initialized by
> U-Boot (again).
>
[snip]
> [ 107.386512] calling parport_pc.888+ @ 2365, parent: platform
> [ 107.392954] call parport_pc.888+ returned 0 after 0 usecs
> [ 107.399026] calling coretemp.0+ @ 2365, parent: platform
> [ 107.405077] call coretemp.0+ returned 0 after 0 usecs
> [ 107.410764] calling pxa2xx-spi.0+ @ 2365, parent: 0000:00:1e.5
> [ 107.417408] call pxa2xx-spi.0+ returned 0 after 9 usecs
> [ 107.423277] calling input5::numlock+ @ 2365, parent: input5
> [ 107.429624] call input5::numlock+ returned 0 after 0 usecs
> [ 107.435773] calling input5::capslock+ @ 2365, parent: input5
> [ 107.442221] call input5::capslock+ returned 0 after 0 usecs
> [ 107.448473] calling input5::scrolllock+ @ 2365, parent: input5
> [ 107.455112] call input5::scrolllock+ returned 0 after 0 usecs
> [ 107.461553] calling iTCO_wdt.0.auto+ @ 2365, parent: 0000:00:1f.0
> [ 107.468484] call iTCO_wdt.0.auto+ returned 0 after 0 usecs
> [ 107.474653] PM: resume of devices complete after 1876.472 msecs
> [ 107.663708] PM: Finishing wakeup.
> [ 107.667482] Restarting tasks ... done.
> [ 109.225751] igb 0000:04:00.0 ens3: igb: ens3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>
> I can't reproduce the resume problem with this pm_async setting
> any more. At least all my 10 attempts were successful now.
Thanks for testing. On my side, I was able to reproduce the unstable
suspend/resume with Ubuntu 16.04 several times on Minnowmax. Looks
there are some timing issues (pm_async) and with the Intel i915
driver. Sometimes kernel even does not suspend correctly (kernel oops
in the i915 driver). I will have a look.
Regards,
Bin
^ permalink raw reply [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support
2017-04-26 4:21 ` Bin Meng
@ 2017-04-26 5:24 ` Stefan Roese
2017-04-26 7:37 ` Bin Meng
0 siblings, 1 reply; 58+ messages in thread
From: Stefan Roese @ 2017-04-26 5:24 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 26.04.2017 06:21, Bin Meng wrote:
> On Tue, Apr 25, 2017 at 7:11 PM, Stefan Roese <sr@denx.de> wrote:
>> Hi Bin,
>>
>> On 25.04.2017 11:34, Bin Meng wrote:
>>
>> <snip>
>>
>>>>> What do you mean by "display
>>>>> stays in power safe mode"? Is it a black screen, or is it just
>>>>> U-Boot's video output screen?
>>>>
>>>> Blank screen and the monitor does not wake up from power-safe
>>>> mode. I see the log on the serial console, since I've changed the
>>>> environment (stdio) to not use the LCD as the console in U-Boot.
>>>> U-Boot uses the console as a splash screen instead.
>>>>
>>>
>>> Since you were seeing black screen I guess your U-Boot was not running
>>> the VGA BIOS for the Intel Baytrail IGD?
>>
>> My U-Boot configuration runs the VGA BIOS via the "preboot" env
>> command:
>>
>> => printenv preboot
>> preboot=load scsi 0:${ubuntu_part} ${loadaddr} /boot/logo/logo.bmp;bmp display ${loadaddr}
>>
>>> The LCD driver is not the
>>> Intel i915 graphics driver?
>>
>> In Linux it is. But in the resume case, the preboot env command is
>> not run, so this explains why the screen is not initialized by
>> U-Boot (again).
>>
>
> [snip]
>
>> [ 107.386512] calling parport_pc.888+ @ 2365, parent: platform
>> [ 107.392954] call parport_pc.888+ returned 0 after 0 usecs
>> [ 107.399026] calling coretemp.0+ @ 2365, parent: platform
>> [ 107.405077] call coretemp.0+ returned 0 after 0 usecs
>> [ 107.410764] calling pxa2xx-spi.0+ @ 2365, parent: 0000:00:1e.5
>> [ 107.417408] call pxa2xx-spi.0+ returned 0 after 9 usecs
>> [ 107.423277] calling input5::numlock+ @ 2365, parent: input5
>> [ 107.429624] call input5::numlock+ returned 0 after 0 usecs
>> [ 107.435773] calling input5::capslock+ @ 2365, parent: input5
>> [ 107.442221] call input5::capslock+ returned 0 after 0 usecs
>> [ 107.448473] calling input5::scrolllock+ @ 2365, parent: input5
>> [ 107.455112] call input5::scrolllock+ returned 0 after 0 usecs
>> [ 107.461553] calling iTCO_wdt.0.auto+ @ 2365, parent: 0000:00:1f.0
>> [ 107.468484] call iTCO_wdt.0.auto+ returned 0 after 0 usecs
>> [ 107.474653] PM: resume of devices complete after 1876.472 msecs
>> [ 107.663708] PM: Finishing wakeup.
>> [ 107.667482] Restarting tasks ... done.
>> [ 109.225751] igb 0000:04:00.0 ens3: igb: ens3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>>
>> I can't reproduce the resume problem with this pm_async setting
>> any more. At least all my 10 attempts were successful now.
>
> Thanks for testing. On my side, I was able to reproduce the unstable
> suspend/resume with Ubuntu 16.04 several times on Minnowmax.
Thats good, thanks!
> Looks
> there are some timing issues (pm_async) and with the Intel i915
> driver. Sometimes kernel even does not suspend correctly (kernel oops
> in the i915 driver). I will have a look.
Good luck.
Please note that I don't see this Ubuntu 16.04 resume issue as
a "show-stopper" for this patch series. From my point of view,
its ready for mainline already for the next merge window as we
can always fix this issue later. So please add my:
Tested-by: Stefan Roese <sr@denx.de>
to the patches.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 58+ messages in thread* [U-Boot] [PATCH v2 00/22] x86: Add ACPI S3 resume support
2017-04-26 5:24 ` Stefan Roese
@ 2017-04-26 7:37 ` Bin Meng
0 siblings, 0 replies; 58+ messages in thread
From: Bin Meng @ 2017-04-26 7:37 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On Wed, Apr 26, 2017 at 1:24 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Bin,
>
>
> On 26.04.2017 06:21, Bin Meng wrote:
>>
>> On Tue, Apr 25, 2017 at 7:11 PM, Stefan Roese <sr@denx.de> wrote:
>>>
>>> Hi Bin,
>>>
>>> On 25.04.2017 11:34, Bin Meng wrote:
>>>
>>> <snip>
>>>
>>>>>> What do you mean by "display
>>>>>> stays in power safe mode"? Is it a black screen, or is it just
>>>>>> U-Boot's video output screen?
>>>>>
>>>>>
>>>>> Blank screen and the monitor does not wake up from power-safe
>>>>> mode. I see the log on the serial console, since I've changed the
>>>>> environment (stdio) to not use the LCD as the console in U-Boot.
>>>>> U-Boot uses the console as a splash screen instead.
>>>>>
>>>>
>>>> Since you were seeing black screen I guess your U-Boot was not running
>>>> the VGA BIOS for the Intel Baytrail IGD?
>>>
>>>
>>> My U-Boot configuration runs the VGA BIOS via the "preboot" env
>>> command:
>>>
>>> => printenv preboot
>>> preboot=load scsi 0:${ubuntu_part} ${loadaddr} /boot/logo/logo.bmp;bmp
>>> display ${loadaddr}
>>>
>>>> The LCD driver is not the
>>>> Intel i915 graphics driver?
>>>
>>>
>>> In Linux it is. But in the resume case, the preboot env command is
>>> not run, so this explains why the screen is not initialized by
>>> U-Boot (again).
>>>
>>
>> [snip]
>>
>>> [ 107.386512] calling parport_pc.888+ @ 2365, parent: platform
>>> [ 107.392954] call parport_pc.888+ returned 0 after 0 usecs
>>> [ 107.399026] calling coretemp.0+ @ 2365, parent: platform
>>> [ 107.405077] call coretemp.0+ returned 0 after 0 usecs
>>> [ 107.410764] calling pxa2xx-spi.0+ @ 2365, parent: 0000:00:1e.5
>>> [ 107.417408] call pxa2xx-spi.0+ returned 0 after 9 usecs
>>> [ 107.423277] calling input5::numlock+ @ 2365, parent: input5
>>> [ 107.429624] call input5::numlock+ returned 0 after 0 usecs
>>> [ 107.435773] calling input5::capslock+ @ 2365, parent: input5
>>> [ 107.442221] call input5::capslock+ returned 0 after 0 usecs
>>> [ 107.448473] calling input5::scrolllock+ @ 2365, parent: input5
>>> [ 107.455112] call input5::scrolllock+ returned 0 after 0 usecs
>>> [ 107.461553] calling iTCO_wdt.0.auto+ @ 2365, parent: 0000:00:1f.0
>>> [ 107.468484] call iTCO_wdt.0.auto+ returned 0 after 0 usecs
>>> [ 107.474653] PM: resume of devices complete after 1876.472 msecs
>>> [ 107.663708] PM: Finishing wakeup.
>>> [ 107.667482] Restarting tasks ... done.
>>> [ 109.225751] igb 0000:04:00.0 ens3: igb: ens3 NIC Link is Up 1000 Mbps
>>> Full Duplex, Flow Control: RX/TX
>>>
>>> I can't reproduce the resume problem with this pm_async setting
>>> any more. At least all my 10 attempts were successful now.
>>
>>
>> Thanks for testing. On my side, I was able to reproduce the unstable
>> suspend/resume with Ubuntu 16.04 several times on Minnowmax.
>
>
> Thats good, thanks!
>
>> Looks
>> there are some timing issues (pm_async) and with the Intel i915
>> driver. Sometimes kernel even does not suspend correctly (kernel oops
>> in the i915 driver). I will have a look.
>
>
> Good luck.
>
> Please note that I don't see this Ubuntu 16.04 resume issue as
> a "show-stopper" for this patch series. From my point of view,
> its ready for mainline already for the next merge window as we
> can always fix this issue later. So please add my:
>
> Tested-by: Stefan Roese <sr@denx.de>
>
Thank you for the testing! I've just added the tag to the series, and
applied this series to the u-boot-x86/next branch.
> to the patches.
Regards,
Bin
^ permalink raw reply [flat|nested] 58+ messages in thread