I wouldalso like to report that i have found a few flash chips, that when read or attempted do perform any action on, it tells me that there are multiple chips found:
`dps@vulcan:~$ sudo flashrom --programmer ch341a_spi -r backup.bin flashrom on Linux 5.0.0-36-generic (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 Macronix flash chip "MX25L6405" (8192 kB, SPI) on ch341a_spi. Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) on ch341a_spi. Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on ch341a_spi. Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI) on ch341a_spi. Multiple flash chip definitions match the detected chip(s): "MX25L6405", "MX25L6405D", "MX25L6406E/MX25L6408E", "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" Please specify which chip definition to use with the -c <chipname> option`
what does this mean?
Hi Christopher, This means that Macronix reuses chip IDs for multiple chips with different capabilities (hence why there are multiple chip entries). It's very frustrating. I recommend avoiding Macronix and using a different flash chip vendor if you can.
On Tue, Nov 19, 2019 at 9:45 PM OMGdaDPS christopherbwilliams1990@gmail.com wrote:
ah, ok thank you for explaining this to me. im kinda bummed out on this one, because i was hoping i had just found a 32mb chip lol.
On Nov 20 2019, at 12:48 am, David Hendricks david.hendricks@gmail.com wrote:
i have the latest one from the flashrom.org website, is there one that i could get and build from the libreboot site?
On Nov 20 2019, at 2:26 am, Iru Cai mytbk920423@gmail.com wrote:
On 20.11.19 08:26, Iru Cai wrote:
Rule of thumb: If libreboot does something downstream, it's wrong.
Reading is always safe, no matter which entry is selected. But, depen- ding on the programmer and options used and the reliability of the connection, all hell can break loose if the wrong entry is selected. The problem is that these chips often use the same commands for erasing different block sizes.
For instance, internal flashing on an Intel system where certain SPI commands can be forbidden, if flashrom erases too much by accident and matching erase block commands are not allowed, it will fail to recover.
If, for any reason, --noverify-all is used and flashrom erases too much at the edge of a region, it will also have backed up too little of sur- rounding flash contents.
If the connection is unreliable, flashrom might make wrong assumptions if something fails. This is actually always true, but becomes much worse when the expected erase-block size is wrong.
Nico
-
David Hendricks -
Iru Cai -
Nico Huber -
OMGdaDPS