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 P
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 http://lists.infradead.org/pipe
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 - https://pwassi.privatedns.o
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 (simil
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 ha
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 --git a/target/linux/kirkwood/base-fi
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: proper
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 allow
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 --git a/target/linux/x86/modu
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 imx6 here:
https://patchwork.ozla
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 sup
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 xx-mmcblk0p4-kernel.
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
a/target/linux/generic/patches-4.4/477-mtd
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
--- a/package/boot/uboot-envtools/files/ipq
+++ b/package/boo
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, 106 insertions(+)
creat
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 a/package/base-files/files/lib/upgrade/
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 xx-mmcblk0p5-rootfs
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 co
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 +++
> .../linux/ipq806x/base-files/lib/upgrade/zyxel.sh | 94
>
On 23 October 2016 at 12:15, wrote:
> 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 WL
* 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
http://lists.infradead.org/mailman/listinfo/lede-dev
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.. ede
___
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 error message might contain '
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 ' /overlay ' /proc/mounts 2>/dev/null )"
Hi,
Several months after the split it looks like things have pretty much
ended up where they were before the split. It's starting to look like
the talk of encouraging new blood, and being more open and transparent
was more talk than real intention. As much as I've gotten busy with
personal issue
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
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 vulnerab
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
> 4.4.26
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 grep?
> Maybe use -
* Chris Blake [24.10.2016 07:47]:
> Alexis is correct, it's to ensure any chance of a random error is
> suppressed. 2> /dev/null was just added as a protection.
i will explain why this makes no sense:
grep will complain if e.g. the file '/proc/mounts' does not exist,
otherwise it output the line
From: Paul Wassi
Minor fix in the usage message on the explanation of the -p option.
Signed-off-by: Paul Wassi
---
system/mtd/src/mtd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/system/mtd/src/mtd.c b/package/system/mtd/src/mtd.c
--- a/package/system/mtd/sr
On 10/24/2016 12:58 AM, Daniel Dickinson wrote:
> Hi,
>
> Several months after the split it looks like things have pretty much
> ended up where they were before the split. It's starting to look like
> the talk of encouraging new blood, and being more open and transparent
> was more talk than rea
On 10/24/2016 12:58 AM, Daniel Dickinson wrote:
> Hi,
>
> Several months after the split it looks like things have pretty much
> ended up where they were before the split. It's starting to look like
> the talk of encouraging new blood, and being more open and transparent
> was more talk than rea
33 matches
Mail list logo
