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