Is upgrading from barrier_breaker to 18.06.2 fine?

I have the 3 doubts

  1. Is it upgrading from barrier_breaker to 18.06.2 fine to do using the LuCI interface firmware upgrade ?

the following files are built
openwrt-ipq40xx-qcom_ap-dk04.1-c1-fit-uImage.itb
openwrt-ipq40xx-qcom_ap-dk04.1-c1-initramfs-fit-uImage.itb
openwrt-ipq40xx-qcom_ap-dk04.1-c1-squashfs-nand-factory.ubi
openwrt-ipq40xx-qcom_ap-dk04.1-c1-squashfs-nand-sysupgrade.bin

  1. Does the openwrt-ipq40xx-qcom_ap-dk04.1-c1-squashfs-nand-sysupgrade.bin contains bootloader (u-boot) since i am unable to locate any u-boot.bin like files in the build folders ?

  2. How to just test the above linux image (initramfs) using the u-boot prompt ?

Thanks

If you have u-boot console, TFTP the initramfs image into RAM and boot it, then use it to flash the sysupgrade (SCP to /tmp RAM disk, then run the sysupgrade script). This is the most certain way to get a good flash, since the same version is being used. In this workflow the firmware presently on the router isn't used at all.

TFTP booting from RAM consists of first checking your environment to use your PC as the server, run a server on your PC, use tftpboot to transfer the file to RAM, the bootm to boot it.

OpenWrt doesn't replace your bootloader. Bootloaders are generally outside the scope of the OpenWrt project.

3 Likes

There has never been ipq40xx support in barrier breaker, so we're not talking about OpenWrt here, but a proprietary vendor SDK instead. This in turn means that there generally isn't a clean upgrade path using sysupgrade, so you need to follow a vendor/ device specific installation method for installing OpenWrt the first time (this could be a factory image or something more complex).

Just for the avoidance of doubt, unless you have a real ap.dk04.1-c1 devboard (and not a commercial product loosely based on QCA's reference implementation!), those files wouldn't be usable (and even actively dangerous) for flashing.

4 Likes

ok... thanks for the info...