Correct. DRAM_ADDR_SPACE_END should be 0xFFFFFFFF for OMAP5. Thanks, Sricharan
On Tue, Jul 31, 2012 at 9:12 PM, Tom Rini <tr...@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 <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
