[coreboot] fallback/normal support [PATCH]Remove non-CBFS

[Patrick Georgi]

Am Mittwoch, den 30.09.2009, 16:07 -0700 schrieb ron minnich:
> Yes, I'm sorry, we keep board support, but stop worrying about huge
> SPI anbd weird accessing of it.
> 
> As for fallback: we really need to bring it back at some point. I'm
> speaking as someone whose life was saved because I did not destroy a
> 1024-node cluster with a bad bios image.
> 
> CBFS will give us a normal/fallback setup that people can understand.
It will, but right now, CBFS is worse off than old-style.

I dropped fallback/normal support in Kconfig deliberately, not because
it is hard, but due to the current situation being a mess (~140 copies
of the fallback-or-normal decision function with minor changes), and
that we don't have a plan on how to safely update a CBFS image anyway.

Once we have a plan that's actually safe, does away with the copy&paste
(and the fallback/normal // failover/fallback/normal duality while we're
at it), I'm all for it.
But please not now, with the mess we have.

My plan for it, pending any better solution:
- unify the decision stuff into a single place
- move everything but the decision stuff out of the bootblock (so it
  essentially becomes immutable across updates)
- extend kconfig so it knows how to update existing images (by adding
  new files)
- somehow make flashrom smart enough to safely update the flash

The idea is that Kconfig continues to build only one image, but allows
to add to such an image later, when it's actually time to carry two
images.
The current approach of having two nearly identical images around made
sense in the old memory layout, but not with CBFS, in my opinion.

I have a prototype of the moving-code-around part of it done, on the
QEmu target. It runs raminit from a cbfs file, linked to a fixed address
within cbfs, which avoids weird compiler tricks. CBFS is only used to
allow multiple such images to coexist without the bootblock having to
know their addresses.

Open issues are:
We need early rom mapping and CMOS access for all boards. So far, only
the boards with failover layout are somewhat guaranteed to have code for
that.


Patrick