Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Ben Pfaff
> Why not? Award BIOS does this, Windows 95 does this. As we participate at
> "The right thing to do[tm]" we should be allowed to do so, too.
Microsoft does a lot of things the wrong way :)
Microsoft flashes the BIOS? Then won't our BIOS, or part of it, get
blown away, if we're not careful?
I belive someone mentioned that there limits to how many times you can
flash most chips. If so, then we definitly don't want to do it every
bootup, especially if we are supporting DOS/Windows :)
I don't believe that we were going to flash it every bootup, just
every time that the user decides to changes his boot settings or
whatnot. That should be fewer than 100,000 times, I think, normally.
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
21 years, 12 months
- 1
- 0
Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Chris Arguin
On Tue, 24 Feb 1998, Stefan Reinauer wrote:
> On Fri, 20 Feb 1998, Chris Arguin wrote:
>
> > All things considered, you really don't want to flash the BIOS too often,
> > and especially not behind the users back, so to speak. As pointed out
> > before, we could always reserve a parition on the disk, which would allow
> > for extra code and data. This just strikes me as kinda kludgy...
>
> Why not? Award BIOS does this, Windows 95 does this. As we participate at
> "The right thing to do[tm]" we should be allowed to do so, too.
Microsoft does a lot of things the wrong way :)
> This allows having no disk at all. It could be possible, too, to receive
> BIOS settings over the net (or from disk). Maybe this should be made
> dependent on whether you have a disk or networking card or not.
I think everyone has agreed that this will be modular enough that if you
don't like a feature, don't use it.
I belive someone mentioned that there limits to how many times you can
flash most chips. If so, then we definitly don't want to do it every
bootup, especially if we are supporting DOS/Windows :)
--
Chris Arguin | "Multiple exclamation marks are a sure sign of a
Chris.Arguin(a)unh.edu | diseased mind." - Eric, Terry Pratchett
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
21 years, 12 months
- 2
- 1
Re: [OpenBIOS] Licensing of the code.
by Pavel Machek
Hi!
> > > Or did you mean the actual microcode update, as opposed to the code which
> > > loads it into the CPU?
> >
> > I mean the actual microcode update.
>
> So what is at issue? The only problem I can forsee is getting Intel to
> give us the Microcode update, since they are not usually publically
> available. Intel has had a Microcode fix to the F00F bug for awhile, but
> is only releasing it to specific vendors, many of whom aren't even
> bothering to use it. Wouldn't you like to be able to take that F00F kludge
> out of Linux?
Wrong. F00F workaround is not based on microcode update. And linux
already does it :-).
Pavel
--
I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
21 years, 12 months
- 1
- 0
RE: [OpenBIOS] User-extentions
by William A. Arbaugh
On Saturday, February 21, 1998 2:37 PM, Benjamin Scott [SMTP:hawk@ttlc.net]
wrote:
> >>> Remember that the CMOS settings are stored in the NVRAM, not the
> >>> flash. Now the question is how big is the NVRAM? I don't think we
> >>> have room for this.
> >>
> >> Why do these have to be stored in the NVRAM? Can't we reserve 1K or
> >> so of flash for this sort of thing? Or can't you erase and replace
> >> just a little bit of flash at a time?
> >
> > All things considered, you really don't want to flash the BIOS too
> > often,and especially not behind the users back, so to speak
>
NVRAM varies from machine to machine some of the chips now have several K
available since a number of BIOS' store the ESCD (needed for PnP) info in
NVRAM rather than flash. Most of the flash ROMs support up to 100,000
reprogramming cycles.
> Flashing the BIOS often would be a Bad Thing. There is a limit to how
> often you can write flash ROM. It would take awhile to hit it, but it
> is a real limit. Plus, I think you need to erase flash ROM in banks of
> a certain size. At least, I've seen plenty of stuff that worked that
> way and that way only.
>
You do need to flash in blocks. The size of the block depends on the chip
with the modern chips now having small blocks for storing configuration
information, e.g. the Intel 28F001BX-T (128K)has two 4KByte parameter
blocks plush a 8KB boot block. The boot block has extra HW protection to
prevent accidental reprogramming. This is how the Intel boards prevent you
from completely trashing your bios by mistake and ruining the motherboard
(since the flash chips are not removable on Intel boards).
> If we're going to store boot configuration info on disk, we might as
> well just go back to using LILO. I want something that can boot your
> selected OS without the need of loading from the disk.
>
So do Microsoft and Intel. This is why they've put together the NetPC spec,
and why there is etherboot and netboot now available for Linux. You can
burn/flash a ROM today that you can put in your ethernet card's ROM socket
and do a net boot with out every touching your hard disk. Take a look at
http://www.slug.au/etherboot.
Bill
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
21 years, 12 months
- 2
- 1
Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Alexander Viro
On Sun, 22 Feb 1998, Benjamin Scott wrote:
> Pascal Dornier wrote:
> > 1. DOS translates logical block address into Cylinder / Head / Sector
> > based on BIOS parameters. This is constrained by the 10 bit limit
> > on cylinder and 6 bit on sector number (and sector numbers start
> > at 1, which further mucks things up).
>
> I never really thought about it, but yeah, I guess DOS's sector
> numbers are a form of LBA, aren't they? Is the LBA DOS uses the same as
> the LBA used by IDE? How could it be, given that DOS does start sector
> numbers at 1. Does the BIOS provide an INT13 extension/alternative that
> supports LBA directly? I've never looked at this stuff this closely
> before. Pointers to info are also welcome. :)
No, they aren't. DOS sectors are linear within the partition.
And that's it. It uses damned amount of layers:
linear in the partition -[int25/26]->3D-[BIOS Int13]-->3D----[IDE,EIDE]
\->linear[EIDE,SCSI]
For Linux:
linear -[driver]-->3D----[IDE]
\->linear[EIDE,SCSI]
Moreover, BIOS in LBA mode means the following: translate DOS 3D into
linear and use another set of hardware commands. Interface DOS/BIOS
remains the same.
>
> > 2. The BIOS translates this either into another CHS
>
> What I don't understand is: If DOS and Linux coexisting on the same
> system, and you have BIOS geometry translation on to support DOS, Linux
> still works. But Linux doesn't use the BIOS. So how does that work?
It uses either linear addresses or native drive CHS.
All point of BIOS translation is to map CHS addresses provided by DOS into
the real addresses.
> Does Linux do the remapping instead of the BIOS? There must be a
What should it remap? Who will feed CHS addresses to Linux driver?
For Linux the disk is a 1-dimensional array of sectors. For DOS it's
3-dimensional one. Both are _ordered_. And there is a real disk geometry.
It's also an ordered sequence of sectors. These orderings should be the
same. Everything else is irrelevant. Driver (or BIOS, in DOS case) should
get a position in array (1D for Linux, 3D for DOS) and transform it into
the disk's one. And vice versa. All (E)IDE disks can be addressed as 3D
arrays _and_ there is a command that makes disk to say you its dimensions.
New disks can be addressed as 1D arrays. Now, for DOS we need to choose
some dimensions suitable for DOS (Cyl<=1024, i.e.) and make a
correspondence between DOS 3D coordinates and disk 3D or 1D. The only
tricky part is choosing the dimensions for DOS, for correspondence should
preserve the order and disk dimensions are known. That's the work of BIOS
translation. For Linux we have to make either correspondence between 1D
and 1D [preserving the order!], or correspondence between 1D and 3D with
known dimensions [preserving the order, again]. If we know that the order
is the same for DOS and Linux we can forget (in Linux) about DOS internal
pecularities. And thus forget about BIOS translation.
> standard method of geometry translation if that is the case (there
> prolly is, I just never dug that far).
>
> > The only right thing to do is put up with this nonsense during boot, then use LBA mode.
>
> Or possibly, one of the things we can do in this project is implement
> a new interface for the disk I/O, for use with advanced OSes and/or
> bootloaders, which supports LBA directly, cleaning things up
> considerably. Oh, sure, it would break some things horribly, but that's
> why it would be an option.
Hmm. Then you can take Linux IDE driver and put it into BIOS. Yep,
it will break some things. DOS, for example. And Virus95, for it is loaded
by BIOS drivers. And LILO (well, _that_ is not a problem for we have the
source, but DOS & Virus...). NT will survive, for it uses its own loader.
And consider the fact that BIOS access is _slow_. So Linux will still use
its own driver (in regular RAM) for speed reasons. The only thing that
will gain something would be LILO (rewritten, i.e.).
>
> We might even be able to implement a better partition table format
> (like the BSD format). The MS partition table format is absolutely
> horrid at times.
Not a BIOS problem. For BIOS partitions don't exist. They are just
linear chunks of disk. It's determined by OS. Even in case of DOS it is
so (in MSDOS.SYS, as far as I remember). Oh, and boot loader have some
reduced knowledge of these matters. Then it's a question of master boot
loader.
Al
>
> I know, I know, why reinvent the wheel. Because we can, dang it,
> that's why! :-)
>
> -- Ben <hawk(a)ttlc.net>
>
>
> ---
> OpenBIOS -- http://www.linkscape.net/openbios/
> openbios-request(a)linkscape.net Body: un/subscribe
> Problems? dcinege(a)psychosis.com
>
>
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
21 years, 12 months
- 2
- 1
Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Pascal Dornier
From: Benjamin Scott <hawk(a)ttlc.net>
To: openbios(a)linkscape.net <openbios(a)linkscape.net>
Date: Sunday, February 22, 1998 6:03
Subject: Re: [OpenBIOS] BIOS extensions are pointless (was: More
comments...)
> I think it might be better to say that re-implementing things like
>INT13 in protected-mode would be pointless. The few things that modern
>OSes actually do *use* the BIOS for are definate canidates for
>improvement and possible protected-mode reimplementation. However,
>"BIOS32" implies it may be protected-mode already. Anyone know more
>about this?
Yes, 32 bit protected mode. See the PCI BIOS spec.
> While I do agree in theory, memory space limitations may force us to
>link the BIOS together before programming the flash. Which isn't really
>a big deal.
If you own all the sources, you can save yourself the complexity of
linking. I don't even use a object linker, my assembler is fast enough
to assemble the whole BIOS in about 60 ms.
> Actually, to the list in general: Does anyone know exactly *where and
>how* geometry translation occurs? I've been thinking it must occur in
>the motherboard BIOS for onboard EIDE controllers. But we already know
>many OSes bypass the BIOS. I was assuming they were still talking to
>the EIDE controller through the BIOS, just via a different route. Is
>that correct? Or is geometry translation implemented in the EIDE
>controller chipset itself? Or something else?
There are multiple levels of geometry translation. It's a classic
example of Winchester Mystery House software design. Read it and
weep.
1. DOS translates logical block address into Cylinder / Head / Sector
based on BIOS parameters. This is constrained by the 10 bit limit
on cylinder and 6 bit on sector number (and sector numbers start
at 1, which further mucks things up).
2. The BIOS translates this either into another CHS (the drive can
only handle 4 bits for the head number, but 16 bits for the cylinder
number, and 8 bits for the sector). Alternatively, the CHS value
is converted into a logical block address.
3. The drive translates the CHS into a logical block number, then
converts that into the real CHS values (which is not a straight
division as the number of sectors per track varies).
The only right thing to do is put up with this nonsense during boot,
then use LBA mode.
--------------------------------------------------------------------
Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com
Your Spec + PC Engines = Custom Embedded PC Hardware
--------------------------------------------------------------------
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
21 years, 12 months
- 1
- 0
Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Benjamin Scott
WA = William A. Arbaugh <waa(a)dsl.cis.upenn.edu>
WA> Not true actually, Linux does use some bios32 functions for PCI
WA> support. My guess is that they'll still need some BIOS level
support
WA> for PnP, Power management, and not to mention DPMI etc.
You're right of course. I had forgotten about the PnP stuff
entirely. I'm not sure how DPMI works, but it's a fair bet it needs
BIOS support, too.
I think it might be better to say that re-implementing things like
INT13 in protected-mode would be pointless. The few things that modern
OSes actually do *use* the BIOS for are definate canidates for
improvement and possible protected-mode reimplementation. However,
"BIOS32" implies it may be protected-mode already. Anyone know more
about this?
DW = David Woodhouse <Dave(a)imladris.demon.co.uk>
CA = Chris Arguin <Chris.Arguin(a)unh.edu>
DW> Regarding the module support:
DW> We can either link them at flash time, or have the BIOS search
through
DW> the available modules when it boots. I prefer the latter,
While I do agree in theory, memory space limitations may force us to
link the BIOS together before programming the flash. Which isn't really
a big deal.
DW>> Other than that, I don't see any point in extra protected-mode
DW>> functionality - as you rightly say, anything running in protected
mode
DW>> is going to have its own drivers already.
CA> Not to be too purest... but is that the "Right Way"? The BIOS is
CA> *supposed* to abstract that away. It doesn't. Maybe it should...
Originally, yes, the IBM-PC BIOS was a hardware abstraction layer.
Rather then, say, having disk device drivers, you called INT13 and got
support that way. Now, the original IBM-PC platform has been extended
so much about the only thing *left* is the original BIOS service code,
like INT13.
One might argue we should "fix" that, that we should put all that
hardware abstraction back in. Other platforms (the Mac comes to mind)
accomplish this very well. A standard hardware abstraction API has
obvious advantages. However, it is typcially accomplished by providing
a low-level API in firmware to which devices talk to. Each device
implements the support for this API. Due to the open nature of the
IBM-PC platform, this is obviously not going to happen.
The only other way to do it would be to write device drivers for each
and every device on the system, incorporate them into firmware, and let
the OS call our new hardware abstraction API. Besides the fact that
this would be totally redundent, I don't know that we have the flash ROM
space to accomplish this.
Even more important, I don't think it *would* be the Right Thing to
do. The IBM-PC mindset has become such that device abstraction occurs
at the OS level. This allows greater flexability and faster
development, something that has kept the IBM-PC line going where others
have failed. Software is easier to change then firmware. I don't
really think that we should try to go back to the "old way" of doing
things, despite the advantages. If you really want hardware abstraction
in firmware, buy a Mac. <grin>
CA> On a related note, I just bought a 8 Gig SCSI disk.
CA> Due to limitations of my SCSI controller,
[snip]
CA> I now have an 8GB Linux Disk. That is not a bad thing, but it wasn't
CA> what I was intending. So there is another bug for us to fix :)
I don't know that we can. Geometry translation for SCSI would be
handled by your SCSI controller and its BIOS, not the motherboard BIOS
(which would only control EIDE gemometry translation).
Actually, to the list in general: Does anyone know exactly *where and
how* geometry translation occurs? I've been thinking it must occur in
the motherboard BIOS for onboard EIDE controllers. But we already know
many OSes bypass the BIOS. I was assuming they were still talking to
the EIDE controller through the BIOS, just via a different route. Is
that correct? Or is geometry translation implemented in the EIDE
controller chipset itself? Or something else?
-- Ben <hawk(a)ttlc.net>
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
21 years, 12 months
- 1
- 0
Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by David Woodhouse
hawk(a)ttlc.net said:
>
> Could someone please tell me where protected-mode code will be
> useful in the BIOS firmware?
Initial memory and other hardware checks, and then some of the INT 15h
functions for copying memory around above 1Mb. Oh, and of course the BIOS
function to switch into protected-mode :)
Also PCI and APM BIOS32 functions.
Other than that, I don't see any point in extra protected-mode functionality -
as you rightly say, anything running in protected mode is going to have its
own drivers already.
> I believe the single most important goal of this effort should be
> modular design. If we make the design modular, most everyone can be
> happy.
Agreed. Most of the things we've been talking about recently have been
proposed extensions which would be separate modules, so those who don't see
the point don't have to use them. We have very little dispute about the core
of the project, other than the fact that we're not entirely happy about LPGL
but it seems to be the best option so far suggested.
Regarding the module support:
We can either link them at flash time, or have the BIOS search through the
available modules when it boots. I prefer the latter, because it doesn't
involve any intelligence on the part of the linker, and the extra headers
required won't take up a significant amount of space
Each module object needs a header, much like the existing BIOS extensions have.
In it we need to store: length, checksum, entry point. We could also do with a
flag indicating the invokation order, and whether it needs to remain in memory
when it's done (for when we've uncompressed into RAM).
For example, a chipset optimisation module would be loaded early, and not
remain in memory. An IDE disk driver providing INT 13h functions could be
loaded later, and will remain in memory. A boot loader will be loaded last.
The power-up vector will point to a routine which does an inventory of the
available modules, and invokes them in the correct order, uncompressing them
from flash into RAM as required. This boot loader will provide certain basic
functions for reading data from the CMOS and other things that a number of
other modules will require.
---- ---- ----
David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355
Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk
finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key.
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
21 years, 12 months
- 1
- 0
Re: [OpenBIOS] More comments and a proposal for priorities
by John Labovitz
Markus Kaufmann <kaufmann(a)pks-software.de> 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/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
22 years
- 2
- 1
Re: [OpenBIOS] More comments and a proposal for priorities
by Markus Kaufmann
Hi,
At 17:05 20.02.98 +0530, Arjun Roychowdhury wrote:
>I feel that while writing a BIOS, we must provide a small set
>of very poweful operations instead of bloatingt the BIOS to include
>one & all. I am strongly for adding prot-mode code, but only when
>necessary. wheras prot. mode code will add extra bytes in size,
>the advantages are obvious. However, IMHO, one should not just
>rewrite the entire BIOS using prot. mode. Real mode code does
>have its advantages, esp. in areas where mem. consumption is
>not so critical.
The real mode vs. prot. mode:
If you want to support DOS, you have to rewrite the normal BIOS
in real mode. Any protected mode extensions can't use these
functions and have to reimplement them.
If you wan't to boot from protected mode, you need your own
SCSI-drivers, small VGA-Drivers and so on.
Bye
Markus Kaufmann
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
22 years
- 1
- 0