Hi, yes, that is the 30 minute IME watchdog timer. It is unable to verify/initialize.
- A On Sat, 29 Aug 2026 at 22:11 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]
