Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

134 comments

BIOS on a processor? (1, Insightful)

Anonymous Coward | more than 3 years ago | (#36070510)

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

Re:BIOS on a processor? (3, Insightful)

vlm (69642) | more than 3 years ago | (#36070982)

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

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

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

Re:BIOS on a processor? (1)

Gbor (1224066) | more than 3 years ago | (#36074942)

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?

Re:BIOS on a processor? (-1, Redundant)

lennier1 (264730) | more than 3 years ago | (#36071002)

*cough* chipset *cough*

Re:BIOS on a processor? (-1)

Anonymous Coward | more than 3 years ago | (#36071100)

Why are you coughing?

Re:BIOS on a processor? (1)

Anonymous Coward | more than 3 years ago | (#36071430)

Bad case of TB.

Re:BIOS on a processor? (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#36071138)

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...

Re:BIOS on a processor? (2)

burnin1965 (535071) | more than 3 years ago | (#36071156)

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

Yes, read TFA.

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

Not exactly (3, Informative)

DrYak (748999) | more than 3 years ago | (#36071618)

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:BIOS on a processor? (1)

Joce640k (829181) | more than 3 years ago | (#36071622)

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

Re:BIOS on a processor? (1)

WorBlux (1751716) | more than 3 years ago | (#36074482)

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.

And? (5, Insightful)

ledow (319597) | more than 3 years ago | (#36070566)

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? (3, Interesting)

dargaud (518470) | more than 3 years ago | (#36070632)

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.

Re:And? (0)

_0xd0ad (1974778) | more than 3 years ago | (#36070662)

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:And? (0)

Anonymous Coward | more than 3 years ago | (#36070814)

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.

Re:And? (1)

_0xd0ad (1974778) | more than 3 years ago | (#36071718)

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".

Re:And? (1)

jimicus (737525) | more than 3 years ago | (#36072904)

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:And? (1)

_0xd0ad (1974778) | more than 3 years ago | (#36074386)

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 [wikipedia.org] (video routines), INT 13h [wikipedia.org] (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.

Re:And? (0)

Anonymous Coward | more than 3 years ago | (#36071000)

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...

Re:And? (1)

VortexCortex (1117377) | more than 3 years ago | (#36071098)

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.

Re:And? (5, Informative)

Barefoot Monkey (1657313) | more than 3 years ago | (#36071988)

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

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

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

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

Re:And? (1)

TheTyrannyOfForcedRe (1186313) | more than 3 years ago | (#36074262)

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:And? (1)

WorBlux (1751716) | more than 3 years ago | (#36074666)

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.

Re:And? (2)

jxself (1210830) | more than 3 years ago | (#36070680)

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:And? (1)

mehrotra.akash (1539473) | more than 3 years ago | (#36070684)

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

Re:And? (2)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#36071184)

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...

Re:And? (0)

Anonymous Coward | more than 3 years ago | (#36070716)

(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.

Re:And? (1)

somersault (912633) | more than 3 years ago | (#36070748)

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? (5, Informative)

oxygene2k2 (615758) | more than 3 years ago | (#36070986)

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

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

Re:And? (1)

dfetter (2035) | more than 3 years ago | (#36071104)

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:And? (0)

Anonymous Coward | more than 3 years ago | (#36071214)

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.

Re:And? (1)

e70838 (976799) | more than 3 years ago | (#36071358)

I guess he has threaten an Intel employee to break his car if he did not give confidential documents.

Re:And? (0)

Anonymous Coward | more than 3 years ago | (#36073762)

DFETTER: that word... I do not believe you know what it means my friend.

OXYGENE2K2: INCONCEIVABLE!

Re:And? (2)

Ant P. (974313) | more than 3 years ago | (#36073844)

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:And? (1)

burnin1965 (535071) | more than 3 years ago | (#36071196)

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

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

They could force the issue (1)

gr8_phk (621180) | more than 3 years ago | (#36071662)

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:And? (1)

Luyseyal (3154) | more than 3 years ago | (#36072240)

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

Re:And? (1)

JamesP (688957) | more than 3 years ago | (#36072532)

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:And? (1)

Runaway1956 (1322357) | more than 3 years ago | (#36073038)

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.

Re:And? (1)

TheTyrannyOfForcedRe (1186313) | more than 3 years ago | (#36074304)

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:And? (1)

Lord Byron II (671689) | more than 3 years ago | (#36074728)

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.

instant computing (4, Interesting)

kubitus (927806) | more than 3 years ago | (#36070644)

the solution for your quick access to the Internet. I have an ASUS P5Q DeLux with Splashtop.

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

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

The rest may come from the disk.

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

Re:instant computing (2, Insightful)

The MAZZTer (911996) | more than 3 years ago | (#36070670)

You can't patch ROM, and having an unpatched and unpatchable OS is a bad idea no matter which OS that is.

Re:instant computing (1)

datapharmer (1099455) | more than 3 years ago | (#36070744)

Ummm... You do know that EEPROM can be reflashed right? Might not be a patch but it will fix the problem...

Re:instant computing (1)

sgt scrub (869860) | more than 3 years ago | (#36071040)

EEPROM can be reflashed

Only a limited number of times. :(

Re:instant computing (2)

limaxray (1292094) | more than 3 years ago | (#36071192)

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.

Re:instant computing (1)

sgt scrub (869860) | more than 3 years ago | (#36071308)

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:instant computing (2)

_0xd0ad (1974778) | more than 3 years ago | (#36071814)

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:instant computing (1)

kubitus (927806) | more than 3 years ago | (#36072450)

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

Re:instant computing (1)

JAlexoi (1085785) | more than 3 years ago | (#36074340)

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

FerrorElectric RAM had an error in it.

Re:instant computing (1)

kubitus (927806) | more than 3 years ago | (#36074648)

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

Re:instant computing (0)

Anonymous Coward | more than 3 years ago | (#36074546)

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

Re:instant computing (1)

sgt scrub (869860) | more than 3 years ago | (#36072758)

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:instant computing (1)

willy_me (212994) | more than 3 years ago | (#36073496)

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.

Re:instant computing (0)

Anonymous Coward | more than 3 years ago | (#36071426)

So you have an EEPROM Destroyer by Dangerous Prototypes?

EEPROMs can easily withstand 100000 read write cycles

Re:instant computing (1)

couchslug (175151) | more than 3 years ago | (#36071614)

Mod up!

Re:instant computing (1)

History's Coming To (1059484) | more than 3 years ago | (#36071116)

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.

Re:instant computing (1)

RobbieThe1st (1977364) | more than 3 years ago | (#36071010)

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.

Re:instant computing (1)

Jesus_666 (702802) | more than 3 years ago | (#36071132)

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...

Re:instant computing (1)

gl4ss (559668) | more than 3 years ago | (#36073412)

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:instant computing (1)

FutureDomain (1073116) | more than 3 years ago | (#36073774)

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).

Did I miss something? (3, Insightful)

TheDarkMaster (1292526) | more than 3 years ago | (#36070656)

Did I miss something?

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

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

Re:Did I miss something? (1)

clang_jangle (975789) | more than 3 years ago | (#36070712)

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.

Re:Did I miss something? (1)

drinkypoo (153816) | more than 3 years ago | (#36070726)

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:Did I miss something? (2)

DrgnDancer (137700) | more than 3 years ago | (#36070786)

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).

Re:Did I miss something? (1)

VortexCortex (1117377) | more than 3 years ago | (#36071276)

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.

Re:Did I miss something? (1, Interesting)

Kjella (173770) | more than 3 years ago | (#36071748)

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:Did I miss something? (1)

VortexCortex (1117377) | more than 3 years ago | (#36072092)

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.)

Re:Did I miss something? (1)

DrgnDancer (137700) | more than 3 years ago | (#36072258)

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.

Re:Did I miss something? (1)

VortexCortex (1117377) | more than 3 years ago | (#36073986)

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.

Re:Did I miss something? (1)

DrgnDancer (137700) | more than 3 years ago | (#36074860)

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.

Buying new HW vs. repurposing existing HW (1)

tepples (727027) | more than 3 years ago | (#36072378)

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:Buying new HW vs. repurposing existing HW (1)

VortexCortex (1117377) | more than 3 years ago | (#36074212)

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.

Re:Buying new HW vs. repurposing existing HW (1)

tepples (727027) | more than 3 years ago | (#36074660)

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? (4, Informative)

ThePhilips (752041) | more than 3 years ago | (#36071076)

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:Did I miss something? (1)

burnin1965 (535071) | more than 3 years ago | (#36071244)

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.

Re:Did I miss something? (1)

TheDarkMaster (1292526) | more than 3 years ago | (#36071428)

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.

Lame. (0)

Anonymous Coward | more than 3 years ago | (#36070724)

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.

angel of mercy appears to support native elders (-1)

Anonymous Coward | more than 3 years ago | (#36070734)

she claims to have come in as if riding on air. she rode her bike today, & arrived as if from above.

disarm your weapons & media. you call this 'weather'? read the teepeeleaks etchings. smarten up, like you're so good at telling people you are. if one is truthful, it shows, so no constant reassurance (unretruthing?) is required. otherwise, it also shows. thank you.

benefits (1)

Black Parrot (19622) | more than 3 years ago | (#36070882)

with a nice list of benefits.

Apparently protection from slashdotting isn't on the list.

Huh...Initial impression is a little coredumpish.. (0)

ibsteve2u (1184603) | more than 3 years ago | (#36070924)

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.

Re:Huh...Initial impression is a little coredumpis (1)

semi-extrinsic (1997002) | more than 3 years ago | (#36071024)

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

Re:Huh...Initial impression is a little coredumpis (0)

ibsteve2u (1184603) | more than 3 years ago | (#36071230)

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.

Re:Huh...Initial impression is a little coredumpis (1)

Anonymous Coward | more than 3 years ago | (#36072018)

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

you must be new here

Re:Huh...Initial impression is a little coredumpis (1)

ibsteve2u (1184603) | more than 3 years ago | (#36071332)

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.

Double-edged sword (1)

lennier1 (264730) | more than 3 years ago | (#36071070)

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:Double-edged sword (1)

VortexCortex (1117377) | more than 3 years ago | (#36071458)

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).

Re:Double-edged sword (1)

lennier1 (264730) | more than 3 years ago | (#36074190)

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.

benefits? (-1)

Anonymous Coward | more than 3 years ago | (#36071642)

In my country we say benefits is when girl does sex with you but she is not wife or girlfriend! And no paying like prostitute.

Can this be used against us? (1)

Compaqt (1758360) | more than 3 years ago | (#36071652)

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

As in trusted computing? Or any other downsides?

Just asking.

Re:Can this be used against us? (0)

cpuh0g (839926) | more than 3 years ago | (#36071808)

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.

Re:Can this be used against us? (0)

Anonymous Coward | more than 3 years ago | (#36072876)

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/ [lafkon.net]

Re:Can this be used against us? (1)

cpuh0g (839926) | more than 3 years ago | (#36073262)

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).

Re:Can this be used against us? (1)

gl4ss (559668) | more than 3 years ago | (#36073510)

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.

No BSD license? (0)

Anonymous Coward | more than 3 years ago | (#36072042)

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 (1)

LOTHAR, of the Hill (14645) | more than 3 years ago | (#36072212)

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.

"Benefits" (1)

rebelwarlock (1319465) | more than 3 years ago | (#36072384)

Since when is a low level bit of software with no assembler code a "benefit"?

embeded only? (1)

mehemiah (971799) | more than 3 years ago | (#36072844)

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.

About damn time (0)

Anonymous Coward | more than 3 years ago | (#36074718)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...