[coreboot] FILO creating filo.conf

Joseph Smith joe at settoplinux.org
Tue Sep 16 00:05:20 CEST 2008




On Tue, 16 Sep 2008 00:01:06 +0200, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 15.09.2008 23:37, Joseph Smith wrote:
>>
>> On Mon, 15 Sep 2008 23:09:01 +0200, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>>> Still, a custom lightweight fs may be better. Or you reuse the no-erase
>>> LAR updating design I created some time ago. The benefit of that LAR
>>> variant is that is it backwards compatible (same struct and no code
>>> changes in lib/lar.c) and works regardless of block size.
>>>
>> Hmm, I will look into this also. Is it a part of libpayload?
>>
> 
> Not yet. Back then, we were not completely sure about the general
> no-erase update design.
> However, I created a new design variant which avoids all unnecessary
> complexity and is so extremely simple that I wonder why I didn't think
> of it earlier. (clear all bits of the first byte of the member name)
> The new variant does have one pitfall, though. To reclaim space for a
> deleted/updated LAR member, you either need to erase all blocks
> "touched" by the member (no problem if filo.conf space is aligned to an
> eraseblock beginning) or resort to a more elaborate updating scheme
> (Sperrfeuer every 16 bytes of deceased member). (Pay no attention to the
> stuff in parentheses, it is a mental note for me.)
> 
> I'll write a short design doc with rationale and patches for libpayload
> after Oct 1. Please ping me if I forget.
> 
> We'll need a write_one_byte_to_flash(u32 addr, u8 byte) function
> provided by a flashrom library, though.
> 
Very cool, thanks :-)
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org





More information about the coreboot mailing list