OpenBIOS

openbios@openbios.org

4297 discussions

Fwd: Re: Hello
by Daniel Engstrom 14 Oct '98

14 Oct '98

On 13 Oct, Stefan Reinauer wrote: > Hi... > > On Tue, 13 Oct 1998 daniel.engstrom(a)riksnett.no wrote: > >> Here is what I thought: >> A free Open Firmware implementation that runs on my PC would be utterly >> cool and the Right Thing To Do <tm>. > > This is generally correct I would say. But what could/should be discussed > is whether we should really implement what is IEEE Std 1275-1994 > (Official Name of Sun's OpenFirmware). I am a bit in fear that we might > get problems implementing a forth interpreter in 128k together with the > whole stuff we need to get a machine running. (This may be because I am > not familiar with Forth, though) :) Some boards have 4MBit (256k byte) flash these days... And IO though one could use compression. The gunzip object code in linux is 14k bytes and the kernel compresses about 2.5:1 which means that if we total 16k uncompressed code we have 112k left in the PROM. If we get 2.5x as well it will give 280k. If we only get 2x it will still be 224k binary code. I am more worried about NVRAM space, the standard RTC only have 64 bytes of which 50 bytes are general purpose. Ofcuse most board have RTC versions with more RAM up to 4k, but we will need compression or some token based system to fit the needed boot variables. My idea of boot sequence (with my limited knowledge on what IEEE1275 says)... 1: Initialize DRAM controller and check 1st 64k DRAM 2: Enter PM 3: Load segments, TSS, stuff 4: Initialize rest of memory, set DRAM timing CONSERVATIVE, 5: Uncompress main firmware 6: Initialize PIC, DMA, Super IO chip and VGA (If boot console is VGA) 7: Parse NVRAM 8: Scan for FORTH code 9: Execute any FORTH code 10: Boot system >> The boring part is that I believe the Open Firmware specs cost money. > They are available as a book. I ordered it today :-) > It's ISBN Number 1-55937-426-8 IEEE Std 1275-1994: IEEE Standard for Boot > Firmware. What did they charge? >> In order to to this one fist should get the specs (anyone here who has >> them?) And then make an architecture addendum for the i386 and submit >> it to the Open Firmware folks. (Las time I checked their web site there >> were none for the i386, the web site is unresponsive at the moment.) > I found http://playground.sun.com/1275/home.html > which might be interesting as a starting point, but I haven't had a closer > look at it. Thats the page I remember looking at. They have "Instruction Set Architecture Supplement"s for Sparc, PPC and ARM. So if we choose that path we'll need to specify Open Firmware for IA-32 and the PC platform. Everything else (PCI, ISA, VGA, etc, seems to be specified already for CHRP I suppose.) > .signature: No such file or directory :) /Daniel --

3 2

Hello
by Daniel Engstrom 13 Oct '98

13 Oct '98

Hello, All! I have just subscribed to this list. Would anybody be kind and sum up the discussion this far? Regards, Daniel --

4 3

Re: OpenBIOS (was Re: UDI and Politics (was Re: Linux, UDI and SCO.) )
by Stephen Williams 21 Sep '98

21 Sep '98

lkd(a)tantalophile.demon.co.uk said: > So why not make up an embedded Linux kernel and load _that_ into the > FLASH-ROM? Serious overkill, I think. There are better solutions in the forms of: RTEMS http://www.rtems.army.mil/rtems.html ucr http://www.picturel.com etc. These are designed for the embedded environment and don't carry the excess baggage you'd be flashing into EEPROM. (Note that this is going to the OpenBIOS list now.) -- Steve Williams "The woods are lovely, dark and deep. steve(a)icarus.com But I have promises to keep, steve(a)picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)psychosis.com Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Test, list server change
by Dave Cinege 07 Sep '98

07 Sep '98

The openbios list (which has been broken and dead) is now (alive and working) on psychosis.com. The post addy is now openbios(a)psychosis.com -- http://www.psychosis.com/emc/ Elite MicroComputers 732-541-4214 http://www.linuxrouter.org/ Linux Router Project I am a regex s/retard/student/. Pray. There is hope. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)psychosis.com Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: Continue Development
by Stefan Reinauer 04 Sep '98

04 Sep '98

Hi.. [about:16bit stuff in bios/compatibility to DOS/Windows] > > IMHO this is not the way to go, since many people still have Windows95 > > installed (because of the games), but would like OpenBIOS. I would leave an > > option that links a set of wrapper functions. The problem is, that the available space on a flashchip is today 128 k or 256 k, depending on the system. Because 256k chips are still too rare, I'd suggest that we try to get the most stuff into 128k and maybe only some not really needed features as the animated logo with mp3 sound at bootup into the second 128k :-)) > Would it be possible somehow to have the original bios image on the > harddisk, and then have an option on the boot console where you could > load it into memory and start it? It may very well not be possible, > but if it was, then we could concentrate on our stuff, and let the > original bioses support the win95/98/dos/other os's... Also having > the possibility to select bios at boot would be a cool feature! :) > Just a thought... Well.. This is really a good idea. I once thought about loadable bios plugins on hd or via network, but that may be very hard. The easiest way would probably be to load the bios directly from harddisk, as it can be done on the Alpha AXP boards. We could do this before the cpu is switched to protected mode or afterwards and switch back to realmode to load award or ami bios. The first would save some code, the second seems to me to be the more elegant version, because we can do the whole floppy stuff in PM (which could be necessary if we want to support ia64 some day) Stefan. -- .signature: No such file or directory

1 0

Re: Continue Development
by Simon Richter 04 Sep '98

04 Sep '98

Stefan Reinauer schrieb: > 1) Do we need the 16bit bios stuff in an OpenBIOS? > I'd say a clear "NO" here. This does mean, on the other hand, that we > won't support any proprietary systems like windows or DOS anymore, > but as for using DOS/Windows, Award and AMI BIOS do a good job, this is > not really needed. > People who need more features like netboot and a good console in their > BIOS very likely use Linux or any BSD flair. IMHO this is not the way to go, since many people still have Windows95 installed (because of the games), but would like OpenBIOS. I would leave an option that links a set of wrapper functions. > I'd suggest C, [...] Agree. I also have some further thoughts on this, but I'll post them tomorrow. > 3) Testing platforms Well, I've got a bunch of testing machines as well as old NE1000 cards here. If I find some time (and the manual and a NE/2 for my PS/2), I can do some testing here. Also, I think if someone just wants to run Linux and nothing else, a Linux kernel with the BIOS querying code commented out would do as well. So the main reason to use OpenBIOS should not be "It loads my Linux bigger/better/faster/more" but rather "I like to have a boot console" or "My company saves $200 on harddisks for each computer". Just my two cents. Also, the BIOS should be optimized towards minimal data storage space rather than speed. It won't harm speed that much, but the final OS has to live with all that stuff in RAM. CU Simon

2 1

Continue Development
by Stefan Reinauer 01 Sep '98

01 Sep '98

Dear guys :-) As you might have noticed, there's not much traffic on this list at the moment. I'd like to start a bit of discussion right now to get things proceeding again. 1) Do we need the 16bit bios stuff in an OpenBIOS? I'd say a clear "NO" here. This does mean, on the other hand, that we won't support any proprietary systems like windows or DOS anymore, but as for using DOS/Windows, Award and AMI BIOS do a good job, this is not really needed. People who need more features like netboot and a good console in their BIOS very likely use Linux or any BSD flair. 2) Which programming language should be used? We sure will have to write some init code in assembler, which is OK, if it doesn't get too much. I think writing in a higher level language is much easier because a) more people can help the project and b) the code can easily be maintained. I'd suggest C, as C++ seems to be a bit bloated for this project. (As well as other languages) To give anyone the chance to help the project, I'd like to use the GNU Compiler GCC. Every Linux/BSD user has access to it and it's available for most other platforms, too(W32 i.e.) 3) Testing platforms I had a look at bochs some days ago (which now runs fine on my Alpha AXP without segfaults) though I am not sure whether it is really good enough for testing (I expect problems with the PnP and PCI init stuff) I am sure that it's possible to get some test mainboards so that no developer has to fear to destroy his computer. You might have a look at my devbios project, a flash bios device for Linux2.1. It can be found at http://www.freiburg.linux.de/~stepan/bios/ The OpenBIOS webpage can be found at http://www.freiburg.linux.de/OpenBIOS/ I'll try to get the archive mirrors of the earlier mailinglist discussions online this week, so stay tuned and don't hesitate starting a new discussion about the above themes (or anything else) Stefan -- .signature: No such file or directory

1 0

This mailinglist.
by Stefan Reinauer 09 Jul '98

09 Jul '98

Dear OpenBIOS-Readers, well, I have to confess, that there's not much traffic on this list at the moment. This is mainly due to my spare free time. I guess I can do much more for this project in 2-3 weeks. We were duscussing the idea of porting OpenFirmware or the Linux/Alpha Loader MILO (which is a full bios) to Intel architecture to get some test enviroment to start with. Has anyone succeeded in booting a PC from the Bochs BIOS? ... You will read much more on this list, soon! Best regards, Stefan (List Maintainer) -- .signature: No such file or directory

1 0

status of openbios
by Alex.Nemirovsky＠radisys.com 24 Jun '98

24 Jun '98

Hi All, I am interested in putting in some effort in getting OpenBIOS going. I am a BIOS engineer and see value in GPL'ed BIOS source code. How far is the development so far? What has been talked about? Thanks -Alex

3 2

OpenBIOS and OpenBoot
by Fare Rideau 09 Jun '98

09 Jun '98

Dear OpenBIOS people, have you by chance considered the fact that there already exist a cross-platform IEEE standard for firmware? It's called Open Firmware, and allows boot code to run unmodified on a variety of platforms, based on a bytecode ANS FORTH interpreter: * Sun SPARCs (on which it first appeared -- try STOP A someday) * PowerPCs * ARM ftp://ftp.netcom.com/pub/me/mejohnsn/OFIntro.html http://playground.sun.com/pub/1275/ ftp://playground.sun.com/pub/p1275/ http://www.firmworks.com If you write something for PCs, it would be great if it reused this proven, standard, design. And if you need a FORTH core, there already exist lots of them, including PFE, GNU forth (gforth), and many others. http://www.forth.org/ ftp://ftp.forth.org/pub And of course, if you are to use this standard, you should contact the Open Firmware committee, to be in synch with whatever they have done or intend to do about the PC platform... Just my 2p worth. I'm not subscribed to this list in any way, I've just seen an announce on the linux-kernel(a)vger.rutgers.edu mailing list. Hence, if you want to reply me, use private e-mail. Good luck! ## Faré | VN: Ð£ng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.

2 1

i960 board with PCI
by Stephen Williams 13 Apr '98

13 Apr '98

larry.panzer(a)excel.net said: > Could you post some more info on your i960 board, is it a custom > design? It may make a good testbed platform on which to try the > OpenBIOS, when the time arrives. It might make some sence to do a pro/ > con list of the different design techniques for this BIOS. Well, OK. The card I refer to is the Picture Elements Imaging Subsystem Engine (ISE). There is information about it on our web page. It may not be of any real use to this list because they cost more then some cheaper PCI motherboard. However, it does have lots of PCI stuff to fuss with and has taught me the issues of BIOS management of PCI busses. Still interested? Read on. ISE is a full-size PCI card that has an i960RD on board. Internally, the board has a PCI bus connected to the secondary bus side of the i960RD. There is a DEC PCI-to-PCI bridge that adds another PCI bus. The board has daughter card positions that are electrically PCI. The daughter cards use typical interface chips (i.e. PLX PCI9080) to do the bus manipulation. Therefore, the cards appear to software like standard PCI devices. I have written code for the i960 that does the job that the BIOS32 does on a PC, namely it locates the PCI devices, probes their registers and assigns interrupt numbers and address space. It is this little bit that may be most interesting to this list. I have also ported TCL 7.6 to this environment. I have given TCL access to the PCI space by a "bios32" extension (load {} bios32) that adds commands to read/write configuration space registers. The software for the ISE board is fairly generic, and available for free from our FTP site. <ftp://ftp.picturel.com/pub/source/ucr/> UCR Version 1.0 is sitting there now, I'll be making a 1.1 release (and updating the TCL port) in a month or so. People are free to look at the PCI stuff to see what I had to go through, and the code may be used under GPL terms. (The TCL source has its own license that allows free use.) Some portions of uCR are known to work under i386 with gcc, as I have built and linked programs to run under Linux, using uCR in place of the C library. This is for simulation purposes, but may provide a decent test bed for embedded software. Anyhow, there you go. In a month or so, things will settle down enough that I can port uCR to i386/PC board if there is interest. -- Steve Williams "The woods are lovely, dark and deep. steve(a)icarus.com But I have promises to keep, steve(a)picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] This list?
by Gregory Gerard 12 Apr '98

12 Apr '98

OpenFirmware hurts! Don't go down this path. As a former Apple employee where OF was law, it causes more problems than it solves. The Forth derivation is baroque and tends to only bring back unmaintainable code (you though asm could be bad?!? You ain't seen nothing yet!) Also talking with Sun people (where OF originally began, though in a slightly derivitive and sometime incompatible language known as OpenBoot) who code it on regular basis, they hate the horribly restrictive environment and the debugging facilities suck wind, but they are stuck with it. Being able to initialize an OF card is okay, but doing a full OF implementation on the host ROM side is a nightmare. greg >On Sat, 11 Apr 1998, David Freeman wrote: > >> Wouldn't that be an OpenFirmware clone? I know that most modern PPC >> systems now use OpenFirmware, as well as newer SPARC systems. An >> OpenFirmware clone would be cool... > >This isn't exactly what I thought of at first, but it sounds like the best >thing to do now that I think about it. This would probably help out some >people trying to run LinuxPPC on Winbloze-NT only Motorola PowerStack >machines (You can flash a new bios onto them from a floppy, I believe) > >Maybe we can even add some cool features like control from an ethernet >interface.. Have it look for a bootp server at boot, and then allow telnet >configuration.. This would be *great* for setting up a cluster.. Take the >machine out of the box, hook it up, and configure it without ever hooking >up a monitor, keyboard, or inserting a floppy. There are some security >issues with this though, but I think those can be dealt with. > >Something like my previous idea is possible with a fully open-source >firware code.. What company would want to bother with something like that >anyway? I personally think it would be very useful. > >> And it isn't exactly proprietary either, independent companies make >> their own implementations of OpenFirmware, so I guess it would be >> possible to get the specs, and write clone, eh? >> >> Troy Benjegerdes wrote: >> > >> > Does this list exist at all? I haven't seen any activity for about 2 weeks >> > or something. >> > >> > Anyway, would anyone like to develop a GNU bios for PPC systems? I *might* >> > be in a position to get all the needed specifications and actually get the >> > developed *used* when it is stable. >> > >---------------------------------------------------------------------------- >| Troy Benjegerdes | troybenj(a)iastate.edu | hozer(a)dodds.net | >| Unix is user friendly... You just have to be friendly to it first. | >| This message composed with 100% free software. http://www.linux.org | >---------------------------------------------------------------------------- > > >--- >OpenBIOS -- http://www.linkscape.net/openbios/ >openbios-request(a)linkscape.net Body: un/subscribe >Problems? dcinege(a)psychosis.com > > --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: Did someone start?
by David Woodhouse 12 Mar '98

12 Mar '98

pavel(a)elf.ucw.cz said: > Hmm. Did someone _really_ start? Is there someone who actually > compiled that Bochs BIOS? Where to download complete package > (including bcc, because it is not really common). I'm not sure about _compiling_ the Bochs BIOS, but Dave Cinege tried the precompiled version that comes with the Bochs source, and it did nothing visibly useful. Bcc is part of the Dev86 package, which can be found at http://poboxes.com/rdebath I'll put a copy of the latest version in /pub/openbios on my machine, too. As for _really_ starting on the code, I doubt that anyone's made much of a start. I'm itching to do some, but my Director of Studies will slaughter me if I so much as look at anything but "An implementation of RSVP on Nemesis" ( http://www.cl.cam.ac.uk/Research/SRG/pegasus/nemesis.html ) ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Hello World
by Pascal Dornier 11 Mar '98

11 Mar '98

>The MDA cards require absolutely no setup. They display text from the moment >the power goes on. I suspect older [CEV]GA cards will be similar. Not correct, you need to initialize the 6845 CRTC. Pardon the grotty formatting. ; ; Init Hercules card ; cld mov al,#$21 ;disable video mov dx,#$03b8 out dx,al mov si,#herctext ;set text mode mov bl,#0 mov dx,#$03b4 hercloop mov al,bl out dx,al inc dx cs: lods.b out dx,al dec dx inc bx cmp bl,#16 jb hercloop mov al,#$29 ;enable video mov dx,#$3b8 out dx,al mov ax,#$b000 ;clear screen mov es,ax mov ax,#vidfill mov cx,#2000 mov di,#0 rep stos jmp hercend ; ; Hercules text mode settings ; herctext B $61,$50,$52,$0F,$19,$06,$19,$19 ; mode 7 B $02,$0D,$0B,$0C,$00,$00,$00,$00 hercend --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] Hello World
by David Woodhouse 11 Mar '98

11 Mar '98

> > Ditch your fancy new SVGA cards, install an old MDA card, and > > mov ax,b800h > > mov ds,ax > > ... > > IIRC, the segment base for MDA is 0xb000, not 0xb800 (CGA), but, as > with you, it's been a while. I stand corrected. I hereby declare myself to be this week's Official Mr. F^&* All Good, for failing even to manage a six-line asm program <D:-( ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Hello World
by David Woodhouse 11 Mar '98

11 Mar '98

oxymoron(a)waste.org said: > It would be nearly as easy to generate output on the serial port > using polled IO. Presumably all the developers have at least a serial > port and a second machine that they're not ready to kill their BIOS > on. I've recently written a small library of assembly functions to do > this, include register and memory dump routines and a printf-like > varargs function for debugging the bootloader of an embedded > operating system I'm writing. The routines are currently written for > MASM - if anyone would like them, I can make them available. Sounds good. Could you mail them to me, and I'll put them up for FTP with the rest of the stuff. Support for reblowing the flash from a serial port, rather than from a floppy, is going to be a damn sight easier to put together, so I suggest that we do that in the first instance, too. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Is this list still alive?
by David Woodhouse 11 Mar '98

11 Mar '98

> It's alive. I signed up recently trying to find out if I can help. Get an > idea of the level of development. But like you said there has been no > traffic (I even forgot I signed up). > > Who can I contact to find out if I can do some work on the OpenBIOS? I think the discussions of general ideas fizzled out, and the last we heard, people were off to play with the Bochs BIOS source, in an attempt to get it to work at least a little bit on a real computer. Until then, we can still put together a development system, binary module spec., and a list of modules to be provided. At some point in the dim and distant past, I and a few other people posted lists of the basic support that we're going to require in order to boot a Linux kernel. Unless you have access to the necessary hardware for making replacement PROMS, assume that someone will get the basic chipset init working, pick something else, and implement it. INT 15h extended memory services might be a simple place to start, and should be quite simple to test from DOS. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] Hello World
by David Woodhouse 11 Mar '98

11 Mar '98

cpa(a)hopper.unh.edu said: > What would it take just to write a Hello World program? Ditch your fancy new SVGA cards, install an old MDA card, and mov ax,b800h mov ds,ax mov ax,'eH' mov [0],ax mov ax,'ll' mov [2],ax ... OK, I'm a bit rusty, but you get the idea. The MDA cards require absolutely no setup. They display text from the moment the power goes on. I suspect older [CEV]GA cards will be similar. > I think > seeing this code would give people something of a starting place. Do > we just load the Video BIOS up and use it to write a string to the > screen and halt, or can/should we do it without the Video BIOS? Until we've set up enough to support the card's Video BIOS, we'd better do it on our own. Most new cards will probably require at least the PCI BIOS functions to have been implemented first. > From there you can add support to initialize your chipsets functions. > BTW, do we have anybody here with a SMP machine? Those do require more > to initialize, and we will eventually want to make sure that works. Yep. I've got such a beast. I'm not playing until May, when my Finals are over, but after that I'll be working on it. You'd be surprised at just how little the SMP Tyan BIOS manages to do for itself - that's half the reason I wanted us to write our own in the first place. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Hello World
by Chris Arguin 11 Mar '98

11 Mar '98

Since everybody is wondering if the list is alive, I'll post something I've been thinking about... What would it take just to write a Hello World program? I think seeing this code would give people something of a starting place. Do we just load the Video BIOS up and use it to write a string to the screen and halt, or can/should we do it without the Video BIOS? >From there you can add support to initialize your chipsets functions. BTW, do we have anybody here with a SMP machine? Those do require more to initialize, and we will eventually want to make sure that works. -- Chris Arguin | "...All we had were Zeros and Ones -- And Chris.Arguin(a)unh.edu | sometimes we didn't even have Ones." +--------------+ - Dilbert, by Scott Adams http://leonardo.sr.unh.edu/arguin/home.html | --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] Hello World
by Ben Pfaff 11 Mar '98

11 Mar '98

cpa(a)hopper.unh.edu said: > What would it take just to write a Hello World program? Ditch your fancy new SVGA cards, install an old MDA card, and mov ax,b800h mov ds,ax mov ax,'eH' mov [0],ax mov ax,'ll' mov [2],ax ... OK, I'm a bit rusty, but you get the idea. IIRC, the segment base for MDA is 0xb000, not 0xb800 (CGA), but, as with you, it's been a while. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Is this list still alive?
by David Woodhouse 11 Mar '98

11 Mar '98

danh(a)firstwest.com said: > Am I able to use C, or is this strictly asm? Of course some asm will > be involved but C makes the development faster. Do what you like. I don't think it's particularly reasonable to expect the whole thing to be written in asm. Also, I reckon that just about any compiler can generate better asm than I can. steve(a)icarus.icarus.com said: > Doing without a compiler only makes sense for writing a few tricky > functions or impressing women. I'm inclined to agree. Glance at http://dwmw2.robinson.cam.ac.uk/devload/ for evidence to back this up. It was fun, but I wouldn't want to do it again. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Introduction
by Jim Stewart 04 Mar '98

04 Mar '98

Hello all, I've been lurking on the mailing list for about a week now and I'd like to say hi. I have an interest in Bios code because I've written the Bios for our Flashlite series of controllers and I'm interested in building an embedded Linux machine. As far as contributions go, I can't give you my code, but I do have the source to a PC/XT Bios, written in Masm, that was freely circulated a few years ago. It does work, I've burned it into eproms and booted from it and I've used just a little code from it. It's not very pretty, but if there is any demand, I'll post it for downloading. Concerning Microsoft OS's and Bios, at least in the case of Win95, I have it on pretty good authority that the OS uses *none* of the Bios functions. This is documented in "Unauthorized Windows 95" and confirmed by the VP of engineering at Award Software. What I got from my discussions with him is that the current microsoft philosophy is for the Bios to initialize the hardware and sorta give the os clues as to what's out there and nothing more. Whether this is relevent to your efforts is not real clear yet as I haven't been on the list very long. In any case, I'll be lurking, and if I can be of any help, let me know. Regards, Jim --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

4 3

Re: [OpenBIOS] Project split. (Let's get working)
by Pavel Machek 03 Mar '98

03 Mar '98

Hi! > > If you want to start hacking grub, let me know, I have some rather > > nice patches into it. Now, grub is actually usable for me. > > What??? You read it correctly. Grub is nearly unusable in normally-distributed version as its user interface is horrible. You can not select entries easily, can not make it lilo-like so it appears only if you want to see it etc. I made entries selectable by first letter, made it behave in nice way with timeout = 0 and made it compile on elf system. (And few details). I'll post patch. Pavel -- Do *NOT* buy software, GNU software is better and free! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Hi.
by Pieter.Dumon＠rug.ac.be 02 Mar '98

02 Mar '98

> > Hi folks out there > > I subscribed like the one a couple of days ago. And would like to join the > discussion by this eMail: > > On Fri, 27 Feb 1998 9732520(a)lewis.sms.ed.ac.uk wrote: > > > > 2) I assume 32-bit code is used as much as possible, ie. start up in real mode and > > switch to protected mode asap. and then deal with all the rest. It doesn't make > > much difference for boot really, but functions used by OS's should really be > > 32-bit now (name one *decent* real mode 16-bit OS). > > > If you speak about real mode booting -- it seems to me that you think only > about booting a i386-compatible. Further it depends on wether you think to > support the PC-standard (16b RM-BIOS support code) or imlement a complete > new BIOS where no compatibilities to existing software can be guaranteed, > ie. no existing OS would run on such an incomaptible PC-BIOS reinvention. Every now existing OS Kernel would run on that BIOS! Normal 32-bit OSs don't use the 16-bit BIOSs now available. If openBIOS loads the kernel correctly, there are no problems with kernels like Mach, wich allready assume they are loaded by the bootloader in pmode etc... if openBIOs supports the multiboot standard, there will be no problem. Its only the boot loader that wouldn't run with the openBIOS, but if openBIOs includes the bootloader itself, so no bootloader will have to be included on disk... -- ######################################## # # # Death of the Rats # # # # Pieter.Dumon(a)rug.ac.be # # # # http://studwww.rug.ac.be/~pdumon # ######################################## --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] BIOS UI
by Stephen Williams 02 Mar '98

02 Mar '98

cpa(a)hopper.unh.edu said: > I'm gonna disagree here. I admit that C++ is good for abstracting > layers away, but I don't think it is really called for in this > project. C++ syntax, INHO, is too ugly to use unless you really need > it. <http://www.picturel.com/ucr-coots97/ucr.html> Here I try to make the point that C++ can actually lead to more effective code then C. I don't often use a lot of the excess cleverness of C++ in this sort of environment, especially since I am a proponent of the KISS principle, but I do use certain non-C features and fully expect increased clarity. And yes, C++ and assembler get along just fine, especially when embedded in the C++ code as asm statements. This can quickly degenerate into a C vs. C++ religious war, it usually does:-) -- Steve Williams "The woods are lovely, dark and deep. steve(a)icarus.com But I have promises to keep, steve(a)picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Alle Metzlar 01 Mar '98

01 Mar '98

Alexander Viro wrote: > On Sat, 28 Feb 1998, Dave Cinege wrote: > > <snip> > > > > The BIOS **MUST** be able to at least read one common FS or this projects > > usfulness has been cut down 10,000%! > > > Why? What kind of filesystem should it understand? FAT??? Damn, > I'ld prefer not to have the stinker around at all. And it would be the > last place where I'ld put the kernel. Especially if DOS will be able to > access it. Not to mention Sucks95 or NT. If it comes to that - who needs > access to the filesystem? DOS - no. It has its own bootloader that _must_ > be present in the first sector of partition. Sucks - also no. By the same > reasons. NT? Has its own loader. OS/2 - ditto. What remains? Right, all > kinds of UNIX. Considering the fact that Linux and *BSD are free what > prevents us from making our own filesystem and implementing it for these > systems? It _must_ be more reliable than FAT. Solaris is not free, but > that's the reason why you don't recompile the kernel there. As far as I > can understand you don't like the fact that LILO should be executed on > each recompilation of the kernel, right? So it's an issue only for free > systems. > Comments? > Al YES! What is BIOS? In my opinion nothing more than a small layer between hardware and OS. Lots of functions of BIOS could be handled by the OS, except for POST routines. FS: let this be handled by the OS. Remind Linux: it can coexist next to any possible OS. Again, what is BIOS? At startup or reset, the CPU points at address F000:FFF0. At this point BIOS should start execution of POST, a couple of test and initialization routines. At a certain point POST activates INT 19h. INT 19h read the boot sector (sector 1, track 0) from the (primary) boot device, and writes these data to address 0000:7C00h, and BIOS transfers control to the data a this address, which in turn loads the OS. Want to change this? Then you will probably also have to rewrite most or all OSses. So, what's the goal of OpenBIOS. A BIOS that can only be used by a few people, or a BIOS that can be used by everybode who wants to, whatever OS they use, whether it sucks or not! -------------------------------------------------------------------------------------------- Alle Metzlar Matrix Technologies P.O. Box 40, NL 1724 ZG Oudkarspel The Netherlands Tel: (+31) 226 316889 Fax: (+31) 226 312157 EMail: matrix(a)xs4all.nl WWW: http://www.xs4all.nl/~matrix/ (Matrix Technologies' BIOS Web) -------------------------------------------------------------------------------------------- Author of: Het BIOS boekje, Uitg. Pim Oets, ISBN 90-5722-013X Das BIOS Buch, Franzis' Verlag, ISBN 3-7723-4832-7 Die BIOS CD-ROM, Franzis' Verlag, ISBN 3-7723-8612-1 -------------------------------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] OpenBIOS: reality check
by David Woodhouse 01 Mar '98

01 Mar '98

aarong(a)wired.com said: > On Sun, 1 Mar 1998, Benjamin Scott wrote: > > > >>> Do Suns, Apollos, HPs, IBMs, NeXTs, etc. have rudamentary > > >>> filesystem code in their BIOS? > > >> > > >> I know for an absolute fact that is has been done on the Alpha. > > > > > > Which filesystem does it use? > > > > Anything Linux does. The MILO loader, which is designed to be blown > > into firmware, actually incorporates regular Linux device drivers. So > > take your pick. :-) > > Not exactly true. The SRM firmware found on most Alpha systems knows > nothing about filesystems or disk partitions. Instead, SRM relies on the > ability to load a secondary bootstap loader, the location of which is > described by values stored on the first 512 byte sector of the physical > disk. > Not so. At least on the SX164 we have, it knows about the filesystem. Anyway, the phrase "the location of which is described by values stored on the first 512 byte sector" sounds suspiciously like understanding disk partitions to me. The SRM firmware understands at least FAT, and possibly also NTFS partitions. Certainly it's capable of loading second-stage bootloaders like "LINLOAD.EXE" from a FAT floppy disk. I believe that even the emergency firmware update is managed from a FAT floppy. When you configure SRM to load Linux using LINLOAD, you have to give a dummy argument for the "OPERATING SYSTEM DIRECTORY", and the SRM console complains if that directory is not there. It definitely understands the filesystem. Looking at the ext2 drivers for Win95, I see that the VXD files gzip down to 15596 bytes. I'm sure we can find that amount of space in the flash for those who choose to configure ext2 support into their BIOS. I for one, would like to do so. Making new filesystems just so that the BIOS can access them easily is not practicable. Neither is the idea of dedicating a partition to BIOS extensions. Simple read-only filesystem support can be kept fairly small, and is going to be required by UNIX people to load either the second-stage bootloader or the kernel itself. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Project split. (Let's get working)
by Dave Cinege 01 Mar '98

01 Mar '98

OK, enough screwing around. My proposal: Split the project into 2 working areas... BIOS Boot loader The boot loader team can start coding NOW. First we make a stage1 loader that fits in the MBR that jumps to our real-mode proggie loaded somewhere on disk. When this program get's put in flash the stage1 is just abandoneed and it is jumped to directly. The very attractive side result is we end up with a seperate system usable by people that do not or can not use our (right now non existant) BIOS. The BIOS team can sort the rest of this shit out later. Even if part/most/whatever of the boot code needs to be redone, what will remain are all the real mode utils (IE chain type loaders) left over from the boot system. IMO we should just start hacking at GRUB. For instance being able to run a real mode util them fall back should be put in. OS/2 and NT will not boot directly for me. Fix this. Fix other OS's. When (if) the time comes we start over taking chunks of our optimized code out of what we did in GRUB. -- http://www.psychosis.com/emc/ Elite MicroComputers 908-541-4214 http://www.psychosis.com/linux-router/ Linux Router Project "The only way to remain cutting edge, is to design for things that do not yet exist." -- Me : ) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

3 2

Re: [OpenBIOS] Filesystem code in BIOS
by Benjamin Scott 01 Mar '98

01 Mar '98

DC = Dave Cinege <dcinege(a)psychosis.com> BS = Ben Scott (me) DC> The BIOS **MUST** be able to at least read one common FS or this DC> projects usfulness has been cut down 10,000%! BS> I don't know about "must". DC> I say must because why the hell are we doing this otherwise!?!?!? Calm down. Don't blow a gasket. :-) I am against "must" mainly because "must" is counter to the entire *idea* of free and open software. If I wanted "must", I'd buy a Microsoft OS and be told by Bill Gates how things should be done. I like Linux because *I* can choose how I want to do things. DC> I want an ORDER OF MAGNITUDE for greater flexabilty and functionality. DC> I also don;t think it should be over modularized, So you want greater flexability but you don't want it to be modular. Those two requirements conflict. :-) Okay, okay, you said "over modularized". :-) I do agree. I'm not saying we should invent the mother of all firmware here. I'm just saying some things are easily modularlized, and we really should do so, otherwise about half the people on this list are always going to be pissed off (and I might be part of that half). :-) It shouldn't be that hard. One state goal has been a standard API to get at all BIOS functions, not just standard INT support. If we do that, we can call it ourselves from things like the UI. Makes the UI drop-in replaceable. The same goes for hypothetical filesystem support -- all you need is a simple conditional that either jumps into the filesystem module or spits out an error. DC> that people have to keep recompiling their BIOS every week like a Linux kernel is. At least in the begining, I think we may have to expect that. Because of its critical nature, we have come to regard the flash ROM as holy. Well, before LILO came along, the MBR was holy, too. Maybe it's time for another reformation. :-) DC> simple FS support should not be optional. Boot menu support should not be DC> optional. If you have OpenBIOS on your box it should me you can do certain DC> things, not 'oh I forgot to compile that in' We can't protect the user against everything they might do wrong. The main reason I think we should stress modular design is limited flash space -- we may not have sufficient room to do everything otherwise. Or we may. I don't know. :) DC> It's not reasonable to strive for an all aroung everything x86 BIOS. DC> TOO MUCH WORK. It will never come to be. Everyone and their mother will DC> want a little feature int he tree, the base BIOS ill nto get the attention it DC> deserves, and all the options will grow to a product that doesn't even fit in DC> 1MBit to get all the base features we are talking about. "An entirely new UNIX OS under GPL? Written from the ground up? On the PC?? Forget it. It will never work. And even if it did, it would be too much work." I'm sure glad Linus didn't listen to comments like that. :-) GW = Greg Weeks <greg(a)durendal.ml.org> GW> OS specific code does NOT belong in the BIOS. BS> Why not? DC> Because upgrading the BIOS should not be a daily routine. Again: Why not? DC> You are confusing boot strap with actual loader. (stage1 v stage2) The bootstrap used to *be* the actual loader. My point is, why should we bother with a two-stage boot process? Why not put it all in firmware? I like that better. More elgant and less things to go wrong. GW> P.S. can we change the list to have a reply-to header that points GW> back to the list? BS> I second this. DC> I regret to inform you, that your request has been denied. I've seen at least four requests for this; can I ask why not? :-) DC> ext2 is also nearly universal, Well.... DOS, OS/2, Win95, NT, Mac, and many UNIXes support FAT right out of the box. Not many support ext2 that way. > I have beaten to death why this is needed. Apparently some people don't think the question is answered. :-) I don't like beating a dead horse either (well, not usually <g>), but there does appear to be some life left in this here equine. :-) -- Ben --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Filesystem code in BIOS
by Benjamin Scott 01 Mar '98

01 Mar '98

DC = Dave Cinege <dcinege(a)psychosis.com> DC> The BIOS **MUST** be able to at least read one common FS or this DC> projects usfulness has been cut down 10,000%! I don't know about "must". Personally, I would find basic read-only FS support very useful in the BIOS, both for booting the kernel as well as for doing firmware updates direct from floppy. But many people, for some reason I quite honestly don't understand, seem to regard this as taboo. So it should be kept optional. :-) GW = Greg Weeks <greg(a)durendal.ml.org> GW> OS specific code does NOT belong in the BIOS. Why not? I'm serious. You have to have OS specific code *somewhere*. Otherwise you can't boot your OS. These days, the BIOS exists mainly to initialize the system hardware and load the bootstrap. The bootstrap then loads your OS. We routinely fiddle with the bootstrap for one reason or another; why not just move it into flash ROM? It seems pointless to require passing control from one block of boot code to another just because one block resides in firmware and the other on disk. Having it all in ROM makes more sense to me. GW> With something like openprom in SUNs et. al. with romable forth it GW> becomes possible to write extensions in forth that are portable and GW> ROMed. Why are people making a big deal over the term "BIOS" vs "ROM" or "firmware"? Does it really matter? :-) GW> I haven`t decided if the extensions should be in ROM (128K isn't GW> very much) With efficient code and data compression, 128K goes a long way. Remember, UNIX used to run on systems with 128K total main memory. I would hope we would be able to implement a glorified bootloader in that space. :-) GW> P.S. can we change the list to have a reply-to header that points GW> back to the list? I second this. AV = Alexander Viro <viro(a)math.psu.edu> AV> Why? What kind of filesystem should it understand? FAT??? Damn, AV> I'ld prefer not to have the stinker around at all. FAT has two key advantages: It is very simple, and it is nearly universal. The first helps us keep our code size down and minimizes the possability of bugs. The second is useful in emergency situations. I don't think I've met a microcomputer OS yet that didn't have some way to support FAT (either built-in or with add-on software). That can be very handy if you need a kernel in a hurry and the only other networked machine around is a Mac or some such thing. :-) FAT actually bears a strong resemblence to the "stand" filesystems some UNIXes use to boot. Such filesystems are typcially limited in filename length, have no security, and are flat (no directories). FAT isn't ideal for this, but suits the purpose, and like I said, is nearly universal. I'm not saying we should and I'm not saying we shouldn't, I just wanted to point this out for further contemplation. :-) -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

3 3

Our goals.
by David Woodhouse 01 Mar '98

01 Mar '98

The discussion on this list doesn't seem to be getting very far. In terms of esoteric features, I think we should definitely follow the Linux model of development - if you can make it work, and make it work nicely, then it will almost certainly get put in as a config option unless it's particularly inane. There are some who want their BIOS to be able to boot the kernel directly at the cost of some chipset optimisations which will no longer fit, and there are some who want the optimisation and would be happy to boot using the traditional method. Open Firmware also sounds like a reasonable option, but there's not a whelk's chance in a supernova that it will fit in the ROM of most PCs. We could make that available on DASD, for the BIOS to load if it likes. We will never resolve these conflicts. The modular design of the OpenBIOS was settled upon specifically to avoid the need to impose a compromise. There's also no chance we're going to get away without providing real mode BIOS interrupt support, if we want people to start using it, so we have to provide it. We can always make it a removable option at a later stage. The main task at the moment is to get the core BIOS, which we all agree on, to initialise the hardware and bring up whatever facilities it provides, be that Open Firmware, booting a kernel directly, or a simple INT 19h bootloader. (I have good cause to believe that it'll be the latter, at least for the initial phase of development.) Once we've got that working, then we'll have a good idea of how much space we've taken up, and how much we can sensibly use for our extensions. At that point, the debate on how we should proceed will be more relevant, but will still be answerable simply by flash-time selection of modules. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Hi.
by Pascal Dornier 01 Mar '98

01 Mar '98

Benjamin Scott wrote: > I suspect that, for onboard IDE chipsets, the IDE BIOS support code is >not part of (for example) Award's code, but something imported from the >chipset manufacturer and co-existing with the Award code. If so, we >might be able to use that same code block. Anyone know for sure? This code is owned by the BIOS vendor. Most of the hardware specific code is in the transfer rate configuration registers. The actual operating code is most likely very generic, at most using 32 bit data transfers rather than 16 bit. -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] OpenBIOS: reality check
by Benjamin Scott 01 Mar '98

01 Mar '98

DK = David Kennedy <dkennedy(a)engsoc.carleton.ca> DK> I was told (recently) that there is a Linux network boot ROM code DK> on the Web somewhere. It might be worthwhile to check it out be- DK> cause it might be a good start to this project. I don't know the DK> reference unfortunately. I was sent this URL, maybe it is what you're thinking of? http://www.slug.org.au/etherboot/ DK> I just think back to the days when I had some wierd piece of DK> hardware that nobody wanted to support, and I had to money to buy DK> a replacement. Especially when the hardware was free. Well, don't forget, if that happens, nothing is going to stop you from using the old-fashioned method of netcard boot ROMs. I think we should try and design this project such that, if native support for X isn't available in our code, we can fall back on whatever X used before our new BIOS came along. :-) DK> I don't think that offers enough support. Being able to boot off DK> of either SCSI or EIDE is fine, but _WHICH_ SCSI, and _WHICH_ EI- DK> DE? Which partition, which controller, which HD... I do agree. As far as picking which device controller, I think you might be able to determine controllers from BIOS extensions installed in upper memory, and pick the one you want. Any such controller which supports INT13 would then let you pick the drive to boot from. Partitions are entirely logical level anyway and thus are no problem. DK> To me, a BIOS password is useless. Actually, it's more than use- DK> less, it's damn annoying. But, hey, that's me. Oh, yeah, the usefulness is limited. But for some things -- say, for example, an office PC where you don't want people rebooting the machine to obtain unrestricted access -- they can be useful. It's a lot easier to hit RESET then it is to rip open the case and move a jumper. :-) > I have yet to see a machine that will boot without a graphics > card installed. But it's the BIOS that's preventing it, not the > MB. I have seen it done. I believe the machine had an Award BIOS, but it's been awhile and I'm not sure anymore. Granted, the OS might object, or some of your hardware might object, but there was nothing in the BIOS forcing you to have video. DK> People are always complaining about code bloat in the Linux kernel, DK> this is another idea to resolve that issue. Wow. I usually consider the Linux kernel small. I mean, compare Linux to NT. No Thanks. :-) > Do Suns, Apollos, HPs, IBMs, NeXTs, etc. have rudamentary > filesystem code in their BIOS? I know for an absolute fact that is has been done on the Alpha. Anything more I can't be sure of. :) -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

BIOS UI
by nuke＠bayside.net 01 Mar '98

01 Mar '98

i, for one, would like to state my opinion on the UI of OpenBIOS. i *DO NOT* want a command-line driven one. if i have to RTFM just to do what Award does with three keystrokes (autoconfigure a hard drive), i'll just give it up. something nice could be done with say, arrow keys and highlight bars maybe? i remember the old BBS days at 2400, with everyone trying to draw huge artistic works out of the regular ASCII characters.. maybe the BIOS shouldn't resemble some big elite ANSI, but that sort of interface is nice. and since this is going to specifically *for* the x86 PC, why not let it get interesting? we can use direct video memory access, no problem. earlier today, i saw an Award system doing its POST, but it started as a blank.. *during* the memory test, the whole thing quickly skidded onto the screen. that was pretty cool. i suppose my point is that we shouldn't try and make this thing so scary and esoteric.. true, many of us are unix people, but not everything has to be so dull and cryptic. i think a command-line BIOS is a bad idea, unless it's made *very* simple. _ _ __ __ _ _ _ | / |/ /_ __/ /_____ | Nuke Skyjumper | | / / // / '_/ -_) | "Master of the Farce" | |_ /_/|_/\_,_/_/\_\\__/ _|_ nuke(a)bayside.net _| --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] BIOS UI
by Stephen Williams 01 Mar '98

01 Mar '98

nuke(a)bayside.net said: > i could code that in asm using about 10k. C? who knows.. note that i'm > still for writing the entire thing in assembly. this is an issue we > should address now, before we go and bloat things with gcc. I use gcc (C++ in particular) in embedded applications, and I find that the word "bloat" is not appropriate. Hell, the compiler writes better assembly then I can. It is true that certain C and C++ libraries are not only overkill, but obese. That is not the fault of the compiler, and if you stick with the freestanding standard very compact programs can be produced. Doing without a compiler only makes sense for writing a few tricky functions or impressing women. -- Steve Williams "The woods are lovely, dark and deep. steve(a)icarus.com But I have promises to keep, steve(a)picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Summary: Booting the OS
by Joel Klecker 28 Feb '98

28 Feb '98

At 15:41 -0500 1998-02-27, <nuke(a)bayside.net> wrote: >System Commander is a very excellent Text-UI based bootloader, compatible >with damn near everything, written and sold by some company named V-Tech. >Norton Commander is a very excellent Text-UI based file manager by John >Socha released by Symantec Corporation. i recommend use of them both, but >unforunately only one of them has been cloned by the GNU.. i was kind of >hoping OpenBIOS would end up being a GNU-equivalent of System Commander. Have you seen the GRUB bootloader? (maybe it looks similar) I suggest getting the Debian grub sources[1] if you wish to try it on a Linux system (the plain grub sources require booting from a floppy to install grub). I am using that version of grub, and I consider it far superior to lilo. grub has a small first stage which then loads a protected-mode second stage, the second stage presents a nice full screen menu interface, the interface also supports reconfiguring, creating new comfigurations, etc. [1]<ftp://ftp.debian.org/debian/hamm/hamm/source/admin/grub_0.4.orig.tar.gz> and <ftp://ftp.debian.org/debian/hamm/hamm/source/admin/grub_0.4-1.diff.gz> -- Joel "Espy" Klecker Debian GNU/Linux Developer <mailto:jk@espy.org> <http://espy.org/> <ftp://ftp.espy.org/pub> God shows his contempt for wealth by the kind of person He selects to receive it. -- Austin O'Malley (1858-1952) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Summary: Booting the OS
by Florian Wunderlich 28 Feb '98

28 Feb '98

Here's the summary of our discussion about booting the OS and how it is done in the minicomputer world. This is not about integrating a new HAL into the BIOS; its just about how the BIOS should load and execute an OS from disk/net/... . - The "unintellingent" approach: c/h/s et al David Kennedy <dkennedy(a)engsoc.carleton.ca>, said that he boots his Next with the following command: bsd(0,0,0) [kernelname] but made not clear what "kernelname" means (passed to a secondary loader?). I booted (before its death) my Sun/CV (68k, SysV) with a command like b sd(0,0,0); syntax is clear. - The "we load an intermediate loader" approach: OpenBoot, ... James Laferriere, <babydr(a)nwrain.net>, said he boots his Sparc 4/xx series with a command like: /sbus/esp@0,800000/sd@3,0:a This is Sun OpenBoot 3.x syntax, as far as I understand, from Sun's OpenBoot 3.x Command Reference Manual, section The Device Tree. (www.sun.com) James states that the BIOS understands UFS(Solaris type) filesystems, too; but it seems to me that this is only true for the secondary boot program. The primary OpenBoot boot code does not understand more than TFTP and simple I/O. Quote from Sun: "Often, the program loaded and executed by the boot process is a secondary boot program whose purpose is to load yet another program. This secondary boot program may use a protocol different from that used by OpenBoot to load the secondary boot program. For example, OpenBoot might use the Trivial File Transfer Protocol (TFTP) to load the secondary boot program while the secondary boot program might then use the Network File System (NFS) protocol to load the operating system. Typical secondary boot programs accept arguments of the form: filename -flags where filename is the name of the file containing the operating system and where -flags is a list of options controlling the details of the start-up phase of either the secondary boot program, the operating system or both." Pros: Bootcode in the EPROM can be small and simple, and need to know only the Right Things; but in contrast to the conventional lilo-style boot, you can have a real comfortable boot prompt, with fq path name to the kernel etc. Cons: If your hdd or whereever you load the second loader from is broken you got a problem. With a litte extensions to the BIOS (network!), this is a fancy lilo. - The "we waste some space on hd only for our kernels" approach: BSD, DOS+loadlin A simple filesystem on a special partition. Pros: We do not need to know anything of a complex filesystem; but we can use different kernel images. Cons: Where are the pros, I have all those with lilo already. Stupid thing. - The "we implement a complex fs, network, cdrom, tape, ... <fill in your favorite killer device driver, at least 512k in size>" approach: Ok, why not just implement it in the firmware of your harddisk? Imagine, an ext2fs harddisk :-). This is the bootrom-on-my-nic-approach. What we wanted (David Kennedy): - Network boot - Boot from any partition - Booting a Linux kernel directly/Filesystem support, so we can easily specify above Linux kernel - A powerful BIOS UI (most likely command-line driven) - Extended hardware diagnostics in flash ROM To conclude, I think the only interesting thing is to improve lilo; without replacing the entire BIOS, I do not see any possibility to make things like diskless boot etc. work without Boot EPROMS on NICs. The best thing IMHO is to adopt OpenBoot for 80x86 machines. It has a well-thought concept, an UI (huh, forth :-), you can write your own hardware diagnostics, and with the secondary-loader-approach, you can do the other things as well. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

4 3

OpenBIOS == Open Boot/Firmware?
by Geir Frode Raanes 27 Feb '98

27 Feb '98

On Fri, 27 Feb 1998, Chris Arguin wrote: As an innocent bystander just entering the show, it appears to me that you are trying to reinvent the wheel here. Have you yet discussed the possibility of simply implement Open Boot (on Sun) or Open Firmware (on PowerPCs)? Same thing. It's availeable on PCI PowerMacs through a three-button combo at powerup. Allows for insertion of device drivers through interpreted/semicompiled Forth code and U*IX like device trees. It is an open standard; IEEE 1275-1994. More important, it *works*. Now. Probabely the best place to read about it is on the home page of the Open Firmware Working Group at; http://playground.sun.com/pub/p1275/ But let me quote some highlights from FirmWorks home page: http://www.cuviello.com/_portfolio/_FirmWorks/technology.powerfeatures.html --- Open Firmware encodes the drivers in a machine-independent language called "FCode". FCode is a byte-coded "intermediate language" for the Forth programming language. The same FCode driver can be used on systems with different processor types. Open Firmware can debug hardware, operating system software, plug-in drivers, and even the firmware itself through Interactive Debuggers. The Open Firmware client interface allows the OS to examine the device tree, temporarily use Open Firmware device drivers, display progress messages on the console device, allocate memory, and utilize other Open Firmware services. Usually, after the OS is fully initialized, it assumes responsibility for most of these tasks, and Open Firmware is no longer needed until the machine is rebooted. The device interface specifies the full set of FCode primitives guaranteed to be available to an FCode driver. A full-featured Open Firmware implementation, including debuggers, network protocols, selftest diagnostics, drivers for on-board devices, keyboard maps, graphics device support libraries, fonts, and on-line help, usually requires between 128K and 256K bytes of ROM space. --- Oh, by the way - SILO, the SPARC/Linux loader have no problems reading the ext2fs filesystem and thus first search out 'silo.conf,' reading that and since find the approriate kernel image. No need to rerun SILO just because of an updated 'silo.conf.' OTOH, SILO itself has to be placed somewhere/anywhere OpenBoot can find it. Usually that means sector one of the first partition, but details may be specified to Open Boot. Unfortunately, I see a problem in how to lobotomate Open Boot to allow legacy BIOS services to be implemented. Perhaps the Quarterdeck Quick Boot feature with a BIOS image reinsertion when needeed is the way to go. -- http://devworld.apple.com/dev/technotes/tn/tn1062.html http://devworld.apple.com/dev/technotes/tn/tn1044.html http://www.forth.org/ -- Geir Frode Raanes Omega Verksted NTNU, Trondheim Norway. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Hello
by Jeroen Jacobs 27 Feb '98

27 Feb '98

Hi, I just subscribed to this mailing-list and I read the discussion about implementing FS-code into the BIOS. There a few things you should consider first: * Every OS (DOS, Win95/NT, Linux, OS/2 ...) should be rewritten to use this new filesystem. * You should also include drivers for Hard-disks (E/IDE, SCSI). Can 1 ROM module hold all this code ?? * What kind of filesystem should it be ?? At least it should contain long filenames-support, user-permission flags and maybe auto-defragmentation. In my opinion it would be best to let the OS do the FS-code. Greetings, Jeroen Jacobs Internet: jjacobs(a)mail.dma.be Fidonet: 2:292/516.2 --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Hi.
by 9732520＠lewis.sms.ed.ac.uk 27 Feb '98

27 Feb '98

I just subscribed a couple of days ago and was trawling through the recent messages and a couple of things came to mind: 1) Any 32-bit OS cannot use int's below 0x1f for their own use. That is why the BIOS is not used (apart from the fact it isn't 32-bit). In protected mode, these interrupts are used or reserved by Intel to signal various exceptions such as FPU overflows or page faults etc. So any BIOS that was to be used by these OS's would have to use int's above 0x20 or another call method like fixed addresses for entry to functions. (which may just be a call to the actual location) and also keep the interrupt controllers out of these int numbers. 2) I assume 32-bit code is used as much as possible, ie. start up in real mode and switch to protected mode asap. and then deal with all the rest. It doesn't make much difference for boot really, but functions used by OS's should really be 32-bit now (name one *decent* real mode 16-bit OS). Otherwise, the project looks interested and may be of some use. Mark Scott marks(a)dai.ed.ac.uk Department of Artificial Intelligence, Edinburgh University God is real unless declared integer --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

3 2

Re: [OpenBIOS] Filesystem code
by Joel Klecker 27 Feb '98

27 Feb '98

At 10:54 +0000 1998-02-27, David Woodhouse wrote: >cpa(a)hopper.unh.edu said: >> What if, at some fixed point in *every* filesystem, the filesystem >> provided an interface to use it. That is to say that the read/write >> functions, etc, are actually BUILT IN to the filesystem. They have to >> be somewhere anyway, and this will (in theory) export them to any OS >> or program that wants to use them. > >Nice idea. Not very practicable though. > >Didn't the Mac do something like this, or was that only hardware drivers? Hardware drivers, and only disks at that. The Mac ROMs know just enough about disk devices to find the partition table, and load the disk's driver off of the driver partition. -- Joel "Espy" Klecker Debian GNU/Linux Developer <mailto:jk@espy.org> <http://espy.org/> <ftp://ftp.espy.org/pub> God shows his contempt for wealth by the kind of person He selects to receive it. -- Austin O'Malley (1858-1952) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] OpenBIOS: reality check
by Florian Wunderlich 27 Feb '98

27 Feb '98

>FW = Florian Wunderlich <florian.wunderlich(a)tec.med.uni-muenchen.de> >FW> Filesystem code in a _BASIC_ input/output system is not a good idea >IMHO. > > The firmware on IBM-PCs can no longer be correctly termed solely an >input/output system. The emphasis was on BASIC, as shown with upper case letters, and maybe we should remind that fact. What I wanted to express is that FS code does not belong to the BIOS or M/B firmware or whatever you want to call it. It depends on the operating system, not on the hardware, and in consequence, it should be implemented in the os. >OS> Note, I did not say I think it should be part of the BIOS code, just >that it >OS> should reside in ROM. > > With all due respect, this is a technical mailing list, not an English >lesson. :-) We are not computers. We can (hopefully :) figure out >what other human beings mean without needing literal terms. Huh. May I repeat that? :-) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Microkernel BIOS
by Igor Babanov 26 Feb '98

26 Feb '98

Wants to offer on discussion an idea and its glance to the development new BIOS. Idea is based on ideas to apply to BIOS, as a small multitasking operating system kernel.(microkernel architecture). If asked by simple words, this kernel consists of microkernels (hard determined) and minimum kit of managers of resources (practically always used in all systems).Other managers of resources can loading from Flash (when initializing) or from the disk (ROM, Flash, HDD, Net) dynamically, on the measure of need, under the work system. MicroKernel BIOS consists: 1 Scheduler. 2 Universal mechanisms of messages communication ( aplicable between process, in network, in multiprocessor, in graphic, and etc exhibits). 3 Interruption Handlers of lower level. 4 Universal mechanisms autoconfiguration myself and the whole around. 5 Universal mechanisms of accompaniment of new managers of resources. Main purpose: 1 To Use BIOS as microkernel for the whole operating system as a whole (rather then for the sake of compatibility only, initial configuration and bootstrap) 2 Buildings BIOS module. At the appearance of new versions of devices - are changed versions of managers of devices. At the appearance of new technologies - is added new manager of resources, written on narrowly defined rules. 3 Developers hardware deliver only one programme manager of device, used as a central to drivers for all operating systems practically. Main difficulties: 1 Compatibility and emulation old BIOS. 2 Choices of universal standards for the issue of reporting, autoconfiguration, accompaniments of new managers and e.t.c. 3 New programme interface Developments to BIOS calling. Old interface herewith too must work, but be considered as a temporary exception. 4 Commercial and political and etc contradictions. Best regards, Igor Babanov --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Considered Open Firmware?
by Joel Klecker 26 Feb '98

26 Feb '98

Several people have mentioned Sun, HP, SGI, etc. workstations boot firmware as examples of kinda the approach the project may want to take. Open Firmware was originally based on Sun's OpenBoot 2.x, and UltraSparcs use OpenBoot 3.x, which is Open Firmware compliant (according to the below site), OF is IEEE standard 1275, and seems quite well thought out, and can do pretty much everything stated as desireable on this list. Other platforms that use OF include most PReP and CHRP-compliant PowerPC machines. The problems I can see is that it is (probably) too big to fit the space we have to work with, both in flash and NVRAM, and x86 processor bindings are not quite there yet, also, it is very unlikely that it could handle booting Windoze, DOS, etc. However, it may still prove useful as reference, see <http://playground.sun.com/1275/> for info. I will quote the description from the above site: << OPEN FIRMWARE DESCRIPTION. Open Firmware is the only firmware standard in existence to have its own song. Download or listen to Mitch Bradley singing the Open Firmware Song (278k). Open Firmware is the non-proprietary name of firmware complying with IEEE Std 1275-1994. OpenBoot (tm) is Sun Microsystems trademark for the firmware product shipping on over one million SparcStations(tm) and SPARCServers(tm) since 1989. Apple Computer's newest line of PCI bus-based Power Macintosh(tm) desktop systems are shipping with Open Firmware. Among Open Firmware's many features, it provides a machine independent device interface, which can be used to boot plug-in cards without providing OS-specific and/or machine dependent binary programs on the plug-in card. This feature enables plug-in card manufacturers to easily support several independent computer architectures without needing to supply different firmware for each one. Open Firmware is based on Sun Microsystem's OpenBoot 2.x implementations and complies with ANS (ANSI) Forth. (Information on ANS Forth is provided courtesy of Athena Programming, Inc.) You can also get additional information about Forth and the Forth Interest Group on the World Wide Web at Forth Interest Group Home Page. OpenBoot 3.x, currently shipping on Sun's 64-bit UltraSparc based systems, complies with the Open Firmware standard. Open Firmware is now shipping on Apple Computer's 604-based, PCI bus, PowerMac systems. Read how Apple Computer describes PCI bus and Open Firmware. Table of Contents. >> Regarding size, <http://www.firmworks.com/www/size.htm> has this to say: << Size A full-featured Open Firmware implementation, including debuggers, network protocols, selftest diagnostics, drivers for on-board devices, keyboard maps, graphics device support libraries, fonts, and on-line help, usually requires between 128K and 256K bytes of ROM space. In some system environments, unnecessary features may be omitted, making it possible to fit Open Firmware in a single 128K byte ROM. >> There's a more detailed description at <http://www.firmworks.com/www/ofw.htm> -- Joel "Espy" Klecker Debian GNU/Linux Developer <mailto:jk@espy.org> <http://espy.org/> <ftp://ftp.espy.org/pub> God shows his contempt for wealth by the kind of person He selects to receive it. -- Austin O'Malley (1858-1952) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

What is the point, a new BIOS or utilities in ROM?
by oskjaeve＠sivos.rl.no 26 Feb '98

26 Feb '98

As a newbie on the list I allow my self a couple of critical remarks and a few possible stupid questions. A quick scan of historical postings makes me think the group would benefit from clearing up a few things. There seems to be a demand for having certain functions in ROM. File system code has been mentioned, and also a boot loader of some kind to get rid of LILO. Making the BIOS be more than a BIOS would be a mistake in my opinion. The BIOS is sopposed to be the hardware abstraction layer, and I think it should be kept that way. If we need a better BIOS, then we should build one. I think a discussion on BIOS topics and how we could improve it, would do us good. Please don't confuse it with where the BIOS is stored. Pulling a new BIOS from disk after startup from a primitive ROM based BIOS, is ok. If the code is a hardware abstraction layer, it is still a BIOS. If we would like to move code normally kept on disk to ROM, like putting file system code or a LILO-killer in ROM, then let us do so. But let us not make it part of the hardware abstraction layer code. So what are the goals? Putting file system code, a LILO-killer, networking software or other code in ROM because it is better than pulling it from disk? Or is it to build a better hardware abstraction layer? Or both? If I may suggest a utility that I think belongs in ROM rather than on disk: an improved memory test. Note, I did not say I think it should be part of the BIOS code, just that it should reside in ROM. (ROM is, by the way, a pretty hopeless acronym because a read only memory is totally useless. Even PROM doesn't make any sense, how can one program a read only memory? If we'd known better back in the stone age, we would have called it a WORMM, write once read many memory, or something...) For the benefit of further discussions, I suggest we somehow make it clear wether we are talking about putting non-BIOS type of code in ROM or if we are talking about actual BIOS code. -- Odd Skjæveland oskjaeve(a)sivos.rl.no --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

3 2

Re: [OpenBIOS] OpenBIOS: reality check
by Benjamin Scott 26 Feb '98

26 Feb '98

DK = David Kennedy <dkennedy(a)engsoc.carleton.ca> DK> Hmm... I certainly hope that I never get a system without an ISA DK> bus. I have way too many specialty cards that require it. Well, I doubt ISA will ever go away totally, but you may see it relegated to specialty systems. Depending on your application, you may find your existing ISA system suitable forever. Or, it may be time to move your specialty cards over to PCI. :-) DK> With the dozen or so PC chipsets out there, can all these differ- KD> ent versions of the initialization code be effectively created? This is an important point. I don't know how things work at that low a level. It is entirely possible that we're biting off more then we can chew. On the other hand, the IBM-PC world is full of de facto standards. We may find much of the chipset support is the same. DK> This one has been done over and over. But it's done with a BIOS DK> chip on the network card using the technique I discussed before. I would like to have more control over the network boot process, including specifying host and boot image at boot time. I haven't seen anything that does this using the ROM on a netcard, though I am far from an expert. Being able to "ping" from the boot monitor prompt would be a handy tool, too. DK> Again, because of the multitude of network boards, I forsee it DK> being very difficult to offer this in a generic BIOS. We don't have to support every network card ever made. Supporting just a few (ie, NE2000, 35x9, etc) would get us support for a large number of systems. And it is a universal agreement that our firmware code should be modular, allowing the user to select which features (such as drivers) they wish to include in the final firmware image. DK> This is a rather easy extension. But the more important one is DK> to boot off of any controller type (SCSI, EIDE, ...) That's a little more complex, but should be doable. I don't think we have to support every SCSI card on the market -- I think it should be possible to select the interrupt services provided by disk controller BIOSes. I'm pretty sure that's what my BIOS does now by offering me a "Boot SCSI or EIDE first?" option. DK> Actually, all BIOSs (to my knowledge anyway) have extended hard- DK> ware diagnostics. The problem is that nobody knows about it. Which is effectively the same as not having them. :-) Perhaps it would be better to say "Extended hardware diagnostics which we can *use*". :-) DK> Unfortunately, enhanced security is not feasable, especially if DK> someone reaches into the case and jumpers the "clear CMOS" DK> jumper. "It is important to realize that any lock be be picked with a big enough hammer." -- Sun System and Network Admin Manual In other words, it is impossible to make a system full-proof. But a more intelligent password system, encrypted BIOS passwords, and the like, would be one more step in the right direction. :-) DK> I would spend good money on a machine that can boot without a DK> graphics card, and a keyboard. Many systems can, if you set both keyboard and video to "Not Present" in BIOS setup (or with jumpers). But it should be possible to do a better job. Of course, some hardware may just flat-out not work without (for example) a VGA card present, but that's bad hardware, not our fault. :-) DK> and the machine has room for all of my custom ISA cards. What exactly do all these custom ISA cards *do*? <G> me> While the idea of implementing a whole new set of BIOS calls -- either me> to be more powerful or faster, or to run in protected-mode -- sounds me> appealing, it would be totally useless. DK> I don't see a need to reimplement all of those calls either. Es- DK> pecially since most of them are kludged anyway. Rewriting them DK> to new specs (in 386 Protected mode) could get rid of code bloat DK> in the Linux kernel, and could pave the way for some tiny embed- DK> ded OSs. I think you missed me point entirely. What I said was, reimplementing all the BIOS calls (or creating new ones) to provide a protected-mode interface would be pointless. See my previous message for the reasons why. :-) DK> Well, rudamentary filesystem code would be acceptible, I think. DK> Enough to find the kernel. That's all I'm taking about. I don't mean full read/write/accounting support. Just enough to find the kernel file on disk, load it into memory, and boot it. Nothing more. DK> How does other command line BIOSs do it? Some just pass control to a secondary boot loader using a standard interface (I'm told Suns do it this way). Others (eg, MILO for the Alpha) actually include Linux filesystem drivers into the firmware, giving you the ultimate in flexability. I'm suggestion something in-between. :) -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

OpenBIOS: reality check
by Pascal Dornier 25 Feb '98

25 Feb '98

The purpose of a BIOS is to create independence between hardware and operating system. A streamlined BIOS can be quite compact. For example, my own BIOS, tinyBIOS, is about 10k lines of assembly source, < 16KB of object code). The code is mostly 16 bit, with 32 bit code used where it makes sense (e.g. memory test) or is required (32 bit PCI entries). 16 bit code is more compact. Assuming no unnecessary delays, system startup time is dominated by hard disk spinup time, and cannot be reduced any further. If desired, custom boot loaders can be installed in the remaining flash space. I've done this for one of my customers (they're using their own non-UNIX kernel and file system). > reentrant BIOS code so we can leave out drivers from the kernel(s)? Why bother ? We're talking about a few KB worth of code. On some platforms, execution out of BIOS space can be slower due to hardware constraints (cacheability of BIOS space etc). If you try to keep this code in the BIOS, you will have extra overhead for generic OS hooks etc. > On Systems with 4MBit Flash (are there any?): Kernel in Bios What if the kernel gets any bigger ? Most boards have 1 Mbit or 2 Mbit flash anyway. > USB Support Unless you need to boot through USB, probably bad idea. This belongs in the OS. > PCI/EISA/PnP Support EISA ??? what's that <g> ? ISA PnP should be implemented at the OS level, if at all. PCI PNP is much simpler and more likely to be reliable. > MSDos Filesystem code A standard BIOS doesn't know about the file system, all it does is load the first sector on the disk. The rest is up to the boot loader of the operating system. > repeat the same procedure for any cards which bring their own BIOS > (SCSI, video, etc.) Do you want to spend the rest of your life doing this ? > obtain complete documentation on how you query SIMMs/DIMMs/etc. > (including common bugs) This is generally based on a trial and error detection procedure (set biggest possible size, then find out how many address bits really work), rather than presence detect bits. > add some backward-compatibility interface for people needing DOS > or one of its offsprings (Maybe not) Highly desirable, DOS is a much easier environment for low level debug. > implement some clever auto-configuration mechanism Yes, this is key. Setup screens are evil. My BIOS doesn't have one. Finally, who are you writing this for ? For the individual user, I think it will be better to leave the BIOS on their system board alone. The savings in boot time etc. will never pay back for the effort spent playing with the BIOS. For the industrial user (embedding Linux or FreeBSD in a custom designed system), they can easily afford to license a commercial product from the usual suspects (Award, AMI, Phoenix, Systemsoft, General Software, moi). In volume, this can be as low as $0.10 per unit. For small volume users, adaptation cost (either at the BIOS vendor or on their side) will be higher than the license cost. If you want to make the UNIX platform more suitable for embedded use: - Make the file system fault resilient. Existing boxes (e.g. http://www.whistle.com ) have to include a UPS to protect the file systems. Costs lots of money, and doesn't protect against software induced crashes. - Flash file system support. Aggressively reduce size of minimum system (e.g. for routers). 1 MB = $5 or more. It's coming down, but slowly. -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

5 4

32bit development environment
by Stephen Williams 25 Feb '98

25 Feb '98

If youall are going to write this OpenBIOS thing in 32bit mode, I would like to offer up a C/C++ development environment that would suit this project nicely. Take a peek at uCR at <http://www.picturel.com/ucrhome.html>. Source is available, as are the compilers (EGCS) precompiled. To make it go, someone would need to write a linker model and startup code. I already have thread switching for i386, but not interrupts. It is plenty small enough for the limited flash of a typical PC. I have TCL 7.6 ported to this environment. This port is currently tied to the ISE board (a Picture Elements product) but I can fix that if there is demand. It should be plausible to write call gates into 32bit code from 16 bit mode, but I don't really know. If you think all the work should be done in 16bit mode, then I doubt this will be helpful. -- Steve Williams "The woods are lovely, dark and deep. steve(a)icarus.com But I have promises to keep, steve(a)picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Pavel Machek 24 Feb '98

24 Feb '98

Hi! > The core-bios would boot up like most BIOSes do now, by requiring lilo or > something like that. But with the user-extention to support ext2fs and > FAT, you could then do something closer to the Sun bootloader. Sun bootloader does *NOT* have any filesystem hardcoded. It just knows how to boot initial 8K block from SCSI (something like MBR) and pass command line to it. It is this 8K block which knows filesystems. I don't think bios should understand fs: you don't want to have partition just because of booting. I do not think that we should change current system anytime soon. Pavel PS: Did anyone try to flash that bochs bios into flash and see if it boots? -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] OpenBIOS: reality check
by Pascal Dornier 24 Feb '98

24 Feb '98

>I believe the main problem of today's BIOSes is that they're designed to run in >real mode. A protected mode OS will either have to switch to and from real and >protected mode to perform I/O (which isn't very neat, and incurs quite a lot >of execution overhead) or ignore the BIOS entirely and provide its own I/O >routines (which is a waste of coding effort). It'll be good if there's a BIOS >that can provide some sort of protected mode framework (possibly amounting to >a microkernel?) within which an OS can access BIOS services in true protected >mode. (Proprietary ROM BIOS extension cards will probably have to be modified >to fit into this scheme, but that's another story...) That's been done in 1987, the so called ABIOS (advanced BIOS) in IBM's PS/2 systems. It was intended to be for OS/2. I don't know whether it got used at all, but the idea died together with the Microchannel architecture. Nobody missed it ever since... Today's protected mode OSs use their own drivers to avoid switching modes. And switching modes on 386 and later CPUs is much faster than it was on the "brain-damaged" 286. -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] OpenBIOS: reality check
by David Kennedy 24 Feb '98

24 Feb '98

On Tue, 24 Feb 1998, Stefan Reinauer wrote: > > A standard BIOS doesn't know about the file system, all it does is > > load the first sector on the disk. The rest is up to the boot loader > > of the operating system. > > Wrong. Current BIOSs have a simple MSDOS system in their int-Code. MSDOS > even doesn't have it's own filesystem code afaik.. According to all the BIOS code I have read, BIOSs do not have any filesystem code. As outlined before, all they have is sector, cylinder and head code. > > This is generally based on a trial and error detection procedure > > (set biggest possible size, then find out how many address bits > > really work), rather than presence detect bits. > > Again, modern PC Chipsets allow reading the exact RAM configuration out of > their registers Yes, in a proprietary way. I would like to take this opportunity now to stop and as "Why?" I'm sure it's been brought up, but I don't see the need to rein- vent the wheel when it comes to BIOSs. First off, don't all PCs come with BIOSs? Second, writing a generic BIOS that will encom- pass all the new motherboards, IMO, will be a wasted effort. Aren't the majority of PC chipsets proprietary on how they are initialized for caching, memory configurations, et al? Personal- ly, I see this project as a waste of programming power. As it was said earlier, the only forseeable benefit is to LILO (ini- tially). I don't see much support after that either, unfortu- nately. The idea of replicating the BIOS programming interface is not a worthy effort either, IMO. Everyone agrees that it is old, ante- quated, and kludged. The idea of rewriting all the BIOS routines anew without the legacy baggage is a good idea, but I don't think that you should "hide" the fact that you are doing it. I think, if you are going to rewrite the BIOS routines correctly, a unused interrupt vector should be chosen, and a completely new set of routines should be written. Or perhaps, simply writing a com- plete set of routines to be loaded overtop of the BIOS, so that any programming wanting the GNU BIOS routines would simply in- clude the object file, and call a initialization routine or two (provided of course they are taking complete control of the sys- tem). Those are my ideas for the current project. As an offshoot from this project, I have an idea that I can per- sonally use (or, more specifically, that I wanted to use). Ac- cording to the documentation I have, memory locations from C8000h to E0000h are checked at 2k intervals for the sequence "0xAA55" If it is found, the next byte is a "length indicator representing the number of 512-byte blocks in the ROM." Following that is a far code entry point. The entire ROM also has to be checksummed modulo hex 100 and come up to 0. I think this interface can be used to produce a LILO of sorts that can replace the initial boot loader. A command line interface can be supplied, as well as some code that would investigate the current hard drives, and their partition tables. This could produce a BIOS that is simi- lar to many older "minicomputer" style BIOSs. This interface is checked after all of the initialization sequence occured, and be- fore any bootstrapping. That way, a more modern BIOS can be written without the worry of compatibility between all sorts of different hardware. This has other practical values as well. Since every single PC in existance has a ISA bus, but not all PCs have the same BIOS chip (not even the same number of chips, or the same number of pins), this allows for better distribution. It allows faster development time, since you can easily remove a card to boot the machine to a useable state again. (as opposed to gerryrigging some sort of external platform with a mechanical switch.) Also, hardware illiterites are more comfortable in- stalling an ISA card, as opposed to removing chips off of the motherboard. As for my experience, I have been programming in Assembly lan- guage for 7 years now, concentrating on low level VGA program- ming, rudamentary OS code, as well as custom cards. I have two BIOS listings, one is a 386+ BIOS reverse engineered (obtained freely from x2ftp.oulu.fi I believe). The other is in the back of the IBM Technical Reference Personal Computer AT, 1985. This code is original IBM BIOS code for the 286. (Did you know that they tested each register, conditional jumps and the BOUND in- struction?) Whichever way the project desides to go, I wouldn't mind helping out. I have experience in this area, and I would like to prac- tice my skills in something, that might, quite possibly, do some- thing, for someone, somewhere. ;) -- David Kennedy Vic/Linux and Pet/Linux: RPMs coming soon.

2 1

Hard drives, CMOS/VRAM and some general ideas
by Alle Metzlar 24 Feb '98

24 Feb '98

This past weekend I have subscribed to the OpenBIOS mailinglist, and it took me some time to read all contributions, except for some in the archive. Following are my thoughts in this discussion: CMOS/NVRAM Older PCs use a CMOS of 64 bytes, newer (486 and up) use 128 bytes. Some other systems use up to 4K or 8K of CMOS (MCI/EISA). The first 16 bytes of CMOS are reserved for RTC use: 00h - 09h Time and date fields 0Ah Status Register A 0Bh Status Register B 0Ch Status Register C 0Dh Status Register D 0Eh Diagnostic Status Register 0Fh Shutdown Register The following 32 bytes are most commonly used for ISA configuration data, and the last 16 bytes are generally used for BIOS-specific configuration data, such as Boot sector virus-protection, security, ROM shadow config, and extended CMOS checksum. An additional 64 bytes may be available in the Extended CMOS RAM, incorporated in many chipsets to store advanced config info. >From space in CMOS RAM 16 bytes less are available. Hard disk drives BIOS CHS limits to 1024/255/63, thus supporting up to 8.0325 Gb. IDE CHS limits to 65,536/16/255, thus supporting up to 130.56 Gb. Thus the overall limits are 1024/16/63, supporting only up to 504 Mb. A little resize of storage in BIOS/CMOS would break those limitations, as Microid Research may have done with its MR BIOS. As far as I know the MR BIOS has CHS support for 16384/255?/63? (128.52 Gb). It already did in 1990! I have used a 2 Gb EIDE drive in an old 386DX (1989) ISA machine with an MR BIOS v1.51, though advanced PIO/DMA modes were not available. Some sort of translation is used however, but I haven't figured that out. It isn't LBA according to WD/Phoenix for sure. By the way, MR BIOS supports installation of 8 hard drives and 4 floppy drives, for some years now, and you can boot from all of these. OK, there is the idea of designing an OpenBIOS. Are there any general ideas on how this OpenBIOS should be designed? Most BIOSses still have the IBM compatibility, that is compatibility to the older PC and XT standards, by maintaining a list of vectors to the IBM-compatible vector (AMI calls this the ROM Compatibility Table, Phoenix calls this COMPAS or Compatibility Structure). And what about the INTs. As I recall, Intel reserved 32 ints to be CPU ints. With the 8088 just a few were used, and IBM began to use all non-used but reserved ints for their PC BIOS, which means that we now are stuck up with several ints being both BIOS and Hardware/CPU ints, such as 05h, 10h, 11h, and 12h. Are there any ideas on this, including some possible work-around? BIOS should at least consist of three parts: Power-On-Self-Test (test and initialize various components, and eventually the bootstrap loader), System BIOS (providing the interface between OS and hardware: interrupts), and a setup utility (system configuration). The setup util should be in the BIOS itself, or a special key(combination) should be available during POST if things go wrong, and you can't access the setup program on disk. The setup program should be functional, and doesn't have to have great looks (as the AMI WinBIOS?). -------------------------------------------------------------------------------------------- Alle Metzlar Matrix Technologies P.O. Box 40, NL 1724 ZG Oudkarspel The Netherlands Tel: (+31) 226 316889 Fax: (+31) 226 312157 EMail: matrix(a)xs4all.nl WWW: http://www.xs4all.nl/~matrix/ (Matrix Technologies' BIOS Web) -------------------------------------------------------------------------------------------- Author of: Het BIOS boekje, Uitg. Pim Oets, ISBN 90-5722-013X Das BIOS Buch, Franzis' Verlag, ISBN 3-7723-4832-7 Die BIOS CD-ROM, Franzis' Verlag, ISBN 3-7723-8612-1 --------------------------------------------------------------------------------------------

1 0

Re: [OpenBIOS] OpenBIOS: reality check
by Pascal Dornier 24 Feb '98

24 Feb '98

>Is your TinyBIOS commercial or is it somewhere available so that we could >have a look at it? ;-) tinyBIOS is a commercial product. At this point I don't think I can afford to give away the farm. I could potentially release the source for non-commercial use only, but not under GPL. >I thought about USB keyboards I think USB keyboards are a lousy idea. I'd rather use USB ports for devices that really need the bandwidth, and are a hassle to hook up otherwise, such as a scanner. Once you get above two USB devices, you will need a hub, and end up with a desk encrusted in USB cables... >Wrong. Current BIOSs have a simple MSDOS system in their int-Code. MSDOS >even doesn't have it's own filesystem code afaik.. News to me. My BIOS works pretty well without any file system. The only place where some kind of file system is needed is for CD-ROM boot, which I don't support at this point. >> This is generally based on a trial and error detection procedure >> (set biggest possible size, then find out how many address bits >> really work), rather than presence detect bits. > >Again, modern PC Chipsets allow reading the exact RAM configuration out of >their registers Guess who sets this configuration ? The BIOS. Do you seriously think a PC manufacturer would waste $0.50 on a input port to read the presence detect bits, if he can detect the memory configuration in software, and avoid compatibility problems with SIMMs that don't have the right configuration ? PC designers would sell their grandmother for savings of $10 a system... -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Ben Pfaff 24 Feb '98

24 Feb '98

> Why not? Award BIOS does this, Windows 95 does this. As we participate at > "The right thing to do[tm]" we should be allowed to do so, too. Microsoft does a lot of things the wrong way :) Microsoft flashes the BIOS? Then won't our BIOS, or part of it, get blown away, if we're not careful? I belive someone mentioned that there limits to how many times you can flash most chips. If so, then we definitly don't want to do it every bootup, especially if we are supporting DOS/Windows :) I don't believe that we were going to flash it every bootup, just every time that the user decides to changes his boot settings or whatnot. That should be fewer than 100,000 times, I think, normally. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Chris Arguin 24 Feb '98

24 Feb '98

On Tue, 24 Feb 1998, Stefan Reinauer wrote: > On Fri, 20 Feb 1998, Chris Arguin wrote: > > > All things considered, you really don't want to flash the BIOS too often, > > and especially not behind the users back, so to speak. As pointed out > > before, we could always reserve a parition on the disk, which would allow > > for extra code and data. This just strikes me as kinda kludgy... > > Why not? Award BIOS does this, Windows 95 does this. As we participate at > "The right thing to do[tm]" we should be allowed to do so, too. Microsoft does a lot of things the wrong way :) > This allows having no disk at all. It could be possible, too, to receive > BIOS settings over the net (or from disk). Maybe this should be made > dependent on whether you have a disk or networking card or not. I think everyone has agreed that this will be modular enough that if you don't like a feature, don't use it. I belive someone mentioned that there limits to how many times you can flash most chips. If so, then we definitly don't want to do it every bootup, especially if we are supporting DOS/Windows :) -- Chris Arguin | "Multiple exclamation marks are a sure sign of a Chris.Arguin(a)unh.edu | diseased mind." - Eric, Terry Pratchett --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] Licensing of the code.
by Pavel Machek 23 Feb '98

23 Feb '98

Hi! > > > Or did you mean the actual microcode update, as opposed to the code which > > > loads it into the CPU? > > > > I mean the actual microcode update. > > So what is at issue? The only problem I can forsee is getting Intel to > give us the Microcode update, since they are not usually publically > available. Intel has had a Microcode fix to the F00F bug for awhile, but > is only releasing it to specific vendors, many of whom aren't even > bothering to use it. Wouldn't you like to be able to take that F00F kludge > out of Linux? Wrong. F00F workaround is not based on microcode update. And linux already does it :-). Pavel -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

RE: [OpenBIOS] User-extentions
by William A. Arbaugh 22 Feb '98

22 Feb '98

On Saturday, February 21, 1998 2:37 PM, Benjamin Scott [SMTP:hawk@ttlc.net] wrote: > >>> Remember that the CMOS settings are stored in the NVRAM, not the > >>> flash. Now the question is how big is the NVRAM? I don't think we > >>> have room for this. > >> > >> Why do these have to be stored in the NVRAM? Can't we reserve 1K or > >> so of flash for this sort of thing? Or can't you erase and replace > >> just a little bit of flash at a time? > > > > All things considered, you really don't want to flash the BIOS too > > often,and especially not behind the users back, so to speak > NVRAM varies from machine to machine some of the chips now have several K available since a number of BIOS' store the ESCD (needed for PnP) info in NVRAM rather than flash. Most of the flash ROMs support up to 100,000 reprogramming cycles. > Flashing the BIOS often would be a Bad Thing. There is a limit to how > often you can write flash ROM. It would take awhile to hit it, but it > is a real limit. Plus, I think you need to erase flash ROM in banks of > a certain size. At least, I've seen plenty of stuff that worked that > way and that way only. > You do need to flash in blocks. The size of the block depends on the chip with the modern chips now having small blocks for storing configuration information, e.g. the Intel 28F001BX-T (128K)has two 4KByte parameter blocks plush a 8KB boot block. The boot block has extra HW protection to prevent accidental reprogramming. This is how the Intel boards prevent you from completely trashing your bios by mistake and ruining the motherboard (since the flash chips are not removable on Intel boards). > If we're going to store boot configuration info on disk, we might as > well just go back to using LILO. I want something that can boot your > selected OS without the need of loading from the disk. > So do Microsoft and Intel. This is why they've put together the NetPC spec, and why there is etherboot and netboot now available for Linux. You can burn/flash a ROM today that you can put in your ethernet card's ROM socket and do a net boot with out every touching your hard disk. Take a look at http://www.slug.au/etherboot. Bill --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Alexander Viro 22 Feb '98

22 Feb '98

On Sun, 22 Feb 1998, Benjamin Scott wrote: > Pascal Dornier wrote: > > 1. DOS translates logical block address into Cylinder / Head / Sector > > based on BIOS parameters. This is constrained by the 10 bit limit > > on cylinder and 6 bit on sector number (and sector numbers start > > at 1, which further mucks things up). > > I never really thought about it, but yeah, I guess DOS's sector > numbers are a form of LBA, aren't they? Is the LBA DOS uses the same as > the LBA used by IDE? How could it be, given that DOS does start sector > numbers at 1. Does the BIOS provide an INT13 extension/alternative that > supports LBA directly? I've never looked at this stuff this closely > before. Pointers to info are also welcome. :) No, they aren't. DOS sectors are linear within the partition. And that's it. It uses damned amount of layers: linear in the partition -[int25/26]->3D-[BIOS Int13]-->3D----[IDE,EIDE] \->linear[EIDE,SCSI] For Linux: linear -[driver]-->3D----[IDE] \->linear[EIDE,SCSI] Moreover, BIOS in LBA mode means the following: translate DOS 3D into linear and use another set of hardware commands. Interface DOS/BIOS remains the same. > > > 2. The BIOS translates this either into another CHS > > What I don't understand is: If DOS and Linux coexisting on the same > system, and you have BIOS geometry translation on to support DOS, Linux > still works. But Linux doesn't use the BIOS. So how does that work? It uses either linear addresses or native drive CHS. All point of BIOS translation is to map CHS addresses provided by DOS into the real addresses. > Does Linux do the remapping instead of the BIOS? There must be a What should it remap? Who will feed CHS addresses to Linux driver? For Linux the disk is a 1-dimensional array of sectors. For DOS it's 3-dimensional one. Both are _ordered_. And there is a real disk geometry. It's also an ordered sequence of sectors. These orderings should be the same. Everything else is irrelevant. Driver (or BIOS, in DOS case) should get a position in array (1D for Linux, 3D for DOS) and transform it into the disk's one. And vice versa. All (E)IDE disks can be addressed as 3D arrays _and_ there is a command that makes disk to say you its dimensions. New disks can be addressed as 1D arrays. Now, for DOS we need to choose some dimensions suitable for DOS (Cyl<=1024, i.e.) and make a correspondence between DOS 3D coordinates and disk 3D or 1D. The only tricky part is choosing the dimensions for DOS, for correspondence should preserve the order and disk dimensions are known. That's the work of BIOS translation. For Linux we have to make either correspondence between 1D and 1D [preserving the order!], or correspondence between 1D and 3D with known dimensions [preserving the order, again]. If we know that the order is the same for DOS and Linux we can forget (in Linux) about DOS internal pecularities. And thus forget about BIOS translation. > standard method of geometry translation if that is the case (there > prolly is, I just never dug that far). > > > The only right thing to do is put up with this nonsense during boot, then use LBA mode. > > Or possibly, one of the things we can do in this project is implement > a new interface for the disk I/O, for use with advanced OSes and/or > bootloaders, which supports LBA directly, cleaning things up > considerably. Oh, sure, it would break some things horribly, but that's > why it would be an option. Hmm. Then you can take Linux IDE driver and put it into BIOS. Yep, it will break some things. DOS, for example. And Virus95, for it is loaded by BIOS drivers. And LILO (well, _that_ is not a problem for we have the source, but DOS & Virus...). NT will survive, for it uses its own loader. And consider the fact that BIOS access is _slow_. So Linux will still use its own driver (in regular RAM) for speed reasons. The only thing that will gain something would be LILO (rewritten, i.e.). > > We might even be able to implement a better partition table format > (like the BSD format). The MS partition table format is absolutely > horrid at times. Not a BIOS problem. For BIOS partitions don't exist. They are just linear chunks of disk. It's determined by OS. Even in case of DOS it is so (in MSDOS.SYS, as far as I remember). Oh, and boot loader have some reduced knowledge of these matters. Then it's a question of master boot loader. Al > > I know, I know, why reinvent the wheel. Because we can, dang it, > that's why! :-) > > -- Ben <hawk(a)ttlc.net> > > > --- > OpenBIOS -- http://www.linkscape.net/openbios/ > openbios-request(a)linkscape.net Body: un/subscribe > Problems? dcinege(a)psychosis.com > > --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Pascal Dornier 22 Feb '98

22 Feb '98

From: Benjamin Scott <hawk(a)ttlc.net> To: openbios(a)linkscape.net <openbios(a)linkscape.net> Date: Sunday, February 22, 1998 6:03 Subject: Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...) > I think it might be better to say that re-implementing things like >INT13 in protected-mode would be pointless. The few things that modern >OSes actually do *use* the BIOS for are definate canidates for >improvement and possible protected-mode reimplementation. However, >"BIOS32" implies it may be protected-mode already. Anyone know more >about this? Yes, 32 bit protected mode. See the PCI BIOS spec. > While I do agree in theory, memory space limitations may force us to >link the BIOS together before programming the flash. Which isn't really >a big deal. If you own all the sources, you can save yourself the complexity of linking. I don't even use a object linker, my assembler is fast enough to assemble the whole BIOS in about 60 ms. > Actually, to the list in general: Does anyone know exactly *where and >how* geometry translation occurs? I've been thinking it must occur in >the motherboard BIOS for onboard EIDE controllers. But we already know >many OSes bypass the BIOS. I was assuming they were still talking to >the EIDE controller through the BIOS, just via a different route. Is >that correct? Or is geometry translation implemented in the EIDE >controller chipset itself? Or something else? There are multiple levels of geometry translation. It's a classic example of Winchester Mystery House software design. Read it and weep. 1. DOS translates logical block address into Cylinder / Head / Sector based on BIOS parameters. This is constrained by the 10 bit limit on cylinder and 6 bit on sector number (and sector numbers start at 1, which further mucks things up). 2. The BIOS translates this either into another CHS (the drive can only handle 4 bits for the head number, but 16 bits for the cylinder number, and 8 bits for the sector). Alternatively, the CHS value is converted into a logical block address. 3. The drive translates the CHS into a logical block number, then converts that into the real CHS values (which is not a straight division as the number of sectors per track varies). The only right thing to do is put up with this nonsense during boot, then use LBA mode. -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Benjamin Scott 22 Feb '98

22 Feb '98

WA = William A. Arbaugh <waa(a)dsl.cis.upenn.edu> WA> Not true actually, Linux does use some bios32 functions for PCI WA> support. My guess is that they'll still need some BIOS level support WA> for PnP, Power management, and not to mention DPMI etc. You're right of course. I had forgotten about the PnP stuff entirely. I'm not sure how DPMI works, but it's a fair bet it needs BIOS support, too. I think it might be better to say that re-implementing things like INT13 in protected-mode would be pointless. The few things that modern OSes actually do *use* the BIOS for are definate canidates for improvement and possible protected-mode reimplementation. However, "BIOS32" implies it may be protected-mode already. Anyone know more about this? DW = David Woodhouse <Dave(a)imladris.demon.co.uk> CA = Chris Arguin <Chris.Arguin(a)unh.edu> DW> Regarding the module support: DW> We can either link them at flash time, or have the BIOS search through DW> the available modules when it boots. I prefer the latter, While I do agree in theory, memory space limitations may force us to link the BIOS together before programming the flash. Which isn't really a big deal. DW>> Other than that, I don't see any point in extra protected-mode DW>> functionality - as you rightly say, anything running in protected mode DW>> is going to have its own drivers already. CA> Not to be too purest... but is that the "Right Way"? The BIOS is CA> *supposed* to abstract that away. It doesn't. Maybe it should... Originally, yes, the IBM-PC BIOS was a hardware abstraction layer. Rather then, say, having disk device drivers, you called INT13 and got support that way. Now, the original IBM-PC platform has been extended so much about the only thing *left* is the original BIOS service code, like INT13. One might argue we should "fix" that, that we should put all that hardware abstraction back in. Other platforms (the Mac comes to mind) accomplish this very well. A standard hardware abstraction API has obvious advantages. However, it is typcially accomplished by providing a low-level API in firmware to which devices talk to. Each device implements the support for this API. Due to the open nature of the IBM-PC platform, this is obviously not going to happen. The only other way to do it would be to write device drivers for each and every device on the system, incorporate them into firmware, and let the OS call our new hardware abstraction API. Besides the fact that this would be totally redundent, I don't know that we have the flash ROM space to accomplish this. Even more important, I don't think it *would* be the Right Thing to do. The IBM-PC mindset has become such that device abstraction occurs at the OS level. This allows greater flexability and faster development, something that has kept the IBM-PC line going where others have failed. Software is easier to change then firmware. I don't really think that we should try to go back to the "old way" of doing things, despite the advantages. If you really want hardware abstraction in firmware, buy a Mac. <grin> CA> On a related note, I just bought a 8 Gig SCSI disk. CA> Due to limitations of my SCSI controller, [snip] CA> I now have an 8GB Linux Disk. That is not a bad thing, but it wasn't CA> what I was intending. So there is another bug for us to fix :) I don't know that we can. Geometry translation for SCSI would be handled by your SCSI controller and its BIOS, not the motherboard BIOS (which would only control EIDE gemometry translation). Actually, to the list in general: Does anyone know exactly *where and how* geometry translation occurs? I've been thinking it must occur in the motherboard BIOS for onboard EIDE controllers. But we already know many OSes bypass the BIOS. I was assuming they were still talking to the EIDE controller through the BIOS, just via a different route. Is that correct? Or is geometry translation implemented in the EIDE controller chipset itself? Or something else? -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by David Woodhouse 21 Feb '98

21 Feb '98

hawk(a)ttlc.net said: > > Could someone please tell me where protected-mode code will be > useful in the BIOS firmware? Initial memory and other hardware checks, and then some of the INT 15h functions for copying memory around above 1Mb. Oh, and of course the BIOS function to switch into protected-mode :) Also PCI and APM BIOS32 functions. Other than that, I don't see any point in extra protected-mode functionality - as you rightly say, anything running in protected mode is going to have its own drivers already. > I believe the single most important goal of this effort should be > modular design. If we make the design modular, most everyone can be > happy. Agreed. Most of the things we've been talking about recently have been proposed extensions which would be separate modules, so those who don't see the point don't have to use them. We have very little dispute about the core of the project, other than the fact that we're not entirely happy about LPGL but it seems to be the best option so far suggested. Regarding the module support: We can either link them at flash time, or have the BIOS search through the available modules when it boots. I prefer the latter, because it doesn't involve any intelligence on the part of the linker, and the extra headers required won't take up a significant amount of space Each module object needs a header, much like the existing BIOS extensions have. In it we need to store: length, checksum, entry point. We could also do with a flag indicating the invokation order, and whether it needs to remain in memory when it's done (for when we've uncompressed into RAM). For example, a chipset optimisation module would be loaded early, and not remain in memory. An IDE disk driver providing INT 13h functions could be loaded later, and will remain in memory. A boot loader will be loaded last. The power-up vector will point to a routine which does an inventory of the available modules, and invokes them in the correct order, uncompressing them from flash into RAM as required. This boot loader will provide certain basic functions for reading data from the CMOS and other things that a number of other modules will require. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] More comments and a proposal for priorities
by John Labovitz 20 Feb '98

20 Feb '98

Markus Kaufmann <kaufmann(a)pks-software.de> said: > A BIOS isn't something that you change daily like the newest > developer kernel. Once you have a perfect BIOS, you should never > change it. to interject a philosophical point here: this is why we're doing an *open* BIOS project -- to rid ourselves of the accepted myth that Thou Shalt Never Change The BIOS (unless the manufacturer tells you to, via an upgrade). yes, we should make it clear that BIOS changes are dangerous and could result in a nonbooting system, but that doesn't mean that someone who got some fancy new file system, device, etc., shouldn't be able to boot directly off it once the BIOS extension is available and installed. however, i do agree with the general point of not cluttering up the new BIOS (and our time devoted to this project) with too many features; things like grub-in-bios should definitely be considered options that are worked on in parallel or sequential to the core code, and compiled/linked in optionally by the user or distribution. john --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] More comments and a proposal for priorities
by Markus Kaufmann 20 Feb '98

20 Feb '98

Hi, At 17:05 20.02.98 +0530, Arjun Roychowdhury wrote: >I feel that while writing a BIOS, we must provide a small set >of very poweful operations instead of bloatingt the BIOS to include >one & all. I am strongly for adding prot-mode code, but only when >necessary. wheras prot. mode code will add extra bytes in size, >the advantages are obvious. However, IMHO, one should not just >rewrite the entire BIOS using prot. mode. Real mode code does >have its advantages, esp. in areas where mem. consumption is >not so critical. The real mode vs. prot. mode: If you want to support DOS, you have to rewrite the normal BIOS in real mode. Any protected mode extensions can't use these functions and have to reimplement them. If you wan't to boot from protected mode, you need your own SCSI-drivers, small VGA-Drivers and so on. Bye Markus Kaufmann --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

We have a testbed and initial code to work from - if we want it.
by David Woodhouse 20 Feb '98

20 Feb '98

Because the license of Bochs only permits using it "for the use it was intended", I've asked the author for permission to use it for testing our BIOS, and he's agreed. Furthermore, he's given us permission to do as we like with the BIOS implementation that he included with it, as a starting point for our project. I've put his rombios.c up for anonymous FTP at dwmw2.robinson.cam.ac.uk in /pub/bios, along with the Bochs distribution code. ------- Forwarded Message From: bochs(a)world.std.com (Kevin P Lawton) Subject: Re: Using Bochs for testing new BIOS code. To: Dave(a)imladris.demon.co.uk (David Woodhouse) Date: Thu, 19 Feb 1998 21:59:06 -0500 (EST) Dave, Yeah sure. Go ahead and use Bochs for this purpose. It'll be good for both of us, in that you may find hardware emulation inconsistencies etc, and give feedback. I'm not very attached to the BIOS I wrote. There was a big need for one, so I wrote it. I used 'bcc', the only freeware compiler that I could find at the time to generate 16bit-only code. I'd be interested in knowing what your tools of choice end up being. The BIOS is certainly not written in the best style (the interface between ASM & C I'd like to have different etc), but it's somewhere to start. Feel free to copy whatever BIOS source you need. I'd like to see a good freeware BIOS, and will be certain to use it with Bochs, if it turns out well. It would be nice to use a BIOS which has been tested on real hardware. This way I could shape up my hardware emulation. Keep in mind, I had no concern for timing of IO port accesses. You won't see any waiting in between IO accesses, since in emulated world you don't have to worry about how fast the IO device can handle this. Best of luck to you. - -Kevin Lawton Bochs Software Company > Hi Kevin, > > I'd like to ask your permission to use Bochs for testing purposes in the > development of OpenBIOS (http://www.linkscape.net/openbios/) > > OpenBIOS is a very new project, the aim of which is to provide an efficient > modular BIOS replacement for Intel PCs, with functionality such as serial > console support, proper chipset optimisation, RAID, etc. The list of ideas has > been vast, and with a proper modular design the end-user should be able to pick > and choose the modules he wants for his system. > > The project is probably going to be released under LGPL, allowing hardware > manufacturers to produce proprietary binary modules to support esoteric > hardware, while still retaining the freedom of the GPL on the majority of the > code. > > Naturally, the idea of blowing a piece of code we've just written into the > precious flash ROM of our PC and rebooting tends to frighten us somewhat, so > we'd like to use Bochs for emulating the PC environment in which our BIOS will > live. > This we would achieve by replacing the binary BIOS image used by Bochs with > our own work. > > As I sincerely doubt that this comes under the category of using Bochs "for the > use it was intended", I'd like, on behalf of the development team, to ask for > your permission to do so. > > Furthermore, (pushing our luck a little further :) ), if you would permit us > to use sections of your own BIOS code from bios/rombios.c as a starting point, > it would be very much appreciated. > > We would not envisage using significant amounts of your code in the final > release, but it would provide a very useful base to work from, on a project > that is so far only vapourware (although we've only been at it for less than a > week, so that's excusable) > > Thankyou for your time. > > Dave. ------- End of Forwarded Message ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

General comments
by Benjamin Scott 20 Feb '98

20 Feb '98

Hello all, Okay, a friend of mine got me so interested in this that I had to sign up. And, having signed up, I of course have to put my two-bits worth in. It's an Internet tradition! :) In regards to some stuff on the OpenBIOS homepage (OB being quotes from the homepage).... OB> Sun-like bootconsole I think this is one of the coolest aspects of this project. I've always liked things like DEC's SRM console for hardware-level control. They give you a lot of power and control and don't get in your way. For our purposes, they are also simpler to program, easy to extend for new features (just add commands and/or variables), and typically use less memory then full-screen menus. They also work on serial consoles. OB> Remote administration (?) I think I might have a better idea: Make the BIOS data structures available via a standard interface to the OS, allowing query and set. This is a good idea anyway (makes system administration easier), and lets the OS handle all the network transport and management protocol stuff. I don't really see any need to have the BIOS support it directly. Why complicate things needlessly? (Of course, if there is a legitimate need for this, by all means, let's do it). Would be nice if you could return to the BIOS UI from the OS via function call or hardware (like the HALT switch on DEC systems). I suppose you might even be able to return control to the OS, if you didn't make any intrusive changes, but I dunno if that would be useful. OB> no Unneccessary hardware detection that makes startup slow OB> no 16bit Code OB> no MSDos Filesystem code While I agree that we should dump anything that is around simply because it was there first, let's not fall into the trap of getting so hooked on redesigning things we forget reality. For one, any x86 CPU starts in real mode, so you'll need at least a 16-bit stub to init protected mode. Some expansion cards that provide BIOS extensions don't work well in protected mode (older stuff, true, but Linux has always been good on that front). Real-mode code is sometimes simpler or smaller then protected-mode, too. Likewise, DOS FAT has two advantages: It's simple (easier to support) and nearly universal (almost everything supports it). I guess my main point is, we should try to avoid arbitrarily declaring what "Must" and "Must Not" be. Make the code design as modular as possible, and you can include whatever you want. Developers will support what they know or need. Users can choose what they want and like. This mirrors the design of the Linux kernel itself, and I think it is a very good design policy to follow. Chris Arguin (chris.arguin(a)unh.edu) posted a suggestion for a source code tree. If I may be so bold to make some suggestions/changes: ui/ <- user-interface and UI extensions cli/ <- command-line interface fsm/ <- full-screen menu mouse/ <- mouse support (maybe?) gui/ <- GUI (if we get really bored :) drivers/ <- device drivers for boot and BIOS function support ide/ scsi/ <- how do we tie this in with SCSI cards that have their own INT13 BIOS? write our own drivers for the SCSI chipset? usb/ <- can USB support boot devices? net/ <- network cards (for BOOTP) init/ <- handles system initialization and the like boot/ <- OS boot stuff (standard MBR, Linux kernel, BOOTP) std/ <- standard BIOS call implementation (like good ole INT13) ext/ <- OpenBIOS extensions (dunno what they are yet, tho :) misc/ <- the ever-popular "other" category Comments, suggestions, flames, etc? -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 2

Re: [OpenBIOS] Licensing of the code.
by David Woodhouse 20 Feb '98

20 Feb '98

Dean Gaudet wrote: > > I think a big sticking point will be the license Intel requires for the > microcode update software. That license may dictate the license you'll > have to use for this project. In fact that license may even preclude a > free software project. > > Without the microcode updates you may have a hard time supporting intel > chips. What's the license? The procedure is documented in the "Pentium Pro Processor BIOS Writer's Guide" at ftp://ftp.intel.com/pub/IAL/p6/pppbios.pdf (Chapter 8) It's also available at http://www.sandpile.org/80x86/mcupdate.shtml I can see no mention of a restrictive license on the algorithms presented. Or did you mean the actual microcode update, as opposed to the code which loads it into the CPU? ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] serial console
by Dean Gaudet 20 Feb '98

20 Feb '98

On Thu, 19 Feb 1998, Benjamin Scott wrote: > Oh, I agree the need for a serial console in some for exists. But > consider: Such server farms are pretty much going to be running either > some flavor of Windows, some flavor of Unix, or Novell Netware. Windows > is out, as it *requires* GUI. Unix (Linux and BSD) should be able to > use a serial console without any sort of goofy video emulation > hardware. That leaves Netware as the only benificiary of such a > hardware-based product, and I can't say I see a big demand for it. :-) No, the linux serial console requires linux to be running. I want a serial console the most when the operating system *isn't* running. > I covered the software above. Do we actually know how much hardware > writes directly to video memory? I know of some stuff that uses BIOS > calls for the very reason of compatability; BIOS is guarenteed to be > there. If your SCSI card's (or whatever) BIOS is well-behaved, it isn't > a problem. Grab a buslogic or adaptec scsi card and watch them put up full screen menus from their bios. > While you can't respond *directly* to such activity, you could run a > timer loop that checks the video memory emulation region for changes > periodically and refreshes the VT screen every so often. Good old DOS > DOORWAY did something very like that. And you would only need to do > this if you have hardware that ignores BIOS and writes directly to > memory. It's trivial to map the display itself, yes. But what you can't do this way is react to vga register writes. There's nothing critical about using vga though, the card could emulate hercules. > Much cheaper, though. :) But doesn't solve the problem. It's not reliable, so you can't really trust it to pull you out of critical situations. > The RESET button works for me. :) Now, if you don't want to go over > and press the button on the system, then yes, things are more > difficult. Your serial-console card could include a remote way to reset > the machine. The BIOS alone can't do that. But I think it would be > cheaper to run a long length of twin-lead wire to the reset-switch > connector on the mainboard then design and manufacture a whole new > hardware product. :-) What if the system is 60? 100? 600? 1000? miles away from you? > Yes, Sun has many advantages over the PC. As does SGI, DEC, HP, and > the like. The primary advantage of the PC has always been *cost*. And > special hardware defeats that goal. :-) Not really. In truth you could do most of what I've suggested so far with a UART, and some lead that lets you trigger SMI. If you can get yourself into SMM then you don't need to have anything special on the card. Once in SMM the bios has complete control of the system... which leads to software solutions. That gets you remote console for reboots, and for unix once its booted. But it still doesn't get you support for scsi cards which do direct screen writes. Dean --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Licensing of the code.
by David Woodhouse 20 Feb '98

20 Feb '98

I said: >I believe that we could use the LGPL for this. dcinege(a)fuckthejunkmailers.org said: > The problem comes in if they have to directly modify any of our > libraries. Since this is so low-level it may be impossible to work > around them in some situations. Then let them produce their own copy of the offending module - they're going to be fairly small modules anyway, so it shouldn't be too much of a hardship. I appreciate that's not particularly ideal, but I suspect it might be the best we can do. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

3 4

Development environment, testing, sample code...
by David Woodhouse 20 Feb '98

20 Feb '98

I suggest that we use dev86 for our development environment. It includes a C compiler capable of generating both real mode and protected mode code, along with libraries for each and binutils, amongst other toys. Its output formats include Linux OMAGIC, ELKS, DOS .COM (small or tiny model), and - this is the important one - standalone code. It has libraries suitable for each target. It can be found at http://www.linux.org.uk/ELKS-Home/dev14.html I've also been investigating testing possibilities - Dosemu and Bochs seem to be the main contenders. Of these, Bochs does a more complete emulation of the hardware. So much so, in fact, that it can even run Win95 in an X window, albeit slowly. In general, the BIOS in Dosemu does callbacks into the Dosemu code, while the Bochs BIOS code actually tries to manipulate the hardware, letting the Bochs host code trap and emulate the actual IO accesses. This means that we'd be better off testing our BIOS code under Bochs. Bochs is available at http://world.std.com/~bochs Remember, though: > The general registration fee for BOCHS is $25 per workstation, PC, or > X-terminal, and should be paid by check in U.S. funds to: > > Kevin Lawton > Bochs Software Company > 528 Lexington St. > Waltham, MA 02154 Both Bochs and Dosemu have BIOS code which we can learn from, but can't copy. Bochs is commercial, and Dosemu GPL. Neither can be used if we intend to release OpenBIOS under LGPL. The interesting bits are: bochs-980124/bios/rombios.c and dosemu-0.97.3/src/base/bios/bios.S ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] comments and ideas
by David Woodhouse 20 Feb '98

20 Feb '98

dcinege(a)fuckthejunkmailers.org said: > Stephane Boyer wrote: > > we already have a 16bit bios! and they work well enough. if you dual-boot > > dos/Linux , fine stay with a 16bit bios, but if you only use Linux, > > wouldn't you want a bios that was specificaly made for it. > No. I have several linux servers here. Durign the rarity that they > reboot I could care less about the BIOS. > On my own workstation I have DOS, NT, 2 installs of OS/2, and Linux. > That's where I need the flexablity of a new BIOS (with boot loading > features, etc) Agreed. We should (IMnsHO) concentrate on getting the normal BIOS up and running before adding the esoteric new features - we want to change one thing at a time. Getting it to work at all is going to be complex enough, without changing the kernel boot procedure at the same time. Clean 32-bit boot functions are a reasonable goal, but we need the basics first, and we need to formulate a proper specification for the 32-bit interface before we even think about implementing it. Let's leave it till later, and try to design something that other OS's will consider using. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] comments and ideas
by Stephane Boyer 20 Feb '98

20 Feb '98

===================================================================== sboyer(a)smegheads.montreal.qc.ca Tel: (514)-457-6124 root(a)smegheads.montreal.qc.ca Stephane Boyer L I N U X 691 Surrey ------------------------------- Baie d'Urfe, Quebec the choice of a GNU generation. CANADA H9X-2E8 On Thu, 19 Feb 1998, Pavel Machek wrote: > Hi! > > > what is really needed, is a a true 32bit bios for people that single > > boot > > Linux. this bios should boot directly into protected mode (this way it can > > load uncompressed kernels). > > Why is it needed? Linux can live with current bioses. There's no need > for 32bios. Linux can do that things itself. What is needed is 16bit > bios. > we already have a 16bit bios! and they work well enough. if you dual-boot dos/Linux , fine stay with a 16bit bios, but if you only use Linux, wouldn't you want a bios that was specificaly made for it. Steph! --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] serial console
by Markus Kaufmann 19 Feb '98

19 Feb '98

Hi. At 04:29 19.02.98 -0800, Dean Gaudet wrote: >If you haven't done it before, try administrating a sun box over serial. >Enjoy the ability to halt and reboot the system, to upgrade the kernel >without fear, to even reinstall the system completely without being at the >physical console. There are many servers from Sun and HP (and others) where the serial port IS the console. When i got my HP server, i tried to connect my VGA screen to it, but i couldn't find the port. I looked closer and realized the small label at the serial port "COM1/console" . These HP servers (and workstations) are able to boot from harddisk, network, CDROM and tape (DAT). I don't know, if they are able to boot from floppy (probably not, since they haven't one). Bye Markus Kaufmann --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] serial console
by Dean Gaudet 19 Feb '98

19 Feb '98

On Thu, 19 Feb 1998, Benjamin Scott wrote: > Dean Gaudet wrote: > > The best idea I've ever heard for a serial console on a PC is an ISA video > > card that behaves like text-mode VGA only, > > While it would be a good idea, it has two problems: Cost and kludge. > Such a thing is going to cost a good amount of bucks, being so rare, and > it really is a kludge to support weirdness on IBM-PCs. rare? Every PC in use at any ISP that has any sense could use one of these. Consider the current situation -- in order to have a farm of machines you need to use expensive video/keyboard multiplexing devices or deal with the pain of switching cables all the time. Plus you have no remote administration of your machines -- telnet doesn't count, it's only useful when the system is in multiuser mode. > > Remember that ISA/PCI cards have bioses on them, and those bioses expect > > to play with a video card. > > I have seen a system boot headless (no video at all), but yes, most > software and some hardware expects to be able to play with video > memory. booting isn't what it's all about. What if during the boot your scsi card gave you a diagnostic? It'd sure be nice to see the diagnostic. > One solution is to just not use (or fix) such > hardware/software. Good luck. > Another is a software version of your above serial > console card. Hardware and software doesn't really want to talk to a > video card, just be able to write directly to video memory (and maybe > play with a couple of video registers). I am fairly sure we can create > a region of "video memory" from the BIOS for such stuff. We could then > either attempt to convert it to serial, or just ignore it, depending on > specific needs. The video registers I'm not sure about; can we hack > together an emulator for them using just BIOS code, or do we need actual > hardware? Won't work. Your VGA emulation needs to react to reads and writes. You "can't" do that -- ok I lie. If you build your system so that it goes into protected mode, and then do a v86 emulation to totally fake out the bios then you can do it. But you still won't be as solid as a hardware card. > > Plus you've got a more reliable method of generating an NMI/reboot which > > you'll absolutely need. > > Why? Without reboot control remote administration is useless. The serial ports on a PC have no way of generating an NMI (or an SMI), so you have no way of ensuring that the system is recoverable from a kernel failure. If you haven't done it before, try administrating a sun box over serial. Enjoy the ability to halt and reboot the system, to upgrade the kernel without fear, to even reinstall the system completely without being at the physical console. sun's serial ports and boot prom are designed to be able to control the system -- a break will send the equivalent of an NMI and bop you into the prom, from anywhere. PCs do not have this luxury. Granted there are probably some easy hardware hacks that would let you trigger an NMI (or better yet, an SMI) in response to a serial event. Dean --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

comments and ideas
by sboyer＠smegheads.montreal.qc.ca 19 Feb '98

19 Feb '98

Hi! first, i'd like to say that re-inventing a 'DOS' bios is a bad idea, what it does for DOS, it does well enough. what is really needed, is a a true 32bit bios for people that single boot Linux. this bios should boot directly into protected mode (this way it can load uncompressed kernels). it should be able to boot the kernel image from any IDE partition on any of the 4 disks (hda,hdb,hdc,hdd), or find the kernel on the IDE cdrom (to be able to boot directly into an install program from a linux distribution CD. and as a fallback, boot from the floppy. later versions could be made to boot from SCSI Disks. ZIPdisks, LS drive. this bios should have a setup utility, to setup things like date, time, boot order, timings, etc.. the kernel could be easily modified to support this bios, heck, make it a Makefile option (make lbios). we should keep this bios as simple as possible, a subset of the drivers allready used in the kernel distribution could be used, but not removed from the kernel, the ones in the bios would only be used for booting. this way the kernel would remain untouched (except for adding an option to the Makefile). if you really want to remake the DOS bios, go look at the bochs x86 emulator, it can boot dos from cpu's other than x86, so it must have it's own bios!!! (freebios?) Steph! -- ===================================================================== sboyer(a)smegheads.montreal.qc.ca Tel: (514)-457-6124 root(a)smegheads.montreal.qc.ca Stephane Boyer L I N U X 691 Surrey ------------------------------- Baie d'Urfe, Quebec the choice of a GNU generation. CANADA H9X-2E8 --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] serial console
by Benjamin Scott 19 Feb '98

19 Feb '98

Dean Gaudet wrote: > The best idea I've ever heard for a serial console on a PC is an ISA video > card that behaves like text-mode VGA only, While it would be a good idea, it has two problems: Cost and kludge. Such a thing is going to cost a good amount of bucks, being so rare, and it really is a kludge to support weirdness on IBM-PCs. > Even full screen stuff is possible: Reminds me of the old DOS DOORWAY program for BBSes. :) > Remember that ISA/PCI cards have bioses on them, and those bioses expect > to play with a video card. I have seen a system boot headless (no video at all), but yes, most software and some hardware expects to be able to play with video memory. One solution is to just not use (or fix) such hardware/software. Another is a software version of your above serial console card. Hardware and software doesn't really want to talk to a video card, just be able to write directly to video memory (and maybe play with a couple of video registers). I am fairly sure we can create a region of "video memory" from the BIOS for such stuff. We could then either attempt to convert it to serial, or just ignore it, depending on specific needs. The video registers I'm not sure about; can we hack together an emulator for them using just BIOS code, or do we need actual hardware? > Plus you've got a more reliable method of generating an NMI/reboot which > you'll absolutely need. Why? -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] BIOS Changes...
by Benjamin Scott 19 Feb '98

19 Feb '98

Jon Torrez wrote: > Would is be possible if there were a OS interface to the BIOS that was > able to change options in real-time; without having to reboot the > machine? I suggested this in my "initial" post; we should definately have an open standard for at least querry/set operations. More difficult is having such config changes take effect without rebooting. Linux doesn't really depend on the BIOS for much after boot anyway, so changing the BIOS config won't help Linux itself during operation. DOS might benifit, but it tends to keep just enough config info in memory to screw up things. Win95 might benifit, but I think you'd also need a way to communicate such changes to the device abstraction layer (if it is even possible, Win95 is pretty horrid for things like this). I won't even bother thinking about NT. -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] could we get better performance?
by David Woodhouse 19 Feb '98

19 Feb '98

johnl(a)meer.net said: > I'm curious what effect a given implementation of a BIOS has on system > performance. From what I understand (and I understand only a little > about the BIOS), DOS et al. use the BIOS functions much more than > Linux, which may just use them to boot and then leave the BIOS > functionality behind and use its own drivers. I suspect that the main performance increase would be under DOS and Windows, yes. Take a look at http://www.mrbios.com/proof.htm for an idea of what we're aiming at there. > Is performance affected more by the particular settings that the BIOS > can make (memory access, etc.) that would change performance? Under Linux, this will be the major factor - we can offer all the more esoteric settings that other BIOSes don't support, so we can eke a little more out of the beast here too. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Testing Platforms
by Chris Arguin 18 Feb '98

18 Feb '98

We should probably start paying attention to what chipsets we have, so that we don't have two people going off and implementing the same one twice. If you want, I can keep track of that list. With any luck, we will have a fair amount of variety of platforms to develop and test on. I've got a ASUS P55TP4N motherboard, which is a single Pentium MB with the Intel 430fx chipset. Currently it has an Award BIOS and a Symlogic SCSI BIOS. The Intel 430fx chipset is a 82437 System Controller, 82438 Data Paths, and a PIIX IDE+ISA interface. -- Chris Arguin | "...All we had were Zeros and Ones -- And Chris.Arguin(a)unh.edu | sometimes we didn't even have Ones." +--------------+ - Dilbert, by Scott Adams http://leonardo.sr.unh.edu/arguin/home.html | --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] BIOS call guides?
by Pavel Machek 18 Feb '98

18 Feb '98

Hi! > > > If I'm gonna start to think about coding, I have to know what to > > > code :) > > > > Do you want to write it in assembly or in C? How are you going to deal > > with 32 bit code? > > I'd suggest that the bios switches to protected mode in a very early > state. This would allow to develop most of the code (except the setup > code) in C, which is sure what we want (At least I think so) Hmm. But int xx interfaces *still* need to be in 16-bit assembly. Still, it might be nice to provide description "how to call this from 32-bit prot mode", i.e. specification saying: BIOS can be called iff CS contains selector with base = 0xf0000 ... > Do we want to support an Award compatible bios which has 16bit calls > or do we want to save up the space to implement newer features? You *must* have int xx calls, which are 16bit, or dos will not boot. -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

AMI BIOS execution order
by Chris Arguin 18 Feb '98

18 Feb '98

I ran across a web page that is supposedly a list of what some AMI BIOS does at startup. It seems to be fairly complete and may be useful to give us an idea of the normal order of execution. http://www.msi-computer.de/faq/A.HTM -- Chris Arguin | "...All we had were Zeros and Ones -- And Chris.Arguin(a)unh.edu | sometimes we didn't even have Ones." +--------------+ - Dilbert, by Scott Adams http://leonardo.sr.unh.edu/arguin/home.html | --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Re: Some Questions and ideas for gnu-bios
by John McPherson 18 Feb '98

18 Feb '98

-----Original Message----- From: Pavel Machek <pavel(a)elf.ucw.cz> Cc: openbios(a)linkscape.net Date: Wednesday, February 18, 1998 8:46 AM Subject: [OpenBIOS] Re: Some Questions and ideas for gnu-bios > >Under linux, bios is not used (well, with exceptions of APM). > >Other 'systems' switch into v86 mode to call bios functions. This goes into my major question. I would like to put the Linux kernel itself in the flash of one of my older fast 486 machines - I hope to make it a router, and I am having trouble with the hard drive in that box - if the kernel is in flash, and maybe most of a ramdisk load, all I need is a floppy with a few config options. Perhaps one could make use of the CMOS to store simple config items. If Linux doesn't use the BIOS at all, what initializations if any need to be done to the system at POST to assign PNP/PCI IRQ settings, test the memory, keyboard, etc. What _exactly_ does the BIOS do to a system when it starts? ---jmc --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

ANNOUNCE: OpenBIOS - Freeware x86 BIOS iniatitive
by Dave Cinege 18 Feb '98

18 Feb '98

Some discussion about the possibility of a freeware 'GNU' BIOS was casually mentioned on the Linux kernel mailing list last week. Talk about it escalated, and a mailing list was quickly formed. After a few more days of ideas, it seems like a very good possibility and some people just hell bent on getting started. What we are looking for now are people with a high degree of knowledge about the low-level workings of the x86 PC architecture, and real mode programming experience. Please join the mailing list and offer what help you can. Also understand that many Linux people are involved with this, but the purpose is a COMPLETE BIOS replacement for use with all Intel x86 OS's, not just some new boot loader. To subscribe to the OpenBIOS Mailing list, write an email To: openbios-request(a)linkscape.net Subject [leave blank!] subscribe [in the body] It is a majordomo managed list. Feel free to use extended MD commands as needed. OpenBIOS web pages: (DO NOT expect to find much here yet!) http://www.linkscape.net/openbios/ http://www.freiburg.linux.de/OpenBIOS/ --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] ASM/C and 16/32 bit questions.
by David Woodhouse 18 Feb '98

18 Feb '98

dcinege(a)fuckthejunkmailers.org said: > When I think 32-bit in the BIOS, to me that means being able to deal > with larger drives, and booting partitions with a huge sector offset. > (corrections please) Thank God for that - I was getting worried there! We want that kind of functionality, definitely. When I think 32-bit, that means "protected mode" - 32-bit code and data, rather than the old real mode 16-bit segment/offset methods. This would have meant that it wouldn't be compatible with legacy operating systems such as DOS and Windows 95 which run at least partly in real mode, using the real mode interrupts into the BIOS. (Unless we provided such 16-bit routines side-by-side with the 32-bit ones, effectively doubling the size of our function code) We can provide big drive support and other such niceties with real mode code - a normal BIOS generally has very little protected mode code AFAIK, although it is required to provide routines for copying data to/from high memory, and for switching into protected mode. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] ASM/C and 16/32 bit questions.
by David Woodhouse 18 Feb '98

18 Feb '98

madman(a)zip.com.au said: > This might be a really bad idea but let me know what you think anyway > :) How about doing a really low level boot loader of some sort so if > your booting linux it goes into 32bit protected mode early where as if > you boot dos or win it loads into 16-bit mode with all the int's that > are needed? I don't think we'd gain much from the 32-bit stuff. It'd mean that we have to provide both 16-bit and 32-bit versions of a number of functions, and who'd ever use the 32-bit API? Linux is always going to have to handle going into 32-bit mode itself, in case it's booted from a standard BIOS. We'd have to write a whole new Linux boot method to get it using the 32-bit BIOS API, and nobody else would ever use it. I think we should stick to pretending to be a normal BIOS for now. We can try adding extra stuff when it's working properly. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

ASM/C and 16/32 bit questions.
by David Woodhouse 18 Feb '98

18 Feb '98

We're going to have to provide a standard 16-bit BIOS interface if we want to support DOS and Windows users. There's not a lot of chance of making the BIOS go straight into 32-bit mode and stay there. We can still use C in 16-bit mode - take a look at the elks development utils, which are quite suitable for this task. I think we want to write most of it in C, with some critical sections in ASM - after http://dwmw2.robinson.cam.ac.uk/devload/ I really don't want to think about large projects written solely in assembly. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

5 4

Code Structure
by Chris Arguin 18 Feb '98

18 Feb '98

Partially to get people talking about what we should support, I would like to propose a possible code layout. A fairly simple method of sorting the source code that should be fairly extensible. memory/ <- how to setup cache, memory timing, etc... Bus/ PCI/ ISA/ AGP/ <- How to access and set up those buses USB/ etc... Drives/ <- for our purposes, anything that can boot Floppy/ IDE/ SCSI/ Interface/ <- The front-end Input/ <- Where do we get input from, and how Output/ <- Where do we send output, and how Common/ <- Whatever code that is common misc/ <- Anything else For example, my computer would be built with something like memory/Intel/82437FX Bus/PCI/Intel/82437X BUS/ISA/Intel/PIIX Drives/Floppy/Std_Floppy Drives/IDE/PIIX Drives/SCSI/NCR53c8xx Interface/Power_CLI Interface/Input/Keyboard Interface/Output/VGA_text misc/std_timer The Interface/Power_CLI would be something like the Sun-bootloader, or the Alpha console. Other possibilities would be a standard (like in most PCs), or maybe a PC96 compliant one, if that applies. Notice that you can easily change to a serial boot if desired, and I think this sort of division allows for quite a bit of flexibility. Configuration scripts can hide much of the actual details (for example, I would just select the Intel 430fx chipset, which would set up the Memory, PCI, ISA, and all that). Comments? -- Chris Arguin | "While I'm still confused and uncertain, it's on a Chris.Arguin(a)unh.edu | much higher plane... at least I know I'm bewildered | about the really fundamental and important facts of | the universe." - Equal Rites, Terry Pratchett --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] Licensing of the code.
by David Woodhouse 18 Feb '98

18 Feb '98

dcinege(a)fuckthejunkmailers.org said: > Haven't looked at BSD fully, but I understand it to be more along the > lines of a PD (free for all) type licence. For this type of project I > would not want to do work that Award could come by and just take it > for their own. I believe that a BSD license would allow them to do that - so we can't use BSD either. > I think a middle ground might be a licease that makes normal usage GPL > like but allows the OpenBIOS group (I guess that's what we are) to > sublicease it to companies for the purpose listed above. (I think the > XFree86 project did something like this) If we're going with the modular approach, with the final link being done at the last moment before the flash is blown, I believe that we could use the LGPL for this. I've just read through it again, and it seems to be precisely what we're after. We can declare all the OpenBIOS modules to be library routines, Then the binary-only modules provided by manufacturers are "work that uses the Library", and the only real restriction on them is that they have to allow for linking with newer versions of our generic modules. How does that sound? ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: Some Questions and ideas for gnu-bios
by Pavel Machek 18 Feb '98

18 Feb '98

Hi! > > Let me start by saying that I've never really investigated the BIOS > > before, so I may make some false assumptions below. Please point out the > > errors of my ways. > > Me too!! I've got a pretty good idea how things work, but do x86 asm. > I'm also unsure about some of the memory limitations, and what, if anything, does > the BIOS do once a protected mode OS starts. Under linux, bios is not used (well, with exceptions of APM). Other 'systems' switch into v86 mode to call bios functions. Pavel -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

4 3

Re: [OpenBIOS] Licensing of the code.
by Dave Cinege 17 Feb '98

17 Feb '98

David Woodhouse wrote: > > dcinege(a)fuckthejunkmailers.org said: > > When it comes to a manufature making changes to support a peice of > > hardware on their boards, this means they must release their changes. > > Fair enough. Is BSD the same? Haven't looked at BSD fully, but I understand it to be more along the lines of a PD (free for all) type licence. For this type of project I would not want to do work that Award could come by and just take it for their own. I think a middle ground might be a licease that makes normal usage GPL like but allows the OpenBIOS group (I guess that's what we are) to sublicease it to companies for the purpose listed above. (I think the XFree86 project did something like this) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Licensing of the code.
by Dave Cinege 17 Feb '98

17 Feb '98

David Woodhouse wrote: > > dcinege(a)fuckthejunkmailers.org said: > > I don't think BSD is good for this, and a straight GPL wouldn't > > really be the right thing either. > > Why so? It is not possible to distribute a BIOS in a completly libary type form.When it comes to a manufature making changes to support a peice of hardware on their boards, this means they must release their changes. If this code is a dependant on a peice of propritary or sub licensed peice of hardware they may not be able to (or just won't) use our BIOS. IF the finaly product is VERY modular and VERY flexable, then a regular GPL might not cause problems. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Licensing of the code.
by Dave Cinege 17 Feb '98

17 Feb '98

Stefan Reinauer wrote: > > Hi. > > > OpenBIOS would mean something else. OpenBIOS would mean that we > > publish our specs, not that we are free. Look at sparc OpenProm. > > > > BAD idea. > > I don't really see that. Look at OpenScape. That project was founded to > promote development of the free netscape source. Yes. Another reason I made the change is GNU is almost like a dirty word in the corporate world. I think all of our greatest dream is that this si successful and motherboard makers start to directly use it. This brings up another problem that we may as well get into now. Licensing. Early on we need to decide where that stands and the effects that it has for pontencial commercial outcome. I don't think BSD is good for this, and a straight GPL wouldn't really be the right thing either. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] OpenBIOS Homepage
by Dave Cinege 17 Feb '98

17 Feb '98

Stefan Reinauer wrote: > > Hi.. > > I've set up a preliminary OpenBIOS homepage today. It's available at > > http://www.freiburg.linux.de/OpenBIOS/ I just talked with Stefan. This will be the german mirror, of the master site below. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: gnu-bios or openbios?
by Pavel Machek 17 Feb '98

17 Feb '98

Hi! > I was just thinking about the name of this list (and I guess the name of the > forth coming project) > > Well a BIOS certainly isn't Unix, but I don't see how they are at all > related. > I think OpenBIOS is more appropreate and sounds a bit better as well. OpenBIOS would mean something else. OpenBIOS would mean that we publish our specs, not that we are free. Look at sparc OpenProm. BAD idea. Pavel -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] BIOS call guides?
by Pavel Machek 17 Feb '98

17 Feb '98

Hi! > Could somebody point me to where I could find a list of all the BIOS > calls? I know I've seen them before, but I am coming up blank now. Ralf Brown's Interrupt list? > If I'm gonna start to think about coding, I have to know what to > code :) Do you want to write it in assembly or in C? How are you going to deal with 32 bit code? -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: A Plan. (was Re: Some Questions and ideas for gnu-bios)
by Pavel Machek 17 Feb '98

17 Feb '98

Hi! > > I think we can assume pentiums at the least since only the pent > > m/b's and above really have flashable bois's. So why not go for a pent > > optimised compiler and maybe have someone check the asm producded <evil > > grin> > > personally, i think the gnu-bios should be done in 100% assembly, > for I do not think so. Well, it would be cleaner to write in assembly, but you do not want to write neither bios setup nor grub in anything else than C. And if you stick with gcc 2.7.2, compilers are ok. Pavel -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: A Plan. (was Re: Some Questions and ideas for gnu-bios)
by Pavel Machek 17 Feb '98

17 Feb '98

Hi! > > Right - that's enough of the theoretical waffle. What we need is a plan. Lots > > and lots of these projects have died out because people spent too long talking > > about them and did bugger all work. > > Well it's ony been a few days.... : > > > > I'd like to see a _really_ primitive skeleton BIOS up and running - just > > enough to boot Linux, with no chipset handling or anything. > > I was thinking about this. IMO if you put grub stage1 + 2 in the flash that > just may be enough. Hmm. I took a look at grub, and it is pretty ugly. I patched it quite a bit. -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

compiler speed
by Stefan Reinauer 02 Jan '04

02 Jan '04

Hi, I played a bit with different gcc versions on Alpha and I noticed that when executing the FIB test from http://home.iae.nl/users/mhx/fib.html in paflof, results are _a lot_ slower with gcc 3.1.1 than with 2.96 (SuSE 7.1 Alpha release) Not only is the 3.1.1 binary about 20% bigger, it also 22% slower. The test: HEX : FIB ( x -- y ) RECURSIVE DUP 2 > IF DUP 1- RECURSE SWAP 2- RECURSE + EXIT THEN DROP 1 ; 28 FIB BYE The results: gcc 2.96 binary real 1m55.642s user 1m55.479s sys 0m0.014s gcc 3.1.1 binary real 2m21.763s user 2m21.533s sys 0m0.027s Where does this come from? Is the code generated by gcc 3.x really that slow, compared to 2.96? Do we make some assumptions that might cause this? (How badly do gotos break code flow analysis for example?) What can we do against this? Having more prim words will speed up the whole thing, but probably not really make it easier for the compiler to optimize. Comments? Stefan.. -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 7

Jump to page: