[coreboot] FILO creating filo.conf

[Carl-Daniel Hailfinger]

On 16.09.2008 00:19, Joseph Smith wrote:
>
> 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?
>   

That would not help for the case where erase is successful and write
fails. To cover that case, you have to write filo.conf to one free
block, then erase the other one and write there. Never erase both blocks
at once.
You'll see how everything fits together once I post my design doc and patch.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/