Hi,
I want to contribute to the board status database. For this I did a build from 4.11 branch.
This is flashing from the OS for the first time.
the SPI command I used was: ./flashrom/flashrom -p ch341a_spi -l firmware/orig/X220/x220-orig.bin.layout -i bios -w coreboot/build/coreboot.rom -c MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F
For internal flash I modified this command to this: sudo ./flashrom/flashrom -p internal:boardmismatch=force -l firmware/orig/X220/x220-orig.bin.layout -i bios -w coreboot/build/coreboot.rom -c MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F
But it doesn't work. What am I doing wrong?
thanks
JPT
flashrom v1.1-rc1-125-g728062f on Linux 5.4.0-29-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org
Using region: "bios". Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). coreboot table found at 0xbff6a000. Found chipset "Intel QM67". Enabling flash write... SPI Configuration is locked down. FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. FREG2: Management Engine region (0x00003000-0x004fffff) is locked. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. At least some flash regions are read protected. You have to use a flash layout and include only accessible regions. For write operations, you'll additionally need the --noverify-all switch. See manpage for more details. OK. Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI) mapped at physical address 0x00000000ff800000. This coreboot image (LENOVO:ThinkPad X220) does not appear to be correct for the detected mainboard (X220:ThinkPad X220). Proceeding anyway because user forced us to. Reading old flash chip contents... Transaction error! FAILED.
Solved it already. added --noverify-all this sounds dangerous but it just doesn't verify the areas it did't write. o.O
Am 07.05.20 um 16:43 schrieb JPT:
Hi,
I want to contribute to the board status database. For this I did a build from 4.11 branch.
This is flashing from the OS for the first time.
the SPI command I used was: ./flashrom/flashrom -p ch341a_spi -l firmware/orig/X220/x220-orig.bin.layout -i bios -w coreboot/build/coreboot.rom -c MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F
For internal flash I modified this command to this: sudo ./flashrom/flashrom -p internal:boardmismatch=force -l firmware/orig/X220/x220-orig.bin.layout -i bios -w coreboot/build/coreboot.rom -c MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F
But it doesn't work. What am I doing wrong?
thanks
JPT
flashrom v1.1-rc1-125-g728062f on Linux 5.4.0-29-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org
Using region: "bios". Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). coreboot table found at 0xbff6a000. Found chipset "Intel QM67". Enabling flash write... SPI Configuration is locked down. FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. FREG2: Management Engine region (0x00003000-0x004fffff) is locked. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. At least some flash regions are read protected. You have to use a flash layout and include only accessible regions. For write operations, you'll additionally need the --noverify-all switch. See manpage for more details. OK. Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI) mapped at physical address 0x00000000ff800000. This coreboot image (LENOVO:ThinkPad X220) does not appear to be correct for the detected mainboard (X220:ThinkPad X220). Proceeding anyway because user forced us to. Reading old flash chip contents... Transaction error! FAILED. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi JPT,
The --no-verify-all option is useful when you are flashing an image on Intel platform that has ME and IFD regions locked/read-only. Even if using --ifd -i bios, flashrom will verify whole image against the binary file you passed to flashrom. --no-verify-all option tells flashrom "please verify only the region I told you to flash", so it basically reprograms BIOS region for example, and then verifies only BIOS region against the binary.
Regards,
Hi!
I'd say that flashrom only verifying the section it writes by default would be less surprising behavior than the current behavior.
Regards Felix
Hi,
On 07.05.20 18:11, Felix Held wrote:
I'd say that flashrom only verifying the section it writes by default would be less surprising behavior than the current behavior.
we'd need a distinction between reliable and unreliable programmers first. Because not verifying everything with the latter can be fatal (we don't even know if commands / addresses were correctly received by the flash). And that's just the biggest problem. Restrictions of internal programmers (e.g. Intel) can cause trouble too (what erase command does the PCH send? oops, did the chip ignore the least signi- ficant address bits?).
So, "the section it writes by default" is pretty much unknown. We could still have a better default ofc. In this particular case (Intel restricts reading) we could default to read everything that can be read (usually, parts of the chip that can't be read also can't be written, so that should be safe). But that's a bigger change (very big given flashrom's development pace).
Nico
Hi,
On Thu, May 7, 2020 at 7:13 PM Nico Huber nico.h@gmx.de wrote:
Hi,
On 07.05.20 18:11, Felix Held wrote:
I'd say that flashrom only verifying the section it writes by default would be less surprising behavior than the current behavior.
we'd need a distinction between reliable and unreliable programmers first. Because not verifying everything with the latter can be fatal (we don't even know if commands / addresses were correctly received by the flash). And that's just the biggest problem. Restrictions of internal programmers (e.g. Intel) can cause trouble too (what erase command does the PCH send? oops, did the chip ignore the least signi- ficant address bits?).
Given these risks, I prefer to have safe defaults. It's better to error out early instead of silently corrupting something.
Something I have noted is that flashrom is too verbose by default, and too much text means people are more likely to not read it in detail. If we can't be quieter, maybe we should indent warning and error messages so that they stick out (literally).
So, "the section it writes by default" is pretty much unknown. We could still have a better default ofc. In this particular case (Intel restricts reading) we could default to read everything that can be read (usually, parts of the chip that can't be read also can't be written, so that should be safe). But that's a bigger change (very big given flashrom's development pace).
That can be risky. If people just run flashrom and both reading and verifying complete successfully, they might think that they have a good backup image. However, that will not be the case. If running flashrom without any additional parameters does not work, people might wonder why and end up learning about the read restrictions imposed by the hardware. Maybe we can reach a compromise and make `--ifd` without specifying any regions do such a thing? Even then, we would still need to handle writes...
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Best regards,
Angel
-
Angel Pons -
Felix Held -
JPT -
Michal Zygowski -
Nico Huber