Myles Watson schrieb:

On Sun, May 31, 2009 at 12:10 PM, Patrick Georgi <patrick@georgi-clan.de> wrote:

...

Hi,

attached patch changes the bootblock generation for CBFS images. It uses coreboot.rom (padded and all), but defaults to smaller fallback/normal image sizes. It requires changes to each CBFS aware mainboard config (and requires adaption on conversion), but it fixes using normal image (as the offsets are calculated correctly).

I thought the next step was normal in CBFS. This doesn't seem to get us closer to that.

The "normal" image is executed with "jmp __normal_image". __normal_image is defined as 8 bytes before the first byte of fallback/coreboot.rom (the reset vector of the normal image). Without this patch, we use fallback/coreboot.strip, which is typically smaller. That's a nice way to automatically reduce the size of the bootblock, but it's hard to figure out its size (without resorting to two link steps and weird calculations inbetween), but __normal_image points to some place where the normal image most likely doesn't reside. Thus, we actually have to change the coreboot.rom's sizes manually (to decrease the bootblock's size) if we want normal to work - we don't do that so far, we simply use coreboot.strip.

...

I tried to get rid of ROM_IMAGE_SIZE and friends, but that'll have to wait until non-CBFS images are gone - maintaining two separate build configurations in a single build system isn't fun.

Until non-CBFS images are gone per board, or for all boards?

I intend to kill the non-CBFS infrastructure some weeks after everything is officially moved over. This patch fixes the last known (to me) regression of CBFS over non-CBFS. So the timeline would be: - this patch + changes to CBFS boards to build correctly - patch to get all boards over to CBFS (test as many of them as possible: I can provide testing for 4 boards by three cpu/chipset vendors + qemu) - wait some weeks - remove non-CBFS code - clean up what's possible Regards, Patrick

Myles Watson schrieb:

Yes. I thought we were going to do something like

cbfs_call("normal"); //totally made up.

What we already do is storing coreboot_ram in CBFS.

Which would look in cbfs for the normal image, decompress it if necessary, and call it.

The first stage is pre-raminit, so we can't decompress or copy it - it must be XIP.

What you're doing makes the normal image work again, but doesn't put it into CBFS.

Ron was working on some support to allow XIP stages in CBFS (uncompressed, but registered in there), but that requires more work. I won't try to hack the build system anymore before non-CBFS is gone: separating the earlier coreboot stages into CBFS would require two different build code paths for that part again, and slowly, that's too much hassle for me. I'll revisit pushing the pre-raminit stage into CBFS after I don't have to care about non-CBFS anymore. By the way, one idea to solve the XIP execution might be to use %cs to allow running the stage from a semi-arbitrary memory location (by setting %cs in a way that addresses in code and ROM layout match again). That could already be looked into now. Patrick

I intend to kill the non-CBFS infrastructure some weeks after everything is officially moved over. I'm not sure how much this buys us. Since we know this is the way we want to go, keeping the non-CBFS stuff around just confuses the issue. I think the fewer commits to kill it, the better.

So the timeline would be:

- this patch + changes to CBFS boards to build correctly - patch to get all boards over to CBFS (test as many of them as possible: I can provide testing for 4 boards by three cpu/chipset vendors + qemu) - remove non-CBFS code - clean up what's possible

The same without "wait some weeks." Things will break during this transition. Let's make it short. Thanks, Myles

The waiting period is not about waiting, but rather careful preparation... In that case I misunderstood the timeline. It looked like a "See if anyone screams" period to me.

Also, there are still spurious bugs in CBFS. Let's make sure they're gone before we cut the bridges. We did that in v3 and it was a disaster. Agreed. I just don't want to prolong the pain or make too many intermediate steps. I think it's easier to say "Everyone test your board because the last commit may have broken it." than to say "Everyone test the next 8 commits." As long as we're sure of the direction we can fix what breaks.

Thanks, Myles