[OpenWrt-Devel] [RFC PATCH] ath79: clarify purpose of factory image

[Chuanhong Guo]

Hi!

On Thu, Mar 26, 2020 at 11:57 PM Adrian Schmutzler
<freifunk at adrianschmutzler.de> wrote:
>
> While the purpose of a factory image in general is to flash a
> device with vendor OS "directly", some vagueness has evolved over
> the years with respect to additional uses of these images.

I think factory image is supposed to be packaged in exactly the
same way as vendor firmware upgrade package, which can be
flashed however vendor ones can be flashed. (e.g. firmware
upgrade page in web interface or user-friendly firmware recovery
methods designed by vendors.)

> One common case is when a device supports TFTP recovery.
> Particularly with TP-Link devices in ar71xx/ath79, it is common
> that the factory image can be flashed via TFTP without any additional
> measures.

These tftp recovery methods are designed by vendors and are
supposed to take their own firmware upgrade packages as well.

> In contrast, on some ramips devices the same procedure might
> overwrite your u-boot partition and make the device unbootable.

This only happens when vendors don't provide an official tftp
recovery method and users are at on their own risk by trying
to use factory images with these undocumented bootloader
features.

> However, in both cases you might only have a factory.bin which
> won't reveal any further information just by itself.
>
> To improve the situation at least a bit, this commit tries to
> clarify the image names by introducing the following three schemes:
>
> factory.bin - used from vendor OS, _not_ suitable for TFTP
> factory-tftp.bin - used from vendor OS, _also_ suitable for TFTP

I think there's no need to differentiate these two variants.
We should instead make it clear that factory should be
used the same way as vendor fw image and name other
images by their use cases like tftp/recovery etc.

> tftp.bin - can _not_ be used from vendor OS, but can be used via TFTP
>
> Since factory.bin and tftp.bin are already used widely, this will
> keep the impact relatively small by only adding the "combined"
> factory-tftp.bin image name. No additional images are built, just
> the name of the existing one is slightly adjusted for matching cases.
> Despite, the name change as an indicator for the new TFTP capability
> will have to be added manually, so in case of uncertainty the image
> name will indicate the lesser functionality by default.
>
> Thus, this patch introduces the factory-tftp.bin name for all devices
> where TFTP flashing instructions are indicated by the commit message,
> and for all TP-Link devices with v1 image/header or tplink-safeloader.

TP-Link doesn't provide an official tftp recovery method for
their earlier devices (most devices with tp-link v1 headers).
In order to unbrick these devices, one would need to attach
serial console and use u-boot command line to manually
erase a certain area on flash and write new firmware image
to it. I think it doesn't worth to mark these factory images as
'tftp capable'.

BTW I have no idea about how tplink-safeloader stuff works.

-- 
Regards,
Chuanhong Guo

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel