March 1998 - OpenBIOS - mail.coreboot.org

Re: [OpenBIOS] Project split. (Let's get working)
by Pavel Machek March 3, 1998

March 3, 1998

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 March 2, 1998

March 2, 1998

> > 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 March 2, 1998

March 2, 1998

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 March 1, 1998

March 1, 1998

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 March 1, 1998

March 1, 1998

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 March 1, 1998

March 1, 1998

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 March 1, 1998

March 1, 1998

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 March 1, 1998

March 1, 1998

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 March 1, 1998

March 1, 1998

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 March 1, 1998

March 1, 1998

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