[Upstream] - OpenWRT master, kernel 4.14 and gl-inet firmware

jeffsf · January 17, 2019, 9:43pm

Thanks, will look into the different NAND chip – would you post or PM me the part number?

On the AR300M-Lite that I have, it looks like what I would guess is a SMD MOSFET has not been populated and bridged with a 0Ω jumper, so I can’t confirm that the USB power will come on for a non-Lite device. Having found several errors already in the DTS (note, for example, that the GPIO for the status LED is incorrect), I don’t completely trust that the DTS has gotten the sense of that line correct. It’s probably a non-issue as you don’t want to be PWM-ing the power to your USB port as defining it as an “LED” would permit and have already removed that designation from my DTS versions.

Thanks for the warning on working on development branches. I’ve been working with “bleeding edge” since it was Backfire.

sfx2000 · January 17, 2019, 10:48pm

GD5F1GQ4UCYIG - it’s very similar when looking at the data sheet for the Micron and comparing things…

It’s standard stuff - 3.0v, 120MHz clock, QIO, 2048-byte read, 128K erase, WSON8 package…

The more I dig into this board, the more I appreciate the developers, there’s a lot of smart thinking that went into it.

sfx2000 · January 17, 2019, 10:54pm

Just keep a copy of your art partition backed up - that’s the factory data including RF Cal… for the AR300M-NAND it’s on /dev/mtd3

cat /dev/mtd3 > art.img # this backs it up to an image file
cat art.img > /dev/mtd3 # this restores

@jeffsf - the NAND box boots out of NOR still, that’s where uboot lives…

on the testing build - 3.012 - noticed that kernel was expecting the NOR to be a Micron 8K, but found the Winbond 16K

[    0.833518] m25p80 spi0.0: found w25q128, expected m25p80
[    0.848358] m25p80 spi0.0: w25q128 (16384 Kbytes)
[    0.853261] 4 cmdlinepart partitions found on MTD device spi0.0
[    0.859369] Creating 4 MTD partitions on "spi0.0":
[    0.891689] spi-nand: Giga SPI NAND was found.
[    0.864336] 0x000000000000-0x000000040000 : "u-boot"
[    0.870837] 0x000000040000-0x000000050000 : "u-boot-env"
[    0.877866] 0x000000050000-0x000000ff0000 : "reserved"
[    0.884717] 0x000000ff0000-0x000001000000 : "art"
[    0.896339] spi-nand: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
[    0.904469] 2 cmdlinepart partitions found on MTD device spi0.1
[    0.910586] Creating 2 MTD partitions on "spi0.1":
[    0.915573] 0x000000000000-0x000000200000 : "kernel"
[    0.925630] 0x000000200000-0x000008000000 : "ubi"
[    1.381634] found bad block 7fe0000

The bad block is nothing to worry about…

Only reason why I’m on openwrt master at the moment is that I’m helping out a small group that is bringing up a rockchip board, and I need to close out my stuff there before I get deeper into this board…

jeffsf · January 17, 2019, 10:54pm

Yes, completely agree – hitting a US$18 price point (GL-AR300M-Lite), delivered, for such a capable device with clean, professional packaging, top-notch firmware, support, and a warranty isn’t easy. They’ve made it easy for me to recommend their products to all the people that are whining that their ancient or cheap devices with insufficient flash and/or RAM, as well as often outdated wireless chips, can’t be supported by modern, secure firmware.

jeffsf · January 17, 2019, 11:40pm

From my AR300M-Lite (likely 2018 production), ath79 target, build based my changes after on

commit 7541d30c9c2946fe112d7966f9d1e7456725c324 (master)
Author: Kevin Darbyshire-Bryant <redacted>
Date:   Mon Dec 17 16:36:44 2018 +0000

I see similar

[    0.000000] CPU0 revision is: 00019374 (MIPS 24Kc)
[    0.000000] MIPS: machine is GL.iNet GL-AR300M-Lite
[    0.000000] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0
[...]
[    0.384810] m25p80 spi0.0: w25q128 (16384 Kbytes)

as well as on another vendor’s product using a QCA9558

[    0.399682] m25p80 spi0.0: w25q128 (16384 Kbytes)

(I also see the same “bad block” message on my AR750S at 7fe0000)

sfx2000 · January 18, 2019, 2:30am

I might be on an older uboot…

root@GL-AR300M:~# strings /dev/mtd0 | grep -nr "U-Boot" | head -n 1
384:U-Boot 1.1.4-g36de7573 (May 26 2017 - 14:42:18)

Anyways - the bad block thing, like I mention, is just a warning, not a problem… The spi-nor - again, probably just a warning based on upstream code… would be good to have confirmation from the gl-intet folks…

sfx2000 · January 18, 2019, 2:45am

The Lite has challenges - but I do think upfront that the AR-300M board with NAND has some serious traction with the maker community… and worthy of an LTS version of the board

@alzhao- nice to see pepe2k for Uboot - netconsole might be handy, but like the WebUI, could be a security risk - but no more than the WebGUI there.

blue-wavenet · March 1, 2019, 7:27am

No GL-AR750 Ath79 target?

jeffsf · March 1, 2019, 6:07pm

Not yet – I’ve “paused” work there until Kernel 4.19 for ath79 is available with the “approved” NAND framework. (Upstream rejected the approach presently used.) I’ve got a NOR version running, but that doesn’t really provide a lot over the ar71xx target.

Edit: This looks promising

github.com/openwrt/openwrt

ath79: add support for linux-4.19 [done]

openwrt:master ← 981213:ath79_basic_4.19

opened 04:00PM - 15 Dec 18 UTC

981213

+7076 -7

This PR adds linux 4.19 support for ath79. tested on Winchannel WB2000 (AR9344+…AR9382+AR8035). modifications to ag71xx are tested on 4.14 with the same router. edit: @mamarley has bumped 910-unaligned_access_hacks.patch and I've included his work here. edit: I did some comparison between the two usb phy drivers and I'm not sure about what the missing phy_provider is for. Since the usb and phy subsystem is out of my knowledge, I'd like to keep using the version in 4.14 and leave the upstream one untouched.

star750 · July 5, 2019, 11:27am

I noticed a patch in the mailing list. Looks like official support for ath79:

http://lists.infradead.org/pipermail/openwrt-devel/2019-June/017775.html

I’m currently building the firmware to test ath79. I’m really curious if the performance will be better!

jeffsf · July 5, 2019, 2:03pm

OpenWrt ath79 has been on 4.14 with 4.19 as “testing” as noted above. After 19.07 was branched, master moved to 4.19. There is no announced LTS kernel past 4.19 at this time.

I would not expect any performance improvements with just the kernel change. There may be some minor changes in performance (in both directions) due to moving from the unsupported ar71xx platform to the ath79 platform and possibly different drivers. The main change is structural in how the kernel and drivers are managed.

The GL-AR150, GL-AR300M, GL-AR300M-Lite, GL-AR750S, and GL-X750 have all been on ath79 for some time now, though with only NOR support. On master they are on 4.19 at this time.

SPI-NAND support for the GL-AR300M and GL-AR750S is under review.

github.com/openwrt/openwrt

ath79: Enable target for SPI-NAND; Support NAND for GL-AR300M and GL-AR750S

openwrt:master ← jeffsf:ath79-nand-pr

opened 07:29PM - 30 Jun 19 UTC

jeffsf

+363 -118

# Overview This series of commits prepares for use of SPI-NAND from the upstr…eam Linux MTD framework for the ath79 target. It 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 https://github.com/openwrt/openwrt/pull/615 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. 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](https://github.com/jeffsf/openwrt) 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: * <strike>pr2184-01-Add_I2C_support</strike> * <strike>pr2184-02-uboot-envtools_support_for_GL-AR300M-Lite</strike> Superseded by commit 5b6a809092 and related: * <strike>pr2184-03-Refactor_of_common_functions</strike> ## Prepare ath79-nand Target <strike>* ath79: Remove legacy GL.iNet GL-AR300M NAND target Removal for reimplementation [confirmed with original author](http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017190.html).</strike> Retained and _replaced_ on suggestion of @adrianschmutzler * 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 https://github.com/openwrt/openwrt/pull/2513 for the ramips target.)_ https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-00-merge_base...jeffsf:pr2184-04-Prepare_ath79-nand_target _Also available as https://patchwork.ozlabs.org/patch/1186259/_ ## 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 _Also available as https://patchwork.ozlabs.org/project/openwrt/list/?series=138554_ ## 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@OpenWrt:/# sysupgrade /tmp/OpenWrt-2019-06-29_0807-0700-ath79-nand-glinet_g l-ar300m-nand-squashfs-sysupgrade.bin Invalid image type. Image check 'platform_check_image' failed. ``` https://github.com/jeffsf/openwrt/compare/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. [https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-06-GL-AR300M\_NAND\_support...jeffsf:pr2184-07-Add\_GL-AR300M16](https://github.com/jeffsf/openwrt/compare/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. [https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-07-Add\_GL-AR300M16...pr2184-08-GL-AR750S\_NAND\_support](https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-07-Add_GL-AR300M16...pr2184-08-GL-AR750S_NAND_support)

sfx2000 · July 7, 2019, 12:09am

I suggest there would b little change in performance - stabilit, yes, shifting to a new target introduces unknowns…

sfx2000 · October 20, 2019, 11:01pm

Saw the recent checkin’s on Master for AR300M/AR300Lite for the ath79 target.

Something I’ve noticed on ath79 for ar150 is that they flipped the interface mapping - eth1 is now WAN, and eth0 is LAN - not sure why… but it can cause problems that one didn’t see on the ar7xxx, where the ar150 machine file shows eth0 as WAN

I might have to dig into this further, but my attention lays elsewhere at the moment… just curious if you see the same thing on the ar300m targets you’re working on.

For the community here - as @jeffsf mentions - no change in performance, so no big hurry to jump

jeffsf · October 21, 2019, 12:36am

Something about driver initialization, as I recall.

The flip, I believe, was undone with

commit 8dde11d521
Author:     Chuanhong Guo <redacted>
AuthorDate: Fri May 10 23:28:47 2019 +0800
Commit:     Petr Štetiar <redacted>
CommitDate: Wed Jun 5 10:12:31 2019 +0200

    ath79: dts: drop "simple-mfd" for gmacs in SoC dtsi
    
    With a proper probe deferring for ag71xx we don't need to explicitly
    probe mdio1 before gmac0.
    Drop all "simple-mfd" in SoC dtsi so that gmac orders can be the same
    as ar71xx.
    This makes eth0/eth1 order the same as those in ar71xx, which means
    we don't need a migration script for this anymore and we can merge
    incorrectly split gmac/mdio driver back together.
    
    Signed-off-by: Chuanhong Guo <redacted>

I resolved the first-boot issues that then arose with the GL-AR300M-Lite in commit eba0db95b5

sfx2000 · October 22, 2019, 2:31am

actually, that does look what did the flip on AR150 compared to ar71xx - there, WAN port is mapped to ETH0, and LAN is ETH1

On first boot, the WAN port shows as a LAN port with an address of 192.168.1.1 - which if one is doing development work, and the local LAN is also 192.168.1.0/24, this causes an ARP conflict with the gateway…

From the GW log… GW is running pfSense on the 192.168.1.0/24 segment…

Oct 18 21:30:46 kernel arp: e4:95:6e:44:f7:ac is using my IP address 192.168.1.1 on igb1!

Which causes every host on that LAN segment to get very confused about who really is 192.168.1.1

Wonder how this impacts the failsafe recovery options with the pepe2k uboot page.

don’t have time to fix it right now - very busy with day job stuff…

Log info…

[    0.444524] libphy: Fixed MDIO Bus: probed
[    0.808376] ag71xx 19000000.eth: Could not connect to PHY device. Deferring p
robe.
[    1.487758] libphy: ag71xx_mdio: probed
[    1.491098] libphy: ar8xxx-mdio: probed
[    1.497091] switch0: Atheros AR724X/AR933X built-in rev. 2 switch registered 
on mdio-bus.0
[    1.543352] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000
, driver=Generic PHY]
[    1.551954] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[    1.560582] NET: Registered protocol family 10
[    1.571933] Segment Routing with IPv6
[    1.574311] NET: Registered protocol family 17
[    1.578800] 8021q: 802.1Q VLAN Support v1.8
[    1.918985] ag71xx 19000000.eth: connected to PHY at mdio-bus.0:1f:04 [uid=00
4dd041, driver=Generic PHY]
[    1.928510] eth1: Atheros AG71xx at 0xb9000000, irq 4, mode: mii

and a bit further down the log where br-lan sorts itself out… (for those who might not know, first boot takes a bit as we have to build the jffs2 file system, subsequent boots take much less time.)

[   80.340793] br-lan: port 1(eth0) entered blocking state
[   80.344568] br-lan: port 1(eth0) entered disabled state
[   80.350400] device eth0 entered promiscuous mode
[   80.411887] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[   80.504625] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   81.078304] eth0: link up (1000Mbps/Full duplex)
[   81.088168] br-lan: port 1(eth0) entered blocking state
[   81.091953] br-lan: port 1(eth0) entered forwarding state
[   81.137380] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[   83.960736] eth1: link up (100Mbps/Full duplex)
[   84.011938] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   95.071990] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   95.148973] br-lan: port 2(wlan0) entered blocking state
[   95.152841] br-lan: port 2(wlan0) entered disabled state
[   95.158764] device wlan0 entered promiscuous mode
[   95.162956] br-lan: port 2(wlan0) entered blocking state
[   95.168200] br-lan: port 2(wlan0) entered forwarding state
[   95.658824] br-lan: port 2(wlan0) entered disabled state
[  100.358656] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  100.363866] br-lan: port 2(wlan0) entered blocking state
[  100.368960] br-lan: port 2(wlan0) entered forwarding state

some backup info, this is from the ar9331 data sheet, and if I recall, ar9531 is the same here…

One would want the GE0 mapped out to WAN, and GE1-MDIO and MAC to be mapped out to the LAN side to ensure enough bandwidth across the LAN ports

ar9331_ethernet_switch_block

jeffsf · October 22, 2019, 2:51pm

I agree that using the GMII interface for the “LAN” ports and the MII interface for the “WAN” port on a device with a 100-Mbps “WAN” phy makes sense. I don’t have a GL-AR150 in hand, so I can’t resolve it here.

sfx2000 · October 23, 2019, 3:22am

I don’t know if this needs to be resolved here, this item is probably better sorted out over on OpenWRT’s forums.

Outcome would be positive for the gl-inet dev team if they choose to go towards the ath79 target, but there are both benefits and risks to get there with their internal development.

Anyways - the port mapping might be more relevant for GL-AR750, as it’s based on the same chip family, and there, we have multiple LAN ports.

sfx2000 · October 24, 2019, 5:34am

@jeffsf - feel free to chime in there.

sfx2000 · December 2, 2019, 12:37am

Hmm… after doing some digging, maybe the port mapping is actually a production line problem.

Checked a number of my AR150’s, and they’re consistent here… including one fresh out of the box.

eth0, eth1, and wlan0 all share the same MAC address.

Reviewing the Atheros Radio Test Guide - MAC addresses are written in via bdChange during cal…

@alzhao - FYI… might want to get in front of this.

I’ll have to check my other non-AR150 devices to see what’s happening there.

From the fresh out of box device… 3.017

br-lan    Link encap:Ethernet  HWaddr E4:95:6E:4C:BC:E1  
          inet addr:192.168.8.1  Bcast:192.168.8.255  Mask:255.255.255.0
          inet6 addr: fdb1:c905:29a3:10::1/60 Scope:Global
          inet6 addr: fe80::e695:6eff:fe4c:bce1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10551 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15431 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1325704 (1.2 MiB)  TX bytes:15878539 (15.1 MiB)

eth0      Link encap:Ethernet  HWaddr **E4:95:6E:4C:BC:E0**  
          inet addr:192.168.1.152  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::e695:6eff:fe4c:bce0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12075 errors:0 dropped:67 overruns:0 frame:0
          TX packets:6868 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12093180 (11.5 MiB)  TX bytes:871173 (850.7 KiB)
          Interrupt:4 

eth1      Link encap:Ethernet  HWaddr **E4:95:6E:4C:BC:E0**  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:5 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:961 errors:0 dropped:0 overruns:0 frame:0
          TX packets:961 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:86902 (84.8 KiB)  TX bytes:86902 (84.8 KiB)

wlan0     Link encap:Ethernet  HWaddr **E4:95:6E:4C:BC:E0**  
          inet6 addr: fe80::e695:6eff:fe4c:bce0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10549 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15652 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1473378 (1.4 MiB)  TX bytes:16348455 (15.5 MiB)

sfx2000 · December 2, 2019, 2:05am

ARM300M (NAND) is the same…