petecb via coreboot wrote:
Does anyone know whether there is a specific coreboot/cmos option I could be missing or if it is a Qubes configuration issue?
Narrow the problem down by booting any common Linux distribution (the install media is fine) and as root suspending with
echo mem > /sys/power/state
..and see if resume works there. If yes coreboot is not neccessarily off the hook, but xen/Qubes is at least involved.
//Peter
Hi Peter,
Narrow the problem down by booting any common Linux distribution (the install media is fine) and as root suspending with
echo mem > /sys/power/state
..and see if resume works there. If yes coreboot is not neccessarily off the hook, but xen/Qubes is at least involved.
Thanks for this suggestion. I have now tried it with a Fedora and a Knoppix live CD and neither of them can resume from suspend.
Kind regards,
Pete
Hi,
as I currently have a D16 right next to me, I thought I'd just test it, too. This is with coreboot-4.8-660-gb1d26f0e92. S3 seems to be working somehow, but I have to press the power button to make it resume - it doesn't react on (USB keyboard) key presses. Also it takes about one minute to resume, with 8x 8GB RAM, single CPU.
Just in case it helps somehow...
See the attached coreboot log.
And BTW, yes, the D16 has a serial port exposed at the rear panel.
Kind Regards,
Merlin
defconfig:
CONFIG_USE_OPTION_TABLE=y CONFIG_VENDOR_ASUS=y CONFIG_BOARD_ASUS_KGPE_D16=y CONFIG_COREBOOT_ROMSIZE_KB_16384=y CONFIG_PAYLOAD_GRUB2=y CONFIG_GRUB2_EXTRA_MODULES="cat" CONFIG_GRUB2_INCLUDE_RUNTIME_CONFIG_FILE=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y CONFIG_NVRAMCUI_SECONDARY_PAYLOAD=y
On Mon, 10 Dec 2018 13:32:04 +0000 petecb via coreboot coreboot@coreboot.org wrote:
Hi,
I have not been able to get S3 suspend to work with this board when using Qubes 4. It's running coreboot v4.6 with the default CMOS options. It appears to go into suspend ok but when I try to resume the system does not respond to keyboard or mouse input and pressing the powerbutton results in what appears to be a fresh cold-boot.
Does anyone know whether there is a specific coreboot/cmos option I could be missing or if it is a Qubes configuration issue?
Kind regards,
Pete
petecb via coreboot wrote:
Narrow the problem down by booting any common Linux distribution (the install media is fine) and as root suspending with
echo mem > /sys/power/state
..and see if resume works there. If yes coreboot is not neccessarily off the hook, but xen/Qubes is at least involved.
Thanks for this suggestion. I have now tried it with a Fedora and a Knoppix live CD and neither of them can resume from suspend.
Those are good data points!
They indicate a coreboot problem; ie. not at all related to xen/Qubes.
Now it would be very helpful to get debug output from coreboot, which requires specific hardware. With luck you can use a USB->serial-adapter that you already have (only specific ones work), otherwise you'll need e.g. a BeagleBone Black to function as a USB Debug Device.
Or if you are really lucky :) the KGPE-D16 already has a serial port and you just have to rebuild coreboot with debugging enabled.
//Peter
Hi,
I have not been able to get S3 suspend to work with this board when using Qubes 4. It's running coreboot v4.6 with the default CMOS options. It appears to go into suspend ok but when I try to resume the system does not respond to keyboard or mouse input and pressing the powerbutton results in what appears to be a fresh cold-boot.
Does anyone know whether there is a specific coreboot/cmos option I could be missing or if it is a Qubes configuration issue?
Kind regards,
Pete
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 12/10/2018 01:55 PM, Angel Pons wrote:
Hello,
On Mon, Dec 10, 2018, 19:45 Taiidan@gmx.com mailto:Taiidan@gmx.com <Taiidan@gmx.com mailto:Taiidan@gmx.com wrote:
S3 - it does work but you just have to wait a long time I would guess that maybe there is some ram re-training going on and that is why resuming from S3 takes over a minute.AFAIK, retraining the RAM destroys its contents (and that is why timings must be cached to flash for S3 to work). Does AMD have anything special to retrain memory yet still preserve RAM data to allow suspend, or am I missing something here?
Best regards,
Angel Pons
You are correct. The memory is not (and cannot be) retrained, the previous settings are loaded from the s3nv region of Flash (this is also why the settings change on each boot -- the last known good training data is loaded into Flash to support resume from suspend).
My understanding is that because the current coreboot native AMD codebase doesn't support relocatable ramstage (yet?) we're hitting a slow path somewhere in resume. I think there was some work being put into adding the relocateable ramstage support but I don't know current status.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
S3 - it does work but you just have to wait a long time I would guess that maybe there is some ram re-training going on and that is why resuming from S3 takes over a minute.
Hello,
On Mon, Dec 10, 2018, 19:45 Taiidan@gmx.com <Taiidan@gmx.com wrote:
S3 - it does work but you just have to wait a long time I would guess that maybe there is some ram re-training going on and that is why resuming from S3 takes over a minute.
AFAIK, retraining the RAM destroys its contents (and that is why timings must be cached to flash for S3 to work). Does AMD have anything special to retrain memory yet still preserve RAM data to allow suspend, or am I missing something here?
Best regards,
Angel Pons
Hi all,
Jumping to the discussion since i've done some tests myself on coreboot 4.8.1 for the Heads project on that board in the past few days. https://github.com/tlaurion/heads/blob/kgpe-d16-merging_good_order/config/co... .
The kgpe-d16 refuses to train memory correctly when "CONFIG_RELOCATABLE_RAMSTAGE=y" is configured in. This option would be interesting to have, since the s3nv cbfs file in rom changes at each bootup for some reason that escape my comprehension.
IOMMU is not setuped correctly when "CONFIG_USE_OPTION_TABLE=y" is not configured in.
On Mon, Dec 10, 2018 at 2:04 PM Merlin Büge toni@bluenox07.de wrote:
Hi,
as I currently have a D16 right next to me, I thought I'd just test it, too. This is with coreboot-4.8-660-gb1d26f0e92. S3 seems to be working somehow, but I have to press the power button to make it resume - it doesn't react on (USB keyboard) key presses. Also it takes about one minute to resume, with 8x 8GB RAM, single CPU.
Just in case it helps somehow...
See the attached coreboot log.
And BTW, yes, the D16 has a serial port exposed at the rear panel.
Kind Regards,
Merlin
defconfig:
CONFIG_USE_OPTION_TABLE=y CONFIG_VENDOR_ASUS=y CONFIG_BOARD_ASUS_KGPE_D16=y CONFIG_COREBOOT_ROMSIZE_KB_16384=y CONFIG_PAYLOAD_GRUB2=y CONFIG_GRUB2_EXTRA_MODULES="cat" CONFIG_GRUB2_INCLUDE_RUNTIME_CONFIG_FILE=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y CONFIG_NVRAMCUI_SECONDARY_PAYLOAD=y
On Mon, 10 Dec 2018 13:32:04 +0000 petecb via coreboot coreboot@coreboot.org wrote:
Hi,
I have not been able to get S3 suspend to work with this board when using Qubes 4. It's running coreboot v4.6 with the default CMOS options. It appears to go into suspend ok but when I try to resume the system does not respond to keyboard or mouse input and pressing the powerbutton results in what appears to be a fresh cold-boot.
Does anyone know whether there is a specific coreboot/cmos option I could be missing or if it is a Qubes configuration issue?
Kind regards,
Pete
-- Merlin Büge -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-
Angel Pons -
Merlin Büge -
petecb -
Peter Stuge -
Taiidan＠gmx.com -
Thierry Laurion -
Timothy Pearson