[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[Valeriy Glushkov]

The previous version rebooted forever with DDR bigger than 256MB.
Access the DS1339 RTC chip is on I2C1 bus.
Allow DHCP.

Signed-off-by: Valeriy Glushkov <gvv@lstec.com>
---
 include/configs/MPC8349ITX.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h
index 14cbc45..f1b5566 100644
--- a/include/configs/MPC8349ITX.h
+++ b/include/configs/MPC8349ITX.h
@@ -98,6 +98,7 @@
 #define CONFIG_SYS_I2C_OFFSET		0x3000
 #define CONFIG_SYS_I2C2_OFFSET		0x3100
 #define CONFIG_SYS_SPD_BUS_NUM		1	/* The I2C bus for SPD */
+#define CONFIG_SYS_RTC_BUS_NUM		1	/* The I2C bus for RTC */
 
 #define CONFIG_SYS_I2C_8574_ADDR1	0x20	/* I2C1, PCF8574 */
 #define CONFIG_SYS_I2C_8574_ADDR2	0x21	/* I2C1, PCF8574 */
@@ -158,6 +159,9 @@
 #define CONFIG_SYS_DDR_SDRAM_CLK_CNTL	(DDR_SDRAM_CLK_CNTL_SS_EN | \
 				DDR_SDRAM_CLK_CNTL_CLK_ADJUST_075)
 
+#define CONFIG_VERY_BIG_RAM
+#define CONFIG_MAX_MEM_MAPPED   ((phys_size_t)256 << 20)
+
 #ifdef CONFIG_HARD_I2C
 #define CONFIG_SPD_EEPROM		/* use SPD EEPROM for DDR setup*/
 #endif
@@ -447,6 +451,7 @@ boards, we say we have two, but don't display a message if we find only one. */
 #define CONFIG_CMD_IRQ
 #define CONFIG_CMD_NET
 #define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
 #define CONFIG_CMD_SDRAM
 
 #ifdef CONFIG_COMPACT_FLASH
-- 
1.5.2.5

[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[Kim Phillips]

On Wed,  4 Feb 2009 18:27:49 +0200
Valeriy Glushkov <gvv@lstec.com> wrote:

> The previous version rebooted forever with DDR bigger than 256MB.
> Access the DS1339 RTC chip is on I2C1 bus.
> Allow DHCP.
> 
> Signed-off-by: Valeriy Glushkov <gvv@lstec.com>
> ---
>  include/configs/MPC8349ITX.h |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h
> index 14cbc45..f1b5566 100644
> --- a/include/configs/MPC8349ITX.h
> +++ b/include/configs/MPC8349ITX.h
> @@ -98,6 +98,7 @@
>  #define CONFIG_SYS_I2C_OFFSET		0x3000
>  #define CONFIG_SYS_I2C2_OFFSET		0x3100
>  #define CONFIG_SYS_SPD_BUS_NUM		1	/* The I2C bus for SPD */
> +#define CONFIG_SYS_RTC_BUS_NUM		1	/* The I2C bus for RTC */
>  
>  #define CONFIG_SYS_I2C_8574_ADDR1	0x20	/* I2C1, PCF8574 */
>  #define CONFIG_SYS_I2C_8574_ADDR2	0x21	/* I2C1, PCF8574 */
> @@ -158,6 +159,9 @@
>  #define CONFIG_SYS_DDR_SDRAM_CLK_CNTL	(DDR_SDRAM_CLK_CNTL_SS_EN | \
>  				DDR_SDRAM_CLK_CNTL_CLK_ADJUST_075)
>  
> +#define CONFIG_VERY_BIG_RAM
> +#define CONFIG_MAX_MEM_MAPPED   ((phys_size_t)256 << 20)
> +

Hi Valeriy,

Are you not getting these warnings?:

Configuring for MPC8349ITX board...
In file included from /home/kim/git/u-boot/include/config.h:5,
                 from include/common.h:35:
/home/kim/git/u-boot/include/configs/MPC8349ITX.h:173:1: warning: "CONFIG_MAX_MEM_MAPPED" redefined
In file included from /home/kim/git/u-boot/include/config.h:4,
                 from include/common.h:35:
/home/kim/git/u-boot/include/asm/config.h:28:1: warning: this is the location of the previous definition

please fix.

Kim

[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[Timur Tabi]

On Mon, Feb 16, 2009 at 7:28 PM, Kim Phillips
<kim.phillips@freescale.com> wrote:
> Configuring for MPC8349ITX board...
> In file included from /home/kim/git/u-boot/include/config.h:5,
>                 from include/common.h:35:
> /home/kim/git/u-boot/include/configs/MPC8349ITX.h:173:1: warning: "CONFIG_MAX_MEM_MAPPED" redefined
> In file included from /home/kim/git/u-boot/include/config.h:4,
>                 from include/common.h:35:
> /home/kim/git/u-boot/include/asm/config.h:28:1: warning: this is the location of the previous definition

Becky posted a patch very similar to this, but for all of 86xx.  Maybe
there's some kind of conflict?

Also, shouldn't this change be made for all 83xx, not just this one board?

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[Kumar Gala]

On Feb 17, 2009, at 10:31 AM, Timur Tabi wrote:

> On Mon, Feb 16, 2009 at 7:28 PM, Kim Phillips
> <kim.phillips@freescale.com> wrote:
>> Configuring for MPC8349ITX board...
>> In file included from /home/kim/git/u-boot/include/config.h:5,
>>                from include/common.h:35:
>> /home/kim/git/u-boot/include/configs/MPC8349ITX.h:173:1: warning:  
>> "CONFIG_MAX_MEM_MAPPED" redefined
>> In file included from /home/kim/git/u-boot/include/config.h:4,
>>                from include/common.h:35:
>> /home/kim/git/u-boot/include/asm/config.h:28:1: warning: this is  
>> the location of the previous definition
>
> Becky posted a patch very similar to this, but for all of 86xx.  Maybe
> there's some kind of conflict?
>
> Also, shouldn't this change be made for all 83xx, not just this one  
> board?

The default value is 256M so I don't thing the change is need anymore.

- k

[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[Timur Tabi]

On Tue, Feb 17, 2009 at 3:49 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> The default value is 256M so I don't thing the change is need anymore.

Huh?  I think his patch is supposed to address the fact that 256MB is
the limit, and he wants to add more.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[Kim Phillips]

On Tue, 17 Feb 2009 15:54:52 -0600
Timur Tabi <timur@freescale.com> wrote:

> On Tue, Feb 17, 2009 at 3:49 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> > The default value is 256M so I don't thing the change is need anymore.
> 
> Huh?  I think his patch is supposed to address the fact that 256MB is
> the limit, and he wants to add more.

so this commit started producing warnings for boards that defined their
own CONFIG_MAX_MEM_MAPPED, such as the SIMPC8313 (with 512MB):

commit 87c9063963561d3d01064be34d0c30855a56587b
Author: Kumar Gala <galak@kernel.crashing.org>
Date:   Thu Feb 5 20:40:58 2009 -0600

    ppc: Move CONFIG_MAX_MEM_MAPPED to common config.h
    
    Moved CONFIG_MAX_MEM_MAPPED to the asm/config.h so its kept consistent
    between the two current users (lib_ppc/board.c, 44x SPD DDR2).
    
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
    Acked-by: Stefan Roese <sr@denx.de>

the warnings are:

In file included from /home/r1aaha/git/u-boot/include/config.h:5,
                 from /home/r1aaha/git/u-boot/include/common.h:35,
                 from simpc8313.c:26:
/home/r1aaha/git/u-boot/include/configs/SIMPC8313.h:81:1: warning: "CONFIG_MAX_MEM_MAPPED" redefined
In file included from /home/r1aaha/git/u-boot/include/config.h:4,
                 from /home/r1aaha/git/u-boot/include/common.h:35,
                 from simpc8313.c:26:
/home/r1aaha/git/u-boot/include/asm/config.h:28:1: warning: this is the location of the previous definition

which is probably all due to include/config.h including the file with
the default value prior to the board's config:

/* Automatically generated - do not edit */
#include <asm/config.h>
#include <configs/SIMPC8313.h>

So how are boards supposed to define their own CONFIG_MAX_MEM_MAPPED
now?  In the Makefile?  Or is there a better place for this default
value?

Kim

[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[Kumar Gala]

On Feb 18, 2009, at 3:20 PM, Kim Phillips wrote:

> On Tue, 17 Feb 2009 15:54:52 -0600
> Timur Tabi <timur@freescale.com> wrote:
>
>> On Tue, Feb 17, 2009 at 3:49 PM, Kumar Gala <galak@kernel.crashing.org 
>> > wrote:
>>> The default value is 256M so I don't thing the change is need  
>>> anymore.
>>
>> Huh?  I think his patch is supposed to address the fact that 256MB is
>> the limit, and he wants to add more.
>
> so this commit started producing warnings for boards that defined  
> their
> own CONFIG_MAX_MEM_MAPPED, such as the SIMPC8313 (with 512MB):
>
> commit 87c9063963561d3d01064be34d0c30855a56587b
> Author: Kumar Gala <galak@kernel.crashing.org>
> Date:   Thu Feb 5 20:40:58 2009 -0600
>
>    ppc: Move CONFIG_MAX_MEM_MAPPED to common config.h
>
>    Moved CONFIG_MAX_MEM_MAPPED to the asm/config.h so its kept  
> consistent
>    between the two current users (lib_ppc/board.c, 44x SPD DDR2).
>
>    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>    Acked-by: Stefan Roese <sr@denx.de>
>
> the warnings are:
>
> In file included from /home/r1aaha/git/u-boot/include/config.h:5,
>                 from /home/r1aaha/git/u-boot/include/common.h:35,
>                 from simpc8313.c:26:
> /home/r1aaha/git/u-boot/include/configs/SIMPC8313.h:81:1: warning:  
> "CONFIG_MAX_MEM_MAPPED" redefined
> In file included from /home/r1aaha/git/u-boot/include/config.h:4,
>                 from /home/r1aaha/git/u-boot/include/common.h:35,
>                 from simpc8313.c:26:
> /home/r1aaha/git/u-boot/include/asm/config.h:28:1: warning: this is  
> the location of the previous definition
>
> which is probably all due to include/config.h including the file with
> the default value prior to the board's config:
>
> /* Automatically generated - do not edit */
> #include <asm/config.h>
> #include <configs/SIMPC8313.h>
>
> So how are boards supposed to define their own CONFIG_MAX_MEM_MAPPED
> now?  In the Makefile?  Or is there a better place for this default
> value?

We can probably swap the order of the generated config.h to have <asm/ 
config.h> be second.

- k

[U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed

[Kim Phillips]

On Mon, 16 Feb 2009 19:28:32 -0600
Kim Phillips <kim.phillips@freescale.com> wrote:

> Are you not getting these warnings?:
> 
> Configuring for MPC8349ITX board...
> In file included from /home/kim/git/u-boot/include/config.h:5,
>                  from include/common.h:35:
> /home/kim/git/u-boot/include/configs/MPC8349ITX.h:173:1: warning: "CONFIG_MAX_MEM_MAPPED" redefined
> In file included from /home/kim/git/u-boot/include/config.h:4,
>                  from include/common.h:35:
> /home/kim/git/u-boot/include/asm/config.h:28:1: warning: this is the location of the previous definition

these warnings are no longer occurring, thus applied.

Thanks Valeriy,

Kim