[OpenWrt-Devel] ar71xx: OM2P ImageBuilder no firmware when BIN_DIR used

Sven Eckelmann seckelmann at datto.com
Mon Feb 11 10:47:07 EST 2019

On Friday, 1 February 2019 13:03:42 CET Paul Spooren wrote:
> Hi all,
> thanks to this[0] bug report I found that the ar71xx/generic
> ImageBuilder doesn't create any firmware images for profile OM2P when
> used with BIN_DIR.
> My first guess is that it's somewhat related to a hard coded destination
> which doesn't handle BIN_DIR. At the very end of an "successful" build log:
> > if [ -e "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-factory.bin" ]; then cp "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-factory.bin" "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-sysupgrade.bin"; fi

Ehrm, no. These things are not hardcoded but your make just filled the 
placeholders before it prints it and sends it to your $SHELL.

The legacy build script is basically calling this helper:

    define Image/Build/OpenMesh
    	-sh $(TOPDIR)/scripts/om-fwupgradecfg-gen.sh \
    		"$(4)" \
    		"$(BUILD_DIR)/fwupgrade.cfg-$(4)" \
    		"$(KDIR_TMP)/vmlinux-$(2).uImage" \
    	-sh $(TOPDIR)/scripts/combined-ext-image.sh \
    		"$(4)" "$(call factoryname,$(1),$(2))" \
    		"$(BUILD_DIR)/fwupgrade.cfg-$(4)" "fwupgrade.cfg" \
    		"$(KDIR_TMP)/vmlinux-$(2).uImage" "kernel" \
    		"$(KDIR)/root.$(1)" "rootfs"
    	if [ -e "$(call factoryname,$(1),$(2))" ]; then \
    		cp "$(call factoryname,$(1),$(2))" "$(call sysupname,$(1),$(2))"; \

The output files are defined using:

    define sysupname
    $(call imgname,$(1),$(2))-sysupgrade.bin

    define factoryname
    $(call imgname,$(1),$(2))-factory.bin

And the imgname is:

    define imgname
    $(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(call rootfs_type,$(1))

At least it looks to me like BIN_DIR is used. But yes, the second parameter to 
scripts/combined-ext-image.sh in the make output is really using something 
which is definitely not containing the user supplied BIN_DIR but the standard 
BIN_DIR from rules.mk.

If you replace the factoryname with imgname in this line (or directly 
$(BIN_DIR)), you will also see that it is not using the user supplied BIN_DIR.

You can also see this problem when you select "Linksys WRT400N" or "Zcomax 
ZCN-1523H-5-16" - which are also using factoryname/imgname. But also devices 
like "ALFA AP96"/"Atheros AP96", which are using the default "RKuImage", have 
this problem. Something tells me that all(?) legacy build scripts are 
affected. At least it works fine with ap121f from the non-legacy devices.

I would guess that this is caused by the way SingleProfile is defined and how 
it interacts with LegacyDevice (include/image-legacy.mk) vs. Device
(include/image.mk). If you look carefully, you will notice that legacy devices 
spawn a new sub-make - non-legacy devices don't do that.

You can try the attached mini-patch [1] to check whether this is your problem. 

Kind regards,

[1] https://github.com/openwrt/openwrt/pull/1815
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-build-Accept-BIN_DIR-parameter-for-legacy-images.patch
Type: text/x-patch
Size: 1574 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190211/68d44398/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190211/68d44398/attachment.sig>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list