CoreBoot (LinuxBIOS) Can Boot Windows 7 Beta 207
billybob2 writes "CoreBoot (formerly LinuxBIOS), the free and open source BIOS replacement, can now boot Windows 7 Beta. Videos and screenshots of this demonstration, which was performed on an ASUS M2V-MX SE motherboard equipped with a 2GHz AMD Sempron CPU, can be viewed on the CoreBoot website. AMD engineers have also been submitting code to allow CoreBoot to run on the company's latest chipsets, such as the RS690 and 780G."
Re:What Benefit Does C Have Over Assembly? (Score:1, Informative)
One word: agnostic. It becomes agnostic in C as opposed to ASM.
Re:What Benefit Does C Have Over Assembly? (Score:5, Informative)
Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C?
Short answer: no.
Long answer: rarely. Optimizing compilers are so good these days that very few humans would be capable of writing better assembler, and I contend that no humans are capable of maintaining and updating such highly-tuned code.
Embedded assembler makes a lot of sense when you're embedding small snippets inside inner loops of computationally expensive function. Outside that one specific case (and disregarding embedded development on tiny systems), there's not much need to mess with it. Note that need is not the same as reason. Learning assembler is good and valuable on its own, even if there are few practical applications for it. If nothing else, it'll cause you to write better C.
Re:What Benefit Does C Have Over Assembly? (Score:5, Informative)
Easier to maintain, more portable accross platforms, easier to do more complex stuff, easier to integrate/reuse existing librairies/code, etc.... ?
Re:first post (Score:0, Informative)
Idiot! It should be "One small post for a troll."
The original misquote only worked because of the double meaning for man. Stupid troll.
Re:What Benefit Does C Have Over Assembly? (Score:5, Informative)
Turns out that the amount of bugs in a given amount of lines of code is fairly constant, regardless of language. Thus, it takes fewer lines in C code = fewer bugs.
Also, it is extremely rare that the compiler cannot emit more optimal code than what is hand-written - compilers are extremely good at optimizing these days. The more common trend is to provide hints & use intrinsics so that you get all the benefits of writing in C code (type checking, more readable code), but the compiler is better able to generate the assembly you want.
You will almost never write better assembly than what the compiler outputs - remember, the compiler takes a "whole program" approach in that it makes optimizations across a larger section of code so that everything is fast. It is highly unlikely that you will be able to match this - your micro-optimization is more likely to slow things down.
There is actually very little in the Linux kernel that is written in assembly (relatively compared to the amount of C code) - the only time it is, is because it is the only way of doing it to support multiple architectures, not performance. For performance, by far, the kernel code is written in C and relies on working with the compiler people to make sure that the code is optimal.
Re:Help! I'm conflicted! (Score:5, Informative)
Also, ATI has open source 2D drivers and just yesterday released specs that should allow for good open source 3D drivers. Sometime in the next 6 months, their graphics cards should support OpenCL, too. ATI is the way to go for open hardware support at the moment.
Re:What Benefit Does C Have Over Assembly? (Score:5, Informative)
It's easier to write structured programs in C than assembly.
Well, it's much easier to write anything in C than assembly, but assembly lends itself to small pieces of self-contained code that do one thing only.
The idea is that assembly is only used where is needs to be, because you have to do something that you can't do in C, such as fiddling around with the CPU's internal state. The rest is written as a collection of modules in C. To build a BIOS for a particular board, you just link the required modules together.
That suggests the question "why not write the BIOS in C++, or Java, or whatever". Anything higher-level than C tends to require more complex runtime environments (which are usually written in C), while C requires nothing more than assembly. It's the highest level language commonly available that can run with absolutely no OS support at all.
Re:What Benefit Does C Have Over Assembly? (Score:3, Informative)
Only very small sections of Coreboot are specific to a particular architecture. The rest can be reused without modifying source code.
Open cores (Score:3, Informative)
Excuse my ignorance but is it already possible to have a fully working computer that doesn't perform a single unknown operation?
Possible? Yes. Feasible for an enthusiast? Not in the first quarter of 2009. Intel and AMD CPUs contain secret microcode. There exist Free CPU cores such as the MIPS-compatible Plasma [opencores.org], but as far as I know, none are commercially fabricated in significant quantities.
Re:EFI? (Score:5, Informative)
EFI is useful in the same way Open Firmware on PowerPC and Sparc is useful. It gives you an extensable system that can do different things with devices. This is great on a system where you don't know what the hardware may be (i.e. Workstations).. but starts to fall down when you get to servers, blades or embedded systems.
On most systems these days BIOS or any type takes between 3 and 30 seconds to boot to the OS. This is simply not acceptable to many blade and embedded system designs.. (Even some server designs this isn't acceptable.)
I can boot a system with coreboot in a second or less to the OS. This is really the most important part of coreboot. (For embedded systems, most of the time our target is in the .2 to .5 range from power on to OS start... this almost all but excludes ia32 from many embedded applications today.)
Re:Help! I'm conflicted! (Score:3, Informative)
ATI's binary drivers actually work, too. They had problems in the past, but I've recently bought a new card from ATI to replace my Nvidia card and I can say easily that they both work very well with the binary drivers.
That's beside the point, though. We're talking about open drivers.
Re:What Benefit Does C Have Over Assembly? (Score:5, Informative)
Writing in 'C' is an order of magnitude faster than writing in assembler; if you're building a system with 10 man-years of coding in it, that becomes really, really important.
Imagine writing a host-side USB stack in assembler; a BIOS has to have that. Or writing an Ethernet driver and TCP/IP stack in assembler. Or any of the other large subsystems of a BIOS; the task would be daunting to me, a 20 year veteran of embedded systems (yes, my 'C' and Assembly mojo is strong).
Assembler has proven its worth when sprinkled through embedded systems. When profiling finds the routines that are bottlenecks for time-critical functions, a good assembly programmer can often speed up the 'C' code by a factor of 2 to 10. But, this generally involves very small chunks of code - 10 to 50 lines of assembly.
In most real systems, the vast majority of the code is executed rarely, and rarely has a performance impact. For example, on a modern dual-core, 2 GHz processor with a GB of RAM, the code used to the display the BIOS setup UI and handle user input will execute faster than human percepption in almost any language you could imagine (say, a PERL interpreter written in VB which generates interpreted LISP). There is no reason in the world to try to optimize performance here. Even in things like Disk I/O, the BIOS' job is mostly to boot the OS, then get the hell out of the way.
Re:EFI? (Score:5, Informative)
EFI allows lightning-fast boot.
First, you can put your kernel in EFI (if there's enough flash) and boot it directly from there.
Second, EFI itself is pretty much efficient - you have access to lots of RAM, CPU works in protected mode, etc.
It's quite possible to have 1 second until kernel startup with EFI. Almost like on my 166Mhz MIPS board :)
You forgot one thing (Score:2, Informative)
Specialized instructions (MMX, SSE, etc) can provide substantial speed boosts with certain code. Unfortunately no C compiler really takes full advantage of those features (if at all) despite them being widely available nowadays.
So in those cases it may be a whole lot faster to use assembly. Usually this is just embedded within a C function because of the specialized nature.
Re:Changes (Score:2, Informative)
What is Linux BIOS?
We are working on making Linux our BIOS. In other words, we plan to replace the BIOS in NVRAM on our Rockhopper cluster with a Linux image, and instead of running the BIOS on startup we'll run Linux. We have a number of reasons for doing this, among them: ... [LinuxBIOS.org, Aug. 2000 [archive.org], at the bottom of the page]
You're wrong.
Re:Yay! Let's trade speed for dumb. (Score:5, Informative)
Re:Hence, One line Perl scripts (Score:2, Informative)
... every program could then be further reduced to the single empty program, which would still contain at least one bug.
Which in turn means that all programs are the same, thus - assuming deterministic execution - all exhibit the same behaviour.
Or in other words: Linux is Windows.
Re:Hence, One line Perl scripts (Score:1, Informative)
any program could be reduced to a single line of code with a bug Doesn't that encompass like 95% of perl programs?
Re:This is awesome (Score:4, Informative)
Each time I do a Coreboot/LinuxBIOS announcement on Freshmeat, I usually add a whole bunch of chipsets and a fair dollop of motherboards. I don't, as a rule, state the level of completeness, simply because there's barely enough space to list just the components.
Having said that, assume the web page is out-of-date when it comes to fully-supported motherboards. I know for a fact that I've seen a lot more motherboards get listed as complete in the changelog than are listed on the website, even though I started tracking those changes relatively recently and they'd plenty of mobos complete even then.
One of the important things to remember about LinuxBIOS/Coreboot (the new name doesn't have the same ring to it, for me) is that it's a highly modular bootstrap, so it has a high probability of working on just about anything, so long as the components you need are listed and ready. I feel certain that a few good QA guys with a bit of backing from mobo suppliers could pre-qualify a huge number of possible configurations. The developers, as with most projects, don't have time to validate, debug and extend, and their choice has (wisely) been to put a lot of emphasis on the debugging and extending.
Of course, Coreboot isn't even the only player in the game. OpenBIOS is out there. That project is evolving a lot more slowly, and seems to have suffered bit-rot on the Forth engine, but that's a damn good piece of code and it deserves much more attention than it is getting.
Intel also Open Sourced the Tiano BIOS code, but as far as I know, the sum total of interest in that has been zero. I've not seen a single Open Source project use it, I don't recall seeing Intel ever release a patch for it. That's a pity, as there's a lot of interesting code there with a lot of interesting ideas. I'd like to see something done with that code, or at the very least an assessment of what is there.