[LinuxBIOS] [PATCH] v3: add a check for a termination member
stepan at coresystems.de
Thu Jan 10 14:36:12 CET 2008
* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [080107 14:37]:
> >> 2. Explicit free space covering lar member is fine, but to add any new
> >> file to the archive, you have to erase the part covered by the exlusive
> >> space.
> > I don't think this is such a bit problem. Lar could remove this entry
> > automatically, and recreate it. This is not more special code in lar
> > than 1. But I start thinking that those two are pretty much the same in
> > the end.
> Yes, 1 and 2 are very similar. Your proposal is almost exactly what I
> had in mind. This "dummy" member would be removed once a file was added
> to the lar and the new entry would "overwrite" the dummy header. If we
> have an explicit size in the dummy header, we can point to the next
> header easily without having to stop. However, once we use an explicit
> size (setting some bits to 0), we have to erase the flash block to add a
> new entry in place of the dummy.
One plea though: What you describe usually only happens in a (currently)
very rare case. That is the case where the "free" entry falls exactly on
a flash block border.
Sure. We could have gaps to match up flash chip borders again. But this
would re-introduce the problem of having to slowly walk a lot of space all
Also, a potential update might as well exchange modules instead of just
adding modules that were not there before. This will potentially shift
all files in the lar, making it necessary to reflash the complete flash
> If we don't specify the size and keep
> all header entries (except magic) at value 0xff (all bits set), we still
> can write the new archive member without erasing because setting bits to
> 0 is always possible.
I am not convinced that safing flash erase cycles on bios updates is
worth any design considerations. With one BIOS update a day, even
deleting all flash blocks makes an average SST chip live at least 273
years. Do we need to extend that?
> My proposed code change is not very flexible and really only serves as
> "end of interesting lar members" marker, but it is flash-friendly.
> Besides that, the code can be overridden so if you really want to look
> at the boot block, you can do so easily.
So that would be another runtime parameter?
> > What about a linked list in the header? Each file could explicitly point
> > to the next file. If the pointer is 0 or -1, we stop.
> Nice idea, but it may not work in all cases. Requirements for this to
> work cleanly are:
> - The next pointer needs to have all bits set to 1 in the "stop pointer"
> case, or it is impossible to add a member after the member with a stop
> pointer without erasing the sector containing the header with the stop
Oh my idea was to have the bootblock have a "next" member of -1. So
there would always be a next member with 0 and 1 bits except for the
last one (that will not allow you to put one behind it anyways, due to
the reset vector on the x86 architecture)
Keep in mind that currently flashrom ALWAYS erases the complete flash
chip except for some esoteric uses of the PMC PM49FL004.
No, I am not saying that we should keep a good concept out of LinuxBIOS
just because one of the tools can not cope with this yet. But I fail to
see the whole picture in the solution yet.
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
More information about the coreboot