Why does Flashrom 1.3.0 on Thinkpad T440p only show 8MiB of SPI?

[fhvyhjriur]

I expect this question to be able to be answered in the heads project, because Flashrom compiled into heads image and running later from the SPI chip detects 12MiB of combined SPI memory space.
But when running Flasrhom 1.3.0 on Linux boot on same hardware, Flashrom show just 8MiB of combined SPI memory space. This is really a bad issue, because when you flash something else then Heads where no Flashrom that detects 12MiB of SPI is included, you are sort of stuck there. It is not possible to flash again a heads maximized image because you cant flash 12MiB into detected 8MiB of space.

[tlaurion]

t440p tagged board owners: @ThePlexus @srgrint @akunterkontrolle @rbreslow

Any insights on discrepancies of flash chips wrongly detected?

Can someone output in text the differences of reported discovered spi chips from Heads and OS versions?

flashrom -p internal output?

[fhvyhjriur]

I did some testing and on a T420 i tested some hours ago i find out, that the flashrom version build inside heads looks to be newer then version 1.3.0 (current stable flashrom version).
To get more in detail: I had heads on T440p. I boot up a linux and it had shown just 8MiB SPI. Reboot into heads command line and its version of flashrom showed 12MiB SPI. I used the build in flashrom in heads to overwrite heads with libreboot (--ifd -i bios -w libreboot.rom).
I expect now the solution would be to build flashrom-git from sourcecode. I think i would first try out flashrom 1.4.0-rc2 and see if this detect 12MiB instead of 8MiB to have a more useful discovery in this Discussions-topic for upcoming users.

This situation (flashrom 1.3.0 does not detect the full 12MiB inside T440p) was before unknown to heads developers/users?

[tlaurion]

I did some testing and on a T420 i tested some hours ago i find out, that the flashrom version build inside heads looks to be newer then version 1.3.0 (current stable flashrom version).
To get more in detail: I had heads on T440p. I boot up a linux and it had shown just 8MiB SPI. Reboot into heads command line and its version of flashrom showed 12MiB SPI. I used the build in flashrom in heads to overwrite heads with libreboot (--ifd -i bios -w libreboot.rom).
I expect now the solution would be to build flashrom-git from sourcecode. I think i would first try out flashrom 1.4.0-rc2 and see if this detect 12MiB instead of 8MiB to have a more useful discovery in this Discussions-topic for upcoming users.

This situation (flashrom 1.3.0 does not detect the full 12MiB inside T440p) was before unknown to heads developers/users?

Last flashrom version bump was in this commit
a1be4e4

Which points to flashrom commit flashrom/flashrom@1776bb4 (August 23 2023)

And where last commit under 1.3.x branch is from January 2023 https://github.com/flashrom/flashrom/commits/1.3.x

A gentle reminder that everything is documented as code under Heads.

Tldr:
Yes heads is > flashrom 1.3, and 1.3 seems to contain a regression which if reported on proper channel will most probably be fixed in 1.4.x which was release recently. Note the Linux distribution normally stick to one base version of a soft and may or may not port back fixes. This is OS decision and has nothing to do with Heads, which bumps version to support their supported boards and need to be reported upstream not under Heads : Heads doesn't pretend to have capabilities to fix all upstream bugs.

Note: this shows again that less and less people use the t420/x220 that would be needed for this platform to be tested and supported properly from upstream projects and that regressions happen, unnoticed and unfixed.

[fhvyhjriur]

Thanks. This information helped me to further understand the issue and what i should try out. In the next about 6 days the flashrom 1.4.0 stable release would be out and this would be a great opportunity for me to test this new stable version.

[tlaurion]

@fhvyhjriur please provide output as requested.
Highgly doubt that regression will be fixed magically. Hence a search for that chip on the bug report system of flashrom should be done, and if no bug reported, a bug should be reported there prior of release if not already fixed. Collaboration upstream should happen from board owners and traces left here at least.

Thanks.

[tlaurion]

The t420 hardcoded some flashrom specific commands when doing internal flashing see board file and this line specifically.

heads/boards/t420-maximized/t420-maximized.config

Line 68 in 0b494fe

export CONFIG_FLASHROM_OPTIONS="--force --noverify-all -p internal:ich_spi_mode=hwseq"

:

export CONFIG_FLASHROM_OPTIONS="--force --noverify-all -p internal:ich_spi_mode=hwseq"

Please provide command output as requested prior of your answers to move this forward.

[tlaurion]

Sorry I reported traces for board configs of t420, not t440p in prior message.

[tlaurion]

The t440p has two spi flash chips which are combined logically : 8mb+4mb

heads/boards/t440p-maximized/t440p-maximized.config

Line 57 in 0b494fe

BOARD_TARGETS += split_8mb4mb

The t440p doesn't have any specific option specified under board config for flashrom command line override

heads/boards/t440p-maximized/t440p-maximized.config

Line 42 in 0b494fe

export CONFIG_FLASHROM_OPTIONS="-p internal"

The t440p prevents write access to SPI chips with chipset SMI lock (PR0), which makes Heads the sole internal flash upgrader on < Skylake

heads/boards/t440p-maximized/t440p-maximized.config

Line 25 in 0b494fe

export CONFIG_FINALIZE_PLATFORM_LOCKING_PRESKYLAKE=y

Note: the t420 has one single 8mb SPI chip. T440p has two. Not sure what is happening there but hypothesis is that PR0 might interfere with flashrom trying to probe the combined 12mb spi space when PR0 is locked prior if jumping (kexec) into final OS.

Once again, information is missing to get a clear view on what is happening from different OS perspective (Heads vs final OS).

Please do within Heads and final booted OS

• flashrom -p internal

This should give needed input to nullify uncertainty.

---

Note that you can turn off chipset locking protection from Heads config options menu for a single boot (toggle off) : that should change the output given from final booted OS. Nothing I can do here to help more without proper output but lay out this hypothesis. Screenshots or it didn't happen. :)

---

t440p tagged board owners: @ThePlexus @srgrint @akunterkontrolle @rbreslow @fhvyhjriur : please provide some replication output of flashrom to move this issue forward to resolution.

[srgrint]

This is the results of flashrom from the Heads environment on my t440p. Presumably @fhvyhjriur can do likewise from their OS environment.

flashrom -p internal

flashrom on Linux 5.10.5-Heads (x86_64)

flashrom is free software, get the source code atCalibrating delay loop... ΟΚ.

coreboot table found at 0x7f352000.

Found chipset "Intel QM87".

This chipset is marked as untested. If you are using an up-to-date version of flashrom and were (not) able to successfully update your firmware with it, then please email a report to flashrom@flashrom.org including a verbose (-V) log. Thank you!

Enabling flash write... FREGO: Flash Descriptor region (0x00000000-0x00000fff) is read-write.

FREG1: BIOS region (0x00021000-0x00bfffff) is read-write.

FREGZ: Management Engine region (0x00003000-0x00020fff) is read-write. FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write.

Enabling hardware sequencing due to multiple flash chips detected.

OK. Multiple flash components detected, skipping flash identification. Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific) on internal. No operations were specified.

[tlaurion]

@fhvyhjriur ping

[fhvyhjriur]

I am heavy on work at the moment. I have not forgot this discussion here and would continue it as soon as possible.

[fhvyhjriur]

This issue is really strange.
I tried out flashrom 1.4.0 and same result. But i tried on random use a different boot procedure and suddenly it showed the correct output.
When booting normal, i see flashrom output like this:
flashrom 1.4.0 ...
...
Opened /dev/mtd0 successfully
Found Programmer flash chip "Opaque flash chip" (8192 kB ...

In ventoy i was able to boot a live mode where ventoy copy the whole ISO image to memdisk and starts from there on to boot. This is a successfull workaround. Then i have this working flashrom output:

flashrom 1.4.0 ...
...
MTD device 0 type is not "nor"
coreboot table found at ...
Found chipset "Intel QM87"
...
Found Programmer flash chip "Opaque flash chip" (12288 kB ...

@i-c-o-n , would you like to jump in? When flashrom or flashprog is in the heads-bootmode, then it always detects the 12MiB SPI, but always reports about the QM87 chipset:
"This chipset is marked as untested. ..."
There seem to be some additional changes needed to at least remove this blocker-situation where its telling "Opened /dev/mtd0 successfully" and is then fully unusable because reporting wrong SPI size and so on.

[i-c-o-n]

Opened /dev/mtd0 successfully

That's likely the culprit. It's trying to use the kernel MTD driver instead of its own chipset driver (that relies on /dev/mem). The kernel driver for Intel has caused mostly pain in the past, hence we decided to disable the MTD automatism on x86 in flashrom-stable (RIP) and flashprog. I never thought about issues with multiple combined flash chips, actually. I guess the kernel driver probably exposes them separately as /dev/mtd0 and /dev/mtd1. It's just one more issue in a long list of Intel quirks.

So beside the flashrom/flashprog version used, YMMV depending on the kernel and its driver selection. HEADS minimizes the latter, hence is unaffected, so far the theory.

[fhvyhjriur]

So when using the MTD driver, i could ignore the "Opaque flash chip"-naming and just think of it like single chips? On heads its simple thanks to the single files. I could just flash the 8MiB SPI image to the mtd0 and the 4MiB SPI image to mtd1? Or would that be something that would with high chance brick the system? I had never this situation on Ivy Bridge hardware. But its there on haswell hardware. Is there maybe some code somwehre that is telling to not use the kernel MTD driver for ivy bridge in flashrom/flashprog but this is missing on haswell hardware? The haswell hardware like i told is listed in the logfiles of flashrom and flashprog to be untested at the current moment.

[i-c-o-n]

So when using the MTD driver, i could ignore the "Opaque flash chip"-naming and just think of it like single chips? On heads its simple thanks to the single files. I could just flash the 8MiB SPI image to the mtd0 and the 4MiB SPI image to mtd1?

Only if the kernel driver (spi-intel) would work as expected. Which it usually doesn't. I advise against trying.

Is there maybe some code somwehre that is telling to not use the kernel MTD driver for ivy bridge in flashrom/flashprog but this is missing on haswell hardware?

It's the other way around, in the kernel there's probably code that tells it to enable the kernel driver on Haswell.

Like I said this is only adding to a list of issues. It's best to avoid the MTD driver on Intel. Either by using above linked patch or a patched version, e.g. any flashprog.

The haswell hardware like i told is listed in the logfiles of flashrom and flashprog to be untested at the current moment.

Now that I've been told, I can mark QM87 as tested. It's basically a formality, we know the driver works for these old platforms. Just when adding PCI IDs etc. we don't know if those are always correct.