Issue #432 has been reported by Josh R.
----------------------------------------
Bug #432: t440p reboots on suspend
https://ticket.coreboot.org/issues/432
* Author: Josh R
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2022-10-21
* Affected versions: 4.15
* Related links: https://ticket.coreboot.org/issues/412
* Affected hardware: Lenovo t440p
* Affected OS: Ubuntu 22.04 (Pop OS)
----------------------------------------
Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM).
My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following:
`sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all`
...but that did not seem to do the trick (still "restarts" without resuming from RAM).
Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions).
coreboot version looks like 4.15.204, and flashrom version 1.2-640.
If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart).
Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :)
---Files--------------------------------
cbmem.20221019195923.normal_boot.log (36.2 KB)
cbmem.20221019200724.from_suspend.log (36.3 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #19 has been updated by Martin Roth.
Some utilities and payload code still uses bare unsigned, but this is completely fixed in the coreboot src/ directory.
There are unfortunately some false positives within names and comments, so the lint test should be updated in addition to fixing the above issues.
----------------------------------------
Bug #19: Violations of Coding guidelines: All objects should have fully qualified types (unsigned int instead of unsigned)
https://ticket.coreboot.org/issues/19#change-1355
* Author: Martin Roth
* Status: New
* Priority: Normal
* Start date: 2015-12-30
----------------------------------------
Some (most?) of these can be seen using the following command:
grep -Grin 'unsigned' | grep -v 'unsigned[[:space:]]*int\|unsigned[[:space:]]*long\|unsigned[[:space:]]*char\|unsigned[[:space:]]*short'
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #36 has been updated by Martin Roth.
Status changed from New to Closed
No updates in 7 years. Closing.
Please reopen if this is still an issue.
----------------------------------------
Bug #36: x201: stuck ec event
https://ticket.coreboot.org/issues/36#change-1354
* Author: Alexander Couzens
* Status: Closed
* Priority: Normal
* Start date: 2016-03-10
----------------------------------------
sometime the ec on x201 is stuck in a queue which results in all fn buttons and lid isn't working. so most of the acpi events aren't generated.
ec 0x34 bit 3 - attention is disabled temporary might interesting.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #33 has been updated by Martin Roth.
Status changed from New to Closed
Closing as fixed.
----------------------------------------
Bug #33: cbmem utility fails on newer linux kernels "Failed to mmap /dev/mem: Resource temporarily unavailable"
https://ticket.coreboot.org/issues/33#change-1353
* Author: Martin Roth
* Status: Closed
* Priority: Normal
* Start date: 2016-02-05
----------------------------------------
This has been going on for a while. Paul mentioned it here:
https://www.coreboot.org/pipermail/coreboot/2015-September/080383.html
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #27 has been updated by Martin Roth.
Status changed from New to Closed
Marking as closed due to the last update being 7 years old. Please reopen if we have a new update.
----------------------------------------
Bug #27: Windows doesn't like references in ACPI to objects that are only defined later
https://ticket.coreboot.org/issues/27#change-1352
* Author: Patrick Georgi
* Status: Closed
* Priority: Normal
* Start date: 2016-01-29
----------------------------------------
There is some concern about Windows not liking ASL structured like in https://review.coreboot.org/#/c/13506/ because NVSA is defined "after" the OpRegion that uses it.
Needs testing and potentially a tree-wide solution
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #20 has been updated by Martin Roth.
Affected versions 4.18 added
This was completed, but seems like it may now be broken again.
The command 'make test-toolchain' should tell you if the toolchain version you are using is current, but currently reports that the toolchain is up-to-date even when that's not the case.
----------------------------------------
Feature #20: Add make target to check if toolchain is up to date
https://ticket.coreboot.org/issues/20#change-1351
* Author: Timothy Pearson
* Status: In Progress
* Priority: Normal
* Assignee: Martin Roth
* Category: build system
* Start date: 2015-12-30
* Affected versions: 4.18
----------------------------------------
Various automated build/test services use a specific toolchain build for all tests, and have no way to know if the toolchain has been updated and requires a rebuild. This, in turn, means manual intervention is needed for these services every time the toolchain version changes. (unless various hacks involving searching the output text are used, but these are highly suboptimal).
A new make target to check if the built toolchain is completely up to date with the current coreboot versions would be very useful.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #7 has been updated by Matt DeVillier.
Martin Roth wrote in #note-14:
> No updates in 7 years. Closing.
also, gnawty has been supported as a rambi variant since early 2017
----------------------------------------
Feature #7: gnawty support based on acer cb3-111
https://ticket.coreboot.org/issues/7#change-1350
* Author: Alexander Couzens
* Status: Closed
* Priority: Normal
* Assignee: Alexander Couzens
* Category: board support
* Start date: 2015-11-20
----------------------------------------
Adding google gnawty boards.
This board is very similiar to rambi, the only difference known is the ram configuration.
http://review.coreboot.org/#/c/12500https://www.coreboot.org/Board:acer/cb3-111
SeaBIOS hangs with message:
Press F12 ...
but pressing f12 does nothing.
~~Booting ELF payload with openwrt fails because e820 isn't properly passed.~~
Using Linux Payload + x64 kernel openwrt boots up.
---Files--------------------------------
bootup_x86_64_openwrt (60 KB)
vga_bios_hangs (29.1 KB)
dmesg (63.6 KB)
lspci_vvv (10.3 KB)
lspci (789 Bytes)
lspci_vvttnn (716 Bytes)
booting_4.1 (58.7 KB)
booting_4.1_with_ioapic (63.5 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #12 has been updated by Martin Roth.
Status changed from New to Closed
Closing as fixed.
----------------------------------------
Bug #12: Use of CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is a mess
https://ticket.coreboot.org/issues/12#change-1349
* Author: Martin Roth
* Status: Closed
* Priority: Normal
* Start date: 2015-11-27
----------------------------------------
In Kconfig, the symbol MAINBOARD_POWER_ON_AFTER_POWER_FAIL is used in a few platforms. It is a bool. Because it's used in only a few mainboards, for MOST platforms, it's going to be defined as 0 (kconfig bools in coreboot are ALWAYS defined)
Here are those mainboards:
> src/mainboard/samsung/lumpy/Kconfig
> src/mainboard/samsung/stumpy/Kconfig
> src/mainboard/asus/kgpe-d16/Kconfig
> src/mainboard/asus/kfsn4-dre/Kconfig
> src/mainboard/asus/kfsn4-dre_k8/Kconfig
> src/mainboard/msi/ms9652_fam10/Kconfig
In a number of other platforms, CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is used as if it were a standard #define - with three states:
from src/southbridge/intel/bd82x6x/pch.h:
<pre><code class="c">
#define MAINBOARD_POWER_OFF 0
#define MAINBOARD_POWER_ON 1
#define MAINBOARD_POWER_KEEP 2
#ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL
#define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
#endif
</code></pre>
Similar patterns are seen in these files:
> src/southbridge/amd/agesa/hudson/sm.c
> src/southbridge/amd/amd8111/acpi.c
> src/southbridge/amd/pi/hudson/sm.c
> src/southbridge/amd/sb600/sm.c
> src/southbridge/amd/sb700/sm.c
> src/southbridge/amd/sb800/sm.c
> src/southbridge/intel/bd82x6x/pch.h
> src/southbridge/intel/fsp_bd82x6x/pch.h
> src/southbridge/intel/fsp_i89xx/pch.h
> src/southbridge/intel/fsp_rangeley/soc.h
> src/southbridge/intel/i3100/lpc.c
> src/southbridge/intel/i82801dx/i82801dx.h
> src/southbridge/intel/i82801ex/lpc.c
> src/southbridge/intel/i82801gx/i82801gx.h
> src/southbridge/intel/i82801ix/i82801ix.h
> src/southbridge/intel/ibexpeak/pch.h
> src/southbridge/intel/lynxpoint/pch.h
> src/southbridge/nvidia/ck804/lpc.c
> src/southbridge/nvidia/mcp55/lpc.c
> src/southbridge/sis/sis966/lpc.c
> src/southbridge/via/vt8237r/vt8237r.h
> src/superio/nuvoton/nct5572d/superio.c
To fix:
* Make sure definitions are the same across all the platforms and fix them to be consistent if they're not already:
** 0 = power off, 1 = power on, 2 = restore previous state
* Add Kconfig symbols to show which platforms get these options based on which platforms are using the option - Everything using CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL needs to be set.
** HAVE_POWER_STATE_ON_AFTER_FAIL - This gets set for platforms that get the option
** HAVE_POWER_STATE_RESTORE - This gets set for platforms that can actually restore the previous state
* Turn the MAINBOARD_POWER_ON_AFTER_POWER_FAIL bool into a choice menu and move it to a higher level in the Kconfig tree.
* Add the HAVE_POWER_STATE_ON_AFTER_FAIL and HAVE_POWER_STATE_RESTORE to the correct Kconfigs
* Remove all of the existing #define stuff from the above files.
* Remove the current MAINBOARD_POWER_ON_AFTER_POWER_FAIL Kconfig options from their current locations (with the exception of setting new defaults)
* Test.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account