What OpenBIOS should contain

Hello all,
    I see it's been busy, even if not on track ;).

The basic requirements that I would have from a BIOS are as 
follows:

1) The ability to chainload to another bootloader ( the most basic 
function ), after enough hardware setup (a little RAM testing etc). 
The state of the processor on hand over should be a runtime option 
(ie protected or real mode). No dabling with V86 mode. There really 
isn't any need, and it gets ugly quickly.
2) A nice simple (though powerful) built in bootloader. Something 
like grub mainly 'cause it's got a command line which is REALLY 
USEFUL when you've got a system you couldn't boot otherwise.
3) The ability to boot from many media (network, cd, floppy, ide 
etc). Network booting would be nice but the network card support 
may be a bit cumbersome.
4) Some cool utilities like a nice format for common filesystem 
types (FAT, VFAT, ext2 etc).

I think we should look to Linux for the filesystem drivers.

Sam.
-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

[Edward Brotsman Dreger]

> The ability to boot from many media (network, cd, floppy, ide
>
> etc). Network booting would be nice but the network card support 
> may be a bit cumbersome.

How about a "combination" netboot approach?  The BIOS could maybe handle
all of the netboot _except_ the NIC driver.

Store the NIC driver on a specially-formatted floppy.  The floppy would
call a BIOS routine to register NIC driver of size XXXX at address XXXX,
and the BIOS would take over.

It's a bit kludgy and backwards way of loading an option ROM, but who says
existing BIOSes aren't kludgy and backwards? ;-)

My $.02

Eddy

*-----------------------------_/~~_/----------------------------------*
  Edward Brotsman Dreger                 "Your Success is Our Success    
  Network & Systems Manager            Our Expertise is Your Advantage"  
  Brian's Consulting Services /~__/~\   www.brics.com * 316-794-8922    
_________________________________________________________________________
SPAMbot bait:  abuse@localhost  postmaster@localhost  [e-mail]

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

[James Oakley]

Edward Brotsman Dreger wrote:
> Store the NIC driver on a specially-formatted floppy.  The floppy would
> call a BIOS routine to register NIC driver of size XXXX at address XXXX,
> and the BIOS would take over.

Unfortunately, this would defeat the purpose of a diskless workstation.

This is why a Linux style BIOS configuration is advantageous. You pick
your NIC and recompile.

JFunk
-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

[Edward Brotsman Dreger]

> > Store the NIC driver on a specially-formatted floppy.  The floppy would
> > call a BIOS routine to register NIC driver of size XXXX at address
> > XXXX, and the BIOS would take over.
> Unfortunately, this would defeat the purpose of a diskless workstation.

True.
> This is why a Linux style BIOS configuration is advantageous. You pick
> your NIC and recompile.

Also true.  I was trying to think of an even more modular approach, and
the floppy probably was a bit bass ackwards.

With a modular BIOS design, there would be space for X number of option
ROMs in the flash memory...

Perhaps a slicker, more useful approach would be to have a tool that
allows loading Linux-like modules into flash.  The system could then be
configured in the BIOS setup which driver to use.

Example (imagine a few dozen computers):

- load Intel Pro/100, DEC 21x4x, 3c590/3c90x drivers into all BIOSes
- config each individual machine to use whatever NIC
- phase out 3Com cards, using only EE/100 and Tulips
- reconfig as needed
- remove 3Com drivers from flash

As long as BIOSes are modular, why not have load/unload module options?  I
think that would be *really* cool.  No need to even recompile; just flash
a new module into the BIOS.  Custom BIOSes in no time!

I don't mind recompiling -- in fact I don't run modules in my kernels, and
recompiles are the only way -- but I think it would be nice to change
computers without having to recompile each BIOS.

As long as I'm rambling... pre-boot management. :-)  I'd love the ability
to flash BIOS modules from one location over a network.

I know that Award/Phoenix has some sort of pre-boot BIOS diagnostic type
tool that, if memory serves me, is around 8KB.  It's certainly not as
advanced as what one could dream up, but the "remote management" and I/O
redirection code clearly isn't that large.

Of course, Linux 2.2 kernel supports redirecting the console to a serial
port.  Smells useful...

Eddy

*-----------------------------_/~~_/----------------------------------*
  Edward Brotsman Dreger                 "Your Success is Our Success    
  Network & Systems Manager            Our Expertise is Your Advantage"  
  Brian's Consulting Services /~__/~\   www.brics.com * 316-794-8922    
_________________________________________________________________________
SPAMbot bait:  abuse@localhost  postmaster@localhost  [e-mail]

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

[Matthew Sullivan]

Edward Brotsman Dreger wrote:
> Of course, Linux 2.2 kernel supports redirecting the console to a serial
> port.  Smells useful...

All sun's do as a matter of course.... Smells _REALLY_ useful for PC
manufacturers

Yours

Mat

[Ed Brinker]

I'm a bit confused.  A you talking about flashing a ROM or are you loading
the NIC driver to shadow RAM.

At 12:36 AM 7/25/99 +0000, you wrote:
> > The ability to boot from many media (network, cd, floppy, ide
> >
> > etc). Network booting would be nice but the network card support 
> > may be a bit cumbersome.
>
> How about a "combination" netboot approach?  The BIOS could maybe handle
> all of the netboot _except_ the NIC driver.
>
> Store the NIC driver on a specially-formatted floppy.  The floppy would
> call a BIOS routine to register NIC driver of size XXXX at address XXXX,
> and the BIOS would take over.
>
> It's a bit kludgy and backwards way of loading an option ROM, but who says
> existing BIOSes aren't kludgy and backwards? ;-)
>
> My $.02
>
> Eddy
>
> *-----------------------------_/~~_/----------------------------------*
>  Edward Brotsman Dreger                 "Your Success is Our Success    
>  Network & Systems Manager            Our Expertise is Your Advantage"  
>  Brian's Consulting Services /~__/~\   www.brics.com * 316-794-8922    
> _________________________________________________________________________
> SPAMbot bait:  abuse@localhost  postmaster@localhost  [e-mail]
>
> To Unsubscribe: send mail to [e-mail]
> with "unsubscribe openbios" in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel holding back information

[Niklas Ekström]

I have been in contact with Intel about obtaining the BIOS specifications
for various chipsets (in particular the 430FX which is the chipset of my
testing environment), but they seem very reluctant to give them away. I
guess it might depend on that a) you normally have to sign a
Non-Disclosure Agreement to obtain them (which doesn't go well with the
fact that I will make the source for the BIOS publicly available) and
possibly b) that I'm a private person and not a well recogized BIOS
manufacturing company.

Does anyone have a good suggestion as how to solve this issue? I think
this is quite a major issue. Even though I think I have a clue on how to
do most things (detecting memory size and type (FPM/EDO)), I also believe
there are some things that you would actually need the BIOS specification
for (atleast so I don't have to _guess_ how to do some things).

I believe some of you here (professional BIOS programmers) have read these
specifications. Can you give any hint to how much information these
specifications contain and how vital that information is? Also, is it
possible to obtain that information for any other source?

/ Niklas

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel holding back information

Did you look at http://developer.intel.com?  I think all relevant documentation
on *current* chipsets is available there.  Not sure if you'll find the 430FX
though.
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel holding back information

[Ron Tsur]

Niklas Ekström wrote:
> I have been in contact with Intel about obtaining the BIOS specifications
> for various chipsets (in particular the 430FX which is the chipset of my
> testing environment), but they seem very reluctant to give them away. I
> guess it might depend on that a) you normally have to sign a
> Non-Disclosure Agreement to obtain them (which doesn't go well with the
> fact that I will make the source for the BIOS publicly available) and
> possibly b) that I'm a private person and not a well recogized BIOS
> manufacturing company.
>
> Does anyone have a good suggestion as how to solve this issue? I think
> this is quite a major issue. Even though I think I have a clue on how to
> do most things (detecting memory size and type (FPM/EDO)), I also believe
> there are some things that you would actually need the BIOS specification
> for (atleast so I don't have to _guess_ how to do some things).
>
> I believe some of you here (professional BIOS programmers) have read these
> specifications. Can you give any hint to how much information these
> specifications contain and how vital that information is? Also, is it
> possible to obtain that information for any other source?
>
> / Niklas

I provide consulting services to Intel, many times concerning chipsets.  I am
bound by non-disclosure agreement so I could not provide you with any
information that you cannot receive by other means.  However, Intel does not
want to hide information regarding released chipsets, only to protect
pre-release products.  I believe that the best avenue for you is to request a
developer CD-ROM subscription, which is free of charge, if you qualify and
includes regular quarterly updates.  refer to Developers' Insight CD-ROM at

http://developer.intel.com

The last issue I received was May 1999.  The August issue is due any day now. 
The information is usually delivered on several (last one was three) CD-ROMs. 
You should be able to find the register-level description of all released
chipsets.  If you cannot find a particular chipset, please let me know and I'll
try to figure out if the information is not available for a good reason.

Good luck,

Ron.

Intel holding back information

[Niklas Ekström]

On Thu, 5 Aug 1999, Ron Tsur wrote:
> I provide consulting services to Intel, many times concerning chipsets.  I am
> bound by non-disclosure agreement so I could not provide you with any
> information that you cannot receive by other means.  However, Intel does not
> want to hide information regarding released chipsets, only to protect
> pre-release products.  I believe that the best avenue for you is to request a
> developer CD-ROM subscription, which is free of charge, if you qualify and
> includes regular quarterly updates.  refer to Developers' Insight CD-ROM at

This is annoying. Do you think that I'm actually that stupid that I
haven't retrieved the information that is freely available from Intel
before I write something like this to this mailinglist?

Ofcourse I have the Developer Insight cdroms and also have got printed
books with datasheets from Intel as well as printed out those chipset
datasheets not in those books.

But what I want is the BIOS specificatons for the chipsets, which is
released under a NDA so you can't just download them from Intel's website
(I can't believe you missed that if you read my original posting).

Also if you would actually have read my original mail, you would know that
I already have been in contact with Intel and that they are unwilling to
give out these specifications (and it's not a pre-release product, the
430FX chipset is from '96).

I know for sure that there is information in the BIOS specification that I
would want when writing the BIOS (an Intel Support Engineer told me so
(she also told me the ordering number for the 430FX BIOS spec 2.2 is 
FM0704)). For example, nowhere in the chipset datasheet it says how you
should do to find out how much RAM there is in each row, so you can
program the DRBs (DRAM Row Boundry registers).

So stop giving me useless advice like "dude, perhaps if you learn
assembler, i've heard that's great.. and visit developer.intel.com"
and come up with a good idea on how to obtain the information in the
BIOS specifications!

Btw, couldn't anyone that works as a BIOS engineer over at Intel send
these specs (by mistake ofcourse) over to me?  ;-)

/ Niklas

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel holding back information

[Ron Tsur]

Niklas Ekström wrote:
> On Thu, 5 Aug 1999, Ron Tsur wrote:
> > I provide consulting services to Intel, many times concerning chipsets.  I am
> > bound by non-disclosure agreement so I could not provide you with any
> > information that you cannot receive by other means.  However, Intel does not
> > want to hide information regarding released chipsets, only to protect
> > pre-release products.  I believe that the best avenue for you is to request a
> > developer CD-ROM subscription, which is free of charge, if you qualify and
> > includes regular quarterly updates.  refer to Developers' Insight CD-ROM at
>
> This is annoying. Do you think that I'm actually that stupid that I
> haven't retrieved the information that is freely available from Intel
> before I write something like this to this mailinglist?

Niklas,

I would not be subscribing to this mailing list if I would not share your
interest in open source and free OpenBIOS.  I don't think that you are stupid,
but your attitude sucks, because you attack the very people that are trying to
help you.  Maybe you cannot get the information you are seeking because of your
attitude.

If you read my letter carefully, you will see that I offered you some real
help.  I can probably get the documents you need at any time.  However, I
cannot distribute them legally without the owners (Intel) consent.  I
understand your frustrations.  I have frustrations about keeping information
from the public too, but I have to live with them.  I don't think that you will
go very far, begging BIOS engineers to (illegally) release the information to
you.  You may be better off developing a strategy to convince Intel that your
effort is going to be in their best interest.  At least, this is what I do when
I need such information.

Now, comes my question.  Why do you need Intel's BIOS specs.  If you are
working on a truly OPEN software product, isn't it better to take the
"cleanroom" approach?  Intel's specs are always influenced by their ties and
legal agreements with the major BIOS manufacturers (phoenix, award, etc.) who
actually PATENT some of the algorithms they are using in their products. 
Intel's BIOS specs may pose some unreasonable limitations on your supposedly
unencumbered design and Intel or one of the other BIOS manufacturers may have
legal claims to OpenBIOS if they can prove that you used "their" proprietary
information in your design.  So, perhaps, we will all be better off without
Intel's help.

Thanks for listening,

Ron.

Intel holding back information

[Niklas Ekström]

On Fri, 6 Aug 1999, Ron Tsur wrote:
> I would not be subscribing to this mailing list if I would not share 
> your interest in open source and free OpenBIOS.  I don't think that you
> are stupid, but your attitude sucks, because you attack the very people
> that are trying to help you.

Yes you're right. I've gotten really frustrated talking to braindead
Intel reps (most of them atleast), who just points me in some other
direction. So the last thing I needed to hear was "have you tried
developer.intel.com?". Anyway, I'm sorry about that, it wasn't you I was
barking at. (However, I do ask that people read through the question
before answering it, so they don't answer the wrong question...)
> If you read my letter carefully, you will see that I offered you some real
> help.  I can probably get the documents you need at any time.  However, I
> cannot distribute them legally without the owners (Intel) consent.

Yesterday I got a mail from a guy at my local Intel distributor, where he
explains why Intel didn't give away the specs (atleast what he thinks). He
said that the reason is probably that if Intel gives out the specs, they
also have to give support and because of that they don't want to give it
out to just anyone. But he also said that if I could prove that Intel
would sell more chips (probably >5k/year, the guy said), they would almost
certainly give out the specs. However, I'd says it's highly unlikely that
people (atleast that many) would buy an Intel machine just to run this
BIOS on it...

Maybe if I can convince them that I, or anyone I give the specs to, will
not require support for it?
> Now, comes my question.  Why do you need Intel's BIOS specs.  If you are
> working on a truly OPEN software product, isn't it better to take the
> "cleanroom" approach?

Ofcourse that is an alternative, but then I would have to get the
information that is available in the BIOS specs from some other place (or
possible reverse engineer or just guess etc) and I feel that it would be
unnessecary difficult, compared to just having all information in one
specification. Ofcourse I wouldn't change my BIOS design because of
something that I read in the BIOS spec.
> Thanks for listening,

Thank you for helping! :)

/ Niklas

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel info

[Tim Small]

Niklas Ekström wrote:
> I have been in contact with Intel about obtaining the BIOS specifications
> for various chipsets (in particular the 430FX which is the chipset of my
> testing environment), but they seem very reluctant to give them away. I

I'm pretty sure I saw these when I downloaded the 440FX specs.  A good index
for order numbers is http://www.sandpile.org/docs/intel/chipset.htm

This is also useful:

http://developer.intel.com/design/intarch/DATASHTS/

and the majority of data sheets can be got by appending number.htm to the
above URL (without the revision number).  The 430FX docs in particular are
here: http://developer.intel.com/design/pcisets/datashts/290518.htm

Tim.

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel info

[Niklas Ekström]

On Fri, 6 Aug 1999, Tim Small wrote:
> > I have been in contact with Intel about obtaining the BIOS specifications
> > for various chipsets (in particular the 430FX which is the chipset of my
> > testing environment), but they seem very reluctant to give them away. I
>
> I'm pretty sure I saw these when I downloaded the 440FX specs.

No you didn't. The BIOS specifications aren't available for public
download (which you were meant to understand from the fact that you have
to sign a Non-Disclosure Agreement to obtain them).

/ Niklas

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel holding back information

[David J. Coffin]

Niklas,

You cannot get a DRAM-sizing algorithm from Intel with-
out signing an NDA, and the NDA forbids you to share your
source code without Intel's written permission.

This is necessary to protect Intel's "competitive ad-
vantage", even for a chipset that was discontinued two years
ago.

VIA Technologies publishes their DRAM-sizing algorithms
without restriction.  The VIA 580VP chipset matches the Intel
430FX almost bit-for-bit, so this is a good place to start.

For an example of actual code, disassemble an Award,
AMI, or Phoenix BIOS.  Don't read the BIOS from shadow RAM;
copy it off the chip or find it on the web.  The DRAM- and
cache-sizing code are easy to find, because most everything
else is compressed to resemble random noise.

There is no way for the BIOS writer to conceal Intel's
secrets.  DRAM-sizing code must run directly off the flash
chip, so it can never be compressed or encrypted.

Dave Coffin  8/7/99

On Fri, Aug 06, 1999 at 01:16:27AM +0200, Niklas Ekström wrote:
> I have been in contact with Intel about obtaining the BIOS specifications
> for various chipsets (in particular the 430FX which is the chipset of my
> testing environment), but they seem very reluctant to give them away. I
> guess it might depend on that a) you normally have to sign a
> Non-Disclosure Agreement to obtain them (which doesn't go well with the
> fact that I will make the source for the BIOS publicly available) and
> possibly b) that I'm a private person and not a well recogized BIOS
> manufacturing company.
>
> Does anyone have a good suggestion as how to solve this issue? I think
> this is quite a major issue. Even though I think I have a clue on how to
> do most things (detecting memory size and type (FPM/EDO)), I also believe
> there are some things that you would actually need the BIOS specification
> for (atleast so I don't have to _guess_ how to do some things).
>
> I believe some of you here (professional BIOS programmers) have read these
> specifications. Can you give any hint to how much information these
> specifications contain and how vital that information is? Also, is it
> possible to obtain that information for any other source?
>
> / Niklas
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel holding back information

[Niklas Ekström]

On Sat, 7 Aug 1999, David J. Coffin wrote:
>  You cannot get a DRAM-sizing algorithm from Intel with-
>
> out signing an NDA, and the NDA forbids you to share your
> source code without Intel's written permission.

Ok, like I suspected :/... (I was pretty certain that someone on this list
could confirm this! :-)
>  VIA Technologies publishes their DRAM-sizing algorithms
>
> without restriction.  The VIA 580VP chipset matches the Intel
> 430FX almost bit-for-bit, so this is a good place to start.

Great tip, thanks!

I do think that I have an idea on how to detect the DRAM sizes. So if I
write the algorithm here, you or someone else can comment on it and say if
you think it will work. Here goes:

disable all caching (if it isn't already disabled (which it probably is));

set all DRAM Boundary registers (DRBs) to it's maximum value (63 * 4MB), \
  which is >128MB which is the most the chipset can use;

previous_drb_val = 0;    // variable used below

for (n = 0; n < 5; n++) {

write (some randon) dword of data, k != 0, to address \ 
   previous_drb_val * 4MB and read back y from the same address;

if (y != k) {
    previous_drb_val += 0;    // NOP
    write previous_drb_val to DRB reg n;
    continue;    // for next n
  }

for (j = 1; j <= 16; j++) {   // 16 * 4MB is the most a row can hold

write (some random) dword of data, p != 0, to address \
      (previous_drb_val + j) * 4MB;      // check for wrap-around
    read back y from address previous_drb_val * 4MB;

if (y == p) {
      previous_drb_val += j;
      write previous_drb_val to DRB reg n;
      break;
    }
  }
}

And that should be it (ofcourse the algorithm must be written without the
use of the stack or any other memory).

On the 440BX, DRAM-sizing seems much less complicated, using the Serial
Presence Detect (SPD) of the 168-pin DIMMs (correct?).
>  For an example of actual code, disassemble an Award,
>
> AMI, or Phoenix BIOS.  Don't read the BIOS from shadow RAM;
> copy it off the chip or find it on the web.  The DRAM- and
> cache-sizing code are easy to find, because most everything
> else is compressed to resemble random noise.

I have been thinking about doing that, but wouldn't that make me unable to
write the bios after that (legally that is) ?

/ Niklas

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel holding back information

[David J. Coffin]

Niklaus,

Your algorithm doesn't account for the fact that DRAM
has two dimensions.  You have to toggle the A11 and A12 lines
to find out the number of columns, and A22-A24 to find out
the number of rows.  Sometimes you have to change the DRB
registers and do more tests.  The details vary from one chip-
set to another.

Always check both halves of a 64-bit word, in case some-
one installed a single SIMM, or mismatched SIMMs, by mistake.
> I have been thinking about doing that, but wouldn't that make me unable to
> write the bios after that (legally that is) ?

If you can understand their code, reduce it to an algo-
rithm, and write your code to that algorithm, it's perfectly
legal.  (I've seen Award's source.  The disassembly is easier
to read!)

Use get_PCI() and set_PCI() routines that are incompatible
with Award's.  That will force you to write something completely
original.
    				Dave Coffin  8/8/99
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Intel holding back information

[Niklas Ekström]

On Sun, 8 Aug 1999, David J. Coffin wrote:
>  Your algorithm doesn't account for the fact that DRAM
>
> has two dimensions.  You have to toggle the A11 and A12 lines
> to find out the number of columns, and A22-A24 to find out
> the number of rows.

Ok, but I thought that the chipset will (automaticly) set the correct row
number from the DRBs that I constantly program with the size of the
previous rows ?

How do I change row otherwise?
>  Always check both halves of a 64-bit word, in case some-
>
> one installed a single SIMM, or mismatched SIMMs, by mistake.

Very good point, will do that.
> > I have been thinking about doing that, but wouldn't that make me unable to
> > write the bios after that (legally that is) ?
>  If you can understand their code, reduce it to an algo-
>
> rithm, and write your code to that algorithm, it's perfectly
> legal.  (I've seen Award's source.  The disassembly is easier
> to read!)
>  Use get_PCI() and set_PCI() routines that are incompatible
>
> with Award's.  That will force you to write something completely
> original.

Wow, now I've got two _totaly_ different opinions on this; that I should
not under any circumstance ever disassemble a commercial bios, and now
this that it should be perfectly ok to do it. Somebody else got an opinion
on this?

/ Niklas

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message