[U-Boot] [PATCH 1/3] MX28: Add u-boot.mx28.sd and u-boot.mx28.nand make targets
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:
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 \
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)); }
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
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
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
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
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.
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.
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
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.
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
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
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.nandThere 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
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.nandThere 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
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
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
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
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
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
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
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
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
participants (3)
-
Fabio Estevam -
Marek Vasut -
Wolfgang Denk