OSDev.org

I read some sweet **** about this project; such as them finally moving the BIOS:bootloader interface forward.

This interface hasn't changed since WAAAAY back, but LinuxBIOS can supposedly let you write your bootloader in 32-bit ELF without any additional time on a proprietary BIOS.

I thought that idea was just HAWT, even for a "straight to 64" thinking guy like myself; and it DEFINITELY blows Grub out of the water.

So... anyone hear anything about that?

I do not like it, it seem to replace the BIOS with no BIOS, so now the OS has to do all the work, that was done by the BIOS.
Wow that must be a hard project, to code for.

I think less people would want to try your OS if they needed to reflash their BIOS just to get it to boot. There's also the fact a majority of people will be using an unsupported board.

Indeed. I've read a great deal about the project's current status. It claims to have two flagship boards at the moment, neither of which works completely even simply by flashing the BIOS. All the other boards are screwy.

What I can say, is that should an OS opt to implement a BIOS component as well, the instructions to flash the bios are not very complicated. The important thing however, is that the user be aware of it's happening, that it means the system cannot run *anything else* as it breaks the BIOS:boot interface, and that if the flash fails, their mobo is bricked.

The upside is that a BIOS booted system that worked 100% on even one board with the latest would be the only system I'd want. The system can go from the time you push the button to running a GUI in about 3 seconds flat and from a security standpoint, is unparalleled.

In fact, a modified one of these is the only platform from which I'd be *willing* to boot my OS; because it's the truly first entry point into programmable code. I've been designing this thing for security using strategies that make OpenBSD look like Outlook. No sense in wasting it on BIOS malware.

Avarok wrote:What I can say, is that should an OS opt to implement a BIOS component as well, the instructions to flash the bios are not very complicated.

Imagine the uproar from the public when the latest version of Windows requires you to use their BIOS which won't allow any unsafe or unverified code to run. You know Microsoft will just be dieing to implement Singularity at a BIOS level.

Then you'd have to write everything in Visual C++/C# and to run unverified code you'll have to register for a Creators Club subscription which is $99 a year.

EDIT: I changed Syllable->Singularity. Now I feel like a fool

MessiahAndrw wrote:You know Microsoft will just be dieing to implement Syllable at a BIOS level.

Off topic, and I don't mean to nitpick, but I've seen a couple of times Syllable mentioned in the forums when I guess you mean Singularity (Syllable is an entirely different project, and not from Microsoft).

More on topic: I think LinuxBIOS is nifty, but it's not going to be successful without some support from major vendors. I see the BIOS as the "glue" between the software & the hardware, making many different pieces of hardware (different motherboards, chipsets) act the same way. If the BIOS starts being flashed with a replacement that do exactly what every other BIOS does, then OS development would be a real mess because you'd have to target a specific BIOS implementation.

Plus, whilst Linux is a nice kernel & I consider 'Linux' (used loosely) the operating system to be the best currently available (although far from perfect), I just don't see any benefit it could provide by running as the BIOS, which is largely ignored once the OS has loaded anyway.

Hi,

Imagine someone building a new town hall. They put a big advert in the local paper telling everyone about it and asking interested volunteers to come and help. Lots of people think it's a good idea and decide to help, but when they get there there's no plans or anything. Instead everyone just grabs hand-fulls of mud and straw and throws it at the building site hoping that it lands in a "good" place, and occasionally they scrape away some of the dried mud that looks like it might be in the wrong place. Eventually (after many years of hard work) they finish, and they all stand back and say how wonderful the new statue of an elephant is. Of couse by this time they forgot they were meant to be building a town hall...

This sounds insane, but it's also the same development model used by LinuxBIOS.

I've had code to boot my OS directly from ROM on Bochs for years. The idea is that (eventually) embedded system designers would be able to write their own "ROM boot loader" for their chipset using my "Bochs ROM boot loader" as a starting point. Several months ago I looked into LinuxBIOS, hoping that it was (or would become) a viable alternative - something that would (eventually) allow embedded system designers to take my OS, LinuxBIOS and an "off-the-shelf" chipset and throw them together.

The hype sounded good, it looked like the project was on the way to becoming something useful, and at the time there was talk of support from hardware manufacturers (there actually was (still is?) code copyrighted by AMD in their source code).

LinuxBIOS boots an ELF file called "the payload". The payload could be a monolithic kernel, an "OS specific" boot loader,, a generic boot loader, a compatibility layer or anything else. I think the orginal idea was to use a Linux kernel as the payload, but someone forgot to compare the size of the Linux kernel to the size of the flash ROM (the Linux kernel is too big and doesn't fit - "oops"). There was (is?) plans to port GRUB to LinuxBIOS, but I think that idea died when they realised how much of the normal BIOS GRUB uses.

For compatability layers, there's ADLO (a "PC BIOS" compatability layer), which never made sense to me (if you want a "PC BIOS" simply don't install LinuxBIOS to begin with). Some people are working on an OpenFirmware payload (which has it's own problems, as unlike other platforms there never was any specifications for OpenFirmware on 80x86).

Anyway, I decided to write my own LinuxBIOS payload to boot my OS. Being (IMHO) a sane person the first thing I did was ask where to find the specification for the hand-off/interface between LinuxBIOS and the payload. There wasn't any. There was a few scraps of information about the "LinuxBIOS tables" (mostly it's format), but nothing that actually explained what each field in these tables is used for. After many questions on their mailing list, and after a few attempts at trying to get them to understand that looking at the source code is almost worthless (it tells you nothing about what may/may not happen in future or which values may/may not be valid for different things) I found out that they're dumping "version 2" and shifting to "version 3".

Of course "version 3" uses different "LinuxBIOS tables", also has no specifications and there was very little source code to reverse engineer specifications from. Being (IMHO) a sane person, I gave up and modified my own "ROM boot loader" code to make it easier for embedded system designers to customize it for their own uses.


Cheers,

Brendan

I probably should just keep my mouth closed as this will sound really stupid, but anyway here goes...

When i first started getting an interest in OS Developement, (NB. i still havent got nether the knowlede nor the skills) the first thing that popped into my head was writing a customized BIOS, a BIOS that would work in a way that i would find suitable, a BIOS that would only contain the ints, ops and stuff that i would need and finaly would contain contain the most essential parts of my OS.
Forst thing i found out is that BIOS programing is hard! Second thing is that mobos, cpus, io devices, is very different from each other it seems.

I still believe that this is the right way to go, but it will certainly not be me doing it.

I think if OS's started using their own BIOSes then it'd be hard to multi-boot because they'd only be designed to boot their OS. Then we'd see a BIOS chain-loader (like GRUB for BIOSes) where you can pick which BIOS you would like to load on boot up.

better yet, MAKE grub into a bios, with VGA h4x of course. Nothing like an animated Tux on bootup.

Heh... no offense...

Tux on boot up is the about the second last thing I want. The last being the Company-Named-After-Its-Founders-Organ logo.

What I want from the BIOS is open source, silent, black screen, reliable setup of the core hardware, the LAPIC, A20, Identity Mapped Paging, and x86-64 Long Mode. It should then load the first 64k off the boot-able disk into 0x0010_0000 and jump there.

That would be my idea of a perfect BIOS.
I'll take it from there.

OrOS wrote:better yet, MAKE grub into a bios, with VGA h4x of course. Nothing like an animated Tux on bootup.

Grub users the BIOS, so would need a rewrite.

Avarok wrote: What I want from the BIOS is open source, silent, black screen, reliable setup of the core hardware, the LAPIC, A20, Identity Mapped Paging, and x86-64 Long Mode. It should then load the first 64k off the boot-able disk into 0x0010_0000 and jump there.

That would be my idea of a perfect BIOS.
I'll take it from there.

That would be easy to do.

I do a lot of ARM coding and with them, it simple loads 4k from nand to ram and jmps to it. Your bootloader needs to do all the work of what a BIOS does on a x86.
So its much harder code a boot loader for ARM than a x86.