RE: [OpenBIOS] ANNOUNCE: Collecting OpenBIOS patches

[Stawnyczy, Evan]

I've been on this OpenBIOS newsletter for almost 2 months... i'ven't seen
much traffic.  However, I would _LOVE_ to contribute, so, can someone tell
me what is required, or in which way i can contribute?

thanks

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

ANNOUNCE: Collecting OpenBIOS patches

[Erwin Rol]

I have been on it for more than a year and i haven't seen much traffic 
either :-)

I am very interested in a way to boot Linux/RTEMS fast. Maybe with some
loggin functionality to a serial port.

But i have the feeling the project kind of grinded to a halt :-/
which is a shame, oh well shit happens.

- Erwin   

"Stawnyczy, Evan" wrote:
> I've been on this OpenBIOS newsletter for almost 2 months... i'ven't seen
> much traffic.  However, I would _LOVE_ to contribute, so, can someone tell
> me what is required, or in which way i can contribute?
>
> thanks
>
> -
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

ANNOUNCE: Collecting OpenBIOS patches

[Ronald G. Minnich]

> I am very interested in a way to boot Linux/RTEMS fast. Maybe with some
> loggin functionality to a serial port.

It's back here, and we're using openbios to support it, and we're
close. Hang on just a bit longer.

ron

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

devbios on linux ln lx440gx+

[Ronald G. Minnich]

here's the problem. I have a:
Linux rp128 2.2.13 #3 SMP Wed Dec 29 09:04:43 MST 1999 i686 unknown

with:

PCI devices found:
  Bus  0, device   0, function  0:
    Host bridge: Intel Unknown device (rev 0).
      Vendor id=8086. Device id=71a0.
      Medium devsel.  Master Capable.  Latency=64.  
      Prefetchable 32 bit memory at 0xf8000000 [0xf8000008].
  Bus  0, device   1, function  0:
    PCI bridge: Intel Unknown device (rev 0).
      Vendor id=8086. Device id=71a1.
      Medium devsel.  Master Capable.  Latency=64.  Min Gnt=132.
  Bus  0, device  18, function  3:
    Bridge: Intel 82371AB PIIX4 ACPI (rev 2).
      Medium devsel.  Fast back-to-back capable.  


I think the 71a0 is the PCI host bride for the 440gx+, which is close to a
440gx hostbridge (the 440gx is a 7180, I think). I added this to the
devbios pci bridge table:

const struct functions pci_functions[] = {
  { (int[]) { 0x8086122d, 0x80861235, 0x80861237, 0x80861250, 0x80867030,
              0x80867100, 0x80867180, 0x808684c4,
              /* 440gx+? */ 0x808671a0,
              0 },
    (int[]) { 0x8086122e, 0x80861234, 0x80867000, 0x80867110,
              0 },
    intel_shadon, intel_shadoff, intel_wpon, intel_wpoff, intel_backout },


Devbios now finds my pci hostbridge, finds the ISA bridge, and then tries
to probe the BIOS memory with no luck. What this means is that I can't get
to the flash. The flash is an Intel 28F008S5 part.

The values of the hostbridge and PIIX4 registers look like devbios expects
them to. I've moved the jumper to enable BIOS writes. 

Any good ideas on what I could be missing?

Thanks
ron

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

ANNOUNCE: Collecting OpenBIOS patches

[Ronald G. Minnich]

On Wed, 19 Jan 2000, Stawnyczy, Evan wrote:
> I've been on this OpenBIOS newsletter for almost 2 months... i'ven't seen
> much traffic.  However, I would _LOVE_ to contribute, so, can someone tell
> me what is required, or in which way i can contribute?

yes, one thing I could really use is a summary of how you get devbios to
write to the flash ram on an intel nightshade (440gx+). I don't have this
right now. 

We're getting pretty close here to frying -- er, flashing the bios from
linux, but I'm stuck on this last step. I'm pretty sure it's the
motherboard jumper. 

I'm also going to mod devbios a little (replace things like 0x40 with
#define-type constants etc.) to make it a bit more readable.

ron

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

Bios Writer for dos?

[Edwin Rhodes]

Hi is there a flash writer for dos? Also where can i get the latest open
bios image? also, is there a way to boot open bios without flashing it into
rom? and what size rom does it need? will it work with any 386 or 486
generic intel cpu?
thanks
edwin

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

Bios Writer for dos?

[Jeff Garzik]

Edwin Rhodes wrote:
> Hi is there a flash writer for dos? Also where can i get the latest open
> bios image? also, is there a way to boot open bios without flashing it into
> rom? and what size rom does it need? will it work with any 386 or 486
> generic intel cpu?

If you are looking for just a generic flash writer, use the one that
came with your motherboard.  If you have an AMI BIOS, use AMI's flash
writer.  There is nothing magical about the ROMs loaded by these
programs :)

-- 
Jeff Garzik         | Andre the Giant has a posse.
Building 1024       |
MandrakeSoft, Inc.  |
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

INFO: How to contribute to OpenBIOS

[Jeff Garzik]

"Stawnyczy, Evan" wrote:
> I've been on this OpenBIOS newsletter for almost 2 months... i'ven't seen
> much traffic.  However, I would _LOVE_ to contribute, so, can someone tell
> me what is required, or in which way i can contribute?

Building OpenBIOS is quite easy, all you really need above a standard
Linux development system is 'nasm', which you can get from
http://www.web-sites.co.uk/nasm/

Since the wishlist on the Web site is so long as to be unusable, here is
a short list of important tasks, and how you can contribute:

*** Implement BIOS interrupts.

MS-DOS, LILO, and many other operating systems and programs use BIOS
calls to communicate with the low-level hardware in a standard way. 
OpenBIOS needs the most popular BIOS calls implemented, so that DOS and
others can allocate memory, read/write to the drives, and similar
things.

At present there is no BIOS interrupt processing in OpenBIOS.  So tasks
include (a) add the necessary hooks for BIOS interrupt processing, and
(b) implenting each BIOS call one-by-one.

Interested programmers should implement just one or two BIOS calls, then
send me a patch.  That way we can make the BIOS interrupt framework
public, so that many others can work individually implementing various
BIOS calls.


*** Support motherboard chipsets

Beginners come here!  This is one of the easier OpenBIOS tasks, and also
one of the most important.

Every motherboard has a core chipset which controls major functions like
talking to peripherals, RAM sizing, power management, and similar
tasks.  And each chipset is slightly different from one another in the
methods by which these tasks are accomplished.

If you want to contribute to OpenBIOS, the best thing you can do is get
the hardware datasheet for your motherboard -- it lists all the
motherboard registers -- and add bootstrap support for your chipset.

This task requires that you know a _little_ assembly language, enough at
least to look at the existing OpenBIOS chipset code and copy from there.

Steps to support a motherboard chipset the easy way:
* Figure out how your motherboard does RAM detection
* Go through your motherboard datasheet, and write down a good,
conservative (ie. SLOW) value for each register
* Write this list of registers into an assembly language data table
* Write code which runs through this table, writing each register value
to the motherboard chipset registers

Note that Intel and many other motherboard chipset vendors make their
databooks (specs) publicly available on the Web.


*** Support BIOS extensions

A third important task is supporting key BIOS extensions, such as the
PCI BIOS.

This task is similar to the BIOS interrupt task above.


-- 
Jeff Garzik         | Andre the Giant has a posse.
Building 1024       |
MandrakeSoft, Inc.  |
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

INFO: How to contribute to OpenBIOS

[Bob Dobbs]

Jeff Garzik wrote:
> *** Implement BIOS interrupts.
>
> MS-DOS, LILO, and many other operating systems and programs use BIOS
> calls to communicate with the low-level hardware in a standard way.
> OpenBIOS needs the most popular BIOS calls implemented, so that DOS and
> others can allocate memory, read/write to the drives, and similar
> things.
>
> At present there is no BIOS interrupt processing in OpenBIOS.  So tasks
> include (a) add the necessary hooks for BIOS interrupt processing, and
> (b) implenting each BIOS call one-by-one.
>
> Interested programmers should implement just one or two BIOS calls, then
> send me a patch.  That way we can make the BIOS interrupt framework
> public, so that many others can work individually implementing various
> BIOS calls.
> Also important is an OpenFirmware interface because we should migrate
> away from x86 real mode interupt system. OpenFirmware would give us a
> clean, standard way for boot loaders or OS's to talk to the hardware. It
> would give us a configuration interface (albeit not too simple). And we
> could include a couple (or one or three) bootloader packages, e.g.
> linux_boot, multi_boot, chain_boot.

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

INFO: How to contribute to OpenBIOS

[Jeff Garzik]

Bob Dobbs wrote:
> Also important is an OpenFirmware interface because we should migrate
> away from x86 real mode interupt system. OpenFirmware would give us a
> clean, standard way for boot loaders or OS's to talk to the hardware. It
> would give us a configuration interface (albeit not too simple). And we
> could include a couple (or one or three) bootloader packages, e.g.
> linux_boot, multi_boot, chain_boot.

I have already given some thought to this.  Definitely a good idea.

This is especially good for video devices, as it provides a clean way to
boot multiple cards (normally difficult as most BIOS's only POST a
single card).

-- 
Jeff Garzik         | Andre the Giant has a posse.
Building 1024       |
MandrakeSoft, Inc.  |
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

INFO: How to contribute to OpenBIOS

[Niklas Ekström]

I just though I should mention that I am, and has been for a while, 
programming an OpenFirmware compliant bios. The code is not available yet, 
but will be when it's finnished. I'm aiming to implement all three major
OF interfaces (device, user, client). So far I have done the devicetree
and the FCode evaluator. Untill I release the code I don't know how this
could benefit anyone else, but atleast now you know that someone else is
also working on this.

Since I'm not working on OpenBIOS I guess I shouldn't comment on how it
should be done. But as a general though about programming (and possible
all intellectual work at all), my opinion is that you should first make a
strategy and write a design, and first after that start to do the actual
work (code). When solving a physics problem you don't start by doing 
experiments and first after that find out what the experiments was good
for, if at all (atleast that's not the way you _should_ do it! ;). From
the above you can probably guess what I think about the "hack-and-go"
approach I've seen mentioned here at times.

/ Niklas


On Mon, 24 Jan 2000, Bob Dobbs wrote:
> Also important is an OpenFirmware interface because we should migrate
> away from x86 real mode interupt system. OpenFirmware would give us a
> clean, standard way for boot loaders or OS's to talk to the hardware. It
> would give us a configuration interface (albeit not too simple). And we
> could include a couple (or one or three) bootloader packages, e.g.
> linux_boot, multi_boot, chain_boot.
>
> -graham

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

INFO: How to contribute to OpenBIOS

[Charles Esson]

Are you writing it in FORTH or C?

If writing in FORTH,  at the moment I am working on a FORTH TCP stack and OS
for the COLDFORTH which will be released under the GPL in February. The stack
may be of use ( a bios should be able to boot off the net).

If I can be of any assistance let me know. This is the way a BIOS should be
written. I also agree with your design comments. Hack and go it a good way to
get the needed background to design you application, nothing more.

Regards
Charles Esson

Niklas Ekström wrote:
> I just though I should mention that I am, and has been for a while,
> programming an OpenFirmware compliant bios. The code is not available yet,
> but will be when it's finnished. I'm aiming to implement all three major
> OF interfaces (device, user, client). So far I have done the devicetree
> and the FCode evaluator. Untill I release the code I don't know how this
> could benefit anyone else, but atleast now you know that someone else is
> also working on this.
>
> Since I'm not working on OpenBIOS I guess I shouldn't comment on how it
> should be done. But as a general though about programming (and possible
> all intellectual work at all), my opinion is that you should first make a
> strategy and write a design, and first after that start to do the actual
> work (code). When solving a physics problem you don't start by doing
> experiments and first after that find out what the experiments was good
> for, if at all (atleast that's not the way you _should_ do it! ;). From
> the above you can probably guess what I think about the "hack-and-go"
> approach I've seen mentioned here at times.
>
> / Niklas
>
> On Mon, 24 Jan 2000, Bob Dobbs wrote:
> > Also important is an OpenFirmware interface because we should migrate
> > away from x86 real mode interupt system. OpenFirmware would give us a
> > clean, standard way for boot loaders or OS's to talk to the hardware. It
> > would give us a configuration interface (albeit not too simple). And we
> > could include a couple (or one or three) bootloader packages, e.g.
> > linux_boot, multi_boot, chain_boot.
> >
> > -graham
>
> -
> 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

INFO: How to contribute to OpenBIOS

[Massimo Dentico]

Charles Esson wrote:
> Are you writing it in FORTH or C?
>
> If writing in FORTH,  at the moment I am working on a FORTH TCP stack and OS
> for the COLDFORTH which will be released under the GPL in February. The stack
> may be of use ( a bios should be able to boot off the net).
>
> If I can be of any assistance let me know. This is the way a BIOS should be
> written. I also agree with your design comments. Hack and go it a good way to
> get the needed background to design you application, nothing more.
>
> Regards
> Charles Esson
>
> Niklas Ekström wrote:
> > I just though I should mention that I am, and has been for a while,
> > programming an OpenFirmware compliant bios. The code is not available yet,
> > but will be when it's finnished. I'm aiming to implement all three major
> > OF interfaces (device, user, client). So far I have done the devicetree
> > and the FCode evaluator. Untill I release the code I don't know how this
> > could benefit anyone else, but atleast now you know that someone else is
> > also working on this.
> >
> > Since I'm not working on OpenBIOS I guess I shouldn't comment on how it
> > should be done. But as a general though about programming (and possible
> > all intellectual work at all), my opinion is that you should first make a
> > strategy and write a design, and first after that start to do the actual
> > work (code). When solving a physics problem you don't start by doing
> > experiments and first after that find out what the experiments was good
> > for, if at all (atleast that's not the way you _should_ do it! ;). From
> > the above you can probably guess what I think about the "hack-and-go"
> > approach I've seen mentioned here at times.
> >
> > / Niklas
> >
> > On Mon, 24 Jan 2000, Bob Dobbs wrote:
> > > Also important is an OpenFirmware interface because we should migrate
> > > away from x86 real mode interupt system. OpenFirmware would give us a
> > > clean, standard way for boot loaders or OS's to talk to the hardware. It
> > > would give us a configuration interface (albeit not too simple). And we
> > > could include a couple (or one or three) bootloader packages, e.g.
> > > linux_boot, multi_boot, chain_boot.
> > >
> > > -graham

A FORTH TCP stack .. very interesting. Charles I don't
remember what is COLDFORTH and I am not able to find
references about COLDFORTH on the net. Is it a Forth-based
board (stack processor)?

However, there is an ongoing Forth OS project released
under the GPL, currently based on Intel x86 architecture,
with which it would be possible exchange ideas and code
(Forth and Assembly); an exchange beneficial, I think,
for OpenBIOS also. It's "Retro/Forth OS" project:

- http://retro.tunes.org/

Charles and Niklas are there URLs for your projects?
Niklas what's the license of your BIOS?

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

INFO: How to contribute to OpenBIOS

[Charles Esson]

> A FORTH TCP stack .. very interesting. Charles I don't
> remember what is COLDFORTH and I am not able to find
> references about COLDFORTH on the net. Is it a Forth-based
> board (stack processor)?

I am using the COLDFIRE processor, so I called it COLDFORTH ( not very
imaginative), 90+% is written in FORTH, assembler is restricted to the base word
set, with a little in the scheduler, which is pre-emtive. All the interrupt code is
in FORTH also.

It is a subroutine threaded FORTH ( needed if your going to write as much as
possible in FORTH).

The project was started because MOTOROLA stopped producing the 68K, our original OS
was mostly written in Assembler I didn't want to make that mistake again.

It is a self reproducing system so it is built using a cross compiler, in the long
term I plan on porting the xcompiler to G forth.

I intend to put up a WEB site and CVS server next month, you can currently look at
the code with a web browser at: 203.87.14.203
> However, there is an ongoing Forth OS project released
> under the GPL, currently based on Intel x86 architecture,
> with which it would be possible exchange ideas and code
> (Forth and Assembly); an exchange beneficial, I think,
> for OpenBIOS also. It's "Retro/Forth OS" project:

I did not know about it.
> - http://retro.tunes.org/
>
> Charles and Niklas are there URLs for your projects?
> Niklas what's the license of your BIOS?

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

INFO: How to contribute to OpenBIOS

[Jeff Garzik]

Niklas Ekström wrote:
> Since I'm not working on OpenBIOS I guess I shouldn't comment on how it
> should be done. But as a general though about programming (and possible
> all intellectual work at all), my opinion is that you should first make a
> strategy and write a design, and first after that start to do the actual
> work (code). When solving a physics problem you don't start by doing
> experiments and first after that find out what the experiments was good
> for, if at all (atleast that's not the way you _should_ do it! ;). From
> the above you can probably guess what I think about the "hack-and-go"
> approach I've seen mentioned here at times.

"hack-and-go" is known more formally as a more iterative approach to
design.  In my experience up-front designs are helpful as roadmaps, but
are _very rarely_ accurate once you reach the end of the road.

As many open source projects have shown, all you need is a
discriminating maintainer in order to succeed, NOT a good design.  A
poor design will show up quickly, and patches from developers will
follow shortly thereafter.  That is what the history of open source
projects have shown so far -- the design gets iteratively better and
better as time passes.

Further, hack-and-go means that results are in the hands of users more
quickly.  And we developers should never forget our target audience, and
their desired results...

	Jeff "hack-and-go" Garzik





-- 
Jeff Garzik         | Andre the Giant has a posse.
Building 1024       |
MandrakeSoft, Inc.  |
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

INFO: How to contribute to OpenBIOS

[Ronald G. Minnich]

On Tue, 25 Jan 2000, Jeff Garzik wrote:
> Niklas Ekstr�m wrote:
> > When solving a physics problem you don't start by doing
> > experiments and first after that find out what the experiments was good
> > for, if at all (atleast that's not the way you _should_ do it! ;). From
> > the above you can probably guess what I think about the "hack-and-go"
> > approach I've seen mentioned here at times.
>
> "hack-and-go" is known more formally as a more iterative approach to
> design.  In my experience up-front designs are helpful as roadmaps, but
> are _very rarely_ accurate once you reach the end of the road.

yes, but jeff, let's keep this in mind when we start using openbios for
physics problems. Until then, though, OpenBios looks like an engineering
problem, with breadboards and testbeds. Which can be misconstrued as "hack
and go" if you haven't been at this kind of thing for very long :-)

ron
p.s. Not that I want to interfere with anyone's right to slam everyone on
this list :-)

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