[U-Boot] [RFC PATCH] rockchip, Makefile: add u-boot-tpl-with-spl.img target
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(+)
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)
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?
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.
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
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:
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
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:
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
participants (5)
-
Chris Webb -
Kever Yang -
Mark Kettenis -
Matwey V. Kornilov -
Simon Glass