[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Patrick Georgi]

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 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.

If this gets accepted, I'll propose a patch for the (few) CBFS boards, and 
commit them together.

Signed-off-by: Patrick Georgi

Patrick

[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Myles Watson]

On Sun, May 31, 2009 at 12:10 PM, Patrick Georgi  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.
> 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?

Thanks,
Myles

[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Patrick Georgi]

Myles Watson schrieb:
> On Sun, May 31, 2009 at 12:10 PM, Patrick Georgi  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

[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Myles Watson]

> > 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).

Yes.  I thought we were going to do something like

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

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

What you're doing makes the normal image work again, but doesn't put it into
CBFS.
> 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.

Right.
> > 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

This is the place where you put in cbfs_call("normal") ?  Thanks for the
overview.

Acked-by: Myles Watson

Thanks,
Myles

[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Patrick Georgi]

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

[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Myles Watson]

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

Good reminder.  I'm always forgetting that we have different raminits
for fallback or normal.
> 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.

Agreed.
> I'll revisit pushing the pre-raminit stage into CBFS after I don't have to
> care about non-CBFS anymore.

Yes.  I'll agree that's lower priority anyway.
> 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.

OK.

Thanks,
Myles

[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Myles Watson]

> 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

[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Stefan Reinauer]

On 01.06.2009 19:58 Uhr, Myles Watson wrote:
> > 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.

The waiting period is not about waiting, but rather careful
preparation... Not sure we want to cut that.
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.

Stefan

[PATCH] use coreboot.rom for CBFS images, but default to smaller size

[Myles Watson]

> 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