Intel Atom: pros/cons/hazzards?

Hi,

I've rescued a couple of Atom-based SBC's. Essentially diskless workstations.

Am I correct in assuming these are just "yet-another-x86"?

Are there any downsides/upsides/problems to watch for when porting desktop OS's/apps to these sorts of boards? Or, just treat it like any other x86 (686?) for all practical purposes?

Should I accept *more* of them? (within reason) Or, are they just "ho-hum" (dust collectors)?

(Boxes in question are 1.6GHz,

Reply to
Don Y
Loading thread data ...

They are essentially netbook class computers. Atoms have been used extensively in netbooks. I have one that is dog slow running Win7. Browsers especially are hard to use on them. If you have 4 GB that would help a lot, mine only has 1 GB. You seem to be saying yours have less than 4 GB... still 2 is better than 1.

I wouldn't mind having one for a workbench computer to run basic stuff like a serial port terminal. But I think you get them for a non-profit and can't share even for a price.

--

Rick
Reply to
rickman

Mostly. I think they are really a RISC CPU that pretends to be an x86 to the outside world. Intel learned from Itanic... yay backward compatibility! [0]

At the time I was playing with a few of these (about 3-4 years ago), I was using Linux, and it was pretty much just "boot and go"; most of the onboard peripherals were standard enough that they just came up and worked. You could then run regular Linux apps (including X).

The exception was the video drivers. Out of the box, it wasn't any problem getting a text console and the "old standard" VGA modes, like

640x480, 800x600, 1024x768, and so on. If you wanted to run the graphics at full capability, though, you sometimes needed a driver from Intel or the SBC manufacturer, and you would run into the usual problem, which is that their unspecified "Linux driver" depended on a particular kernel version down to the ninth decimal place. I suspect as time marches on, more Linux distributions now ship with suitable drivers. But you still may need to "goose" the kernel with a boot-time command line option to get it to do the right thing.

If I remember right, some of the SBC vendors said you could use a relatively huge heatsink (a few inches on a side) and no fan. Most of them advised at least a small fan.

Upside: you don't have to use 12 gauge wires to power it. :)

They might be good for media PCs, although I don't know if they can do full HD or not. If you have applications that you'd like to dedicate a PC to, like packet radio, weather station support, home automation, or stuff like that, they'd be good for that - low power and either zero or one fans.

Matt Roberds

[0] On the other hand, when they are hooking me up to the machines in the hospital 50 years from now, I fully expect one of them to project "NO ROM BASIC, SYSTEM HALTED" as a hologram, if the quantum storage isn't plugged in at boot time.
Reply to
mroberds

Understood. But, still execute IA instruction set, etc.? (perhaps different opcode timings, no FPU?, etc.)

Exactly. So much for "open" software! :>

I'm not interested in them as graphic workstations. Rather, I would like to use them to replace some of the dedicated machines that I have here. E.g., RDBMS server, audio server, etc. In those roles, I would be happy with a text console (assuming I can't telnet/xdm to the device).

And, as "generic" SBC's that I can use in lieu of custom hardware to prototype some of my algorithms (currently using

1GHz/1GB similar SBC's... though the old ones are probably twice the size, physically, and require an external "brick"). In these roles, no console is necessary (having one would just be overhead as I don't need "video" in those devices)

These have no fan but a cooling pipe to a remote radiator.

Exactly. See above. I've been tentatively targeting ARM at a few hundred MHz (for the system being prototyped) and figure these are roughly the same ballpark ("a small integer factor") given differences in the efficiency of the instruction set, I/O's, etc.

No doubt Bill Gates dressed as Max Headroom!

Reply to
Don Y

Yes.

All fast, modern CISC CPUs are implemented as a sort of RISC CPU and a x86-to-internal-RISC translator. The details of the RISC CPU itself will vary wildly between implementations, and they are invisible to the outside (other than timings) - so you ignore them and treat the chip as a "native" x86 cpu.

Atom chips, AFAIK, all have FPUs - but things like the SSE instruction support will vary from device to device, just as it does on big x86 cpus.

In short, your original assumption - these are just "yet another x86" devices - was correct.

Intel used to be difficult regarding its openness around its graphics chips. These days it is much better. Use a modern kernel, and you'll /probably/ have no problems.

Should be fine - and once you've got the initial installation in place, ssh is usually the best way in (it has several advantages over telnet, even if you are not concerned about security).

Expect more processing power per MHz than an ARM chip, but more variation in latency on I/O. Apart from that, an Atom SBC sounds fine for you use.

Reply to
David Brown
[...]

That was when IP in the Atom chips GPU was held by PowerVR. Thankfully, Intel dumped them and went to their own graphics processor.

Avoid any of the Atoms that utilize PowerVR GPUs. They suck on video performance for the most part, anyway.

formatting link

Graphics performance is quite good on the latest iteration of the Atom platform, code named Baytrail.

Reply to
JW

the outside world. Intel learned from Itanic... yay backward compatibilit y! [0]

top OS's/apps to these sorts of boards?

s using Linux, and it was pretty much just "boot and go"; most of the onboa rd peripherals were standard enough that they just came up and worked. You could then run regular Linux apps (including X).

My HP Atom laptop was built 5 years ago. It has Nivida ION graphic core bui ld-in. It plays full HD video and mp4 well.

em getting a text console and the "old standard" VGA modes, like 640x480, 8

00x600, 1024x768, and so on. If you wanted to run the graphics at full cap ability, though, you sometimes needed a driver from Intel or the SBC manufa cturer, and you would run into the usual problem, which is that their unspe cified "Linux driver" depended on a particular

No, it works out of the box from standard kernel 3.14 and 3.15.

s on, more Linux distributions now ship with suitable drivers. But you stil l may need to "goose" the kernel with a boot-time command line option to ge t it to do the right thing.

No, you don't.

Reply to
edward.ming.lee

Yep. That's exactly how Intel's x86 CPUs have been built for ages.

--
Grant Edwards               grant.b.edwards        Yow! Was my SOY LOAF left 
                                  at               out in th'RAIN?  It tastes 
 Click to see the full signature
Reply to
Grant Edwards

Basically so (taking into account that the "x86" family includes a huge range of architectural implementations and performances.)

Think "Pentium, with most of the newer instruction set additions such as MMX/SSE, but without hardware virtualization support, scaled down to a small and relatively lower-power silicon process, with only modest amounts of on-chip cache."

They usually come with on-chip graphics support (so you don't need a separate graphics card) using a shared-memory implementation. The older ones generally have graphics performance in the "meh" class... fine for server-console use, but sluggish for modern desktop use (e.g. they often don't have multi-plane compositing). If you pick your desktop environment properly, though, and turn off a lot of the fancy "desktop/window visual effects" eye-candy nonsense, they can be quite usable.

Some of the newer Atoms are designed for home-theatre PC applications, and have much faster graphics (often with on-chip video decompression support).

I've been using a small Atom-based motherboard as my home's firewall, web server, domain name-server, DHCP server, and mail server for several years. It works just fine in that application, and the fact that the CPU runs fine without a fan is a definite win. I can do CD-quality audio capture on it (from a turntable and an external ADC board, into a S/PDIF digital input) while it's doing everything else, and it never misses a beat.

Reply to
David Platt

On Wed, 17 Sep 2014 00:46:51 -0700, Don Y Gave us:

If they are the new Atoms, they are made to replace Xeons in single task network server applications.

Even the old ones are nice. Yes they are fully x86-64 compliant IIRC.

All of mine run various Windows OSes. I have 2 Acer Aspire Nettops and use them as HTPCs.

Collect those things you have... sell a few, and buy an established consumer product. Though I do not know if the Atom is still being incorporated into these mini PC form factors any more.

AMD and ARM and others are weighing in. I have a cubox-i4Pro ARM processed 'box', which literally is a tiny box.

formatting link

Reply to
DecadentLinuxUserNumeroUno

Yes.

The timings are almost certainly different than a "real" Pentium or Core or whatever. I am pretty sure the Atoms have an FPU.

If I remember right, the proprietary graphics driver was closed-source. It's entirely possible, and (I am not a lawyer and this is not legal advice) probably within the terms of the GNU GPL, and other open-source licenses, to have proprietary software running "on top of" an open- source OS. It just tends to be a pain in the butt in practice.

They will probably work well for that. If your database is really huge, it might pay to see if you have one that supports SATA 2, and pair it with a SATA 2 disk.

If the test harness isn't completely huge (that is, it doesn't take forever to build on a desktop box), you can even install gcc on the target and not have to mess around with cross-compiling, if you want. I did this when I was messing around with the Atom SBCs.

Matt Roberds

Reply to
mroberds

Correct.

With kernel-driver modules, the consensus agreement seems to be that it's OK if you build your driver as a closed-source "operating system independent" core (a.k.a. a "hardware adaptation layer"), wrapped with a Linux-specific shell that calls into the HAL (and provides callouts for things like memory allocation and I/O scheduling).

As long as the closed-source binary core doesn't make direct use of Linux-specific data structures or code (i.e. it isn't compiled against any of the kernel header files) Linus, at least, seem to be comfortable with this approach, and doesn't feel that it violates the kernel's GPLv2 license.

Similarly, for X11 "driver" libraries, I believe it's consistent with the X11 server licenses used on most Linux distributions to provide closed-source user-mode binary libraries (dynamically loadable on demand).

And, yes, this can all be a big pain in the tail... these proprietary libraries and wrappers aren't always updated in a timely fashion, and can leave you "stuck" running older versions of the kernel or X11 or etc. until an update finally arrives from the vendor (if it ever does).

Reply to
David Platt

I've just had wonderful luck with using Cubie boards for this purpose. Every USB based serial port adapter I've put in 'em Just Works and they have quite a bit of PIO.

I doubt you'll even get down to 1msec latency with them without some knuckle busting ( and never with USB serial ) but gosh they're handy for this. There are a blinding array of peripherals available besides just serial. They run 'C' ( built in gcc ), Tcl, Perl, Python, others.

The RasPi class devices are small enough that this is a significant advantage over an Atom. All you need is a USB style power supply.

--
Les Cargill
Reply to
Les Cargill

No - it will say "PC LOAD LETTER".

--
Les Cargill
Reply to
Les Cargill

I don't *think* these have integrated video. I tried booting a NetBSD system and the video quickly scrambled (hard to see the dmesg output to determine which device was probed at the time). I'll have to make some time to investigate...

Database isn't obscene. It doesn't see many queries but those that it does field tend to be a bit complex (lots of joins, etc.)

Yes, that's what I've already been doing on the various boxes. Lets me build custom kernels for each box's capabilities, etc.

Perhaps next step will be to try a *Windows* install if only to get an enumeration of the various "devices" in the box! Then, use that information to build an appropriate kernel.

Reply to
Don Y

Can't you boot it with the console being another machine over the network?

Just remember that these CPUs would have been top dog some 10 years ago. So anything that would have been easy for that period hardwware should be easy for them now. Well, maybe not. I had a VIA CPU which was clocked around 1.something GHz and it was a dog. I replaced it with a Celeron later and got better performance. It had a passive heat sink, but the PSU still had a fan.

Linux can't do that?

--

Rick
Reply to
rickman

Not all of them. The N270 and N280, for example do not (although it's just a feature that's fused off on those chips). Other things like virtualization and SSE4 (and a few other things) are also not universally supported. Although none of that (except the lack of

64-bit support on a few chips), is any different than that "normal x86s.
Reply to
Robert Wessel

Even assuming the NIC is recognized and autoconfigured, it doesn't

*appear* that the system is surviving this "scrambled video" event.

E.g., dmesg appears in red for this kernel. When the screen goes wonky, I can see the red text that has been scrolling by (correctly) up to this point -- amid a scrambled bunch of "white" video (as if HLock was lost). The red text stops scrolling -- as if the next probed item never got added to the output.

I've been busy with a cheesecake, tonight, so not much "free time" to devote to this problem (beyond the "easy checks")

Some of the boxes I would like to replace are far more capable (e.g., one is a 2U double dual-core machine with ~12G of RAM... but, it's much bigger and more capable than I need -- it just happened to be something "unused" when I pressed it into service)

It, perhaps, can. I just don't run Linux. And, imagine it wasn't *designed* with Linux in mind but, rather, "Windows" (of some flavor). So, I'd expect putting Windows on it would "work" -- at least enough to allow me to inspect its hardware complement.

I'll have to see if I have a smallish 2.5" SATA drive that I can "waste". All I've found so far are > 500GB.

Reply to
Don Y

I designed an Atom Z510 into a product in 2009. I prefer ARM, but there was a requirement to use x86 on this product. The Z510 is still available, but the US15W support chip that's needed to make it do useful work is EOL, with last orders being taken in less than two weeks. Thanks Intel.

A co-worker is currently evaluating replacements, also Atoms. We've tried the new E3800 series Atoms, which look great on paper and maybe will work if we can ever find a BIOS that's mature enough.

We're currently favouring an N2600 Atom, which is a couple of years old, but at least the BIOS and the OS kernel seem to understand the hardware. It's much faster and also hotter than the Z510, but should be fine for our application.

Allan

Reply to
Allan Herriman

*BSD supports serial console for headless boxen. If graphics probing causes problems, then you can disable the relevant drivers without rebuilding the kernel.
--
(Remove the obvious prefix to reply privately.) 
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.