Just to clarify a few things on the i.MX51 and Efika MX in particular here.
Display support
---------------------
The i.MX51 can support high resolutions under certain circumstances:
this assumes you are not going to be running any video decoding or
using the YUV overlay support, as this tends to cause some horrific
amounts of bandwidth on the display bus that the chip can't adequately
manage (the result is that the display controller has to wait for
activity to cease, which may cause the occasional screen blink under
high bandwidth conditions). The maximum resolution to be able to
utilize every part of the chip without weird things going on is
1280x720 (32-bit RGB display, decoding a 720p video to a 720p YUV
overlay).
Therefore 1280x800 is easily possible but not for anyone who wants to
ship a media capable Netbook. These days any system that can't play a
video reliably isn't going to go very far in consumer space. The
desktop version of the Efika MX runs at 1680x1050MR@60 on many
monitors and should support 1080p30 or 1080p24. Some modes are not
possible due to pixel clock limitations (no mode clocking over 133MHz
DCLK to TMDS rate can be supported. Interlaced video is not supported.
Somewhere in there you can support pretty much everyone, video bus
bandwidth notwithstanding, and it's *absolutely* fine for just
displaying an X desktop.. but nobody wants to just run a 2D desktop,
do they?
The i.MX53 fixes those limitations across the board - it's still
specced only for 1080p30 but the bandwidth available is improved and
there are no pixel clock limitations on the display (it is safely
above the maximum rate required by any CEA-compliant HD display). You
won't have to worry about display size and could run a 17" 1920x1080
panel if you wanted.
Gordan's assertion that we said it would support 1280x720 is entirely
down to the fact that we only tested one panel above 1024x600. He
found that exact panel for purchase.. if someone wants to go in and
add support for a 1600x900 panel, they may by all means! We're not
going to code it for them though.
Memory
-----------
512MB is the maximum on the i.MX51 but the i.MX53 can support 2GB.
Most vendors are going to ship 1GB units, though. That's just a matter
of target market.
Clock Speed
-----------------
1GHz on the i.MX51 is possible but it's only for select customers. The
clock speed has nothing to do with the process, it's perfectly
possible to make a 65nm Cortex-A8 hit >1GHz. You start getting into
the realm of abortive power consumption and it starts to negate the
benefits of increased battery life and low heat, and drives up the
cost of the board.
i.MX53 comes at 1GHz as standard. I think it's a 55nm part?
One thing I have to really disagree with here is the complaining going
on that somehow 800MHz isn't enough, but 1GHz is. I really don't think
you notice the speed difference. It's nominally 20% but in real life,
you don't often see the numbers the math would expect, on any CPU. You
can find benchmarks all round that show an 800MHz Cortex-A8 being
comparable if not faster than a 1.6GHz N450 Atom with reasonably
optimized software.
Not Useful For Developers
-----------------------------------
If you want a 12" 1GHz ARM laptop, someone might make one, but they'd
be almost identical in every setting against x86 except where you had
a need for 12 hours of battery life and are conscious about the weight
of your handbag. This is where the value for money is in ARM Netbooks.
This is where the market is - consumers who like battery life. It is
not in providing the most awesome compiler box. You don't even see
that in the x86 world. Nobody makes systems "just for developers",
except perhaps Genesi :)
In this case, if all you want to do is compile stuff, why not develop
on x86 and use a cross-compiler? I can think of several beautiful
dual-core x86 notebooks that come in 12" models. I actually use a 17"
VAIO and everyone else has a Mac or a dual-core laptop. We
cross-compile. We drop it on the Smartbook and we test... this is how
development is. If we had a 1.5GHz quad-core Cortex-A9 laptop with a
16" screen, I'd still be able to compile kernels faster on a Core i7
(we actually use one of our servers - an 8-core Xeon L5240 with 32GB
RAM - if and when we get bored of using our laptops).
I do however do native compiles just because cross-compiling debian
packages is a pain. It's not that slow, to be honest. I can't think of
any time I've been disappointed with how fast my Smartbook compiles
code. I would sure like it to be faster, but I got Cairo done in a
couple minutes, the OpenGL driver (proprietary and very large) takes
about 20 minutes. Add ccache to a kernel compile and it can take 20
minutes too. Most of my compiles take about 45 seconds because I'm
changing so little each time that only a few files are modified and
the rest is dealt with by dependencies in makefiles. Installing a
package takes about the same as it would on my laptop. A lot of it is
build system overhead, not compiling. Even my laptop takes forever
doing a ./configure script.
Freescale suck at OpenSource compared to TI
--------------------------------------------------------------
They are, no offense intended to either, just as bad as each other,
and both are bound by exactly the same restrictions whereby they
license IP from all over the place and have no legal right to
opensource a lot of what they do. TI have only very recently given a
fig about actually developing decent kernels. Both of them are in
Linaro and both of them are contributing the same amount of support.
--
Matt Sealey <matt(a)genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
