[U-Boot] [PATCH 01/17] omap3/omap4/omap5/am33xx: Use a common running_from_sdram function

[R, Sricharan]

Hi Tom,

On Tue, Jul 31, 2012 at 8:43 PM, Tom Rini <trini at ti.com> wrote:
> On 07/31/2012 01:33 AM, R, Sricharan wrote:
>> Hi Tom,
>> [snip..]
>>> diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h
>>> index 7f05cb5..c697e0b 100644
>>> --- a/arch/arm/include/asm/arch-omap5/omap.h
>>> +++ b/arch/arm/include/asm/arch-omap5/omap.h
>>> @@ -39,11 +39,6 @@
>>>  #define OMAP54XX_L4_WKUP_BASE  0x4Ae00000
>>>  #define OMAP54XX_L4_PER_BASE   0x48000000
>>>
>>> -#define OMAP54XX_DRAM_ADDR_SPACE_START 0x80000000
>>> -#define OMAP54XX_DRAM_ADDR_SPACE_END   0xFFFFFFFF
>>> -#define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
>>> -#define DRAM_ADDR_SPACE_END    OMAP54XX_DRAM_ADDR_SPACE_END
>>> -
>>   This is a problem for OMAP5, which has  a trap section at 0xFF000000
>>   with in the sdram boundary. OMAP5 evm board has 2GB of memory from
>>   0x80000000 - 0xFFFFFFFF.  Size of the trap section should not be
>> included in the
>>  total sdram size.
>
> But it's not sdram size.  What happens when you're executing at the trap
> section, or rather, where are you executing code from?

   When we execute at trap section address, the system aborts.
   EMIF returns a exception. This is to catch the unmapped tiler
   entries.
    So total size of sdram size calculated should subtract the size
   of trap section if that falls with in the sdram boundary,
   as in case of omap5.  This is taken care in omap_sdram_size
   function.  But with this change the trap section will go un-noticed.

Thanks,
 Sricharan