Hi Tom,
On Tue, Jul 31, 2012 at 8:43 PM, Tom Rini <tr...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
