[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Fabio Estevam]

Introduce arch_early_init_r() function, which can be useful for doing
early initialization after relocation has happened.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 arch/arm/include/asm/u-boot-arm.h |    1 +
 arch/arm/lib/board.c              |    4 ++++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/u-boot-arm.h b/arch/arm/include/asm/u-boot-arm.h
index 4ca75f9..9f3cae5 100644
--- a/arch/arm/include/asm/u-boot-arm.h
+++ b/arch/arm/include/asm/u-boot-arm.h
@@ -52,6 +52,7 @@ void	cpu_init_cp15(void);
 /* cpu/.../arch/cpu.c */
 int	arch_cpu_init(void);
 int	arch_misc_init(void);
+int	arch_early_init_r(void);
 
 /* board/.../... */
 int	board_init(void);
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 5270c11..025d6ca 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -500,6 +500,10 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	malloc_start = dest_addr - TOTAL_MALLOC_LEN;
 	mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
 
+#ifdef CONFIG_ARCH_EARLY_INIT_R
+	arch_early_init_r();
+#endif
+
 #if !defined(CONFIG_SYS_NO_FLASH)
 	puts("Flash: ");
 
-- 
1.7.1

[U-Boot] [PATCH 2/2] mmc: mxsmmc: Fix operation with DMA

[Fabio Estevam]

Initialize the DMA controller so that the following errors are fixed:

U-Boot 2012.04-rc1-00001-g037cbfd (Apr 02 2012 - 10:57:48)

Freescale i.MX28 family at 454 MHz
DRAM:  128 MiB
MMC:   MXS MMC: 0
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC init failed

Do the DMA initialization inside arch_early_init_r(), so that it can work after relocation.

In order to not break the DMA NAND support, remove mxs_dma_init from the
NAND driver now that it is called from arch_early_init_r().

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 arch/arm/cpu/arm926ejs/mx28/mx28.c |   12 ++++++++++++
 drivers/mtd/nand/mxs_nand.c        |    3 ---
 include/configs/m28evk.h           |    1 +
 include/configs/mx28evk.h          |    1 +
 4 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index cf6d4e9..6c148a8 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -34,6 +34,7 @@
 #include <asm/arch/iomux.h>
 #include <asm/arch/imx-regs.h>
 #include <asm/arch/sys_proto.h>
+#include <asm/arch/dma.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -297,3 +298,14 @@ U_BOOT_CMD(
 	"display clocks",
 	""
 );
+
+#ifdef CONFIG_ARCH_EARLY_INIT_R
+int arch_early_init_r(void)
+{
+#ifdef	CONFIG_APBH_DMA
+	/* Initialize the DMA controller. */
+	mxs_dma_init();
+#endif
+	return 0;
+}
+#endif
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 4b1297a..95eac35 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -1072,9 +1072,6 @@ int mxs_nand_init(struct mxs_nand_info *info)
 			goto err2;
 	}
 
-	/* Init the DMA controller. */
-	mxs_dma_init();
-
 	/* Reset the GPMI block. */
 	mx28_reset_block(&gpmi_regs->hw_gpmi_ctrl0_reg);
 
diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index 8b83180..b0e6d3b 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -42,6 +42,7 @@
 #define	CONFIG_BOARD_EARLY_INIT_F
 #define	CONFIG_ARCH_CPU_INIT
 #define	CONFIG_ARCH_MISC_INIT
+#define	CONFIG_ARCH_EARLY_INIT_R
 
 /*
  * SPL
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 705fdab..350e833 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -36,6 +36,7 @@
 #define CONFIG_BOARD_EARLY_INIT_F
 #define CONFIG_ARCH_CPU_INIT
 #define CONFIG_ARCH_MISC_INIT
+#define CONFIG_ARCH_EARLY_INIT_R
 
 /*
  * SPL
-- 
1.7.1

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Tom Rini]

On Mon, Apr 02, 2012 at 06:19:45PM -0300, Fabio Estevam wrote:

> Introduce arch_early_init_r() function, which can be useful for doing
> early initialization after relocation has happened.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

Perhaps I just overlooked earlier conversations, but why not just do
this in board_init() ?

-- 
Tom

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Marek Vasut]

Dear Tom Rini,

> On Mon, Apr 02, 2012 at 06:19:45PM -0300, Fabio Estevam wrote:
> > Introduce arch_early_init_r() function, which can be useful for doing
> > early initialization after relocation has happened.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> 
> Perhaps I just overlooked earlier conversations, but why not just do
> this in board_init() ?

Because we have multiple boards and they all need it.

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Tom Rini]

On Tue, Apr 03, 2012 at 12:00:31AM +0200, Marek Vasut wrote:
> Dear Tom Rini,
> 
> > On Mon, Apr 02, 2012 at 06:19:45PM -0300, Fabio Estevam wrote:
> > > Introduce arch_early_init_r() function, which can be useful for doing
> > > early initialization after relocation has happened.
> > > 
> > > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > 
> > Perhaps I just overlooked earlier conversations, but why not just do
> > this in board_init() ?
> 
> Because we have multiple boards and they all need it.

And you aren't architectured with a common board_init() over the family
(would there be little to no duplication)?  This is what we do in
various TI families.

-- 
Tom

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Marek Vasut]

Dear Tom Rini,

> On Tue, Apr 03, 2012 at 12:00:31AM +0200, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> > > On Mon, Apr 02, 2012 at 06:19:45PM -0300, Fabio Estevam wrote:
> > > > Introduce arch_early_init_r() function, which can be useful for doing
> > > > early initialization after relocation has happened.
> > > > 
> > > > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > > 
> > > Perhaps I just overlooked earlier conversations, but why not just do
> > > this in board_init() ?
> > 
> > Because we have multiple boards and they all need it.
> 
> And you aren't architectured with a common board_init() over the family
> (would there be little to no duplication)?  This is what we do in
> various TI families.

Common board_init() ? How would you then do the actual distinct per-board init?

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Tom Rini]

On Tue, Apr 03, 2012 at 12:08:33AM +0200, Marek Vasut wrote:
> Dear Tom Rini,
> 
> > On Tue, Apr 03, 2012 at 12:00:31AM +0200, Marek Vasut wrote:
> > > Dear Tom Rini,
> > > 
> > > > On Mon, Apr 02, 2012 at 06:19:45PM -0300, Fabio Estevam wrote:
> > > > > Introduce arch_early_init_r() function, which can be useful for doing
> > > > > early initialization after relocation has happened.
> > > > > 
> > > > > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > > > 
> > > > Perhaps I just overlooked earlier conversations, but why not just do
> > > > this in board_init() ?
> > > 
> > > Because we have multiple boards and they all need it.
> > 
> > And you aren't architectured with a common board_init() over the family
> > (would there be little to no duplication)?  This is what we do in
> > various TI families.
> 
> Common board_init() ? How would you then do the actual distinct per-board init?

Pah, mis-recalled things, sorry.  We have a pre-relocation hook that's
common per-family (lowlevel_init (generic) -> s_init (TI generic)).

-- 
Tom

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Tom Rini]

On Mon, Apr 02, 2012 at 06:19:45PM -0300, Fabio Estevam wrote:

> Introduce arch_early_init_r() function, which can be useful for doing
> early initialization after relocation has happened.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
[snip]
> +#ifdef CONFIG_ARCH_EARLY_INIT_R
> +	arch_early_init_r();
> +#endif

We never check return status, make this a void?  As Wolfgang has said
before, just because the other examples do things wrong doesn't mean we
should keep doing it :)

-- 
Tom

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Graeme Russ]

Hi Tom,

On Tue, Apr 3, 2012 at 8:15 AM, Tom Rini <trini@ti.com> wrote:
> On Mon, Apr 02, 2012 at 06:19:45PM -0300, Fabio Estevam wrote:
>
>> Introduce arch_early_init_r() function, which can be useful for doing
>> early initialization after relocation has happened.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> [snip]
>> +#ifdef CONFIG_ARCH_EARLY_INIT_R
>> + ? ? arch_early_init_r();
>> +#endif
>
> We never check return status, make this a void? ?As Wolfgang has said
> before, just because the other examples do things wrong doesn't mean we
> should keep doing it :)

The INIT_FUNC patch series will require that the board_init...() functions
get flattened to simply processing loops and all of these extra functions
that have crept in outside those loops be moved into the init arrays.

Have a look at arch/x86/lib/board.c for reference

Defining these functions as returning int with no parameters will make
that work a lot easier

Regards,

Graeme

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Marek Vasut]

Dear Fabio Estevam,

> Introduce arch_early_init_r() function, which can be useful for doing
> early initialization after relocation has happened.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

Are we getting anywhere with this patchset please?

CCing Albert Aribaud.

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Fabio Estevam]

On Thu, Apr 5, 2012 at 9:30 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Fabio Estevam,
>
>> Introduce arch_early_init_r() function, which can be useful for doing
>> early initialization after relocation has happened.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>
> Are we getting anywhere with this patchset please?

Looking forward for it to be applied :-)

>
> CCing Albert Aribaud.

I added Albert on Cc on my initial patch submission.

Regards,

Fabio Estevam

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Marek Vasut]

Dear Fabio Estevam,

> On Thu, Apr 5, 2012 at 9:30 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Fabio Estevam,
> > 
> >> Introduce arch_early_init_r() function, which can be useful for doing
> >> early initialization after relocation has happened.
> >> 
> >> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > 
> > Are we getting anywhere with this patchset please?
> 
> Looking forward for it to be applied :-)
> 
> > CCing Albert Aribaud.
> 
> I added Albert on Cc on my initial patch submission.

Well ... let's prod him a bit more ;)

> Regards,
> 
> Fabio Estevam

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/2] ARM: introduce arch_early_init_r()

[Albert ARIBAUD]

Hi Fabio,

On Mon, 2 Apr 2012 18:19:45 -0300, Fabio Estevam
<fabio.estevam@freescale.com> wrote:

> Introduce arch_early_init_r() function, which can be useful for doing
> early initialization after relocation has happened.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>  arch/arm/include/asm/u-boot-arm.h |    1 +
>  arch/arm/lib/board.c              |    4 ++++
>  2 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/include/asm/u-boot-arm.h
> b/arch/arm/include/asm/u-boot-arm.h index 4ca75f9..9f3cae5 100644
> --- a/arch/arm/include/asm/u-boot-arm.h
> +++ b/arch/arm/include/asm/u-boot-arm.h
> @@ -52,6 +52,7 @@ void	cpu_init_cp15(void);
>  /* cpu/.../arch/cpu.c */
>  int	arch_cpu_init(void);
>  int	arch_misc_init(void);
> +int	arch_early_init_r(void);
>  
>  /* board/.../... */
>  int	board_init(void);
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index 5270c11..025d6ca 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -500,6 +500,10 @@ void board_init_r(gd_t *id, ulong dest_addr)
>  	malloc_start = dest_addr - TOTAL_MALLOC_LEN;
>  	mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
>  
> +#ifdef CONFIG_ARCH_EARLY_INIT_R
> +	arch_early_init_r();
> +#endif
> +
>  #if !defined(CONFIG_SYS_NO_FLASH)
>  	puts("Flash: ");
>  

Applied to u-boot-arm (with an addmittedly very slow sensitivity to
prodding), thanks.

Amicalement,
-- 
Albert.