[U-Boot] [PATCH] mx51evk: support new relocation scheme
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(-)
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
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
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?
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
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.
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
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
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?
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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 */
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
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.
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 */
participants (6)
-
Heiko Schocher -
Jason Liu -
Reinhard Meyer -
Shawn Guo -
Stefano Babic -
Wolfgang Denk