On Tue, Aug 28, 2012 at 5:20 AM, Aaro Koskinen [off-list ref] wrote:

Hi,

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

quoted

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...

Or the PPA has resized the secure area of 16K. As you have seen the issue
on one OMAP3 device, it makes sense to takeout that 16K from the public
SRAM map.

Can you send the patch with fixed base address fir PUB SRAM ?

Regards
Santosh