On Mon, 15 Sep 2008 23:09:01 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 15.09.2008 22:32, Joseph Smith wrote:
On Mon, 15 Sep 2008 14:17:11 -0500, Alex Mauer hawke@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.
Wow that would be a showstopper. We would only need one block. I will look into this futher.
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?
We would also have to add support for jffs2 to FILO. But
So the JFFS2 code would live in a library? Sounds OK.
yes.