[coreboot] FILO creating filo.conf

[Joseph Smith]

On Tue, 16 Sep 2008 00:07:02 +0200, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 15.09.2008 23:56, Joseph Smith wrote:
>> On Mon, 15 Sep 2008 14:39:29 -0700, ebiederm at xmission.com (Eric W.
>> Biederman) wrote:
>>
>>> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> writes:
>>>
>>>> On 15.09.2008 22:32, Joseph Smith wrote:
>>>>
>>>>> On Mon, 15 Sep 2008 14:17:11 -0500, Alex Mauer <hawke at hawkesnest.net>
>>>>> wrote:
>>>>>
>>>>>> Carl-Daniel Hailfinger wrote:
>>>>>>
>>>>>>> Some legacy BIOSes seem to use that method. Stuffing a complete
>>>>>>>
>>>>>>> flashrom binary there would be overkill, though.
>>>>>>>
>>>>>>>
>>>>>> He was talking about turning flashrom into a library.  I guess you'd
>>>>>> have to ask him about the details though.
>>>>>>
>>>>>>
>>>>> Well like I said earlier. Why not setup a small jffs2 filesystem in
>>>>>
>>>>> flash to host filo.conf?
>>>>>
>>>> Code complexity and minimum size of jffs2 (5*eraseblocksize (64 kByte
>>>> minimum) according to some tests) are the big problems here. Even if
> the
>>>> code complexity was kept local, allocating 320 kByte of flash for
>>>> filo.conf would be a showstopper. You may be able to get size
>>>> requirements down with hacks and newer jffs2.
>>>>
>>> Well it looked to me when I last looked that 2 flash blocks that you
>>> alternated writing to for BIOS config uses would probably be a good
>>> idea.
>>>
>>> In addition as I recall a lot of SST flash parts had 4K erase blocks.
>>> And some others had a few small erase blocks.  So you can dramatically
>>> get the erase size down.
>>>
>>> The only downside is that you don't get as many erases as if you
>>> had done wear leveling across the entire device.  But for something
>>> you write infrequently it would not be a big deal.
>>>
>> Thanks for the input Eric, this sounds promising :-)
>>
> 
> Yes, I was talking more about JFFS2 limitations (according to jffs2
> mailing list posts) when I mentioned these big erase blocks.
> 
> In theory (if you're willing to risk losing filo.conf on very rare
> occassions of working write and failing write after erase) you could do
> this with one erase block only.
> 
Well, upon startup if filo.conf is copied into a temp memory location and
FILO reads it from there. The only time it writes to flash is when you edit
it and save it. We could also impliment a simple automatic data
verification after it is written to flash, that compairs filo.conf in flash
to filo.conf in memory. And if it doesn't match the user will get an error
message "filo.conf couldn't be saved, please try again". At this point the
user would have to try again.

Also as Eric pointed out we could use two blocks. Except when writing,
write to both of them, kind of like a fall back mirror image??? Does that
make sense?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org