[U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
From: Aneesh V aneesh@ti.com
Calculate the SDRAM size from DMM configuration registers instead of using hard-coded values. This gives correct values for all different boards.
It's assumed that DMM sections do not overlap memory areas.
Signed-off-by: Aneesh V aneesh@ti.com Tested-by: Steve Sakoman steve@sakoman.com --- arch/arm/cpu/armv7/omap4/board.c | 30 +++++++++++++++++++++++++++++- arch/arm/include/asm/arch-omap4/omap4.h | 10 ++++++++++ 2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c index 195be6e..8c1f395 100644 --- a/arch/arm/cpu/armv7/omap4/board.c +++ b/arch/arm/cpu/armv7/omap4/board.c @@ -30,6 +30,7 @@ #include <common.h> #include <asm/arch/cpu.h> #include <asm/arch/sys_proto.h> +#include <asm/sizes.h>
/* * Routine: s_init @@ -66,6 +67,33 @@ void watchdog_init(void) writel(WD_UNLOCK2, &wd2_base->wspr); }
+ +/* + * This function finds the SDRAM size available in the system + * based on DMM section configurations + * This is needed because the size of memory installed may be + * different on different versions of the board + */ +u32 sdram_size(void) +{ + u32 section, i, total_size = 0, size, addr; + for (i = 0; i < 4; i++) { + section = __raw_readl(DMM_LISA_MAP_BASE + i*4); + addr = section & DMM_LISA_MAP_SYS_ADDR_MASK; + /* See if the address is valid */ + if ((addr >= OMAP44XX_DRAM_ADDR_SPACE_START) && + (addr < OMAP44XX_DRAM_ADDR_SPACE_END)) { + size = ((section & DMM_LISA_MAP_SYS_SIZE_MASK) >> + DMM_LISA_MAP_SYS_SIZE_SHIFT); + size = 1 << size; + size *= SZ_16M; + total_size += size; + } + } + return total_size; +} + + /* * Routine: dram_init * Description: sets uboots idea of sdram size @@ -75,7 +103,7 @@ int dram_init(void) DECLARE_GLOBAL_DATA_PTR;
gd->bd->bi_dram[0].start = 0x80000000; - gd->bd->bi_dram[0].size = 512 << 20; + gd->bd->bi_dram[0].size = sdram_size(); return 0; }
diff --git a/arch/arm/include/asm/arch-omap4/omap4.h b/arch/arm/include/asm/arch-omap4/omap4.h index d0c808d..a30bb33 100644 --- a/arch/arm/include/asm/arch-omap4/omap4.h +++ b/arch/arm/include/asm/arch-omap4/omap4.h @@ -42,6 +42,10 @@ #define OMAP44XX_L4_WKUP_BASE 0x4A300000 #define OMAP44XX_L4_PER_BASE 0x48000000
+#define OMAP44XX_DRAM_ADDR_SPACE_START 0x80000000 +#define OMAP44XX_DRAM_ADDR_SPACE_END 0xD0000000 + + /* CONTROL */ #define CTRL_BASE (OMAP44XX_L4_CORE_BASE + 0x2000) #define CONTROL_PADCONF_CORE (OMAP44XX_L4_CORE_BASE + 0x100000) @@ -66,6 +70,12 @@ /* GPMC */ #define OMAP44XX_GPMC_BASE 0x50000000
+/* DMM */ +#define OMAP44XX_DMM_BASE 0x4E000000 +#define DMM_LISA_MAP_BASE (OMAP44XX_DMM_BASE + 0x40) +#define DMM_LISA_MAP_SYS_SIZE_MASK (7 << 20) +#define DMM_LISA_MAP_SYS_SIZE_SHIFT 20 +#define DMM_LISA_MAP_SYS_ADDR_MASK (0xFF << 24) /* * Hardware Register Details */
On 09/23/2010 04:12 PM, Steve Sakoman wrote:
From: Aneesh Vaneesh@ti.com
Calculate the SDRAM size from DMM configuration registers instead of using hard-coded values. This gives correct values for all different boards.
It's assumed that DMM sections do not overlap memory areas.
How do we handle NOR boot? is it assumed that the configuration will be done way befor the sdram_init?
Signed-off-by: Aneesh Vaneesh@ti.com Tested-by: Steve Sakomansteve@sakoman.com
arch/arm/cpu/armv7/omap4/board.c | 30 +++++++++++++++++++++++++++++- arch/arm/include/asm/arch-omap4/omap4.h | 10 ++++++++++ 2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c index 195be6e..8c1f395 100644 --- a/arch/arm/cpu/armv7/omap4/board.c +++ b/arch/arm/cpu/armv7/omap4/board.c @@ -30,6 +30,7 @@ #include<common.h> #include<asm/arch/cpu.h> #include<asm/arch/sys_proto.h> +#include<asm/sizes.h>
/*
- Routine: s_init
@@ -66,6 +67,33 @@ void watchdog_init(void) writel(WD_UNLOCK2,&wd2_base->wspr); }
+/*
- This function finds the SDRAM size available in the system
- based on DMM section configurations
- This is needed because the size of memory installed may be
- different on different versions of the board
- */
+u32 sdram_size(void) +{
- u32 section, i, total_size = 0, size, addr;
- for (i = 0; i< 4; i++) {
section = __raw_readl(DMM_LISA_MAP_BASE + i*4);addr = section& DMM_LISA_MAP_SYS_ADDR_MASK;/* See if the address is valid */if ((addr>= OMAP44XX_DRAM_ADDR_SPACE_START)&&(addr< OMAP44XX_DRAM_ADDR_SPACE_END)) {size = ((section& DMM_LISA_MAP_SYS_SIZE_MASK)>>DMM_LISA_MAP_SYS_SIZE_SHIFT);size = 1<< size;size *= SZ_16M;total_size += size;}- }
- return total_size;
+}
- /*
- Routine: dram_init
- Description: sets uboots idea of sdram size
@@ -75,7 +103,7 @@ int dram_init(void) DECLARE_GLOBAL_DATA_PTR;
gd->bd->bi_dram[0].start = 0x80000000;
- gd->bd->bi_dram[0].size = 512<< 20;
- gd->bd->bi_dram[0].size = sdram_size(); return 0; }
diff --git a/arch/arm/include/asm/arch-omap4/omap4.h b/arch/arm/include/asm/arch-omap4/omap4.h index d0c808d..a30bb33 100644 --- a/arch/arm/include/asm/arch-omap4/omap4.h +++ b/arch/arm/include/asm/arch-omap4/omap4.h @@ -42,6 +42,10 @@ #define OMAP44XX_L4_WKUP_BASE 0x4A300000 #define OMAP44XX_L4_PER_BASE 0x48000000
+#define OMAP44XX_DRAM_ADDR_SPACE_START 0x80000000 +#define OMAP44XX_DRAM_ADDR_SPACE_END 0xD0000000
- /* CONTROL */ #define CTRL_BASE (OMAP44XX_L4_CORE_BASE + 0x2000) #define CONTROL_PADCONF_CORE (OMAP44XX_L4_CORE_BASE + 0x100000)
@@ -66,6 +70,12 @@ /* GPMC */ #define OMAP44XX_GPMC_BASE 0x50000000
+/* DMM */ +#define OMAP44XX_DMM_BASE 0x4E000000 +#define DMM_LISA_MAP_BASE (OMAP44XX_DMM_BASE + 0x40) +#define DMM_LISA_MAP_SYS_SIZE_MASK (7<< 20) +#define DMM_LISA_MAP_SYS_SIZE_SHIFT 20 +#define DMM_LISA_MAP_SYS_ADDR_MASK (0xFF<< 24) /*
- Hardware Register Details
*/
Dear Nishanth Menon,
In message 4C9E0E7E.7090900@gmail.com you wrote:
How do we handle NOR boot? is it assumed that the configuration will be done way befor the sdram_init?
What do you mean? Which configuration?
Please note that things have changed with the relocation patches; boards should now use get_ram_size() before relating to RAM.
Best regards,
Wolfgang Denk
On Sat, 2010-09-25 at 10:00 -0500, Nishanth Menon wrote:
On 09/23/2010 04:12 PM, Steve Sakoman wrote:
From: Aneesh Vaneesh@ti.com
Calculate the SDRAM size from DMM configuration registers instead of using hard-coded values. This gives correct values for all different boards.
It's assumed that DMM sections do not overlap memory areas.
How do we handle NOR boot? is it assumed that the configuration will be done way befor the sdram_init?
None of the OMAP4 board configs currently supported in u-boot utilize NOR boot.
I would expect that NOR boot patches would be submitted when a board/config that requires it is added. We shouldn't add code for NOR until there is a need.
Steve
Signed-off-by: Aneesh Vaneesh@ti.com Tested-by: Steve Sakomansteve@sakoman.com
arch/arm/cpu/armv7/omap4/board.c | 30 +++++++++++++++++++++++++++++- arch/arm/include/asm/arch-omap4/omap4.h | 10 ++++++++++ 2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c index 195be6e..8c1f395 100644 --- a/arch/arm/cpu/armv7/omap4/board.c +++ b/arch/arm/cpu/armv7/omap4/board.c @@ -30,6 +30,7 @@ #include<common.h> #include<asm/arch/cpu.h> #include<asm/arch/sys_proto.h> +#include<asm/sizes.h>
/*
- Routine: s_init
@@ -66,6 +67,33 @@ void watchdog_init(void) writel(WD_UNLOCK2,&wd2_base->wspr); }
+/*
- This function finds the SDRAM size available in the system
- based on DMM section configurations
- This is needed because the size of memory installed may be
- different on different versions of the board
- */
+u32 sdram_size(void) +{
- u32 section, i, total_size = 0, size, addr;
- for (i = 0; i< 4; i++) {
section = __raw_readl(DMM_LISA_MAP_BASE + i*4);addr = section& DMM_LISA_MAP_SYS_ADDR_MASK;/* See if the address is valid */if ((addr>= OMAP44XX_DRAM_ADDR_SPACE_START)&&(addr< OMAP44XX_DRAM_ADDR_SPACE_END)) {size = ((section& DMM_LISA_MAP_SYS_SIZE_MASK)>>DMM_LISA_MAP_SYS_SIZE_SHIFT);size = 1<< size;size *= SZ_16M;total_size += size;}- }
- return total_size;
+}
- /*
- Routine: dram_init
- Description: sets uboots idea of sdram size
@@ -75,7 +103,7 @@ int dram_init(void) DECLARE_GLOBAL_DATA_PTR;
gd->bd->bi_dram[0].start = 0x80000000;
- gd->bd->bi_dram[0].size = 512<< 20;
- gd->bd->bi_dram[0].size = sdram_size(); return 0; }
diff --git a/arch/arm/include/asm/arch-omap4/omap4.h b/arch/arm/include/asm/arch-omap4/omap4.h index d0c808d..a30bb33 100644 --- a/arch/arm/include/asm/arch-omap4/omap4.h +++ b/arch/arm/include/asm/arch-omap4/omap4.h @@ -42,6 +42,10 @@ #define OMAP44XX_L4_WKUP_BASE 0x4A300000 #define OMAP44XX_L4_PER_BASE 0x48000000
+#define OMAP44XX_DRAM_ADDR_SPACE_START 0x80000000 +#define OMAP44XX_DRAM_ADDR_SPACE_END 0xD0000000
- /* CONTROL */ #define CTRL_BASE (OMAP44XX_L4_CORE_BASE + 0x2000) #define CONTROL_PADCONF_CORE (OMAP44XX_L4_CORE_BASE + 0x100000)
@@ -66,6 +70,12 @@ /* GPMC */ #define OMAP44XX_GPMC_BASE 0x50000000
+/* DMM */ +#define OMAP44XX_DMM_BASE 0x4E000000 +#define DMM_LISA_MAP_BASE (OMAP44XX_DMM_BASE + 0x40) +#define DMM_LISA_MAP_SYS_SIZE_MASK (7<< 20) +#define DMM_LISA_MAP_SYS_SIZE_SHIFT 20 +#define DMM_LISA_MAP_SYS_ADDR_MASK (0xFF<< 24) /*
- Hardware Register Details
*/
Hi Nishanth
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of Nishanth Menon Sent: Saturday, September 25, 2010 8:30 PM To: Steve Sakoman Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
On 09/23/2010 04:12 PM, Steve Sakoman wrote:
From: Aneesh Vaneesh@ti.com
Calculate the SDRAM size from DMM configuration registers instead
of using
hard-coded values. This gives correct values for all different
boards.
It's assumed that DMM sections do not overlap memory areas.
How do we handle NOR boot? is it assumed that the configuration will be done way befor the sdram_init?
I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init().
Best regards, Aneesh
Dear "V, Aneesh",
In message FF55437E1F14DA4BAEB721A458B6701706FCA3B7C0@dbde02.ent.ti.com you wrote:
I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init().
If you have to deal with boards which may come with different memory sizes, these may need different initializations. I don't know your hardware - you may or may not be able to read the needed configuration from the hardware. Eventually you need to try out different configurations, in which case the SDRAM initialization has to be part of the RAM initialization code (as it has to be retried for each possible configuration).
Best regards,
Wolfgang Denk
On 09/26/2010 03:39 AM, V, Aneesh wrote:
Hi Nishanth
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of Nishanth Menon Sent: Saturday, September 25, 2010 8:30 PM To: Steve Sakoman Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
On 09/23/2010 04:12 PM, Steve Sakoman wrote:
From: Aneesh Vaneesh@ti.com
Calculate the SDRAM size from DMM configuration registers instead
of using
hard-coded values. This gives correct values for all different
boards.
It's assumed that DMM sections do not overlap memory areas.
How do we handle NOR boot? is it assumed that the configuration will be done way befor the sdram_init?
I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init().
thanks for the clarification.. NOR boot is usually going to have initial part in XIP -> we'd traditionally relocate to SDRAM before the call to sdram_size() happens.
Regards, Nishanth Menon
Dear Nishanth Menon,
In message 4C9F3E4F.3040403@gmail.com you wrote:
I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init().
thanks for the clarification.. NOR boot is usually going to have initial part in XIP -> we'd traditionally relocate to SDRAM before the call to sdram_size() happens.
Yes, this was the way how many ARM boards id, and this is what I'm trying to explain: this is WRONG.
SDRAM configuration must be done while still running from NOR, i. e. before relocation. Only then free reconfiguration, auto-sizing etc. is possible.
Best regards,
Wolfgang Denk
On Sun, 2010-09-26 at 16:37 +0200, Wolfgang Denk wrote:
Dear Nishanth Menon,
In message 4C9F3E4F.3040403@gmail.com you wrote:
I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init().
thanks for the clarification.. NOR boot is usually going to have initial part in XIP -> we'd traditionally relocate to SDRAM before the call to sdram_size() happens.
Yes, this was the way how many ARM boards id, and this is what I'm trying to explain: this is WRONG.
SDRAM configuration must be done while still running from NOR, i. e. before relocation. Only then free reconfiguration, auto-sizing etc. is possible.
I'll make sure that this is done properly when(if?) a patch series for an OMAP4 board with NOR boot is prepared.
Getting back to the subject patch, though :-)
This patch fixes a bug in the current Panda board support in rc2. Without this patch U-boot will return an erroneous size for available RAM. We should consider it for inclusion as soon as practical.
Regards,
Steve
On 09/26/2010 09:57 AM, Steve Sakoman wrote:
On Sun, 2010-09-26 at 16:37 +0200, Wolfgang Denk wrote:
Dear Nishanth Menon,
In message4C9F3E4F.3040403@gmail.com you wrote:
I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init().
thanks for the clarification.. NOR boot is usually going to have initial part in XIP -> we'd traditionally relocate to SDRAM before the call to sdram_size() happens.
Yes, this was the way how many ARM boards id, and this is what I'm trying to explain: this is WRONG.
SDRAM configuration must be done while still running from NOR, i. e. before relocation. Only then free reconfiguration, auto-sizing etc. is possible.
I'll make sure that this is done properly when(if?) a patch series for an OMAP4 board with NOR boot is prepared.
Getting back to the subject patch, though :-)
This patch fixes a bug in the current Panda board support in rc2. Without this patch U-boot will return an erroneous size for available RAM. We should consider it for inclusion as soon as practical.
I tend to agree, I might rather have my panda functioning properly and improve the location of sdram_size read at a later point of time -> for cleanups, we should probably start with the mux stuff..
That said, can we compromise by adding a FIXME: comment so that we dont really forget to fix it later on?
Regards, Nishanth Menon
Dear Wolfgang Denk,
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Sunday, September 26, 2010 8:07 PM To: Nishanth Menon Cc: V, Aneesh; u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
Dear Nishanth Menon,
In message 4C9F3E4F.3040403@gmail.com you wrote:
I think you are referring to SDRAM initialization. Yes, it is
assumed
that SDRAM initialization(at least the DMM part of it) is done
before
the call to sdram_size(). The right location for this seems to be the initial part of sdram_init().
thanks for the clarification.. NOR boot is usually going to have
initial
part in XIP -> we'd traditionally relocate to SDRAM before the
call to
sdram_size() happens.
Yes, this was the way how many ARM boards id, and this is what I'm trying to explain: this is WRONG.
SDRAM configuration must be done while still running from NOR, i. e. before relocation. Only then free reconfiguration, auto-sizing etc. is possible.
We shall rework the patch to do SDRAM size calculation as part of 'lowlevel_init' that is called before relocation. I hope that should solve the problem.
Please note that we are always running from SDRAM because none of the OMAP4 boards so far have any XIP device.
Regarding true run-time detection of SDRAM size and configuration: We do not support it today. However, LPDDR2 supports Mode Registers that have size info and our memory controller can read it. This coupled with the base AC timings specified by the LPDDR2 spec creates the possibility of doing a truly run-time detection and configuration of SDRAM that works for all boards. I was indeed thinking of trying it out sometime. Please note that the base AC timing values may not be optimal for all memory parts.
Best regards, Aneesh
Dear Wolfgang Denk,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of V, Aneesh Sent: Monday, September 27, 2010 12:03 PM To: Wolfgang Denk; Nishanth Menon Cc: u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
Dear Wolfgang Denk,
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Sunday, September 26, 2010 8:07 PM To: Nishanth Menon Cc: V, Aneesh; u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
Dear Nishanth Menon,
In message 4C9F3E4F.3040403@gmail.com you wrote:
I think you are referring to SDRAM initialization. Yes, it is
assumed
that SDRAM initialization(at least the DMM part of it) is done
before
the call to sdram_size(). The right location for this seems to be the initial part of sdram_init().
thanks for the clarification.. NOR boot is usually going to have
initial
part in XIP -> we'd traditionally relocate to SDRAM before the
call to
sdram_size() happens.
Yes, this was the way how many ARM boards id, and this is what I'm trying to explain: this is WRONG.
SDRAM configuration must be done while still running from NOR, i.
e.
before relocation. Only then free reconfiguration, auto-sizing
etc.
is possible.
We shall rework the patch to do SDRAM size calculation as part of 'lowlevel_init' that is called before relocation. I hope that should solve the problem.
I realize that gd will not be setup at this point of time. So, I would propose keeping the same patch. sdram_size() can be called at any point of time as SDRAM is initialized by the time u-boot starts. We can do whatever extra needed to support the new relocation scheme once those patches are upstream.
Please note that we are always running from SDRAM because none of the OMAP4 boards so far have any XIP device.
Regarding true run-time detection of SDRAM size and configuration: We do not support it today. However, LPDDR2 supports Mode Registers that have size info and our memory controller can read it. This coupled with the base AC timings specified by the LPDDR2 spec creates the possibility of doing a truly run-time detection and configuration of SDRAM that works for all boards. I was indeed thinking of trying it out sometime. Please note that the base AC timing values may not be optimal for all memory parts.
Best regards, Aneesh
Dear "V, Aneesh",
In message FF55437E1F14DA4BAEB721A458B6701706FCA3B8E5@dbde02.ent.ti.com you wrote:
SDRAM configuration must be done while still running from NOR, i. e. before relocation. Only then free reconfiguration, auto-sizing etc. is possible.
We shall rework the patch to do SDRAM size calculation as part of 'lowlevel_init' that is called before relocation. I hope that should solve the problem.
No. This is not where it belongs. RAM initialization is done by the dram_init() function, which is an entry in the init_sequence[] array; see arch/arm/lib/board.c
Please note that we are always running from SDRAM because none of the OMAP4 boards so far have any XIP device.
I see.
Best regards,
Wolfgang Denk
On Mon, 2010-09-27 at 11:02 +0200, Wolfgang Denk wrote:
Dear "V, Aneesh",
In message FF55437E1F14DA4BAEB721A458B6701706FCA3B8E5@dbde02.ent.ti.com you wrote:
SDRAM configuration must be done while still running from NOR, i. e. before relocation. Only then free reconfiguration, auto-sizing etc. is possible.
We shall rework the patch to do SDRAM size calculation as part of 'lowlevel_init' that is called before relocation. I hope that should solve the problem.
No. This is not where it belongs. RAM initialization is done by the dram_init() function, which is an entry in the init_sequence[] array; see arch/arm/lib/board.c
Please note that we are always running from SDRAM because none of the OMAP4 boards so far have any XIP device.
I see.
I fear that all this discussion of what might happen someday with a XIP NOR implementation on OMAP4 may have distracted from the consideration of this patch for a real problem on today's hardware! The current Panda implementation returns an incorrect value for system ram size.
The subject patch does indeed set the ram size properly in the OMAP4 specific dram_init() function. As Wolfgang says above, this is the proper place. If there are no other objections we should try to get this integrated.
Regards,
Steve
Dear Steve Sakoman,
In message 1285622277.4705.43.camel@quadra you wrote:
The subject patch does indeed set the ram size properly in the OMAP4 specific dram_init() function. As Wolfgang says above, this is the proper place. If there are no other objections we should try to get this integrated.
It's ok with me. Just waiting for a pull request.
24 hours to go.
Best regards,
Wolfgang Denk
On Mon, 2010-09-27 at 23:37 +0200, Wolfgang Denk wrote:
Dear Steve Sakoman,
In message 1285622277.4705.43.camel@quadra you wrote:
The subject patch does indeed set the ram size properly in the OMAP4 specific dram_init() function. As Wolfgang says above, this is the proper place. If there are no other objections we should try to get this integrated.
It's ok with me. Just waiting for a pull request.
24 hours to go.
Thanks Wolfgang.
Copying Sandeep so he knows he has to work fast :-)
Steve
Dear Sandeep,
In message 1285623705.4705.45.camel@quadra Steve Sakoman wrote:
On Mon, 2010-09-27 at 23:37 +0200, Wolfgang Denk wrote:
Dear Steve Sakoman,
In message 1285622277.4705.43.camel@quadra you wrote:
The subject patch does indeed set the ram size properly in the OMAP4 specific dram_init() function. As Wolfgang says above, this is the proper place. If there are no other objections we should try to get this integrated.
It's ok with me. Just waiting for a pull request.
24 hours to go.
Thanks Wolfgang.
Copying Sandeep so he knows he has to work fast :-)
Ping???
Best regards,
Wolfgang Denk
participants (5)
-
Nishanth Menon -
Paulraj, Sandeep -
Steve Sakoman -
V, Aneesh -
Wolfgang Denk