[OpenWrt-Devel] Setting *wireless* MTU, "UCI-compliant" way?

[Jeff Kletsky]

TL;DR

When wireless is used as transport for an encapsulated stream, it can be 
beneficial (or essential) to increase the MTU of the link closer to the 
2304 802.11 MTU. I haven't found a way to set the MTU of the wireless 
device itself through UCI. If there's something I'm missing, I'd 
appreciate hearing about it.



In Detail

I'm using 802.11s for transport of GRE-encapsulated bridged streams. 
PMTUD doesn't work in a bridged situation (for non-local devices) as 
there no way of determining to whom the fragmentation-required ICMP 
packet needs to be sent to. This is not an OpenWRT-specific problem.


OpenWRT "properly" reduces the MTU of the gretap link based on the 
underlying link, in this case below the 1500 MTU of an OpenWRT wireless 
link configured with


config wifi-iface 'mesh0'
    option device 'radio5'
    option ifname 'mesh0'
    option mode 'mesh'
    option mesh_id ''
    option mesh_fwding '1'
    option encryption 'psk2+ccmp'
    option key ''
    option sae_password ''

(Yes, both key and sae_password are there, as they have been bouncing 
around as to which works and which doesn't over the last month or so of 
master commits.)


What is challenging is that even with a "named" wireless interface, 
there doesn't seem to be a way to directly use netifd and UCI 
configuration to override the default MTU. Changing the bridge over the 
interface doesn't help, as the bridge MTU is limited by the smallest MTU 
of its bridged interfaces.


Right now, I "hook" things in a somewhat hack-ish way

--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -513,6 +513,8 @@ mac80211_prepare_vif() {
    ip link set dev "$ifname" address "$macaddr"
    fi

+   [ -x /etc/mac80211-post-add.sh ] && /etc/mac80211-post-add.sh 
"$ifname"

+
    json_select ..
 }


At least my read of things is that virtual wireless devices are "wiped" 
and re-created when changes are made. If this isn't the case, I'd 
appreciate knowing where else I might need to "hook" things if this is 
the "only" approach to managing MTU of the wireless link.



All nodes are under my administrative control, so the "non-standard" MTU 
does not pose interoperability concerns for me.



Is there a cleaner way to manage this?


Jeff
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Current "OpenWrt Style Guide for DTS"?

[Jeff Kletsky]

I'm working on DTS definition for the ath79 target for GL.iNet 
AR300M-Lite (NOR) and AR750S (NOR and NAND both) and have some questions 
around current, OpenWrt best-practices for DTS definitions, as well as 
NAND partitioning.


Before wasting a lot of time on already-answered questions, are there 
some references as to the OpenWrt project preferences for how these are 
handled?


I've already located:

* https://openwrt.org/submitting-patches#dts_checklist

* https://openwrt.org/docs/guide-developer/defining-firmware-partitions

as well as the general information at

* 
https://devicetree-specification.readthedocs.io/en/latest/source-language.html


* https://elinux.org/Device_Tree_Mysteries

but I still have a few unanswered questions.


I'm willing to not only read the responses, but collect them to the 
OpenWrt wiki as well.



Jeff


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] INSTALL_SUID macro

[Jeff Kletsky]

On 1/22/19 3:26 AM, Daniel Golle wrote:

Hi Jo,
Hi everyone,

I was happy to see the addition of the INSTALL_SUID macro and now
wonder if it'd make sense to use fakeroot in order to allow installing
files for different users as well. For now, all files in rootfs are
always owned by root:root, and sometimes this is not what we want.


The ability to easily have services running with reduced privileges 
would be a welcome change. While I have also written some rather ugly 
scripts to change ownership at first boot, such a change would allow 
OpenWrt to ship and packages to install in an arguably more secure 
configuration.


For packages, it would seem that some changes in opkg might be needed to 
manage the proper additions to users/groups, as well as setting 
ownership and access during install. Personally, it wouldn't bother me 
if the added users/groups were not removed if the package was removed.



Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Current "OpenWrt Style Guide for DTS"?

[Jeff Kletsky]

On 1/21/19 9:26 PM, Rafał Miłecki wrote:

> On Mon, 21 Jan 2019 at 20:06, Jeff Kletsky  wrote:

>> but I still have a few unanswered questions
>> [around DTS "best practices" for OpenWrt].

>
> Ask?
>


Style Questions
===


Choice of Node Naming for Partitions


In some DTS files, the partitions are named using sequential integers.
In others, the offset of the partition is used.

* Which of the two is preferred?

    uboot: u-boot@0 {
    firmware@2 {
    art: art@ff {

vs.

    partition@0 {
    partition@1 {
    partition@2 {
    art: partition@3 {



Use of CPP #include vs. Device Tree /include/
=

* It appears that the CPP #include is preferred. Is this correct?



TAB vs. SPACE Indentation
=

* It appears that TAB indentation is being used. Is this correct?



Structure Questions
===


read-only Partitions


* Is it appropriate to mark the boot-loader partition as read-only?

* What about the art partition?

Doing so would seem to be able help prevent users following outdated
or ill-advised suggestions to write to their file systems using
low-level access.

Advanced users that, for some reason, want to overwrite these critical
partitions could always compile their own kernel with the restriction
removed.



---
Context for the following questions is discussed below the "8<" marker
TL;DR Stable references to partitions for DT modification when "inheriting"
---

Partition "label" Properties


Some of the "label" properties seem obviously named, like "firmware"
and "art" and I assume that the kernel and drivers key off of these.

* Is there a list of "reserved" and/or "preferred" values for the
  label property of the partitions?



Labels for Partition Nodes
==

I've noticed that there are some common labels for partition nodes in
use. A quick check of the ath79 platform shows

    addr, art, ART, caldata, eeprom, firmware, info, mac, mtdparts,
    nvram, partitions, uboot, ubootenv

* Is there a list of any of these that are "reserved" by general DTS
  files under OpenWrt?

At least as I understand DTS definition, these labels are not passed
to the kernel, but only during compilation.

* Assuming this is the case, is there any guidance for adding
  "commonly used" labels or "device-specific" labels?


8<

The questions above around the "label" property and labels arise
mainly because I'm working with devices that have both NOR and NAND
flash.  With the goal of easier maintainability and potential utility,
I'd like to define the partitioning *once* for a physical device and,
if needed, modify it for the NOR and NAND instances.

These devices that I'm working with can, once the boot loader is
running off NOR, boot either from NOR or from NAND (with fall-back if
the preferred one fails). Flashing both variants simultaneously has
benefits, but how to accomplish that may need to be the subject of
another thread.

At least as I (weakly) understand the use of

    label = "firmware"
    compatible = "denx,uimage"

from https://openwrt.org/docs/guide-developer/defining-firmware-partitions
there is some magic in the boot loader to know that the kernel is in the
"firmware" partition and that the kernel, once running, can split the
firmware partition into kernel and filesystem partitions, on the
fly. This would suggest to me that "it would be bad" to have two
partitions with the "firmware" label, and likely with the
"denx,uimage" compatible (or whatever the boot loader and kernel are
expecting for that device).

This line of thinking suggests to me that if one or both flash storage
partitions are defined in a common place, "the other" flash storage
needs to be "de-fanged" at least as a start.

Ideally, I'd like to be able to define the NOR partitioning in a
common .dsti for the device, then modify it for the NAND variant,
along the lines of:

    partition@0 {
    label = "u-boot";
    reg = <0x00 0x04>;
    read-only;
    };

    partition@4 {
    label = "u-boot-env";
    reg = <0x04 0x01>;
    };

    art: partition@5 {
    label = "art";
    reg = <0x05 0x01>;
    read-only;
    };

  

[OpenWrt-Devel] [PATCH 1/2] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

Resend as per M. Kreskin


From 2e3b968813e3862c5319c6c360781b0921d4b413 Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Sun, 20 Jan 2019 14:07:30 -0800
Subject: [PATCH 1/2] ath79: Add GL.iNet AR-300M-Lite

AR300M-Lite is single-Ethernet variant of the AR300M series
Its eth0 would otherwise be assigned to the WAN interface
making it unreachable firstboot or failsafe.

Installation instructions from OEM (OpenWrt variant):
* Install sysupgrade.bin using OEM's "Advanced" GUI (LuCI),
  * Do not preserve settings
* Access rebooted device via Ethernet at OpenWrt default address

Runtime-tested:  GL.iNet AR300M-Lite

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/base-files/etc/board.d/02_network |  1 +
 target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts |  8 
 target/linux/ath79/image/generic.mk  | 14 
--

 3 files changed, 21 insertions(+), 2 deletions(-)
 create mode 100644 
target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts


diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network

index 3eb0e413f3..fa947203f8 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -13,6 +13,7 @@ ath79_setup_interfaces()
 devolo,dvl1200i|\
 devolo,dvl1750c|\
 devolo,dvl1750i|\
+    glinet,ar300m-lite|\
 ocedo,koala|\
 ocedo,raccoon|\
 pcs,cap324|\
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts

new file mode 100644
index 00..b14d1a47a9
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
@@ -0,0 +1,8 @@
+/dts-v1/;
+
+#include "qca9531_glinet_gl-ar300m-nor.dts"
+
+/ {
+    compatible = "glinet,gl-ar300m-lite", "qca,qca9531";
+    model = "GL.iNet GL-AR300M-Lite";
+};
diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk

index 22ba5305b1..2021d83471 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -296,13 +296,23 @@ define Device/glinet_gl-ar150
 endef
 TARGET_DEVICES += glinet_gl-ar150

-define Device/glinet_gl-ar300m-nor
+define Device/glinet_gl-ar300m-common-nor
   ATH_SOC := qca9531
-  DEVICE_TITLE := GL.iNet GL-AR300M
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2
   IMAGE_SIZE := 16000k
   SUPPORTED_DEVICES += gl-ar300m
 endef
+
+define Device/glinet_gl-ar300m-lite
+  $(Device/glinet_gl-ar300m-common-nor)
+  DEVICE_TITLE := GL.iNet GL-AR300M-Lite
+endef
+TARGET_DEVICES += glinet_gl-ar300m-lite
+
+define Device/glinet_gl-ar300m-nor
+  $(Device/glinet_gl-ar300m-common-nor)
+  DEVICE_TITLE := GL.iNet GL-AR300M
+endef
 TARGET_DEVICES += glinet_gl-ar300m-nor

 define Device/glinet_gl-ar750s
--
2.11.0



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

[Jeff Kletsky]

Resend as per M. Kreskin


From f485678e7f37b3f2995fefc1e7c41794091bd73e Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Sun, 20 Jan 2019 14:48:09 -0800
Subject: [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED 
definitions


Change the "status" LED to proper GPIO 12 and "red" naming.

Remove GPIO 2 from definition as a USB LED.

GPIO 2 is used to control power to the USB socket, not an LED.
As such, PWM on the line or typical LED triggers are inappropriate.
Users who wish to control the USB power for custom applications
can manipulate the GPIO through code, or for example, export it
through /sys/class/gpio/export.

Runtime-tested:  GL.iNet AR300M-Lite

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi

index 2a0c4385cd..9baa6235b2 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
@@ -41,13 +41,6 @@
 leds {
     compatible = "gpio-leds";

-        usb {
-            label = "gl-ar300m:green:usb";
-            gpios = < 2 GPIO_ACTIVE_LOW>;
-            trigger-sources = <_port>;
-            linux,default-trigger = "usbport";
-        };
-
     wlan {
         label = "gl-ar300m:green:wlan";
         gpios = < 14 GPIO_ACTIVE_LOW>;
@@ -60,8 +53,8 @@
     };

     led_status: status {
-            label = "gl-ar300m:green:status";
-            gpios = < 3 GPIO_ACTIVE_LOW>;
+            label = "gl-ar300m:red:status";
+            gpios = < 12 GPIO_ACTIVE_LOW>;
     };
 };
 };
--
2.11.0



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: Remove NAND targets as no available drivers

[Jeff Kletsky]

From 7bd39bc01d8b0a03e796268f06f99b5a65fc353a Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Mon, 28 Jan 2019 08:25:52 -0800
Subject: [PATCH] ath79: Remove NAND targets as no available drivers

At this time, there are no drivers for NAND flash for ath79.

Remove the only present ath79 NAND target, GL.iNet AR300M,
as it will not boot due to lack of a suitable NAND driver.

From openwrt-devel on 2019-01-25

  The upstream SPI NAND framework is available in 4.19.

  As for raw nand driver for AR9344/QCA9558, the ar934x-nfc driver
  isn't ported to ath79 yet.

From https://github.com/openwrt/openwrt/pull/1428 on 2018-11-26

  (In reference to patches trying to support the GL.iNet AR300M NAND
   without using the spi-nand as it not present in Kernel 4.14)

  Please re-spin the patch as soon as we have kernel 4.19 support. The
  approach was already NAK'ed upstream and I don't see much gain in
  adding the hack if the next major kernel in OpenWrt will provide a
  suitable solution.
---
 target/linux/ath79/image/nand.mk | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/target/linux/ath79/image/nand.mk 
b/target/linux/ath79/image/nand.mk

index eee419194b..91873ef007 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -1,13 +1,2 @@
-define Device/glinet_gl-ar300m-nand
-  ATH_SOC := qca9531
-  DEVICE_TITLE := GL-AR300M (NAND)
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage 
kmod-usb-ledtrig-usbport

-  KERNEL_SIZE := 2048k
-  BLOCKSIZE := 128k
-  PAGESIZE := 2048
-  VID_HDR_OFFSET := 512
-  IMAGES += factory.ubi
-  IMAGE/sysupgrade.bin := sysupgrade-tar
-  IMAGE/factory.ubi := append-kernel | pad-to (KERNEL_SIZE) | 
append-ubi

-endef
-TARGET_DEVICES += glinet_gl-ar300m-nand
+# No NAND drivers available for the ath79 target at this time
+# (January, 2018)
--
2.11.0



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Remove NAND targets as no available drivers

[Jeff Kletsky]

(Resend due to garbled patch)

From 7bd39bc01d8b0a03e796268f06f99b5a65fc353a Mon Sep 17 00:00:00 2001

From: Jeff Kletsky 
Date: Mon, 28 Jan 2019 08:25:52 -0800
Subject: [PATCH] ath79: Remove NAND targets as no available drivers

At this time, there are no drivers for NAND flash for ath79.

Remove the only present ath79 NAND target, GL.iNet AR300M,
as it will not boot due to lack of a suitable NAND driver.

From openwrt-devel on 2019-01-25

  The upstream SPI NAND framework is available in 4.19.

  As for raw nand driver for AR9344/QCA9558, the ar934x-nfc driver
  isn't ported to ath79 yet.

From https://github.com/openwrt/openwrt/pull/1428 on 2018-11-26

  (In reference to patches trying to support the GL.iNet AR300M NAND
   without using the spi-nand as it not present in Kernel 4.14)

  Please re-spin the patch as soon as we have kernel 4.19 support. The
  approach was already NAK'ed upstream and I don't see much gain in
  adding the hack if the next major kernel in OpenWrt will provide a
  suitable solution.
---
 target/linux/ath79/image/nand.mk | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/target/linux/ath79/image/nand.mk 
b/target/linux/ath79/image/nand.mk

index eee419194b..91873ef007 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -1,13 +1,2 @@
-define Device/glinet_gl-ar300m-nand
-  ATH_SOC := qca9531
-  DEVICE_TITLE := GL-AR300M (NAND)
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage 
kmod-usb-ledtrig-usbport

-  KERNEL_SIZE := 2048k
-  BLOCKSIZE := 128k
-  PAGESIZE := 2048
-  VID_HDR_OFFSET := 512
-  IMAGES += factory.ubi
-  IMAGE/sysupgrade.bin := sysupgrade-tar
-  IMAGE/factory.ubi := append-kernel | pad-to (KERNEL_SIZE) | 
append-ubi

-endef
-TARGET_DEVICES += glinet_gl-ar300m-nand
+# No NAND drivers available for the ath79 target at this time
+# (January, 2018)
--
2.11.0



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] qca8x DSA: Configured Switch Sends Packets Out Wrong Interface

[Jeff Kletsky]

qca8x DSA: Configured Switch Sends Packets Out Wrong Interface

Using qca8k and ipqess on an EA8300 (ipq40xx) under Linux 4.19 based
on patches from chunkeey's staging tree[1] as well as a patch to
resolve the NPE issue[2].

Once the switch has been configured (this is *after* the power-on
config has been overridden), I see that packets are being sent out
over ports that aren't associated with the bridge. As these packets
are not seen with tcpdump on the underlying interface, I believe that
they are traveling through the switch fabric.

 * Am I configuring the bridge as expected?

 * Are there patches that I am missing?




I have tried configuring the bridge both using /etc/config/network (no
switch-related sections) as well as "manually" with iproute2
commands and see the same behavior in both cases. In both cases,
`brctl show` and `bridge link` output is consistent with that
expected; the expected interfaces are present and those not involved
in the bridge are not present.

The initial test was for the "desired" configuration:

 * lan1  stand-alone 192.168.1.1/24
 * lan2    -|
 * lan3    -| -- bridged
 * lan4    -|
 * wan0.10 -|
 * wan0.  -- other trunked VLANs -- to Cisco SG300

config interface 'lan'
   option type 'bridge'
   option ifname 'lan2 lan3 lan4 wan0.10'
   option proto 'static'
   option stp '1'
   option ipaddr '10.X.Y.Z'
   option netmask '255.255.255.0'

(wan0.10 configured and brought up elsewhere)


This appeared to work for connectivity to the device itself, but a
wired client plugged into lan2 was unable to obtain a DHCP lease from
the DHCP server connected to the Cisco SG300, leading to this exploration.

Examining the packets seen by this client suggested that they were
being sent out lan2-4 as tagged VLAN 10 (unexpected).

(I need to re-confirm this as the EA8300 at the time "won" STP root.)


I then removed wan.10 from the bridge and connected lan4 to
an untagged source of the 10.X.Y.Z/24 traffic from the SG300

 * lan1 - stand-alone 192.168.1.1/24
 * lan2 -|
 * lan3 -| -- bridged
 * lan4 -|

config interface 'lan'
   option type 'bridge'
   option ifname 'lan2 lan3 lan4'
   option proto 'static'
   option stp '1'
   option ipaddr '10.X.Y.Z'
   option netmask '255.255.255.0'

Looking at the packets on the lan1 port, traffic that was clearly from
the subnet associated with the 10 VLAN was being seen (unexpected).

Looking at lan1 with `tcpdump -ni lan1` only showed an occasional ARP
related to the 192.168.1.1/24 subnet (as expected).


This suggests to me that the packets are flowing through the switch
fabric, not the CPU.


Configuring lan1 as a bridge rather than a direct-accessed interface
did not change the behavior.

(This continued to occur after changing the STP priority of the SG300,
rebooting the router, and confirming that the SG300 was the STP root.)


Configuring with iproute2 commands after removing the applicable
interface section from /etc/config/network did not change the behavior

    #!/bin/sh

    ip addr add 192.168.1.1/24 dev lan1

    for if in lan1 lan2 lan3 lan4 wan0 ; do
    ip link set ${if} up
    done

    ip link add name lan-br type bridge
    ip link set lan-br type bridge stp_state 1

    ip addr add 10.X.Y.Z/24 dev lan-br

    ip link set lan-br up

    for if in lan2 lan3 lan4 ; do
    ip link set ${if} master lan-br
    done



Based on these observations, I believe that the switch fabric is not
being properly configured, that I am missing patches causing the
former, or that I am somehow not configuring the bridge properly.



Any suggestions as to how to proceed?

Jeff



[1] Patches from chunkeey's staging tree:

f42d8ea703 ipq40xx: include ipq40xx-ized qca8k version
35cacbdc1e ipq40xx: fix NPE related to bogus use of fixed phy
b696da2763 ipq40xx: extend DT mdio node to be more accessible
1c8d4e491b ipq40xx: add ipqess ethernet driver
23cf41880f ipq40xx: add resets for individual MAC1-5 and PSGMII
7bf4edca65 ipq40xx: decouple mdio-ipq40xx and ar40xx
415f2c04c4 phytool: add phytool utility

merge-base with master is b61495409b
CommitDate: Thu Mar 14 22:55:06 2019 +0100




[2] 730-HACK-prevent-panic-adding-vlan-to-bridge.patch
after Florian Fainelli,
[PATCH] net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation


--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,7 +255,10 @@ int dsa_port_vlan_add(struct dsa_port *d
 if (netif_is_bridge_master(vlan->obj.orig_dev))
     return -EOPNOTSUPP;

-    if (br_vlan_enabled(dp->bridge_dev))
+    /* Can be called from dsa_slave_port_obj_add() or
+     * dsa_slave_vlan_rx_add_vid()
+     */
+    if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
     return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, );

 return 0;
@@ -270,10 +273,13 @@ int dsa_port_vlan_del(struct dsa_port *d
     .vlan = vlan,
 };

-    if (netif_is_bridge_master(vlan->obj.orig_dev))
+    if (vlan->obj.orig_dev && 

Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

[Jeff Kletsky]

On 2/28/19 3:39 AM, Andreas Ziegler wrote:

Jeff Kletsky schrieb am 25.02.19 um 02:22:

On 2/24/19 4:21 PM, Andreas Ziegler wrote:

Hi Jeff,

thanks for your suggested change!
Although i agree with your change regarding USB GPIO, i don't with the
other part.

Using stock/vendor firmware, GPIO 12 is a green system/status LED and
GPIO 14 is a red wifi LED.

I just sent a patch to the list which fixes this in ar71xx target, maybe
you can update your patch for ath79, too.
see "[PATCH] ar71xx: GL.iNet AR300M family: correct LED definitions"

Regards

Andreas


Thank you for taking care of the ar71xx target.


I agree that the device has a red LED and have confirmed
with the manufacturer on this.  Alas, I'm behind in
updating the patch.


Jeff

I took the liberty to send a Patch fixing this to the list.
After it is merged, i'll also try to rebase your patch for the
Lite-Version of the device if you don't mind.

Regards

Andreas


With three devices in pieces on my desk, that would be greatly appreciated.

No need for dueling patches!

The AR300M-Lite _does_ have different LED colors. Here's what I put
together this morning, built, and booted on my AR300M-Lite

target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts


/dts-v1/;

#include "qca9531_glinet_gl-ar300m-nor.dts"

/ {
    compatible = "glinet,gl-ar300m-lite", "qca,qca9531";
    model = "GL.iNet GL-AR300M-Lite";
};

// GL-AR300M-Lite has different LED colors than the non-Lite version

_status {
    label = "gl-ar300m-lite:red:status";
};

_lan {
    label = "gl-ar300m-lite:green:lan";
};

_wlan {
    label = "gl-ar300m-lite:green:wlan";
};



and the corresponding, referenced segment from
target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi


    leds {
        compatible = "gpio-leds";

        // Colors from non-Lite versions

        led_status: status {
            label = "gl-ar300m:green:status";
            gpios = < 3 GPIO_ACTIVE_LOW>;
        };

        led_lan: lan {
            label = "gl-ar300m:green:lan";
            gpios = < 13 GPIO_ACTIVE_LOW>;
        };

        led_wlan: wlan {
            label = "gl-ar300m:red:wlan";
            gpios = < 14 GPIO_ACTIVE_LOW>;
            linux,default-trigger = "phy0tpt";
        };
    };



Jeff




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

Update of patch based on feedback that the variants
have different colors for the LEDs. Confirmed with
OEM that they are not all green, in contrast to the
presently mach file in OEM's source.

This patch is now self-contained.

Patch [2/2] in this series should be withdrawn.

See also https://patchwork.ozlabs.org/patch/1049396/

Jeff Kletsky


From 5536569e7cf589d3c64e1405937c56c931f30eaa Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Wed, 16 Jan 2019 12:32:15 -0800
Subject: [PATCH] ath79: Add GL.iNet AR300M-Lite

AR300M-Lite is single-Ethernet variant of the AR300M series
Its eth0 would otherwise be assigned to the WAN interface
making it unreachable firstboot or failsafe.

Installation instructions from OEM (OpenWrt variant):
* Install sysupgrade.bin using OEM's "Advanced" GUI (LuCI),
   * Do not preserve settings
   * Access rebooted device via Ethernet at OpenWrt default address

Runtime-tested:  GL.iNet AR300M-Lite

Signed-off-by: Jeff Kletsky 
---
 .../linux/ath79/base-files/etc/board.d/02_network  |  1 +
 .../ath79/dts/qca9531_glinet_gl-ar300m-lite.dts    | 22 +
 .../ath79/dts/qca9531_glinet_gl-ar300m-nand.dts    | 34 -
 .../ath79/dts/qca9531_glinet_gl-ar300m-nor.dts | 39 ---
 .../linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi  | 57 
+++---

 target/linux/ath79/image/generic.mk    | 14 +-
 6 files changed, 84 insertions(+), 83 deletions(-)
 create mode 100644 
target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts


diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network

index f1171695bd..a275af0e9e 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -13,6 +13,7 @@ ath79_setup_interfaces()
 devolo,dvl1200i|\
 devolo,dvl1750c|\
 devolo,dvl1750i|\
+    glinet,ar300m-lite|\
 ocedo,koala|\
 ocedo,raccoon|\
 pcs,cap324|\
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts

new file mode 100644
index 00..fba08e4295
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
@@ -0,0 +1,22 @@
+/dts-v1/;
+
+#include "qca9531_glinet_gl-ar300m-nor.dts"
+
+/ {
+    compatible = "glinet,gl-ar300m-lite", "qca,qca9531";
+    model = "GL.iNet GL-AR300M-Lite";
+};
+
+// GL-AR300M-Lite has different LED colors than the non-Lite version
+
+_status {
+    label = "gl-ar300m-lite:red:status";
+};
+
+_lan {
+    label = "gl-ar300m-lite:green:lan";
+};
+
+_wlan {
+    label = "gl-ar300m-lite:green:wlan";
+};
\ No newline at end of file
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts

index 9e78f83a76..26c30f2b72 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts
@@ -8,42 +8,8 @@
 };

  {
-    status = "okay";
 num-cs = <1>;

-    flash@0 {
-        compatible = "winbond,w25q128", "jedec,spi-nor";
-        reg = <0>;
-        spi-max-frequency = <2500>;
-
-        partitions {
-            compatible = "fixed-partitions";
-            #address-cells = <1>;
-            #size-cells = <1>;
-
-            partition@0 {
-                label = "u-boot";
-                reg = <0x00 0x04>;
-                read-only;
-            };
-
-            partition@1 {
-                label = "u-boot-env";
-                reg = <0x04 0x01>;
-            };
-
-            partition@2 {
-                label = "reserved";
-                reg = <0x05 0xfa>;
-            };
-
-            art: partition@3 {
-                label = "art";
-                reg = <0xff 0x01>;
-            };
-        };
-    };
-
 flash@1 {
     compatible = "spinand,mt29f";
     reg = <1>;
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts

index 6b77af0401..02196cf9c4 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts
@@ -9,42 +9,3 @@
 compatible = "glinet,gl-ar300m-nor", "qca,qca9531";
 model = "GL.iNet GL-AR300M (NOR)";
 };
-
- {
-    status = "okay";
-    num-cs = <0>;
-
-    flash@0 {
-        compatible = "winbond,w25q128", "jedec,spi-nor";
-        reg = <0>;
-        spi-max-frequency = <2500>;
-
-        partitions {
-            compatible = "fixed-partitions";
-            #address-cells = <1>;
-           

Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

[Jeff Kletsky]

Patch [2/2] in this series should be withdrawn.

See also

Patch [1/2] of this series

https://patchwork.ozlabs.org/patch/1049396/


Jeff Kletsky


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

From: Jeff Kletsky 

AR300M-Lite is single-Ethernet variant of the AR300M series
Its eth0 would otherwise be assigned to the WAN interface
making it unreachable firstboot or failsafe.

Installation instructions from OEM (OpenWrt variant):
* Install sysupgrade.bin using OEM's "Advanced" GUI (LuCI),
   * Do not preserve settings
   * Access rebooted device via Ethernet at OpenWrt default address

Runtime-tested:  GL.iNet AR300M-Lite

Signed-off-by: Jeff Kletsky 
---
 .../linux/ath79/base-files/etc/board.d/02_network  |  1 +
 .../ath79/dts/qca9531_glinet_gl-ar300m-lite.dts| 22 +
 .../ath79/dts/qca9531_glinet_gl-ar300m-nand.dts| 34 -
 .../ath79/dts/qca9531_glinet_gl-ar300m-nor.dts | 39 ---
 .../linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi  | 57 +++---
 target/linux/ath79/image/generic.mk| 14 +-
 6 files changed, 84 insertions(+), 83 deletions(-)
 create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network
index f1171695bd..a275af0e9e 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -13,6 +13,7 @@ ath79_setup_interfaces()
devolo,dvl1200i|\
devolo,dvl1750c|\
devolo,dvl1750i|\
+   glinet,ar300m-lite|\
ocedo,koala|\
ocedo,raccoon|\
pcs,cap324|\
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
new file mode 100644
index 00..fba08e4295
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
@@ -0,0 +1,22 @@
+/dts-v1/;
+
+#include "qca9531_glinet_gl-ar300m-nor.dts"
+
+/ {
+   compatible = "glinet,gl-ar300m-lite", "qca,qca9531";
+   model = "GL.iNet GL-AR300M-Lite";
+};
+
+// GL-AR300M-Lite has different LED colors than the non-Lite version
+
+_status {
+   label = "gl-ar300m-lite:red:status";
+};
+
+_lan {
+   label = "gl-ar300m-lite:green:lan";
+};
+
+_wlan {
+   label = "gl-ar300m-lite:green:wlan";
+};
\ No newline at end of file
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts
index 9e78f83a76..26c30f2b72 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts
@@ -8,42 +8,8 @@
 };
 
  {
-   status = "okay";
num-cs = <1>;
 
-   flash@0 {
-   compatible = "winbond,w25q128", "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <2500>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {
-   label = "u-boot";
-   reg = <0x00 0x04>;
-   read-only;
-   };
-
-   partition@1 {
-   label = "u-boot-env";
-   reg = <0x04 0x01>;
-   };
-
-   partition@2 {
-   label = "reserved";
-   reg = <0x05 0xfa>;
-   };
-
-   art: partition@3 {
-   label = "art";
-   reg = <0xff 0x01>;
-   };
-   };
-   };
-
flash@1 {
compatible = "spinand,mt29f";
reg = <1>;
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts
index 6b77af0401..02196cf9c4 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts
@@ -9,42 +9,3 @@
compatible = "glinet,gl-ar300m-nor", "qca,qca9531";
model = "GL.iNet GL-AR300M (NOR)";
 };
-
- {
-   status = "okay";
-   num-cs = <0>;
-
-   flash@0 {
-   compatible = "winbond,w25q128", "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <2500>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {

Re: [OpenWrt-Devel] [PATCH 1/2] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

(Resend using git-send-email to resolve mangling)

Update of patch based on feedback that the variants
have different colors for the LEDs. Confirmed with
OEM that they are not all green, in contrast to the
presently mach file in OEM's source.

This patch is now self-contained.

Patch [2/2] in this series should be withdrawn.

See also https://patchwork.ozlabs.org/patch/1049396/

Jeff Kletsky


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

As Patchwork has decided this is a new patch series
rather than a continuation of the previous series:

<https://patchwork.ozlabs.org/patch/1031665/>

<https://patchwork.ozlabs.org/patch/1031668/>

those two patches may be withdrawn.


With apologies for the clutter,

Jeff


On 3/1/19 2:18 PM, Jeff Kletsky wrote:

From: Jeff Kletsky 

AR300M-Lite is single-Ethernet variant of the AR300M series
Its eth0 would otherwise be assigned to the WAN interface
making it unreachable firstboot or failsafe.

Installation instructions from OEM (OpenWrt variant):
* Install sysupgrade.bin using OEM's "Advanced" GUI (LuCI),
* Do not preserve settings
* Access rebooted device via Ethernet at OpenWrt default address

Runtime-tested:  GL.iNet AR300M-Lite

Signed-off-by: Jeff Kletsky 
---

[...]

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Add GL.iNet GL-AR300M Family to /etc/board.d/01_leds

[Jeff Kletsky]

On 3/2/19 9:32 AM, Piotr Dymacz wrote:

Hi Jeff,

On 02.03.2019 18:01, Jeff Kletsky wrote:

[...]]
-Lite variant uses language-independent Ethernet
as its single port may be configured as WAN or LAN,
depending use case.


This introduces unnecessary inconsistency. If you look at the whole 
file you will find out that UCI section names (and LED name within the 
section) follow sysfs LED names.


Please, follow this common pattern _or_ update LED names if they don't 
match their functions.


[...]

Also, please make sure used LED names are correct.
'qca9531_glinet_gl-ar300m.dtsi' doesn't contain 'gl-ar300m:green:wan'...



Piotr,

Thanks for the constructive comments.

Patches prepared and rebased on current `master`.

Waiting for word on a robust way to deliver them so that Patchwork
properly associates them with each of the two existing patches, rather
than creating new ones (when I've used `git email-patch --in-reply-to=`)
or mangling them (as seems to happen if I use `git format-patch` and
Thunderbird).


Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: Add GL.iNet GL-AR300M Family to /etc/board.d/01_leds

[Jeff Kletsky]

From: Jeff Kletsky 

Previously missing, add the three variants;
-nand, -nor, -lite to the definitions in 01_leds

-Lite variant uses language-independent Ethernet
as its single port may be configured as WAN or LAN,
depending use case.

Non-lite variants thanks to Andreas Ziegler
https://patchwork.ozlabs.org/patch/1049396/

Runtime-tested: GL.iNet AR300M-Lite

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/base-files/etc/board.d/01_leds | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds 
b/target/linux/ath79/base-files/etc/board.d/01_leds
index a56fe58f76..a5c23e1f84 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -63,6 +63,13 @@ glinet,gl-ar150)
ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth0"
ucidef_set_led_switch "lan" "LAN" "$boardname:green:lan" "switch0" 
"0x02"
;;
+glinet,gl-ar300m-nand|\
+glinet,gl-ar300m-nor)
+   ucidef_set_led_netdev "lan" "LAN" "gl-ar300m:green:wan" "eth0"
+   ;;
+glinet,gl-ar300m-lite)
+   ucidef_set_led_netdev "ethernet" "Ethernet" "gl-ar300m-lite:green:wan" 
"eth0"
+   ;;
 glinet,gl-x750)
ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth0"
;;
-- 
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Patchwork and git send-email

[Jeff Kletsky]

How does one get Patchwork to properly associate an update or addendum
to an existing patch / series when sent from git send-email?


While I have set --in-reply-to=''
and see the In-Reply-To and References headers both prior to sending
as well as in the delivered messages, Patchwork failed to associate
the messages with the existing patch series.


Would someone share a set of command-line arguments and a manner for
selecting their parameters that consistently works to:

* Have the "cover letter" included in the patch series

* Update an existing patch

* Add an additional patch to an existing patch series


It seems that, at least at one time, sending patches to the mailing
list was preferred over pull requests on GitHub. Is this still the
case?

Jeff


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: Select better ch/VHT for sub-band radios

[Jeff Kletsky]

On 3/3/19 2:44 PM, Jeff Kletsky wrote:


From: Jeff Kletsky 

Certain wireless devices have limitations on the channels
on which they can operate. For some of these devices,
the present default of ch. 36 (VHT80) is outside of the
capabilities of the device.

For 5 GHz, provide a default of the first non-disabled channel
returned by `iw phy $phy info`. For VHT-capable devices,
Select VHT20 if that channel may  not be "clear" for either
VHT40 or VHT80 due to either band edges or DFS restrictions.

Based on hostap src/common/hw_features_common.c

VHT80: 36, 52, 100, 116, 132, 149
VHT40: 44, 60, 108, 124, 140, 157, 165, 184, 192

Adding in band edges, DFS, and limited-use bands reduces this to:

VHT80: 36, 149
VHT40: 44, 157

Runtime-tested: TP-Link Archer C7v2, GL.iNet AR750S
Runtime-tested: Linksys EA8300 (QCA9888; ch. 100 and above only)

Signed-off-by: Jeff Kletsky 


[...]

If and when https://patchwork.ozlabs.org/patch/1051204/ is accepted,
this may need a change to detect the presence of 5 GHz capabilities.

The existing check in `master` for '5180 MHz' may fail, depending on
the channels permitted by the DT restriction and how `iw` renders them
in its output.


One approach (untested against patch/1051204 at this time) would be to 
change


fgrep -q '5180 MHz'

to

egrep -q '5[0-9][0-9][0-9] MHz'

Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ARM: Overriding Specific bootargs

[Jeff Kletsky]

I could use some guidance to either a solution or an approach to
wresting the OEM bootloader args into an "OpenWrt-compatible" form.

(ARM; ipq40xx, in particular)

TL;DR

    What's the "best" way to override `root=ubi0:ubifs` from the
    bootloader to `root=/dev/ubiblock0_0` or otherwise make the
    OpenWrt kernel boot without changing the U-Boot environment?

    and/or

    How can I configure an OpenWrt build to have the kernel be able to
    boot with `root=ubi0:ubifs` (and not break everything that might
    expect the UBI volume be named `rootfs`)?


While I could control the U-Boot environment from an installed OpenWrt
Instance, that doesn't seem like it could provide a "serial-less"
OEM-to-OpenWrt transition.

That the device (Linksys EA8300) is a dual-firmware device and could
be booting from either partition, at least as far as I can tell, makes
a hard-coded kernel command line an unsuitable approach.


What I'm looking for is how to get from the information provided by
the bootloader about which partition is "active" into the kernel's
command line so that it can mount the proper root.

From the OEM U-Boot:

    init=/sbin/init rootfstype=ubifs ubi.mtd=NN,2048 root=ubi0:ubifs
    rootwait rw

where NN is 11 or 13, depending on selected firmware version.


What my current build is looking for:

    ubi.mtd=NN root=/dev/ubiblock0_0



Apparently, for ARM architectures, "the bootloader is always
right" [1][2][3], adding additional challenges.

Using chosen/bootargs was confirmed to be "ignored" if the bootloader
provided bootargs.



Using chosen/bootargs-append didn't help as the result still tries to
boot from ubi0:ubifs

    init=/sbin/init rootfstype=ubifs ubi.mtd=11,2048 root=ubi0:ubifs
    rootwait rw root=/dev/ubiblock0_0 clk_ignore_unused



Testing from the boot loader with

    ubi.mtd=NN root=ubi0:rootfs

didn't boot, as apparently the kernel isn't finding the UBI volume by
name, at least as I have it configured.



I've looked at a few of the ARM Kconfig options as a "quick hack", but
none seemed to be able to get the "right" bootargs to the kernel:

* ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND
* CMDLINE_EXTEND
* CONFIG_MANGLE_BOOTARGS

This kind of "heavy handed" approach has problems with impacting other
devices on the same target, or maintenance problems as there doesn't
seem to be a way to "patch" the kernel .config for a single device.



I found, looked at, and tried

target/linux/ipq806x/patches-4.14/0067-generic-Mangle-bootloader-s-kernel-arguments.patch

which provides

* ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER

but it extracts a number from the `root=` argument from the bootloader
command line and doesn't *remove* the `root=` argument.

(The three variants of this patch are all similar in function.)



=

I can see a couple ways forward with this that allow end users to
install/revert OpenWrt without cracking the case and installing a
serial connection:

* Modify the UBI bundle to change the name of the volume from "rootfs"
  to "ubifs" (and all kernel and downstream changes needed)

* Consider the task of adding arg /removal/ to something like
  "Mangle-bootloader-s-kernel-arguments.patch" (which would allow
  "replacement" from chosen/bootargs-append)


Suggestions of the path to explore first, or other approaches, are welcome


Jeff


=

DTS using `append-rootblock` in `master`
from `fgrep -r append-rootblock target`:

armada-385-linksys-venom.dts   append-rootblock = "root=/dev/mtdblock"
qcom-ipq8065-nbg6817.dts   append-rootblock = "root=/dev/mmcblk0p";
qcom-ipq8064-ea8500.dts    append-rootblock = "ubi.mtd="



is not directly applicable, as its U-Boot environment has the "right" root=

    init=/sbin/init rootfstype=squashfs
    ubi.mtd=11,2048 ubi.block=0,0 root=/dev/ubiblock0_0 rootwait ro


=

[1] 



[2] 



[3] arch/arm/boot/compressed/atags_to_fdt.c


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

[Jeff Kletsky]

On 2/24/19 4:21 PM, Andreas Ziegler wrote:

Hi Jeff,

thanks for your suggested change!
Although i agree with your change regarding USB GPIO, i don't with the
other part.

Using stock/vendor firmware, GPIO 12 is a green system/status LED and
GPIO 14 is a red wifi LED.

I just sent a patch to the list which fixes this in ar71xx target, maybe
you can update your patch for ath79, too.
see "[PATCH] ar71xx: GL.iNet AR300M family: correct LED definitions"

Regards

Andreas



Thank you for taking care of the ar71xx target.


I agree that the device has a red LED and have confirmed
with the manufacturer on this.  Alas, I'm behind in
updating the patch.


Jeff




Jeff Kletsky schrieb am 28.01.19 um 03:54:

Resend as per M. Kreskin


 From f485678e7f37b3f2995fefc1e7c41794091bd73e Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Sun, 20 Jan 2019 14:48:09 -0800
Subject: [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED
definitions

Change the "status" LED to proper GPIO 12 and "red" naming.

Remove GPIO 2 from definition as a USB LED.

GPIO 2 is used to control power to the USB socket, not an LED.
As such, PWM on the line or typical LED triggers are inappropriate.
Users who wish to control the USB power for custom applications
can manipulate the GPIO through code, or for example, export it
through /sys/class/gpio/export.

Runtime-tested:  GL.iNet AR300M-Lite

Signed-off-by: Jeff Kletsky 
---
  target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi | 11 ++-
  1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
index 2a0c4385cd..9baa6235b2 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
@@ -41,13 +41,6 @@
  leds {
      compatible = "gpio-leds";

-        usb {
-            label = "gl-ar300m:green:usb";
-            gpios = < 2 GPIO_ACTIVE_LOW>;
-            trigger-sources = <_port>;
-            linux,default-trigger = "usbport";
-        };
-
      wlan {
          label = "gl-ar300m:green:wlan";
          gpios = < 14 GPIO_ACTIVE_LOW>;
@@ -60,8 +53,8 @@
      };

      led_status: status {
-            label = "gl-ar300m:green:status";
-            gpios = < 3 GPIO_ACTIVE_LOW>;
+            label = "gl-ar300m:red:status";
+            gpios = < 12 GPIO_ACTIVE_LOW>;
      };
  };
  };


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mac80211: Select better ch/VHT for sub-band radios

[Jeff Kletsky]

From: Jeff Kletsky 

Certain wireless devices have limitations on the channels
on which they can operate. For some of these devices,
the present default of ch. 36 (VHT80) is outside of the
capabilities of the device.

For 5 GHz, provide a default of the first non-disabled channel
returned by `iw phy $phy info`. For VHT-capable devices,
Select VHT20 if that channel may  not be "clear" for either
VHT40 or VHT80 due to either band edges or DFS restrictions.

Based on hostap src/common/hw_features_common.c

VHT80: 36, 52, 100, 116, 132, 149
VHT40: 44, 60, 108, 124, 140, 157, 165, 184, 192

Adding in band edges, DFS, and limited-use bands reduces this to:

VHT80: 36, 149
VHT40: 44, 157

Runtime-tested: TP-Link Archer C7v2, GL.iNet AR750S
Runtime-tested: Linksys EA8300 (QCA9888; ch. 100 and above only)

Signed-off-by: Jeff Kletsky 
---
 package/kernel/mac80211/files/lib/wifi/mac80211.sh | 42 ++
 1 file changed, 36 insertions(+), 6 deletions(-)
 mode change 100644 => 100755 package/kernel/mac80211/files/lib/wifi/mac80211.sh

diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh 
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
old mode 100644
new mode 100755
index 511a9188db..59c765d616
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -59,8 +59,12 @@ check_mac80211_device() {
 }
 
 detect_mac80211() {
-   devidx=0
+   local iw_phy_info
+
config_load wireless
+
+   devidx=0
+
while :; do
config_get type "radio$devidx" type
[ -n "$type" ] || break
@@ -81,13 +85,39 @@ detect_mac80211() {
htmode=""
ht_capab=""
 
-   iw phy "$dev" info | grep -q 'Capabilities:' && htmode=HT20
+   iw_phy_info=$( iw phy "${dev}" info )
+
+   echo "${iw_phy_info}" | fgrep -q 'Capabilities:' && htmode=HT20
+
+   if echo "${iw_phy_info}" | fgrep -q '5180 MHz' ; then
 
-   iw phy "$dev" info | grep -q '5180 MHz' && {
mode_band="a"
-   channel="36"
-   iw phy "$dev" info | grep -q 'VHT Capabilities' && 
htmode="VHT80"
-   }
+
+   channel=$( echo "${iw_phy_info}" | \
+   fgrep -v disabled | \
+   sed -Ene 's/^.+ 5[0-9]{3} MHz 
\[([1-9][0-9]{1,2})\].*$/\1/p' | \
+   head -n 1 )
+
+   if [ -z "${channel}" ] ; then
+   logger -p warn -t detect_mac80211 \
+   "No enabled channel found in `iw phy 
${dev} info`"
+   fi
+
+   if echo "${iw_phy_info}" | fgrep -q 'VHT Capabilities'
+   then
+   case "$channel" in
+   36 | 149 )
+   htmode="VHT80"
+   ;;
+   44 | 157 )
+   htmode="VHT40"
+   ;;
+   *)
+   htmode="VHT20"
+   ;;
+   esac
+   fi
+   fi  # 5 GHz
 
[ -n "$htmode" ] && ht_capab="set 
wireless.radio${devidx}.htmode=$htmode"
 
-- 
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

[Jeff Kletsky]

On 2/25/19 11:25 AM, Sven Eckelmann wrote:

On Monday, 25 February 2019 15:08:15 CET Jeff Kletsky wrote:

Mesh is broken using ath10k-ct?
https://bugs.openwrt.org/index.php?do=details_id=2123

[...]

* The "classic" drivers/firmware fail on or after the indicated commit

  CONFIG_PACKAGE_ath10k-firmware-qca9887=y
  CONFIG_PACKAGE_kmod-ath10k=y
  # CONFIG_PACKAGE_kmod-ath10k-ct is not set


That the CT drivers/firmware don't support 802.11s mesh
isn't really an OpenWrt issue.

That there is a regression in overall system capability
that "kills" connectivity is a signficant concern.

* Can you confirm that it works with ath10k-ct but not with ath10k?
* And can you confirm that changing encryption to none has no effect on the
   problem.
* Can you confirm that reverting commit cd93b83ad927 ("ath10k: support for
   multicast rate control") [1] in ath10k fixes this problem?
* Can you confirm that manually setting mcast_rate to 18000  in the mesh wifi-
   iface fixes the problem?

 config wifi-iface 'mesh0'
 option device 'radio0'
 option ifname 'mesh0'
 option network 'nwi_mesh0'
 option mode 'mesh'
 option mesh_id 'TestMesh'
 option mesh_fwding '1'
 option mcast_rate '18000'
 option encryption 'none'

* can you confirm that it lo



Testing performed off `master` [1] on a mesh of Archer C7v2 units and 
one "test" unit.


* Setting `option mcast_rate '18000'` allows the mesh to connect and 
ping for ath10k "classic"


* https://github.com/openwrt/openwrt/pull/1861 allows the mesh to 
connect and ping for ath10k "classic"


* ath10k-ct drivers/firmware continue to be unable to support 802.11s on 
5 GHz on the Archer C7v2


    * The output of `iw phy` is ambiguous on mesh support for the CT 
drivers/firmware for 5 GHz phy

    * `Supported interface modes:` includes `* mesh point`
    * `valid interface combinations:` seems to contradict
    * `* #{ managed, P2P-client } <= 16, #{ P2P-GO } <= 3, #{ 
AP } <= 7, #{ IBSS } <= 1,`



Additional information at

https://github.com/openwrt/openwrt/pull/1861 -- shows significant 
benefit "classic"


https://github.com/openwrt/openwrt/pull/1862 -- "CT" drivers/firmware


Additional testing available on (reasonable) request


Jeff Kletsky


[1] "Current" builds based off

commit fe90e48c39c46b3c253b65f38e392c43f6abe2f0 (openwrt/master, 
openwrt/HEAD, master)

Author: Piotr Dymacz 
Date:   Tue Feb 26 13:04:54 2019 +0100


Previous reference points and other units are off master, at or prior to

commit b14289354adb1f07dc9904bfdbc43e6b0bf17a92 (tag: 80211s-good)
Author: John Crispin 
Date:   Wed Sep 5 14:51:44 2018 +0200





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

[Jeff Kletsky]

On 2/25/19 5:32 AM, Steve Brown wrote:

On Mon, 2019-02-25 at 12:10 +0100, Daniel Engberg wrote:

Hi,


Mesh is broken using ath10k-ct?
https://bugs.openwrt.org/index.php?do=details_id=2123


The combination of ath10k-ct and firmware ver 10.2.4-1.0-00043 works on
my QCA9880 (tp-link archer a7 v5).

According to debugfs, ath10k/wmi_services claims the ath10k-ct firmware
(10.1-ct-8x-__fW-022-1bbfa151) doesn't support mesh.

"WMI_SERVICE_MESH_11S -"

Steve



Two pieces of breakage there, only the second is the showstopper for me:

* The CT drivers/firmware do not support mesh, as confirmed above

* The "classic" drivers/firmware fail on or after the indicated commit

    CONFIG_PACKAGE_ath10k-firmware-qca9887=y
    CONFIG_PACKAGE_kmod-ath10k=y
    # CONFIG_PACKAGE_kmod-ath10k-ct is not set


That the CT drivers/firmware don't support 802.11s mesh
isn't really an OpenWrt issue.

That there is a regression in overall system capability
that "kills" connectivity is a signficant concern.


Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ipq40xx: bootarg Manipulation Failing

[Jeff Kletsky]

On 3/14/19 3:39 PM, Jeff Kletsky wrote:


I'm trying to bring up an IPQ4019-based Linksys EA8300 and have a
challenge with the OEM bootargs from U-Boot. While they could be
modified once in OpenWrt, I'm hoping to provide a serial-less way
for users to easily flash OpenWrt from the OEM web interface.

[...]

TL;DR
=

  * I've tried 0067-generic-Mangle-bootloader-s-kernel-arguments.patch
    It doesn't seem to be able to modify the FDT

  * Can I better confirm if atags_to_fdt() is executing?

  * If it is executing, what am I not doing properly to modify the FDT?

  * If it is not executing:
    * Is there an example of command-line modification in `init`?
    * Is there a better way, short of changing U-Boot, to make the 
change?

[...]



While still something of a puzzle, I've been able to find a solution
in early `init`.

For future manipulations of this sort, working in `init/` where there
are fuller memory-management facilities, access to richer C calls,
in-built command-line parsing, as well as a console to be able to
more easily trace and understand execution flow.


Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

From: Jeff Kletsky 

AR300M-Lite is single-Ethernet variant of the AR300M series
Its eth0 would otherwise be assigned to the WAN interface
making it unreachable firstboot or failsafe.

Installation instructions from OEM (OpenWrt variant):
* Install sysupgrade.bin using OEM's "Advanced" GUI (LuCI),
   * Do not preserve settings
   * Access rebooted device via Ethernet at OpenWrt default address

Add previously missing LED defaults for all three variants;
-nand, -nor, -lite to the definitions in 01_leds

Non-lite variants thanks to Andreas Ziegler
https://patchwork.ozlabs.org/patch/1049396/

Runtime-tested:  GL.iNet AR300M-Lite

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/base-files/etc/board.d/01_leds  |  7 +++
 .../linux/ath79/base-files/etc/board.d/02_network  |  1 +
 .../ath79/dts/qca9531_glinet_gl-ar300m-lite.dts| 22 +
 .../ath79/dts/qca9531_glinet_gl-ar300m-nand.dts| 34 -
 .../ath79/dts/qca9531_glinet_gl-ar300m-nor.dts | 39 ---
 .../linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi  | 57 +++---
 target/linux/ath79/image/generic.mk| 14 +-
 7 files changed, 91 insertions(+), 83 deletions(-)
 create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts

diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds 
b/target/linux/ath79/base-files/etc/board.d/01_leds
index 0fa4bc73bb..e9a85c3eb1 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -63,6 +63,13 @@ glinet,gl-ar150)
ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth0"
ucidef_set_led_switch "lan" "LAN" "$boardname:green:lan" "switch0" 
"0x02"
;;
+glinet,gl-ar300m-nand|\
+glinet,gl-ar300m-nor)
+   ucidef_set_led_netdev "lan" "LAN" "gl-ar300m:green:lan" "eth0"
+   ;;
+glinet,gl-ar300m-lite)
+   ucidef_set_led_netdev "lan" "LAN" "gl-ar300m-lite:green:lan" "eth0"
+   ;;
 glinet,gl-x750)
ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth0"
;;
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network
index 9a7f2d6472..6bc3abf331 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -13,6 +13,7 @@ ath79_setup_interfaces()
devolo,dvl1200i|\
devolo,dvl1750c|\
devolo,dvl1750i|\
+   glinet,ar300m-lite|\
ocedo,koala|\
ocedo,raccoon|\
pcs,cap324|\
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
new file mode 100644
index 00..fba08e4295
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
@@ -0,0 +1,22 @@
+/dts-v1/;
+
+#include "qca9531_glinet_gl-ar300m-nor.dts"
+
+/ {
+   compatible = "glinet,gl-ar300m-lite", "qca,qca9531";
+   model = "GL.iNet GL-AR300M-Lite";
+};
+
+// GL-AR300M-Lite has different LED colors than the non-Lite version
+
+_status {
+   label = "gl-ar300m-lite:red:status";
+};
+
+_lan {
+   label = "gl-ar300m-lite:green:lan";
+};
+
+_wlan {
+   label = "gl-ar300m-lite:green:wlan";
+};
\ No newline at end of file
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts
index 9e78f83a76..26c30f2b72 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nand.dts
@@ -8,42 +8,8 @@
 };
 
  {
-   status = "okay";
num-cs = <1>;
 
-   flash@0 {
-   compatible = "winbond,w25q128", "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <2500>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {
-   label = "u-boot";
-   reg = <0x00 0x04>;
-   read-only;
-   };
-
-   partition@1 {
-   label = "u-boot-env";
-   reg = <0x04 0x01>;
-   };
-
-   partition@2 {
-   label = "reserved";
-   reg = <0x05 0xfa>;
-   };
-
-  

Re: [OpenWrt-Devel] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

Patch updated to include default LED triggers 
on suggestion of Andreas Ziegler

Confirmed to apply cleanly, build, and run 
on `master` of today.

Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge

[Jeff Kletsky]

On 3/19/19 11:17 AM, Florian Fainelli wrote:


On 3/19/19 11:14 AM, Christian Lamparter wrote:

Cc: Florian. I hope you don't mind.

On Tuesday, March 19, 2019 5:50:01 PM CET Jeff Kletsky wrote:

Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
on an IPQ4019-based device, I can get basic connectivity either manually,
or with a "standard" UCI definition of the "lan" bridge[2].

(I'm aware that this is not "production" code and expect "challenges".)

[...]

This unfortunately results in a kernel panic when trying to add to the
bridge.

Bridge br-lan initially set up with "default" UCI config[2]

Full serial log available[4]

ip link add link wan0 name wan0.100 type vlan id 100
ip link set wan0 up
ip link set wan0.100 up
ip link set wan0.100 master br-lan
(kernel panics)


I've traced this to passing of a null pointer to br_vlan_enabled()
with the diagnostic patch shown in [5]

Yes, this shouldn't crash. I think Florian has already a patch for this
upstream [6].

Right, this specific commit omitted two key details which were that:

- not all drivers support port_vlan_{add,del}
- not all drivers support programming VID 0

This is fixed upstream with d6af21a4fb5fff2f6640feb011902212e658414d
("net: dsa: Use prepare/commit phase in dsa_slave_vlan_rx_add_vid()")


commit 061f6a505ac33659eab007731c0f6374df39ab55
Author: Florian Fainelli 
Date:   Wed Feb 20 14:35:39 2019 -0800

 net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation

That should help with the NPEs since it now checks whenever the
bridge_dev is valid or not.
  
[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt

[6] <https://patchwork.ozlabs.org/patch/1026172/>



Thanks all for the quick and insightful responses!


It looks like the critical line to avoid the NPE

+   if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))

was provided by in recent mainline by the referenced commit 061f6a505ac3


The structure of the DSA code changed significantly on the way to 5.1,
so I'm looking through the 46 or so commits in mainline net/dsa/ that
aren't in 4.19 and trying to make sense of which need to be backported
to have a reasonably complete and functional 4.19 implementation.

Jeff


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge

[Jeff Kletsky]

Working with 4.19 / qca8k / ipqess patches from staging/chunkeey[1]
on an IPQ4019-based device, I can get basic connectivity either manually,
or with a "standard" UCI definition of the "lan" bridge[2].

(I'm aware that this is not "production" code and expect "challenges".)

However, I'm puzzled as how to manage VLANs and tagging, even using
`ip` and `bridge` (iproute2, from ip-bridge and ip-full packages).

It appears that the qca8k driver doesn't support `bridge` VLAN-related
commands. Checking the source doesn't show implementation of the
`port_vlan_*` functions described in the Linux DSA doc[3].


Setting aside my suspicion that a port-based VLAN approach seems
unlikely to be able to handle trunking of VLANs, I tried adding a
sub-interface of one of the otherwise unused phy interfaces (renamed
in my DTS as "wan0" to not conflict with the OpenWrt OS usage of "wan").


This unfortunately results in a kernel panic when trying to add to the
bridge.

Bridge br-lan initially set up with "default" UCI config[2]

Full serial log available[4]

  ip link add link wan0 name wan0.100 type vlan id 100
  ip link set wan0 up
  ip link set wan0.100 up
  ip link set wan0.100 master br-lan
  (kernel panics)


I've traced this to passing of a null pointer to br_vlan_enabled()
with the diagnostic patch shown in [5]


root@OpenWrt:/# ip link add link wan0 name wan0.100 type vlan id 100
root@OpenWrt:/# ip link set wan0 up
[  104.994191] qca8k c00.switch wan0: configuring for phy/ link mode
[  104.994465] IPv6: ADDRCONF(NETDEV_UP): wan0: link is not ready
[  104.07] IPv6: ADDRCONF(NETDEV_UP): wan0.100: link is not ready
root@OpenWrt:/# [  106.086762] qca8k c00.switch wan0: Link is Up - 
1Gbps/Full - flow control off

[  106.087172] IPv6: ADDRCONF(NETDEV_CHANGE): wan0: link becomes ready
[  106.095911] IPv6: ADDRCONF(NETDEV_CHANGE): wan0.100: link becomes ready

root@OpenWrt:/# ip link set wan0.100 up
root@OpenWrt:/# ip link set wan0.100 master br-lan
[  125.304300] br-lan: port 8(wan0.100) entered blocking state
[  125.304384] br-lan: port 8(wan0.100) entered disabled state
[  125.309269] device wan0.100 entered promiscuous mode
[  125.314262] device wan0 entered promiscuous mode
[  125.320068] VLAN: dsa_port_vlan_add(dsa_port *dp: ecf2e7af)
[  125.324073] VLAN: net_device->name: wan0
[  125.329413] VLAN: (port) index: 5, name: wan0, type: 3
[  125.333529] VLAN: ds->index: 0
[  125.338499] [ cut here ]
[  125.341532] WARNING: CPU: 2 PID: 2722 at net/bridge/br_vlan.c:756 
br_vlan_enabled+0x28/0x38

[  125.346320] VLAN: br_vlan_enabled(  (null))




Examining earlier in the log, the call to br_vlan_enabled()
is passed a pointer to a valid net_device for other interfaces.



As I've got a running device on the bench with which I can test
things, I'm willing to dig into this further either for diagnostics or
for testing. Please let me know how I can further help.


Jeff












[1]
$ git log -1 --pretty=fuller $(git merge-base HEAD master)
commit b61495409b
Author: Tony Ambardar 
AuthorDate: Thu Dec 13 23:49:32 2018 -0800
Commit: Hans Dedecker 
CommitDate: Thu Mar 14 22:55:06 2019 +0100

Cherry-picked from staging/chunkeey:

9b3a3a9cdf ipq40xx: include ipq40xx-ized qca8k version
5272a018b9 ipq40xx: fix NPE related to bogus use of fixed phy
e3946c85a6 ipq40xx: extend DT mdio node to be more accessible
273ffef2d8 ipq40xx: add ipqess ethernet driver
9b34795310 ipq40xx: add resets for individual MAC1-5 and PSGMII
f1042e1b15 ipq40xx: decouple mdio-ipq40xx and ar40xx
e34265ecf1 phytool: add phytool utility


[2]
config interface 'lan'
    option type 'bridge'
    option ifname 'lan1 lan2 lan3 lan4'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'


[3] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt


[4] https://gist.github.com/jeffsf/21109ff71a9041ebe4bd452d9cc0ddce


[5]

--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -753,6 +753,8 @@ bool br_vlan_enabled(const struct net_de
 {
 struct net_bridge *br = netdev_priv(dev);

+    WARN(!(dev), "VLAN: br_vlan_enabled(%p)\n", ((void *)dev));
+
 return !!br->vlan_enabled;
 }
 EXPORT_SYMBOL_GPL(br_vlan_enabled);
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,6 +255,11 @@ int dsa_port_vlan_add(struct dsa_port *d
 if (netif_is_bridge_master(vlan->obj.orig_dev))
     return -EOPNOTSUPP;

+    pr_notice("VLAN: dsa_port_vlan_add(dsa_port *dp: %p)\n", ((void *)dp));
+     pr_notice("VLAN: net_device->name: %s\n", dp->master->name);
+     pr_notice("VLAN: (port) index: %d, name: %s, type: %i\n", 
dp->index, dp->name, dp->type);

+     pr_notice("VLAN: ds->index: %d\n", dp->ds->index);
+
 if (br_vlan_enabled(dp->bridge_dev))
     return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, );




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

[OpenWrt-Devel] ipq40xx: bootarg Manipulation Failing

[Jeff Kletsky]

I'm trying to bring up an IPQ4019-based Linksys EA8300 and have a
challenge with the OEM bootargs from U-Boot. While they could be
modified once in OpenWrt, I'm hoping to provide a serial-less way
for users to easily flash OpenWrt from the OEM web interface.

The OEM boot args are

  init=/sbin/init rootfstype=ubifs ubi.mtd=NN,2048 root=ubi0:ubifs 
rootwait rw


where NN is either 11 or 13, depending on the "selected" firmware

The OpenWrt boot args that work are

  ubi.mtd=NN root=/dev/ubiblock0_0


Changing the OEM line to include `root=ubi0:rootfs` as a quick way to
check if a change of the UBI volume name would resolve the issue
failed to boot. `/dev/ubiblock0_0` was the only viable option shown.


TL;DR
=

  * I've tried 0067-generic-Mangle-bootloader-s-kernel-arguments.patch
    It doesn't seem to be able to modify the FDT

  * Can I better confirm if atags_to_fdt() is executing?

  * If it is executing, what am I not doing properly to modify the FDT?

  * If it is not executing:
    * Is there an example of command-line modification in `init`?
    * Is there a better way, short of changing U-Boot, to make the change?


---

I'm aware of 0067-generic-Mangle-bootloader-s-kernel-arguments.patch
used by the ipq80xx devices and copied that patch over. I configured
the kernel appropriately, based on the #ifdef statements in the patch

  root@OpenWrt:~# zcat /proc/config.gz | fgrep ATAG
  # CONFIG_ATAGS is not set
  CONFIG_ARM_ATAG_DTB_COMPAT=y
  # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER is not set
  # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
  CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y

as well as adding in the `append-rootblock` property to the DTS

    chosen {
    // stdout-path = "serial0:115200n8";    // set in 
dk07.1.dtsi

    bootargs = "ubi.mtd=11 root=/dev/ubiblock0_0";
    bootargs-append = " clk_ignore_unused";
    append-rootblock = "append_rootblock=";
    call-count = "not";
    };

(call-count was not present in initial tests, and is discussed later)

There was no evidence of the patched code running, either in the
booted /proc/device-tree, or from early `init` messages
(`Bootloader command line not present` appears, not
 `Bootloader command line (ignored): ... `)

---

Confirming that the code was running is challenging, as it is so early
in the boot process, still in  arch/arm/boot/compressed/head.S

To try to confirm that it was running, I moved the "extend the FDT"
code up and tried to write to a new, already defined property:

int atags_to_fdt(void *atag_list, void *fdt, int total_space)
{
    struct tag *atag = atag_list;
    /* In the case of 64 bits memory size, need to reserve 2 cells for
 * address and size for each bank */
    uint32_t mem_reg_property[2 * 2 * NR_BANKS];
    int memcount = 0;
    int ret, memsize;

    /* let's give it all the room it could need */
    ret = fdt_open_into(fdt, fdt, total_space);
    if (ret < 0)
    return ret;

    /* indicate that this has been called and how many times */
    /* for now, just say "yes" */
    setprop_string(fdt, "/chosen", "call-count", "yes");

before any of the branching.

There is no change to the call-count property; it remains "not" as set
by the DTS.

---

I've looked through the logic in arch/arm/boot/compressed/head.S
and I only see one reason why atags_to_fdt() wouldn't be called
(assuming I've followed the nested #ifdef properly)



(I previously had the same results with 4.14)

* 294: Branch to dtb_check_done (386) if there is no DTB signature

The signature looks to be there, based on hexdump (0xd00dfeed):

0021fe50  00 00 00 00 41 52 4d 20  4f 70 65 6e 57 72 74 20  |ARM 
OpenWrt |
0021fe60  6c 69 6e 6b 73 79 73 5f  65 61 38 33 30 30 20 64 
|linksys_ea8300 d|
0021fe70  65 76 69 63 65 20 74 72  65 65 20 62 6c 6f 62 00  |evice tree 
blob.|
0021fe80  00 00 00 03 00 00 4a fe  00 00 00 1b d0 0d fe ed 
|..J.|

   ===

---

Which leaves me with the puzzle:

  * Can I better confirm if atags_to_fdt() is executing?

  * If it is executing, what am I not doing properly to modify the FDT?

  * If it is not executing:
    * Is there an example of command-line modification in `init`?
    * Is there a better way, short of changing U-Boot, to make the change?


Thanks,

Jeff


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] ipq40xx: qca8x / ipqess: 10_indicate_preinit Likely Needs Adjustment

[Jeff Kletsky]

In working with an IPQ4019 device with qca8x and ipqess,
using a handful of patches[1] from


it appears that `10_indicate_preinit` has some behavior that needs to
be addressed in the future, prior to calling `preinit_net_echo`.

The two issues that I see include

  * eth0 needs to be "up" for lan1@eth0 to be "up"

  * qca8x takes a little over a second from interface up request
    to the time that the bridge has reconfigured itself

The timing issue may be "hidden" once UCI-based switch configuration
is present in `preinit_config_switch`, but should be considered if the
`preinit_net_echo` functionality is to be reliably supported.


Indication of the issues can be seen in the boot log (serial) as

  [    4.024645] init: - preinit -
  ip: SIOCSIFFLAGS: Network is down
  sendto(): Network unreachable
  Press the [f] key and hit [enter] to enter failsafe mode


An "ugly hack" for this is to `ip link set dev eth0 up`
prior to trying to bring up lan1, then `sleep 2` after lan1 is up


The delay in qca8k is just a little over a second:

  [    5.165257] qca8k c00.switch lan1: configuring for phy/ link mode
  DEBUG: Snoozing for 2 seconds to allow qca8k to respond
  [    6.246260] qca8k c00.switch lan1: Link is Up - 1Gbps/Full - 
flow control rx/tx

  [    6.246654] IPv6: ADDRCONF(NETDEV_CHANGE): lan1: link becomes ready


I've thought about bringing up any interfaces that match `ethN`, as
well as waiting for the "up" condition before `preinit_net_echo` as
potentially more robust approaches. Other suggestions are welcome.



Jeff



[1]

1db1612bbc ipq40xx: include ipq40xx-ized qca8k version
2db429cf34 ipq40xx: fix NPE related to bogus use of fixed phy
505cfcfb1c ipq40xx: extend DT mdio node to be more accessible
abf050221c ipq40xx: add ipqess ethernet driver
2d6352f8b1 ipq40xx: add resets for individual MAC1-5 and PSGMII
fce445b243 ipq40xx: decouple mdio-ipq40xx and ar40xx
99e74d2e90 phytool: add phytool utility
c83b9fec9e ipq40xx: fix phy interrupt setting

The last of these patches appears to now be present in `master`
as commit 784f2e73df


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mac80211: Select better ch/VHT for sub-band radios

[Jeff Kletsky]

From: Jeff Kletsky 

Certain wireless devices have limitations on the channels
on which they can operate. For some of these devices,
the present default of ch. 36 (VHT80) is outside of the
capabilities of the device.

For 5 GHz, provide a default of the first non-disabled channel
returned by `iw phy $phy info`. For VHT-capable devices,
Select VHT20 if that channel may  not be "clear" for either
VHT40 or VHT80 due to either band edges or DFS restrictions.

Based on hostap src/common/hw_features_common.c

VHT80: 36, 52, 100, 116, 132, 149
VHT40: 44, 60, 108, 124, 140, 157, 165, 184, 192

Adding in band edges, DFS, and limited-use bands reduces this to:

VHT80: 36, 149
VHT40: 44, 157

Runtime-tested: TP-Link Archer C7v2, GL.iNet AR750S
Runtime-tested: Linksys EA8300 (QCA9888; ch. 100 and above only)

Signed-off-by: Jeff Kletsky 
---
 package/kernel/mac80211/files/lib/wifi/mac80211.sh | 42 ++
 1 file changed, 36 insertions(+), 6 deletions(-)
 mode change 100644 => 100755 package/kernel/mac80211/files/lib/wifi/mac80211.sh

diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh 
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
old mode 100644
new mode 100755
index 511a9188db..368973eea4
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -59,8 +59,12 @@ check_mac80211_device() {
 }
 
 detect_mac80211() {
-   devidx=0
+   local iw_phy_info
+
config_load wireless
+
+   devidx=0
+
while :; do
config_get type "radio$devidx" type
[ -n "$type" ] || break
@@ -81,13 +85,39 @@ detect_mac80211() {
htmode=""
ht_capab=""
 
-   iw phy "$dev" info | grep -q 'Capabilities:' && htmode=HT20
+   iw_phy_info=$( iw phy "${dev}" info )
+
+   echo "${iw_phy_info}" | fgrep -q 'Capabilities:' && htmode=HT20
+
+   if echo "${iw_phy_info}" | egrep -q '(49|5[0-9])[0-9][0-9] MHz' 
; then
 
-   iw phy "$dev" info | grep -q '5180 MHz' && {
mode_band="a"
-   channel="36"
-   iw phy "$dev" info | grep -q 'VHT Capabilities' && 
htmode="VHT80"
-   }
+
+   channel=$( echo "${iw_phy_info}" | \
+   fgrep -v disabled | \
+   sed -Ene 's/^.+ (49|5[0-9])[0-9][0-9] MHz 
\[([1-9][0-9]{1,2})\].*$/\2/p' | \
+   head -n 1 )
+
+   if [ -z "${channel}" ] ; then
+   logger -p warn -t detect_mac80211 \
+   "No enabled channel found in `iw phy 
${dev} info`"
+   fi
+
+   if echo "${iw_phy_info}" | fgrep -q 'VHT Capabilities'
+   then
+   case "$channel" in
+   36 | 149 )
+   htmode="VHT80"
+   ;;
+   44 | 157 )
+   htmode="VHT40"
+   ;;
+   *)
+   htmode="VHT20"
+   ;;
+   esac
+   fi
+   fi  # 5 GHz
 
[ -n "$htmode" ] && ht_capab="set 
wireless.radio${devidx}.htmode=$htmode"
 
-- 
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC/RFT] mtd resetbc: Unify "Linksys" NOR/NAND variants; Add Logging and Error Return

[Jeff Kletsky]

In working with porting the dual-firmware, NAND-based Linksys EA8300
to OpenWrt, one of the puzzles was why it wouldn't "take" a change of
boot partition reliably. After digging into it some, I found that when
a previous Linksys device was ported to the ipq40xx platform, the
boot-counter reset was "hard-wired" to 16 bytes, rather than the write
size of the MTD partition. This was likely due to the device booting from
NOR (write size of 1), rather than NAND (typical write size of 2048)
as do most of the other Linksys devices.

As a result, the boot-counter reset failed.


Right now, the choice of action behind `mtd resetbc ` is
made on a platform-wide basis. This is questionable in general, as
what happens when a device with a different boot loader is ported to
one of the impacted architectures in package/system/mtd/src/Makefile ?

* Does the boot-counter reset function belong as an `mtd` operation?

* If so, how will future devices with different needs be accommodated?



Putting those questions aside, I've:


* Unified the "NOR" variant with the rest of the Linksys variants

* Added logging to indicate success and failure

* Provided a meaningful return value for scripting

* "Protected" the use of `mtd resetbc` in start-up scripts so that
  failure does not end the boot sequence


As this would have impact on more devices than just adding the EA8300,
I'm bringing it up now, rather than hiding it away in a device-specific
patch/PR.


I don't have the other impacted devices. I believe that with the
exception of the EA6350v3, all are NAND-based and this should be a
transparent change.

Testing would be greatly appreciated!

* ipq40xx
  * EA8350v3 (NOR boot)

* ipq806x
  * EA8500

* kirkwood
  * audi
  * viper

* mvebu
  * armada-385-linksys-caiman
  * armada-385-linksys-cobra
  * armada-385-linksys-rango
  * armada-385-linksys-shelby
  * armada-385-linksys-venom
  * armada-xp-linksys-mamba


Thanks!

Jeff


See also:
<https://forum.openwrt.org/t/add-support-for-linksys-ea6350-v3/18907/289>




From aa142cb0e7b58e5c22c62be1e95325299e5acc92 Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Sat, 16 Mar 2019 16:52:02 -0700
Subject: [PATCH] mtd: Linksys: Add logging and NOR-detection to
 linksys_bootcount.c

---
 package/system/mtd/src/Makefile    |   2 +-
 package/system/mtd/src/linksys_bootcount.c | 113 

 package/system/mtd/src/linksys_bootcount_fix.c | 115 
-

 .../base-files/etc/init.d/zlinksys_recovery    |   2 +-
 .../ipq806x/base-files/etc/init.d/linksys_recovery |   2 +-
 .../base-files/etc/init.d/linksys_recovery |   2 +-
 .../mvebu/base-files/etc/init.d/linksys_recovery   |   2 +-
 7 files changed, 100 insertions(+), 138 deletions(-)
 delete mode 100644 package/system/mtd/src/linksys_bootcount_fix.c

diff --git a/package/system/mtd/src/Makefile 
b/package/system/mtd/src/Makefile

index 08a9fb295d..e469e23ef7 100644
--- a/package/system/mtd/src/Makefile
+++ b/package/system/mtd/src/Makefile
@@ -16,7 +16,7 @@ obj.ramips = $(obj.seama) $(obj.tpl) $(obj.wrg)
 obj.mvebu = linksys_bootcount.o
 obj.kirkwood = linksys_bootcount.o
 obj.ipq806x = linksys_bootcount.o
-obj.ipq40xx = linksys_bootcount_fix.o
+obj.ipq40xx = linksys_bootcount.o

 ifdef FIS_SUPPORT
   obj += fis.o
diff --git a/package/system/mtd/src/linksys_bootcount.c 
b/package/system/mtd/src/linksys_bootcount.c

index 500ede4972..9fb581ee02 100644
--- a/package/system/mtd/src/linksys_bootcount.c
+++ b/package/system/mtd/src/linksys_bootcount.c
@@ -18,6 +18,11 @@
  *
  */

+/*
+ * Portions Copyright (c) 2019, Jeff Kletsky
+ *
+ */
+
 #include 
 #include 
 #include 
@@ -29,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -37,6 +43,30 @@

 #define BOOTCOUNT_MAGIC    0x20110811

+/*
+ * EA6350v3, and potentially other NOR-boot devices,
+ * use an offset increment of 16 between records,
+ * not mtd_info_user.writesize (often 1 on NOR devices).
+ */
+
+#define BC_OFFSET_INCREMENT_MIN 16
+
+
+
+#define DLOG_OPEN()
+
+#define DLOG_ERR(...) do {                           \
+        fprintf(stderr, "ERROR: " __VA_ARGS__); fprintf(stderr, "\n"); \
+    } while (0)
+
+#define DLOG_NOTICE(...) do {                        \
+        fprintf(stderr, __VA_ARGS__); fprintf(stderr, "\n");    \
+    } while (0)
+
+#define DLOG_DEBUG(...)
+
+
+
 struct bootcounter {
 uint32_t magic;
 uint32_t count;
@@ -50,25 +80,51 @@ int mtd_resetbc(const char *mtd)
 struct mtd_info_user mtd_info;
 struct bootcounter *curr = (struct bootcounter *)page;
 unsigned int i;
+    unsigned int bc_offset_increment;
 int last_count = 0;
 int num_bc;
 int fd;
 int ret;
+    int retval = 0;
+
+    DLOG_OPEN();

 fd = mtd_check_open(mtd);

 if (ioctl(fd, MEMGETINFO, _info) < 0) {
-        fprintf(stderr, "failed to get mtd info!\n");

[OpenWrt-Devel] Importing DTS Files from Future Kernel -- Best Practice?

[Jeff Kletsky]

I'm working on a derivative of the qcom-ipq4019-ap.dk07.1-c1 that
is present in Kernel 4.19, but not in 4.14

In the interest of "correctness" and future maintainability,
I'd like to import from Kernel 4.19 linux/arch/arm/boot/dts/

* qcom-ipq4019-ap.dk07.1-c1.dts
* qcom-ipq4019-ap.dk07.1.dtsi

and use the upstream sources as #include in the EA8300 DTS
rather than the monolithic approach used in a previously
declined patch set for the device.

I can see a couple ways of doing this:

* target/linux/ipq40xx/patches-4.14/ -- patch in the entire files
* target/linux/ipq40xx/files-4.14/   -- add the files directly

Which is the preference of the project, or is there another approach?

Jeff





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

On 2/16/19 12:03 PM, w...@reboot.ch wrote:

Hello Jeff,

I did try your suggested change but really not sure to have done that correctly,
this is what lsusb shows while I have a wifi usb dongle connected (also tried 
with memory stick):

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

No luck to use USB. Did you had a chance to have a look?

Thank you!
- will



I built an image this morning and my AR300M-Lite recognizes devices and 
attaches drivers as expected


root@OpenWrt:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

(start following log and insert Transcend card reader)

root@OpenWrt:~# logread -f
Sun Feb 17 15:52:01 2019 kern.info kernel: [  763.408605] usb 1-1: new 
high-speed USB device number 2 using ehci-platform
Sun Feb 17 15:52:01 2019 kern.info kernel: [  763.613737] usb-storage 
1-1:1.0: USB Mass Storage device detected
Sun Feb 17 15:52:01 2019 kern.info kernel: [  763.621082] scsi host0: 
usb-storage 1-1:1.0
Sun Feb 17 15:52:02 2019 kern.notice kernel: [  764.670474] scsi 
0:0:0:0: Direct-Access TS-RDF5  SD  Transcend    TS35 PQ: 0 ANSI: 6
Sun Feb 17 15:52:02 2019 kern.notice kernel: [  764.685408] sd 0:0:0:0: 
[sda] Attached SCSI removable disk


root@OpenWrt:~# lsusb
Bus 001 Device 002: ID 8564:4000 Transcend Information, Inc. RDF8
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Do you have the proper USB drivers installed?

Test above performed with

jeff@deb-devel:~/devel/openwrt-ar300m$ ./scripts/diffconfig.sh | fgrep usb
CONFIG_PACKAGE_kmod-usb-storage=y
CONFIG_PACKAGE_kmod-usb-storage-uas=y
CONFIG_PACKAGE_libusb-1.0=y
CONFIG_PACKAGE_usbutils=y


Jeff



On 4 Feb 2019, at 21:59, Jeff Kletsky  wrote:

On 2/4/19 4:20 AM, w...@reboot.ch wrote:


Hello Jeff, thanks for adding GL.iNet AR-300M-Lite !

I can't test it as it's not yet merged into master I think,
I'm currently using GL.iNet AR-300M settings with a GL.iNet AR-300M-Lite box
and USB is not working, lsusb shows nothing.

Wondering if it's a known issue and if your latest patches fix it.

Thank you!
- will

It will be this evening, GMT+8, until I will be able to check, but it wouldn't surprise 
me if the change to "gl-ar300m:green:usb" in the DTS will resolve the issue. I 
can imagine all kinds of problems with a trigger on a USB device-present flipping the USB 
power!

Until then, you can try changing the trigger to "always on" in 
/etc/config/system or through LuCI.

Jeff




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 5GHz wifi is broken

[Jeff Kletsky]

Are you running "classic" ath10k drivers and firmware, or the default 
ath10k-ct drivers and firmware?


You should have a line similar to

ath10k_pci :00:00.0: firmware ver 10.2.4-1.0-00041 api 5 features 
no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 f43fa422


Which firmware version does it show?

Which version of the Archer C7? ar71xx, or ath79?

Which version of the ath10k-related packages?


On 2/14/19 9:43 AM, e9hack wrote:

Hi,

a change somewhere between 8.Feb and 10.Feb breaks the usage of the 5GHz WiFi 
on my Archer C7 router. I get the
following entries in the log file:


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

[Jeff Kletsky]

On 2/5/19 4:19 PM, Szabolcs Hubai wrote:

Hi Jeff,

sorry for being late in the topic, but that [1] red "status" LED is
GL-AR300M-Lite specific, and isn't suitable for the original GL-AR300M
model, IMHO.


Here are my points:

I opened my GL-AR300MD's case (a limited, dualband model), and it has
a "GL-AR300M-V1.3.1" print on it's PCB.
It has the exactly same pinouts as it could be seen on the
documentation page [2] (picture attached) and it's WLAN LED is red,
the other two, LAN and SYS (in DTS: "status") are green.

I'm unsure how are the LED colors in the other GL-AR300M sub-models.


I checked the GL.iNet site and the video of the GL-AR300M at

published in January, 2017, shows two green and a red LED,
consistent with your description.

On the other hand, GL.iNet's source shows them as all "green"
(as is the AR300M-Lite I have in hand)



I'm fine with leaving the color alone or being consistent with current 
production
and the OEM's definitions. Shoot, my Archer C7 v2 has "blue" LEDs under 
OpenWrt.

Too bad that doesn't actually change the color of them ;)

The GPIO assignments are still in need of correction, as far as I can 
tell, for all variants.



Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ath79 (qca95xx): Status of SPI-Attached NAND Drivers?

[Jeff Kletsky]

Context
===

Working on bringing up the GL.iNet AR750S as a NAND variant
on the ath79 target. While I can build an image, it fails to attach
a driver to the SPI-attached NAND. There is a GL.iNet AR300M NAND
variant, but I am unable to confirm if this device will fully boot
from the images generated (as my AR300M is NOR only).


Questions
=

* What is the level of support for QCA9531 and QCA9563 SoCs for NAND?

* Is the AR300M NAND target bootable?

  * If not, should it be removed from the list of valid targets
until NAND support is available and confirmed bootable?


Thanks,

Jeff



What I Have Found So Far


* This List, May 17, 2018
  "[OpenWrt-Devel] [PATCH] ath79: add spi nand driver, the source code from"
  "[OpenWrt-Devel] [PATCH] mtd: add spi nand driver"


Last message on thread that I found, from Florian Fainelli:

On 05/17/2018 06:14 PM, Luochongjun wrote:

---
 .../patches-4.9/491-mtd-spi-nand-driver.patch  | 2785 
 1 file changed, 2785 insertions(+)
 create mode 100644 
target/linux/ar71xx/patches-4.9/491-mtd-spi-nand-driver.patch


Instead of combining all upstream patches that got recently submitted on
the MTD mailing-list into one large patch, you should provide a patch
that includes all the necessary patches to bring the recent SPI-NAND
framework into the OpenWrt kernel tree. This makes it much easier to
drop dependencies and/or backport fixes as we move from either 4.9 to
another 4.9 stable release, or from 4.9 to say 4.14 for instance.

See how bcm53xx does it for instance.

Thank you!



* https://github.com/openwrt/openwrt/pull/1428

Closed by mkresin on November 26, 2018 with the comment


But it requires 4.19 to not have to backport pretty much the whole
MTD and SPI subsystems



Please re-spin the patch as soon as we have kernel 4.19 support. The
approach was already NAK'ed upstream and I don't see much gain in
adding the hack if the next major kernel in OpenWrt will provide a
suitable solution.




* git://git.infradead.org/linux-mtd

Earliest "interesting" tag is "mtd/for-4.16" (not 4.14)




* Linux Kernel commit eaa76499711535fd64d747cc4ef0d78ab0fd41c

Merge tag 'mtd/for-4.21' of git://git.infradead.org/linux-mtd

  SPI-NAND drivers changes:
   - Remove the depreacated mt29f_spinand driver from staging.


(At least that's a while off, but reinforces the unwillingness of
upstream acceptance of keeping the mt29f_spinand driver alive.)



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ath79: ar71xx: Upgrade: tl-wr842n-v1 has Wrong BOARDNAME in ar71xx Builds

[Jeff Kletsky]

As reported in 
https://forum.openwrt.org/t/ath79-image-builder-problem-for-wr842n-v1/30197/4?u=jeff


the board configuration for the ar71xx tl-wr842n-v1 improperly sets 
BOARDNAME to TL-MR3420

(confirmed on master and on openwrt-18.06)

As a result, users upgrading that device to ath79 will not have a 
seamless experience, requiring manual intervention.


I'm hesitant to suggest that the TL-MR3420 be added to SUPPORTED_DEVICES 
for tl-wr842n-v2 under ath79, as I believe the MR3420 is a 4/32 device 
and the WR842N v1 is a 8/32 device. Some idiot 
uninformed user might suggest that TL-MR3420 users try to flash the 8 MB 
image.


Jeff


target/linux/ar71xx/image/generic-tp-link.mk:

define Device/tl-wr842n-v1
  $(Device/tplink-8m)
  DEVICE_TITLE := TP-LINK TL-WR842N/ND v1
  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
  BOARDNAME := TL-MR3420
  DEVICE_PROFILE := TLWR842
  TPLINK_HWID := 0x08420001
endef
TARGET_DEVICES += tl-wr842n-v1



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] mac80211: 802.11s TCP/IP Connectivity Fails After 2018-09

[Jeff Kletsky]

802.11s mesh appears to not transport TCP/IP even though the mesh
appears up, for commits on master after late September, 2018.

(Steps to replicate at the end of this message)

The output of `iw dev mesh0 station dump` yields similar results for
working and non-working builds, along the lines of:

    mesh plink:    ESTAB
    mesh local PS mode:    ACTIVE
    mesh peer PS mode:    ACTIVE
    mesh non-peer PS mode:    ACTIVE
    authorized:    yes
    authenticated:    yes
    associated:    yes

or

    mesh plink:    ESTAB
    mesh local PS mode:    ACTIVE
    mesh peer PS mode:    UNKNOWN
    mesh non-peer PS mode:    ACTIVE
    authorized:    yes
    authenticated:    yes
    associated:    yes

ping to the peer(s) prior to the first failing commit is sucessful and
the peer is reflected in the arp table.  Full connectivity can be
established over the mesh to peers with UDP or TCP transport.

Both ping and arp fail to behave as expected on or after the first
failing commit.

The routing is the same for both builds.

Behavior seen on both Archer C7 v2 (QCA9880-BR4A v2)
and a GL.iNet AR750S (QCA9887), both on ath79 target (AR750S is WIP)

Confirmed that the newer (newest?) firmware (ver 10.2.4-1.0-00041)
works on the "old" build.

Lack of TCP/IP transport over the mesh confirmed both with 802.11s
integral routing, as well with 802.11s routing disabled and replaced
with batman-adv.  Configuration using both 802.11s routing and
batman-adv on distinct meshes on the same radios has been running
successfully with four or five Archer C7 v2 units for both backhaul
over the 5 GHz mesh, as well as client access on 5 GHz.  (Not tested
on 2.4 GHz on either the Archer C7 or the AR750S.)


git bisect was used to identify the "first failing commit":

commit db90c243a0b9bd72fc691cd09e58a96ac2a452cf
Author: Hauke Mehrtens 
Date:   Sun Sep 23 18:02:35 2018 +0200

    mac80211: update to version based on 4.19-rc4


Note that the Candela Technologies drivers do not appear to support
mesh on either chipset.


Any suggestions as to how I can further explore this issue, or assist
others in the process?

Jeff





Additional notes at


Thanks to @slh and Koen for hopping on thing there!


**To Replicate:**

==> Pick your target of choice

$ ./scripts/diffconfig.sh
CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_generic=y
CONFIG_TARGET_ath79_generic_DEVICE_glinet_gl-ar750s-nor=y
CONFIG_DEVEL=y
CONFIG_ATH10K_LEDS=y
CONFIG_BUILD_LOG=y
CONFIG_CCACHE=y
CONFIG_OPENSSL_WITH_DEPRECATED=y
CONFIG_OPENSSL_WITH_EC=y
CONFIG_OPENSSL_WITH_NPN=y
CONFIG_OPENSSL_WITH_PSK=y
CONFIG_OPENSSL_WITH_SRP=y
CONFIG_PACKAGE_ath10k-firmware-qca9887=y
# CONFIG_PACKAGE_ath10k-firmware-qca9887-ct is not set
CONFIG_PACKAGE_diffutils=y
CONFIG_PACKAGE_findutils-find=y
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_kmod-ath10k-ct is not set
# CONFIG_PACKAGE_kmod-hwmon-core is not set
CONFIG_PACKAGE_less=y
CONFIG_PACKAGE_libncurses=y
CONFIG_PACKAGE_libopenssl=y
CONFIG_PACKAGE_terminfo=y
# CONFIG_PACKAGE_wpad-basic is not set
CONFIG_PACKAGE_wpad-mesh-openssl=y


==> Add to `/etc/config/network`

config interface 'nwi_mesh0'
    option ifname 'mesh0'
    option mtu '2304'
    option proto 'static'
    option ipaddr '172.16.0.NNN'
    option netmask '255.255.255.0'


==> Add to / replace in `/etc/config/wireless`
  * Please confirm a valid channel for your location
  * Adjust the device path/reference as needed
  * 'n' used for support of older iPhones here

config wifi-device 'radio5'
    option type 'mac80211'
    option channel '149'
    option hwmode '11a'
    option path 'pci:00/:00:00.0'
    option htmode 'VHT80'
    option require_mode 'n'

config wifi-iface 'mesh0'
    option device 'radio5'
    option ifname 'mesh0'
    option network 'nwi_mesh0'
    option mode 'mesh'
    option mesh_id 'TestMesh'
    option mesh_fwding '1'
    option encryption 'psk2+ccmp'
    option key 'TestMeshPassPhrase'


==> Flash and configure additional unit(s), changing the last octet
of the nwi_mesh0 interface address.

==> Note that the mesh appears established from the output of
`iw dev mesh0 station dump`

==> Note that the one unit can’t ping the other’s nwi_mesh0 address
when building on or after "first bad commit" but ping (arp and ip
neigh) will work as expected prior to that commit.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ath79: Add GL.iNet AR-300M-Lite

[Jeff Kletsky]

On 2/4/19 4:20 AM, w...@reboot.ch wrote:


Hello Jeff, thanks for adding GL.iNet AR-300M-Lite !

I can't test it as it's not yet merged into master I think,
I'm currently using GL.iNet AR-300M settings with a GL.iNet AR-300M-Lite box
and USB is not working, lsusb shows nothing.

Wondering if it's a known issue and if your latest patches fix it.

Thank you!
- will


It will be this evening, GMT+8, until I will be able to check, but it 
wouldn't surprise me if the change to "gl-ar300m:green:usb" in the DTS 
will resolve the issue. I can imagine all kinds of problems with a 
trigger on a USB device-present flipping the USB power!


Until then, you can try changing the trigger to "always on" in 
/etc/config/system or through LuCI.


Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] mtd: sysupgrade: Is `mtd write` Correct for NAND-Based Devices?

[Jeff Kletsky]

In going through code used by a port of an IPQ4019 device, I see that

target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
in platform_do_upgrade_linksys()

writes the image using

get_image "$1" | mtd write - $part_label

This surprises me as I had thought that NAND-based flash should use
NAND utilities because of the possibility of bad blocks and metadata.

The OEM firmware follows more of what I had expected to see:

ubifs_v1.1.4/usr/sbin/update_defs (Linksys OEM)
in erase_and_program()

if [ ${FLASH_TYPE} = "MTD_NANDFLASH" ]; then
echo -ne "\tErasing... /dev/$2\n" >> /dev/console
if [ "$VERBOSE" = "yes" ]; then
# flash_eraseall -j /dev/$2
flash_erase /dev/$2 0 0
else
# flash_eraseall -q -j /dev/$2
flash_erase -q /dev/$2 0 0
fi
check_error
echo -ne "\tProgramming... /dev/$2\n" >> /dev/console
if [ "$VERBOSE" = "yes" ]; then
#nandwrite -m -a -p /dev/$2 $3
nandwrite -p /dev/$2 $3
else
#nandwrite -q -m -a -p /dev/$2 $3
nandwrite -q -p /dev/$2 $3
fi
check_error
fi


While I don't have any bad blocks in my NAND (yet), should this be changed
to use the NAND-based utilities in a separate patch?


Jeff








___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gre: introduce 'nohostroute' option

[Jeff Kletsky]

On 5/26/19 12:15 PM, Hans Dedecker wrote:


Hi,
On Sun, May 26, 2019 at 12:19 PM Fabian Bläse via openwrt-devel
 wrote:
[...]
Please use git send-email to deliver the patch

Hans

---
  package/network/config/gre/files/gre.sh | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/package/network/config/gre/files/gre.sh 
b/package/network/config/gre/files/gre.sh
index 2bb1010b76..3414ed3047 100755
--- a/package/network/config/gre/files/gre.sh
+++ b/package/network/config/gre/files/gre.sh
[...]


I can confirm the need to manage the routing generated by the call.
When I was using Layer 2, GRE tunnels I found that I had reverse
at least some of effect of the call to get routing to work properly.

I was unable to determine why the routing was being set as it was,
and crudely reversed it with
 
  ( proto_add_host_dependency "$cfg" "$peeraddr" "$tunlink" )
 
  +   # jmk -- hack for broken logic somewhere

  +
  +   ip route delete proto static "$peeraddr"
  +


Jeff

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/2] kernel: mtd: spinand: backport-4.19: Add'l chip support

[Jeff Kletsky]

From: Jeff Kletsky 

This patch series brings in various chips supported by the upstream
SPI-NAND framework after 4.19 and through linux/next at this time.

There are significant changes to the driver in 5.x that add new
features that have not been backported as they are relatively invasive
and/or require changes in upper layers, such as UBI, to provide
benefit. These include:

 * 509198485bf2 mtd: spinand: Implement mtd->_max_bad_blocks
 * 377e517b5fa5 mtd: nand: Add max_bad_eraseblocks_per_lun info to memorg
 * 981d1aa0697c mtd: spinand: Use the spi-mem dirmap API

Those changes include the addition of a new bad-block limit parameter
to the chip descriptions. This has been backed out of the impacted
patch for the GD5F1GQ4UFxxG and noted in the OpenWrt patch file for
future reference.

Two "fixes" present in upstream 5.0 appear already present on 4.19.47,
and are noted in the related patch-commit message:

 * Fix the error/cleanup path in spinand_init()
 * Handle the case where PROGRAM LOAD does not reset the cache

All patches refreshed against 4.19.47

This patch series supersedes https://patchwork.ozlabs.org/patch/1099813/

Signed-off-by: Jeff Kletsky 

---

Jeff Kletsky (2):
  kernel: mtd: spinand: backport-4.19: Chip support through 5.1
  kernel: mtd: spinand: Backport GigaDevice "F" from linux/next

 ...nbond-Add-support-for-W25N01GV.patch (new) |  42 
 ...l-support-for-Toshiba-TC58CVG2.patch (new) | 188 +
 ...d-support-for-GigaDevice-GD5FxGQ4xA.patch} |  12 +-
 ...d-macronix-Fix-ECC-Status-Read.patch (new) |  44 
 ...t-for-all-Toshiba-Memory-produ.patch (new) | 141 +
 ...upport-for-GigaDevice-GD5F1GQ4UExxG.patch} |  13 +-
 ...ros-for-page-read-ops-with-thr.patch (new) |  86 
 ...upport-for-two-byte-device-IDs.patch (new) |  48 +
 ...t-for-GigaDevice-GD5F1GQ4UFxxG.patch (new) | 197 ++
 9 files changed, 761 insertions(+), 10 deletions(-)
 create mode 100644 
target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
 create mode 100644 
target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
 rename 
target/linux/generic/backport-4.19/{450-v5.0-mtd-spinand-add-support-for-GigaDevice-GD5FxGQ4xA.patch
 => 423-v5.0-mtd-spinand-add-support-for-GigaDevice-GD5FxGQ4xA.patch} (94%)
 create mode 100644 
target/linux/generic/backport-4.19/426-v5.1-mtd-spinand-macronix-Fix-ECC-Status-Read.patch
 create mode 100644 
target/linux/generic/backport-4.19/427-v5.1-mtd-spinand-Add-support-for-all-Toshiba-Memory-produ.patch
 rename 
target/linux/generic/backport-4.19/{451-v5.1-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UExxG.patch
 => 428-v5.1-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UExxG.patch} (89%)
 create mode 100644 
target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
 create mode 100644 
target/linux/generic/backport-4.19/432-v5.3-mtd-spinand-Add-support-for-two-byte-device-IDs.patch
 create mode 100644 
target/linux/generic/backport-4.19/433-v5.3-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UFxxG.patch

-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] kernel: mtd: spinand: backport-4.19: Chip support through 5.1

[Jeff Kletsky]

From: Jeff Kletsky 

Several SPI NAND chips were added between 4.19 and 5.1
including GigaDevice, Toshiba, and Winbond.
A fix to Macronix chips' ECC was also included.

 * Add support for GigaDevice GD5F1GQ4UExxG
 * Add support for all Toshiba Memory products
 * macronix: Fix ECC Status Read
 * add support for GigaDevice GD5FxGQ4xA
 * Add initial support for Toshiba TC58CVG2S0H
 * winbond: Add support for W25N01GV

The following two commits from 5.0 appear already backported upstream
so are not included here:

 * Fix the error/cleanup path in spinand_init()
 * Handle the case where PROGRAM LOAD does not reset the cache

Existing GigaDevice patches reordered to maintain upstream content

Upstream patches refreshed against 4.19.47

Run-tested-on: ath79/nand (4.19.47, WIP)

Signed-off-by: Jeff Kletsky 
---
 ...nbond-Add-support-for-W25N01GV.patch (new) |  42 
 ...l-support-for-Toshiba-TC58CVG2.patch (new) | 188 ++
 ...d-support-for-GigaDevice-GD5FxGQ4xA.patch} |  12 +-
 ...d-macronix-Fix-ECC-Status-Read.patch (new) |  44 
 ...t-for-all-Toshiba-Memory-produ.patch (new) | 141 +
 ...upport-for-GigaDevice-GD5F1GQ4UExxG.patch} |  13 +-
 6 files changed, 430 insertions(+), 10 deletions(-)

diff --git 
a/target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
 
b/target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
new file mode 100644
index 00..7fae1ad2d6
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
@@ -0,0 +1,42 @@
+From 9a4d83074769d6ecf1f5c3fef0f183b09abf3726 Mon Sep 17 00:00:00 2001
+From: Robert Marko 
+Date: Sat, 6 Oct 2018 17:36:42 +0200
+Subject: [PATCH 1/8] mtd: spinand: winbond: Add support for W25N01GV
+
+W25N01GV is a single die version of the already supported
+W25M02GV with half the capacity. Everything else is the
+same so introduce support for W25N01GV.
+
+Datasheet:http://www.winbond.com/resource-files/w25n01gv%20revl%20050918%20unsecured.pdf
+
+Tested on 8devices Jalapeno dev board under OpenWrt running 4.19-rc5.
+
+Signed-off-by: Robert Marko 
+Reviewed-by: Boris Brezillon 
+Signed-off-by: Miquel Raynal 
+---
+ drivers/mtd/nand/spi/winbond.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
+index 67baa1b32c00..5d944580b898 100644
+--- a/drivers/mtd/nand/spi/winbond.c
 b/drivers/mtd/nand/spi/winbond.c
+@@ -84,6 +84,14 @@ static const struct spinand_info winbond_spinand_table[] = {
+0,
+SPINAND_ECCINFO(_ooblayout, NULL),
+SPINAND_SELECT_TARGET(w25m02gv_select_target)),
++  SPINAND_INFO("W25N01GV", 0xAA,
++   NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 1),
++   NAND_ECCREQ(1, 512),
++   SPINAND_INFO_OP_VARIANTS(_cache_variants,
++_cache_variants,
++_cache_variants),
++   0,
++   SPINAND_ECCINFO(_ooblayout, NULL)),
+ };
+ 
+ /**
+-- 
+2.20.1
+
diff --git 
a/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
 
b/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
new file mode 100644
index 00..ed42f0024b
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
@@ -0,0 +1,188 @@
+From 10949af1681d5bb5cdbcc012815c6e40eec17d02 Mon Sep 17 00:00:00 2001
+From: Schrempf Frieder 
+Date: Thu, 8 Nov 2018 08:32:11 +
+Subject: [PATCH 2/8] mtd: spinand: Add initial support for Toshiba TC58CVG2S0H
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Add minimal support for the Toshiba TC58CVG2S0H SPI NAND chip.
+
+Signed-off-by: Frieder Schrempf 
+Acked-by: Clément Péron 
+Signed-off-by: Miquel Raynal 
+---
+ drivers/mtd/nand/spi/Makefile  |   2 +-
+ drivers/mtd/nand/spi/core.c|   1 +
+ drivers/mtd/nand/spi/toshiba.c | 137 +
+ include/linux/mtd/spinand.h|   1 +
+ 4 files changed, 140 insertions(+), 1 deletion(-)
+ create mode 100644 drivers/mtd/nand/spi/toshiba.c
+
+--- a/drivers/mtd/nand/spi/Makefile
 b/drivers/mtd/nand/spi/Makefile
+@@ -1,3 +1,3 @@
+ # SPDX-License-Identifier: GPL-2.0
+-spinand-objs := core.o macronix.o micron.o winbond.o
++spinand-objs := core.o macronix.o micron.o toshiba.o winbond.o
+ obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
+--- a/drivers/mtd/nand/spi/core.c
 b/drivers/mtd/nand/spi/core.c
+@@ -764,6 +764,7 @@ static const struct nand_ops spinand_ops
+ static const struct spinand_manufacturer *spinand_manufacturers[] = {
+   _spinand_manufacturer,
+   _spinand_manufacturer,
++  _spinand_ma

[OpenWrt-Devel] [RFC] Dual-Flash (NOR/NAND) Board Naming and Kernel

[Jeff Kletsky]

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] 


[2] 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] kernel: mtd: spinand: Backport GigaDevice "F" from linux/next

[Jeff Kletsky]

From: Jeff Kletsky 

Backport upstream support for GigaDevice GD5F1GQ4UFxxG SPI NAND

 * Add support for GigaDevice GD5F1GQ4UFxxG
 * Add support for two-byte device IDs
 * Define macros for page-read ops with three-byte addresses

Upstream patches refreshed against 4.19.47

Run-tested-on: ath79/nand (4.19.47, WIP)

Signed-off-by: Jeff Kletsky 
---
 ...ros-for-page-read-ops-with-thr.patch (new) |  86 
 ...upport-for-two-byte-device-IDs.patch (new) |  48 +
 ...t-for-GigaDevice-GD5F1GQ4UFxxG.patch (new) | 197 ++
 3 files changed, 331 insertions(+)

diff --git 
a/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
 
b/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
new file mode 100644
index 00..87bb35275e
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
@@ -0,0 +1,86 @@
+From d014717d50b1efd011a3a028ce92563a4dc9bae5 Mon Sep 17 00:00:00 2001
+From: Jeff Kletsky 
+Date: Wed, 22 May 2019 15:05:53 -0700
+Subject: [PATCH 1/3] mtd: spinand: Define macros for page-read ops with
+ three-byte addresses
+
+The GigaDevice GD5F1GQ4UFxxG SPI NAND utilizes three-byte addresses
+for its page-read ops.
+
+http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/
+
+Signed-off-by: Jeff Kletsky 
+Reviewed-by: Frieder Schrempf 
+Signed-off-by: Miquel Raynal 
+---
+ include/linux/mtd/spinand.h | 30 ++
+ 1 file changed, 30 insertions(+)
+
+diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
+index 507f7e289bd1..8aa39ac41e8e 100644
+--- a/include/linux/mtd/spinand.h
 b/include/linux/mtd/spinand.h
+@@ -68,30 +68,60 @@
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 1))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_OP_3A(fast, addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(fast ? 0x0b : 0x03, 1),   \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 1))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_X2_OP(addr, ndummy, buf, len)\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0x3b, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 1), \
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 2))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_X2_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0x3b, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 2))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_X4_OP(addr, ndummy, buf, len)\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0x6b, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 1), \
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 4))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_X4_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0x6b, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 4))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(addr, ndummy, buf, len)
\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0xbb, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 2), \
+  SPI_MEM_OP_DUMMY(ndummy, 2), \
+  SPI_MEM_OP_DATA_IN(len, buf, 2))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0xbb, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 2), \
++ SPI_MEM_OP_DUMMY(ndummy, 2), \
++ SPI_MEM_OP_DATA_IN(len, buf, 2))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(addr, ndummy, buf, len)
\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0xeb, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 4), \
+  SPI_MEM_OP_DUMMY(ndummy, 4), \
+  SPI_MEM_OP_DATA_IN(len, buf, 4))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0xeb, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 4

Re: [OpenWrt-Devel] [PATCH 1/2] kernel: mtd: spinand: backport-4.19: Chip support through 5.1

[Jeff Kletsky]

On 6/5/19 1:54 PM, Petr Štetiar wrote:


Jeff Kletsky  [2019-06-05 13:17:05]:

Hi,

I'll put aside, that it's 4.19 (we should still focus on 4.14), can you please
explain in more detail, why we would need all this bacported patches?


  * macronix: Fix ECC Status Read

I can understand this one.


  * winbond: Add support for W25N01GV

This one as well, but then you need to remove existing one in the ipq40xx
patches or you're going to introduce build failure.


  * Add support for GigaDevice GD5F1GQ4UExxG
  * Add support for all Toshiba Memory products
  * add support for GigaDevice GD5FxGQ4xA
  * Add initial support for Toshiba TC58CVG2S0H

What devices currently in the tree need (or want) this? I mean, the more
patches, the more work during kernel bumps, so we should avoid it if the
patches are not necessary.

-- ynezz


Thanks for your time in review, insight, and comments.

The "focus" on 4.19 is for the ath79 target to be able to use SPI NAND
with the upstream support that became available to OpenWrt with 4.19

This will also help OEM/ODMs who have both been told to move off
the ar71xx platform, yet are stymied by the lack of "OpenWrt-approved"
SPI NAND support.

As one example:
https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401

mkresin commented on Nov 26, 2018

But [SPI-NAND support] requires 4.19 to not have to backport
pretty much the whole MTD and SPI subsystems

Please re-spin the patch as soon as we have kernel 4.19 support.
The approach was already NAK'ed upstream and I don't see much gain
in adding the hack if the next major kernel in OpenWrt
will provide a suitable solution.

That direction is embodied in complete and tested local work,
easily extensible to other boards, once accepted by OpenWRT.
However, it requires support of the chips employed in the boards.


The GL.iNet GL-AR300M and GL-AR750S units have been shipped with:

  ParagonPN26G01Ax
  GigaDevice GD5F1GQ4UExxx
  GigaDevice GD5F1GQ4UFxxx

Both of these units have now been successfully ported to OpenWrt with
full NAND support on the ath79/nand target (4.19), including sysupgrade
and, on the AR300M, dual-firmware boot with automated fall-back.
(The GL-AR750S U-Boot only loads the kernel NOR at this time.)

The GigaDevice "F" chips are being used in currently available units.
I understand that Marty (cc-ed), who has worked on the AR300M as well,
has a Paragon-based device, so these chips exist "in the wild" as well.
 
These widely available units also address the similar question about[1]

[OpenWrt-Devel,2/2] kernel: mtd: spinand: Backport GigaDevice "F" from 
linux/next

The Paragon driver is complete, tested, and literally just submitted
to Linux MTD for review[2].

As this driver has not yet undergone upstream review and that there are
Paragon-based units that would otherwise not boot, I am holding the
patch series for these units until the Paragon driver is "cleared" upstream.



The main reason for including the Toshiba devices is to *simplify* bumps.
They all "intermingle" in spinand.h and core.c. Establishing a list consistent
with upstream Linux means that any potential patches should apply smoothly.
By "filling out" the supported devices, the upstream patches in this patch set
apply without significant changes.

  git log --pretty='%h %s'stable/linux-5.1.y ^v4.19.74 -- \
drivers/mtd/nand/spi/ include/linux/mtd/spinand.h

indicates that there are no further patches that impact these files prior to 5.2
Of that list, as called out in the cover to this series and the related commit,
two have already been backported to 4.19.74.

Also, as these patches reflect the state of upstream Linux, they would be 
removed
in their entirely when the next LTS kernel is available, sometime after 5.2.

These drivers are only compiled when CONFIG_MTD_SPI_NAND=y is set by the target.

These targets are only pistachio and ipq4019, with ath79/nand (not /generic) 
WIP.

As a result, they do not impact "tiny" boards, or the often "value-focused"
and low-resource ar71xx, ath79/generic, and ramips boards.

A quick check of removing support of the Toshiba SPI NAND from a local build 
here
shows a change in kernel size in the image of only 366 bytes. This is consistent
with the changes being a set of structs defining the device, and two, brief bits
of code, one for decoding the return status of ECC, the other to check the 
MID/DID.

The run-time impact is effectively zero; if the MID doesn't match, the s/r 
returns.
It is only invoked only during driver-attachment probes, not during "run time".



Thank you for pointing out
patches-4.19/082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch

It appears to be the same patch as present as part of this commit.

I did not find "winbond" elsewhere under target/linux in the context of SPI 
NAND.

If deemed appropriate, th

[OpenWrt-Devel] [PATCH 1/2] kernel: mtd: spinand: backport-4.19: Chip support through 5.1

[Jeff Kletsky]

From: Jeff Kletsky 

generic: Add/rename patches for consistency

ipq40xx: Generic-level patch replaces same-source patches-4.19/
 082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch

Several SPI NAND chips were added between 4.19 and 5.1
including GigaDevice, Toshiba, and Winbond.
A fix to Macronix chips' ECC was also included.

 * Add support for GigaDevice GD5F1GQ4UExxG
 * Add support for all Toshiba Memory products
 * macronix: Fix ECC Status Read
 * add support for GigaDevice GD5FxGQ4xA
 * Add initial support for Toshiba TC58CVG2S0H
 * winbond: Add support for W25N01GV

The following two commits from 5.0 appear already backported upstream
so are not included here:

 * Fix the error/cleanup path in spinand_init()
 * Handle the case where PROGRAM LOAD does not reset the cache

Existing GigaDevice patches reordered to maintain upstream content

Upstream patches refreshed against 4.19.48

Build-tested-on: ipq40xx with TESTING_KERNEL enabled (4.19)
Run-tested-on: ath79/nand (4.19.48, WIP)

Signed-off-by: Jeff Kletsky 
---
 ...nd-winbond-Add-support-for-W25N01GV.patch} |  19 +-
 ...initial-support-for-Toshiba-TC58CVG2.patch | 188 ++
 ...d-support-for-GigaDevice-GD5FxGQ4xA.patch} |  12 +-
 ...spinand-macronix-Fix-ECC-Status-Read.patch |  44 
 ...support-for-all-Toshiba-Memory-produ.patch | 141 +
 ...upport-for-GigaDevice-GD5F1GQ4UExxG.patch} |  13 +-
 6 files changed, 403 insertions(+), 14 deletions(-)
 rename 
target/linux/{ipq40xx/patches-4.19/082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
 => 
generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch}
 (56%)
 create mode 100644 
target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
 rename 
target/linux/generic/backport-4.19/{450-v5.0-mtd-spinand-add-support-for-GigaDevice-GD5FxGQ4xA.patch
 => 423-v5.0-mtd-spinand-add-support-for-GigaDevice-GD5FxGQ4xA.patch} (94%)
 create mode 100644 
target/linux/generic/backport-4.19/426-v5.1-mtd-spinand-macronix-Fix-ECC-Status-Read.patch
 create mode 100644 
target/linux/generic/backport-4.19/427-v5.1-mtd-spinand-Add-support-for-all-Toshiba-Memory-produ.patch
 rename 
target/linux/generic/backport-4.19/{451-v5.1-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UExxG.patch
 => 428-v5.1-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UExxG.patch} (89%)

diff --git 
a/target/linux/ipq40xx/patches-4.19/082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
 
b/target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
similarity index 56%
rename from 
target/linux/ipq40xx/patches-4.19/082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
rename to 
target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
index 22bd985124..7fae1ad2d6 100644
--- 
a/target/linux/ipq40xx/patches-4.19/082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
+++ 
b/target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
@@ -1,20 +1,28 @@
-From 342fc01bfd6d717602c71d96d3ef40a36e45e060 Mon Sep 17 00:00:00 2001
+From 9a4d83074769d6ecf1f5c3fef0f183b09abf3726 Mon Sep 17 00:00:00 2001
 From: Robert Marko 
-Date: Fri, 5 Oct 2018 09:02:50 +0200
-Subject: [PATCH] mtd: spinand: winbond: Add support for W25N01GV
+Date: Sat, 6 Oct 2018 17:36:42 +0200
+Subject: [PATCH 1/8] mtd: spinand: winbond: Add support for W25N01GV
 
 W25N01GV is a single die version of the already supported
 W25M02GV with half the capacity. Everything else is the
 same so introduce support for W25N01GV.
 
+Datasheet:http://www.winbond.com/resource-files/w25n01gv%20revl%20050918%20unsecured.pdf
+
+Tested on 8devices Jalapeno dev board under OpenWrt running 4.19-rc5.
+
 Signed-off-by: Robert Marko 
+Reviewed-by: Boris Brezillon 
+Signed-off-by: Miquel Raynal 
 ---
  drivers/mtd/nand/spi/winbond.c | 8 
  1 file changed, 8 insertions(+)
 
+diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
+index 67baa1b32c00..5d944580b898 100644
 --- a/drivers/mtd/nand/spi/winbond.c
 +++ b/drivers/mtd/nand/spi/winbond.c
-@@ -84,6 +84,14 @@ static const struct spinand_info winbond
+@@ -84,6 +84,14 @@ static const struct spinand_info winbond_spinand_table[] = {
 0,
 SPINAND_ECCINFO(_ooblayout, NULL),
 SPINAND_SELECT_TARGET(w25m02gv_select_target)),
@@ -29,3 +37,6 @@ Signed-off-by: Robert Marko 
  };
  
  /**
+-- 
+2.20.1
+
diff --git 
a/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
 
b/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
new file mode 100644
index 00..ed42f0024b
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
@@ -0,0 +1,188

[OpenWrt-Devel] [PATCH 2/2] kernel: mtd: spinand: Backport GigaDevice "F" from linux/next

[Jeff Kletsky]

From: Jeff Kletsky 

Backport upstream support for GigaDevice GD5F1GQ4UFxxG SPI NAND

 * Add support for GigaDevice GD5F1GQ4UFxxG
 * Add support for two-byte device IDs
 * Define macros for page-read ops with three-byte addresses

Upstream patches refreshed against 4.19.48

Run-tested-on: ath79/nand (4.19.48, WIP)

Signed-off-by: Jeff Kletsky 
---
 ...ne-macros-for-page-read-ops-with-thr.patch |  86 
 ...-Add-support-for-two-byte-device-IDs.patch |  48 +
 ...support-for-GigaDevice-GD5F1GQ4UFxxG.patch | 197 ++
 3 files changed, 331 insertions(+)
 create mode 100644 
target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
 create mode 100644 
target/linux/generic/backport-4.19/432-v5.3-mtd-spinand-Add-support-for-two-byte-device-IDs.patch
 create mode 100644 
target/linux/generic/backport-4.19/433-v5.3-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UFxxG.patch

diff --git 
a/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
 
b/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
new file mode 100644
index 00..87bb35275e
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
@@ -0,0 +1,86 @@
+From d014717d50b1efd011a3a028ce92563a4dc9bae5 Mon Sep 17 00:00:00 2001
+From: Jeff Kletsky 
+Date: Wed, 22 May 2019 15:05:53 -0700
+Subject: [PATCH 1/3] mtd: spinand: Define macros for page-read ops with
+ three-byte addresses
+
+The GigaDevice GD5F1GQ4UFxxG SPI NAND utilizes three-byte addresses
+for its page-read ops.
+
+http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/
+
+Signed-off-by: Jeff Kletsky 
+Reviewed-by: Frieder Schrempf 
+Signed-off-by: Miquel Raynal 
+---
+ include/linux/mtd/spinand.h | 30 ++
+ 1 file changed, 30 insertions(+)
+
+diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
+index 507f7e289bd1..8aa39ac41e8e 100644
+--- a/include/linux/mtd/spinand.h
 b/include/linux/mtd/spinand.h
+@@ -68,30 +68,60 @@
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 1))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_OP_3A(fast, addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(fast ? 0x0b : 0x03, 1),   \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 1))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_X2_OP(addr, ndummy, buf, len)\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0x3b, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 1), \
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 2))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_X2_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0x3b, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 2))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_X4_OP(addr, ndummy, buf, len)\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0x6b, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 1), \
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 4))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_X4_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0x6b, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 4))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(addr, ndummy, buf, len)
\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0xbb, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 2), \
+  SPI_MEM_OP_DUMMY(ndummy, 2), \
+  SPI_MEM_OP_DATA_IN(len, buf, 2))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0xbb, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 2), \
++ SPI_MEM_OP_DUMMY(ndummy, 2), \
++ SPI_MEM_OP_DATA_IN(len, buf, 2))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(addr, ndummy, buf, len)
\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0xeb, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 4

[OpenWrt-Devel] [PATCH 0/2] kernel: mtd: spinand: backport-4.19: Add'l chip support

[Jeff Kletsky]

From: Jeff Kletsky 

Supersedes https://patchwork.ozlabs.org/project/openwrt/list/?series=112040
and addresses related comments

GigaDevice (and a future commit for Paragon) SPI NAND required for
use of SPI NAND on at least GL.iNet GL-AR300M and GL-AR750S, already
on the ath79 target on both openwrt-19./07 and master.

Existing ipq40xx-specific patch for Winbond W25N01GV removed.
Examination of the previous ipq40xx patch
patches-4.19/082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
and the "generic" patch here confirm that they represent the same
content. Build test confirms that the compiled source remains the same.

Toshiba devices included to simplify any future patches by ensuring
that the diff context in spinand.h and core.c is consistent with
upstream Linux. (There are alphabetized lists of manufacturers.)

These drivers are only compiled when CONFIG_MTD_SPI_NAND=y is set by
the target.

These targets are only pistachio and ipq4019, with ath79/nand WIP.

As a result, they do not impact "tiny" boards, or the often
"value-focused" and low-resource ar71xx, ath79/generic, and ramips
boards.

A quick check of removing support of the Toshiba SPI NAND from a local
build here shows a change in kernel size in the image of only 366 bytes.
This is consistent with the changes being a set of structs
defining the device, and two, brief bits of code, one for decoding the
return status of ECC, the other to check the MID/DID.

The run-time impact is effectively zero; if the MID doesn't match, the
s/r returns.  It is only invoked only during driver-attachment probes,
not during "run time".

Signed-off-by: Jeff Kletsky 



Jeff Kletsky (2):
  kernel: mtd: spinand: backport-4.19: Chip support through 5.1
  kernel: mtd: spinand: Backport GigaDevice "F" from linux/next

 ...nd-winbond-Add-support-for-W25N01GV.patch} |  19 +-
 ...initial-support-for-Toshiba-TC58CVG2.patch | 188 +
 ...d-support-for-GigaDevice-GD5FxGQ4xA.patch} |  12 +-
 ...spinand-macronix-Fix-ECC-Status-Read.patch |  44 
 ...support-for-all-Toshiba-Memory-produ.patch | 141 +
 ...upport-for-GigaDevice-GD5F1GQ4UExxG.patch} |  13 +-
 ...ne-macros-for-page-read-ops-with-thr.patch |  86 
 ...-Add-support-for-two-byte-device-IDs.patch |  48 +
 ...support-for-GigaDevice-GD5F1GQ4UFxxG.patch | 197 ++
 9 files changed, 734 insertions(+), 14 deletions(-)
 rename 
target/linux/{ipq40xx/patches-4.19/082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
 => 
generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch}
 (56%)
 create mode 100644 
target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
 rename 
target/linux/generic/backport-4.19/{450-v5.0-mtd-spinand-add-support-for-GigaDevice-GD5FxGQ4xA.patch
 => 423-v5.0-mtd-spinand-add-support-for-GigaDevice-GD5FxGQ4xA.patch} (94%)
 create mode 100644 
target/linux/generic/backport-4.19/426-v5.1-mtd-spinand-macronix-Fix-ECC-Status-Read.patch
 create mode 100644 
target/linux/generic/backport-4.19/427-v5.1-mtd-spinand-Add-support-for-all-Toshiba-Memory-produ.patch
 rename 
target/linux/generic/backport-4.19/{451-v5.1-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UExxG.patch
 => 428-v5.1-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UExxG.patch} (89%)
 create mode 100644 
target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
 create mode 100644 
target/linux/generic/backport-4.19/432-v5.3-mtd-spinand-Add-support-for-two-byte-device-IDs.patch
 create mode 100644 
target/linux/generic/backport-4.19/433-v5.3-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UFxxG.patch

-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] NOHZ: local_softirq_pending 08 -- IPQ4019 on master

[Jeff Kletsky]

Just flashed a build off `master` and am seeing "new" error messages
starting after the network has started, a couple times,
then every 20 seconds, seemingly like clockwork.

root@test:/# dmesg | fgrep NOHZ
[   36.955401] NOHZ: local_softirq_pending 08
[   57.439420] NOHZ: local_softirq_pending 08
[   98.397107] NOHZ: local_softirq_pending 08
[  118.881226] NOHZ: local_softirq_pending 08
[  139.356879] NOHZ: local_softirq_pending 08
[  159.840218] NOHZ: local_softirq_pending 08
[  180.315962] NOHZ: local_softirq_pending 08
[  200.799979] NOHZ: local_softirq_pending 08
[  221.275747] NOHZ: local_softirq_pending 08
[  241.756644] NOHZ: local_softirq_pending 08

Still looking into it, but curious if anyone else is seeing this.

Linux 4.19.53

commit 629e6538a1 (openwrt/master, openwrt/HEAD, master)
Author: Christian Lamparter 
Date:   Sat Jun 22 12:23:10 2019 +0200


Similar behavior on the alternate firmware on the device

commit eaad2211db
Author: Jo-Philipp Wich 
Date:   Fri Jun 21 17:41:28 2019 +0200

root@test:/# dmesg | fgrep NOHZ
[   56.800024] NOHZ: local_softirq_pending 08
[   77.281594] NOHZ: local_softirq_pending 08
[   97.763395] NOHZ: local_softirq_pending 08
[  138.718065] NOHZ: local_softirq_pending 08
[  138.720722] NOHZ: local_softirq_pending 08
[  159.197431] NOHZ: local_softirq_pending 08
[  200.157115] NOHZ: local_softirq_pending 08
[  220.636004] NOHZ: local_softirq_pending 08
[  241.116778] NOHZ: local_softirq_pending 08
[  241.119413] NOHZ: local_softirq_pending 08


Some mention of `NOHZ: local_softirq_pending 08` back in 2012
https://groups.google.com/forum/#!topic/linux.kernel/YeH1CTNT9vU

Other mention at
https://askubuntu.com/questions/878030/occasional-dmesg-log-nohz-local-softirq-pending-08


Add nohz=off to the kernel parameters during boot to disable it.


This option causes RCU to attempt to accelerate grace periods
in order to allow CPUs to enter dynticks-idle state more quickly.
On the other hand, this option increases the overhead
of the dynticks-idle checking, particularly on systems
with large numbers of CPUs.


I'm not sure I'd consider an IPQ4019 to have "large numbers of CPUs"
but I figured I'd lay out what I have found so far.


Jeff

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] sysupgrade: Cross-flashing NOR/NAND proof of concept

[Jeff Kletsky]

From: Jeff Kletsky 

Certain devices can have both NOR- and NAND-resident firmware, such as
the GL.iNet GL-AR300M. These devices can be booted with either firmware.
The GL-AR300M boot loader will automatically fail-over to NOR firmware
after three failed boots, providing end-user benefits when bad flashes
or other "no boot" situations occur.

THIS IS A PROOF OF CONCEPT

The "tricks" are that:

  * The kernel and software for both the NOR- and NAND-resident
variants need to be able to read/write raw MTD as well as UBI.

  * The existing sysupgrade paths already prevent flashing of a
NOR-intended image onto a NAND-based device, as well as the other
way around. As such, even if a approach like this is accepted
after these board names are "in the wild", sysupgrade will be
"safe" on "old" builds against future additions to SUPPORTED_DEVICES.

  * The MTD partitioning for both variants need to define both NOR and
NAND partitioning in a way that:

  * Early init does not try to mount the "wrong" root file system

  * sysupgrade can locate the "other" partitions

This was accomplished in the commit sequence for the GL-AR300M
(linked below) by defining the partitions in a common DTSI with a
"neutered" partition label, prefixing it with nor_ or nand_, then
setting the label as appropriate within the DTS for the specific
build.

It can be used with buildable code for the GL.iNet AR300M that is
being prepared for submission and is presently available at

  https://github.com/jeffsf/openwrt/tree/ath79-nand-2019-06-11

or the latest, similarly named branch. Note that the above code has
not implemented SUPPORTED_DEVICES to allow cross-flashing, so that
sysupgrade -F will be required for those cases (at this time).

It intentionally does *not* switch to the flashed partition at this time.

Past removing my comments/notes in the source, I'd be interesting in
finding out if there are cases that I haven't thought of.

Run-tested-on: GL.iNet AR300M

Signed-off-by: Jeff Kletsky 
---
 .../ath79/base-files/lib/upgrade/platform.sh  | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/target/linux/ath79/base-files/lib/upgrade/platform.sh 
b/target/linux/ath79/base-files/lib/upgrade/platform.sh
index b6f720fd0a..110d459b27 100644
--- a/target/linux/ath79/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ath79/base-files/lib/upgrade/platform.sh
@@ -32,6 +32,67 @@ redboot_fis_do_upgrade() {
fi
 }
 
+nand_nor_do_upgrade() {
+   local upgrade_file="$1"
+
+   local magic
+   local found_nor_part
+
+   # If here, the metadata check has already passed (or --force)
+   # ath79:nand so far only uses uImage and tar files
+
+   magic=$(get_magic_long "$upgrade_file")
+   case "$magic" in
+
+   "27051956") #define IH_MAGIC 0x27051956 /* [U-Boot] Image Magic 
Number */
+
+   found_nor_part="Not yet"
+   for pn in "$PART_NAME" "nor_${PART_NAME}" ; do  # 
firmware
+
+   if [ "$(find_mtd_index "$pn")" ] ; then
+   PART_NAME="$pn"
+   found_nor_part=''
+   >&2 printf "Running NOR upgrade\n"
+   default_do_upgrade "$upgrade_file"
+   fi
+   done
+   if [ -n "$found_nor_part" ] ; then
+   >&2 printf "ERROR: UPGRADE FAILED: Unable to locate 
'$PART_NAME' or 'nor_${PART_NAME}'\n"
+   sleep 5
+   exit 1
+   fi
+   ;;
+
+
+   *)  # has to be a tar file of some sort
+
+   for pn in "$CI_KERNPART" "nand_${CI_KERNPART}" ; do # kernel
+
+   if [ "$(find_mtd_index "$pn")" ] ; then
+   CI_KERNPART="$pn"
+   break
+   fi
+   done
+   for pn in "$CI_UBIPART" "nand_${CI_UBIPART}" ; do   # ubi
+
+   if [ "$(find_mtd_index "$pn")" ] ; then
+   CI_UBIPART="$pn"
+   break
+   fi
+   done
+   for pn in "$CI_ROOTPART" "nand_${CI_ROOTPART}" ; do #rootfs
+
+   if [ "$(find_mtd_index "$pn")" ] ; then
+   CI_ROOTPART="$pn"
+   break
+   fi
+   done
+   >&2 printf "Running NAND u

[OpenWrt-Devel] [PATCH] base-files: sysupgrade: Bring down wifi just before killall

[Jeff Kletsky]

From: Jeff Kletsky 

Wifi can, in certain situations, cause sysupgrade to fail silently
with a 256 return value as all processes can't be killed.
One of these situations is mesh with batman-adv active.

Added `wifi down` just prior to the killall sequence in stage2

Run-tested-on: Linksys EA8300

Signed-off-by: Jeff Kletsky 
---
 package/base-files/files/lib/upgrade/stage2 | 4 
 1 file changed, 4 insertions(+)

diff --git a/package/base-files/files/lib/upgrade/stage2 
b/package/base-files/files/lib/upgrade/stage2
index bdc12c7426..d911614e36 100755
--- a/package/base-files/files/lib/upgrade/stage2
+++ b/package/base-files/files/lib/upgrade/stage2
@@ -124,6 +124,10 @@ kill_remaining() { # [  [  ] ]
 
 indicate_upgrade
 
+if [ -x "$(which wifi)" ] ; then
+wifi down
+sleep 1
+fi
 killall -9 telnetd
 killall -9 dropbear
 killall -9 ash
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/1] ipq40xx: Linksys: sysupgrade: Ensure OEM volumes are removed

[Jeff Kletsky]

From: Jeff Kletsky 

When OEM volumes are present in the [alt_]firmware partition,
sysupgrade will write a new kernel, but will fail to write
the root file system. The next boot will hang indefinitely

Waiting for root device /dev/ubiblock0_0...

Modified ipq40xx/base-files/lib/upgrade/linksys.sh
to remove both `squashfs` and `ubifs` if found
on the target firmware partition's UBI device.

Run-tested-on: Linksys EA8300

Signed-off-by: Jeff Kletsky 
---
 .../ipq40xx/base-files/lib/upgrade/linksys.sh | 22 +++
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh 
b/target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
index b8e6dd7352..a6cf5d8de9 100755
--- a/target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
+++ b/target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
@@ -1,3 +1,5 @@
+#!/bin/sh
+
 linksys_get_target_firmware() {
 
local cur_boot_part mtd_ubi0
@@ -53,8 +55,12 @@ linksys_get_root_magic() {
 }
 
 platform_do_upgrade_linksys() {
+
local magic_long="$(get_magic_long "$1")"
 
+   local rm_oem_fw_vols="squashfs ubifs"   # from OEM [alt_]rootfs UBI
+   local vol
+
mkdir -p /var/lock
local part_label="$(linksys_get_target_firmware)"
touch /var/lock/fw_printenv.lock
@@ -64,7 +70,7 @@ platform_do_upgrade_linksys() {
exit 1
fi
 
-   local target_mtd=$(find_mtd_part $part_label)
+   local target_mtd=$(find_mtd_part "$part_label")
 
[ "$magic_long" = "73797375" ] && {
CI_KERNPART="$part_label"
@@ -74,8 +80,6 @@ platform_do_upgrade_linksys() {
CI_UBIPART="alt_rootfs"
fi
 
-   # remove "squashfs" vol (in case we are flashing over a stock 
image, which is also UBI)
-
local mtdnum="$( find_mtd_index "$CI_UBIPART" )"
if [ ! "$mtdnum" ]; then
echo "cannot find ubi mtd partition $CI_UBIPART"
@@ -89,15 +93,14 @@ platform_do_upgrade_linksys() {
ubidev="$( nand_find_ubi "$CI_UBIPART" )"
fi
 
-   if [ "$ubidev" ]; then
-   local squash_ubivol="$( nand_find_volume $ubidev 
squashfs )"
-   # kill volume
-   [ "$squash_ubivol" ] && ubirmvol /dev/$ubidev -N 
squashfs || true
-   fi
+   [ "$ubidev" ] && for vol in $rm_oem_fw_vols ; do
+   ubirmvol "/dev/$ubidev" -N "$vol" 2>/dev/null
+   done
 
# complete std upgrade
nand_upgrade_tar "$1"
}
+
[ "$magic_long" = "27051956" ] && {
# This magic is for a uImage (which is a sysupgrade image)
# check firmwares' rootfs types
@@ -107,7 +110,8 @@ platform_do_upgrade_linksys() {
if [ "$newroot" = "55424923" -a "$oldroot" = "55424923" ]; then
# we're upgrading from a firmware with UBI to one with 
UBI
# erase everything to be safe
-   # - Is that really needed? Won't remove (or comment) 
the if, because it may be needed in a future device.
+   # - Is that really needed? Won't remove (or comment) 
the if,
+   #   because it may be needed in a future device.
#mtd erase $part_label
#get_image "$1" | mtd -n write - $part_label
echo "writing \"$1\" UBI image to \"$part_label\" 
(UBI)..."
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/1] ipq40xx: Linksys: sysupgrade: Ensure OEM volumes are removed

[Jeff Kletsky]

From: Jeff Kletsky 

User reported that second sysupgrade of EA8300 resulted in hang

Problem determined to be that an OEM "ubifs" volume was present
in the OEM firmware, like the already handled "squashfs" volume.

Recommend applying/backporting to openwrt-19.07

Jeff


Jeff Kletsky (1):
  ipq40xx: Linksys: sysupgrade: Ensure OEM volumes are removed

 .../ipq40xx/base-files/lib/upgrade/linksys.sh | 22 +++
 1 file changed, 13 insertions(+), 9 deletions(-)

-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Build system puzzles: PCI_SUPPORT not being set for subtarget

[Jeff Kletsky]

On 5/9/19 10:49 AM, Robert Marko wrote:


I don't see any differences between the generic and nand subtargets'
`config-default`, `target.mk`, or `image/*.mk` that seem related to
PCI_SUPPORT.

Well, generic target has PCI symbols enabled in config-default
https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/generic/config-default#L14

So you gotta enable those in nand too.


I had already tried that, as well as my understanding about the "inheritance"
of the various layers of config-4.xx and config-default that I also queried 
about.

I reconfirmed that

  openwrt/target/linux/ath79$ cp generic/config-default nand/config-default
  openwrt$ cat /dev/null > .config
  openwrt$ make menuconfig

has the same behavior -- the nand target does not set PCI_SUPPORT

Jeff


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] utils/spidev_test: Update to current source from upstream Linux

[Jeff Kletsky]

On 5/10/19 11:18 PM, Christian Lamparter wrote:


On Friday, May 10, 2019 3:56:37 PM CEST l...@allycomm.com wrote:

From: Jeff Kletsky 

Incorporates multiple changes, including file-based input and output

 From upstream commit:

 commit 35386dfd13b7
 Author: Geert Uytterhoeven 
 Date:   Mon Sep 3 19:33:23 2018 +0200

Signed-off-by: Jeff Kletsky 
---

Hm, this got me thinking. Because we could also just do what the perf
package does and built the spidev_test from the device's linux kernel
source and ship it. This would also entail that we don't need to ship
the spidev_test.c in package/utils/spidev_test/src anymore. What do you
think?

Cheers,
Christian

---
diff --git a/package/utils/spidev_test/Makefile 
b/package/utils/spidev_test/Makefile
index b7c5227f91..29c6a90dc8 100644
--- a/package/utils/spidev_test/Makefile
+++ b/package/utils/spidev_test/Makefile
@@ -10,13 +10,16 @@ include $(INCLUDE_DIR)/kernel.mk
  
  PKG_NAME:=spidev-test

  PKG_RELEASE:=$(LINUX_VERSION)
+PKG_FLAGS:=nonshared
+PKG_BUILD_DIR:=$(LINUX_DIR)/tools/spi-$(TARGET_DIR_NAME)
+PKG_BUILD_PARALLEL:=1
  
  include $(INCLUDE_DIR)/package.mk
  
  define Package/spidev-test

SECTION:=utils
CATEGORY:=Utilities
-  DEPENDS:=+kmod-spi-dev
+  DEPENDS:=+kmod-spi-dev @!IN_SDK
TITLE:=SPI testing utility
VERSION:=$(LINUX_VERSION)-$(PKG_RELEASE)
URL:=http://www.kernel.org
@@ -27,9 +30,26 @@ define Package/spidev-test/description
SPI testing utility.
  endef
  
+define Build/Prepare

+   $(CP) $(LINUX_DIR)/tools/spi/* $(PKG_BUILD_DIR)/
+endef

[...]


Sounds great to me!

It's one of those packages that probably only a couple people a year
need, but when they need it, they really need it. The way you proposed
means that it is as current as the Linux version in hand without further
attention.

I was going to say that it would be a couple days until I was back home
and able to look into it and test as I'm on travel, but it looks like
you've already got things well in order. If you want to go ahead with
your patch, I think it's a much better approach.

Jeff

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Build system puzzles: PCI_SUPPORT not being set for subtarget

[Jeff Kletsky]

On 5/9/19 7:28 PM, Tomasz Maciej Nowak wrote:


Hi Jeff,

W dniu 09.05.2019 o 18:25, Jeff Kletsky pisze:

On 5/9/19 12:04 PM, Petr Štetiar wrote:


Jeff Kletsky  [2019-05-09 11:23:18]:


I reconfirmed that

    openwrt/target/linux/ath79$ cp generic/config-default nand/config-default
    openwrt$ cat /dev/null > .config
    openwrt$ make menuconfig

has the same behavior -- the nand target does not set PCI_SUPPORT

it works here(tm):

   CONFIG_TARGET_ath79=y
   CONFIG_TARGET_ath79_nand=y
   CONFIG_TARGET_ath79_nand_DEVICE_glinet_gl-ar300m-nand=y
   CONFIG_ATH10K-CT_LEDS=y
   CONFIG_DRIVER_11AC_SUPPORT=y
   CONFIG_PACKAGE_kmod-ath10k-ct=y
   CONFIG_PACKAGE_kmod-hwmon-core=y

-- ynezz

What I'm seeing is that ath10k gets stripped out for nand,
but not for nor. I ran "virgin" tests with the scripts below,
with the same config-default in both generic/ and nand/.

I did run Your script for nand and this is the output (removed feeds to 
speed-up):

[tomek@vaio-vpcz1 openwrt]$ ./test.sh
Cloning into 'openwrt-nand-test'...

[...]

# CONFIG_PACKAGE_ath10k-firmware-qca99x0-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca99x0-ct-htt is not set
# CONFIG_PACKAGE_kmod-ath10k is not set
CONFIG_PACKAGE_kmod-ath10k-ct=y

So it appears to work.


[...]

When adding changes to target/subtarget config sometimes It's necessary to 
remove
$(TOPDIR)/tmp to see changes, maybe that's the issue You were hitting?

Regards

--
TMN


Removing $(TOPDIR)/tmp did resolve the issue, thanks!

Still somewhat puzzling, but enough to let me proceed here
and come back to see if I can improve the dependencies another day.

The time of all involved is greatly appreciated.


Jeff

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Build system puzzles: PCI_SUPPORT not being set for subtarget

[Jeff Kletsky]

On 5/9/19 12:04 PM, Petr Štetiar wrote:


Jeff Kletsky  [2019-05-09 11:23:18]:


I reconfirmed that

   openwrt/target/linux/ath79$ cp generic/config-default nand/config-default
   openwrt$ cat /dev/null > .config
   openwrt$ make menuconfig

has the same behavior -- the nand target does not set PCI_SUPPORT

it works here(tm):

  CONFIG_TARGET_ath79=y
  CONFIG_TARGET_ath79_nand=y
  CONFIG_TARGET_ath79_nand_DEVICE_glinet_gl-ar300m-nand=y
  CONFIG_ATH10K-CT_LEDS=y
  CONFIG_DRIVER_11AC_SUPPORT=y
  CONFIG_PACKAGE_kmod-ath10k-ct=y
  CONFIG_PACKAGE_kmod-hwmon-core=y

-- ynezz


What I'm seeing is that ath10k gets stripped out for nand,
but not for nor. I ran "virgin" tests with the scripts below,
with the same config-default in both generic/ and nand/.

Perhaps I am missing something or misunderstood, but below
is what I'm seeing with what I interpreted as .config seed above.

Both

  # CONFIG_PACKAGE_kmod-ath10k is not set
  CONFIG_PACKAGE_kmod-ath10k-ct=y

are missing for the nand subtarget.


I'm willing to track this down (as I've got an AR750S
running on NAND, including sysupgrade), but at least so far
I haven't been successful in getting output from
scripts/kconfig.pl to confirm that it is what is generating
the config from the various pieces at the generic-Linux, target,
and subtarget levels. Is there a different place I should
be looking?


Jeff



glinet_gl-ar300m-nor


CONFIG_PACKAGE_kmod-ath10k-ct=y


=

'target/linux/ath79/generic/config-default' -> 
'target/linux/ath79/nand/config-default'
Collecting package info: done
configuration written to .config

*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

# ath10k IPQ4019 Boarddata
# CONFIG_PACKAGE_ath10k-firmware-qca4019 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca4019-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca4019-ct-htt is not set
# CONFIG_PACKAGE_ath10k-firmware-qca6174 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9887 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9887-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9887-ct-htt is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9888 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9888-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9888-ct-htt is not set
# CONFIG_PACKAGE_ath10k-firmware-qca988x is not set
# CONFIG_PACKAGE_ath10k-firmware-qca988x-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca988x-ct-htt is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9984 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9984-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9984-ct-htt is not set
# CONFIG_PACKAGE_ath10k-firmware-qca99x0 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca99x0-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca99x0-ct-htt is not set
# CONFIG_PACKAGE_kmod-ath10k is not set
CONFIG_PACKAGE_kmod-ath10k-ct=y



glinet_gl-ar300m-nand
-

CONFIG_PACKAGE_kmod-ath10k-ct=y


=

'target/linux/ath79/generic/config-default' -> 
'target/linux/ath79/nand/config-default'
Collecting package info: done
configuration written to .config

*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

# ath10k IPQ4019 Boarddata
# CONFIG_PACKAGE_ath10k-firmware-qca4019 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca4019-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca6174 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9887 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9887-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9888 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9888-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca988x is not set
# CONFIG_PACKAGE_ath10k-firmware-qca988x-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9984 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca9984-ct is not set
# CONFIG_PACKAGE_ath10k-firmware-qca99x0 is not set
# CONFIG_PACKAGE_ath10k-firmware-qca99x0-ct is not set



Scripts to replicate:

test-nor.sh
---

#!/bin/bash

mkdir -p ~/devel/ 2>/dev/null

cd ~/devel/

git clone https://git.openwrt.org/openwrt/openwrt.git openwrt-nor-test
cd openwrt-nor-test
git checkout master
./scripts/feeds update -a
./scripts/feeds install -a
cat > .config </dev/null

cd ~/devel/

git clone https://git.openwrt.org/openwrt/openwrt.git openwrt-nand-test
cd openwrt-nand-test
git checkout master
./scripts/feeds update -a
./scripts/feeds install -a
cat > .config <https://git.openwrt.org/openwrt/openwrt.git openwrt-nor-test
< cd openwrt-nor-test
---

git clone https://git.openwrt.org/openwrt/openwrt.git openwrt-nand-test
cd openwrt-nand-test

14,15c14,15
< CONFIG_TARGET_ath79_generic=y
< CONFIG_TARGET_ath79_generic_DEVICE_glinet_gl-ar300m-nor=y
---

CONFIG_TARGET_ath79_nand=y
CONFIG_TARGET_ath79_nand_DEVICE_glinet_gl-ar300m-nand=y




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Build system puzzles: PCI_SUPPORT not being set for subtarget

[Jeff Kletsky]

I'm having some challenges understanding why PCI_SUPPORT is being set
for the "generic" target, but not being set for the "nand" subtarget.
This seems to be the cause for the ath10k drivers not being available
in menuconfig.

While this has become an issue with the first port of an ath79 device
using the spinand framework backported to Linux 4.19, it can be seen
on `master` without any modifications.

All that follows is based on `master` as of

  commit 165d598521 (HEAD -> master, openwrt/master)
  Author: Hans Dedecker 
  Date:   Wed May 8 21:52:20 2019 +0200


To replicate:

* Check out `master`
* `make menuconfig`

* Select
  * Target System (Atheros ATH79 (DTS))
  * Subtarget (Generic)
  * Target Profile (GL.iNet GL-AR300M)
* Search (with /) for "mod-ath10k"
* Note that
  * PACKAGE_kmod-ath10k-ct is available for selection
  * It "Depends on: PCI_SUPPORT [=y] && ..."
* Exit from the search

* Change the selection to
  * Target System (Atheros ATH79 (DTS))
  * Subtarget (Generic devices with NAND flash)
  * Target Profile (GL.iNet GL-AR300M (NAND))
* Search (with /) for "mod-ath10k"
* Note that
  * PACKAGE_kmod-ath10k-ct is *not* available for selection
  * It "Depends on: PCI_SUPPORT [=n] && ..."

I don't see any differences between the generic and nand subtargets'
`config-default`, `target.mk`, or `image/*.mk` that seem related to
PCI_SUPPORT.

FEATURES don't seem to come into play at the target level

  target/linux/ath79$ fgrep -r FEATURES .
  ./Makefile:FEATURES:=ramdisk
  ./tiny/target.mk:FEATURES += squashfs small_flash
  ./nand/target.mk:FEATURES += squashfs nand rtc
  ./generic/target.mk:FEATURES += squashfs

I've tried adding FEATURES += pci with no apparent change in behavior.

I've tried to follow through `include/target.mk` and `scripts/kconfig.pl`
around LINUX_KCONFIG_LIST and LINUX_RECONFIG_LIST and it appears to me
that the "starting" config is generic, then platform, then subtarget,
(then local from ./env/, at least for compile). __config_name_list
suggests to me that `config-4.x` is processed before `config-default`
for each of these levels. It seems that this is a "last wins" process
for each specific config line.

Is my understanding of this process correct?

Can you provide any insight as how to resolve this specific problem
with PCI_SUPPORT?

Thanks,

Jeff




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] sysupgrade-tar: board_name in Image Generation vs. Run Time

[Jeff Kletsky]

TL;DR

What would be a workable plan to reconcile mfgr_specific-board-name
at image-generation time with mfgr,specific-board-name at run time?



With the apparent tree-wide changes in progress to canonicalize board
naming of TARGET_DEVICES to mfgr_specific-board-name, there becomes a
disconnect between the board name at image generation and run time.

This results in a "disconnect" between what is used in the tar file as
the directory name and CONTROL contents by `scripts/sysupgrade-tar.sh`

mkdir -p "${tmpdir}/sysupgrade-${board}"
echo "BOARD=${board}" > "${tmpdir}/sysupgrade-${board}/CONTROL"
[ -z "${rootfs}" ] || cp "${rootfs}" "${tmpdir}/sysupgrade-${board}/root"
[ -z "${kernel}" ] || cp "${kernel}" "${tmpdir}/sysupgrade-${board}/kernel"

where ${board} is, for example, `glinet_gl-ar750s-nand`

and what is checked (or should be checked) by nand_do_platform_check()
in `package/base-files/files/lib/upgrade/nand.sh`

tar xf $tar_file sysupgrade-$board_name/CONTROL

where $(board_name) returns the comma-delimited form, `glinet,gl-ar750s-nand`
(The contents of CONTROL are not checked at this time, but would suffer
from the same mismatch issues.)

The metadata commonly attached to the sysupgrade bundle often uses
the run-time, comma-delimited form in "supported_devices", yet the
build-time, underscore-delimited form in "board".



At this time, there appear to be very few boards that actually call
nand_do_platform_check(). Many still have board names that don't
appear to be what I believe is canonical:

  * layerscape
  * pistachio
  * imx6
  * ar71xx

While most either explicitly set the board name in the call or have
comma-less board names, `sysupgrade-img,pistachio-marduk` makes a
global, `tr ',' '_'` an unacceptable work-around.



I can see a few paths forward on this, but don't have the project
history and insight to properly evaluate them.

Of the options out there that I've considered, transitioning
scripts/sysupgrade-tar to use the run-time, comma-delimited form that
is returned by $(board_name) seems the cleanest, at least to me.



I can work around this for now with a device-specific workaround, but
it seems to be something that should be considered going forward,
perhaps before v19 is "cut" to reduce future upgrade issues.


Jeff


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/3] ath79: Extend GL.iNet AR750S support to NAND file system

[Jeff Kletsky]

The following patches prepare for and implement support of the
NAND-based, GL.iNet AR750S under the upstream spi-nand framework
available in Linux 4.19 and later.

Existing commit 3bc8ed91d4 on `master` backports upstream support for
certain GigaDevice SPI NAND devices in the "A" and "E" series.

The AR750S, however, uses a GD5F1GQ4UFxxG SPI NAND, which was not
supported upstream. Patch 1 of this series represents the current code
to support this chip, submitted upstream[1] and under review. This has
received a positive review, but no formal "ACK" at this time.

In the process of preparing for the updated subtarget, the existing
GL.iNet AR300M (NAND) board was removed as it has been non-bootable
and it appears that the definitions in image/nand.mk may not be
consistent with GigaDevice SPI NAND. The DTS and other files have been
retainied. It should be reasonably straightforward for someone with an
NAND-bearing AR300M to complete the port, with the AR750S as a template.


dmesg of the AR750S running with NAND is available at

https://gist.github.com/jeffsf/7fd567b4da3874893111d8ac841d2987


[0.338008] ar7200-usb-phy usb-phy: phy reset is missing

is bothersome, but a check of the DTS which inherits from qca956x.dtsi,
the running device, and the ar7200-usb-phy code has not led to any
clear cause. The USB subsystem appears to work properly, allowing
access to a USB "stick" as well as the microSD reader.  /1 and
_phy0/1 have been enabled and the corresponding rst/rst2 are
unmodified from qca956x.dtsi. Disabling one or the other of the USBs
doesn't change the message. There has been some mention that this
is "normal"[2]. If you've got some further insight into this, I would
certainly try to resolve it.

Current NAND-based kernel size is 1,811,125 bytes, including the
addition of ext4 support. As the NOR version uses the typical
kernel+squashfs+jffs2 scheme, a residual NOR-based root file system is
likely not readable from an over-flashed NAND install at this time.

The NOR-based variant remains on Linux 4.14 with the other ath79
generic targets. The NOR-based kernel size is 1,619,638 bytes.


Jeff




[1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=107874

[2] https://forum.openwrt.org/t/porting-guide-ar71xx-to-ath79/13013/788





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] ath79: Prepare nand subtarget for SPI-NAND boards under Linux 4.19

[Jeff Kletsky]

From: Jeff Kletsky 

Linux 4.19 supplies the upstream spi-nand framework,
permitting porting and support of boards with SPI NAND.

  * Adjusted nand/target.mk to set KERNEL_PATCHVER:=4.19
and provide FEATURES += squashfs nand

  * Updated config-default to provide current MTD and UBI support

  * Removed non-functional GL.iNet AR300M NAND target

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/image/nand.mk   | 13 ---
 target/linux/ath79/nand/config-default | 32 +++---
 target/linux/ath79/nand/target.mk  | 10 +---
 3 files changed, 26 insertions(+), 29 deletions(-)

diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index eee419194b..e69de29bb2 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -1,13 +0,0 @@
-define Device/glinet_gl-ar300m-nand
-  ATH_SOC := qca9531
-  DEVICE_TITLE := GL-AR300M (NAND)
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage 
kmod-usb-ledtrig-usbport
-  KERNEL_SIZE := 2048k
-  BLOCKSIZE := 128k
-  PAGESIZE := 2048
-  VID_HDR_OFFSET := 512
-  IMAGES += factory.ubi
-  IMAGE/sysupgrade.bin := sysupgrade-tar
-  IMAGE/factory.ubi := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
-endef
-TARGET_DEVICES += glinet_gl-ar300m-nand
diff --git a/target/linux/ath79/nand/config-default 
b/target/linux/ath79/nand/config-default
index 738c29c9b1..05a5a8dbd0 100644
--- a/target/linux/ath79/nand/config-default
+++ b/target/linux/ath79/nand/config-default
@@ -1,14 +1,20 @@
-CONFIG_BCH=y
-CONFIG_MTD_NAND=y
-CONFIG_MTD_NAND_BCH=y
-CONFIG_MTD_NAND_ECC=y
-CONFIG_MTD_NAND_ECC_BCH=y
-CONFIG_MTD_SPINAND_MT29F=y
-CONFIG_MTD_SPINAND_ONDIEECC=y
+CONFIG_BLK_MQ_PCI=y
+CONFIG_LEDS_RESET=y
+CONFIG_MTD_NAND_CORE=y
+CONFIG_MTD_SPI_NAND=y
 CONFIG_MTD_UBI=y
-CONFIG_MTD_UBI_BEB_LIMIT=20
-# CONFIG_MTD_UBI_BLOCK is not set
-# CONFIG_MTD_UBI_FASTMAP is not set
-# CONFIG_MTD_UBI_GLUEBI is not set
-CONFIG_MTD_UBI_WL_THRESHOLD=4096
-# CONFIG_UBIFS_FS is not set
+CONFIG_MTD_UBI_BLOCK=y
+CONFIG_OF_ADDRESS_PCI=y
+CONFIG_OF_PCI=y
+CONFIG_OF_PCI_IRQ=y
+CONFIG_PCI=y
+# CONFIG_PCI_AR71XX is not set
+CONFIG_PCI_AR724X=y
+CONFIG_PCI_DISABLE_COMMON_QUIRKS=y
+CONFIG_PCI_DOMAINS=y
+# CONFIG_PHY_AR7100_USB is not set
+CONFIG_PHY_AR7200_USB=y
+CONFIG_UBIFS_FS=y
+CONFIG_UBIFS_FS_ADVANCED_COMPR=y
+CONFIG_UBIFS_FS_LZO=y
+CONFIG_UBIFS_FS_ZLIB=y
diff --git a/target/linux/ath79/nand/target.mk 
b/target/linux/ath79/nand/target.mk
index 91afe675c5..6ab9748ca4 100644
--- a/target/linux/ath79/nand/target.mk
+++ b/target/linux/ath79/nand/target.mk
@@ -1,9 +1,13 @@
 BOARDNAME := Generic devices with NAND flash
-FEATURES += squashfs nand rtc
+
+# SPI NAND support requires at least Linux 4.19
+KERNEL_PATCHVER:=4.19
+
+FEATURES += squashfs nand
 
 DEFAULT_PACKAGES += wpad-basic
 
 define Target/Description
-   Build firmware for Atheros AR71xx/AR913x based boards with
-   NAND flash, e.g. Netgear WNDR4300.
+   Firmware for boards based on MIPS 24kc Atheros/Qualcomm SoCs
+   in the ar72xx and subsequent generations with support for NAND flash
 endef
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] mtd: spinand: Add support for GigaDevice GD5F1GQ4UFxxG (Pending)

[Jeff Kletsky]

From: Jeff Kletsky 

Submitted upstream as https://patchwork.ozlabs.org/patch/1098024/

The GigaDevice GD5F1GQ4UFxxG SPI NAND is in current production devices
and, while it has the same logical layout as the E-series devices,
it differs in the SPI interfacing in significant ways.

To accommodate these changes, this patch also:

  * Adds support for two-byte manufacturer IDs
  * Adds #define-s for three-byte addressing for read ops

http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/

Signed-off-by: Jeff Kletsky 
---
 ...support-for-gigadevice-gd5f1gq4ufxxg.patch | 255 ++
 1 file changed, 255 insertions(+)
 create mode 100644 
target/linux/generic/pending-4.19/452-mtd-spinand-add-support-for-gigadevice-gd5f1gq4ufxxg.patch

diff --git 
a/target/linux/generic/pending-4.19/452-mtd-spinand-add-support-for-gigadevice-gd5f1gq4ufxxg.patch
 
b/target/linux/generic/pending-4.19/452-mtd-spinand-add-support-for-gigadevice-gd5f1gq4ufxxg.patch
new file mode 100644
index 00..9687e28154
--- /dev/null
+++ 
b/target/linux/generic/pending-4.19/452-mtd-spinand-add-support-for-gigadevice-gd5f1gq4ufxxg.patch
@@ -0,0 +1,255 @@
+Index: linux-4.19.37/drivers/mtd/nand/spi/gigadevice.c
+===
+--- linux-4.19.37.orig/drivers/mtd/nand/spi/gigadevice.c
 linux-4.19.37/drivers/mtd/nand/spi/gigadevice.c
+@@ -9,11 +9,17 @@
+ #include 
+ 
+ #define SPINAND_MFR_GIGADEVICE0xC8
++
+ #define GD5FXGQ4XA_STATUS_ECC_1_7_BITFLIPS(1 << 4)
+ #define GD5FXGQ4XA_STATUS_ECC_8_BITFLIPS  (3 << 4)
+ 
+ #define GD5FXGQ4UEXXG_REG_STATUS2 0xf0
+ 
++#define GD5FXGQ4UXFXXG_STATUS_ECC_MASK(7 << 4)
++#define GD5FXGQ4UXFXXG_STATUS_ECC_NO_BITFLIPS (0 << 4)
++#define GD5FXGQ4UXFXXG_STATUS_ECC_1_3_BITFLIPS(1 << 4)
++#define GD5FXGQ4UXFXXG_STATUS_ECC_UNCOR_ERROR (7 << 4)
++
+ static SPINAND_OP_VARIANTS(read_cache_variants,
+   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+@@ -22,6 +28,14 @@ static SPINAND_OP_VARIANTS(read_cache_va
+   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+ 
++static SPINAND_OP_VARIANTS(read_cache_variants_f,
++  SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
++  SPINAND_PAGE_READ_FROM_CACHE_X4_OP_3A(0, 1, NULL, 0),
++  SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
++  SPINAND_PAGE_READ_FROM_CACHE_X2_OP_3A(0, 1, NULL, 0),
++  SPINAND_PAGE_READ_FROM_CACHE_OP_3A(true, 0, 1, NULL, 0),
++  SPINAND_PAGE_READ_FROM_CACHE_OP_3A(false, 0, 0, NULL, 0));
++
+ static SPINAND_OP_VARIANTS(write_cache_variants,
+   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+   SPINAND_PROG_LOAD(true, 0, NULL, 0));
+@@ -59,6 +73,11 @@ static int gd5fxgq4xa_ooblayout_free(str
+   return 0;
+ }
+ 
++static const struct mtd_ooblayout_ops gd5fxgq4xa_ooblayout = {
++  .ecc = gd5fxgq4xa_ooblayout_ecc,
++  .free = gd5fxgq4xa_ooblayout_free,
++};
++
+ static int gd5fxgq4xa_ecc_get_status(struct spinand_device *spinand,
+u8 status)
+ {
+@@ -83,7 +102,7 @@ static int gd5fxgq4xa_ecc_get_status(str
+   return -EINVAL;
+ }
+ 
+-static int gd5fxgq4uexxg_ooblayout_ecc(struct mtd_info *mtd, int section,
++static int gd5fxgq4_variant2_ooblayout_ecc(struct mtd_info *mtd, int section,
+  struct mtd_oob_region *region)
+ {
+   if (section)
+@@ -95,7 +114,7 @@ static int gd5fxgq4uexxg_ooblayout_ecc(s
+   return 0;
+ }
+ 
+-static int gd5fxgq4uexxg_ooblayout_free(struct mtd_info *mtd, int section,
++static int gd5fxgq4_variant2_ooblayout_free(struct mtd_info *mtd, int section,
+   struct mtd_oob_region *region)
+ {
+   if (section)
+@@ -108,6 +127,11 @@ static int gd5fxgq4uexxg_ooblayout_free(
+   return 0;
+ }
+ 
++static const struct mtd_ooblayout_ops gd5fxgq4_variant2_ooblayout = {
++  .ecc = gd5fxgq4_variant2_ooblayout_ecc,
++  .free = gd5fxgq4_variant2_ooblayout_free,
++};
++
+ static int gd5fxgq4uexxg_ecc_get_status(struct spinand_device *spinand,
+   u8 status)
+ {
+@@ -150,15 +174,25 @@ static int gd5fxgq4uexxg_ecc_get_status(
+   return -EINVAL;
+ }
+ 
+-static const struct mtd_ooblayout_ops gd5fxgq4xa_ooblayout = {
+-  .ecc = gd5fxgq4xa_ooblayout_ecc,
+-  .free = gd5fxgq4xa_ooblayout_free,
+-};
++static int gd5fxgq4ufxxg_ecc_get_status(struct spinand_device *spinand,
++  u8 status)
++{
++  switch (status & GD5FXGQ4UXFXXG_STATUS_ECC_MASK) {
++  case GD5FXGQ4UXFXXG_STATUS_ECC_NO_BITFLIPS:
++  return 0;
+ 
+-static const struct mtd_ooblayout_ops 

[OpenWrt-Devel] [PATCH 3/3] ath79: Extend GL.iNet AR750S support to NAND file system

[Jeff Kletsky]

From: Jeff Kletsky 

The GL.iNet AR750S ("Slate") is a dual-band, compact "travel router"
which has previously been supported by OpenWrt with only its NOR flash
accessible.

This ports the device to both NOR and NAND flash using the
upstream SPI NAND framework available in Linux 4.19

Device Highlights

* QCA9563 at 775 MHz
* QCA9887
* External antennas (2x)
* 128 MB DDR RAM
* 16 MB SPI NOR flash
* 128 MB SPI NAND flash
* 3x GigE ports
* USB 2 port
* microSD (USB-attached)
* One button, one switch
* I2C and serial headers
* OEM U-Boot supplies HTTP/GUI access
* Runs off 5 V supplied over microUSB

Implementation Notes


Both the NOR and NAND variants boot off a NOR-based kernel,
consistent with the OEM's firmware.

The mode LEDs are

* Boot, Running   power
* Failsafe2G
* Upgrade 5G

Installation


Using sysupgrade


sysupgrade may be used to install a NAND image on a device running
a NAND image or a NOR image on a device running a NOR image. It is
recommended to *not* preserve config when upgrading from OEM firmware
or previous versions of OpenWrt. No supported sysupgrade path should
require "force". Transitioning from NOR to NAND can be accomplished
using U-Boot.

To glinet_ar750s-nand:

gl-ar750s  OEM NAND, Self-built from OEM source NAND

To glinet_ar750s-nor:

gl-ar750s  Self-built from OEM source NOR
glinet_gl-ar750s   OpenWrt NOR (prior builds)

Using U-Boot


The OEM U-Boot can be put into a graphical, firmware-upload mode by
holding down the button on the side of the router while applying power
and for a bit more than five seconds following with the current OEM
U-Boot. The power LED will come on, then the 5G LED will flash five
times, about once a second.  When the 5G LED stops flashing and the
2G LED lights solid, the router's U-Boot will provide an upload page
at http://192.168.1.1/ Either a browser may be used to upload an image,
or a utility such as curl may be used:

curl -X POST -F gl_firmware=\@*-nand-squashfs-factory.img \
 http://192.168.1.1/index.html
or
curl -X POST -F gl_firmware=\@*-nor-squashfs-sysupgrade.bin \
 http://192.168.1.1/index.html

Note that NOR vs. NAND is based on the file name extension.

Serial & I2C Access
===

Serial access is *not* required to flash or enter U-Boot recovery.

Serial is configured for 115200, 8n1. 3.3 V logic levels are compatible.

Warning:  5 V ("TTL") or RS232 levels can cause permananent damage.

The board has well-labled (unpopulated) headers for serial and I2C
along the front edge of the board (the edge with the LEDs). Looking
from the top, rear of the unit (behind Ethernet jacks)

 ---
  5G_LED2G_LED  PWR_LED

O O O O O O O

3 S S G T R G
V C D N X X N
        3 L A D D

Signed-off-by: Jeff Kletsky 
---
 package/boot/uboot-envtools/files/ath79   |   1 +
 .../ath79/base-files/etc/board.d/01_leds  |   4 +
 .../ath79/base-files/etc/board.d/02_network   |   2 +-
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   2 +-
 .../ath79/base-files/lib/upgrade/platform.sh  |  23 +++-
 .../dts/qca9563_glinet_gl-ar750s-nand.dts |  10 ++
 .../dts/qca9563_glinet_gl-ar750s-nor.dts  |  15 +++
 ...750s.dts => qca9563_glinet_gl-ar750s.dtsi} | 109 +-
 target/linux/ath79/image/generic.mk   |   6 +-
 target/linux/ath79/image/nand.mk  |  15 +++
 10 files changed, 152 insertions(+), 35 deletions(-)
 create mode 100644 target/linux/ath79/dts/qca9563_glinet_gl-ar750s-nand.dts
 create mode 100644 target/linux/ath79/dts/qca9563_glinet_gl-ar750s-nor.dts
 rename target/linux/ath79/dts/{qca9563_glinet_gl-ar750s.dts => 
qca9563_glinet_gl-ar750s.dtsi} (64%)

diff --git a/package/boot/uboot-envtools/files/ath79 
b/package/boot/uboot-envtools/files/ath79
index 2144f61070..faa5c501f3 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -19,6 +19,7 @@ buffalo,wzr-hp-ag300h)
 buffalo,bhr-4grv2|\
 glinet,gl-ar300m-nand|\
 glinet,gl-ar300m-nor|\
+glinet,gl-ar750s-*|\
 librerouter,librerouter-v1|\
 netgear,ex6400|\
 netgear,ex7300|\
diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds 
b/target/linux/ath79/base-files/etc/board.d/01_leds
index 9c353baabe..c974c12d14 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -78,6 +78,10 @@ glinet,gl-ar300m-nor)
 glinet,gl-ar300m-lite)
ucidef_set_led_netdev "lan" "LAN" "gl-ar300m-lite:green:lan" "eth0"
;;
+glinet,gl-ar750s-*)
+   ucidef_set_led_netdev "wlan2g" "WLAN 2G" "gl-ar750s

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

[Jeff Kletsky]

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.
==



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.

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.



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] 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] ath79: Extend GL.iNet AR750S support to NAND file system

[Jeff Kletsky]

On 5/15/19 2:00 AM, Petr Štetiar wrote:


Jeff Kletsky  [2019-05-14 15:39:56]:


[...]

A question and an answer as I wrap up the punch-down list on this


+comma_to_underscore() {
+   echo "${1%%,*}_${1#*,}"
+}
+
[...]

I think, that it would be better to add support for DT compatible based
board_name format directly into nand_do_platform_check, so it could be reused
by other platforms as well.


I originally had applied this in `nand_do_platform_check()`,
but when I checked for potential adverse impact on other boards
I found that there was an unfortunate exception with the
pistachio marduck board, which passes `img,pistachio-marduk`
to nand_do_platform_check(), preventing a "blind" change
in that function[1]. "img" is apparently from "imgtec.com".

While `target/linux/pistachio/image/Makefile` uses

IMAGE/sysupgrade.tar := sysupgrade-tar

it also defines a custom board name

define Device/marduk
  BOARD_NAME := img,pistachio-marduk
  DEVICE_DTS := img/pistachio_marduk

apparently resulting in the comma being in the tar directory

sysupgrade-img,pistachio-marduk/
sysupgrade-img,pistachio-marduk/root
sysupgrade-img,pistachio-marduk/CONTROL
sysupgrade-img,pistachio-marduk/kernel

While this likely could be fixed by unifying the board name
and tar directory name with current convention, I'm hesitant
to change a device build that I can't test, especially around
flashing and upgrade.


As a side note, the pistachio platform is a "snowflake"
in other ways, including what looks like a custom SPI-NAND
framework originally on Linux 4.9. `git log -1 52c17bff3c`


The remainder of the boards that I found that call `nand_do_platform_check()`
do so with a comma-free board_name or with an explicit, comma-free string.
Surprisingly few make this check; ath79, imx6, ar71xx, layerscape



For clarity, orthogonality, and maintainability, I was considering
handling this with two, distinct commits:

(1) Add the "automatic" first-comma-to-underscore transformation to
package/base-files/files/lib/upgrade/nand.sh:nand_do_platform_check()

(2) Add a specific exception to (1) for `img,pistachio-marduk`


Is this a reasonable approach?





[...]


diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index e69de29bb2..7db5f51c98 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -0,0 +1,15 @@
+define Device/glinet_gl-ar750s-nand
+  ATH_SOC := qca9563
+  DEVICE_TITLE := GL.iNet GL-AR750S
+  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca9887-ct 
kmod-i2c-gpio
+  KERNEL_SIZE := 2048k
+  BLOCKSIZE := 128k
+  PAGESIZE := 2048
+  VID_HDR_OFFSET := 2048
+  IMAGES += factory.img
+  IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
+  IMAGE/factory.img := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
+  SUPPORTED_DEVICES += gl-ar750s

I'm really not sure about this. Do we've enough checks in place, that we won't
allow sysupgrade from NOR?



The ath79 builds, prior to this proposed patch set, use `glinet,gl-ar750s`,
so are not impacted. After this patch set there will be a `-nor` and `-nand`
suffix to clearly differentiate between the two variants.

The `gl-ar750s` board name comes from ar71xx builds for this board,
either from OpenWrt or GL.iNet (based on 18.06.1) source[2].

GL.iNet only provides the NAND-based variant through their download site[3],
from what I can tell. GL.iNet and their U-Boot differentiate NOR-based
with a .bin extension, NAND-based with a .img or .tar extension.

From target/linux/ar71xx/base-files/lib/upgrade/platform.sh

331 [ "$magic" != "2705" ] && {
332 echo "Invalid image type."
333 return 1
334 }
335
336 return 0
337 ;;

"2705" is keying off U-Boot's

#define IH_MAGIC0x27051956  /* Image Magic Number   */

GL.iNet provides similar checks for their boards in their source
including detection if `gl_board_is_nand()` [4].

I have confirmed that this works as expected on OpenWrt snapshots
as well as from a NOR-based build from the GL.iNet sources.



Surprisingly, there is no first-order image check for the ath79 platform.
This would be a project unto itself, based on looking at the ar71xx code.




Jeff


---

[1] http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017045.html

[2] https://github.com/gl-inet/openwrt
 
[3] https://dl.gl-inet.com/firmware/ar750s/


[4] 
https://github.com/gl-inet/openwrt/blob/develop/target/linux/ar71xx/base-files/lib/upgrade/platform.sh#L215





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] upgrade: nand: fix board_name assumtions

[Jeff Kletsky]

cc-ing primary Imgtec / pistachio / Creator Ci40 contributors identified

On 5/20/19 3:14 AM, Bjørn Mork wrote:


nand_do_platform_check assumes that the current board name is
used as-is in the tar file sysupgrade directory.  This fails
for any image supporting multiple device names, and it also
fails if the board_name contains a comma.

Signed-off-by: Bjørn Mork 
---
This is a local workaround I'va had lying around for a while.  Please
consider if it makes any sense at all, or if there are better ways
to solve the problem.

I don't have an actual upstreamed usecase, as this is an issue I've
met while trying to prepare for a never-finished ZyXEL WAP6805
support...



Bjørn

  package/base-files/files/lib/upgrade/nand.sh | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index 99916a4e96fc..14856357989e 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -320,7 +320,9 @@ nand_do_upgrade() {
  nand_do_platform_check() {
local board_name="$1"
local tar_file="$2"
-   local control_length=`(tar xf $tar_file sysupgrade-$board_name/CONTROL -O 
| wc -c) 2> /dev/null`
+   local board_dir=$(tar tf $tar_file | grep -m 1 '^sysupgrade-.*/$')
+   board_dir=${board_dir%/}
+   local control_length=`(tar xf $tar_file ${board_dir}/CONTROL -O | wc -c) 
2> /dev/null`
local file_type="$(identify $2)"
  
  	[ "$control_length" = 0 -a "$file_type" != "ubi" -a "$file_type" != "ubifs" ] && {



Your timing as good as I've been wrestling with this as well
in context of providing ath79 support for SPI-NAND[1].

At least for me, the use case is the equivalent of

nand_do_platform_check $(board_name) ${upgrade_file_name}

without jumping through hoops of translating the output of $(board_name)
to the expected tar-dir name for each and every instance of the call.


I don't know that there is a "better" solution, but what I have found:

* nand_do_platform_upgrade() is called by relatively few targets
  * ath79 (see [1])
  * pistachio
  * imx6
  * ar71xx

* I can see a desire to check for a *specific* tar-dir name,
  rather than just "any" tar-dir name (wrestled with this for a while)

* Only one board seems to prevent a first-comma-to-underscore approach,
  the `img,pistachio-marduk` uses `sysupgrade-img,pistachio-marduk`

  otherwise, I've got this on a development branch

+   local tar_dir_name="sysupgrade-$(echo "$board_name" | sed -e s/,/_/)"
+   local control_length=`(tar xf $tar_file ${tar_dir_name}/CONTROL -O | wc 
-c) 2> /dev/null`


It looks like the pistachio board could have its Makefile modified
to bring it's tar-dir name into the "standard" underscore form,
however I don't have one of these boards to test with,
nor do I know if the file-name change would impact users.

One set of changes I explored last night comes down to

-  IMAGE/sysupgrade.tar := sysupgrade-tar
+  IMAGE/sysupgrade.tar := sysupgrade-tar | append-metadata
 endef
 
-define Device/marduk

-  BOARD_NAME := img,pistachio-marduk
+define Device/img_pistachio-marduk
   DEVICE_DTS := img/pistachio_marduk
   BLOCKSIZE := 256KiB
   PAGESIZE := 4KiB
   DEVICE_TITLE := Creator Ci40
   DEVICE_PACKAGES := kmod-tpm-i2c-infineon
 endef
-
-TARGET_DEVICES += marduk
+TARGET_DEVICES += img_pistachio-marduk


commit b1c010 (HEAD -> jmk-pistachio)
Author: Jeff Kletsky 
Date:   Sun May 19 20:28:12 2019 -0700

pistachio: Update image/Makefile for tar root and metadata

Prior to this patch, the img,pistachio-marduk was the only board that

used the comma-delimited board name for the sysupgrade-tar directory
rather than the underscore-delimited, DTS-compatible form.

To allow for easier use of $(board_name) in upgrade scripting, this

patch brings the sysupgrade-tar directory into the more canonical
form. It also adds append-metadata to the sysupgrade-tar image.

The board name at run time should be the same as before.

However, the build results have a different name, changing from

openwrt-pistachio-marduk-squashfs-sysupgrade.tar

to
openwrt-pistachio-img_pistachio-marduk-squashfs-sysupgrade.tar




[1] http://patchwork.ozlabs.org/project/openwrt/list/?series=107880

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] upgrade: nand: fix board_name assumtions

[Jeff Kletsky]

(imgtec.com addresses removed as mail to them bounces)

On 5/20/19 6:42 AM, Jeff Kletsky wrote:


On 5/20/19 3:14 AM, Bjørn Mork wrote:

nand_do_platform_check assumes that the current board name is
used as-is in the tar file sysupgrade directory.  This fails
for any image supporting multiple device names, and it also
fails if the board_name contains a comma.

Signed-off-by: Bjørn Mork
---
This is a local workaround I'va had lying around for a while.  Please
consider if it makes any sense at all, or if there are better ways
to solve the problem.

I don't have an actual upstreamed usecase, as this is an issue I've
met while trying to prepare for a never-finished ZyXEL WAP6805
support...



Bjørn

  package/base-files/files/lib/upgrade/nand.sh | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index 99916a4e96fc..14856357989e 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -320,7 +320,9 @@ nand_do_upgrade() {
  nand_do_platform_check() {
local board_name="$1"
local tar_file="$2"
-   local control_length=`(tar xf $tar_file sysupgrade-$board_name/CONTROL -O 
| wc -c) 2> /dev/null`
+   local board_dir=$(tar tf $tar_file | grep -m 1 '^sysupgrade-.*/$')
+   board_dir=${board_dir%/}
+   local control_length=`(tar xf $tar_file ${board_dir}/CONTROL -O | wc -c) 
2> /dev/null`
local file_type="$(identify $2)"
  
  	[ "$control_length" = 0 -a "$file_type" != "ubi" -a "$file_type" != "ubifs" ] && {

Your timing as good as I've been wrestling with this as well
in context of providing ath79 support for SPI-NAND[1].

At least for me, the use case is the equivalent of

 nand_do_platform_check $(board_name) ${upgrade_file_name}

without jumping through hoops of translating the output of $(board_name)
to the expected tar-dir name for each and every instance of the call.


[...]

* I can see a desire to check for a *specific* tar-dir name,
   rather than just "any" tar-dir name (wrestled with this for a while)

* Only one board seems to prevent a first-comma-to-underscore approach,
   the `img,pistachio-marduk` uses `sysupgrade-img,pistachio-marduk`

  [...]


Having spent quite a bit of time today thinking about the impact of
board-name changes, I can see use cases where the running system
doesn't know a priori what the range of acceptable tar-dir values are.

Take the case where `mfgr,board-name` gets a new, compatible variant,
`mfgr,board-name-special-purpose`. If you're running `mfgr,board-name`,
a strict check for `mfgr_board-name` would fail, even though the
sysupgrade-tar was applicable. This kind of board-compatibility check
should arguably be done with image metadata, either or both appended
or in the CONTROL section.

As such, I would welcome this change, as proposed by Bjørn.

I would suggest an update to the comment to reflect the change as
`has to include "sysupgrade-BOARD" directory` is no longer correct.




Jeff
   

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Remove NAND targets as no available drivers

[Jeff Kletsky]

Updating this patch as likely still valuable for v19

WIP on master edited for Linux 4.19 and ath79 spi-nand suggests that
support will be possible after ath79 master moves to Linux 4.19

Jeff



From 7bd39bc01d8b0a03e796268f06f99b5a65fc353a Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Mon, 28 Jan 2019 08:25:52 -0800
Subject: [PATCH] ath79: Remove NAND targets as no available drivers

At this time, there are no drivers for NAND flash for ath79.

Remove the only present ath79 NAND target, GL.iNet AR300M,
as it will not boot due to lack of a suitable NAND driver.

From openwrt-devel on 2019-01-25

  The upstream SPI NAND framework is available in 4.19.

  As for raw nand driver for AR9344/QCA9558, the ar934x-nfc driver
  isn't ported to ath79 yet.

From https://github.com/openwrt/openwrt/pull/1428 on 2018-11-26

  (In reference to patches trying to support the GL.iNet AR300M NAND
   without using the spi-nand as it not present in Kernel 4.14)

  Please re-spin the patch as soon as we have kernel 4.19 support. The
  approach was already NAK'ed upstream and I don't see much gain in
  adding the hack if the next major kernel in OpenWrt will provide a
  suitable solution.
---
 target/linux/ath79/image/nand.mk | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index eee419194b..91873ef007 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -1,13 +1,2 @@
-define Device/glinet_gl-ar300m-nand
-  ATH_SOC := qca9531
-  DEVICE_TITLE := GL-AR300M (NAND)
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage 
kmod-usb-ledtrig-usbport
-  KERNEL_SIZE := 2048k
-  BLOCKSIZE := 128k
-  PAGESIZE := 2048
-  VID_HDR_OFFSET := 512
-  IMAGES += factory.ubi
-  IMAGE/sysupgrade.bin := sysupgrade-tar
-  IMAGE/factory.ubi := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
-endef
-TARGET_DEVICES += glinet_gl-ar300m-nand
+# No NAND drivers available for the ath79 target at this time
+# (January, 2019)
--
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

[Jeff Kletsky]

This is a resubmission of the garbled
https://patchwork.ozlabs.org/patch/1088433/

Jeff Kletsky



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

[Jeff Kletsky]

From: Jeff Kletsky 

The GL.iNet AR750S is based around the QCA9563
and requires the QCA9887 firmware for operation.

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/image/generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 8588e7cdf6..8e162e1d0e 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -363,7 +363,7 @@ TARGET_DEVICES += glinet_gl-ar300m-nor
 define Device/glinet_gl-ar750s
   ATH_SOC := qca9563
   DEVICE_TITLE := GL.iNet GL-AR750S
-  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct
+  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca9887-ct
   IMAGE_SIZE := 16000k
   SUPPORTED_DEVICES += gl-ar750s
 endef
-- 
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

[Jeff Kletsky]

On 5/3/19 11:19 AM, Petr Štetiar wrote:


Jeff Kletsky  [2019-04-20 18:33:10]:


This patch corrects the firmware selection for the ath79 AR750S

The ar71xx AR750S already uses the QCA9887 firmware.

$ fgrep -A 3 Device/gl-ar750s target/linux/ar71xx/image/generic.mk
define Device/gl-ar750s
   DEVICE_TITLE := GL.iNet GL-AR750S
   DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9887-ct kmod-usb-core \
kmod-usb2 kmod-usb-storage


Jeff



 From cb6e411f8d172a8dde5ca7e075cef67994ac0062 Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Sun, 27 Jan 2019 20:17:16 -0800
Subject: [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

The GL.iNet AR750S is based around the QCA9563
and uses the QCA9887 firmware for operation.

Signed-off-by: Jeff Kletsky 
---
  target/linux/ath79/image/generic.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 8588e7cdf6..8e162e1d0e 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -363,7 +363,7 @@ TARGET_DEVICES += glinet_gl-ar300m-nor
  define Device/glinet_gl-ar750s
ATH_SOC := qca9563
DEVICE_TITLE := GL.iNet GL-AR750S
-  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct
+  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca9887-ct
IMAGE_SIZE := 16000k
SUPPORTED_DEVICES += gl-ar750s
  endef
--
2.11.0

something probably went wrong with this patch:

  ../maintainer-tools/patchwork-apply.sh 1088433
  Saved patch to OpenWrt-Devel-ath79-glinet_gl-ar750s-Use-QCA9887-firmware
  Patch is empty.  Was it split wrong?
  If you would prefer to skip this patch, instead run "git am --skip".
  To restore the original branch and stop patching run "git am --abort".
  Failed to apply patch 1088433

-- ynezz


That's strange -- perhaps another patch updated it?

jeff@deb-devel:~/devel/openwrt$ git pull
Already up-to-date.

jeff@deb-devel:~/devel/openwrt$ git log -1 --pretty=oneline
2c3dd70741 (HEAD -> master, openwrt/master, openwrt/HEAD) procd: add 
procd_running() helper for checking running state

jeff@deb-devel:~/devel/openwrt$ fgrep -iA6 ar750s 
target/linux/ath79/image/generic.mk
define Device/glinet_gl-ar750s
  ATH_SOC := qca9563
  DEVICE_TITLE := GL.iNet GL-AR750S
  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct
  IMAGE_SIZE := 16000k
  SUPPORTED_DEVICES += gl-ar750s
endef
TARGET_DEVICES += glinet_gl-ar750s

jeff@deb-devel:~/devel/openwrt$ git remote -v show openwrt
* remote openwrt
  Fetch URL: https://git.openwrt.org/openwrt/openwrt.git


Jeff

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

[Jeff Kletsky]

On 5/3/19 12:20 PM, Petr Štetiar wrote:


Jeff Kletsky  [2019-05-03 12:11:48]:


That's strange -- perhaps another patch updated it?

no, if you look at the patchwork, the patch was simply sent out broken.

-- ynezz


My apologies, resend due to broken patch

(Only applies to and impacts `master` as on ath79 target)

From c553a3becef8c774c7f725cf84035773b868b809 Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Sun, 27 Jan 2019 20:17:16 -0800
Subject: [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

The GL.iNet AR750S is based around the QCA9563
and requires the QCA9887 firmware for operation.

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/image/generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 8588e7cdf6..8e162e1d0e 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -363,7 +363,7 @@ TARGET_DEVICES += glinet_gl-ar300m-nor
 define Device/glinet_gl-ar750s
   ATH_SOC := qca9563
   DEVICE_TITLE := GL.iNet GL-AR750S
-  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct
+  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca9887-ct
   IMAGE_SIZE := 16000k
   SUPPORTED_DEVICES += gl-ar750s
 endef
--
2.11.0



.
 



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SDK enhancement proposal - add external toolchains via feeds

[Jeff Kletsky]

On 4/23/19 12:41 AM, Florian Eckert wrote:

Hello Mirko,

I am not a member of OpenWrt but this are my hints.


 To start this process, we have collected a small number of core
features that we would propose to add to the OpenWrt build system. Our
goal with these patches is to remove the need for companies to develop
external scripts used to manipulate the build configuration of
OpenWrt. We will present the use cases and our proposed way to
implement these in a series of emails.

 If and when there is agreement on the proposal and implementation
approach, we will develop the feature and submit a patch for approval.
We are aware that this might take time and are prepared for several
iterations.


Do not ask if this would be a good improvement.
Just do it and make a traceable pullrequest with the changes.
If the community likes this then it will get merged.



 The first use case we would like to present is the ability to add
external toolchains in a feed.


Why not include the toolchain for new archs or changes to existing 
into OpenWrt Upstream?

This has a lot of advantages, which hopefully are all well known.

[...]



Mirko,

First, I would echo Florian's suggestion as perhaps the most effective 
way to accomplish this.


(I'm not a member of the OpenWrt team either.)

I am, however, wondering how the existing features of the build system 
aren't meeting your needs. While I haven't tried them myself, it at 
least appears that there are many options available beneath


Symbol: EXTERNAL_TOOLCHAIN [=y]
  │ Type  : boolean
  │ Prompt: Use external toolchain
  │   Location:
  │ -> Advanced configuration options (for developers) (DEVEL [=y])
  │   Defined at toolchain/Config.in:41


On the feeds, at least as I understand it, `./scripts/feeds` looks at 
`feeds.conf` or, if not present, `feeds.conf.default` (Perl)


 44 sub parse_config() {
 45 my $line = 0;
 46 my %name;
 47
 48 open FEEDS, "feeds.conf" or
 49 open FEEDS, "feeds.conf.default" or
 50 die "Unable to open feeds configuration";

so that the choice of feeds is already part of the source itself, 
manageable through git or your VCS.



On a separate note, I wanted to thank the folks at Prpl for providing 
some documentation on procd that was once present at 
 I had linked to it 
at  some 
time ago, and replaced it with a link to the Internet Archive when the 
page disappeared. If that is present elsewhere, I know I'd appreciate it 
if we could know the URL to link to it directly, or maintain the 
information to the OpenWrt wiki directly.



Jeff




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] DTS Style: Referring to "Upstream" Nodes

[Jeff Kletsky]

In general, within an OpenWrt DTS that `#include "some_linux_supplied.dtsi"`
is it preferred to refer to a node defined in upstream code by label, or 
by path?


For example, with `blsp1_spi2: spi@78b6000` in the upstream-controlled 
DTS, prefer


    _spi2

or (taking into account scope or path, as needed)

    spi@78b6000


Thanks,


Jeff









___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

[Jeff Kletsky]

This patch corrects the firmware selection for the ath79 AR750S

The ar71xx AR750S already uses the QCA9887 firmware.

$ fgrep -A 3 Device/gl-ar750s target/linux/ar71xx/image/generic.mk
define Device/gl-ar750s
  DEVICE_TITLE := GL.iNet GL-AR750S
  DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9887-ct kmod-usb-core \
kmod-usb2 kmod-usb-storage


Jeff



From cb6e411f8d172a8dde5ca7e075cef67994ac0062 Mon Sep 17 00:00:00 2001
From: Jeff Kletsky 
Date: Sun, 27 Jan 2019 20:17:16 -0800
Subject: [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

The GL.iNet AR750S is based around the QCA9563
and uses the QCA9887 firmware for operation.

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/image/generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 8588e7cdf6..8e162e1d0e 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -363,7 +363,7 @@ TARGET_DEVICES += glinet_gl-ar300m-nor
 define Device/glinet_gl-ar750s
   ATH_SOC := qca9563
   DEVICE_TITLE := GL.iNet GL-AR750S
-  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct
+  DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca9887-ct
   IMAGE_SIZE := 16000k
   SUPPORTED_DEVICES += gl-ar750s
 endef
--
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] build: sysupgrade: kernel: mtd: Image too SMALL to Restore Config

[Jeff Kletsky]

I've run across some seemingly "wrong" behavior related to sysupgrade
where if the image is "too small" the contents of /sysupgrade.tgz are
not properly recovered on reboot.

It seems as if the various pieces are functioning as expected, but
that they do not work in concert under certain situations. It seems as
though /sysupgrade.tgz is written where

  mtd write -j /tmp/sysupgrade.tgz -

intends, but when the kernel splits the partition into rootfs and
rootfs_data, the split is 0x1 "early", likely resulting in the
JFFS2 believing that rootfs_data is "empty".

Prior to trying to "fix" this, I'd like to confirm the expected
behavior. `default_do_upgrade()` is writing the upgrade.


---


The smaller, "failing" image contains

003eb6f0  3e 30 0d 8b 02 00 00 00  00 01 59 5a de b2 20 00 
|>0YZ.. .|
003eb700  00 00 00 00 04 80 00 00  00 00 04 b7 20 00 00 00 | 
...|
003eb710  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
003eb720  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  de ad c0 de 00 00 00 00  00 00 00 00 7b 20 20 22 
|{  "|
00400010  6d 65 74 61 64 61 74 61  5f 76 65 72 73 69 6f 6e 
|metadata_version|



and results in the MTD firmware partition containing

003eb6f0  3e 30 0d 8b 02 00 00 00  00 01 59 5a de b2 20 00 
|>0YZ.. .|
003eb700  00 00 00 00 04 80 00 00  00 00 04 b7 20 00 00 00 | 
...|
003eb710  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
003eb720  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  19 85 20 03 00 00 00 0c  f0 60 dc 98 19 85 e0 01  |.. 
..`..|
00400010  00 00 00 36 5d 44 48 fe  00 00 00 01 00 00 00 00 
|...6]DH.|
00400020  00 00 00 02 00 00 00 00  0e 08 00 00 97 8f 0a 5b 
|...[|
00400030  31 ff 3d bc 73 79 73 75  70 67 72 61 64 65 2e 74 
|1.=.sysupgrade.t|
00400040  67 7a ff ff 19 85 e0 02  00 00 10 44 ee 2d 30 6f 
|gz.D.-0o|




The larger, "succeeding" image contains

003effe0  3e 30 0d 8b 02 00 00 00  00 01 59 5a ce fb 20 00 
|>0YZ.. .|
003efff0  00 00 00 00 04 80 00 00  00 00 f4 ff 20 00 00 00 | 
...|
003f  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
003f0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  de ad c0 de 00 00 00 00  00 00 00 00 7b 20 20 22 
|{  "|
00400010  6d 65 74 61 64 61 74 61  5f 76 65 72 73 69 6f 6e 
|metadata_version|



and results in the MTD firmware partition containing

003effe0  3e 30 0d 8b 02 00 00 00  00 01 59 5a ce fb 20 00 
|>0YZ.. .|
003efff0  00 00 00 00 04 80 00 00  00 00 f4 ff 20 00 00 00 | 
...|
003f  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
003f0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  19 85 20 03 00 00 00 0c  f0 60 dc 98 19 85 e0 01  |.. 
..`..|
00400010  00 00 00 36 5d 44 48 fe  00 00 00 01 00 00 00 00 
|...6]DH.|
00400020  00 00 00 02 00 00 00 00  0e 08 00 00 97 8f 0a 5b 
|...[|
00400030  31 ff 3d bc 73 79 73 75  70 67 72 61 64 65 2e 74 
|1.=.sysupgrade.t|
00400040  67 7a ff ff 19 85 e0 02  00 00 10 44 ee 2d 30 6f 
|gz.D.-0o|



Note that the difference between the two is the length of the squashfs
crossing an erase-block boundary.

It appears from the build logs that `padjffs2` is being called in the
default image-generation process.  I have not yet located where in the
make files the default rule(s) are defined.

The on-flash data appears to be consistent with the code in
package/system/mtd/src/mtd.c which looks for JFFS2_EOF
#define JFFS2_EOF "\xde\xad\xc0\xde"

---

When the system boots, in the "failing" case, the MTD split is
"early", at at 0x3f, compared to the location of the
JFFS2_NODETYPE_CLEANMARKER `19 85 20 03` at 0x40

[    0.435672] 0x0005-0x00ff : "firmware"
[    0.444132] 2 uimage-fw partitions found on MTD device firmware
[    0.450255] Creating 2 MTD partitions on "firmware":
[    0.455441] 0x-0x001e : "kernel"
[    0.461418] 0x001e-0x00fa : "rootfs"
[    0.467345] mtd: device 4 (rootfs) set to be root filesystem
[    0.474785] mtdsplit: squashfs length: 0x20b712
[    0.479477] mtdsplit_squashfs: part_offset:  0x001e
[    0.484828] mtdsplit_squashfs: squashfs_len: 0x0020b712
[    0.490222] mtdsplit_squashfs: sum:  0x003eb712
[    0.494923] mtdsplit_squashfs: part->offset: 0x0021
[    0.505635] 1 squashfs-split partitions found on MTD device rootfs
[    0.512029] 0x003f-0x00fa : "rootfs_data"
[    0.518440] 0x00ff-0x0100 : "art"


In the "succeeding" case, the split is at the CLEANMARKER

[    0.435680] 0x0005-0x00ff : "firmware"
[    0.444143] 2 uimage-fw partitions found on MTD device firmware
[    0.450264] Creating 2 MTD partitions on "firmware":
[    0.455449] 

Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

[Jeff Kletsky]

On 8/2/19 7:46 AM, Adrian Schmutzler wrote:

This converts all remaining devices to use interrupt-driven
gpio-keys compatible instead of gpio-keys-polled.
The poll-interval is removed.



Not that this proposed change makes the situation any different, but 
many devices have switches that are poorly handled by the "key-press" 
approach.


One specific case that has bothered me (but not enough to dig into it) 
is the Archer C7v2 that has an "rfkill" switch. Not only is it 
"backwards" (label "Off" is really "wireless on"), but it only responds 
to changes in state, so its state at boot is not respected. You can't, 
as I recall, set it for "wireless off", plug in the device, and have the 
wireless be off when OpenWrt boots.


The GL-AR300M series and the GL-AR750S also have a multi-position "mode" 
switch.


Right now, all these switches have to be toggled twice to have their 
position be properly respected by the OS if they're not in the 
"expected" position.


It would seem that, at some point, switches like these would be better 
served by a driver that can both detect position, as well as transition. 
This would likely also require a way to poll the position at 
"impacted-service start" and ubus support along with changes in existing 
hotplug scripts.



Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Compilation error switch to pyhon 3

[Jeff Kletsky]

On 7/27/19 3:53 PM, Petr Štetiar wrote:

Ansuel Smith  [2019-07-27 19:46:35]:

Hi,


I can't currently compile my image and i have this error

make[3]: Leaving directory '/home/ansuel/openwrt/tools/libtool'
time: tools/libtool/compile#0.05#0.00#0.10
Traceback (most recent call last):
   File "/home/ansuel/openwrt/build_dir/host/scons-3.0.5/setup.py",
line 26, in 
 import distutils.command.build_scripts
ModuleNotFoundError: No module named 'distutils.command'

yep, I've seen that already[1], out of curiosity, what distro is that? I
think, that scons has no place in the master tree as no package in the master
tree depends on it, so I've started move process into packages feed[2].

1. 
https://github.com/openwrt/openwrt/commit/316c8b5503e54cdb3ee5bd3b5d81a3b7dd139294#commitcomment-34460875
2. https://github.com/openwrt/packages/pull/9584

-- ynezz


Fresh install of Debian 10 ("Buster") on AMD64 after my usual

apt install build-essential git gitk libncurses5-dev gawk unzip wget 
curl ccache rsync zlib1g-dev



Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] "mac80211: Update to version 5.2-rc7" breaks batman-adv

[Jeff Kletsky]

git bisect suggests

commit 0b2c42ced2 (HEAD, refs/bisect/bad)

    mac80211: Update to version 5.2-rc7

as the problem behind the failure to compile batman-adv on July 21, 2019 
and perhaps prior


See, for example 
http://downloads.openwrt.org/snapshots/faillogs/mips_24kc/routing/batman-adv/compile.txt


/builder/shared-workdir/build/sdk/build_dir/target-mips_24kc_musl/linux-ath79_generic/batman-adv-2019.2/net/batman-adv/netlink.c:1347:4:
 error: 'const struct backport_genl_ops' has no member named 'policy'
   .policy = batadv_netlink_policy,
^~


Same problem observed locally on ath79 and on ipq40xx

Nothing obvious in the patch itself, but building at d616b2c906 resolves 
the issue for both ipq40xx and ath79 builds



Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mvebu: Replace backticks by $(...)

[Jeff Kletsky]

On 7/24/19 11:05 AM, Rosen Penev wrote:

On Wed, Jul 24, 2019 at 10:48 AM Adrian Schmutzler
 wrote:

Hi,


-Original Message-
From: Rosen Penev [mailto:ros...@gmail.com]
Sent: Mittwoch, 24. Juli 2019 18:54
To: Adrian Schmutzler 
Cc: OpenWrt Development List 
Subject: Re: [OpenWrt-Devel] [PATCH] mvebu: Replace backticks by $(...)

On Wed, Jul 24, 2019 at 6:34 AM Adrian Schmutzler
 wrote:

Signed-off-by: Adrian Schmutzler 
---
  target/linux/mvebu/base-files/lib/upgrade/linksys.sh | 2 +-
  target/linux/mvebu/base-files/sbin/fan_ctrl.sh   | 6 +++---
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/linux/mvebu/base-files/lib/upgrade/linksys.sh

b/target/linux/mvebu/base-files/lib/upgrade/linksys.sh

index 3f45d6cac5..ddf24836bc 100644
--- a/target/linux/mvebu/base-files/lib/upgrade/linksys.sh
+++ b/target/linux/mvebu/base-files/lib/upgrade/linksys.sh
@@ -6,7 +6,7 @@ linksys_get_target_firmware() {

 local cur_boot_part mtd_ubi0

-   cur_boot_part=`/usr/sbin/fw_printenv -n boot_part`
+   cur_boot_part=$(/usr/sbin/fw_printenv -n boot_part)
 if [ -z "${cur_boot_part}" ] ; then
 mtd_ubi0=$(cat /sys/devices/virtual/ubi/ubi0/mtd_num)
 case $(egrep ^mtd${mtd_ubi0}: /proc/mtd | cut -d '"' -f 2) in

egrep is deprecated as well. I'm assuming you're running these through
shellcheck.

I indeed got this hint from shellcheck, suggesting "grep -E" as replacement.
However, I'm not familiar with the old egrep.
So, I was not sure whether I really can replace it without side-effects, and 
since I cannot test on this target, I decided against changing that.

If you tell me it's okay, I can include it in a v2.

egrep is equivalent to grep -E. I have never seen any fallout from
changing this.


[...]

The one place that I know it is critical to use `grep -E` over `egrep` 
is during stage2 of sysupgrade, when `grep` is typically available and 
`egrep` is often not.


switch_to_ramfs() {
    for binary in \
    /bin/busybox /bin/ash /bin/sh /bin/mount /bin/umount    \
    pivot_root mount_root reboot sync kill sleep    \
    md5sum hexdump cat zcat bzcat dd tar    \
    ls basename find cp mv rm mkdir rmdir mknod touch chmod \
    '[' printf wc grep awk sed cut  \
    mtd partx losetup mkfs.ext4 \
    ubiupdatevol ubiattach ubiblock ubiformat   \
    ubidetach ubirsvol ubirmvol ubimkvol    \
    snapshot snapshot_tool  \
    $RAMFS_COPY_BIN
[...]


As I've had my hands in `linksys.sh` recently (commit b3770eaca3), I can 
say that the primary reason I didn't change it in that file then was to 
keep the large number of changes somewhat more understandable.



Jeff





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] "mac80211: Update to version 5.2-rc7" breaks batman-adv

[Jeff Kletsky]

On 7/21/19 4:16 PM, Jeff Kletsky wrote:


git bisect suggests

commit 0b2c42ced2 (HEAD, refs/bisect/bad)

    mac80211: Update to version 5.2-rc7

as the problem behind the failure to compile batman-adv on July 21, 
2019 and perhaps prior


See, for example 
http://downloads.openwrt.org/snapshots/faillogs/mips_24kc/routing/batman-adv/compile.txt


/builder/shared-workdir/build/sdk/build_dir/target-mips_24kc_musl/linux-ath79_generic/batman-adv-2019.2/net/batman-adv/netlink.c:1347:4:
 error: 'const struct backport_genl_ops' has no member named 'policy'
.policy = batadv_netlink_policy,
 ^~


Same problem observed locally on ath79 and on ipq40xx

Nothing obvious in the patch itself, but building at d616b2c906 
resolves the issue for both ipq40xx and ath79 builds





Looks like the likely (upstream) event that triggered this was

(Linux) commit 3b0f31f2b8c9
Author: Johannes Berg 
Date:   Thu Mar 21 22:51:02 2019 +0100

    genetlink: make policy common to family


which moves .policy off where "current" batman-adv is expecting it.

The backport tar ball does contain backport-include/net/genetlink.h 
which seems to be picked up inappropriately for batman-adv, or there is 
a patch missing for batman-adv (commit 3b0f31f2b8c9 does modify it), or ...


I haven't quite figured out how the backports work, so don't yet know 
the root cause and "best" solution.



Jeff


See also 
https://forum.openwrt.org/t/batman-adv-build-failure-master-2019-07-21/41205


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/1] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

[Jeff Kletsky]

On 9/27/19 6:39 PM, Chuanhong Guo wrote:

Hi!

On Sat, Sep 28, 2019 at 12:33 AM Jeff Kletsky  wrote:

[...]
As suggested by Alberto Bursi in the linked thread, one approach to
resolution would be to disable the "unused" interface, GMAC1. This
would have the additional advantage of removing the unconnected
interface from the kernel and end-user visibility. By disabling GMAC1,
it was expected that GMAC0 would be identified by the kernel as "eth0"
as the sole Ethernet interface visible.

 {
status = "disabled";
};


To disable GMAC1, you should use the following:
 {
compatible = "syscon", "simple-mfd";
}

Thanks, yes, setting it as a MFD results in GMAC0 being able to connect 
to the phy.


Initial version of patch withdrawn. Will submit a v2 later on.

Jeff



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 1/2] ath79: Correct glinet, gl-ar300m-lite in 02_network

[Jeff Kletsky]

From: Jeff Kletsky 

Previously, the board name for the GL-AR300M-Lite was incorrect
in 02_network, resulting in an unintended, fall-through condition
when initializing the network configuration.

While builds prior to commit 8dde11d521 (merged June 5, 2019)
ath79: dts: drop "simple-mfd" for gmacs in SoC dtsi
functioned properly, the error was noted in resolving first-boot
connectivity issues related to the single-phy nature of the device
and the "swap" of eth0 and eth1 related to that commit.

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/base-files/etc/board.d/02_network | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network
index 15371a1dd9..0de17adb9d 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -19,7 +19,7 @@ ath79_setup_interfaces()
devolo,dvl1750i|\
devolo,dvl1750x|\
engenius,ecb1750|\
-   glinet,ar300m-lite|\
+   glinet,gl-ar300m-lite|\
netgear,ex6400|\
netgear,ex7300|\
ocedo,koala|\
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/2] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

[Jeff Kletsky]

From: Jeff Kletsky 

The relationship between GMAC0 and GMAC1 and the kernel devices
eth0 and eth1 was reversed for many ath79 devices by commit 8dde11d521
ath79: dts: drop "simple-mfd" for gmacs in SoC dtsi

The GL-AR300M-Lite is a single-port device, with the "LAN" port of the
GL-AR300M board unpopulated and its sole port now referenced as eth1,
as a result of commit 8dde11d521. The device was unreachable on
first boot or fresh config.

By changing  (GMAC1) to an MFD, GMAC0 is able to associate with
the phy and is known by the kernel as "eth0".

Thanks to Chuanhong Guo for the suggestion of "simple-mfd"

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
index fba08e4295..e29af5411d 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
@@ -7,7 +7,11 @@
model = "GL.iNet GL-AR300M-Lite";
 };
 
-// GL-AR300M-Lite has different LED colors than the non-Lite version
+// "Disable" unpopulated GMAC1
+
+ {
+   compatible = "syscon", "simple-mfd";
+};
 
 _status {
label = "gl-ar300m-lite:red:status";
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/1] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

[Jeff Kletsky]

NB: What is described here may also impact other single-port, ath79 devices

There are over 40 such devices that appear to use "eth0" as their only
Ethernet port in target/linux/ath79/base-files/etc/board.d/02_network


TL;DR

  * Single-port ath79 devices may be unreachable on first boot

  * Attempts at disabling the "unused" GMAC1 as a solution were unsuccessful
* If there is a way to disable GMAC1, it seems a preferred solution

  * This patch, or its replacement, should be applied to `master`
as well as `openwrt-19.07` as both contain the interface reversal



commit 8dde11d521, ath79: dts: drop "simple-mfd" for gmacs in SoC dtsi
reversed the assignment of eth0 and eth1 on many ath79 devices.

In the case of the single-port GL-AR300M-Lite, this resulted in an
inability to connect to the device after a clean flash[1] or after
regeneration of /etc/config/network.

This patch manages the change by modifying 02_network to use the
now-labeled eth1 for the "LAN" interface on configuration of
/etc/config network

As I understand the QCA9531, it has two GMACs:

* GMAC0
  * Base address of 0x1900
  * Can be connected to FE PHY 0 or FE PHY 5 of the 5-port, integral switch
(or, if in SW_ONLY_MODE is set, is not connected)
  * Is referenced as `eth0: eth@1900` in ath79.dtsi

* GMAC1
  * Base address of 0x1a00
  * Is connected "directly" to the integral switch
  * Is referenced as `eth1: eth@1a00` in ath79.dtsi

Prior to commit 8dde11d521, the kernel designation of the interfaces
was consistent with the naming in the DTSI:

  /sys/devices/platform/ahb/1900.eth/net/eth0
  /sys/devices/platform/ahb/1a00.eth/net/eth1

Builds prior to this commit were tested at the time to provide
first-boot connectivity and that has been subsequently confirmed.

After commit 8dde11d521, the kernel names are reversed (as suggested
by the commit message):

  /sys/devices/platform/ahb/1900.eth/net/eth1
  /sys/devices/platform/ahb/1a00.eth/net/eth0

The SoC's GMAC1 is now associated with the kernel's "eth0".

In the case of the GL-AR300M-Lite, testing of "official" snapshots as
well as local `master` builds indicated that the populated port was that
which the kernel now identified with "eth1" -- GMAC0

This is consistent with observations that "old" firmware for the
device connected through "eth0" and "new" firmware, through "eth1".

As suggested by Alberto Bursi in the linked thread, one approach to
resolution would be to disable the "unused" interface, GMAC1. This
would have the additional advantage of removing the unconnected
interface from the kernel and end-user visibility. By disabling GMAC1,
it was expected that GMAC0 would be identified by the kernel as "eth0"
as the sole Ethernet interface visible.

 {
   status = "disabled";
};

This, unfortunately, resulted in the Ethernet driver unable to connect
to the assigned phy 4, with no Ethernet interface created and

kern.info kernel: [0.495579] libphy: Fixed MDIO Bus: probed
kern.err kernel: [0.846986] ag71xx 1900.eth: Could not connect to PHY 
device. Deferring probe.
kern.err kernel: [1.216982] ag71xx 1900.eth: Could not connect to PHY 
device. Deferring probe.
kern.err kernel: [1.556969] ag71xx 1900.eth: Could not connect to PHY 
device. Deferring probe.
kern.err kernel: [4.681196] ag71xx 1900.eth: Could not connect to PHY 
device. Deferring probe.
kern.err kernel: [5.057462] ag71xx 1900.eth: Could not connect to PHY 
device. Deferring probe.

appearing in the logs. Thinking that it was related to switch initialization

 {
   status = "okay";
};

was tested, and found to have the same, unsucessful result.

If there are suggestions as to how to disable the "unused" GMAC, yet
preserve the ability to access the phy, I would evaulate them.

Jeff




[1] https://forum.openwrt.org/t/how-do-i-flash-gl-ar300-lite/44802




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/1] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

[Jeff Kletsky]

From: Jeff Kletsky 

The relationship between GMAC0 and GMAC1 and the kernel devices
eth0 and eth1 was reversed for many ath79 devices by
commit 8dde11d521
ath79: dts: drop "simple-mfd" for gmacs in SoC dtsi

The GL-AR300M-Lite is a single-port device, with the "LAN" port of the
GL-AR300M board unpopulated and its sole port now referenced as eth1,
as a result of commit 8dde11d521. The device was unreachable on
first boot or fresh config.

This patch changes 02_network to utilize eth1 for initial configuration
of the device, so that it may be reached on first boot or fresh config.

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/base-files/etc/board.d/02_network | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network
index 15371a1dd9..12eb11825f 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -19,7 +19,6 @@ ath79_setup_interfaces()
devolo,dvl1750i|\
devolo,dvl1750x|\
engenius,ecb1750|\
-   glinet,ar300m-lite|\
netgear,ex6400|\
netgear,ex7300|\
ocedo,koala|\
@@ -56,6 +55,9 @@ ath79_setup_interfaces()
winchannel,wb2000)
ucidef_set_interface_lan "eth0"
;;
+   glinet,gl-ar300m-lite)
+   ucidef_set_interface_lan "eth1"
+   ;;
avm,fritz4020|\
pcs,cr3000|\
tplink,archer-c58-v1|\
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: Clean up GL-AR300M DTS/DTSI inclusions

[Jeff Kletsky]

From: Jeff Kletsky 

Modify GL-AR300M-Lite and GL-AR300M (NOR):

* Include qca9531_glinet_gl-ar300m.dtsi directly
  rather than qca9531_glinet_gl-ar300m-nor.dts

* Remove redundant inclusion of gpio.h and input.h

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts | 2 +-
 target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts  | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
index e29af5411d..b2cb5bc261 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-#include "qca9531_glinet_gl-ar300m-nor.dts"
+#include "qca9531_glinet_gl-ar300m.dtsi"
 
 / {
compatible = "glinet,gl-ar300m-lite", "qca,qca9531";
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts
index 02196cf9c4..22e5ae4e74 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m-nor.dts
@@ -1,8 +1,5 @@
 /dts-v1/;
 
-#include 
-#include 
-
 #include "qca9531_glinet_gl-ar300m.dtsi"
 
 / {
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/1] ipq40xx: Linksys: sysupgrade: Ensure OEM volumes are removed

[Jeff Kletsky]

On 6/16/19 4:49 AM, Christian Lamparter wrote:


On Saturday, June 15, 2019 11:40:56 PM CEST Jeff Kletsky wrote:

From: Jeff Kletsky 

When OEM volumes are present in the [alt_]firmware partition,
sysupgrade will write a new kernel, but will fail to write
the root file system. The next boot will hang indefinitely

 Waiting for root device /dev/ubiblock0_0...

Modified ipq40xx/base-files/lib/upgrade/linksys.sh
to remove both `squashfs` and `ubifs` if found
on the target firmware partition's UBI device.

Run-tested-on: Linksys EA8300

Signed-off-by: Jeff Kletsky 

Can you check if this is still working? Or if I broke it
when I was implementing the shellcheck changes?

https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=003c63f7b1102702fb4a0580683b21ded1ee1a3e

Cheers,
Christian

[...]


With the caveat that I don't know how to exercise the
[ "$magic_long" = "27051956" ] branch of the code[1],
your referenced commit from staging/chunkeey is able to
sysupgrade my ipq4019-based EA8300 both over OpenWrt
as well as over OEM. I have also spot-checked the
"missing boot_part" path.

Thanks for the quick review of the changes as well as
the clean-up of existing code.

Jeff


---

[1] EA8300 "factory" images don't match the "other" branch

$ hexdump -C -n 128 ~/devel/ea8300/FW_EA8300_1.1.4.191539_prod.img
  d0 0d fe ed 00 27 72 7c  00 00 00 38 00 27 6e a8  |.'r|...8.'n.|
0010  00 00 00 28 00 00 00 11  00 00 00 10 00 00 00 00  |...(|
0020  00 00 00 6c 00 27 6e 70  00 00 00 00 00 00 00 00  |...l.'np|
0030  00 00 00 00 00 00 00 00  00 00 00 01 00 00 00 00  ||
0040  00 00 00 03 00 00 00 04  00 00 00 5c 5b d0 bf b0  |...\[...|
0050  00 00 00 03 00 00 00 27  00 00 00 00 41 52 4d 20  |...'ARM |
0060  4c 69 6e 6b 73 79 73 20  46 49 54 20 28 46 6c 61  |Linksys FIT (Fla|
0070  74 74 65 6e 65 64 20 49  6d 61 67 65 20 54 72 65  |ttened Image Tre|
0080

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export

[Jeff Kletsky]

On 11/5/19 11:01 AM, Bjørn Mork wrote:


"Adrian Schmutzler"  writes:


But, based on the discussion here, the opposite has been identified as
superior solution (discussing nand subtarget):
https://github.com/openwrt/openwrt/pull/2184#discussion_r342136635

That's missing the point. Regulators are superior if there is
controlling driver. E.g.
https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt

See arch/arm/boot/dts/armada-385-linksys.dtsi for a nice, OpenWrt
relevant, example using this with a fixed regulator.

If you don't link anything to the regulator, then I agree that you might
as well use gpio-hog.  But I still don't see how you can call that a
superior solution.  It doesn't suck more or less.  I thought the ath79
conversion was all about using devicetree to document the boards ;-)



I agree that if the driver can control the regulator and do something
useful with it (such as dropping it to hard-reset the USB devices),
there are advantages.

However, my recent work on the ath79-nand kernel shows that adding

  CONFIG_REGULATOR=y
  CONFIG_REGULATOR_FIXED_VOLTAGE=y

results in an increase in kernel size of ~14 kB:

  1,952,020 with regulator-fixed
  1,937,164 with gpio-hog

At least for the ath79-nand target, things are getting tight for a
2 MB kernel limit, with only a handful of boards and their "unique"
hardware aspects accounted for yet.


Jeff


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] build-system: NAND: Concerns around bad-block reservation and kernel / image size

[Jeff Kletsky]

TL;DR

  NAND-resident kernels seem likely to have bad blocks in the partition.

  `KERNEL_SIZE := 2048k` seems likely to overflow a 2 MB partition
  that has even a single bad block

  The ath79-nand kernel is already over 1,900,000 bytes

  What should the bad-block reservation be for a 2-MB partition?
  A 4-MB partition?

  Is there a way to handle "blit-it-down", "factory" images?

  What is the best way to implement bad-block reservation in the build
  system for kernels and for images in general?


-

Perhaps my memory of probability is poor, but it seems unlikely that
all the blocks in even a 2 MB kernel partition stay good over the life
of a device.

Looking at typical SPI-NAND, it has 128 kB blocks, with a bad-block
reservation of 20/1024 blocks.

A 2 MB kernel then has 16 blocks, so, assuming random failures, the
probability that they are all good would be

    (1 - (20/1024))^16 ~ 73%

A 27% failure rate for devices in the field doesn't seem reasonable.

Even with dual-kernel devices with U-Boot failover, the probability of
both being bad is around 7%, which still seems unreasonable.


-

Leaving aside poor boot-loader implementations, it would then seem
that U-Boot manages bad blocks in some way.

It looks like the `nand write` and `nand read` commands skip bad
blocks[1]. It is my understanding that the OpenWrt `mtd` executable
functions similarly.

If I've got a device with a single, bad, 128 kB block in a 2 MB kernel
partition, then I've only got 1,966,080 of writable space. Lose
another block and there's only 1,835,008 available.

First off, this, coupled with seeing ath79-nand kernels already at
1,933,844 bytes, argues for 3- or 4-MB kernel partitions.

Second, `KERNEL_SIZE := 2048k` may not be the right way to handle
this. Not only is it used for a kernel-size check, but it is often
used in the construction of "factory" images as the size of the kernel
partition

  IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | 
append-ubi


It seems that either bad-block reservation needs to be "built in" to
the KERNEL_SIZE check, or a new parameter introduced that is the
"pad-to" size.

There seems to be an additional complication with pad-to, as it often
is used in "factory" images to move the UBI image to its desired
starting address. The build system can't know how many bad blocks
there already may be on a specific end-user's device.


-

As far as how much to reserve, my recollection of combinations and
permutations probably isn't what it should be. If I've made a mistake
in my assumptions or analysis, please let me know!

For the SPI NAND that I've looked at, as well as for something like
the Micron MT29F1-series parallel NAND[2], it looks like

* Blocks are 128 kB of data
* Number of valid blocks is typically 1004 per 1024

At least as far as I know, when a block "goes bad", the entire 128 kB
of data is no longer available.

If my dusty memory of probability is correct, then the probability of a
given number of bad blocks is the probability that it happens in one
pattern

  p_one_way = (p_bad ** bad_count) *
  (p_good ** (partition_blocks - bad_count))

multiplied by the number of ways those number of bad blocks can be
arranged among the number of blocks being examined.

  combinations(partition_blocks, bad_count)

The probability of failure at a given number of failed blocks is then
one minus the cumulative probability of that number of failed blocks or
less.

If I got this all right (Python code below), the results are ugly

(The second column is the "unreserved" space for the kernel,
"One in" is the probability of the bad blocks impacting the kernel.)

  p_bad = 20/1024

2 MB partition: Pnbb Pcumul
 0 in 16    2,048 kB    One in  3  0.729357 0.729357
 1 in 16    1,920 kB    One in 26  0.232464 0.961821
 2 in 16    1,792 kB    One in    290  0.034731 0.996552
 3 in 16    1,664 kB    One in  4,558  0.003229 0.999781
 4 in 16    1,536 kB    One in 96,443  0.000209 0.90
 5 in 16    1,408 kB    One in  2,662,549  0.10 1.00

4 MB partition: Pnbb Pcumul
 0 in 32    4,096 kB    One in  2  0.531961 0.531961
 1 in 32    3,968 kB    One in  7  0.339099 0.871060
 2 in 32    3,840 kB    One in 41  0.104702 0.975762
 3 in 32    3,712 kB    One in    295  0.020857 0.996619
 4 in 32    3,584 kB    One in  2,713  0.003012 0.999631
 5 in 32    3,456 kB    One in 30,772  0.000336 0.68
 6 in 32    3,328 kB    One in    421,026  0.30 0.98
 7 in 32    3,200 kB    One in  6,827,817  0.02 1.00


If 1 in ~100,000 is an "acceptable" failure rate for a given kernel
(see later note on dual-kernel layouts)

2 MB partition can "safely" hold 1,536 kB
4 MB partition can "safely" hold 3,328 kB


Dropping to 

Re: [OpenWrt-Devel] [PATCH 1/3] ipq40xx: Add gigadevice nandspi flash driver

[Jeff Kletsky]

On 10/30/19 4:27 AM, Daniel Danzberger wrote:


This patch adds support for Gigadevice SPI NAND device to the mt29f stagging 
driver.

Signed-off-by: Daniel Danzberger 
---
  ...port-gigadevice-nandspi-flash-device.patch | 1778 +
  1 file changed, 1778 insertions(+)
  create mode 100644 
target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch


[...]



Is there a reason why the upstream SPI-NAND framework isn't being used?

This has been demanded of the ath79 target (see, for example
https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401)

and is available to the ipq40xx target and appears to already be in use by:

  qcom-ipq4018-rt-ac58u.dts
  qcom-ipq4018-ea6350v3.dts
  qcom-ipq4018-ap120c-ac.dts
  qcom-ipq4018-jalapeno.dts



Further, the mt29f driver has been removed from upstream Linux

commit 647ad49ca672
Author: Boris Brezillon 
Date:   Mon Oct 22 22:10:59 2018 +0200

    staging: Remove the mt29f_spinand driver

    A new SPI NAND subsystem has been added in drivers/mtd/nand/spi/ and
    Micron's MT29F devices are now supported in
    drivers/mtd/nand/spi/micron.c.

    Remove the old driver.




The set of SPI-NAND chips supported by Linux 5.3 has already been
backported to OpenWrt `master`, including; GigaDevice, Macronix,
Micron, Paragon, Toshiba, and Winbond.


commit b9d58f7e06
Author: Jeff Kletsky 
Date:   Thu Oct 24 09:54:11 2019 -0700

    kernel: mtd: spinand: Backport chip definitions

    generic: Add/rename patches for upstream consistency

    ipq40xx: generic-level patch replaces same-source patches-4.19/
082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch

    The SPI-NAND framework from Linux uses common driver code that is then
    "tuned" by a tiny struct of chip-specific data that describes
    available commands, timing, and layout (data and OOB data). Several
    manufacturers and chips have been added since 4.19, several of which
    are used in devices already supported by OpenWrt (typically with no or
    "legacy" access to their NAND memory). This commit catches up the
    supported-chip definitions through Linux 5.2-rc6 and linux/next.

    The driver is only compiled for platforms with CONFIG_MTD_SPI_NAND=y.
    This presently includes ipq40xx and pistachio, with the addition of
    ath79-nand in these commits (and not ath79-generic or ath79-tiny).

    Upstream patches refreshed against 4.19.75

    Build-tested-on: ipq40xx
    Run-tested-on: ath79-nand




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] v5.4 as next kernel

[Jeff Kletsky]

 are any new commits within release branch" until after 20.06
  (reality here outweighs product-manager instincts)

* Plan for and release 20.07
  * On schedule
  * With Linux 5.4


Jeff Kletsky


[1] https://openwrt.org/meetings/hamburg2019/start#decisions



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

[Jeff Kletsky]

On 10/30/19 4:27 AM, Daniel Danzberger wrote:


This device contains 2 flash devices. One NOR (32M) and one NAND (128M).
U-boot and caldata are on the NOR, the firmware on the NAND.

 SoC:IPQ4019
 CPU:4x 710MHz ARMv7
 RAM:256MB
 FLASH:  NOR:32MB NAND:128MB

[...]




 .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
 .../include/dt-bindings/msm/msm-bus-ids.h |  869 +

The sudden appearance of a need the MSM bus and its IDs worries me.

With 25 devices already on the ipq40xx platform without them, it feels
like something is missing if they are needed by this one.



diff --git a/target/linux/ipq40xx/config-4.19 b/target/linux/ipq40xx/config-4.19
index 8948b73ff7..3ee921abed 100644
--- a/target/linux/ipq40xx/config-4.19
+++ b/target/linux/ipq40xx/config-4.19
@@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
  CONFIG_MTD_NAND_QCOM=y
  CONFIG_MTD_SPI_NAND=y
  CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_SPINAND_MT29F=y
+CONFIG_MTD_SPINAND_GIGADEVICE=y
+CONFIG_MTD_SPINAND_ONDIEECC=y



The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND



  CONFIG_MTD_SPLIT_FIRMWARE=y
  CONFIG_MTD_SPLIT_FIT_FW=y
  CONFIG_MTD_UBI=y

[...]

diff --git 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
new file mode 100644
index 00..5553bbd166
--- /dev/null
+++ b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
@@ -0,0 +1,371 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019, Nguyen Dinh Phi 
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+

[...]

+
+   spi_0: spi@78b5000 {
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+   cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
GPIO_ACTIVE_HIGH>;
+   num-cs = <2>;
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   linux,modalias = "m25p80", "n25q128a11";
+   compatible = "jedec,spi-nor", "n25q128a11";
+   spi-max-frequency = <2400>;



I don't think you need linux,modalias here, nor the chip type in the 
compatible line.

I believe that the following compatible line is sufficient

    compatible = "jedec,spi-nor";


You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
or the like, rather than a chip-specific name. (I'm not a committer.)



+
+   partitions {
+   compatible = "fixed-partitions";
+
+   partition@0 {
+   label = "0:SBL1";
+   reg = <0x00 0x04>;
+   read-only;
+   };
+
+   partition@4 {
+   label = "0:MIBIB";
+   reg = <0x04 0x02>;
+   read-only;
+   };
+
+   partition@6 {
+   label = "0:QSEE";
+   reg = <0x06 0x06>;
+   read-only;
+   };
+
+   partition@c {
+   label = "0:CDT";
+   reg = <0x0c 0x01>;
+   read-only;
+   };



Someone may rip on you for capitalization of labels. (I'm not a committer.)



+
+   partition@d {
+   label = "0:DDRPARAMS";
+ 

[OpenWrt-Devel] [Info] Fwd: [PATCH v4 0/4] MTD concat

[Jeff Kletsky]

If I understand this properly, the ability to logically concatenate
MTD partitions may have benefits to the project in the future.

http://lists.infradead.org/pipermail/linux-mtd/2019-November/092535.html

Jeff

---


Hello,

A year ago Bernhard Frauendienst started an effort to bring MTD
devices concatenation generic [1]. Today I also need this
concatenation to be possible in order to support configurations where
two MTD devices are treated like one bigger in order to be able to
define partitions across chip boundaries, hence reviving this
patchset.

After having talked with Mark Brown and Boris Brezillon this approach
seems to be the cleanest and easiest one. If discussions need to
happen, it is probably on the dt-bindings file where I tried to
summarize the issue and the possible solutions in the commit log.

I changed a bit the code logic and style but not so much, all the
changes with the 2018 version are in [ ] in the commit logs.

I would like to add another way to concatenate devices: with module
parameters/arguments on the cmdline. I will extend this work once the
bindings will have been discussed and accepted.

Thanks,
Miquèl

[1] 
https://lwn.net/ml/linux-kernel/20180907173515.19990-1-ker...@nospam.obeliks.de/



Bernhard Frauendienst (3):
mtd: Add get_mtd_device_by_node() helper
dt-bindings: mtd: Describe mtd-concat devices
mtd: Add driver for concatenating devices

Miquel Raynal (1):
mtd: concat: Fix a comment referring to an unknown symbol

.../devicetree/bindings/mtd/mtd-concat.yaml | 56 
drivers/mtd/Kconfig | 8 ++
drivers/mtd/Makefile | 1 +
drivers/mtd/mtd_virt_concat.c | 132 ++
drivers/mtd/mtdconcat.c | 5 +-
drivers/mtd/mtdcore.c | 38 +
include/linux/mtd/mtd.h | 2 +
7 files changed, 238 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/mtd-concat.yaml
create mode 100644 drivers/mtd/mtd_virt_concat.c

--
2.20.1


__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] ath79: GL-AR750S (NOR/NAND): limit factory.img kernel size to 2 MB

[Jeff Kletsky]

From: Jeff Kletsky 

The present U-Boot for GL-AR750S has a limit of 2 MB for kernel size.
While sysupgrade can manage kernels up to the present limit of 4 MB,
directly flashing a factory.img with a kernel size greater than 2 MB
through U-Boot will result in an unbootable device.

This commit uses the newly-introduced check-kernel-size build
operation to prevent the output of factory.img when the kernel
exceeds 2 MB in size, yet permits output of sysupgrade.img
as long as the kernel is within KERNEL_SIZE := 4096k

Cc: Chuanhong Guo 

Signed-off-by: Jeff Kletsky 
---
 target/linux/ath79/image/nand.mk | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 7940167e1a..75c1af89bb 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -89,12 +89,15 @@ define Device/glinet_gl-ar750s-common
   VID_HDR_OFFSET := 2048
 endef
 
+# NB: The kernel size is intentionally restricted at this time; see commit 
message
 define Device/glinet_gl-ar750s-nor-nand
   $(Device/glinet_gl-ar750s-common)
   DEVICE_VARIANT := NOR/NAND
   BLOCKSIZE := 128k
+  GL_UBOOT_UBI_OFFSET := 2048k
   IMAGES += factory.img
-  IMAGE/factory.img := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
+  IMAGE/factory.img := append-kernel | pad-to (GL_UBOOT_UBI_OFFSET) | \
+   append-ubi | check-kernel-size (GL_UBOOT_UBI_OFFSET)
   IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
   SUPPORTED_DEVICES += glinet,gl-ar750s-nor
 endef
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] build: define check-kernel-size to remove unflashable images

[Jeff Kletsky]

From: Jeff Kletsky 

Certain boards have limitations on U-Boot that prevent flashing
of images where the kernel size exceeds a threshold, yet
sysupgrade can sucessfully manage larger kernels. The current
check-size will remove the target artifact if its total size
exceeds the threshold. If applied after append-kernel,
it will remove the kernel, but the remaining image-assembly
steps will continue, resulting in an image without a kernel
that is likely unbootable.

By defining check-kernel-size, it is now possible to prevent release
of such unbootable images through a construct similar to:

  IMAGE/factory.img := append-kernel | pad-to (GL_UBOOT_UBI_OFFSET) | \
append-ubi | check-kernel-size (GL_UBOOT_UBI_OFFSET)

Cc: Chuanhong Guo 

Signed-off-by: Jeff Kletsky 
---
 include/image-commands.mk | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/image-commands.mk b/include/image-commands.mk
index 5dfd6a2c2f..f561ad4669 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -271,6 +271,13 @@ define Build/check-size
}
 endef
 
+define Build/check-kernel-size
+   @[ $$(($(subst k,* 1024,$(subst m, * 1024k,$(1) -ge "$$(stat -c%s 
$(IMAGE_KERNEL))" ] || { \
+   echo "WARNING: Kernel for $@ is too big > $(1)" >&2; \
+   rm -f $@; \
+   }
+endef
+
 define Build/combined-image
-sh $(TOPDIR)/scripts/combined-image.sh \
"$(IMAGE_KERNEL)" \
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] fstools: Question: Approach to make jffs2reset NAND-aware

[Jeff Kletsky]

One of the next things on my list is getting `firstboot` to work with
NAND (UBI) flash.

As reported[1], `jff2reset.c` does not seem to consider that there is
a UBI volume being used for the overlay. It appears to fail in
"marking" the file system as needing erasure.

root@(none):/# firstboot
[   32.530266] jffs2reset: This will erase all settings and remove any 
installed packages. Are you sure? [N/y]

y
[   34.958257] jffs2reset: /dev/ubi0_1 is not mounted
[   34.963187] jffs2reset: /dev/ubi0_1 will be erased on next mount
[   34.969244] jffs2reset: writing /dev/ubi0_1 failed: Operation not 
permitted


While there are command-line work-arounds, this also impacts the
"button-press reset" functionality.

The failure is due to at least

  sz = write(fd, , sizeof(deadc0de));

which returns -1 when trying to write directly to NAND flash.


Before I dive into dealing with UBI from C code, what would be a
project-preferred way to mark a UBI volume for erasure at next mount?

  * Presence of `.erase_this_volume` in the root of the file system?
  * Some other mark?


I'll work through how to erase the volume without losing track of the
existing wear-balancing and bad-block management features once I've
got a good way to detect that it should be done at next mount,
preferably without a "double erase" occurring[2].

Jeff




[1] https://bugs.openwrt.org/index.php?do=details_id=468
    https://bugs.openwrt.org/index.php?do=details_id=2121

[2] http://www.linux-mtd.infradead.org/faq/ubifs.html#L_why_ubiformat





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel