LinuxBIOS Gains Steam 126
solferino writes: "LinuxJournal has a good overview article about linuxBIOS and where it's currently at (hint : moving like a sleek penguin under arctic ice). Why linuxBIOS? To quote from the article "Currently two different interest groups are working on LinuxBIOS: one working on embedded systems and one building large-scale computer clusters. For these applications the legacy x86 firmware is suboptimal." Yes, this was a slashdot story in March this year but this article is relevant for updating the project status and for providing indepth information."
Heroic bird (Score:5, Funny)
Re:Heroic bird (Score:1, Offtopic)
The other thing I can think of is that "under arctic ice" (or antarctic ice, as the case may be) would be a place where no one could tell, and I might say that if I had really no clue as to how the project was actually doing. I think that the submitter should really learn some new similes, because his current ones just aren't doing the job.
Re:Heroic bird (Score:2)
Their shape is very sleek indeed for cruising under water. Ever see those suckers in the zoo?
Re:Heroic bird (Score:2)
I suspect he's really one of those mythical cartoon pengiuns that wear hats and scarves and hang out with polar bears
Re:Heroic bird (Score:1)
arctic parsed better than antarctic (a clumsy word) and i just presumed you had penguins in the northern hemisphere as well
- later i thought to check, realised my error and knew i'd be picked up by the slashdot crowd straight away
more on-topic, here's [lanl.gov] a link to the linuxbios homepage
Re:Heroic bird (Score:2)
Not Boot to Windows (Score:3, Interesting)
If OpenSource has a project like this and the comptability is never included, I don't even want to think about what MS could retaliate with...
Re:Not Boot to Windows (Score:1)
BTW, what about BSD?
Re:Not Boot to Windows (Score:1)
For now, at least.
Re:Not Boot to Windows (Score:1, Informative)
The problem is most BIOS/mobo combinations, particularly the ones in laptops, have buggy or subset ACPI implementations that are just enough to work with Windows 95/98. Windows XP will have similar difficulties to Linux with those motherboards, which are unfortunately the large majority of laptops greater than 6 months old on the market, and most of the cheapest ones available today. In fact, come to think of it, certain laptops won't even work with version of w95/98 other than the particular, and very carefully patched and tuned, "mobile edition" they shipped with. Sony used to be the worst for this, don't know if that's still the situation.
Windows-only BIOS unlikely (Score:2)
Even the secure DRM computer mentioned here earlier is likely to limit authentication to authorized OS's (of which Windows is likely to be the only one using x86 hardware), rather than prohibiting unauthenticated OS's from running. Unless that law that requires OS's to be secure gets passed... That would be bad all over, though.
Re:Windows-only BIOS unlikely (Score:1)
Maybe I should start a new
What a sweet trojan, this Internet appliance disguised as a console. You get the market built, you come out with great games, then a keyboard, and start offering MSN to EcchsBox owners. Mix in some broadband, and away you go!
Re:Windows-only BIOS unlikely (Score:1)
Microsoft has said on many occasions that they have no plans to release a keyboard for the Xbox (you seem to have been mispelling throughout your whole comment, perhaps you should get spellcheck
Re:Windows-only BIOS unlikely (Score:3, Interesting)
Microsoft has also said at each release of Windows, that "this one is reeeeaaaaally stable now." I woulden't place too much faith in what they say, after all they are a corporate criminal in the eyes of the US justice system.
Re:Windows-only BIOS unlikely (Score:1)
after all they are a corporate criminal in the US justice system.
Hell how about 85% of the earth population.>
Re:Windows-only BIOS unlikely (Score:1)
Additionally, please follow included link to a place where your apparent regard for MS practices can do Mr. Softy the most good [usdoj.gov].
A groovy day to ya. 8^)
What LinuxBIOS is NOT (Score:5, Informative)
Nor is it that the BIOS is free software--there are other open source BIOS projects that can perform a DOS/Windows boot.
It isn't even that LinuxBIOS is suitable for embedded systems--other free BIOS's will support embedded systems and can perform a DOS/Windows boot.
In any case, there's nothing to stop someone writing a DOS/Windows boot loader and booting it from LinuxBIOS.
The point, surely, is that "LinuxBIOS generally weighs in under 64KB and doesn't waste ROM space with unnecessary functionality. Because it isn't a legacy design, LinuxBIOS starts up fast, even without code optimization."
It really just provides a nice slimmed down boot cycle suitable for embedded systems that do not require the PC BIOS baggage. We're not even talking about manufacturers dropping DOS/Windows compatibility, simply one or two equipment providers considering using LinuxBIOS in situations where compatibility is unnecessary and speed to boot is an important factor.
Re:What LinuxBIOS is NOT (Score:1)
Re:What LinuxBIOS is NOT (Score:1)
What sort of problems are you having? I have a 730 based system (basically the Athlon version of the 630) which works just fine in X.
Re:Not Boot to Windows (Score:2, Informative)
>this and the comptability is never
>included, I don't even want to think
>about what MS could retaliate with
This [geocities.com].
Re:Not Boot to Windows (Score:2)
Well that's good, because that's not the thinking behind the project as others have pointed out.
At the same time, don't get to comfortable with your head in the sand. M$ is already up to those kinds of tricks. Heard about the DRM OS? I'm sure it has a BIOS component to check the OS for complience. Less speculatively, I've got a motherboard that uses a Norton utility that identifies LILO as a boot sector virus. Very annoying but I can turn it off, for now. Also you should not forget all the work M$ has done to make things non standard and impossible to write drivers to: WinModems, the death of OpenGL, Sound board wierdness, and the list goes on and on.
Don't think of hardware with Open/Free standards as anti M$. Think of it as something that will simply work that M$ can use if they want. If M$ chooses to go their own way and keeps making things difficult for for their users, too bad. That's no reason to give in and have things difficult for yourself all the time.
Arctic Ice? (Score:2, Funny)
[quibble]Any penguin under arctic ice is seriously lost. Antarctic ice, certainly. The Falklands, and other land masses of the high southern latitudes, certainly. But not in the Arctic.[/quibble]
Re:Arctic Ice? (Score:2)
Re:Arctic Ice? (Score:1)
But I'm quite sure the real answer is somehing in the neighbourhood of
No - not the Ximian you dunce!
Re:Arctic Ice? (Score:1)
and the bios is for what, exactly? (Score:1, Interesting)
Typical, when they're not decrying Microsoft for embracing and extending, they themselves are embracing and debilitating.
Even Compaq, today's best known advanced technology destroyer, managed to make a *faithful* copy of the IBM PC BIOS.
Anyway, why an embedded device would want to use x86 hardware is beyond me...
Re:and the bios is for what, exactly? (Score:2, Interesting)
Re:and the bios is for what, exactly? (Score:5, Interesting)
Anyway, why an embedded device would want to use x86 hardware is beyond me...
because it's incredibly cheap maybe, with a mind boggling array of useful peripheral hardwares?
The aim of LinuxBIOS doesn't even remotely touch on some competitive manuevering as you ignorantly suggest.
Installing a LinuxBIOS ROM in place of normal DOS compatible microcode is something you do to modify I>commodity off the shelf hardware hardware to -for example- make your appliance system boot Linux to multiuser + network runlevel from a cold start in 3 seconds or less. It is a very specialized aftermarket improvement for hardware integrators - not motherboard OEMs or PC sellers- and has nothing whatever to do with the kinds of exclusionary practices Microsoft is famous for. It is not practical for general use PC system design, since kernel upgrades mean plugging in a new ROM or reprogramming the old one in a special ROM burner. It is for dedicated appliances only.
In short, Anonymous Coward, if you can't comment intelligently, and without smallminded paranoia, you may want to forgo commenting at all.
Re:and the bios is for what, exactly? (Score:2)
I don't think you read the article. Because the ROM is typically 256K, and the author could not squeeze a kernel down to that size, his code does not use a Linux kernel. Therefore, upgrading the kernel would have no impact on the code in the ROM. Second, there is no need to remove the ROM or use a "special burner". The article specifically mentions that the ROM is re-flashed in place, and onlyl removed if the flash fails.
And it is not just for appliances. The author states that his focus is on compute clusters. I see this as a logical technology for server farms and even managed workstations. I have worked on automating boot and install for servers, and the antiquated BIOS is always a stumbling block. It would be great to have firmware that works with you instead of against you. For example, as mentioned in the article, moving the console to serial and eliminating video hardware.
penguins? (Score:1)
Umm
Re:penguins? (Score:2)
dictionary.com:
arctic (ärk t k, är t k) adj. Extremely cold; frigid. See Synonyms at cold.
Re:penguins? (Score:1)
Afterall that was definition #2. Try definition #1
and a little etymology
[ME artik, fr. L arcticus,
fr. Gk arktikos, fr. arktos]bear, Ursa Major, north; akin to L ursus bear
often cap 1: of, characteristic of, or relating to the region around the
north pole to approximately 65^ N
BIOSes should not be operating system-specific. (Score:4, Insightful)
Its all about establishing the NEW monopoly. (Score:2)
They don't actually CARE about Open Source, just about establishing a NEW default standard *Linux.
When people talk about how *Linux just copied the UNIX API, want to copy the Windows API, or copy program X, you can add copy Microsoft's monopoly position via creating hardware that only runs one OS.
Re:BIOSes should not be operating system-specific. (Score:5, Interesting)
Most current BIOSes are extremely biased toward DOS and DOS-derivatives like windows 95 - they're pretty ill suited to even Windows 2000, I'm sure microsoft now would prefer them to be replaced too (but with something that still ties you to MS, of course - no doubt MS will be prodding at x86 BIOS manufacturers to get this).
At the same time, perhaps what's needed is a open standard for the provision of a wodge of on-mobo flash-ram - the main reason people want to replace the BIOS with linux, so that the OS loads in a blink of an eye, perhaps without even requiring a HD. It's just silly that the BIOS spends a good while screwing around in Real Mode when Linux (or newer versions of Windows!) just go back and do all the setup again...
I thik it's be REALLY nice to have an OpenFirmware-type BIOS on x86, but with a few megs of flash on the motherboard that one could load the OS kernel and perhaps an initrd from, instead of having to mess about with the harddrive.
Re:BIOSes should not be operating system-specific. (Score:3, Insightful)
Intel is pushing a new BIOS standard called EFI (Extensible Firmware Interface?); it's not really clear why they're not just using Open Firmware except maybe the conspiracy theory you mentioned.
Re:BIOSes should not be operating system-specific. (Score:3, Interesting)
OF's forth-bytecode intended to act as cross-platform on-card boot-time init and bare-bones device drivers and so on is replaced by in-rom snippets of "PE32+" 32/64-bit IA code, etc., etc.
It's well-defined support for reading boot-time image files from FAT filesystems, and net-booting, should make the boot process a lot less painful for Microsoft OSes, and a bit less painful for Linux - actually, I presume the Linux-Itanium project's already got this sorted.
It's certainly well-suited for integration with Microsoft OSes (certain aspects, like the Vendor Device Path look tailor-made for their end-to-end "DRM OS" recently mentioned on
All that said, I think one could, in theory, have a BIOS that was largely x86 EFI and Open Firmware compliant at the same time, if a designer really put his mind to it - one could probably write an EFI-compliant implementation in a mixture of forth and asm in the first place, and have it call legacy x86 PC ("PCI ROM type 0"), Open Firmware ("PCI ROM type 1") or EFI ("Proposed PCI ROM type 3") boot code segments on the PCI cards as it saw fit! The "Firmware Boot Manager" that EFI eventually drops into could be a full forth console, for all intel care, by my reading of the spec, and producing the EFI/ACPI device tree from the Open Firmware tree or vice-versa would just be a "simple" transform, I suppose.
I very, very much doubt anyone will bother doing this, though, unless Apple paid them a very large bung to encourage the proliferation of OpenFirmware-compliant devices...
So the fix is in already, as usual. Obviously, they've wheel-reinvented, presumably because OF is (was (afaik it's lapsed, like Scheme)) an IEEE standard they didn't control.
Re:BIOSes should not be operating system-specific. (Score:2)
If a card is to be used in the boot process, it needs to have initialization code and some sort of basic driver code on-board. Intel's continuing ability to define the direction of the computing market and thus maintain a ready market for its half-arsed "innovations" depends on lock-in. If that init/driver code becomes portable, then the hardware is instantly useful without and independent of the Intel architecture, and customers' barriers to mixing or even switching architectures drop as quickly as the load in Intel's skivvies. Vendors like Adaptec that can double or more the list price on a SCSI card just by replacing the x86 SCSI BIOS code with OpenFirmware code wouldn't be thrilled by such a move either.
Large bureaucracies exist primarily to perpetuate themselves, and the customer is only a means to this end. (It only takes a little bit of dot-connecting to conclude that capitalism serves only itself, just like 1984's Ingsoc and the Party, but that's another flame war for another time.)
-jhp
Re:BIOSes should not be operating system-specific. (Score:2)
Get to the correct boot drive by typing "fs0:". YUCK!
Re:BIOSes should not be operating system-specific. (Score:2)
Anyone remember the IBM PS/2 and it's ABIOS (protected mode BIOS)?
Re:BIOSes should not be operating system-specific. (Score:2)
Code talks, BS walks (Score:1)
The subject line says it all: Code talks; BS walks.
Re:BIOSes should not be operating system-specific. (Score:1)
Although the name may make you think otherwise, LinuxBios is a bios that will load any operating system. However, once that OS is booted, it won't provide extensive eighties-compatibility to allow a windows-like OS to continue booting. It provides just the bare minimum to get the OS up and running. Linux then quickly takes over.
Roger.
Re:BIOSes should not be operating system-specific. (Score:2, Informative)
This isn't meant for home use. If you'll notice the target audience it's embedded devices and large clusters.
I work on large beowulf clusters and there are many advantages to using a linux kernel to boot the machines, and none of them are the fact that you can't boot windows.
Linux boots faster and is able to tell you if something failed, and what it was, and can actually continue past some problems so you're not totally sunk if something dies. You can also redirect the output to a COM port, which is *great* for headless nodes. That way you can see that "oh, I had a stick of memory go out" without making the trip to the server room and pulling out the node and starting a whole troubleshooting series on it.
Not everything relevant to Linux is involved in the Linux/MS holy war. This is about optimizing clusters for speed and ease of management. The fact that windows isn't supported is a side effect of the technology, not an attack on "The Enemy". It's not that the BIOS intentionally prohibits you from using windows, it's that the BIOS *is* a linux kernel.
Re:BIOSes should not be operating system-specific. (Score:2)
I'd put it differently. The fact that Windows isn't supported is a side effect of the development path. Somebody may implement Dos-bios compatability into the Linux BIOS at a later date, but for people who want a box that can more easily and powerfully boot into Linux, it hasn't been a high enoug priority (yet).
Probably the quickest way to get DOS compatability put in would be to get a large-market wintel distributer interested in the idea. I can think of a few reasons why a general motherboard manufacturer might be interested in an open-source BIOS. Has anybody approached them with the idea?
Re:BIOSes should not be operating system-specific. (Score:3, Insightful)
Re:BIOSes should not be operating system-specific. (Score:5, Interesting)
The BIOS should be a generic facility that can load any desired operating system.
That is a desirable goal. Linux was chosen first because that was what the developer needed (meeting personal or professional need is the start of most Free software projects). Secondly, Windows is much more difficult since it is quite dependant on the legacy BIOS calls at startup while Linux is not.
The upshot is that if you can load the linux image into ram and jump to it, it will boot. With windows, you'd have to re-implement a good bit of the original BIOS.
Currently, LinuxBIOS just needs an ELF formatted binary image to load and execute. If you'd care to write a second stage that implements all of the necessary BIOS calls and boots Windows, feel free. There are a few people on the developer's list that would love to see that.
As a side note, it doesn't look like it would be all that hard to get *BSD or The HURD booting from LinuxBIOS.
Re:BIOSes should not be operating system-specific. (Score:3, Informative)
Just want to point out the differences in the BSD and Linux booting process.
Linux has a 16-bit slab of code that does all the BIOS calls in arch/i386/boot/setup.s. This code works out the memory requirements (does the E820 map), gets any paramaters about any hard disks, APM,etc. Some of the information it finds out may or may not be used. Then it does the protected mode setup (GDT, IDT, etc) and jumps into the protected mode code (head.S)
BSD on the otherhand pretty much is entered already in protected mode, and obtains this information by spawning a V86 (Virtual 8086 mode) task that performs any BIOS calls.
I'm not sure if that has any bearing on being able to boot from LinuxBIOS, just wanted to point it out.
Re:BIOSes should not be operating system-specific. (Score:2)
I'm not sure if that has any bearing on being able to boot from LinuxBIOS, just wanted to point it out.
It's good to know. For linux, it's fairly easy to just skip over the real mode stuff by using the protected mode entry point.
Presumably, for BSD, the part that makes the V86 calls for parameters could be replaced by a part that grabs the parameters from a 'well known location'.
Why does Windows use the BIOS so much? (Score:2)
It is true that anybody that makes a motherboard will test that it runs Windows, but that testing is not going to be very complete and there are many machines that are older than the newest versions of MicroSoft software. I can be pretty sure that if somebody loads WinXP on a machine and it fails, they will blame MicroSoft rather than the unusual BIOS chip in their machine.
So why is this?
Re:BIOSes should not be operating system-specific. (Score:1)
The instant DRM meets with a Disk-On-Chip that is spacious enough and cheap enough for OEMs, the BIOS will be gone before you can say "Hey! Why won't Linux boot on this new motherboard?!" Not that it won't be hackable (just buy a new DoC, if you can bypass the CPU's DRM support) but I strongly suspect Microsoft would like nothing better than to make it nearly impossible to dual-boot or install a new OS without special OEM tools.
Re:BIOSes should not be operating system-specific. (Score:2)
The biggest problem I could even forsee would be boards with an integrated RAID controller. The OEM updates contain the RAID bios updates and can wipe your RAID settings. Use RAID 1 and select rebuild, problem solved.
Since when should the BIOS not be optimized for the software?? The x86 BIOS has been the bitch of Windows ever since they started making plug-n-pray a part of it. ACPI was supposed to implement the "Instant On" feature in Win98. (Which still doesn't work in XP.)
The reality of it is that the BIOS should be flexible enough to be modified to run what you need. The open source nature of this BIOS may eventually provide a "royalty-free" product that doesn't force manufacturers to pay BIOS licensing. In addition, manufacturers also have the option of modifying the BIOS to do more than fix bugs.
Friends, there are more BIOSes out there than the x86, and everything doesn't "work like Windows". I can't friggin' stand this new generation of "geeks" who think the computer began and ended with Wintel. Same wackos who have never seen a board with jumpers, think VB is a kick-ass lang., and think the DOS prompt is what causes crackers to attack people. The x86 for the most part is a cheap kludge swimming in a sea of cruft.
The real question is this.... When will we get past 15 IRQ's??
~Hammy
"I write the mooky, my verse is Xtra spooky"
MR. Xcitement
nothing4sale.org
Re:BIOSes should not be operating system-specific. (Score:1, Informative)
Some higher-end Intel x86 single-processor motherboards also have APIC support, but it's not enabled usually, since most Windows versions fail to take advantage of it - however Linux 2.4.x will support APICs on both single and multiprocessor x86 systems, if you use the kernel config option "enable APIC on Uniprocessor systems". It doesn't usually do any harm to do so, since it will silently fall back to PIC IRQs if it doesn't find an APIC.
I presume AMD have similar APIC stuff for SMP Athlons, though I've never looked into it.
*APIC = "advanced programmable interrupt controller", as opposed to the cruddy, crappy 15-IRQ PIC (which is actually 2 even more ancient 7-IRQ PICs kludged together) that PCs have been stuck with since last century. These days, the APIC is actually on-die on SMP-capable Intel chips.
Re:BIOSes should not be operating system-specific. (Score:2)
Re:BIOSes should not be operating system-specific. (Score:2)
This BIOS is unlikely to be bundled with new motherboards; therefore it is unlikely to restrict anyone's choices. It is currently aimed at embedded devices and clusters. Anyone who sets up a large cluster of identical computers to crunch numbers probably doesn't mind being "locked in" to the family of OS for which the cluster is intended. And if they decide to repurpose the machines as general-purpose PC's (which is unlikely if they have no disk, floppy, cdrom or video, as the author intends) they can just re-flash the BIOS.
Given that writing this firmware is a pretty difficult project, I have no wish for the author to go out of his way to also support Windows.
Not generally useful.. (Score:3, Interesting)
For example I've got a 440LX motherboard with Adaptec SCSI built-in. The 440LX is not supported and there was absolutely no information about the SCSI. It seems like all the new motherboards include RAID controllers... I found no information about these either..
So for the markets they mentioned(embedded, and clusters), this is useful... but I don't see normal users needing this.
Re:Not generally useful.. (Score:2)
Looks like the supported Chipsets are quite limited. And I could find no information on their site about extra hardware that is typically included on the motherboard.
The list of supported chipsets is quite limited. That is a combination of there being more chipsets than time, and chipset vendors who refuse to release programming information without an NDA (impossable for a GPL project).
Reverse engineering is possable, but difficult.
One objective is to NOT support any extra hardware. The idea is to load Linux out of flash, and let it initialise and support the other hardware. That Linux kernel (and possably minimal filesystem) would then use kexec or monte to boot your final OS (probably another linux kernel).
Re:Not generally useful.. (Score:3, Insightful)
So with my board's original BIOS, the SCSI BIOS comes up after the regular BIOS. This allows configuring of the controller, each device, low-level disk formating, etc. So will the SCSI BIOS still be displayed on boot-up? If not, I would have lost alot of functionality by using the LinuxBIOS.
Re:Not generally useful.. (Score:2)
So will the SCSI BIOS still be displayed on boot-up? If not, I would have lost alot of functionality by using the LinuxBIOS.
It will not. The problem is that that BIOS extension expects to run in real mode with access to at least int 0x10 (and probably much more) which simply isn't there with LinuxBIOS.
Note that those config settings primarily affect the SCSI devices when accessed through int 13 in real mode. The Linux (or other) protected mode drivers will blow most of that configuration away anyway.
There are several tools in Linux that replace the functionality of the extension ROM.
I have used LinuxBIOS with SCSI, and never missed the SCSI BIOS (especially not when accessing from a serial console!!!
Nice troll... (Score:2)
Re:Not concept of design. (Score:1)
If you want to run a web server, then server software is strictly needed. You could enable it. Ditto for all those other services. There goes your argument...
Arctic Penguins? (Score:5, Funny)
Reminds me of my ? to RMS about a free BIOS (Score:5, Insightful)
He said it was a good question. His position on it is if it's flashable and programmable, source should be free.
He kind of dodged the question about whether or not his computer BIOS was flashable, free, whatever...
Don't get me wrong, unlike most people, I have a lot of respect for the guy and I don't believe for a second Linux or Open Source would be where it is today without the efforts of him and his team. It's just that there are always little contradictions that trip up even the best of zealots. Like, I wonder if his life is in danger, will he approve of being hooked up to a computer that provides life support but is running non-free software! :-)
Re:Reminds me of my ? to RMS about a free BIOS (Score:2)
There is no contradiction. The GNU developers have faced this problem before when they needed to run a proprietary UNIX (eg, Solaris/Sparc) in order to develop free software (eg, GCC). After much debate they decided that it's perfectly OK to use proprietary tools in order to create their free replacements. This is all documented on http://www.gnu.org/.
Re:Reminds me of my ? to RMS about a free BIOS (Score:3, Informative)
Karma Whoring: (Score:4, Informative)
The Linux Bios Homepage [lanl.gov]
Congratulations! (Score:1)
That's funnier than most (Score:5, Funny) I've seen.
Meanwhile, in the offices of Slashdot... (Score:2, Funny)
I can see it now... (delicate fade...)
CT: Gee, we're really getting hammered on these duplicate stories.
Timothy: Yeah, we should do a little more checking. Ah, here comes a submission now. Wow, this is cool! It's Linux! It's a BIOS! Post it, Taco!
CT: Hold on pardner, what did we just talk about?
Timothy: Alright, alright, hold on... aww gee, we posted this back in March! Darn it, this is just so cool, too! It's Linux, it's a BIOS, it's LinuxBIOS!
CT: Calm down, Timmy boy. I tell you what we'll do. We'll link to the original story, and justify this one by calling it an update, with new information.
Timothy: Can we really do that, Taco? That would be great!
CT: Sure. This way, we can't get flamed for re-posting an old story, you get to post a cool article, and all our readers can learn about what's new with LinuxBIOS. Everybody wins!
Timothy: Gosh Taco, you're the greatest.
CT: Just doin' my job, just doin' my job.
(Fade back to reality) And that's how this story was posted.
other OSs? (Score:2, Interesting)
Turn a PC into a real server....;-) (Score:1)
That looks very promising, connect to the box via serial on BIOS level, control BIOS settings from the runinng OS, this should turn a PC running Linux in a real server, no need for keyboard/graphic...:-)
No need for something like http://www.realweasel.com/, which has some other limitations.
Nuff said, fast to the download area....
Michael
What should be in the ROM (Score:5, Insightful)
2. A quick self-test to make sure that everything looks like it's basically working.
3. Offer the option of a more extensive self-test to provide some assurance that weird behavior is not a hardware problem.
4. Load a bootstrap loader from *any* I/O device on the board that might be practical. If the board has an Ethernet interface, it must be able to boot from that. If not, then perhaps from a serial port. This is for initial system installation. Normally you'd boot from the disc controller, of course.
5. Not require any equipment that's not permanently attached to the motherboard, i.e., if you don't know you've got a keyboard and a local video display, then use the Ethernet (preferably) or a serial port for operator control. Load the loader unattended if there's no operator present.
6. A remote reset sure would be nice if you could make sure you could keep it out of the hands of the jokers.
With all that and a 100Mbit Ethernet, the admin could reinstall the officially-approved software on the luser's workstation in a few minutes, without getting out of his own chair, and without having to walk the luser through any complicated procedure like finding the reset button and pressing it, let alone finding some special floppy or CD. And not just luser's workstations, servers, too. once the power and the Ethernet are plugged in you'd never have to turn the lights on in the server room again.
Re:What should be in the ROM (Score:2)
Haven't you heard of a lil thing called OpenBOOT? (Score:2, Interesting)
cfs
Re:Haven't you heard of a lil thing called OpenBOO (Score:1)
Realtime LinuxBIOS? (Score:2)
Anyone?
Re:Realtime LinuxBIOS? (Score:2)
LiloBIOS? (Score:1)
Is there any reason why they could not modify LILO (or GRUB, etc...) so that it could do the init stuff, and then load Linux/BSD/M$-NT?
If this is totally off-beam, that I should point out that all thought I'm a programmer, I've never studied PC raw hardware, so my knowlage of a PC boot process is basically
So I can't use this in my desktop? (Score:1)
New boot procedures are good (Score:1)
I wonder if we'll even invent a RAM-like thing that doesn't loose it's state on power off. Sort of like magnetic core memory but at modern RAM speeds. Oh well, I can dream...
Re:The logical conclusion (Score:1)
Re:The logical conclusion (Score:2)