: Jeff Shiu
---
list.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/list.c b/list.c
index 304c9e1..6545ba5 100644
--- a/list.c
+++ b/list.c
@@ -228,6 +228,7 @@ uci_free_section(struct uci_section *s)
if ((s->type != uci_dataptr(s)) &&
(s-&g
From: Jeff Kletsky
Introduction of the ath79/nand images for the GL-AR300M series
resulted in a non-bootable set of partition names for the
ath79/generic kernels for the GL-AR300M16 and GL-AR300M-Lite.
Signed-off-by: Jeff Kletsky
---
target/linux/ath79/dts/qca9531_glinet_gl-ar300m-lite.dts
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
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
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
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&task_id=468
https://bugs.openwrt.org/index.p
pgrade messaging and
NAND upgrade would need to be improved, as it would be reasonably
likely that the partition didn't "switch every time" as it does now.)
Yes, UBI-resident kernels[3] help this as the bad blocks are dealt with
over the span of the UBI partition, but very few de
On 11/6/19 2:47 PM, Daniel Golle wrote:
Hi Jeff,
On Thu, Oct 24, 2019 at 08:57:52PM -0700, Jeff Kletsky wrote:
From: Jeff Kletsky
Targets that use nand_do_platform_check() can't use SUPPORTED_DEVICES
as the check requires ./sysupgrade-legacy_boardname/CONTROL to be
non-zero leng
B:
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
__
milar ipq40xx. It may provide insight.
https://forum.openwrt.org/t/ipsec-differences-between-devices-is-kmod-crypto-ctr-the-problem/44461?u=jeff
https://github.com/openwrt/openwrt/pull/2518
I haven't been following it very closely, but as I was surprised that
the IPQ4019-based EA8300
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
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
[...]
.
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 d
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 provide FEATURES += squashfs nand
* Updated config-default to provide current MTD and UBI support
Defaults selected for
Supersedes https://patchwork.ozlabs.org/project/openwrt/list/?series=138553
due to need to rebase
With commit 758a4d1766 ath79: add AR934x NAND Flash Controller driver
cleaning up the ath79 NAND target and the problems with NAND-based
sysupgrade, including that it doesn't respect SUPPORTED_DEVICE
ult of a call to mktemp(1), or generically named.
Jeff Kletsky
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
0x1000. Thus, remove the
redundant mtd-mac-address for those devices.
Signed-off-by: Adrian Schmutzler
Tested-by: Jeff Kletsky GL-AR300M-NAND
---
Not tested on the devices affected by this patch, but obviously
tested quite often with other device support PRs prior to merge.
---
target/linux
From: Jeff Kletsky
Targets that use nand_do_platform_check() can't use SUPPORTED_DEVICES
as the check requires ./sysupgrade-legacy_boardname/CONTROL to be
non-zero length as extracted from the tar file. Previously, only
./sysupgrade-new_boardname/CONTROL was present.
This prevents up
This submission is part of a series of commits that prepares for
use of SPI-NAND with the upstream Linux MTD framework for the ath79
target. The entire series of pending changes may be seen on GitHub[1].
The series also addresses upgrade issues associated with tar-style
files and metadata, allow
From: Jeff Kletsky
Improve NAND-based sysupgrade for current and future upgrades
nand_upgrade_tar():
* Use the CONTROL file specific to the running board
to determine asset directory name in the tar file
* Check for string `BOARD=board_name` directly rather than
source-ing to
From: Jeff Kletsky
Remove the sole board on the legacy ath79 NAND target
to clarify patches that will reintroduce support
on the MTD SPI-NAND framework present in Linux 4.19
Cc: Marty E. Plummer
Signed-off-by: Jeff Kletsky
---
package/boot/uboot-envtools/files/ath79 | 1 -
.../ath79
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 provide FEATURES += squashfs nand
* Updated config-default to provide current MTD and UBI support
Defaults selected for
This submission is part of a series of commits that prepares for
use of SPI-NAND with the upstream Linux MTD framework for the ath79
target. The entire series of pending changes may be seen on GitHub[1].
The series also addresses upgrade issues associated with tar-style
files and metadata, allow
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"
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
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
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
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
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
ET_IMAGES_GZIP)),.gz))
$$(_TARGET): $(BIN_DIR)/$(call IMAGE_NAME,$(1),$(2))$$(GZ_SUFFIX)
My "make" skills are, unfortunately, not sufficient to diagnose further.
Jeff
[1] https://github.com/openwrt/openwrt/pull/2184#issuecomment-544830445
___
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
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
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
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
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
rr 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
&mdio1 {
status = "okay";
};
was tested, and found to have the same, unsucessful result.
If there are s
ll 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
l/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
mkvol \
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 understan
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
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.
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 sm
lit/mtdsplit_squashfs.c
which calls mtd_get_squashfs_len()
target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit.c
from the super block.
---
I tend to believe that the JFFS2 code from Linux handles the partition
"properly". If so, in
#x27;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
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
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
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
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
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
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
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
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
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
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
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
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
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.
Th
addr" "$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
(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
On 5/20/19 6:42 AM, Jeff Kletsky wrote:
cc-ing primary Imgtec / pistachio / Creator Ci40 contributors identified
Note that all five imgtec.com email addresses found in the commit log bounce.
The pistachio and the Ci40 do not seem to appear on the imgtec.com site,
nor do related downloads at
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
t 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=10788
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
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
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
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
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
onsidered, 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,
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
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
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/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-
or 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 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
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
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
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
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
ciate 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
-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
s have been
demonstrated to be able to use it under OpenWrt. Not that I expect those
things to magically happen, but they do make it challenging for a
responsible OEM to switch over as easily as a hobbyist.
Jeff
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Overtaken by https://github.com/openwrt/openwrt/pull/1980
Can close this patch in favor of the PR
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Overtaken by https://github.com/openwrt/openwrt/pull/1980
Can close this patch in favor of the PR
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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
___
count 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
r
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
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: 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
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,
ed( (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.
s 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
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
oing 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
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&
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
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
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
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
ditional 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@lis
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
1 - 100 of 159 matches
Mail list logo
