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

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Oct 1 09:44:21 CEST 2009

On 01.10.2009 09:09, Patrick Georgi wrote:
> Am Mittwoch, den 30.09.2009, 16:07 -0700 schrieb ron minnich:
>> CBFS will give us a normal/fallback setup that people can understand.
> It will, but right now, CBFS is worse off than old-style.
> [...]
> 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)

This means we either need a CBFS walker in ASM or compile it with ROMCC.
Even if that is possible (and IIRC you already have code for this) it
strikes me as a bad idea. I want to have as little asm code as possible
and I want to keep ROMCC out of the CAR images. Others may disagree with
me, but I thought I'd say this before the decision is finalized.

> - extend kconfig so it knows how to update existing images (by adding
>   new files)

Sorry, I don't understand this. Did you mean the makefiles? I see no
relation between fallback/normal and Kconfig.

> - somehow make flashrom smart enough to safely update the flash

Patches to add partial erase support for some chips are pending since
quite some time. We need more flashrom reviewers.

> 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.

Ah. I always thought of Kconfig as a configuration system, not a build

> 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.

Is that the v3 model?

> 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.

Early ROM mapping: Yes. Early CMOS access... hm maybe. Please note that
CMOS access will not solve the issue of deciding which image to boot
unless we decide to forbid clearing CMOS with a jumper. The information
about which image part is newer needs to be somewhere in the ROM image.
See my other mail in this thread for a bit more details.



More information about the coreboot mailing list