On Tue, Aug 28, 2012 at 5:20 AM, Aaro Koskinen <aaro.koskinen@xxxxxx> wrote: > 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 <aaro.koskinen@xxxxxx> wrote: >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
