With the availability of the SPI-NAND framework in Linux 4.19 and
later it has become possible to support devices with SPI NAND on the
ath79 platform. The two devices I've been working on have both NOR and
NAND flash.
These devices can be built in multiple configurations and, with U-Boot
support, booted as:
* Kernel NOR, rootfs NOR
* Kernel NOR, rootfs NAND
* Kernel NAND, rootfs NAND
* Kernel NAND, rootfs NOR (arguably "degenerate")
In the case of at least the GL.iNet AR300M, the choice booting a
NOR-resident kernel or a NAND-resident kernel can be made through
use of a switch on the device, or by use of U-Boot environment value.
Working with a dual-firmware Linksys device has convinced me of the
value of having two, independent firmware versions, especially when
one goes awry, either through misconfiguration or a bad build/flash.
This becomes even more valuable when the "other" firmware can be
mounted for read and potentially write access, as can be done with the
Linksys devices[1].
However, if a NOR-only kernel is booted, it is unable to access the
NAND flash, preventing this valuable feature.
The specific case that is driving naming is the AR750S. Its OEM
configuration is kernel on NOR and file system on NAND. As either
GL.iNet or another may provide an updated U-Boot that supports
direct boot from NAND (like the AR300M, or finds that it already does),
I'd like to "reserve" glinet,gl-ar750s-nand for a "full NAND" build
in the future.
The proposal here is that:
(1) All NAND-bearing boards begin provide kernels that can
read/write their NAND, as well as providing UBI support
(2) Boards that have both NOR and NAND memory start to be named in such a
manner to clearly identify the kernel and file-system locations,
as well as to permit future implementations of `sysupgrade` to be
able to "cross-grade" compatible images (NOR to/from NAND)
On (1), only building with a SPI-NAND kernel with UBI support, the
sizes of a "default" kernel for the ath79 platform for NOR and for
NAND (based on WIP on the AR750S[2]) are:
* NOR only -- 1,618,231 bytes
* SPI-NAND -- 1,803,792 bytes
for a net increase of 185,561 bytes by adding:
FEATURES += nand
CONFIG_MTD_NAND_CORE=y
CONFIG_MTD_SPI_NAND=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_BLOCK=y
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_ADVANCED_COMPR=y
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
While a significant amount compared to 4 or 8 MB flash, NAND-bearing
devices seem unlikely to be in the "bottom of the barrel" for
resources, with 16 MB NOR being seen. Even in the case where the
device uses NOR for the kernel with no intention of providing a file
system on NOR (such as the IPQ40xx-based EA6350), 4 MB of NOR should
be more than sufficient for a kernel for at least the next several
years (roughly double of current size, accounting for boot loader
and device-specific partitions).
This also means that if you have, for example, an AR300M which has
NAND, you would always "look" in the "Generic devices with NAND flash"
section for your device, then being presented, for example
[...]
GL.iNet AR300M (NAND)
GL.iNet AR300M (NOR)
[...]
or the like. As the kernel config and required packages would be the
same, it becomes straightforward to build and flash both to provide
the same basic functionality, even if the total storage were different.
The question of MTD-partition naming and associated auto-splitting
becomes "trivial" with a DTS-based kernel through the use of
node/property deletion and/or overrides in a handful of lines in
"flavor-specific" DTS files.
On (2), board (and DTS) naming, things are a bit murkier. At the
moment, there appear to be several forms:
* legacy_name
* mfgr,board-name
* mfgr,board-name-nor
* mfgr,board-name-nand
Leaving the migration of the legacy_name boards as a separate task,
I'd propose for boards going forward:
* mfgr,board-name[-kernel[-rootfs]]
with the suffixes applied only as needed to disambiguate.
In more detail:
* mfgr,board-name
Single flash/kernel configuration possible due to *hardware* limitations
(only NOR or NAND flash present)
* mfgr,board-name-nor
Kernel and file system both on NOR
* mfgr,board-name-nand
Kernel and file system both on NAND
* mfgr,board-name-nor-nand
Kernel on NOR, file system on NAND (OEM U-Boot on AR750S always boots
NOR)
* mfgr,board-name-nand-nor (degenerate case, likely "never" offered)
Kernel on NAND, file system on NOR
A similar naming approach would apply for the DTS files.
Thoughts? Suggestions?
Jeff
[1]
<https://forum.openwrt.org/t/script-mount-alternate-nand-firmware-linksys/33588?u=jeff>
[2] <https://patchwork.ozlabs.org/patch/1099811/>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
