On Tue, 16 Sep 2008 00:01:06 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@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@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 :-)