[flashrom] Parallel chips and addressability.
libv at skynet.be
Mon Feb 1 00:08:41 CET 2010
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
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
- 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)
- 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.
- check if the image present or the image that is supposed
to get written is 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.
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
* 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.
More information about the flashrom