Re: [coreboot] Does S3 work on Haswell boards?

[Matt DeVillier]

On Thu, Nov 2, 2017 at 1:48 PM, Nico Huber  wrote:

> Hi Aladyshev,
>
> On 30.10.2017 16:49, Аладышев Константин wrote:
>
>> Does S3 work on Haswell boards?
>>
>
> It definitely worked at some point. Matt might know a latest revision
> where it was tested on Chromebooks or maybe can verify if it still works
> upstream.
>
> Nico
>

it's working on google/wolf, which is running coreboot/SeaBIOS built on
2017/10/20.  Even Windows has no problem with suspend/resume, so I don't
believe there's a platofrm/chipset-level issue at play
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Does S3 work on Haswell boards?

[Nico Huber]

Hi Aladyshev,

On 30.10.2017 16:49, Аладышев Константин wrote:

I have problem with S3 mode on Haswell board. Everything is fine if S3 time
is very small (<15 seconds), but if it is longer, coreboot won't resume. It
fails on quick_ram_check.


sounds much like the DRAM loses some state. e.g. if the MRC doesn't
reinitialize MRx registers in the DRAM and their state is lost,
quick_ram_check() could fail even if the controller is configured
correctly.

There was a DRAM_RESET_GATE_GPIO Kconfig for Sandy/Ivy Bridge but no
equivalent for Haswell. Maybe your board needs something like that?

Or maybe even power was lost for the DRAM. It all pretty much depends
on the board.



I've enabled mrc.cache and ME in coreboot. I use ME binary from original
board and MRC.bin from Google Panther.

...

It seems like DRAM controller and ME are initialized correctly (like in
normal boot), what can be wrong?

Does S3 work on Haswell boards?


It definitely worked at some point. Matt might know a latest revision
where it was tested on Chromebooks or maybe can verify if it still works
upstream.

Nico

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Does S3 work on Haswell boards?

[Zoran Stojsavljevic]

> I use “pm-suspend” to go to S3, but “systemctl suspend” works exactly the
same. USB wakeup doesn't work at all for me. I wake system with power
button.

I myself will check what is going on with my HP EliteBook 840 G1 (HSW
i5-4300U) upon my return to Munich (on my bare metal Fedora 26). I have to.
If it works (and I remember that it works, not ideally, as I recall), there
is something awry with Coreboot S3 state (ACPI tables) settings, for sure.

Please, stay tuned!

Zoran

On Tue, Oct 31, 2017 at 10:36 AM, Аладышев Константин <aladys...@nicevt.ru>
wrote:

> I don’t think that the problem is connected to operating system version as
> both Windows 7 and Ubuntu 16.04 act the same for me:
> - for S3 time less than ~15s, resume works ok
> - for S3 time longer than ~15s, Coreboot won't resume with quick_ram_check
> error
>
> I use “pm-suspend” to go to S3, but “systemctl suspend” works exactly the
> same. USB wakeup doesn't work at all for me. I wake system with power
> button.
>
>
> From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
> Sent: Tuesday, October 31, 2017 10:19 AM
> To: Аладышев Константин
> Cc: Coreboot
> Subject: Re: [coreboot] Does S3 work on Haswell boards?
>
> Hello Kostja,
>
> Since presently I am not in Munich/Germany (I am in front of my HSW
> notebook in my apartment in Belgrade), I have limited abilities to test
> your question, since I do not have native/bare metal Fedora on my SSD (I
> have in safe box HDD with dual boot: WIN10 and Fedora 26 in Munich).
>
> Here, I have my notebook (HP EliteBook 840 G1) with SSD, bare metal WIN10
> 64 PRO and VMWare reader with Fedora 26 VM. IT is based on HSW i5-4300:
> [user@192 ~]$ dmesg | grep 4300
> [0.097524] smpboot: CPU0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
> (family: 0x6, model: 0x45, stepping: 0x1)
> [user@192 ~]$
>
> Here is the pointer to ark.intel.com for this CPU: https://ark.intel.com/
> products/76308/Intel-Core-i5-4300U-Processor-3M-Cache-up-to-2_90-GHz
>
> The current BSP used is UEFI: BIOS 01.39 Rev.A (08 Nov 2016) ->
> sp77791.exe (12.7 MB)
> ___
>
> Being in WIN10, suspend works when I simply press , but resume works
> ONLY while I press muse buttons - keyboard  does not work,
> although it should?!
>
> I did several attempts to suspend and resume using Fedora 26 VM, but I did
> not have success. I do remember that this does work with my bare metal
> Fedora 26:
> Kernel used for Fedora26 VM: uname -r -> 4.13.9-200.fc26.x86_64 .
>
> I would strongly suggest to use two methods to check S3 on Linux bare
> metal:
> [1] To use systemctl suspend and systemctl resume commands;
> [2] To install on your HSW platform the following package:
> http://www.linuxfromscratch.org/blfs/view/cvs/general/pm-utils.html
>   so you can try the following two commands: pm-suspend and
> pm-hibernate (wakeup should work using keyboard/mouse)!
>
> First, you should do all these tests with UEFI BIOS for your platform,
> record the results, and then switch to Coreboot, than repeat all use cases,
> and cross compare.
>
> If you do, please, post your kernel version and results here.
>
> Hope this helps.
>
> Best Regards,
> Zoran Stojsavljevic
> ___
>
> On Mon, Oct 30, 2017 at 4:49 PM, Аладышев Константин <aladys...@nicevt.ru>
> wrote:
> I have problem with S3 mode on Haswell board. Everything is fine if S3 time
> is very small (<15 seconds), but if it is longer, coreboot won't resume. It
> fails on quick_ram_check.
>
> I've enabled mrc.cache and ME in coreboot. I use ME binary from original
> board and MRC.bin from Google Panther.
>
> Log from S3 resume:
>
> """
> Disabling Watchdog reboot... done.
> SMBus controller enabled.
> Setting up static northbridge registers... done.
> Initializing Graphics...
> Back from haswell_early_initialization()
> Resume from S3 detected.
> CPU id(40651) ucode:001c Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
> AES supported, TXT supported, VT supported
> PCH type: LP Premium, device id: 9c43, rev id 4
> Starting UEFI PEI System Agent
> CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100
> CBFS: CBFS location: 0xf0~0xfff7c0, align: 64
> CBFS: Looking for 'mrc.cache' starting from 0xf0.
> CBFS:  - load entry 0xf0 file name (16 bytes)...
> CBFS:  (unmatched file @0xf0: bootsplash.jpg)
> CBFS:  - load entry 0xf187c0 file name (16 bytes)...
> CBFS:  (unmatched file @0xf187c0: bootorder)
> CBFS:  - load entry 0xf18b80 file name (16 bytes)...
> CBFS:  (unmatched file @0xf18b80: cmos_layout.bin)
> CBFS:  - load entry 0xf19040 file name (32 bytes)...
> CBFS:  (unmatched file @0xf19040: pci8086,0a26.rom)
> CBFS:  - load entry 0xf29080 file name (72 

Re: [coreboot] Does S3 work on Haswell boards?

[Аладышев Константин]

I don’t think that the problem is connected to operating system version as both 
Windows 7 and Ubuntu 16.04 act the same for me:
- for S3 time less than ~15s, resume works ok
- for S3 time longer than ~15s, Coreboot won't resume with quick_ram_check error

I use “pm-suspend” to go to S3, but “systemctl suspend” works exactly the same. 
USB wakeup doesn't work at all for me. I wake system with power button.


From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com] 
Sent: Tuesday, October 31, 2017 10:19 AM
To: Аладышев Константин
Cc: Coreboot
Subject: Re: [coreboot] Does S3 work on Haswell boards?

Hello Kostja,

Since presently I am not in Munich/Germany (I am in front of my HSW notebook in 
my apartment in Belgrade), I have limited abilities to test your question, 
since I do not have native/bare metal Fedora on my SSD (I have in safe box HDD 
with dual boot: WIN10 and Fedora 26 in Munich).

Here, I have my notebook (HP EliteBook 840 G1) with SSD, bare metal WIN10 64 
PRO and VMWare reader with Fedora 26 VM. IT is based on HSW i5-4300:
[user@192 ~]$ dmesg | grep 4300
[0.097524] smpboot: CPU0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz (family: 
0x6, model: 0x45, stepping: 0x1)
[user@192 ~]$

Here is the pointer to ark.intel.com for this CPU: 
https://ark.intel.com/products/76308/Intel-Core-i5-4300U-Processor-3M-Cache-up-to-2_90-GHz

The current BSP used is UEFI: BIOS 01.39 Rev.A (08 Nov 2016) -> sp77791.exe 
(12.7 MB)
___

Being in WIN10, suspend works when I simply press , but resume works ONLY 
while I press muse buttons - keyboard  does not work, although it 
should?!

I did several attempts to suspend and resume using Fedora 26 VM, but I did not 
have success. I do remember that this does work with my bare metal Fedora 26:
Kernel used for Fedora26 VM: uname -r -> 4.13.9-200.fc26.x86_64 .

I would strongly suggest to use two methods to check S3 on Linux bare metal:
[1] To use systemctl suspend and systemctl resume commands;
[2] To install on your HSW platform the following package: 
http://www.linuxfromscratch.org/blfs/view/cvs/general/pm-utils.html
  so you can try the following two commands: pm-suspend and pm-hibernate 
(wakeup should work using keyboard/mouse)!

First, you should do all these tests with UEFI BIOS for your platform, record 
the results, and then switch to Coreboot, than repeat all use cases, and cross 
compare.

If you do, please, post your kernel version and results here.

Hope this helps.

Best Regards,
Zoran Stojsavljevic
___

On Mon, Oct 30, 2017 at 4:49 PM, Аладышев Константин <aladys...@nicevt.ru> 
wrote:
I have problem with S3 mode on Haswell board. Everything is fine if S3 time
is very small (<15 seconds), but if it is longer, coreboot won't resume. It
fails on quick_ram_check.

I've enabled mrc.cache and ME in coreboot. I use ME binary from original
board and MRC.bin from Google Panther.

Log from S3 resume:

"""
Disabling Watchdog reboot... done.
SMBus controller enabled.
Setting up static northbridge registers... done.
Initializing Graphics...
Back from haswell_early_initialization()
Resume from S3 detected.
CPU id(40651) ucode:001c Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
AES supported, TXT supported, VT supported
PCH type: LP Premium, device id: 9c43, rev id 4
Starting UEFI PEI System Agent
CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100
CBFS: CBFS location: 0xf0~0xfff7c0, align: 64
CBFS: Looking for 'mrc.cache' starting from 0xf0.
CBFS:  - load entry 0xf0 file name (16 bytes)...
CBFS:  (unmatched file @0xf0: bootsplash.jpg)
CBFS:  - load entry 0xf187c0 file name (16 bytes)...
CBFS:  (unmatched file @0xf187c0: bootorder)
CBFS:  - load entry 0xf18b80 file name (16 bytes)...
CBFS:  (unmatched file @0xf18b80: cmos_layout.bin)
CBFS:  - load entry 0xf19040 file name (32 bytes)...
CBFS:  (unmatched file @0xf19040: pci8086,0a26.rom)
CBFS:  - load entry 0xf29080 file name (72 bytes)...
CBFS:  (unmatched file @0xf29080: cpu_microcode_blob.bin)
CBFS:  - load entry 0xf2e100 file name (32 bytes)...
CBFS:  (unmatched file @0xf2e100: etc/usb-time-sigatt)
CBFS:  - load entry 0xf2e140 file name (16 bytes)...
CBFS:  (unmatched file @0xf2e140: config)
CBFS:  - load entry 0xf2fa00 file name (16 bytes)...
CBFS:  (unmatched file @0xf2fa00: revision)
CBFS:  - load entry 0xf2fc80 file name (16 bytes)...
CBFS:  (unmatched file @0xf2fc80: )
CBFS:  - load entry 0xf2ff80 file name (76 bytes)...
CBFS:  (unmatched file @0xf2ff80: fallback/romstage)
CBFS:  - load entry 0xf38f00 file name (32 bytes)...
CBFS:  (unmatched file @0xf38f00: fallback/ramstage)
CBFS:  - load entry 0xf4d0c0 file name (32 bytes)...
CBFS:  (unmatched file @0xf4d0c0: fallback/payload)
CBFS:  - load entry 0xf5e8c0 file name (32 bytes)...
CBFS:  (unmatched file @0xf5e8c0: pci8086,1521.rom)
CBFS:  - load entry 0xf6e900 file name (16 bytes)...
CBFS:  (unmatched file @0xf6e900: )
CBFS:  - load entry 0xf9ffc0 file name (40 bytes)...
CBFS:  (unmatched file @0x

Re: [coreboot] Does S3 work on Haswell boards?

[Zoran Stojsavljevic]

Hello Kostja,

Since presently I am not in Munich/Germany (I am in front of my HSW
notebook in my apartment in Belgrade), I have limited abilities to test
your question, since I do not have native/bare metal Fedora on my SSD (I
have in safe box HDD with dual boot: WIN10 and Fedora 26 in Munich).

Here, I have my notebook (HP EliteBook 840 G1) with SSD, bare metal WIN10
64 PRO and VMWare reader with Fedora 26 VM. IT is based on HSW i5-4300:
[user@192 ~]$ dmesg | grep 4300
[0.097524] smpboot: CPU0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
(family: 0x6, model: 0x45, stepping: 0x1)
[user@192 ~]$

Here is the pointer to ark.intel.com for this CPU:
https://ark.intel.com/products/76308/Intel-Core-i5-4300U-Processor-3M-Cache-up-to-2_90-GHz

The current BSP used is UEFI: BIOS 01.39 Rev.A (08 Nov 2016) -> sp77791.exe
(12.7 MB)
___

Being in WIN10, suspend works when I simply press , but resume works
ONLY while I press muse buttons - keyboard  does not work,
although it should?!

I did several attempts to suspend and resume using Fedora 26 VM, but I did
not have success. I do remember that this does work with my bare metal
Fedora 26:
Kernel used for Fedora26 VM: uname -r -> 4.13.9-200.fc26.x86_64 .

I would strongly suggest to use two methods to check S3 on Linux bare metal:
[1] To use systemctl suspend and systemctl resume commands;
[2] To install on your HSW platform the following package:
http://www.linuxfromscratch.org/blfs/view/cvs/general/pm-utils.html
  so you can try the following two commands: pm-suspend and
pm-hibernate (wakeup should work using keyboard/mouse)!

First, you should do all these tests with UEFI BIOS for your platform,
record the results, and then switch to Coreboot, than repeat all use cases,
and cross compare.

If you do, please, post your kernel version and results here.

Hope this helps.

Best Regards,
Zoran Stojsavljevic
___

On Mon, Oct 30, 2017 at 4:49 PM, Аладышев Константин 
wrote:

> I have problem with S3 mode on Haswell board. Everything is fine if S3 time
> is very small (<15 seconds), but if it is longer, coreboot won't resume. It
> fails on quick_ram_check.
>
> I've enabled mrc.cache and ME in coreboot. I use ME binary from original
> board and MRC.bin from Google Panther.
>
> Log from S3 resume:
>
> """
> Disabling Watchdog reboot... done.
> SMBus controller enabled.
> Setting up static northbridge registers... done.
> Initializing Graphics...
> Back from haswell_early_initialization()
> Resume from S3 detected.
> CPU id(40651) ucode:001c Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
> AES supported, TXT supported, VT supported
> PCH type: LP Premium, device id: 9c43, rev id 4
> Starting UEFI PEI System Agent
> CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100
> CBFS: CBFS location: 0xf0~0xfff7c0, align: 64
> CBFS: Looking for 'mrc.cache' starting from 0xf0.
> CBFS:  - load entry 0xf0 file name (16 bytes)...
> CBFS:  (unmatched file @0xf0: bootsplash.jpg)
> CBFS:  - load entry 0xf187c0 file name (16 bytes)...
> CBFS:  (unmatched file @0xf187c0: bootorder)
> CBFS:  - load entry 0xf18b80 file name (16 bytes)...
> CBFS:  (unmatched file @0xf18b80: cmos_layout.bin)
> CBFS:  - load entry 0xf19040 file name (32 bytes)...
> CBFS:  (unmatched file @0xf19040: pci8086,0a26.rom)
> CBFS:  - load entry 0xf29080 file name (72 bytes)...
> CBFS:  (unmatched file @0xf29080: cpu_microcode_blob.bin)
> CBFS:  - load entry 0xf2e100 file name (32 bytes)...
> CBFS:  (unmatched file @0xf2e100: etc/usb-time-sigatt)
> CBFS:  - load entry 0xf2e140 file name (16 bytes)...
> CBFS:  (unmatched file @0xf2e140: config)
> CBFS:  - load entry 0xf2fa00 file name (16 bytes)...
> CBFS:  (unmatched file @0xf2fa00: revision)
> CBFS:  - load entry 0xf2fc80 file name (16 bytes)...
> CBFS:  (unmatched file @0xf2fc80: )
> CBFS:  - load entry 0xf2ff80 file name (76 bytes)...
> CBFS:  (unmatched file @0xf2ff80: fallback/romstage)
> CBFS:  - load entry 0xf38f00 file name (32 bytes)...
> CBFS:  (unmatched file @0xf38f00: fallback/ramstage)
> CBFS:  - load entry 0xf4d0c0 file name (32 bytes)...
> CBFS:  (unmatched file @0xf4d0c0: fallback/payload)
> CBFS:  - load entry 0xf5e8c0 file name (32 bytes)...
> CBFS:  (unmatched file @0xf5e8c0: pci8086,1521.rom)
> CBFS:  - load entry 0xf6e900 file name (16 bytes)...
> CBFS:  (unmatched file @0xf6e900: )
> CBFS:  - load entry 0xf9ffc0 file name (40 bytes)...
> CBFS:  (unmatched file @0xf9ffc0: mrc.bin)
> CBFS:  - load entry 0xfceb40 file name (16 bytes)...
> CBFS:  (unmatched file @0xfceb40: )
> CBFS:  - load entry 0xfdffc0 file name (40 bytes)...
> CBFS: Found file (offset=0xfe, len=65536).
> find_current_mrc_cache_local: picked entry 0 from cache block
> prepare_mrc_cache: at fffe0010, size fe0 checksum 9771
> CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100
> CBFS: CBFS location: 0xf0~0xfff7c0, align: 64
> CBFS: Looking for 'mrc.bin' starting from 0xf0.
> CBFS:  - load entry 0xf0 file name (16 bytes)...
>