[OpenWrt-Devel] [RFC] ath79: Removal of GL.iNet AR300M NAND Target

Tue May 21 10:32:52 EDT 2019

 > > On Sun, May 19, 2019 at 12:44:18PM -0700, Jeff Kletsky wrote:
 > > I'm in the process of porting the AR750S to the ath79 target with
 > > SPI-NAND support now available on Linux 4.19[1].
 > >
 > > From what I can tell, the AR300M (NAND) target, while it builds,
 > > does not provide a functional image with either Linux 4.14 or 4.19
 > > as there has not been and is not yet an applicable SPI-NAND driver
 > > built by OpenWrt[2].
 > >
 > > While the ar71xx target had various patches to provide an SPI-attached
 > > NAND driver, at least as I understand it, these were rejected for the
 > > ath79 target in favor of the upstream SPI-NAND framework that would
 > > become available[2,3].
 > >
 > > While there is support for the GigaDevice E-series SPI NAND already
 > > backported to OpenWrt under Linux 4.19[4] and I have submitted patches to
 > > support the F-series chips upstream[5], I have been told that some of the
 > > AR300M units also shipped with Paragon SPI NAND[6], for which there is no
 > > upstream driver support at this time.
 > >
 > >
 > >
 > > As there is no bootable image produced, I would like to remove
 > > the AR300M (NAND) target from the ath79 tree at this time. The AR300M
 > > would remain on the ath79 generic (NOR) target.
 > >
 > > The intention is that the AR300M (NAND) would be reinstated once
 > > proper driver support is available.
 > >
 > >
 > >
 > > ======================
 > > If you have objections to this course of action, please let me know.
 > > ======================
 > >
 > Nah. Worst case is we have to dig the commmit log and pull the data back
 > out. That's the great thing about git.
 > >
 > >
 > > Also, if you have an AR300M with the Paragon SPI NAND that you would
 > > be able to assist me in testing development of an upstream-supported
 > > driver, please also let me know.
 > >
 > I do believe my particular ar300m is paragon based, and I'm more than
 > willing to assist wherever I can. I was under the impression that
 > bbrezelion or however you spell it was working on a generic spi-nand
 > driver?
 > > From looking at the GL.iNet source[7], I would expect to see `dmesg` on
 > > an OEM or image built from their sources to display a line containing
 > >
 > >     spi-nand: Paragon SPI NAND was found.
 > >
 > > These are probably older-production units.
 > >

 I just received a new GL ARM300M last week.  From gl-inet's 3.019 version:

 [    0.833564] m25p80 spi0.0: found w25q128, expected m25p80
 [    0.848151] m25p80 spi0.0: w25q128 (16384 Kbytes)
 [    0.853060] 4 cmdlinepart partitions found on MTD device spi0.0
 [    0.859168] Creating 4 MTD partitions on "spi0.0":
 [    0.864134] 0x000000000000-0x000000040000 : "u-boot"
 [    0.870637] 0x000000040000-0x000000050000 : "u-boot-env"
 [    0.877667] 0x000000050000-0x000000ff0000 : "reserved"
 [    0.884526] 0x000000ff0000-0x000001000000 : "art"
 [    0.891497] spi-nand: Giga SPI NAND was found.
 [    0.896149] spi-nand: 128 MiB, block size: 128 KiB, page size:
 2048, OOB size: 128
 [    0.904277] 2 cmdlinepart partitions found on MTD device spi0.1
 [    0.910394] Creating 2 MTD partitions on "spi0.1":
 [    0.915381] 0x000000000000-0x000000200000 : "kernel"
 [    0.925438] 0x000000200000-0x000008000000 : "ubi"

 [    2.771631] UBI: auto-attach mtd5
 [    2.775137] ubi0: attaching mtd5
 [    5.175419] ubi0: scanning is finished
 [    5.287855] ubi0: volume 1 ("rootfs_data") re-sized from 9 to 905 LEBs
 [    5.295504] ubi0: attached mtd5 (name "ubi", size 126 MiB)
 [    5.301183] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
 [    5.308323] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
 [    5.315337] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
 [    5.322531] ubi0: good PEBs: 1007, bad PEBs: 1, corrupted PEBs: 0
 [    5.328822] ubi0: user volume: 2, internal volumes: 1, max. volumes
 count: 128
 [    5.336289] ubi0: max/mean erase counter: 1/0, WL threshold: 4096,
 image sequence number: 933695444
 [    5.345631] ubi0: available PEBs: 0, total reserved PEBs: 1007,
 PEBs reserved for bad PEB handling: 19
 [    5.355319] ubi0: background thread "ubi_bgt0d" started, PID 301
 [    5.373091] block ubiblock0_0: created from ubi0:0(rootfs)
 [    5.378767] ubiblock: device ubiblock0_0 (rootfs) set to be root filesystem

 Happy to help out any testing.  Our community has started using these devices.

 Joe AE6XE
 http://www.arednmesh.org project

 > >
 > >
 > > Jeff
 > >
 > >
 > > ---
 > >
 > > [1] http://patchwork.ozlabs.org/project/openwrt/list/?series=107880
 > >
 > > [2] http://lists.infradead.org/pipermail/openwrt-devel/2019-January/015604.html
 > >     http://lists.infradead.org/pipermail/openwrt-devel/2019-January/015606.html
 > >
 > > [3] https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401
 > >
 > > [4] 3bc8ed91d4 generic-4.19: Backport spi-nand support for GigaDevice A/E
 > >
 > > [5] http://patchwork.ozlabs.org/project/linux-mtd/list/?series=107874
 > >
 > > [6] http://www.xtxtech.com/upfile/2016082517274590.pdf
 > >
 > > [7] <https://github.com/gl-inet/openwrt/blob/develop/target/linux/ar71xx/patches-4.9/491-mtd-spi-nand-driver.patch#L2678>
 > >

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