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

[Tom Rini]

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