| Message ID | 1337729574-30475-1-git-send-email-marex@denx.de |
|---|---|
| State | Superseded |
| Delegated to: | Stefano Babic |
| Headers | show |
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.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
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
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
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
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:
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(-)