Creating "factory.bin" for Sunvalleytek FileHub devices (RAVPower, HooToo) to be used "as a whole" for flashing as intended by the vendor

[xabolcs]

This is a spin-off topic from the HooToo TM05 supporting topic about creating a real factory.bin instead kernel and rootfs.

HooToo TM-05, Add LZMA Loader

I'm thinking about creating a full-blown firmware.bin which works as the original, OEM Firmware. What do you think @arrmo ? With this firmware.bin we would be able to do the initial flash without buggy-erase-all-the-things TFTP automatically back up original flash contents to the pendrive

HooToo TM-05, Add LZMA Loader

I already wrote what it buys: it avoids the buggy-erase-all-the-things TFTP recovery it have fewer requirements: no UTP cable needed no TFTP server needed just a pendrive with a few mbytes free space easier install method: put stuff on pendrive, plug the pendrive to device Quoting Adrian: The name "factory.bin" implies that the image can be used "as a whole" for flashing as intended by the vendor, i.e. via GUI or TFTP. With this new firmware.bin, the user could follow the official fir…

In this topic I'd like to talk about development such an upgrade script and an OpenWrt recipe.

I also need some help from people with serial access to their devices. It's even better if they have some flash programming gadgets!

[arrmo]

Count me it!

One "warning" - the Sunvalley shell has less capability than OpenWrt, but it's what has to be assumed. Agreed?

Thanks!

[xabolcs]

Thanks for your help!

@arrmo

... Sunvalley shell has less capability than OpenWrt ...

I see! No cut, no awk but at least sed, dd and mtd_write !

[arrmo]

@xabolcs

No cut , no awk but at least sed , dd and mtd_write

Right, wanted to make sure you knew the limits - what you have to work with

[arrmo]

FYI, tried creating a "new" HooToo file, replacing the kernel and roofs inside the HooToo stock file, updating the checksum. Ya, that didn't work ...

Ended up going the TFTP route, with the 2 files - worked perfectly!

[xabolcs]

Nice findings, thanks!

[arrmo]

NP at all, will help as much as I can. The vendor (OEM) script did help, shows how they separate the script and binary, and the checksum calculation (with the functions that are available in OEM).

[fonix232]

The stock update system has a pretty interesting way of handling things. I have the dev environment for the WD009, which includes a builder for these update files.

Basically the CRC is checked by both the script and the updater on the device. It includes not just the image, but parts of the script too - I think the calculation is done on the whole firmware file sans the first 4 lines, but I have to verify this.

The script itself extracts a rootFS ext2 image, mounts it, unmounts all MTD partitions, and chroots into the new environment. Then it proceeds to run a script in it, which does the flashing of the bootloader, kernel, and new rootFS, then reboots.

This environment contains a much more feature rich busybox, with dd and mtd_write included. I think you should be able to cobble together a build system within OpenWrt for it, which would then build the conversion image for every nightly and release.

[xabolcs]

@arrmo, I'm going to base my work on your rp-wd03 branch, and will add some new image recipe to HT-TM05, RP-WD03 and RP-WD009.

If somebody has HT-TM02, that would be nice.

[arrmo]

That makes sense to me - thanks! I can try to test the HT-TM05 and RP-WD03 once I'm back home (later next week).

Yell if there is anything else I can help with!

[xabolcs]

For an update here: I have HooToo HT-TM01 and HT-TM02 on my desk!

Sadly I don't have serial access for them, so I'm unable to debug what happens with OKLI Loader and k5.4.

[xabolcs]

I have serial.

OKLI Loader doesn't work, as it's reads garbage "from the flash" every time. The only way to avoid the 1536 k kernel size limit is to port U-Boot, IMHO.

---

Back to the topic: I'm stucked.

Vendor firmware upgrade script extracts a rootfs to the flash drive and chroots into and deploys the new firmware.

The (HT-TM05) GPL drop contains that rootfs, and of course, all OEM firmware upgrade files contain that.

Of course I don't want to include that "unkown" blob into OpenWrt tree, but generate it.
As this device is supported, a valid rootfs is generated already.
But I need to modify that rootfs to include the upgrade script and the kernel and rootfs files.

So I don't know how to add a unpack-rootfs-include-kernel-rootfs-and-a-few-files-into-it-repack-it-and-tar-it-to-an-OEM-compatible-payload magic to the recipe below:

define Device/hootoo_ht-tm02
  SOC := rt5350
  IMAGE_SIZE := 7872k
  DEVICE_VENDOR := HooToo
  DEVICE_MODEL := HT-TM02
  DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport
  SUPPORTED_DEVICES += ht-tm02
  DEFAULT := n
endef

[xabolcs]

Ok. There is a change that I could learn that magic ...

$ grep "TARGET_ROOTFS_DIR" . -r
./rules.mk:TARGET_ROOTFS_DIR?=$(if $(call qstrip,$(CONFIG_TARGET_ROOTFS_DIR)),$(call qstrip,$(CONFIG_TARGET_ROOTFS_DIR)),$(BUILD_DIR))
./rules.mk:TARGET_DIR:=$(TARGET_ROOTFS_DIR)/root-$(BOARD)
./.config:CONFIG_TARGET_ROOTFS_DIR=""
./include/rootfs.mk:TARGET_DIR_ORIG := $(TARGET_ROOTFS_DIR)/root.orig-$(BOARD)

That TARGET_DIR variable points to a directory (e.g. build_dir/target-mipsel_24kc_musl/root-ramips) which contains the ready-to-pack-to-rootfs files in "extracted" form e.g.:

$ ls build_dir/target-mipsel_24kc_musl/root-ramips
bin  dev  etc  lib  mnt  overlay  proc  rom  root  sbin  sys  tmp  usr  var  www

One should copy that TARGET_DIR and put kernel and rootfs (IMAGE_KERNEL and IMAGE_ROOTFS variables) and other helper scripts into that new copy. Of course one should manually pack that into squashfs (or something which is known by the OEM firwmare).