Re: [OpenBIOS] More comments and a proposal for priorities

[John Labovitz]

Markus Kaufmann  said:
> A BIOS isn't something that you change daily like the newest
> developer kernel. Once you have a perfect BIOS, you should never
> change it.

to interject a philosophical point here: this is why we're doing an
*open* BIOS project -- to rid ourselves of the accepted myth that Thou
Shalt Never Change The BIOS (unless the manufacturer tells you to, via
an upgrade).

yes, we should make it clear that BIOS changes are dangerous and could
result in a nonbooting system, but that doesn't mean that someone who
got some fancy new file system, device, etc., shouldn't be able to
boot directly off it once the BIOS extension is available and
installed.

however, i do agree with the general point of not cluttering up the
new BIOS (and our time devoted to this project) with too many
features; things like grub-in-bios should definitely be considered
options that are worked on in parallel or sequential to the core code,
and compiled/linked in optionally by the user or distribution.

john

---
OpenBIOS -- http://www.linkscape.net/openbios/
[e-mail]   Body: un/subscribe
Problems?  [e-mail]

More comments and a proposal for priorities

[Michael Miller]

John Labovitz wrote:
> Markus Kaufmann  said:
> > A BIOS isn't something that you change daily like the newest
> > developer kernel. Once you have a perfect BIOS, you should never
> > change it.
>
> to interject a philosophical point here: this is why we're doing an
> *open* BIOS project -- to rid ourselves of the accepted myth that Thou
> Shalt Never Change The BIOS (unless the manufacturer tells you to, via
> an upgrade).
>
> yes, we should make it clear that BIOS changes are dangerous and could
> result in a nonbooting system,

I haven't been following this list for more than a week, so forgive me 
if this has already been addressed.

Don't most of the modern BIOSs use the boot block feature of the flash 
devices to provide a mechanism for recovery when a BIOS update goes bad?
I ported some Phoenix 4.0 source, and this was a feature they used.  How
will it be possible to overwrite an existing BIOS with an OpenBIOS when
the boot block is already locked?  Also, on all of the the MBs that I've 
used in the past two years, the system flash is SMD soldered to the
board, 
so you can't exactly replace the devices easily.

Also, in response to issues of device capacity, some newer BIOSs are
stored 
in a compressed format, and then shadowed as required.  POST is
decompressed 
into shadow RAM, executed and then overwritten by the run-time code.  My 
project with the Phoenix code had an incredible amount of support for
advanced
features on a laptop, and it all fit into a 128K device (using
compression).

michael

---
OpenBIOS -- http://www.linkscape.net/openbios/
[e-mail]   Body: un/subscribe
Problems?  [e-mail]