[PATCH] arm: omap: ratelimit omap_l3_smx error log spam

Hi,

On Mon, Aug 27, 2012 at 05:17:30PM -0700, Shilimkar, Santosh wrote:

On Mon, Aug 27, 2012 at 4:26 PM, Aaro Koskinen [off-list ref] wrote:

quoted

I tried bypassing the whole SRAM init, but the device does not seem to
boot up at all.

If I comment out the memset alone, then it boots and the issue is gone:

+#if 0
        memset_io(omap_sram_base + SRAM_BOOTLOADER_SZ, 0,
                  omap_sram_size - SRAM_BOOTLOADER_SZ);
+#endif

Good. So the issue is indeed direct or indirect access to the secure SRAM.
As security can dynamically resize the secure RAM size it is even harder
to fix this issue properly. One easier way to deal with the issue is map only
needed SRAM and leave rest for security.

For now, Can you check if reducing the size of the SRAM in init is helping you
to get way with the issue. Sorry it might need few iterations for you to get
a working SRAM size.

The problem is triggered by writing to the beginning of the SRAM area,
not to the end. I need to skip the first 16k (0x4000) to get rid of
the errors. Maybe the base address calculation is wrong? This could
also explain why it's still possible to use the device - it seems the
allocator starts from the end, and moves towards the base...

A.