[OpenWrt-Devel] [PATCH 0/2] build: sysupgrade: Enable Robust NAND Upgrades

Thu Oct 24 23:57:51 EDT 2019

This submission is part of a series of commits that prepares for
use of SPI-NAND with the upstream Linux MTD framework for the ath79
target. The entire series of pending changes may be seen on GitHub[1].

The series also addresses upgrade issues associated with tar-style
files and metadata, allowing "force-less" upgrade paths from ar71xx
to ath79 builds, including from previous NOR builds to ath79 builds
that support NAND.

Addresses comments in previous PRs around SPI-NAND support, including
  #615  https://github.com/openwrt/openwrt/pull/615
  #1428 https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401
in the manner requested by @mkresin

> Please re-spin [PR 1428] as soon as we have kernel 4.19 support.

SPI-NAND support in this PR utilizes the upstream Linux framework, as
requested. Support for specific SPI-NAND devices present in target
devices was crafted, tested, and committed to upstream Linux in June
and just backported to OpenWrt with commit b9d58f7e06 (master).

The GL.iNet GL-AR300M and GL-AR750S devices are then supported using
NAND with this framework.

The commits have been resequenced here from the order in which they
were developed to provide clearer patches, rather than the original
"find a problem and fix it" order. As a result, the reasoning behind
some of the preliminary set of commits may not be completely clear
until the devices are added in subsequent commits.

Original development done on master prior to the 19.07 branch and the
change to Linux 4.19 for the ath79 target.

This series should be able to be backported to v19 by adding
KERNEL_PATCHVER:=4.19 to target/linux/ath79/nand/target.mk

Boot logs and/or upgrade logs of any configuration or transition
available on request.

==================
Roadmap of Commits
==================

These logical "chunks" of commits are denoted in my GitHub repo as
tags. The links within each chunk's description below will show the
commits and changes associated with each chunk.

The tags will be updated should this PR be rebased or changed prior to
merge, keeping the tag-based links usable.

In addition to the supplied links, the tags are available in clones of
my repo for local examination and exploration of the commits in this
PR, without the need to apply remote patches to a local repo.

* pr2184-00-merge_base
* pr2184-04-Prepare_ath79-nand_target
* pr2184-05-Enable_robust_upgrades
* pr2184-06-GL-AR300M_NAND_support
* pr2184-07-Add_GL-AR300M16
* pr2184-08-GL-AR750S_NAND_support

Accepted from Patchwork:

* pr2184-01-Add_I2C_support
* pr2184-02-uboot-envtools_support_for_GL-AR300M-Lite

Superseded by commit 5b6a809 and related:

* pr2184-03-Refactor_of_common_functions

=========================
Prepare ath79-nand Target
=========================

ath79: Remove legacy GL.iNet GL-AR300M NAND target
--------------------------------------------------

Removal for reimplementation confirmed with original author[2].

ath79: Prepare NAND subtarget for upstream support of SPI NAND
--------------------------------------------------------------

Use of subtarget-specific nand/base-files/ makes this a lot cleaner
and doesn't impact the generic or tiny targets.

Examination of the tiny target (and the one-board nature of
base-files/lib/functions/k2t.sh) suggest that a few kB might be saved
for the tiny target by similarly splitting out its own files from
those for the generic target. This refactoring of the generic and tiny
sub-targets was not performed. (See further
https://patchwork.ozlabs.org/patch/1181653/ by @adrianschmutzler for
the ath79 target and #2513 for the ramips target.)

https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-00-merge_base...jeffsf:pr2184-04-Prepare_ath79-nand_target

======================
Enable Robust Upgrades
======================

build: sysupgrade-tar alt-board= for legacy upgrades
----------------------------------------------------

Existing sysupgrade tooling on the ar71xx platform isn't able to
upgrade to ath79 NAND images, even with the use of SUPPORTED_DEVICES.

sysupgrade: NAND: Prefer CONTROL for board, improve robustness
--------------------------------------------------------------

Rather than taking the first directory found in the tar as that from
which the assets are obtained, trust the contents of the CONTROL file
found. Though the CONTROL file could be fed to sh, parse it somewhat
robustly to allow for a transition to JSON or other formats in the
future.

    grep -m 1 -o -E "\bBOARD=[^[:space:]'\"]+"

Exploration of legacy flashing revealed some "interesting" behavior of
the NAND upgrade process off the "happy path". The most egregious were
addressed.

Unmodified, nand_do_upgrade_success() continues to perform a reboot
rather than returning. This continues to prevent boards from checking
that the flash was successful prior to changing the next-boot
partition. Do to the invasiveness of changing this, it was not
refactored at this time. Future refactor of this should also consider
using the existing $CONF_TAR rather than the hard-coded local
conf_tar="/tmp/sysupgrade.tgz"

Error-checking was examined, but between the above concerns and the
challenges on getting return codes from pipelined commands under sh
(neither pipefail nor PIPESTATUS are available) it was not further
pursued. Initial thoughts were that non-zero error codes might be
split into those that were still bootable ("warnings") and those that
were not bootable ("errors"), perhaps as positive and negative for
ease of consistent implementation.

https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-04-Prepare_ath79-nand_target...jeffsf:pr2184-05-Enable_robust_upgrades

======================
GL-AR300M NAND Support
======================

With the previous support in place, the boards can be added. Features
such as access to NAND storage while booted under NOR (intentionally,
or as a result of boot-count based fail over) and flashing either
NOR-based or NAND-based firmware are provided.

Legacy NOR boards may be transitioned to full support of NAND without
serial, U-Boot access, or use of "force" in sysupgrade. For example

    Legacy NOR ==> glinet,gl-ar300m-nor ==> glinet,gl-ar300m-nand

Direct transition to glinet,gl-ar300m-nand from a NOR kernel is not
possible and is prevented by checks already in place within
sysupgrade. For example:

    LEDE_RELEASE="OpenWrt 18.06.2 r7676-cddd7b4c77"

            "model": {
                    "id": "gl-ar300m",
                    "name": "GL.iNet GL-AR300M"
            },

    root at OpenWrt:/# sysupgrade /tmp/OpenWrt-2019-06-29_0807-0700-ath79-nand-glinet_gl-ar300m-nand-squashfs-sysupgrade.bin 
    Invalid image type.
    Image check 'platform_check_image' failed.

jeffsf/openwrt at jeffsf:pr2184-05-Enable_robust_upgrades...jeffsf:pr2184-06-GL-AR300M_NAND_support

===============
Add GL-AR300M16
===============

As the glinet,gl-ar300m-nor board was moved to the NAND target in the
previous commits, there is not a "generic" build suitable for the
dual-port, NAND-less GL-AR300M16, or for users of the GL-AR300M that
do not need access to the NAND (which adds ~320 kB at this time).

This commit clearly disambiguates the "generic" (NOR-only) build and
its primary, intended device from the NAND-aware build.

jeffsf/openwrt at jeffsf:pr2184-06-GL-AR300M_NAND_support...jeffsf:pr2184-07-Add_GL-AR300M16

======================
GL-AR750S NAND Support
======================

Two variants are provided, one with root file system on NOR flash, the
other with it on NAND flash. Consistent with the OEM firmware at this
time, the kernel always resides on NOR flash.

As noted in the commit message, the "glinet,gl-ar750s-nand" board name
is reserved for a potential, future build that boots its kernel from
NAND flash. It is likely that change to the U-Boot would be required
to boot off NAND, either from the manufacturer or a third party. The
current U-Boot provides for updating itself through an HTTP interface,
without serial connectivity being required.

jeffsf/openwrt at jeffsf:pr2184-07-Add_GL-AR300M16...pr2184-08-GL-AR750S_NAND_support

[1] https://github.com/openwrt/openwrt/pull/2184
[2] http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017190.html

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