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

Patrick Georgi patrick at georgi-clan.de
Thu Oct 1 10:17:42 CEST 2009

Am Donnerstag, den 01.10.2009, 09:44 +0200 schrieb Carl-Daniel
> > - 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.
I have a CBFS walker in ASM, and I'd prefer using romcc for some things
(eg. early HT init on K8).

> 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.
ROMCC is bad if it's used for the entire ram init code. Early init is
supposed to be a small piece of code, and that's what ROMCC is quite
good at.

>  Others may disagree with
> me, but I thought I'd say this before the decision is finalized.
I won't force the issue - but there must be a better way than having 140
copies of "if cmos say good, run normal, otherwise run fallback" around.
That's my main concern.

Having an immutable bootblock is only an attempt to have a more robust
update mechanism. Given that I personally won't update systems without
having recovery gear around, it doesn't actually affect me. But if we're
trying to enable updates, I'd rather have them as safe as possible, and
that's what this experiment is about.

> > - 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.
If two images should be configurable in one pass, Kconfig must be
adapted for that - and it won't be pretty.

I'd rather have the system build _one_ image in one pass, and allow the
user to configure whether a new image is built, or an existing one is
extended with a new image.

This issue is more about what we can express sensibly in Kconfig, than
what the build system can do. The latter is more flexible, but it's
outright lost without being told what it's supposed to do.

> > 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
> system.
Right, but the makefile will only build what can be configured, so
they're really quite interdependent. I'm mixing up terminology there,
I'm sorry about that.

> > 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?
The prototype has a ROMCC/assembly bootblock, and raminit in CBFS (where
CAR would end up, too). So it's somewhat different from v3.

I started out from the QEmu decision code. In the end, it is an
experiment, and it's mostly based around my opinions, as outlined above.

But the only thing I _really_ care about is getting rid of the jmp
fallback_image junk in every single mainboard directory.

> 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.
While we need some other way to determine which is the newest image (ie.
the one we'd preferably use), we also need a way to figure out that the
newest version didn't actually work on the last attempt. I know no other
place than CMOS to store such information (ie. mark boot as unclean,
boot into coreboot stage, which marks boot as clean right before
entering the payload - or maybe delegating that to the payload, not


More information about the coreboot mailing list