OpenWrt Forum Archive

Topic: compiled LEDE for ipq8064 ap148, how to flash spi flash?

The content of this topic has been archived on 20 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

hi, everyone!

I compiled the lede source code, then get these files:

config.seed
lede-ipq806x-AP148-squashfs-nand-factory.ubi
lede-ipq806x-AP148-squashfs-nand-sysupgrade.tar
lede-ipq806x-AP148-ubifs-nand-factory.ubi
lede-ipq806x-AP148-ubifs-nand-sysupgrade.tar
lede-ipq806x-device-ap148.manifest
lede-ipq806x-squashfs-root.img
lede-ipq806x-ubifs-root.img
lede-ipq806x-vmlinux.elf
packages
sha256sums

My ipq8064 board(WPQ864)  has only spi flash, without nand flash. Which file is right for my board?

I flash my board by tftp or Internet explore, but both are failed.

The short answer: None of them.

SPI refers to the peripheral bus used to connect the flash chip into the microcontroller unit. It has very little to do with NAND, which is a technology used to implement the flash memory chip itself; the other prominent technology being NOR.

WPQ864 has both NOR and NAND flash (see this and this). The files that you have generated are for the AP148 development board, which is a completely different unit.

AP148 has the same SoC, equal amount of flash memory and RAM, but that's where the similarities end. Looking at the hardware specs, I wouldn't use the AP148 images on a WPQ864 board.

To build OpenWRT for WPQ864, I recommend you get in touch with OEM, which is Complex Systems. They have listed OpenWRT as a supported operating system, so they probably have a customized build environment that results in a WPQ864-compatible OpenWRT image.

You might also want to ask more help from the LEDE forums, if you want to create a new LEDE device profile for your board.

(Last edited by Antek on 11 Jul 2017, 07:20)

Could you tell me the usage of those files?

liveonlinux wrote:

Could you tell me the usage of those files?

I'm not sure if I am up to speed with all the files LEDE build environment generates, but I'll try my best to help you. This explanation might not be entirely accurate, since both LEDE and OpenWRT are moving targets, and I am not  at all familiar with the AP148 development board and all the intricacies involved with it.

It should give you the general idea though.

config.seed

That is the output of ./scripts/diffconfig.sh (In practice that is the difference between global empty defaults and all the changes you've done inside 'make menuconfig')

lede-ipq806x-AP148-squashfs-nand-factory.ubi

A combo that contains a kernel image, followed by a read-only root filesystem and a read-write JFFS2 filesystem. The entire package is masqueraded to look like a stock firmware so as to make it compatible with the "upgrade" or "update" tools that are present in the OEM's own firmware; the package may contain folder structures, padding, headers, magic numbers, checksums etc. depending on what is required.

The 'squashfs' refers to the filesystem used in the root filesystem, and 'ubi' refers to the Unsorted Block Images layer that is placed underneath both the root filesystem and the read-write filesystem in order to extend the life of the NAND physical chip. The two filesystems are combined together using the  OverlayFS scheme.

lede-ipq806x-AP148-squashfs-nand-sysupgrade.tar

Similar in essence to the 'factory' variant, but is an archive that contains a folder structure and some supporting files to make the image compatible with LEDE/OpenWRT's own "upgrade" option (i.e. the 'sysupgrade' program or from LuCI). Does not contain padding, headers, magic numbers or anything of the sort (since LEDE/OpenWRT does not use them), and is not compatible with the stock firmware's "upgrade" or "update" tools.

lede-ipq806x-AP148-ubifs-nand-factory.ubi

Similar to the first 'factory' variant, but the root filesystem and the read-write filesystem both use UBIFS instead of a SquashFS+JFFS2 combo. Underneath the entire UBIFS, there's an UBI layer. Contains folder structures, padding, headers, magic numbers & checksums to make it look like a stock firmware. I don't know if OverlayFS is in use in these images, or how exactly it is used.

lede-ipq806x-AP148-ubifs-nand-sysupgrade.tar

Similar to the previous 'sysupgrade' variant, but uses UBIFS instead of SquashFS+JFFS2 combo.

lede-ipq806x-device-ap148.manifest

I do not know what this file contains. Open it up and see for yourself smile

lede-ipq806x-squashfs-root.img

A filesystem image that contains the read-only SquashFS root section and the read-write JFFS2 section. An OverlayFS is present to combine the two.

lede-ipq806x-ubifs-root.img

A filesystem image that uses UBIFS for all sections. I'm not sure if OverlayFS is used here.

lede-ipq806x-vmlinux.elf

A kernel image. I do not know if this image is usable as-is, or if it requires binary conversion or something else before it gets placed into the 'factory' and 'sysupgrade' packages. You can try doing binary compare between the kernel image found inside the aforementioned packages and this file, to see how they differ from each other.

packages

If memory serves right, this file contains a full list of packages (and the versions used) that you selected for installation during the 'make menuconfig' phase. This file can be empty if you chose to remove the IPKG/OPKG data from the final image in 'make menuconfig'.

sha256sums

The SHA256 checksums of the image files.

Hopefully these explanations are useful. I take no responsibility if the explanations are inaccurate. I try the best I can, but considering the complexity of the LEDE system, it's very difficult to be always on the top of everything smile

(Last edited by Antek on 11 Jul 2017, 10:23)

lede-XXX-squashfs-nand-factory.ubi
lede-XXX-ubifs-nand-factory.ubi


The two files is different only about filesystem format, is it? And each one can run OK?

liveonlinux wrote:

The two files is different only about filesystem format, is it?

Usually, yes. This depends on the instructions in the makefile. Usually the makefiles use specific naming conventions for the target files so it is easy for anyone to logically deduce what the files contain. However, if the makefiles are broken, then there's no knowing what these images really contain. Look at the makefiles and see what they do.

liveonlinux wrote:

And each one can run OK?

Impossible to say. Perhaps they work fine, perhaps they don't. Since you built these two images yourself on your own build environment, there's no way of knowing whether they will run or not. It depends on what settings you used, and whether these settings are correct for the target system where you intend to run the image.

Antek, thanks!

After i traced the Makefile related to building images.
1. target/linux/ipq806x/image/Makefile
2. include/image.mk
3. include/image-commands.mk

The below is just my concepts, I cannot verify.

If you change the SUBTARGET to 'Qualcomm AP148 (legacy)', the SDK will generates the AP148-legacy-uImage.

You can find the uImage in this directory, $(TOPDIR)/build_dir/target-arm_cortex-a15+neon-vfpv4_musl-1.1.16_eabi/linux-ipq806x .

And take the lede-ipq806x-squashfs-root.img as your rootfs.

The discussion might have continued from here.