OpenBIOS

openbios@openbios.org

4297 discussions

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 28 Feb '98

28 Feb '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 28 Feb '98

28 Feb '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 28 Feb '98

28 Feb '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 28 Feb '98

28 Feb '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 27 Feb '98

27 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

Jump to page: