[LinuxBIOS] [PATCH] v3: add a check for a termination member

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Mon Jan 7 18:08:11 CET 2008

On 07.01.2008 17:40, ron minnich wrote:
> On Jan 7, 2008 1:40 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> Well, we can't use CPU cache, but we can abuse CAR memory as cache
>> (ironic, isn't it? I'll call it CARAC.) for the first few (or all)
>> members in the LAR. The cost estimate would be 8-32 bytes per LAR
>> member, depending on your personal opinion on memory usage vs. speed
>> tradeoff.
> I would rather not walk all of empty space ever at any time. I like
> the end marker best. We can do it many ways, I leave it to you folks,
> but let's try to not look at 2^16-2^4 entries in search of something
> :-)

My cache idea is completely orthogonal to the "walk empty space or not"
lib/lar.c would set up a cache of all LAR entries it encountered so far,
making subsequent lookups almost pure cache memory operations.

> I still find the explicit termination marker very interesting, esp.
> since it is flash rewrite friendly.
> Pointers, let's not do them, instead, if we want such a thing, let's
> do indices. If we start doing pointers, LAR is no longer
> location-independent.

Agreed, but even for indices, the reasoning from my other mail applies.
It is almost impossible to do without erasing unaffected flash sectors.
There is one way to use indices sensibly without erasing the block
containing the previous LAR header, but it will require an erase of the
placeholder member.
No-erase adding of LAR members with the requirement of
no-collateral-erase-ever is not possible unless you allow me to add a
dozen lines of code and uglify the central LAR parsing loop in a way
that nobody ever is going to be able to verify the code. And I need 8
additional bytes in the header. There will be lots of special cases and
people will have a strong urge to start v4 ;-)


More information about the coreboot mailing list