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/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
