In regards to the OEM TRENDnet's main HTTP UI image uploader/upgrade method:
It looks like the source of the Cameo signature/hardware_ID is in /etc/config/cameo on the local system as "option fw_hwid 'AP148AR9880-RT-150127-00'" under the "config system 'system'" section. I grepped through a dump of the filesystem from my booted system and don't see the signature string anywhere else.
Cameo's stuff is closed-source, but this is what I've figured out so far...
On the HTTP side, /www/cgi/ssi has all the magic. It's a stripped binary but there's plenty of strings and other stuff that gives me hints about what is going on.
It looks like /sbin/cameo_sysupgrade gets executed against the downloaded file. That probably checks the signature/hwid, though there's some evidence that the ssi file itself supports that.
cameo_sysupgrade is tiny. It just calls the regular old sysupgrade script.
sysupgrade get's all of it's useful functions from /lib/upgrade/platform.sh, which is where the important stuff is.
platform.sh functions indicate that the file should be a FIT image. The input file is validated via image_is_FIT().
image_demux() indicates "dumpimage -i" is used to extract. Note the lack of -T usage in this version of dumpimage.
One important feature is that platform_check_image() examines the FIT image to make sure it has an Image/File named "ubi.*". It checks this via the following command:
dumpimage -l ${img} | grep -q "^ Image.*(${sec}.*)"
Where sec=ubi
in the case of the OEM upgrade image file, Image 19 is "ubi-4247a56920048807ca170b332e81164b8067496f".
So our factory image will need to contain such a named Image.
This platform_check_image() func also allows and prohibits other named Images in the FIT. If the names are not right, they don't get loaded. Worth reading.
So when we get down to it, platform_do_upgrade() runs flash_section(), which then iterates through the list of possible images to flash. The script/flash.scr that I mentioned in the uboot-HTTP image loader? It's an ignored volume, so it does nothing for the OEM HTTP system upgrader.
Since the UBI image is the only one we really care about for now, we look at the do_flash_ubi() func.
do_flash_ubi() hit's things in /proc/boot_info for the Fail Safe Upgrader system. It's touching the BOOTCONFIG I think.
This is apparently where the system is deciding to switch our UBI MTD parts between rootfs and rootfs_1.
/proc/boot_info/rootfs/upgradepartition is called, which for my running system right now is "rootfs_1". So that's why the system switches between parts. However, this is stupidly broke, which I'll explain in a moment.
In do_flash_ubi(), "ubiformat /dev/${mtdpart} -y -f" gets called and that's what actually writes the new UBI image.
Finally it looks like platform_do_upgrade() is where the BOOTCONFIG related Safe Upgrade stuff happens to document that an upgrade is in progress/has-occurred. I still need to look into the uboot code to see what is reading that partition and how it evaluates the contents.
That Fail Safe Upgrade system is trash. It just does not work. Worse, I think it might cause upgrades to fail.
As an example, for my current running system, it did the following during boot:
First the APPSBL uboot is loaded. I can tell this because the version of uboot in APPSBL_1 is different (compile date).
Second, uboot selected rootfs_1 (mtd14) to boot the kernel from.
Then kernel then mounted rootfs (mtd11) for the squash and ubifs!
Even when I broke the UBI, the system failed to switch over to the other.
I would be afraid to test overwriting APPBL/uboot. I don't know if the low-level multi-stage bootloader is smart enough to try the backup APPSBL_1.
It is also noteworthy that the regular upgrade process appears to not touch/upgrade APPSBL_1 at all. It doesn't get upgraded.
This must be why our uboot "bootcmd=bootipq". I bet bootipq is supposed to change the bootargs so that the kernel knows which UBI to load. Well, it's not working.
Whatever the intent of this Fail Safe system was, it's broken.
Anyway, what I learned about that OEM web system upgrader is that it needs a FIT image (compatible with that version of dumpimage) with a "ubi.*" named UBI Image inside and a Cameo signature/hwid on the end. It does not use the script like the uboot-HTTP upgrader does, but it's safe to include it (it will be ignored).
I'm not completely sure about the Cameo signature since I can't see how that's evaluated, but I figure it's like previous images we already know about.
(Last edited by jmomo on 31 Jul 2016, 03:15)
