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

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

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

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

Re: [OpenWrt-Devel] INSTALL_SUID macro

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,

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

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 === Ch

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

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

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

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 &q

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

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

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

(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

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

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

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

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

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

://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

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

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] [PATCH] ath79: Add GL.iNet AR-300M-Lite

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"

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

] 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

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

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

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

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

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

[OpenWrt-Devel] Patchwork and git send-email

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

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

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

[OpenWrt-Devel] ARM: Overriding Specific bootargs

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

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

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

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

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

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

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 indica

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

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

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

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

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

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"

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

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

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

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

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

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

[OpenWrt-Devel] ipq40xx: bootarg Manipulation Failing

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  

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

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

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

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

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

5c22c62be1e95325299e5acc92 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.

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

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

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

$ ./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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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(-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-Devel] NOHZ: local_softirq_pending 08 -- IPQ4019 on master

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

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

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

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

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

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

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

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

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 Je

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

[OpenWrt-Devel] [PATCH 2/3] ath79: Prepare nand subtarget for SPI-NAND boards under Linux 4.19

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

[OpenWrt-Devel] [PATCH 1/3] mtd: spinand: Add support for GigaDevice GD5F1GQ4UFxxG (Pending)

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

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

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 i

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

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

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

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 compat

Re: [OpenWrt-Devel] [PATCH] upgrade: nand: fix board_name assumtions

duk +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 (

Re: [OpenWrt-Devel] [PATCH] upgrade: nand: fix board_name assumtions

(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

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

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

[OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

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

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

Re: [OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

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

Re: [OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 firmware

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

Re: [OpenWrt-Devel] SDK enhancement proposal - add external toolchains via feeds

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

[OpenWrt-Devel] DTS Style: Referring to "Upstream" Nodes

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,

[OpenWrt-Devel] [PATCH] ath79: glinet_gl-ar750s: Use QCA9887 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

[OpenWrt-Devel] build: sysupgrade: kernel: mtd: Image too SMALL to Restore Config

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

Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

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

Re: [OpenWrt-Devel] Compilation error switch to pyhon 3

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

[OpenWrt-Devel] "mac80211: Update to version 5.2-rc7" breaks batman-adv

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

Re: [OpenWrt-Devel] [PATCH] mvebu: Replace backticks by $(...)

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]

Re: [OpenWrt-Devel] "mac80211: Update to version 5.2-rc7" breaks batman-adv

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

Re: [OpenWrt-Devel] [PATCH 0/1] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

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 o

[OpenWrt-Devel] [PATCH v2 1/2] ath79: Correct glinet, gl-ar300m-lite in 02_network

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 "simpl

[OpenWrt-Devel] [PATCH v2 2/2] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

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

[OpenWrt-Devel] [PATCH 0/1] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

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

[OpenWrt-Devel] [PATCH 1/1] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

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" p

[OpenWrt-Devel] [PATCH] ath79: Clean up GL-AR300M DTS/DTSI inclusions

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

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

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

Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export

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

[OpenWrt-Devel] [RFC] build-system: NAND: Concerns around bad-block reservation and kernel / image size

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

Re: [OpenWrt-Devel] [PATCH 1/3] ipq40xx: Add gigadevice nandspi flash driver

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

Re: [OpenWrt-Devel] v5.4 as next kernel

nager 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

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 [...]

[OpenWrt-Devel] [Info] Fwd: [PATCH v4 0/4] MTD concat

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

[OpenWrt-Devel] [PATCH 2/2] ath79: GL-AR750S (NOR/NAND): limit factory.img kernel size to 2 MB

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

[OpenWrt-Devel] [PATCH 1/2] build: define check-kernel-size to remove unflashable images

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

[OpenWrt-Devel] [RFC] fstools: Question: Approach to make jffs2reset NAND-aware

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 [  

  1   2   >