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

[Carl-Daniel Hailfinger]

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

True.


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

True.


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

Yes!


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

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/