[LEDE-DEV] jffs issues on sysupgrade with keeping old config
Hi, Having some issues with sysupgrade on Archer C2600 (ipq806x with NOR flash). (from the discussion at https://forum.openwrt.org/viewtopic.php?pid=327671#p327671) When doing sysupgrade without keeping config files, everything goes ok. In that case at first boot I get Sat Jun 18 09:50:48 2016 user.notice kernel: [9.003952] mount_root: jffs2 not ready yet, using temporary tmpfs overlay and then later Sat Jun 18 09:52:21 2016 daemon.info mount_root: performing overlay whiteout Which I interpret as "jffs not ready at the beginning of init, so use the ram overlay temporarily, then switch to jffs2 later when it is ready at the end of the init" Now instead, running sysupgrade and keeping the configuration, we end up with the attached log, where somehow the system thinks that jffs2 is ready to use, even if it isn't fully ready, and then there is a crash when there is an attempt to write to it. Any ideas here? It almost looks to me that the check on whether jffs2 is ready at this stage is not strict enough. (But maybe there is something else wrong). Thanks, Josh ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice bug
Hi everybody,
Some of you might remember that there was a bug where an ext4 rootfs was
mounted twice, first as / and then as overlay.
After staring down the mount_root.c file I think I spotted the reason
for it. Sadly I was not able to reproduce the original problem so I am
looking for somebody who had this issue and would be willing to try out
a patch of mine.
Please get back at me if you can.
For any interested people I am attaching the patch to this mail (this is
not yet a patch submission, just discussion).
br
Josua Mayer
>From 92e2a22f3af1e04e8f83c3b580da941c69e460b4 Mon Sep 17 00:00:00 2001
From: Ram Chandra Jangir
Date: Fri, 11 Mar 2016 22:01:42 +0530
Subject: [PATCH 1/2] fstools: support for ext4fs overlay
This change will enables eMMC (ext4 fs) boot support, when we try to boot
from eMMC card then it will read partition names from
/sys/block/mmcblkX/mmcblkXY/uevent
file and will mount the rootfs_data partition as ext4fs overlay.
Signed-off-by: Ram Chandra Jangir
---
CMakeLists.txt | 1 +
libfstools/ext4.c | 193
libfstools/find.c | 3 +-
libfstools/libfstools.h | 1 +
libfstools/overlay.c| 14
libfstools/volume.h | 1 +
mount_root.c| 2 +
7 files changed, 214 insertions(+), 1 deletion(-)
create mode 100644 libfstools/ext4.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a6002e5..5117e8e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -11,6 +11,7 @@ ADD_LIBRARY(fstools SHARED
libfstools/overlay.c
libfstools/volume.c
libfstools/mtd.c
+ libfstools/ext4.c
libfstools/mount.c
libfstools/ubi.c
libfstools/find.c)
diff --git a/libfstools/ext4.c b/libfstools/ext4.c
new file mode 100644
index 000..f648aa8
--- /dev/null
+++ b/libfstools/ext4.c
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+*/
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "libfstools.h"
+
+#include "volume.h"
+
+#define ext4_sysfs_path "/sys/block/mmcblk*/mmcblk*/uevent"
+#define MAX_SIZE 128
+
+#define EXT_SB_OFF 0x400
+#define EXT_SB_KBOFF (EXT_SB_OFF >> 10)
+#define EXT_SB_MAGIC "\123\357"
+#define EXT_MAG_OFF 0x38
+
+struct ext4_priv {
+ char *name;
+ char*devname;
+};
+
+static struct driver ext4_driver;
+
+static int ext4_volume_init(struct volume *v)
+{
+ char buf[MAX_SIZE];
+ struct ext4_priv *p;
+
+ p = (struct ext4_priv*)v->priv;
+ snprintf(buf, sizeof(buf), "/dev/%s",p->devname);
+
+ v->name = strdup(p->name);
+ v->type = EXT4VOLUME;
+ v->blk = strdup(buf);
+ return 0;
+}
+
+static int
+ext4_part_match(char *dev, char *name, char *filename)
+{
+ FILE *fp;
+ char buf[MAX_SIZE];
+ char devname[MAX_SIZE];
+ int i;
+ int ret = -1;
+
+ fp = fopen(filename, "r");
+ if (!fp)
+ return ret;
+
+ while (fgets(buf, sizeof(buf), fp)) {
+ if (strstr(buf, "DEVNAME")) {
+ strcpy(devname, buf + strlen("DEVNAME="));
+ continue;
+ }
+ /* Match partition name */
+ if (strstr(buf, name)) {
+ ret = 0;
+ break;
+ }
+ }
+
+ fclose(fp);
+
+ /* make sure the string is \0 terminated */
+ devname[sizeof(devname) - 1] = '\0';
+
+ /* remove trailing whitespace */
+ i = strlen(devname) - 1;
+ while (i > 0 && devname[i] <= ' ')
+ devname[i--] = '\0';
+
+ strcpy(dev, devname);
+ return ret;
+}
+
+static int ext4_find_devname(char *dev, char *name)
+{
+ int i;
+ glob_t gl;
+
+ if (glob(ext4_sysfs_path, GLOB_NOESCAPE | GLOB_MARK, NULL, &gl) < 0)
+ return -1;
+
+ for (i = 0; i < gl.gl_pathc; i++) {
+ if (!ext4_part_match(dev, name, gl.gl_pathv[i])) {
+ globfree(&gl);
+ return 0;
+ }
+ }
+
+ globfree(&gl);
+ return -1;
+}
+
+static int check_for_mtd(const char *mtd)
+{
+ FILE *fp;
+ char dev[MAX_SIZE];
+
+ if ((fp = fopen("/proc/mtd", "r"))) {
+ while (fgets(dev, sizeof(dev), fp)) {
+ if (strstr(dev, mtd)) {
+fclose(fp);
+return -1;
+ }
+ }
+ }
+ fclose(fp);
+ return 0;
+}
+
+static int ext4_volume_find(struct volume *v, char *name)
+{
+ char buf[MAX_SIZE];
+ struct ext4_priv *p;
+
+ if (find_filesystem("ext4"))
+ return -1;
+
+ if (check_for_mtd(name))
+ return -1;
+
+ if (ext4_find_devname(buf, name))
+ return -1;
+
+p
[LEDE-DEV] [PATCH] lantiq: fix network in failsafe
So far the network in failsafe is setup only for one board. Use the
eth0 interface as lan interface for all boards for now.
If a board has its lan interface(s) on another eth, a special
handling based on the board name can be added.
Signed-off-by: Mathias Kresin
---
.../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git
a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
index 3d7fabf..7ed0fab 100644
--- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
+++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
@@ -3,15 +3,7 @@
. /lib/functions/lantiq.sh
set_preinit_iface() {
-
- board=$(lantiq_board_name)
-
- case "$board" in
- TDW8970)
- ifname=eth0
- ;;
- esac
-
+ ifname=eth0
}
boot_hook_add preinit_main set_preinit_iface
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] lantiq: fix build of NAND sysupgrade images
The *_UBIFS_OPTS variables need to be prefixed with DEVICE_ to match the profile name. The conditions need to be evaluated after the *_UBIFS_OPTS are set, otherwise the variables are always empty. Do not append or pass the DEVICE_ prefixed profile name to the images. Use the name that is passed by the Image/Build/Profile/ step. Signed-off-by: Mathias Kresin --- The changes have been only tested with the BTHOMEHUBV5A profile but should work for all (u-boot) NAND images. EVA NAND images are completely untested. target/linux/lantiq/image/Makefile | 102 - 1 file changed, 45 insertions(+), 57 deletions(-) diff --git a/target/linux/lantiq/image/Makefile b/target/linux/lantiq/image/Makefile index d9424f8..e75d634 100644 --- a/target/linux/lantiq/image/Makefile +++ b/target/linux/lantiq/image/Makefile @@ -57,14 +57,6 @@ define Image/Build/squashfs $(call prepare_generic_squashfs,$(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(1).image) endef -ifneq ($($(PROFILE)_UBI_OPTS),) - define Image/BuildNAND/squashfs - $(call prepare_generic_squashfs,$(KDIR)/root.$(1)) - $(call Image/Build/UbinizeImage,$(PROFILE),,squashfs,$($(PROFILE)_UBI_OPTS)) - $(call Image/Build/SysupgradeNAND,$(PROFILE),$(1),$(KDIR)/uImage-$(PROFILE)) - endef -endif - DGN3500_SKERNEL=0x5 DGN3500_SKERNEL_DECIMAL=327680 define Image/BuildDGN3500/squashfs @@ -107,19 +99,6 @@ define Image/BuildEVA/squashfs $(call prepare_generic_squashfs,$(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(1).image.eva) endef -ifneq ($($(PROFILE)_UBIFS_OPTS),) - define Image/BuildEVA/ubifs - $(CP) $(KDIR)/root.ubifs $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs.ubifs - endef -endif - -ifneq ($($(PROFILE)_UBI_OPTS),) - define Image/BuildEVA/ubi - $(CP) $(KDIR)/root.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs.ubi - $(CP) $(KDIR)/root-overlay.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs-overlay.ubi - endef -endif - define Image/BuildLoader/squashfs dd if=$(KDIR)/loader-$(2).bin of=$(KDIR)/loader-$(2).bin.padded bs=3072k conv=sync cat $(KDIR)/loader-$(2).bin.padded $(KDIR)/root.$(1) > $(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(1).image @@ -145,30 +124,6 @@ define Image/Build/jffs2-256k cat $(KDIR)/uImage-$(2)-$(1) $(KDIR)/root.$(1) > $(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(1).image endef -ifneq ($($(PROFILE)_UBIFS_OPTS),) - define Image/Build/ubifs - $(CP) $(KDIR)/root.ubifs $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs.ubifs - endef -endif - -ifneq ($($(PROFILE)_UBI_OPTS),) - define Image/Build/ubi - $(CP) $(KDIR)/root.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs.ubi - $(CP) $(KDIR)/root-overlay.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs-overlay.ubi - endef -endif - - -ifneq ($($(PROFILE)_UBIFS_OPTS),) -ifneq ($($(PROFILE)_UBI_OPTS),) - define Image/BuildNAND/ubifs - $(call Image/Build/UbinizeImage,$(PROFILE),,ubifs,$($(PROFILE)_UBI_OPTS)) - $(call Image/Build/SysupgradeNAND,$(PROFILE),$(1),$(KDIR)/uImage-$(PROFILE)) - endef -endif -endif - - ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) define Image/BuildKernel/InitramfsTemplate $(call PatchKernelLzma,$(1),-initramfs) @@ -326,8 +281,8 @@ endif ifeq ($(SUBTARGET),xway) # Danube -BTHOMEHUBV2B_UBIFS_OPTS:="-m 512 -e 15872 -c 1959" -BTHOMEHUBV2B_UBI_OPTS:="-m 512 -p 16KiB -s 256" +DEVICE_BTHOMEHUBV2B_UBIFS_OPTS:="-m 512 -e 15872 -c 1959" +DEVICE_BTHOMEHUBV2B_UBI_OPTS:="-m 512 -p 16KiB -s 256" Image/BuildKernel/Profile/BTHOMEHUBV2B=$(call Image/BuildKernel/Template,BTHOMEHUBV2B) Image/Build/Profile/BTHOMEHUBV2B=$(call Image/BuildNAND/$(1),$(1),BTHOMEHUBV2B) @@ -497,8 +452,8 @@ TARGET_DEVICES += GIGASX76X # AR9 -BTHOMEHUBV3A_UBIFS_OPTS:="-m 512 -e 15872 -c 1959" -BTHOMEHUBV3A_UBI_OPTS:="-m 512 -p 16KiB -s 256" +DEVICE_BTHOMEHUBV3A_UBIFS_OPTS:="-m 512 -e 15872 -c 1959" +DEVICE_BTHOMEHUBV3A_UBI_OPTS:="-m 512 -p 16KiB -s 256" Image/BuildKernel/Profile/BTHOMEHUBV3A=$(call Image/BuildKernel/Template,BTHOMEHUBV3A) Image/Build/Profile/BTHOMEHUBV3A=$(call Image/BuildNAND/$(1),$(1),BTHOMEHUBV3A) @@ -627,8 +582,8 @@ endif ifeq ($(SUBTARGET),xrx200) # VR9 -P2812HNUF1_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096" -P2812HNUF1_UBI_OPTS:="-m 2048 -p 128KiB -s 512" +DEVICE_P2812HNUF1_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096" +DEVICE_P2812HNUF1_UBI_OPTS:="-m 2048 -p 128KiB -s 512" Image/BuildKernel/Profile/P2812HNUF1=$(call Image/BuildKernel/Template,P2812HNUF1) Image/Build/Profile/P2812HNUF1=$(call Image/BuildNAND/$(1),$(1),P2812HNUF1) @@ -639,8 +594,8 @@ define LegacyDevice/P2812HNUF1 endef LEGACY_DEVICES += P2812HNUF1 -P2812HNUF3_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096" -P2812HNUF3_UBI_OPTS:="-m 2048 -p 128KiB -s 512" +DEVICE_P2812HNUF3_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096" +DEVICE_P2812HNUF3_UBI_OPTS:="-m 2048 -p 128KiB -s 512" Image/BuildKernel/Profile/P2812HNUF3=$(call Image/BuildKernel/Template,P2812HNUF3) Image/Build/Profile/P2812HNUF3=$(call Image/BuildNAND/
[LEDE-DEV] [PATCH] lantiq: diag - switch off the power led on failsafe
This patch is a follow up to commit 4cf3fd4 "add support for indicating
the boot state using three leds".
At the time of writing the patch, I wasn't aware that it's possible to
switch info failsafe after boot (factory reset).
Enabling the failsafe led without disabling the running led causes an
unexpected led colour on devices using a single multicolour led to
indicate the boot state.
Signed-off-by: Mathias Kresin
---
target/linux/lantiq/base-files/etc/diag.sh | 4
1 file changed, 4 insertions(+)
diff --git a/target/linux/lantiq/base-files/etc/diag.sh
b/target/linux/lantiq/base-files/etc/diag.sh
index 71d6f3e..f6363b3 100644
--- a/target/linux/lantiq/base-files/etc/diag.sh
+++ b/target/linux/lantiq/base-files/etc/diag.sh
@@ -17,6 +17,10 @@ set_state() {
;;
failsafe)
status_led_off
+ [ -n "$running" ] && {
+ status_led="$running"
+ status_led_off
+ }
status_led="$failsafe"
status_led_blink_failsafe
;;
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] lantiq: BTHOMEHUBV5A - use the power event code for the restart button
The restart event code is used in LEDE to trigger a factory reset on
long press as well.
By using the power event code, the restart functionality can be used
without being prone to trigger a factory reset.
Signed-off-by: Mathias Kresin
---
target/linux/lantiq/dts/BTHOMEHUBV5A.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
index e62a18d..2013b31 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
@@ -158,7 +158,7 @@
restart {
label = "restart";
gpios = <&gpio 39 1>;
- linux,code = <0x198>;
+ linux,code = <0x74>;
};
};
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Me prioritizing work on automated bug report data collection
Hi, I'm thinking since I'll be having limited time to LEDE for a while that once we know what we're doing for bug report system that I should prioritize the LuCI and command line bug report info tool (to maximize usefulness of bug reports) and that's probably the most useful thing I can work on in the short term for the project as a whole. Does that make sense? In the meantime I'm compile testing the ACL patch for the two kernels I can run an image on, as well as retesting fully on ar71xx, because it's something just about read to go that I said I'd work on. I also intend to respect Felix's working on the multi profile things and get at least ar71xx converted completely. (Other archs except x86 where it doesn't really apply, I can't actually test so I'm not sure much sense it makes for me to work on them). Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt
On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote: > On Thu, Jun 16, 2016 at 4:03 AM, David Lang wrote: > > With Imagebuilder and things pre-compiled, what does it take to create an > > image? I'm wondering if this is something that can be converted to a web UI > > where we could have someone select stuff (or upload a config file) and have > > the system spit out a custom tailored image a few seconds later. > > > > Something like this could do wonders to move people away from the 'base > > image must contain what I need' mentality. > Personally, I would like that (and wouldn't have a problem with > waiting a half hour or an hour for a build to be done). > For example, I don't need PPOE support on any of the hardware I use, > many of the devices don't have a USB port, so I don't need USB > support, its internal on an IPV4 network, so I don't need IPV6 > support, it would be nice to have Nano installed by default (hard to > use vi over ssh from a phone that doesn't have an escape key :D). > But that's just the perspective of a end user/sysadmin who has been > using OpenWrt (and now LEDE) for 7-10 years. TBH I think the biggest reasons this hasn't already is: 1) People who want it don't care enough to work on it, or are the people who don't know how to work it and and can't/don't fund someone who does. 2) Infrastructure: You need a server to host on and storage etc, and this costs money or donations. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt
Hi David, Thanks for the good info on wear levelling; apparently I was misinformed on the topic. On Thu, 2016-06-16 at 01:03 -0700, David Lang wrote: [snip] > >>> To a certain extent though, I question the need for something as > >>> restricted as OpenWrt > >>> for the new bigger devices anyway; there are elements like netifd that > >>> would be good to > >>> see continue, but I'm not sure that most of OpenWrt really makes as much > >>> sense when you're > >>> not needing to squeeze maximum use out of very erase block, and that > >>> therefore, while it > >>> may be a smaller market/mindshare, that focussing on the the true > >>> embedded type scenario, > >>> seems to be more of what LEDE's niche is. > >> > >> LEDE/OpenWRT is a good fit for any device that operates on raw flash > >> instead of > >> a hard drive or ssd with wear leveling. Once you have storage that you > >> don't > >> worry about wearing out and is large enough to hold a normal Linux Distro, > >> it > > > > makes sense to move to such a distro and update packages individually. > > > > Hmmm...the wear levelling thing is confusing. I was told by someone who I > > thought knew > > what they were talking about, that flash chips included some form of > > hardware-based > > wear levelling built in already. Apparently that is was inaccurate > > (hardware-level > > support is something I only having minor knowledge of; it's not the part > > the interests me, > > nor where I have worked on it for any length of time; I'm more interested > > in what you can > > do with existing hardware support combined with software rather developing > > the core support > > itself). > > raw flash chips like we have in a router have nothing. > > flash chips packaged in SD cards, USB drives, etc commonly have very > primitive > wear leveling (in many cases only targeted at the places that the FAT > filesystem > is going to use) > > flash chips packaged into SSD drives or anything more sophisticated tend to > have > very extensive wear leveling setups, and will move existing, unmodified data > if > needed to balance things. > > I haven't looked recently, but a couple years ago the idea of having an > in-kernel flash wear leveling capability was getting a lot of discussion on > the > kernel mailing list. I din't remember seeing what finally happened with that. > > For the very tiny devices, it doesn't make sense to try and make use of > something like that (it takes more space ond isn't going to apply to a > static, > pre-build compressed filesystem) > > But for the overlay filesystem where new stuff may get added on newer devices > that have the much larger NAND flash, it may be something to look into, even > though it complicates the base config for such systems. > Okay, I understand a lot better where you are coming from now, since I was under a misapprehension about the capabilities of the hardware. In this case I agree we need to do some work to support these bigger devices including things like wear-levelling, and that this is definitely a space in which LEDE can be relevant going forward. Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt
On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote: On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote: On Thu, Jun 16, 2016 at 4:03 AM, David Lang wrote: With Imagebuilder and things pre-compiled, what does it take to create an image? I'm wondering if this is something that can be converted to a web UI where we could have someone select stuff (or upload a config file) and have the system spit out a custom tailored image a few seconds later. Something like this could do wonders to move people away from the 'base image must contain what I need' mentality. Personally, I would like that (and wouldn't have a problem with waiting a half hour or an hour for a build to be done). For example, I don't need PPOE support on any of the hardware I use, many of the devices don't have a USB port, so I don't need USB support, its internal on an IPV4 network, so I don't need IPV6 support, it would be nice to have Nano installed by default (hard to use vi over ssh from a phone that doesn't have an escape key :D). But that's just the perspective of a end user/sysadmin who has been using OpenWrt (and now LEDE) for 7-10 years. TBH I think the biggest reasons this hasn't already is: 1) People who want it don't care enough to work on it, or are the people who don't know how to work it and and can't/don't fund someone who does. 2) Infrastructure: You need a server to host on and storage etc, and this costs money or donations. or don't know how to contribute funds to make something like this work. the LEDE home page under the "how can I help" talks about development and the mailing list. I says nothing about how to contribute money or equipment. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] looking for ar7 testers
On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote: > Is there a list of hardware that is needed? (or do you want donations of > money > for the project to buy hardware)? TBH I'm not sure how useful random hardware donations are. For example getting a router which is more than just updating image generation specifics (and assuming there is even enough information available via flash browsing etc to do that, which isn't always the case), there is the problem most chips manufacturers don't talk to random developer X, and only want to give data sheets and programming information to people who sign an NDA and have a support contract, presumably with contracts to by X units from ODM who is actually the one making the information available, or enabling the request). Dealing with unsupported hardware is not something developers can often do something about simply by having random device X. If it's just image generation usually it can be figured out, but beyond that it normally requires some level of information that isn't easy to discover simply by having a device. Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
On Thu, 2016-06-16 at 02:50 -0500, L. D. Pinney wrote: > From the OP > > I wanted to ask folks whether they want me to continue to cross post to these > Quite frankly I think it's great that companies are stepping up and contributing back - I think the lack of that is a frustration that more than just I have experienced. The reality is that if it benefits the community there is not reason to not accept corporate input, and in fact getting paid work to help the project is essentially and the main way that happens in open source is if companies feel inspired to contribute back to the project because it benefits them. The linux kernel would not be where it is today (in a lot of good ways) without paid corporate input. In case you have failed to notice these statistics, the vast majority of work done on open source projects *as a whole* is not by unpaid volunteers such as myself (who have limited time to devote to such pursuits) but by people who have corporate sponsorship to do the work. I don't know about you, but I have to work to pay for the things my family needs, and unless you're *lucky* that work typically doesn't involve an ideal world chance to work on open source projects without any concerns about IP etc from management. You seem to be even more hostile than I sometimes get (and now have implemented a solution so I "don't post impulsively"). I've arranged it so I make myself think before I post and I think most folks will agree that is a good thing. Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
On Wed, 2016-06-15 at 16:55 -0700, Dave Taht wrote: > On Wed, Jun 15, 2016 at 3:22 PM, L. D. Pinney wrote: > > It's a Development List ... no place for corporate agendas. > > I think you are making a good point here, being that there is only one > lede list, presently, and devs would like to just see dev related > traffic > > Personally I find it incredibly difficult to sort through the patch > volume on this (and linux-wireless), and would welcome a forum (web or > email) to be able to discuss other matters. I was invited several Silly question, but when you're interested in topics other than patches, wouldn't a simple filter that shoves [PATCH] subjects in another folder mitigate the majority of this? Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt
On Sun, 2016-06-19 at 12:35 -0700, David Lang wrote: > On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote: > > > On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote: > >> On Thu, Jun 16, 2016 at 4:03 AM, David Lang wrote: > >>> With Imagebuilder and things pre-compiled, what does it take to create an > >>> image? I'm wondering if this is something that can be converted to a web > >>> UI > >>> where we could have someone select stuff (or upload a config file) and > >>> have > >>> the system spit out a custom tailored image a few seconds later. > >>> > >>> Something like this could do wonders to move people away from the 'base > >>> image must contain what I need' mentality. > >> Personally, I would like that (and wouldn't have a problem with > >> waiting a half hour or an hour for a build to be done). > >> For example, I don't need PPOE support on any of the hardware I use, > >> many of the devices don't have a USB port, so I don't need USB > >> support, its internal on an IPV4 network, so I don't need IPV6 > >> support, it would be nice to have Nano installed by default (hard to > >> use vi over ssh from a phone that doesn't have an escape key :D). > >> But that's just the perspective of a end user/sysadmin who has been > >> using OpenWrt (and now LEDE) for 7-10 years. > > > > TBH I think the biggest reasons this hasn't already is: > > > > 1) People who want it don't care enough to work on it, or are the people > > who don't know how to work it and and can't/don't fund someone who does. > > 2) Infrastructure: You need a server to host on and storage etc, and > > this costs money or donations. > > or don't know how to contribute funds to make something like this work. That's what I meant by can't (and I agree that having some means of hooking up community funders with community developers would be helpfu; kind of like prpl but for community). > > the LEDE home page under the "how can I help" talks about development and the > mailing list. I says nothing about how to contribute money or equipment. > > David Lang > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt
On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote: On Sun, 2016-06-19 at 12:35 -0700, David Lang wrote: On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote: On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote: On Thu, Jun 16, 2016 at 4:03 AM, David Lang wrote: With Imagebuilder and things pre-compiled, what does it take to create an image? I'm wondering if this is something that can be converted to a web UI where we could have someone select stuff (or upload a config file) and have the system spit out a custom tailored image a few seconds later. Something like this could do wonders to move people away from the 'base image must contain what I need' mentality. Personally, I would like that (and wouldn't have a problem with waiting a half hour or an hour for a build to be done). For example, I don't need PPOE support on any of the hardware I use, many of the devices don't have a USB port, so I don't need USB support, its internal on an IPV4 network, so I don't need IPV6 support, it would be nice to have Nano installed by default (hard to use vi over ssh from a phone that doesn't have an escape key :D). But that's just the perspective of a end user/sysadmin who has been using OpenWrt (and now LEDE) for 7-10 years. TBH I think the biggest reasons this hasn't already is: 1) People who want it don't care enough to work on it, or are the people who don't know how to work it and and can't/don't fund someone who does. 2) Infrastructure: You need a server to host on and storage etc, and this costs money or donations. or don't know how to contribute funds to make something like this work. That's what I meant by can't (and I agree that having some means of hooking up community funders with community developers would be helpfu; kind of like prpl but for community). I was calling out the difference between "I don't have money to contribute" and "I have money I could send, but I don't know who to give it to" The first is something the project can't do anything about, the second will cost some effort (setting up the ability to receive donations and policies/processes to use the donations), but properly done (assuming people are willing to send money/equipment) could be a net win for the project. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] looking for ar7 testers
On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote: On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote: Is there a list of hardware that is needed? (or do you want donations of money for the project to buy hardware)? TBH I'm not sure how useful random hardware donations are. For example getting a router which is more than just updating image generation specifics (and assuming there is even enough information available via flash browsing etc to do that, which isn't always the case), there is the problem most chips manufacturers don't talk to random developer X, and only want to give data sheets and programming information to people who sign an NDA and have a support contract, presumably with contracts to by X units from ODM who is actually the one making the information available, or enabling the request). Dealing with unsupported hardware is not something developers can often do something about simply by having random device X. If it's just image generation usually it can be figured out, but beyond that it normally requires some level of information that isn't easy to discover simply by having a device. Well, I'll point out that the thread I'm replying to started off with "I no longer have the hardware to test this" I agree that random, unsolicited donations are likely to be less useful, but donations of hardware to solve the "I can't test this" or add to a test farm are directly useful. And getting a new piece of equipment can get a developer interested enough to go after the NDAs needed to make it work well. In some cases the vendors involved are known to 'not play well with others' and so donations of their hardware will do no good. But those of us out in the wild can't tell the difference between the different categories. That's why I asked for a list of what would be useful to donate :-) David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
Hi, Mathias Kresin
On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin wrote:
> So far the network in failsafe is setup only for one board. Use the
> eth0 interface as lan interface for all boards for now.
>
> If a board has its lan interface(s) on another eth, a special
> handling based on the board name can be added.
>
> Signed-off-by: Mathias Kresin
> ---
> .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq | 10
> +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git
> a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
> b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
> index 3d7fabf..7ed0fab 100644
> --- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
> +++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
> @@ -3,15 +3,7 @@
> . /lib/functions/lantiq.sh
>
> set_preinit_iface() {
> -
> - board=$(lantiq_board_name)
> -
> - case "$board" in
> - TDW8970)
> - ifname=eth0
> - ;;
> - esac
> -
> + ifname=eth0
What about to add a default branch in case statement?
*)
ifname=eth0
;;
> }
>
> boot_hook_add preinit_main set_preinit_iface
> --
> 1.9.1
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] looking for ar7 testers
On 20/06/2016 02:51, David Lang wrote: > On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote: > >> On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote: >>> Is there a list of hardware that is needed? (or do you want donations >>> of money >>> for the project to buy hardware)? >> >> TBH I'm not sure how useful random hardware donations are. For example >> getting a router which is more than just updating image generation >> specifics (and assuming there is even enough information available via >> flash browsing etc to do that, which isn't always the case), there is >> the problem most chips manufacturers don't talk to random developer X, >> and only want to give data sheets and programming information to people >> who sign an NDA and have a support contract, presumably with contracts >> to by X units from ODM who is actually the one making the information >> available, or enabling the request). >> >> Dealing with unsupported hardware is not something developers can often >> do something about simply by having random device X. If it's just image >> generation usually it can be figured out, but beyond that it normally >> requires some level of information that isn't easy to discover simply by >> having a device. > > Well, I'll point out that the thread I'm replying to started off with "I > no longer have the hardware to test this" > > I agree that random, unsolicited donations are likely to be less useful, > but donations of hardware to solve the "I can't test this" or add to a > test farm are directly useful. > > And getting a new piece of equipment can get a developer interested > enough to go after the NDAs needed to make it work well. > > In some cases the vendors involved are known to 'not play well with > others' and so donations of their hardware will do no good. > > But those of us out in the wild can't tell the difference between the > different categories. > > That's why I asked for a list of what would be useful to donate :-) > > David Lang how is this related to "i am looking for ar7 maintainers and testers" ? please try to stay on topic ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
On 20/06/2016 05:15, Zhao, Gang wrote:
> Hi, Mathias Kresin
>
> On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin wrote:
>> So far the network in failsafe is setup only for one board. Use the
>> eth0 interface as lan interface for all boards for now.
>>
>> If a board has its lan interface(s) on another eth, a special
>> handling based on the board name can be added.
>>
>> Signed-off-by: Mathias Kresin
>> ---
>> .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq | 10
>> +-
>> 1 file changed, 1 insertion(+), 9 deletions(-)
>>
>> diff --git
>> a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> index 3d7fabf..7ed0fab 100644
>> --- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> +++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> @@ -3,15 +3,7 @@
>> . /lib/functions/lantiq.sh
>>
>> set_preinit_iface() {
>> -
>> - board=$(lantiq_board_name)
>> -
>> - case "$board" in
>> - TDW8970)
>> - ifname=eth0
>> - ;;
>> - esac
>> -
>> + ifname=eth0
>
> What about to add a default branch in case statement?
>
> *)
> ifname=eth0
> ;;
>
i am wondering if we should add a switch default config here or simply
reset the switch with vlans turned off
John
>> }
>>
>> boot_hook_add preinit_main set_preinit_iface
>> --
>> 1.9.1
>>
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] uloop: handle waker pipe write() return value
Recent glibc warns if result of read() or write() is unused.
Added a retry in case of EINTR, all other faults are silently discarded.
Signed-off-by: Eyal Birger
-
- I was not able to reproduce the EINTR case, but it seems to be the right
thing to do
- Retrying on EAGAIN in this case would be weird as there is no one to read
from the other end of the pipe. We could call waker_consume() directly but
since the size of the message is just one byte, I think this would be dead
code
---
uloop.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/uloop.c b/uloop.c
index e60fb09..fd315c0 100644
--- a/uloop.c
+++ b/uloop.c
@@ -386,7 +386,13 @@ static void uloop_handle_processes(void)
static void uloop_signal_wake(void)
{
- write(waker_pipe, "w", 1);
+ do {
+ if (write(waker_pipe, "w", 1) < 0) {
+ if (errno == EINTR)
+ continue;
+ }
+ break;
+ } while (1);
}
static void uloop_handle_sigint(int signo)
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
Am 20.06.2016 um 07:19 schrieb John Crispin:
On 20/06/2016 05:15, Zhao, Gang wrote:
Hi, Mathias Kresin
On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin wrote:
So far the network in failsafe is setup only for one board. Use the
eth0 interface as lan interface for all boards for now.
If a board has its lan interface(s) on another eth, a special
handling based on the board name can be added.
Signed-off-by: Mathias Kresin
---
.../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git
a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
index 3d7fabf..7ed0fab 100644
--- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
+++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
@@ -3,15 +3,7 @@
. /lib/functions/lantiq.sh
set_preinit_iface() {
-
- board=$(lantiq_board_name)
-
- case "$board" in
- TDW8970)
- ifname=eth0
- ;;
- esac
-
+ ifname=eth0
What about to add a default branch in case statement?
*)
ifname=eth0
;;
i am wondering if we should add a switch default config here or simply
reset the switch with vlans turned off
Is it really necessary? I mean the failsafe kicks in long before the
network config and vlan setup is done.
I've tested this with a board using the xrx200 in-SoC switch and a board
using a RTL8306G switch. In both cases it wasn't necessary to turn off
the vlans since they had not yet been configured.
Mathias
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
On 20/06/2016 07:39, Mathias Kresin wrote:
> Am 20.06.2016 um 07:19 schrieb John Crispin:
>>
>>
>> On 20/06/2016 05:15, Zhao, Gang wrote:
>>> Hi, Mathias Kresin
>>>
>>> On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin wrote:
So far the network in failsafe is setup only for one board. Use the
eth0 interface as lan interface for all boards for now.
If a board has its lan interface(s) on another eth, a special
handling based on the board name can be added.
Signed-off-by: Mathias Kresin
---
.../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq |
10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git
a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
index 3d7fabf..7ed0fab 100644
---
a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
+++
b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
@@ -3,15 +3,7 @@
. /lib/functions/lantiq.sh
set_preinit_iface() {
-
- board=$(lantiq_board_name)
-
- case "$board" in
- TDW8970)
- ifname=eth0
- ;;
- esac
-
+ ifname=eth0
>>>
>>> What about to add a default branch in case statement?
>>>
>>> *)
>>> ifname=eth0
>>> ;;
>>>
>>
>> i am wondering if we should add a switch default config here or simply
>> reset the switch with vlans turned off
>
> Is it really necessary? I mean the failsafe kicks in long before the
> network config and vlan setup is done.
>
> I've tested this with a board using the xrx200 in-SoC switch and a board
> using a RTL8306G switch. In both cases it wasn't necessary to turn off
> the vlans since they had not yet been configured.
>
> Mathias
>
this code also runs on danubes with rtl and ar8327 switches. some of
which have a default vlan setup provided by the bootloader
John
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
Am 20.06.2016 um 05:15 schrieb Zhao, Gang:
Hi, Mathias Kresin
On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin wrote:
So far the network in failsafe is setup only for one board. Use the
eth0 interface as lan interface for all boards for now.
If a board has its lan interface(s) on another eth, a special
handling based on the board name can be added.
Signed-off-by: Mathias Kresin
---
.../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git
a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
index 3d7fabf..7ed0fab 100644
--- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
+++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
@@ -3,15 +3,7 @@
. /lib/functions/lantiq.sh
set_preinit_iface() {
-
- board=$(lantiq_board_name)
-
- case "$board" in
- TDW8970)
- ifname=eth0
- ;;
- esac
-
+ ifname=eth0
What about to add a default branch in case statement?
*)
ifname=eth0
;;
Adding a default branch doesn't make any sense to me as long as the only
value set in the default branch is the same as the one in the only
conditional.
I had changed the case statement to only consists of a default case, to
make obvious how to add a different config for a specific board. But in
the end I dropped the whole case since it was just unused code.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
Am 20.06.2016 um 07:40 schrieb John Crispin:
On 20/06/2016 07:39, Mathias Kresin wrote:
Am 20.06.2016 um 07:19 schrieb John Crispin:
On 20/06/2016 05:15, Zhao, Gang wrote:
Hi, Mathias Kresin
On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin wrote:
So far the network in failsafe is setup only for one board. Use the
eth0 interface as lan interface for all boards for now.
If a board has its lan interface(s) on another eth, a special
handling based on the board name can be added.
Signed-off-by: Mathias Kresin
---
.../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq |
10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git
a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
index 3d7fabf..7ed0fab 100644
---
a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
+++
b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
@@ -3,15 +3,7 @@
. /lib/functions/lantiq.sh
set_preinit_iface() {
-
- board=$(lantiq_board_name)
-
- case "$board" in
- TDW8970)
- ifname=eth0
- ;;
- esac
-
+ ifname=eth0
What about to add a default branch in case statement?
*)
ifname=eth0
;;
i am wondering if we should add a switch default config here or simply
reset the switch with vlans turned off
Is it really necessary? I mean the failsafe kicks in long before the
network config and vlan setup is done.
I've tested this with a board using the xrx200 in-SoC switch and a board
using a RTL8306G switch. In both cases it wasn't necessary to turn off
the vlans since they had not yet been configured.
Mathias
this code also runs on danubes with rtl and ar8327 switches. some of
which have a default vlan setup provided by the bootloader
John
Indeed, for these boards a reset of the vlan config, depending on the
particular bootloader vlan config, might be necessary.
But I don't like the idea of adding a default switch config for boards
where it isn't strictly required. Especially in a failsafe script. The
more code we add, the more likely is a breakage or an unconsidered
side-effect of a change.
Since I don't have any of the affected danube boards, adding support for
this special case to the patch is out of scope for me. I don't like to
add untested code.
Mathias
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
