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

[R, Sricharan]

Correct.
DRAM_ADDR_SPACE_END should be 0xFFFFFFFF for OMAP5.

Thanks,
 Sricharan

On Tue, Jul 31, 2012 at 9:12 PM, Tom Rini <trini at ti.com> wrote:
> On 07/31/2012 08:27 AM, R, Sricharan wrote:
>> 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.
>
> So you're saying the problem is that 0xFF... needs to be included in
> DRAM_ADDR_SPACE on omap5?
>
> --
> Tom