[LEDE-DEV] curl --capath not supported on mbedtls but was supported on polarssl
Hi everyone, I hit something that seems like a regression to me. In a little program named openwisp-config [1], we are using the --capath argument, when switching - as was widely suggested - from polarssl to mbedtls, we noticed curl cannot use the capath argument. There's also a thread in the forum here: https://forum.lede-project.org/t/capath-not-supported-by-libcurl-with-mbedtls-support/947/8 I would like to ask 2 questions 1. is it's desired behaviour or a regression? 2. what's an alternative way to tell curl and or wget to find certificates? Thx in advance Federico [1] https://github.com/openwisp/openwisp-config ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ramips: Improve Sanlinking D240 config
* The left most mini-PCIe (USB) slot (the one attached to SIM2) can be
power-cycled by setting GPIO 0 to high/low. I have no strong opinion on the
name, but since the slot can be used for other things than modems I went for
usb2.
* The D240 only needs the MT76x2 module, so update makefile to reflect this.
Note that until the default mt7620 target is updated, then kmod-mt76 (and thus
kmod-mt7603) will be selected by default.
Signed-off-by: Kristian Evensen
---
target/linux/ramips/dts/D240.dts| 14 ++
target/linux/ramips/image/mt7620.mk | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
index ef45d38..4abf7f5 100644
--- a/target/linux/ramips/dts/D240.dts
+++ b/target/linux/ramips/dts/D240.dts
@@ -46,6 +46,20 @@
bootargs = "console=ttyS0,115200";
};
+ gpio-export {
+ compatible = "gpio-export";
+ #size-cells = <0>;
+ /*
+* The modem ("usb port") connected with the SIM2 slot can be
power
+* controlled by setting gpio 0 to high/low.
+*/
+ usb2 {
+ gpio-export,name = "usb2";
+ gpio-export,output = ;
+ gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
gpio-leds {
compatible = "gpio-leds";
diff --git a/target/linux/ramips/image/mt7620.mk
b/target/linux/ramips/image/mt7620.mk
index 4a76ab3..0410a9a 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -471,6 +471,6 @@ define Device/d240
DTS := D240
IMAGE_SIZE := $(ralink_default_fw_size_16M)
DEVICE_TITLE := Sanlinking Technologies D240
- DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76 kmod-sdhci-mt7620
+ DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76-core kmod-mt76x2
kmod-sdhci-mt7620
endef
TARGET_DEVICES += d240
--
2.9.3
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE - Telnet Client
Hi Carlo, Please read this thread on the LEDE forum: https://forum.lede-project.org/t/where-is-a-telnet-client/361/6 To quote hnyman: "Previously telnet client was part of the busybox multi-utility, but when the "telnet server" was disabled in 2015 and ssh was set to be the only login method, also the "telnet client" capability was removed. If you want to have telnet client easily available, compiling a firmware that has modified busybox options so that telnet is again in busybox is maybe the easiest option.". Regards, Bart On Thu, Mar 2, 2017 at 8:36 AM, Carlo wrote: > Hi, > I was using OpenWrt as remote "swiss army knife" with the embedded telnet > client. I'm usual to get access via SSH to the remote OpenWRT box and from > there use the telnet client for router/switch configuration, for mail/http > session simulation/troubleshooting etc . > Now I'm starting using LEDE, but it seems that the telnet client has been > removed from busybox. > > If I search the package list i see only this programs: > > mac-telnet-client > mac-telnet-discover > mac-telnet-ping > mac-telnet-server > openocd > perl-net-telnet > ruby-net-telnet > ser2net > > I don't want to recompile the sources to re-include telnet client, since I > prefer to keep the OS as standard as possible, to use it an all the > supported hardware. > I was wondering if the dev-team can consider to re-introduce the telnet > client in the OS or consider to make available a stand-alone pkg telnet > clien. > > Regards > Carlo > > ___ > 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] LEDE - Telnet Client
On Thu, Mar 2, 2017 at 8:36 AM, Carlo wrote: > I don't want to recompile the sources to re-include telnet client, since I > prefer to keep the OS as standard as possible, to use it an all the > supported hardware. There is netcat (nc) in the default image. Should be able to do most of what telnet does? regards ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ramips: Improve Sanlinking D240 config
Hi Kristian, 2017-03-02 11:55 GMT+01:00 Kristian Evensen : > * The left most mini-PCIe (USB) slot (the one attached to SIM2) can be > power-cycled by setting GPIO 0 to high/low. I have no strong opinion on the > name, but since the slot can be used for other things than modems I went for > usb2. [...] What about "power_mpcieX" (or something similar), where X is 1 or 2, depending on what is printed on the PCB (I wasn't able to find hi-res photo)? Take a look at other examples: grep -rn "gpio-export.*power" target/linux/ramips/dts/ target/linux/ramips/dts/HC5861.dts:43:gpio-export,name = "usbpower"; target/linux/ramips/dts/HC5861.dts:49:gpio-export,name = "sdpower"; target/linux/ramips/dts/PBR-M1.dts:78:gpio-export,name = "power_usb2"; target/linux/ramips/dts/PBR-M1.dts:84:gpio-export,name = "power_usb3"; target/linux/ramips/dts/PBR-M1.dts:90:gpio-export,name = "power_sata"; target/linux/ramips/dts/WNDR3700V5.dts:63:gpio-export,name = "usbpower"; target/linux/ramips/dts/TINY-AC.dts:49:gpio-export,name = "usbpower"; target/linux/ramips/dts/ArcherMR200.dts:92:gpio-export,name = "power_usb1"; target/linux/ramips/dts/HC5XXX.dtsi:28:gpio-export,name = "usbpower"; target/linux/ramips/dts/Newifi-D1.dts:56:gpio-export,name = "usb2power"; target/linux/ramips/dts/Newifi-D1.dts:62:gpio-export,name = "usb3power"; --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ramips: Improve Sanlinking D240 config
Hi, On Thu, Mar 2, 2017 at 12:39 PM, Piotr Dymacz wrote: > What about "power_mpcieX" (or something similar), where X is 1 or 2, > depending on what is printed on the PCB (I wasn't able to find hi-res > photo)? Good idea and thanks for the pointer. There does not seem to be any easy-to-find value or id printed on the PCB. However, in some material I was sent from Sanlinking then the slot that can be power-cycled is referred to as mini PCIe 2, so I will rename the slot to power_mpcie_2 and send a v2. -Kristian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ramips: Improve Sanlinking D240 config
Hi Kristian, 2017-03-02 12:46 GMT+01:00 Kristian Evensen : > Hi, > > On Thu, Mar 2, 2017 at 12:39 PM, Piotr Dymacz wrote: >> What about "power_mpcieX" (or something similar), where X is 1 or 2, >> depending on what is printed on the PCB (I wasn't able to find hi-res >> photo)? > > Good idea and thanks for the pointer. There does not seem to be any > easy-to-find value or id printed on the PCB. However, in some material > I was sent from Sanlinking then the slot that can be power-cycled is > referred to as mini PCIe 2, so I will rename the slot to power_mpcie_2 > and send a v2. OK, I think you can also drop the comment with new gpio name. --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Q: bad longshot: iw dev wlanX station dump - what is: "rx drop misc:"
I have a bad performing "longshot" (~10 meters): both sides with recent LEDE, one 1043ND and one WDR4300 on 2.4GHz. The link performs bad, although the values seem OK: # iw dev wlan0 station dump (on 1043ND) Station 64:70:02:d3:24:0b (on wlan0) inactive time: 0 ms rx bytes: 1856328043 rx packets: 3090925 tx bytes: 1529873286 tx packets: 2423239 tx retries: 433117 tx failed: 809 rx drop misc: 28492 signal: -60 [-67, -63, -66] dBm signal avg: -59 [-66, -62, -65] dBm tx bitrate: 117.0 MBit/s MCS 14 rx bitrate: 130.0 MBit/s MCS 15 expected throughput:42.388Mbps authorized: yes authenticated: yes associated: yes preamble: long WMM/WME:yes MFP:no TDLS peer: no DTIM period:0 beacon interval:1000 connected time: 229269 seconds # iw dev wlan0 station dump (on WDR4300) Station f4:ec:38:9d:81:82 (on wlan0) inactive time: 150 ms rx bytes: 113057100 rx packets: 318848 tx bytes: 172204259 tx packets: 248059 tx retries: 25208 tx failed: 322 rx drop misc: 892 signal: -57 [-60, -60] dBm signal avg: -52 [-58, -56] dBm tx bitrate: 130.0 MBit/s MCS 15 rx bitrate: 104.0 MBit/s MCS 13 expected throughput:44.677Mbps authorized: yes authenticated: yes associated: yes preamble: long WMM/WME:yes MFP:no TDLS peer: no DTIM period:0 beacon interval:1000 connected time: 31557 seconds Both sides have set on 2.4GHz with channel 14: wireless.radio0.chanbw=5 wireless.radio0.txpower=20 The question: what is "rx drop misc"? I have a packetloss of ~20%. Any idea why that? bye, bastian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v2] ramips: Improve Sanlinking D240 config
* The left most mini-PCIe slot (the one attached to SIM2) can be
power-cycled by setting GPIO 0 to high/low.
* The D240 only needs the MT76x2 module, so update makefile to reflect this.
Note that until the default mt7620 target is updated, then kmod-mt76 (and thus
kmod-mt7603) will be selected by default.
v1->v2:
* Rename gpio and remove redundant comment (thanks Piotr Dymacz)
Signed-off-by: Kristian Evensen
---
target/linux/ramips/dts/D240.dts| 11 +++
target/linux/ramips/image/mt7620.mk | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
index ef45d38..dbf061c 100644
--- a/target/linux/ramips/dts/D240.dts
+++ b/target/linux/ramips/dts/D240.dts
@@ -46,6 +46,17 @@
bootargs = "console=ttyS0,115200";
};
+ gpio-export {
+ compatible = "gpio-export";
+ #size-cells = <0>;
+
+power_mpcie2 {
+ gpio-export,name = "power_mpcie2";
+ gpio-export,output = ;
+ gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
gpio-leds {
compatible = "gpio-leds";
diff --git a/target/linux/ramips/image/mt7620.mk
b/target/linux/ramips/image/mt7620.mk
index 4a76ab3..0410a9a 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -471,6 +471,6 @@ define Device/d240
DTS := D240
IMAGE_SIZE := $(ralink_default_fw_size_16M)
DEVICE_TITLE := Sanlinking Technologies D240
- DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76 kmod-sdhci-mt7620
+ DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76-core kmod-mt76x2
kmod-sdhci-mt7620
endef
TARGET_DEVICES += d240
--
2.9.3
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] ramips: Improve Sanlinking D240 config
On Thu, Mar 2, 2017 at 1:37 PM, Kristian Evensen
wrote:
>
> + gpio-export {
> + compatible = "gpio-export";
> + #size-cells = <0>;
> +
> +power_mpcie2 {
> + gpio-export,name = "power_mpcie2";
[..]
Missed this indentation error, will send a v3.
-Kristian
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v3] ramips: Improve Sanlinking D240 config
* The left most mini-PCIe slot (the one attached to SIM2) can be
power-cycled by setting GPIO 0 to high/low.
* The D240 only needs the MT76x2 module, so update makefile to reflect this.
Note that until the default mt7620 target is updated, then kmod-mt76 (and thus
kmod-mt7603) will be selected by default.
v2->v3:
* Indentation error.
v1->v2:
* Rename gpio and remove redundant comment (thanks Piotr Dymacz)
Signed-off-by: Kristian Evensen
---
target/linux/ramips/dts/D240.dts| 11 +++
target/linux/ramips/image/mt7620.mk | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
index ef45d38..46d0141 100644
--- a/target/linux/ramips/dts/D240.dts
+++ b/target/linux/ramips/dts/D240.dts
@@ -46,6 +46,17 @@
bootargs = "console=ttyS0,115200";
};
+ gpio-export {
+ compatible = "gpio-export";
+ #size-cells = <0>;
+
+ power_mpcie2 {
+ gpio-export,name = "power_mpcie2";
+ gpio-export,output = ;
+ gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
gpio-leds {
compatible = "gpio-leds";
diff --git a/target/linux/ramips/image/mt7620.mk
b/target/linux/ramips/image/mt7620.mk
index 4a76ab3..0410a9a 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -471,6 +471,6 @@ define Device/d240
DTS := D240
IMAGE_SIZE := $(ralink_default_fw_size_16M)
DEVICE_TITLE := Sanlinking Technologies D240
- DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76 kmod-sdhci-mt7620
+ DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76-core kmod-mt76x2
kmod-sdhci-mt7620
endef
TARGET_DEVICES += d240
--
2.9.3
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] brcm63xx: Setup BCM6318 pinmux to make the switch LEDs work
Add BCM6318 to GPIO_MODE internal switch port leds setup.
As with BCM6368 the pinmux for the switch LEDs in BCM6318
is also lost when LEDE initializes the peripherals. Fix it.
Signed-off-by: Daniel Gonzalez Cabanelas
---
...rcm63xx-setup-pinctrl-for-internal-switch-leds-on-b.patch | 12
.../patches-4.4/403-6358-enet1-external-mii-clk.patch| 2 +-
...13-BCM63XX-allow-providing-fixup-data-in-board-data.patch | 4 ++--
.../418-MIPS-BCM63XX-pass-caldata-info-to-flash.patch| 2 +-
.../patches-4.4/420-BCM63XX-add-endian-check-for-ath9k.patch | 2 +-
.../patches-4.4/421-BCM63XX-add-led-pin-for-ath9k.patch | 2 +-
.../422-BCM63XX-add-a-fixup-for-rt2x00-devices.patch | 2 +-
7 files changed, 15 insertions(+), 11 deletions(-)
diff --git
a/target/linux/brcm63xx/patches-4.4/382-brcm63xx-setup-pinctrl-for-internal-switch-leds-on-b.patch
b/target/linux/brcm63xx/patches-4.4/382-brcm63xx-setup-pinctrl-for-internal-switch-leds-on-b.patch
index 83e1ddc..b89c8d1 100644
---
a/target/linux/brcm63xx/patches-4.4/382-brcm63xx-setup-pinctrl-for-internal-switch-leds-on-b.patch
+++
b/target/linux/brcm63xx/patches-4.4/382-brcm63xx-setup-pinctrl-for-internal-switch-leds-on-b.patch
@@ -9,16 +9,20 @@ Subject: [PATCH] brcm63xx: setup pinctrl for internal switch
leds on bcm6368
--- a/arch/mips/bcm63xx/boards/board_common.c
+++ b/arch/mips/bcm63xx/boards/board_common.c
-@@ -104,6 +104,15 @@ void __init board_early_setup(const stru
+@@ -104,6 +104,19 @@ void __init board_early_setup(const stru
GPIO_MODE_6348_G0_EXT_MII;
}
-+ if (BCMCPU_IS_6368() && board.has_enetsw) {
++ if ((BCMCPU_IS_6368() || (BCMCPU_IS_6318())) && board.has_enetsw) {
+ int i;
+
+ for (i = 0; i < 4; i++) {
-+ if (board.enetsw.used_ports[i].used)
-+ val |= (GPIO_MODE_6368_EPHY0_LED << i);
++ if (board.enetsw.used_ports[i].used) {
++ if (BCMCPU_IS_6368())
++ val |= (GPIO_MODE_6368_EPHY0_LED << i);
++ else if (BCMCPU_IS_6318())
++ val |= BIT(i+4);
++ }
+ }
+ }
+
diff --git
a/target/linux/brcm63xx/patches-4.4/403-6358-enet1-external-mii-clk.patch
b/target/linux/brcm63xx/patches-4.4/403-6358-enet1-external-mii-clk.patch
index 206fc3f..43215a6 100644
--- a/target/linux/brcm63xx/patches-4.4/403-6358-enet1-external-mii-clk.patch
+++ b/target/linux/brcm63xx/patches-4.4/403-6358-enet1-external-mii-clk.patch
@@ -8,7 +8,7 @@
+ val |= GPIO_MODE_6358_ENET1_MII_CLK_INV;
}
- if (BCMCPU_IS_6368() && board.has_enetsw) {
+ if ((BCMCPU_IS_6368() || (BCMCPU_IS_6318())) && board.has_enetsw) {
--- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h
+++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h
@@ -651,6 +651,8 @@
diff --git
a/target/linux/brcm63xx/patches-4.4/413-BCM63XX-allow-providing-fixup-data-in-board-data.patch
b/target/linux/brcm63xx/patches-4.4/413-BCM63XX-allow-providing-fixup-data-in-board-data.patch
index b02ab44..bd8a915 100644
---
a/target/linux/brcm63xx/patches-4.4/413-BCM63XX-allow-providing-fixup-data-in-board-data.patch
+++
b/target/linux/brcm63xx/patches-4.4/413-BCM63XX-allow-providing-fixup-data-in-board-data.patch
@@ -18,7 +18,7 @@ Subject: [PATCH 58/72] BCM63XX: allow providing fixup data in
board data
#include "board_common.h"
-@@ -191,6 +192,7 @@ static struct of_device_id of_ids[] = {
+@@ -195,6 +196,7 @@ static struct of_device_id of_ids[] = {
int __init board_register_devices(void)
{
int usbh_ports = 0;
@@ -26,7 +26,7 @@ Subject: [PATCH 58/72] BCM63XX: allow providing fixup data in
board data
#if CONFIG_OF
if (of_have_populated_dt()) {
-@@ -271,6 +273,10 @@ int __init board_register_devices(void)
+@@ -275,6 +277,10 @@ int __init board_register_devices(void)
board.ephy_reset_gpio_flags);
}
diff --git
a/target/linux/brcm63xx/patches-4.4/418-MIPS-BCM63XX-pass-caldata-info-to-flash.patch
b/target/linux/brcm63xx/patches-4.4/418-MIPS-BCM63XX-pass-caldata-info-to-flash.patch
index ccdcefd..ac07eb0 100644
---
a/target/linux/brcm63xx/patches-4.4/418-MIPS-BCM63XX-pass-caldata-info-to-flash.patch
+++
b/target/linux/brcm63xx/patches-4.4/418-MIPS-BCM63XX-pass-caldata-info-to-flash.patch
@@ -11,7 +11,7 @@ Subject: [PATCH 69/80] MIPS: BCM63XX: pass caldata info to
flash
--- a/arch/mips/bcm63xx/boards/board_common.c
+++ b/arch/mips/bcm63xx/boards/board_common.c
-@@ -261,7 +261,7 @@ int __init board_register_devices(void)
+@@ -265,7 +265,7 @@ int __init board_register_devices(void)
if (board.num_spis)
spi_register_board_info(board.spis, board.num_spis);
diff --git
a/target/linux/brcm63xx/patches-4.4/420-BCM63XX-add-e
[LEDE-DEV] Github's new TOS
Hi! For your consideration: Please have a look at https://joeyh.name/blog/entry/removing_everything_from_github/ This is not very surprising -- if power gets too concentrated it's only a matter of time to see it being abused. Hopefully we can pull stuff out there without implicitely acknowledging the new terms by doing that. I wonder how big player (torvald/linux.git and such) are going to react to this. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Github's new TOS
On 03/02/2017 12:02 PM, Daniel Golle wrote: > Hi! > > For your consideration: Please have a look at > https://joeyh.name/blog/entry/removing_everything_from_github/ > > This is not very surprising -- if power gets too concentrated it's > only a matter of time to see it being abused. Hopefully we can pull > stuff out there without implicitely acknowledging the new terms by > doing that. > I wonder how big player (torvald/linux.git and such) are going to > react to this. > > > Cheers > > > Daniel As another datapoint, I asked Richard Fontana, current Redhat lawyer and co-drafter of the GPL3, and he referred to analysis in the article as "basically wrong"[1]. So it seems unclear whether this has a negative effect or not. Eric Schultz [1]: https://twitter.com/richardfontana/status/837370085392199681 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Github's new TOS
On 03/02/2017 07:02 PM, Daniel Golle wrote: > Hi! > > For your consideration: Please have a look at > https://joeyh.name/blog/entry/removing_everything_from_github/ > > This is not very surprising -- if power gets too concentrated it's > only a matter of time to see it being abused. Hopefully we can pull > stuff out there without implicitely acknowledging the new terms by > doing that. > I wonder how big player (torvald/linux.git and such) are going to > react to this. > > > Cheers > > > Daniel > tl;dr I'm not seeing anything evil in Github TOS, those articles look quite suspicious. An excerpt of the TOS https://help.github.com/articles/github-terms-of-service/#d-user-generated-content 5. License Grant to Other Users ... If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality. You may grant further rights if you adopt a license. (link to https://help.github.com/articles/adding-a-license-to-a-repository/#including-an-open-source-license-in-your-repository ) -- This part above says that whatever you upload in a public repo is legally viewable and reproducible by anyone as long as it stays on Github (so the "reproducible" means "forkable in another Github repo"), if you add a (opensource) license you can grant more rights to others. I'm not seeing how that breaks copyleft licenses. and this is the part about Moral Rights (also discussed in the articles cited in your mail) --- 7. Moral Rights You retain all moral rights to Content you upload, publish, or submit to any part of the Service, including the rights of integrity and attribution. However, you waive these rights and agree not to assert them against us, to enable us to reasonably exercise the rights granted in Section D.4, but not otherwise. You understand that you will not receive any payment for any of the rights granted in this Section. To the extent such an agreement is not enforceable by applicable law, you grant GitHub a nonexclusive, revocable, worldwide, royalty-free right to (1) use the Content without attribution strictly as necessary to render the Website and provide the Service; and (2) make reasonable adaptations of the Content as provided in this Section. We need these rights to allow basic functions like search to work. --- Please note the "REVOCABLE", and the "strictly as necessary to render the Website and provide the Service" and the "reasonable adaptations of the Content as provided in this Section" which is probably connected to --- 4. License Grant to Us Your Content belongs to you, and you are responsible for Content you post even if it does not belong to you. However, we need the legal right to do things like host it, publish it, and share it. You grant us and our legal successors the right to store and display your Content and make incidental copies as necessary to render the Website and provide the Service. That means you're giving us the right to do things like reproduce your content (so we can do things like copy it to our database and make backups); display it (so we can do things like show it to you and other users); modify it (so our server can do things like parse it into a search index); distribute it (so we can do things like share it with other users); and perform it (in case your content is something like music or video). This license does not grant GitHub the right to sell your Content or otherwise distribute it outside of our Service. --- Again I'm not seeing anything evil. I tend to see any accusatory article as highly suspicious unless they quote fully the bad parts of the documents they use as proof of wrongdoings, and neither of those you cited does. I might be spoiled brat, but that rule of thumb has never let me down. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
Thanks Sebastian, turned out to be a silly syntax error, I have it all disabled now. Ethtool -k and ethtool -K printing/requiring different stuff doesn't help of course :-) I re-enabled SQM, will see how that works out with the offloading disabled. Cheers Stijn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
On 3/2/17 11:51 AM, Stijn Segers wrote: > Thanks Sebastian, turned out to be a silly syntax error, I have it all > disabled now. Ethtool -k and ethtool -K printing/requiring different > stuff doesn't help of course :-) > > I re-enabled SQM, will see how that works out with the offloading disabled. Would be good to know. I lost a bit of sleep lately (given how badly we got bit by RCU on the ATF front, I worry about cake... but I can't see how that would break, there.) In terms of general "why does shaping use so much cpu"... I am keen to stress that the core fq_codel algorithm is very lightweight and barely shows up on traces when used without software rate limiting and with BQL. You CAN see a difference in forwarding performance at really high native rates if you use pfifo and compare it to fq_codel on some platforms - pfifo-fast is simpler overall. To experiment, you can re-enable pfifo-fast in scenarios if you want - (tc qdisc add dev whatever pfifo limit somethingsane, or bfifo something sane) ... however things like nat and firewall rules tend to dominate the forwarding costs, and fq_codel reduces latency muchly over pfifo), and the principal use of fq_codel is for sqm (and now wifi). As for software rate shaping - this is very cpu intensive no matter how you do it. I wish we didn't have to do it - and with certain (mostly old DSL) modems that do flow control you don't. The only one I know that gets this right is the transverse geode that david woodhouse has. One of my disappointments across the industry is not seeing BQL roll out universally on any dsl firmwares, starting, oh, 5 years ago. If we had ethernet devices with a programmable timer (only interrupt me on 40mbit rate) we could also completely eliminate software rate shaping anyway my benchmarks are showing that: cake in it's "besteffort" mode smokes HTB + fq_codel, affording over 40% more headroom in terms of cpu with bandwidth. (Independent confirmation across more cpu types is need) In the default mode, with the new 3 tier classification, wash, nat and triple-isolate/dual-host/dual-src features - which we hope are going to help folk deal with torrent better in particular - it's a wash. cake is a LOT more cpu intense than fq_codel is, especially in its default modes, which it makes up for by being more unified. Mostly. If you are running low on cpu and are trying to shape inbound on most of these low-end mips devices to speeds > 60Mbits, I'd highly recommend switching to using "besteffort" on that rather than the 3 QoS queue default. Most ISPs are not classifying traffic well, anyway, and FQ solves nearly everything, especially per host fq But none of what I just said applies if there's a bug somewhere else! GRO has given me fits for years now, and I'm scarred by that. In terms of cpu costs in cake/fq_codel - dequeue, hashing, and timestamping show up most on a trace. The rate limiting effort where all that is happening shows up in softirq dominating the platform. I have *always* worried that there exists devices (particularly multi-cores) without a first class high speed internal clock facility, but thus far haven't had an issue with it (unlike on BSD, which has internal timings good to only a ms). As for speeding up hashing, I've been looking over various algorithms to do that for years now, I'm open to suggestions. The fastest new ones tend to depend on co-processor support. The fastest I've seen relies on the CRC32 instruction which is only in some intel platforms. Cake could certainly use a big round of profiling but it is generally my hope that we won big with it, in its present form. I welcome (especially flent) benchmarks of sqm on various architectures we've not explored fully - notably arm ones - My hat is off to all that have worked so hard to make this subsystem - and also all of lede - work so well, in this release. > Cheers > > Stijn > > > ___ > 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] brcm47xx: Add switch topology for Asus WL-500W
The four LAN ports are connected to switch ports 0..3 in sequence,
switch port 4 is not used, and switch port 5 is connected to the CPU.
The WAN port is not connected to the switch, but to another CPU interface.
Signed-off-by: Mirko Parthey
---
target/linux/brcm47xx/base-files/etc/board.d/01_detect | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/brcm47xx/base-files/etc/board.d/01_detect
b/target/linux/brcm47xx/base-files/etc/board.d/01_detect
index 357cc7f22432..5db479b6502c 100755
--- a/target/linux/brcm47xx/base-files/etc/board.d/01_detect
+++ b/target/linux/brcm47xx/base-files/etc/board.d/01_detect
@@ -139,7 +139,6 @@ detect_by_model() {
;;
"Asus WL500G" | \
- "Asus WL500W" | \
"Microsoft MN-700")
ucidef_set_interfaces_lan_wan "eth0" "eth1"
;;
@@ -157,6 +156,7 @@ detect_by_model() {
"0:wan" "1:lan" "2:lan" "3:lan" "4:lan" "5@eth0"
;;
+ "Asus WL500W" | \
"Dell TrueMobile 2300")
ucidef_set_interface_wan "eth1"
ucidef_add_switch "switch0" \
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Github's new TOS
Hi Alberto, Hi Eric, thank you for getting into this. I'm quite the oposite of a legal expert, so this might all just as well be rather meaningless FUD. On Thu, Mar 02, 2017 at 07:26:02PM +, Alberto Bursi wrote: > ... > Again I'm not seeing anything evil. > > I tend to see any accusatory article as highly suspicious unless they > quote fully the bad parts of the documents they use as proof of > wrongdoings, and neither of those you cited does. I might be spoiled > brat, but that rule of thumb has never let me down. Sounds very reasonable to me. From what I understood that was all about partial quotes which show up as part of search-results and the github website without the attribution required or full-text license next to it. In a way that sounded like an excuse, because they could just embed the required text-blocks into the site and display them on-mouse-over of the SPDX tag, which would technically speaking make that change in their usage terms unnessecary, thus I got suspicous. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Github's new TOS
On Thu, 2 Mar 2017, Daniel Golle wrote: Sounds very reasonable to me. From what I understood that was all about partial quotes which show up as part of search-results and the github website without the attribution required or full-text license next to it. In a way that sounded like an excuse, because they could just embed the required text-blocks into the site and display them on-mouse-over of the SPDX tag, which would technically speaking make that change in their usage terms unnessecary, thus I got suspicous. haivng to send a large chunk of license data for each snippet in a search result would greatly multiply the size of the downloaded page, not nice to users. This change seems reasonable to me. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Github's new TOS
On Thu, Mar 02, 2017 at 02:18:45PM -0800, David Lang wrote: > On Thu, 2 Mar 2017, Daniel Golle wrote: > > > Sounds very reasonable to me. From what I understood that was all > > about partial quotes which show up as part of search-results and the > > github website without the attribution required or full-text license > > next to it. In a way that sounded like an excuse, because they could > > just embed the required text-blocks into the site and display them > > on-mouse-over of the SPDX tag, which would technically speaking make > > that change in their usage terms unnessecary, thus I got suspicous. > > haivng to send a large chunk of license data for each snippet in a search > result would greatly multiply the size of the downloaded page, not nice to > users. > > This change seems reasonable to me. Sure does. The article kinda claimed that github would then also implicetely have the right to relicense code to 3rd parties under BSD-like terms with that change, but I guess we can safely assume that this is not the case and the grant to github for 'basic services like search to function' is really only for that purpose and it cannot be transfered to 3rd parties. > > David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
On Thu, Mar 2, 2017 at 4:10 PM, Dave Täht wrote: > As for speeding up hashing, I've been looking over various algorithms to > do that for years now, I'm open to suggestions. The fastest new ones > tend to depend on co-processor support. The fastest I've seen relies on > the CRC32 instruction which is only in some intel platforms. This is an area where I have a fair amount of experience. It is a misconception that CRC is a good hash function. It is good at detecting errors but has poor avalanche performance. What are the requirements for this hashing function? - How much data is being hashed? (I would guess a limited number of bytes rather than an entire packet payload.) - What is the typical number of hash table buckets? Must it be a power of 2? Or are you willing to make it a prime number? Assuming you can afford a 1KB lookup table I would suggest the SBox hash in figure four of this article: http://papa.bretmulvey.com/post/124028832958/hash-functions The virtue of a prime number of buckets is that when you mod your 32-bit hash value to get a bucket index you harvest _all_ of the entropy in the hash, not just the entropy in the bits you preserve. /john ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
> On 3 Mar, 2017, at 01:16, John Yates wrote: > > What are the requirements for this hashing function? > - How much data is being hashed? I am guessing a limited number of bytes > rather than an entire packet payload. Generally it’s what we call the “5-tuple”: two addresses (which could be IPv4, IPv6, or potentially Ethernet MAC), two port numbers (16 bits each), and a transport protocol ID (1 byte). In Cake, the hash function is by default run three times, in order to get separate hashes over just the source address and just the destination address, as well as the full 5-tuple. These are necessary to operate the triple-isolate algorithm. There may be an opportunity for optimisation by producing all three hashes in parallel. > - What is the typical number of hash table buckets? Is it prime or a power > of 2? It’s a power of two, yes. The actual number of buckets is 1024, but Cake uses the full 32-bit hash as a “tag” for hash collision detection without having to store and compare the entire 5-tuple. - Jonathan Morton ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
> On 3 Mar, 2017, at 01:55, John Yates wrote: > > The virtue of a prime number of buckets is that when you mod > your 32-bit hash value to get a bucket index you harvest _all_ > of the entropy in the hash, not just the entropy in the bits you > preserve. True, but you incur the cost of a division, which is very much non-trivial on ARM CPUs, which are increasingly common in CPE. - Jonathan Morton ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH][buildbot] phase1: rename gpg signature files .gpg -> .asc
gnupg doesn't recognize .gpg files by it's extension.
> gpg --verify sha256sums.gpg
>> gpg: no signed data
>> gpg: can't hash datafile: No data
Signed-off-by: Alexander Couzens
---
phase1/signall.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/phase1/signall.sh b/phase1/signall.sh
index d256131..2160bdc 100755
--- a/phase1/signall.sh
+++ b/phase1/signall.sh
@@ -27,7 +27,7 @@ find "$tmpdir/" -type f -not -name "*.gpg" -exec gpg \
${comment:+--comment="$comment"} \
${GNUPGHOME:+--homedir "$GNUPGHOME"} \
${PASSFILE:+--passphrase-file "$PASSFILE"} \
- -o "{}.gpg" "{}" \; || finish 4
+ -o "{}.asc" "{}" \; || finish 4
tar -C "$tmpdir/" -czf "$tarball" . || finish 5
--
2.11.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] brcm2708-gpu-fw: update to latest version
Signed-off-by: Stijn Tintel --- package/kernel/brcm2708-gpu-fw/Makefile | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/package/kernel/brcm2708-gpu-fw/Makefile b/package/kernel/brcm2708-gpu-fw/Makefile index 2a5a043..7e80530 100644 --- a/package/kernel/brcm2708-gpu-fw/Makefile +++ b/package/kernel/brcm2708-gpu-fw/Makefile @@ -9,8 +9,8 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=brcm2708-gpu-fw -PKG_VERSION:=2017-02-05 -PKG_RELEASE:=eba0fa58add5aa548d18ae436d2f0be93cdfbbe3 +PKG_VERSION:=2017-03-02 +PKG_RELEASE:=f5446ba0b3bbd4241bf0ad35a2c9f299f5c447d5 PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/$(PKG_NAME)/rpi-firmware-$(PKG_RELEASE) @@ -33,7 +33,7 @@ define Download/bootcode_bin FILE:=$(RPI_FIRMWARE_FILE)-bootcode.bin URL:=$(RPI_FIRMWARE_URL) URL_FILE:=bootcode.bin - HASH:=e68fafc606a1e8ee6ccd4cbc5d9c7ca3b322c37bf65389a2ea011eb59cc96bbd + HASH:=d990031baec20fe2cd5e24d9f3d6fc34891afdb128838d010d9a0249ae29ea6b endef $(eval $(call Download,bootcode_bin)) @@ -41,7 +41,7 @@ define Download/fixup_dat FILE:=$(RPI_FIRMWARE_FILE)-fixup.dat URL:=$(RPI_FIRMWARE_URL) URL_FILE:=fixup.dat - HASH:=4032c5de826ca3bc6294b2da713849486c290d83553895e1162cd2a7309861e8 + HASH:=38b69384f62bc7b64f17dcedc03c5582af6b4f8dfc25fe5904d4eb3181a3387b endef $(eval $(call Download,fixup_dat)) @@ -49,7 +49,7 @@ define Download/fixup_cd_dat FILE:=$(RPI_FIRMWARE_FILE)-fixup_cd.dat URL:=$(RPI_FIRMWARE_URL) URL_FILE:=fixup_cd.dat - HASH:=b3b6983fd781cfc4b6fc0ba3d7f7242d7fef66fa6a27faf817572faf3165e02a + HASH:=05c682ffcc74cd1356f1b9a32a7034763bfea94e5cb54eaaa2e69affc1cd33d7 endef $(eval $(call Download,fixup_cd_dat)) @@ -57,7 +57,7 @@ define Download/start_elf FILE:=$(RPI_FIRMWARE_FILE)-start.elf URL:=$(RPI_FIRMWARE_URL) URL_FILE:=start.elf - HASH:=18717d43450e75926c929058ace530f76520a9dcc603d5c5953d08138c73a2c0 + HASH:=59b9d26b463a84f017fae186493bb54e642de6c7e0376b3cbe3375df6132edc0 endef $(eval $(call Download,start_elf)) @@ -65,7 +65,7 @@ define Download/start_cd_elf FILE:=$(RPI_FIRMWARE_FILE)-start_cd.elf URL:=$(RPI_FIRMWARE_URL) URL_FILE:=start_cd.elf - HASH:=d4d09b015b0376b37b22c108c01095a1c35ff1943e227a3f428edc57ed26670f + HASH:=fb9aea03eb6790062c100166444bf7d2b8a6cea605bd041f905fcacefacbbae2 endef $(eval $(call Download,start_cd_elf)) -- 2.10.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] brcm2708: add Raspberry Zero W support
Signed-off-by: Stijn Tintel
---
.../brcm2708/base-files/etc/board.d/02_network | 3 +
target/linux/brcm2708/base-files/etc/diag.sh | 3 +-
target/linux/brcm2708/base-files/lib/brcm2708.sh | 3 +
target/linux/brcm2708/image/Makefile | 7 +-
.../0152-BCM270X_DT-Add-bcm2708-rpi-0-w.dts.patch | 233 +
5 files changed, 247 insertions(+), 2 deletions(-)
create mode 100644
target/linux/brcm2708/patches-4.9/0152-BCM270X_DT-Add-bcm2708-rpi-0-w.dts.patch
diff --git a/target/linux/brcm2708/base-files/etc/board.d/02_network
b/target/linux/brcm2708/base-files/etc/board.d/02_network
index 7642c06..0679c24 100755
--- a/target/linux/brcm2708/base-files/etc/board.d/02_network
+++ b/target/linux/brcm2708/base-files/etc/board.d/02_network
@@ -11,6 +11,9 @@ board_config_update
board=$(brcm2708_board_name)
case "$board" in
+rpi-0-w)
+ ucidef_set_interface_lan "wlan0"
+ ;;
rpi-b |\
rpi-b-plus |\
rpi-2-b |\
diff --git a/target/linux/brcm2708/base-files/etc/diag.sh
b/target/linux/brcm2708/base-files/etc/diag.sh
index 2a866e4..dfcda54 100644
--- a/target/linux/brcm2708/base-files/etc/diag.sh
+++ b/target/linux/brcm2708/base-files/etc/diag.sh
@@ -8,7 +8,8 @@ set_state() {
case "$(brcm2708_board_name)" in
rpi-b |\
rpi-cm |\
- rpi-zero)
+ rpi-zero |\
+ rpi-0-w)
status_led="led0"
;;
rpi-b-plus |\
diff --git a/target/linux/brcm2708/base-files/lib/brcm2708.sh
b/target/linux/brcm2708/base-files/lib/brcm2708.sh
index ab7a23d..156d706 100644
--- a/target/linux/brcm2708/base-files/lib/brcm2708.sh
+++ b/target/linux/brcm2708/base-files/lib/brcm2708.sh
@@ -21,6 +21,9 @@ brcm2708_detect() {
"Raspberry Pi Zero Rev"*)
board_name="rpi-zero"
;;
+ "Raspberry Pi Zero W Rev"*)
+ board_name="rpi-0-w"
+ ;;
"Raspberry Pi 2 Model B Rev"*)
board_name="rpi-2-b"
;;
diff --git a/target/linux/brcm2708/image/Makefile
b/target/linux/brcm2708/image/Makefile
index 0b3f6a7..357bb5e 100644
--- a/target/linux/brcm2708/image/Makefile
+++ b/target/linux/brcm2708/image/Makefile
@@ -58,8 +58,13 @@ define Device/rpi
DEVICE_TITLE := Raspberry Pi B/B+/CM/Zero
DEVICE_DTS := bcm2708-rpi-b bcm2708-rpi-b-plus bcm2708-rpi-cm
endef
+define Device/rpi-0-w
+ DEVICE_TITLE := Raspberry Pi Zero W
+ DEVICE_DTS := bcm2708-rpi-0-w
+ DEVICE_PACKAGES := brcmfmac-firmware-43430-sdio kmod-brcmfmac wpad-mini
+endef
ifeq ($(SUBTARGET),bcm2708)
- TARGET_DEVICES += rpi
+ TARGET_DEVICES += rpi rpi-0-w
endif
define Device/rpi-2
diff --git
a/target/linux/brcm2708/patches-4.9/0152-BCM270X_DT-Add-bcm2708-rpi-0-w.dts.patch
b/target/linux/brcm2708/patches-4.9/0152-BCM270X_DT-Add-bcm2708-rpi-0-w.dts.patch
new file mode 100644
index 000..e1b8af5
--- /dev/null
+++
b/target/linux/brcm2708/patches-4.9/0152-BCM270X_DT-Add-bcm2708-rpi-0-w.dts.patch
@@ -0,0 +1,233 @@
+From 935c7ce84c982a26f567a03a58a1537424569938 Mon Sep 17 00:00:00 2001
+From: Phil Elwell
+Date: Tue, 24 May 2016 16:30:05 +0100
+Subject: [PATCH] BCM270X_DT: Add bcm2708-rpi-0-w.dts
+
+Add DT support for the Pi Zero W. N.B. It will not be loaded
+automatically without a corresponding change to the firmware.
+
+Signed-off-by: Phil Elwell
+---
+ arch/arm/boot/dts/Makefile| 1 +
+ arch/arm/boot/dts/bcm2708-rpi-0-w.dts | 197 ++
+ 2 files changed, 198 insertions(+)
+ create mode 100644 arch/arm/boot/dts/bcm2708-rpi-0-w.dts
+
+diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
+index c697c48..46228af 100644
+--- a/arch/arm/boot/dts/Makefile
b/arch/arm/boot/dts/Makefile
+@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
+ bcm2708-rpi-b.dtb \
+ bcm2708-rpi-b-plus.dtb \
+ bcm2708-rpi-cm.dtb \
++ bcm2708-rpi-0-w.dtb \
+ bcm2709-rpi-2-b.dtb \
+ bcm2710-rpi-3-b.dtb \
+ bcm2710-rpi-cm3.dtb
+diff --git a/arch/arm/boot/dts/bcm2708-rpi-0-w.dts
b/arch/arm/boot/dts/bcm2708-rpi-0-w.dts
+new file mode 100644
+index 000..db0f99d
+--- /dev/null
b/arch/arm/boot/dts/bcm2708-rpi-0-w.dts
+@@ -0,0 +1,197 @@
++/dts-v1/;
++
++#include "bcm2708.dtsi"
++
++/ {
++ model = "Raspberry Pi Zero W";
++};
++
++&gpio {
++ sdhost_pins: sdhost_pins {
++ brcm,pins = <48 49 50 51 52 53>;
++ brcm,function = <4>; /* alt0 */
++ };
++
++ spi0_pins: spi0_pins {
++ brcm,pins = <9 10 11>;
++ brcm,function = <4>; /* alt0 */
++ };
++
++ spi0_cs_pins: spi0_cs_pins {
++ brcm,pins = <8 7>;
++ brcm,function = <1>; /* output */
++ };
++
++ i2c0_pins: i2c0 {
++ brcm,pins = <0 1>;
++ brcm,function = <4>;
++ };
++
++ i2c1_pins: i2c1 {
++ brcm,pins = <2 3>;
++ brcm,function = <4>;
++ };
++
++ i2s_pins:
[LEDE-DEV] [PATCH ubox] kmodloader: modprobe: return 0 for loaded modules
This is the default behaviour with modprobe from kmod package [1] unless
it is explicitly told that the module is to be loaded for --first-time
[1] http://www.kernel.org/pub/linux/utils/kernel/kmod/
Fixes FS#433
Signed-off-by: Yousong Zhou
---
kmodloader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kmodloader.c b/kmodloader.c
index 892ddd8..ed8f833 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -837,7 +837,7 @@ static int main_modprobe(int argc, char **argv)
if (m && m->state == LOADED) {
if (!quiet)
ULOG_ERR("%s is already loaded\n", name);
- return -1;
+ return 0;
} else if (!m) {
if (!quiet)
ULOG_ERR("failed to find a module named %s\n", name);
--
2.6.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
On 03/02/2017 07:02 PM, Jonathan Morton wrote: >> On 3 Mar, 2017, at 01:55, John Yates wrote: >> >> The virtue of a prime number of buckets is that when you mod >> your 32-bit hash value to get a bucket index you harvest _all_ >> of the entropy in the hash, not just the entropy in the bits you >> preserve. > True, but you incur the cost of a division, which is very much non-trivial on > ARM CPUs, which are increasingly common in CPE. > > - Jonathan Morton Also with SQM you may not what idealized entropy in your queue distribution. It is desired by some to have host-connection fairness, and not so much interest in stream-type fairness. So overlap in a few hash "tags" may not be always such a bad thing depending on how it works itself out. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
> On 3 Mar, 2017, at 06:31, Eric Luehrsen wrote: > > Also with SQM you may not what idealized entropy in your queue > distribution. It is desired by some to have host-connection fairness, > and not so much interest in stream-type fairness. So overlap in a few > hash "tags" may not be always such a bad thing depending on how it works > itself out. That sort of thing is explicitly catered for by the triple-isolate algorithm. I don’t want to rely on particular hash behaviour to achieve an inferior result. I’d much rather have a good hash with maximal entropy. - Jonathan Morton ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
On 03/02/2017 11:35 PM, Jonathan Morton wrote: >> On 3 Mar, 2017, at 06:31, Eric Luehrsen wrote: >> >> Also with SQM you may not what idealized entropy in your queue >> distribution. It is desired by some to have host-connection fairness, >> and not so much interest in stream-type fairness. So overlap in a few >> hash "tags" may not be always such a bad thing depending on how it works >> itself out. > That sort of thing is explicitly catered for by the triple-isolate algorithm. > I don’t want to rely on particular hash behaviour to achieve an inferior > result. I’d much rather have a good hash with maximal entropy. > > - Jonathan Morton That's not what I was going for. Agree, it would not be good to depend on an inferior hash. You mentioned divide as a "cost." So I was proposing a thought around a "benefit" estimate. If hash collisions are not as important (or are they), then what is "benefit / cost?" ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
> On 3 Mar, 2017, at 07:00, Eric Luehrsen wrote: > > That's not what I was going for. Agree, it would not be good to depend > on an inferior hash. You mentioned divide as a "cost." So I was > proposing a thought around a "benefit" estimate. If hash collisions are > not as important (or are they), then what is "benefit / cost?" The computational cost of one divide is not the only consideration I have in mind. Cake’s set-associative hash is fundamentally predicated on the number of hash buckets *not* being prime, as it requires further decomposing the hash into a major and minor part when a collision is detected. The minor part is then iterated to try to locate a matching or free bucket. This is considerably easier to do and reason about when everything is a power of two. Then, modulus is a masking operation, and divide is a shift, either of which can be done in one cycle flat. AFAIK, however, the main CPU cost of the hash function in Cake is not the hash itself, but the packet dissection required to obtain the data it operates on. This is something a profile would shed more light on. - Jonathan Morton ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Using kdump... persistent logs, etc.
I built an x86_64 image and turned on crash logging, and then forced a crash with: echo c >/proc/sysrq-trigger it rebooted, but when it did there was nothing in /sys/kernel/debug/ (i.e. no crashlog file). What am I missing? Does this not work with x86_64? -Philip > On Feb 23, 2017, at 10:27 AM, Philip Prindeville > wrote: > > Thanks for that. > > >> On Feb 22, 2017, at 11:44 PM, Syrone Wong wrote: >> >> According to LEDE's source code: >> >> config KERNEL_CRASHLOG >> bool "Crash logging" >> depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) >> default y >> >> https://github.com/lede-project/source/blob/master/config/Config-kernel.in >> >> It is enabled by default on some targets and will be available at >> `/sys/kernel/debug/crashlog` on next boot after crash. >> >> The implementation detail can be found here: >> https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch >> >> >> Best Regards, >> Syrone Wong >> >> >> On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville >> wrote: >>> Hi, >>> >>> Has anyone managed to use kdump with OpenWRT/LEDE? >>> >>> I have a box which periodically panics, and since /var is a link to /tmp/ >>> there are no persistent logs. Which reminds me: is it safe to configure a >>> third partition on my CF card, format it as ext3, and mount that as >>> /var/log in /etc/fstab? >>> >>> And how would I modify the build process if I wanted to add additional >>> partitions? >>> >>> Thanks, >>> >>> -Philip >>> ___ >>> openwrt-devel mailing list >>> openwrt-de...@lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > ___ > 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] Can't build gcc (initial) on Ubuntu 16.04
Hi. I was trying to build LEDE (HEAD) today after rebasing all of my fixes to it (from OpenWRT), but I couldn’t even get gcc to build. This was on Ubuntu 16.04-2 LTS. Is there a dependency that might have creeped in? I’m seeing the following: … Checking multilib configuration for libgcc... mkdir -p -- x86_64-openwrt-linux-musl/libgcc Configuring in x86_64-openwrt-linux-musl/libgcc configure: creating cache ./config.cache checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-openwrt-linux-musl checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking for x86_64-openwrt-linux-musl-ar... /home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/x86_64-openwrt-linux-musl/bin/ar checking for x86_64-openwrt-linux-musl-lipo... x86_64-openwrt-linux-musl-lipo checking for x86_64-openwrt-linux-musl-nm... /home/philipp/bertram/lede/build_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/gcc-5.3.0-initial/./gcc/nm checking for x86_64-openwrt-linux-musl-ranlib... /home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/x86_64-openwrt-linux-musl/bin/ranlib checking for x86_64-openwrt-linux-musl-strip... /home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/x86_64-openwrt-linux-musl/bin/strip checking whether ln -s works... yes checking for x86_64-openwrt-linux-musl-gcc... /home/philipp/bertram/lede/build_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/gcc-5.3.0-initial/./gcc/xgcc -B/home/philipp/bertram/lede/build_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/gcc-5.3.0-initial/./gcc/ -B/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/x86_64-openwrt-linux-musl/bin/ -B/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/x86_64-openwrt-linux-musl/lib/ -isystem /home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/x86_64-openwrt-linux-musl/include -isystem /home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/x86_64-openwrt-linux-musl/sys-include checking for suffix of object files... configure: error: in `/home/philipp/bertram/lede/build_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/gcc-5.3.0-initial/x86_64-openwrt-linux-musl/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. Makefile:10905: recipe for target 'configure-target-libgcc' failed make[4]: *** [configure-target-libgcc] Error 1 make[4]: Leaving directory '/home/philipp/bertram/lede/build_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/gcc-5.3.0-initial' Makefile:36: recipe for target '/home/philipp/bertram/lede/build_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/gcc-5.3.0-initial/.built' failed make[3]: *** [/home/philipp/bertram/lede/build_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/gcc-5.3.0-initial/.built] Error 2 make[3]: Leaving directory '/home/philipp/bertram/lede/toolchain/gcc/initial' toolchain/Makefile:96: recipe for target 'toolchain/gcc/initial/compile' failed make[2]: *** [toolchain/gcc/initial/compile] Error 2 make[2]: Leaving directory '/home/philipp/bertram/lede' toolchain/Makefile:94: recipe for target '/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/stamp/.toolchain_compile' failed make[1]: *** [/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/stamp/.toolchain_compile] Error 2 make[1]: Leaving directory '/home/philipp/bertram/lede' /home/philipp/bertram/lede/include/toplevel.mk:199: recipe for target 'world' failed make: *** [world] Error 2 The failing configure script was: build_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl/gcc-5.3.0/libgcc/configure around line 3695. Am I missing something? Is there a library or utility that has an unexpressed dependency? Thanks. -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Using kdump... persistent logs, etc.
depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) x86_64 is disabled by default. You may want to enable it yourself. I don't know why. Best Regards, Syrone Wong On Fri, Mar 3, 2017 at 2:31 PM, Philip Prindeville wrote: > I built an x86_64 image and turned on crash logging, and then forced a crash > with: > > echo c >/proc/sysrq-trigger > > it rebooted, but when it did there was nothing in /sys/kernel/debug/ (i.e. no > crashlog file). > > What am I missing? Does this not work with x86_64? > > -Philip > > >> On Feb 23, 2017, at 10:27 AM, Philip Prindeville >> wrote: >> >> Thanks for that. >> >> >>> On Feb 22, 2017, at 11:44 PM, Syrone Wong wrote: >>> >>> According to LEDE's source code: >>> >>> config KERNEL_CRASHLOG >>> bool "Crash logging" >>> depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) >>> default y >>> >>> https://github.com/lede-project/source/blob/master/config/Config-kernel.in >>> >>> It is enabled by default on some targets and will be available at >>> `/sys/kernel/debug/crashlog` on next boot after crash. >>> >>> The implementation detail can be found here: >>> https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch >>> >>> >>> Best Regards, >>> Syrone Wong >>> >>> >>> On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville >>> wrote: Hi, Has anyone managed to use kdump with OpenWRT/LEDE? I have a box which periodically panics, and since /var is a link to /tmp/ there are no persistent logs. Which reminds me: is it safe to configure a third partition on my CF card, format it as ext3, and mount that as /var/log in /etc/fstab? And how would I modify the build process if I wanted to add additional partitions? Thanks, -Philip ___ openwrt-devel mailing list openwrt-de...@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> >> >> ___ >> 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] [OpenWrt-Devel] Using kdump... persistent logs, etc.
Looks like it got changed here: commit 749918911d35613f8bf7852d2a91f78ff625739e Author: Felix Fietkau Date: Fri Jan 13 14:48:25 2017 +0100 x86: disable crashlog It could cause crashes with some forms of virtualization, and it is unlikely to work properly with most systems. It's safer to just disable it. Signed-off-by: Felix Fietkau diff --git a/config/Config-kernel.in b/config/Config-kernel.in index 3f30013..a4c46f5 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -26,7 +26,7 @@ config KERNEL_PRINTK config KERNEL_CRASHLOG bool "Crash logging" - depends on !(arm || powerpc || sparc || TARGET_uml) + depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) default y config KERNEL_SWAP I must have missed the discussion about this. I’m not using virtualization, but I’m definitely seeing crashing without it. Can we get more details on "and it is unlikely to work properly with most systems”? -Philip > On Mar 3, 2017, at 12:23 AM, Syrone Wong wrote: > > depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) > > x86_64 is disabled by default. You may want to enable it yourself. I > don't know why. > > > Best Regards, > Syrone Wong > > > On Fri, Mar 3, 2017 at 2:31 PM, Philip Prindeville > wrote: >> I built an x86_64 image and turned on crash logging, and then forced a crash >> with: >> >> echo c >/proc/sysrq-trigger >> >> it rebooted, but when it did there was nothing in /sys/kernel/debug/ (i.e. >> no crashlog file). >> >> What am I missing? Does this not work with x86_64? >> >> -Philip >> >> >>> On Feb 23, 2017, at 10:27 AM, Philip Prindeville >>> wrote: >>> >>> Thanks for that. >>> >>> On Feb 22, 2017, at 11:44 PM, Syrone Wong wrote: According to LEDE's source code: config KERNEL_CRASHLOG bool "Crash logging" depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) default y https://github.com/lede-project/source/blob/master/config/Config-kernel.in It is enabled by default on some targets and will be available at `/sys/kernel/debug/crashlog` on next boot after crash. The implementation detail can be found here: https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch Best Regards, Syrone Wong On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville wrote: > Hi, > > Has anyone managed to use kdump with OpenWRT/LEDE? > > I have a box which periodically panics, and since /var is a link to /tmp/ > there are no persistent logs. Which reminds me: is it safe to configure > a third partition on my CF card, format it as ext3, and mount that as > /var/log in /etc/fstab? > > And how would I modify the build process if I wanted to add additional > partitions? > > Thanks, > > -Philip > ___ > openwrt-devel mailing list > openwrt-de...@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >>> >>> ___ >>> 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
