[U-Boot] [PATCH] mx51evk: support new relocation scheme

[U-Boot] [PATCH] mx51evk: support new relocation scheme

[Shawn Guo]

The patchset is to support new relocation scheme and fix the build
breakage on master introduced by the relocation scheme.

It depends on the following patch from Jason to fix build error
introduced by incorrect u-boot.lds.

    MX5: use common u-boot.lds of cpu layer
    http://lists.denx.de/pipermail/u-boot/2010-October/079926.html

The patchset was tested on mx51evk 3.0 board.

Shawn Guo (2):
 [PATCH 1/2] mx51evk: support new relocation scheme
 [PATCH 2/2] mx51evk: correct internal RAM base address

 arch/arm/include/asm/arch-mx5/imx-regs.h |    2 +-
 board/freescale/mx51evk/mx51evk.c        |    6 +++---
 include/configs/mx51evk.h                |    5 ++++-
 3 files changed, 8 insertions(+), 5 deletions(-)

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Shawn Guo]

This patch is to fix build breakage and support new relocatoin
scheme for mx51evk.

 - It includes imx-regs.h in mx51evk.h, so that CSD0_BASE_ADDR and
   IRAM_BASE_ADDR can be referred to.
 - It uses i.mx51 internal RAM as the init stack, as the internal
   RAM is totally free from ROM code when u-boot lives.

Signed-off-by: Shawn Guo <shawn.gsc@gmail.com>
---
 board/freescale/mx51evk/mx51evk.c |    6 +++---
 include/configs/mx51evk.h         |    5 ++++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/board/freescale/mx51evk/mx51evk.c b/board/freescale/mx51evk/mx51evk.c
index c8d7d39..8820698 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -52,9 +52,9 @@ u32 get_board_rev(void)
 
 int dram_init(void)
 {
-	gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
-	gd->bd->bi_dram[0].size = get_ram_size((long *)PHYS_SDRAM_1,
-			PHYS_SDRAM_1_SIZE);
+	/* dram_init must store complete ramsize in gd->ram_size */
+	gd->ram_size = get_ram_size((volatile void *)CONFIG_SYS_SDRAM_BASE,
+				PHYS_SDRAM_1_SIZE);
 	return 0;
 }
 
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 6165473..82f364d 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -24,11 +24,11 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#include <asm/arch/imx-regs.h>
 
  /* High Level Configuration Options */
 
 #define CONFIG_MX51	/* in a mx51 */
-#define CONFIG_SKIP_RELOCATE_UBOOT
 
 #define CONFIG_SYS_MX5_HCLK	24000000
 #define CONFIG_SYS_MX5_CLK32		32768
@@ -175,6 +175,9 @@
 #define PHYS_SDRAM_1		CSD0_BASE_ADDR
 #define PHYS_SDRAM_1_SIZE	(512 * 1024 * 1024)
 
+#define CONFIG_SYS_SDRAM_BASE	PHYS_SDRAM_1
+#define CONFIG_SYS_INIT_SP_ADDR	(IRAM_BASE_ADDR + 0x1000)
+
 #define CONFIG_SYS_DDR_CLKSEL	0
 #define CONFIG_SYS_CLKTL_CBCDR	0x59E35100
 
-- 
1.7.1

[U-Boot] [PATCH 2/2] mx51evk: correct internal RAM base address

[Shawn Guo]

i.mx51 internal RAM starts from 0x1FFE0000 than 0x1FFE8000

Signed-off-by: Shawn Guo <shawn.gsc@gmail.com>
---
 arch/arm/include/asm/arch-mx5/imx-regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 3ddda40..bcab3db 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -26,7 +26,7 @@
 /*
  * IRAM
  */
-#define IRAM_BASE_ADDR		0x1FFE8000	/* internal ram */
+#define IRAM_BASE_ADDR		0x1FFE0000	/* internal ram */
 /*
  * Graphics Memory of GPU
  */
-- 
1.7.1

[U-Boot] [PATCH 2/2] mx51evk: correct internal RAM base address

[Jason Liu]

HI, Shawn

2010/10/25 Shawn Guo <shawn.gsc@gmail.com>:
> i.mx51 internal RAM starts from 0x1FFE0000 than 0x1FFE8000

Correctly speaking, i.mx51 TO1 SCCv2 RAM strart from 0x1FF80000  TO3
should be starting from 0x1FFE0000
Maybe you need fix the commit log and state it clearly.

>
> Signed-off-by: Shawn Guo <shawn.gsc@gmail.com>
> ---
> ?arch/arm/include/asm/arch-mx5/imx-regs.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/asm/arch-mx5/imx-regs.h
> index 3ddda40..bcab3db 100644
> --- a/arch/arm/include/asm/arch-mx5/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
> @@ -26,7 +26,7 @@
> ?/*
> ?* IRAM
> ?*/
> -#define IRAM_BASE_ADDR ? ? ? ? 0x1FFE8000 ? ? ?/* internal ram */
> +#define IRAM_BASE_ADDR ? ? ? ? 0x1FFE0000 ? ? ?/* internal ram */
> ?/*
> ?* Graphics Memory of GPU
> ?*/
> --
> 1.7.1
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] [PATCH v2 2/2] mx51evk: correct internal RAM base address

[Shawn Guo]

The internal RAM starts from 0x1FFE0000 on final revsion i.mx51
than 0x1FFE8000 which is for older revision.

Signed-off-by: Shawn Guo <shawn.gsc@gmail.com>
---
Changes for v2:
 Rewrite the commit message for a better change log.

 arch/arm/include/asm/arch-mx5/imx-regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 3ddda40..bcab3db 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -26,7 +26,7 @@
 /*
  * IRAM
  */
-#define IRAM_BASE_ADDR		0x1FFE8000	/* internal ram */
+#define IRAM_BASE_ADDR		0x1FFE0000	/* internal ram */
 /*
  * Graphics Memory of GPU
  */
-- 
1.7.1

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Stefano Babic]

On 10/25/2010 05:14 PM, Shawn Guo wrote:

> +#define CONFIG_SYS_SDRAM_BASE	PHYS_SDRAM_1
> +#define CONFIG_SYS_INIT_SP_ADDR	(IRAM_BASE_ADDR + 0x1000)

What is the meaning of the offset at 0x1000 ? Is there something at
IRAM_BASE_ADDR ?

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Shawn Guo]

Hi Stefano,

On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
> On 10/25/2010 05:14 PM, Shawn Guo wrote:
>
>> +#define CONFIG_SYS_SDRAM_BASE ? ? ? ?PHYS_SDRAM_1
>> +#define CONFIG_SYS_INIT_SP_ADDR ? ? ?(IRAM_BASE_ADDR + 0x1000)
>
> What is the meaning of the offset at 0x1000 ? Is there something at
> IRAM_BASE_ADDR ?
>
I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
which decrease the address.  Is it not the case?

-- 
Regards,
Shawn

[U-Boot] [PATCH 2/2] mx51evk: correct internal RAM base address

[Stefano Babic]

On 10/25/2010 07:02 PM, Jason Liu wrote:
> HI, Shawn
> 
> 2010/10/25 Shawn Guo <shawn.gsc@gmail.com>:
>> i.mx51 internal RAM starts from 0x1FFE0000 than 0x1FFE8000
> 
> Correctly speaking, i.mx51 TO1 SCCv2 RAM strart from 0x1FF80000

0x1FFE8000, you mean.

>  TO3
> should be starting from 0x1FFE0000
> Maybe you need fix the commit log and state it clearly.

Then there could be a problem. If we set the IRAM as for TO3, u-boot
does not run on boards with TO1 (never seen) and TO2 (I used a board
with it. Freescale sold several boards with TO2, so I do not think we
can simply drop it). The stackpointer used before the relocation should
be in an area common at least for TO2 and TO3.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 2/2] mx51evk: correct internal RAM base address

[Shawn Guo]

Hi Stefano,

On Tue, Oct 26, 2010 at 4:07 PM, Stefano Babic <sbabic@denx.de> wrote:
> Then there could be a problem. If we set the IRAM as for TO3, u-boot
> does not run on boards with TO1 (never seen) and TO2 (I used a board
> with it. Freescale sold several boards with TO2, so I do not think we
> can simply drop it). The stackpointer used before the relocation should
> be in an area common at least for TO2 and TO3.
>
TO2 and TO3 shares the same memory map, so IRAM starts from 0x1FFE0000
on both TO2 and TO3.

-- 
Regards,
Shawn

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Stefano Babic]

On 10/26/2010 10:05 AM, Shawn Guo wrote:
> Hi Stefano,
> 
> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
>> On 10/25/2010 05:14 PM, Shawn Guo wrote:
>>
>>> +#define CONFIG_SYS_SDRAM_BASE        PHYS_SDRAM_1
>>> +#define CONFIG_SYS_INIT_SP_ADDR      (IRAM_BASE_ADDR + 0x1000)
>>
>> What is the meaning of the offset at 0x1000 ? Is there something at
>> IRAM_BASE_ADDR ?
>>
> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
> which decrease the address.  Is it not the case?
> 

Yes, my doubt is due to the fact that we do not set the SP at the end of
the IRAM and we set it to an arbitrary address in between.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Shawn Guo]

On Tue, Oct 26, 2010 at 4:14 PM, Stefano Babic <sbabic@denx.de> wrote:
> On 10/26/2010 10:05 AM, Shawn Guo wrote:
>> Hi Stefano,
>>
>> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
>>> On 10/25/2010 05:14 PM, Shawn Guo wrote:
>>>
>>>> +#define CONFIG_SYS_SDRAM_BASE ? ? ? ?PHYS_SDRAM_1
>>>> +#define CONFIG_SYS_INIT_SP_ADDR ? ? ?(IRAM_BASE_ADDR + 0x1000)
>>>
>>> What is the meaning of the offset at 0x1000 ? Is there something at
>>> IRAM_BASE_ADDR ?
>>>
>> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
>> which decrease the address. ?Is it not the case?
>>
>
> Yes, my doubt is due to the fact that we do not set the SP at the end of
> the IRAM and we set it to an arbitrary address in between.
>
At this point, IRAM is totally free for u-boot to use, so I simply
reserved 4 KB from start.


-- 
Regards,
Shawn

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Heiko Schocher]

Hello Stefano,

Stefano Babic wrote:
> On 10/26/2010 10:05 AM, Shawn Guo wrote:
>> Hi Stefano,
>>
>> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
>>> On 10/25/2010 05:14 PM, Shawn Guo wrote:
>>>
>>>> +#define CONFIG_SYS_SDRAM_BASE        PHYS_SDRAM_1
>>>> +#define CONFIG_SYS_INIT_SP_ADDR      (IRAM_BASE_ADDR + 0x1000)
>>> What is the meaning of the offset at 0x1000 ? Is there something at
>>> IRAM_BASE_ADDR ?
>>>
>> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
>> which decrease the address.  Is it not the case?
>>
> 
> Yes, my doubt is due to the fact that we do not set the SP at the end of
> the IRAM and we set it to an arbitrary address in between.

We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE
- CONFIG_SYS_GBL_DATA_SIZE)

Don;t know if IRAM_BASE_SIZE exists ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Shawn Guo]

Hi Heiko,

On Tue, Oct 26, 2010 at 4:25 PM, Heiko Schocher <hs@denx.de> wrote:
> Hello Stefano,
>
> Stefano Babic wrote:
>> On 10/26/2010 10:05 AM, Shawn Guo wrote:
>>> Hi Stefano,
>>>
>>> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
>>>> On 10/25/2010 05:14 PM, Shawn Guo wrote:
>>>>
>>>>> +#define CONFIG_SYS_SDRAM_BASE ? ? ? ?PHYS_SDRAM_1
>>>>> +#define CONFIG_SYS_INIT_SP_ADDR ? ? ?(IRAM_BASE_ADDR + 0x1000)
>>>> What is the meaning of the offset at 0x1000 ? Is there something at
>>>> IRAM_BASE_ADDR ?
>>>>
>>> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
>>> which decrease the address. ?Is it not the case?
>>>
>>
>> Yes, my doubt is due to the fact that we do not set the SP at the end of
>> the IRAM and we set it to an arbitrary address in between.
>
> We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE
> - CONFIG_SYS_GBL_DATA_SIZE)
>
Since u-boot is running in external memory, shouldn't
CONFIG_SYS_GBL_DATA_SIZE be using the external memory space other than
IRAM?

-- 
Regards,
Shawn

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Stefano Babic]

On 10/26/2010 10:25 AM, Heiko Schocher wrote:
> Hello Stefano,
> 
> Stefano Babic wrote:
>> On 10/26/2010 10:05 AM, Shawn Guo wrote:
>>> Hi Stefano,
>>>
>>> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
>>>> On 10/25/2010 05:14 PM, Shawn Guo wrote:
>>>>
>>>>> +#define CONFIG_SYS_SDRAM_BASE        PHYS_SDRAM_1
>>>>> +#define CONFIG_SYS_INIT_SP_ADDR      (IRAM_BASE_ADDR + 0x1000)
>>>> What is the meaning of the offset at 0x1000 ? Is there something at
>>>> IRAM_BASE_ADDR ?
>>>>
>>> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
>>> which decrease the address.  Is it not the case?
>>>
>>
>> Yes, my doubt is due to the fact that we do not set the SP at the end of
>> the IRAM and we set it to an arbitrary address in between.
> 
> We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE
> - CONFIG_SYS_GBL_DATA_SIZE)

Agree, this is what I set for the vision2 board. We should be consistent
and do the same for the mx51evk.

> 
> Don;t know if IRAM_BASE_SIZE exists ...

we must define it. I set it in the board configuration file, but it is
wrong. The value should be moved into register definition file for the
SoC (imx-regs.h)

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Heiko Schocher]

Hello Shawn,

Shawn Guo wrote:
> Hi Heiko,
> 
> On Tue, Oct 26, 2010 at 4:25 PM, Heiko Schocher <hs@denx.de> wrote:
>> Hello Stefano,
>>
>> Stefano Babic wrote:
>>> On 10/26/2010 10:05 AM, Shawn Guo wrote:
>>>> Hi Stefano,
>>>>
>>>> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
>>>>> On 10/25/2010 05:14 PM, Shawn Guo wrote:
>>>>>
>>>>>> +#define CONFIG_SYS_SDRAM_BASE        PHYS_SDRAM_1
>>>>>> +#define CONFIG_SYS_INIT_SP_ADDR      (IRAM_BASE_ADDR + 0x1000)
>>>>> What is the meaning of the offset at 0x1000 ? Is there something at
>>>>> IRAM_BASE_ADDR ?
>>>>>
>>>> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
>>>> which decrease the address.  Is it not the case?
>>>>
>>> Yes, my doubt is due to the fact that we do not set the SP at the end of
>>> the IRAM and we set it to an arbitrary address in between.
>> We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE
>> - CONFIG_SYS_GBL_DATA_SIZE)
>>
> Since u-boot is running in external memory, shouldn't
> CONFIG_SYS_GBL_DATA_SIZE be using the external memory space other than
> IRAM?

U-Boot uses only before relocation the sp @CONFIG_SYS_INIT_SP_ADDR.
This is for example for boards, which boots from NOR flash, and they
have no working RAM before relocation. So Stackpointer should be setup
in some none SDRAM. After relocation, Stackpointer is setup in SDRAM,
and CONFIG_SYS_INIT_SP_ADDR is not longer used.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Heiko Schocher]

Hello Stefano,

Stefano Babic wrote:
> On 10/26/2010 10:25 AM, Heiko Schocher wrote:
>> Hello Stefano,
>>
>> Stefano Babic wrote:
>>> On 10/26/2010 10:05 AM, Shawn Guo wrote:
>>>> Hi Stefano,
>>>>
>>>> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
>>>>> On 10/25/2010 05:14 PM, Shawn Guo wrote:
>>>>>
>>>>>> +#define CONFIG_SYS_SDRAM_BASE        PHYS_SDRAM_1
>>>>>> +#define CONFIG_SYS_INIT_SP_ADDR      (IRAM_BASE_ADDR + 0x1000)
>>>>> What is the meaning of the offset at 0x1000 ? Is there something at
>>>>> IRAM_BASE_ADDR ?
>>>>>
>>>> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
>>>> which decrease the address.  Is it not the case?
>>>>
>>> Yes, my doubt is due to the fact that we do not set the SP at the end of
>>> the IRAM and we set it to an arbitrary address in between.
>> We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE
>> - CONFIG_SYS_GBL_DATA_SIZE)
> 
> Agree, this is what I set for the vision2 board. We should be consistent
> and do the same for the mx51evk.

Yep.

>> Don;t know if IRAM_BASE_SIZE exists ...
> 
> we must define it. I set it in the board configuration file, but it is
> wrong. The value should be moved into register definition file for the
> SoC (imx-regs.h)

Full-Ack. This is a SoC define, not board dependend.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Shawn Guo]

On Tue, Oct 26, 2010 at 4:34 PM, Stefano Babic <sbabic@denx.de> wrote:
> On 10/26/2010 10:25 AM, Heiko Schocher wrote:
>> We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE
>> - CONFIG_SYS_GBL_DATA_SIZE)
>
> Agree, this is what I set for the vision2 board. We should be consistent
> and do the same for the mx51evk.
>
>>
>> Don;t know if IRAM_BASE_SIZE exists ...
>
> we must define it. I set it in the board configuration file, but it is
> wrong. The value should be moved into register definition file for the
> SoC (imx-regs.h)
>
I see many other platforms using 0x1000 offset way to define
CONFIG_SYS_INIT_SP_ADDR, so I did that to make it a little bit more
common.  But I'm fine to start from the end, and will send v3 of this
patch soon.

-- 
Regards,
Shawn

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Reinhard Meyer]

Dear Shawn Guo,
> On Tue, Oct 26, 2010 at 4:34 PM, Stefano Babic <sbabic@denx.de> wrote:
>> On 10/26/2010 10:25 AM, Heiko Schocher wrote:
>>> We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE
>>> - CONFIG_SYS_GBL_DATA_SIZE)
>> Agree, this is what I set for the vision2 board. We should be consistent
>> and do the same for the mx51evk.
>>
>>> Don;t know if IRAM_BASE_SIZE exists ...
>> we must define it. I set it in the board configuration file, but it is
>> wrong. The value should be moved into register definition file for the
>> SoC (imx-regs.h)
>>
> I see many other platforms using 0x1000 offset way to define
> CONFIG_SYS_INIT_SP_ADDR, so I did that to make it a little bit more
> common.  But I'm fine to start from the end, and will send v3 of this
> patch soon.

I just tried to add the symbolic version

#define CONFIG_SYS_INIT_SP_ADDR (xxx_SRAM_BASE + xxx_SRAM_SIZE - CONFIG_SYS_GBL_DATA_SIZE)

in AT91, but that means (assuming those xxx- defines come from an SoC specific file)
that in start.s the includes

#if defined(CONFIG_OMAP1610)
#include <./configs/omap1510.h>
#elif defined(CONFIG_OMAP730)
#include <./configs/omap730.h>
#endif

have to be expanded for every SoC in question. Or to include the <soc>.h
into the <board>.h...

Which way to go?

Reinhard

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Shawn Guo]

Hi Reinhard

On Tue, Oct 26, 2010 at 5:04 PM, Reinhard Meyer
<u-boot@emk-elektronik.de> wrote:
> Dear Shawn Guo,
>> On Tue, Oct 26, 2010 at 4:34 PM, Stefano Babic <sbabic@denx.de> wrote:
>>> On 10/26/2010 10:25 AM, Heiko Schocher wrote:
>>>> We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE
>>>> - CONFIG_SYS_GBL_DATA_SIZE)
>>> Agree, this is what I set for the vision2 board. We should be consistent
>>> and do the same for the mx51evk.
>>>
>>>> Don;t know if IRAM_BASE_SIZE exists ...
>>> we must define it. I set it in the board configuration file, but it is
>>> wrong. The value should be moved into register definition file for the
>>> SoC (imx-regs.h)
>>>
>> I see many other platforms using 0x1000 offset way to define
>> CONFIG_SYS_INIT_SP_ADDR, so I did that to make it a little bit more
>> common. ?But I'm fine to start from the end, and will send v3 of this
>> patch soon.
>
> I just tried to add the symbolic version
>
> #define CONFIG_SYS_INIT_SP_ADDR (xxx_SRAM_BASE + xxx_SRAM_SIZE - CONFIG_SYS_GBL_DATA_SIZE)
>
> in AT91, but that means (assuming those xxx- defines come from an SoC specific file)
> that in start.s the includes
>
> #if defined(CONFIG_OMAP1610)
> #include <./configs/omap1510.h>
> #elif defined(CONFIG_OMAP730)
> #include <./configs/omap730.h>
> #endif
>
> have to be expanded for every SoC in question. Or to include the <soc>.h
> into the <board>.h...
>
> Which way to go?
>
I'm going the way of including <soc>.h into <board>.h, as I see
omap3_beagle.h is doing this way.

-- 
Regards,
Shawn

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Wolfgang Denk]

Dear Shawn Guo,

In message <AANLkTinK5=i58ft6mb17qLZq_Gi3oytUh9OjMYtyXx_A@mail.gmail.com> you wrote:
> Hi Stefano,
> 
> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
> > On 10/25/2010 05:14 PM, Shawn Guo wrote:
> >
> >> +#define CONFIG_SYS_SDRAM_BASE =A0 =A0 =A0 =A0PHYS_SDRAM_1
> >> +#define CONFIG_SYS_INIT_SP_ADDR =A0 =A0 =A0(IRAM_BASE_ADDR + 0x1000)
> >
> > What is the meaning of the offset at 0x1000 ? Is there something at
> > IRAM_BASE_ADDR ?
> >
> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
> which decrease the address.  Is it not the case?

Boards should define CONFIG_SYS_INIT_RAM_ADDR (the start address) and
CONFIG_SYS_INIT_RAM_END (actually the size of the initial RAM).

I'm working on patches that will auto-calculate CONFIG_SYS_INIT_SP*
from that.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the strict scientific sense we all feed on death -- even
vegetarians.
	-- Spock, "Wolf in the Fold", stardate 3615.4

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Wolfgang Denk]

Dear Shawn Guo,

In message <AANLkTiknA2QYu1KVnxqmEnqJ0ewKaXwgnAMNu19i7SgO@mail.gmail.com> you wrote:
> On Tue, Oct 26, 2010 at 4:14 PM, Stefano Babic <sbabic@denx.de> wrote:
> > On 10/26/2010 10:05 AM, Shawn Guo wrote:
> >> Hi Stefano,
> >>
> >> On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic <sbabic@denx.de> wrote:
> >>> On 10/25/2010 05:14 PM, Shawn Guo wrote:
> >>>
> >>>> +#define CONFIG_SYS_SDRAM_BASE =A0 =A0 =A0 =A0PHYS_SDRAM_1
> >>>> +#define CONFIG_SYS_INIT_SP_ADDR =A0 =A0 =A0(IRAM_BASE_ADDR + 0x1000)
> >>>
> >>> What is the meaning of the offset at 0x1000 ? Is there something at
> >>> IRAM_BASE_ADDR ?
> >>>
> >> I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp)
> >> which decrease the address. =A0Is it not the case?
> >>
> >
> > Yes, my doubt is due to the fact that we do not set the SP at the end of
> > the IRAM and we set it to an arbitrary address in between.
> >
> At this point, IRAM is totally free for u-boot to use, so I simply
> reserved 4 KB from start.

It is a bad idea when everybody implement this differently, just as he
feels.

I want to get rid of this. Patches following soon. As for now, please
focus on defining the proper address and size of the IRAM, the rest
will then be automatically derived (global data on top, then stack
below).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4CC693FE.4090500@denx.de> you wrote:
> 
> >> Don;t know if IRAM_BASE_SIZE exists ...
> > 
> > we must define it. I set it in the board configuration file, but it is
> > wrong. The value should be moved into register definition file for the
> > SoC (imx-regs.h)
> 
> Full-Ack. This is a SoC define, not board dependend.

It may be board dependent - for exmaple, when there is some large and
conveniently usable SRAM on a board, you might want to use that
instead of any limited area on the SoC.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Either one of us, by himself, is expendable.  Both of us are not.
	-- Kirk, "The Devil in the Dark", stardate 3196.1

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4CC69992.1060505@emk-elektronik.de> you wrote:
>
> in AT91, but that means (assuming those xxx- defines come from an SoC specific file)
> that in start.s the includes
> 
> #if defined(CONFIG_OMAP1610)
> #include <./configs/omap1510.h>
> #elif defined(CONFIG_OMAP730)
> #include <./configs/omap730.h>
> #endif
> 
> have to be expanded for every SoC in question. Or to include the <soc>.h
> into the <board>.h...
> 
> Which way to go?

Wait for my patches :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is wanted is not the will to believe,  but the will to find out,
which is the exact opposite.
		        -- Bertrand Russell, "Skeptical Essays", 1928

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Wolfgang Denk]

Dear Shawn Guo,

In message <AANLkTi=xWMvAHuTSD89FXXQkNPbZs2rwCz825K15APBP@mail.gmail.com> you wrote:
> 
> > Which way to go?
> >
> I'm going the way of including <soc>.h into <board>.h, as I see
> omap3_beagle.h is doing this way.

Please wait. Patches in the works.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Without facts, the decision cannot be made logically. You  must  rely
on your human intuition.
	-- Spock, "Assignment: Earth", stardate unknown

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk schrieb:
> Dear Heiko Schocher,
> 
> In message <4CC693FE.4090500@denx.de> you wrote:
>>>> Don;t know if IRAM_BASE_SIZE exists ...
>>> we must define it. I set it in the board configuration file, but it is
>>> wrong. The value should be moved into register definition file for the
>>> SoC (imx-regs.h)
>> Full-Ack. This is a SoC define, not board dependend.
> 
> It may be board dependent - for exmaple, when there is some large and
> conveniently usable SRAM on a board, you might want to use that
> instead of any limited area on the SoC.

IRAM_BASE_SIZE is SoC dependend! You maybe mean CONFIG_SYS_INIT_SP_ADDR
which can be of course board dependend.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Stefano Babic]

On 10/26/2010 12:03 PM, Heiko Schocher wrote:
> Hello Wolfgang,
> 
> Wolfgang Denk schrieb:
>> Dear Heiko Schocher,
>>
>> In message <4CC693FE.4090500@denx.de> you wrote:
>>>>> Don;t know if IRAM_BASE_SIZE exists ...
>>>> we must define it. I set it in the board configuration file, but it is
>>>> wrong. The value should be moved into register definition file for the
>>>> SoC (imx-regs.h)
>>> Full-Ack. This is a SoC define, not board dependend.
>>
>> It may be board dependent - for exmaple, when there is some large and
>> conveniently usable SRAM on a board, you might want to use that
>> instead of any limited area on the SoC.
> 
> IRAM_BASE_SIZE is SoC dependend! You maybe mean CONFIG_SYS_INIT_SP_ADDR
> which can be of course board dependend.

Agree. IRAM_BASE_SIZE and IRAM_BASE are SoC dependent and they must be
set in the register definition file for the MX.51. At the moment,
IRAM_BASE is set with a wrong value (that is a smaller IRAM is actually
defined as the one processor has) and IRAM_BASE_SIZE is not set, but is
derived in board configuration file (both things must be corrected,
anyway).

Stefano


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4CC6A772.1080509@denx.de> you wrote:
> 
> > It may be board dependent - for exmaple, when there is some large and
> > conveniently usable SRAM on a board, you might want to use that
> > instead of any limited area on the SoC.
> 
> IRAM_BASE_SIZE is SoC dependend! You maybe mean CONFIG_SYS_INIT_SP_ADDR
> which can be of course board dependend.

No, what I mean is CONFIG_SYS_INIT_RAM_ADDR (and
CONFIG_SYS_INIT_RAM_END). CONFIG_SYS_INIT_SP_ADDR is a definition
that will go away because it can be computed from the other data.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Swap read error.  You lose your mind.