Build problems for kernel zImage and squashfs for the PowerPC P1020

For Developers
1

Some time ago, I don't know exactly when, the standard configuration for the MPC85XX OpenWRT seems to have deleted the building of the following files.

Currently it seems to build for some board named 'panda', or 'hive', which don't match my board that I've been building OpenWRT for, for the last 5 or so years.

There seems to be the option somewhere to build these files, but I can not figure out what options at the top level to just make it happen.

Has anyone else had this problem or does anyone use the PowerPC with OpenWRT since the grand amalgamation of LED and OpenWRT.

Files:
openwrt-mpc85xx-p1020-zImage
openwrt-mpc85xx-p1020-root.squashfs

Help/explanation would be appreciated.

John C.

2 
git log -- target/linux/mpc85xx

would be one place to start looking.

Edit: You are correct, the artifacts produced are different at http://downloads.openwrt.org/releases/17.01.6/targets/mpc85xx/p1020/

It seems that there are a few options under the p1020 subtarget:

image
image.png902×294 64.9 KB

Which look to be currently built from http://downloads.openwrt.org/snapshots/targets/mpc85xx/p1020/

Trying here

cat > .config <<EOF
CONFIG_TARGET_mpc85xx=y
CONFIG_TARGET_mpc85xx_p1020=y
CONFIG_TARGET_mpc85xx_p1020_Default=y
EOF

make defconfig
make -j12 clean download toolchain/install world

Does not produce the artifacts you were looking for.

My guess is that it's in the Makefile now making specific targets (and not generic bits).

git log --pretty=oneline $(git merge-base openwrt/lede-17.01 openwrt/master)..openwrt/master -- target/linux/mpc85xx/image/Makefile

From that, I'd guess

commit ec269290db
Author: Chris Blake <redacted>
Date:   Fri Oct 20 12:36:25 2017 -0500

    mpc85xx: use new build code style
    
    The following moves the mpc85xx target (generic & P1020) to the new
    build code style.
    
    Compile & Flash tested on an Aerohive HiveAP-330.

Edit: all the parts seem to be there

jeff@deb-devel:~/devel/openwrt$ find build_dir/ -iname '*zImage'
build_dir/target-powerpc_8540_musl/linux-mpc85xx_p1020/linux-4.19.82/arch/powerpc/boot/zImage
build_dir/target-powerpc_8540_musl/linux-mpc85xx_p1020/zImage
jeff@deb-devel:~/devel/openwrt$ find build_dir/ -iname '*.squashfs'
build_dir/target-powerpc_8540_musl/linux-mpc85xx_p1020/root.squashfs
1 Like
3

I am using the ‘default’ profile. It does generate the Hive/Panda output, which are the one available on the ’snapshot’ site.

The log file seems to indicate the WDR4900v1 was ‘disabled’ because the build was over the memory available, or setup in the Device tree.

Since I am not using the WDR4900 and have ‘fixed’ my device tree to accommodate 64M of flash for quite some time, I don’t have that problem. So, how does one ‘reenable’ the WDR4900, which I think I used at some ancient time originally to get going on some configuration?

Thanks,

John C.

4

If you don't have a tl-wdr4900, but another device that diverges from the tl-wdr4900 in the relevant domains, you add a new profile for -your- device (which you can base on the tl-wdr4900's definitions, to the extent possible). Reusing other profiles is bad practice and not a solution, as the tl-wdr4900 profile only cares about a single model, the tl-wdr4900 - and as long as there are problems generating a functional image for the tl-wdr4900, it won't be available.

5

Yes, I found the files that seem to no longer be 'moved' to the bin/target/... path. It was a bit inconvenient. But I burned those in and they seem to be working on my board.

Does this constitute a 'failure' given previous behavior to do a bug report?

Thanks,
John C.

6

I don't think so. The build system produces output for specific boards, not individual, constituent assets.

The "best" approach for a different board would be to create a DTS for the board and add it to the build system. https://openwrt.org/faq/how_can_i_add_support_for_a_new_device

7

I was using the 'default' selection for previous builds, over the last few years. Early on I did crib some elements or used the WDR4900 as a 'model/guide', but selected the more generic build for the .config file.

It seems given the other poster's response, that there were some changes to the output behavior of selecting 'default', which did not copy the zImage or the root.squashfs to the bin/target/... path as was the case previously.

The files that are found in the bin/target/... directory are 'sysupgrade' type packages, and are suited for taking an existing AP unit, using the sysupgrade feature found on most of the supported APs, and burning the OpenWRT in.

I am the manufacturer of the boards, so for my initial unflashed eeprom, I have several steps which require I have the more basic image files, rather than the sysupgrade type.

Thanks,
John C.

8

You should be able to accommodate this in the image/blah.mk file.

For example, the hiveap-330 creates a "special" in its definition, a stand-alone DTB in the fdt.bin file in the output, as well as a highly customized sysupgrade.bin

define Device/hiveap-330
  DEVICE_VENDOR := Aerohive
  DEVICE_MODEL := HiveAP-330
  DEVICE_PACKAGES := kmod-tpm-i2c-atmel
  BLOCKSIZE := 128k
  KERNEL := kernel-bin | gzip | uImage gzip
  KERNEL_SIZE := 8m
  KERNEL_INITRAMFS := copy-file $(KDIR)/vmlinux-initramfs | uImage none
  SUPPORTED_DEVICES := aerohive,hiveap-330
  IMAGES := fdt.bin sysupgrade.bin
  IMAGE/fdt.bin := append-dtb
  IMAGE/sysupgrade.bin := append-dtb | pad-to 256k | check-size 256k | \
        append-uImage-fakehdr ramdisk | pad-to 256k | check-size 512k | \
        append-rootfs | pad-rootfs $$(BLOCKSIZE) | pad-to 41216k | check-size 41216k | \
        append-kernel | append-metadata
endef
TARGET_DEVICES += hiveap-330

Take a look at include/image-commands.mk for additional options