[coreboot] [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 <patrick at 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