flashrom

flashrom@flashrom.org

5 participants
9154 discussions

"Intel P55" with PCI ID 8086:3b02 successful read / Apple iMac11,3 2010 firmware chip
by Wolf Dieter Brandt 29 Nov '22

29 Nov '22

flashrom v1.2 on Linux 5.10.0-8-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.6.4, GCC 9.2.1 20200224, little endian Command line (7 args): flashrom --programmer internal -V -c MX25L3273E -r UEV.bin Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing internal programmer /sys/class/mtd/mtd0 does not exist No coreboot table found. Using Internal DMI decoder. No DMI table found. Found chipset "Intel P55" with PCI ID 8086:3b02. 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(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0xc61: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: not enabled 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x4 0x7fffffff/0x7fffffff FWH IDSEL: 0x5 0x7fffffff/0x7fffffff FWH IDSEL: 0x6 0x7fffffff/0x7fffffff FWH IDSEL: 0x7 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching disabled, caching enabled, BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled SPIBAR = 0x00007f5fce36a000 + 0x3800 0x04: 0xe008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 SPI Configuration is locked down. Reading OPCODES... done 0x06: 0x0004 (HSFC) HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0 0x50: 0x0000ffff (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write. 0x58: 0x03ff0021 FREG1: BIOS region (0x00021000-0x003fffff) is read-write. 0x5C: 0x00200001 FREG2: Management Engine region (0x00001000-0x00020fff) is read-write. 0x74: 0x82c10021 PR0: Warning: 0x00021000-0x002c1fff is read-only. 0x78: 0x9fff02e6 PR1: Warning: 0x002e6000-0x01ffffff is read-only. At least some flash regions are write protected. For write operations, you should use a flash layout and include only writable regions. See manpage for more details. 0x90: 0x04 (SSFS) SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 0x91: 0xf97f20 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=2, DBC=63, SME=0, SCF=1 0x94: 0x5006 (PREOP) 0x96: 0x0c6c (OPTYPE) 0x98: 0x0103029f (OPMENU) 0x9c: 0x00002005 (OPMENU+4) 0xa0: 0x00000000 (BBAR) 0xc4: 0x00000000 (LVSCC) LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=0 0xc8: 0x00002011 (UVSCC) UVSCC: BES=0x1, WG=0, WSR=0, WEWS=1, EO=0x20 0xd0: 0x00000000 (FPB) OK. The following protocols are supported: SPI. Probing for Macronix MX25L3273E, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2016 Found Macronix flash chip "MX25L3273E" (4096 kB, SPI) mapped at physical address 0x00000000ffc00000. Chip status register is 0x00. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is not set Chip status register: Bit 6 is not set Chip status register: Block Protect 3 (BP3) is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is not set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). Reading flash... done. Restoring MMIO space at 0x7f5fce36d8a0 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

Instructions for download, verify, and authenticate.
by 66Avanti＠outlook.com 29 Nov '22

29 Nov '22

To: flashrom(a)flashrom.org Hello, everyone! Here's a suggestion for a way to make flashrom easier to use: Please include simple and explicit instructions on how to verify and authenticate a download of flashrom. Linux Mint's installation instructions are an excellent example of clear instructions that non-technical users can follow easily. Linux Mint provides these steps: 1. Download the operating system (which is a ".iso" file), the sha256sum checksum (in a file named "sha256sum.txt"), and the Linux Mint digital signature/key (in a file named "sha256sum.txt.gpg"). All three files are available from the single download page. 2. Put the three files in the same folder in computer memory. 3. In a terminal screen, run "sha256sum *.iso". 4. Compare the result of the hash function in step 3 with the contents of the file named "sha256sum.txt". If they match, the iso has no errors. 5. Import the Linux Mint signing key by running this command in the terminal screen: "gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-key"27DE B156 44C6 B3CF 3BD7 D291 300F 846B A25B AE09". 6. In a terminal screen, run "gpg --verify sha256sum.txt.gpg sha256sum.txt". The results will say whether the source of the download is legitimate. The Linux Mint page is at: https://linux-mint-installation-guide.readthedocs.io/en/latest/verify.html The flashrom download page does not provide the sha256sum output. (I could not find it.) I ran "sha256sum flashrom" in a Linux terminal screen and used Google to search for the outcome and for more information. The Google search for the sha256sum (that I computed) returned seventeen hits. None of the hits was from an official flashrom.org man page. Most of them seem to be conversation between developers, not information for end-users. The "launchpad" webpage in the Google hits is from Ubuntu, but it has this note at the top: "flashrom (1.2-1) unstable; urgency=medium". That note suggests that the version of flashrom with the checksum "e1f8d..." is unstable and should not be used; at the least, it requires user care to install v. 1.2, not v. 1.2-1. The flashrom download page provides the "GPG signature" and a 40-digit hexadecimal number ("584A...") that seems to be related to the gpg signature, but neither one is in a readily usable form, and the correct instruction - with the correct syntax - to use them is not presented. (I read dozens of articles on "gpg" but did not find the necessary command to use. Like many people who need to use flashrom, I am not a computer code writer, so I need your help to get the command and syntax right.) Although I could download flashrom by using the Linux Mint Package Manager and then have reasonable confidence that the source of the file is legitimate, I would still need to confirm the sha256sum to be sure that the downloaded copy of the file is 100% correct. The final and reliable checksum should be posted on the manual's download page (along with instructions for signature verification) so that users won't need to search for the checksum and so that users can be certain that they have the right checksum and a reliable copy of flashrom. A defective operating system will cause problems, but it won't turn a computer into a brick. One mistake in the ROM could make the computer useless, so checking integrity and authenticity is a critical task. I sincerely appreciate all of the work that the flashrom team has put into a very worthwhile project, and I hope that these suggestions will make flashrom useful to many more people. - Joe

1 0

FAILED: Protectli vp4650
by Omkhar Arasaratnam 27 Nov '22

27 Nov '22

git cloned https://github.com/protectli-root/protectli-firmware-updater/tree/070b83f4d… Attempted to run on my Protectcli vp4650 - it failed ______ ______ ______ ______ ______ ______ ______ __ __ /\ == \ /\ == \ /\ __ \ /\__ _\ /\ ___\ /\ ___\ /\__ _\ /\ \ /\ \ \ \ _-/ \ \ __< \ \ \/\ \ \/_/\ \/ \ \ __\ \ \ \____ \/_/\ \/ \ \ \____ \ \ \ \ \_\ \ \_\ \_\ \ \_____\ \ \_\ \ \_____\ \ \_____\ \ \_\ \ \_____\ \ \_\ \/_/ \/_/ /_/ \/_____/ \/_/ \/_____/ \/_____/ \/_/ \/_____/ \/_/ _________________________________________________________________________________________ =========================================FlashLi========================================= --Version 1.1.28-- Device: Protectli vp4650 CPU: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz BIOS Mode: EFI Available BIOS: [1]: ami (vp4650_YW6L2516_221102.bin) Enter the [#] of an image file, or [0] to quit. Flashing will not begin yet > 1 ********************************************!******************************************** Are you sure you would like to flash this device? Flashing new firmware onto any hardware is potentially dangerous in that if the procedure is interrupted or otherwise not able to complete, your hardware may be rendered useless. Please proceed with caution. If there are any questions, please contact Protectli support BEFORE proceeding. Unless there is a compelling reason to update the BIOS, we recommend to stay with your current known working BIOS version ********************************************!******************************************** Acknowledgement Yes [Y]: Y flashrom v1.2-326-gf57486e on Linux 6.0.0-4-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found chipset "Intel Comet Lake U Premium". Enabling flash write... Warning: BIOS region SMM protection is enabled! Warning: Setting BIOS Control at 0xdc from 0xaa to 0x89 failed. New value is 0xaa. SPI Configuration is locked down. Enabling hardware sequencing because some important opcode is locked. PROBLEMS, continuing anyway Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Reading old flash chip contents... done. Erasing and writing flash chip... Transaction error between offset 0x00600000 and 0x00600fff (= 0x00600000 + 4095)! Reading current flash chip contents... done. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Apparently at least some data has changed. Your flash chip is in an unknown state. Get help on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with the subject "FAILED: <your board name>"! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! BIOS Flash failed, is this script running with root permissions? Please try again, but if problems persist, please contact Protectli. TODO: Collect info and display instructions on how to submit a Github issue. --oa

2 2

flashrom dev meeting notes week 45/2022
by Anastasia Klimchuk 27 Nov '22

27 Nov '22

(apologies this one is sent out of chronological order, it was completely missed. but... better late than never) # 2th November, 21:00 - 22:00 UTC+0 Attendees: Felix, Angel, Edward, Anastasia, Stefan ## Decision summary * Angel: See the ALL CAPS text at the start of the page. Thanks to aklm for the idea. We do not talk about others if they’re not present on the call. Mentioning people who did something, for context, is fine. * We created the release branch today and will be doing all the fixes/reverts into the release branch. Meanwhile development continues on master. * Initially we wanted to create a release branch with the name “1.3.x” but then we discovered a branch with this name already exists (created an unknown number of months ago, and in an unknown state). Therefore, Angel created branch with name “1.3.x_infdev” and the plan is to rename the current 1.3.x to 1.3.x_old (to keep whatever is in there) and then rename 1.3.x_infdev to 1.3.x. * Angel made [https://review.coreboot.org/68823](https://review.coreboot.org/68823) to deal with the sb600spi problems (“Promontory” support is broken), at least for the v1.3 release. A long-term plan is to fix the code. ## Agenda * When can we make a release branch? * Aklm: can we make a plan? * Branch master ? * [Angel] We need this for the release: [https://review.coreboot.org/68823](https://review.coreboot.org/68823) * Angel decided to create the `1.3.x_infdev` branch ([“infdev” is a reference to a Minecraft version](https://minecraft.fandom.com/wiki/Java_Edition_Infdev)) to be used as flashrom v1.3 release candidate. The already-present `1.3.x` branch is left untouched as we don’t know for sure whose it is. When the v1.3 release is done, Angel suggests keeping the `1.3.x_infdev` branch as a memento of the struggle. * Felix will figure out the status of the 1.3.x branch and what’s about it. -- Anastasia.

2 1

Starting over; how would you do it?
by Nico Huber 21 Nov '22

21 Nov '22

Hi flashrom folks, I've been thinking more and more about returning to a stable flashrom branch lately; starting over from v1.2 seems reasonable. The question is, how to proceed on such a branch? There are, of course, many cherries on the current master branch. But in what order should they be picked? And should they be picked first? What about even older patches? There are still many patches on patch- work [1] and also on Gerrit. Some of them probably also cherries. When I was still more of an official maintainer for flashrom, I tried to keep track of these things. And lately, a look at the wiki history told me that maintainers before me cared too [2]. But I guess nothing happened in that direction in the past 3 years. Depending on the progress with the 1.3 release, I'd suggest to either try to merge things in historical order, or start with the easy cher- ries on the current master branch (new chips and programmers that are ready; for a small release and then focus on a short release cycle). WDYT? Cheers, Nico [1] https://patchwork.coreboot.org/project/flashrom/list/ [2] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=2252#…

4 7

flashrom dev meeting notes week 46/2022
by Felix Singer 21 Nov '22

21 Nov '22

# 16th November, 21:00 - 22:00 UTC+0 Attendees: Anastasia, Felix ## Decision summary * Everything is in the bugtracker: some tickets have been unlinked from release, some others are waiting for clarification. We added comments to all tickets that we went through. ## Agenda * [aklm] Lets go through bugs in the release list [https://ticket.coreboot.org/issues/353](https://ticket.coreboot.org/issues/… * We went through the list and stopped at 372

1 0

[PATCH] Add support for XMC XM25QH128A. Read/write tested.
by Stijn Segers 21 Nov '22

21 Nov '22

Signed-off-by: Stijn Segers <foss(a)volatilesystems.org> --- flashchips.c | 49 ++++++++++++++++++++++++++++++++++++++++++++ include/flashchips.h | 1 + 2 files changed, 50 insertions(+) diff --git a/flashchips.c b/flashchips.c index 47a37ee..e3fd368 100644 --- a/flashchips.c +++ b/flashchips.c @@ -19707,6 +19707,55 @@ const struct flashchip flashchips[] = { .voltage = {1650, 1950}, }, + { + .vendor = "XMC", + .name = "XM25QH128A", + .bustype = BUS_SPI, + .manufacture_id = ST_ID, + .model_id = XMC_XM25QH128A, + .total_size = 16384, + .page_size = 256, + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI | FEATURE_WRSR2, + .tested = TEST_OK_PREW, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 4096} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 512} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 256} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {16 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {16 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + } + }, + .printlock = spi_prettyprint_status_register_plain, + .unlock = spi_disable_blockprotect, + .write = spi_chip_write_256, + .read = spi_chip_read, + .voltage = {2700, 3600}, + .reg_bits = + { + .srp = {STATUS1, 7, RW}, + .srl = {STATUS2, 0, RW}, + .bp = {{STATUS1, 2, RW}, {STATUS1, 3, RW}, {STATUS1, 4, RW}}, + .tb = {STATUS1, 5, RW}, + .sec = {STATUS1, 6, RW}, + .cmp = {STATUS2, 6, RW}, + }, + .decode_range = decode_range_spi25, + }, + + { .vendor = "XMC", .name = "XM25QH128C", diff --git a/include/flashchips.h b/include/flashchips.h index 5df42dc..8317da7 100644 --- a/include/flashchips.h +++ b/include/flashchips.h @@ -818,6 +818,7 @@ #define ST_M45PE16 0x4015 #define XMC_XM25QH64C 0x4017 #define XMC_XM25QU64C 0x4117 +#define XMC_XM25QH128A 0x7018 #define XMC_XM25QH128C 0x4018 #define XMC_XM25QU128C 0x4118 #define XMC_XM25QH256C 0x4019 -- 2.36.1

3 8

Status of Meson support, where are we? (was Re: Build systems and `uinstall` option)
by Nico Huber 14 Nov '22

14 Nov '22

Hi all, it feels like this deserves its own thread. I was a little surprised by the news that we are already ready to deprecate Make. Hopefully, I'm just not up to date and this is the case! If I'm horribly off track, please ignore the following. IIRC, we said this would be the case if we can do everything with Meson what we can do with Make (due to lack of knowing what the latter can, we made a list of target environments that we need to support at least) and Meson produces the same binaries as Make. Are we there yet? My last state wrt. the more special target environments like lib- payload was that it seems feasible, but I haven't seen a PoC yet. On 10.11.22 17:43, Felix Singer wrote: > The Make build system is going to be deprecated with the next release > and it is going to be dropped with the release after that. "next release" being the one that just started or the next after that? iow. does this mean deprecate with flashrom 1.3 and drop in 1.4? > We discussed the Make build system in many meetings now and we all > agreed that we won't add any more features to it. That means its > current feature state is frozen and it doesn't get any additional > functionality, just bug fixes, refactorings or adjustments as far as > they are really necessary. Was this ever discussed on / announced to the ML? My status was that this was of the "nobody objected during some meeting" decision kind. Nico

5 7

Build systems and `uinstall` option
by Joursoir 14 Nov '22

14 Nov '22

Hello everyone, I wonder why there is no 'uninstall' option in the flashrom's Makefile? Is it just an oversight? Or do we have a reason for that? The same question is related to the meson script. -- Joursoir

5 12

Future development and release process
by Nico Huber 11 Nov '22

11 Nov '22

Hi flashrom fellows, some of us have picked a new release process for flashrom 1.3 that ignores the problems of the master branch but will attend to them on a separate branch. This leaves us without a strategy to get future releases done with less hassle. It also feels quite frustrating be- cause I fear it takes incentive away to fix the master branch. And hence increases the incentive for myself to abandon said branch. During a phone call with Felix, I explained the options I see roughly as follows. There are probably more options, feel free to discuss others as well. These just came to my head. 1. Full reset: Branch off 1.2.x before the master branch started to make trouble. Also reset the Gerrit privileges to a state where only people got merge rights after they earned trust by the pre- existing maintainers (people with those rights); to prevent that history repeats itself. So far this seemed to be unacceptable by the Google team. The rest of this email will assume that we won't be doing this. If it turns out I'm wrong, this would be my preferred solution and we won't have to discuss anything below. 2. Try harder: Keep working on the current master branch. Try to fix the process as we go along. This is unacceptable to me. We have tried this already and I have not seen things getting better. Building up on a broken state is most often harder than rewinding to a good state and starting new things from scratch. Working on this branch has not been fun since flashrom 1.2. Beside that, the master branch hasn't provided any- thing that I could use in my day job for years (not as a develop- ment tool and definitely not in our products). 3. Compromise: The current situation evolved due to a highly dynamic development process that is roughly the opposite of what we had before we tried to converge upstream and chromium development. Also, adding many new developers that are used to a very different process requires a lot of communication (IMO) which didn't happen. We could accept these different development strategies and work on two branches. Not(!) competing branches but branches that complement each other. Something like this was actually proposed before [1]. The rough idea: we could have a 'stable' branch and a more dynamic one. Back then we called the latter 'staging'. Merging commits to the 'stable' branch would be limited to maintainers who know flash- rom well enough and trust each other. To be honest, I wouldn't care much what happens on the 'staging' branch, who gets to merge etc. There were often reservations if this could work without diverging the branches. But there are strategies to avoid it. For instance, a regular `git merge` onto the 'staging' branch could avoid that. To give it a good start, I would also suggest to base a 'stable' branch on 1.2.x. 4. Divide: If we don't find a compromise, I'll have to continue my work on a new branch. I wouldn't care then if things diverge. Details depend mostly on who would like to join the effort. It would likely start on 1.2.x with things added from the current master branch (might get things through review again, or also cherry pick real cherries directly without going through Gerrit). Quite unappealing because it would push contributors to choose a branch. And we would have to discuss how to deal with future releases. You may notice that most of my ideas suggest rewinding to 1.2.x. Beside easing further development on a reasonable code base, there is one more thing driving me: The master branch contains many commits that caused awkward feelings. I think it would help working together if we wouldn't be reminded of them all the time. Nico [1] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=2252#…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom