[coreboot] [PATCH]clean up bootblocksize handling in cbfstool, kconfig

Patrick Georgi patrick.georgi at coresystems.de
Thu Nov 12 19:51:51 CET 2009

Am 12.11.2009 19:44, schrieb Myles Watson:
> On Thu, Nov 12, 2009 at 11:39 AM, Patrick Georgi
> <patrick.georgi at coresystems.de>  wrote:
>> Am 12.11.2009 19:13, schrieb Myles Watson:
>>> This patch saves 28K on my s2895, and 55K on qemu.  Anybody have a
>>> strong objection to that?  Are we trying to have bootblock size be
>>> constant for each board?  Does it mess up future plans for backwards
>>> compatibility?
>> Having a good automatic way to minimize the bootblock size is very useful.
>> As for backwards compatibility, what do you mean - updates? The bootblock
>> complicates any attempt to do safe updates currently. This change won't
>> improve it, but it won't make it worse.
> I thought that the master CBFS header was directly above the
> bootblock.
The bootblock can be stored whereever we want. Its location is recorded 
in 0xfffffffc. It can be copied, regenerated, etc. at will, given that 
there's 32byte (or so) of free space somewhere - and we need a special 
"update bootblock" routine in any case, so it could as well take care of 
the master header.

The only "downside" is that the "only 64kb are mapped" test I added 
earlier today won't work anymore, if the bootblock is usually smaller 
than 64kb.

>   If someone wanted to just update the bootblock, but the
> size increased, there would be no way to do that.  I realize that it's
> impossible now, but it seems like that was a future plan at some
> point.
My hope is that at some point, the bootblock is immutable for a board, 
by kicking everything out of it that really, really has to be in there.

More information about the coreboot mailing list