[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
>
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/
More information about the coreboot
mailing list