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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 :)
"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 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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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).
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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:
Charles and Niklas are there URLs for your projects? Niklas what's the license of your BIOS?
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.
Charles and Niklas are there URLs for your projects? Niklas what's the license of your BIOS?
-- Massimo Dentico
To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
-
Bob Dobbs -
Charles Esson -
Edwin Rhodes -
Erwin Rol -
Jeff Garzik -
Massimo Dentico -
Niklas Ekström -
Ronald G. Minnich -
Stawnyczy, Evan