AMD To Support Coreboot On All Upcoming Processors

← Back to Stories (view on slashdot.org)

AMD To Support Coreboot On All Upcoming Processors

Posted by timothy on Monday May 9, 2011 @12:10AM 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.

134 comments

Min score:

Reason:

Sort:

BIOS on a processor? by Anonymous Coward · 2011-05-09 00:15 · Score: 1, Insightful

Isn't it a motherboard, and not a CPU, that needs to support a BIOS?
1. Re:BIOS on a processor? by vlm · 2011-05-09 01:12 · Score: 3, 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.
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
2. Re:BIOS on a processor? by fuzzyfuzzyfungus · 2011-05-09 01:28 · Score: 1
  
  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, that hardly assures 100% support(some wacky WinRAID half-baked option ROM? You have fun with that.); but it should make the basic "Boot, bring up some basic I/O, and figure out where the hell you are from there" step a great deal easier...
3. Re:BIOS on a processor? by burnin1965 · 2011-05-09 01:30 · Score: 2
  
  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.
4. Re:BIOS on a processor? by Anonymous Coward · 2011-05-09 02:00 · Score: 1
  
  Bad case of TB.
5. Re:BIOS on a processor? by Joce640k · 2011-05-09 02:18 · Score: 1
  
  If a BIOS has (eg.) CPU power management functions in it; the CPU needs to follow the instructions from the BIOS.
  
  --
  No sig today...
6. Re:BIOS on a processor? by WorBlux · 2011-05-09 06:48 · Score: 1
  
  It's not a BIOS, it's a BIOS replacement. And yes and no. To actually use coreboot you need it to recognize the CPU, the soutbridge, the northbridge, and the Super I/0. It basically just just initializes hardware and hands it off to a paylod, be it the linux kenrel, a BIOS or EFI implementation, or bootloaders like FILO or Grub. Basically this step makes it easier for implementation of Coreboot, as you know all the CPU specific features should be set-up without any tweaking.
7. Re:BIOS on a processor? by Gbor · 2011-05-09 07:30 · Score: 1
  
  I don't think that AMD is that big of a motherboard vendor, so such a statement wouldn't make much sense. "Coreboot support for AMD chipsets" would have sounded less confusing to me as well. Anyway, I think this is great news... at least if as a consequence of AMD's support for Coreboot we'd actually starting to see the old BIOS being replaced on large volume mainboards. Btw... The blog creates the impression that AMD is quite committed to Coreboot... Was there any actual contribution from AMD to Coreboot or is this more related to PR and throwing off the competition? Perhaps someone from the Coreboot devs could provide some details? What does AMD's support actually mean?
8. Re:BIOS on a processor? by Builder · 2011-05-09 07:47 · Score: 1
  
  Badger!
9. Re:BIOS on a processor? by klkblake · 2011-05-09 12:12 · Score: 1
  
  AMD contributed ~165,000 lines of code to coreboot.
  
  --
  The sum of the intelligence of the world is constant. The population is, of course, growing.
And? by ledow · 2011-05-09 00:21 · 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.
1. Re:And? by dargaud · 2011-05-09 00:31 · Score: 3, Interesting
  
  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.
  
  --
  Non-Linux Penguins ?
2. Re:And? by _0xd0ad · 2011-05-09 00:37 · Score: 0
  
  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...
3. Re:And? by jxself · 2011-05-09 00:39 · 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.
4. Re:And? by mehrotra.akash · 2011-05-09 00:40 · Score: 1
  
  Considering that Intel sells its own boards as well, perhaps they could manufacture some with coreboot
5. Re:And? by Anonymous Coward · 2011-05-09 00:44 · Score: 0
  
  (Argh! Flashback to the days when a lot machines *couldn't* get basic support under Linux working without patching an tweaking).
  that was why i used FreeBSD, linux i mainly use to recover virii infected systems. the pc i'm using now was recovered from a nasty virus. it runs better under linux now than it ran windows xp. puppy linux is great for dumpster divers.
6. Re:And? by somersault · 2011-05-09 00:47 · Score: 1
  
  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..
  
  --
  which is totally what she said
7. Re:And? by Anonymous Coward · 2011-05-09 00:56 · Score: 0
  
  You don't get it.
  in LinuxBios linux is the BIOS, it is a stripped-down linux kernel that does those checks and provides those handlers.
  I don't think that ex. uboot is equivalent to either a legacy BIOS, EFI or LinuxBIOS -- it's rather a kind of lilo boot-loader.
8. Re:And? by oxygene2k2 · 2011-05-09 01:13 · 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.
9. Re:And? by Anonymous Coward · 2011-05-09 01:14 · Score: 0
  
  It also configures a bunch of PCI and other PnP devices - allocating memory regions etc. U-Boot also does this sort of stuff - writing your own PCI configuration space code might take a while - as well as providing support for networking, nfs/tftp booting and firmware downloading. GP is doing a bit of an unfair apples-to-oranges comparison - for a very specific and simple system (which the load flash, jump to it certainly suggests) then pretty much anything else is going to be far more complex. PCs tend not to be quite so well defined in terms of what hardware is present and how to operate it so the BIOS and bootloader will be more complex. Embedded systems can be even more varied (non-standard methods of bringing up buses, network etc.). You need to work out the point at which writing stuff from scratch becomes more hassle than understanding and customizing an existing solution. Also you might only have to gain that understanding once (or at least most of it), whereas you could end up writing that quick simple boot loader for every board you work on...
10. Re:And? by VortexCortex · 2011-05-09 01:22 · Score: 1
  
  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 it is simple... However, the next hardware revision may require you to rewrite large portions that you may not have had to if you had considered the various different kitchens before you built your sink.
  Additionally, your one-off BIOS is unlikely to benefit from changes that other hardware BIOS software coders create, and your one-off BIOS's unique interface may render it more difficult for users to add changes to it than a more widespread BIOS that the user is more familiar with...
  TL;DR: Note the simplicity of the task at hand -- Inventing a Wheel; Also note that a the Hacker's principal virtue of laziness still applies. In short, let's not reinvent the wheel.
11. Re:And? by dfetter · 2011-05-09 01:23 · Score: 1
  
  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?
  
  --
  What part of "A well regulated militia" do you not understand?
12. Re:And? by fuzzyfuzzyfungus · 2011-05-09 01:33 · Score: 2
  
  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 intel has a variety of proprietary-secret-sauce-but-useful-and-tasty features, AMD will want something to compete. If they decided to support coreboot in order to add these sorts of advanced modern BIOS features, it's a win for both parties. AMD gets powerful preboot features, Coreboot doesn't have to painstakingly reverse-engineer support for every single board they want to run on...
13. Re:And? by burnin1965 · 2011-05-09 01:34 · Score: 1
  
  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.
14. Re:And? by Anonymous Coward · 2011-05-09 01:37 · Score: 0
  
  Are you really in a position to force Intel to do anything? Really?
  Your assumption is that they don't have large corporate backers. You may want to reconsider.
  Coreboot is apparently quite popular among people who work with clusters and those people have leverage with Intel.
15. Re:And? by e70838 · 2011-05-09 01:51 · Score: 1
  
  I guess he has threaten an Intel employee to break his car if he did not give confidential documents.
16. Re:And? by _0xd0ad · 2011-05-09 02:30 · Score: 1
  
  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 initializes the OS itself.
  I do "get it". My point was only that dargaud's bootloader does almost none of those things. It just copies a kernel from a fixed location in flash memory and jumps to it. Obviously it's going to be much simpler than "everything but the kitchen sink boot projects".
17. Re:And? by Barefoot+Monkey · 2011-05-09 02:56 · 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.
18. Re:And? by Luyseyal · 2011-05-09 03:20 · Score: 1
  
  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 changed.
  -l
  
  --
  Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
19. Re:And? by JamesP · 2011-05-09 03:45 · Score: 1
  
  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.
  
  --
  how long until /. fixes commenting on Chrome?
20. Re:And? by jimicus · 2011-05-09 04:21 · Score: 1
  
  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.
21. Re:And? by Runaway1956 · 2011-05-09 04:34 · Score: 1
  
  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 the thing with good memory, then I might start cheaping out with a bargain brand CD-DVD or a budget quality case (assuming adequate ventilation).
  Something tells me that the people who generally use Foxconn and the like don't give a small damn about Coreboot or any other developments in the computer world. If it connects to sluttybitch dot com and plays the media found there, then it's a good computer - for them.
  
  --
  "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
22. Re:And? by Anonymous Coward · 2011-05-09 05:39 · Score: 0
  
  DFETTER: that word... I do not believe you know what it means my friend.
  OXYGENE2K2: INCONCEIVABLE!
23. Re:And? by Ant+P. · 2011-05-09 05:45 · 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.
24. Re:And? by TheTyrannyOfForcedRe · 2011-05-09 06:22 · Score: 1
  
  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.
  
  --
  "Liechtenstein is the world's largest producer of sausage casings, potassium storage units, and false teeth."
25. Re:And? by TheTyrannyOfForcedRe · 2011-05-09 06:27 · Score: 1
  
  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.
  
  --
  "Liechtenstein is the world's largest producer of sausage casings, potassium storage units, and false teeth."
26. Re:And? by _0xd0ad · 2011-05-09 06:36 · Score: 1
  
  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 supplied such things as INT 10h (video routines), INT 13h (file system routines), and several other interrupts for serial communication, keyboard, and printer, among other things. Regardless of whether the OS used them or not, user-level programs could (and did) use these interrupts back in the DOS era, which means that anything running legacy DOS apps has to emulate these interrupts.
27. Re:And? by WorBlux · 2011-05-09 07:05 · Score: 1
  
  And coreboot makes that first stage a lot easier by letting you write in C, rather than assembly. It only has to be in real mode a couple of more instruction before in can jump into your compiled C code.It also provides fallback to a standard shell (busybox) can use any of the Linux driver code, and is extensible. Considering the EFI on intel's newer boards, Coreboot may be the only option for AMD if they want a competing extensibility and standardization between boards and shipsets.
28. Re:And? by Lord+Byron+II · 2011-05-09 07:10 · Score: 1
  
  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 an MSI MB with a defective powersupply (Antec, go figure), their tech support/RMA process was a breeze to work with and had me my new board in a couple of days with minimal fuss.
29. Re:And? by Anonymous Coward · 2011-05-09 07:47 · Score: 0
  
  Intel promotes EFI instead.
30. Re:And? by Anonymous Coward · 2011-05-09 09:27 · Score: 0
  
  Intel does not support coreboot. Please don't post uninformed assumptions.
31. Re:And? by Luckster7 · 2011-05-09 09:59 · Score: 1
  
  My experience with Cyrix chips was they crashed every 30 minutes no matter what OS you put on them.
  
  --
  Deuteronomy 13:06-9
32. Re:And? by Anonymous Coward · 2011-05-09 10:01 · Score: 0
  
  Rumors said it took support from two governments to get them to cooperate.
33. Re:And? by nukem996 · 2011-05-09 11:53 · Score: 1
  
  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 interface.
34. Re:And? by mjwx · 2011-05-09 14:41 · Score: 1
  
  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.
  
  --
  Calling someone a "hater" only means you can not rationally rebut their argument.
35. Re:And? by Anonymous Coward · 2011-05-10 07:50 · Score: 0
  
  Intel?!? Supports Coreboot?!?
  You can't get decent docs out of Intel without a procedure that makes 6 months at Gitmo start looking good. By decent, I mean not actively deceptive with the key pieces removed so you waste your time. Not redacted where you could see that there's something missing, just removed and made to look like it was never there.
  In contrast, AMD actually contributes working code to Coreboot.
36. Re:And? by sjames · 2011-05-10 08:01 · Score: 1
  
  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.
  Once that hard stuff is done, copying the kernel into RAM and jumping to it is a gimme.
37. Re:And? by Anonymous Coward · 2011-05-10 23:58 · Score: 0
  
  In 1996, Linux had gone from IA32 only to supporting IA32 and Dec Alpha. Cyrix chips were supposed to be IA32-compatible, so even if Linux was Intel only, it should still have run on those chips.
  However, I do remember one line from /proc/cpuinfo, which may have been related: "Cyrix Crash Bug: no". If you had one of the buggy Cyrix CPUs, before the workaround was added, that would explain you problem. Not a Linux problem, but a bug in the CPU itself.
  Note: This happened to Intel a few years later. It was called the F00F bug, from the byte sequence that triggered the bug (F0 0F C7 C8).
38. Re:And? by Luyseyal · 2011-05-11 01:17 · Score: 1
  
  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
  
  --
  Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
instant computing by kubitus · 2011-05-09 00:33 · Score: 4, Interesting

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.
1. Re:instant computing by The+MAZZTer · 2011-05-09 00:38 · Score: 2, Insightful
  
  You can't patch ROM, and having an unpatched and unpatchable OS is a bad idea no matter which OS that is.
2. Re:instant computing by datapharmer · 2011-05-09 00:46 · Score: 1
  
  Ummm... You do know that EEPROM can be reflashed right? Might not be a patch but it will fix the problem...
  
  --
  Get a web developer
3. Re:instant computing by RobbieThe1st · 2011-05-09 01:15 · Score: 1
  
  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 you can keep the image in one spot, and sitting on the disk in one long spiral, it will work very fast due to no seek-lag to speak of.
4. Re:instant computing by sgt+scrub · 2011-05-09 01:17 · Score: 1
  
  EEPROM can be reflashed
  Only a limited number of times. :(
  
  --
  Having to work for a living is the root of all evil.
5. Re:instant computing by History's+Coming+To · 2011-05-09 01:25 · Score: 1
  
  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.
  
  --
  Please consider this account deleted, I just can't be bothered with the spam anymore.
6. Re:instant computing by Jesus_666 · 2011-05-09 01:27 · Score: 1
  
  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...
  
  --
  USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
7. Re:instant computing by limaxray · 2011-05-09 01:33 · Score: 2
  
  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.
8. Re:instant computing by sgt+scrub · 2011-05-09 01:46 · Score: 1
  
  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.
  
  --
  Having to work for a living is the root of all evil.
9. Re:instant computing by Anonymous Coward · 2011-05-09 01:59 · Score: 0
  
  So you have an EEPROM Destroyer by Dangerous Prototypes?
  EEPROMs can easily withstand 100000 read write cycles
10. Re:instant computing by couchslug · 2011-05-09 02:18 · Score: 1
  
  Mod up!
  
  --
  "This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
11. Re:instant computing by _0xd0ad · 2011-05-09 02:39 · Score: 2
  
  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...
12. Re:instant computing by kubitus · 2011-05-09 03:40 · Score: 1
  
  what happend to FerrorElectric RAM and all the other promising technologies?
13. Re:instant computing by sgt+scrub · 2011-05-09 04:07 · Score: 1
  
  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
  
  --
  Having to work for a living is the root of all evil.
14. Re:instant computing by gl4ss · 2011-05-09 05:07 · Score: 1
  
  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.
  
  --
  world was created 5 seconds before this post as it is.
15. Re:instant computing by willy_me · 2011-05-09 05:14 · Score: 1
  
  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 implement.
  EEPROM memory is really designed for saving small amounts of data - such as the configuration settings for whatever widget the memory is part of. More expensive to implement and slower but cells can be erased individually thus making it a very convenient feature to have in a microcontroller. If you look at the specs for current microcontrollers you will notice that they tend to include only small amounts of EEPROM with much larger amounts of Flash. This is why.
  Technically they could very well be made of the same components - making you correct. But the support circuitry differs thus making them two different types of memory.
16. Re:instant computing by FutureDomain · 2011-05-09 05:40 · Score: 1
  
  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 since the 1980s. All that's left to do is optimize the operating systems so that they boot faster, and you have a fully functional OS that boots almost as fast as your little Splashtop system, with the ability to install patches and run a browser that's newer than Firefox 2 (the creaky old browser in Splashtop).
  
  --
  Hydraulic pizza oven!! Guided missile! Herring sandwich! Styrofoam! Jayne Mansfield! Aluminum siding! Borax!
17. Re:instant computing by JAlexoi · 2011-05-09 06:31 · Score: 1
  
  what happend to FerrorElectric RAM and all the other promising technologies?
  FerrorElectric RAM had an error in it.
18. Re:instant computing by Anonymous Coward · 2011-05-09 06:55 · Score: 0
  
  Not enough density (yet). Although TI just announced some microcontrollers featuring a few kB of embedded FRAM:
  http://www.ti.com/ww/en/mcu/fram_ultra_low_power_embedded_memory/index.htm?DCMP=FRAM&HQS=Other+PR+fr57xx-pr-lp
19. Re:instant computing by kubitus · 2011-05-09 07:04 · Score: 1
  
  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
20. Re:instant computing by recharged95 · 2011-05-09 08:00 · Score: 1
  
  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.
21. Re:instant computing by parlancex · 2011-05-09 09:32 · Score: 1
  
  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.
22. Re:instant computing by swillden · 2011-05-09 10:55 · Score: 1
  
  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.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
23. Re:instant computing by neonsignal · 2011-05-09 13:43 · Score: 1
  
  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.
24. Re:instant computing by RobbieThe1st · 2011-05-09 14:09 · Score: 1
  
  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.
25. Re:instant computing by Jesus_666 · 2011-05-09 16:35 · Score: 1
  
  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).
  
  --
  USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
26. Re:instant computing by kubitus · 2011-05-09 19:08 · Score: 1
  
  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 )
27. Re:instant computing by rdnetto · 2011-05-09 22:36 · Score: 1
  
  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.
  
  --
  Most human behaviour can be explained in terms of identity.
28. Re:instant computing by _0xd0ad · 2011-05-10 00:45 · Score: 1
  
  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 memory significantly less, not more, so it can't be the explanation for the increase in lifespan of a modern EEPROM as sgt scrub was trying to suggest. The simple fact is that technology has advanced and EEPROM last for far more erase cycles than it used to.
29. Re:instant computing by sjames · 2011-05-10 08:11 · Score: 1
  
  We've come a long way since tanning beds for eproms!
30. Re:instant computing by sjames · 2011-05-10 08:18 · Score: 1
  
  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.
31. Re:instant computing by RobbieThe1st · 2011-05-10 11:21 · Score: 1
  
  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.
32. Re:instant computing by sjames · 2011-05-10 12:31 · Score: 1
  
  It's OK for a splashtop, but in that case, just make it a valid boot image and do nothing special with the BIOS.
33. Re:instant computing by RobbieThe1st · 2011-05-10 18:31 · Score: 1
  
  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.
34. Re:instant computing by sjames · 2011-05-10 20:46 · Score: 1
  
  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.
35. Re:instant computing by RobbieThe1st · 2011-05-11 00:49 · Score: 1
  
  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...
36. Re:instant computing by sjames · 2011-05-11 18:14 · Score: 1
  
  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.
Did I miss something? by TheDarkMaster · 2011-05-09 00:35 · Score: 3, Insightful

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?

--
Religion: The greatest weapon of mass destruction of all time
1. Re:Did I miss something? by clang_jangle · 2011-05-09 00:43 · Score: 1
  
  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.
  
  --
  Caveat Utilitor
2. Re:Did I miss something? by drinkypoo · 2011-05-09 00:45 · Score: 1
  
  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.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
3. Re:Did I miss something? by DrgnDancer · 2011-05-09 00:54 · Score: 2
  
  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 inch square around the very center of the glass. So assuming all you ever wanted to scan was the really small Post-It Notes you were fine.
  Luckily the whole thing had been merely an exercise for me; the scanner worked fine on my Windows box, and I'd only tried to get it working on Linux for the experience. It was pretty shocking to see what constituted "partial support" though. 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 don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
4. Re:Did I miss something? by ThePhilips · 2011-05-09 01:20 · Score: 4, 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.
  
  --
  All hope abandon ye who enter here.
5. Re:Did I miss something? by burnin1965 · 2011-05-09 01:40 · Score: 1
  
  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.
6. Re:Did I miss something? by VortexCortex · 2011-05-09 01:43 · Score: 1
  
  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 not be made available -- I will simply return the device to the store or manufacturer for a full refund.
  I've designed hardware & the drivers that interface with them -- Typically getting my driver to run on another OS is as simple as re-compiling the driver on the new OS, and resolving any OS dependent features. The better you are at this process, the less OS dependent features you build into your hardware/drivers... unless, of course, you don't care if you miss out on a segment of market share.
  If you don't let the hardware vendor know that you want to use it with a given OS -- They won't spend the money to support it. 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.
7. Re:Did I miss something? by TheDarkMaster · 2011-05-09 01:59 · Score: 1
  
  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.
  
  --
  Religion: The greatest weapon of mass destruction of all time
8. Re:Did I miss something? by Kjella · 2011-05-09 02:33 · Score: 1, 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.
  
  --
  Live today, because you never know what tomorrow brings
9. Re:Did I miss something? by VortexCortex · 2011-05-09 03:06 · Score: 1
  
  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 will allow the manufacturer to take advantage of additional market share...
  Alternatively, if a binary for my chosen OS is made available for the hardware, I will continue to use the hardware with my 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. (...) 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.
  First off -- I've never found a manufacturer that could not understand that if they refused to release drivers for my OS, I would be unable to use their hardware... A return to the retail outlet, or to the manufacturer seemed like an acceptable solution rather than keeping the unusable hardware.
  When I first started using Sansa MP3 players there was no system requirement that listed its compatibility with GNU/Linux or BSD/Unix; However, the hardware did work just fine on these free OSs. Today, there's a Tux (penguin) icon on many of the Sandisk products, from MP3 players to USB storage drives. You must (incorrectly) assume that customer communications with a manufacturer never results in their products being actively supported on my OS...
  So, simply because my chosen OS is not listed as supported does not mean it will not work -- Many times the manufacturer did not initially provide support for my OS, and later models ended up having support...
  For instance: I installed Linux on my Toshiba laptop. I had problems getting the built in fingerprint reader to work -- a feature that was important in my purchasing decision. I called support and they told me that the Linux driver was in the process of being released. A week later, I received an e-mail with a link to the open source code for my fingerprint reader.
  My fingerprint reader now works with my chosen OS -- Not in small part because I didn't give up immediately when it did not work out of the box, and also not in small part because many users make inquiries to Toshiba about the state of their Linux hardware support.
  (Additionally, prior to me calling Toshiba, I was able to verify, by way of my own C code, that the fingerprint reader was actually "working" under Linux and Unix, and not defective or broken -- It just needed a driver.)
10. Re:Did I miss something? by DrgnDancer · 2011-05-09 03:23 · Score: 1
  
  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 provided (either through vendors stepping up to the plate and writing them, or hackers reverse engineering them) for most major hardware, it's not unreasonable to think that a similar combination of motherboard manufactures and hackers could eventually provided similar levels of support for Coreboot.
  
  --
  I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
11. Re:Did I miss something? by VortexCortex · 2011-05-09 05:58 · Score: 1
  
  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 objection to is that you present the possibility that hardware working on a machine that is running MS/Windows software and has software drivers that work with MS/Windows, can be found to not work at all when Linux or Unix software is installed as OS for such a system.
  The specific example that you site I especially take issue with, since you have stated that the Linux OS, was functional, and that the hardware worked with Windows, but that the hardware did not work with Linux... I put it to you that this was not the case -- In fact, it was only a matter of an incomplete software implementation that is the source of your stated problem -- Not a hardware issue at all.
  Let me spell it out for you so that you can see the objection for what it is: You have confused Hardware support with Software support, the two are not mutually exclusive, but I do take issue with and point out such confusions.
  I'll grant that people who do not know the difference between hardware and software may think their hardware is incompatible with Linux software -- I do not count you as a member of this group; It is my intention to illustrate that your issue should be with the hardware vendor, which designed the hardware and driver API for that hardware, and Windows compatible software, drivers for that hardware, and intentionally did not support your ability to choose an OS other than Windows -- Otherwise they might have provided a binary for the latest Linux and Unix versions, or source code which others may use to create such binaries (at no cost to the hardware manufacturer).
  Consider that when you purchase hardware, you are not buying it for the driver -- you should be free to use the hardware as you wish, and thus the driver sources really should be provided so that you may support your hardware on new OSs even after the hardware manufacturer stops supporting the hardware.
  To accept otherwise is to agree to let the hardware manufacturer limit your OS choices to the current version of whatever OSs they support (Note: some printers don't work with Vista/7 that do work with XP) -- Unless you take issue with this incompatibility, especially this artificial obsolescence (which, honestly, pales in comparison to the lack of Linux driver support -- 1065 days left for XP, BTW), the OS incompatibility should not be limited to FLOSS OSes...
  To further illustrate my point: s/Linux/Windows7/ and s/Windows/XP/ in your original post; I can claim that the resulting argument is equally true.
12. Re:Did I miss something? by DrgnDancer · 2011-05-09 07:24 · Score: 1
  
  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 hardware that lacks either a) a functional Windows 7 driver or b) an XP driver that works in compatibility mode, I say that the hardware doesn't work with Windows 7. Because for any useful definition of "works", it doesn't. That (b) above is somewhat important by the way. The amount of hardware that has no working compatibility mode drivers is even smaller than the fairly small set of hardware that can't be made to work in Linux. Just as I'm willing to give wireless cards that require nswrapper to work in Linux credit, I give compatibility mode drivers credit in Windows.
  
  --
  I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
13. Re:Did I miss something? by sjames · 2011-05-10 08:23 · Score: 1
  
  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.
14. Re:Did I miss something? by Anonymous Coward · 2011-05-11 07:29 · Score: 0
  
  You sir, are one of the reasons i don't use Linux for anything. The schmuck expression of yourself as a coder and that everything would work just fine if it just was to your satisfaction. Welcome to the dream of humanity: The U.S.S.R.
Lame. by Anonymous Coward · 2011-05-09 00:45 · Score: 0

That means a flexible Free software BIOS replacement with a nice list of benefits.
Of which 99.9% of people will never know nor care about these "benefits". Besides that list of benefits is so lame that 2 of them are just basically reworded versions of themselves to fill the list out.
benefits by Black+Parrot · 2011-05-09 01:02 · Score: 1

with a nice list of benefits.
Apparently protection from slashdotting isn't on the list.

--
Sheesh, evil *and* a jerk. -- Jade
Huh...Initial impression is a little coredumpish.. by ibsteve2u · 2011-05-09 01:07 · Score: 0

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.

--
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
Re:Huh...Initial impression is a little coredumpis by semi-extrinsic · 2011-05-09 01:15 · Score: 1

Hopefully, the guts of your system won't be slashdotted, though...

--
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
Double-edged sword by lennier1 · 2011-05-09 01:19 · Score: 1

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.
1. Re:Double-edged sword by VortexCortex · 2011-05-09 02:02 · Score: 1
  
  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... In addition to the race against time before the bug is patched, you must also realize that as soon as the exploit is released it has a limited life expectancy -- It will elevate the desire to fix the bug it exploits.
  With proprietary systems malware writers can take comfort in the fact that only a limited number of people can actually fix a bug, and that the "responsible disclosure" practice works in the malware author's favor. The limited ability for users to update and/or fix a proprietary system also gives the malware writer a larger window of active exploitation.
  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).
2. Re:Double-edged sword by lennier1 · 2011-05-09 06:16 · Score: 1
  
  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 vulnerable to weaknesses which have been known to the masses for quite some time.
Re:Huh...Initial impression is a little coredumpis by ibsteve2u · 2011-05-09 01:38 · Score: 0

lolll...error was from coreboot.org, not slashdot. I suppose I could "assume" that quality control is tighter on the BIOS side of that organization...

Nah...I assumed that the OEM washers on this Hyper 212+ were "good enough", and the other day after a couple months of running CEP2 flat-out six cores and six threads the cooler cut through the varnish atop some motherboard traces on a P6X58D premium.

Daggone if I hadn't assumed my way right into a system failure.

--
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
Re:Huh...Initial impression is a little coredumpis by ibsteve2u · 2011-05-09 01:48 · Score: 1

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.

--
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
Not exactly by DrYak · 2011-05-09 02:18 · Score: 3, 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.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Can this be used against us? by Compaqt · 2011-05-09 02:21 · Score: 1

Is there any way that this can be used against us?
As in trusted computing? Or any other downsides?
Just asking.

--
I'm not a lawyer, but I play one on the Internet. Blog
1. Re:Can this be used against us? by cpuh0g · 2011-05-09 02:38 · Score: 0
  
  Trusted Computing technology is not necessarily a "downside". The FUD about it being about DRM or denying you the ability to run the OS of choice on your system are just that, FUD. There are some useful applications built on top of TC technology.
2. Re:Can this be used against us? by Anonymous Coward · 2011-05-09 04:18 · Score: 0
  
  So the technology on top of TCP fucks with my freedom and I'm supposed to consider it useful? No way, thanks.
  Saying that Digital Restrictions Management is bad is not FUD, it's a simple fact. You may want to watch this animated short: http://www.lafkon.net/tc/
3. Re:Can this be used against us? by cpuh0g · 2011-05-09 04:53 · Score: 1
  
  How in the world does TC technology "fuck with your freedom"? Please give concrete examples. Microsoft uses it for bitlocker security, but they are not "fucking with your freedom" to wipe it out and install whatever OS you want. TPM devices can be disabled by the platform owner at any time. Also, as I originally wrote, TC != DRM. They are not related. I dont believe there are any mainstream DRM implementations that rely on TPMs to enforce restrictions. It's easy enough to write DRM schemes without it (Apple's FairPlay, for example).
4. Re:Can this be used against us? by gl4ss · 2011-05-09 05:15 · Score: 1
  
  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.
  
  --
  world was created 5 seconds before this post as it is.
5. Re:Can this be used against us? by Xtifr · 2011-05-09 08:16 · Score: 1
  
  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 (PDF).
They could force the issue by gr8_phk · 2011-05-09 02:22 · Score: 1

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 to coreboot. Not saying that is likely to happen, but the first step for any of it is to make sure the support is there. Hopefully the second step - cost saving - will get everyone on board.
Re:Huh...Initial impression is a little coredumpis by Anonymous Coward · 2011-05-09 02:57 · Score: 1

lolll...error was from coreboot.org, not slashdot.

you must be new here
No BSD license? by Anonymous Coward · 2011-05-09 03:00 · Score: 0

If ever there was a case for a BSD license instead of a GPL license, I'd think this would be it.
This is good, but mostly for mobo mfgr by LOTHAR,+of+the+Hill · 2011-05-09 03:18 · Score: 1

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 development.
Buying new HW vs. repurposing existing HW by tepples · 2011-05-09 03:34 · Score: 1

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.
1. Re:Buying new HW vs. repurposing existing HW by VortexCortex · 2011-05-09 06:19 · Score: 1
  
  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 hardware vendor.
  Hardware vendors stopped providing source code when they found that vendor lock-in was acceptable to the unsuspecting masses -- Unsuspect no-longer. Insist on driver source code, even if you don't use a FLOSS OS.
2. Re:Buying new HW vs. repurposing existing HW by tepples · 2011-05-09 07:05 · Score: 1
  
  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?
"Benefits" by rebelwarlock · 2011-05-09 03:34 · Score: 1

Since when is a low level bit of software with no assembler code a "benefit"?
embeded only? by mehemiah · 2011-05-09 04:15 · Score: 1

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.
It's time to push Intel by GPLHost-Thomas · 2011-05-09 04:34 · Score: 1

As described here: http://www.fsf.org/campaigns/free-bios.html
About damn time by Anonymous Coward · 2011-05-09 07:09 · Score: 0

HAL and udev hate my laptop's motherboard (Latitude E6410 system). This is probably because it's a hacked-on "legacy mode" for UEFI. What this means is that under Linux - even with a recent 2.6.38 kernel - I sometimes get nonsensical results like "no batteries and no CPUs present" when I'm running a hyperthreaded dual-core i5 on battery power. Hopefully Coreboot will fix this.
This is highly informatics by Anonymous Coward · 2011-05-11 08:06 · Score: 0

This is highly informatics, crisp and clear. I think that Everything has been described in systematic manner so that reader could get maximum information and learn many things. As i can judge your quality writing.This is one of the best blogs I have read. congrats for a very meaningful efforts.
Las Vegas Foreclosures
Thomas Sabo Bracelets by Anonymous Coward · 2011-05-12 19:25 · Score: 0

pandora sale
links of london
Thomas Sabo Bracelets
Monster Beats
beats by dr dre
Rosetta Stone Spanish