Re: [LEDE-DEV] [PATCH v4] base-files: Ensure reset only works if an overlay exists

Hello, Alexis is correct, it's to ensure any chance of a random error is suppressed. 2> /dev/null was just added as a protection. Regards, Chris Blake On Sun, Oct 23, 2016 at 4:46 PM, Alexis Green wrote: > I’m guessing it’s because there might some random error message from

Re: [LEDE-DEV] DirtyCOW backport

On 24-10-16 03:10, Stijn Tintel wrote: > On 24-10-16 02:37, James Feeney wrote: >> What are thoughts about backporting the DirtyCOW patch to the Lede kernels? >> I >> did not see any mention in the Lede-dev Archives. >> > Most targets use kernel 4.4. As the 4.4 kernel has been updated to >

Re: [LEDE-DEV] DirtyCOW backport

On 24-10-16 02:37, James Feeney wrote: > What are thoughts about backporting the DirtyCOW patch to the Lede kernels? I > did not see any mention in the Lede-dev Archives. > Most targets use kernel 4.4. As the 4.4 kernel has been updated to 4.4.26 on Friday [0], these targets are no longer

[LEDE-DEV] DirtyCOW backport

What are thoughts about backporting the DirtyCOW patch to the Lede kernels? I did not see any mention in the Lede-dev Archives. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v4] base-files: Ensure reset only works if an overlay exists

I’m guessing it’s because there might some random error message from grep? Maybe use -s option for grep instead to suppress error messages? > On Oct 23, 2016, at 12:30 PM, Bastian Bittorf wrote: > > * Chris Blake [23.10.2016 21:10]: >> +OVERLAY="$( grep '

Re: [LEDE-DEV] [PATCH v4] base-files: Ensure reset only works if an overlay exists

On 23.10.2016 23:42, edgar.sol...@web.de wrote: > On 23.10.2016 21:30, Bastian Bittorf wrote: >> * Chris Blake [23.10.2016 21:10]: >>> +OVERLAY="$( grep ' /overlay ' /proc/mounts 2>/dev/null )" >> >> whats the reason for the 2>...? >> > > for the corner case that the

Re: [LEDE-DEV] [PATCH v4] base-files: Ensure reset only works if an overlay exists

On 23.10.2016 21:30, Bastian Bittorf wrote: > * Chris Blake [23.10.2016 21:10]: >> +OVERLAY="$( grep ' /overlay ' /proc/mounts 2>/dev/null )" > > whats the reason for the 2>...? > for the corner case that the error message might contain ' /overlay' ? just a guess..

Re: [LEDE-DEV] [PATCH v4] base-files: Ensure reset only works if an overlay exists

* Chris Blake [23.10.2016 21:10]: > +OVERLAY="$( grep ' /overlay ' /proc/mounts 2>/dev/null )" whats the reason for the 2>...? bye, bastian ___ Lede-dev mailing list Lede-dev@lists.infradead.org

Re: [LEDE-DEV] [PATCH v3 3/5] ipq806x/nbg6817: add sysupgrade support

On 2016-10-23 16:25, André Valentin wrote: > Add new way of flashing to mmc devices based on rootfs split with loop > devices. > > Signed-off-by: André Valentin > --- > .../ipq806x/base-files/lib/upgrade/platform.sh | 12 +++ >

Re: [LEDE-DEV] [PATCH v3 1/5] ipq806x/nbg6817: add support for ZyXEL NBG6817

On 2016-10-23 16:38, Felix Fietkau wrote: > On 2016-10-23 16:25, André Valentin wrote: >> CPU: 2x1.8GHz ARM, RAM: 512MiB >> Storage: 4MiB serial Flash, 3.9GiB MMC >> NIC: 2x1GBit/s, Switch with 5 external and 2 internal ports >> WiFi: Dualband, ath10k 2.4GHz, 5GHz MU-MIMO >> >> For installation

Re: [LEDE-DEV] [PATCH v3 1/5] ipq806x/nbg6817: add support for ZyXEL NBG6817

On 2016-10-23 16:25, André Valentin wrote: > CPU: 2x1.8GHz ARM, RAM: 512MiB > Storage: 4MiB serial Flash, 3.9GiB MMC > NIC: 2x1GBit/s, Switch with 5 external and 2 internal ports > WiFi: Dualband, ath10k 2.4GHz, 5GHz MU-MIMO > > For installation copy xx-mmcblk0p4-kernel.bin and

[LEDE-DEV] [PATCH v3 4/5] package/basefiles: add mkfs.ext4 and losetup binaries to ramfs list

mkfs.ext4 und losetup are needed for sysupgrade support on mmc devices with automatic rootfs split (loopback device usage). Signed-off-by: André Valentin --- package/base-files/files/lib/upgrade/common.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git

[LEDE-DEV] [PATCH v3 3/5] ipq806x/nbg6817: add sysupgrade support

Add new way of flashing to mmc devices based on rootfs split with loop devices. Signed-off-by: André Valentin --- .../ipq806x/base-files/lib/upgrade/platform.sh | 12 +++ .../linux/ipq806x/base-files/lib/upgrade/zyxel.sh | 94 ++ 2 files changed,

[LEDE-DEV] [PATCH v3 1/5] ipq806x/nbg6817: add support for ZyXEL NBG6817

CPU: 2x1.8GHz ARM, RAM: 512MiB Storage: 4MiB serial Flash, 3.9GiB MMC NIC: 2x1GBit/s, Switch with 5 external and 2 internal ports WiFi: Dualband, ath10k 2.4GHz, 5GHz MU-MIMO For installation copy xx-mmcblk0p4-kernel.bin and xx-mmcblk0p5-rootfs-full.bin to device. Then run: cat

[LEDE-DEV] [PATCH v3 2/5] linux/mtd: add id for mx25u3235f needed by ZyXEL NBG6817

Signed-off-by: André Valentin --- .../patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch diff --git

[LEDE-DEV] [PATCH v3 5/5] package/uboot-envtools: Add support for ZyXEL NBG6817

Signed-off-by: André Valentin --- package/boot/uboot-envtools/files/ipq | 3 +++ 1 file changed, 3 insertions(+) diff --git a/package/boot/uboot-envtools/files/ipq b/package/boot/uboot-envtools/files/ipq index 8cf0ddb..369f90f 100755 ---

[LEDE-DEV] [PATCH v3 0/5] ipq806x/nbg6817: add support for ZyXEL NBG6817

Support for NBG6817 comes with several challenges: -enable mmc support on platform -use fstools rootfs split on block devices ( creates a loop dev with offset ) -extend sysupgrade support to format the loop fs and save config Please comment changes. André Valentin (5): ipq806x/nbg6817: add

[LEDE-DEV] [PATCH] kirkwood: Add RTC driver to kernel for working hctosys

From: Paul Wassi Build the RTC driver into the kernel, (and remove the optional module), in order to make hctosys working. (Currently the module is loaded after hctosys has failed previously) Signed-off-by: Paul Wassi --- It's the same on kirkwood, as it is on

Re: [LEDE-DEV] [RFC 3/6 v2] x86: Add sp5100_tco as a kernel module

On 2016-10-22 19:39, Chris Blake wrote: > This patch enables the kernel sp5100_tco watchdog driver to be built as > a kernel module. > > Signed-off-by: Chris Blake > --- > target/linux/x86/modules.mk | 15 +++ > 1 file changed, 15 insertions(+) > > diff

Re: [LEDE-DEV] [RFC 2/6 v2] x86: Add LED & GPIO drivers for the PC Engines APU2 board

On 2016-10-22 19:39, Chris Blake wrote: > This patch adds the following drivers to the x86 target: > > leds-apu2 - A driver that enables usage of the onboard LEDs and Reset > button wired to the chipset. This driver uses DMI to only enable on the > APU2 board. > gpio-nct5104d - A driver that

Re: [LEDE-DEV] [RFC 1/6 v2] Generic: Backport sp5100_tco patches for AMD platforms

On 2016-10-22 19:39, Chris Blake wrote: > This patch adds the following upstream patches to the 4.4 kernel: > > sp5100_tco: Add AMD Mullins platform support > sp5100_tco: Add AMD Carrizo platform support > sp5100_tco: fix the device check for SB800 and later chipsets > watchdog: sp5100_tco:

[LEDE-DEV] [PATCH] kirkwood: remove redundant code in etc/board.d/02_network

From: Paul Wassi Remove redundant code: merge boards/cases that share the same network configuration. Signed-off-by: Paul Wassi --- linux/kirkwood/base-files/etc/board.d/02_network | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff

[LEDE-DEV] [PATCH v4] base-files: Ensure reset only works if an overlay exists

Currently the reset script will try to run jffs2reset on boards that are running a rw rootfs, such as ext4. This will cause jffs2reset to fail and the board to never reboot while the LED blinks until a manual reboot. This commit does two different things: 1. Disables reset on boards that do not

Re: [LEDE-DEV] [PATCH] kirkwood: disable fault LEDs by default

Hi Mathias, > status:orange:fault is on after boot because it is used as status_led. Ah, I see. However, after changing the default value to '0' it is off after boot (althoug set as status_led !) > What do you think about using the status:green:health led instead as > status_led in diag.sh

[LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

Hi there! As one of LEDE's TODOs is "Bump all kernels to v4.4", I've done some testing on two brcm47xx devices (brcm47xx is still on kernel 4.1). The devices I tested on + bootlog: Linksys WRT54GL - https://pwassi.privatedns.org/lede/brcm47xx/#wrt54gl ASUS WL500gP V2 -

Re: [LEDE-DEV] [RFC 4/6 v2] Generic: Crypto - aesni - add ccm(aes) algorithm implementation

Christian, Thanks for the information. This patch will be removed from the next RFC. - Chris Blake On Sat, Oct 22, 2016 at 2:12 PM, Christian Lamparter wrote: > On Saturday, October 22, 2016 12:39:26 PM CEST Chris Blake wrote: >> This patch was provided by Ben at

Re: [LEDE-DEV] [RFC 0/6 v2] Add the PC Engines APU2 to LEDE

Hello, In regards to the usb-serial-kmod decision, this goes back to the issue in the coverletter around what should be considered "acceptable" for this image or not. If we are going for full functionality, then we could add every package available to the image. The goal is to support things the

Re: [LEDE-DEV] regulatory domain information

on 2016-10-19 Charles wrote: > Questions: > > 1. Why does LEDE show four regulatory domain blocks while OpenWrt shows >only one? > > 2. What does the "country US: DFS-FCC" blocks tell me when radio is set >to an ETSI region country (DE) according to uci? > > 3. What does AUTO-BW mean?