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

2012-07-31 Thread R, Sricharan 
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  0x4Ae0
  #define OMAP54XX_L4_PER_BASE   0x4800

 -#define OMAP54XX_DRAM_ADDR_SPACE_START 0x8000
 -#define OMAP54XX_DRAM_ADDR_SPACE_END   0x
 -#define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
 -#define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
 -
  This is a problem for OMAP5, which has  a trap section at 0xFF00
  with in the sdram boundary. OMAP5 evm board has 2GB of memory from
  0x8000 - 0x.  Size of the trap section should not be
included in the
 total sdram size.

Thanks,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2012-07-31 Thread Tom Rini 
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  0x4Ae0
  #define OMAP54XX_L4_PER_BASE   0x4800

 -#define OMAP54XX_DRAM_ADDR_SPACE_START 0x8000
 -#define OMAP54XX_DRAM_ADDR_SPACE_END   0x
 -#define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
 -#define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
 -
   This is a problem for OMAP5, which has  a trap section at 0xFF00
   with in the sdram boundary. OMAP5 evm board has 2GB of memory from
   0x8000 - 0x.  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?

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2012-07-31 Thread R, Sricharan 
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  0x4Ae0
  #define OMAP54XX_L4_PER_BASE   0x4800

 -#define OMAP54XX_DRAM_ADDR_SPACE_START 0x8000
 -#define OMAP54XX_DRAM_ADDR_SPACE_END   0x
 -#define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
 -#define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
 -
   This is a problem for OMAP5, which has  a trap section at 0xFF00
   with in the sdram boundary. OMAP5 evm board has 2GB of memory from
   0x8000 - 0x.  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

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

2012-07-31 Thread 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 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  0x4Ae0
  #define OMAP54XX_L4_PER_BASE   0x4800

 -#define OMAP54XX_DRAM_ADDR_SPACE_START 0x8000
 -#define OMAP54XX_DRAM_ADDR_SPACE_END   0x
 -#define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
 -#define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
 -
   This is a problem for OMAP5, which has  a trap section at 0xFF00
   with in the sdram boundary. OMAP5 evm board has 2GB of memory from
   0x8000 - 0x.  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

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

2012-07-31 Thread R, Sricharan 
Correct.
DRAM_ADDR_SPACE_END should be 0x 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  0x4Ae0
  #define OMAP54XX_L4_PER_BASE   0x4800

 -#define OMAP54XX_DRAM_ADDR_SPACE_START 0x8000
 -#define OMAP54XX_DRAM_ADDR_SPACE_END   0x
 -#define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
 -#define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
 -
   This is a problem for OMAP5, which has  a trap section at 0xFF00
   with in the sdram boundary. OMAP5 evm board has 2GB of memory from
   0x8000 - 0x.  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

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

2012-07-31 Thread Tom Rini 
On 07/31/2012 08:46 AM, R, Sricharan wrote:
 Correct.
 DRAM_ADDR_SPACE_END should be 0x for OMAP5.

OK, I will just drop this.

 
 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  0x4Ae0
  #define OMAP54XX_L4_PER_BASE   0x4800

 -#define OMAP54XX_DRAM_ADDR_SPACE_START 0x8000
 -#define OMAP54XX_DRAM_ADDR_SPACE_END   0x
 -#define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
 -#define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
 -
   This is a problem for OMAP5, which has  a trap section at 0xFF00
   with in the sdram boundary. OMAP5 evm board has 2GB of memory from
   0x8000 - 0x.  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

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

2012-07-30 Thread Tom Rini 
On all OMAP3+ platforms we know that SDRAM starts at 0x8000 and we
can use 0xD000 as the end.

Signed-off-by: Tom Rini tr...@ti.com
---
 arch/arm/cpu/armv7/omap3/board.c|4 ++--
 arch/arm/cpu/armv7/omap3/sys_info.c |   12 
 arch/arm/include/asm/arch-omap3/sys_proto.h |1 -
 arch/arm/include/asm/arch-omap4/omap.h  |5 -
 arch/arm/include/asm/arch-omap4/sys_proto.h |8 
 arch/arm/include/asm/arch-omap5/omap.h  |5 -
 arch/arm/include/asm/arch-omap5/sys_proto.h |8 
 arch/arm/include/asm/omap_common.h  |   14 ++
 8 files changed, 16 insertions(+), 41 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index f2e52e9..7639bdd 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -177,7 +177,7 @@ void secureworld_exit()
 void try_unlock_memory()
 {
int mode;
-   int in_sdram = is_running_in_sdram();
+   int in_sdram = running_from_sdram();
 
/*
 * if GP device unlock device SRAM for general use
@@ -210,7 +210,7 @@ void try_unlock_memory()
  */
 void s_init(void)
 {
-   int in_sdram = is_running_in_sdram();
+   int in_sdram = running_from_sdram();
 
watchdog_init();
 
diff --git a/arch/arm/cpu/armv7/omap3/sys_info.c 
b/arch/arm/cpu/armv7/omap3/sys_info.c
index 3c80113..a49e84a 100644
--- a/arch/arm/cpu/armv7/omap3/sys_info.c
+++ b/arch/arm/cpu/armv7/omap3/sys_info.c
@@ -240,18 +240,6 @@ u32 is_running_in_sram(void)
return 0;   /* running in FLASH or SDRAM */
 }
 
-/
- *  is_running_in_sdram() - tell if currently running in
- *  SDRAM.
- ***/
-u32 is_running_in_sdram(void)
-{
-   if (get_base()  4)
-   return 1;   /* in SDRAM */
-
-   return 0;   /* running in SRAM or FLASH */
-}
-
 /***
  *  get_boot_type() - Is this an XIP type device or a stream one
  *  bits 4-0 specify type. Bit 5 says mem/perif
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h 
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index 9e52b12..269b8cc 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -57,7 +57,6 @@ u32 get_sysboot_value(void);
 u32 is_gpmc_muxed(void);
 u32 get_gpmc0_type(void);
 u32 get_gpmc0_width(void);
-u32 is_running_in_sdram(void);
 u32 is_running_in_sram(void);
 u32 is_running_in_flash(void);
 u32 get_device_type(void);
diff --git a/arch/arm/include/asm/arch-omap4/omap.h 
b/arch/arm/include/asm/arch-omap4/omap.h
index 03bd923..83d3813 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -42,11 +42,6 @@
 #define OMAP44XX_L4_WKUP_BASE  0x4A30
 #define OMAP44XX_L4_PER_BASE   0x4800
 
-#define OMAP44XX_DRAM_ADDR_SPACE_START 0x8000
-#define OMAP44XX_DRAM_ADDR_SPACE_END   0xD000
-#define DRAM_ADDR_SPACE_START  OMAP44XX_DRAM_ADDR_SPACE_START
-#define DRAM_ADDR_SPACE_ENDOMAP44XX_DRAM_ADDR_SPACE_END
-
 /* CONTROL */
 #define CTRL_BASE  (OMAP44XX_L4_CORE_BASE + 0x2000)
 #define CONTROL_PADCONF_CORE   (OMAP44XX_L4_CORE_BASE + 0x10)
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h 
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index d633573..48a6550 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -67,14 +67,6 @@ void force_emif_self_refresh(void);
  */
 extern struct omap_boot_parameters boot_params;
 
-static inline u32 running_from_sdram(void)
-{
-   u32 pc;
-   asm volatile (mov %0, pc : =r (pc));
-   return ((pc = OMAP44XX_DRAM_ADDR_SPACE_START) 
-   (pc  OMAP44XX_DRAM_ADDR_SPACE_END));
-}
-
 static inline u8 uboot_loaded_by_spl(void)
 {
/*
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  0x4Ae0
 #define OMAP54XX_L4_PER_BASE   0x4800
 
-#define OMAP54XX_DRAM_ADDR_SPACE_START 0x8000
-#define OMAP54XX_DRAM_ADDR_SPACE_END   0x
-#define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
-#define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
-
 /* CONTROL */
 #define CTRL_BASE  (OMAP54XX_L4_CORE_BASE + 0x2000)
 #define CONTROL_PADCONF_CORE   (CTRL_BASE + 0x0800)
diff --git a/arch/arm/include/asm/arch-omap5/sys_proto.h 
b/arch/arm/include/asm/arch-omap5/sys_proto.h
index 74feb90..23b02fd 100644
--- a/arch/arm/include/asm/arch-omap5/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap5/sys_proto.h
@@ -68,14 +68,6 @@ void