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

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Oct 1 11:05:25 CEST 2009

On 01.10.2009 10:17, Patrick Georgi wrote:
> Am Donnerstag, den 01.10.2009, 09:44 +0200 schrieb Carl-Daniel
> Hailfinger:
>>> - 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).

Unless I'm mistaken, K8 HT init is done with gcc code in CAR in v3.

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

I still worry about romcc bugs (like sometimes ignoring code lines if
there is not enough whitespace before them) which I can't remember being
fixed (mostly due to the ability to work around them).

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

OK, fully agreed. There is no need to duplicate (or even have 140 copies
of) code which essentially never changes.

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

I see your point.

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

Ah, that makes sense. Thanks for clarifying. I agree with this.

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

No problem. You explained everything in your followup mail and that's
what counts. ;-)

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

Given the current state of the tree, your plans are definitely a hige
improvement. I can still send patches to make startup resemble v3 more
closely on top of this.

> 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
> sure)

Right. So we need two variables:
- One variable (in ROM) says which image is newer
- One variable (in CMOS/NVRAM) helps decide whether to boot the new or
the old image.



More information about the coreboot mailing list