Message ID | 20190811080602.4154-1-matwey.kornilov@gmail.com |
---|---|
State | RFC |
Delegated to: | Philipp Tomsich |
Headers | show |
Series | [U-Boot,RFC] rockchip, Makefile: add u-boot-tpl-with-spl.img target | expand |
Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote: > Here, we introduce generic u-boot-tpl-with-spl.img target which is the > TPL image followed by the SPL binary. Having built U-Boot TPL + SPL images over and over again for testing on various rk3399 hardware, something like this would certainly be a convenience. It would simplify instructions to end users too. Best wishes, Chris.
Hi, On Sun, 11 Aug 2019 at 07:51, Chris Webb <chris@arachsys.com> wrote: > > Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote: > > > Here, we introduce generic u-boot-tpl-with-spl.img target which is the > > TPL image followed by the SPL binary. > > Having built U-Boot TPL + SPL images over and over again for testing on > various rk3399 hardware, something like this would certainly be a > convenience. It would simplify instructions to end users too. How about using binman for rockchip? It is designed to put various images together. I could have a crack at it if no one else wants to. Regards, Simon
> From: Simon Glass <sjg@chromium.org> > Date: Sun, 11 Aug 2019 12:37:13 -0600 > > Hi, > > On Sun, 11 Aug 2019 at 07:51, Chris Webb <chris@arachsys.com> wrote: > > > > Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote: > > > > > Here, we introduce generic u-boot-tpl-with-spl.img target which is the > > > TPL image followed by the SPL binary. > > > > Having built U-Boot TPL + SPL images over and over again for testing on > > various rk3399 hardware, something like this would certainly be a > > convenience. It would simplify instructions to end users too. > > How about using binman for rockchip? It is designed to put various > images together. For a simple concatenation?
> From: "Matwey V. Kornilov" <matwey.kornilov@gmail.com> > Date: Sun, 11 Aug 2019 11:06:02 +0300 > > Many Rockchip platforms require the same u-boot deploy procedure > when TPL and SPL both enabled. > > The following examples are taken from doc/README.rockchip > and board/theobroma-systems/lion_rk3368/README: > > RK3288: > > ./tools/mkimage -n rk3288 -T rksd -d ./tpl/u-boot-tpl.bin out > cat ./spl/u-boot-spl-dtb.bin >> out > sudo dd if=out of=/dev/mmcblk0 seek=64 > > RK3328: > > ./tools/mkimage -n rk3328 -T rksd -d ./tpl/u-boot-tpl.bin idbloader.img > cat ./spl/u-boot-spl.bin >> idbloader.img > sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 > > RK3368: > > ./tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img > cat spl/u-boot-spl-dtb.bin >> spl-3368.img > dd if=spl-3368.img of=/dev/sdb seek=64 > > RK3399: > > ./tools/mkimage -n rk3399 -T rksd -d ./tpl/u-boot-tpl-dtb.bin out > cat ./spl/u-boot-spl-dtb.bin >> out > sudo dd if=out of=/dev/sdc seek=64 > > Here, we introduce generic u-boot-tpl-with-spl.img target > which is the TPL image followed by the SPL binary. Nice. Only comment/question I have is whether we should go with your name (which fits well with the way we name other U-Boot components) or use idbloader.img which is the name used in some external documentation such as: http://opensource.rock-chips.com/wiki_Boot_option Cheers, Mark > Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> > --- > Makefile | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/Makefile b/Makefile > index 8513db94e3..4d70b6ac2e 100644 > --- a/Makefile > +++ b/Makefile > @@ -882,6 +882,10 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy) > ALL-y += u-boot-with-dtb.bin > endif > > +ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL)$(CONFIG_TPL),yyy) > +ALL-y += u-boot-tpl-with-spl.img > +endif > + > LDFLAGS_u-boot += $(LDFLAGS_FINAL) > > # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. > @@ -1293,6 +1297,14 @@ OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \ > u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE > $(call if_changed,pad_cat) > > +ifeq ($(CONFIG_ARCH_ROCKCHIP),y) > +MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T rksd > +tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE > + $(call if_changed,mkimage) > +u-boot-tpl-with-spl.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE > + $(call if_changed,cat) > +endif > + > ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy) > MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE) > > -- > 2.16.4 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
вс, 11 авг. 2019 г. в 22:10, Mark Kettenis <mark.kettenis@xs4all.nl>: > > > From: "Matwey V. Kornilov" <matwey.kornilov@gmail.com> > > Date: Sun, 11 Aug 2019 11:06:02 +0300 > > > > Many Rockchip platforms require the same u-boot deploy procedure > > when TPL and SPL both enabled. > > > > The following examples are taken from doc/README.rockchip > > and board/theobroma-systems/lion_rk3368/README: > > > > RK3288: > > > > ./tools/mkimage -n rk3288 -T rksd -d ./tpl/u-boot-tpl.bin out > > cat ./spl/u-boot-spl-dtb.bin >> out > > sudo dd if=out of=/dev/mmcblk0 seek=64 > > > > RK3328: > > > > ./tools/mkimage -n rk3328 -T rksd -d ./tpl/u-boot-tpl.bin idbloader.img > > cat ./spl/u-boot-spl.bin >> idbloader.img > > sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 > > > > RK3368: > > > > ./tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img > > cat spl/u-boot-spl-dtb.bin >> spl-3368.img > > dd if=spl-3368.img of=/dev/sdb seek=64 > > > > RK3399: > > > > ./tools/mkimage -n rk3399 -T rksd -d ./tpl/u-boot-tpl-dtb.bin out > > cat ./spl/u-boot-spl-dtb.bin >> out > > sudo dd if=out of=/dev/sdc seek=64 > > > > Here, we introduce generic u-boot-tpl-with-spl.img target > > which is the TPL image followed by the SPL binary. > > Nice. Only comment/question I have is whether we should go with your > name (which fits well with the way we name other U-Boot components) or > use idbloader.img which is the name used in some external > documentation such as: > > http://opensource.rock-chips.com/wiki_Boot_option I think it is for maintainers to decide. What does idb in "idbloader" stands for? > > Cheers, > > Mark > > > Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> > > --- > > Makefile | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > > > diff --git a/Makefile b/Makefile > > index 8513db94e3..4d70b6ac2e 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -882,6 +882,10 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy) > > ALL-y += u-boot-with-dtb.bin > > endif > > > > +ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL)$(CONFIG_TPL),yyy) > > +ALL-y += u-boot-tpl-with-spl.img > > +endif > > + > > LDFLAGS_u-boot += $(LDFLAGS_FINAL) > > > > # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. > > @@ -1293,6 +1297,14 @@ OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \ > > u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE > > $(call if_changed,pad_cat) > > > > +ifeq ($(CONFIG_ARCH_ROCKCHIP),y) > > +MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T rksd > > +tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE > > + $(call if_changed,mkimage) > > +u-boot-tpl-with-spl.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE > > + $(call if_changed,cat) > > +endif > > + > > ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy) > > MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE) > > > > -- > > 2.16.4 > > > > _______________________________________________ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot
Hi Mark, On Sun, 11 Aug 2019 at 12:53, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Simon Glass <sjg@chromium.org> > > Date: Sun, 11 Aug 2019 12:37:13 -0600 > > > > Hi, > > > > On Sun, 11 Aug 2019 at 07:51, Chris Webb <chris@arachsys.com> wrote: > > > > > > Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote: > > > > > > > Here, we introduce generic u-boot-tpl-with-spl.img target which is the > > > > TPL image followed by the SPL binary. > > > > > > Having built U-Boot TPL + SPL images over and over again for testing on > > > various rk3399 hardware, something like this would certainly be a > > > convenience. It would simplify instructions to end users too. > > > > How about using binman for rockchip? It is designed to put various > > images together. > > For a simple concatenation? Well, for producing an image that works. E.g. producing a full image (TPL, SPL and U-Boot) for an SD card - it would be nice to have u-boot-rockchip.sd.bin or something like that. Regards, Simon
> From: Simon Glass <sjg@chromium.org> > Date: Mon, 12 Aug 2019 10:45:46 -0600 > > Hi Mark, > > On Sun, 11 Aug 2019 at 12:53, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: Simon Glass <sjg@chromium.org> > > > Date: Sun, 11 Aug 2019 12:37:13 -0600 > > > > > > Hi, > > > > > > On Sun, 11 Aug 2019 at 07:51, Chris Webb <chris@arachsys.com> wrote: > > > > > > > > Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote: > > > > > > > > > Here, we introduce generic u-boot-tpl-with-spl.img target which is the > > > > > TPL image followed by the SPL binary. > > > > > > > > Having built U-Boot TPL + SPL images over and over again for testing on > > > > various rk3399 hardware, something like this would certainly be a > > > > convenience. It would simplify instructions to end users too. > > > > > > How about using binman for rockchip? It is designed to put various > > > images together. > > > > For a simple concatenation? > > Well, for producing an image that works. E.g. producing a full image > (TPL, SPL and U-Boot) for an SD card - it would be nice to have > u-boot-rockchip.sd.bin or something like that. True. That'd be an image you write at certain offset I suppose so it preserves the MBR/partition tables?
Hi Mark, On Mon, 12 Aug 2019 at 10:56, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Simon Glass <sjg@chromium.org> > > Date: Mon, 12 Aug 2019 10:45:46 -0600 > > > > Hi Mark, > > > > On Sun, 11 Aug 2019 at 12:53, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > From: Simon Glass <sjg@chromium.org> > > > > Date: Sun, 11 Aug 2019 12:37:13 -0600 > > > > > > > > Hi, > > > > > > > > On Sun, 11 Aug 2019 at 07:51, Chris Webb <chris@arachsys.com> wrote: > > > > > > > > > > Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote: > > > > > > > > > > > Here, we introduce generic u-boot-tpl-with-spl.img target which is the > > > > > > TPL image followed by the SPL binary. > > > > > > > > > > Having built U-Boot TPL + SPL images over and over again for testing on > > > > > various rk3399 hardware, something like this would certainly be a > > > > > convenience. It would simplify instructions to end users too. > > > > > > > > How about using binman for rockchip? It is designed to put various > > > > images together. > > > > > > For a simple concatenation? > > > > Well, for producing an image that works. E.g. producing a full image > > (TPL, SPL and U-Boot) for an SD card - it would be nice to have > > u-boot-rockchip.sd.bin or something like that. > > True. That'd be an image you write at certain offset I suppose so it > preserves the MBR/partition tables? Well I suppose so, but I think it is also useful to write out the whole thing, so that it at least boots. Regards, Simon
Mark Kettenis <mark.kettenis@xs4all.nl> wrote: >> [Simon Glass <sjg@chromium.org> wrote:] >> >> Well, for producing an image that works. E.g. producing a full image >> (TPL, SPL and U-Boot) for an SD card - it would be nice to have >> u-boot-rockchip.sd.bin or something like that. > > True. That'd be an image you write at certain offset I suppose so it > preserves the MBR/partition tables? This is also just concatenation and padding, surely? tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl-dtb.bin u-boot-sd.img cat spl/u-boot-spl-dtb.bin >>u-boot-sd.img dd if=u-boot.itb of=u-boot-sd.img seek=16320 # 16384 - 64 ...or truncate(1) and cat(1) instead of dd(1) if you prefer. As you say, Mark, this assumes it's meant to be written at offset 64 sectors in to avoid blowing away the partition table. (Pad with 64 leading NULs if it's supposed to be a bootable card image I guess.) My worry about using binman for cracking such a simple nut is the dependencies it pulls in that wouldn't otherwise be needed: the documentation suggests at least lzma-alone, liblz4, and pyelftools. We've just exorcised the pyelftools requirement for building Rockchip u-boot; it would be a pity for to re-inflict it on users and casual developers just for a convenience feature. Best wishes, Chris.
On 2019/8/12 下午9:05, Matwey V. Kornilov wrote: > вс, 11 авг. 2019 г. в 22:10, Mark Kettenis <mark.kettenis@xs4all.nl>: >>> From: "Matwey V. Kornilov" <matwey.kornilov@gmail.com> >>> Date: Sun, 11 Aug 2019 11:06:02 +0300 >>> >>> Many Rockchip platforms require the same u-boot deploy procedure >>> when TPL and SPL both enabled. >>> >>> The following examples are taken from doc/README.rockchip >>> and board/theobroma-systems/lion_rk3368/README: >>> >>> RK3288: >>> >>> ./tools/mkimage -n rk3288 -T rksd -d ./tpl/u-boot-tpl.bin out >>> cat ./spl/u-boot-spl-dtb.bin >> out >>> sudo dd if=out of=/dev/mmcblk0 seek=64 >>> >>> RK3328: >>> >>> ./tools/mkimage -n rk3328 -T rksd -d ./tpl/u-boot-tpl.bin idbloader.img >>> cat ./spl/u-boot-spl.bin >> idbloader.img >>> sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 >>> >>> RK3368: >>> >>> ./tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img >>> cat spl/u-boot-spl-dtb.bin >> spl-3368.img >>> dd if=spl-3368.img of=/dev/sdb seek=64 >>> >>> RK3399: >>> >>> ./tools/mkimage -n rk3399 -T rksd -d ./tpl/u-boot-tpl-dtb.bin out >>> cat ./spl/u-boot-spl-dtb.bin >> out >>> sudo dd if=out of=/dev/sdc seek=64 >>> >>> Here, we introduce generic u-boot-tpl-with-spl.img target >>> which is the TPL image followed by the SPL binary. >> Nice. Only comment/question I have is whether we should go with your >> name (which fits well with the way we name other U-Boot components) or >> use idbloader.img which is the name used in some external >> documentation such as: >> >> http://opensource.rock-chips.com/wiki_Boot_option > I think it is for maintainers to decide. > > What does idb in "idbloader" stands for? The 'idb' means 'ID Block' which is header for Rockchip BootRom, and idbloader including header(2KB)+TPL+SPL, which is able to be understand by the BootRom. So this name is very clear to tell people what it is, eg, the idbloader may come from rockchip binary loader with: header(2KB)+ddr.bin+miniloader.bin. I would prefer to use idbloader.img. Thanks, - Kever > >> Cheers, >> >> Mark >> >>> Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> >>> --- >>> Makefile | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/Makefile b/Makefile >>> index 8513db94e3..4d70b6ac2e 100644 >>> --- a/Makefile >>> +++ b/Makefile >>> @@ -882,6 +882,10 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy) >>> ALL-y += u-boot-with-dtb.bin >>> endif >>> >>> +ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL)$(CONFIG_TPL),yyy) >>> +ALL-y += u-boot-tpl-with-spl.img >>> +endif >>> + >>> LDFLAGS_u-boot += $(LDFLAGS_FINAL) >>> >>> # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. >>> @@ -1293,6 +1297,14 @@ OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \ >>> u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE >>> $(call if_changed,pad_cat) >>> >>> +ifeq ($(CONFIG_ARCH_ROCKCHIP),y) >>> +MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T rksd >>> +tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE >>> + $(call if_changed,mkimage) >>> +u-boot-tpl-with-spl.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE >>> + $(call if_changed,cat) >>> +endif >>> + >>> ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy) >>> MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE) >>> >>> -- >>> 2.16.4 >>> >>> _______________________________________________ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> https://lists.denx.de/listinfo/u-boot > >
Hi Chris, On Mon, 12 Aug 2019 at 11:59, Chris Webb <chris@arachsys.com> wrote: > > Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > >> [Simon Glass <sjg@chromium.org> wrote:] > >> > >> Well, for producing an image that works. E.g. producing a full image > >> (TPL, SPL and U-Boot) for an SD card - it would be nice to have > >> u-boot-rockchip.sd.bin or something like that. > > > > True. That'd be an image you write at certain offset I suppose so it > > preserves the MBR/partition tables? > > This is also just concatenation and padding, surely? > > tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl-dtb.bin u-boot-sd.img > cat spl/u-boot-spl-dtb.bin >>u-boot-sd.img > dd if=u-boot.itb of=u-boot-sd.img seek=16320 # 16384 - 64 > > ...or truncate(1) and cat(1) instead of dd(1) if you prefer. As you say, > Mark, this assumes it's meant to be written at offset 64 sectors in to > avoid blowing away the partition table. (Pad with 64 leading NULs if it's > supposed to be a bootable card image I guess.) > > > My worry about using binman for cracking such a simple nut is the > dependencies it pulls in that wouldn't otherwise be needed: the > documentation suggests at least lzma-alone, liblz4, and pyelftools. I should probably update this. Unless you use compression and SPL symbols you shouldn't need these. > > We've just exorcised the pyelftools requirement for building Rockchip > u-boot; it would be a pity for to re-inflict it on users and casual > developers just for a convenience feature. You mean make_fit_atf.py? Again I think that this logic should be moved into binman. It doesn't actually have support to generic FITs but should. We don't use a lot from this library so perhaps could adopt a similar implmentation. Regards, Simon
Simon Glass <sjg@chromium.org> wrote: > Chris Webb <chris@arachsys.com> wrote: >> My worry about using binman for cracking such a simple nut is the >> dependencies it pulls in that wouldn't otherwise be needed: the >> documentation suggests at least lzma-alone, liblz4, and pyelftools. > > I should probably update this. Unless you use compression and SPL symbols > you shouldn't need these. Hi Simon. If it doesn't pull in these extra dependencies, please ignore my concern/objection above. I was kind of hoping you'd tell me I was wrong! :) >> We've just exorcised the pyelftools requirement for building Rockchip >> u-boot; it would be a pity for to re-inflict it on users and casual >> developers just for a convenience feature. > > You mean make_fit_atf.py? Again I think that this logic should be moved > into binman. It doesn't actually have support to generic FITs but should. > > We don't use a lot from this library so perhaps could adopt a similar > implmentation. Happy to try to help if I can; ELF is just a collection of fixed C-style structures so is dead easy to parse with Python's built in struct support. The only (minor) complication for binman compared to make_fit_atf.py is the need work across 32/64-bit and big/little-endian platforms. Field sizes and therefore offsets vary between the two cases of 32-bit and 64-bit ELF files. (I could just verify 64-bit little-endian ARM and then used fixed offsets in make_fit_atf.py.) Best wishes, Chris.
Hi Chris, On Tue, 13 Aug 2019 at 03:52, Chris Webb <chris@arachsys.com> wrote: > > Simon Glass <sjg@chromium.org> wrote: > > > Chris Webb <chris@arachsys.com> wrote: > >> My worry about using binman for cracking such a simple nut is the > >> dependencies it pulls in that wouldn't otherwise be needed: the > >> documentation suggests at least lzma-alone, liblz4, and pyelftools. > > > > I should probably update this. Unless you use compression and SPL symbols > > you shouldn't need these. > > Hi Simon. If it doesn't pull in these extra dependencies, please ignore my > concern/objection above. I was kind of hoping you'd tell me I was wrong! :) Well sunxi uses binman and I can build all of that without those dependencies. I'll do a patch to update the docs. > > >> We've just exorcised the pyelftools requirement for building Rockchip > >> u-boot; it would be a pity for to re-inflict it on users and casual > >> developers just for a convenience feature. > > > > You mean make_fit_atf.py? Again I think that this logic should be moved > > into binman. It doesn't actually have support to generic FITs but should. > > > > We don't use a lot from this library so perhaps could adopt a similar > > implmentation. > > Happy to try to help if I can; ELF is just a collection of fixed C-style > structures so is dead easy to parse with Python's built in struct support. > > The only (minor) complication for binman compared to make_fit_atf.py is the > need work across 32/64-bit and big/little-endian platforms. Field sizes and > therefore offsets vary between the two cases of 32-bit and 64-bit ELF > files. (I could just verify 64-bit little-endian ARM and then used fixed > offsets in make_fit_atf.py.) Well whatever you can do in that script you can do in Python in binman. I'd be quite happy to drop the pylibelf dependency. Regards, Simon
diff --git a/Makefile b/Makefile index 8513db94e3..4d70b6ac2e 100644 --- a/Makefile +++ b/Makefile @@ -882,6 +882,10 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy) ALL-y += u-boot-with-dtb.bin endif +ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL)$(CONFIG_TPL),yyy) +ALL-y += u-boot-tpl-with-spl.img +endif + LDFLAGS_u-boot += $(LDFLAGS_FINAL) # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. @@ -1293,6 +1297,14 @@ OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE $(call if_changed,pad_cat) +ifeq ($(CONFIG_ARCH_ROCKCHIP),y) +MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T rksd +tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE + $(call if_changed,mkimage) +u-boot-tpl-with-spl.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE + $(call if_changed,cat) +endif + ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy) MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE)
Many Rockchip platforms require the same u-boot deploy procedure when TPL and SPL both enabled. The following examples are taken from doc/README.rockchip and board/theobroma-systems/lion_rk3368/README: RK3288: ./tools/mkimage -n rk3288 -T rksd -d ./tpl/u-boot-tpl.bin out cat ./spl/u-boot-spl-dtb.bin >> out sudo dd if=out of=/dev/mmcblk0 seek=64 RK3328: ./tools/mkimage -n rk3328 -T rksd -d ./tpl/u-boot-tpl.bin idbloader.img cat ./spl/u-boot-spl.bin >> idbloader.img sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 RK3368: ./tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img cat spl/u-boot-spl-dtb.bin >> spl-3368.img dd if=spl-3368.img of=/dev/sdb seek=64 RK3399: ./tools/mkimage -n rk3399 -T rksd -d ./tpl/u-boot-tpl-dtb.bin out cat ./spl/u-boot-spl-dtb.bin >> out sudo dd if=out of=/dev/sdc seek=64 Here, we introduce generic u-boot-tpl-with-spl.img target which is the TPL image followed by the SPL binary. Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> --- Makefile | 12 ++++++++++++ 1 file changed, 12 insertions(+)