[U-Boot] [PATCH][repost] bin_dep.sh Support
From: prafulla_wadaskar prafulla@marvell.com
In some cases the u-boot.bin need to be processed further to create bootable u-boot binary from boot device This processing may be cpu,soc and/or board spcific bin_dep.sh provides a mechanism to execute bin_dep.sh if present in above platform specific folders
Signed-off-by: prafulla_wadaskar prafulla@marvell.com --- Makefile | 2 + tools/bin_dep.sh | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 81 insertions(+), 0 deletions(-) create mode 100755 tools/bin_dep.sh
diff --git a/Makefile b/Makefile index f857641..8bf36ce 100644 --- a/Makefile +++ b/Makefile @@ -318,6 +318,7 @@ $(obj)u-boot.srec: $(obj)u-boot
$(obj)u-boot.bin: $(obj)u-boot $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@ + @./tools/bin_dep.sh $(CPU) $(BOARD) $(VENDOR) $(SOC) $@
$(obj)u-boot.ldr: $(obj)u-boot $(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS) @@ -3506,6 +3507,7 @@ clean: $(obj)tools/gen_eth_addr $(obj)tools/img2srec \ $(obj)tools/mkimage $(obj)tools/mpc86x_clk \ $(obj)tools/ncb $(obj)tools/ubsha1 + @./tools/bin_dep.sh $(CPU) $(BOARD) $(VENDOR) $(SOC) $@ @rm -f $(obj)board/cray/L1/{bootscript.c,bootscript.image} \ $(obj)board/netstar/{eeprom,crcek,crcit,*.srec,*.bin} \ $(obj)board/trab/trab_fkt $(obj)board/voiceblue/eeprom \ diff --git a/tools/bin_dep.sh b/tools/bin_dep.sh new file mode 100755 index 0000000..b32e2ab --- /dev/null +++ b/tools/bin_dep.sh @@ -0,0 +1,79 @@ +#!/bin/sh + +# (C) Copyright 2009 +# Marvell Semiconductor <www.marvell.com> +# Written-by: Prafulla Wadaskar prafulla@marvell.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +# Some platform may require additional post processing of u-boot.bin +# to create usefull binaries +# This script will be executed after each make u-boot.bin and make clean operation + +CUR_DIR=`pwd` +CPU_DIR=$CUR_DIR/cpu/$1 +SOC_DIR=$CPU_DIR/$4 +BOARD_DIR=$CUR_DIR/board/$2 +VENDOR_DIR=$CUR_DIR/board/$3 +VENDOR_BOARD_DIR=$CUR_DIR/board/$3/$2 +DEFAULT_ARG=$5 +#default argument will be <binary name> to be processed in case of build +#default argument will be "clean" in case of mrproper/distclean operation +BIN_ARGS=$DEFAULT_ARG + +#echo CPU_DIR $CPU_DIR +#echo SOC_DIR $SOC_DIR +#echo BOARD_DIR $BOARD_DIR +#echo VENDOR_DIR $VENDOR_DIR +#echo VENDOR_BOARD_DIR $VENDOR_BOARD_DIR +#echo BIN_ARGS $BIN_ARGS + +if [ -d $CPU_DIR ]; then + if [ -f $CPU_DIR/bin_dep.sh ]; then + $CPU_DIR/bin_dep.sh $BIN_ARGS $CPU_DIR + else + if [ -d $SOC_DIR ]; then + if [ -f $SOC_DIR/bin_dep.sh ]; then + $SOC_DIR/bin_dep.sh $BIN_ARGS $SOC_DIR + fi + fi + fi +fi + + +if [ -d $BOARD_DIR ]; then + if [ -f $BOARD_DIR/bin_dep.sh ]; then + $BOARD_DIR/bin_dep.sh $BIN_ARGS $BOARD_DIR + fi +else + if [ -d $VENDOR_DIR ]; then + if [ -f $VENDOR_DIR/bin_dep.sh ]; then + $VENDOR_DIR/bin_dep.sh $BIN_ARGS $VENDOR_DIR + else + if [ -d $VENDOR_BOARD_DIR ]; then + if [ -f $VENDOR_BOARD_DIR/bin_dep.sh ]; then + $VENDOR_BOARD_DIR/bin_dep.sh $BIN_ARGS $VENDOR_BOARD_DIR + fi + fi + fi + fi +fi + +
Dear Prafulla Wadaskar,
In message 1247498802-12488-1-git-send-email-prafulla@marvell.com you wrote:
From: prafulla_wadaskar prafulla@marvell.com
In some cases the u-boot.bin need to be processed further to create bootable u-boot binary from boot device This processing may be cpu,soc and/or board spcific bin_dep.sh provides a mechanism to execute bin_dep.sh if present in above platform specific folders
Signed-off-by: prafulla_wadaskar prafulla@marvell.com
Makefile | 2 + tools/bin_dep.sh | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 81 insertions(+), 0 deletions(-) create mode 100755 tools/bin_dep.sh
diff --git a/Makefile b/Makefile index f857641..8bf36ce 100644 --- a/Makefile +++ b/Makefile @@ -318,6 +318,7 @@ $(obj)u-boot.srec: $(obj)u-boot
$(obj)u-boot.bin: $(obj)u-boot $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
@./tools/bin_dep.sh $(CPU) $(BOARD) $(VENDOR) $(SOC) $@
NAK. I reject this patch, and I will continue to reject all attempts to perform additional operations on the u-boot.bin image.
u-boot.bin is by definition the raw binary image of U-Boot. If you use additional tools to post-process this image, then you are creating a new image format, which must have it's own name.
Best regards,
Wolfgang Denk
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Monday, July 13, 2009 4:56 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek Subject: Re: [U-Boot] [PATCH][repost] bin_dep.sh Support
Dear Prafulla Wadaskar,
In message 1247498802-12488-1-git-send-email-prafulla@marvell.com you wrote:
From: prafulla_wadaskar prafulla@marvell.com
In some cases the u-boot.bin need to be processed further to create bootable u-boot binary from boot device This processing may
be cpu,soc
and/or board spcific bin_dep.sh provides a mechanism to execute bin_dep.sh if present in above platform specific folders
Signed-off-by: prafulla_wadaskar prafulla@marvell.com
Makefile | 2 + tools/bin_dep.sh | 79
++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 81 insertions(+), 0 deletions(-) create
mode 100755
tools/bin_dep.sh
diff --git a/Makefile b/Makefile index f857641..8bf36ce 100644 --- a/Makefile +++ b/Makefile @@ -318,6 +318,7 @@ $(obj)u-boot.srec: $(obj)u-boot
$(obj)u-boot.bin: $(obj)u-boot $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
@./tools/bin_dep.sh $(CPU) $(BOARD) $(VENDOR) $(SOC) $@NAK. I reject this patch, and I will continue to reject all attempts to perform additional operations on the u-boot.bin image.
u-boot.bin is by definition the raw binary image of U-Boot. If you use additional tools to post-process this image, then you are creating a new image format, which must have it's own name.g
Then I feel what Jean has suggested is the only way to go ahead with kirkwood use case I will go ahead with this.
Ref:
we can simply add a new target u-boot.kwd which will do somthing like this
$(obj)u-boot.kwd: $(obj)u-boot.bin $(do_image) $(obj)u-boot.kwd $(obj)u-boot.bin $(obj)board/$(BOARDDIR)/sdramregs.txt
Second issue: I will have to add a tool i.e. do_image (to be renamed) which will create u-boot.kwd. this tool is specific to Kirkwood only, I am going to add this in ./tools/ folder (as per Jean's feedback earlier), is this okay?
Regards.. Prafulla . .
Hi Prafulla,
Then I feel what Jean has suggested is the only way to go ahead with kirkwood use case I will go ahead with this.
Ref:
we can simply add a new target u-boot.kwd which will do somthing like this
$(obj)u-boot.kwd: $(obj)u-boot.bin $(do_image) $(obj)u-boot.kwd $(obj)u-boot.bin $(obj)board/$(BOARDDIR)/sdramregs.txt
I think this looks good.
Second issue: I will have to add a tool i.e. do_image (to be renamed) which will create u-boot.kwd. this tool is specific to Kirkwood only, I am going to add this in ./tools/ folder (as per Jean's feedback earlier), is this okay?
The plan as such is ok, although you will probably need to rewrite the latest version of do_image posted to this ML[1] completely. Starting out to read the code, I was tempted to post some specific remarks about the code, but quickly realized that this is not a good attempt to move further here.
The code really needs to be rewritten in a clean fashion using common programming metaphors, style and library functions (i.e. use getopt(3), etc.).
Cheers Detlev
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/57251
-----Original Message----- From: Detlev Zundel [mailto:dzu@denx.de] Sent: Tuesday, July 14, 2009 5:09 PM To: Prafulla Wadaskar Cc: Wolfgang Denk; Manas Saksena; Ronen Shitrit; Nicolas Pitre; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek Subject: Re: [U-Boot] [PATCH][repost] bin_dep.sh Support
Hi Prafulla,
Then I feel what Jean has suggested is the only way to go
ahead with
kirkwood use case I will go ahead with this.
Ref:
we can simply add a new target u-boot.kwd which will do somthing like this
$(obj)u-boot.kwd: $(obj)u-boot.bin $(do_image) $(obj)u-boot.kwd $(obj)u-boot.bin $(obj)board/$(BOARDDIR)/sdramregs.txt
I think this looks good.
Second issue: I will have to add a tool i.e. do_image (to be renamed)
which will create u-boot.kwd.
this tool is specific to Kirkwood only, I am going to add this in ./tools/ folder (as per Jean's feedback earlier), is this okay?
The plan as such is ok, although you will probably need to rewrite the latest version of do_image posted to this ML[1] completely. Starting out to read the code, I was tempted to post some specific remarks about the code, but quickly realized that this is not a good attempt to move further here.
The code really needs to be rewritten in a clean fashion using common programming metaphors, style and library functions (i.e. use getopt(3), etc.).
Dear Detlev Thanks for your feedback Yes I am doing the same code cleanup. I am planning to remove all command line interface and the configuration needed will be provided using CONFIGs. This will make code size smaller and sdramregs.txt a standard c header file. What do you think?
If you have further inputs those are welcomed... :-)
Thanks and regards.. Prafulla . . .
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/57251
-- Of course my password is the same as my pet's name My macaw's name was Q47pY!3 and I change it every 90 days -- Trevor Linton -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Prafulla Wadaskar Sent: Tuesday, July 14, 2009 10:34 PM To: Detlev Zundel Cc: Ronen Shitrit; Nicolas Pitre; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek; Manas Saksena Subject: Re: [U-Boot] [PATCH][repost] bin_dep.sh Support
-----Original Message----- From: Detlev Zundel [mailto:dzu@denx.de] Sent: Tuesday, July 14, 2009 5:09 PM To: Prafulla Wadaskar Cc: Wolfgang Denk; Manas Saksena; Ronen Shitrit; Nicolas Pitre; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek Subject: Re: [U-Boot] [PATCH][repost] bin_dep.sh Support
Hi Prafulla,
Then I feel what Jean has suggested is the only way to go
ahead with
kirkwood use case I will go ahead with this.
Ref:
we can simply add a new target u-boot.kwd which will do somthing like this
$(obj)u-boot.kwd: $(obj)u-boot.bin $(do_image) $(obj)u-boot.kwd $(obj)u-boot.bin $(obj)board/$(BOARDDIR)/sdramregs.txt
I think this looks good.
Second issue: I will have to add a tool i.e. do_image (to be renamed)
which will create u-boot.kwd.
this tool is specific to Kirkwood only, I am going to add this in ./tools/ folder (as per Jean's feedback earlier), is this okay?
The plan as such is ok, although you will probably need to
rewrite the
latest version of do_image posted to this ML[1] completely.
Starting
out to read the code, I was tempted to post some specific remarks about the code, but quickly realized that this is not a
good attempt
to move further here.
The code really needs to be rewritten in a clean fashion
using common
programming metaphors, style and library functions (i.e. use getopt(3), etc.).
Hi Wolfgang During restructuring activity for this utility, I found that most of the code and algorithm is common between mkimage and kwimage (old name doimage). I have studied mkimage code. kwimage requirements can be well supported by adding one more type support to the mkimage (i.e. "bootrom"). The bootrom image file generation generic abstraction can be provided with new file ./common/bootrom.c internally supported by Arch specific macros/code.
With this- 1. mkimage can be reused for kwimage generation. 2. Kwimage generation can be supported in a generic way under "bootrom" image type 3. In future the same interface can be used by other Marvell and non Marvell socs for similar kind of requirements.
Shall I go ahead with this approach? or I should not disturb mkimage at all? What is your opinion?
Regards.. Prafulla . .
Dear Detlev Thanks for your feedback Yes I am doing the same code cleanup. I am planning to remove all command line interface and the configuration needed will be provided using CONFIGs. This will make code size smaller and sdramregs.txt a standard c header file. What do you think?
If you have further inputs those are welcomed... :-)
Thanks and regards.. Prafulla . . .
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/57251
-- Of course my password is the same as my pet's name My
macaw's name was
Q47pY!3 and I change it every 90 days -- Trevor Linton -- DENX Software Engineering GmbH, MD: Wolfgang Denk &
Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194
Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email:
dzu@denx.de
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Prafulla Wadaskar,
In message 73173D32E9439E4ABB5151606C3E19E202DDF26EFD@SC-VEXCH1.marvell.com you wrote:
The code really needs to be rewritten in a clean fashion using common programming metaphors, style and library functions (i.e. use getopt(3), etc.).
During restructuring activity for this utility, I found that most of the code and algorithm is common between mkimage and kwimage (old name doimage).
I'm not really surprised.
I have studied mkimage code. kwimage requirements can be well supported by adding one more type support to the mkimage (i.e. "bootrom").
"bootrom" is a way to generic name. You have a specific data format in mind, so please use a more specific name.
The bootrom image file generation generic abstraction can be provided with new file ./common/bootrom.c internally supported by Arch specific macros/code.
Hm... I guess this would make it even more complicated to separate the mkimage tool from the rest of the U-Boot code. There have been repeated requests to make it more independent or even integrate in into the Linux kernel code tree. We should keep this in mind.
Note that this is not an argument against your proposal - just a note that we should keep this aspect in mind when implementing and reviewing the new code.
With this-
- mkimage can be reused for kwimage generation.
Sounds good to me.
- Kwimage generation can be supported in a generic way under "bootrom" image type
This doesn't sound such a good idea to me. As mentioned above, "bootrom" is a very generic name which can be anything - but if you assign this name to a specific format, it should be exactly _one_ speific format.
- In future the same interface can be used by other Marvell and non Marvell socs for similar kind of requirements.
Shall I go ahead with this approach? or I should not disturb mkimage at all? What is your opinion?
I think this is a pretty good plan. Please go ahead.
Best regards,
Wolfgang Denk
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Thursday, July 16, 2009 4:55 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH][repost] mkimage support ( bin_dep.sh Support)
Dear Prafulla Wadaskar,
In message <73173D32E9439E4ABB5151606C3E19E202DDF26EFD@SC-VEXCH1.marvell. com> you wrote:
The code really needs to be rewritten in a clean fashion using common programming metaphors, style and library functions (i.e. use getopt(3), etc.).
During restructuring activity for this utility, I found
that most of
the code and algorithm is common between mkimage and
kwimage (old name doimage).
I'm not really surprised.
I have studied mkimage code. kwimage requirements can be well supported by adding one
more type support to the mkimage (i.e. "bootrom").
"bootrom" is a way to generic name. You have a specific data format in mind, so please use a more specific name.
Kirkwood Specs call it as "boot image" which is a post processed binary bundled with BootRom header and optional header extension so that Kirkwood's internal bootRom loads it from specific media to DRAM and starts execution. Ref: (Section 24.2.4) http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F618...
So I will name this as "kwbimage" and target will be u-boot.kwb
Further boot image could be different for "boot from SF/NANDF/UART/SATA" etc... This information will be abstracted form board specific config.mk.
The bootrom image file generation generic abstraction can
be provided with new file ./common/bootrom.c internally supported by Arch specific macros/code.
Hm... I guess this would make it even more complicated to separate the mkimage tool from the rest of the U-Boot code. There have been repeated requests to make it more independent or even integrate in into the Linux kernel code tree. We should keep this in mind.
So I will limit my self not to disturb current mkimage architecture. I will add additional kwbimage type support the related code will be abstracted to ./tools/kwbimage.c
Note that this is not an argument against your proposal - just a note that we should keep this aspect in mind when implementing and reviewing the new code.
Thanks...If this find useful for others we can think of expanding it latter. For ex. Type = <SOC>bimage and abstraction in <SOC>bimage.c/h
With this-
- mkimage can be reused for kwimage generation.
Sounds good to me.
- Kwimage generation can be supported in a generic way under
"bootrom" image type
This doesn't sound such a good idea to me. As mentioned above, "bootrom" is a very generic name which can be anything - but if you assign this name to a specific format, it should be exactly _one_ speific format.
Cool. In sync... Type renamed "kwbimage", abstraction in ./tools/kwbimage.c/h
- In future the same interface can be used by other
Marvell and non Marvell socs for similar kind of requirements.
Shall I go ahead with this approach? or I should not disturb mkimage at all? What is your opinion?
I think this is a pretty good plan. Please go ahead.
Thanks a lot.... :-D
Regards.. Prafulla . .
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@denx.de After a heated argument on some trivial matter Nancy [Astor] . . . shouted, ``If I were your wife I would put poison in your coffee!'' Whereupon Winston Churchill with equal heat and sincerity answered, ``And if I were your husband I would drink it.''
participants (3)
-
Detlev Zundel -
Prafulla Wadaskar -
Wolfgang Denk