[U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board

Support for the MINI2416 board based on a Samsung's S3C2416 SoC with 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC.
Changes for v2: - Coding style cleanup - Removed new serial and rtc drivers - Use of in-tree serial and rtc drivers
José Miguel Gonçalves (11): ARM: fix relocation on ARM926EJS S3C24XX: Add core support for Samsung's S3C24XX SoCs serial: Add support to 4 ports in serial_s3c24x0 serial: Use a more precise baud rate generation for serial_s3c24x0 serial: Remove unnecessary delay in serial_s3c24x0 rtc: Improve rtc_get() on s3c24x0_rtc rtc: Fix rtc_reset() on s3c24x0_rtc rtc: Don't allow setting unsuported years on s3c24x0_rtc S3C24XX: Add NAND Flash driver Add u-boot-ubl.bin target to the Makefile S3C24XX: Add support to MINI2416 board
MAINTAINERS | 4 + Makefile | 7 +- arch/arm/cpu/arm926ejs/s3c24xx/Makefile | 52 ++ arch/arm/cpu/arm926ejs/s3c24xx/cpu.c | 56 +++ arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c | 57 +++ arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c | 114 +++++ arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c | 116 +++++ arch/arm/cpu/arm926ejs/s3c24xx/timer.c | 152 ++++++ arch/arm/cpu/arm926ejs/start.S | 4 +- arch/arm/include/asm/arch-s3c24xx/s3c2412.h | 120 +++++ arch/arm/include/asm/arch-s3c24xx/s3c2416.h | 175 +++++++ arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h | 41 ++ arch/arm/include/asm/arch-s3c24xx/s3c24xx.h | 598 +++++++++++++++++++++++ arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h | 30 ++ board/boardcon/mini2416/Makefile | 47 ++ board/boardcon/mini2416/config.mk | 4 + board/boardcon/mini2416/mini2416.c | 98 ++++ board/boardcon/mini2416/mini2416_spl.c | 200 ++++++++ board/boardcon/mini2416/u-boot-spl.lds | 63 +++ boards.cfg | 1 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/s3c24xx_nand.c | 245 ++++++++++ drivers/rtc/s3c24x0_rtc.c | 30 +- drivers/serial/serial_s3c24x0.c | 52 +- include/common.h | 1 + include/configs/VCMA9.h | 2 +- include/configs/mini2416.h | 200 ++++++++ include/configs/smdk2410.h | 2 +- 28 files changed, 2446 insertions(+), 26 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/Makefile create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/timer.c create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2412.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2416.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h create mode 100644 board/boardcon/mini2416/Makefile create mode 100644 board/boardcon/mini2416/config.mk create mode 100644 board/boardcon/mini2416/mini2416.c create mode 100644 board/boardcon/mini2416/mini2416_spl.c create mode 100644 board/boardcon/mini2416/u-boot-spl.lds create mode 100644 drivers/mtd/nand/s3c24xx_nand.c create mode 100644 include/configs/mini2416.h

Jumping to board_init_r is not performed due to a bug on address computation. Relocation offsets are not needed when building SPL.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - None --- arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs - ldr r1, _TEXT_BASE + adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ @@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif
+#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif
/* *************************************************************************

Dear José Miguel Gonçalves,
Jumping to board_init_r is not performed due to a bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Relocation offsets are not needed when building SPL.
Do they cause any trouble?
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2:
- None
arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs
- ldr r1, _TEXT_BASE
- adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif
+#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif
/*
Best regards, Marek Vasut

On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
Jumping to board_init_r is not performed due to a bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL? Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Relocation offsets are not needed when building SPL.
Do they cause any trouble?
No! Just not needed.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2: - None
arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs
- ldr r1, _TEXT_BASE
- adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif
+#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif
/*
Best regards, Marek Vasut
Best regards, José Gonçalves

Dear José Miguel Gonçalves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
Jumping to board_init_r is not performed due to a bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
Relocation offsets are not needed when building SPL.
Do they cause any trouble?
No! Just not needed.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2: - None
arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S
@@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot
#else
ldr r0, _board_init_r_ofs
- ldr r1, _TEXT_BASE
adr r1, _start
add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start
#endif
+#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs: .word __rel_dyn_start - _start
_rel_dyn_end_ofs: .word __rel_dyn_end - _start
_dynsym_start_ofs: .word __dynsym_start - _start
+#endif
/*
Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, Marek Vasut

On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
Jumping to board_init_r is not performed due to a bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board.
Relocation offsets are not needed when building SPL.
Do they cause any trouble?
No! Just not needed.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2: - None
arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S
@@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot
#else
ldr r0, _board_init_r_ofs
- ldr r1, _TEXT_BASE
adr r1, _start
add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start
#endif
+#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs: .word __rel_dyn_start - _start
_rel_dyn_end_ofs: .word __rel_dyn_end - _start
_dynsym_start_ofs: .word __dynsym_start - _start
+#endif
/*
********************************************************************* ****
Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, Marek Vasut
Best regards, José Gonçalves

Dear José Miguel Gonçalves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
Jumping to board_init_r is not performed due to a bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that.
What do you boot the rest from ?
If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board.
Relocation offsets are not needed when building SPL.
Do they cause any trouble?
No! Just not needed.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2: - None
arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S
@@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot
#else
ldr r0, _board_init_r_ofs
- ldr r1, _TEXT_BASE
adr r1, _start
add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start
#endif
+#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs: .word __rel_dyn_start - _start
_rel_dyn_end_ofs: .word __rel_dyn_end - _start
_dynsym_start_ofs: .word __dynsym_start - _start
+#endif
/*
****************************************************************** *** ****
Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, Marek Vasut
Best regards, José Gonçalves

On 09/16/2012 04:36 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
Jumping to board_init_r is not performed due to a bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
My bad. I should be more explicit on the patch description.
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that.
What do you boot the rest from ?
Both SPL and U-Boot are in NAND Flash.
The board's SPL code in board/boardcon/mini2416/mini2416_spl.c that needs this patch was based on existing code from arch/arm/cpu/arm926ejs/davinci/spl.c and arm/cpu/armv7/omap-common/spl.c
The need to call relocate_code() in board_init_f() is explained on the SPL source comment, i.e., only to initialize .bss before we could use it in board_init_r() (in the serial driver initialization).
If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board.
Relocation offsets are not needed when building SPL.
Do they cause any trouble?
No! Just not needed.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2: - None
arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S
@@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot
#else ldr r0, _board_init_r_ofs
- ldr r1, _TEXT_BASE
adr r1, _start
add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start
#endif
+#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start
+#endif
/* ****************************************************************** *** ****
Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, Marek Vasut
Best regards, José Gonçalves

Dear José Miguel Gonçalves,
On 09/16/2012 04:36 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
> Jumping to board_init_r is not performed due to a bug on address > computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
My bad. I should be more explicit on the patch description.
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that.
What do you boot the rest from ?
Both SPL and U-Boot are in NAND Flash.
The board's SPL code in board/boardcon/mini2416/mini2416_spl.c that needs this patch was based on existing code from arch/arm/cpu/arm926ejs/davinci/spl.c and arm/cpu/armv7/omap-common/spl.c
CCing Tom, he's the SPL expert.
The need to call relocate_code() in board_init_f() is explained on the SPL source comment, i.e., only to initialize .bss before we could use it in board_init_r() (in the serial driver initialization).
If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board.
> Relocation offsets are not needed when building SPL.
Do they cause any trouble?
No! Just not needed.
> Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt > --- > > Changes for v2: > - None > > --- > > arch/arm/cpu/arm926ejs/start.S | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/arm926ejs/start.S > b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 > --- a/arch/arm/cpu/arm926ejs/start.S > +++ b/arch/arm/cpu/arm926ejs/start.S > > @@ -325,7 +325,7 @@ _nand_boot_ofs: > .word nand_boot > > #else > > ldr r0, _board_init_r_ofs > > - ldr r1, _TEXT_BASE > + adr r1, _start > > add lr, r0, r1 > add lr, lr, r9 > /* setup parameters for board_init_r */ > > @@ -338,12 +338,14 @@ _board_init_r_ofs: > .word board_init_r - _start > > #endif > > +#ifndef CONFIG_SPL_BUILD > > _rel_dyn_start_ofs: > .word __rel_dyn_start - _start > > _rel_dyn_end_ofs: > .word __rel_dyn_end - _start > > _dynsym_start_ofs: > .word __dynsym_start - _start > > +#endif > > /* > > *************************************************************** > *** *** ****
Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, Marek Vasut
Best regards, José Gonçalves

Hi,
On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut marex@denx.de wrote:
Dear José Miguel Gonçalves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
Jumping to board_init_r is not performed due to a bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board.
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that.
Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian
What do you boot the rest from ?
If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board.
Relocation offsets are not needed when building SPL.
Do they cause any trouble?
No! Just not needed.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2: - None
arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S
@@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot
#else
ldr r0, _board_init_r_ofs
ldr r1, _TEXT_BASE
adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start
#endif
+#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs: .word __rel_dyn_start - _start
_rel_dyn_end_ofs: .word __rel_dyn_end - _start
_dynsym_start_ofs: .word __dynsym_start - _start
+#endif
/*
****************************************************************** *** ****
Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, Marek Vasut
Best regards, José Gonçalves
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

On 09/17/2012 07:28 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut marex@denx.de wrote:
Dear José Miguel Gonçalves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
> Jumping to board_init_r is not performed due to a bug on address > computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board.
They are different because of how start.S is implemented in arm926ejs.
In my SPL map file I see:
.text 0x0000000000000000 0xc24 arch/arm/cpu/arm926ejs/start.o(.text) .text 0x0000000000000000 0x120 arch/arm/cpu/arm926ejs/start.o 0x0000000000000000 _start 0x0000000000000040 _TEXT_BASE 0x0000000000000044 _bss_start_ofs 0x0000000000000048 _bss_end_ofs 0x000000000000004c _end_ofs 0x0000000000000050 IRQ_STACK_START_IN 0x0000000000000074 relocate_code
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that.
Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian
What do you boot the rest from ?
If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board.
> Relocation offsets are not needed when building SPL. Do they cause any trouble?
No! Just not needed.
> Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt > --- > > Changes for v2: > - None > > --- > > arch/arm/cpu/arm926ejs/start.S | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/arm926ejs/start.S > b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 > --- a/arch/arm/cpu/arm926ejs/start.S > +++ b/arch/arm/cpu/arm926ejs/start.S > > @@ -325,7 +325,7 @@ _nand_boot_ofs: > .word nand_boot > > #else > > ldr r0, _board_init_r_ofs > > - ldr r1, _TEXT_BASE > + adr r1, _start > > add lr, r0, r1 > add lr, lr, r9 > /* setup parameters for board_init_r */ > > @@ -338,12 +338,14 @@ _board_init_r_ofs: > .word board_init_r - _start > > #endif > > +#ifndef CONFIG_SPL_BUILD > > _rel_dyn_start_ofs: > .word __rel_dyn_start - _start > > _rel_dyn_end_ofs: > .word __rel_dyn_end - _start > > _dynsym_start_ofs: > .word __dynsym_start - _start > > +#endif > > /* > > ****************************************************************** > *** **** Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, José Gonçalves

Hi,
On Mon, Sep 17, 2012 at 10:34 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/17/2012 07:28 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut marex@denx.de wrote:
Dear José Miguel Gonçalves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
On 09/15/2012 07:03 PM, Marek Vasut wrote: > > Dear José Miguel Gonçalves, > >> Jumping to board_init_r is not performed due to a bug on address >> computation. > > Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any > misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board.
They are different because of how start.S is implemented in arm926ejs.
In my SPL map file I see:
.text 0x0000000000000000 0xc24 arch/arm/cpu/arm926ejs/start.o(.text) .text 0x0000000000000000 0x120 arch/arm/cpu/arm926ejs/start.o 0x0000000000000000 _start 0x0000000000000040 _TEXT_BASE 0x0000000000000044 _bss_start_ofs 0x0000000000000048 _bss_end_ofs 0x000000000000004c _end_ofs 0x0000000000000050 IRQ_STACK_START_IN 0x0000000000000074 relocate_code
So _start is 0x00000000, and in your config/include/include/configs/mini2416.h you have
#define CONFIG_SPL_TEXT_BASE 0x00000000
and in arch/arm/cpu/arm926ejs/start.S we have
.globl _TEXT_BASE _TEXT_BASE: #ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */ .word CONFIG_SYS_TEXT_BASE #else #ifdef CONFIG_SPL_BUILD .word CONFIG_SPL_TEXT_BASE #else .word CONFIG_SYS_TEXT_BASE #endif #endif
So
ldr r1, _TEXT_BASE
should be the same as
adr r1, _start
However, if you do not load your SPL to 0x00000000 but to another address and execute it from there, it will be different, since adr uses relative adressing, right? Are you sure you are loading it to 0x00000000?
Regards, Christian
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that.
Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian
What do you boot the rest from ?
If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board.
>> Relocation offsets are not needed when building SPL. > > Do they cause any trouble?
No! Just not needed.
>> Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt >> --- >> >> Changes for v2: >> - None >> >> --- >> >> arch/arm/cpu/arm926ejs/start.S | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/cpu/arm926ejs/start.S >> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >> --- a/arch/arm/cpu/arm926ejs/start.S >> +++ b/arch/arm/cpu/arm926ejs/start.S >> >> @@ -325,7 +325,7 @@ _nand_boot_ofs: >> .word nand_boot >> >> #else >> >> ldr r0, _board_init_r_ofs >> >> - ldr r1, _TEXT_BASE >> + adr r1, _start >> >> add lr, r0, r1 >> add lr, lr, r9 >> /* setup parameters for board_init_r */ >> >> @@ -338,12 +338,14 @@ _board_init_r_ofs: >> .word board_init_r - _start >> >> #endif >> >> +#ifndef CONFIG_SPL_BUILD >> >> _rel_dyn_start_ofs: >> .word __rel_dyn_start - _start >> >> _rel_dyn_end_ofs: >> .word __rel_dyn_end - _start >> >> _dynsym_start_ofs: >> .word __dynsym_start - _start >> >> +#endif >> >> /* >> >> >> ****************************************************************** >> *** **** > > Best regards, > Marek Vasut
Best regards, José Gonçalves
Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, José Gonçalves _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Hi Christian,
On 09/17/2012 10:03 AM, Christian Riesch wrote:
Hi,
On Mon, Sep 17, 2012 at 10:34 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/17/2012 07:28 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut marex@denx.de wrote:
Dear José Miguel Gonçalves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear José Miguel Gonçalves,
> On 09/15/2012 07:03 PM, Marek Vasut wrote: >> Dear José Miguel Gonçalves, >> >>> Jumping to board_init_r is not performed due to a bug on address >>> computation. >> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any >> misbehavior on my arm926 boards. > Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . > Please check the same chunk of code in other start.S for arm1176 and > armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board.
They are different because of how start.S is implemented in arm926ejs.
In my SPL map file I see:
.text 0x0000000000000000 0xc24 arch/arm/cpu/arm926ejs/start.o(.text) .text 0x0000000000000000 0x120 arch/arm/cpu/arm926ejs/start.o 0x0000000000000000 _start 0x0000000000000040 _TEXT_BASE 0x0000000000000044 _bss_start_ofs 0x0000000000000048 _bss_end_ofs 0x000000000000004c _end_ofs 0x0000000000000050 IRQ_STACK_START_IN 0x0000000000000074 relocate_code
So _start is 0x00000000, and in your config/include/include/configs/mini2416.h you have
#define CONFIG_SPL_TEXT_BASE 0x00000000
and in arch/arm/cpu/arm926ejs/start.S we have
.globl _TEXT_BASE _TEXT_BASE: #ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */ .word CONFIG_SYS_TEXT_BASE #else #ifdef CONFIG_SPL_BUILD .word CONFIG_SPL_TEXT_BASE #else .word CONFIG_SYS_TEXT_BASE #endif #endif
So
ldr r1, _TEXT_BASE
should be the same as
adr r1, _start
However, if you do not load your SPL to 0x00000000 but to another address and execute it from there, it will be different, since adr uses relative adressing, right? Are you sure you are loading it to 0x00000000?
Not an expert on ARM assembly, so cannot give any feedback on the differences between adr and ldr mnemonics.
What I know for a fact is that the S3C2416, when booting from it's internal ROM, makes a copy of the first 8KB of the NAND flash to an internal RAM (named SteppingStone), maps it at address 0 and the jumps to the start of it. This mapping is not clear in Samsung's user manual but I retrieved that information from here:
http://barebox.org/documentation/barebox-2011.05.0/dev_s3c24xx_arch.html
Regards, Christian
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that.
Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian
What do you boot the rest from ?
If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board.
>>> Relocation offsets are not needed when building SPL. >> Do they cause any trouble? > No! Just not needed. > >>> Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt >>> --- >>> >>> Changes for v2: >>> - None >>> >>> --- >>> >>> arch/arm/cpu/arm926ejs/start.S | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/arm/cpu/arm926ejs/start.S >>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >>> --- a/arch/arm/cpu/arm926ejs/start.S >>> +++ b/arch/arm/cpu/arm926ejs/start.S >>> >>> @@ -325,7 +325,7 @@ _nand_boot_ofs: >>> .word nand_boot >>> >>> #else >>> >>> ldr r0, _board_init_r_ofs >>> >>> - ldr r1, _TEXT_BASE >>> + adr r1, _start >>> >>> add lr, r0, r1 >>> add lr, lr, r9 >>> /* setup parameters for board_init_r */ >>> >>> @@ -338,12 +338,14 @@ _board_init_r_ofs: >>> .word board_init_r - _start >>> >>> #endif >>> >>> +#ifndef CONFIG_SPL_BUILD >>> >>> _rel_dyn_start_ofs: >>> .word __rel_dyn_start - _start >>> >>> _rel_dyn_end_ofs: >>> .word __rel_dyn_end - _start >>> >>> _dynsym_start_ofs: >>> .word __dynsym_start - _start >>> >>> +#endif >>> >>> /* >>> >>> >>> ****************************************************************** >>> *** **** >> Best regards, >> Marek Vasut > Best regards, > José Gonçalves Best regards, Marek Vasut
Best regards, José Gonçalves
Best regards, José Gonçalves
Best regards, José Gonçalves

On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
Jumping to board_init_r is not performed due to a bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
- In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series.

On 09/17/2012 12:18:31 PM, Tom Rini wrote:
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
> Jumping to board_init_r is not performed due to a bug on
address
> computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't
detect any
misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for
arm1176 and
armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address
computation."
Ok, I don't know how to replicate the bug from this comment or what
effects it
causes or ... well, anything. So please, try to be more elaborate
in your patch
description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think
I have
all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL
is there only
to load the real U-Boot from whatever media, so you usually use
either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand:
- In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our
jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
- In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
So you've removed the ability to relocate at all? What about hardware where you boot from an I/O buffer, that you need to get out of in order to load more pages?
-Scott

On Mon, Sep 17, 2012 at 12:23:53PM -0500, Scott Wood wrote:
On 09/17/2012 12:18:31 PM, Tom Rini wrote:
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/15/2012 07:03 PM, Marek Vasut wrote: > Dear Jos? Miguel Gon?alves, > >> Jumping to board_init_r is not performed due to a bug on
address
>> computation. > > Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't
detect any
> misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for
arm1176 and
armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on
address computation."
Ok, I don't know how to replicate the bug from this comment or
what effects it
causes or ... well, anything. So please, try to be more
elaborate in your patch
description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I
think I have
all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL.
SPL is there only
to load the real U-Boot from whatever media, so you usually use
either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand:
- In the current in-tree SPL implementations the code flow is
board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
- In my series this has been changed slightly to be board_init_f calls
memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
So you've removed the ability to relocate at all? What about hardware where you boot from an I/O buffer, that you need to get out of in order to load more pages?
Then you do that instead. Getting from board_init_f to _r is setup at the arch level, weakly, and with what it must perform documented.

Dear Tom Rini,
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
> Jumping to board_init_r is not performed due to a bug on address > computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand:
In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ?
Best regards, Marek Vasut

On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
Dear Tom Rini,
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/15/2012 07:03 PM, Marek Vasut wrote: > Dear Jos? Miguel Gon?alves, > >> Jumping to board_init_r is not performed due to a bug on address >> computation. > > Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect > any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand:
In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ?
I think people have posted patches for this before and yes, once CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so long as it doesn't grow in size or doesn't grow in size that would be problematic (remember the 4kb people).

Dear Tom Rini,
On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
Dear Tom Rini,
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
> On 09/15/2012 07:03 PM, Marek Vasut wrote: >> Dear Jos? Miguel Gon?alves, >> >>> Jumping to board_init_r is not performed due to a bug on >>> address computation. >> >> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't >> detect any misbehavior on my arm926 boards. > > Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> Please check the same chunk of code in other start.S for arm1176 > and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand:
In the current in-tree SPL implementations the code flow is
board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
In my series this has been changed slightly to be board_init_f calls
memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ?
I think people have posted patches for this before and yes, once CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so long as it doesn't grow in size or doesn't grow in size that would be problematic (remember the 4kb people).
How does MANUAL_RELOC interfere with that? Eg. on ARM, it can already be shifted to C. Then if we made it generic enough, those MANUAL_RELOC platforms could simply adopt the C code.
Best regards, Marek Vasut

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/17/12 10:48, Marek Vasut wrote:
Dear Tom Rini,
On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
Dear Tom Rini,
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote: > Dear Jos? Miguel Gon?alves, > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>> Dear Jos? Miguel Gon?alves, >>> >>>> Jumping to board_init_r is not performed due to a >>>> bug on address computation. >>> >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? >>> I don't detect any misbehavior on my arm926 >>> boards. >> >> Maybe because you are not using it to build an SPL? > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > >> Please check the same chunk of code in other start.S >> for arm1176 and armv7. They have the same code that I >> put for arm926ejs. > > Please wait and please first explain what is the > issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is
board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
- In my series this has been changed slightly to be
board_init_f calls
memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ?
I think people have posted patches for this before and yes, once CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so long as it doesn't grow in size or doesn't grow in size that would be problematic (remember the 4kb people).
How does MANUAL_RELOC interfere with that? Eg. on ARM, it can already be shifted to C. Then if we made it generic enough, those MANUAL_RELOC platforms could simply adopt the C code.
Yes, one of the platforms that already has C code for ELF relocation (x86, iirc) could be made more generic and I think someone (Graeme?) already started this a long time ago as part of making a generic set of functions for board_init_{f,r}. Just can't make it for all platforms until everyone has ELF is the point I was poorly making.
- -- Tom

On 17-09-2012 18:18, Tom Rini wrote:
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
> Jumping to board_init_r is not performed due to a bug on address > computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand:
In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
OK Tom. I will start working on rebasing the MINI2416 board support on the new SPL framework. If I have any doubts I will get in touch with you...
Best regards, José Gonçalves

Hi José,
On Fri, 14 Sep 2012 18:28:52 +0100, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
Jumping to board_init_r is not performed due to a bug on address computation. Relocation offsets are not needed when building SPL.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2:
- None
arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs
- ldr r1, _TEXT_BASE
- adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif
+#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif
/*
Deferring decision on this one until after 2012.10.
Amicalement,

This patch adds the support for Samsung's S3C24XX SoCs that have an ARM926EJS core. Currently it supports S3C2412, S3C2413, S3C2416 and S3C2450. Tested on an S3C2416 platform.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - Added register bit macros to avoid magic numbers - Removed volatile attribute from register structs - Added s3c24x0_cpu.h to be able to use drivers from s3c24x0 family - Fixed EPLL computation in get_PLLCLK for S3C2416 - Added display of UCLK in print_cpu_info - Use of clrsetbits_le32()
--- arch/arm/cpu/arm926ejs/s3c24xx/Makefile | 52 ++ arch/arm/cpu/arm926ejs/s3c24xx/cpu.c | 56 +++ arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c | 57 +++ arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c | 114 +++++ arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c | 116 +++++ arch/arm/cpu/arm926ejs/s3c24xx/timer.c | 152 ++++++ arch/arm/include/asm/arch-s3c24xx/s3c2412.h | 120 +++++ arch/arm/include/asm/arch-s3c24xx/s3c2416.h | 175 +++++++ arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h | 41 ++ arch/arm/include/asm/arch-s3c24xx/s3c24xx.h | 598 +++++++++++++++++++++++ arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h | 30 ++ include/common.h | 1 + 12 files changed, 1512 insertions(+) create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/Makefile create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/timer.c create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2412.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2416.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h
diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/Makefile b/arch/arm/cpu/arm926ejs/s3c24xx/Makefile new file mode 100644 index 0000000..62b8378 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/s3c24xx/Makefile @@ -0,0 +1,52 @@ +# +# (C) Copyright 2012 INOV - INESC Inovacao +# Jose Goncalves jose.goncalves@inov.pt +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(SOC).o + +COBJS-$(CONFIG_DISPLAY_CPUINFO) += cpu_info.o +ifeq ($(filter y,$(CONFIG_S3C2412) $(CONFIG_S3C2413)),y) +COBJS-y += s3c2412_speed.o +else +COBJS-y += s3c2416_speed.o +endif +COBJS-y += cpu.o +COBJS-y += timer.o + +SRCS := $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) + +all: $(obj).depend $(LIB) + +$(LIB): $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +######################################################################### + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +######################################################################### diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/cpu.c b/arch/arm/cpu/arm926ejs/s3c24xx/cpu.c new file mode 100644 index 0000000..e16ae73 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/s3c24xx/cpu.c @@ -0,0 +1,56 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> + +void enable_caches(void) +{ +#ifndef CONFIG_SYS_ICACHE_OFF + icache_enable(); +#endif +#ifndef CONFIG_SYS_DCACHE_OFF + dcache_enable(); +#endif +} + +/* + * Reset the cpu by setting up the watchdog timer and let him time out. + */ +void reset_cpu(ulong addr) +{ + struct s3c24xx_watchdog *const watchdog = s3c24xx_get_base_watchdog(); + + /* Disable watchdog */ + writel(0x0000, &watchdog->wtcon); + + /* Initialize watchdog timer count register */ + writel(0x0001, &watchdog->wtcnt); + + /* Enable watchdog timer; assert reset at timer timeout */ + writel(WTCON_RSTEN | WTCON_ENABLE, &watchdog->wtcon); + + while (1) + /* loop forever and wait for reset to happen */; +} diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c b/arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c new file mode 100644 index 0000000..d2a8b95 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c @@ -0,0 +1,57 @@ +/* + * (C) Copyright 2010 + * David Mueller d.mueller@elsoft.ch + * + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> + +typedef ulong(*getfreq) (void); + +static const getfreq freq_f[] = { + get_FCLK, + get_HCLK, + get_PCLK, + get_UCLK, +}; + +static const char freq_c[] = { 'F', 'H', 'P', 'U' }; + +int print_cpuinfo(void) +{ + int i; + char buf[32]; + ulong cpuid; + struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio(); + + cpuid = readl(&gpio->gstatus[1]); + printf("CPU: %8s (id %08lX) @ %s MHz\n", s3c24xx_get_cpu_name(), + cpuid, strmhz(buf, get_ARMCLK())); + for (i = 0; i < ARRAY_SIZE(freq_f); i++) + printf("%cCLK: %8s MHz\n", freq_c[i], + strmhz(buf, freq_f[i] ())); + + return 0; +} diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c b/arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c new file mode 100644 index 0000000..eeadc3c --- /dev/null +++ b/arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c @@ -0,0 +1,114 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * Based on U-Boot 1.3.4 from Samsung. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <asm/io.h> +#include <asm/arch/s3c2412.h> + +#define MPLL 0 +#define UPLL 1 + +/* ------------------------------------------------------------------------- */ +/* + * CONFIG_SYS_CLK_FREQ should be defined as the input frequency of the PLL. + * + * get_FCLK(), get_HCLK(), get_PCLK() and get_UCLK() return the clock of + * the specified bus in HZ. + */ +/* ------------------------------------------------------------------------- */ + +static ulong get_PLLCLK(int pllreg) +{ + struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl(); + u32 pllcon, f; + u16 mdiv, pdiv, sdiv; + + if (pllreg == MPLL) + pllcon = readl(&sysctl->mpllcon); + else if (pllreg == UPLL) + pllcon = readl(&sysctl->upllcon); + else + hang(); + + mdiv = (pllcon >> 12) & 0xFF; + pdiv = (pllcon >> 4) & 0x3F; + sdiv = pllcon & 0x3; + + f = (mdiv + 8) * (CONFIG_SYS_CLK_FREQ / ((pdiv + 2) << sdiv)); + if (pllreg == MPLL) + f <<= 1; + + return f; +} + +/* return FCLK frequency */ +ulong get_FCLK(void) +{ + return get_PLLCLK(MPLL); +} + +/* return HCLK frequency */ +ulong get_HCLK(void) +{ + struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl(); + u32 clkdivn; + u16 hclk_div, arm_div; + + clkdivn = readl(&sysctl->clkdivn); + hclk_div = (clkdivn & 0x3) + 1; + arm_div = ((clkdivn >> 3) & 0x1) + 1; + + return get_FCLK() / (hclk_div * arm_div); +} + +/* return PCLK frequency */ +ulong get_PCLK(void) +{ + struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl(); + u32 clkdivn; + + clkdivn = readl(&sysctl->clkdivn); + + return (clkdivn & 0x4) ? get_HCLK() / 2 : get_HCLK(); +} + +/* return UCLK frequency */ +ulong get_UCLK(void) +{ + return get_PLLCLK(UPLL); +} + +/* return ARMCORE frequency */ +ulong get_ARMCLK(void) +{ + struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl(); + u32 clkdivn; + + clkdivn = readl(&sysctl->clkdivn); + if (clkdivn & 0x10) + return get_FCLK(); + + return (clkdivn & 0x8) ? get_FCLK() / 2 : get_FCLK(); +} diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c b/arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c new file mode 100644 index 0000000..e8ea0c7 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c @@ -0,0 +1,116 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * Based on U-Boot 1.3.4 from Samsung. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <asm/io.h> +#include <asm/arch/s3c2416.h> + +#define MPLL 0 +#define EPLL 1 + +/* ------------------------------------------------------------------------- */ +/* + * CONFIG_SYS_CLK_FREQ should be defined as the input frequency of the PLL. + * + * get_FCLK(), get_HCLK(), get_PCLK() and get_UCLK() return the clock of + * the specified bus in HZ. + */ +/* ------------------------------------------------------------------------- */ + +static ulong get_PLLCLK(int pllreg) +{ + struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl(); + u32 pllcon; + u16 mdiv, pdiv, sdiv; + + if (pllreg == MPLL) { + pllcon = readl(&sysctl->mpllcon); + mdiv = (pllcon >> 14) & 0x3FF; + pdiv = (pllcon >> 5) & 0x3F; + } else if (pllreg == EPLL) { + pllcon = readl(&sysctl->epllcon); + mdiv = (pllcon >> 16) & 0xFF; + pdiv = (pllcon >> 8) & 0x3F; + } else { + hang(); + } + + sdiv = pllcon & 0x7; + + return mdiv * (CONFIG_SYS_CLK_FREQ / (pdiv << sdiv)); +} + +/* return FCLK frequency */ +ulong get_FCLK(void) +{ + return get_PLLCLK(MPLL); +} + +/* return HCLK frequency */ +ulong get_HCLK(void) +{ + struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl(); + u32 clkdiv0; + u16 hclk_div, pre_div; + + clkdiv0 = readl(&sysctl->clkdiv0); + hclk_div = (clkdiv0 & 0x3) + 1; + pre_div = ((clkdiv0 >> 4) & 0x3) + 1; + + return get_FCLK() / (hclk_div * pre_div); +} + +/* return PCLK frequency */ +ulong get_PCLK(void) +{ + struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl(); + u32 clkdiv0; + + clkdiv0 = readl(&sysctl->clkdiv0); + + return (clkdiv0 & 0x4) ? get_HCLK() / 2 : get_HCLK(); +} + +/* return UCLK frequency */ +ulong get_UCLK(void) +{ + return get_PLLCLK(EPLL); +} + +/* return ARMCORE frequency */ +ulong get_ARMCLK(void) +{ + struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl(); + u32 clkdiv0; + u16 arm_div; + + clkdiv0 = readl(&sysctl->clkdiv0); + if (clkdiv0 & 0x2000) + return get_FCLK(); + + arm_div = ((clkdiv0 >> 9) & 0x7) + 1; + + return get_FCLK() / arm_div; +} diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/timer.c b/arch/arm/cpu/arm926ejs/s3c24xx/timer.c new file mode 100644 index 0000000..23d3343 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/s3c24xx/timer.c @@ -0,0 +1,152 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * Based on arch/arm/cpu/armv7/s5p-common/timer.c and U-Boot 1.3.4 from Samsung. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> + +DECLARE_GLOBAL_DATA_PTR; + +static ulong get_current_tick(void) +{ + struct s3c24xx_timers *const timers = s3c24xx_get_base_timers(); + ulong now = readl(&timers->tcnto4); + + if (gd->lastinc >= now) + gd->tbl += gd->lastinc - now; + else + gd->tbl += gd->lastinc + gd->tbu - now; + + gd->lastinc = now; + + return gd->tbl; +} + +int timer_init(void) +{ + struct s3c24xx_timers *const timers = s3c24xx_get_base_timers(); + + /* use PWM Timer 4 because it has no output */ + if (gd->tbu == 0) { + /* set divider value for Timer 4 to 2 */ + clrsetbits_le32(&timers->tcfg1, TCFG1_MUX4_MASK, + TCFG1_MUX4_DIV2); + /* set prescaler value for Timer 4 to 15 */ + clrsetbits_le32(&timers->tcfg0, TCFG0_PRESCALER1_MASK, + TCFG0_PRESCALER1(15)); + /* + * Timer Freq(HZ) = + * PCLK / (prescaler_value + 1) / (divider_value) + */ + gd->timer_rate_hz = get_PCLK() / (15 + 1) / 2; + gd->tbu = gd->timer_rate_hz / CONFIG_SYS_HZ; + } + /* load value for selected timeout */ + writel(gd->tbu, &timers->tcntb4); + /* auto reload, manual update of timer 4 */ + clrsetbits_le32(&timers->tcon, TCON_T4START, + TCON_T4RELOAD | TCON_T4MANUALUPD); + /* auto reload, start timer 4 */ + clrsetbits_le32(&timers->tcon, TCON_T4MANUALUPD, + TCON_T4RELOAD | TCON_T4START); + gd->lastinc = 0; + gd->tbl = 0; + + return 0; +} + +ulong get_timer(ulong base) +{ + return get_timer_masked() - base; +} + +void __udelay(unsigned long usec) +{ + ulong tmo, tmp; + + if (usec >= 1000) { + /* + * if "big" number, spread normalization + * to seconds + * 1. start to normalize for usec to ticks per sec + * 2. find number of "ticks" to wait to achieve target + * 3. finish normalize. + */ + tmo = usec / 1000; + tmo *= gd->timer_rate_hz; + tmo /= 1000; + } else { + /* else small number, don't kill it prior to HZ multiply */ + tmo = usec * gd->timer_rate_hz; + tmo /= (1000 * 1000); + } + + /* get current timestamp */ + tmp = get_current_tick(); + + /* if setting this fordward will roll time stamp */ + /* reset "advancing" timestamp to 0, set lastinc value */ + /* else, set advancing stamp wake up time */ + if ((tmo + tmp + 1) < tmp) + reset_timer_masked(); + else + tmo += tmp; + + /* loop till event */ + while (get_current_tick() < tmo) + /* NOP */; +} + +void reset_timer_masked(void) +{ + struct s3c24xx_timers *const timers = s3c24xx_get_base_timers(); + + /* reset time */ + gd->lastinc = readl(&timers->tcnto4); + gd->tbl = 0; +} + +ulong get_timer_masked(void) +{ + return get_current_tick() / gd->tbu; +} + +/* + * This function is derived from PowerPC code (read timebase as long long). + * On ARM it just returns the timer value. + */ +unsigned long long get_ticks(void) +{ + return get_timer_masked(); +} + +/* + * This function is derived from PowerPC code (timebase clock frequency). + * On ARM it returns the number of timer ticks per second. + */ +ulong get_tbclk(void) +{ + return CONFIG_SYS_HZ; +} diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c2412.h b/arch/arm/include/asm/arch-s3c24xx/s3c2412.h new file mode 100644 index 0000000..f5b5b21 --- /dev/null +++ b/arch/arm/include/asm/arch-s3c24xx/s3c2412.h @@ -0,0 +1,120 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +/************************************************ + * NAME : s3c2412.h + * + * Based on S3C2412 User's manual Rev 1.06a + ************************************************/ + +#ifndef __S3C2412_H__ +#define __S3C2412_H__ + +/* Base addresses for S3C2412 specific modules */ +#define S3C2412_INTERRUPT_BASE 0x4A000000 +#define S3C2412_SYSCTL_BASE 0x4C000000 +#define S3C2412_LCD_BASE 0x4D000000 +#define S3C2412_USB_DEVICE_BASE 0x52000000 +#define S3C2412_ADC_BASE 0x58000000 +#define S3C2412_SPI_BASE 0x59000000 +#define S3C2412_SDIO_BASE 0x5A000000 + +#define S3C24XX_UART_CHANNELS 3 +#define S3C24XX_DMA_CHANNELS 4 +#define S3C24XX_SMC_BANKS 8 + +#ifdef CONFIG_S3C2412 +#define S3C24XX_CPU_NAME "S3C2412" +#else +#define S3C24XX_CPU_NAME "S3C2413" +#endif + +enum s3c24xx_uarts { + S3C24XX_UART0, + S3C24XX_UART1, + S3C24XX_UART2 +}; + +enum s3c24xx_dmas { + S3C24XX_DMA0, + S3C24XX_DMA1, + S3C24XX_DMA2, + S3C24XX_DMA3 +}; + +enum s3c24xx_smcs { + S3C24XX_SMC0, + S3C24XX_SMC1, + S3C24XX_SMC2, + S3C24XX_SMC3, + S3C24XX_SMC4, + S3C24XX_SMC5, + S3C24XX_SMC6, + S3C24XX_SMC7 +}; + +/* Interrupt Controller */ +struct s3c2412_interrupt { + u32 srcpnd; + u32 intmod; + u32 intmsk; + u32 priority; + u32 intpnd; + u32 intoffset; + u32 subsrcpnd; + u32 intsubmsk; +}; + +/* System Controller */ +struct s3c2412_sysctl { + u32 locktime; + u32 mpllcon; + u32 upllcon; + u32 clkcon; + u32 _res1; + u32 clkdivn; + u32 oscset; + u32 clksrc; + u32 _res2; + u32 pwrcfg; + u32 _res3[2]; + u32 swrstcon; + u32 rstcon; + u32 _res4[13]; + u32 inform[4]; +}; + +static inline struct s3c2412_interrupt *s3c2412_get_base_interrupt(void) +{ + return (struct s3c2412_interrupt *)S3C2412_INTERRUPT_BASE; +} + +static inline struct s3c2412_sysctl *s3c2412_get_base_sysctl(void) +{ + return (struct s3c2412_sysctl *)S3C2412_SYSCTL_BASE; +} + +/* Include common stuff */ +#include <asm/arch/s3c24xx.h> + +#endif /*__S3C2412_H__*/ diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c2416.h b/arch/arm/include/asm/arch-s3c24xx/s3c2416.h new file mode 100644 index 0000000..b68b8bb --- /dev/null +++ b/arch/arm/include/asm/arch-s3c24xx/s3c2416.h @@ -0,0 +1,175 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +/************************************************ + * NAME : s3c2416.h + * + * Based on S3C2416 User's manual Rev 1.40 + ************************************************/ + +#ifndef __S3C2416_H__ +#define __S3C2416_H__ + +/* Base addresses for S3C2416 specific modules */ +#define S3C2416_USB_DEVICE_BASE 0x49800000 +#define S3C2416_INTERRUPT_BASE 0x4A000000 +#define S3C2416_HSMMC_BASE 0x4A800000 +#define S3C2416_SYSCTL_BASE 0x4C000000 +#define S3C2416_LCD_BASE 0x4C800000 +#define S3C2416_HSSPI_BASE 0x52000000 +#define S3C2416_ADC_BASE 0x58000000 + +#define S3C24XX_UART_CHANNELS 4 +#define S3C24XX_DMA_CHANNELS 6 +#define S3C24XX_SMC_BANKS 6 + +#ifdef CONFIG_S3C2416 +#define S3C24XX_CPU_NAME "S3C2416" +#else +#define S3C24XX_CPU_NAME "S3C2450" +#endif + +enum s3c24xx_uarts { + S3C24XX_UART0, + S3C24XX_UART1, + S3C24XX_UART2, + S3C24XX_UART3 +}; + +enum s3c24xx_dmas { + S3C24XX_DMA0, + S3C24XX_DMA1, + S3C24XX_DMA2, + S3C24XX_DMA3, + S3C24XX_DMA4, + S3C24XX_DMA5 +}; + +enum s3c24xx_smcs { + S3C24XX_SMC0, + S3C24XX_SMC1, + S3C24XX_SMC2, + S3C24XX_SMC3, + S3C24XX_SMC4, + S3C24XX_SMC5 +}; + +/* Interrupt Controller */ +struct s3c2416_interrupt { + u32 srcpnd1; + u32 intmod1; + u32 intmsk1; + u32 _res1; + u32 intpnd1; + u32 intoffset1; + u32 subsrcpnd; + u32 intsubmsk; + u32 _res2[4]; + u32 priority_mode1; + u32 priority_update1; + u32 _res3[2]; + u32 srcpnd2; + u32 intmod2; + u32 intmsk2; + u32 _res4; + u32 intpnd2; + u32 intoffset2; + u32 _res5[6]; + u32 priority_mode2; + u32 priority_update2; +}; + +/* System Controller */ +struct s3c2416_sysctl { + u32 lockcon0; + u32 lockcon1; + u32 oscset; + u32 _res1; + u32 mpllcon; + u32 _res2; + u32 epllcon; + u32 epllcon_k; + u32 clksrc; + u32 clkdiv0; + u32 clkdiv1; + u32 clkdiv2; + u32 hclkcon; + u32 pclkcon; + u32 sclkcon; + u32 _res3; + u32 pwrmode; + u32 swrst; + u32 _res4[2]; + u32 busprio; + u32 _res5[3]; + u32 pwrcfg; + u32 rstcon; + u32 rststat; + u32 wkupstat; + u32 inform[4]; + u32 uphyctrl; + u32 uphypwr; + u32 urstcon; + u32 uclkcon; +}; + +#define MPLLCON_MDIV_MASK (0x3FF<<14) +#define MPLLCON_MDIV(x) ((x)<<14) +#define MPLLCON_PDIV_MASK (0x3F<<5) +#define MPLLCON_PDIV(x) ((x)<<5) +#define MPLLCON_SDIV_MASK (0x7<<0) +#define MPLLCON_SDIV(x) ((x)<<0) + +#define EPLLCON_MDIV_MASK (0xFF<<16) +#define EPLLCON_MDIV(x) ((x)<<16) +#define EPLLCON_PDIV_MASK (0x3F<<8) +#define EPLLCON_PDIV(x) ((x)<<8) +#define EPLLCON_SDIV_MASK (0x7<<0) +#define EPLLCON_SDIV(x) ((x)<<0) + +#define CLKSRC_MSYSCLK_MPLL (1<<4) +#define CLKSRC_ESYSCLK_EPLL (1<<6) + +#define CLKDIV0_HCLKDIV_MASK (3<<0) +#define CLKDIV0_HCLKDIV(x) ((x)<<0) +#define CLKDIV0_PCLKDIV (1<<2) +#define CLKDIV0_HALFHCLK (1<<3) +#define CLKDIV0_PREDIV_MASK (3<<4) +#define CLKDIV0_PREDIV(x) ((x)<<4) +#define CLKDIV0_ARMDIV_MASK (7<<9) +#define CLKDIV0_ARMDIV(x) ((x)<<9) + +static inline struct s3c2416_interrupt *s3c2416_get_base_interrupt(void) +{ + return (struct s3c2416_interrupt *)S3C2416_INTERRUPT_BASE; +} + +static inline struct s3c2416_sysctl *s3c2416_get_base_sysctl(void) +{ + return (struct s3c2416_sysctl *)S3C2416_SYSCTL_BASE; +} + +/* Include common stuff */ +#include <asm/arch/s3c24xx.h> + +#endif /*__S3C2416_H__*/ diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h b/arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h new file mode 100644 index 0000000..e54a46b --- /dev/null +++ b/arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h @@ -0,0 +1,41 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +/* To be able to use s3c24x0 drivers */ + +#ifndef __S3C24X0_CPU_H__ +#define __S3C24X0_CPU_H__ + +#include <asm/arch/s3c24xx_cpu.h> + +#define s3c24x0_rtc s3c24xx_rtc +#define s3c24x0_get_base_rtc s3c24xx_get_base_rtc + +#define S3C24X0_UART0 S3C24XX_UART0 +#define S3C24X0_UART1 S3C24XX_UART1 +#define S3C24X0_UART2 S3C24XX_UART2 +#define S3C24X0_UART3 S3C24XX_UART3 +#define s3c24x0_uart s3c24xx_uart +#define s3c24x0_get_base_uart s3c24xx_get_base_uart + +#endif diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c24xx.h b/arch/arm/include/asm/arch-s3c24xx/s3c24xx.h new file mode 100644 index 0000000..d0ce2f6 --- /dev/null +++ b/arch/arm/include/asm/arch-s3c24xx/s3c24xx.h @@ -0,0 +1,598 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +/****************************************************** + * NAME : s3c24xx.h + * + * Common stuff for SAMSUNG S3C24XX SoC (ARM926EJ core) + ******************************************************/ + +#ifndef __S3C24XX_H__ +#define __S3C24XX_H__ + +/* Base addresses for S3C24XX common modules */ +#define S3C24XX_DRAMCTL_BASE 0x48000000 +#define S3C24XX_USB_HOST_BASE 0x49000000 +#define S3C24XX_DMA_BASE 0x4B000000 +#define S3C24XX_NAND_BASE 0x4E000000 +#define S3C24XX_SMC_BASE 0x4F000000 +#define S3C24XX_UART_BASE 0x50000000 +#define S3C24XX_TIMER_BASE 0x51000000 +#define S3C24XX_WATCHDOG_BASE 0x53000000 +#define S3C24XX_I2C_BASE 0x54000000 +#define S3C24XX_I2S_BASE 0x55000000 +#define S3C24XX_GPIO_BASE 0x56000000 +#define S3C24XX_RTC_BASE 0x57000000 +#define S3C24XX_ADC_BASE 0x58000000 + +/* Mobile DRAM Controller */ +struct s3c24xx_dramctl { + u32 bankcfg; + u32 bankcon1; + u32 bankcon2; + u32 bankcon3; + u32 refresh; + u32 timeout; +}; + +#define BANKCFG_VAL_DDR2 0x00049253 + +#define BANKCON1_VAL_DDR2 0x44000040 +#define BANKCON1_INIT_NORMAL 0x0 +#define BANKCON1_INIT_PALL 0x1 +#define BANKCON1_INIT_MRS 0x2 +#define BANKCON1_INIT_EMRS 0x3 + +#define BANKCON2_VAL_DDR2 0x005D0035 + +#define BANKCON3_VAL_EMRS1 0x44000000 +#define BANKCON3_EMRS1_CAS3 (3<<4) +#define BANKCON3_EMRS1_OCD7 (7<<23) +#define BANKCON3_VAL_EMRS2 0x80000000 +#define BANKCON3_VAL_EMRS3 0xC0000000 +#define BANKCON3_VAL_MRS 0x44000030 +#define BANKCON3_MRS_DLL_RESET (1<<8) + +/* USB Host Controller */ +struct s3c24xx_usb_host { + u32 HcRevision; + u32 HcControl; + u32 HcCommonStatus; + u32 HcInterruptStatus; + u32 HcInterruptEnable; + u32 HcInterruptDisable; + u32 HcHCCA; + u32 HcPeriodCuttendED; + u32 HcControlHeadED; + u32 HcControlCurrentED; + u32 HcBulkHeadED; + u32 HcBuldCurrentED; + u32 HcDoneHead; + u32 HcRmInterval; + u32 HcFmRemaining; + u32 HcFmNumber; + u32 HcPeriodicStart; + u32 HcLSThreshold; + u32 HcRhDescriptorA; + u32 HcRhDescriptorB; + u32 HcRhStatus; + u32 HcRhPortStatus1; + u32 HcRhPortStatus2; +}; + +/* DMA Controller */ +struct s3c24xx_dma { + u32 disrc; + u32 disrcc; + u32 didst; + u32 didstc; + u32 dcon; + u32 dstat; + u32 dcsrc; + u32 dcdst; + u32 dmasktrig; + u32 dmareqsel0; +}; + +/* NAND Flash Controller */ +struct s3c24xx_nand { + u32 nfconf; + u32 nfcont; + u32 nfcmmd; + u32 nfaddr; + u32 nfdata; + u32 nfmeccd[2]; + u32 nfseccd; + u32 nfsblk; + u32 nfeblk; + u32 nfstat; + u32 nfeccerr[2]; + u32 nfmecc[2]; + u32 nfsecc; + u32 nfmlcbitpt; +#if !(defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)) + u32 nf8eccerr[3]; + u32 nfm8ecc[4]; + u32 nfmlc8bitpt[2]; +#endif +}; + +#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413) +#define NFCONF_ECCTYPE_MASK (1<<24) +#define NFCONF_ECCTYPE_1BIT (0<<24) +#define NFCONF_ECCTYPE_4BIT (1<<24) +#else +#define NFCONF_ECCTYPE_MASK (3<<23) +#define NFCONF_ECCTYPE_1BIT (0<<23) +#define NFCONF_ECCTYPE_8BIT (1<<23) +#define NFCONF_ECCTYPE_4BIT (2<<23) +#endif +#define NFCONF_TACLS_MASK (7<<12) +#define NFCONF_TWRPH0_MASK (7<<8) +#define NFCONF_TWRPH1_MASK (7<<4) +#define NFCONF_TACLS(x) ((x)<<12) +#define NFCONF_TWRPH0(x) ((x)<<8) +#define NFCONF_TWRPH1(x) ((x)<<4) + +#define NFCONT_ENABLE (1<<0) +#define NFCONT_NCE0 (1<<1) +#define NFCONT_NCE1 (1<<2) +#define NFCONT_INITSECC (1<<4) +#define NFCONT_INITMECC (1<<5) +#define NFCONT_SECCLOCK (1<<6) +#define NFCONT_MECCLOCK (1<<7) +#define NFCONT_WP (1<<16) +#define NFCONT_ECC_ENC (1<<18) + +#define NFSTAT_RNB (1<<0) + +/* SMC */ +struct s3c24xx_smc { + u32 smbidcy; + u32 smbwstrd; + u32 smbwstwr; + u32 smbwstoen; + u32 smbwstwen; + u32 smbc; + u32 smbs; + u32 smbwstbrd; +}; + +#define SMBC_RBLE (1<<0) +#define SMBC_WAIT_POL (1<<1) +#define SMBC_WAIT_EN (1<<2) +#define SMBC_MW_MASK (0x3<<4) +#define SMBC_MW_16BIT (1<<4) +#define SMBC_MW_8BIT (0<<4) +#define SMBC_DRNCS (1<<7) +#define SMBC_RSMAVD_RD (1<<12) +#define SMBC_DRNOWE (1<<15) +#define SMBC_RSMAVD_WR (1<<20) + +/* UART */ +struct s3c24xx_uart { + u32 ulcon; + u32 ucon; + u32 ufcon; + u32 umcon; + u32 utrstat; + u32 uerstat; + u32 ufstat; + u32 umstat; +#ifdef __BIG_ENDIAN + u8 _res1[3]; + u8 utxh; + u8 _res2[3]; + u8 urxh; +#else /* Little Endian */ + u8 utxh; + u8 _res1[3]; + u8 urxh; + u8 _res2[3]; +#endif + u32 ubrdiv; + u32 udivslot; +}; + +#define ULCON_8N1 0x03 + +#define UCON_POLL 0x005 + +#define UMCON_NOAFC 0 + +#define UFCON_FIFOMODE (1<<0) +#define UFCON_RESETRX (1<<1) +#define UFCON_RESETTX (1<<2) + +#define UTRSTAT_RXDR (1<<0) +#define UTRSTAT_TXFE (1<<1) +#define UTRSTAT_TXE (1<<2) + +/* PWM Timer */ +struct s3c24xx_timer { + u32 tcntb; + u32 tcmpb; + u32 tcnto; +}; + +struct s3c24xx_timers { + u32 tcfg0; + u32 tcfg1; + u32 tcon; + struct s3c24xx_timer ch[4]; + u32 tcntb4; + u32 tcnto4; +}; + +#define TCFG0_PRESCALER1_MASK (0xFF<<8) +#define TCFG0_PRESCALER1(x) ((x)<<8) + +#define TCFG1_MUX4_DIV2 (0<<16) +#define TCFG1_MUX4_DIV4 (1<<16) +#define TCFG1_MUX4_DIV8 (2<<16) +#define TCFG1_MUX4_DIV16 (3<<16) +#define TCFG1_MUX4_TCLK1 (4<<16) +#define TCFG1_MUX4_MASK (0xF<<16) + +#define TCON_T4START (1<<20) +#define TCON_T4MANUALUPD (1<<21) +#define TCON_T4RELOAD (1<<22) + +/* Watchdog Timer */ +struct s3c24xx_watchdog { + u32 wtcon; + u32 wtdat; + u32 wtcnt; +}; + +#define WTCON_RSTEN (1<<0) +#define WTCON_INTEN (1<<2) +#define WTCON_ENABLE (1<<5) + +/* IIC-Bus Interface */ +struct s3c24xx_i2c { + u32 iiccon; + u32 iicstat; + u32 iicadd; + u32 iicds; + u32 iiclc; +}; + +/* IIS-Bus Interface */ +struct s3c24xx_i2s { + u32 iiscon; + u32 iismod; + u32 iisfic; + u32 iispsr; + u32 iistxd; + u32 iisrxd; +}; + +/* I/O Ports */ +struct s3c24xx_gpio { +#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413) + u32 gpacon; + u32 gpadat; + u32 _res1[2]; + u32 gpbcon; + u32 gpbdat; + u32 gpbdn; + u32 gpbslpcon; + u32 gpccon; + u32 gpcdat; + u32 gpcdn; + u32 gpcslpcon; + u32 gpdcon; + u32 gpddat; + u32 gpddn; + u32 gpdslpcon; + u32 gpecon; + u32 gpedat; + u32 gpedn; + u32 gpeslpcon; + u32 gpfcon; + u32 gpfdat; + u32 gpfdn; + u32 _res2; + u32 gpgcon; + u32 gpgdat; + u32 gpgdn; + u32 gpgslpcon; + u32 gphcon; + u32 gphdat; + u32 gphdn; + u32 gphslpcon; + u32 gpjcon; + u32 gpjdat; + u32 gpjdn; + u32 gpjslpcon; + + u32 misccr; + u32 dclkcon; + u32 extint[3]; + u32 eintflt[4]; + u32 eintmask; + u32 eintpend; + u32 gstatus[6]; + u32 mstcon; + u32 mslcon; + u32 dsc[2]; +#else + u32 gpacon; + u32 gpadat; + u32 _res1[2]; + u32 gpbcon; + u32 gpbdat; + u32 gpbudp; + u32 gpbsel; + u32 gpccon; + u32 gpcdat; + u32 gpcudp; + u32 _res2; + u32 gpdcon; + u32 gpddat; + u32 gpdudp; + u32 _res3; + u32 gpecon; + u32 gpedat; + u32 gpeudp; + u32 gpesel; + u32 gpfcon; + u32 gpfdat; + u32 gpfudp; + u32 _res4; + u32 gpgcon; + u32 gpgdat; + u32 gpgudp; + u32 _res5; + u32 gphcon; + u32 gphdat; + u32 gphudp; + u32 _res6; + + u32 misccr; + u32 dclkcon; + u32 extint[3]; + u32 _res7[2]; + u32 eintflt2; + u32 eintflt3; + u32 eintmask; + u32 eintpend; + u32 gstatus[2]; + u32 _res8[3]; + u32 dsc[4]; + + u32 gpjcon; + u32 gpjdat; + u32 gpjudp; + u32 gpjsel; + u32 gpkcon; + u32 gpkdat; + u32 gpkudp; + u32 _res9; + u32 gplcon; + u32 gpldat; + u32 gpludp; + u32 gplsel; + u32 gpmcon; + u32 gpmdat; + u32 gpmudp; + u32 _res10; + + u32 dsc3; + u32 pddmcon; + u32 pdsmcon; +#endif +}; + +/* RTC */ +struct s3c24xx_rtc { +#ifdef __BIG_ENDIAN + u8 _res1[67]; + u8 rtccon; + u8 _res2[3]; + u8 ticnt0; +#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413) + u8 _res3[4]; +#else + u8 _res3[3]; + u8 ticnt2; +#endif + u8 _res4[3]; + u8 ticnt1; + u8 _res5[3]; + u8 rtcalm; + u8 _res6[3]; + u8 almsec; + u8 _res7[3]; + u8 almmin; + u8 _res8[3]; + u8 almhour; + u8 _res9[3]; + u8 almdate; + u8 _res10[3]; + u8 almmon; + u8 _res11[3]; + u8 almyear; + u8 _res12[7]; + u8 bcdsec; + u8 _res13[3]; + u8 bcdmin; + u8 _res14[3]; + u8 bcdhour; + u8 _res15[3]; + u8 bcddate; + u8 _res16[3]; + u8 bcdday; + u8 _res17[3]; + u8 bcdmon; + u8 _res18[3]; + u8 bcdyear; +#if !(defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)) + u8 _res19[3]; + u8 tickcnt; +#endif +#else /* little endian */ + u8 _res0[64]; + u8 rtccon; + u8 _res1[3]; + u8 ticnt0; + u8 _res2[3]; +#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413) + u8 _res3[4]; +#else + u8 ticnt2; + u8 _res3[3]; +#endif + u8 ticnt1; + u8 _res4[3]; + u8 rtcalm; + u8 _res5[3]; + u8 almsec; + u8 _res6[3]; + u8 almmin; + u8 _res7[3]; + u8 almhour; + u8 _res8[3]; + u8 almdate; + u8 _res9[3]; + u8 almmon; + u8 _res10[3]; + u8 almyear; + u8 _res11[7]; + u8 bcdsec; + u8 _res12[3]; + u8 bcdmin; + u8 _res13[3]; + u8 bcdhour; + u8 _res14[3]; + u8 bcddate; + u8 _res15[3]; + u8 bcdday; + u8 _res16[3]; + u8 bcdmon; + u8 _res17[3]; + u8 bcdyear; + u8 _res18[3]; +#if !(defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)) + u8 tickcnt; + u8 _res19[3]; +#endif +#endif +}; + +#define RTCCON_RTCEN (1<<0) +#define RTCCON_CNTSEL (1<<2) +#define RTCCON_CLKRST (1<<3) +#define RTCCON_TICSEL (1<<4) + +/* ADC & Touch Screen Interface */ +struct s3c24xx_adc { + u32 adccon; + u32 adctsc; + u32 adcdly; + u32 adcdat0; + u32 adcdat1; +#if !(defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)) + u32 adcupdn; + u32 adcmux; +#endif +}; + +static inline struct s3c24xx_dramctl *s3c24xx_get_base_dramctl(void) +{ + return (struct s3c24xx_dramctl *)S3C24XX_DRAMCTL_BASE; +} + +static inline struct s3c24xx_usb_host *s3c24xx_get_base_usb_host(void) +{ + return (struct s3c24xx_usb_host *)S3C24XX_USB_HOST_BASE; +} + +static inline struct s3c24xx_dma *s3c24xx_get_base_dma(enum s3c24xx_dmas n) +{ +#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413) + return (struct s3c24xx_dma *)(S3C24XX_DMA_BASE + (n * 0x40)); +#else + return (struct s3c24xx_dma *)(S3C24XX_DMA_BASE + (n * 0x100)); +#endif +} + +static inline struct s3c24xx_nand *s3c24xx_get_base_nand(void) +{ + return (struct s3c24xx_nand *)S3C24XX_NAND_BASE; +} + +static inline struct s3c24xx_smc *s3c24xx_get_base_smc(enum s3c24xx_smcs n) +{ + return (struct s3c24xx_smc *)(S3C24XX_SMC_BASE + (n * 0x20)); +} + +static inline struct s3c24xx_uart *s3c24xx_get_base_uart(enum s3c24xx_uarts n) +{ + return (struct s3c24xx_uart *)(S3C24XX_UART_BASE + (n * 0x4000)); +} + +static inline struct s3c24xx_timers *s3c24xx_get_base_timers(void) +{ + return (struct s3c24xx_timers *)S3C24XX_TIMER_BASE; +} + +static inline struct s3c24xx_watchdog *s3c24xx_get_base_watchdog(void) +{ + return (struct s3c24xx_watchdog *)S3C24XX_WATCHDOG_BASE; +} + +static inline struct s3c24xx_i2c *s3c24xx_get_base_i2c(void) +{ + return (struct s3c24xx_i2c *)S3C24XX_I2C_BASE; +} + +static inline struct s3c24xx_i2s *s3c24xx_get_base_i2s(void) +{ + return (struct s3c24xx_i2s *)S3C24XX_I2S_BASE; +} + +static inline struct s3c24xx_gpio *s3c24xx_get_base_gpio(void) +{ + return (struct s3c24xx_gpio *)S3C24XX_GPIO_BASE; +} + +static inline struct s3c24xx_rtc *s3c24xx_get_base_rtc(void) +{ + return (struct s3c24xx_rtc *)S3C24XX_RTC_BASE; +} + +static inline struct s3c24xx_adc *s3c24xx_get_base_adc(void) +{ + return (struct s3c24xx_adc *)S3C24XX_ADC_BASE; +} + +static inline char *s3c24xx_get_cpu_name(void) +{ + return S3C24XX_CPU_NAME; +} + +extern ulong get_ARMCLK(void); + +#endif /*__S3C24XX_H__*/ diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h b/arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h new file mode 100644 index 0000000..59ccfd4 --- /dev/null +++ b/arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h @@ -0,0 +1,30 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413) +#include <asm/arch/s3c2412.h> +#elif defined(CONFIG_S3C2416) || defined(CONFIG_S3C2450) +#include <asm/arch/s3c2416.h> +#else +#error Please define the S3C24XX SoC type +#endif diff --git a/include/common.h b/include/common.h index 55025c0..36f0636 100644 --- a/include/common.h +++ b/include/common.h @@ -628,6 +628,7 @@ ulong get_OPB_freq (void); ulong get_PCI_freq (void); #endif #if defined(CONFIG_S3C24X0) || \ + defined(CONFIG_S3C24XX) || \ defined(CONFIG_LH7A40X) || \ defined(CONFIG_S3C6400) || \ defined(CONFIG_EP93XX)

Dear José Miguel Gonçalves,
It's getting better :)
[...]
+typedef ulong(*getfreq) (void);
Is this used?
+static const getfreq freq_f[] = {
const array const members, no?
- get_FCLK,
- get_HCLK,
- get_PCLK,
- get_UCLK,
+};
+static const char freq_c[] = { 'F', 'H', 'P', 'U' };
Same here.
+int print_cpuinfo(void) +{
- int i;
- char buf[32];
- ulong cpuid;
- struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio();
- cpuid = readl(&gpio->gstatus[1]);
- printf("CPU: %8s (id %08lX) @ %s MHz\n", s3c24xx_get_cpu_name(),
cpuid, strmhz(buf, get_ARMCLK()));
- for (i = 0; i < ARRAY_SIZE(freq_f); i++)
printf("%cCLK: %8s MHz\n", freq_c[i],
strmhz(buf, freq_f[i] ()));
- return 0;
+}
[...]
+ulong get_HCLK(void) +{
- struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
- u32 clkdivn;
- u16 hclk_div, arm_div;
- clkdivn = readl(&sysctl->clkdivn);
- hclk_div = (clkdivn & 0x3) + 1;
- arm_div = ((clkdivn >> 3) & 0x1) + 1;
Magic.
- return get_FCLK() / (hclk_div * arm_div);
+}
+/* return PCLK frequency */ +ulong get_PCLK(void) +{
- struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
- u32 clkdivn;
- clkdivn = readl(&sysctl->clkdivn);
- return (clkdivn & 0x4) ? get_HCLK() / 2 : get_HCLK();
Magic
+}
+/* return UCLK frequency */ +ulong get_UCLK(void) +{
- return get_PLLCLK(UPLL);
+}
+/* return ARMCORE frequency */ +ulong get_ARMCLK(void) +{
- struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
- u32 clkdivn;
- clkdivn = readl(&sysctl->clkdivn);
- if (clkdivn & 0x10)
return get_FCLK();
Magic above and below and in the following file
- return (clkdivn & 0x8) ? get_FCLK() / 2 : get_FCLK();
+}
[...]
diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/timer.c b/arch/arm/cpu/arm926ejs/s3c24xx/timer.c new file mode 100644 index 0000000..23d3343 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/s3c24xx/timer.c @@ -0,0 +1,152 @@ +/*
- (C) Copyright 2012 INOV - INESC Inovacao
- Jose Goncalves jose.goncalves@inov.pt
- Based on arch/arm/cpu/armv7/s5p-common/timer.c and U-Boot 1.3.4 from
Samsung. + *
- See file CREDITS for list of people who contributed to this
- project.
- This program is free software; you can redistribute it and/or
- modify it under the terms of the GNU General Public License as
- published by the Free Software Foundation; either version 2 of
- the License, or (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
- */
+#include <common.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h>
+DECLARE_GLOBAL_DATA_PTR;
+static ulong get_current_tick(void) +{
- struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
- ulong now = readl(&timers->tcnto4);
- if (gd->lastinc >= now)
gd->tbl += gd->lastinc - now;
- else
gd->tbl += gd->lastinc + gd->tbu - now;
- gd->lastinc = now;
- return gd->tbl;
+}
+int timer_init(void) +{
- struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
- /* use PWM Timer 4 because it has no output */
- if (gd->tbu == 0) {
/* set divider value for Timer 4 to 2 */
clrsetbits_le32(&timers->tcfg1, TCFG1_MUX4_MASK,
TCFG1_MUX4_DIV2);
/* set prescaler value for Timer 4 to 15 */
clrsetbits_le32(&timers->tcfg0, TCFG0_PRESCALER1_MASK,
TCFG0_PRESCALER1(15));
/*
* Timer Freq(HZ) =
* PCLK / (prescaler_value + 1) / (divider_value)
*/
gd->timer_rate_hz = get_PCLK() / (15 + 1) / 2;
gd->tbu = gd->timer_rate_hz / CONFIG_SYS_HZ;
- }
- /* load value for selected timeout */
- writel(gd->tbu, &timers->tcntb4);
- /* auto reload, manual update of timer 4 */
- clrsetbits_le32(&timers->tcon, TCON_T4START,
TCON_T4RELOAD | TCON_T4MANUALUPD);
- /* auto reload, start timer 4 */
- clrsetbits_le32(&timers->tcon, TCON_T4MANUALUPD,
TCON_T4RELOAD | TCON_T4START);
- gd->lastinc = 0;
- gd->tbl = 0;
- return 0;
+}
+ulong get_timer(ulong base) +{
- return get_timer_masked() - base;
+}
+void __udelay(unsigned long usec) +{
- ulong tmo, tmp;
- if (usec >= 1000) {
/*
* if "big" number, spread normalization
* to seconds
* 1. start to normalize for usec to ticks per sec
* 2. find number of "ticks" to wait to achieve target
* 3. finish normalize.
*/
tmo = usec / 1000;
tmo *= gd->timer_rate_hz;
tmo /= 1000;
- } else {
/* else small number, don't kill it prior to HZ multiply */
tmo = usec * gd->timer_rate_hz;
tmo /= (1000 * 1000);
- }
- /* get current timestamp */
- tmp = get_current_tick();
- /* if setting this fordward will roll time stamp */
- /* reset "advancing" timestamp to 0, set lastinc value */
- /* else, set advancing stamp wake up time */
/* * multi * line * comment */
- if ((tmo + tmp + 1) < tmp)
reset_timer_masked();
- else
tmo += tmp;
- /* loop till event */
- while (get_current_tick() < tmo)
/* NOP */;
+}
+void reset_timer_masked(void) +{
- struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
- /* reset time */
- gd->lastinc = readl(&timers->tcnto4);
- gd->tbl = 0;
+}
+ulong get_timer_masked(void) +{
- return get_current_tick() / gd->tbu;
+}
+/*
- This function is derived from PowerPC code (read timebase as long
long). + * On ARM it just returns the timer value.
- */
+unsigned long long get_ticks(void) +{
- return get_timer_masked();
+}
+/*
- This function is derived from PowerPC code (timebase clock frequency).
- On ARM it returns the number of timer ticks per second.
- */
+ulong get_tbclk(void) +{
- return CONFIG_SYS_HZ;
+}
[...]
diff --git a/include/common.h b/include/common.h index 55025c0..36f0636 100644 --- a/include/common.h +++ b/include/common.h @@ -628,6 +628,7 @@ ulong get_OPB_freq (void); ulong get_PCI_freq (void); #endif #if defined(CONFIG_S3C24X0) || \
- defined(CONFIG_S3C24XX) || \ defined(CONFIG_LH7A40X) || \ defined(CONFIG_S3C6400) || \ defined(CONFIG_EP93XX)
What's this change? Split into different patch please.

On Fri, Sep 14, 2012 at 06:28:53PM +0100, Jos?? Miguel Gon??alves wrote:
This patch adds the support for Samsung's S3C24XX SoCs that have an ARM926EJS core. Currently it supports S3C2412, S3C2413, S3C2416 and S3C2450. Tested on an S3C2416 platform.
[snip]
+/*
- Reset the cpu by setting up the watchdog timer and let him time out.
- */
+void reset_cpu(ulong addr) +{
- struct s3c24xx_watchdog *const watchdog = s3c24xx_get_base_watchdog();
- /* Disable watchdog */
- writel(0x0000, &watchdog->wtcon);
- /* Initialize watchdog timer count register */
- writel(0x0001, &watchdog->wtcnt);
- /* Enable watchdog timer; assert reset at timer timeout */
- writel(WTCON_RSTEN | WTCON_ENABLE, &watchdog->wtcon);
- while (1)
/* loop forever and wait for reset to happen */;
+}
As we're dealing with in another series, this should be __noreturn (from <linux/compiler.h>).
Also, please audit your new headers to make sure you aren't adding structs / defines / etc that you aren't using by the end of the series, and make sure to note in the cover letter that you are checkpatch clean or explain away the false positives. Thanks!

S3C2416 and S3C2450 have 4 UARTs insted of 3 found on older chips. This patch adds support to the additional UART port and changes the mapping between CONFIG_SERIAL? and S3C24X0_UART? in order they have a direct correspondence.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - New patch --- drivers/serial/serial_s3c24x0.c | 25 ++++++++++++++++++------- include/configs/VCMA9.h | 2 +- include/configs/smdk2410.h | 2 +- 3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c index 12bcdd3..280cd2d 100644 --- a/drivers/serial/serial_s3c24x0.c +++ b/drivers/serial/serial_s3c24x0.c @@ -2,6 +2,9 @@ * (C) Copyright 2002 * Gary Jennejohn, DENX Software Engineering, garyj@denx.de * + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or @@ -24,17 +27,20 @@
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_SERIAL1 +#if defined(CONFIG_SERIAL0) #define UART_NR S3C24X0_UART0
-#elif defined(CONFIG_SERIAL2) +#elif defined(CONFIG_SERIAL1) #define UART_NR S3C24X0_UART1
-#elif defined(CONFIG_SERIAL3) +#elif defined(CONFIG_SERIAL2) #define UART_NR S3C24X0_UART2
+#elif defined(CONFIG_SERIAL3) +#define UART_NR S3C24X0_UART3 + #else -#error "Bad: you didn't configure serial ..." +#error "You didn't configure serial." #endif
#include <asm/io.h> @@ -310,15 +316,20 @@ INIT_S3C_SERIAL_STRUCTURE(1, "s3ser1"); DECLARE_S3C_SERIAL_FUNCTIONS(2); struct serial_device s3c24xx_serial2_device = INIT_S3C_SERIAL_STRUCTURE(2, "s3ser2"); +DECLARE_S3C_SERIAL_FUNCTIONS(3); +struct serial_device s3c24xx_serial3_device = +INIT_S3C_SERIAL_STRUCTURE(3, "s3ser3");
__weak struct serial_device *default_serial_console(void) { -#if defined(CONFIG_SERIAL1) +#if defined(CONFIG_SERIAL0) return &s3c24xx_serial0_device; -#elif defined(CONFIG_SERIAL2) +#elif defined(CONFIG_SERIAL1) return &s3c24xx_serial1_device; -#elif defined(CONFIG_SERIAL3) +#elif defined(CONFIG_SERIAL2) return &s3c24xx_serial2_device; +#elif defined(CONFIG_SERIAL3) + return &s3c24xx_serial3_device; #else #error "CONFIG_SERIAL? missing." #endif diff --git a/include/configs/VCMA9.h b/include/configs/VCMA9.h index 06adc94..46bc22d 100644 --- a/include/configs/VCMA9.h +++ b/include/configs/VCMA9.h @@ -120,7 +120,7 @@ * select serial console configuration */ #define CONFIG_S3C24X0_SERIAL -#define CONFIG_SERIAL1 1 /* we use SERIAL 1 on VCMA9 */ +#define CONFIG_SERIAL0 1 /* we use SERIAL 0 on VCMA9 */
/* USB support (currently only works with D-cache off) */ #define CONFIG_USB_OHCI diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h index 1c0978d..5daa3fe 100644 --- a/include/configs/smdk2410.h +++ b/include/configs/smdk2410.h @@ -60,7 +60,7 @@ * select serial console configuration */ #define CONFIG_S3C24X0_SERIAL -#define CONFIG_SERIAL1 1 /* we use SERIAL 1 on SMDK2410 */ +#define CONFIG_SERIAL0 1 /* we use SERIAL 0 on SMDK2410 */
/************************************************************ * USB support (currently only works with D-cache off)

Program udivslot register in order to obtain a more precise baudrate.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - New patch --- drivers/serial/serial_s3c24x0.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c index 280cd2d..c9bc121 100644 --- a/drivers/serial/serial_s3c24x0.c +++ b/drivers/serial/serial_s3c24x0.c @@ -92,16 +92,32 @@ DECLARE_GLOBAL_DATA_PTR; static int hwflow; #endif
+/* + * The values stored in the baud rate divisor register (UBRDIVn) and dividing + * slot register (UDIVSLOTn), are used to determine the serial Tx/Rx clock rate + * (baud rate) as follows: + * DIV_VAL = UBRDIVn + (num of 1’s in UDIVSLOTn) / 16 + * Using UDIVSLOT, which is the factor of floating point divisor, you can make + * more accurate baud rate. Section 2.1.10 of the S3C2416 User's Manual suggests + * using the constants on the following table. + */ +static const int udivslot[] = { + 0x0000, 0x0080, 0x0808, 0x0888, 0x2222, 0x4924, 0x4A52, 0x54AA, + 0x5555, 0xD555, 0xD5D5, 0xDDD5, 0xDDDD, 0xDFDD, 0xDFDF, 0xFFDF, +}; + void _serial_setbrg(const int dev_index) { struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index); - unsigned int reg = 0; + u32 pclk; + u32 baudrate; int i;
- /* value is calculated so : (int)(PCLK/16./baudrate) -1 */ - reg = get_PCLK() / (16 * gd->baudrate) - 1; + pclk = get_PCLK(); + baudrate = gd->baudrate;
- writel(reg, &uart->ubrdiv); + writel((pclk / baudrate / 16) - 1, &uart->ubrdiv); + writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot); for (i = 0; i < 100; i++) /* Delay */ ; }

Dear José Miguel Gonçalves,
Program udivslot register in order to obtain a more precise baudrate.
More explanatory commit message would be nice.
[...]
+static const int udivslot[] = {
const array const members, no ?
- 0x0000, 0x0080, 0x0808, 0x0888, 0x2222, 0x4924, 0x4A52, 0x54AA,
- 0x5555, 0xD555, 0xD5D5, 0xDDD5, 0xDDDD, 0xDFDD, 0xDFDF, 0xFFDF,
+};
void _serial_setbrg(const int dev_index) { struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
- unsigned int reg = 0;
- u32 pclk;
- u32 baudrate; int i;
- /* value is calculated so : (int)(PCLK/16./baudrate) -1 */
- reg = get_PCLK() / (16 * gd->baudrate) - 1;
- pclk = get_PCLK();
- baudrate = gd->baudrate;
- writel(reg, &uart->ubrdiv);
- writel((pclk / baudrate / 16) - 1, &uart->ubrdiv);
- writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot); for (i = 0; i < 100; i++) /* Delay */ ;
}
Best regards, Marek Vasut

The loop used to make a delay after baudrate setting is not necessary. Moreover it is removed by the GCC optimizer (at least with GCC 4.6).
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - New patch --- drivers/serial/serial_s3c24x0.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c index c9bc121..ec5d1cb 100644 --- a/drivers/serial/serial_s3c24x0.c +++ b/drivers/serial/serial_s3c24x0.c @@ -111,15 +111,12 @@ void _serial_setbrg(const int dev_index) struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index); u32 pclk; u32 baudrate; - int i;
pclk = get_PCLK(); baudrate = gd->baudrate;
writel((pclk / baudrate / 16) - 1, &uart->ubrdiv); writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot); - for (i = 0; i < 100; i++) - /* Delay */ ; }
#if defined(CONFIG_SERIAL_MULTI)

Dear José Miguel Gonçalves,
The loop used to make a delay after baudrate setting is not necessary. Moreover it is removed by the GCC optimizer (at least with GCC 4.6).
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Acked-by: Marek Vasut marex@denx.de
Changes for v2:
- New patch
drivers/serial/serial_s3c24x0.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c index c9bc121..ec5d1cb 100644 --- a/drivers/serial/serial_s3c24x0.c +++ b/drivers/serial/serial_s3c24x0.c @@ -111,15 +111,12 @@ void _serial_setbrg(const int dev_index) struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index); u32 pclk; u32 baudrate;
int i;
pclk = get_PCLK(); baudrate = gd->baudrate;
writel((pclk / baudrate / 16) - 1, &uart->ubrdiv); writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot);
for (i = 0; i < 100; i++)
/* Delay */ ;
}
#if defined(CONFIG_SERIAL_MULTI)
Best regards, Marek Vasut

A better approach to avoid reading the RTC during updates, as sugested in the S3C2416 User's Manual.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - New patch --- drivers/rtc/s3c24x0_rtc.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c index c16ff2e..7d04b74 100644 --- a/drivers/rtc/s3c24x0_rtc.c +++ b/drivers/rtc/s3c24x0_rtc.c @@ -65,20 +65,26 @@ int rtc_get(struct rtc_time *tmp) uchar sec, min, hour, mday, wday, mon, year; __maybe_unused uchar a_sec, a_min, a_hour, a_date, a_mon, a_year, a_armed; + int have_retried = 0;
/* enable access to RTC registers */ SetRTC_Access(RTC_ENABLE);
/* read RTC registers */ do { - sec = readb(&rtc->bcdsec); min = readb(&rtc->bcdmin); hour = readb(&rtc->bcdhour); mday = readb(&rtc->bcddate); wday = readb(&rtc->bcdday); mon = readb(&rtc->bcdmon); year = readb(&rtc->bcdyear); - } while (sec != readb(&rtc->bcdsec)); + sec = readb(&rtc->bcdsec); + /* + * The only way to work out whether the RTC was mid-update + * when we read it is to check the seconds counter. + * If it's zero, then we re-try the entire read. + */ + } while ((sec == 0) && !(have_retried++));
/* read ALARM registers */ a_sec = readb(&rtc->almsec);

Dear José Miguel Gonçalves,
A better approach to avoid reading the RTC during updates, as sugested in the S3C2416 User's Manual.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2:
- New patch
drivers/rtc/s3c24x0_rtc.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c index c16ff2e..7d04b74 100644 --- a/drivers/rtc/s3c24x0_rtc.c +++ b/drivers/rtc/s3c24x0_rtc.c @@ -65,20 +65,26 @@ int rtc_get(struct rtc_time *tmp) uchar sec, min, hour, mday, wday, mon, year; __maybe_unused uchar a_sec, a_min, a_hour, a_date, a_mon, a_year, a_armed;
int have_retried = 0;
/* enable access to RTC registers */ SetRTC_Access(RTC_ENABLE);
/* read RTC registers */ do {
min = readb(&rtc->bcdmin); hour = readb(&rtc->bcdhour); mday = readb(&rtc->bcddate); wday = readb(&rtc->bcdday); mon = readb(&rtc->bcdmon); year = readb(&rtc->bcdyear);sec = readb(&rtc->bcdsec);
- } while (sec != readb(&rtc->bcdsec));
sec = readb(&rtc->bcdsec);
/*
* The only way to work out whether the RTC was mid-update
* when we read it is to check the seconds counter.
* If it's zero, then we re-try the entire read.
*/
- } while ((sec == 0) && !(have_retried++));
You don't need that parens around (have_retried++)
/* read ALARM registers */ a_sec = readb(&rtc->almsec);
Best regards, Marek Vasut

rtc_reset() must set the RTC date to the UNIX Epoch.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - New patch --- drivers/rtc/s3c24x0_rtc.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c index 7d04b74..54bf6e3 100644 --- a/drivers/rtc/s3c24x0_rtc.c +++ b/drivers/rtc/s3c24x0_rtc.c @@ -167,10 +167,17 @@ int rtc_set(struct rtc_time *tmp)
void rtc_reset(void) { - struct s3c24x0_rtc *rtc = s3c24x0_get_base_rtc(); - - writeb((readb(&rtc->rtccon) & ~0x06) | 0x08, &rtc->rtccon); - writeb(readb(&rtc->rtccon) & ~(0x08 | 0x01), &rtc->rtccon); + static struct rtc_time tmp = { + .tm_year = 1970, + .tm_mon = 1, + .tm_mday = 1, + .tm_wday = 4, + .tm_hour = 0, + .tm_min = 0, + .tm_sec = 0, + }; + + rtc_set(&tmp); }
#endif

Dear José Miguel Gonçalves,
rtc_reset() must set the RTC date to the UNIX Epoch.
Acked-by: Marek Vasut marex@denx.de
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2:
- New patch
drivers/rtc/s3c24x0_rtc.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c index 7d04b74..54bf6e3 100644 --- a/drivers/rtc/s3c24x0_rtc.c +++ b/drivers/rtc/s3c24x0_rtc.c @@ -167,10 +167,17 @@ int rtc_set(struct rtc_time *tmp)
void rtc_reset(void) {
- struct s3c24x0_rtc *rtc = s3c24x0_get_base_rtc();
- writeb((readb(&rtc->rtccon) & ~0x06) | 0x08, &rtc->rtccon);
- writeb(readb(&rtc->rtccon) & ~(0x08 | 0x01), &rtc->rtccon);
- static struct rtc_time tmp = {
.tm_year = 1970,
.tm_mon = 1,
.tm_mday = 1,
.tm_wday = 4,
.tm_hour = 0,
.tm_min = 0,
.tm_sec = 0,
- };
- rtc_set(&tmp);
}
#endif
Best regards, Marek Vasut

This RTC only supports a 100 years range so rtc_set() should not allow setting years bellow 1970 or above 2069.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - New patch --- drivers/rtc/s3c24x0_rtc.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c index 54bf6e3..f96cb11 100644 --- a/drivers/rtc/s3c24x0_rtc.c +++ b/drivers/rtc/s3c24x0_rtc.c @@ -139,6 +139,11 @@ int rtc_set(struct rtc_time *tmp) tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday, tmp->tm_hour, tmp->tm_min, tmp->tm_sec); #endif + if (tmp->tm_year < 1970 || tmp->tm_year > 2069) { + puts("ERROR: year should be between 1970 and 2069!\n"); + return -1; + } + year = bin2bcd(tmp->tm_year % 100); mon = bin2bcd(tmp->tm_mon); wday = bin2bcd(tmp->tm_wday);

Dear José Miguel Gonçalves,
This RTC only supports a 100 years range so rtc_set() should not allow setting years bellow 1970 or above 2069.
Acked-by: Marek Vasut marex@denx.de
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2:
- New patch
drivers/rtc/s3c24x0_rtc.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c index 54bf6e3..f96cb11 100644 --- a/drivers/rtc/s3c24x0_rtc.c +++ b/drivers/rtc/s3c24x0_rtc.c @@ -139,6 +139,11 @@ int rtc_set(struct rtc_time *tmp) tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday, tmp->tm_hour, tmp->tm_min, tmp->tm_sec); #endif
- if (tmp->tm_year < 1970 || tmp->tm_year > 2069) {
puts("ERROR: year should be between 1970 and 2069!\n");
return -1;
- }
- year = bin2bcd(tmp->tm_year % 100); mon = bin2bcd(tmp->tm_mon); wday = bin2bcd(tmp->tm_wday);
Best regards, Marek Vasut

NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - Coding style cleanup - Use of clrsetbits_le32() - Use of register bit macros instead of magic numbers --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/s3c24xx_nand.c | 245 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 246 insertions(+) create mode 100644 drivers/mtd/nand/s3c24xx_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 29dc20e..791ec44 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -60,6 +60,7 @@ COBJS-$(CONFIG_NAND_MXS) += mxs_nand.o COBJS-$(CONFIG_NAND_NDFC) += ndfc.o COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o +COBJS-$(CONFIG_NAND_S3C24XX) += s3c24xx_nand.o COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o COBJS-$(CONFIG_NAND_SPEAR) += spr_nand.o COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o diff --git a/drivers/mtd/nand/s3c24xx_nand.c b/drivers/mtd/nand/s3c24xx_nand.c new file mode 100644 index 0000000..9c0f6e2 --- /dev/null +++ b/drivers/mtd/nand/s3c24xx_nand.c @@ -0,0 +1,245 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * Based on drivers/mtd/nand/s3c64xx.c and U-Boot 1.3.4 from Samsung. + * Supports only SLC NAND Flash chips. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h> + +#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0) +#endif + +static void s3c_nand_select_chip(struct mtd_info *mtd, int chip) +{ + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand(); + u_long nfcont; + + nfcont = readl(&nand->nfcont); + + switch (chip) { + case -1: + nfcont |= NFCONT_NCE1 | NFCONT_NCE0; + break; + case 0: + nfcont &= ~NFCONT_NCE0; + break; + case 1: + nfcont &= ~NFCONT_NCE1; + break; + default: + return; + } + + writel(nfcont, &nand->nfcont); +} + +/* + * Hardware specific access to control-lines function + */ +static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) +{ + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand(); + struct nand_chip *this = mtd->priv; + + if (ctrl & NAND_CTRL_CHANGE) { + if (ctrl & NAND_CLE) + this->IO_ADDR_W = &nand->nfcmmd; + else if (ctrl & NAND_ALE) + this->IO_ADDR_W = &nand->nfaddr; + else + this->IO_ADDR_W = &nand->nfdata; + if (ctrl & NAND_NCE) + s3c_nand_select_chip(mtd, *(int *)this->priv); + else + s3c_nand_select_chip(mtd, -1); + } + + if (cmd != NAND_CMD_NONE) + writeb(cmd, this->IO_ADDR_W); +} + +/* + * Function for checking device ready pin + */ +static int s3c_nand_device_ready(struct mtd_info *mtdinfo) +{ + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand(); + + return readl(&nand->nfstat) & NFSTAT_RNB; +} + +#ifdef CONFIG_S3C24XX_NAND_HWECC +/* + * This function is called before encoding ECC codes to ready ECC engine. + */ +static void s3c_nand_enable_hwecc(struct mtd_info *mtd, int mode) +{ + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand(); + + /* Set 1-bit ECC */ + clrsetbits_le32(&nand->nfconf, NFCONF_ECCTYPE_MASK, + NFCONF_ECCTYPE_1BIT); + + /* Initialize & unlock ECC */ + clrsetbits_le32(&nand->nfcont, NFCONT_MECCLOCK, NFCONT_INITMECC); +} + +/* + * This function is called immediately after encoding ECC codes. + * This function returns encoded ECC codes. + */ +static int s3c_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat, + u_char *ecc_code) +{ + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand(); + u_long nfmecc0; + + /* Lock ECC */ + setbits_le32(&nand->nfcont, NFCONT_MECCLOCK); + + /* Return 1-bit ECC */ + nfmecc0 = readl(&nand->nfmecc[0]); + + ecc_code[0] = nfmecc0 & 0xff; + ecc_code[1] = (nfmecc0 >> 8) & 0xff; + ecc_code[2] = (nfmecc0 >> 16) & 0xff; + ecc_code[3] = (nfmecc0 >> 24) & 0xff; + + return 0; +} + +/* + * This function determines whether read data is good or not. + * On SLC, must write ECC codes to controller before reading status bit. + * If status bit is good, return 0. + * If a correctable error occured, correct it and return 1. + * If an uncorrectable error occured, return -1. + */ +static int s3c_nand_correct_data(struct mtd_info *mtd, u_char *dat, + u_char *read_ecc, u_char *calc_ecc) +{ + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand(); + int ret; + u_long nfeccerr0, nfmeccdata0, nfmeccdata1, err_byte_addr; + u_char err_type, repaired; + + /* SLC: Write ECC to compare */ + nfmeccdata0 = (((u_long) read_ecc[1]) << 16) | read_ecc[0]; + nfmeccdata1 = (((u_long) read_ecc[3]) << 16) | read_ecc[2]; + writel(nfmeccdata0, &nand->nfmeccd[0]); + writel(nfmeccdata1, &nand->nfmeccd[1]); + + /* Read ECC status */ + nfeccerr0 = readl(&nand->nfeccerr[0]); + err_type = nfeccerr0 & 0x3; + + switch (err_type) { + case 0: /* No error */ + ret = 0; + break; + + case 1: + /* + * 1 bit error (Correctable) + * (nfeccerr0 >> 7) & 0x7ff :error byte number + * (nfeccerr0 >> 4) & 0x7 :error bit number + */ + err_byte_addr = (nfeccerr0 >> 7) & 0x7ff; + repaired = dat[err_byte_addr] ^ (1 << ((nfeccerr0 >> 4) & 0x7)); + + printf("S3C24XX NAND: 1 bit error detected at byte %ld. " + "Correcting from 0x%02x to 0x%02x\n", + err_byte_addr, dat[err_byte_addr], repaired); + + dat[err_byte_addr] = repaired; + + ret = 1; + break; + + case 2: /* Multiple error */ + case 3: /* ECC area error */ + printf("S3C24XX NAND: ECC uncorrectable error detected.\n"); + ret = -1; + break; + } + + return ret; +} +#endif /* CONFIG_S3C24XX_NAND_HWECC */ + +/* + * Board-specific NAND initialization. + */ +int board_nand_init(struct nand_chip *nand) +{ + static int chip_n; + struct s3c24xx_nand *const nand_reg = s3c24xx_get_base_nand(); + + if (chip_n == 0) { + /* Extend NAND timings to the maximum */ + clrsetbits_le32(&nand_reg->nfconf, + NFCONF_TACLS_MASK | NFCONF_TWRPH0_MASK | + NFCONF_TWRPH1_MASK, + NFCONF_TACLS(7) | NFCONF_TWRPH0(7) | + NFCONF_TWRPH1(7)); + + /* Disable chip selects and soft lock, enable controller */ + clrsetbits_le32(&nand_reg->nfcont, NFCONT_WP, + NFCONT_NCE1 | NFCONT_NCE0 | NFCONT_ENABLE); + } else if (chip_n >= MAX_CHIPS) { + return -ENODEV; + } + + nand->IO_ADDR_R = &nand_reg->nfdata; + nand->IO_ADDR_W = &nand_reg->nfdata; + nand->cmd_ctrl = s3c_nand_hwcontrol; + nand->dev_ready = s3c_nand_device_ready; + nand->select_chip = s3c_nand_select_chip; + nand->options = 0; +#ifdef CONFIG_SPL_BUILD + nand->read_buf = nand_read_buf; +#endif + +#ifdef CONFIG_S3C24XX_NAND_HWECC + nand->ecc.hwctl = s3c_nand_enable_hwecc; + nand->ecc.calculate = s3c_nand_calculate_ecc; + nand->ecc.correct = s3c_nand_correct_data; + nand->ecc.mode = NAND_ECC_HW_OOB_FIRST; + nand->ecc.size = CONFIG_SYS_NAND_ECCSIZE; + nand->ecc.bytes = CONFIG_SYS_NAND_ECCBYTES; +#else + nand->ecc.mode = NAND_ECC_SOFT; +#endif /* ! CONFIG_S3C24XX_NAND_HWECC */ + + nand->priv = nand_cs + chip_n++; + + return 0; +}

Dear José Miguel Gonçalves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
1) this should be in CPU directory 2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be inline function, not a macro
+#endif
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip) +{
- struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
- u_long nfcont;
- nfcont = readl(&nand->nfcont);
- switch (chip) {
- case -1:
nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
break;
- case 0:
nfcont &= ~NFCONT_NCE0;
break;
- case 1:
nfcont &= ~NFCONT_NCE1;
break;
- default:
return;
- }
- writel(nfcont, &nand->nfcont);
+}
+/*
- Hardware specific access to control-lines function
- */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) +{
- struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
- struct nand_chip *this = mtd->priv;
- if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_CLE)
this->IO_ADDR_W = &nand->nfcmmd;
else if (ctrl & NAND_ALE)
this->IO_ADDR_W = &nand->nfaddr;
else
this->IO_ADDR_W = &nand->nfdata;
Why don't you use local variable here?
if (ctrl & NAND_NCE)
s3c_nand_select_chip(mtd, *(int *)this->priv);
Uh, how's this *(int *) supposed to work? [...]

On 14-09-2012 19:21, Marek Vasut wrote:
Dear José Miguel Gonçalves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
1) and 3) OK. Don't quite understand 2). I want to remove the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
+#endif
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip) +{
- struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
- u_long nfcont;
- nfcont = readl(&nand->nfcont);
- switch (chip) {
- case -1:
nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
break;
- case 0:
nfcont &= ~NFCONT_NCE0;
break;
- case 1:
nfcont &= ~NFCONT_NCE1;
break;
- default:
return;
- }
- writel(nfcont, &nand->nfcont);
+}
+/*
- Hardware specific access to control-lines function
- */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) +{
- struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
- struct nand_chip *this = mtd->priv;
- if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_CLE)
this->IO_ADDR_W = &nand->nfcmmd;
else if (ctrl & NAND_ALE)
this->IO_ADDR_W = &nand->nfaddr;
else
this->IO_ADDR_W = &nand->nfdata;
Why don't you use local variable here?
Because you need to retain the NAND controller register to use between calls to s3c_nand_hwcontrol(). If you call the function without the NAND_CTRL_CHANGE bit set in the parameter 'ctrl' you must use the register used on the last call on the next access.
if (ctrl & NAND_NCE)
s3c_nand_select_chip(mtd, *(int *)this->priv);
Uh, how's this *(int *) supposed to work?
*(int *)this->priv contains an integer that is the chip id (0 or 1).
Best regards, José Gonçalves
Best regards, José Gonçalves

On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
- and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my SPL series that's still enough to get you printf/puts (I believe 4kb was the cutoff where that had to be dropped).

On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
- and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my SPL series that's still enough to get you printf/puts (I believe 4kb was the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...

On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
- and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my SPL series that's still enough to get you printf/puts (I believe 4kb was the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...
There's two parts to this: - What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :) - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).

On 09/17/2012 11:57:57 AM, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves
wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
- and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least
in my
SPL series that's still enough to get you printf/puts (I believe
4kb was
the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184
u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...
There's two parts to this:
- What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and
SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :)
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to
the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).
Weak symbols are not OK for configuring printf out of the SPL, as you'll still have all the format strings and caller code in the binary. It should be a macro (or an inline function that replaces the standard printf declaration), but it should be in a system header (not the CPU directory -- not sure what Marek meant there) and be based on an appropriate CONFIG symbol.
-Scott

On 09/17/12 10:03, Scott Wood wrote:
On 09/17/2012 11:57:57 AM, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
>NAND Flash driver with HW ECC for the S3C24XX SoCs. >Currently it only supports SLC NAND chips. > >Signed-off-by: Jos? Miguel Gon?alves jose.goncalves@inov.pt [...]
>+#include <common.h> >+#include <nand.h> >+#include <asm/io.h> >+#include <asm/arch/s3c24xx_cpu.h> >+#include <asm/errno.h> >+ >+#define MAX_CHIPS 2 >+static int nand_cs[MAX_CHIPS] = { 0, 1 }; >+ >+#ifdef CONFIG_SPL_BUILD >+#define printf(arg...) do {} while (0) This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
- and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least
in my
SPL series that's still enough to get you printf/puts (I believe
4kb was
the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...
There's two parts to this:
- What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :)
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).
Weak symbols are not OK for configuring printf out of the SPL, as you'll still have all the format strings and caller code in the binary. It should be a macro (or an inline function that replaces the standard printf declaration), but it should be in a system header (not the CPU directory -- not sure what Marek meant there) and be based on an appropriate CONFIG symbol.
I'm a little leery of adding #if ... into <common.h> around printf. I'd like to not worry about the branch/return bytes until we really really have to again but yes, the strings are more of a concern since they won't be collected out. Just top of my head thinking above.

On 09/17/2012 12:08:17 PM, Tom Rini wrote:
On 09/17/12 10:03, Scott Wood wrote:
Weak symbols are not OK for configuring printf out of the SPL, as
you'll
still have all the format strings and caller code in the binary. It should be a macro (or an inline function that replaces the standard printf declaration), but it should be in a system header (not the
CPU
directory -- not sure what Marek meant there) and be based on an appropriate CONFIG symbol.
I'm a little leery of adding #if ... into <common.h> around printf. I'd like to not worry about the branch/return bytes until we really really have to again but yes, the strings are more of a concern since they won't be collected out. Just top of my head thinking above.
Caller code won't be collected either. It's not just branch/return bytes but argument preparation -- possibly significant chunks of code to calculate values to be displayed, that might otherwise be optimized out.
-Scott

On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
- and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my SPL series that's still enough to get you printf/puts (I believe 4kb was the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...
There's two parts to this:
- What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future expansion! Being able to boot also from an SD card. With only 8KB for .text and .data, I can not use printfs in the SPL for this platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/17/12 10:08, José Miguel Gonçalves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
> NAND Flash driver with HW ECC for the S3C24XX SoCs. > Currently it only supports SLC NAND chips. > > Signed-off-by: Jos? Miguel Gon?alves > jose.goncalves@inov.pt [...]
> +#include <common.h> +#include <nand.h> +#include > <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include > <asm/errno.h> + +#define MAX_CHIPS 2 +static int > nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef > CONFIG_SPL_BUILD +#define printf(arg...) do {} while > (0) This doesn't seem quite right ...
- this should be in CPU directory 2) should be enabled
only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be inline function, not a macro
- and 3) OK. Don't quite understand 2). I want to remove
the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my SPL series that's still enough to get you printf/puts (I believe 4kb was the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...
There's two parts to this: - What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future expansion! Being able to boot also from an SD card. With only 8KB for .text and .data, I can not use printfs in the SPL for this platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series, keeping in mind what Scott has said (which makes sense) because otherwise you'll be changing a lot of MMC files too to drop out printf :)
- -- Tom

On 17-09-2012 18:56, Tom Rini wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/17/12 10:08, José Miguel Gonçalves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote: > Dear Jos? Miguel Gon?alves, > >> NAND Flash driver with HW ECC for the S3C24XX SoCs. >> Currently it only supports SLC NAND chips. >> >> Signed-off-by: Jos? Miguel Gon?alves >> jose.goncalves@inov.pt > [...] > >> +#include <common.h> +#include <nand.h> +#include >> <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include >> <asm/errno.h> + +#define MAX_CHIPS 2 +static int >> nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef >> CONFIG_SPL_BUILD +#define printf(arg...) do {} while >> (0) > This doesn't seem quite right ... > > 1) this should be in CPU directory 2) should be enabled > only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be > inline function, not a macro
- and 3) OK. Don't quite understand 2). I want to remove
the printfs in the SPL build, as it would blown up the internal SoC RAM space available. So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my SPL series that's still enough to get you printf/puts (I believe 4kb was the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...
There's two parts to this: - What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future expansion! Being able to boot also from an SD card. With only 8KB for .text and .data, I can not use printfs in the SPL for this platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series, keeping in mind what Scott has said (which makes sense) because otherwise you'll be changing a lot of MMC files too to drop out printf :)
The solution that I sorted out on the current SPL framework was to add this:
#ifdef CONFIG_SPL_BUILD #define printf(arg...) do {} while (0) #ifdef CONFIG_SPL_SERIAL_SUPPORT #define puts(arg) serial_puts(arg) #endif #endif
on a CPU specific header. Marek told me to not use macros, but to use inline functions instead, but has I told earlier on this thread, I am unable to do that. Suggestions for doing this in a better way are welcome...

On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:
On 17-09-2012 18:56, Tom Rini wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote: >On 14-09-2012 19:21, Marek Vasut wrote: >>Dear Jos? Miguel Gon?alves, >> >>>NAND Flash driver with HW ECC for the S3C24XX SoCs. >>>Currently it only supports SLC NAND chips. >>> >>>Signed-off-by: Jos? Miguel Gon?alves >>>jose.goncalves@inov.pt >>[...] >> >>>+#include <common.h> +#include <nand.h> +#include >>><asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include >>><asm/errno.h> + +#define MAX_CHIPS 2 +static int >>>nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef >>>CONFIG_SPL_BUILD +#define printf(arg...) do {} while >>>(0) >>This doesn't seem quite right ... >> >>1) this should be in CPU directory 2) should be enabled >>only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be >>inline function, not a macro >1) and 3) OK. Don't quite understand 2). I want to remove >the printfs in the SPL build, as it would blown up the >internal SoC RAM space available. So why add a condition >with CONFIG_SPL_SERIAL_SUPPORT? You've got 8KB, based on the final patch in the series. At least in my SPL series that's still enough to get you printf/puts (I believe 4kb was the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...
There's two parts to this: - What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future expansion! Being able to boot also from an SD card. With only 8KB for .text and .data, I can not use printfs in the SPL for this platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series, keeping in mind what Scott has said (which makes sense) because otherwise you'll be changing a lot of MMC files too to drop out printf :)
The solution that I sorted out on the current SPL framework was to add this:
#ifdef CONFIG_SPL_BUILD #define printf(arg...) do {} while (0) #ifdef CONFIG_SPL_SERIAL_SUPPORT #define puts(arg) serial_puts(arg) #endif #endif
on a CPU specific header. Marek told me to not use macros, but to use inline functions instead, but has I told earlier on this thread, I am unable to do that. Suggestions for doing this in a better way are welcome...
It's gotta go in <common.h>, and something like /* Big comment what / why */ #if !defined(CONFIG_SPL_BUILD) || \ (CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT) void putc(...); void puts(...); int printf(....); #else #define putc(c) serial_putc(c) #define puts(s) serial_puts(s) #define printf(arg...) do {} while (0) #endif

On 17-09-2012 19:27, Tom Rini wrote:
On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:
On 17-09-2012 18:56, Tom Rini wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote: > On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel > Gon?alves wrote: >> On 14-09-2012 19:21, Marek Vasut wrote: >>> Dear Jos? Miguel Gon?alves, >>> >>>> NAND Flash driver with HW ECC for the S3C24XX SoCs. >>>> Currently it only supports SLC NAND chips. >>>> >>>> Signed-off-by: Jos? Miguel Gon?alves >>>> jose.goncalves@inov.pt >>> [...] >>> >>>> +#include <common.h> +#include <nand.h> +#include >>>> <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include >>>> <asm/errno.h> + +#define MAX_CHIPS 2 +static int >>>> nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef >>>> CONFIG_SPL_BUILD +#define printf(arg...) do {} while >>>> (0) >>> This doesn't seem quite right ... >>> >>> 1) this should be in CPU directory 2) should be enabled >>> only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be >>> inline function, not a macro >> 1) and 3) OK. Don't quite understand 2). I want to remove >> the printfs in the SPL build, as it would blown up the >> internal SoC RAM space available. So why add a condition >> with CONFIG_SPL_SERIAL_SUPPORT? > You've got 8KB, based on the final patch in the series. At > least in my SPL series that's still enough to get you > printf/puts (I believe 4kb was the cutoff where that had to > be dropped). > Barely:
$ size u-boot-spl text data bss dec hex filename 3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf text data bss dec hex filename 7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space available and preventing any future SPL expansion...
There's two parts to this: - What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future expansion! Being able to boot also from an SD card. With only 8KB for .text and .data, I can not use printfs in the SPL for this platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series, keeping in mind what Scott has said (which makes sense) because otherwise you'll be changing a lot of MMC files too to drop out printf :)
The solution that I sorted out on the current SPL framework was to add this:
#ifdef CONFIG_SPL_BUILD #define printf(arg...) do {} while (0) #ifdef CONFIG_SPL_SERIAL_SUPPORT #define puts(arg) serial_puts(arg) #endif #endif
on a CPU specific header. Marek told me to not use macros, but to use inline functions instead, but has I told earlier on this thread, I am unable to do that. Suggestions for doing this in a better way are welcome...
It's gotta go in <common.h>, and something like /* Big comment what / why */ #if !defined(CONFIG_SPL_BUILD) || \ (CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT) void putc(...); void puts(...); int printf(....); #else #define putc(c) serial_putc(c) #define puts(s) serial_puts(s) #define printf(arg...) do {} while (0) #endif
Are macros OK to remove printf() and to replace putc()/puts() by serial_putc()/serial_puts() in the SPL? Shouldn’t we be using inline functions instead?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/17/12 11:34, José Miguel Gonçalves wrote:
On 17-09-2012 19:27, Tom Rini wrote:
On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:
On 17-09-2012 18:56, Tom Rini wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote: > On 09/14/2012 08:01 PM, Tom Rini wrote: >> On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? >> Miguel Gon?alves wrote: >>> On 14-09-2012 19:21, Marek Vasut wrote: >>>> Dear Jos? Miguel Gon?alves, >>>> >>>>> NAND Flash driver with HW ECC for the S3C24XX >>>>> SoCs. Currently it only supports SLC NAND >>>>> chips. >>>>> >>>>> Signed-off-by: Jos? Miguel Gon?alves >>>>> jose.goncalves@inov.pt >>>> [...] >>>> >>>>> +#include <common.h> +#include <nand.h> >>>>> +#include <asm/io.h> +#include >>>>> <asm/arch/s3c24xx_cpu.h> +#include >>>>> <asm/errno.h> + +#define MAX_CHIPS 2 +static >>>>> int nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef >>>>> CONFIG_SPL_BUILD +#define printf(arg...) do {} >>>>> while (0) >>>> This doesn't seem quite right ... >>>> >>>> 1) this should be in CPU directory 2) should be >>>> enabled only if CONFIG_SPL_SERIAL_SUPPORT is not >>>> set 3) should be inline function, not a macro >>> 1) and 3) OK. Don't quite understand 2). I want to >>> remove the printfs in the SPL build, as it would >>> blown up the internal SoC RAM space available. So >>> why add a condition with >>> CONFIG_SPL_SERIAL_SUPPORT? >> You've got 8KB, based on the final patch in the >> series. At least in my SPL series that's still >> enough to get you printf/puts (I believe 4kb was the >> cutoff where that had to be dropped). >> > Barely: > > $ size u-boot-spl text data bss > dec hex filename 3337 8 588 > 3933 f5d u-boot-spl > > $ size u-boot-spl-printf text data bss > dec hex filename 7968 8 604 > 8580 2184 u-boot-spl-printf > > The printf is not so important that justifies > exhausting the IRAM space available and preventing any > future SPL expansion... There's two parts to this: - What else can you do in a single binary, in theory? Is there boot medium detection and you would want to have, for example, NAND and SD support in the same binary? I would say memory is meant for using, but this is a board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future expansion! Being able to boot also from an SD card. With only 8KB for .text and .data, I can not use printfs in the SPL for this platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT)
that toggles printf or no printf. If we really need to say yes to LIBCOMMON_SUPPORT and no to printf, we need finer grained config options and then a do-nothing printf is used for SPL. Doing the opt-out driver by driver just punts this problem down the road to the next developer and that's not very nice (and adding CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few Makefiles, update a bunch of config files, add common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series, keeping in mind what Scott has said (which makes sense) because otherwise you'll be changing a lot of MMC files too to drop out printf :)
The solution that I sorted out on the current SPL framework was to add this:
#ifdef CONFIG_SPL_BUILD #define printf(arg...) do {} while (0) #ifdef CONFIG_SPL_SERIAL_SUPPORT #define puts(arg) serial_puts(arg) #endif #endif
on a CPU specific header. Marek told me to not use macros, but to use inline functions instead, but has I told earlier on this thread, I am unable to do that. Suggestions for doing this in a better way are welcome...
It's gotta go in <common.h>, and something like /* Big comment what / why */ #if !defined(CONFIG_SPL_BUILD) || \ (CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT) void putc(...); void puts(...); int printf(....); #else #define putc(c) serial_putc(c) #define puts(s) serial_puts(s) #define printf(arg...) do {} while (0) #endif
Are macros OK to remove printf() and to replace putc()/puts() by serial_putc()/serial_puts() in the SPL? Shouldn’t we be using inline functions instead?
As Scott pointed out, inline won't remove the string constants from the binary so it will still be possibly too large, depending on all of the code in question. And note the above isn't 100% right, we need a test for SERIAL_SUPPORT in there too.
- -- Tom

On Fri, Sep 14, 2012 at 08:21:11PM +0200, Marek Vasut wrote:
Dear José Miguel Gonçalves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
What specifically should be in the CPU directory?
+#endif
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip) +{
- struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
- u_long nfcont;
- nfcont = readl(&nand->nfcont);
- switch (chip) {
- case -1:
nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
break;
- case 0:
nfcont &= ~NFCONT_NCE0;
break;
- case 1:
nfcont &= ~NFCONT_NCE1;
break;
- default:
return;
- }
- writel(nfcont, &nand->nfcont);
+}
+/*
- Hardware specific access to control-lines function
- */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) +{
- struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
- struct nand_chip *this = mtd->priv;
- if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_CLE)
this->IO_ADDR_W = &nand->nfcmmd;
else if (ctrl & NAND_ALE)
this->IO_ADDR_W = &nand->nfaddr;
else
this->IO_ADDR_W = &nand->nfdata;
Why don't you use local variable here?
Because then you'll access the wrong data when the function is called again without NAND_CTRL_CHANGE. This is a common way of writing the hwcontrol function, though the way ndfc.c does it is simpler (you can use a local variable if you ignore NAND_CTRL_CHANGE altogether).
if (ctrl & NAND_NCE)
s3c_nand_select_chip(mtd, *(int *)this->priv);
Uh, how's this *(int *) supposed to work?
Usually driver-private data is a struct; apparently in this driver it's an int.
-Scott

On Fri, Sep 14, 2012 at 02:24:48PM -0500, Scott Wood wrote:
On Fri, Sep 14, 2012 at 08:21:11PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncalves@inov.pt
[snip]
+/*
- Hardware specific access to control-lines function
- */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) +{
- struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
- struct nand_chip *this = mtd->priv;
- if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_CLE)
this->IO_ADDR_W = &nand->nfcmmd;
else if (ctrl & NAND_ALE)
this->IO_ADDR_W = &nand->nfaddr;
else
this->IO_ADDR_W = &nand->nfdata;
Why don't you use local variable here?
Because then you'll access the wrong data when the function is called again without NAND_CTRL_CHANGE. This is a common way of writing the hwcontrol function, though the way ndfc.c does it is simpler (you can use a local variable if you ignore NAND_CTRL_CHANGE altogether).
if (ctrl & NAND_NCE)
s3c_nand_select_chip(mtd, *(int *)this->priv);
Uh, how's this *(int *) supposed to work?
Usually driver-private data is a struct; apparently in this driver it's an int.
Shall we take both of these comments as requests to do things differently (struct like everyone else does, simpiler code like ndfc.c does) unless there's good reason to not change?

On Fri, Sep 14, 2012 at 01:20:32PM -0700, Tom Rini wrote:
On Fri, Sep 14, 2012 at 02:24:48PM -0500, Scott Wood wrote:
On Fri, Sep 14, 2012 at 08:21:11PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncalves@inov.pt
[snip]
+/*
- Hardware specific access to control-lines function
- */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) +{
- struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
- struct nand_chip *this = mtd->priv;
- if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_CLE)
this->IO_ADDR_W = &nand->nfcmmd;
else if (ctrl & NAND_ALE)
this->IO_ADDR_W = &nand->nfaddr;
else
this->IO_ADDR_W = &nand->nfdata;
Why don't you use local variable here?
Because then you'll access the wrong data when the function is called again without NAND_CTRL_CHANGE. This is a common way of writing the hwcontrol function, though the way ndfc.c does it is simpler (you can use a local variable if you ignore NAND_CTRL_CHANGE altogether).
if (ctrl & NAND_NCE)
s3c_nand_select_chip(mtd, *(int *)this->priv);
Uh, how's this *(int *) supposed to work?
Usually driver-private data is a struct; apparently in this driver it's an int.
Shall we take both of these comments as requests to do things differently (struct like everyone else does, simpiler code like ndfc.c does) unless there's good reason to not change?
Sure. :-)
-Scott

Hi Marek,
On 14-09-2012 19:21, Marek Vasut wrote:
Dear José Miguel Gonçalves,
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
[...]
+#include <common.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include <asm/errno.h>
+#define MAX_CHIPS 2 +static int nand_cs[MAX_CHIPS] = { 0, 1 };
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
- this should be in CPU directory
- should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
- should be inline function, not a macro
I'm having difficulties in following this suggestion. No problem if I migrate the printf as a macro to a header in the CPU directory. The problem is when I try to put it as an inline function. In this case if I define it like this;
#ifdef CONFIG_SPL_BUILD static inline int printf(const char *fmt, ...) { return 0; } #endif
I will get an "static declaration of `printf' follows non-static declaration" error due to the printf() declaration in common.h.
If I put this inline printf function (without the static) in a .c file in the CPU directory, it will compile but, as I expected, it will not be inlined, but it will be compiled as a normal function.
Can you detail on how to do this?
Best regards, José Gonçalves

On Fri, Sep 14, 2012 at 06:29:00PM +0100, Jos?? Miguel Gon??alves wrote:
NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt
[snip]
+#ifdef CONFIG_SPL_BUILD +#define printf(arg...) do {} while (0) +#endif
As Marek pointed out, this isn't the right way to do this.
[snip]
- case 2: /* Multiple error */
- case 3: /* ECC area error */
printf("S3C24XX NAND: ECC uncorrectable error detected.\n");
Use puts() here.

Samsung's S3C24XX SoCs need this in order to generate a binary image with the SPL and U-Boot concatenated.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - None --- Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile index 058fb53..595b5f6 100644 --- a/Makefile +++ b/Makefile @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin + rm $(obj)spl/u-boot-spl-pad.bin + +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin - rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)tools/mkimage -s -n $(if $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \

Dear José Miguel Gonçalves,
Samsung's S3C24XX SoCs need this in order to generate a binary image with the SPL and U-Boot concatenated.
You aren't adding it, you're modifying it.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt
Changes for v2:
- None
Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile index 058fb53..595b5f6 100644 --- a/Makefile +++ b/Makefile @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin +
rm
$(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-
boot.ubl
rm $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
Check the apollon board, won't this colide with it's NAND IPL?
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)tools/mkimage -s -n $(if $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
Best regards, Marek Vasut

On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt
Changes for v2:
- None
Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile index 058fb53..595b5f6 100644 --- a/Makefile +++ b/Makefile @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
rm $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)tools/mkimage -s -n $(if $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
This diff is hard to read, but what exactly are you changing? The u-boot-ubl target is also used on TI platforms. It looks like you're making it such that u-boot-ubl.bin produces the old binary and u-boot-ubl adds a new target which is the mkimage header on top of the same bits as before, but without possibly padding the output image. I suspect in your case you could just set PAD_TO to 8192 in board/../config.mk and use the existing target.

On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt
Changes for v2: - None
Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile index 058fb53..595b5f6 100644 --- a/Makefile +++ b/Makefile @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
rm $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)tools/mkimage -s -n $(if $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
This diff is hard to read, but what exactly are you changing? The u-boot-ubl target is also used on TI platforms. It looks like you're making it such that u-boot-ubl.bin produces the old binary and u-boot-ubl adds a new target which is the mkimage header on top of the same bits as before, but without possibly padding the output image. I suspect in your case you could just set PAD_TO to 8192 in board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image padded at 8KB concatenated with the standard U-Boot. What I've done was to split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to program the Flash, and u-boot-ubl that remains with the same functionality as before, just now it depends on u-boot-ubl.bin.

Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt
Changes for v2: - None
Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile index 058fb53..595b5f6 100644 --- a/Makefile +++ b/Makefile @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@ -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
rm $(obj)u-boot-ubl.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)tools/mkimage -s -n $(ifrm $(obj)spl/u-boot-spl-pad.bin
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
This diff is hard to read, but what exactly are you changing? The u-boot-ubl target is also used on TI platforms. It looks like you're making it such that u-boot-ubl.bin produces the old binary and u-boot-ubl adds a new target which is the mkimage header on top of the same bits as before, but without possibly padding the output image. I suspect in your case you could just set PAD_TO to 8192 in board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image padded at 8KB concatenated with the standard U-Boot. What I've done was to split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to program the Flash, and u-boot-ubl that remains with the same functionality as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target (u-boot-ubl.bin) since this is TI specific, use something more generic. Regards, Christian

On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt
Changes for v2: - None
Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile index 058fb53..595b5f6 100644 --- a/Makefile +++ b/Makefile @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@ -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
rm $(obj)u-boot-ubl.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)tools/mkimage -s -n $(ifrm $(obj)spl/u-boot-spl-pad.bin
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
This diff is hard to read, but what exactly are you changing? The u-boot-ubl target is also used on TI platforms. It looks like you're making it such that u-boot-ubl.bin produces the old binary and u-boot-ubl adds a new target which is the mkimage header on top of the same bits as before, but without possibly padding the output image. I suspect in your case you could just set PAD_TO to 8192 in board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image padded at 8KB concatenated with the standard U-Boot. What I've done was to split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to program the Flash, and u-boot-ubl that remains with the same functionality as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target (u-boot-ubl.bin) since this is TI specific, use something more generic.
I only reused a temporary filename used for the u-boot-ubl target and make it a new target. If you think this is not an adequate name, can you suggest a new one?
Best regards, José Gonçalves

On Mon, Sep 17, 2012 at 10:30 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt
Changes for v2: - None
Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile index 058fb53..595b5f6 100644 --- a/Makefile +++ b/Makefile @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@ -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
rm $(obj)u-boot-ubl.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)tools/mkimage -s -n $(ifrm $(obj)spl/u-boot-spl-pad.bin
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
This diff is hard to read, but what exactly are you changing? The u-boot-ubl target is also used on TI platforms. It looks like you're making it such that u-boot-ubl.bin produces the old binary and u-boot-ubl adds a new target which is the mkimage header on top of the same bits as before, but without possibly padding the output image. I suspect in your case you could just set PAD_TO to 8192 in board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image padded at 8KB concatenated with the standard U-Boot. What I've done was to split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to program the Flash, and u-boot-ubl that remains with the same functionality as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target (u-boot-ubl.bin) since this is TI specific, use something more generic.
I only reused a temporary filename used for the u-boot-ubl target and make it a new target. If you think this is not an adequate name, can you suggest a new one?
u-boot.pad? u-boot-pad.bin?

On 09/17/2012 10:10 AM, Christian Riesch wrote:
On Mon, Sep 17, 2012 at 10:30 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt
Changes for v2: - None
Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile index 058fb53..595b5f6 100644 --- a/Makefile +++ b/Makefile @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@ -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
rm $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)tools/mkimage -s -n $(if
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
This diff is hard to read, but what exactly are you changing? The u-boot-ubl target is also used on TI platforms. It looks like you're making it such that u-boot-ubl.bin produces the old binary and u-boot-ubl adds a new target which is the mkimage header on top of the same bits as before, but without possibly padding the output image. I suspect in your case you could just set PAD_TO to 8192 in board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image padded at 8KB concatenated with the standard U-Boot. What I've done was to split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to program the Flash, and u-boot-ubl that remains with the same functionality as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target (u-boot-ubl.bin) since this is TI specific, use something more generic.
I only reused a temporary filename used for the u-boot-ubl target and make it a new target. If you think this is not an adequate name, can you suggest a new one?
u-boot.pad? u-boot-pad.bin?
If no one else has anything against, I will change the name of the new target to u-boot-pad.bin
Best regards, José Gonçalves

On Mon, Sep 17, 2012 at 10:24:34AM +0100, Jos?? Miguel Gon??alves wrote:
On 09/17/2012 10:10 AM, Christian Riesch wrote:
On Mon, Sep 17, 2012 at 10:30 AM, Jos?? Miguel Gon??alves jose.goncalves@inov.pt wrote:
On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, Jos?? Miguel Gon??alves jose.goncalves@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
>Samsung's S3C24XX SoCs need this in order to generate a binary image >with the SPL and U-Boot concatenated. > >Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt >--- >Changes for v2: > - None >--- > Makefile | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > >diff --git a/Makefile b/Makefile >index 058fb53..595b5f6 100644 >--- a/Makefile >+++ b/Makefile >@@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin > $(obj)u-boot.dis: $(obj)u-boot > $(OBJDUMP) -d $< > $@ > -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin >+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin > $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary >$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin > cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > >$(obj)u-boot-ubl.bin >+ rm $(obj)spl/u-boot-spl-pad.bin >+ >+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin > $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ > -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin >$(obj)u-boot.ubl >- rm $(obj)u-boot-ubl.bin >- rm $(obj)spl/u-boot-spl-pad.bin > $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin > $(obj)tools/mkimage -s -n $(if >$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \ This diff is hard to read, but what exactly are you changing? The u-boot-ubl target is also used on TI platforms. It looks like you're making it such that u-boot-ubl.bin produces the old binary and u-boot-ubl adds a new target which is the mkimage header on top of the same bits as before, but without possibly padding the output image. I suspect in your case you could just set PAD_TO to 8192 in board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image padded at 8KB concatenated with the standard U-Boot. What I've done was to split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to program the Flash, and u-boot-ubl that remains with the same functionality as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target (u-boot-ubl.bin) since this is TI specific, use something more generic.
I only reused a temporary filename used for the u-boot-ubl target and make it a new target. If you think this is not an adequate name, can you suggest a new one?
u-boot.pad? u-boot-pad.bin?
If no one else has anything against, I will change the name of the new target to u-boot-pad.bin
I think I'm OK with that.

Dear Tom Rini,
[...]
If no one else has anything against, I will change the name of the new target to u-boot-pad.bin
I think I'm OK with that.
What about having CPU-overridable targets ? So omap can have it's own .ubl result and commands leading to it ... and so can s3c24xx. Such targets would have to be shifted into CPU-specific dirs, is that possible?
Best regards, Marek Vasut

On 09/17/12 09:29, Marek Vasut wrote:
Dear Tom Rini,
[...]
If no one else has anything against, I will change the name of the new target to u-boot-pad.bin
I think I'm OK with that.
What about having CPU-overridable targets ? So omap can have it's own .ubl result and commands leading to it ... and so can s3c24xx. Such targets would have to be shifted into CPU-specific dirs, is that possible?
The problem I see first is that "UBL" doesn't seem to mean anything in the context of s3c24xx, it just happens to be doing some of what the system wants.

On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
On 09/17/2012 10:10 AM, Christian Riesch wrote:
On Mon, Sep 17, 2012 at 10:30 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves jose.goncalves@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
> Samsung's S3C24XX SoCs need this in order to generate a binary > image > with the SPL and U-Boot concatenated. > > Signed-off-by: Jos?? Miguel Gon??alves jose.goncalves@inov.pt > --- > Changes for v2: > - None > --- > Makefile | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index 058fb53..595b5f6 100644 > --- a/Makefile > +++ b/Makefile > @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin > $(obj)u-boot.dis: $(obj)u-boot > $(OBJDUMP) -d $< > $@ > -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin > $(obj)u-boot.bin > +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin > $(obj)u-boot.bin > $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O > binary > $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin > cat $(obj)spl/u-boot-spl-pad.bin > $(obj)u-boot.bin > > $(obj)u-boot-ubl.bin > + rm $(obj)spl/u-boot-spl-pad.bin > + > +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin > $(obj)tools/mkimage -n $(UBL_CONFIG) -T > ublimage \ > -e $(CONFIG_SYS_TEXT_BASE) -d > $(obj)u-boot-ubl.bin > $(obj)u-boot.ubl > - rm $(obj)u-boot-ubl.bin > - rm $(obj)spl/u-boot-spl-pad.bin > $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin > $(obj)u-boot.bin > $(obj)tools/mkimage -s -n $(if > $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") > \ This diff is hard to read, but what exactly are you changing? The u-boot-ubl target is also used on TI platforms. It looks like you're making it such that u-boot-ubl.bin produces the old binary and u-boot-ubl adds a new target which is the mkimage header on top of the same bits as before, but without possibly padding the output image. I suspect in your case you could just set PAD_TO to 8192 in board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image padded at 8KB concatenated with the standard U-Boot. What I've done was to split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to program the Flash, and u-boot-ubl that remains with the same functionality as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target (u-boot-ubl.bin) since this is TI specific, use something more generic.
I only reused a temporary filename used for the u-boot-ubl target and make it a new target. If you think this is not an adequate name, can you suggest a new one?
u-boot.pad? u-boot-pad.bin?
If no one else has anything against, I will change the name of the new target to u-boot-pad.bin
What exactly is u-boot-pad.bin supposed to be? I hope that's not being proposed as the final output file the user sees.
With old nand_spl we had u-boot-nand.bin for the final concatenated binary, but that's not appropriate for a generic spl. I think it would be better for the user to see "u-boot.bin" as the actual image to put on the boot device, regardless of implementation details like spl, if there's no requirement of a specific file format. The second stage could become "u-boot-main.bin" or similar on builds where spl is used.
-Scott

On 09/17/12 09:27, Scott Wood wrote:
On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
[snip]
If no one else has anything against, I will change the name of the new target to u-boot-pad.bin
What exactly is u-boot-pad.bin supposed to be? I hope that's not being proposed as the final output file the user sees.
With old nand_spl we had u-boot-nand.bin for the final concatenated binary, but that's not appropriate for a generic spl. I think it would be better for the user to see "u-boot.bin" as the actual image to put on the boot device, regardless of implementation details like spl, if there's no requirement of a specific file format. The second stage could become "u-boot-main.bin" or similar on builds where spl is used.
We need some name that means "U-Boot SPL with U-Boot tacked on at the end". This can optionally be padded to a defined size to make writing to hardware easier. We also have the problem that "u-boot.bin" already means something so it needs to be clear. I further fear that even if we made an "out" directory if we put u-boot.bin in there and it's not the same as the objcopy -O binary u-boot u-boot.bin as before we've violated the rule of least surprise and the end user problems from people that read "the" document (that happened to be out of date) will be our problem.
In short, at least a few people have said something along the lines of "We need generic output nameo $mediums and targets" but there's two hard problems, one of which is that every SoC _needs_ things tweaked just so (no header? no boot!), sometimes wants things tweaked further (pad the final image out to be easier to write to $medium) and sometimes needs multiple files (the whole of 'SPL' will be read so it must fit into $SMALL_MEMORY). The other is naming.
I don't want to block this series on this problem. I do want to say it needs to use my updated SPL framework or show that it's inadequate (and I owe another reply to part of this thread still) for this platform. Call it u-boot.s3c or .s3c24xx and lets continue talking about how to solve the general problem.

On 09/17/2012 11:51:52 AM, Tom Rini wrote:
On 09/17/12 09:27, Scott Wood wrote:
On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
[snip]
If no one else has anything against, I will change the name of the
new
target to u-boot-pad.bin
What exactly is u-boot-pad.bin supposed to be? I hope that's not
being
proposed as the final output file the user sees.
With old nand_spl we had u-boot-nand.bin for the final concatenated binary, but that's not appropriate for a generic spl. I think it
would
be better for the user to see "u-boot.bin" as the actual image to
put on
the boot device, regardless of implementation details like spl, if there's no requirement of a specific file format. The second stage could become "u-boot-main.bin" or similar on builds where spl is
used.
We need some name that means "U-Boot SPL with U-Boot tacked on at the end". This can optionally be padded to a defined size to make writing to hardware easier. We also have the problem that "u-boot.bin" already means something so it needs to be clear.
u-boot.bin has traditionally (except for nand_spl and derivatives) meant the final image ready to put into flash, after any platform-specific layout issues are taken care of (e.g. on mpc83xx it will have a reset control word embedded, on mpc85xx it will be padded to 512K with a reset vector at the end, etc.). That we did the tweaking in the linker script rather than after linking seems like an inconsequential implementation detail.
I further fear that even if we made an "out" directory if we put u-boot.bin in there and it's not the same as the objcopy -O binary u-boot u-boot.bin as before we've violated the rule of least surprise and the end user problems from people that read "the" document (that happened to be out of date) will be our problem.
In this case I think you can't meet one user's expectations without violating another's. I think it's more important to make it clear to the user what file they're supposed to put into flash. Users of platforms that are currently supported by nand_spl would probably like to continue seeing u-boot-nand.bin -- it's a tradeoff of historical stability versus current consistency.
In short, at least a few people have said something along the lines of "We need generic output nameo $mediums and targets" but there's two hard problems, one of which is that every SoC _needs_ things tweaked just so (no header? no boot!), sometimes wants things tweaked further (pad the final image out to be easier to write to $medium) and sometimes needs multiple files (the whole of 'SPL' will be read so it must fit into $SMALL_MEMORY). The other is naming.
A simple concatenation of a padded SPL plus the main U-Boot was good enough for all the nand_spl boards AFAIK, so it's not quite every SoC that needs something special here. For those that do require a special format (or multiple files) with a file extension that is familiar to people working with that platform, using that extension makes sense. "pad" does not, and a proliferation of SoC-specific suffixes isn't much better.
-Scott

On 09/17/12 10:32, Scott Wood wrote:
On 09/17/2012 11:51:52 AM, Tom Rini wrote:
On 09/17/12 09:27, Scott Wood wrote:
On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
[snip]
If no one else has anything against, I will change the name of the new target to u-boot-pad.bin
What exactly is u-boot-pad.bin supposed to be? I hope that's not being proposed as the final output file the user sees.
With old nand_spl we had u-boot-nand.bin for the final concatenated binary, but that's not appropriate for a generic spl. I think it would be better for the user to see "u-boot.bin" as the actual image to
put on
the boot device, regardless of implementation details like spl, if there's no requirement of a specific file format. The second stage could become "u-boot-main.bin" or similar on builds where spl is used.
We need some name that means "U-Boot SPL with U-Boot tacked on at the end". This can optionally be padded to a defined size to make writing to hardware easier. We also have the problem that "u-boot.bin" already means something so it needs to be clear.
u-boot.bin has traditionally (except for nand_spl and derivatives) meant the final image ready to put into flash, after any platform-specific layout issues are taken care of (e.g. on mpc83xx it will have a reset control word embedded, on mpc85xx it will be padded to 512K with a reset vector at the end, etc.). That we did the tweaking in the linker script rather than after linking seems like an inconsequential implementation detail.
Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and this is the biggie to me, just U-Boot.
I further fear that even if we made an "out" directory if we put u-boot.bin in there and it's not the same as the objcopy -O binary u-boot u-boot.bin as before we've violated the rule of least surprise and the end user problems from people that read "the" document (that happened to be out of date) will be our problem.
In this case I think you can't meet one user's expectations without violating another's. I think it's more important to make it clear to the user what file they're supposed to put into flash. Users of platforms that are currently supported by nand_spl would probably like to continue seeing u-boot-nand.bin -- it's a tradeoff of historical stability versus current consistency.
Right. So I'm saying we need to set new expectations for everyone and some human helper symlinks to help. A new top-level out or images or something, with symlinks inside.
In short, at least a few people have said something along the lines of "We need generic output nameo $mediums and targets" but there's two hard problems, one of which is that every SoC _needs_ things tweaked just so (no header? no boot!), sometimes wants things tweaked further (pad the final image out to be easier to write to $medium) and sometimes needs multiple files (the whole of 'SPL' will be read so it must fit into $SMALL_MEMORY). The other is naming.
A simple concatenation of a padded SPL plus the main U-Boot was good enough for all the nand_spl boards AFAIK, so it's not quite every SoC that needs something special here. For those that do require a special format (or multiple files) with a file extension that is familiar to people working with that platform, using that extension makes sense. "pad" does not, and a proliferation of SoC-specific suffixes isn't much better.
I think we're running into PowerPC vs ARM "fun". We've got 7 or so different "whack the image for this SoC for this medium" type things already.

On 09/17/2012 12:53:41 PM, Tom Rini wrote:
On 09/17/12 10:32, Scott Wood wrote:
On 09/17/2012 11:51:52 AM, Tom Rini wrote:
On 09/17/12 09:27, Scott Wood wrote:
On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
[snip]
If no one else has anything against, I will change the name of
the new
target to u-boot-pad.bin
What exactly is u-boot-pad.bin supposed to be? I hope that's
not being
proposed as the final output file the user sees.
With old nand_spl we had u-boot-nand.bin for the final
concatenated
binary, but that's not appropriate for a generic spl. I think
it would
be better for the user to see "u-boot.bin" as the actual image to
put on
the boot device, regardless of implementation details like spl,
if
there's no requirement of a specific file format. The second
stage
could become "u-boot-main.bin" or similar on builds where spl is
used.
We need some name that means "U-Boot SPL with U-Boot tacked on at
the
end". This can optionally be padded to a defined size to make
writing
to hardware easier. We also have the problem that "u-boot.bin"
already
means something so it needs to be clear.
u-boot.bin has traditionally (except for nand_spl and derivatives)
meant
the final image ready to put into flash, after any platform-specific layout issues are taken care of (e.g. on mpc83xx it will have a
reset
control word embedded, on mpc85xx it will be padded to 512K with a
reset
vector at the end, etc.). That we did the tweaking in the linker
script
rather than after linking seems like an inconsequential
implementation
detail.
Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and this is the biggie to me, just U-Boot.
I further fear that even if we made an "out" directory if we put u-boot.bin in there and it's not
the
same as the objcopy -O binary u-boot u-boot.bin as before we've
violated
the rule of least surprise and the end user problems from people
that
read "the" document (that happened to be out of date) will be our problem.
In this case I think you can't meet one user's expectations without violating another's. I think it's more important to make it clear
to
the user what file they're supposed to put into flash. Users of platforms that are currently supported by nand_spl would probably
like
to continue seeing u-boot-nand.bin -- it's a tradeoff of historical stability versus current consistency.
Right. So I'm saying we need to set new expectations for everyone and some human helper symlinks to help. A new top-level out or images or something, with symlinks inside.
How about something like "u-boot-final.bin"[1], "u-boot-all.bin", "u-boot-image.bin", etc. as the end-user output, with ".bin" changed to something else if it's a well known file type? At least for the boards that only require one output file.
-Scott
[1] Though then LDFLAGS_FINAL becomes confusing...

Dear Tom Rini,
In message 505763A5.1030101@ti.com you wrote:
Right. So I'm saying we need to set new expectations for everyone and some human helper symlinks to help. A new top-level out or images or something, with symlinks inside.
Why would we need that?
For the end user, any name is good enough, as long as it's clearly documented which file to use, and what exactly to do with it. There are so many different boot formatrequirements, that we canot expect to come up with "good" names for all of these in any way that matches all people's expectations because everything is completely self-explanatory.
Make it simple, and handle it in the documentation.
I think we're running into PowerPC vs ARM "fun". We've got 7 or so different "whack the image for this SoC for this medium" type things already.
I don't think it's an PPC versus ARM issue It's more an "good old times" versus "brave new world" thing. Actually Shakespeare's verses apply fully to many of teh recent SoC designs - be these PPC or ARM or whatever based:
O wonder! How many goodly creatures are there here! How beauteous mankind is! O brave new world, That has such people in't. —William Shakespeare, The Tempest, Act V, Scene I, ll. 203—6
Thinking about features, boot image formats, boot device selection and other boot requirements of the ROM boot loaders of any recent SoC indeed makes me wonder "How many goodly creatures are there here!"
PS: The "good" in this reference is to be understood in the same sense as the "best" in the name of the MPC5200 BestComm DMA controller.
Best regards,
Wolfgang Denk

The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.
Signed-off-by: José Miguel Gonçalves jose.goncalves@inov.pt --- Changes for v2: - Coding style cleanup - Use of Use of clrbits_le32(), setbits_le32() and clrsetbits_le32() - Use of register bit macros instead of magic numbers - Use of serial and rtc drivers implemented for s3c24x0 --- MAINTAINERS | 4 + board/boardcon/mini2416/Makefile | 47 ++++++++ board/boardcon/mini2416/config.mk | 4 + board/boardcon/mini2416/mini2416.c | 98 ++++++++++++++++ board/boardcon/mini2416/mini2416_spl.c | 200 ++++++++++++++++++++++++++++++++ board/boardcon/mini2416/u-boot-spl.lds | 63 ++++++++++ boards.cfg | 1 + include/configs/mini2416.h | 200 ++++++++++++++++++++++++++++++++ 8 files changed, 617 insertions(+) create mode 100644 board/boardcon/mini2416/Makefile create mode 100644 board/boardcon/mini2416/config.mk create mode 100644 board/boardcon/mini2416/mini2416.c create mode 100644 board/boardcon/mini2416/mini2416_spl.c create mode 100644 board/boardcon/mini2416/u-boot-spl.lds create mode 100644 include/configs/mini2416.h
diff --git a/MAINTAINERS b/MAINTAINERS index 4aabcff..593baa0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -655,6 +655,10 @@ Fabio Estevam fabio.estevam@freescale.com mx53ard i.MX53 mx53smd i.MX53
+José Gonçalves jose.goncalves@inov.pt + + mini2416 ARM926EJS (S3C2416 SoC) + Daniel Gorsulowski daniel.gorsulowski@esd.eu
meesc ARM926EJS (AT91SAM9263 SoC) diff --git a/board/boardcon/mini2416/Makefile b/board/boardcon/mini2416/Makefile new file mode 100644 index 0000000..bf92ba1 --- /dev/null +++ b/board/boardcon/mini2416/Makefile @@ -0,0 +1,47 @@ +# +# (C) Copyright 2012 INOV - INESC Inovacao +# Jose Goncalves jose.goncalves@inov.pt +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +ifdef CONFIG_SPL_BUILD +COBJS += mini2416_spl.o +else +COBJS += mini2416.o +endif + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB): $(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +######################################################################### + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +######################################################################### diff --git a/board/boardcon/mini2416/config.mk b/board/boardcon/mini2416/config.mk new file mode 100644 index 0000000..f1230d0 --- /dev/null +++ b/board/boardcon/mini2416/config.mk @@ -0,0 +1,4 @@ +PAD_TO := 0x2000 +ifndef CONFIG_SPL_BUILD +ALL-y += $(obj)u-boot-ubl.bin +endif diff --git a/board/boardcon/mini2416/mini2416.c b/board/boardcon/mini2416/mini2416.c new file mode 100644 index 0000000..e31d2c3 --- /dev/null +++ b/board/boardcon/mini2416/mini2416.c @@ -0,0 +1,98 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <netdev.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> + +DECLARE_GLOBAL_DATA_PTR; + +static void ether_if_init(void) +{ + /* Ethernet chip is on memory bank 1 */ + struct s3c24xx_smc *const smc = s3c24xx_get_base_smc(S3C24XX_SMC1); + struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio(); + + /* Set bus timings */ + writel(0, &smc->smbidcy); /* Idle Cycle */ + writel(14, &smc->smbwstwr); /* Write Wait State */ + writel(2, &smc->smbwstoen); /* Output Enable Assertion Delay */ + writel(2, &smc->smbwstwen); /* Write Enable Assertion Delay */ + writel(14, &smc->smbwstrd); /* Read Wait State */ + + /* Init SMC control register */ + clrsetbits_le32(&smc->smbc, + (SMBC_RSMAVD_WR | SMBC_RSMAVD_RD | SMBC_MW_MASK | + SMBC_WAIT_POL), + (SMBC_DRNOWE | SMBC_DRNCS | SMBC_MW_16BIT | + SMBC_WAIT_EN | SMBC_RBLE)); + + /* Enable CS pin */ + setbits_le32(&gpio->gpacon, (1 << 12)); +} + +int board_init(void) +{ + struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio(); + + /* Turn LED on */ + clrbits_le32(&gpio->gpcdat, (1 << 5)); + + /* Init interface with Ethernet chip */ + ether_if_init(); + + /* Arch number of MINI2416 Board */ + gd->bd->bi_arch_number = MACH_TYPE_MINI2416; + + /* Address of boot parameters */ + gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; + + return 0; +} + +int dram_init(void) +{ + gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE, + CONFIG_SYS_SDRAM_SIZE); + return 0; +} + +#ifdef CONFIG_DISPLAY_BOARDINFO +int checkboard(void) +{ + printf("\nBoard: MINI2416\n"); + return 0; +} +#endif + +#ifdef CONFIG_CMD_NET +int board_eth_init(bd_t *bis) +{ + int rc = 0; +#ifdef CONFIG_SMC911X + rc = smc911x_initialize(0, CONFIG_SMC911X_BASE); +#endif + return rc; +} +#endif diff --git a/board/boardcon/mini2416/mini2416_spl.c b/board/boardcon/mini2416/mini2416_spl.c new file mode 100644 index 0000000..ba9bbec --- /dev/null +++ b/board/boardcon/mini2416/mini2416_spl.c @@ -0,0 +1,200 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <version.h> +#include <nand.h> +#include <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> + +/* FCLK = 800 MHz, HCLK = 133 MHz, PCLK = 66 MHz */ +#define M_MDIV 400 +#define M_PDIV 3 +#define M_SDIV 1 +#define ARMDIV 1 +#define PREDIV 2 +#define HCLKDIV 1 + +/* EPLLclk = 96MHz */ +#define E_MDIV 32 +#define E_PDIV 1 +#define E_SDIV 2 + +DECLARE_GLOBAL_DATA_PTR; +static gd_t gdata; + +inline void hang(void) +{ + serial_puts("### ERROR ### Please RESET the board ###\n"); + for (;;) + /* NOP */; +} + +static inline void asm_delay(ulong loops) +{ + asm volatile ("1:\n" "subs %0, %1, #1\n" + "bne 1b" : "=r" (loops) : "0"(loops)); +} + +static inline void watchdog_disable(void) +{ + struct s3c24xx_watchdog *const watchdog = s3c24xx_get_base_watchdog(); + + writel(0, &watchdog->wtcon); +} + +static void pinmux_init(void) +{ + struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio(); + + /* Init LED pin and turn LED off */ + clrsetbits_le32(&gpio->gpccon, (0x3 << 10), (0x1 << 10)); + setbits_le32(&gpio->gpcdat, (1 << 5)); + + /* Init UART pins */ + writel(0x0000AAAA, &gpio->gphcon); + + /* Init NAND interface */ + setbits_le32(&gpio->gpacon, (0x3F << 17)); +} + +static void pll_init(void) +{ + struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl(); + + /* Configure clocks division ratio */ + clrsetbits_le32(&sysctl->clkdiv0, + CLKDIV0_ARMDIV_MASK | CLKDIV0_PREDIV_MASK | + CLKDIV0_HCLKDIV_MASK, + CLKDIV0_ARMDIV(ARMDIV) | CLKDIV0_PREDIV(PREDIV) | + CLKDIV0_HALFHCLK | CLKDIV0_PCLKDIV | + CLKDIV0_HCLKDIV(HCLKDIV)); + + /* Set MPLL lock time */ + writel(0x0E10, &sysctl->lockcon0); + + /* Configure MPLL */ + writel(MPLLCON_MDIV(M_MDIV) | MPLLCON_PDIV(M_PDIV) | + MPLLCON_SDIV(M_SDIV), &sysctl->mpllcon); + + /* Set EPLL lock time */ + writel(0x1780, &sysctl->lockcon1); + + /* Configure EPLL */ + writel(EPLLCON_MDIV(E_MDIV) | EPLLCON_PDIV(E_PDIV) | + EPLLCON_SDIV(E_SDIV), &sysctl->epllcon); + + /* MSYSCLK = MPLL and ESYSCLK = EPLL */ + setbits_le32(&sysctl->clksrc, + CLKSRC_MSYSCLK_MPLL | CLKSRC_ESYSCLK_EPLL); +} + +static void dramctl_init(void) +{ + struct s3c24xx_dramctl *const dramctl = s3c24xx_get_base_dramctl(); + + /* Step 1: Init BANKCFG & BANKCON1 */ + writel(BANKCFG_VAL_DDR2, &dramctl->bankcfg); + writel(BANKCON1_VAL_DDR2, &dramctl->bankcon1); + + /* Step 2: Init BANKCON2 */ + writel(BANKCON2_VAL_DDR2, &dramctl->bankcon2); + + /* Step 3: Issue a PALL command */ + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_PALL, &dramctl->bankcon1); + + /* Step 4: Issue a EMRS2 command */ + writel(BANKCON3_VAL_EMRS2, &dramctl->bankcon3); + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1); + + /* Step 5: Issue a EMRS3 command */ + writel(BANKCON3_VAL_EMRS3, &dramctl->bankcon3); + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1); + + /* Step 6: Issue a EMRS1 command */ + writel(BANKCON3_VAL_EMRS1, &dramctl->bankcon3); + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1); + + /* Step 7: Issue a MRS command */ + writel(BANKCON3_VAL_MRS | BANKCON3_MRS_DLL_RESET, &dramctl->bankcon3); + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_MRS, &dramctl->bankcon1); + + /* Step 8: Issue a PALL command */ + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_PALL, &dramctl->bankcon1); + + /* Step 9: Write 0xFF into the refresh timer */ + writel(0xFF, &dramctl->refresh); + + /* Step 10: Wait more than 120 clocks */ + asm_delay(256); + + /* Step 11: Issue a MRS command */ + writel(BANKCON3_VAL_MRS, &dramctl->bankcon3); + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_MRS, &dramctl->bankcon1); + + /* Step 12: Issue a EMRS1 command */ + writel(BANKCON3_VAL_EMRS1 | BANKCON3_EMRS1_OCD7 | BANKCON3_EMRS1_CAS3, + &dramctl->bankcon3); + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1); + + writel(BANKCON3_VAL_EMRS1 | BANKCON3_EMRS1_CAS3, &dramctl->bankcon3); + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1); + + /* Step 13: Write 0x87 into the refresh timer */ + writel(0x87, &dramctl->refresh); + + /* Step 14: Normal Mode */ + writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_NORMAL, &dramctl->bankcon1); +} + +void board_init_f(ulong bootflag) +{ + watchdog_disable(); + pinmux_init(); + pll_init(); + + /* + * We call relocate_code() with relocation target set to the SPL entry + * point. This will result in relocation getting skipped and only .bss + * initialization is performed before jumping to board_init_r(). + */ + relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE); +} + +void board_init_r(gd_t *id, ulong dest_addr) +{ + gd = id; + gd->baudrate = CONFIG_BAUDRATE; + serial_init(); + + /* Print U-Boot SPL version string */ + serial_puts("\n\nU-Boot SPL " PLAIN_VERSION); + serial_puts(" (" U_BOOT_DATE " - " U_BOOT_TIME ")\n"); + + dramctl_init(); + nand_init(); + + serial_puts("Loading U-Boot from NAND Flash...\n"); + + nand_boot(); +} diff --git a/board/boardcon/mini2416/u-boot-spl.lds b/board/boardcon/mini2416/u-boot-spl.lds new file mode 100644 index 0000000..d339b0d --- /dev/null +++ b/board/boardcon/mini2416/u-boot-spl.lds @@ -0,0 +1,63 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +MEMORY { .iram : ORIGIN = CONFIG_SPL_TEXT_BASE, \ + LENGTH = CONFIG_SPL_MAX_SIZE } +MEMORY { .sram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \ + LENGTH = CONFIG_SPL_BSS_MAX_SIZE } + +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +SECTIONS +{ + .text : + { + CPUDIR/start.o (.text) + *(.text*) + } > .iram + + . = ALIGN(4); + .rodata : + { + *(SORT_BY_ALIGNMENT(.rodata*)) + } > .iram + + . = ALIGN(4); + .data : + { + *(SORT_BY_ALIGNMENT(.data*)) + } > .iram + + . = ALIGN(4); + _end = .; + + .bss : + { + . = ALIGN(4); + __bss_start = .; + *(.bss*) + . = ALIGN(4); + __bss_end__ = .; + } >.sram +} diff --git a/boards.cfg b/boards.cfg index 72e7803..bf084a0 100644 --- a/boards.cfg +++ b/boards.cfg @@ -193,6 +193,7 @@ omap730p2_cs0boot arm arm926ejs omap730p2 ti omap omap730p2_cs3boot arm arm926ejs omap730p2 ti omap omap730p2:CS3_BOOT edminiv2 arm arm926ejs - LaCie orion5x dkb arm arm926ejs - Marvell pantheon +mini2416 arm arm926ejs mini2416 boardcon s3c24xx spear300 arm arm926ejs spear300 spear spear spear3xx_evb:spear300 spear300_nand arm arm926ejs spear300 spear spear spear3xx_evb:spear300,nand spear300_usbtty arm arm926ejs spear300 spear spear spear3xx_evb:spear300,usbtty diff --git a/include/configs/mini2416.h b/include/configs/mini2416.h new file mode 100644 index 0000000..406a7e6 --- /dev/null +++ b/include/configs/mini2416.h @@ -0,0 +1,200 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves jose.goncalves@inov.pt + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __CONFIG_H +#define __CONFIG_H + +/* + * SoC Configuration + */ +#define CONFIG_ARM926EJS /* ARM926EJS CPU Core */ +#define CONFIG_S3C24XX /* SAMSUNG S3C24XX Family */ +#define CONFIG_S3C2416 /* SAMSUNG S3C2416 SoC */ +#define CONFIG_SYS_CLK_FREQ 12000000 +#define CONFIG_SYS_HZ 1000 + +/* + * Memory Information + */ +#define CONFIG_SYS_IRAM_BASE 0x00000000 /* Steppingstone base address */ +#define CONFIG_SYS_IRAM_SIZE (8 << 10) /* 8KB of Steppingstone */ +#define CONFIG_SYS_IRAM_END (CONFIG_SYS_IRAM_BASE + CONFIG_SYS_IRAM_SIZE) + +#define CONFIG_SYS_SRAM_BASE 0x00002000 /* SRAM base address */ +#define CONFIG_SYS_SRAM_SIZE (56 << 10) /* 56KB of SRAM */ +#define CONFIG_SYS_SRAM_END (CONFIG_SYS_SRAM_BASE + CONFIG_SYS_SRAM_SIZE) + +#define CONFIG_SYS_SDRAM_BASE 0x30000000 /* DDR2 SDRAM base address */ +#define CONFIG_SYS_SDRAM_SIZE (64 << 20) /* 64MB of DDR2 SDRAM */ +#define CONFIG_SYS_SDRAM_END (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_SDRAM_SIZE) + +/* + * Linux Interface + */ +#define MACH_TYPE_MINI2416 3850 +#define CONFIG_MACH_TYPE MACH_TYPE_MINI2416 +#define CONFIG_CMDLINE_TAG +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_BOOTDELAY 3 +#define CONFIG_BOOTARGS "console=ttySAC3,115200n8" +#define CONFIG_BOOTCOMMAND "" /* TBD */ + +/* + * SPL + */ +#define CONFIG_SPL +#define CONFIG_SPL_SERIAL_SUPPORT +#define CONFIG_SPL_NAND_SUPPORT +#define CONFIG_SPL_NAND_SIMPLE +#define CONFIG_SPL_NAND_LOAD +#define CONFIG_SPL_TEXT_BASE 0x00000000 /* CONFIG_SYS_IRAM_BASE */ +#define CONFIG_SPL_MAX_SIZE CONFIG_SYS_IRAM_SIZE +#define CONFIG_SPL_BSS_START_ADDR CONFIG_SYS_SRAM_BASE +#define CONFIG_SPL_BSS_MAX_SIZE (CONFIG_SYS_SRAM_SIZE - (8 << 10)) +#define CONFIG_SPL_STACK CONFIG_SYS_SRAM_END /* 8KB for stack */ + +/* + * Monitor Interface + */ +#define CONFIG_SYS_PROMPT "MINI2416 # " +#define CONFIG_SYS_LONGHELP +#define CONFIG_SYS_CBSIZE 1024 +#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 +#define CONFIG_CMDLINE_EDITING + +/* + * Command Definition + */ +#define CONFIG_SYS_NO_FLASH /* No NOR Flash */ +#include <config_cmd_default.h> +#define CONFIG_CMD_CACHE +#define CONFIG_CMD_DATE +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_MISC +#define CONFIG_CMD_NAND +#define CONFIG_CMD_PING + +/* + * Miscellaneous Settings + */ +#define CONFIG_SKIP_LOWLEVEL_INIT +#define CONFIG_DISPLAY_CPUINFO +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_NR_DRAM_BANKS 1 +#define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + (1 << 20)) +#define CONFIG_SYS_MONITOR_BASE (CONFIG_SYS_SDRAM_END - (1 << 20)) +#define CONFIG_SYS_MONITOR_LEN (256 << 10) +#define CONFIG_SYS_TEXT_BASE 0x33F00000 /* CONFIG_SYS_MONITOR_BASE */ +#define CONFIG_SYS_MALLOC_LEN (384 << 10) +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SRAM_END - \ + GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_ALT_MEMTEST +#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE +#define CONFIG_SYS_MEMTEST_END CONFIG_SYS_MONITOR_BASE + +/* + * NAND Flash + */ +#ifdef CONFIG_CMD_NAND + +#define CONFIG_NAND_S3C24XX +#define CONFIG_S3C24XX_NAND_HWECC +#define CONFIG_SYS_NAND_BASE 0x4E000010 +#define CONFIG_SYS_MAX_NAND_DEVICE 1 + +/* SPL NAND Driver */ +#define CONFIG_SYS_NAND_PAGE_SIZE (2 << 10) +#define CONFIG_SYS_NAND_BLOCK_SIZE (128 << 10) +#define CONFIG_SYS_NAND_PAGE_COUNT (CONFIG_SYS_NAND_BLOCK_SIZE / \ + CONFIG_SYS_NAND_PAGE_SIZE) +#define CONFIG_SYS_NAND_OOBSIZE 64 +#define CONFIG_SYS_NAND_ECCSIZE 512 +#define CONFIG_SYS_NAND_ECCBYTES 4 +#define CONFIG_SYS_NAND_ECCPOS {40, 41, 42, 43, 44, 45, 46, 47, \ + 48, 49, 50, 51, 52, 53, 54, 55} +#define CONFIG_SYS_NAND_BAD_BLOCK_POS 0 +#define CONFIG_SYS_NAND_HW_ECC_OOBFIRST +#define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_U_BOOT_DST CONFIG_SYS_TEXT_BASE +#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_NAND_U_BOOT_DST +#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_MAX_SIZE +#define CONFIG_SYS_NAND_U_BOOT_SIZE (CONFIG_SYS_MONITOR_LEN - \ + CONFIG_SPL_MAX_SIZE) + +#endif + +/* + * Serial Driver + */ +#define CONFIG_S3C24X0_SERIAL +#define CONFIG_SERIAL3 +#define CONFIG_BAUDRATE 115200 +#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 } + +/* + * Ethernet + */ +#ifdef CONFIG_CMD_NET +#define CONFIG_SMC911X +#define CONFIG_SMC911X_BASE 0x08000000 +#define CONFIG_SMC911X_16_BIT +#define CONFIG_ETHADDR FE:11:22:33:44:55 +#define CONFIG_OVERWRITE_ETHADDR_ONCE +#define CONFIG_IPADDR 192.168.0.10 +#define CONFIG_NETMASK 255.255.255.0 +#define CONFIG_SERVERIP 192.168.0.1 +#define CONFIG_GATEWAYIP 192.168.0.1 +#endif + +/* + * RTC + */ +#ifdef CONFIG_CMD_DATE +#define CONFIG_RTC_S3C24X0 +#endif + +/* + * Environment + */ +#ifdef CONFIG_CMD_NAND +#define CONFIG_ENV_IS_IN_NAND +#define CONFIG_ENV_SIZE CONFIG_SYS_NAND_BLOCK_SIZE +#define CONFIG_ENV_OFFSET CONFIG_SYS_MONITOR_LEN +#define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) +#else +#define CONFIG_ENV_IS_NOWHERE +#endif + +/* + * File System + */ +#ifdef CONFIG_CMD_NAND +#define CONFIG_CMD_MTDPARTS +#define CONFIG_MTD_DEVICE +#define CONFIG_MTD_PARTITIONS +#endif + +#endif /* __CONFIG_H */

On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.
[snip]
Can you please try this on top of my SPL framework series? Thanks!

On 09/14/2012 07:58 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.
[snip]
Can you please try this on top of my SPL framework series? Thanks!
I thought I was using the latest SPL framework! Can you please detail on what I should do different?
Best regards, José Gonçalves

On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 07:58 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.
[snip]
Can you please try this on top of my SPL framework series? Thanks!
I thought I was using the latest SPL framework! Can you please detail on what I should do different?
Please see http://www.mail-archive.com/u-boot@lists.denx.de/msg92156.html

On 17-09-2012 15:39, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 07:58 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.
[snip]
Can you please try this on top of my SPL framework series? Thanks!
I thought I was using the latest SPL framework! Can you please detail on what I should do different?
Please see http://www.mail-archive.com/u-boot@lists.denx.de/msg92156.html
As this is still not merged, I reckon you only want to check if this new SPL framework works fine with my board.
I'm not expected to resubmit my patch to be according with the new framework, correct?
Best regards, José Gonçalves

On Mon, Sep 17, 2012 at 03:47:46PM +0100, Jos? Miguel Gon?alves wrote:
On 17-09-2012 15:39, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 07:58 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.
[snip]
Can you please try this on top of my SPL framework series? Thanks!
I thought I was using the latest SPL framework! Can you please detail on what I should do different?
Please see http://www.mail-archive.com/u-boot@lists.denx.de/msg92156.html
As this is still not merged, I reckon you only want to check if this new SPL framework works fine with my board.
I'm not expected to resubmit my patch to be according with the new framework, correct?
v1 of your patches was posted well after the merge window for v2012.10 closed. My SPL series will be merged to mainline shortly (taking care of everyone elses merge requests first). So yes, to get into v2013.01 you will need to update. If you check the archives you can see how the altera soc support changed to adapt to this framework. And if there's a shortcoming in the framework, I really do want to know. Thanks!

Hi Tom,
On 17-09-2012 16:11, Tom Rini wrote:
On Mon, Sep 17, 2012 at 03:47:46PM +0100, Jos? Miguel Gon?alves wrote:
On 17-09-2012 15:39, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 07:58 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.
[snip]
Can you please try this on top of my SPL framework series? Thanks!
I thought I was using the latest SPL framework! Can you please detail on what I should do different?
Please see http://www.mail-archive.com/u-boot@lists.denx.de/msg92156.html
As this is still not merged, I reckon you only want to check if this new SPL framework works fine with my board.
I'm not expected to resubmit my patch to be according with the new framework, correct?
v1 of your patches was posted well after the merge window for v2012.10 closed. My SPL series will be merged to mainline shortly (taking care of everyone elses merge requests first). So yes, to get into v2013.01 you will need to update. If you check the archives you can see how the altera soc support changed to adapt to this framework. And if there's a shortcoming in the framework, I really do want to know. Thanks!
I already have my board working on the top of this new SPL framework. It was easy to migrate and the interface is easier to use for a new U-Boot developer (like me). Good work! I'll resubmit my new patch later on.
Here are my board's SPL sizes for both older and new frameworks:
text data bss dec hex filename 4083 8 588 4679 1247 u-boot/spl/u-boot-spl
text data bss dec hex filename 3905 160 500 4565 11d5 u-boot-spl-framework/spl/u-boot-spl
So I get around 30 bytes of additional IRAM space (text + data).
I have a comment, though. As you use memset() to initialize the .bss, wouldn’t be better that CONFIG_SPL_LIBGENERIC_SUPPORT would be automaticaly included when adding CONFIG_SPL_FRAMEWORK to the board config?
Best regards, José Gonçalves
participants (7)
-
Albert ARIBAUD
-
Christian Riesch
-
José Miguel Gonçalves
-
Marek Vasut
-
Scott Wood
-
Tom Rini
-
Wolfgang Denk