OpenBIOS

openbios@openbios.org

4297 discussions

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 01 Mar '98

01 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

Jump to page: