November 1998 - OpenBIOS - mail.coreboot.org

Logo
by Daniele 'Realcosmo' Frijia Nov. 21, 1998

Nov. 21, 1998

hiho... stefan and me had the idea, to make a logo contest... i think it's necessary to make a logo, that says "ahh...i know this logo..it's that from OpenBIOS !" ;-) suggestions, comments ? greetings... Daniele .oO http://realcosmo.hat.gelitten.org realcosmo(a)hat.gelitten.bei.infra.de Oo.

2 1

Re: OpenBIOS news.
by Andrew Kohlsmith Nov. 20, 1998

Nov. 20, 1998

I had lost this mailing list for a few months this summer and when I finally do find it I find that there is something tangible to play with. Most excellent. :-) > Daniel Engstroem told, that he would prefer "Generic Firmware" as name > for this project. This is sure a philosophical question, but I'd like > to see the word "Open" in our project name. As OpenFirmware is already > taken by the IEEE standard, I decided to use OpenBIOS. On the other > hand, what we want to do is not to write just another BIOS like MR > BIOS, Award BIOS, Ami BIOS, Phoenix BIOS, ... but something completely > new with the approach of being modern. Personally I love the name OpenBIOS. It kind of goes well with the F-CPU. Just because it has the acronym "BIOS" in it doesn't mean it can't be something better than anything else with the same acronym. > 6) I thought about writing email to some chipset manufacturers to ask > whether they want to participate in our project by writing free code > for their hardware. Does anyone have an idea what to write? I would guess that the best method to target the chipset manufacturers would be to indicate that by releasing the specifcations to their chipsets they are making it available to MANY more people than they would via an NDA or similarly closed agreement policy. Look at Apple/IBM... As far as having the chipset manufacturers write code... I doubt they'd be interested... that is what the databooks are for, for someone *else* to use *their* hardware. :-) As far as licensing goes, I agree that it should be licensed such that it remains free and in the public domain no matter what gets done with it. I too am lacking in the license knowledge department, however. Andrew

1 0

OpenBIOS news.
by Stefan Reinauer Nov. 20, 1998

Nov. 20, 1998

Dear OpenBIOS readers, at first I have to tell you that I am totally overwhelmed by the subscriptions in the last three days. Our project has been announced on http://slashdot.org/ and will be announced on http://news.freshmeat.net/ this evening or tomorrow. Well, I saw some wishes on the wishlist, that I think are necessary to discuss here. 1) Licence Is anything speaking against using GPL as licence for OpenBIOS? I am not really into that licencing stuff. Would it be better to use some kind of BSD licence or even the Netscape NPL? I want to make sure that this project will remain free forever and people can use it for free, no matter whether it is commercial use or not. And, of course, I think it would be best, if changes made by foreign contributors are included into the official project. 2) Name Daniel Engstroem told, that he would prefer "Generic Firmware" as name for this project. This is sure a philosophical question, but I'd like to see the word "Open" in our project name. As OpenFirmware is already taken by the IEEE standard, I decided to use OpenBIOS. On the other hand, what we want to do is not to write just another BIOS like MR BIOS, Award BIOS, Ami BIOS, Phoenix BIOS, ... but something completely new with the approach of being modern. 3) Supported hardware Many people told me that they would like to see support for recent PCI hardware only. I think this makes sense, because it's easy to autoprobe chipset type and SuperIO type on the PCI bus. This allows us to have one generic firmware image that can be flashed to a couple of different machines that have different motherboards. This is especially nice for people with large computer pools (like admins of universitiy pools) Please note: I don't want to keep anyone from writing support for his very own hardware, but the main goal must be to support current stuff. This is IMHO the only way to reach a wide usage of OpenBIOS/GFW 4) There have been many new wishes on the wishlist today, please check them out at http://www.freiburg.linux.de/OpenBIOS/wishlist/ and *DO* comment on them. 5) I noticed that the wishlist is still a bit buggy, especially with handling the dates of entries. I hope I get the time to fix that very soon. 6) I thought about writing email to some chipset manufacturers to ask whether they want to participate in our project by writing free code for their hardware. Does anyone have an idea what to write? So, happy hacking, guys :-) Stefan.

1 0

OpenBIOS wishlist
by Stefan Reinauer Nov. 16, 1998

Nov. 16, 1998

Hi... I've written a little script to maintain a wishlist for openbios/gfw. This is easier than editing the homepage every time there's a new idea. You can have a look at it or add own entries on http://www.freiburg.linux.de/OpenBIOS/wishlist/ Best regards, Stefan -- Sex is one of the nine reasons for reincarnation ... the other eight are unimportant. -- Henry Miller

1 0

Re: OpenBIOS has first Code :-) (fwd)
by Ragnar Hojland Espinosa Nov. 15, 1998

Nov. 15, 1998

Since it looks it didn't make it here: (or at least I didn't get it) On Sat, 14 Nov 1998, Stefan Reinauer wrote: > Dear Linux-Kernel readers, > > This may be somewhat offtopic for most of you, but as I guess it's interesting > for many others, I decided to send this mail to linux-kernel. It's about the > OpenBIOS project. Our goal is to write a free, completely configurable firmware > that is availbale under GNU PL. > > I had the time to have a closer look at Daniel Engstroems code now and I > think we should use this as a code base for further developments. > I've played around a bit with the Makefiles and you can now configure the > firmware setup by using make menuconfig or make config, like in the linux > kernel. make xconfig doesn't work correctly right now, because I had to > add some changes to the whole bunch of Linux configuration scripts to > allow a more general usage. > > Get OpenBIOS 0.0.1 (completely based on Daniel's gfw-0.1) from > http://www.freiburg.linux.de/OpenBIOS/ > > We only have support for 3 chipsets right now, which is definitely not > enough. I will try to write support for the Intel 430HX/TX/VX/.. chipsets, > as I have an old HX board at home. If anyone is capable of doing this > (it's not really hard, as you just need the datasheets for your chipset > and a board containing the chipset itself to test) > > Now, at the moment, we don't have hardware drivers for any bootdevices. > Should we go the way linux goes and write our own drivers or should we try > to use other bioses (i.e. scsi bios on host adapter) for that? > > The second thing may be simpler and shorter, but I guess the first one is > the way to go because we need drivers for floppies, parport devices etc, > too.. :) > > Well.. I wrote this just to start discussion again :-) > > Best regards, > Stefan. > > -- > Reincarnation: Life sucks, then you die. Then life sucks again. -- ____/| Ragnar Hojland (ragnar(a)lightside.ddns.org) Fingerprint 94C4B \ o.O| _______________________________________________ 2F0D27DE025BE2302C =(_)= | 7 Diciembre, manifestacion contra Telefonica! | 104B78C56 B72F0822 U | No faltes!! http://www.internautas.org/7D/) | hkp://keys.pgp.com ----------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)psychosis.com Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: A little patch
by Philipp Rumpf Nov. 15, 1998

Nov. 15, 1998

On Sun, Nov 15, 1998 at 02:40:24AM +0100, daniel.engstrom(a)riksnett.no wrote: > On 15 Nov, Philipp Rumpf wrote: > >> Can anybody figure out why the memtest fails? (boot/init32/memtest.S) > > > > %edx is 0 ? > > cause you write > > > > cmpl $0, %edx # did we relocate earlier ? > > je .out > > ^^^^ does not reset %eax, which is 0x10000 in the moment > Thanks, (blaming the coffee) fixed now, time to hunt the next bug. What one ? Apropos bug: Stefan, when do you want to put a new devbios version on the net, here is my patch (against 0.2.100) again (I'll post it here cause it's small enough and if some people are brave enough to flash OpenBIOS sometime soon they should be sure they don't run into one of the bugs and cause their system to hard-reboot half-way of flashing a new BIOS(as this is definitely _no_ good time to reboot)). I am currently reading the 82371 / 82430 documentation, perhaps I'll be able to write something tomorrow, but my 3am code is not that good normally. Philipp Rumpf (prumpf(a)jcsbs.lanobis.de)

1 0

A little patch
by Daniel Engstrom Nov. 14, 1998

Nov. 14, 1998

This is against gfw-0.1 (I have note switched to Stepans version yet) * exception cleanup * console in works * the beginnings of a memory tester Can anybody figure out why the memtest fails? (boot/init32/memtest.S) /Daniel --

2 1

Re: New Code :-)
by daniel.engstrom＠riksnett.no Nov. 14, 1998

Nov. 14, 1998

On 13 Nov, Stefan Reinauer wrote: > Dear OpenBIOS readers, > > I had the time to have a closer look at Daniel Engstroems code now and I > think we should use this as a code base for further developments. (Daniel, > I hope, you allow this :>) Ok. :) About the name, when I thought of the name I very delibraty(sp?) avoided the use of the word 'BIOS', since we're actually not trying to clone the BIOS, but doing something rather generic. Not that this is important or anything... > > We only have support for 3 chipsets right now. 2, the Ali 1510 support does not work yet... > which is definitely not > enough. I will try to write support for the Intel 430HX/TX/VX/.. chipsets, > as I have an old HX board at home. If anyone is capable of doing this > (it's not really hard, as you just need the datasheets for your chipset > and a board containing the chipset itself to test) I must admit that having the data sheets helps, but the only chipset I have found data sheets for is the ACC1287. Having a working bios image on disk is what really helps, ndissasm is your friend. Hint: the bios enters at 0xffff0 (eg. 'ndissasm -e 0xfff0 -o 0xffff0 rom.bin > bin.txt' for a 64k bios) > I thought about building something like an eprom simulator which can be > plugged into the bios socket of a board and to the parallel port of > another computer which just holds a file with the bios image. This would > make defelopment and testing *quite* faster. Has anyone experiences with > this or does anyone know whether there are ready, cheap solutions for > this? I know they exist. A one Mbit version costs about $500 here. They can be bough from DanBit http://www.danbit.dk (Danish languge pages only) A friend of mine is thinking of designing one for other reasons, he can be found at http://www2.e.kth.se/~e92_jre/ . A port 0x80 decoder is very useful... > Now, at the moment, we don't have hardware drivers for any bootdevices. > Should we go the way linux goes and write our own drivers or should we try > to use other bioses (i.e. scsi bios on host adapter) for that? I think we need to do at least floppy and IDE ourself. That will keep us busy for a while... I still haven't given up on the idea of being 100% OpenFrimware compatible at some point in the future. > Well.. I wrote this just to start discussion again :-) Some notes on the current code: The chipset drives are not finished. I am planning of having a 2nd stage C part of them that runs shortly after the console is initialized, it would probe and test the memory above 1MB. (The 16 bit asm version should enable memory below 1MB with a safe timing.) The last part, also in C should set the memory timings to a value specified by the user (saved in the NVRAM, obiusly) the boot/init32 directory should be moved to the top level firmware dir. Only MDA displays are working, the EGA/VGA stuff is some bone headed attempt to get those working without using their BIOSes, it might work for some cards some day, the other plan is to steal some 386-emulator to parse the video BIOS with, like the ppc/alpha people do (calling the video BIOS directly would just postpone the problem 'til we port this to a non-386 compatible processor, besides the BIOS is 16bit anyway). Console in is not done yet. I can read the keyboard, but I don't keep track of the shift-state, etc. Serial console in is not done yet. (What terminal emulation should we use? Some very basic I think.) Serial console is fixed to com1,9600,8n1 Oh, and the board I have been using are Ampro CM2/3SXi, CM2/4DXi, LB3/P5i. I also have an old ASUS 486 board with a SIS chipset, that I plan on doing (I have the chipset manual, but the board have an Eprom istead of a flash, and I have no 28pin flashes around) /Daniel --

3 3

Re: New Code :-)
by Qiwei Xiao Nov. 13, 1998

Nov. 13, 1998

Stefan Reinauer wrote: > > Dear OpenBIOS readers, > > ... > > I thought about building something like an eprom simulator which can be > plugged into the bios socket of a board and to the parallel port of > another computer which just holds a file with the bios image. This would > make defelopment and testing *quite* faster. Has anyone experiences with > this or does anyone know whether there are ready, cheap solutions for > this? > I have been thinking about building such eprom simulator as well. The circuit needs at least 10 74xx/40xx ICs to build. I can post the schematic if anybody is interested but I don't know if it is worth the effort to build such a simulator. The solution I am thinking of using is this: (1) Buy an EPROM/Flash ROM writer. The cheapest I have found is around US$150. It can handle a ROM up to 8M of size. (2) Build a small board with a ZIP socket and hook it up to the EPROM socket on the MB so I don't have to worry about damaging the MB when insert/remove the ROM frequently. This, although not as fast as eprom simulator, should work well. The only thing I am not happy with is that the EPROM writer only works on Windows. I hate to boot up Windows for a single minute. Another viable solution is to use devbio (thanks, Stefan). But still I need to build a board with two ROM sockets and a soft "switch" so that I can boot up the PC using the good bios on one ROM, switch to the other ROM, write the new bios image to it using devbio, reboot and test. But the circuit is not substantially simpler than the ROM simulator. Cheers, Qiwei

1 0

New Code :-)
by Stefan Reinauer Nov. 13, 1998

Nov. 13, 1998

Dear OpenBIOS readers, I had the time to have a closer look at Daniel Engstroems code now and I think we should use this as a code base for further developments. (Daniel, I hope, you allow this :>) I've played around a bit with the Makefiles and you can now configure the firmware setup by using make menuconfig or make config, like in the linux kernel. make xconfig doesn't work correctly right now, because I had to add some changes to the whole bunch of Linux configuration scripts to allow a more general usage. Get OpenBIOS 0.0.1 (completely based on Daniel's gfw-0.1) from http://www.freiburg.linux.de/OpenBIOS/ We only have support for 3 chipsets right now, which is definitely not enough. I will try to write support for the Intel 430HX/TX/VX/.. chipsets, as I have an old HX board at home. If anyone is capable of doing this (it's not really hard, as you just need the datasheets for your chipset and a board containing the chipset itself to test) I thought about building something like an eprom simulator which can be plugged into the bios socket of a board and to the parallel port of another computer which just holds a file with the bios image. This would make defelopment and testing *quite* faster. Has anyone experiences with this or does anyone know whether there are ready, cheap solutions for this? Now, at the moment, we don't have hardware drivers for any bootdevices. Should we go the way linux goes and write our own drivers or should we try to use other bioses (i.e. scsi bios on host adapter) for that? The second thing may be simpler and shorter, but I guess the first one is the way to go because we need drivers for floppies, parport devices etc, too.. :) Well.. I wrote this just to start discussion again :-) Best regards, Stefan. -- Sex is one of the nine reasons for reincarnation ... the other eight are unimportant. -- Henry Miller

1 0