[OpenWrt-Devel] openwrt-devel Digest, Vol 37, Issue 94

Mon May 20 22:42:05 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