On 07/31/2012 08:27 AM, R, Sricharan wrote: > 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.
So you're saying the problem is that 0xFF... needs to be included in DRAM_ADDR_SPACE on omap5? -- Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
