2010-02-25 04:35:50 Ssync for CONFIG_EXACT_HWERR in entry.S _trap can trigger Blackfin stall anomaly
Andrew Rook (UNITED KINGDOM)
Message: 86529
This is a report of a Blackfin anomaly problem which is effectively caused by a bug in linux-2.6.x/arch/blackfin/mach-common/entry.S. This was seen with code from the 2009R1 release, but the relevant code is the same in the SVN trunk.
On a custom board (based on the BF533 Stamp) using the BF533 silicon rev 0.5, the Blackfin core was found to stall indefinitely when running the kernel with two custom device drivers which both made frequent SPI bus accesses, while
several user-space processes were also running.
On using GDB with the gnICE JTAG emulator to halt, the PC was found to always be at the ssync instruction at entry.S line 490 for CONFIG_EXACT_HWERR in _trap. EXCAUSE in the SEQSTAT register indicated that a data CPLB miss exception was being processed.
Attempting to immediately start the core running again in GDB had no effect, while using GDB to disassemble memory around the PC value and then starting the core running caused the code to run, with a Hardware Error exception occurring shortly afterwards.
Hence it seems that the ssync instruction was triggering a Blackfin silicon anomaly, probably 05000283 although the behaviour did not exactly match the description of that anomaly (as the Emulation event from gnICE was handled correctly).
Moving the ssync instruction for CONFIG_EXACT_HWERR to immediately after the work-around code for anomalies 05000283 and 05000315 prevented the core stall occurring, as did disabling CONFIG_EXACT_HWERR in the kernel configuration.
Hence I am suggesting that you consider moving the ssync instruction for CONFIG_EXACT_HWERR in entry.S _trap to after the anomaly work-around, in the SVN trunk and in the SVN 2009R1 branch.
QuoteReplyEditDelete
2010-02-25 13:16:39 Re: Ssync for CONFIG_EXACT_HWERR in entry.S _trap can trigger Blackfin stall anomaly
Robin Getz (UNITED STATES)
Message: 86549
Andrew:
Thanks for the report - committed to trunk and branch.
-Robin
QuoteReplyEditDelete
2010-02-26 05:17:02 Re: Ssync for CONFIG_EXACT_HWERR in entry.S _trap can trigger Blackfin stall anomaly
Andrew Rook (UNITED KINGDOM)
Message: 86598
Robin,
The changed entry.S in the 2009R1 branch (SVN rev 8358) fails to compile because it uses macro ANOMALY_283_315_WORKAROUND() but arch/blackfin/include/asm/entry.h in the 2009R1 branch actually has that macro called ANOMALY_05000283_WORKAROUND() rather than ANOMALY_283_315_WORKAROUND().
Also, the ANOMALY_05000283_WORKAROUND() macro in the 2009R1 branch ends with 3 nop instructions and a comment that they are to prevent anomaly 05000244. Macro ANOMALY_283_315_WORKAROUND() in entry.h of the SVN trunk does not have those nop instructions, so it would seem that the ssync instruction for CONFIG_EXACT_HWERR immediately after the ANOMALY_283_315_WORKAROUND() macro could trigger anomaly 05000244 on a vulnerable Blackfin part in the trunk.
Hence it might be worth adding the nop instructions within the CONFIG_EXACT_HWERR code in _trap before the ssync instruction in the trunk version of entry.S, possibly using conditional compile like macro NOP_PAD_ANOMALY_05000244 in arch/blackfin/include/asm/irq.h.
-----
Unrelated to the above, there does not seem to be any explicit work-around code in the kernel for Blackfin anomaly 05000258 (Instruction cache is corrupted when bits 9 and 12 of the ICPLB Data registers differ), except for defining macro ANLOMALY_05000258 for relevant Blackfin parts.
Bit 12 of the ICPLB data register is given by define CPLB_L1_CHBL and the recommended work-around (at least for the BF531/2/3) is to set bit 9 the same as bit 12. However, CPLB_L1_CHBL is also used for DCPLB data registers, so it can't be re-defined as bits 12 and 9.
For the NOMPU build of the 2009R1 branch kernel, I think it is enough to add (CPLB_L1_CHBL >> 3) to #define SDRAM_IGENERIC as the work-around.
I have not fully investigated the MPU build (CONFIG_MPU) of the 2009R1 branch kernel, but it would seem that it is actually using ANOMALY_05000158_WORKAROUND (which is 0x200 or 0) when generating ICPLB values. Anomaly 05000158 is documented as only applying to DCPLB Data registers, but using it for ICPLB Data registers would give the anomaly 05000258 work-around.
I have not investigated the code in the SVN trunk, but it doesn't seem to have any explicit work-arounds for anomaly 05000258, although it may also be using ANOMALY_05000158_WORKAROUND for that.
Andrew Rook
QuoteReplyEditDelete
2010-02-26 08:17:49 Re: Ssync for CONFIG_EXACT_HWERR in entry.S _trap can trigger Blackfin stall anomaly
Robin Getz (UNITED STATES)
Message: 86607
Andrew:
Sorry about that -- should be OK now.
258 is worked aound in the CPLB code - by making sure those bits are equal. (At least that is the way I thought it worked - I'll have to have a deeper look later this afternoon.)
If you are concerned about anomaly workarounds - have a look at
https://docs.blackfin.uclinux.org/doku.php?id=bfin:anomalies
It's autogenerated from the kernel source.
-Robin
QuoteReplyEditDelete
2010-03-01 07:58:51 Re: Ssync for CONFIG_EXACT_HWERR in entry.S _trap can trigger Blackfin stall anomaly
Andrew Rook (UNITED KINGDOM)
Message: 86666
Robin,
arch/blackfin/mach-common/entry.S in the SVN 2009R1 branch (rev 8363) still fails to compile, due to a syntax error in line 501 now.
#ifdef (ANOMALY_05000283 || ANOMALY_05000315) && ANOMALY_05000244
should be
#if (ANOMALY_05000283 || ANOMALY_05000315) && ANOMALY_05000244
(I assume you are all far too busy to do regression builds and testing on the SVN branch, so I am just reporting the error to avoid giving problems to anybody else who picks up changes from the SVN branch.)
Andrew Rook
QuoteReplyEditDelete
2010-03-01 08:58:38 Re: Ssync for CONFIG_EXACT_HWERR in entry.S _trap can trigger Blackfin stall anomaly
Robin Getz (UNITED STATES)
Message: 86670
Andrew:
Sorry - I need to be a little more careful...
Thanks
-Robin