Challenges with off the shelf PC motherboards in embedded systems?

planning

..

It sounds as if you at least have the right sort of budget, if you can seriously consider a custom BIOS. There are a few problems I encountered using PC motherboards - the main one was power. For an embedded system that doesn't use rotating media, the power requirements for the board are going to be (IMHO) unnecessarily complicated. Have you considered an x86-architecture SBC? For reasonable production quantities, this will make the overall BOM cost lower, even though the mobo itself will be more expensive.

Startup time is a big problem on generic PC BIOSes. Take a look at the LinuxBIOS project. I haven't actually used that in a fielded project but I've looked at it briefly. Our x86-based project (at a former employer recently out of business) had a VGA display on it and the option to connect a keyboard if necessary, so we didn't need to get too exotic. And there were more important things to do than try to reduce startup time.

CompactFlash is probably easiest. USB media are doable but your custom BIOS needs to support it as a boot option and your OS needs to be able to cope with its backing store disappearing during USB device enumeration - CF emulates IDE and it's much easier to integrate.

Software

No experience with them. I customized the BIOS on our product using the regular OEM customization tools (startup screens, CMOS defaults).

In the PC industry, component production life time can be quite short varying from a few months to a few years, so if you plan to produce your end products for, say, 5 years or are required to provide replacement systems after that, I think that you should plan for at lest 1-2 motherboard and/or processor changes during your production period (or stock a large number of components for further production, when the end of life for a specific component is announced :-).

When expecting a lot of component changes during a long production run, it would make sense to avoid too much customising, since some of it would have to be repeated at each component change.

I think that the standard BIOS included with the motherboard should usually be enough, since in most cases you should be able to set the how the system behaves when the mains power is applied (automatic boot) and ignore the "keyboard missing" error (or use a keyboard emulator). A VGA chip on the motherboard will also reduce many BIOS complaints about missing display adaptors.

It would also be a good idea to select a motherboard with a well established form factor (but avoiding types that are soon going to go out of production), so that it would be more likely that a similar motherboard with matching outlines would be available, when the production of the original motherboard has ended.

Paul

My employer has been shipping FreeBSD network appliances for almost a decade. Before this employer, I've used Linux for both network appliances and also deeply embedded real-time control systems. None of these systems used a custom BIOS, although at one place I hacked up the stock BIOS with a netboot image until the mobo vendor did it themselves.

Do you have a good idea about acceptable failure rates?

If you're careful, rotating media will work fine and will be hard to beat for price/megabyte. Unless you're going into a very ugly environment, a 2.5" notebook hard drive is fairly rugged. If you're going into a data center, why not use a stock 3.5" drive? It's not the drive hardware you need to worry about - it's what the software does with it. You definitely don't want one big partition that's constantly mounted read/write. In general, the file system isn't your friend ;)

I've also used Compact Flash and found it worked just fine, although I'd recommend *not* letting the OS use it for a swap file. I've found that FlashDrives (an older technology, presents a 2.5" IDE connector) presented a surprisingly high failure rate (over 12% per year). DiskOnChip modules are handy, but you get a single source for those which can always be exciting.

If you've got the money, the aerospace folks have some highly ruggedized solid-state disk emulators. If you've got a lot of money.

Since you have quite modest storage requirements (quarter gig) I feel safe in recommending a high-quality Compact Flash card. Avoid the cheaper manufacturers unless you do per-unit thermal testing :)

About the only really fancy BIOS feature I can think of needing is a completely serial-port accessible BIOS. Most of the hardcore x86 SBC vendors offer this. At the same time, this is mostly a convenience to the service techs, IMHO; we would rather overnight a new unit to a customer than expect them to tweak the BIOS.

As bootloaders go, GRUB (used most often with Linux) is pretty easy to tweak in a variety of ways that might meet your needs. For my company, though, we don't bother much beyond the simplest FreeBSD BTX bootloader (which you can hack in Forth, if you feel inclined). However, our boot process is relatively complicated because we barely trust the hard drive. Once we can load the barest hint of the OS, we go through a bunch of consistency checks before we start loading/starting the system in earnest. Our goal, instead of giving the repair tech a complete CLI with which to repair the system, is to let the machine examine, diagnose, and repair itself, if at all possible. For the rare times it can't, we offer 24 hour replacements.

There are lots of ways you can give the user a good experience. Some of them require expensive hardware and some require complicated software and some of them trade off the engineering with tech support. Knowing which way to go depends on what your customers demand, your corporate goals and your estimated shipping quantity.

Kelly

Have you looked at small form factor boards that utilize the Pentium M or other lower power x86 CPUs? Often they have features you might want such as watchdog and native CF support. ought to give you some ideas in this area.

Like someone else said, maybe the Linux BIOS would be something to look at. Most bios can be customized though to not show anything except a logo so that may fit your needs at a lower cost. There's a variety of ways an emergency shell could be implemented. A lot of vendors in the PC market have a separate, small, and proprietary partition on the boot media that has this kind of function for when windows blows up.

Some kind of solid state Flash for sure. there's CF cards but also look at the solid state disks that plug into a special 44-pin IDE port. Check out But... if possible, be sure that all the partitions on it are mounted read only and it will last virtually forever. The amount of writes this type of memory can take is limited so keep that in mind. You definitely do not want a swap file on there! Depending on data storage needs, a battery backed ram disk may be what you need. There are also the CF form factor micro drives but I'm not sure what the reliability on those is (a mechanical device).

~Jason

--

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com

Hallo Paul,

That is exactly the sore point I have experienced. You have a nice system and two years later you can't buy any more motherboards. Or some card on it becomes unobtainable. Or the manufacturer did some "design improvements" without telling anyone in advance. Version control can also be a huge issue.

SBC, as someone suggested, would be a good idea and I'd at least look into it.

As to the OS I would look for something very mature such as QNX. That one is quite PC friendly, lots of drivers. Since John plans to run it without VGA the OS must have a good crash worthiness as well. "The application performed an illegal operation" with an Ok and cancel button isn't going to cut it under these circumstances.

Regards, Joerg

...

look

Yes, CF cards would be a better choice, in terms of price/performance.

Check

M-system does not make the flash chip. They buy the NAND chips from samsung, same as Lexer CF, for example. M-system is charging a lot more money for the same internal flash memory.

...

Sounds familiar :-)

In the previous year, quite a few manufacturers have changed their 5 V PCI cards (one id-slot) to the 3.3/5 V "universal" PCI card (two id-slots).

In the simplest case, the device driver must be changed to accept the new PCI bridge chip, but at least some new "universal" PCI boards actually require the 3.3 V supply, which might not be available at some very old systems, so in the worst case, you would also have to change the motherboard (and possibly power supply) for the new card to also get 3.3 V.

Paul

You cannot get close to these two factors with an embedded system...but....

If your company is riding on this PHB decision, look for another company.

In what sense is this an embedded system user experience? Maybe if your user is controlling a nuclear power plant. Who has to connect a serial port to configure an embedded system?

Avoid a custom bios. The bios is designed to shelter the executing program from broken hardware and weird peripherals. Even the concept of BIOS is non-embedded. You will end up with a group of "gurus" that have to maintain the bios every time the PC changes. That will be at least once every 3 months.

Again, what kind of embedded system is this? A CLI shell? A Cisco router is not an embedded system. It is a limited volume control system.

Long ago we tried to use a x86 clone, now bought by National and VIA, I forget the company name (maybe Cyrix?). It had a special interrupt to translate "normal" bios calls to their custom calls. The normal clock frequency meant that their audio frequency was slightly off, something no true geek would notice, but a musician did. The processor vendor company, (I don't remember which of the above), did not have source code for this translation code, and did not even know the frequency was off. The Bios guy could do wonders, but what does he do with an undocumented, and invisible instruction trap?

Even with pure Intel MOBOs, (and who would use those when a $2 cheaper version is available?) the lifetime of the MOBO is limited and the lifetime of chips on the MOBO is even more limited. And Intel has cancelled processors in its 5 year embedded chip inventory, way before

5 years is up. What happens when a chipset changes and existing code breaks?

You are screwed. When you get on a chip treadmill where 100s of millions of units are involved, no embedded app matters at all. The big volumes will dance where they will and you will try to keep your toes from being stepped on too often.

Like I said if your company depends on this decision to use a consumer PC MOBO find another company fast.

Regards ~Steve

There is no "x" in my email address.

Thanks for the responses. Lots to think about.

Here are some thoughts based on the replies so far:

1. PHBs No PHBs here - just price/performance constraints.
2. SBCs Single board computers don't meet the price/performance criteria. We are very cost sensitive and need lots of horsepower. Off the shelf motherboards fit the bill.
3. LinuxBIOS LinuxBIOS does not support modern chipsets and also can't boot FreeBSD. We don't want to take on such a large effort as hacking a free BIOS into shape.
4. FreeBSD Our product uses BSD as its base. Has done for years. Now we need to package it up.
5. Compact Flash, mini disks, etc. Thanks for the options. Compact Flash looks good. I'll be doing some experiments with an IDE to CF converter (won't need to be power-on removable). No OS swapping/paging required.
6. Availability of motherboards We expect motherboards to be available for 12-18 months and are prepared for the hassle of transitions. Our motherboard requirements are very basic - we don't need exotic peripherals. If the product succeeds we may very well build our own minimal motherboard (we have very capable hardware guys).
7. Hiding the BIOS We don't want users play with anything that might disable the unit accidentally. That means setting the BIOS parameters at manufacturing time and not letting users near it.

Thanks for the feedback.