Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
AMD Open Source Hardware Linux

AMD To Support Coreboot On All Upcoming Processors 134

Posted by timothy
from the you-had-me-at-hello dept.
nukem996 writes "AMD has just announced that they will be supporting Coreboot (previously LinuxBIOS) on all upcoming processors." That means a flexible Free software BIOS replacement with a nice list of benefits.
This discussion has been archived. No new comments can be posted.

AMD To Support Coreboot On All Upcoming Processors

Comments Filter:
  • by Anonymous Coward
    Isn't it a motherboard, and not a CPU, that needs to support a BIOS?
    • by vlm (69642) on Monday May 09, 2011 @08:12AM (#36070982)

      Isn't it a motherboard, and not a CPU, that needs to support a BIOS?

      I ran into a problem a few years ago with an AMD CPU and an Asys (was it Asus?) MB where the MB bios was old enough that it would read the CPU type info, learn the CPU was newer than it was programmed to understand, and give up all hope. Had to install the oldest AMD CPU I could find, flash the BIOS, then install the brand new fast CPU.

      I would assume this means they will give all CPU revision data to the coreboot guys so coreboot can support all (all future?) CPUs in a series without choking.

    • I'm sure that there will be a variety of horrid messes lurking under the surface; a man could lose his sanity plunging too deep into the dark corners of motherboard ACPI details and the like.

      However, if AMD is planning to "support Coreboot on all upcoming processors", they presumably wouldn't bother doing that if the announcement didn't cover the accompanying chipsets as well(whatever chipset isn't included on die these days, that is). Between the CPU and its embedded peripherals, and the AMD chipset, th
    • Isn't it a motherboard, and not a CPU, that needs to support a BIOS?

      Yes, read TFA.

      AMD is providing coreboot development to support both AMD CPUs and chipsets. They specifically list three motherboards that will utilize coreboot and AMD chipsets and CPUs thus benefiting from AMDs development work on coreboot.

    • Not exactly (Score:4, Informative)

      by DrYak (748999) on Monday May 09, 2011 @09:18AM (#36071618) Homepage

      It used to be the case before :
      Most of the functionality (controlling memory, etc.) was done by the chipset on the motherboard. The CPU being almost only a dumb number-crunching unit.
      So the BIOS was needed to help initialize this chipset and was mostly tailored to the mother board.

      Nowadays, not only CPU cores have much more feature requiring some initialization (sleep states, speed stepping, etc.),
      but even some of the functionnality of the chipset, mainly the north bridge, has moved into the CPU.
      Low-latency memory controller, sometimes HyperTransport or Quickpath controller, sometimes PCIe controller : All these are now on the same silicon as the CPU (or at least inside the same package for some earlies Intel attempts). On the motherboard, only the south-bridge (lower speed controllers like : the rest of the PCIe, eSATA, old-school PCI, USB, LPC, I2C, etc.) is present and communicates through a standard protocol with the CPU (Hypertransport for AMD, either Quickpath or rebranded PCIe for Intel).

      Thus to support a "chipset" (What you're thinking about), you need to both support the northbridge inside the CPU, and the southbridge on the motherboard (as well as a few extra chips which might be useful for booting such as : GPU or serial I/O to display messages, additional mass-storage controllers, ethernet interfaces for networked boot and/or remote diagnostic, etc.)
      TFA mentions that AMD works to support both north and south of them, over the enitre product range, from lightweight low-power netbook CPU + Southbridges, all the way to server combination.

    • by Joce640k (829181)

      If a BIOS has (eg.) CPU power management functions in it; the CPU needs to follow the instructions from the BIOS.

  • And? (Score:5, Insightful)

    by ledow (319597) on Monday May 09, 2011 @07:21AM (#36070566) Homepage

    They "support" it now. So do Intel. The problem is not that the processor or even chipset supports it but that the bundled BIOS *IS* coreboot, which is unlikely.

    And even then, every tweak made by a motherboard manufacturer has to be taken account of. It's like saying the AMD "supports" running Linux on it. Course it does, but it doesn't mean that the computer can actually run Linux usefully (Argh! Flashback to the days when a lot machines *couldn't* get basic support under Linux working without patching an tweaking).

    It's a step forward but hardly worth shouting about - when Foxconn, MSI, etc. get on board, then you have a deal. Until then, it's like saying that my computer support FireWire. It does. It just doesn't have any FireWire ports, and I haven't installed the drivers for them on any OS.

    • Re:And? (Score:4, Interesting)

      by dargaud (518470) <[ten.duagradg] [ta] [2todhsals]> on Monday May 09, 2011 @07:31AM (#36070632) Homepage
      Yes, that's what I was thinking too. I recently wrote my own bootloader for a project. It honestly took me less time to do it from scratch (copy kernel from flash to mem, jump to it, done) than to read, understand and customize Coreboot or U-Boot or one of the many everything but the kitchen sink boot projects.
      • by _0xd0ad (1974778)

        copy kernel from flash to mem, jump to it, done

        Normally a BIOS does power-on checks and loads a library of interrupt handlers. Naturally, leaving all of that out would make it very simple...

      • Yes, that's what I was thinking too. I recently wrote my own bootloader for a project. It honestly took me less time to do it from scratch (copy kernel from flash to mem, jump to it, done) than to read, understand and customize Coreboot or U-Boot or one of the many everything but the kitchen sink boot projects.

        Of course you do realize that a generic bootloader like Coreboot must be more complex than a one off unportable one you can quickly write yourself for one set of hardware, am I right?

        In your comment you use the term "kitchen sink". To you this may mean that there are many things in the "sink" that you will have no use for... To me this means that Coreboot supports more that just the things that you will have a use for.

        A one off BIOS, or one that is specifically designed for the hardware is fine, and

      • Re:And? (Score:5, Informative)

        by Barefoot Monkey (1657313) on Monday May 09, 2011 @09:56AM (#36071988)

        Yes, that's what I was thinking too. I recently wrote my own bootloader for a project. It honestly took me less time to do it from scratch (copy kernel from flash to mem, jump to it, done) than to read, understand and customize Coreboot or U-Boot or one of the many everything but the kitchen sink boot projects.

        What you made is a second-stage bootloader. All those really need to do is load some other program into memory and then transfer control to it. Coreboot is a primary bootloader - it handles starting up the computer, setting up the memory and CPU modes, testing harware, providing services such as the hard-drive access that your loader would need, and finally loading your secondary loader for you. Your job was easy because there wasn't much left to do.

        Coreboot is more complicated than your loader because yours was piggybacking off something else, whereas Coreboot is that something else on which other people's loaders rely.

        I'm not sure if I explained that well, but I hope it helped.

        • What you made is a second-stage bootloader. All those really need to do is load some other program into memory and then transfer control to it. Coreboot is a primary bootloader - it handles starting up the computer, setting up the memory and CPU modes, testing harware, providing services such as the hard-drive access that your loader would need, and finally loading your secondary loader for you. Your job was easy because there wasn't much left to do.

          You don't have anywhere near enough information to make that claim. What if the parent poster made his own arm board from scratch? There is no "primary bootloader" as you call it when you buy a bare chip from Digikey and solder it to a board of your own design. The same is true for dozens of other processors. Sure, you can buy chips with bootloaders programmed into them but lot's of guys roll their own.

      • by sjames (1099)

        It's easy once something like Coreboot does the heavy lifting such as initializing the memory and memory controller (so there's somewhere to copy the kernel to) and gets the various bridge chips and links running for you.

        When Coreboot starts, there is NO RAM at all. Through clever tricks, it sets the CPU up to use it's cache as a sort of fragile RAM until the memory controller and DIMMs can be set up and enabled. It also sets up address decoding for PCI(e) and basic things like the serial port and keyboard.

    • by jxself (1210830)

      And even then, every tweak made by a motherboard manufacturer has to be taken account of. It's like saying the AMD "supports" running Linux on it. Course it does, but it doesn't mean that the computer can actually run Linux usefully (Argh! Flashback to the days when a lot machines *couldn't* get basic support under Linux working without patching an tweaking).

      It is much easier when you have support from the manufacturer. Previously, AMD would provide preriodic code drops and makes their engineers available. Now, one of their more recent contributions provided the same code that BIOS manufacturers get.

    • Considering that Intel sells its own boards as well, perhaps they could manufacture some with coreboot

      • I suspect that, given that Intel specifically designed EFI, and has AMT, their own proprietary PXE-on-Steroids setup; their incentive to support coreboot is relatively small. If somebody shoved a giant pile of cash in their face and said "100,000 Xeon cluster; but only with Coreboot", they might consider doing a custom job; but their roadmap is pretty clearly not in Coreboot's direction.

        While that is an issue for people who want Coreboot and Intel, it is arguably an advantage in making AMD play nice. If
    • The more it's shouted about, the more likely Foxconn, MSI, etc are to get on board. In these chicken and egg type situations, you need to get the impetus going somehow..

    • Re:And? (Score:5, Informative)

      by oxygene2k2 (615758) on Monday May 09, 2011 @08:13AM (#36070986)

      AMD made their platform code work for coreboot. That is, the same code they ship to board and BIOS makers, they release to coreboot, and even went the extra mile to integrate it.

      Intel doesn't support coreboot. In fact, they hinder us and we'll have to get each bit of information out of the hardware or by massive coercion. Every support of Intel hardware in coreboot exists despite Intel's efforts.

      • by dfetter (2035)

        I don't think the word, "coercion" means what you think it means. Are you really in a position to force Intel to do anything? Really?

        • by e70838 (976799)
          I guess he has threaten an Intel employee to break his car if he did not give confidential documents.
      • by Ant P. (974313)

        I'm pretty sure I've figured out why they do that. Every Intel CPU I've owned in the last 10 years has been crippled and locked down in the BIOS, while the AMD boards enable more or less everything the hardware supports. They don't want you supporting their hardware because it's harder to nickel-and-dime paying customers for basic features that way.

        • by mjwx (966435)

          I'm pretty sure I've figured out why they do that. Every Intel CPU I've owned in the last 10 years has been crippled and locked down in the BIOS, while the AMD boards enable more or less everything the hardware supports. They don't want you supporting their hardware because it's harder to nickel-and-dime paying customers for basic features that way.

          I thought the IBM business model died decades ago.

    • The problem is not that the processor or even chipset supports it but that the bundled BIOS *IS* coreboot, which is unlikely.

      The AMD blog posting lists three motherboards that will be utilising AMD chipsets and CPUs with these new coreboot developments provided by AMD, so unlikely is no longer the correct assumption.

    • They "support" it now. So do Intel. The problem is not that the processor or even chipset supports it but that the bundled BIOS *IS* coreboot, which is unlikely.

      The first thing to do is make sure support is there in coreboot. Then in markets that are very cost sensitive the system makers can use it to save money. Then at some point if AMD feels it is mature and really want to force the issue, they can stop supporting traditional BIOS developers, which will almost force the board and system guys to switch t

    • by Luyseyal (3154)

      Argh! Flashback to the days when a lot machines *couldn't* get basic support under Linux working without patching an tweaking.

      No kidding. I would have started using Linux in 1996 when I first heard about it fresh out of high school. But I was poor and couldn't afford Intel so I had purchased a Cyrix chip. Little did I know that Linux was Intel-only back then. I was so mad that Slackware kept segfaulting for no apparent reason during the installation process. I finally gave up and ran Windows 95 on the box. A year or two later, I read on some teal geek site that non-Intel processors were now supported and my desktop OS was forever

    • by JamesP (688957)

      Exactly

      Until then, the Bios is going to be patch after patch over an assembly code already way past its life and
      cobbled together from unrelated pieces by people that doesn't have the slightest idea about what's DSDT or test if the memory
      configurations are ok.

    • I had one Foxconn - never again. MSI I might be persuaded to use again, but not likely. I'll stick with better name brands, such as ASUS, or Gigabyte. Oh - I have an Abit that was produced for the original AMD Athlon XP CPU's. It still runs great, I can't pry the wife away from it.

      It simply doesn't matter to me what the cheap motherboards support, because I'm not buying them. My order of priority when building or buying a comuter puts the CPU at the top, and the mainboard second, the GPU third. Load t

      • I had one Foxconn - never again. MSI I might be persuaded to use again, but not likely. I'll stick with better name brands, such as ASUS, or Gigabyte.

        I'll counter your meaningless anecdotal experience with one of my own. I've owned a number of Foxconn boards and they have all been flawless.

        • Yeah, I'll second that. I usually pick a MB on the basis of chipset and supported CPU power. Chipset is important because there are real clunkers and real winners out there. CPU power is important because you might want to use a 65W processor today, but upgrade to a 125W one next year.

          But as far as manufacturers are concerned, I've used numerous Foxconn boards, several MSI boards, and a couple of Gigabyte boards. And I have never had a major issue with any of the brands.

          One extra anecdote: After blowing out

    • by nukem996 (624036)
      Thats true but I wouldn't be putting pressure on Foxconn, MSI, or any other ODM builders its really who your buying from. HP, Dell, Acer, etc are the ones who really make the calls. They go with the BIOS because thats what Windows works with best and its whats known. What coreboot needs to do is support Windows well and do something the BIOS/EFI doesn't that consumers really want. Faster boot time is really nice and is something that could give them that however they still need to catch up with a graphical
  • instant computing (Score:5, Interesting)

    by kubitus (927806) on Monday May 09, 2011 @07:33AM (#36070644)
    the solution for your quick access to the Internet. I have an ASUS P5Q DeLux with Splashtop.

    No need to wait until your OS has booted to get the latest e-mails and/or news.

    I wonder why there is no HW manufacturer coming up with Linux in the ROM - ROM chips are big enough for a basic functionality.

    The rest may come from the disk.

    And its damned hard to overcome a physical write protection and install permanent malware.

    • Re: (Score:3, Insightful)

      by The MAZZTer (911996)
      You can't patch ROM, and having an unpatched and unpatchable OS is a bad idea no matter which OS that is.
      • Ummm... You do know that EEPROM can be reflashed right? Might not be a patch but it will fix the problem...
        • by sgt scrub (869860)

          EEPROM can be reflashed

          Only a limited number of times. :(

          • by limaxray (1292094)
            Limited usually being 100,000+ times

            I have prototype devices used for development that have had their EEPROMs erased and reprogrammed hundreds of times without any signs of a problem. A customer in the field would never come anywhere close to this.

            In any case, this would be better served by flash memory than EEPROM.
            • by sgt scrub (869860)

              oh your right. i forgot about eeproms emulated using flash which i guess is what they all are now. back in the day eeproms could only be flashed between 10 and 100 times.

              • by _0xd0ad (1974778)

                i forgot about eeproms emulated using flash which i guess is what they all are now.

                Emulated? Flash memory is a type of EEPROM (electronically erasable programmable read-only memory).

                back in the day eeproms could only be flashed between 10 and 100 times.

                Back in the day 640k of RAM was enough space for anyone, too. Technology has advanced since then...

                • by kubitus (927806)
                  what happend to FerrorElectric RAM and all the other promising technologies?
                  • by JAlexoi (1085785)

                    what happend to FerrorElectric RAM and all the other promising technologies?

                    FerrorElectric RAM had an error in it.

                    • by kubitus (927806)
                      may I reply with a quote from Frank Zappa:

                      you are damned right! ( when he was asked if he has cancer )

                      Ferro-Electric

                      BTW you can keep the error

                • by sgt scrub (869860)

                  not originally.

                  Although [flash memory is] technically a type of EEPROM, the term "EEPROM" is generally used to refer specifically to non-flash EEPROM which is erasable in small blocks, typically bytes. Because erase cycles are slow, the large block sizes used in flash memory erasing give it a significant speed advantage over old-style EEPROM when writing large amounts of data.

                  http://en.wikipedia.org/wiki/Flash_memory [wikipedia.org]

                • by willy_me (212994)

                  Flash and EEPROM memories are different. Look at the specs for any microcontroller and you will notice that they specify both EEPROM and Flash separately. The reason for this is because of the way they are erased. Flash is divided into blocks, the entirety of the block is erased in a single operation. This is great for storing large blocks of data, like an executable, as it greatly decreases the time required to erase the memory. It also reduces the cost of the memory as it is requires less space to im

                  • by _0xd0ad (1974778)

                    Flash and EEPROM memories are different ... because of the way they are erased.
                    Flash is divided into blocks, the entirety of the block is erased in a single operation. ...
                    EEPROM ... cells can be erased individually.

                    Technically they could very well be made of the same components ... the support circuitry differs

                    The phrase "eeproms emulated in flash" is still nonsensical, because emulation would have to occur in the support circuitry, which is the only difference between the two anyway. If anything, it means that the EEPROM is erased and written by blocks like flash, but the flash controller is designed to seamlessly erase an entire block and then re-write it whenever a single byte is modified in the eeprom, making it look like a memory cell can be erased individually.

                    However that would make the lifespan of the mem

              • by swillden (191260)

                oh your right. i forgot about eeproms emulated using flash which i guess is what they all are now. back in the day eeproms could only be flashed between 10 and 100 times.

                Lots of real EEPROMs (byte-erasable) support hundreds of thousands or even millions of erase cycles.

              • You might be thinking of uv erasable eproms, which could only handle a few thousand cycles. But that would have been about the time "The Godfather" was showing in the cinemas.

              • by sjames (1099)

                We've come a long way since tanning beds for eproms!

            • by couchslug (175151)

              Mod up!

      • If you're not going to connect to a network that doesn't really matter. My Asus netbook uses the Splashtop and it's very handy as a disaster recovery OS - the first thing I did with the netbook was wipe the XP installation and it immediately dropped into the Splashtop, very handy if you lose the primary OS for any reason. You're right though, I wouldn't use it as a regular OS for exactly the reasons you mention.
    • It's probably due to the fact that the only cheap memory solution big enough would be using flash memory - Probably an eMMC chip - and it's fairly slow(20mb/sec reads). Increasing the speed through the use of high end chips and controllers would raise the cost quite a bit.

      I'd be more interested in a simple image file loaded to an outer track on the disk: The whole image is then copied to memory at boot(meaning you get top-speed linear reads; 100+mb/sec at least), where it's then uncompressed etc.
      So long as

      • by Jesus_666 (702802)
        IBM did that for some older Thinkpad models. The result was that a defect on one of those tracks made your entire system unbootable - in fact, you didn't even get any BIOS beeps because the BIOS couldn't be loaded. I think I know why they stopped doing it like that...
        • Seriously? I've had a number of thinkpads, and the only hidden partition was a recovery one(Not great, but no problem if it gets wiped).
          Putting bios functions on a spinning disk - Or even a easily writable flash - is indeed a bad idea.
          Still, I'm talking about a splashtop, not the bios etc - If it gets corrupt, you should be able to just have to stick a CD in and re-image it. Heck, for /most/ corruption(all but first few KB), it should just display a message saying just that.

          • by Jesus_666 (702802)
            That was back when the hard drive had a proprietary form factor so you had to buy the replacement from IBM (which probably wasn't such a big deal since the BIOS thing meant they weren't easily replacable anyway).
      • by sjames (1099)

        The biggest reason to even want a recovery system is to make life easier if the HD screws up. Having the recovery tools on the HD doesn't really work.

        • That is true. But for a splashtop it's fine.

          'course, having some recovery stuff on the harddisk for the 95% of the time that yopu just get a virus on Windows instead... It could be useful. But a recovery CD should still be provided.

          • by sjames (1099)

            It's OK for a splashtop, but in that case, just make it a valid boot image and do nothing special with the BIOS.

            • I think the idea is that Coreboot can directly boot Linux kernels and such, so you'd be able to have native support for your splashtop right from bios(i.e., press f9 to boot splashtop), instead of having to load a bootloader like Grub first, which would mean even faster boots.
              Without it, though, it should still chainload into your OS of choice.

              • by sjames (1099)

                Once you accept loading from disk, you've already lost that battle, might as well make it as compatible as possible. You'll spend more time than you might think waiting for the disk to spin up.

                Grub and other decent bootloaders don't take that long unless you add a delay for human interaction.

                The big thing you gain from Coreboot in this case is not having the BIOS screwing around for a minute and a half.

                • Yes, exactly. However, you'd need some user-interaction time if you used grub: You have to choose between the splashtop and the main OS at least.
                  You could minimise it by adding that function to coreboot, so while it's already waiting for del or w/e to enter Setup, it can also take say f1 for splashtop...

                  • by sjames (1099)

                    I'm guessing you would be using SeaBIOS loaded by Coreboot. In that case, SeaBIOS can let you choose a boot image based on a keypress. Just make your splashtop a regular bootable image and it'll work fine. Optionally modify SeaBIOS to prompt pressing F1 for splashtop.

                    You then have something that can be very quickly loaded using Coreboot, or loaded merely faster than the full OS from any BIOS/bootloader you like.

    • by gl4ss (559668)

      splashtop is a linux distribution in the rom.

      but you know, win7 boots to login about just as fast from ssd(in meaningful calculations, it's on login screen pretty fast, out of hibernate even faster of course). and I had an asus rog line of laptop with 2x320gb, and even it booted fast enough that I didn't really use the splashtop for anything. also it's hw support sucks.

      if you want a quick glance you'd be rolling some news ticker on your smartphone.

    • No need to wait until your OS has booted to get the latest e-mails and/or news.

      That's the whole point of Coreboot. The reason that booting is so slow is because of three things: the BIOS, the hard drive, and the OS itself. My laptop originally took about a minute to boot, but once I installed an SSD, it dropped to 20 seconds. The creaky BIOSs all run in 16-bit mode and have so many numerous hacks (like the INT 13h fixes) that most modern OSs don't use them hardly at all. Coreboot slims it down so that booting is even faster and eliminates all the legacy crap that's been tagging along

    • Why not? Much the same reasons as why J2ME and a java vm never made into ROM... it's still too complex that they can't control serious logic failures.

    • Meh. First of all, I can boot Windows 7 from POST to desktop in less than 10 seconds, and for most people it's probably only marginally higher than that. Second of all, who powers down their computer these days anyway? I guess I should expect Linux users to be less familiar with common ACPI power management features like S3 or S4, given the support for them in even modern distros is still shoddy at best.
      • by kubitus (927806)
        your 10 to 20 second boot comes at which cost?

        do you keep your notebook/laptop always on?

        and as I said before: it is damned hard to corrupt a system in ROM.

        Unfortunately you are right to an too large extent on the S3 and S4 ACPI functionality in Linux distros ( more in HW drivers again )

    • by rdnetto (955205)
      According to Wikipedia, Splashtop boots in 5 seconds. My desktop has an SSD and Ubuntu boots in 10 seconds. (Which is still fast enough to feel pretty damn fast.) Why bother with an atomic OS when you can get the same degree of speed with an SSD and a full Linux distro*? * Despite the SSD, Windows still takes as long to boot as it did before.
  • by TheDarkMaster (1292526) on Monday May 09, 2011 @07:35AM (#36070656)
    Did I miss something?

    The problem is not the CPU support, is support for the motherboard... I went to see a list of motherboards "compatible" on Coreboot site and after seeing the definition of "compatible", I concluded that it would be madness to use Coreboot on any motherboard, especially if a newer type.

    Do not get me wrong, but if that Coreboot want to replace the BIOS of a motherboard then it should necessarily be 100% compatible, nothing less. How can they say that for example the Coreboot is compatible with the Asus A8N-E, when only one SATA port works and PCI-E 16X do not work?
    • How can they say that for example the Coreboot is compatible with the Asus A8N-E, when only one SATA port works and PCI-E 16X do not work?

      Garsh, that's just ugly. I'm kind of satisfied with the EFI and GUID most new machines are using.

    • by drinkypoo (153816)

      You didn't miss anything. AMD has "supported" their processors and their chipsets for coreboot for ages now. Geode, Hammer, R690. It doesn't do you any good because, as you say, motherboards differ in implementation details that will make coreboot not work for YOU until after massive hacking and reverse engineering.

      This is a bullshit marketing statement, nothing more.

    • It's gotten much, much better, but I can remember the days when "compatible" Linux hardware often meant that if you didn't mind missing half the functionality and everything being slow, it was completely compatible. Gods forbid something had "partial" or "experimental" support. I remember installing a scanner once that supposedly had "partial" support. It installed OK, and GIMP was able to use to it, so I was getting pretty excited. Then I tried to scan something. It would only scan approximately a 1 i

      • I take issue with this:

        Now, of course, nearly everything works with little or no effort. It's not *quite* as plug and play easy as Windows in some cases (though in many cases it is), but rarely do you find a piece of hardware that doesn't work at all or is severely degraded in Linux. Hopefully as time and development proceeds, this will improve as well (but I'm not using it till it does).

        I've never found a piece of hardware that didn't work at all once when the machine was booted as GNU/Linux instead of MS/Windows.

        Typically at the very least the device works exactly the same under either environment. I have, however, discovered that a device's driver software was not portable to Linux, and that the manufacturer only provided support for Windows. In this instance I contact support, and if no resolution can be reached -- a source or binary for my chosen OS will no

        • Re: (Score:2, Interesting)

          by Kjella (173770)

          I've never found a piece of hardware that didn't work at all once when the machine was booted as GNU/Linux instead of MS/Windows. (...) I have, however, discovered that a device's driver software was not portable to Linux, and that the manufacturer only provided support for Windows.

          You've never found hardware that didn't work, except it didn't work? Or does coming to POST and that your DVD drive will open and close count as "working"?

          In this instance I contact support, and if no resolution can be reached -- a source or binary for my chosen OS will not be made available -- I will simply return the device to the store or manufacturer for a full refund. (...) Unless we actively make it less profitable for such incompatible manufacturers to ignore us and not provide cross platform drivers for their hardware, your OS choices will remain limited.

          So your solution to them not finding your market segment profitable is to make it appear like a market of bothersome, high return, "can't read the system requirements" buffoons who'll kill off all profit? That's not encouragement, that's teaching them to not touch that market with a ten foot pole.

          • You've never found hardware that didn't work, except it didn't work? Or does coming to POST and that your DVD drive will open and close count as "working"?

            To a device driver coder like myself, yes, opening and closing and responding without malfunction to properly formatted binary signals is all that is required for me to verify if the hardware is "working" as intended.

            Having the IO API published, and/or publishing the source code for ANY driver (including the MS/Windows driver) is enough for me to interface that hardware with my OS and software. Additionally, allowing me to code and distribute a working driver for Linux on my own dime for their hardware

        • You're splitting hairs. If it has no driver support, or the driver support is flaky, incomplete, or fiddly, then from a user's point of view it doesn't work, or works incompletely or flaky. From the point of view my statement was made from (user/system administrator/high level programmer), it was completely accurate. As it relates to the subject at hand, Coreboot not working, or working poorly with some hardware, my statement was completely relevant. If, as has happened over time, Linux drivers can be p

          • You're splitting hairs. If it has no driver support, or the driver support is flaky, incomplete, or fiddly, then from a user's point of view it doesn't work, or works incompletely or flaky. From the point of view my statement was made from (user/system administrator/high level programmer), it was completely accurate.

            No, I'm not splitting hairs... I've identified a statement that I take issue with, as I see it is absolutely incorrect, and then further explain my position. This is in no way splitting hairs.

            but rarely do you find a piece of hardware that doesn't work at all

            I have clearly argued my point -- The hardware that "doesn't work at all" on GNU/Linux will also not work at all on any other software platform because it is by definition, broken. However, if the hardware does work on any OS, including MS/Windows, then it fundamentally must be working hardware.

            The issue have obj

            • No I have simplified the question "does this hardware have software support for this platform?" to "Does this hardware work on this platform". I'm well aware of what drivers are, and how they provide binary interaction between the operating system and the hardware, however I don't particularly care. If I have a Linux box, and a piece of hardware that lacks Linux drivers, then for all practical purposes the hardware doesn't work with my OS. I can't make it *do* anything. And yes, if I get a piece of hard

        • In this instance I contact support, and if no resolution can be reached -- a source or binary for my chosen OS will not be made available -- I will simply return the device to the store or manufacturer for a full refund.

          Returning an incompatible product works fine when you are buying new hardware on which to run your chosen OS. It doesn't necessarily work so well if you are repurposing existing hardware, which is past its return window, from a previous chosen OS to your current chosen OS.

          • In this instance I contact support, and if no resolution can be reached -- a source or binary for my chosen OS will not be made available -- I will simply return the device to the store or manufacturer for a full refund.

            Returning an incompatible product works fine when you are buying new hardware on which to run your chosen OS. It doesn't necessarily work so well if you are repurposing existing hardware, which is past its return window, from a previous chosen OS to your current chosen OS.

            Thank you for illustrating my point -- This is the precise conclusion that we should all arrive at. Either insist open source drivers for the hardware you purchase, or risk artificial obsolescence of your hardware. (Note: The same can be said of software obsolescence -- 1065 days 'til XP EOL).

            The software drivers are not the hardware. The software driver source code used to be provided with nearly all hardware, so that we could support the hardware ourselves without expending any resources of the hardwa

            • by tepples (727027)

              Insist on driver source code, even if you don't use a FLOSS OS.

              Then which video card brand and which USB Wi-Fi card brand do you recommend?

    • by ThePhilips (752041) on Monday May 09, 2011 @08:20AM (#36071076) Homepage Journal

      The problem is not the CPU support, is support for the motherboard...

      But the MB manufs won't move until chipset CPU/manufacturers also support the type BIOS.

      Do not get me wrong, but if that Coreboot want to replace the BIOS of a motherboard then it should necessarily be 100% compatible, nothing less. How can they say that for example the Coreboot is compatible with the Asus A8N-E, when only one SATA port works and PCI-E 16X do not work?

      Yes, you have missed something. Check the server motherboard compatibility list. It is much much more "up-to-date." Apparently people who are struggling most with the carp of proprietary BIOSs are the admins of data centers and server farms. Thus the developer's bias. Me, desktop user, is not on their roadmap.

    • Did I miss something?

      Yes.

      The AMD blog post listed three motherboards that were specifically targeted by their coreboot development release...

      Each of these releases will be targeted at the following platforms: SuperMicro MBD-H8SCM-F-O for the 4100/SR56x0/SP5100, SuperMicro H8QGI-G34 for the 6100/SR56x0/SP5100 and Advansus (Advantech) A785E- I (w/1.7GHz dual-core) for the AMD 785E/SB8xx.

      • Hum... So it might work. Serious, I would like to have a BIOS more "smart" and without bugs, but it needs to make all the hardware work 100% out of the box, without having to scour half of the Internet for obscure hacks. This is acceptable for a new user application, but it is unacceptable for something that is the heart and soul of the motherboard.
    • by sjames (1099)

      The CPU is a BIG step in the right direction, especially since the memory controller is in the CPU. Imagine trying to debug a system where you can't get the memory working!

      The mainboards are a significant issue, not only because each is done differently, but because some seem to change at random during it's lifetime even without the sku changing. That's the REAL pain.

  • with a nice list of benefits.

    Apparently protection from slashdotting isn't on the list.

  • So I go to see the list of features via the above "nice list of benefits" link and...

    A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "". Database returned error "1205: Lock wait timeout exceeded; try restarting transaction (localhost)".

    I am always a little more comfortable with something that will be in the guts of my systems if my very first exposure doesn't include a big fat oops.

    • Hopefully, the guts of your system won't be slashdotted, though...
      • Which is not to say that I wouldn't try Coreboot's BIOS...my first job was as a "cold warrior"...that education left me less than thrilled with the fact that mobos are almost universally assembled - and BIOSed-up - in the PRC.

        But I do hope their QC on the public face they put on the web isn't reflective of the QC effort they put into their BIOS.
  • A lot more people work on an OS level than the BIOS level, meaning that a lot more people will be aware of possible ways to exploit weaknesses in the used Linux kernel and its related packages.

    • A lot more people work on an OS level than the BIOS level, meaning that a lot more people will be aware of possible ways to exploit weaknesses in the used Linux kernel and its related packages.

      Correct. In fact, many people will likely discover or have knowledge of such weaknesses -- Rarely is anything ever invented that is not re-invented, likely simultaneously (see: Telephones).

      Depending on the motives of a given individual with knowledge of an exploit the bug will either be fixed or exploited, or both, simultaneously. Considering that once the details of a bug are known it typically takes less effort to fix the bug than to create a usable exploit, it doesn't bode well for malware writers.

      • by lennier1 (264730)

        In short -- Using a free/open BIOS or OS is more secure by nature, for the same reason that my car is more reliable with an unlocked hood than if it is only serviceable by the dealer (I can check and change my own oil, esp. on long drives away from any dealer approved maintenance facility).

        In theory, but it depends on the frequency of those updates/bugfixes.
        Just take a look at all those Android devices. They may be Linux-based, but they rarely (if ever) receive security updates from upstream, leaving them v

  • Is there any way that this can be used against us?

    As in trusted computing? Or any other downsides?

    Just asking.

    • by gl4ss (559668)

      no, what they were announcing was stuff that they had announced before, basically. just saying it again.

      if anything it means that you can buy some motherboards and use them to defeat drm that's supposed to work on it's principles.

  • One of the most expensive, and labor intensive part of mobo development is the BIOS. The licensing is very expensive, and requires a good deal of effort on the part of the SW developer. Often times the developers and mobo mfgr don't even have access to the full source code. The fact that U-boot (universal bootloader) is free makes x86 inherently more expensive than an ARM or PPC board, even if the processor components cost less. This is good for small and mid-size companies that are priced out of x86 de

  • They say future products but right now all they claim to support is embedded systems and their Opteron. No mention of desktop processors like Phenom 2 or their 6 core ventures or Fusion. I'll look up what the Llano APU is.

All the simple programs have been written.

Working...