[U-Boot] [PATCH 0/3] i.MX refactoring patchset

[U-Boot] [PATCH 0/3] i.MX refactoring patchset

[Otavio Salvador]

This patchset include minor changes for i.MX; mainly:

 1/3: improves the rare case of unkown booting machine
 2/3: generalize the code so it works for i.MX23 and i.MX28

The patch 3/3 is what we've been using in Yocto and has been change to
affect only mx28evk.

Otavio Salvador (3):
  imx: Use a clear identification of an unidentified CPU type
  mxs: generalize code for print_cpuinfo()
  mx28evk: extend default environment

 arch/arm/cpu/arm926ejs/mx28/mx28.c  |   29 +++++++++++-
 arch/arm/cpu/armv7/imx-common/cpu.c |    4 +-
 include/configs/mx28evk.h           |   83 +++++++++++++++++++++++++++++++----
 3 files changed, 104 insertions(+), 12 deletions(-)

-- 
1.7.10

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Otavio Salvador]

In case an unidentified CPU type is detected it now returns
i.MX<unidentified>, in a const char.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
---
 arch/arm/cpu/armv7/imx-common/cpu.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/imx-common/cpu.c b/arch/arm/cpu/armv7/imx-common/cpu.c
index b3195dd..77aac7d 100644
--- a/arch/arm/cpu/armv7/imx-common/cpu.c
+++ b/arch/arm/cpu/armv7/imx-common/cpu.c
@@ -66,7 +66,7 @@ char *get_reset_cause(void)
 
 #if defined(CONFIG_DISPLAY_CPUINFO)
 
-static char *get_imx_type(u32 imxtype)
+static const char *get_imx_type(u32 imxtype)
 {
 	switch (imxtype) {
 	case 0x63:
@@ -80,7 +80,7 @@ static char *get_imx_type(u32 imxtype)
 	case 0x53:
 		return "53";
 	default:
-		return "unknown";
+		return "<unidentified>";
 	}
 }
 
-- 
1.7.10

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Otavio Salvador]

The information now is gathered from HW_DIGCTL_CHIPID register and
includes the revision of the chip on the output.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
---
 arch/arm/cpu/arm926ejs/mx28/mx28.c |   29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index a82ff25..ac2f2e0 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -190,13 +190,38 @@ int arch_cpu_init(void)
 #endif
 
 #if defined(CONFIG_DISPLAY_CPUINFO)
+static const char *get_cpu_type(void)
+{
+	struct mx28_digctl_regs *digctl_regs =
+		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
+
+	switch (readl(&digctl_regs->hw_digctl_chipid) >> 16) {
+	case 0x2800:
+		return "28";
+	case 0x3728:
+		return "23";
+	default:
+		return "<unidentified>";
+	}
+}
+
+static u8 get_cpu_rev(void)
+{
+	struct mx28_digctl_regs *digctl_regs =
+		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
+
+	return readl(&digctl_regs->hw_digctl_chipid) & 0x0000F;
+}
+
 int print_cpuinfo(void)
 {
 	struct mx28_spl_data *data = (struct mx28_spl_data *)
 		((CONFIG_SYS_TEXT_BASE - sizeof(struct mx28_spl_data)) & ~0xf);
 
-	printf("Freescale i.MX28 family at %d MHz\n",
-			mxc_get_clock(MXC_ARM_CLK) / 1000000);
+	printf("CPU:   Freescale i.MX%s rev%d at %d MHz\n",
+		get_cpu_type(),
+		get_cpu_rev(),
+		mxc_get_clock(MXC_ARM_CLK) / 1000000);
 	printf("BOOT:  %s\n", mx28_boot_modes[data->boot_mode_idx].mode);
 	return 0;
 }
-- 
1.7.10

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Otavio Salvador]

The environment has been based on mx53loco and m28evk but keeping the
possibility to easy change the default console device as Freescale and
mainline kernels differ on the device name.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
---
 include/configs/mx28evk.h |   83 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 75 insertions(+), 8 deletions(-)

diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index e98a746..889d58a 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -234,7 +234,6 @@
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_BOOTDELAY	3
 #define CONFIG_BOOTFILE	"uImage"
-#define CONFIG_BOOTCOMMAND	"run bootcmd_net"
 #define CONFIG_LOADADDR	0x42000000
 #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
 #define CONFIG_OF_LIBFDT
@@ -243,13 +242,81 @@
  * Extra Environments
  */
 #define CONFIG_EXTRA_ENV_SETTINGS \
-	"console_fsl=console=ttyAM0" \
-	"console_mainline=console=ttyAMA0" \
-	"netargs=setenv bootargs console=${console_mainline}" \
+	"update_nand_full_filename=u-boot.nand\0" \
+	"update_nand_firmware_filename=u-boot.sb\0"	\
+	"update_sd_firmware_filename=u-boot.sd\0" \
+	"update_nand_firmware_maxsz=0x100000\0"	\
+	"update_nand_stride=0x40\0"	/* MX28 datasheet ch. 12.12 */ \
+	"update_nand_count=0x4\0"	/* MX28 datasheet ch. 12.12 */ \
+	"update_nand_get_fcb_size="	/* Get size of FCB blocks */ \
+		"nand device 0 ; " \
+		"nand info ; " \
+		"setexpr fcb_sz ${update_nand_stride} * ${update_nand_count};" \
+		"setexpr update_nand_fcb ${fcb_sz} * ${nand_writesize}\0" \
+	"update_nand_full="		    /* Update FCB, DBBT and FW */ \
+		"if tftp ${update_nand_full_filename} ; then " \
+		"run update_nand_get_fcb_size ; " \
+		"nand scrub -y 0x0 ${filesize} ; " \
+		"nand write.raw ${loadaddr} 0x0 ${update_nand_fcb} ; " \
+		"setexpr update_off ${loadaddr} + ${update_nand_fcb} ; " \
+		"setexpr update_sz ${filesize} - ${update_nand_fcb} ; " \
+		"nand write ${update_off} ${update_nand_fcb} ${update_sz} ; " \
+		"fi\0" \
+	"update_nand_firmware="		/* Update only firmware */ \
+		"if tftp ${update_nand_firmware_filename} ; then " \
+		"run update_nand_get_fcb_size ; " \
+		"setexpr fcb_sz ${update_nand_fcb} * 2 ; " /* FCB + DBBT */ \
+		"setexpr fw_sz ${update_nand_firmware_maxsz} * 2 ; " \
+		"setexpr fw_off ${fcb_sz} + ${update_nand_firmware_maxsz};" \
+		"nand erase ${fcb_sz} ${fw_sz} ; " \
+		"nand write ${loadaddr} ${fcb_sz} ${filesize} ; " \
+		"nand write ${loadaddr} ${fw_off} ${filesize} ; " \
+		"fi\0" \
+	"update_sd_firmware="		/* Update the SD firmware partition */ \
+		"if mmc rescan ; then "	\
+		"if tftp ${update_sd_firmware_filename} ; then " \
+		"setexpr fw_sz ${filesize} / 0x200 ; "	/* SD block size */ \
+		"setexpr fw_sz ${fw_sz} + 1 ; "	\
+		"mmc write ${loadaddr} 0x800 ${fw_sz} ; " \
+		"fi ; "	\
+		"fi\0" \
+	"script=boot.scr\0"	\
+	"uimage=uImage\0" \
+	"console_fsl=ttyAM0\0" \
+	"console_mainline=ttyAMA0\0" \
+	"console=${console_mainline}\0" \
+	"mmcdev=0\0" \
+	"mmcpart=2\0" \
+	"mmcroot=/dev/mmcblk0p3 rw\0" \
+	"mmcrootfstype=ext3 rootwait\0"	\
+	"mmcargs=setenv bootargs console=${console},${baudrate} " \
+		"root=${mmcroot} " \
+		"rootfstype=${mmcrootfstype}\0"	\
+	"loadbootscript="  \
+		"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+	"bootscript=echo Running bootscript from mmc ...; "	\
+		"source\0" \
+	"loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
+	"mmcboot=echo Booting from mmc ...; " \
+		"run mmcargs; "	\
+		"bootm\0" \
+	"netargs=setenv bootargs console=${console},${baudrate} " \
 		"root=/dev/nfs " \
-		"ip=dhcp nfsroot=${serverip}:${nfsroot}\0" \
-	"bootcmd_net=echo Booting from net ...; " \
-		"run netargs; " \
-		"dhcp ${uimage}; bootm\0" \
+		"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
+	"netboot=echo Booting from net ...; " \
+		"run netargs; "	\
+		"dhcp ${uimage}; bootm\0"
+
+#define CONFIG_BOOTCOMMAND \
+	"if mmc rescan ${mmcdev}; then " \
+		"if run loadbootscript; then " \
+			"run bootscript; " \
+		"else " \
+			"if run loaduimage; then " \
+				"run mmcboot; " \
+			"else run netboot; " \
+			"fi; " \
+		"fi; " \
+	"else run netboot; fi"
 
 #endif /* __MX28EVK_CONFIG_H__ */
-- 
1.7.10

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Fabio Estevam]

On Sun, Jun 17, 2012 at 9:58 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:

> -static char *get_imx_type(u32 imxtype)
> +static const char *get_imx_type(u32 imxtype)

This is OK, but ...
> ?{
> ? ? ? ?switch (imxtype) {
> ? ? ? ?case 0x63:
> @@ -80,7 +80,7 @@ static char *get_imx_type(u32 imxtype)
> ? ? ? ?case 0x53:
> ? ? ? ? ? ? ? ?return "53";
> ? ? ? ?default:
> - ? ? ? ? ? ? ? return "unknown";
> + ? ? ? ? ? ? ? return "<unidentified>";

I really don't see any improvement here.

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Otavio Salvador]

On Sun, Jun 17, 2012 at 10:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> ? ? ? ?default:
>> - ? ? ? ? ? ? ? return "unknown";
>> + ? ? ? ? ? ? ? return "<unidentified>";
>
> I really don't see any improvement here.

It is just to avoid a i.MXunkown return; besides this is how I am
doing in the mx23 code too.

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Fabio Estevam]

On Sun, Jun 17, 2012 at 9:58 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> The information now is gathered from HW_DIGCTL_CHIPID register and
> includes the revision of the chip on the output.
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> ?arch/arm/cpu/arm926ejs/mx28/mx28.c | ? 29 +++++++++++++++++++++++++++--
> ?1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c b/arch/arm/cpu/arm926ejs/mx28/mx28.c
> index a82ff25..ac2f2e0 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
> @@ -190,13 +190,38 @@ int arch_cpu_init(void)
> ?#endif
>
> ?#if defined(CONFIG_DISPLAY_CPUINFO)
> +static const char *get_cpu_type(void)
> +{
> + ? ? ? struct mx28_digctl_regs *digctl_regs =
> + ? ? ? ? ? ? ? (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> +
> + ? ? ? switch (readl(&digctl_regs->hw_digctl_chipid) >> 16) {
> + ? ? ? case 0x2800:
> + ? ? ? ? ? ? ? return "28";
> + ? ? ? case 0x3728:
> + ? ? ? ? ? ? ? return "23";
> + ? ? ? default:
> + ? ? ? ? ? ? ? return "<unidentified>";
> + ? ? ? }
> +}
> +
> +static u8 get_cpu_rev(void)
> +{
> + ? ? ? struct mx28_digctl_regs *digctl_regs =
> + ? ? ? ? ? ? ? (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> +
> + ? ? ? return readl(&digctl_regs->hw_digctl_chipid) & 0x0000F;
> +}
> +
> ?int print_cpuinfo(void)
> ?{
> ? ? ? ?struct mx28_spl_data *data = (struct mx28_spl_data *)
> ? ? ? ? ? ? ? ?((CONFIG_SYS_TEXT_BASE - sizeof(struct mx28_spl_data)) & ~0xf);
>
> - ? ? ? printf("Freescale i.MX28 family at %d MHz\n",
> - ? ? ? ? ? ? ? ? ? ? ? mxc_get_clock(MXC_ARM_CLK) / 1000000);
> + ? ? ? printf("CPU: ? Freescale i.MX%s rev%d at %d MHz\n",

In all other i.MX SoCs we display the revision as rev%d.%d, for example:

rev1.0 , rev1.1 , etc.

I think we should print it in the same format here (x.y)

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Fabio Estevam]

On Sun, Jun 17, 2012 at 10:09 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Sun, Jun 17, 2012 at 10:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>> ? ? ? ?default:
>>> - ? ? ? ? ? ? ? return "unknown";
>>> + ? ? ? ? ? ? ? return "<unidentified>";
>>
>> I really don't see any improvement here.
>
> It is just to avoid a i.MXunkown return; besides this is how I am
> doing in the mx23 code too.

This is OK. If you read "i.MXunkown" things are too broken already
because the chip version could not be read.

Reading "i.MX<unidentified>" will make things no better.

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Otavio Salvador]

On Sun, Jun 17, 2012 at 10:13 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Reading "i.MX<unidentified>" will make things no better.

OK; I'll drop it from the patch queue then.

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Fabio Estevam]

On Sun, Jun 17, 2012 at 9:58 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:

> ?#if defined(CONFIG_DISPLAY_CPUINFO)
> +static const char *get_cpu_type(void)
> +{
> + ? ? ? struct mx28_digctl_regs *digctl_regs =
> + ? ? ? ? ? ? ? (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> +
> + ? ? ? switch (readl(&digctl_regs->hw_digctl_chipid) >> 16) {
> + ? ? ? case 0x2800:
> + ? ? ? ? ? ? ? return "28";
> + ? ? ? case 0x3728:

Reading the Reference Manual I read 0x3780 instead.

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Marek Vasut]

Dear Otavio Salvador,

> The information now is gathered from HW_DIGCTL_CHIPID register and
> includes the revision of the chip on the output.
> 
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>  arch/arm/cpu/arm926ejs/mx28/mx28.c |   29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> b/arch/arm/cpu/arm926ejs/mx28/mx28.c index a82ff25..ac2f2e0 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
> @@ -190,13 +190,38 @@ int arch_cpu_init(void)
>  #endif
> 
>  #if defined(CONFIG_DISPLAY_CPUINFO)
> +static const char *get_cpu_type(void)
> +{
> +	struct mx28_digctl_regs *digctl_regs =
> +		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> +
> +	switch (readl(&digctl_regs->hw_digctl_chipid) >> 16) {

#define that >> 16 ... maybe offset? I'd define a mask though, see below.

#define PRODUCT_CODE_MASK (0xffff << 16)

> +	case 0x2800:

#define this as something ... #define PRODUCT_CODE_MX28 (0x2800 << 16)

> +		return "28";
> +	case 0x3728:
> +		return "23";
> +	default:
> +		return "<unidentified>";

So X-Files-ish ;-)

> +	}
> +}
> +
> +static u8 get_cpu_rev(void)

uint8_t ... maybe? it's used throughout the code, so let's keep consistent.

> +{
> +	struct mx28_digctl_regs *digctl_regs =
> +		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> +
> +	return readl(&digctl_regs->hw_digctl_chipid) & 0x0000F;
> +}
> +
>  int print_cpuinfo(void)
>  {
>  	struct mx28_spl_data *data = (struct mx28_spl_data *)
>  		((CONFIG_SYS_TEXT_BASE - sizeof(struct mx28_spl_data)) & ~0xf);
> 
> -	printf("Freescale i.MX28 family at %d MHz\n",
> -			mxc_get_clock(MXC_ARM_CLK) / 1000000);
> +	printf("CPU:   Freescale i.MX%s rev%d at %d MHz\n",
> +		get_cpu_type(),
> +		get_cpu_rev(),
> +		mxc_get_clock(MXC_ARM_CLK) / 1000000);
>  	printf("BOOT:  %s\n", mx28_boot_modes[data->boot_mode_idx].mode);
>  	return 0;
>  }

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Marek Vasut]

Dear Fabio Estevam,

> On Sun, Jun 17, 2012 at 10:09 AM, Otavio Salvador
> 
> <otavio@ossystems.com.br> wrote:
> > On Sun, Jun 17, 2012 at 10:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
> >>>        default:
> >>> -               return "unknown";
> >>> +               return "<unidentified>";
> >> 
> >> I really don't see any improvement here.
> > 
> > It is just to avoid a i.MXunkown return; besides this is how I am
> > doing in the mx23 code too.
> 
> This is OK. If you read "i.MXunkown" things are too broken already
> because the chip version could not be read.
> 
> Reading "i.MX<unidentified>" will make things no better.

This was from my head actually ... and I think this is better. The text is at 
least not mangled so badly. So let's keep it.

Best regards,
Marek Vasut

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Marek Vasut]

Dear Fabio Estevam,

> On Sun, Jun 17, 2012 at 9:58 AM, Otavio Salvador
> 
> <otavio@ossystems.com.br> wrote:
> >  #if defined(CONFIG_DISPLAY_CPUINFO)
> > +static const char *get_cpu_type(void)
> > +{
> > +       struct mx28_digctl_regs *digctl_regs =
> > +               (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> > +
> > +       switch (readl(&digctl_regs->hw_digctl_chipid) >> 16) {
> > +       case 0x2800:
> > +               return "28";
> 
> > +       case 0x3728:
> Reading the Reference Manual I read 0x3780 instead.

Good catch ;-)

What's the code for mx6q? They dropped this register from it it seems ;-)

Best regards,
Marek Vasut

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Fabio Estevam]

On Sun, Jun 17, 2012 at 10:35 AM, Marek Vasut <marex@denx.de> wrote:

> What's the code for mx6q? They dropped this register from it it seems ;-)

mx6 code does read the SoC type and revision correctly.

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Otavio Salvador]

On Sun, Jun 17, 2012 at 10:25 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Reading the Reference Manual I read 0x3780 instead.

Indeed; I must have typoed it when writting it back.

I fixed it locally; Fabio will check the masking for mx28 revision and
when I get it I update the patch according.

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Marek Vasut]

Dear Otavio Salvador,

> On Sun, Jun 17, 2012 at 10:25 AM, Fabio Estevam <festevam@gmail.com> wrote:
> > Reading the Reference Manual I read 0x3780 instead.
> 
> Indeed; I must have typoed it when writting it back.
> 
> I fixed it locally; Fabio will check the masking for mx28 revision and
> when I get it I update the patch according.

It's 0x2800 ... roll out a new version ;-)

Best regards,
Marek Vasut

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Otavio Salvador]

On Sun, Jun 17, 2012 at 12:10 PM, Marek Vasut <marex@denx.de> wrote:
>> I fixed it locally; Fabio will check the masking for mx28 revision and
>> when I get it I update the patch according.
>
> It's 0x2800 ... roll out a new version ;-)

We are in doubt about the revision, not product code ;-)

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Stefano Babic]

On 17/06/2012 14:58, Otavio Salvador wrote:
> In case an unidentified CPU type is detected it now returns
> i.MX<unidentified>, in a const char.
> 
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> ---

Hi Otavio,


>  arch/arm/cpu/armv7/imx-common/cpu.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/imx-common/cpu.c b/arch/arm/cpu/armv7/imx-common/cpu.c
> index b3195dd..77aac7d 100644
> --- a/arch/arm/cpu/armv7/imx-common/cpu.c
> +++ b/arch/arm/cpu/armv7/imx-common/cpu.c
> @@ -66,7 +66,7 @@ char *get_reset_cause(void)
>  
>  #if defined(CONFIG_DISPLAY_CPUINFO)
>  
> -static char *get_imx_type(u32 imxtype)
> +static const char *get_imx_type(u32 imxtype)
>  {
>  	switch (imxtype) {
>  	case 0x63:
> @@ -80,7 +80,7 @@ static char *get_imx_type(u32 imxtype)
>  	case 0x53:
>  		return "53";
>  	default:
> -		return "unknown";
> +		return "<unidentified>";

Taste ist taste... but why <unidentified> is better that unknown ?

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

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Otavio Salvador]

On Sun, Jun 17, 2012 at 12:43 PM, Stefano Babic <sbabic@denx.de> wrote:
>> - ? ? ? ? ? ? return "unknown";
>> + ? ? ? ? ? ? return "<unidentified>";
>
> Taste ist taste... but why <unidentified> is better that unknown ?

For me it gives a visual indication that we didn't meant to support a
i.MXunknown processor ;-) i.MX<unidentified> make it easy to spot
this.

But really, I don't mind it being included or not. I did it because
Marek has comment about it when looking at my initial mx23 patches.

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Stefano Babic]

On 17/06/2012 14:58, Otavio Salvador wrote:
> The information now is gathered from HW_DIGCTL_CHIPID register and
> includes the revision of the chip on the output.
> 
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> ---

Hi Otavio,

>  arch/arm/cpu/arm926ejs/mx28/mx28.c |   29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c b/arch/arm/cpu/arm926ejs/mx28/mx28.c
> index a82ff25..ac2f2e0 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
> @@ -190,13 +190,38 @@ int arch_cpu_init(void)
>  #endif
>  
>  #if defined(CONFIG_DISPLAY_CPUINFO)
> +static const char *get_cpu_type(void)
> +{
> +	struct mx28_digctl_regs *digctl_regs =
> +		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> +
> +	switch (readl(&digctl_regs->hw_digctl_chipid) >> 16) {
> +	case 0x2800:
> +		return "28";
> +	case 0x3728:
> +		return "23";
> +	default:
> +		return "<unidentified>";
> +	}
> +}

I like that there will be support for i.MX23, too. But I dislike that
everything takes the name "MX28". As you suggest in your subject, maybe
it is time to rename directories, and use "mxs" (as in kernel) instead
of mx28.

> +
> +static u8 get_cpu_rev(void)
> +{
> +	struct mx28_digctl_regs *digctl_regs =
> +		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> +
> +	return readl(&digctl_regs->hw_digctl_chipid) & 0x0000F;
> +}

Everywhere (i.MX, omap, ...) get_cpu_rev returns u32. The function is
currently exported, too.

Best regards,
Stefano Babic

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

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Marek Vasut]

Dear Stefano Babic,

> On 17/06/2012 14:58, Otavio Salvador wrote:
> > The information now is gathered from HW_DIGCTL_CHIPID register and
> > includes the revision of the chip on the output.
> > 
> > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> > Cc: Marek Vasut <marex@denx.de>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > ---
> 
> Hi Otavio,
> 
> >  arch/arm/cpu/arm926ejs/mx28/mx28.c |   29 +++++++++++++++++++++++++++--
> >  1 file changed, 27 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> > b/arch/arm/cpu/arm926ejs/mx28/mx28.c index a82ff25..ac2f2e0 100644
> > --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> > +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
> > @@ -190,13 +190,38 @@ int arch_cpu_init(void)
> > 
> >  #endif
> >  
> >  #if defined(CONFIG_DISPLAY_CPUINFO)
> > 
> > +static const char *get_cpu_type(void)
> > +{
> > +	struct mx28_digctl_regs *digctl_regs =
> > +		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> > +
> > +	switch (readl(&digctl_regs->hw_digctl_chipid) >> 16) {
> > +	case 0x2800:
> > +		return "28";
> > +	case 0x3728:
> > +		return "23";
> > +	default:
> > +		return "<unidentified>";
> > +	}
> > +}
> 
> I like that there will be support for i.MX23, too. But I dislike that
> everything takes the name "MX28". As you suggest in your subject, maybe
> it is time to rename directories, and use "mxs" (as in kernel) instead
> of mx28.

We can do that eventually, later ... it depends on the ordering of Otavio's 
patches, I'm fine either way.

> > +
> > +static u8 get_cpu_rev(void)
> > +{
> > +	struct mx28_digctl_regs *digctl_regs =
> > +		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> > +
> > +	return readl(&digctl_regs->hw_digctl_chipid) & 0x0000F;
> > +}
> 
> Everywhere (i.MX, omap, ...) get_cpu_rev returns u32. The function is
> currently exported, too.

Correct, but isn't the return value mangled somehow (like having major rev. << 
16 and minor rev. << 0 )? Or that's only IMX?

> 
> Best regards,
> Stefano Babic

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Marek Vasut]

Dear Otavio Salvador,

> On Sun, Jun 17, 2012 at 12:43 PM, Stefano Babic <sbabic@denx.de> wrote:
> >> -             return "unknown";
> >> +             return "<unidentified>";
> > 
> > Taste ist taste... but why <unidentified> is better that unknown ?
> 
> For me it gives a visual indication that we didn't meant to support a
> i.MXunknown processor ;-) i.MX<unidentified> make it easy to spot
> this.
> 
> But really, I don't mind it being included or not. I did it because
> Marek has comment about it when looking at my initial mx23 patches.

And I like it more, it looks less like a typo.

Best regards,
Marek Vasut

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Otavio Salvador]

On Sun, Jun 17, 2012 at 12:49 PM, Stefano Babic <sbabic@denx.de> wrote:
> I like that there will be support for i.MX23, too. But I dislike that
> everything takes the name "MX28". As you suggest in your subject, maybe
> it is time to rename directories, and use "mxs" (as in kernel) instead
> of mx28.

I have it in my wip branch; I'd like to hold it until I have mx23
working so I have freedom to rework the patches.

I can split it on mx28 part and leave mx23 on my branch; this does
looks nicer for me.

>> +static u8 get_cpu_rev(void)
>> +{
>> + ? ? struct mx28_digctl_regs *digctl_regs =
>> + ? ? ? ? ? ? (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
>> +
>> + ? ? return readl(&digctl_regs->hw_digctl_chipid) & 0x0000F;
>> +}
>
> Everywhere (i.MX, omap, ...) get_cpu_rev returns u32. The function is
> currently exported, too.

I change it then.

Will fix it.

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Otavio Salvador]

On Sun, Jun 17, 2012 at 1:03 PM, Marek Vasut <marex@denx.de> wrote:
>> But really, I don't mind it being included or not. I did it because
>> Marek has comment about it when looking at my initial mx23 patches.
>
> And I like it more, it looks less like a typo.

Sorry; I didn't get what you meant ... should it go or not?

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Stefano Babic]

On 17/06/2012 18:02, Marek Vasut wrote:

>> I like that there will be support for i.MX23, too. But I dislike that
>> everything takes the name "MX28". As you suggest in your subject, maybe
>> it is time to rename directories, and use "mxs" (as in kernel) instead
>> of mx28.
> 
> We can do that eventually, later ... it depends on the ordering of Otavio's 
> patches, I'm fine either way.

Fine with me - anyway, it is something must be done.

> 
>>> +
>>> +static u8 get_cpu_rev(void)
>>> +{
>>> +	struct mx28_digctl_regs *digctl_regs =
>>> +		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
>>> +
>>> +	return readl(&digctl_regs->hw_digctl_chipid) & 0x0000F;
>>> +}
>>
>> Everywhere (i.MX, omap, ...) get_cpu_rev returns u32. The function is
>> currently exported, too.
> 
> Correct, but isn't the return value mangled somehow (like having major rev. << 
> 16 and minor rev. << 0 )? Or that's only IMX?

Checking in current implementations for get_cpu_rev() (i.MX / OMAP24 /
OMAP3 / AM33, and even board/apollon/sys_info.c: I do not know why the
cpu detection is inseide this file), none of them requires strictly 32
bit. However, we should be coherent in all code - for this reason I
dislike if one of the i.MX is implemented differently as for other SOCs.

Best regards,
Stefano Babic

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

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Otavio Salvador]

On Sun, Jun 17, 2012 at 2:56 PM, Stefano Babic <sbabic@denx.de> wrote:
>> Correct, but isn't the return value mangled somehow (like having major rev. <<
>> 16 and minor rev. << 0 )? Or that's only IMX?
>
> Checking in current implementations for get_cpu_rev() (i.MX / OMAP24 /
> OMAP3 / AM33, and even board/apollon/sys_info.c: I do not know why the
> cpu detection is inseide this file), none of them requires strictly 32
> bit. However, we should be coherent in all code - for this reason I
> dislike if one of the i.MX is implemented differently as for other SOCs.

So, we change this one to follow the others or fix the others?

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Marek Vasut]

Dear Stefano Babic,

> On 17/06/2012 18:02, Marek Vasut wrote:
> >> I like that there will be support for i.MX23, too. But I dislike that
> >> everything takes the name "MX28". As you suggest in your subject, maybe
> >> it is time to rename directories, and use "mxs" (as in kernel) instead
> >> of mx28.
> > 
> > We can do that eventually, later ... it depends on the ordering of
> > Otavio's patches, I'm fine either way.
> 
> Fine with me - anyway, it is something must be done.
> 
> >>> +
> >>> +static u8 get_cpu_rev(void)
> >>> +{
> >>> +	struct mx28_digctl_regs *digctl_regs =
> >>> +		(struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> >>> +
> >>> +	return readl(&digctl_regs->hw_digctl_chipid) & 0x0000F;
> >>> +}
> >> 
> >> Everywhere (i.MX, omap, ...) get_cpu_rev returns u32. The function is
> >> currently exported, too.
> > 
> > Correct, but isn't the return value mangled somehow (like having major
> > rev. << 16 and minor rev. << 0 )? Or that's only IMX?
> 
> Checking in current implementations for get_cpu_rev() (i.MX / OMAP24 /
> OMAP3 / AM33, and even board/apollon/sys_info.c: I do not know why the
> cpu detection is inseide this file), none of them requires strictly 32
> bit. However, we should be coherent in all code - for this reason I
> dislike if one of the i.MX is implemented differently as for other SOCs.

+1

> Best regards,
> Stefano Babic

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Stefano Babic]

On 17/06/2012 19:50, Otavio Salvador wrote:
> On Sun, Jun 17, 2012 at 1:03 PM, Marek Vasut <marex@denx.de> wrote:
>>> But really, I don't mind it being included or not. I did it because
>>> Marek has comment about it when looking at my initial mx23 patches.
>>
>> And I like it more, it looks less like a typo.
> 
> Sorry; I didn't get what you meant ... should it go or not?

Hi Otavio,

I make also my point clearer for Marek: my point is that the behavior
for all i.MX must be consistent. If you change here, please change also
for i.MX31 (that returns "unknown in print_cpuinfo) and for other SOCs
that returns "unknown" in print_cpuinfo() - or let the code as now.

Best regards,
Stefano

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

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Marek Vasut]

Dear Otavio Salvador,

> On Sun, Jun 17, 2012 at 1:03 PM, Marek Vasut <marex@denx.de> wrote:
> >> But really, I don't mind it being included or not. I did it because
> >> Marek has comment about it when looking at my initial mx23 patches.
> > 
> > And I like it more, it looks less like a typo.
> 
> Sorry; I didn't get what you meant ... should it go or not?

It doesn't look like a typing mistake (i.MX<unknown> vs. i.MXunknown) => I like 
it more with "<" ">".

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] imx: Use a clear identification of an unidentified CPU type

[Marek Vasut]

Dear Stefano Babic,

> On 17/06/2012 19:50, Otavio Salvador wrote:
> > On Sun, Jun 17, 2012 at 1:03 PM, Marek Vasut <marex@denx.de> wrote:
> >>> But really, I don't mind it being included or not. I did it because
> >>> Marek has comment about it when looking at my initial mx23 patches.
> >> 
> >> And I like it more, it looks less like a typo.
> > 
> > Sorry; I didn't get what you meant ... should it go or not?
> 
> Hi Otavio,
> 
> I make also my point clearer for Marek: my point is that the behavior
> for all i.MX must be consistent. If you change here, please change also
> for i.MX31 (that returns "unknown in print_cpuinfo) and for other SOCs
> that returns "unknown" in print_cpuinfo() - or let the code as now.

Ah, I thought it was about the revision. Ok, whatever way is fine by me.

> Best regards,
> Stefano

Best regards,
Marek Vasut

[U-Boot] [PATCH 2/3] mxs: generalize code for print_cpuinfo()

[Marek Vasut]

Dear Otavio Salvador,

> On Sun, Jun 17, 2012 at 2:56 PM, Stefano Babic <sbabic@denx.de> wrote:
> >> Correct, but isn't the return value mangled somehow (like having major
> >> rev. << 16 and minor rev. << 0 )? Or that's only IMX?
> > 
> > Checking in current implementations for get_cpu_rev() (i.MX / OMAP24 /
> > OMAP3 / AM33, and even board/apollon/sys_info.c: I do not know why the
> > cpu detection is inseide this file), none of them requires strictly 32
> > bit. However, we should be coherent in all code - for this reason I
> > dislike if one of the i.MX is implemented differently as for other SOCs.
> 
> So, we change this one to follow the others or fix the others?

Fix the others ;-)

Best regards,
Marek Vasut

[U-Boot] [PATCH 0/3] i.MX refactoring patchset

[Marek Vasut]

Dear Otavio Salvador,

> This patchset include minor changes for i.MX; mainly:
> 
>  1/3: improves the rare case of unkown booting machine

<trolling>
The word's actually "unknown" ;-D
</trolling>

>  2/3: generalize the code so it works for i.MX23 and i.MX28
> 
> The patch 3/3 is what we've been using in Yocto and has been change to
> affect only mx28evk.
> 
> Otavio Salvador (3):
>   imx: Use a clear identification of an unidentified CPU type
>   mxs: generalize code for print_cpuinfo()
>   mx28evk: extend default environment

It's good, really good :-)

>  arch/arm/cpu/arm926ejs/mx28/mx28.c  |   29 +++++++++++-
>  arch/arm/cpu/armv7/imx-common/cpu.c |    4 +-
>  include/configs/mx28evk.h           |   83
> +++++++++++++++++++++++++++++++---- 3 files changed, 104 insertions(+), 12
> deletions(-)

Best regards,
Marek Vasut

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Wolfgang Denk]

Dear Marek,

In message <201205292314.04143.marex@denx.de> you wrote:
> 
> > Not because I consider it inherently bad, but for example because it
> > is different from what we, our customers, our documentation and our
> > test scripts are used to.
> 
> Then I guess some kind of "common env" for all boards won't happen ?

I don't see a real chance. Pick any of the bigger vendors - say
Freescale: do you consider it a realistic chance that all their
boards (PPC, ARM, ColdFire, what else) get converted to a common
environment? Do you expect that TI and Samsung and Marvell and ...
agree with this approach and apply it on thier boards as ell? Or vice
versa?


I think the best we can do is factor out some parts we consider well
designed, and use these in the boards in our own responsibility.  Then
we can start pointing people at that and try to convince them to
accept this for new stuff added.

But reorganizing existing environents is basicly impossible - all the
bigger vendors will tell you how much effort it would take to update
just all the documentation, not to mention to update all the boards
and scrpts and handle the resulting board breakages / brickages.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Marek Vasut]

Dear Wolfgang Denk,

> Dear Otavio Salvador,
> 
> In message <CAP9ODKqPY51QzdLPejC4GyO3H-
S0jYwFxEipEhSebX74Jkg0aQ@mail.gmail.com> you wrote:
> > I can work on that as far as I know what people expect to have. In
> > meanwhile I'd prefer to have this in since it allow the default
> > environment to just work in our BSP layer for OpenEmbedded.
> 
> There is no such thing as "the default environment".
> 
> The default environment is vendor specific at bets, and usualy board
> specific.  As explained before, I will not accept the Freescale style
> on boards maintained by DENX.
> 
> Not because I consider it inherently bad, but for example because it
> is different from what we, our customers, our documentation and our
> test scripts are used to.

Then I guess some kind of "common env" for all boards won't happen ?

> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Otavio Salvador]

On Tue, May 29, 2012 at 5:57 PM, Wolfgang Denk <wd@denx.de> wrote:

> Starting by now,  I will NAK all these patches that get posted and
> reposted and reposted again continuously ignoring the rules for patch
> submissions.
>

I sent the last version of the patch changing only the Freescable board.

As I said, I am working on MX23 and will rebase and resend all this patches
once it is OK. If possible, give access to the patchwork so I remove the
patches that has been deprecated and I am the author so it doesn't bother
there.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Wolfgang Denk]

Dear Otavio Salvador,

In message <1337117472-15907-1-git-send-email-otavio@ossystems.com.br> you wrote:
> The environment has been based on mx53loco and m28evk but keeping the
> possibility to easy change the default console device as Freescale and
> mainline kernels differ on the device name.
> 
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>  include/configs/mx28evk.h |   83 ++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 75 insertions(+), 8 deletions(-)

Starting by now,  I will NAK all these patches that get posted and
reposted and reposted again continuously ignoring the rules for patch
submissions.

Please read
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
and stick to the documented rules.

I suggest we invalidate _all_ previously posted patcehs, you add the
required changes and resubmit.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If in any problem you find yourself doing an immense amount of  work,
the answer can be obtained by simple inspection.

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Wolfgang Denk]

Dear Otavio Salvador,

In message <CAP9ODKqPY51QzdLPejC4GyO3H-S0jYwFxEipEhSebX74Jkg0aQ@mail.gmail.com> you wrote:
>
> I can work on that as far as I know what people expect to have. In
> meanwhile I'd prefer to have this in since it allow the default
> environment to just work in our BSP layer for OpenEmbedded.

There is no such thing as "the default environment".

The default environment is vendor specific at bets, and usualy board
specific.  As explained before, I will not accept the Freescale style
on boards maintained by DENX.

Not because I consider it inherently bad, but for example because it
is different from what we, our customers, our documentation and our
test scripts are used to.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It is easier to port a shell than a shell script."      - Larry Wall

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Wolfgang Denk]

Dear Otavio Salvador,

In message <1337115571-14115-3-git-send-email-otavio@ossystems.com.br> you wrote:
> The environment has been based on mx53loco and m28evk but keeping the
> possibility to easy change the default console device as Freescale and
> mainline kernels differ on the device name.

NAK.

I will not acceept this.


Please accept that the configuration of the Freescale boards was done
by Freescale and is maintained by freescale, but it is not generally
considered to be the best of all possible solutions.

Freescale may use it on their boards if they like.  You may use it on
your boards if you like.

But I don't want to see this on any boards in my responsibility,
because I dislike it.

Please allow that we maintain the M28EVK configuration as we like it.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Summit meetings tend to be like panda matings. The expectations  are
always high, and the results usually disappointing."   - Robert Orben

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Otavio Salvador]

The environment has been based on mx53loco and m28evk but keeping the
possibility to easy change the default console device as Freescale and
mainline kernels differ on the device name.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
---
 include/configs/mx28evk.h |   83 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 75 insertions(+), 8 deletions(-)

diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index e98a746..889d58a 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -234,7 +234,6 @@
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_BOOTDELAY	3
 #define CONFIG_BOOTFILE	"uImage"
-#define CONFIG_BOOTCOMMAND	"run bootcmd_net"
 #define CONFIG_LOADADDR	0x42000000
 #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
 #define CONFIG_OF_LIBFDT
@@ -243,13 +242,81 @@
  * Extra Environments
  */
 #define CONFIG_EXTRA_ENV_SETTINGS \
-	"console_fsl=console=ttyAM0" \
-	"console_mainline=console=ttyAMA0" \
-	"netargs=setenv bootargs console=${console_mainline}" \
+	"update_nand_full_filename=u-boot.nand\0" \
+	"update_nand_firmware_filename=u-boot.sb\0"	\
+	"update_sd_firmware_filename=u-boot.sd\0" \
+	"update_nand_firmware_maxsz=0x100000\0"	\
+	"update_nand_stride=0x40\0"	/* MX28 datasheet ch. 12.12 */ \
+	"update_nand_count=0x4\0"	/* MX28 datasheet ch. 12.12 */ \
+	"update_nand_get_fcb_size="	/* Get size of FCB blocks */ \
+		"nand device 0 ; " \
+		"nand info ; " \
+		"setexpr fcb_sz ${update_nand_stride} * ${update_nand_count};" \
+		"setexpr update_nand_fcb ${fcb_sz} * ${nand_writesize}\0" \
+	"update_nand_full="		    /* Update FCB, DBBT and FW */ \
+		"if tftp ${update_nand_full_filename} ; then " \
+		"run update_nand_get_fcb_size ; " \
+		"nand scrub -y 0x0 ${filesize} ; " \
+		"nand write.raw ${loadaddr} 0x0 ${update_nand_fcb} ; " \
+		"setexpr update_off ${loadaddr} + ${update_nand_fcb} ; " \
+		"setexpr update_sz ${filesize} - ${update_nand_fcb} ; " \
+		"nand write ${update_off} ${update_nand_fcb} ${update_sz} ; " \
+		"fi\0" \
+	"update_nand_firmware="		/* Update only firmware */ \
+		"if tftp ${update_nand_firmware_filename} ; then " \
+		"run update_nand_get_fcb_size ; " \
+		"setexpr fcb_sz ${update_nand_fcb} * 2 ; " /* FCB + DBBT */ \
+		"setexpr fw_sz ${update_nand_firmware_maxsz} * 2 ; " \
+		"setexpr fw_off ${fcb_sz} + ${update_nand_firmware_maxsz};" \
+		"nand erase ${fcb_sz} ${fw_sz} ; " \
+		"nand write ${loadaddr} ${fcb_sz} ${filesize} ; " \
+		"nand write ${loadaddr} ${fw_off} ${filesize} ; " \
+		"fi\0" \
+	"update_sd_firmware="		/* Update the SD firmware partition */ \
+		"if mmc rescan ; then "	\
+		"if tftp ${update_sd_firmware_filename} ; then " \
+		"setexpr fw_sz ${filesize} / 0x200 ; "	/* SD block size */ \
+		"setexpr fw_sz ${fw_sz} + 1 ; "	\
+		"mmc write ${loadaddr} 0x800 ${fw_sz} ; " \
+		"fi ; "	\
+		"fi\0" \
+	"script=boot.scr\0"	\
+	"uimage=uImage\0" \
+	"console_fsl=ttyAM0\0" \
+	"console_mainline=ttyAMA0\0" \
+	"console=${console_mainline}\0" \
+	"mmcdev=0\0" \
+	"mmcpart=2\0" \
+	"mmcroot=/dev/mmcblk0p3 rw\0" \
+	"mmcrootfstype=ext3 rootwait\0"	\
+	"mmcargs=setenv bootargs console=${console},${baudrate} " \
+		"root=${mmcroot} " \
+		"rootfstype=${mmcrootfstype}\0"	\
+	"loadbootscript="  \
+		"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+	"bootscript=echo Running bootscript from mmc ...; "	\
+		"source\0" \
+	"loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
+	"mmcboot=echo Booting from mmc ...; " \
+		"run mmcargs; "	\
+		"bootm\0" \
+	"netargs=setenv bootargs console=${console},${baudrate} " \
 		"root=/dev/nfs " \
-		"ip=dhcp nfsroot=${serverip}:${nfsroot}\0" \
-	"bootcmd_net=echo Booting from net ...; " \
-		"run netargs; " \
-		"dhcp ${uimage}; bootm\0" \
+		"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
+	"netboot=echo Booting from net ...; " \
+		"run netargs; "	\
+		"dhcp ${uimage}; bootm\0"
+
+#define CONFIG_BOOTCOMMAND \
+	"if mmc rescan ${mmcdev}; then " \
+		"if run loadbootscript; then " \
+			"run bootscript; " \
+		"else " \
+			"if run loaduimage; then " \
+				"run mmcboot; " \
+			"else run netboot; " \
+			"fi; " \
+		"fi; " \
+	"else run netboot; fi"
 
 #endif /* __MX28EVK_CONFIG_H__ */
-- 
1.7.10

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Otavio Salvador]

On Tue, May 15, 2012 at 6:21 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
>> I tried something in this direction but Wolfgang NACKed the patch. It
>> wasn't clear to me what he wants so I preferred to go again with
>> mx28evk patch only.
>
> Well ... it might have been a good idea to discuss it with WD. I think we
> discussed some time ago that universal default env would be very cool.

I can work on that as far as I know what people expect to have. In
meanwhile I'd prefer to have this in since it allow the default
environment to just work in our BSP layer for OpenEmbedded.

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Marek Vasut]

Dear Otavio Salvador,

> On Tue, May 15, 2012 at 6:16 PM, Marek Vasut <marex@denx.de> wrote:
> > But I like this patch. On the other hand, can't this be made even more
> > generic so everyone can use such a nice unified env?
> 
> I tried something in this direction but Wolfgang NACKed the patch. It
> wasn't clear to me what he wants so I preferred to go again with
> mx28evk patch only.

Well ... it might have been a good idea to discuss it with WD. I think we 
discussed some time ago that universal default env would be very cool.

Best regards,
Marek Vasut

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Otavio Salvador]

On Tue, May 15, 2012 at 6:08 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, May 15, 2012 at 5:59 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>
>> + ? ? ? "loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
>> + ? ? ? "mmcboot=echo Booting from mmc ...; " \
>> + ? ? ? ? ? ? ? "run mmcargs; " \
>> + ? ? ? ? ? ? ? "bootm\0" \
>> + ? ? ? "netargs=setenv bootargs console=ttymxc0,${baudrate} " \
>
> No, ttymxc0 is wrong for mx28. You should use console=${console}.

My fault; when I redone it I forgot to fix it once again.

-- 
Otavio Salvador? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O.S. Systems
E-mail: otavio at ossystems.com.br? http://www.ossystems.com.br
Mobile: +55 53 9981-7854? ? ? ?? ? ? ?http://projetos.ossystems.com.br

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Marek Vasut]

Dear Otavio Salvador,

> The environment has been based on mx53loco and m28evk but keeping the
> possibility to easy change the default console device as Freescale and
> mainline kernels differ on the device name.

FSL kernel is dumb :-(

But I like this patch. On the other hand, can't this be made even more generic 
so everyone can use such a nice unified env?

> 
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>  include/configs/mx28evk.h |   83
> ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 75
> insertions(+), 8 deletions(-)
> 
> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
> index e98a746..6c2bf5f 100644
> --- a/include/configs/mx28evk.h
> +++ b/include/configs/mx28evk.h
> @@ -234,7 +234,6 @@
>  #define CONFIG_SETUP_MEMORY_TAGS
>  #define CONFIG_BOOTDELAY	3
>  #define CONFIG_BOOTFILE	"uImage"
> -#define CONFIG_BOOTCOMMAND	"run bootcmd_net"
>  #define CONFIG_LOADADDR	0x42000000
>  #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
>  #define CONFIG_OF_LIBFDT
> @@ -243,13 +242,81 @@
>   * Extra Environments
>   */
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> -	"console_fsl=console=ttyAM0" \
> -	"console_mainline=console=ttyAMA0" \
> -	"netargs=setenv bootargs console=${console_mainline}" \
> +	"update_nand_full_filename=u-boot.nand\0" \
> +	"update_nand_firmware_filename=u-boot.sb\0"	\
> +	"update_sd_firmware_filename=u-boot.sd\0" \
> +	"update_nand_firmware_maxsz=0x100000\0"	\
> +	"update_nand_stride=0x40\0"	/* MX28 datasheet ch. 12.12 */ \
> +	"update_nand_count=0x4\0"	/* MX28 datasheet ch. 12.12 */ \
> +	"update_nand_get_fcb_size="	/* Get size of FCB blocks */ \
> +		"nand device 0 ; " \
> +		"nand info ; " \
> +		"setexpr fcb_sz ${update_nand_stride} * ${update_nand_count};" \
> +		"setexpr update_nand_fcb ${fcb_sz} * ${nand_writesize}\0" \
> +	"update_nand_full="		    /* Update FCB, DBBT and FW */ \
> +		"if tftp ${update_nand_full_filename} ; then " \
> +		"run update_nand_get_fcb_size ; " \
> +		"nand scrub -y 0x0 ${filesize} ; " \
> +		"nand write.raw ${loadaddr} 0x0 ${update_nand_fcb} ; " \
> +		"setexpr update_off ${loadaddr} + ${update_nand_fcb} ; " \
> +		"setexpr update_sz ${filesize} - ${update_nand_fcb} ; " \
> +		"nand write ${update_off} ${update_nand_fcb} ${update_sz} ; " \
> +		"fi\0" \
> +	"update_nand_firmware="		/* Update only firmware */ \
> +		"if tftp ${update_nand_firmware_filename} ; then " \
> +		"run update_nand_get_fcb_size ; " \
> +		"setexpr fcb_sz ${update_nand_fcb} * 2 ; " /* FCB + DBBT */ \
> +		"setexpr fw_sz ${update_nand_firmware_maxsz} * 2 ; " \
> +		"setexpr fw_off ${fcb_sz} + ${update_nand_firmware_maxsz};" \
> +		"nand erase ${fcb_sz} ${fw_sz} ; " \
> +		"nand write ${loadaddr} ${fcb_sz} ${filesize} ; " \
> +		"nand write ${loadaddr} ${fw_off} ${filesize} ; " \
> +		"fi\0" \
> +	"update_sd_firmware="		/* Update the SD firmware partition */ \
> +		"if mmc rescan ; then "	\
> +		"if tftp ${update_sd_firmware_filename} ; then " \
> +		"setexpr fw_sz ${filesize} / 0x200 ; "	/* SD block size */ \
> +		"setexpr fw_sz ${fw_sz} + 1 ; "	\
> +		"mmc write ${loadaddr} 0x800 ${fw_sz} ; " \
> +		"fi ; "	\
> +		"fi\0" \
> +	"script=boot.scr\0"	\
> +	"uimage=uImage\0" \
> +	"console_fsl=ttyAM0\0" \
> +	"console_mainline=ttyAMA0\0" \
> +	"console=${console_mainline}\0" \
> +	"mmcdev=0\0" \
> +	"mmcpart=2\0" \
> +	"mmcroot=/dev/mmcblk0p3 rw\0" \
> +	"mmcrootfstype=ext3 rootwait\0"	\
> +	"mmcargs=setenv bootargs console=${console},${baudrate} " \
> +		"root=${mmcroot} " \
> +		"rootfstype=${mmcrootfstype}\0"	\
> +	"loadbootscript="  \
> +		"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
> +	"bootscript=echo Running bootscript from mmc ...; "	\
> +		"source\0" \
> +	"loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
> +	"mmcboot=echo Booting from mmc ...; " \
> +		"run mmcargs; "	\
> +		"bootm\0" \
> +	"netargs=setenv bootargs console=ttymxc0,${baudrate} " \
>  		"root=/dev/nfs " \
> -		"ip=dhcp nfsroot=${serverip}:${nfsroot}\0" \
> -	"bootcmd_net=echo Booting from net ...; " \
> -		"run netargs; " \
> -		"dhcp ${uimage}; bootm\0" \
> +		"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
> +	"netboot=echo Booting from net ...; " \
> +		"run netargs; "	\
> +		"dhcp ${uimage}; bootm\0"
> +
> +#define CONFIG_BOOTCOMMAND \
> +	"if mmc rescan ${mmcdev}; then " \
> +		"if run loadbootscript; then " \
> +			"run bootscript; " \
> +		"else " \
> +			"if run loaduimage; then " \
> +				"run mmcboot; " \
> +			"else run netboot; " \
> +			"fi; " \
> +		"fi; " \
> +	"else run netboot; fi"
> 
>  #endif /* __MX28EVK_CONFIG_H__ */

Best regards,
Marek Vasut

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Fabio Estevam]

On Tue, May 15, 2012 at 5:59 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:

> + ? ? ? "loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
> + ? ? ? "mmcboot=echo Booting from mmc ...; " \
> + ? ? ? ? ? ? ? "run mmcargs; " \
> + ? ? ? ? ? ? ? "bootm\0" \
> + ? ? ? "netargs=setenv bootargs console=ttymxc0,${baudrate} " \

No, ttymxc0 is wrong for mx28. You should use console=${console}.

[U-Boot] [PATCH 3/3] mx28evk: extend default environment

[Otavio Salvador]

The environment has been based on mx53loco and m28evk but keeping the
possibility to easy change the default console device as Freescale and
mainline kernels differ on the device name.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
---
 include/configs/mx28evk.h |   83 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 75 insertions(+), 8 deletions(-)

diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index e98a746..6c2bf5f 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -234,7 +234,6 @@
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_BOOTDELAY	3
 #define CONFIG_BOOTFILE	"uImage"
-#define CONFIG_BOOTCOMMAND	"run bootcmd_net"
 #define CONFIG_LOADADDR	0x42000000
 #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
 #define CONFIG_OF_LIBFDT
@@ -243,13 +242,81 @@
  * Extra Environments
  */
 #define CONFIG_EXTRA_ENV_SETTINGS \
-	"console_fsl=console=ttyAM0" \
-	"console_mainline=console=ttyAMA0" \
-	"netargs=setenv bootargs console=${console_mainline}" \
+	"update_nand_full_filename=u-boot.nand\0" \
+	"update_nand_firmware_filename=u-boot.sb\0"	\
+	"update_sd_firmware_filename=u-boot.sd\0" \
+	"update_nand_firmware_maxsz=0x100000\0"	\
+	"update_nand_stride=0x40\0"	/* MX28 datasheet ch. 12.12 */ \
+	"update_nand_count=0x4\0"	/* MX28 datasheet ch. 12.12 */ \
+	"update_nand_get_fcb_size="	/* Get size of FCB blocks */ \
+		"nand device 0 ; " \
+		"nand info ; " \
+		"setexpr fcb_sz ${update_nand_stride} * ${update_nand_count};" \
+		"setexpr update_nand_fcb ${fcb_sz} * ${nand_writesize}\0" \
+	"update_nand_full="		    /* Update FCB, DBBT and FW */ \
+		"if tftp ${update_nand_full_filename} ; then " \
+		"run update_nand_get_fcb_size ; " \
+		"nand scrub -y 0x0 ${filesize} ; " \
+		"nand write.raw ${loadaddr} 0x0 ${update_nand_fcb} ; " \
+		"setexpr update_off ${loadaddr} + ${update_nand_fcb} ; " \
+		"setexpr update_sz ${filesize} - ${update_nand_fcb} ; " \
+		"nand write ${update_off} ${update_nand_fcb} ${update_sz} ; " \
+		"fi\0" \
+	"update_nand_firmware="		/* Update only firmware */ \
+		"if tftp ${update_nand_firmware_filename} ; then " \
+		"run update_nand_get_fcb_size ; " \
+		"setexpr fcb_sz ${update_nand_fcb} * 2 ; " /* FCB + DBBT */ \
+		"setexpr fw_sz ${update_nand_firmware_maxsz} * 2 ; " \
+		"setexpr fw_off ${fcb_sz} + ${update_nand_firmware_maxsz};" \
+		"nand erase ${fcb_sz} ${fw_sz} ; " \
+		"nand write ${loadaddr} ${fcb_sz} ${filesize} ; " \
+		"nand write ${loadaddr} ${fw_off} ${filesize} ; " \
+		"fi\0" \
+	"update_sd_firmware="		/* Update the SD firmware partition */ \
+		"if mmc rescan ; then "	\
+		"if tftp ${update_sd_firmware_filename} ; then " \
+		"setexpr fw_sz ${filesize} / 0x200 ; "	/* SD block size */ \
+		"setexpr fw_sz ${fw_sz} + 1 ; "	\
+		"mmc write ${loadaddr} 0x800 ${fw_sz} ; " \
+		"fi ; "	\
+		"fi\0" \
+	"script=boot.scr\0"	\
+	"uimage=uImage\0" \
+	"console_fsl=ttyAM0\0" \
+	"console_mainline=ttyAMA0\0" \
+	"console=${console_mainline}\0" \
+	"mmcdev=0\0" \
+	"mmcpart=2\0" \
+	"mmcroot=/dev/mmcblk0p3 rw\0" \
+	"mmcrootfstype=ext3 rootwait\0"	\
+	"mmcargs=setenv bootargs console=${console},${baudrate} " \
+		"root=${mmcroot} " \
+		"rootfstype=${mmcrootfstype}\0"	\
+	"loadbootscript="  \
+		"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+	"bootscript=echo Running bootscript from mmc ...; "	\
+		"source\0" \
+	"loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
+	"mmcboot=echo Booting from mmc ...; " \
+		"run mmcargs; "	\
+		"bootm\0" \
+	"netargs=setenv bootargs console=ttymxc0,${baudrate} " \
 		"root=/dev/nfs " \
-		"ip=dhcp nfsroot=${serverip}:${nfsroot}\0" \
-	"bootcmd_net=echo Booting from net ...; " \
-		"run netargs; " \
-		"dhcp ${uimage}; bootm\0" \
+		"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
+	"netboot=echo Booting from net ...; " \
+		"run netargs; "	\
+		"dhcp ${uimage}; bootm\0"
+
+#define CONFIG_BOOTCOMMAND \
+	"if mmc rescan ${mmcdev}; then " \
+		"if run loadbootscript; then " \
+			"run bootscript; " \
+		"else " \
+			"if run loaduimage; then " \
+				"run mmcboot; " \
+			"else run netboot; " \
+			"fi; " \
+		"fi; " \
+	"else run netboot; fi"
 
 #endif /* __MX28EVK_CONFIG_H__ */
-- 
1.7.10