I'm using a Raspberry Pi Zero and SOIC clip to communicate with a MX25L12873F chip, using flashrom built from master branch (1b1066e).
Reading the chip is working fine, no matter how many times I do a read operation, the resulting firmware image is correct. However, I'm unable to write to the chip:
======================================================================== flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1000 -c \ MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F \ -w firmware.bin --ifd -i fd -i bios -i me --noverify-all -VVV -o out.log Initializing linux_spi programmer Using device /dev/spidev0.0 Using 1000kHz clock get_max_kernel_buf_size: Using value from \ /sys/module/spidev/parameters/bufsiz as max buffer size. linux_spi_init: max_kernel_buf_size: 4096 The following protocols are supported: SPI. Probing for Macronix \ MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F, \ 16384 kB: programmer_map_flash_region: mapping \ MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F from \ 0xff000000 to 0x00000000 RDID returned 0xc2 0x20 0x18. compare_id: id1 0xc2, id2 0x2018 Added layout entry 00000000 - 00ffffff named complete flash Found Macronix flash chip \ "MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F" \ (16384 kB, SPI) on linux_spi. Chip status register is 0x7c. Chip status register: Status Register Write Disable (SRWD, SRP, ...) \ is not set Chip status register: Bit 6 is set Chip status register: Block Protect 3 (BP3) is set Chip status register: Block Protect 2 (BP2) is set Chip status register: Block Protect 1 (BP1) is set Chip status register: Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set programmer_unmap_flash_region: unmapped 0x00000000 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). programmer_map_flash_region: mapping \ MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F from \ 0xff000000 to 0x00000000 Some block protection in effect, disabling... \ Block protection could not be disabled! Chip status register is 0x7c. Chip status register: Status Register Write Disable (SRWD, SRP, ...) \ is not set Chip status register: Bit 6 is set Chip status register: Block Protect 3 (BP3) is set Chip status register: Block Protect 2 (BP2) is set Chip status register: Block Protect 1 (BP1) is set Chip status register: Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set Reading ich descriptor... done. layout_from_ich_descriptors():1367, returned with value -1. Couldn't parse the descriptor! Illegal instruction ========================================================================
On an identical system, I have been using the flashrom internal programmer to write the same firmware image without any errors parsing the descriptor.
Any ideas why this happens? I'm a doing something wrong?
Thanks.
Best regards, Pete Smith
Hello Pete,
On 29.03.22 06:15, Pete Smith via flashrom wrote:
I'm using a Raspberry Pi Zero and SOIC clip to communicate with a MX25L12873F chip, using flashrom built from master branch (1b1066e).
Reading the chip is working fine, no matter how many times I do a read operation, the resulting firmware image is correct.
how did you confirm that it's correct? If you have a reference image, you can also run `ich_descriptors_tool` on it. If it doesn't see a descriptor, there probably is none.
Nico
Hello Nico,
On Tuesday, March 29th, 2022 at 1:55 PM, Nico Huber wrote:
how did you confirm that it's correct? If you have a reference image, you can also run `ich_descriptors_tool` on it. If it doesn't see a descriptor, there probably is none.
Reading the chip will produce an image with identical SHA-256 hash everytime. I assumed that if the connection was flaky or other problems, this would not be the case. Running ich_descriptors_tool on the dumped image, indeed reveal that there is no descriptor:
The flash image has a size of 16777216 [0x1000000] bytes. Image not in descriptor mode.
However, the motherboard I'm working on is unbootable, so it could be that the dump is correct, but firmware in chip is very corrupted. Running strings on the dumped image also prints many readable strings e.g.:
Intel(R) Core(TM) i7 Intel(R) Xeon(R) Intel(R) Corporation EFI_LOAD_ERROR EFI_INVALID_PARAMETER EFI_UNSUPPORTED #PF - Page-Fault #GP - General Protection #SS - Stack Fault Fault
The valid firmware image I'm trying to write (firmware.bin) does contain a descriptor:
The flash image has a size of 16777216 [0x1000000] bytes. Assuming chipset '100 series Sunrise Point'. === Content Section === FLVALSIG 0x0ff0a55a FLMAP0 0x00040003 FLMAP1 0x5a100208 FLMAP2 0x00310330
--- Details --- NR (Number of Regions): 10 FRBA (Flash Region Base Address): 0x040 ...
The chipset is the 200-series "Union Lake", as not currently supported by the ich_descriptor_tool, but apart from that, everything looks fine.
Right now it occurs to me that I have misunderstood the --ifd flag. Just reading the output of --help, I assumed that the descriptor was read from the firmware image, but manpage says "...The on-chip descriptor will be read and used to generate the layout." Yikes, that won't work if the descriptor is corrupted on-chip.
I only wanted to flash fd, bios and me region to avoid overwriting correct MAC address in gbe region. Of course this could also be corrupted on-chip, but I would like to give it a try before overwriting everything.
The ifdtool from coreboot has a --layout flag that I can run on the firmware image and generate a layout file, that I think flashrom can use with the --layout option. Then I only need to change --ifd to --layout layoutfile.txt and maybe it will work...
Annoyingly, I can't try this right away as the system is located in a remote location, so I will have to travel first. But does the above sound as a plausible reason for the problem?
Best regards, Pete Smith
Hello Pete,
On 30.03.22 07:19, Pete Smith wrote:
The chipset is the 200-series "Union Lake", as not currently supported by the ich_descriptor_tool, but apart from that, everything looks fine.
should be compatible, IIRC we just don't mention Union Point explicitly.
Right now it occurs to me that I have misunderstood the --ifd flag. Just reading the output of --help, I assumed that the descriptor was read from the firmware image, but manpage says "...The on-chip descriptor will be read and used to generate the layout." Yikes, that won't work if the descriptor is corrupted on-chip.
I only wanted to flash fd, bios and me region to avoid overwriting correct MAC address in gbe region. Of course this could also be corrupted on-chip, but I would like to give it a try before overwriting everything.
The ifdtool from coreboot has a --layout flag that I can run on the firmware image and generate a layout file, that I think flashrom can use with the --layout option. Then I only need to change --ifd to --layout layoutfile.txt and maybe it will work...
What I do in this case is to start with the most simple layout:
0000:0fff fd
and then flash only the descriptor to make `--ifd` work again. `ifdtool` may work too but has some quirks: sometimes you have to tell it what descriptor generation to expect and it doesn't warn if you don't, AIUI.
Nico
On Wednesday, March 30th, 2022 at 10:42 AM, Nico Huber wrote:
What I do in this case is to start with the most simple layout:
0000:0fff fd
and then flash only the descriptor to make `--ifd` work again. `ifdtool` may work too but has some quirks: sometimes you have to tell it what descriptor generation to expect and it doesn't warn if you don't, AIUI.
Hello Nico,
I have finally been able to try your suggestion, and I belive that my original problem has been solved. However, I'm not yet able to flash the chip. I don't know if this should be posted as a new question to the mailing list, but as this problem could also just be a rookie mistake by me, I will try to post it here first.
The chip I'm trying to flash is the Macronix MX25L12873F which support was added for in commit 16661d82e3c17e224a21c109572b0834ec63a17c / Change-Id I59c8067f15b5ceac5a2e2f8fe93431a465f17e23 on 14/07-21.
I'm using flashrom built from master branch (7dcd0de).
The SOIC clip is high quality with very good grip, and so far I have never had any communication problems with the chip. I have made sure that everything is wired correctly and also tried with different values for spispeed, but the error is the same:
======================================================================== Command line (14 args): flashrom -p \ linux_spi:dev=/dev/spidev0.0,spispeed=1000 -c \ MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F -w \ firmware.bin -l rom.layout -i fd --noverify-all -V -o out.log Added layout entry 00000000 - 00000fff named fd Using region: "fd". Initializing linux_spi programmer Using device /dev/spidev0.0 Using 1000kHz clock get_max_kernel_buf_size: Using value from \ /sys/module/spidev/parameters/bufsiz as max buffer size. linux_spi_init: max_kernel_buf_size: 4096 The following protocols are supported: SPI. Probing for Macronix \ MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F, 16384 kB: \ compare_id: id1 0xc2, id2 0x2018 Added layout entry 00000000 - 00ffffff named complete flash Found Macronix flash chip \ "MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F" \ (16384 kB, SPI) on linux_spi. Chip status register is 0x7c. Chip status register: Status Register Write Disable (SRWD, SRP, ...) \ is not set Chip status register: Bit 6 is set Chip status register: Block Protect 3 (BP3) is set Chip status register: Block Protect 2 (BP2) is set Chip status register: Block Protect 1 (BP1) is set Chip status register: Block Protect 0 (BP0) is 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). Some block protection in effect, disabling... Block protection could \ not be disabled! Chip status register is 0x7c. Chip status register: Status Register Write Disable (SRWD, SRP, ...) \ is not set Chip status register: Bit 6 is set Chip status register: Block Protect 3 (BP3) is set Chip status register: Block Protect 2 (BP2) is set Chip status register: Block Protect 1 (BP1) is set Chip status register: Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set Reading old flash chip contents... done. Erasing and writing flash chip... Trying erase function 0... \ 0x000000-0x000fff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, \ failed byte count from 0x00000000-0x00000fff: 0x1000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase \ function. Trying erase function 1... 0x000000-0x007fff:RREFAILED at 0x00000000! \ Expected=0xff, Found=0x00, failed byte count from \ 0x00000000-0x00007fff: 0x8000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase \ function. Trying erase function 2... 0x000000-0x00ffff:RREFAILED at 0x00000000! \ Expected=0xff, Found=0x00, failed byte count from \ 0x00000000-0x0000ffff: 0x10000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase \ function. Trying erase function 3... 0x000000-0xffffff:RREFAILED at 0x00000000! \ Expected=0xff, Found=0x00, failed byte count from \ 0x00000000-0x00ffffff: 0xae98a3 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase \ function. Trying erase function 4... 0x000000-0xffffff:RREFAILED at 0x00000000! \ Expected=0xff, Found=0x00, failed byte count from \ 0x00000000-0x00ffffff: 0xae98a3 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase \ function. Trying erase function 5... not defined. Looking for another erase \ function. Trying erase function 6... not defined. Looking for another erase \ function. Trying erase function 7... not defined. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Your flash chip is in an unknown state. Please report this to the mailing list at flashrom@flashrom.org or on IRC (see https://www.flashrom.org/Contact for details), thanks! ========================================================================
What could I be doing wrong, that causes this new error?
Thanks.
Best regards, Pete Smith
Hi Pete,
On 05.04.22 06:08, Pete Smith wrote:
On Wednesday, March 30th, 2022 at 10:42 AM, Nico Huber wrote: The chip I'm trying to flash is the Macronix MX25L12873F which support was added for in commit 16661d82e3c17e224a21c109572b0834ec63a17c / Change-Id I59c8067f15b5ceac5a2e2f8fe93431a465f17e23 on 14/07-21.
...
Chip status register is 0x7c. Chip status register: Status Register Write Disable (SRWD, SRP, ...) \ is not set Chip status register: Bit 6 is set Chip status register: Block Protect 3 (BP3) is set Chip status register: Block Protect 2 (BP2) is set Chip status register: Block Protect 1 (BP1) is set Chip status register: Block Protect 0 (BP0) is 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). Some block protection in effect, disabling... Block protection could \ not be disabled!
this is likely the source of the problem. For some reason, flashrom can't write the BP* (block protection) bits. I've been looking into the datasheet and couldn't find a possible explanation. This particular model doesn't seem to have a hardware write protection. I guess either something is wrong with the hardware, could be wrong voltage / insuf- ficient power, or there's some advanced protection mechanism enabled.
You could test if communication is 100% reliable, e.g. read once, verify multiple times. Also, measure the voltage at the flash chip.
Adding Nikolai in CC as he might have an idea about the BP bits.
Nico
On Tuesday, April 5th, 2022 at 9:42 AM, Nico Huber wrote:
You could test if communication is 100% reliable, e.g. read once, verify multiple times. Also, measure the voltage at the flash chip.
Hello Nico,
Just an update as I think my second issue has also been solved, and maybe this can be of use to others.
First I connected an external power supply to the Raspberry Pi, this did not change anything, but this connection was still reliable, I tried to verify a read 20 times in a row without problems.
I then disconnected the 3.3V connection and tried to power the chip from normal PSU as explained in the flashrom ISP wiki, but this seems not to work with this board, as I was unable to communicate with chip no matter what I did.
Because of my ignorance, I did not mention or consider that the motherboard is a Gigabyte with DualBIOS (GA-H270N), I just checked the chips were identical and didn't think more of that. With this board there is no way to control anything about the DualBIOS function, e.g. by switch or using jumpers. The motherboard has been in a reboot loop for over a month, and before using an external programmer, I tried the procedures found online related to these boards, e.g. shorting pins, resetting CMOS etc. to no avail.
Until now I have only been trying to write the M_BIOS chip, but then I tried the B_BIOS chip and lo and behold, the flash was successful. No problems with disabling block protection and erase function 0 was able to erase the chip. After powering on, the system rebooted 1 or 2 times and then booted normally.
I think the M_BIOS was overwritten automatically with content from B_BIOS during the inital reboots, but I need to investigate this further. Flashrom requires a patch for '-p internal:dualbiosindex=' to work with this board, I will submit it after testing everything works.
After doing some research, I have found out that on boards with multiple flash chips, you should connect 3.3V to "Chip Select" (CS) of the other chip while flashing. Does this sound right? Would flashrom be able to disable block protection on M_BIOS if I had done this? I almost want to to take apart the whole system again and try just to find out.
Best regards, Pete Smith
-
Nico Huber -
Pete Smith