There seems to be some disagreement over the issue of whether or not
OpenBIOS should provide for possibility to compile into a single binary
support for multiple chipset types to be autodetected at run-time.
For OpenBIOS to be successful, it needs to become more attractive to
the MB manufacturers than the alternatives. I don't know whether such
a feature would be attractive to the MB manufacturers or not. I suggest
will begin by compiling a list of the advantages and disadvantages of
this feature. Having done that (so that we understand it ourselves as
best we can) we should then ask the manufacturers. (This will be a good
step toward getting free hardware from them for development.)
When we ask them, we should also ask any other questions about their
needs. In effect, we need to do some market research.
Here are the advantages and disadvantages that I can think of. There are
probably others.
Pro:
It's cool.
It would allow manufacturers to have one BIOS ROM that supports all
their MB products.
The autodetect code might also be useful for diagnostics.
Con:
Extra complexity--something else to go wrong. Bug free code is *really*
important in the BIOS.
Extra complexity--more difficult to test.
What other questions would we like the MB manufacturers to answer for us?
M
> I thought, a main topic for OpenBIOS development is full access to the
> hard drives so there is no trouble with large disks, large partitions and
> kernels laying somewhere on them.
Perhaps I'm confused. Shouldn't OpenBIOS be able implement the functionality
of LILO? I thought that LILO existed because BIOS16 are incapable of loading
anything that isn't DOS-like. Doesn't LILO look to the BIOS like DOS? In
other words, when a BIOS is loading LILO, doesn't it "think" it's loading
DOS?
> I thought, a main topic for OpenBIOS development is full access to the
> hard drives so there is no trouble with large disks, large partitions and
> kernels laying somewhere on them.
That sounds right. So why have a new LILO? Why not just not need LILO
anymore?
M
Hiya all
My two pennies worth...<G>
Asbjoernsen(a)atntr.telemax.no wrote:
> > Too Big. Each chipset got it's own data and specs (don't forget we're
> > talking about 386, 486, LX, BX, VX, FX chipset and they got lots of
> > differences) - combining them all together will give a binary file that
> > will probably won't fit into the flash (not mentioning other features we
> > want to have).
> We aren't talking about compiling in support for all and every supported
> chipsets, just making it configurable, so one could add support for more
> chipsets in one binary, of course limited by size. This would for instance be
> nice for admins having a large pool of computers with two different
> motherboards.
Compile time config on chipset support will be the answer.. I have an FX so i
need just to compile FX support... I have FX & HX boards so I'll compile both
separatly --> or compile HX & FX into the same binary.... that has to be decided
i think...
>
> I think this is the answer to many discussions we will probably see:
> - Do we want a boot logo?
Yes i think so, even if optional...
>
> - Should it support loading the kernel directly?
Only if the kernel is placed in a _standardised_ place, like the MBR
currently.... If people want kernel ROMs surely it will be better, _and_ SAFER
to just compile a linux kernel boot ROM and pop it onto their nearest
Net/VGA/SCSI card.... cause most are capable of holding custom boot ROMs, and
executing them.
>
> - Should we support 16bit functions for compatibility
Again compile time ... remember you get your _generic_ Linux kernel, you then
compile it to do _exactly_ what _you_ want then you install it.
The generic BIOS is of course the current MB BIOS's, if they take on OpenBIOS,
then implementing the current Flash failsafe (which IMHO is not very well
implemented), similar to the 3Com Router BIOS/Firmware(which is implemented
beautifully <G>), should be made the default.
3Com router Firmware has 3 parts:
Boot Loader - initialises hardware can checks for valid checksum on flash.
Provides a method of re-writing boot/main code, or erasing flash - Does nothing
hardware dependant, works across platform.
Main Code - Takes into account Version/Revision/Chipset can do all functions of
Bootloader, but provides user stuff - the real BIOS as it were.....
Data Code - Settings/config - user deturmined.
>
> - ...
> Make it configurable (tm) :)
>
tu chez!
yours
Matthew (aka Mickey)
A couple of ideas to consider - single all inclusive chipset support vs.
modularized chipset specific builds:
1. The bios core is relatively stable
2. Chipsets keep changing
3. CPU platforms change over time - 386, 486, ........
4. There are usually 2 or 3 places in the code where chipset initialization
is called - usually very early in the code
5. Encountered these problems in the 16 bit bios over many iterations,
finally arrived at a basic structure that
included a chipset module. The chipset modules required some ASM and some C
and some H code. Rather than
create 3 files for a chipset, I created one file to keep the chipset info in
a convenient place and then extracted the ASM,C, and H info
into 3 temporary files when doing the build.
6. Did this about ten years ago using MS C and MASM - primitive but it works
7. MS H2INC utility is very nice - lets one use one H definition file for
both C and MASM structures so they are always in sync with each other
8. A bios build was based on a configuration file (xxx.job) that defined
variables for the build for a particular configuration
9. Separating the chipsets from the core code made it easier to debug
developing new chipset code and to update core code - by allowing testing to
verify core code on existing platforms
10. It also made creating new chipset code easier because it is all defined
in one separate file.
BTW - the openbios.org domain has a temporary link to M's new pages - a bit
of kludge so far - but we will work on getting this prettified and organized
:-)
John
-----Original Message-----
From: M Carling <m(a)midgard.net>
To: openbios(a)elvis.informatik.uni-freiburg.de
<openbios(a)elvis.informatik.uni-freiburg.de>
Date: Sunday, November 29, 1998 9:13 PM
Subject: Chipset autodetect -- pro and con
>
>
>There seems to be some disagreement over the issue of whether or not
>OpenBIOS should provide for possibility to compile into a single binary
>support for multiple chipset types to be autodetected at run-time.
>
>For OpenBIOS to be successful, it needs to become more attractive to
>the MB manufacturers than the alternatives. I don't know whether such
>a feature would be attractive to the MB manufacturers or not. I suggest
>will begin by compiling a list of the advantages and disadvantages of
>this feature. Having done that (so that we understand it ourselves as
>best we can) we should then ask the manufacturers. (This will be a good
>step toward getting free hardware from them for development.)
>
>When we ask them, we should also ask any other questions about their
>needs. In effect, we need to do some market research.
>
>Here are the advantages and disadvantages that I can think of. There are
>probably others.
>
>Pro:
>
>It's cool.
>
>It would allow manufacturers to have one BIOS ROM that supports all
>their MB products.
>
>The autodetect code might also be useful for diagnostics.
>
>Con:
>
>Extra complexity--something else to go wrong. Bug free code is *really*
>important in the BIOS.
>
>Extra complexity--more difficult to test.
>
>What other questions would we like the MB manufacturers to answer for us?
>
>M
Hello, all.
It seems that it will be time soon for med to add a memory allocator to
my tree. I know nothing about the implementation of those, anyone who
wants to try to make something up?
/Daniel
--
Hello,
Just figured I should share this:
If you think that Adobes Acrobat Reader renders PDF files too slow, give
xpdf a shot. It renders faster, but uglier than Acrobat Reader.
It can be had from:
http://www.foolabs.com/xpdf/
/Daniel
--
Dear all,
I am forwarding the following message from the seul-edu maillist. The GPLed
digital circuit simulator may benefits the subscribers of this list.
I am _NOT_ the author of the digital circuit simulator. Thi
<ttn(a)mingle.glug.org> is. Any corresponding should be with Thi, and not me.
Thank you.
- ----------------------
Forwarded message begins
- ----------------------
From: thi <ttn(a)mingle.glug.org>
X-Mailing-list: seul-edu(a)seul.org
[...]
ObCode: Anyone interested in adapting the (GPLed) digital circuit
simulator I'm working on for teaching purposes, please look at the code
and let me know how I can help.
ftp://ftp.netcom.com/pub/tt/ttn/thud/thud-0.13.READMEftp://ftp.netcom.com/pub/tt/ttn/thud/thud-0.13.tar.gz
In writing this code, I am also a student, and welcome critique. If
THUD is not useful for teaching purposes, how can it be made so?
- --------------------
Forwarded message ends
- --------------------
Check http://www.winbond.com.tw/ (taiwan)
I see various permutations of the 83C787 digits (e.g 83C877), but I do not
see that part. Are you sure that your part is 83C787? You can download
Winbond datasheets from that web site.. Is C787 an old ('486 days) part? My
recommondation is to focus on recent chipsets first because data is more
easily available and the results are most useful.
-Ray
-----BEGIN PGP SIGNED MESSAGE-----
Hi...
I've put out some new code again, today and it's based on Daniel's work.
This is not a final 0.0.2 release as there's a lot of work to do left.
I am sorry to say that I am away (working) until sunday evening, so I won't be
able to release anything new until the mid of next week.
I've put John's work from OpenBIOS.org to the web directory as well as some
other stuff..
look at it, comment on it, hack it!!!
I expect to have at least a thousand openbios mails in my mbox when I return on
Sunday evening ;-))
Philipp Rumpf <prumpf(a)jcsbs.lanobis.de> has looked at the linux kernel startup
and the lilo code and determined which software interrupts are needed to boot
up a system at the moment....
It's the following
1000 o SET VIDEO MODE
100E o TELETYPE OUTPUT
100F o GET CURRENT VIDEO MODE
1014 o LOAD FONT
11 ? GET EQUIPMENT LIST
12 ? GET MEMORY SIZE
13?? ! DISK ACCESS
140000 ! INITIALIZE SERIAL PORT
1587 COPY EXTENDED MEMORY
1588 GET EXTENDED MEMORY SIZE
15C0 GET CONFIGURATION
15E801 GET MEMORY SIZE > 64M
1600 ! GET KEYSTROKE
1601 ! CHECK FOR KEYSTROKE
1602 ! GET SHIFT FLAGS
with the following meaning
o obsolete (not really needed)
? don't know
don't know, too.
! IMPORTANT.
Thanks, Philipp.. I will try to join work again on Sunday evening or on Monday
Happy hacking guys....
BTW, I'd like to set out a prize on the best OpenBIOS logo... Any ideas what
would be sufficient for this? Maybe we could even find a little company as
sponsor for this.. ? :-)
Best wishes,
Stefan (tired now)
- --
Reincarnation: Life sucks, then you die. Then life sucks again.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBNl3svyu+zKndEmP5AQHsMgf/edfqPFPy7g95Mn2Xx0NQBgMsKvIiEfAg
3DYvLBdGwk3uCxJsJ/ltDNPIQRJCBptv+PiKOyLgCfU6nPoOIodptISyarUYEBJU
BZg/zzyWHMVscJrV3rMYndwo0LU3wBhKZSyMQuzugpmrO9ePqWRGlUg74N+Le/Gx
ufH9SREFleBz8hdUJQClUrduf6yyr49LsWcIz3tca4yy+oYPo1SGTsJRTKf1YroD
1pvFlBzs/1NQM3uhNPqn6vuofvZEqUh0JsaNWfw3nwlcpeTrTlpvyuElJbw4R/EW
RU/Y7+nxcx0R/c9KDiS3P+lMxX3i2MV2UvS2OKtRQPbvCuLfAkeS1A==
=fF84
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hi again...
Am I getting old? I forgot the URL of the new code...
get it at http://www.freiburg.linux.de/OpenBIOS/bin/
g'night OpenBIOS hackers :)
Stefan
- --
Reincarnation: Life sucks, then you die. Then life sucks again.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBNl3t8iu+zKndEmP5AQGWDgf7BKU/VmfJGYGKlxGNzmyhtPB3aPqoQs9i
LJgc6R2AGiN7uYsEBuEedcnzWns4p//tGWq1b4taTSo2lDEGG848tgb04fwuIoP/
lBUTOWRoqlhs3M7mlucpuuNnRhVu7xPBRV4l3qhZOoRxPnYSujw3fdALR5OQjyDF
DEUthBtGMbRckkUkexM6gD7PfF2P4QdkZsx5EsTjsp4uS+lUMqpoIo0vMwIKqKRr
lk1k/YvTTgdDpiTspmnEwfNkCWN4MhuqIvX2ByVdmPZZO+wk8RyZ94Dh2leHSBqg
zuh3sxpKWIS0PFPHwITuCPAcdpQ44s6lwoSBGY9KDmDuyAeE6q4tDg==
=7X0A
-----END PGP SIGNATURE-----
