| Message ID | 505A6580.2050102@inov.pt |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/19/12 17:38, José Miguel Gonçalves wrote: > Tom & Scott, > > On 09/20/2012 12:40 AM, Tom Rini wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 09/19/12 16:36, Scott Wood wrote: >>> On 09/19/2012 06:31:29 PM, Tom Rini wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 09/19/12 15:39, Scott Wood wrote: >>>>> On 09/19/2012 06:25:26 AM, José Miguel Gonçalves wrote: >>>>>> Samsung's S3C24XX SoCs need this in order to generate a >>>>>> binary image with a padded SPL concatenated with U-Boot. >>>>>> >>>>>> Signed-off-by: José Miguel Gonçalves >>>>>> <jose.goncalves@inov.pt> --- Changes for v2: - None >>>>>> >>>>>> Changes for v3: - Changed new binary target name from >>>>>> u-boot-ubl.bin to u-boot-pad.bin >>>>>> >>>>>> Changes for v4: - None --- Makefile | 11 ++++++----- 1 >>>>>> file changed, 6 insertions(+), 5 deletions(-) >>>>>> >>>>>> diff --git a/Makefile b/Makefile index 8738d55..86dedca >>>>>> 100644 --- a/Makefile +++ b/Makefile @@ -433,14 +433,15 >>>>>> @@ $(obj)u-boot.sha1: $(obj)u-boot.bin >>>>>> $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@ >>>>>> >>>>>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin >>>>>> $(obj)u-boot.bin +$(obj)u-boot-pad.bin: >>>>>> $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) >>>>>> ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary >>>>>> $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat >>>>>> $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > >>>>>> $(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n >>>>>> $(UBL_CONFIG) -T ublimage \ - -e >>>>>> $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin >>>>>> $(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin + cat >>>>>> $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > >>>>>> $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin >>>>> This rule lists u-boot-spl.bin as a prerequisite, but it >>>>> doesn't appear to use it -- it uses u-boot-spl instead. >>>>> >>>>> It seems that either spl/Makefile should produce >>>>> u-boot-spl rather than u-boot-spl.bin and let the toplevel >>>>> Makefile deal with converting it to a binary, or >>>>> spl/Makefile should take care of adding any needed padding >>>>> for the target and the final rule should just be a >>>>> concatenation. >>>> So, if we use a weak PAD_TO value of say 0x1, we could >>>> always "pad" u-boot-spl.bin out and then do the concatenation >>>> here and in a few other targets as well. >>> Yes, or use a variable that includes the linker option, so that >>> it expands to an empty string if padding isn't required. >> Yes, I don't know if say IMAGE_PAD ?= "" and having boards set >> that to - --pad-to=... or just saying --pad-to=$(PAD_SIZE) and >> PAD_SIZE ?= 0x1 ends up looking cleaner once all is said and >> done. First one to try both and patch... :) >> > > Please check the following patch. It seems to work for me... > > diff --git a/Makefile b/Makefile index 8738d55..fad8b33 100644 --- > a/Makefile +++ b/Makefile @@ -433,13 +433,12 @@ $(obj)u-boot.sha1: > $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > > $@ > > -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin > - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary > $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat > $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > > $(obj)u-boot-ubl.bin +$(obj)u-boot-with-spl.bin: > $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin + cat $^ > $@ + > +$(obj)u-boot.ubl: $(obj)u-boot-with-spl.bin > $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ - -e > $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl - > rm $(obj)u-boot-ubl.bin - rm $(obj)spl/u-boot-spl-pad.bin + > -e $(CONFIG_SYS_TEXT_BASE) -d $< $@ > > $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img > $(obj)tools/mkimage -s -n /dev/null -T aisimage \ diff --git > a/spl/Makefile b/spl/Makefile index f96c08e..6ea9f26 100644 --- > a/spl/Makefile +++ b/spl/Makefile @@ -23,6 +23,8 @@ include > $(TOPDIR)/config.mk # We want the final binaries in this directory > obj := $(OBJTREE)/spl/ > > +PAD_TO ?= 1 + HAVE_VENDOR_COMMON_LIB := $(shell [ -f > $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ && echo y || echo > n) > > @@ -124,7 +126,7 @@ $(obj)$(BOARD)-spl.bin: $(obj)u-boot-spl.bin > endif > > $(obj)u-boot-spl.bin: $(obj)u-boot-spl - $(OBJCOPY) > $(OBJCFLAGS) -O binary $< $@ + $(OBJCOPY) ${OBJCFLAGS} > --pad-to=$(PAD_TO) -O binary $< $@ > > GEN_UBOOT = \ UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \ Tom W, since I'd like you to upgrade the tegra rules after this change goes in (since they do a u-boot-spl.bin + pad + u-boot.bin + stuff), does this look good to you as well? Thanks! - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQWnFxAAoJENk4IS6UOR1WybcQALKP61eZDe4AZCuhacsvFIiX EWpA4YLSDTA6Z419lkgN7qJoIKbm0lqOvlp8jyWGMgmkUjY/omGEbDjJdqRx3Fmy Hd937BU9VvUBB11S6qC/FcEpP6vC+yiSCHq9GgQ27q1qxFfnn2uzo5xODdV6XaiW mBZ4hzbLOJFxM3BVNlBAH2T/4OhVuRRucGYt68Su3EOgcbe3qd0YCHyTLuZl/k8Z HIDaKku5lgHa2BZT1JjDkRai/QuJhX53EBONc1n/S+fQr1IjXcvcppu8h4x65W8Q Rb8FKjDbUTuAvksCC/uqPJ59oMhctcmws2ywnRnGo5y097GKyl1zxyuqY5CZMSnu voJrzuIQpdPp48cXQuMHQx9z5kPmM+ohsDT9/s80AjXdS/2XqwQQjelWosn1krUi cgEq2IrtTqpiBqrYrEf1nidVJluf1VBKtCV4XRHYd6sSEteimrMu+qfLN/42U+CF tiFWqjMVpW2SCHUFogYUzARaQ/NXCYvDF1FFvnBmUWd/C9haiHqBUPba3HO/rlmb dsFM2RcMNX2CKeikA/Tdb4gwCB9wYsjJNQynE3h8BShaCbA04gYT6K1SRXSDiOuO LQuqrkLsNiL/DrqH3Trvxaxxsy0yGrs9jANfcyPlNbV+A4DKsJK6RX4MP8oYLKoV OzeS14a1CjZci5FyGgB/ =4cKu -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/20/12 09:01, Tom Warren wrote: >> -----Original Message----- From: Tom Rini [mailto:trini@ti.com] >> Sent: Wednesday, September 19, 2012 6:29 PM To: José Miguel >> Gonçalves Cc: Scott Wood; u-boot@lists.denx.de; marex@denx.de; >> mk7.kang@samsung.com; Tom Warren Subject: Re: [PATCH v4 10/11] >> Add u-boot-pad.bin target to the Makefile >> >> * PGP Signed by an unknown key >> >> On 09/19/12 17:38, José Miguel Gonçalves wrote: >>> Tom & Scott, >>> >>> On 09/20/2012 12:40 AM, Tom Rini wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 09/19/12 16:36, Scott Wood wrote: >>>>> On 09/19/2012 06:31:29 PM, Tom Rini wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> On 09/19/12 15:39, Scott Wood wrote: >>>>>>> On 09/19/2012 06:25:26 AM, José Miguel Gonçalves >>>>>>> wrote: >>>>>>>> Samsung's S3C24XX SoCs need this in order to >>>>>>>> generate a binary image with a padded SPL >>>>>>>> concatenated with U-Boot. >>>>>>>> >>>>>>>> Signed-off-by: José Miguel Gonçalves >>>>>>>> <jose.goncalves@inov.pt> --- Changes for v2: - None >>>>>>>> >>>>>>>> Changes for v3: - Changed new binary target name from >>>>>>>> u-boot-ubl.bin to u-boot-pad.bin >>>>>>>> >>>>>>>> Changes for v4: - None --- Makefile | 11 >>>>>>>> ++++++----- 1 file changed, 6 insertions(+), 5 >>>>>>>> deletions(-) >>>>>>>> >>>>>>>> diff --git a/Makefile b/Makefile index >>>>>>>> 8738d55..86dedca 100644 --- a/Makefile +++ >>>>>>>> b/Makefile @@ -433,14 +433,15 @@ $(obj)u-boot.sha1: >>>>>>>> $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot >>>>>>>> $(OBJDUMP) -d $< > $@ >>>>>>>> >>>>>>>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin >>>>>>>> $(obj)u-boot.bin +$(obj)u-boot-pad.bin: >>>>>>>> $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) >>>>>>>> ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary >>>>>>>> $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - >>>>>>>> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > >>>>>>>> $(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n >>>>>>>> $(UBL_CONFIG) -T ublimage \ - -e >>>>>>>> $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin >>>>>>>> $(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin + >>>>>>>> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > >>>>>>>> $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin >>>>>>> This rule lists u-boot-spl.bin as a prerequisite, but >>>>>>> it doesn't appear to use it -- it uses u-boot-spl >>>>>>> instead. >>>>>>> >>>>>>> It seems that either spl/Makefile should produce >>>>>>> u-boot-spl rather than u-boot-spl.bin and let the >>>>>>> toplevel Makefile deal with converting it to a binary, >>>>>>> or spl/Makefile should take care of adding any needed >>>>>>> padding for the target and the final rule should just >>>>>>> be a concatenation. >>>>>> So, if we use a weak PAD_TO value of say 0x1, we could >>>>>> always "pad" u-boot-spl.bin out and then do the >>>>>> concatenation here and in a few other targets as well. >>>>> Yes, or use a variable that includes the linker option, so >>>>> that it expands to an empty string if padding isn't >>>>> required. >>>> Yes, I don't know if say IMAGE_PAD ?= "" and having boards >>>> set that to - --pad-to=... or just saying >>>> --pad-to=$(PAD_SIZE) and PAD_SIZE ?= 0x1 ends up looking >>>> cleaner once all is said and done. First one to try both >>>> and patch... :) >>>> >>> >>> Please check the following patch. It seems to work for me... >>> >>> diff --git a/Makefile b/Makefile index 8738d55..fad8b33 100644 >>> --- a/Makefile +++ b/Makefile @@ -433,13 +433,12 @@ >>> $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: >>> $(obj)u-boot $(OBJDUMP) -d $< >>>> $@ >>> >>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin >>> $(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS} >>> --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl >>> $(obj)spl/u-boot-spl-pad.bin - cat >>> $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > >>> $(obj)u-boot-ubl.bin +$(obj)u-boot-with-spl.bin: >>> $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin + cat $^ > $@ >>> + +$(obj)u-boot.ubl: $(obj)u-boot-with-spl.bin >>> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ - -e >>> $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin >>> $(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin - rm >>> $(obj)spl/u-boot-spl-pad.bin + -e $(CONFIG_SYS_TEXT_BASE) -d >>> $< $@ >>> >>> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin >>> $(obj)u-boot.img $(obj)tools/mkimage -s -n /dev/null -T >>> aisimage \ diff --git a/spl/Makefile b/spl/Makefile index >>> f96c08e..6ea9f26 100644 --- a/spl/Makefile +++ b/spl/Makefile >>> @@ -23,6 +23,8 @@ include $(TOPDIR)/config.mk # We want the >>> final binaries in this directory obj := $(OBJTREE)/spl/ >>> >>> +PAD_TO ?= 1 + HAVE_VENDOR_COMMON_LIB := $(shell [ -f >>> $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ && echo y || >>> echo n) >>> >>> @@ -124,7 +126,7 @@ $(obj)$(BOARD)-spl.bin: >>> $(obj)u-boot-spl.bin endif >>> >>> $(obj)u-boot-spl.bin: $(obj)u-boot-spl - $(OBJCOPY) >>> $(OBJCFLAGS) -O binary $< $@ + $(OBJCOPY) ${OBJCFLAGS} >>> --pad-to=$(PAD_TO) -O binary $< $@ >>> >>> GEN_UBOOT = \ UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \ >> >> Tom W, since I'd like you to upgrade the tegra rules after this >> change goes in (since they do a u-boot-spl.bin + pad + >> u-boot.bin + stuff), does this look good to you as well? >> Thanks! > > I'm not clear what you want the final binary names to be. I seem > to be missing segments of this discussion - maybe not CC'd on all > threads? Sorry, I'm just asking if this way of padding u-boot-spl.bin to the required size by default in spl/Makefile and then not doing any - --pad-to in the toplevel Makefile rules for u-boot-spl will work for your needs as well (so update the existing rules to just concatenate spl/u-boot-spl.bin and u-boot.bin and whatever else you need and have PAD_TO be set to $(CONFIG_SYS_TEXT_BASE), I believe). - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQW0LyAAoJENk4IS6UOR1Wst8P/2IhNv0s3YKGp2r8ze4TWKaJ rMxHs9KQ+ZHcemZuD4jWkx+Ms1pZrZlKDbF2lG622n+FsgTvXP8xSyBZCB0sV0J9 wVUQR8QB6EHrdw5pOhMn7T4y3+sy61l/E50NQHU5Nu2sA7t5g/xQH95gslN9b1yv VNhX/sdISna8lEqJPF5Iuxuc9Cl7huEbSCpu/uETQZVqHfKDxkp7mZDcOHq0JJ4q 150WwOQhNKNgtX1AV9D2vcDHMRO6AOXE1cH/jMv9CBoPMkeJaW1EaGHTv8PrKeUG ONN8fCEcdTEPvv6XXk3DLXVDFruAG7jk7bQr7B59nr5NVwuxZkZKOGn4o07stTBK c2ixDbsS8K4BIlDrAMckd4pyjAWVE0bN8lDfOKvJtxMDSjMj+EagiDnPkAsnzJAB Usml6rpIuBNLC2l4MZsYEihNHk0I10/M328c0kKUwWmT4UI3GB8V/sti1OUOyAoy DBy9dH7U/aPVr72aXLcBf8vDdA3abHmHt6zLq4KDMw4+xBLmsqmALYvOOoGSdW9S X5C6d6xpQVt5ovvSV8IZkT3rKUFAhmjcLgjwxKam3eTuSEyapZAJPji9h1Bl2PMB UqR6MP8RceP9OqkSXhyCK6reFq6KCtsvGMdPnYs2uY2dZVjqMwtxPNWE1W39LqhU VCbg1HKz/kmpmS9gQqRt =qd5a -----END PGP SIGNATURE-----
Dear Tom, In message <5FBF8E85CA34454794F0F7ECBA79798F379F6FD992@HQMAIL04.nvidia.com> you wrote: > > If you flash u-boot-dtb-tegra.bin, you'll get a fully functioning > U-Boot. There's an intermediate file (u-boot-dtb.bin) that I assume > is u-boot.bin+dtb - I'm not sure why it's left around - Allen could > comment here. I _dislike_ the idea of having image names which include architecture or even board parts. I would really like to have generic names, that can be used in a consistent way across platforms, architectures and boards. > So in my eyes, all you really need is u-boot-dtb-tegra.bin - an > unwieldy name, to be sure, but it seems to satisfy your request for a > Soc identifier in the name. I voted for just having u-boot.bin be the Please reconsider. I definitely do NOT want to have SoC names or that in any such images! IIRC, the original idea was to provide image names (common for all architectures, SoCs, boards) that only depend on where you install U-Boot to. in this way, we would have: - u-boot.bin for the generic case (say, for installation into NOR flash, no SPL or similar needed). - u-boot-nand.bin for installation in NAND (with all needed headers, padding etc. included) - u-boot-onenand.bin for installation in OneNAND - u-boot.sd for installation on a SDCard [actually we have an inconsistency in names here; this should have been "u-boot-sd.bin" or maybe even better "u-boot-sdcard.bin"] etc. It is very important to me that we do NOT include any architectures, SoCs, or board specifc parts in the names because this will cause major PITA for all kind of automatic test suites etc. Best regards, Wolfgang Denk
Hi Wolfgang, On 09/21/2012 06:43 AM, Wolfgang Denk wrote: > Dear Tom, > > In message <5FBF8E85CA34454794F0F7ECBA79798F379F6FD992@HQMAIL04.nvidia.com> you wrote: >> If you flash u-boot-dtb-tegra.bin, you'll get a fully functioning >> U-Boot. There's an intermediate file (u-boot-dtb.bin) that I assume >> is u-boot.bin+dtb - I'm not sure why it's left around - Allen could >> comment here. > I _dislike_ the idea of having image names which include architecture > or even board parts. I would really like to have generic names, that > can be used in a consistent way across platforms, architectures and > boards. > >> So in my eyes, all you really need is u-boot-dtb-tegra.bin - an >> unwieldy name, to be sure, but it seems to satisfy your request for a >> Soc identifier in the name. I voted for just having u-boot.bin be the > Please reconsider. I definitely do NOT want to have SoC names or that > in any such images! > > > IIRC, the original idea was to provide image names (common for all > architectures, SoCs, boards) that only depend on where you install > U-Boot to. in this way, we would have: > > - u-boot.bin for the generic case (say, for installation into NOR > flash, no SPL or similar needed). > - u-boot-nand.bin > for installation in NAND (with all needed headers, > padding etc. included) > - u-boot-onenand.bin > for installation in OneNAND > - u-boot.sd for installation on a SDCard > [actually we have an inconsistency in names here; this > should have been "u-boot-sd.bin" or maybe even better > "u-boot-sdcard.bin"] > etc. > > It is very important to me that we do NOT include any architectures, > SoCs, or board specifc parts in the names because this will cause > major PITA for all kind of automatic test suites etc. > To me this seems also a cleaner solution, as any end user, that simply takes the u-boot sources and performs a make, would easily find the appropriate file to burn on his boot media. But in that case, as the NAND image format (for instance) is architecture and/or SoC dependant, what do you suggest is to add conditionals in the Makefile that adequate the 'u-boot-nand.bin' file to the target SoC? Best regards, José Gonçalves
Dear José Miguel Gonçalves, In message <505C21BB.7000209@inov.pt> you wrote: > > > It is very important to me that we do NOT include any architectures, > > SoCs, or board specifc parts in the names because this will cause > > major PITA for all kind of automatic test suites etc. > > To me this seems also a cleaner solution, as any end user, that simply > takes the u-boot sources and performs a make, would easily find the > appropriate file to burn on his boot media. > > But in that case, as the NAND image format (for instance) is > architecture and/or SoC dependant, what do you suggest is to add > conditionals in the Makefile that adequate the 'u-boot-nand.bin' file to > the target SoC? SoC specific make rules can probably be added to the respective SoC specific makefiles, thus still avoiding to clutter the top level Makefile with lots of conditionals. Best regards, Wolfgang Denk
Dear Wolfgang Denk, > Dear José Miguel Gonçalves, > > In message <505C21BB.7000209@inov.pt> you wrote: > > > It is very important to me that we do NOT include any architectures, > > > SoCs, or board specifc parts in the names because this will cause > > > major PITA for all kind of automatic test suites etc. > > > > To me this seems also a cleaner solution, as any end user, that simply > > takes the u-boot sources and performs a make, would easily find the > > appropriate file to burn on his boot media. > > > > But in that case, as the NAND image format (for instance) is > > architecture and/or SoC dependant, what do you suggest is to add > > conditionals in the Makefile that adequate the 'u-boot-nand.bin' file to > > the target SoC? > > SoC specific make rules can probably be added to the respective SoC > specific makefiles, thus still avoiding to clutter the top level > Makefile with lots of conditionals. I've been pestering Tom about this a lot, but we got nowhere so far. That's the problem here :-( > Best regards, > > Wolfgang Denk Best regards, Marek Vasut
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/21/12 08:52, Wolfgang Denk wrote: > Dear José Miguel Gonçalves, > > In message <505C21BB.7000209@inov.pt> you wrote: >> >>> It is very important to me that we do NOT include any >>> architectures, SoCs, or board specifc parts in the names >>> because this will cause major PITA for all kind of automatic >>> test suites etc. >> >> To me this seems also a cleaner solution, as any end user, that >> simply takes the u-boot sources and performs a make, would >> easily find the appropriate file to burn on his boot media. >> >> But in that case, as the NAND image format (for instance) is >> architecture and/or SoC dependant, what do you suggest is to add >> conditionals in the Makefile that adequate the 'u-boot-nand.bin' >> file to the target SoC? > > SoC specific make rules can probably be added to the respective SoC > specific makefiles, thus still avoiding to clutter the top level > Makefile with lots of conditionals. Ideally? Yes, Possible today? Not sure. I have a hazy recollection that it wasn't so easy when I tried adding some build rules to one of the config.mk files. When I post SPI SPL for am335x support I'll try again since for that I need to add a rule to generate a byte-swapped MLO file. If that can go somewhere other than spl/Makefile that would be nice (but needs to be visible to a number of TI SoCs is an issue). - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQXJIxAAoJENk4IS6UOR1WvRgP/1sA7S2GQUKx6v67zP/9aful 4YnamVKZkuutSuf/FKadLoK9NQbB4VOq6gXUcwbANlygiFVX9Ax9K6XC0JNYOSpm DeitwLu/ni9MduYM/11quwwfDWBKvIUO62cJcnRiDVSn3xyjJeEfr6lEHmgpcRx5 0wlVT183OurED18ZXZYRRKe1AxxEixVhk8XHMbBxrV01CbZckhjMgVfOCoVgIbtZ 8jo5NmW1b9TfT2FDPfEAVelpm8XTEKspVubgyE6C2uZosQOtgemMNNyTBhcAINX8 dTAed1aDJ/3ja7HEOCvnS5KtKrGnTIopWh5Q9JumrvpRYa72AXUkz2bBmWl/b4+E fZJMWoIaMh79gGcjBLU3rquCuY+zYxO9qXnKC8JaT5YnhGmIhHPFYDie1XU+9IQm EuJSzo8A3jM9TTURjmhIQ7svO6HcliuDU96HmjxKWdN/J7v+erKxy9XDwmn72R0Y oz8yQu+Sf85HAlmx5uoOZ+B8jinDxfZFseuQyrq4V8wUwTbxrFzHEelWvkSCfAn7 rr9ZjzCiCUymxpACp4YvLTultsiYIzbVevOliMbrO6ymsyByT6YmOO1eqSmsCkqq 2zXP0TZhdNgZVaGsYa+debvk7wjfTLlSqIUqKmOujPmwrtKXhGmxe9Cg4FpBbUuQ aG3hO/HSgMhBVpdS++60 =TSHS -----END PGP SIGNATURE-----
On 21-09-2012 17:13, Tom Rini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/21/12 08:52, Wolfgang Denk wrote: >> Dear José Miguel Gonçalves, >> >> In message <505C21BB.7000209@inov.pt> you wrote: >>>> It is very important to me that we do NOT include any >>>> architectures, SoCs, or board specifc parts in the names >>>> because this will cause major PITA for all kind of automatic >>>> test suites etc. >>> To me this seems also a cleaner solution, as any end user, that >>> simply takes the u-boot sources and performs a make, would >>> easily find the appropriate file to burn on his boot media. >>> >>> But in that case, as the NAND image format (for instance) is >>> architecture and/or SoC dependant, what do you suggest is to add >>> conditionals in the Makefile that adequate the 'u-boot-nand.bin' >>> file to the target SoC? >> SoC specific make rules can probably be added to the respective SoC >> specific makefiles, thus still avoiding to clutter the top level >> Makefile with lots of conditionals. > Ideally? Yes, Possible today? Not sure. I have a hazy recollection > that it wasn't so easy when I tried adding some build rules to one of > the config.mk files. When I post SPI SPL for am335x support I'll try > again since for that I need to add a rule to generate a byte-swapped > MLO file. If that can go somewhere other than spl/Makefile that would > be nice (but needs to be visible to a number of TI SoCs is an issue). > So what is your suggestion for my patch? Can I push it with a new "u-boot-with-spl.bin" target and you'll handle the unification of all NAND targets later? Best regards, José Gonçalves
Hello Tom, Tom Rini wrote on 2012-09-21: >> SoC specific make rules can probably be added to the respective SoC >> specific makefiles, thus still avoiding to clutter the top level >> Makefile with lots of conditionals. > > Ideally? Yes, Possible today? Not sure. I have a hazy recollection > that it wasn't so easy when I tried adding some build rules to one of > the config.mk files. When I post SPI SPL for am335x support I'll try > again since for that I need to add a rule to generate a byte-swapped > MLO file. If that can go somewhere other than spl/Makefile that would > be nice (but needs to be visible to a number of TI SoCs is an issue). I have done something like this in a SoC config.mk: <--- # only active in topdir ifeq ($(subst $(SRCTREE),,$(CURDIR)),) ALL-y += $(obj)u-boot-SoC-file $(obj)u-boot-SoC-file: ... ... endif ---> Without the check the rule(s) become active in all subdirs. And of course this is a hack, as it is a Makefile fragment and not only a config anymore. But maybe this gives you or someone else a hint for implementing a cleaner framework for SoC specific image rules? > > - -- > Tom Best regards, Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/21/12 09:26, José Miguel Gonçalves wrote: > On 21-09-2012 17:13, Tom Rini wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 09/21/12 08:52, Wolfgang Denk wrote: >>> Dear José Miguel Gonçalves, >>> >>> In message <505C21BB.7000209@inov.pt> you wrote: >>>>> It is very important to me that we do NOT include any >>>>> architectures, SoCs, or board specifc parts in the names >>>>> because this will cause major PITA for all kind of >>>>> automatic test suites etc. >>>> To me this seems also a cleaner solution, as any end user, >>>> that simply takes the u-boot sources and performs a make, >>>> would easily find the appropriate file to burn on his boot >>>> media. >>>> >>>> But in that case, as the NAND image format (for instance) is >>>> architecture and/or SoC dependant, what do you suggest is >>>> to add conditionals in the Makefile that adequate the >>>> 'u-boot-nand.bin' file to the target SoC? >>> SoC specific make rules can probably be added to the >>> respective SoC specific makefiles, thus still avoiding to >>> clutter the top level Makefile with lots of conditionals. >> Ideally? Yes, Possible today? Not sure. I have a hazy >> recollection that it wasn't so easy when I tried adding some >> build rules to one of the config.mk files. When I post SPI SPL >> for am335x support I'll try again since for that I need to add a >> rule to generate a byte-swapped MLO file. If that can go >> somewhere other than spl/Makefile that would be nice (but needs >> to be visible to a number of TI SoCs is an issue). >> > > So what is your suggestion for my patch? Can I push it with a new > "u-boot-with-spl.bin" target and you'll handle the unification of > all NAND targets later? Having said I'm terrible at names already, Scott suggested that one and Wolfgang didn't object, so yes, you add that target and the more general problem falls to me. I'll just outsource the naming parts of it :) - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQXJf5AAoJENk4IS6UOR1W8XwQAJ1KTaHrr2F0w1/qvFZdIIOM JJz9tWhYTiLRvrWhJfIgx3kwtflxzw6JQuLfwhOryf5/5W43ySRYPb+vHl1PBwq4 RlhwVdRUpPBZPWhuSrgajIi4P8z4OkaaW7v+YhkrNh1QQCbTQMO/RWYa66Xou6UJ hAsnCKJkTqOjpCxc2JeYL/hK/EUba7o4zYAU1H8sdVtch4hOvAJEMT9C/D6/Vxsq FyNB0+IMcomYavimjbTPLIVRUCpr2lt/8l5TTIPhjnqXUbSetrgysLn75ofKBU7Q db/cf+Ry2bFTGnQ8OdPU2FCwsqA905EU/WCjjX6/yUwRR3OpnJVkPi0DTqvEJ0YR gpADl5yy6VmCcZXRnPa1CGRyKv3vbRk333W4X2FgNCUES98BUM8L/qbbd29Tb5I7 KiaF6s5YoeDVCqMW7ER9a+BvvzD2YlHHcO4PwgOPu+xdkGbWxosxdKOgWRmTjR8X HQnuzwqT0X36unC5HpLxmzqHHxTomP02dil7eT+XHMNA6d/Jd61ByZvd2Lk/getw gALsACCcAZN/WtpA1s6DGYBX2/g/8pMul5Hf3tbAFseKumqeqd+ufcAEPgAQ/nKV 8sUz2DtFnmRsaukTkCl3aFexPr1upbQJh/EkopLq3uuHwKRxWymP2AQ/AAML7kYY 94pdwweLvRpb3AYvS5ZJ =xeXW -----END PGP SIGNATURE-----
diff --git a/Makefile b/Makefile index 8738d55..fad8b33 100644 --- a/Makefile +++ b/Makefile @@ -433,13 +433,12 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@ -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin +$(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin + cat $^ > $@ + +$(obj)u-boot.ubl: $(obj)u-boot-with-spl.bin $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ - -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin - rm $(obj)spl/u-boot-spl-pad.bin + -e $(CONFIG_SYS_TEXT_BASE) -d $< $@ $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img $(obj)tools/mkimage -s -n /dev/null -T aisimage \ diff --git a/spl/Makefile b/spl/Makefile index f96c08e..6ea9f26 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -23,6 +23,8 @@ include $(TOPDIR)/config.mk # We want the final binaries in this directory obj := $(OBJTREE)/spl/ +PAD_TO ?= 1 + HAVE_VENDOR_COMMON_LIB := $(shell [ -f $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ && echo y || echo n)