On Tue, 4 Oct 2011, Rob Herring wrote: > On 10/04/2011 04:21 PM, Nicolas Pitre wrote: > > On Tue, 4 Oct 2011, Santosh Shilimkar wrote: > > > >> On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote: > >>> * Nicolas Pitre <nico@xxxxxxxxxxx> [111003 14:36]: > >>>> On Mon, 3 Oct 2011, Tony Lindgren wrote: > >>>> > >>>>> Having the SRAM base address move around with different sizes also > >>>>> requires the SoC detection.. Otherwise we can end up mapping wrong > >>>>> size and end up trying to access secure SRAM that will hang the system. > >>>>> > >>>>> The way to fix it is to move SRAM init happen much later so we don't > >>>>> have to map it early. I guess now we could use ioremap for SRAM, > >>>>> although we may not want device attributes for the executable code? > >>>>> Got any suggestions here on how we should map SRAM later on? > >>>> > >>>> You can use a variant of ioremap() such as __arm_ioremap() which let you > >>>> specify the memory attribute. > >>> > >>> OK, I'll take a look at that. > >>> > >> I have tried __arm_ioremap_pfn() for some DDR mapping and it didn't > >> work as expected. The mapping was not getting created. > > > > Did you investigate why it wasn't created? Must have been a trivial > > issue surely? But you have to wait until memory management is fully > > initialized to call the real ioremap() though, which happens later > > during the boot. > > > > Isn't ioremap prevented from using main memory now? My point is that the memory allocator has to be fully initialized because memory might need to be allocated when ioremap() is called. At the point where static mappings are created, the regular memory allocator is not available yet. Nicolas -- 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
