Xscale PXA255 versus PXA250

I can't tell you whether you'll have any trouble with Linux on PXA255, but I think I'm right in saying that PXA210/250 are discontinued in any case. PXA255 has all of the fixes that accumulated up to stepping C0 of PXA250, but there are still 'errata'.

The Familiar project has ported linux to (at least) an iPAQ 39XX running a PXA255. See

it's an excellent example of open-source development at its best.

Also, here is the Intel info page on the differences. They appear to be binary compatible.

Also, I understand the internal bus on the PX255 is twice as fast as the PXA250.

Hmm, that sounds good if you read it fast. In actual fact, the PXA255 has one clock configuration that has a slightly faster internal bus clock than the original PXA210/250... but the flip side is that only a fraction of the original PXA210/250 range of clock configurations are left as valid and working.

Do not use pxa250! It has LOOOOOTS of hw bugs! I haven't seen the fixed version (pxa255) but pxa250 on 400MHz is slower than the 206MHz StrongARM 1110.

Best Regards,

--
Alexander Popov                  ProSyst Bulgaria Inc.
RTOS Leader                      48 Vladajska Str.
RTOS and JVM			 Sofia 1606, Bulgaria
Phone:  +359 2 952 35 81/203     http://www.prosyst.com
Mobile: +359 87 663 193          OSGi Technology Leaders

PXA255 is not a fixed version of PXA250; a lot of the errata remain but have been converted to documentation and/or specification changes. It's true that some errata are fixed; those that accumulated up to stepping C0 of PXA250.

Despite much PXAxxx-induced hairloss, I have to defend the speed issue. XScale at 400MHz is almost 2 x faster than StrongARM at 206MHz.... but only for register operations (internal). The fact that you don't see any benefit from this speed demonstrates the folly of equating MHz with application performance under an OS; you can still brew a pot cup of coffee in the time it takes for Windows XP to get it's act together after power up... despite a few GHz.

MHz mean nothing unless you have a single-register intensive thread of execution; An OSs running on a 400MHz CPU will waste four times as much time context switching than on a 100Hz CPU. Just about every thing that the microprocessor architects do to speed up execution of instruction sequences makes context swithing more expensive. The same is true of compiler writers.

I absolutely agree with you Tim,

It's clear that the 255 model is not "just" a fixed 250. I'm not an expert, but I think it's normal for a next generation CPU to run faster. When I say faster I mean a general applications performance.

My point was that this is simply not true with the SA11xx and PXA250. The reason, I think, are the kernel workarounds for the hw bugs. Some _simple_ benchmark results (seconds for add, sub, mul and div operations in a while loop - smaller is better):

XScale: Float Double Integer Long

28.672 17.640 0.556 0.558 28.279 17.362 0.561 0.553 28.763 17.387 0.537 0.555

----------------------------------------------------- SA1110: Float Double Integer Long

27.742 13.440 0.985 0.950 27.888 13.509 0.928 0.944 27.904 13.624 0.945 0.871

Obviously the problems come when one uses floating point.

Regards, Alexander

--
Alexander Popov                  ProSyst Bulgaria Inc.
RTOS Leader                      48 Vladajska Str.
RTOS and JVM			 Sofia 1606, Bulgaria
Phone:  +359 2 952 35 81/203     http://www.prosyst.com
Mobile: +359 87 663 193          OSGi Technology Leaders