OpenBIOS

openbios@openbios.org

1 participants
4280 discussions

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

Jump to page: