OESF Portables Forum
General Forums => General Discussion => Topic started by: wirawan0 on March 31, 2004, 05:34:56 pm
-
Hi,
I have a z-5600 with pxa250 processor inside (uh...). The question is: has the cache problem been fixed (somehow) for a few later revisions of pxa250?
I\'ve learned that pxa250 has a bug in regard to the cache writeback:
http://www.intel.com/design/pca/applicatio...dt/27853405.pdf (http://www.intel.com/design/pca/applicationsprocessors/specupdt/27853405.pdf)
see issue # 100.
In the same paper, however, it is indicated that the problem has been solved. Does anybody know what this means? My understanding is that for SOME revisions of the pxa250 the problem has been fixed. Is this correct? And if it has been fixed, which was the first revision when the problem was fixed?
I have a great interest to using special kernel 1.3, but hesitate because the potency for cache problem is not clearly stated there (in the documentation).
-
Check out this thread I think it will address and concerns as well as provide a solution. I am running the \"Special Kernel\" mentioned in the thread along with over clocking and it works great. My Z is much more repsonsive with this.
Hope this helps!
Jim
-
In the same paper, however, it is indicated that the problem has been solved. Does anybody know what this means? My understanding is that for SOME revisions of the pxa250 the problem has been fixed. Is this correct? And if it has been fixed, which was the first revision when the problem was fixed?
Well the bug was fixed, but they used that as an opportunity to stop calling it the pxa250 So all pxa250s do suffer from this.
-
Check out this thread I think it will address and concerns as well as provide a solution. I am running the \"Special Kernel\" mentioned in the thread along with over clocking and it works great. My Z is much more repsonsive with this.
Hope this helps!
Jim
Where is the thread or URL?
-
Well the bug was fixed, but they used that as an opportunity to stop calling it the pxa250 So all pxa250s do suffer from this.
Have you checked the Intel\'s document anyway? There are 3 revisions there: B1, B2, and C0 (p. 10-11 there). I suppose that there are some pxa250 out there which are the revision C0. And, just based on my naive thinking, those chips can run the kernel w/o cache errata patch with no problem. Is this the case? Can someone give more clarification?
The fact that there is possibility for the cache bug to come out (for revision B1, B2) is, according to me, \"good enough\" reason to not use the special kernel for now. Don\'t get me wrong--I appreciate the presence of that kernel, and I wish I have time to mess around and try it out, but unfortunately it cannot be in my priority list now.
-
Have you checked the Intel\'s document anyway? There are 3 revisions there: B1, B2, and C0 (p. 10-11 there). I suppose that there are some pxa250 out there which are the revision C0. And, just based on my naive thinking, those chips can run the kernel w/o cache errata patch with no problem. Is this the case? Can someone give more clarification?
The fact that there is possibility for the cache bug to come out (for revision B1, B2) is, according to me, \"good enough\" reason to not use the special kernel for now. Don\'t get me wrong--I appreciate the presence of that kernel, and I wish I have time to mess around and try it out, but unfortunately it cannot be in my priority list now.
It\'s only fixed in C0. You can refer to http://www.intel.com/design/pca/applicatio...dt/27853405.pdf (http://www.intel.com/design/pca/applicationsprocessors/specupdt/27853405.pdf), you\'re looking for #100 on page 12
-
Check out this thread I think it will address and concerns as well as provide a solution. I am running the \"Special Kernel\" mentioned in the thread along with over clocking and it works great. My Z is much more repsonsive with this.
Hope this helps!
Jim
Where is the thread or URL?
Sorry about that here you go!
http://www.zaurususergroup.com/index.php?n...iewtopic&t=2119 (https://www.oesf.org/forums/index.php?showtopic=2119)
-
Is there a way to check the cpu version without opening the case?
This is the output from cpuinfo:
# cat /proc/cpuinfo
Processor : Intel XScale-PXA250 rev 4 (v5l)
BogoMIPS : 397.31
Features : swp half thumb fastmult edsp
CPU implementor : 0x69
CPU architecture: 5TE
CPU variant : 0x0
CPU part : 0x290
CPU revision : 4
Cache type : undefined 5
Cache clean : undefined 5
Cache lockdown : undefined 5
Cache unified : harvard
I size : 16384
I assoc : 16
I line length : 32
I sets : 32
D size : 16384
D assoc : 16
D line length : 32
D sets : 32
Hardware : SHARP Poodle
Revision : 0000
Serial : 0000000000000000
The rom I’m using hasn’t caused me any problems.
zImage_Sharp5600-ROMv1.00_Preemptive-Wireless-Ext-No-PXA250-.bin
-
Hmmm based on the document:
ftp://download.intel.com/design/pca/appli.../278522-001.pdf (http://ftp://download.intel.com/design/pca/applicationsprocessors/manuals/278522-001.pdf)
It would appear that you have a C0 stepping of the PXA250. Take a look at page 33 of the manual and you will find a table (2.2) - they dont specifically mention the C0 stepping but A0 = 00, A1 = 01, B0 = 10, B1 = 11, so I am guessing where yours is 4 then it would appear to be 0100 for C0 given the prior data. The 0x290 value would indicate a PXA250 with XScale core (V3 of the core). Need to check mine out tonight to see which version it is.
-Dan
-
Found some more info on the intel site.
ftp://download.intel.com/design/pcn/proce...rs/d0102973.pdf (http://ftp://download.intel.com/design/pcn/processors/d0102973.pdf)
It appears that the \"Fixed\" C0 stepping was provided as an engineering sample only.
From the doc the pxa250 rev4 is in fact a B2 stepping.
Rev1 A0
Rev2 A1
Rev3 B0
Rev4 B1
Bummer...
Want a working cache, get a pxa255.
-
Bummer is right - I was hoping that would be a C0 in mine but they changed the upper bits from 290 to 2D0 so definitely its a B2.
Thanks for the info.
-Dan
-
Too bad then, that all pxa250\'s on our hand are buggy....
Has anybody had an idea on what risks it poses to use the unpatched kernel? Data corruption on some occassions? It seems from the errata that the bug is not controllable, i.e. no way to work around it through the software. Am I correct?