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