[U-Boot-Users] [id]cache_status looks at wrong bit for MPC8560
Hi, the [id]cache_status functions in the MPC85xx start.S code look at the wrong bit in the L1CSRn registers for the MPC8560. I have a patch for it, but I was wondering if the code is wrong for all 85xx processors, or just the 8560. Rather than me downloading all the 85xx user manuals and checking the register bits (as I am only interested in 8560) I thought I would post here instead. If anyone knows for certain the code is correct or otherwise for other 85xx processors, please let me know. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
If they are wrong on 8560 they are wrong on 85xx since the same code is used for all 85xx.
However, looking at the code my guess is that [id]cache_status return 0 if the caches are off and any non-zero value if they are on. So from that point of view the code appears to be ok. When you say they are looking at the wrong bit, what exactly do you mean?
- kumar
On Jul 14, 2005, at 7:40 PM, Murray.Jensen@csiro.au Murray.Jensen@csiro.au wrote:
Hi, the [id]cache_status functions in the MPC85xx start.S code look at the wrong bit in the L1CSRn registers for the MPC8560. I have a patch for it, but I was wondering if the code is wrong for all 85xx processors, or just the 8560. Rather than me downloading all the 85xx user manuals and checking the register bits (as I am only interested in 8560) I thought I would post here instead. If anyone knows for certain the code is correct or otherwise for other 85xx processors, please let me know. Cheers!
Murray...
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On Fri, 15 Jul 2005 09:27:49 -0500, Kumar Gala writes:
When you say they are looking at the wrong bit, what exactly do you mean?
This code:
srwi r3, r3, 31 /* >>31 => select bit 0 */
looks at the MSB of L1CSRn. It should look at the LSB.
I think the code should be something like this:
andi. r3,r3,1
or maybe:
li r4,1 and r3,r3,r4
if you dont want to touch CR0 (can you modify the CRs whenever you like?).
This reasoning is based on the description of the L1CSRn regs in my MPC8560 manual. I was wondering if this was correct for all MPC85xx processors, or just the 8560 (or maybe my manual is wrong, or I haven't seen an errata). Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
On Jul 15, 2005, at 10:36 AM, Murray.Jensen@csiro.au Murray.Jensen@csiro.au wrote:
On Fri, 15 Jul 2005 09:27:49 -0500, Kumar Gala writes:
When you say they are looking at the wrong bit, what exactly do you mean?
This code:
srwi r3, r3, 31 /* >>31 => select bit 0 */looks at the MSB of L1CSRn. It should look at the LSB.
I think the code should be something like this:
andi. r3,r3,1
This is probably the way to go.
or maybe:
li r4,1 and r3,r3,r4if you dont want to touch CR0 (can you modify the CRs whenever you like?).
CR0 is volatile and thus can be used w/o saving it.
I recommend sending a patch to the list to fix this.
- kumar
participants (2)
-
Kumar Gala -
Murray.Jensen＠csiro.au