Br octeonIII new device - sysupgrade option error?

I am building from scratch (Octeon III, non-supported device). It builds fine, I defined a board option (at least, it says I did).

grommish@norwits:~/openwrt$ ls bin/targets/octeon/generic
config.seed
openwrt-octeon-device-itus.manifest
openwrt-octeon-itus-initramfs-kernel.bin
openwrt-octeon-itus-squashfs-sysupgrade.tar
packages
sha256sums
grommish@norwits:~/openwrt$ 

The build works, flashes if I drop the image into where it needs to go.

I was working on the update system and attempted to load the openwrt-octeon-itus-squashfs-sysupgrade.tar via the luCi interface, and it returns:

The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. Select 'Force upgrade' to flash the image even if the image format check fails. Use only if you are sure that the firmware is correct and meant for your device! 

Obviously, I could try and force it (I haven't yet), but I need to find out why I'm getting the error.

How are we to understand what you mean here?

fgrep -r 'The uploaded image file' /usr/lib/lua/
fgrep -r 'image_invalid' /usr/lib/lua/ | head -n 1
cat /usr/lib/lua/luci/controller/admin/system.lua | grep -C15 image_invalid
cat /usr/lib/lua/luci/controller/admin/system.lua | grep -A3 image_supported | head -n 3

Yields;

os.execute("sysupgrade -T %q >/dev/null" % image) == 0

In addition to some space and checksum verification. Good place to start....

Check in /lib/upgrade/, from

  • package/base-files/files/lib/upgrade/
  • target/linux/<target>/base-files/lib/upgrade/
  • target/linux/target>/<sub-target>/base-files/lib/upgrade/ (potentially)

You're likely either missing image metadata (please use it on platforms that support it) or have anothe "problem" with your upgrade image.

For example, if doing a NAND upgrade, if you don't match the following, you lose

identify_magic() {
	local magic=$1
	case "$magic" in
		"55424923")
			echo "ubi"
			;;
		"31181006")
			echo "ubifs"
			;;
		"68737173")
			echo "squashfs"
			;;
		"d00dfeed")
			echo "fit"
			;;
		"4349"*)
			echo "combined"
			;;
		*)
			echo "unknown $magic"
			;;
	esac
}
2 Likes

@anon50098793 Thanks for the assist.

@jeff I have a feeling I'm going to run into some of the same problems with using the sysupgrade as I did with other things, since I don't HAVE a "boot device" per-se, just the image that init's to the point of handing off root to the external partitions. Buggah me. Flashing the .bin image doesn't actually upgrade anything on my systems - it's when it's actually moved over to the external.

I'm going to have to pry the .tar apart and see what is being stored.. Maybe I can kludge my own update system from it, depending on what the file actually contains.

I appreciate the help from both of you!

1 Like

Ok, so now that I've got a slightly better idea of the structure for OpenWrt, I'm going to revisit this topic.

root@OpenWrt:/etc# sysupgrade -i -v -T /var/openwrt-octeon-itus-squashfs-sysupgrade.tar
Image metadata not found
Sysupgrade is not yet supported on generic.
Image check failed.
root@OpenWrt:/etc# 

Ok, so.. This is what I've done so far:

In target/linux/octeon/image/Makefile I have the following define

define Device/itus
  CPU_TYPE := OCTEON_CN70XX_PASS1_2
  DEVICE_VENDOR := Itus Networks
  DEVICE_MODEL := Shield
endef
TARGET_DEVICES += itus

In target/linux/octeon/base-files/lib/upgrade/platform.sh I've added to platform_do_upgrade

       itus)
                case "${SHIELD_MODE}" in
                Router)
                        kernel=mmcblk1p2
                        echo "sysupgrade: ${SHIELD_MODE} Mode" > /dev/kmsg
                        ;;
                Gateway)
                        kernel=mmcblk1p3
                        echo "sysupgrade: ${SHIELD_MODE} Mode" > /dev/kmsg
                        ;;
                Bridge)
                        kernel=mmcblk1p4
                        echo "sysupgrade: ${SHIELD_MODE} Mode" > /dev/kmsg
                        ;;
                *)
                        echo "sysupgrade: FAILED CASE" > /dev/kmsg
                        return 1
                esac
                ;;

I've got the ability to select both the target and the kernel targets.. It builds, flashes, and runs without issue. The inability to do the sysupgrade is one of the very few things from me calling it done. What am I doing wrong? What define did I miss?

maybe more like.... ( for testing -> be really careful about running these cmds live... )

obviously would need folding later but this struct might cut to the chase a lil better to begin with...

platform_do_upgrade() {
	local tar_file="$1"
	local board=$(board_name)
	local rootfs="$(platform_get_rootfs)"
	local kernel=

    echo "Your board is calling itself: $board" >> /tmp/debugsysup

	case "$board" in
	itus|Shield|generic)
		        kernel=mmcblk0p1
               	[ -z "${rootfs}" ] && rootfs="mmcblk0pCAREFUL"
                [ -b "${rootfs}" ] && echo "will-robinson rootfs: $rootfs is a blockdev!" >> /tmp/debugsysup
                echo "platform_do_flash $tar_file $board $kernel $rootfs" >> /tmp/debugsysup
                return 0
		;;
	esac

	[ -b "${rootfs}" ] || return 1
	case "$board" in
	er)
		kernel=mmcblk0p1
		;;
	erlite)
		kernel=sda1
		;;
	*)
		return 1
	esac

	platform_do_flash $tar_file $board $kernel $rootfs

	return 0
}

see how you go... turns out I need exactly the same thing... lol!

been putting it off cause I couldn't cat my head around "mtdVSmmcblk>pX/FILES"... but now i get it! ( better ) so thankyou (s) :slight_smile:

1 Like

Thank you for the suggestion! It didn't help me, but I think it's because I've missed something.

$board (and $board_name) returns generic, however, the .tar file generated when the image itself was created, has BOARD=itus in the CONTROL file

It's like it's building for the "itus" board, but it installed it reports as generic.

target/linux/octeon/base-files/lib/preinit/01_sysinfo

you have to edit all the files for the target properly;

fgrep -r 'erlite' target/linux/octeon/ | uniq

as to why this target sets board_name via cpuinfo i have no idea... maybe its an old target like ath71 ( edit: looking more... seems like something to do with mainline integration ), reading the commit for the erlite may give clues...

fgrep -r 'UBNT_E100' target/linux/octeon

target/linux/octeon/patches-4.19/100-ubnt_edgerouter2_support.patch: 	CVMX_BOARD_TYPE_UBNT_E100 = 20002