[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