Intel Atom: pros/cons/hazzards?

In sci.electronics.design Don Y <this@is.not.me.com> wrote:
> On 9/17/2014 1:21 AM, mroberds@att.net wrote:
>
>> I think they are really a RISC CPU that pretends to be an x86 to the
>> outside world.
>
> Understood.  But, still execute IA instruction set, etc.?

Yes.

> (perhaps different opcode timings, no FPU?, etc.)

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

>> 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.
>
> Exactly.  So much for "open" software!  :>

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.

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

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.

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

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

In article <lvcvbp$i2o$3@dont-email.me>,  <mroberds@att.net> wrote:

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

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

rickman wrote:
> On 9/17/2014 3:46 AM, Don Y wrote:
>> 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, <4G DDR2, with all the
>> typical "PC" I/O's)
>
> 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.

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.

 >  But I think you get them for a non-profit
> and can't share even for a price.
>

-- 
Les Cargill

mroberds@att.net wrote:
> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>> Am I correct in assuming these are just "yet-another-x86"?
>
> 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]
>
>> Are there any downsides/upsides/problems to watch for when porting
>> desktop OS's/apps to these sorts of boards?
>
> 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.  :)
>
>> Should I accept *more* of them?  (within reason)
>
> 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.
>


No - it will say "PC LOAD LETTER".

-- 
Les Cargill

On 9/17/2014 2:44 PM, mroberds@att.net wrote:
> In sci.electronics.design Don Y <this@is.not.me.com> wrote:

>>> 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.
>>
>> Exactly.  So much for "open" software!  :>
>
> 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.

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

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

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

>> And, as "generic" SBC's that I can use in lieu of custom hardware to
>> prototype some of my algorithms
>
> 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.

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.

On 9/18/2014 3:28 AM, Don Y wrote:
> On 9/17/2014 2:44 PM, mroberds@att.net wrote:
>> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>
>>>> 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.
>>>
>>> Exactly.  So much for "open" software!  :>
>>
>> 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.
>
> 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...

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


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

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.


>>> And, as "generic" SBC's that I can use in lieu of custom hardware to
>>> prototype some of my algorithms
>>
>> 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.
>
> 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.

Linux can't do that?

-- 

Rick

On Wed, 17 Sep 2014 13:33:47 -0700, DecadentLinuxUserNumeroUno
<DLU1@DecadentLinuxUser.org> wrote:

>On Wed, 17 Sep 2014 00:46:51 -0700, Don Y <this@is.not.me.com> Gave us:
>
>>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, <4G DDR2, with all the
>>typical "PC" I/O's)
>>
>>Thx,
>>--don
>
>
>  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.


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.

On 9/18/2014 12:41 AM, rickman wrote:
> On 9/18/2014 3:28 AM, Don Y wrote:
>> On 9/17/2014 2:44 PM, mroberds@att.net wrote:
>>> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>>
>>> 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.
>>
>> 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...
>
> Can't you boot it with the console being another machine over the network?

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

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

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)

>>>> And, as "generic" SBC's that I can use in lieu of custom hardware to
>>>> prototype some of my algorithms
>>>
>>> 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.
>>
>> 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.
>
> Linux can't do that?

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.

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

> 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, <4G DDR2, with all the typical "PC"
> I/O's)
> 
> Thx,
> --don


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

Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>:
> On 9/17/2014 2:44 PM, mroberds@att.net wrote:
>> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>
>>>> 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.
>>>
>>> Exactly.  So much for "open" software!  :>
>>
>> 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.
>
> 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...

*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/