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@xxxxxxxxxxxxxx> Product Development Analyst, Genesi USA, Inc. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
