[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Marek Vasut]

These targets allow for easy invocation of mxstool, for generating
the u-boot images bootable in mx28 CPU.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
CC: Albert Aribaud <albert.u.boot@aribaud.net>
---
 Makefile               |    6 ++++++
 doc/README.mx28_common |   39 +++++++++++++++++++++++----------------
 2 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/Makefile b/Makefile
index bd37c7a..cafe12d 100644
--- a/Makefile
+++ b/Makefile
@@ -453,6 +453,12 @@ $(obj)u-boot.sb:       $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin
 		elftosb -zdf imx28 -c $(TOPDIR)/board/$(BOARDDIR)/u-boot.bd \
 			-o $(obj)u-boot.sb
 
+$(obj)u-boot.mx28.sd:  $(obj)u-boot.sb
+		$(obj)tools/mxsboot sd $(obj)u-boot.sb $(obj)u-boot.mx28.sd
+
+$(obj)u-boot.mx28.nand: $(obj)u-boot.sb
+		$(obj)tools/mxsboot nand $(obj)u-boot.sb $(obj)u-boot.mx28.nand
+
 ifeq ($(CONFIG_SANDBOX),y)
 GEN_UBOOT = \
 		cd $(LNDIR) && $(CC) $(SYMS) -T $(obj)u-boot.lds \
diff --git a/doc/README.mx28_common b/doc/README.mx28_common
index 448d221..cad3029 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mx28_common
@@ -83,8 +83,10 @@ Examples:
 	$ make mx28evk_config
 
 Lastly, compile U-Boot and prepare a "BootStream". The "BootStream" is a special
-type of file, which the i.MX28 CPU can boot. This is handled by the following
-command:
+type of file, which the i.MX28 CPU can boot. Having this file is useful for
+updating U-Boot on an already running system. In case you need an SD card image
+or NAND image, you can skip this step, since this file will be generated in the
+process anyway. Generation of "BootStream" is handled by the following command:
 
 	$ make u-boot.sb
 
@@ -102,7 +104,6 @@ To boot a MX28 based board from SD, set the boot mode DIP switches according
 to i.MX28 manual chapter 12.2.1 (Table 12-2), PORT=SSP0, SD/MMC master on
 SSP0, 3.3V.
 
-
 An SD card the i.MX28 CPU can use to boot U-Boot must contain a DOS partition
 table, which in turn carries a partition of special type and which contains a
 special header. The rest of partitions in the DOS partition table can be used
@@ -133,18 +134,21 @@ The partition layout is ready, next the special partition must be filled with
 proper contents. The contents is generated by running the following command
 (see chapter 2)):
 
-	$ ./tools/mxsboot sd u-boot.sb u-boot.sd
+	$ make u-boot.mx28.sd
 
-The resulting file, "u-boot.sd", shall then be written to the partition. In this
-case, we assume the first partition of the SD card is /dev/mmcblk0p1:
+The resulting file, "u-boot.mx28.sd", shall then be written to the partition. In
+this case, we assume the first partition of the SD card is /dev/mmcblk0p1:
 
-	$ dd if=u-boot.sd of=/dev/mmcblk0p1
+	$ dd if=u-boot.mx28.sd of=/dev/mmcblk0p1
 
 Last step is to insert the card into MX28 based board and boot.
 
 NOTE: If the user needs to adjust the start sector, the "mxsboot" tool contains
       a "-p" switch for that purpose. The "-p" switch takes the sector number as
-      an argument.
+      an argument. The invocation of the "mxsboot" tool for SD boot is like the
+      following:
+
+	$ ./tools/mxsboot sd u-boot.sb u-boot.mx28.sd
 
 4) Installation of U-Boot for NAND flash
 -----------------------------------------------
@@ -158,10 +162,9 @@ There are two possibilities when preparing an image writable to NAND flash.
 	----------------------------------------------------------
 	   In this case, both BCB (FCB and DBBT) and firmware needs to be
 	   written to NAND. To generate NAND image containing all these,
-	   there is a tool called "mxsboot" in the "tools/" directory. The tool
-	   is invoked on "u-boot.sb" file from chapter 2):
+	   run the following command:
 
-		 $ ./tools/mxsboot nand u-boot.sb u-boot.nand
+		 $ make u-boot.mx28.nand
 
 	   NOTE: The above invokation works for NAND flash with geometry of
 		 2048b per page, 64b OOB data, 128kb erase size. If your chip
@@ -172,14 +175,18 @@ There are two possibilities when preparing an image writable to NAND flash.
 		 -e <size>	change erase size (default 131072 b)
 
 		 The geometry information can be obtained from running U-Boot
-		 on the MX28 board by issuing the "nand info" command.
+		 on the MX28 board by issuing the "nand info" command. The
+		 invocation of custom "mxsboot" call is then as follows:
+
+		   $ ./tools/mxsboot nand u-boot.sb u-boot.mx28.nand
 
-	   The resulting file, "u-boot.nand" can be written directly to NAND
-	   from the U-Boot prompt. To simplify the process, the U-Boot default
-	   environment contains script "update_nand_full" to update the system.
+	   The resulting file, "u-boot.mx28,nand" can be written directly to
+	   NAND from the U-Boot prompt. To simplify the process, the U-Boot
+	   default environment contains script "update_nand_full" to update
+	   the system.
 
 	   This script expects a working TFTP server containing the file
-	   "u-boot.nand" in it's root directory. This can be changed by
+	   "u-boot.mx28.nand" in it's root directory. This can be changed by
 	   adjusting the "update_nand_full_filename" varible.
 
 	   To update the system, run the following in U-Boot prompt:
-- 
1.7.10

[U-Boot] [PATCH 2/3] MX28: Cleanup mxsboot within make mrproper

[Marek Vasut]

Delete the "mxsboot" binary if make mrproper is called.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
CC: Albert Aribaud <albert.u.boot@aribaud.net>
---
 Makefile |    1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index cafe12d..70f9f83 100644
--- a/Makefile
+++ b/Makefile
@@ -737,6 +737,7 @@ clean:
 	       $(obj)tools/gen_eth_addr    $(obj)tools/img2srec		  \
 	       $(obj)tools/mk{env,}image   $(obj)tools/mpc86x_clk	  \
 	       $(obj)tools/mk{smdk5250,}spl				  \
+	       $(obj)tools/mxsboot					  \
 	       $(obj)tools/ncb		   $(obj)tools/ubsha1
 	@rm -f $(obj)board/cray/L1/{bootscript.c,bootscript.image}	  \
 	       $(obj)board/matrix_vision/*/bootscript.img		  \
-- 
1.7.10

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Marek Vasut]

This is a precaution to prevent some USB flash drives
from misbehaving in early boot stage.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
CC: Albert Aribaud <albert.u.boot@aribaud.net>
---
 board/denx/m28evk/m28evk.c   |    3 ---
 board/denx/m28evk/spl_boot.c |   11 +++++++++++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index 3d28ea8..5068071 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -53,9 +53,6 @@ int board_early_init_f(void)
 	mx28_set_sspclk(MXC_SSPCLK2, 96000, 0);
 
 #ifdef	CONFIG_CMD_USB
-	mxs_iomux_setup_pad(MX28_PAD_SSP2_SS1__USB1_OVERCURRENT);
-	mxs_iomux_setup_pad(MX28_PAD_AUART3_TX__GPIO_3_13 |
-			MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_PULLUP);
 	gpio_direction_output(MX28_PAD_AUART3_TX__GPIO_3_13, 0);
 #endif
 
diff --git a/board/denx/m28evk/spl_boot.c b/board/denx/m28evk/spl_boot.c
index 7a12592..6b51332 100644
--- a/board/denx/m28evk/spl_boot.c
+++ b/board/denx/m28evk/spl_boot.c
@@ -214,9 +214,20 @@ const iomux_cfg_t iomux_setup[] = {
 	MX28_PAD_SSP2_MISO__SSP2_D0 | MUX_CONFIG_SSP2,
 	MX28_PAD_SSP2_SS0__SSP2_D3 |
 		(MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP),
+
+	/* USB */
+	MX28_PAD_SSP2_SS1__USB1_OVERCURRENT,
+	MX28_PAD_AUART3_TX__GPIO_3_13 |
+			MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_PULLUP,
 };
 
 void board_init_ll(void)
 {
+	/* Powerdown the USB */
+	mxs_iomux_setup_pad(MX28_PAD_SSP2_SS1__USB1_OVERCURRENT);
+	mxs_iomux_setup_pad(MX28_PAD_AUART3_TX__GPIO_3_13 |
+			MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_PULLUP);
+	gpio_direction_output(MX28_PAD_AUART3_TX__GPIO_3_13, 1);
+
 	mx28_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
 }
-- 
1.7.10

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Wolfgang Denk]

Dear Marek Vasut,

In message <1337729574-30475-1-git-send-email-marex@denx.de> you wrote:
> These targets allow for easy invocation of mxstool, for generating
> the u-boot images bootable in mx28 CPU.

Thanks.

> +$(obj)u-boot.mx28.sd:  $(obj)u-boot.sb
> +		$(obj)tools/mxsboot sd $(obj)u-boot.sb $(obj)u-boot.mx28.sd
> +
> +$(obj)u-boot.mx28.nand: $(obj)u-boot.sb
> +		$(obj)tools/mxsboot nand $(obj)u-boot.sb $(obj)u-boot.mx28.nand

There are rules missing to clean up these new images when make clean /
make distclean is used.

Why do we need this special "mx28" part in the name?   I don't see how
this would be useful, but it hurts as you will have to add a (probably
growing) list uf targets to the remove lists. - what's wrong with just
calling these "u-boot.bin.sd" and "u-boot.bin.nand" ?

Would it not be useful to automatically build these images when
someone runs just "make -j8 -s m28evk" (or "./MAKEALL m28evk") ?


Also, I'm a bit surprised about the restrictive permissions of the
resulting images:

-rw-------   1 wd wd  464320 May 23 11:09 u-boot.mx28.sd
-> umask
0002

This should be fixed (probably in tools/mxsboot0 ?

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
People have one thing in common: they are all different.

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Marek Vasut]

Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <1337729574-30475-1-git-send-email-marex@denx.de> you wrote:
> > These targets allow for easy invocation of mxstool, for generating
> > the u-boot images bootable in mx28 CPU.
> 
> Thanks.
> 
> > +$(obj)u-boot.mx28.sd:  $(obj)u-boot.sb
> > +		$(obj)tools/mxsboot sd $(obj)u-boot.sb $(obj)u-boot.mx28.sd
> > +
> > +$(obj)u-boot.mx28.nand: $(obj)u-boot.sb
> > +		$(obj)tools/mxsboot nand $(obj)u-boot.sb $(obj)u-boot.mx28.nand
> 
> There are rules missing to clean up these new images when make clean /
> make distclean is used.
> 
> Why do we need this special "mx28" part in the name?   I don't see how
> this would be useful, but it hurts as you will have to add a (probably
> growing) list uf targets to the remove lists. - what's wrong with just
> calling these "u-boot.bin.sd" and "u-boot.bin.nand" ?

Because there'd then be no way to tell apart u-boot.bin.sd for another target 
but mx28.

> Would it not be useful to automatically build these images when
> someone runs just "make -j8 -s m28evk" (or "./MAKEALL m28evk") ?

Usually, you just want to update the system. You don't need the full image for 
that in NAND case. You do in SD card. Ok, it might be useful.
> 
> Also, I'm a bit surprised about the restrictive permissions of the
> resulting images:
> 
> -rw-------   1 wd wd  464320 May 23 11:09 u-boot.mx28.sd
> -> umask
> 0002
> 
> This should be fixed (probably in tools/mxsboot0 ?

That's a separate bug, but ok.

> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Marek Vasut]

Dear Wolfgang Denk,

> > Dear Marek Vasut,
> > 
> > In message <1337729574-30475-1-git-send-email-marex@denx.de> you wrote:
> > > These targets allow for easy invocation of mxstool, for generating
> > > the u-boot images bootable in mx28 CPU.
> > 
> > Thanks.
> > 
> > > +$(obj)u-boot.mx28.sd:  $(obj)u-boot.sb
> > > +		$(obj)tools/mxsboot sd $(obj)u-boot.sb $(obj)u-boot.mx28.sd
> > > +
> > > +$(obj)u-boot.mx28.nand: $(obj)u-boot.sb
> > > +		$(obj)tools/mxsboot nand $(obj)u-boot.sb $(obj)u-boot.mx28.nand
> > 
> > There are rules missing to clean up these new images when make clean /
> > make distclean is used.
> > 
> > Why do we need this special "mx28" part in the name?   I don't see how
> > this would be useful, but it hurts as you will have to add a (probably
> > growing) list uf targets to the remove lists. - what's wrong with just
> > calling these "u-boot.bin.sd" and "u-boot.bin.nand" ?
> 
> Because there'd then be no way to tell apart u-boot.bin.sd for another
> target but mx28.

Maybe add some switch statement based on CONFIG_MX28 or another within the 
target?

> 
> > Would it not be useful to automatically build these images when
> > someone runs just "make -j8 -s m28evk" (or "./MAKEALL m28evk") ?
> 
> Usually, you just want to update the system. You don't need the full image
> for that in NAND case. You do in SD card. Ok, it might be useful.
> 
> > Also, I'm a bit surprised about the restrictive permissions of the
> > resulting images:
> > 
> > -rw-------   1 wd wd  464320 May 23 11:09 u-boot.mx28.sd
> > -> umask
> > 0002
> > 
> > This should be fixed (probably in tools/mxsboot0 ?
> 
> That's a separate bug, but ok.
> 
> > Best regards,
> > 
> > Wolfgang Denk
> 
> Best regards,
> Marek Vasut

Best regards,
Marek Vasut

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Wolfgang Denk]

Dear Marek Vasut,

In message <1337729574-30475-3-git-send-email-marex@denx.de> you wrote:
> This is a precaution to prevent some USB flash drives
> from misbehaving in early boot stage.

Tested on M28EVK; sorry, but this commit doesn't change behaviour:
the LED on the stick is still blinking after power-on.

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
"The number  of  Unix  installations  has  grown  to  10,  with  more
expected."    - The Unix Programmer's Manual, 2nd Edition, June, 1972

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Wolfgang Denk]

Dear Marek Vasut,

In message <201205231127.51935.marex@denx.de> you wrote:
> 
> Because there'd then be no way to tell apart u-boot.bin.sd for another target 
> but mx28.

So what?  We also use "u-boot.bin" for all targets.  What's the
difference?

> > Would it not be useful to automatically build these images when
> > someone runs just "make -j8 -s m28evk" (or "./MAKEALL m28evk") ?
> 
> Usually, you just want to update the system. You don't need the full image for 
> that in NAND case. You do in SD card. Ok, it might be useful.

Indeed. I consider it useful, too.

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
The explanation requiring the fewest assumptions is the  most  likely
to be correct.                                    -- William of Occam

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Wolfgang Denk]

Dear Marek Vasut,

In message <201205231144.04272.marex@denx.de> you wrote:
> 
> > Because there'd then be no way to tell apart u-boot.bin.sd for another
> > target but mx28.
> 
> Maybe add some switch statement based on CONFIG_MX28 or another within the 
> target?

I can't parse this sentence - and I don't understand why you think
any specific name would be needed or useful.

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
 The software required `Windows 95 or better', so I installed Linux.

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Marek Vasut]

Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <201205231144.04272.marex@denx.de> you wrote:
> > > Because there'd then be no way to tell apart u-boot.bin.sd for another
> > > target but mx28.
> > 
> > Maybe add some switch statement based on CONFIG_MX28 or another within
> > the target?
> 
> I can't parse this sentence - and I don't understand why you think
> any specific name would be needed or useful.

Well consider some completely different board would want to use the same target 
name -- u-boot.sd -- for the resulting image. How would that be handled?

> 
> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Wolfgang Denk]

Dear Marek Vasut,

In message <201205231334.53948.marex@denx.de> you wrote:
> 
> > > Maybe add some switch statement based on CONFIG_MX28 or another within
> > > the target?
> > 
> > I can't parse this sentence - and I don't understand why you think
> > any specific name would be needed or useful.
> 
> Well consider some completely different board would want to use the same target 
> name -- u-boot.sd -- for the resulting image. How would that be handled?

I fail to understand which problem you see.

All board use the same target name "u-boot.bin" - and everything is
fine.

What would be wrong if all boards would use the same "u-boot.bin.sdcard"
target name?

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
Heavier than air flying machines are impossible.
                    -- Lord Kelvin, President, Royal Society, c. 1895

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Marek Vasut]

Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <1337729574-30475-3-git-send-email-marex@denx.de> you wrote:
> > This is a precaution to prevent some USB flash drives
> > from misbehaving in early boot stage.
> 
> Tested on M28EVK; sorry, but this commit doesn't change behaviour:
> the LED on the stick is still blinking after power-on.

Dang, this must be related to bootrom somehow then. Fabio, can you confirm the 
following:

If you turn off the mx28 board, connect usb flashdisc, turn it on -- do you see 
the flashdisc led blinking? Any idea what might cause it? This patch forced the 
VBUS off, so very early in uboot, the USB flash has no way to blink (unless 
there's some surge).

> 
> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Marek Vasut]

Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <201205231334.53948.marex@denx.de> you wrote:
> > > > Maybe add some switch statement based on CONFIG_MX28 or another
> > > > within the target?
> > > 
> > > I can't parse this sentence - and I don't understand why you think
> > > any specific name would be needed or useful.
> > 
> > Well consider some completely different board would want to use the same
> > target name -- u-boot.sd -- for the resulting image. How would that be
> > handled?
> 
> I fail to understand which problem you see.
> 
> All board use the same target name "u-boot.bin" - and everything is
> fine.
> 
> What would be wrong if all boards would use the same "u-boot.bin.sdcard"
> target name?

That such file (u-boot.bin.sdcard) would be generated by a different tool for 
each different board, unlike u-boot.bin . Maybe I'm just flat missing something 
here.

> 
> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Fabio Estevam]

On Wed, May 23, 2012 at 8:53 AM, Marek Vasut <marex@denx.de> wrote:

> Dang, this must be related to bootrom somehow then. Fabio, can you confirm the
> following:
>
> If you turn off the mx28 board, connect usb flashdisc, turn it on -- do you see
> the flashdisc led blinking? Any idea what might cause it? This patch forced the
> VBUS off, so very early in uboot, the USB flash has no way to blink (unless
> there's some surge).

I have just tried it on my mx28evk and I don't see the USB thumb LED to turn on.

Only if I do a "usb reset" that it turns on. Doing a "usb stop" turns
it off as expected.

I would suggest you to compare your USB circuitry  against mx28evk schematics.

Regards,

Fabio Estevam

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Fabio Estevam]

On Tue, May 22, 2012 at 8:32 PM, Marek Vasut <marex@denx.de> wrote:

> ?void board_init_ll(void)
> ?{
> + ? ? ? /* Powerdown the USB */
> + ? ? ? mxs_iomux_setup_pad(MX28_PAD_SSP2_SS1__USB1_OVERCURRENT);
> + ? ? ? mxs_iomux_setup_pad(MX28_PAD_AUART3_TX__GPIO_3_13 |
> + ? ? ? ? ? ? ? ? ? ? ? MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_PULLUP);
> + ? ? ? gpio_direction_output(MX28_PAD_AUART3_TX__GPIO_3_13, 1);

I don't have access to the m28evk schematics, but please double check
if you really need to set this pin to '1' to powerdown the USB, or if
this should be a '0' instead.

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Marek Vasut]

Dear Fabio Estevam,

> On Tue, May 22, 2012 at 8:32 PM, Marek Vasut <marex@denx.de> wrote:
> >  void board_init_ll(void)
> >  {
> > +       /* Powerdown the USB */
> > +       mxs_iomux_setup_pad(MX28_PAD_SSP2_SS1__USB1_OVERCURRENT);
> > +       mxs_iomux_setup_pad(MX28_PAD_AUART3_TX__GPIO_3_13 |
> > +                       MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_PULLUP);
> > +       gpio_direction_output(MX28_PAD_AUART3_TX__GPIO_3_13, 1);
> 
> I don't have access to the m28evk schematics, but please double check
> if you really need to set this pin to '1' to powerdown the USB, or if
> this should be a '0' instead.

This is correct, it should be inverted.

Best regards,
Marek Vasut

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Marek Vasut]

Dear Fabio Estevam,

> On Wed, May 23, 2012 at 8:53 AM, Marek Vasut <marex@denx.de> wrote:
> > Dang, this must be related to bootrom somehow then. Fabio, can you
> > confirm the following:
> > 
> > If you turn off the mx28 board, connect usb flashdisc, turn it on -- do
> > you see the flashdisc led blinking? Any idea what might cause it? This
> > patch forced the VBUS off, so very early in uboot, the USB flash has no
> > way to blink (unless there's some surge).
> 
> I have just tried it on my mx28evk and I don't see the USB thumb LED to
> turn on.
> 
> Only if I do a "usb reset" that it turns on. Doing a "usb stop" turns
> it off as expected.
> 
> I would suggest you to compare your USB circuitry  against mx28evk
> schematics.

Well, what can it be caused by? I disabled the VBUS, so how come it can still be 
on. The usb circuitry maybe then?

> Regards,
> 
> Fabio Estevam

Best regards,
Marek Vasut

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Fabio Estevam]

On Wed, May 23, 2012 at 10:08 AM, Marek Vasut <marex@denx.de> wrote:

> Well, what can it be caused by? I disabled the VBUS, so how come it can still be
> on. The usb circuitry maybe then?

I cannot comment on that, as I never looked at the m28evk schematics.

Please use a mx28evk for comparison.

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Fabio Estevam]

On Wed, May 23, 2012 at 10:07 AM, Marek Vasut <marex@denx.de> wrote:

> This is correct, it should be inverted.

So where in your code you powerup the USB?

There should be a:

gpio_direction_output(MX28_PAD_AUART3_TX__GPIO_3_13, 0);

,somewhere in order to power your USB on then.

[U-Boot] [PATCH 3/3] M28: Disable USB power on boot

[Marek Vasut]

Dear Fabio Estevam,

> On Wed, May 23, 2012 at 10:07 AM, Marek Vasut <marex@denx.de> wrote:
> > This is correct, it should be inverted.
> 
> So where in your code you powerup the USB?
> 
> There should be a:
> 
> gpio_direction_output(MX28_PAD_AUART3_TX__GPIO_3_13, 0);
> 
> ,somewhere in order to power your USB on then.

Sure, board/denx/m28evk/m28evk.c, in board_early_init_f() call. Hm, might as 
well move it to board_init_f() too, but that has no relevance.

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Wolfgang Denk]

Dear Marek Vasut,

In message <201205231422.17293.marex@denx.de> you wrote:
> 
> > What would be wrong if all boards would use the same "u-boot.bin.sdcard"
> > target name?
> 
> That such file (u-boot.bin.sdcard) would be generated by a different tool for 
> each different board, unlike u-boot.bin . Maybe I'm just flat missing something 
> here.

Who cares which tool is building the image?  or why would this matter?

All we need to know is that "u-boot.bin.sdcard" is an image that can
be installed on a SDCard to be booted from.

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
HR Manager to job candidate "I see you've had no  computer  training.
Although  that  qualifies  you  for upper management, it means you're
under-qualified for our entry level positions."

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Marek Vasut]

Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <201205231422.17293.marex@denx.de> you wrote:
> > > What would be wrong if all boards would use the same
> > > "u-boot.bin.sdcard" target name?
> > 
> > That such file (u-boot.bin.sdcard) would be generated by a different tool
> > for each different board, unlike u-boot.bin . Maybe I'm just flat
> > missing something here.
> 
> Who cares which tool is building the image?  or why would this matter?

I think we're missing each others point. So, lemme put it this way:

We have CPU X, which uses sequence of commands, sequence A.
We have CPU Y, which uses sequence of commands, sequence B.

We want make target M, which results in file named F.

How do we make sure the target M will result in file F produced by sequence A if 
u-boot is configured for CPU X && file F produced by sequence B if u-boot is 
configured for CPU Y ?

I think I might have already answered myself ... u-boot is configured for CPU 
X/CPU Y, right?

> All we need to know is that "u-boot.bin.sdcard" is an image that can
> be installed on a SDCard to be booted from.
> 
> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets

[Wolfgang Denk]

Dear Marek Vasut,

In message <201206221444.46242.marex@denx.de> you wrote:
> 
> I think we're missing each others point. So, lemme put it this way:
> 
> We have CPU X, which uses sequence of commands, sequence A.
> We have CPU Y, which uses sequence of commands, sequence B.
> 
> We want make target M, which results in file named F.
> 
> How do we make sure the target M will result in file F produced by sequence A if 
> u-boot is configured for CPU X && file F produced by sequence B if u-boot is 
> configured for CPU Y ?

By cding the neeeded rules depending on what may be needed for one SoC
or another.

> I think I might have already answered myself ... u-boot is configured for CPU 
> X/CPU Y, right?

Right.  Such CPU (or ARCH) specific code should be placed in the
respective CPU (or ARCH) specific Makefile, and everything will just
work as expected.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"In Christianity neither morality nor religion come into contact with
reality at any point."                          - Friedrich Nietzsche