Uwe just added another chip to the board enable to track what the board can address when writing.
Addressing issues only happen when using parallel flash, when not all the lines are wired up.
Now, the biggest use case of flashrom is people updating the factory inserted flashchip to a new bios version. Only the corebooters would stick a bigger parallel chip in their motherboards and try to flash that. The number of reports of board addressing issues is going to be insanely low, compared to the high number of possibly "faulty" boards out there.
My point in this email is: Tracking chipset addressing issues is fine, and necessary. But tracking board addressing issues is a fight against windmills, only a few people will run into this. We are better off trying to detect wrap around, before anything is actually harmed.
This is not foolproof, as we might end up in a sitution where things did go wrong, and we only afterwards were able to tell that it was address wrap around. In this case, we should be as graceful as possible.
Here is some logic for such detection: - probing works, so we know how big the flash is and what type it is. It's parallel, and the size is not bigger than the chipset addressing size. - read in the flash. * if all 0xFF: - it's either been erased, and we can just write it destructively. - or the bottom half is erased, and the top half isn't. We can write to it anyway, as we will only write this part. Erase is the only bit we should be scared off. (1) * else: - compare top and bottom half (even when the chip wraps around 4x, this is good enough). * if mismatched: * No wrapping! and we are free to write. * else - check if the image present or the image that is supposed to get written is coreboot. * coreboot: Complain loudly and continue anyway. Catting the image twice to match the size is not that nice. But the corebooter should not be protected like average joe user. * else: Complain loudly and bail out. Tell the user to use a --force or somesuch option to write this thing. If the user still proceeds, it's his own fault.
Now, from this logic we might proceed to writing, which is always preceded by an erase.
(1) is the scary bit here. We do not want to erase the whole chip when we can only address half. But, since the visible half is all 0xFF, we do not need to erase at all. Since we do not erase this chip at all, we can only end up overwriting the empty, visible part of the chip anyway.
If we do an erase on a wrapped board, then we might be able to do a blockwise erase, and see the first block in both halves change. And as such detect wrap around too.
So when subsequently writing a wrapped around chip, we will see the following: * If the image is a catted coreboot, then verify will work (we're wrapping anyway). Upon reboot, it will Just Work. * If not, verify will fail... And... We can see the wrapping too, and tell the user about it.
We can then provide information on bailout on how to execute a blockwise restore (with blockwise erase -- do we have this for all parallel chips?) of the original image.
Luc Verhaegen.