AMD To Support Coreboot On All Upcoming Processors 134
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.
BIOS on a processor? (Score:1, Insightful)
Re:BIOS on a processor? (Score:4, Insightful)
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.
Re: (Score:2)
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
Re: (Score:3)
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)
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.
Re: (Score:2)
If a BIOS has (eg.) CPU power management functions in it; the CPU needs to follow the instructions from the BIOS.
Re: (Score:2)
Badger!
And? (Score:5, Insightful)
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)
Re: (Score:1)
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...
Re: (Score:2)
Whether it is uboot, LinuxBIOS, or a legacy BIOS, it's going to be doing a lot of stuff like checking memory & polling the IDE/SATA ports to detect the hard drives and verify that they're the expected size, loading the BIOS interrupt handler routines, starting basic drivers e.g. for keyboard, network, and hard drive support (any of which might be over USB), monitoring keyboard to show BIOS settings screens on keystroke, and selecting a boot device from which to load the bootstrap code which loads and in
Re: (Score:2)
Does it actually need to with LinuxBIOS? I thought most operating systems more-or-less ignored the BIOS routines. Though I suppose bootloaders might use them, so you may have to emulate something there.
Re: (Score:2)
The bootloader is the BIOS (well, part of it). And whether or not the OS ignores the BIOS routines or not depends on the OS, I would assume. The legacy Mac OS relied much more on the BIOS routines - the PC BIOS was much simpler, one reason why it was reverse-engineered and the BIOS on Mac systems wasn't. To run a legacy Mac operating system in an emulator, you need a copy of an original Mac BIOS dumped from its ROM, because the OS calls a lot of routines that were stored on the ROM.
But even the PC BIOS supp
Re: (Score:2)
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)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Considering that Intel sells its own boards as well, perhaps they could manufacture some with coreboot
Re: (Score:3)
While that is an issue for people who want Coreboot and Intel, it is arguably an advantage in making AMD play nice. If
Re: (Score:2)
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)
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.
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 could force the issue (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Well, you gotta support the errata on any CPU. IIRC, you could only use Intel with FreeBSD for quite a long time. I always supposed this was due to not having the microcode/errata support for the AMD/Cyrix.
I was still a newbie at computers during the Cyrix incident and had no contact with anyone with knowledge to fix it or tell me what was wrong. The Internet has solved that one, nicely.
(I'd go look up the FreeBSD thing but Googling on this tiny phone is no fun)
-l
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
instant computing (Score:5, Interesting)
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)
Re: (Score:2)
Re: (Score:2)
EEPROM can be reflashed
Only a limited number of times. :(
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:3)
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...
Re: (Score:2)
Re: (Score:2)
what happend to FerrorElectric RAM and all the other promising technologies?
FerrorElectric RAM had an error in it.
Re: (Score:2)
you are damned right! ( when he was asked if he has cancer )
Ferro-Electric
BTW you can keep the error
Re: (Score:2)
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]
Re: (Score:2)
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
Re: (Score:2)
Flash and EEPROM memories are different ... because of the way they are erased. ... ... cells can be erased individually.
Flash is divided into blocks, the entirety of the block is erased in a single operation.
EEPROM
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
We've come a long way since tanning beds for eproms!
Re: (Score:2)
Mod up!
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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). /most/ corruption(all but first few KB), it should just display a message saying just that.
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
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
It's OK for a splashtop, but in that case, just make it a valid boot image and do nothing special with the BIOS.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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...
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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 )
Re: (Score:2)
Did I miss something? (Score:4, Insightful)
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?
Re: (Score:2)
Garsh, that's just ugly. I'm kind of satisfied with the EFI and GUID most new machines are using.
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Buying new HW vs. repurposing existing HW (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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?
Re:Did I miss something? (Score:5, Informative)
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.
Re: (Score:2)
Yes.
The AMD blog post listed three motherboards that were specifically targeted by their coreboot development release...
Re: (Score:2)
Re: (Score:2)
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.
benefits (Score:2)
with a nice list of benefits.
Apparently protection from slashdotting isn't on the list.
Huh...Initial impression is a little coredumpish.. (Score:1)
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.
Re: (Score:1)
Re: (Score:2)
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.
Double-edged sword (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Can this be used against us? (Score:2)
Is there any way that this can be used against us?
As in trusted computing? Or any other downsides?
Just asking.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Saying that Digital Restrictions Management is bad is not FUD, it's a simple fact.
You'll get no argument from me there, but that's not what OP said! He said that TC is not about DRM, not that DRM was not about "bad things". Linux has had TC support for years, with full blessings from Linus. The result is more like advanced tripwire than any sort of DRM. In fact, TC-based DRM, while theoretically possible, isn't likely to be too useful, because TC was never designed to protect against local attackers, and "can be vulnerable to power-analysis, RF-analysis and timing-analysis". (Source [ibm.com]
This is good, but mostly for mobo mfgr (Score:2)
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
embeded only? (Score:2)