openbios and via

[Jeff Garzik]

Is this list still alive?  I don't see any links to mail archives, but
the files in the latest source archive are about 10 months old.

I might be using the OpenBIOS code in an embedded project.  First I am
going to play around with it on my home PC, where I already have the VIA
82Cxxx databook.  Once I get that working, I'll probably add support for
Intel PIIX4 chipsets, they look pretty easy.

Can motherboard chipset coding be done in C?  If not, what needs to be
fixed before this can happen?

Also, is www.openbios.org DNS down?  I can't seem to complete a lookup,
much less a web hit.

Thanks,

Jeff

[Jeff Garzik]

And FWIW, there is a 16-bit C compiler that the ELKS guys use, at
http://www.tunes.org/~fare/files/asm/bcc-95.3.12.src.tgz

[Joseph D. Foley]

More importantly, borland released (*free, for real*) TurboC to the web,
which supports far pointers, among other things.

Joseph
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Jeff Garzik
> Sent: Thursday, September 16, 1999 12:50 AM
> To: [e-mail]
> Subject: [OpenBIOS] Re: openbios and via
>
> And FWIW, there is a 16-bit C compiler that the ELKS guys use, at
> http://www.tunes.org/~fare/files/asm/bcc-95.3.12.src.tgz
> --
> Custom driver development	|    Never worry about theory as long
> Open source programming		|    as the machinery does what it's
>    			|    supposed to do.  -- R. A. Heinlein
>
> 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

Questions and comments (was Re: openbios and via)

[Jeff Garzik]

"Joseph D. Foley" wrote:
> More importantly, borland released (*free, for real*) TurboC to the web,
> which supports far pointers, among other things.

And probably optimizes better too...  But I'll have to run it under
DOSemu, as I don't want to install MS-DOS or FreeDOS.  :)

BTW, can the OpenBIOS firmware be tested from Linux or a boot disk,
without having to flash the development code into flash mem?

It looks like it wouldn't be hard to integrate Linux's bios32.c into
OpenBIOS, to provide PCI support.

And I have an Intel PIIX, a popular chipset, in addition to Via, so
maybe I can add Via and PIIX4, once PCI support is in.  (both chipsets
are generally controlled via PCI)

Finally, another question:  Does OpenBIOS ('make config ; make') built a
32-bit protected mode image, or a 16-bit image?  The make output seems
to imply both, though most of the code I look at is 16-bit.

Can we do _everything_ in protected mode?

Personally, I think doing everything in C is the best choice, as you can
more easily compile code to be either 16-bit or 32-bit.  That way ROMs
can choose whether they want larger, faster firmware, or smaller but
slower firmware.

Regards,

Jeff

some links

[Jeff Garzik]

This network boot loader project is interesting: 
http://nilo.on.openprojects.net/

Most the things it references is OsKit, which looks to potentially be
very valuable to OpenBIOS:  http://www.cs.utah.edu/flux/oskit/

some links

[Joseph D. Foley]

The code is oskit is a good reference... but the kit itself, IMHO, is a
mess.  And *very* large.

Joseph
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Jeff Garzik
> Sent: Thursday, September 16, 1999 3:01 PM
> To: [e-mail]
> Subject: [OpenBIOS] some links
>
> This network boot loader project is interesting:
> http://nilo.on.openprojects.net/
>
> Most the things it references is OsKit, which looks to potentially be
> very valuable to OpenBIOS:  http://www.cs.utah.edu/flux/oskit/
>
> 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

BIOS debug codes.

[Tim Small]

Hi,

I found something interesting in the back of a motherboard manual, the
section is headed
"Uncompressed Initialization Codes", with the subtitle "The following
runtime checkpoint hex codes are listed in order of execution.  These codes
are uncompressed in F0000h shadow RAM."

There follows around 100 codes, with a textual description of each step.
Would anyone be interested in this info (I may try and track down an online
copy, as I'm not keen on doing that much typing).  Does anyone have any
opinions on the legality aspect of posting this info?

Tim.

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

Yup this list is still alive, it just goes through some VERY quiet 
patches. If you're one of the lucky few, you might spark another 
flurry of activity, but who knows?

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

[Clive Jenkins]

At 00:44 16/09/99 -0400, Jeff Garzik wrote:
> Is this list still alive?  I don't see any links to mail archives, but
> the files in the latest source archive are about 10 months old.

Well, I'm listening!
> ...
> Can motherboard chipset coding be done in C?  If not, what needs to be
> fixed before this can happen?

Yes. Chipset registers are normally accessed via I/O ports. Most C
compilers provide appropriate functions such as:

unsigned char	inportb  (unsigned short _port);
unsigned short	inportw  (unsigned short _port);
void		outportb (unsigned short _port, unsigned char  _data);
void		outportw (unsigned short _port, unsigned short _data);

and/or

unsigned char	inp(unsigned short _port);
unsigned short	inpw(unsigned short _port);
void		outp(unsigned short _port, unsigned char _data);
void		outpw(unsigned short _port, unsigned short _data);

The actual types vary between C implementations. Output functions may not
be void: they may return the same _data.
> Also, is www.openbios.org DNS down?  I can't seem to complete a lookup,
> much less a web hit.

I can't access it site either. I believe information about this can be
found at http://www.freiburg.linux.de/openbios/.
--------

At 14:44:11 16/09/99 -0400, Jeff Garzik wrote:
> Finally, another question:  Does OpenBIOS ('make config ; make') built a
> 32-bit protected mode image, or a 16-bit image?  The make output seems
> to imply both, though most of the code I look at is 16-bit.
>
> Can we do _everything_ in protected mode?

BIOS normally operates in real mode, except for identifying the processor
and certain POST tests done in protected mode. All calls from the operating
system or application program into the BIOS (via software interrupts) will
be done in real mode. All calls out of the BIOS (e.g.: to external BIOS
ROMs detected during the ROM scan; to the boot code on the boot sector of
the disk containing the operating system) must also be in real mode. Apart
from these requirements, there is no reason in principle why internal
portions of BIOS code should not run in protected mode. However in practice
I think you would find it very inconvenient having to switch modes all the
time.
--------

At 18:37:48 16/09/99 -0400, Jeff Garzik wrote:
> ... What needs to be done, to write chipset
> drivers in C?

For a start you will need a fully detailed data sheet on the chipset, and
any applications notes and code examples you can find on the chipset's
manufacturer's web site.
--------

Clive

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