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? We would also have to add support for jffs2 to FILO. But it would work pretty cool. I also found some old posts where Eric Biederman was looking into jffs2 for something else. I'm not sure if he got anywhere with it.
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. 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.
We would also have to add support for jffs2 to FILO. But
So the JFFS2 code would live in a library? Sounds OK.
Regards, Carl-Daniel
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.
Joseph Smith joe@settoplinux.org writes:
Wow that would be a showstopper. We would only need one block. I will look into this futher.
It requires 2 blocks. So that after you can guarantee you don't loose anything while you are erasing a block.
Eric
On Mon, 15 Sep 2008 14:47:50 -0700, ebiederm@xmission.com (Eric W. Biederman) wrote:
Joseph Smith joe@settoplinux.org writes:
Wow that would be a showstopper. We would only need one block. I will
look
into this futher.
It requires 2 blocks. So that after you can guarantee you don't loose anything while you are erasing a block.
Ok, that makes perfect sense.
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.
Regards, Carl-Daniel
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 :-)
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
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.
Eric
On Mon, 15 Sep 2008 14:39:29 -0700, ebiederm@xmission.com (Eric W. Biederman) wrote:
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
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 :-)
On 15.09.2008 23:56, Joseph Smith wrote:
On Mon, 15 Sep 2008 14:39:29 -0700, ebiederm@xmission.com (Eric W. Biederman) wrote:
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
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.
Regards, Carl-Daniel
On Tue, 16 Sep 2008 00:07:02 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 15.09.2008 23:56, Joseph Smith wrote:
On Mon, 15 Sep 2008 14:39:29 -0700, ebiederm@xmission.com (Eric W. Biederman) wrote:
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
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?
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@gmx.net wrote:
On 15.09.2008 23:56, Joseph Smith wrote:
On Mon, 15 Sep 2008 14:39:29 -0700, ebiederm@xmission.com (Eric W. Biederman) wrote:
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
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
You'll see how everything fits together once I post my design doc and patch.
Ok, I will be patient October is not that far away. There is plenty of other parts of FILO I can work on.
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
Note ideally you would be able to fit multiple versions of your data files in the same erase block. So you can take advantage of the fact that you can write to an erase block multiple times between erases.
Eric
On 16.09.2008 00:36, Eric W. Biederman wrote:
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
Note ideally you would be able to fit multiple versions of your data files in the same erase block. So you can take advantage of the fact that you can write to an erase block multiple times between erases.
Absolutely. That's what I had in mind.
Regards, Carl-Daniel
On Tue, 16 Sep 2008 00:59:32 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 16.09.2008 00:36, Eric W. Biederman wrote:
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
Note ideally you would be able to fit multiple versions of your data files in the same erase block. So you can take advantage of the fact that you can write to an erase block multiple times between erases.
Absolutely. That's what I had in mind.
Hmm, very interesting. So ideally we could add a unique identifier each time filo.conf is written. Something like filo.conf.001, filo.conf.002 and so on. This way if the new config fails you would still have the previous to revert back to, correct?
On 16.09.2008 01:57, Joseph Smith wrote:
On Tue, 16 Sep 2008 00:59:32 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 16.09.2008 00:36, Eric W. Biederman wrote:
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
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.
Note ideally you would be able to fit multiple versions of your data files in the same erase block. So you can take advantage of the fact that you can write to an erase block multiple times between erases.
Absolutely. That's what I had in mind.
Hmm, very interesting. So ideally we could add a unique identifier each time filo.conf is written. Something like filo.conf.001, filo.conf.002 and so on. This way if the new config fails you would still have the previous to revert back to, correct?
That's a possible solution as well. I had something different in mind. You'll see once I post my design doc and patch. Since you're leading the filo.conf storage effort, you get to choose.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
ebiederm＠xmission.com -
Joseph Smith