Using a t440p, with Debian bullseye (kernel 5.10.140-1), finding that:
after entering suspend state (systemctl suspend),
pressing the power button either restarts (or enters normal boot-up), resulting in the normal osboot prompt, and not resuming from suspend.
Searching online, I found some guidance with coreboot issue #412 (https://ticket.coreboot.org/issues/412), implying that there could be a potential issue with flashing method could cause the issue.
I attempted to re-flash osboot using the following:
...after which, the flashrom prompted indicated VERIFIED. However, resume-from-suspend issue persists (enters into restart/normal boot routine after suspend).
See full cbmem output below, but following coreboot issue #412, the sizing issue log warnings are present in this excerpt:
SF size 0x2800000 does not correspond to CONFIG_ROM_SIZE 0xc00000!!
MRC: no data in 'RW_MRC_CACHE'
MRC: cache data 'RW_MRC_CACHE' needs update.
...but during my osbmk compilation step this appeared to have been taken care of as a result of the ifd.bin extracted from a Lenovo source. This ticket seems to have addressed this, but maybe introduced something to related here: #129
Some updates from the coreboot folks here: https://ticket.coreboot.org/issues/432
Their investigations seem to point to a potential issue with the ifd blob as used within the osbmk process.
I noticed that the documentation for the ifd for the t440p referenced the need to track down the ifd yourself: https://osboot.org/docs/build/#optional-extract-binary-blobs
...but during my osbmk compilation step this appeared to have been taken care of as a result of the ifd.bin extracted from a Lenovo source. This ticket seems to have addressed this, but maybe introduced something to related here: https://notabug.org/osboot/osbmk/issues/129
Thank you for a detailed bug report, I have the same issue with an osboot-flashed T440p (already discussed with the developer over e-mail and IRC) and would be interested to have the bug fix too when it is available.
The bug reproduces for me using both Ubuntu 22.04 and Debian 11 with all updates, the only difference (AFAIR) is that in Debian the suspended laptop powers on by keyboard and in Ubuntu it does not. In either case the power button continues to fade in and out after the botched resume. The BIOS identifies itself as follows:
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: coreboot
Version: 4.15-204-gcf1d1fa672
Release Date: 03/20/2022
ROM Size: 12 MB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
BIOS is upgradeable
Selectable boot is supported
ACPI is supported
Targeted content distribution is supported
BIOS Revision: 4.15
Firmware Revision: 0.0
Thank you for a detailed bug report, I have the same issue with an osboot-flashed T440p (already discussed with the developer over e-mail and IRC) and would be interested to have the bug fix too when it is available.
The bug reproduces for me using both Ubuntu 22.04 and Debian 11 with all updates, the only difference (AFAIR) is that in Debian the suspended laptop powers on by keyboard and in Ubuntu it does not. In either case the power button continues to fade in and out after the botched resume. The BIOS identifies itself as follows:
```text
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: coreboot
Version: 4.15-204-gcf1d1fa672
Release Date: 03/20/2022
ROM Size: 12 MB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
BIOS is upgradeable
Selectable boot is supported
ACPI is supported
Targeted content distribution is supported
BIOS Revision: 4.15
Firmware Revision: 0.0
```
Just thinking out loud: the t440p ifd.bin blob is committed part of the osbmk repo. But looking at the obwww repo, this commit added documentation talking about how to extract or download the binary blobs from board: 85dbbf2abb
Appears to perform operations with ich9utils, but I'm sort of out of my depth in terms of what to do with it.
Given that my device is already flashed (likely with an invalid ifd.bin), and the ifd.bin provided with the osbmk repo appears to have a sizing issue, I'm wondering the best way to get the ifd.bin to correct the issue myself.
I found where osbmk extracts the ME bin from a Lenovo firmware patch, but I didn't find anything similar for getting your own ifd.bin (sketchy-looking Google results aside).
Just thinking out loud: the t440p `ifd.bin` blob is committed part of the osbmk repo. But looking at the obwww repo, this commit added documentation talking about how to extract or download the binary blobs from board: <https://notabug.org/osboot/osbwww/commit/85dbbf2abb4207e206a15669797ad76ccf46517f>
The docs referenced this command:
```
./build descriptors intel_blobs t440p_12mb /path/to/12mb_backup.rom
```
...but running that just comes back with a `USAGE` message.
Running:
```
./build descriptors list
```
...shows:
```
Available options for mode 'descriptors':
ich9m
```
Running the command with `ich9m`:
```
./build descriptors ich9m t440p_12mb /path/to/12mb_backup.rom
```
Appears to perform operations with ich9utils, but I'm sort of out of my depth in terms of what to do with it.
Given that my device is already flashed (likely with an invalid `ifd.bin`), and the `ifd.bin` provided with the osbmk repo appears to have a sizing issue, I'm wondering the best way to get the `ifd.bin` to correct the issue myself.
I found where osbmk extracts the ME bin from a Lenovo firmware patch, but I didn't find anything similar for getting your own `ifd.bin` (sketchy-looking Google results aside).
The firmware descriptor for this board is manually modified, which may have caused the issue. I pulled the ifd from a donor board with the factory 9.0 ME version. Since Lenovo only offers updates for download (not the factory version) I manually resized the region's to match the size of the newer ME automatically downloaded in osbmk.
You are on the right track to try manually extracting the blobs and flashing with that instead. I forgot to update the documentation when I cleaned up the way blobs are dealt with. The correct command is
./blobutil extract
Rather than
./build descriptors
The firmware descriptor for this board is manually modified, which may have caused the issue. I pulled the ifd from a donor board with the factory 9.0 ME version. Since Lenovo only offers updates for download (not the factory version) I manually resized the region's to match the size of the newer ME automatically downloaded in osbmk.
You are on the right track to try manually extracting the blobs and flashing with that instead. I forgot to update the documentation when I cleaned up the way blobs are dealt with. The correct command is
`./blobutil extract`
Rather than
`./build descriptors`
In case it helps to fix this problem, flashing the most recent release of Skulls coreboot distribution on the T440p laptop makes the problem disappear: suspend and resume work normally as expected.
In case it helps to fix this problem, flashing the most recent release of Skulls coreboot distribution on the T440p laptop makes the problem disappear: suspend and resume work normally as expected.
Hello there, i just have same issue and was trying to build rom with original ifd.bin and me extracted from original rom. But issue is there, even i have builded the obmk with a commit before ifd.bin was added, still same issue. Laptop gets restarted after suspend.
Hello there, i just have same issue and was trying to build rom with original ifd.bin and me extracted from original rom. But issue is there, even i have builded the obmk with a commit before ifd.bin was added, still same issue. Laptop gets restarted after suspend.
In this last week I tried building from the new LBMK scripts after the libreboot / osboot project merge (see: https://notabug.org/libreboot/lbmk.git). However, the image produced had the same issue as before.
@Nazar65, thanks for the confirmation.
In this last week I tried building from the new LBMK scripts after the libreboot / osboot project merge (see: https://notabug.org/libreboot/lbmk.git). However, the image produced had the same issue as before.
For what it's worth, I was able to get a working "wake from suspend" using the Skulls coreboot (at version 1.0.6, if that helps): https://github.com/merge/skulls/releases/tag/1.0.6 (thanks, @dovsienko)
I will switch to coreboot for now, since there it is working as well for me, i have followed this instructions https://blog.0xcb.dev/lenovo-t440p-coreboot/ with latest coreboot suspend and wakeup works just fine. Will wait for some updates here.
I will switch to coreboot for now, since there it is working as well for me, i have followed this instructions https://blog.0xcb.dev/lenovo-t440p-coreboot/ with latest coreboot suspend and wakeup works just fine. Will wait for some updates here.
Hello i managed to fix this by building my own coreboot with my .config file, looks like the problem is in one of the config there. I have builded my own coreboot and then added grub payload from libreboot with configurations and etc. And now suspend and wake works just fine
Hello i managed to fix this by building my own coreboot with my .config file, looks like the problem is in one of the config there. I have builded my own coreboot and then added grub payload from libreboot with configurations and etc. And now suspend and wake works just fine
Nazar65 can you let me know the coreboot version you built from and the sha1sum hash of the ifd you used. If I have those I can figure out how to solve this issue permanently in lbmk. I'll leave instructions below on how to get that info, but please don't be offended if you think I'm treating you like a n00b, I'm only trying to make things quick and easy for you. I really would appreciate your help.
For the coreboot revision:git log -1 | awk 'NR==1 {print $2}' in the coreboot directory.
For the ifd hash:sha1sum /path/to/descriptor
Nazar65 can you let me know the coreboot version you built from and the sha1sum hash of the ifd you used. If I have those I can figure out how to solve this issue permanently in lbmk. I'll leave instructions below on how to get that info, but please don't be offended if you think I'm treating you like a n00b, I'm only trying to make things quick and easy for you. I really would appreciate your help.
**For the coreboot revision:** `git log -1 | awk 'NR==1 {print $2}'` in the coreboot directory.
**For the ifd hash:** `sha1sum /path/to/descriptor`
Hello @shmalebx9 the git revision of coreboot is "f4c97ea131" and the sha1sum for ifd is "71f9d5eee3" it was extracted from the original rom
Hello @shmalebx9 the git revision of coreboot is "f4c97ea131944c7be940b35361407e4b63a14faf" and the sha1sum for ifd is "71f9d5eee376a637879d035ef82f52982a43e8e8" it was extracted from the original rom
Using a t440p, with Debian bullseye (kernel 5.10.140-1), finding that:
systemctl suspend
),Searching online, I found some guidance with coreboot issue #412 (https://ticket.coreboot.org/issues/412), implying that there could be a potential issue with flashing method could cause the issue.
I attempted to re-flash osboot using the following:
...after which, the flashrom prompted indicated
VERIFIED
. However, resume-from-suspend issue persists (enters into restart/normal boot routine after suspend).See full cbmem output below, but following coreboot issue #412, the sizing issue log warnings are present in this excerpt:
...full cbmem output (as attachments don't seem to allow .log files):
Some updates from the coreboot folks here: https://ticket.coreboot.org/issues/432
Their investigations seem to point to a potential issue with the ifd blob as used within the osbmk process.
I noticed that the documentation for the ifd for the t440p referenced the need to track down the ifd yourself: https://osboot.org/docs/build/#optional-extract-binary-blobs
...but during my osbmk compilation step this appeared to have been taken care of as a result of the ifd.bin extracted from a Lenovo source. This ticket seems to have addressed this, but maybe introduced something to related here: #129
Thank you for a detailed bug report, I have the same issue with an osboot-flashed T440p (already discussed with the developer over e-mail and IRC) and would be interested to have the bug fix too when it is available.
The bug reproduces for me using both Ubuntu 22.04 and Debian 11 with all updates, the only difference (AFAIR) is that in Debian the suspended laptop powers on by keyboard and in Ubuntu it does not. In either case the power button continues to fade in and out after the botched resume. The BIOS identifies itself as follows:
Just thinking out loud: the t440p
ifd.bin
blob is committed part of the osbmk repo. But looking at the obwww repo, this commit added documentation talking about how to extract or download the binary blobs from board:85dbbf2abb
The docs referenced this command:
...but running that just comes back with a
USAGE
message.Running:
...shows:
Running the command with
ich9m
:Appears to perform operations with ich9utils, but I'm sort of out of my depth in terms of what to do with it.
Given that my device is already flashed (likely with an invalid
ifd.bin
), and theifd.bin
provided with the osbmk repo appears to have a sizing issue, I'm wondering the best way to get theifd.bin
to correct the issue myself.I found where osbmk extracts the ME bin from a Lenovo firmware patch, but I didn't find anything similar for getting your own
ifd.bin
(sketchy-looking Google results aside).The firmware descriptor for this board is manually modified, which may have caused the issue. I pulled the ifd from a donor board with the factory 9.0 ME version. Since Lenovo only offers updates for download (not the factory version) I manually resized the region's to match the size of the newer ME automatically downloaded in osbmk.
You are on the right track to try manually extracting the blobs and flashing with that instead. I forgot to update the documentation when I cleaned up the way blobs are dealt with. The correct command is
./blobutil extract
Rather than
./build descriptors
In case it helps to fix this problem, flashing the most recent release of Skulls coreboot distribution on the T440p laptop makes the problem disappear: suspend and resume work normally as expected.
Hello there, i just have same issue and was trying to build rom with original ifd.bin and me extracted from original rom. But issue is there, even i have builded the obmk with a commit before ifd.bin was added, still same issue. Laptop gets restarted after suspend.
@Nazar65, thanks for the confirmation.
In this last week I tried building from the new LBMK scripts after the libreboot / osboot project merge (see: https://notabug.org/libreboot/lbmk.git). However, the image produced had the same issue as before.
For what it's worth, I was able to get a working "wake from suspend" using the Skulls coreboot (at version 1.0.6, if that helps): https://github.com/merge/skulls/releases/tag/1.0.6 (thanks, @dovsienko)
I will switch to coreboot for now, since there it is working as well for me, i have followed this instructions https://blog.0xcb.dev/lenovo-t440p-coreboot/ with latest coreboot suspend and wakeup works just fine. Will wait for some updates here.
Hello i managed to fix this by building my own coreboot with my .config file, looks like the problem is in one of the config there. I have builded my own coreboot and then added grub payload from libreboot with configurations and etc. And now suspend and wake works just fine
Nazar65 can you let me know the coreboot version you built from and the sha1sum hash of the ifd you used. If I have those I can figure out how to solve this issue permanently in lbmk. I'll leave instructions below on how to get that info, but please don't be offended if you think I'm treating you like a n00b, I'm only trying to make things quick and easy for you. I really would appreciate your help.
For the coreboot revision:
git log -1 | awk 'NR==1 {print $2}'
in the coreboot directory.For the ifd hash:
sha1sum /path/to/descriptor
Hello @shmalebx9 the git revision of coreboot is "
f4c97ea131
" and the sha1sum for ifd is "71f9d5eee3
" it was extracted from the original rom