The 30-minute reset is a well-known watchdog timer that expires when the ME firmware is corrupted or missing. This has nothing to do with coreboot (or edk2 payload), your OS, etc.
Restore your stock ME firmware and the issue should resolve itself. On Sat, Aug 29, 2026 at 11:41 AM ikattana via coreboot < [email protected]> wrote: > Hello coreboot community, > > I'm ikattana and this is my currently diagnosing in my Lenovo ThinkPad > T440p running with coreboot 26.06 & an EDK2 payload. > > I want to be transparent about the methodology: I am doing the diagnostic > work with ChatGPT as an assistant. I use it mainly to organize the > investigation, understand firmware layers, prepare read-only commands and > interpret results. > > *Important distinction:* all logs, register values, hashes, firmware > dumps and .config values listed below are real outputs obtained directly > from my T440p or from firmware images that I previously read from its SPI > chips. > The explanations and interpretations of those values are provisional and > may be wrong, so I would especially appreciate review from people familiar > with Haswell/Lynx Point and Intel ME. > > I am deliberately avoiding further firmware writes until the cause is > better understood. > > *Main symptom* > > The T440p boots coreboot, EDK2 and Ubuntu successfully, but the entire > system resets abruptly after approximately 30 minutes. > > I also tested leaving the T440p inside EDK2 without booting Linux. The > reset still occurs at approximately the same time. > > Because of that, I currently consider Linux unlikely to be the primary > cause of the reset. > > *Hardware / firmware* > > - Lenovo ThinkPad T440p > - Haswell / Lynx Point > - coreboot 26.06 > - EDK2 payload > > SPI flash: > > - U113: Winbond W25Q64FV, 8 MiB > - U49: Winbond W25Q32FV, 4 MiB > > Coreboot was flashed only to the 4 MiB U49 chip. > > U113 was read and backed up, but was not written during this process. > > *Observed Intel MEI / HECI runtime failure* > > PCI: > > 00:16.0 Communication controller: Intel 8 Series/C220 Series Chipset > Family MEI Controller #1 [8086:8c3a] > > Subsystem: Lenovo ThinkPad T440p [17aa:220e] > > Kernel output: > > mei mei0: H_RST is set = 0x80000015 > > mei mei0: wait hw ready failed > > mei mei0: hw_start failed ret = -62 fw status = 00003026 00080000 ... > > mei mei0: reset: reached maximal consecutive resets: disabling the device > > mei_me 0000:00:16.0: init hw failure > > mei_me 0000:00:16.0: initialization failed > > /dev/mei0 is not created. > > *Direct PCI register reads* > > These values were read directly from PCI configuration space: > > 0x40 = 0x00003026 > > 0x44 = 0x80010020 > > 0x48 = 0x00080000 > > 0x4c = 0x70000001 > > My current interpretation is that ME does not complete initialization and > HECI/MEI never reaches a usable HW READY state, but I would like this > interpretation reviewed. > > *Stored U113 / Intel ME evidence* > > The following checks were performed only against firmware images backed up > from U113. > > Intel Flash Descriptor: > > IFD signature = 0x0FF0A55A > > Region map: > > IFD 0x000000-0x000fff > > GbE 0x001000-0x002fff > > ME 0x003000-0x4fffff > > BIOS 0x500000-0xbfffff > > The ME region contains: > > - $FPT at ME + 0x10 > - FPT checksum = 0x00 > - 27 FPT entries > - all parsed partition boundaries remain within the ME region > - FTPR at 0x160000, size 0x0b0000 > - NFTP at 0x210000 > - $MN2 manifests present > - reported ME version 9.0.31.1487 > - FTPR RSA signature validated successfully > - AltMeDisable bit not set > > Flash Master permissions also appear to allow Intel ME to read its own ME > region. > > UMA / memory-related values also appear coherent from the checks performed > so far. > > Again, these are *observed values and validation results*. Any conclusion > that the complete ME image is healthy is still only an interpretation, not > something I want to claim as proven. > > *Backup consistency* > > The saved physical U113 dump and the first 8 MiB of the reconstructed 12 > MiB full image have identical SHA256 values. > > The ME regions extracted from both also have identical SHA256 values. > > The generated coreboot.rom, however, does not contain the same lower 8 > MiB/ME contents, which appears consistent with the fact that the build was > intended to provide the BIOS/Coreboot region while U113 was left untouched. > > *Recovered coreboot build configuration* > > From the actual saved .config: > > CONFIG_BOARD_LENOVO_THINKPAD_T440P=y > > CONFIG_ROM_SIZE=0x00c00000 > > CONFIG_CBFS_SIZE=0x700000 > > CONFIG_SOUTHBRIDGE_INTEL_LYNXPOINT=y > > CONFIG_DISABLE_ME_PCI=y > > CONFIG_MAINBOARD_USES_IFD_GBE_REGION=y > > # CONFIG_HAVE_IFD_BIN is not set > > I did not find ME_CLEANER, HAVE_ME_BIN, or an explicit ME replacement > option in that saved configuration. > > *Current working hypothesis* > > This is the part I consider *interpretation, not established fact*: > > The stored ME region appears structurally coherent from the checks above, > while the runtime ME state is abnormal very early during initialization. > > I therefore currently suspect either: > > - an ME internal/state/configuration problem not detected by the > structural checks, > - a Lynx Point / coreboot ME initialization issue, > - or some interaction between the existing ME state and the coreboot > 26.06 initialization path. > > I am also investigating whether that ME failure could explain the > approximately 30-minute platform reset, especially because the same reset > happens while staying in EDK2 before Linux is started. > > I do *not* want to claim that causality has been proven yet. > > *Questions* > > 1. How should HFS=0x00003026 and HFS2=0x00080000 be interpreted on > Lynx Point / ME9? > 2. Do these values point to a known ME9 failure state? > 3. Could coreboot 26.06's Lynx Point ME initialization path contribute > to this state? > 4. Is CONFIG_DISABLE_ME_PCI=y relevant here, or would that normally > only be acted upon after ME has initialized successfully? > 5. Is ME firmware 9.0.31.1487 appropriate for this T440p? > 6. Is there another ME partition/state check you would recommend > before considering any rewrite of U113? > 7. Does the approximately 30-minute reset pattern fit a known ME > initialization failure on this generation? > > My priority is to recover stable operation while keeping coreboot if > possible. > > Before writing U113 or changing the ME region, I would like to understand > whether the evidence above points to an ME image/state problem or to > coreboot/Lynx Point initialization. > > Any corrections to my interpretation are very welcome. The raw outputs and > firmware evidence are the part I consider authoritative here; the > diagnostic conclusions are still open for review. > > Thanks for your help. > > Enviado desde un correo electrónico seguro de Proton Mail > <https://proton.me/mail/home>. > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
