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