Please create an account to participate in the Slashdot moderation system


Forgot your password?
Hardware Hacking Windows Build Linux

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."
This discussion has been archived. No new comments can be posted.

CoreBoot (LinuxBIOS) Can Boot Windows 7 Beta

Comments Filter:
  • This is awesome (Score:4, Insightful)

    by kcbanner ( 929309 ) on Tuesday January 27, 2009 @11:48AM (#26623113) Homepage Journal
    I'd really like to see the buggy vendor bioses get the boot and be replaced by this. The BIOS on my motherboard has all sorts of quirks, like missing one stick of my ram during detection randomly, to really laggy page switches. Windows support is what CoreBoot needs to get accepted.
  • Re:This is awesome (Score:4, Insightful)

    by richlv ( 778496 ) on Tuesday January 27, 2009 @11:54AM (#26623215)

    some fully supported desktop mobos is what coreboot needs ;)
    if a mobo was fully supported, that would be a huge plus when i'd choose.
    we've seen a lot of issues where even if a bios isn't massively buggy by itself, future development of hardware leaves a lot to be desired, but vendor has dropped any support. this includes servers by ibm, hp, desktop boards...
    problems have been various during the years (and i really mean only the problems that can be fixed in bios) - larger disk drive support, larger memory support, proper booting from hdd (for example, ibm netfinity 5000 stops booting when an ide drive is attached), proper booting from all cdroms, usb booting...
    so, amd, if your products will be fully supported by - or even shipped with - coreboot before everybody else, it is very likely that my future purchases will go to you :)

  • Re:This is awesome (Score:3, Insightful)

    by hedwards ( 940851 ) on Tuesday January 27, 2009 @11:55AM (#26623239)

    Well, there's two issues there. One is that Vendors haven't cared a lot about getting it right, and two that the BIOS itself as a specification is pretty limited.

    Replacing the BIOS with EFI or something more up to date and extensible could potentially solve the second problem.

    But, ultimately vendors are lazy and tend not to bother doing it right. More often than not they just use a stock BIOS which is itself buggy. Really it's probably the BIOS manufacturers that ought to be taken to task for screwing it up.

  • by sprag ( 38460 ) on Tuesday January 27, 2009 @12:02PM (#26623389)

    Being in C, it is easier to see what the person writing it was doing, compared to assembly.

    Consider if you had to do some nasty computation such as finding what address is used for a given row and column on the screen:
    (in bad assembly)

    mov ax, row
    mov bx, col
    shl col,#1
    xor dx,dx
    mul ax,#80
    add ax,bx
    mov pos,ax

    Whereas in C it is:


    and much more readable.

  • by richlv ( 778496 ) on Tuesday January 27, 2009 @12:05PM (#26623459)

    as coreboot targets many bioses and platforms, i'd expect portability to become so much more important.
    btw, i found an interview with coreboot developer at []. from there :

    "The real accomplishment was to be able to write memory and other early initialization code in C. Which is much easier to write and maintain then assembler. Assembly code is fragile when you change it, especially when you don't have a stack. C is much more robust â" the code is easier to change without breaking everything. This makes coreboot easier to work on, to contribute to and to maintain."

  • by Giant Electronic Bra ( 1229876 ) on Tuesday January 27, 2009 @12:06PM (#26623467)

    There may be SOME architecture specific code, even a lot of that can probably be written in C. 99% of the Linux kernel is C and that has to interact with hardware too.

    As far as efficiency goes, in the old days it was true that a coder with an intimate knowledge of the architecture could usually hand code more efficient assembly. Modern C compilers however can do a LOT of optimization and generally the resulting code is faster than anything that could be coded by hand, or at least AS fast. Even if it is microscopically slower it is still a LOT easier to use C. Plus if hardware abstraction is done properly even a low level driver back end should be portable for the most part.

    Manufacturer BIOS may be written in Assembly since they are A) targeting a specific board which is going to obviously only run that one family of chip and B) probably have a lot of legacy assembly code they would rather not bother to port to C. Neither of those would apply to Coreboot.

  • by KasperMeerts ( 1305097 ) on Tuesday January 27, 2009 @12:08PM (#26623521)
    What's more important to you? OSS graphics drivers or OSS BIOS? And by the way, if you need a decent graphics card, you're gonna need ATI or nVidia anyways, Intel doesn't make really high performance cards.
  • Congrats (Score:1, Insightful)

    by Anonymous Coward on Tuesday January 27, 2009 @12:22PM (#26623767)

    Congrats to the team.

    At first you think no big deal, then you realize they are making their own bios, something most of us would fear trying. Congrats for doing something difficult, well.

  • by Anonymous Coward on Tuesday January 27, 2009 @12:32PM (#26623929)

    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.

    Actually, in my experience it's more about the modern CPU than the modern compiler. If you look at the output from modern compilers, there's some truly awful code in there. gcc can be particularly awful (Intel and MSVC appear to be substantially better).

    But tricks like hand-reordering matter little when you've got a superscalar CPU with a 20-instruction reorder window.

    I suspect it would be a lot more obvious on platforms like the Atom or the consoles, which are all using in-order cores.

    That doesn't mean that the technology doesn't exist to make the compilers better, but if it does, nobody's bothering because it isn't making a difference (on most x86, at least).

  • by moteyalpha ( 1228680 ) * on Tuesday January 27, 2009 @12:35PM (#26623977) Homepage Journal

    Those should have been multiplies by 160 instead of 80.

    I would have thought that immediately ( 160 ) since I did so much assembly with CGA, however I may be even older and some of the displays were 40 characters wide, so 80 would be correct for that. On the issues of coreboot, that is fantastic and I want it for my machine now. I want instant boot to linux and ext4 for my next upgrade. On the other issue of _asm_ as faster, I bet I could make some of it faster, but gcc is way good anymore and I often objdump my "c" code to look at the assembly and the people who write the compiler are virtually magicians with that code. I have tried competing with the compiler and it is a waste of time for most things and unless I was doing firmware or a device driver, I wouldn't even consider assembly. As far as the code, the one thing I wouldn't do is a "mul" just for the cycle cost, I would combine shifts and adds to get (16x+64x).

  • by salimma ( 115327 ) on Tuesday January 27, 2009 @12:43PM (#26624103) Homepage Journal

    Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C?

    For a piece of software that gets run once per boot, speed is probably not very critical. A typical BIOS completes its run in a couple of seconds.

    Using an optimizing C compiler also has a further potential benefit -- given that motherboards specifically target certain CPUs, you can optimize the BIOS code for that CPU family. Not sure how much improvement this will yield, though.

  • by Hordeking ( 1237940 ) on Tuesday January 27, 2009 @01:04PM (#26624493)

    My best guess is there are parts of a BIOS that are tied to the hardware architecture, and there are parts that aren't.

    For instance, what if you want to write a BIOS that can read an EXT3 partition?

    Actually, a BIOS that can read EXT would be kickass. My bios can only read FAT12 (and maybe FAT32 for a hdd) off the floppy. If I wanted EXT3 (or 2), I'd have to put that stuff in the "kernel" that gets loaded by the boot sector. That kernel, however is on a FAT12 partition =P As for TCP/IP, that would be nice to allow diskless boots. PXE anyone?

  • by mpapet ( 761907 ) on Tuesday January 27, 2009 @01:29PM (#26625019) Homepage

    It deserves praise and support previously reserved for deities. I'm only overstating this a little.

    The benefits of CoreBoot are many:
    1. Cheaper motherboard manufacturing. TPM chips are expensive components when mass producing motherboards.

    2. CoreBoot gives hardware manufacturers a viable market that Microsoft and Apple cannot touch.

    3. Keeps the hardware open for all operating sytems and devices. This simple fact cannot be stressed enough. As the world slowly migrates to 64-bit everything. Microsoft has locked hobby driver developers out of Vista in 64-bit land.

    TPM BIOS modules have the capacity to lock out unapproved operating systems, devices, etc. Are they widely implemented? No. Is it possible to the point of being well documented? Yes.

  • by Grishnakh ( 216268 ) on Tuesday January 27, 2009 @04:18PM (#26628007)

    As another poster pointed out, Coreboot (which is written in C now) already boots Linux in 3 seconds, which is far faster than normal BIOSes. So obviously, performance isn't a problem here.

    Custom assembly language routines, written by an expert, may be helpful for certain things which are executed a lot. However, BIOS code is NOT executed a lot: it's executed just before booting the OS, and that's it. After the OS boots, BIOS code is never seen again. So if you're trying to eke out every bit of performance on your computer, writing custom assembly language code for your BIOS is probably the biggest possible waste of time. Instead, you should concentrate on things like OS interrupt routines, or certain software libraries which demand high performance (video codecs for example). Of course, even then it's debatable how well your asm routines will perform compared to well-written C code that's compiled by a good compiler with optimization.

Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann