On Monday 08 February 2010, Måns Rullgård wrote:
Siarhei Siamashka siarhei.siamashka@gmail.com writes:
On Sunday 07 February 2010, Tom wrote:
Siarhei Siamashka wrote:
725233: PLD instructions executed with PLD data forwarding enabled can result in a processor deadlock
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com
Please add a detailed comment on the errata.
The short summary is pretty much complete (PLD data forwarding is not working correctly and needs to be turned off to prevent problems). Though it really makes sense to add that:
- only r1pX revisions of Cortex-A8 are affected
- performance impact is practically non-existant
The detailed description of this erratum is available in the official Cortex-A8 errata list. I'm not sure about directly copying full erratum description text here. Anyway, this workaround would be better submitted by somebody TI. I'm just "guilty" of triggering this deadlock with some ARM NEON optimizations from pixman library, so feel a bit of responsibility for it too.
Also looks like this jumping to ROM code. Can this be done without a ROM code call ?
I just added it to the part of code which is already doing similar things (sets L1NEON and other bits from AUXCR with some icky looking assembly via ROM code call). Most likely it can be also done in some other way.
L2AUX is only writable in secure mode, which on GP devices implies using a ROM call. Nothing wrong with that.
OK, thanks for the clarification. Can I add you to Acked-by field in the soon to be resubmitted patch with updated comment?
I just remembered the following patch and had a doubt for a second: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
Have not tested this yet (IBE bit is set from u-boot on my beagleboard at the moment), but apparently the MCR instruction used in that kernel patch has no effect on OMAP3 and setting IBE bit in u-boot is also required for anybody who wants to have thumb support which is not totally broken. Additionally it would be nice to do something about related Cortex-A8 erratas #687067 and #454179. The status of L1 System Array Debug Register on the beagleboard is particularly interesting.
Maybe it is a good time to do a full review of all the needed workarounds and update the u-boot code responsible for applying them on omap3 devices?