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&task_id=2123 [...] * The "classic" drivers/firmware fail on or after the in

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, GP

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

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

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

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

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

[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 ass

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] 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] [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 of the

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 https://lists.openwrt.org/mailman/li

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

[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   init=/sbin/in

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 t

[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 issues

[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 a

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,

[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

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

[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

[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     &blsp1_spi2 or (taking into account scope or

[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

[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

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 for

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

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 `m

[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

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

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 https://github.com/openwrt/openwrt/blob/ma

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

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

[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 b

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

[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

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

[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 applicable

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

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_DEV

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] 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] [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 support,

[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 and/or

[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

[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

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 understan

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

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

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 will

[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 08

[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 situation

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

Thanks! Blocksize turned out to be the issue -- resolved for the devices in question. I'm still interested in finding out where the definition of the "default" sysupgrade.img is found in make files of the build system. Jeff On 7/1/19 1:47 PM, Hannu Nyman wrote: The smaller, "failing" image

[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 http://downloads.openwrt.org/snapshots/faillogs/mips_24kc/routing/batman-adv/comp

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] 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] 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 "/ho

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 po

[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 ther

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, an

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] 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 gene

[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 be

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

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] 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 of:

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 has

[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 an

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

On 2/8/19 4:00 AM, Christian Lamparter wrote: On Thursday, February 7, 2019 6:15:13 PM CET Jeff Kletsky wrote: 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 maintainabili

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 sh

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

[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 t

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

firmed 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 Subjec

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&task_id=2123 The combination of ath10k-ct and firmware ver 10.2.4-1.0-00043 works on my QCA9880 (tp-link archer a

[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 appreci

[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

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 of re

[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 "simple-mfd

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

[OpenWrt-Devel] build: "bash: GZ_SUFFIX: command not found" -- Likely From Device/Build/image

As discovered by "wulfy23"[1], a verbose build (V=s) off `master` indicates     GZ_SUFFIX :=     bash: GZ_SUFFIX: command not found This appears to be "cosmetic", as the images are created, can be flashed, and run as expected. Observed with: * ath79, GL-AR300M (NAND) (1x) * ath79, Archer C7

[OpenWrt-Devel] [PATCH 2/2] ath79: GL-AR750S: Add I2C Support

From: Jeff Kletsky The GL-AR750S has an internal header for I2C. Provide DTS definitions for the i2c-gpio driver. The I2C drivers; kmod-i2c-core, kmod-i2c-gpio consume ~20 kB of flash and can be loaded as modules, Default clock measured ~11.2 ms period, ~89 kHz The board has well-labeled

[OpenWrt-Devel] [PATCH 1/2] ath79: GL-AR300M series: Add I2C Support

From: Jeff Kletsky The GL-AR300M series have an internal header for I2C. Provide DTS definitions for the i2c-gpio driver. The I2C drivers; kmod-i2c-core, kmod-i2c-gpio consume ~20 kB of flash and can be loaded as modules, Default clock measured ~11.4 ms period, ~88 kHz The board has two sets

[OpenWrt-Devel] [PATCH] ath79: Refactor GL.iNet GL-AR300M-series generic.mk

From: Jeff Kletsky Rework DEVICE_VENDOR, DEVICE_MODEL, and DEVICE_VARIANT for the GL-AR300M series on the ath79-generic target. Changes GL-AR300M-Lite to the current form with DEVICE_VARIANT := Lite (board name is unchanged) Signed-off-by: Jeff Kletsky --- target/linux/ath79/image/generic.mk

[OpenWrt-Devel] [PATCH] ath79: uboot-envtools: Add GL-AR300M-Lite

From: Jeff Kletsky Add the GL.iNet GL-AR300M-Lite to the list of supported boards. Signed-off-by: Jeff Kletsky --- package/boot/uboot-envtools/files/ath79 | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ath79 b/package/boot/uboot-envtools/files/ath79

Re: [OpenWrt-Devel] [PATCH] ath79: split base-files into subtargets

ry for a target and subtarget Note that even a few kB of increased file size can increase the size of the file system by a full JFFS erase block, pushing a device from "supported" to not supportable. Jeff Kletsky [1] https://github.com/openwrt/openwrt/pull/2184

[OpenWrt-Devel] [PATCH] kernel: mtd: spinand: Backport chip definitions

From: Jeff Kletsky 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"

  1   2   >