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

[Carl-Daniel Hailfinger]

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
>   

Agreed.


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


> The current approach of having two nearly identical images around made
> sense in the old memory layout, but not with CBFS, in my opinion.
>   

Agreed.


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

Regards,
Carl-Daniel

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