AM335X: NEON instructions on framebuffer cause system freeze

Hi,

I will forward this to the SW team.

pastie-10240981.cpp

Andrzej Szombierski said:

Did you manage to reproduce my results?

I have had the same issue with NEON instructions and framebuffer memory. Sometimes I get a few hundred iterations, sometime a few thousand.

I should note that in the example code provided, the storage addresses in the last iteration appear to be written beyond the allocated buffer.

In my application, I'm using chroma-key mask to combine 2D and 3D data, the chroma-key being already in the frame buffer. It is read from the frame buffer and replaces any of the chroma-key value with the  new content. We've had to copy the frame buffer to a temporary buffer, apply the chroma key with NEON instructions, and then copy the image back to the frame buffer. However, using ARM instructions directly in this case is probably more efficient.

Andrzej Szombierski said:

You are right, c+=16, should be moved to the end of the loop.

Obviously it doesn't affect the end result, the processor still freezes as easily.

Hi Boyko,

This problem has resurfaced at my customer:

Two years ago we had a problem when using the AM3354 at 1GHz when we used the NEON co-processor.  We were using 1GHz certified parts.  Using this combination, the processor would occasionally but eventually ‘lock up’.  Everything would stop.  We had no console access; our application wouldn’t respond.  We didn’t get core dumps. The only way we had to get out of this state was to power cycle.  We tried a lot of things to get around the problem.  We compiled the code without enabling NEON; the product worked correctly albeit a bit slower at 1GHz.  We enabled NEON and made a modification to the bootstrap (MLO, u-boot) to drop the processor speed to 800MHz.  Everything worked.  We stuck with the 800MHz solution and NEON.  This gave us an acceptable speed and actually worked a bit better that the 1GHz with NEON combination when it worked.  We started buying the 800MHz version of the AM3354 and we haven’t had any ‘lock-up’ problems since.

Recently, we’ve begun seeing an almost identical problem.  This time it’s in the models running the AM3352 with 800MHz certified processors and NEON turned on.  These models are in production and have been for the last two years.  We reluctantly ran the same experiments we did last time and got the same results.  I say reluctantly because we tried dozens of other things.  We regressed the code, we swapped parts on boards and we tried enabling and disabling different sections code.  Two things fixed the problem; running at 720MHz or running at 800MHz without NEON.  

This is a recent development in hardware.  If we run units with older processor date codes (5xxxxxx or 6xxxxxx) we have no problem running current software on the 800MHz with NEON.  Most units (80% in a small sample) with a later date coded processor (71xxxxW) fail.  There are some that run flawlessly but most fail.  We’ve been very careful with configurations and have been using the same software on all the units.

Linux version 3.2.28 (nellix@1c49b2e0fd24) (gcc version 4.5.4 20120305 (prerelease) (GCC) ) #1 Fri Jul 28 19:11:36 UTC 2017

We have customized the bootstrap and kernel to match our hardware.  I’m displaying a recent build date because we wanted to test with exactly the same software on all models.  Older builds behave the same way.

I talked with some internal apps folks previously and it was postulated that perhaps some clock registers weren't being set right (perhaps memory access speed?).  If you give us some things to try we can try and run this to ground.

Thanks!

Blake