-----Original Message-----
From: Pavel Machek <pavel(a)elf.ucw.cz>
Cc: openbios(a)linkscape.net Date: Wednesday, February 18, 1998 8:46 AM
Subject: [OpenBIOS] Re: Some Questions and ideas for gnu-bios
>
>Under linux, bios is not used (well, with exceptions of APM).
>
>Other 'systems' switch into v86 mode to call bios functions.
This goes into my major question. I would like to put the Linux kernel
itself in the flash of one of my older fast 486 machines - I hope to make it
a router, and I am having trouble with the hard drive in that box - if the
kernel is in flash, and maybe most of a ramdisk load, all I need is a floppy
with a few config options. Perhaps one could make use of the CMOS to store
simple config items.
If Linux doesn't use the BIOS at all, what initializations if any need to
be done to the system at POST to assign PNP/PCI IRQ settings, test the
memory, keyboard, etc.
What _exactly_ does the BIOS do to a system when it starts?
---jmc
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
Some discussion about the possibility of a freeware 'GNU' BIOS
was casually mentioned on the Linux kernel mailing list last week.
Talk about it escalated, and a mailing list was quickly formed.
After a few more days of ideas, it seems like a very good possibility
and some people just hell bent on getting started.
What we are looking for now are people with a high degree of knowledge
about the low-level workings of the x86 PC architecture, and real mode
programming experience. Please join the mailing list and offer what help
you can.
Also understand that many Linux people are involved with this, but the
purpose is a COMPLETE BIOS replacement for use with all Intel x86 OS's,
not just some new boot loader.
To subscribe to the OpenBIOS Mailing list, write an email
To: openbios-request(a)linkscape.net
Subject [leave blank!]
subscribe [in the body]
It is a majordomo managed list. Feel free to use extended MD commands as needed.
OpenBIOS web pages: (DO NOT expect to find much here yet!)
http://www.linkscape.net/openbios/http://www.freiburg.linux.de/OpenBIOS/
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
dcinege(a)fuckthejunkmailers.org said:
> When I think 32-bit in the BIOS, to me that means being able to deal
> with larger drives, and booting partitions with a huge sector offset.
> (corrections please)
Thank God for that - I was getting worried there! We want that kind of
functionality, definitely.
When I think 32-bit, that means "protected mode" - 32-bit code and data, rather
than the old real mode 16-bit segment/offset methods.
This would have meant that it wouldn't be compatible with legacy operating
systems such as DOS and Windows 95 which run at least partly in real mode,
using the real mode interrupts into the BIOS. (Unless we provided such 16-bit
routines side-by-side with the 32-bit ones, effectively doubling the size of
our function code)
We can provide big drive support and other such niceties with real mode code -
a normal BIOS generally has very little protected mode code AFAIK, although it
is required to provide routines for copying data to/from high memory, and for
switching into protected mode.
---- ---- ----
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
madman(a)zip.com.au said:
> This might be a really bad idea but let me know what you think anyway
> :) How about doing a really low level boot loader of some sort so if
> your booting linux it goes into 32bit protected mode early where as if
> you boot dos or win it loads into 16-bit mode with all the int's that
> are needed?
I don't think we'd gain much from the 32-bit stuff. It'd mean that we have
to provide both 16-bit and 32-bit versions of a number of functions, and who'd
ever use the 32-bit API?
Linux is always going to have to handle going into 32-bit mode itself, in case
it's booted from a standard BIOS. We'd have to write a whole new Linux boot
method to get it using the 32-bit BIOS API, and nobody else would ever use it.
I think we should stick to pretending to be a normal BIOS for now. We can try
adding extra stuff when it's working properly.
---- ---- ----
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
We're going to have to provide a standard 16-bit BIOS interface if we want to
support DOS and Windows users. There's not a lot of chance of making the BIOS
go straight into 32-bit mode and stay there.
We can still use C in 16-bit mode - take a look at the elks development utils,
which are quite suitable for this task.
I think we want to write most of it in C, with some critical sections in ASM -
after http://dwmw2.robinson.cam.ac.uk/devload/ I really don't want to think
about large projects written solely in assembly.
---- ---- ----
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
Partially to get people talking about what we should support, I would like
to propose a possible code layout. A fairly simple method of sorting the
source code that should be fairly extensible.
memory/ <- how to setup cache, memory timing, etc...
Bus/
PCI/
ISA/
AGP/ <- How to access and set up those buses
USB/
etc...
Drives/ <- for our purposes, anything that can boot
Floppy/
IDE/
SCSI/
Interface/ <- The front-end
Input/ <- Where do we get input from, and how
Output/ <- Where do we send output, and how
Common/ <- Whatever code that is common
misc/ <- Anything else
For example, my computer would be built with something like
memory/Intel/82437FX
Bus/PCI/Intel/82437X
BUS/ISA/Intel/PIIX
Drives/Floppy/Std_Floppy
Drives/IDE/PIIX
Drives/SCSI/NCR53c8xx
Interface/Power_CLI
Interface/Input/Keyboard
Interface/Output/VGA_text
misc/std_timer
The Interface/Power_CLI would be something like the Sun-bootloader, or the
Alpha console. Other possibilities would be a standard (like in most PCs),
or maybe a PC96 compliant one, if that applies.
Notice that you can easily change to a serial boot if desired, and I think
this sort of division allows for quite a bit of flexibility. Configuration
scripts can hide much of the actual details (for example, I would just
select the Intel 430fx chipset, which would set up the Memory, PCI, ISA,
and all that).
Comments?
--
Chris Arguin | "While I'm still confused and uncertain, it's on a
Chris.Arguin(a)unh.edu | much higher plane... at least I know I'm bewildered
| about the really fundamental and important facts of
| the universe." - Equal Rites, Terry Pratchett
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
dcinege(a)fuckthejunkmailers.org said:
> Haven't looked at BSD fully, but I understand it to be more along the
> lines of a PD (free for all) type licence. For this type of project I
> would not want to do work that Award could come by and just take it
> for their own.
I believe that a BSD license would allow them to do that - so we can't use BSD
either.
> I think a middle ground might be a licease that makes normal usage GPL
> like but allows the OpenBIOS group (I guess that's what we are) to
> sublicease it to companies for the purpose listed above. (I think the
> XFree86 project did something like this)
If we're going with the modular approach, with the final link being done at
the last moment before the flash is blown, I believe that we could use the
LGPL for this. I've just read through it again, and it seems to be precisely
what we're after.
We can declare all the OpenBIOS modules to be library routines, Then the
binary-only modules provided by manufacturers are "work that uses the Library",
and the only real restriction on them is that they have to allow for linking
with newer versions of our generic modules. How does that sound?
---- ---- ----
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
Hi!
> > Let me start by saying that I've never really investigated the BIOS
> > before, so I may make some false assumptions below. Please point out the
> > errors of my ways.
>
> Me too!! I've got a pretty good idea how things work, but do x86 asm.
> I'm also unsure about some of the memory limitations, and what, if anything, does
> the BIOS do once a protected mode OS starts.
Under linux, bios is not used (well, with exceptions of APM).
Other 'systems' switch into v86 mode to call bios functions.
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
David Woodhouse wrote:
>
> dcinege(a)fuckthejunkmailers.org said:
> > When it comes to a manufature making changes to support a peice of
> > hardware on their boards, this means they must release their changes.
>
> Fair enough. Is BSD the same?
Haven't looked at BSD fully, but I understand it to be more along the lines
of
a PD (free for all) type licence. For this type of project I would not want
to do
work that Award could come by and just take it for their own.
I think a middle ground might be a licease that makes normal usage GPL like
but allows the OpenBIOS group (I guess that's what we are) to sublicease it
to
companies for the purpose listed above. (I think the XFree86 project did
something like this)
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
David Woodhouse wrote:
>
> dcinege(a)fuckthejunkmailers.org said:
> > I don't think BSD is good for this, and a straight GPL wouldn't
> > really be the right thing either.
>
> Why so?
It is not possible to distribute a BIOS in a completly libary type form.When
it comes to a manufature making changes to support a peice of hardware on
their boards, this means they must release their changes. If this code is a
dependant on a peice of propritary or sub licensed peice of hardware they
may not be able to (or just won't) use our BIOS.
IF the finaly product is VERY modular and VERY flexable, then a regular GPL
might not cause problems.
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com