Parallel chips and addressability.

[Luc Verhaegen]

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.