January 1999 - OpenBIOS - mail.coreboot.org

Hello, introducing myself, big rant and newbie (on this list) questions [LONG]
by Mircea Ciocan Jan. 31, 1999

Jan. 31, 1999

Hi all, My name is Mircea Ciocan, presently I'm struggling as a sysadmin at a small ISP and data carrier in Romania, but my "love of the heart" was allways low level asm programming and hardware hacking. < rant mode on - you may skip that > So few days ago I was thinking how can I become as rich as BillG. or as famous as Linus ;), remembering that some time ago there was still a need for people who can do asm and wrote their own device drivers. But I'm not so smart to make a better Linux and I hate any kind of spreadsheet so billgatising is not an issue. But what can do an old low level programmer and hardware guy do to reward somehow the community that gived him Linux and all those beautifull tools that allow him a (reletively) quiet and fruitfull job ??? Browsing deadly bored on the FSF site I see that on their task list the project of an open BIOS and I rememberd that I see on /. that a new project was started and after a little search I find you guys :). By some kind of miracle on the same time few other things happend: On /. was announced the smallest PC that can run Linux, making me deathly gelous that I wasn't the first to do that ;) and remembering that with a lot of time ago I haved the smallest ZX Spectrum compatible in Romania :). I found the nicest and affordable board that a hacker can find as a Mini Internet Gateway build along in a nice case with power supply, 2 serial ports, one Realtek 8019 Ethernet controller with dual interface, twisted and coax cable, 1MB of RAM and 512KB of FlashROM, "powerd by the ferocious" ALI 6117C processor ( something like 386SX/40) all on a board of 100x110mm cased in a nice little plastic case[1]. The beast was used for connecting a network of max 256 station on 1 or 2 dial-up/leased/ISDN, it has a DHCP server for those windoze machines ;), it can be administrated remotely by telnet and WEB interface, it has built-in IP masquerading, traffic shaper, firewalling and it was a dream to work with. It saved me and my company a LOT of problems (and money) by zapping expensive routers, expensive windozian proxyes and wingates :) and yes, even Linux boxes and all that under 200$ !!!!. So I felt in love instantly, but with the hackerish devil in me just awaken, I mistreated a poor box to "see what's inside", beeing firmly convinced that is some proprietary chip design and I can never make it to mount network drivers and serve custom web pages for example, not to mention some other nice usages. To my great surprise the little thing has the above configuration and I said "You're mine baby, you'll run Linux in 2 weeks from now and you'll be everything that I want to do with you like a wereable(?) computer, network driven EPROM programmer and many other automation thingies ;)))". The joy was quickly shadowed by the fact that that the manufacturer of the chips "Acer Labs Int'l" (ALI)[2] IS THE MOST ANAL RETENTIVE AND IDIOTIC CHIP MANUFACTURER IN THE WORLD !!! Now I feel better that I said it ;). Protected by password datasheets, no email address, a Taiwan BBS number that don't work and nothing more than some description, it was a real shock me that almost make me hack their american Solaris web host, but I think: what the hell, I just need a embedded BIOS with serial redirection and screw ALI. After another day browsing the Internet for a BIOS and seeing it at prices between 200-2000$ I give up closed source and see the light: "... the world needs an OpenBIOS, and mostly an embedded one ;)))" On the same time frame a customer with a lot of measurement points that spits their measured values on modems ask us if he can use our microwave MAN for colecting data, given that Breezecom[3] adapters we use have a phone voice channell simulating a PSTN. Unfortunately the modems did not work well on voice channel ( it wasn't intended for that) so I came with the ideea of simulating a modem by network and to use this little beasts, so now I have more time and resources to work on the BIOS project. So, all in all I'm here, all yours, eager to help, code and be if not a Linus to BIOSes but maybe a little Alan Cox or Dave Miller. And now let's get to real ( even protected mode) things ;) < /rant mode off, thank you for your patience.. > Questions (not in relevant order): 1) It is considered in this project an embedded BIOS for small appliance, industrial PCs or PC104 ? 2) Is the list archived somewere? 3) Have you guys established the guide lines of this project and freezed the specifications? 4) Does the above specifications contain something about embedded BIOSEs and if yes, who is the sub-project leader? 5) What is the organisation of this project, who are the leaders and how many of you are here ( I'll be glad to receive personal mail from you to meet you all) ? 6) [IMPORTANT] Does anybody has specifications of those beasts: ALI 6117C ALI M5113-A2 ALI M5232-A1 and if so can he/she share it with me? 7) Is anybody working at some related boards like the above one? 8) What kind of develpment tools you standardised ( assembler,debugger and so..)? OK, this I'll figure soon when I'll try to see what's in the code tar ball. In the end of this long and boring post thank you for your patience and I hope that I can be part of your team for a real free BIOS embedded or not ;). Mircea C. P.S. For the pacient of you who made it here some pointers: [1] http://www.surecom.com.tw/ - SURECOM - the maker of Internet Gateway/Hub on that beautifull board. [2] http://www.ali.com.tw/ - Acer Labs - and their most idiotic overseas site: http://www.acerlabs.com/ [3] http://www.breezecom.com/ - BREEZECOM - manufacturers of microwave WAN adapters, in essance small calculators that are even cuter than Surecom

1 0

Re: BIOS Autodetection Design
by M Carling Jan. 12, 1999

Jan. 12, 1999

> >The objective is not to write OpenBIOS such that (in practice) a single > >compiled image can boot any chipset. Rather, the autodetect objective is > >that a set of chipsets may be chosen at compile time from which the image > >is about to boot. Thus, for example, a MB manufacturer could compile a > >BIOS such that one image would work for all the MBs that they manufacture. > If this (compile time selection) is the objective, why call it autodetect? I > would have thought from the name that one image fits all. Then, at run time > it is autodetected, requiring all of the tables at once. If someone chooses a set of chipsets at compile time, and then compiles an image which can automatically detect which of those chipsets it on the MB on which it finds itself running, why not call that autodetect? Do you have a better name in mind for such functionality? Note that the software architecture would not impose any particular limit on the size of the set of chipsets for which support could be compiled in. Rather the size of the image is the only constraining factor. I cannot think of an application that would require a BIOS image that supports more than a handfull of chipsets. MB manufacturers wouldn't need more than a handful, home users wouldn't need more than a handful, and embedded systems builders probably wouldn't need more than one. Who needs a BIOS compiled to run on every machine? M

2 1

Re: BIOS Autodetection Design
by M Carling Jan. 12, 1999

Jan. 12, 1999

Erin R. Kern wrote: > The tables for all of the chipsets that you want to support would fill > any BIOS EEPROM on the market and you haven't even written one line of > code yet. The objective is not to write OpenBIOS such that (in practice) a single compiled image can boot any chipset. Rather, the autodetect objective is that a set of chipsets may be chosen at compile time from which the image is about to boot. Thus, for example, a MB manufacturer could compile a BIOS such that one image would work for all the MBs that they manufacture. Do you think this has any merit, Eric? M

3 2

Chipset autodetect -- pro and con
by M Carling Jan. 12, 1999

Jan. 12, 1999

There seems to be some disagreement over the issue of whether or not OpenBIOS should provide for possibility to compile into a single binary support for multiple chipset types to be autodetected at run-time. For OpenBIOS to be successful, it needs to become more attractive to the MB manufacturers than the alternatives. I don't know whether such a feature would be attractive to the MB manufacturers or not. I suggest will begin by compiling a list of the advantages and disadvantages of this feature. Having done that (so that we understand it ourselves as best we can) we should then ask the manufacturers. (This will be a good step toward getting free hardware from them for development.) When we ask them, we should also ask any other questions about their needs. In effect, we need to do some market research. Here are the advantages and disadvantages that I can think of. There are probably others. Pro: It's cool. It would allow manufacturers to have one BIOS ROM that supports all their MB products. The autodetect code might also be useful for diagnostics. Con: Extra complexity--something else to go wrong. Bug free code is *really* important in the BIOS. Extra complexity--more difficult to test. What other questions would we like the MB manufacturers to answer for us? M

7 7

Re: BIOS Autodetection Design
by M Carling Jan. 12, 1999

Jan. 12, 1999

Eric R. Kern wrote: > Is the objective of OpenBIOS to provide source code to motherboard > manufacturers that they can modify and customize for their boards > or is it to provide a BIOS that will run on an individuals PC? One objective is that MB manufacturers should have a better, more reliable BIOS such that license fees don't exist and thus are not passed on to the consumer. Another objective is that end users should be able to customize and compile thier own BIOS. Of course, since it is Open Source[tm], others may want to do other things with it. I expect OpenBIOS to become widely used in embedded systems, for example. I suspect that providing code that will compile without any pre- configuration and run on any PeeCee is probably too ambitious. Some decisions will need to be made at compile time, I think. M

1 0

Re: BIOS Autodetection Design
by Ray Jones Jan. 12, 1999

Jan. 12, 1999

>The objective is not to write OpenBIOS such that (in practice) a single >compiled image can boot any chipset. Rather, the autodetect objective is >that a set of chipsets may be chosen at compile time from which the image >is about to boot. Thus, for example, a MB manufacturer could compile a >BIOS such that one image would work for all the MBs that they manufacture. If this (compile time selection) is the objective, why call it autodetect? I would have thought from the name that one image fits all. Then, at run time it is autodetected, requiring all of the tables at once. -Ray

1 0

BIOS Autodetection Design
by Eric R. Kern Jan. 12, 1999

Jan. 12, 1999

> After alot of thinking about this I've come to the conclusion that I agree > that there should be autodetection of chipsets. I have been reading some > pciset documents from Intel, and as Andrew says there is really only > smaller differences (between the PCI chipsets that is). But all this > depends on one things; if it is possible to, with 100% accuracy, determine > what chipset the BIOS is running on. If this is possible, is see no reason > not to include autodetection. A wild guess is that the code for the > various chipsets (all together) is not more then a couple of kB. I'll give you a little help with sizing the chipset code since I have had some experience with this (I am a BIOS programmer for IBM's Commercial Desktop Division). Upon bootup of a system, there are many PCI configuration registers that need to be set to a certain value in order for the system to boot DOS (let alone a sophisticated operating system like Linux, Windows NT or Windows 98). These registers are generally set through a table early on in POST (Power On Self Test). The autodetecting BIOS would need to keep a table for every chipset that it detects. The tables for all of the chipsets that you want to support would fill any BIOS EEPROM on the market and you haven't even written one line of code yet. I think I have a better design. There are generally three ways of modifying the BIOS on a computer. The first way is to pull the EEPROM off the mother board and "burn" an image using an EEPROM burner. The second way is to enable boot block recovery mode, put the desired flash image in the floppy drive (or whatever media that was preselected) and turn the computer on. (Boot block recovery mode is usually a jumper setting that runs a "bare bones" portion of BIOS in order to load the desired image.) The third way is through a flash utility. The flash utility should run from DOS (or maybe Linux for you Linux fans out there). DOS is used since this utility is run at manufacturing time before an operating system has been loaded onto the harddrive and DOS fits nicely onto a floppy. My proposed design would have the system boot to a CDROM (more space and everyone has one) which boots DOS. The autodetection would be built into the flash utility. The chipset and other hardware detected by the flash utility would load the appropriate modules. These modules would then be put together to form a BIOS image and a table of pointers to each module would be created at a specified location in the image. +------------------------+ FFFFh | Jmp Vector | +------------------------+ | Table of Pointers | +------------------------+ | North Bridge Config. | +------------------------+ | South Bridge Config. | +------------------------+ | Cache Configuration | +------------------------+ | Memory Configuration | +------------------------+ | ISA Configuration | +------------------------+ | PCI Configuration | +------------------------+ | Keyboard Controller | +------------------------+ | BIOS Functions (int 15)| +------------------------+ | Planar Hardware | +------------------------+ | Etc. | +------------------------+ E000h Just a thought. Good luck. Eric R. Kern

2 1