Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server
On 14/02/2018 04:53, Philip Prindeville wrote: On Feb 11, 2018, at 3:54 AM, Yousong Zhou wrote: On 9 February 2018 at 08:28, Philip Prindeville wrote: From: Philip Prindeville Allowing password logins leaves you vulnerable to dictionary attacks. We disable password-based authentication, limiting authentication to keys only which are more secure. Note: You'll need to pre-populate your image with some initial keys. To do this: 1. Create the appropriate directory as "mkdir -p files/root/.ssh" from your top-level directory; 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into "files/root/.ssh/authorized_keys" and indeed, you can collect keys from several sources this way by concatenating them; 3. Set the permissions on "authorized_keys" to 644 or 640. If forgetting doing this means I may need physical connection like vga monitor or serial connection to "unlock" the device, very likely I will hate this security enforcement... It's just the inconvenience regardless of whether the said situation should happen. As a user I'd like to keep this level of convenience as using password authentication and turn it off when I see it appropriate. yousong Well, we’re at an impasse because some people have said “this should be the new norm and it’s a mistake not to disable it unconditionally” and others have said the opposite, “yes, okay, let’s do this but only as an option”. So I’m happy to go other way but we should reach a consensus. What if it *is* an option but depends on a virtual package that takes a value (like CONFIG_SSH_PUBLIC_KEYS) and squirts that into the /root/.ssh/authorized_keys file. Would that work for everyone? You could still lock yourself out of a box by (a) mis-formatting the keys or (b) getting the wrong public keys that don’t match your installed private keys, but getting this to be absolutely foolproof is a fool's errand. So what constitutes “good enough”? -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev That would be good for me only if the virtual package fails building and blocks the compilation if it does not find the file. The part I'm worried about is just someone enabling a config option by mistake and getting locked out. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ag71xx: Add some unlikely calls + rearange some stuff in hard_start_xmit.
On 2018-02-13 23:53, Rosen Penev wrote:
> Based on Qualcomm driver. Improves iperf3 throughput by ~20mbps on transmit
> on Archer C7v4.
>
> Signed-off-by: Rosen Penev
> ---
> .../drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c | 14
> +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git
> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> index 95682b7641..d32f220178 100644
> ---
> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> +++
> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> @@ -797,11 +797,14 @@ static netdev_tx_t ag71xx_hard_start_xmit(struct
> sk_buff *skb,
> if (ag71xx_has_ar8216(ag))
> ag71xx_add_ar8216_header(ag, skb);
>
> - if (skb->len <= 4) {
> + dma_cache_sync (NULL, skb->data, skb->len, DMA_TO_DEVICE);
The use of dma_cache_sync here makes no sense, since it's the wrong API.
Also, effectively it results in the same kind of cache flush as the one
that's done by the DMA mapping done later.
- Felix
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add support for Gainstrong Oolite V5.2
Hi Daniel,
Few minor comments inline, below.
On 14.02.2018 02:01, Daniel Golle wrote:
The Oolite V5.2 is a dual-radio system-on-a-module.
Specs:
- QCA9531 @ 550MHz with integrated 2T2R 802.11bgn
- 64 MB DDR2 RAM
- 16 MB SPI NOR Flash (W25Q128FV)
- 1+4x 10/100 Mbps Ethernet
- QCA9887 1T1R 802.11ac
Signed-off-by: Daniel Golle
---
.../linux/ar71xx/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 ++
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 11 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-gs-oolite.c | 41 ++
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/generic/config-default | 1 +
target/linux/ar71xx/image/generic.mk | 10 ++
12 files changed, 73 insertions(+)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index f131b3b633..002ad977b7 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -322,6 +322,7 @@ ar71xx_setup_interfaces()
;;
dir-615-i1|\
omy-g1|\
+ oolite-v5.2|\
If you reorder ath79_register_eth() calls in your mach file, you could
use a more common lan/wan mapping: eth0/eth1.
With your current setup, failsafe probably doesn't work (eth0 is the
default interface in failsafe mode).
r6100|\
smart-300|\
tl-wdr6500-v2|\
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8284550e92..f7bffe8232 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -67,6 +67,7 @@ case "$FIRMWARE" in
cf-e380ac-v1|\
cf-e380ac-v2|\
dlan-pro-1200-ac|\
+ oolite-v5.2|\
sr3200|\
xd3200)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index a255b83802..0dfb278792 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -850,6 +850,9 @@ ar71xx_board_detect() {
*"Oolite V1.0")
name="oolite"
;;
+ *"Oolite V5.2")
+ name="oolite-v5.2"
+ ;;
*"PB42")
name="pb42"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 8f56d1a8f6..23e45e941f 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -391,6 +391,7 @@ platform_check_image() {
omy-x1|\
onion-omega|\
oolite|\
+ oolite-v5.2|\
re355|\
re450|\
rut900|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 068b83ce8a..d2c4472cd3 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -123,6 +123,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_USB150 is not set
# CONFIG_ATH79_MACH_GS_MINIBOX_V1 is not set
# CONFIG_ATH79_MACH_GS_OOLITE is not set
+# CONFIG_ATH79_MACH_GS_OOLITE_V5_2 is not set
# CONFIG_ATH79_MACH_HIVEAP_121 is not set
# CONFIG_ATH79_MACH_HIWIFI_HC6361 is not set
# CONFIG_ATH79_MACH_HORNET_UB is not set
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index e495f6b4c2..dd5c63dcd5 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -121,6 +121,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_USB150 is not set
# CONFIG_ATH79_MACH_GS_MINIBOX_V1 is not set
# CONFIG_ATH79_MACH_GS_OOLITE is not set
+# CONFIG_ATH79_MACH_GS_OOLITE_V5_2 is not set
# CONFIG_ATH79_MACH_HIVEAP_121 is not set
# CONFIG_ATH79_MACH_HIWIFI_HC6361 is not set
# CONFIG_ATH79_MACH_HORNET_UB is not set
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 248bffb1f5..e7fc8db78c 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -878,6 +878,17 @@ config ATH79_MACH_GS_OOLITE
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_GS_OOLITE_V5_2
+ bool "GS Oolite V5.2 support"
+ select SOC_QCA953X
+ select ATH79_DEV_AP9X_PCI if PCI
+ select A
Re: [LEDE-DEV] [PATCH] ag71xx: Add some unlikely calls + rearange some stuff in hard_start_xmit.
On 13/02/18 23:53, Rosen Penev wrote:
Based on Qualcomm driver. Improves iperf3 throughput by ~20mbps on transmit on
Archer C7v4.
this is missing the description of what the patch does.
John
Signed-off-by: Rosen Penev
---
.../drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 95682b7641..d32f220178 100644
---
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -797,11 +797,14 @@ static netdev_tx_t ag71xx_hard_start_xmit(struct sk_buff
*skb,
if (ag71xx_has_ar8216(ag))
ag71xx_add_ar8216_header(ag, skb);
- if (skb->len <= 4) {
+ dma_cache_sync (NULL, skb->data, skb->len, DMA_TO_DEVICE);
+
+ if (unlikely(skb->len <= 4)) {
DBG("%s: packet len is too small\n", ag->dev->name);
goto err_drop;
}
+ netdev_sent_queue(dev, skb->len);
dma_addr = dma_map_single(&dev->dev, skb->data, skb->len,
DMA_TO_DEVICE);
@@ -817,27 +820,24 @@ static netdev_tx_t ag71xx_hard_start_xmit(struct sk_buff *skb,
ring->buf[i].len = skb->len;
ring->buf[i].skb = skb;
- netdev_sent_queue(dev, skb->len);
-
skb_tx_timestamp(skb);
desc->ctrl &= ~DESC_EMPTY;
ring->curr += n;
- /* flush descriptor */
- wmb();
-
ring_min = 2;
if (ring->desc_split)
ring_min *= AG71XX_TX_RING_DS_PER_PKT;
- if (ring->curr - ring->dirty >= ring_size - ring_min) {
+ if (unlikely(ring->curr - ring->dirty >= ring_size - ring_min)) {
DBG("%s: tx queue full\n", dev->name);
netif_stop_queue(dev);
}
DBG("%s: packet injected into TX queue\n", ag->dev->name);
+ /* flush descriptor */
+ wmb();
/* enable TX engine */
ag71xx_wr(ag, AG71XX_REG_TX_CTRL, TX_CTRL_TXE);
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server
Philip Prindeville wrote: On Feb 11, 2018, at 3:54 AM, Yousong Zhou wrote: On 9 February 2018 at 08:28, Philip Prindeville wrote: From: Philip Prindeville Allowing password logins leaves you vulnerable to dictionary attacks. We disable password-based authentication, limiting authentication to keys only which are more secure. Note: You'll need to pre-populate your image with some initial keys. To do this: 1. Create the appropriate directory as "mkdir -p files/root/.ssh" from your top-level directory; 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into "files/root/.ssh/authorized_keys" and indeed, you can collect keys from several sources this way by concatenating them; 3. Set the permissions on "authorized_keys" to 644 or 640. If forgetting doing this means I may need physical connection like vga monitor or serial connection to "unlock" the device, very likely I will hate this security enforcement... It's just the inconvenience regardless of whether the said situation should happen. As a user I'd like to keep this level of convenience as using password authentication and turn it off when I see it appropriate. yousong Well, we’re at an impasse because some people have said “this should be the new norm and it’s a mistake not to disable it unconditionally” and others have said the opposite, “yes, okay, let’s do this but only as an option”. So I’m happy to go other way but we should reach a consensus. What if it *is* an option but depends on a virtual package that takes a value (like CONFIG_SSH_PUBLIC_KEYS) and squirts that into the /root/.ssh/authorized_keys file. Would that work for everyone? You could still lock yourself out of a box by (a) mis-formatting the keys or (b) getting the wrong public keys that don’t match your installed private keys, but getting this to be absolutely foolproof is a fool's errand. So what constitutes “good enough”? Personally - my thoughts There should be an option to enable passwords (default off...) A warning should be placed on the checkbox to inform the user it is not a good idea to enable them. SSH should be disabled on external interfaces unless specifically enabled. (what constitutes 'external' if there is no 'wan' port? ...i.e. AP only?) SSH without password in place and no keys should be unconditionally disabled (and not enable-able - except by hand editing.) One could try to do what some manufacturers have done and open ssh for a period of time if the WPS button is depressed for a certain length of time as a 'fool proof' command login personally though I think anyone using SSH instead of the webinterface is more than likely going to know what they are doing and therefore it should not be an issue... ie err on the side of 'there is an idiot at the controls, lets make it default as secure as possible'... -- Michelle Sullivan http://www.mhix.org/ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server
> On Feb 11, 2018, at 3:54 AM, Yousong Zhou wrote: > > On 9 February 2018 at 08:28, Philip Prindeville > wrote: >> From: Philip Prindeville >> >> Allowing password logins leaves you vulnerable to dictionary >> attacks. We disable password-based authentication, limiting >> authentication to keys only which are more secure. >> >> Note: You'll need to pre-populate your image with some initial >> keys. To do this: >> >> 1. Create the appropriate directory as "mkdir -p files/root/.ssh" >> from your top-level directory; >> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into >> "files/root/.ssh/authorized_keys" and indeed, you can collect >> keys from several sources this way by concatenating them; >> 3. Set the permissions on "authorized_keys" to 644 or 640. >> > > If forgetting doing this means I may need physical connection like vga > monitor or serial connection to "unlock" the device, very likely I > will hate this security enforcement... It's just the inconvenience > regardless of whether the said situation should happen. As a user I'd > like to keep this level of convenience as using password > authentication and turn it off when I see it appropriate. > >yousong > Well, we’re at an impasse because some people have said “this should be the new norm and it’s a mistake not to disable it unconditionally” and others have said the opposite, “yes, okay, let’s do this but only as an option”. So I’m happy to go other way but we should reach a consensus. What if it *is* an option but depends on a virtual package that takes a value (like CONFIG_SSH_PUBLIC_KEYS) and squirts that into the /root/.ssh/authorized_keys file. Would that work for everyone? You could still lock yourself out of a box by (a) mis-formatting the keys or (b) getting the wrong public keys that don’t match your installed private keys, but getting this to be absolutely foolproof is a fool's errand. So what constitutes “good enough”? -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ar71xx: add support for Gainstrong Oolite V5.2
The Oolite V5.2 is a dual-radio system-on-a-module.
Specs:
- QCA9531 @ 550MHz with integrated 2T2R 802.11bgn
- 64 MB DDR2 RAM
- 16 MB SPI NOR Flash (W25Q128FV)
- 1+4x 10/100 Mbps Ethernet
- QCA9887 1T1R 802.11ac
Signed-off-by: Daniel Golle
---
.../linux/ar71xx/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 ++
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 11 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-gs-oolite.c | 41 ++
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/generic/config-default | 1 +
target/linux/ar71xx/image/generic.mk | 10 ++
12 files changed, 73 insertions(+)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index f131b3b633..002ad977b7 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -322,6 +322,7 @@ ar71xx_setup_interfaces()
;;
dir-615-i1|\
omy-g1|\
+ oolite-v5.2|\
r6100|\
smart-300|\
tl-wdr6500-v2|\
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8284550e92..f7bffe8232 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -67,6 +67,7 @@ case "$FIRMWARE" in
cf-e380ac-v1|\
cf-e380ac-v2|\
dlan-pro-1200-ac|\
+ oolite-v5.2|\
sr3200|\
xd3200)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index a255b83802..0dfb278792 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -850,6 +850,9 @@ ar71xx_board_detect() {
*"Oolite V1.0")
name="oolite"
;;
+ *"Oolite V5.2")
+ name="oolite-v5.2"
+ ;;
*"PB42")
name="pb42"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 8f56d1a8f6..23e45e941f 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -391,6 +391,7 @@ platform_check_image() {
omy-x1|\
onion-omega|\
oolite|\
+ oolite-v5.2|\
re355|\
re450|\
rut900|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 068b83ce8a..d2c4472cd3 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -123,6 +123,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_USB150 is not set
# CONFIG_ATH79_MACH_GS_MINIBOX_V1 is not set
# CONFIG_ATH79_MACH_GS_OOLITE is not set
+# CONFIG_ATH79_MACH_GS_OOLITE_V5_2 is not set
# CONFIG_ATH79_MACH_HIVEAP_121 is not set
# CONFIG_ATH79_MACH_HIWIFI_HC6361 is not set
# CONFIG_ATH79_MACH_HORNET_UB is not set
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index e495f6b4c2..dd5c63dcd5 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -121,6 +121,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_USB150 is not set
# CONFIG_ATH79_MACH_GS_MINIBOX_V1 is not set
# CONFIG_ATH79_MACH_GS_OOLITE is not set
+# CONFIG_ATH79_MACH_GS_OOLITE_V5_2 is not set
# CONFIG_ATH79_MACH_HIVEAP_121 is not set
# CONFIG_ATH79_MACH_HIWIFI_HC6361 is not set
# CONFIG_ATH79_MACH_HORNET_UB is not set
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 248bffb1f5..e7fc8db78c 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -878,6 +878,17 @@ config ATH79_MACH_GS_OOLITE
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_GS_OOLITE_V5_2
+ bool "GS Oolite V5.2 support"
+ select SOC_QCA953X
+ select ATH79_DEV_AP9X_PCI if PCI
+ select ATH79_DEV_ETH
+ select ATH79_DEV_GPIO_BUTTONS
+ select ATH79_DEV_LEDS_GPIO
+ select ATH79_DEV_M25P80
+ select ATH79_DEV_USB
+ select ATH79_DEV_WMAC
+
config ATH79_MACH_HIVEAP_121
bool "Aerohive HiveAP-121 support"
select SOC_AR934X
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
b/target/li
[LEDE-DEV] Data corruption on kernel 4.9 with MIPS
Just thought I'd give a heads up given that the stable release is upon us. I've tried making some noise about an issue affecting ramips with kernel 4.9 where any device under /dev/sdX (maybe even /dev/mtdblock) will start returning bad data after a while (how long seems dependent on RAM size). Issue is here: https://bugs.lede-project.org/index.php?do=details&task_id=1242&opened=21&openedsm=userid It turns out, ar71xx is affected by this as well. I had an mvebu router (Turris Omnia) running 4.9 with a USB hard drive connected that I replaced with an Archer C7v4 after bricking the former. Hard drive connected as well but this time, the drive got corrupt(mounts as read-only) after several days uptime(I didn't check how long, less than a week). As for why this happens, current theory is some kind of DMA mapping error in the kernel. The first suspect is this change: https://github.com/lede-project/source/commit/668eb70157be59b17bb6da4a6de5d5e71a7c832b But if memory serves me correctly, this was occurring before as well. On the LEDE forums, people with XiaoMi MIR 3G routers were running into this issue as well with several rolling back to 4.4 and reporting good results. Link: https://forum.lede-project.org/t/xiaomi-wifi-router-3g/5377/508 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ag71xx: Add some unlikely calls + rearange some stuff in hard_start_xmit.
Based on Qualcomm driver. Improves iperf3 throughput by ~20mbps on transmit on
Archer C7v4.
Signed-off-by: Rosen Penev
---
.../drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 95682b7641..d32f220178 100644
---
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -797,11 +797,14 @@ static netdev_tx_t ag71xx_hard_start_xmit(struct sk_buff
*skb,
if (ag71xx_has_ar8216(ag))
ag71xx_add_ar8216_header(ag, skb);
- if (skb->len <= 4) {
+ dma_cache_sync (NULL, skb->data, skb->len, DMA_TO_DEVICE);
+
+ if (unlikely(skb->len <= 4)) {
DBG("%s: packet len is too small\n", ag->dev->name);
goto err_drop;
}
+ netdev_sent_queue(dev, skb->len);
dma_addr = dma_map_single(&dev->dev, skb->data, skb->len,
DMA_TO_DEVICE);
@@ -817,27 +820,24 @@ static netdev_tx_t ag71xx_hard_start_xmit(struct sk_buff
*skb,
ring->buf[i].len = skb->len;
ring->buf[i].skb = skb;
- netdev_sent_queue(dev, skb->len);
-
skb_tx_timestamp(skb);
desc->ctrl &= ~DESC_EMPTY;
ring->curr += n;
- /* flush descriptor */
- wmb();
-
ring_min = 2;
if (ring->desc_split)
ring_min *= AG71XX_TX_RING_DS_PER_PKT;
- if (ring->curr - ring->dirty >= ring_size - ring_min) {
+ if (unlikely(ring->curr - ring->dirty >= ring_size - ring_min)) {
DBG("%s: tx queue full\n", dev->name);
netif_stop_queue(dev);
}
DBG("%s: packet injected into TX queue\n", ag->dev->name);
+ /* flush descriptor */
+ wmb();
/* enable TX engine */
ag71xx_wr(ag, AG71XX_REG_TX_CTRL, TX_CTRL_TXE);
--
2.14.3
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH] add support for OCTEON TX target
On 02/13/2018 09:46 PM, Hauke Mehrtens wrote: > Hi Tim, > > sorry that I haven't reviewed this earlyer, but now I saw some problems, > see my comments inline. > > Can you please create a follow up patch based on current master branch. > > On 01/24/2018 12:15 AM, Tim Harvey wrote: >> The Cavium OCTEON TX is an ARM 64-bit SoC leveraging CPU cores and >> periperhals from the Cavium ThunderX SoC. >> >> This initial support provides a 4.14 kernel and kernel+initramfs that is >> bootable on the Gateworks Newport GW630x as well as the Cavium sff8104 >> reference board. >> >> Signed-off-by: Tim Harvey >> --- >> target/linux/octeontx/Makefile | 27 + >> .../octeontx/base-files/etc/board.d/02_network | 18 + >> target/linux/octeontx/base-files/etc/inittab | 5 + >> target/linux/octeontx/base-files/lib/octeontx.sh | 43 ++ >> target/linux/octeontx/config-4.14 | 670 >> + >> target/linux/octeontx/image/Makefile | 21 + >> ...x-add-support-for-rgmii-internal-delay-mo.patch | 148 + >> ...hunderx-workaround-BGX-TX-Underflow-issue.patch | 117 >> 8 files changed, 1049 insertions(+) >> create mode 100644 target/linux/octeontx/Makefile >> create mode 100644 target/linux/octeontx/base-files/etc/board.d/02_network >> create mode 100644 target/linux/octeontx/base-files/etc/inittab >> create mode 100644 target/linux/octeontx/base-files/lib/octeontx.sh >> create mode 100644 target/linux/octeontx/config-4.14 >> create mode 100644 target/linux/octeontx/image/Makefile >> create mode 100644 >> target/linux/octeontx/patches-4.14/0001-net-thunderx-add-support-for-rgmii-internal-delay-mo.patch >> create mode 100644 >> target/linux/octeontx/patches-4.14/0001-net-thunderx-workaround-BGX-TX-Underflow-issue.patch >> >> diff --git a/target/linux/octeontx/Makefile b/target/linux/octeontx/Makefile >> new file mode 100644 >> index 000..bbe8149 >> --- /dev/null >> +++ b/target/linux/octeontx/Makefile >> @@ -0,0 +1,27 @@ >> +# >> +# Copyright (C) 2018 OpenWrt.org >> +# >> +# This is free software, licensed under the GNU General Public License v2. >> +# See /LICENSE for more information. >> +# >> +include $(TOPDIR)/rules.mk >> + >> +ARCH:=aarch64 >> +BOARD:=octeontx >> +BOARDNAME:=Octeon-TX >> +FEATURES:=targz pcie gpio rtc usb > > I think you should define fpu here, but arm64 anyway has a fpu. > >> +CFLAGS:=-Os -pipe -fno-caller-saves > > You should not define CFLAGS for the toolchain as this will also leak > into other targets if they share the same toolchain. > > Can you try to remove the CFLAGS setting if it still works? > The build system will then set it to "-Os -pipe -mcpu=generic" > >> + >> +MAINTAINER:=Tim Harvey >> + >> +KERNEL_PATCHVER:=4.14 >> + >> +define Target/Description >> +Build images for Octeon-TX CN80XX/CN81XX based boards >> +endef >> + >> +include $(INCLUDE_DIR)/target.mk >> + >> +KERNELNAME:=Image >> + >> +$(eval $(call BuildTarget)) > >> diff --git a/target/linux/octeontx/config-4.14 >> b/target/linux/octeontx/config-4.14 >> new file mode 100644 >> index 000..97d0cc6 >> --- /dev/null >> +++ b/target/linux/octeontx/config-4.14 >> @@ -0,0 +1,670 @@ > . >> +# CONFIG_CRYPTO_SHA512_ARM64 is not set >> +CONFIG_CRYPTO_SIMD=y >> +CONFIG_CRYPTO_WORKQUEUE=y >> +CONFIG_DCACHE_WORD_ACCESS=y >> +# CONFIG_DEBUG_ALIGN_RODATA is not set >> +# CONFIG_DEBUG_BLK_CGROUP is not set >> +CONFIG_DEBUG_INFO=y > > Is this needed by default? > >> +CONFIG_DEFAULT_IOSCHED="noop" >> +CONFIG_DEFAULT_NOOP=y >> +# CONFIG_DEVPORT is not set >> +CONFIG_DEVTMPFS=y >> +CONFIG_DEVTMPFS_MOUNT=y >> +CONFIG_DMADEVICES=y >> +CONFIG_DMA_CMA=y >> +CONFIG_DMA_ENGINE=y >> +# CONFIG_DMA_NOOP_OPS is not set >> +CONFIG_DMA_OF=y >> +CONFIG_DMA_SHARED_BUFFER=y >> +# CONFIG_DMA_VIRT_OPS is not set >> +CONFIG_DNS_RESOLVER=y >> +# CONFIG_DRM_LIB_RANDOM is not set >> +CONFIG_DTC=y >> +CONFIG_DT_IDLE_STATES=y >> +CONFIG_EDAC=y >> +# CONFIG_EDAC_DEBUG is not set >> +CONFIG_EDAC_LEGACY_SYSFS=y >> +CONFIG_EDAC_SUPPORT=y >> +CONFIG_EDAC_THUNDERX=y >> +# CONFIG_EDAC_XGENE is not set >> +CONFIG_EEPROM_AT24=y >> +# CONFIG_EVM is not set >> +CONFIG_EXT2_FS=y >> +CONFIG_EXT3_FS=y > > Please activate ext2 and 3 support in ext4 instead. > >> +# CONFIG_EXT3_FS_POSIX_ACL is not set >> +# CONFIG_EXT3_FS_SECURITY is not set >> +CONFIG_EXT4_FS=y >> +CONFIG_EXT4_FS_POSIX_ACL=y >> +# CONFIG_F2FS_CHECK_FS is not set >> +CONFIG_F2FS_FS=y >> +# CONFIG_F2FS_FS_SECURITY is not set >> +CONFIG_F2FS_FS_XATTR=y >> +CONFIG_F2FS_STAT_FS=y > ... > > You should run "make kernel_oldconfig" to refresh the configuration. Please do not deactivate all the CONFIG_NET_VENDOR* options. > > There is also something missing in this configuration or in the generic > one, see this error from the build bot: > http://phase1.builds.lede-project.org/builders/octeontx%2Fgeneric/builds/0/steps/kmods/logs/stdio > > Please test compile it with this configuration: > CONFIG_TARGET
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH] add support for OCTEON TX target
Hi Tim, sorry that I haven't reviewed this earlyer, but now I saw some problems, see my comments inline. Can you please create a follow up patch based on current master branch. On 01/24/2018 12:15 AM, Tim Harvey wrote: > The Cavium OCTEON TX is an ARM 64-bit SoC leveraging CPU cores and > periperhals from the Cavium ThunderX SoC. > > This initial support provides a 4.14 kernel and kernel+initramfs that is > bootable on the Gateworks Newport GW630x as well as the Cavium sff8104 > reference board. > > Signed-off-by: Tim Harvey > --- > target/linux/octeontx/Makefile | 27 + > .../octeontx/base-files/etc/board.d/02_network | 18 + > target/linux/octeontx/base-files/etc/inittab | 5 + > target/linux/octeontx/base-files/lib/octeontx.sh | 43 ++ > target/linux/octeontx/config-4.14 | 670 > + > target/linux/octeontx/image/Makefile | 21 + > ...x-add-support-for-rgmii-internal-delay-mo.patch | 148 + > ...hunderx-workaround-BGX-TX-Underflow-issue.patch | 117 > 8 files changed, 1049 insertions(+) > create mode 100644 target/linux/octeontx/Makefile > create mode 100644 target/linux/octeontx/base-files/etc/board.d/02_network > create mode 100644 target/linux/octeontx/base-files/etc/inittab > create mode 100644 target/linux/octeontx/base-files/lib/octeontx.sh > create mode 100644 target/linux/octeontx/config-4.14 > create mode 100644 target/linux/octeontx/image/Makefile > create mode 100644 > target/linux/octeontx/patches-4.14/0001-net-thunderx-add-support-for-rgmii-internal-delay-mo.patch > create mode 100644 > target/linux/octeontx/patches-4.14/0001-net-thunderx-workaround-BGX-TX-Underflow-issue.patch > > diff --git a/target/linux/octeontx/Makefile b/target/linux/octeontx/Makefile > new file mode 100644 > index 000..bbe8149 > --- /dev/null > +++ b/target/linux/octeontx/Makefile > @@ -0,0 +1,27 @@ > +# > +# Copyright (C) 2018 OpenWrt.org > +# > +# This is free software, licensed under the GNU General Public License v2. > +# See /LICENSE for more information. > +# > +include $(TOPDIR)/rules.mk > + > +ARCH:=aarch64 > +BOARD:=octeontx > +BOARDNAME:=Octeon-TX > +FEATURES:=targz pcie gpio rtc usb I think you should define fpu here, but arm64 anyway has a fpu. > +CFLAGS:=-Os -pipe -fno-caller-saves You should not define CFLAGS for the toolchain as this will also leak into other targets if they share the same toolchain. Can you try to remove the CFLAGS setting if it still works? The build system will then set it to "-Os -pipe -mcpu=generic" > + > +MAINTAINER:=Tim Harvey > + > +KERNEL_PATCHVER:=4.14 > + > +define Target/Description > + Build images for Octeon-TX CN80XX/CN81XX based boards > +endef > + > +include $(INCLUDE_DIR)/target.mk > + > +KERNELNAME:=Image > + > +$(eval $(call BuildTarget)) > diff --git a/target/linux/octeontx/config-4.14 > b/target/linux/octeontx/config-4.14 > new file mode 100644 > index 000..97d0cc6 > --- /dev/null > +++ b/target/linux/octeontx/config-4.14 > @@ -0,0 +1,670 @@ . > +# CONFIG_CRYPTO_SHA512_ARM64 is not set > +CONFIG_CRYPTO_SIMD=y > +CONFIG_CRYPTO_WORKQUEUE=y > +CONFIG_DCACHE_WORD_ACCESS=y > +# CONFIG_DEBUG_ALIGN_RODATA is not set > +# CONFIG_DEBUG_BLK_CGROUP is not set > +CONFIG_DEBUG_INFO=y Is this needed by default? > +CONFIG_DEFAULT_IOSCHED="noop" > +CONFIG_DEFAULT_NOOP=y > +# CONFIG_DEVPORT is not set > +CONFIG_DEVTMPFS=y > +CONFIG_DEVTMPFS_MOUNT=y > +CONFIG_DMADEVICES=y > +CONFIG_DMA_CMA=y > +CONFIG_DMA_ENGINE=y > +# CONFIG_DMA_NOOP_OPS is not set > +CONFIG_DMA_OF=y > +CONFIG_DMA_SHARED_BUFFER=y > +# CONFIG_DMA_VIRT_OPS is not set > +CONFIG_DNS_RESOLVER=y > +# CONFIG_DRM_LIB_RANDOM is not set > +CONFIG_DTC=y > +CONFIG_DT_IDLE_STATES=y > +CONFIG_EDAC=y > +# CONFIG_EDAC_DEBUG is not set > +CONFIG_EDAC_LEGACY_SYSFS=y > +CONFIG_EDAC_SUPPORT=y > +CONFIG_EDAC_THUNDERX=y > +# CONFIG_EDAC_XGENE is not set > +CONFIG_EEPROM_AT24=y > +# CONFIG_EVM is not set > +CONFIG_EXT2_FS=y > +CONFIG_EXT3_FS=y Please activate ext2 and 3 support in ext4 instead. > +# CONFIG_EXT3_FS_POSIX_ACL is not set > +# CONFIG_EXT3_FS_SECURITY is not set > +CONFIG_EXT4_FS=y > +CONFIG_EXT4_FS_POSIX_ACL=y > +# CONFIG_F2FS_CHECK_FS is not set > +CONFIG_F2FS_FS=y > +# CONFIG_F2FS_FS_SECURITY is not set > +CONFIG_F2FS_FS_XATTR=y > +CONFIG_F2FS_STAT_FS=y ... You should run "make kernel_oldconfig" to refresh the configuration. There is also something missing in this configuration or in the generic one, see this error from the build bot: http://phase1.builds.lede-project.org/builders/octeontx%2Fgeneric/builds/0/steps/kmods/logs/stdio Please test compile it with this configuration: CONFIG_TARGET_octeontx=y CONFIG_TARGET_octeontx_Default=y CONFIG_TARGET_BOARD="octeontx" CONFIG_ALL_KMODS=y ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH-v2 1/3] Update to latest ath10k-ct driver, enable AHB.
On 02/13/2018 12:03 PM, John Crispin wrote:
On 13/02/18 19:27, Ben Greear wrote:
What is the status on this?
I have some new firmware/driver changes I'd like to get upstream
as well, but this series is stuck in limbo. The first two patches
should should be useful for anyone using my ath10k-ct stuff, and the
third will at least help IPQ4019 have a better chance at running my
code, even if they cannot currently select the options w/out applying
a few patches to relax some of the REQUIRES stuff that the 4019
platforms may currently have.
Thanks,
Ben
Hi Ben,
was going to send an email, ... what happened to patch 3/3 ?
Well, it was sent to the list, if that is what you mean?
There was also some disagreement about it, and some platforms
cannot select the IPQ4019 firmware it provides because of package dependencies.
I do not know
what is a good way to resolve it, and the quick fix of just removing
the hard dependency was not welcomed. I'd prefer the patch applied,
as then users have to do only a small and simple tweak to make the firmware
usable, and it should not hurt anyone else since they can just stick with
the stock firmware.
If the 3/3 patch is just not wanted, then users that want my firmware can
manually download it to their system. The first two patches could
still be applied.
Thanks,
Ben
John
On 01/19/2018 04:27 PM, gree...@candelatech.com wrote:
From: Ben Greear
The driver updates include:
ath10k driver backport to fix WPA 'pn' related security bugs
(4.13 based driver only currently),
a fix for off-channel TX for CT wave-1 firmware, a likely
fix for napi related crashes, and a backport of the firmware fetch
patch.
AHB is needed for the IPQ4019 platform radios.
Signed-off-by: Ben Greear
---
v2: Don't remove stock 4019 firmware from 4019 platform depends.
Add ability to load ct-firmware-[52].bin before other firmware.
Add ath10k-ct driver specific firmware option for 4019.
Verified driver loads on Jalapeno board.
package/kernel/ath10k-ct/Makefile | 14 +
...ctivate-user-space-firmware-loading-again.patch | 36 --
2 files changed, 8 insertions(+), 42 deletions(-)
delete mode 100644
package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index fe094e7..83d3a05 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -9,8 +9,8 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
PKG_SOURCE_PROTO:=git
PKG_SOURCE_DATE:=2017-06-13
-PKG_SOURCE_VERSION:=bded1823912549017d819d1796273b3134c3de20
-PKG_MIRROR_HASH:=616174650e12a82edb6b6bd18ac186e2c6a48fdad0082df9d2011ab20940814b
+PKG_SOURCE_VERSION:=e1edd74d5f0c5291b0be72c81033e74e267929d4
+PKG_MIRROR_HASH:=945dc7110017a80c33cac20d9d2a9beda0a6a98b50178319403568098534e60a
PKG_MAINTAINER:=Ben Greear
PKG_BUILD_PARALLEL:=1
@@ -29,7 +29,7 @@ include $(INCLUDE_DIR)/package.mk
define KernelPackage/ath10k-ct
SUBMENU:=Wireless Drivers
TITLE:=ath10k-ct driver optimized for CT ath10k firmware
- DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT
@PCI_SUPPORT +kmod-hwmon-core
+ DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT
+@DRIVER_11W_SUPPORT +kmod-hwmon-core
FILES:=\
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_pci.ko \
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
@@ -50,9 +50,11 @@ ifdef CONFIG_PACKAGE_MAC80211_MESH
endif
CT_MAKEDEFS += CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m
-# No AHB support enabled yet. Could conditionally enable it later.
-#CT_MAKEDEFS += CONFIG_ATH10K_AHB=y
-#NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
+# This AHB logic is needed for IPQ4019 radios
+CT_MAKEDEFS += CONFIG_ATH10K_AHB=m
+NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
NOSTDINC_FLAGS += -DSTANDALONE_CT
ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
diff --git
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
b/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
deleted file mode 100644
index dc02a9d..000
---
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From c0cc00f250e19c717fc9cdbdb7f55aaa569c7498 Mon Sep 17 00:00:00 2001
-From: Hauke Mehrtens
-Date: Thu, 24 Aug 2017 23:06:41 +0200
-Subject: [PATCH] ath10k: activate user space firmware loading again
-
-In commit 9f5bcfe93315 ("ath10k: silence firmware file probing
-warnings") the firmware loading was changed from request_firmware() to
-request_firmware_direct() to silence some warnings in case it fails.
-request_firmware_direct() directly searches in the file system only and
-does not send a hotplug event to user space in case it could not find
-the firmware directly.
-In LEDE we use a user space script to extract the cali
Re: [LEDE-DEV] [PATCH-v2 1/3] Update to latest ath10k-ct driver, enable AHB.
On 13/02/18 19:27, Ben Greear wrote:
What is the status on this?
I have some new firmware/driver changes I'd like to get upstream
as well, but this series is stuck in limbo. The first two patches
should should be useful for anyone using my ath10k-ct stuff, and the
third will at least help IPQ4019 have a better chance at running my
code, even if they cannot currently select the options w/out applying
a few patches to relax some of the REQUIRES stuff that the 4019
platforms may currently have.
Thanks,
Ben
Hi Ben,
was going to send an email, ... what happened to patch 3/3 ?
John
On 01/19/2018 04:27 PM, gree...@candelatech.com wrote:
From: Ben Greear
The driver updates include:
ath10k driver backport to fix WPA 'pn' related security bugs
(4.13 based driver only currently),
a fix for off-channel TX for CT wave-1 firmware, a likely
fix for napi related crashes, and a backport of the firmware fetch
patch.
AHB is needed for the IPQ4019 platform radios.
Signed-off-by: Ben Greear
---
v2: Don't remove stock 4019 firmware from 4019 platform depends.
Add ability to load ct-firmware-[52].bin before other firmware.
Add ath10k-ct driver specific firmware option for 4019.
Verified driver loads on Jalapeno board.
package/kernel/ath10k-ct/Makefile | 14 +
...ctivate-user-space-firmware-loading-again.patch | 36
--
2 files changed, 8 insertions(+), 42 deletions(-)
delete mode 100644
package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index fe094e7..83d3a05 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -9,8 +9,8 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
PKG_SOURCE_PROTO:=git
PKG_SOURCE_DATE:=2017-06-13
-PKG_SOURCE_VERSION:=bded1823912549017d819d1796273b3134c3de20
-PKG_MIRROR_HASH:=616174650e12a82edb6b6bd18ac186e2c6a48fdad0082df9d2011ab20940814b
+PKG_SOURCE_VERSION:=e1edd74d5f0c5291b0be72c81033e74e267929d4
+PKG_MIRROR_HASH:=945dc7110017a80c33cac20d9d2a9beda0a6a98b50178319403568098534e60a
PKG_MAINTAINER:=Ben Greear
PKG_BUILD_PARALLEL:=1
@@ -29,7 +29,7 @@ include $(INCLUDE_DIR)/package.mk
define KernelPackage/ath10k-ct
SUBMENU:=Wireless Drivers
TITLE:=ath10k-ct driver optimized for CT ath10k firmware
- DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT
+@DRIVER_11AC_SUPPORT @PCI_SUPPORT +kmod-hwmon-core
+ DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT
+@DRIVER_11AC_SUPPORT +@DRIVER_11W_SUPPORT +kmod-hwmon-core
FILES:=\
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_pci.ko \
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
@@ -50,9 +50,11 @@ ifdef CONFIG_PACKAGE_MAC80211_MESH
endif
CT_MAKEDEFS += CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m
-# No AHB support enabled yet. Could conditionally enable it later.
-#CT_MAKEDEFS += CONFIG_ATH10K_AHB=y
-#NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
+# This AHB logic is needed for IPQ4019 radios
+CT_MAKEDEFS += CONFIG_ATH10K_AHB=m
+NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
NOSTDINC_FLAGS += -DSTANDALONE_CT
ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
diff --git
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
b/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
deleted file mode 100644
index dc02a9d..000
---
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From c0cc00f250e19c717fc9cdbdb7f55aaa569c7498 Mon Sep 17 00:00:00 2001
-From: Hauke Mehrtens
-Date: Thu, 24 Aug 2017 23:06:41 +0200
-Subject: [PATCH] ath10k: activate user space firmware loading again
-
-In commit 9f5bcfe93315 ("ath10k: silence firmware file probing
-warnings") the firmware loading was changed from request_firmware() to
-request_firmware_direct() to silence some warnings in case it fails.
-request_firmware_direct() directly searches in the file system only and
-does not send a hotplug event to user space in case it could not find
-the firmware directly.
-In LEDE we use a user space script to extract the calibration data from
-the flash memory which gets triggered by the hotplug event. This way
the
-firmware gets extracted from some vendor specific partition when the
-driver requests this firmware. This mechanism does not work any more
-after this change.
-
-Fixes: 9f5bcfe93315 ("ath10k: silence firmware file probing warnings")
-Signed-off-by: Hauke Mehrtens
-Cc: Michal Kazior
-Signed-off-by: Kalle Valo
- ath10k-4.13/core.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
a/ath10k-4.13/core.c
-+++ b/ath10k-4.13/core.c
-@@ -556,7 +556,7 @@ static const struct firmware *ath10k_fet
- dir = ".";
-
- snprintf(filename, sizeof(filename), "%s/%s", dir, file);
-- ret = request_firmware_direct(&f
Re: [LEDE-DEV] U-Boot v2018.01 requiring GCC6
Shouldn't a jump to gcc 7.2 or 8 with the Retopoline patches included, be the target given meltdown/spectre mitigations? This is going to affect newer Arm (mvebu potentially) and atom/x86 builds - although these use grub generally so not so much specific to uboot not compiling. -Joel On 14 February 2018 at 04:04, wrote: > Hey guys, > > as of U-Boot v2018.01, the bootloader requires at least a GCC 6 based > toolchain > for ARM targets [1]. Building will fail with GCCs prior to 6. (I.e. current > default 5.5.0) > > For the Kirkwood target, I've prepared a patch to bring it to v2018.01, but > that would result > in a failed build as stated above. (Of course, when manually selecting GCC6 > as compiler > everything is fine) > > How can this situation be resolved? > -) Stick to U-Boot 2017.11 until GCC 6.x is the default here? > -) Is a switch to GCC6 planned in the near future? > -) Undo the changes in [1] via a local patch and check, whether GCC5 is still > fine for Kirkwood? > > While the bootloader may not be that important in day to day business, > eventually a 'regular' > package might have a requirement for a newer compiler too... > > Best, > P. Wassi > > [1]: > http://git.denx.de/?p=u-boot.git;a=commit;h=6b867dabe84bae1e74e88f4af620c26cb793c4c2 > > > > ___ > 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] [PATCH-v2 1/3] Update to latest ath10k-ct driver, enable AHB.
What is the status on this?
I have some new firmware/driver changes I'd like to get upstream
as well, but this series is stuck in limbo. The first two patches
should should be useful for anyone using my ath10k-ct stuff, and the
third will at least help IPQ4019 have a better chance at running my
code, even if they cannot currently select the options w/out applying
a few patches to relax some of the REQUIRES stuff that the 4019
platforms may currently have.
Thanks,
Ben
On 01/19/2018 04:27 PM, gree...@candelatech.com wrote:
From: Ben Greear
The driver updates include:
ath10k driver backport to fix WPA 'pn' related security bugs
(4.13 based driver only currently),
a fix for off-channel TX for CT wave-1 firmware, a likely
fix for napi related crashes, and a backport of the firmware fetch
patch.
AHB is needed for the IPQ4019 platform radios.
Signed-off-by: Ben Greear
---
v2: Don't remove stock 4019 firmware from 4019 platform depends.
Add ability to load ct-firmware-[52].bin before other firmware.
Add ath10k-ct driver specific firmware option for 4019.
Verified driver loads on Jalapeno board.
package/kernel/ath10k-ct/Makefile | 14 +
...ctivate-user-space-firmware-loading-again.patch | 36 --
2 files changed, 8 insertions(+), 42 deletions(-)
delete mode 100644
package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index fe094e7..83d3a05 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -9,8 +9,8 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
PKG_SOURCE_PROTO:=git
PKG_SOURCE_DATE:=2017-06-13
-PKG_SOURCE_VERSION:=bded1823912549017d819d1796273b3134c3de20
-PKG_MIRROR_HASH:=616174650e12a82edb6b6bd18ac186e2c6a48fdad0082df9d2011ab20940814b
+PKG_SOURCE_VERSION:=e1edd74d5f0c5291b0be72c81033e74e267929d4
+PKG_MIRROR_HASH:=945dc7110017a80c33cac20d9d2a9beda0a6a98b50178319403568098534e60a
PKG_MAINTAINER:=Ben Greear
PKG_BUILD_PARALLEL:=1
@@ -29,7 +29,7 @@ include $(INCLUDE_DIR)/package.mk
define KernelPackage/ath10k-ct
SUBMENU:=Wireless Drivers
TITLE:=ath10k-ct driver optimized for CT ath10k firmware
- DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT
@PCI_SUPPORT +kmod-hwmon-core
+ DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT
+@DRIVER_11W_SUPPORT +kmod-hwmon-core
FILES:=\
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_pci.ko \
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
@@ -50,9 +50,11 @@ ifdef CONFIG_PACKAGE_MAC80211_MESH
endif
CT_MAKEDEFS += CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m
-# No AHB support enabled yet. Could conditionally enable it later.
-#CT_MAKEDEFS += CONFIG_ATH10K_AHB=y
-#NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
+# This AHB logic is needed for IPQ4019 radios
+CT_MAKEDEFS += CONFIG_ATH10K_AHB=m
+NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
NOSTDINC_FLAGS += -DSTANDALONE_CT
ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
diff --git
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
b/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
deleted file mode 100644
index dc02a9d..000
---
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From c0cc00f250e19c717fc9cdbdb7f55aaa569c7498 Mon Sep 17 00:00:00 2001
-From: Hauke Mehrtens
-Date: Thu, 24 Aug 2017 23:06:41 +0200
-Subject: [PATCH] ath10k: activate user space firmware loading again
-
-In commit 9f5bcfe93315 ("ath10k: silence firmware file probing
-warnings") the firmware loading was changed from request_firmware() to
-request_firmware_direct() to silence some warnings in case it fails.
-request_firmware_direct() directly searches in the file system only and
-does not send a hotplug event to user space in case it could not find
-the firmware directly.
-In LEDE we use a user space script to extract the calibration data from
-the flash memory which gets triggered by the hotplug event. This way the
-firmware gets extracted from some vendor specific partition when the
-driver requests this firmware. This mechanism does not work any more
-after this change.
-
-Fixes: 9f5bcfe93315 ("ath10k: silence firmware file probing warnings")
-Signed-off-by: Hauke Mehrtens
-Cc: Michal Kazior
-Signed-off-by: Kalle Valo
- ath10k-4.13/core.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
a/ath10k-4.13/core.c
-+++ b/ath10k-4.13/core.c
-@@ -556,7 +556,7 @@ static const struct firmware *ath10k_fet
- dir = ".";
-
- snprintf(filename, sizeof(filename), "%s/%s", dir, file);
-- ret = request_firmware_direct(&fw, filename, ar->dev);
-+ ret = request_firmware(&fw, filename, ar->dev);
- ath10k_dbg(ar, ATH10K_DBG_BOOT, "boo
Re: [LEDE-DEV] Bug when processing long lines
On 11/01/18 17:28, Jakub Horák wrote: Hello LEDE developers, I found a bug in procd that gets triggered when long lines are printed by services whose stdout/stderr are being logged. The bug itself is explained in the attached patch. However, when I was testing the fix, I found out that the bug is present in other places, mostly those that call "ustream_get_read_buf" function. Some examples: - ubox/log/logread.c:logread_fb_data_cb() - when buffer passed on the descriptor is larger than 4096, reception stops - netifd/main.c:netifd_process_log_read_cb - this is a place that seems to have this bug fixed, but still has incorrect handling of NUL bytes - libubox/examples/ustream-example.c:client_read_cb - this is probably the place that originated this broken bit of code - uhttpd/relay.c:relay_process_headers - another place that seems broken I've attached an init script (that goes to /etc/init.d/flood) and three Lua programs (flood[123].lua) that trigger this behavior: - flood1.lua writes long message to stdout, that triggers this behavior in procd - flood2.lua writes message that gets correctly processed by procd, but triggers the bug in logread - flood3.lua writes message with embedded zeros I don't post patches to mailing lists very often, so I apologize if I'm sending this in a wrong format or in a too broken english. Best regards, Jakub Horak Hi Jakub, i've just posted and alternative solution. could you help test it please ? John ___ 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] procd: fix ustream deadlock when there are 0 bytes or no newlines
Signed-off-by: John Crispin
---
service/instance.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/service/instance.c b/service/instance.c
index 917b003..27e35b1 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -469,18 +469,20 @@ instance_stdio(struct ustream *s, int prio, struct
service_instance *in)
ulog_open(ULOG_SYSLOG, LOG_DAEMON, ident);
do {
- str = ustream_get_read_buf(s, NULL);
+ str = ustream_get_read_buf(s, &len);
if (!str)
break;
- newline = strchr(str, '\n');
- if (!newline)
+ newline = memchr(str, '\n', len);
+ if (!newline && (s->r.buffer_len != len))
break;
- *newline = 0;
+ if (newline) {
+ *newline = 0;
+ len = newline + 1 - str;
+ }
ulog(prio, "%s\n", str);
- len = newline + 1 - str;
ustream_consume(s, len);
} while (1);
--
2.11.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] imx6: update to Linux 4.14
On Tue, Feb 13, 2018 at 12:43 AM, John Crispin wrote: > > > On 01/02/18 23:35, Tim Harvey wrote: >> >> Tested on a Gateworks GW54xx >> >> Tim Harvey (4): >>kernel: add missing config symbols >>imx6: add support for Linux 4.14 >>imx6: switch to kernel 4.14 >>imx6: remove support for 4.9 > > > Hi, > > karl and hauke posted some comments to the series. I've marked the whole > series as "changes requested". please send a v3 with them incorporated. > > John > John, Thanks - will get one out today or tomorrow. Tim ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] curl: Switch all TLS libraries to use ca-bundle.
On Tue, Feb 13, 2018 at 4:28 AM, John Crispin wrote: > > > On 25/01/18 04:29, Rosen Penev wrote: >> >> On Wed, Jan 24, 2018 at 1:56 PM, Hauke Mehrtens wrote: >>> >>> On 01/24/2018 05:28 AM, Rosen Penev wrote: At least one application (transmission) depends on CURL_CA_BUNDLE being set in order to operate properly (Could not connect to tracker errors). As far as I can tell, there's no real drawback to doing this for all TLS libraries supported by curl. >>> >>> Do all of these libraries support --with-ca-bundle ? >>> >> OpenSSL I know does. GnuTLS most likely does as it seems to be geared >> towards desktop systems. > > > Hi, > > "most likely" is not good enough. please compile/runtime test your patches > for all possible combos before posting them. > I've fixed the transmission issue by setting the env parameter to the proper value. Meaning this patch doesn't help in this case. It probably does in others. A quick Google search shows that it does indeed work with GnuTLS. Maybe it didn't with some previous version. > John > Signed-off-by: Rosen Penev --- package/network/utils/curl/Makefile | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/package/network/utils/curl/Makefile b/package/network/utils/curl/Makefile index 17fcf70..930bd10 100644 --- a/package/network/utils/curl/Makefile +++ b/package/network/utils/curl/Makefile @@ -111,13 +111,15 @@ CONFIGURE_ARGS += \ --without-nss \ --without-libmetalink \ --without-librtmp \ + --without-ca-path \ + --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt \ \ $(call autoconf_bool,CONFIG_IPV6,ipv6) \ \ - $(if $(CONFIG_LIBCURL_WOLFSSL),--with-cyassl="$(STAGING_DIR)/usr" --without-ca-path --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-cyassl) \ - $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr" --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-gnutls) \ - $(if $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr" --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-ssl) \ - $(if $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr" --without-ca-path --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-mbedtls) \ + $(if $(CONFIG_LIBCURL_WOLFSSL),--with-cyassl="$(STAGING_DIR)/usr",--without-cyassl) \ + $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr",--without-gnutls) \ + $(if $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr",--without-ssl) \ + $(if $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr",--without-mbedtls) \ \ $(if $(CONFIG_LIBCURL_LIBIDN),--with-libidn="$(STAGING_DIR)/usr",--without-libidn) \ $(if $(CONFIG_LIBCURL_SSH2),--with-libssh2="$(STAGING_DIR)/usr",--without-libssh2) \ >> ___ >> 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] U-Boot v2018.01 requiring GCC6
Hey guys, as of U-Boot v2018.01, the bootloader requires at least a GCC 6 based toolchain for ARM targets [1]. Building will fail with GCCs prior to 6. (I.e. current default 5.5.0) For the Kirkwood target, I've prepared a patch to bring it to v2018.01, but that would result in a failed build as stated above. (Of course, when manually selecting GCC6 as compiler everything is fine) How can this situation be resolved? -) Stick to U-Boot 2017.11 until GCC 6.x is the default here? -) Is a switch to GCC6 planned in the near future? -) Undo the changes in [1] via a local patch and check, whether GCC5 is still fine for Kirkwood? While the bootloader may not be that important in day to day business, eventually a 'regular' package might have a requirement for a newer compiler too... Best, P. Wassi [1]: http://git.denx.de/?p=u-boot.git;a=commit;h=6b867dabe84bae1e74e88f4af620c26cb793c4c2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] brcm63xx not booting on newer kernels (JFFS2)
> I just pushed a fix for this. I can now confirm operation on both 4.9 and 4.14 :) Thanks for fixing! P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] archs38: add HSDK board
Synopsys DesignWare HSDK (which stands for ARC HS Development Kit) is the latest and greatest development platform that sports quad-core ARC HS38 in real silicon. Most noticeable features of the board are: * Quad-core ARC HS38 CPU running at 1GHz * 4Gb of DDR * Built-in Vivante GPU (well supported via open source Etnaviv drivers) * Built-in Wi-Fi/Bluetooth module (RedPine RS-9113) And as usual we have: * [micro] SD-card slot * 2 USB 2.0 ports * 1Gbit Ethernet port * Built-in Digilent JTAG probe * Serial port accessible via micro-USB port For more information about HSDK board visit: https://www.synopsys.com/dw/ipdir.php?ds=arc-hs-development-kit Signed-off-by: Evgeniy Didin CC: Alexey Brodkin CC: Hauke Mehrtens CC: John Crispin --- target/linux/archs38/config-4.14 | 7 +-- target/linux/archs38/image/Makefile | 6 -- target/linux/archs38/image/uboot.env.txt | 29 + 3 files changed, 38 insertions(+), 4 deletions(-) create mode 100644 target/linux/archs38/image/uboot.env.txt diff --git a/target/linux/archs38/config-4.14 b/target/linux/archs38/config-4.14 index 39db6a57d1..9a04154a20 100644 --- a/target/linux/archs38/config-4.14 +++ b/target/linux/archs38/config-4.14 @@ -40,12 +40,13 @@ CONFIG_ARC_PLAT_AXS10X=y # CONFIG_ARC_PLAT_EZNPS is not set # CONFIG_ARC_PLAT_TB10X is not set # CONFIG_ARC_SMP_HALT_ON_RESET is not set -# CONFIG_ARC_SOC_HSDK is not set +CONFIG_ARC_SOC_HSDK=y CONFIG_ARC_TIMERS=y CONFIG_ARC_TIMERS_64BIT=y CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_AXS103=y CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLK_HSDK=y CONFIG_CLONE_BACKWARDS=y CONFIG_COMMON_CLK=y # CONFIG_CPU_BIG_ENDIAN is not set @@ -119,7 +120,7 @@ CONFIG_JBD2=y CONFIG_KALLSYMS=y CONFIG_KERNEL_GZIP=y CONFIG_LIBFDT=y -CONFIG_LINUX_LINK_BASE=0x8000 +CONFIG_LINUX_LINK_BASE=0x9000 CONFIG_LINUX_RAM_BASE=0x8000 CONFIG_LOCK_SPIN_ON_OWNER=y CONFIG_MDIO_BUS=y @@ -152,6 +153,7 @@ CONFIG_NET_PTP_CLASSIFY=y # CONFIG_NET_VENDOR_SEEQ is not set # CONFIG_NET_VENDOR_VIA is not set # CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_NLS=y CONFIG_NO_BOOTMEM=y CONFIG_NO_IOPORT_MAP=y CONFIG_NR_CPUS=4 @@ -182,6 +184,7 @@ CONFIG_RCU_STALL_COMMON=y CONFIG_REGMAP=y CONFIG_REGMAP_MMIO=y CONFIG_RESET_CONTROLLER=y +CONFIG_RESET_HSDK=y CONFIG_RFS_ACCEL=y CONFIG_RPS=y # CONFIG_SCHED_INFO is not set diff --git a/target/linux/archs38/image/Makefile b/target/linux/archs38/image/Makefile index 5d941bc94b..1e0d3e99fd 100644 --- a/target/linux/archs38/image/Makefile +++ b/target/linux/archs38/image/Makefile @@ -33,8 +33,8 @@ TARGET_DEVICES += nsim_hs endif # Root FS on SD-card -KERNEL_LOADADDR := 0x8000 -DEVICE_DTS_LIST:= axs103_idu nsim_hs_idu +KERNEL_LOADADDR := 0x9000 +DEVICE_DTS_LIST:= axs103_idu nsim_hs_idu hsdk FAT32_BLOCK_SIZE=1024 FAT32_BLOCKS=$(shell echo $$(($(CONFIG_AXS10X_SD_BOOT_PARTSIZE)*1024*1024/$(FAT32_BLOCK_SIZE @@ -49,9 +49,11 @@ define Image/Build/SDCard rm -f $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img mkfs.fat $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img -C $(FAT32_BLOCKS) mkimage -C none -A arc -T script -d uEnv.txt $(BIN_DIR)/uEnv.scr + mkenvimage -s 0x4000 -o $(BIN_DIR)/uboot.env ./uboot.env.txt mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(BIN_DIR)/uEnv.scr ::boot.scr mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(DTS_DIR)/*.dtb :: mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(BIN_DIR)/$(IMG_PREFIX)-uImage ::uImage + mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(BIN_DIR)/uboot.env ::uboot.env ./gen_axs10x_sdcard_img.sh \ $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-sdcard-vfat-$(1).img \ diff --git a/target/linux/archs38/image/uboot.env.txt b/target/linux/archs38/image/uboot.env.txt new file mode 100644 index 00..9ae7bd0c62 --- /dev/null +++ b/target/linux/archs38/image/uboot.env.txt @@ -0,0 +1,29 @@ +baudrate=115200 +bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p2 rootwait +bootcmd=fatload mmc 0:1 0x8200 uImage && fatload mmc 0:1 0x8100 hsdk.dtb && bootm 0x8200 - 0x8100 +bootdelay=2 +bootfile=uImage +loadaddr=0x8200 +stderr=serial0@f0005000 +stdin=serial0@f0005000 +stdout=serial0@f0005000 +core_dccm_0=0x10 +core_dccm_1=0x6 +core_dccm_2=0x10 +core_dccm_3=0x6 +core_iccm_0=0x10 +core_iccm_1=0x6 +core_iccm_2=0x10 +core_iccm_3=0x6 +core_mask=0xF +dcache_ena=0x1 +icache_ena=0x1 +non_volatile_limit=0xE +hsdk_hs34=setenv core_mask 0x2; setenv icache_ena 0x0; setenv dcache_ena 0x0; setenv core_iccm_1 0x7; setenv core_dccm_1 0x8; setenv non_volatile_limit 0x0; +hsdk_hs36=setenv core_mask 0x1; setenv icache_ena 0x1; setenv dcache_ena 0x1; setenv core_iccm_0 0x10; setenv core_dccm_0 0x10; setenv non_volatile_limit 0xE; +hsdk_hs36_ccm=setenv core_mask 0x2; setenv icache_ena 0x1; setenv dcache_ena 0x1; setenv core_iccm_1 0x7; setenv core_dccm_1 0x8; setenv non_volatile_limit 0xE; +hsdk_
[LEDE-DEV] [PATCH 1/2] archs38: switch to kmod-usb2
We have managed to get USB 2.0 working good enough on all archs38 platforms so we're ready to switch to much faster USB 2.0. Signed-off-by: Evgeniy Didin CC: Alexey Brodkin CC: Hauke Mehrtens CC: John Crispin --- target/linux/archs38/generic/profiles/00-default.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/archs38/generic/profiles/00-default.mk b/target/linux/archs38/generic/profiles/00-default.mk index fd8143a166..b27b5a4dfa 100644 --- a/target/linux/archs38/generic/profiles/00-default.mk +++ b/target/linux/archs38/generic/profiles/00-default.mk @@ -7,7 +7,7 @@ define Profile/Default NAME:=Default Profile (all drivers) - PACKAGES:= kmod-usb-core kmod-usb-ohci kmod-ath9k-htc wpad-mini + PACKAGES:= kmod-usb-core kmod-usb2 kmod-ath9k-htc wpad-mini endef define Profile/Default/Description -- 2.11.0 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/2] archs38: add HSDK board
In first patch appears switch from usb1.1 to usb2 usage on archs38. In second patch we finally add new HSDK board to target/linux/archs38. Signed-off-by: Evgeniy Didin CC: Alexey Brodkin CC: Hauke Mehrtens CC: John Crispin Evgeniy Didin (2): archs38: switch to kmod-usb2 archs38: add HSDK board target/linux/archs38/config-4.14 | 7 -- .../linux/archs38/generic/profiles/00-default.mk | 2 +- target/linux/archs38/image/Makefile| 6 +++-- target/linux/archs38/image/uboot.env.txt | 29 ++ 4 files changed, 39 insertions(+), 5 deletions(-) create mode 100644 target/linux/archs38/image/uboot.env.txt -- 2.11.0 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] generic: swconfig: reduce lock duration on sysfs files
sysfs attributes 'port_mask' & 'speed_mask' held locks whilst doing
mundane tasks such as sprintf. Refactor code to reduce length of time
locks are held unnecessarily.
Signed-off-by: Kevin Darbyshire-Bryant
---
.../generic/files/drivers/net/phy/swconfig_leds.c| 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
b/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
index 92be3c7501..91824b7cf6 100644
--- a/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
+++ b/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
@@ -124,18 +124,16 @@ swconfig_trig_port_mask_store(struct device *dev, struct
device_attribute *attr,
return ret;
write_lock(&trig_data->lock);
-
changed = (trig_data->port_mask != port_mask);
+ trig_data->port_mask = port_mask;
+ write_unlock(&trig_data->lock);
+
if (changed) {
- trig_data->port_mask = port_mask;
if (port_mask == 0)
swconfig_trig_set_brightness(trig_data, LED_OFF);
- }
- write_unlock(&trig_data->lock);
-
- if (changed)
swconfig_trig_update_port_mask(led_cdev->trigger);
+ }
return size;
}
@@ -146,11 +144,14 @@ swconfig_trig_port_mask_show(struct device *dev, struct
device_attribute *attr,
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct swconfig_trig_data *trig_data = led_cdev->trigger_data;
+ u32 port_mask;
read_lock(&trig_data->lock);
- sprintf(buf, "%#x\n", trig_data->port_mask);
+ port_mask = trig_data->port_mask;
read_unlock(&trig_data->lock);
+ sprintf(buf, "%#x\n", port_mask);
+
return strlen(buf) + 1;
}
@@ -164,11 +165,14 @@ static ssize_t swconfig_trig_speed_mask_show(struct
device *dev,
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct swconfig_trig_data *trig_data = led_cdev->trigger_data;
+ u8 speed_mask;
read_lock(&trig_data->lock);
- sprintf(buf, "%#x\n", trig_data->speed_mask);
+ speed_mask = trig_data->speed_mask;
read_unlock(&trig_data->lock);
+ sprintf(buf, "%#x\n", speed_mask);
+
return strlen(buf) + 1;
}
--
2.14.3 (Apple Git-98)
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] generic: swconfig: add mode led attribute
Add sysfs 'mode' attribute to swconfig controlled LEDs.
swconfig 'link state' LEDs blink in the presence of port traffic. This
behaviour becomes more obvious as switches start to support
get_port_stats() e.g. commits 0369e358916ef092a1644334f5dd1412051b68a4,
3056d09b4046e0eb0f6de0f3f5432cd9fa86fc51,
4ddbc43cc15c2fa128a2f169964ef7eb508cf2c5,
4d8a66d9346373c2a7fcac5bdae3f662a9dbd9df.
This blinking can be confusing/distracting if the switch has other LEDs
used to indicate traffic. Provide a 'mode' sysfs attribute that
controls the blink on traffic behaviour.
mode - either "none" (LED is off) or a space separated list of one or more:
link: LED's normal state reflects whether the link is up (has carrier) or not
tx: LED blinks on transmitted data
rx: LED blinks on receive data
Note that 'link' considers any port speed mask that may be applicable.
e.g. if an LED is configured to indicate 1Gbit link speed and mode is
set to 'link rx tx' but the port is connected at 100Mbit then the LED
will not light or blink. A mode of 'tx rx' will blink in the presence of
traffic only if the port matches the rate (if configured)
This maintains compatibility with existing behaviour.
Attribute is 'link tx rx' by default for backwards compatible behaviour.
Many thanks to Thibaut Varene for providing a more sensible led_event
routine after I had mangled the original, and other coding style hints.
Signed-off-by: Kevin Darbyshire-Bryant
Acked-by: Thibaut VARENE
---
.../generic/files/drivers/net/phy/swconfig_leds.c | 137 +++--
1 file changed, 125 insertions(+), 12 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
b/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
index 20b9a12a54..92be3c7501 100644
--- a/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
+++ b/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
@@ -29,6 +29,15 @@
SWCONFIG_LED_PORT_SPEED_100 | \
SWCONFIG_LED_PORT_SPEED_1000)
+#define SWCONFIG_LED_MODE_LINK 0x01
+#define SWCONFIG_LED_MODE_TX 0x02
+#define SWCONFIG_LED_MODE_RX 0x04
+#define SWCONFIG_LED_MODE_TXRX (SWCONFIG_LED_MODE_TX | \
+SWCONFIG_LED_MODE_RX)
+#define SWCONFIG_LED_MODE_ALL (SWCONFIG_LED_MODE_LINK | \
+SWCONFIG_LED_MODE_TX | \
+SWCONFIG_LED_MODE_RX)
+
struct switch_led_trigger {
struct led_trigger trig;
struct switch_dev *swdev;
@@ -36,7 +45,8 @@ struct switch_led_trigger {
struct delayed_work sw_led_work;
u32 port_mask;
u32 port_link;
- unsigned long long port_traffic[SWCONFIG_LED_NUM_PORTS];
+ unsigned long long port_tx_traffic[SWCONFIG_LED_NUM_PORTS];
+ unsigned long long port_rx_traffic[SWCONFIG_LED_NUM_PORTS];
u8 link_speed[SWCONFIG_LED_NUM_PORTS];
};
@@ -50,6 +60,7 @@ struct swconfig_trig_data {
bool prev_link;
unsigned long prev_traffic;
enum led_brightness prev_brightness;
+ u8 mode;
u8 speed_mask;
};
@@ -186,6 +197,79 @@ static ssize_t swconfig_trig_speed_mask_store(struct
device *dev,
static DEVICE_ATTR(speed_mask, 0644, swconfig_trig_speed_mask_show,
swconfig_trig_speed_mask_store);
+static ssize_t swconfig_trig_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct swconfig_trig_data *trig_data = led_cdev->trigger_data;
+ u8 mode;
+
+ read_lock(&trig_data->lock);
+ mode = trig_data->mode;
+ read_unlock(&trig_data->lock);
+
+ if (mode == 0) {
+ strcpy(buf, "none\n");
+ } else {
+ if (mode & SWCONFIG_LED_MODE_LINK)
+ strcat(buf, "link ");
+ if (mode & SWCONFIG_LED_MODE_TX)
+ strcat(buf, "tx ");
+ if (mode & SWCONFIG_LED_MODE_RX)
+ strcat(buf, "rx ");
+ strcat(buf, "\n");
+ }
+
+ return strlen(buf)+1;
+}
+
+static ssize_t swconfig_trig_mode_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct swconfig_trig_data *trig_data = led_cdev->trigger_data;
+ char copybuf[128];
+ int new_mode = -1;
+ char *p, *token;
+
+ /* take a copy since we don't want to trash the inbound buffer when
using strsep */
+ strncpy(copybuf, buf, sizeof(copybuf));
+ copybuf[sizeof(copybuf) - 1] = 0;
+ p = copybuf;
+
+ while ((token = strsep(&p, " \t\n")) != NULL) {
+ if (!*token)
+ continue;
+
+ if (new_mode < 0)
+
Re: [LEDE-DEV] brcm63xx not booting on newer kernels (JFFS2)
Hi, On 13 February 2018 at 13:03, wrote: > Hi Jonas, > > thanks for bringing kernel 4.9 and 4.14 to the brcm63xx target and therefore > keeping > them as 'active' devices (regarding development). > I just tried 4.9 and 4.14 on my AV4202 and can't fully boot the thing due to > JFFS2 errors. > Already erased the whole main image and reflashed it via CFE, same results. > The kernel correctly processes and detects the partition layout like in 4.4 > rootfs_data's begin has moved from 0x36 to 0x3A (due to larger rootfs > and/or kernel) > > Attached is the serial bootlog from 4.9 (4.14 is similar) I just pushed a fix for this. Not sure why it didn't pop up when I tested it ... . Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: Orders the names of the devices alphabetically.
On 17/01/18 14:16, Arne Zachlod wrote:
Signed-off-by: Arne Zachlod
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 236 ++---
.../ar71xx/base-files/etc/board.d/03_gpio_switches | 12 +-
target/linux/ar71xx/base-files/etc/diag.sh | 40 ++--
3 files changed, 144 insertions(+), 144 deletions(-)
[...]
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 6cbb3576d8..5c60ebd6a8 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -72,6 +72,23 @@ get_status_led() {
tl-wr902ac-v1)
status_led="$board:green:power"
;;
+ archer-c5|\
+ archer-c7|\
+ tl-mr10u|\
+ tl-mr12u|\
+ tl-mr13u|\
+ tl-wdr4300|\
+ tl-wdr4900-v2|\
+ tl-wr703n|\
+ tl-wr710n|\
+ tl-wr720n-v3|\
+ tl-wr802n-v1|\
+ tl-wr810n|\
+ tl-wr810n-v2|\
+ tl-wr940n-v4|\
+ tl-wr941nd-v6)
+ status_led="tp-link:blue:system"
+ ;;
ap90q|\
cpe830|\
cpe870|\
@@ -103,9 +120,6 @@ get_status_led() {
rocket-m-xw)
status_led="ubnt:green:link4"
;;
- rocket-m-ti)
- status_led="ubnt:green:link6"
- ;;
bxu2000n-2-a1)
status_led="bhu:green:status"
;;
@@ -337,6 +351,9 @@ get_status_led() {
sc300m)
status_led="$board:blue:power"
;;
+ rocket-m-ti)
+ status_led="ubnt:green:link6"
+ ;;
this looks wrong, sorting r behind s ?
John
routerstation|\
routerstation-pro)
status_led="ubnt:green:rf"
@@ -414,23 +431,6 @@ get_status_led() {
tl-wr941nd-v5)
status_led="tp-link:green:system"
;;
- archer-c5|\
- archer-c7|\
- tl-mr10u|\
- tl-mr12u|\
- tl-mr13u|\
- tl-wdr4300|\
- tl-wdr4900-v2|\
- tl-wr703n|\
- tl-wr710n|\
- tl-wr720n-v3|\
- tl-wr802n-v1|\
- tl-wr810n|\
- tl-wr810n-v2|\
- tl-wr940n-v4|\
- tl-wr941nd-v6)
- status_led="tp-link:blue:system"
- ;;
tl-wr841n-v9)
status_led="tp-link:green:qss"
;;
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] brcm63xx not booting on newer kernels (JFFS2)
On 2018-02-13 13:03, p.wa...@gmx.at wrote: [0.802787] 0x0100-0x00172598 : "kernel" [0.813538] 0x00172598-0x00fc : "rootfs" [0.824870] mtd: device 3 (rootfs) set to be root filesystem [0.830761] 1 squashfs-split partitions found on MTD device rootfs [0.837154] 0x0038-0x00fc : "rootfs_data" [0.849052] 0x00fe-0x0100 : "nvram" partitions rootfs and rootfs_data seem to overlap here. They both have the same end-address Koen ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] ar71xx: add support for Ubiquiti Litebeam M5
On 17/01/18 14:23, Arne Zachlod wrote:
Specification:
- SoC: Atheros AR9342
- Flash: 8 MiB
- RAM: 64 MiB
- UART: 1x UART on PCB - 115200 8N1
- Ethernet: 1 x 100 Mbit with passive PoE (24V/0.2A)
Doesn't work:
* Flash via TFTP with Uiquiti Uboot
Installation via vendor firmware:
- upload factory image via webinterface
Signed-off-by: Arne Zachlod
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 4 ++
.../linux/ar71xx/base-files/etc/board.d/02_network | 1 +
target/linux/ar71xx/base-files/etc/diag.sh | 3 ++
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 ++
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
.../ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c| 58 ++
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/ubnt.mk | 7 +++
this file does not exist. please fix/resend
John
8 files changed, 78 insertions(+)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 150ef91b48..ebdfb142d4 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -363,6 +363,10 @@ hornet-ub-x2)
ucidef_set_led_wlan "wlan" "WLAN" "alfa:blue:wlan" "phy0tpt"
ucidef_set_led_usbdev "usb" "USB" "alfa:blue:usb" "1-1"
;;
+lbe-m5)
+ ucidef_set_led_netdev "lan" "LAN" "ubnt:green:lan" "eth0"
+ ucidef_set_led_wlan "wlan" "WLAN" "ubnt:green:wlan" "phy0tpt"
+ ;;
mc-mac1200r)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "mercury:green:wlan2g" "phy1tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "mercury:green:wlan5g" "phy0tpt"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index fb61792bf4..86d6ffd91d 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -78,6 +78,7 @@ ar71xx_setup_interfaces()
fritz300e|\
gl-usb150|\
hiveap-121|\
+ lbe-m5|\
loco-m-xw|\
mr12|\
mr16|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 5c60ebd6a8..5042e7a008 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -236,6 +236,9 @@ get_status_led() {
jwap230)
status_led="$board:green:led1"
;;
+ lbe-m5)
+ status_led="ubnt:green:sys"
+ ;;
ls-sr71)
status_led="ubnt:green:d22"
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b5440230a5..00a4acc6e0 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -711,6 +711,9 @@ ar71xx_board_detect() {
*"Lima"*)
name="lima"
;;
+ *"Litebeam M5"*)
+ name="lbe-m5"
+ ;;
*"Loco M XW")
name="loco-m-xw"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index ecf6820a2b..4e839f12c1 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -248,6 +248,7 @@ platform_check_image() {
hiwifi-hc6361|\
hornet-ub-x2|\
jwap230|\
+ lbe-m5|\
lima|\
loco-m-xw|\
mzk-w04nu|\
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
index 55cf52d19e..8afb3ad054 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -503,6 +504,60 @@ static void __init ubnt_loco_m_xw_setup(void)
ath79_register_eth(0);
}
+#define UBNT_LBE_M5_GPIO_LED_LAN 13
+#define UBNT_LBE_M5_GPIO_LED_WLAN 14
+#define UBNT_LBE_M5_GPIO_LED_SYS 16
+
+static struct gpio_led ubnt_lbe_m5_leds_gpio[] __initdata = {
+ {
+ .name = "ubnt:green:lan",
+ .gpio = UBNT_LBE_M5_GPIO_LED_LAN,
+ .active_low = 1,
+ }, {
+ .name = "ubnt:green:wlan",
+ .gpio = UBNT_LBE_M5_GPIO_LED_WLAN,
+ .active_low = 1,
+ }, {
+ .name = "ubnt:green:sys",
+ .gpio = UBNT_LBE_M5_GPIO_LED_SYS,
+ .active_low = 1,
+ },
+};
+
+static void __init ubnt_lbe_m5_setup(void)
+{
+ u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff);
+
+ ath79_register_m25p80
Re: [LEDE-DEV] [PATCH] curl: Switch all TLS libraries to use ca-bundle.
On 25/01/18 04:29, Rosen Penev wrote: On Wed, Jan 24, 2018 at 1:56 PM, Hauke Mehrtens wrote: On 01/24/2018 05:28 AM, Rosen Penev wrote: At least one application (transmission) depends on CURL_CA_BUNDLE being set in order to operate properly (Could not connect to tracker errors). As far as I can tell, there's no real drawback to doing this for all TLS libraries supported by curl. Do all of these libraries support --with-ca-bundle ? OpenSSL I know does. GnuTLS most likely does as it seems to be geared towards desktop systems. Hi, "most likely" is not good enough. please compile/runtime test your patches for all possible combos before posting them. John Signed-off-by: Rosen Penev --- package/network/utils/curl/Makefile | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/package/network/utils/curl/Makefile b/package/network/utils/curl/Makefile index 17fcf70..930bd10 100644 --- a/package/network/utils/curl/Makefile +++ b/package/network/utils/curl/Makefile @@ -111,13 +111,15 @@ CONFIGURE_ARGS += \ --without-nss \ --without-libmetalink \ --without-librtmp \ + --without-ca-path \ + --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt \ \ $(call autoconf_bool,CONFIG_IPV6,ipv6) \ \ - $(if $(CONFIG_LIBCURL_WOLFSSL),--with-cyassl="$(STAGING_DIR)/usr" --without-ca-path --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-cyassl) \ - $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr" --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-gnutls) \ - $(if $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr" --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-ssl) \ - $(if $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr" --without-ca-path --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-mbedtls) \ + $(if $(CONFIG_LIBCURL_WOLFSSL),--with-cyassl="$(STAGING_DIR)/usr",--without-cyassl) \ + $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr",--without-gnutls) \ + $(if $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr",--without-ssl) \ + $(if $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr",--without-mbedtls) \ \ $(if $(CONFIG_LIBCURL_LIBIDN),--with-libidn="$(STAGING_DIR)/usr",--without-libidn) \ $(if $(CONFIG_LIBCURL_SSH2),--with-libssh2="$(STAGING_DIR)/usr",--without-libssh2) \ ___ 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] brcm63xx not booting on newer kernels (JFFS2)
Hi Jonas, thanks for bringing kernel 4.9 and 4.14 to the brcm63xx target and therefore keeping them as 'active' devices (regarding development). I just tried 4.9 and 4.14 on my AV4202 and can't fully boot the thing due to JFFS2 errors. Already erased the whole main image and reflashed it via CFE, same results. The kernel correctly processes and detects the partition layout like in 4.4 rootfs_data's begin has moved from 0x36 to 0x3A (due to larger rootfs and/or kernel) Attached is the serial bootlog from 4.9 (4.14 is similar) Thanks for your support and let me know if I can provide further information, P. Wassi [0.00] Linux version 4.9.77 (buildbot@builds) (gcc version 5.5.0 (OpenWrt GCC 5.5.0 r6038-13e8d54) ) #0 Mon Feb 12 14:21:43 2018 [0.00] Detected Broadcom 0x6368 CPU revision b2 [0.00] CPU frequency is 400 MHz [0.00] 64MB of RAM installed [0.00] board_bcm963xx: Boot address 0xb800 [0.00] board_bcm963xx: CFE version: 1.0.37-102.6 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 0002a031 (Broadcom BMIPS4350) [0.00] board: board name: 96368_Swiss_S1 [0.00] MIPS: machine is ADB P.DG AV4202N [0.00] Determined physical RAM map: [0.00] memory: 0400 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 16 bytes. [0.00] Primary data cache 32kB, 2-way, VIPT, cache aliases, linesize 16 bytes [0.00] Zone ranges: [0.00] Normal [mem 0x-0x03ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] Initmem setup node 0 [mem 0x-0x03ff] [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 [0.00] Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 [0.00] PID hash table entries: 256 (order: -2, 1024 bytes) [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Memory: 58648K/65536K available (3518K kernel code, 178K rwdata, 964K rodata, 1284K init, 217K bss, 6888K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:256 [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 9556302233 ns [0.29] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns [0.008162] Calibrating delay loop... 397.82 BogoMIPS (lpj=795648) [0.042911] pid_max: default: 32768 minimum: 301 [0.048054] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.054864] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.082829] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [0.092906] futex hash table entries: 256 (order: -1, 3072 bytes) [0.099389] pinctrl core: initialized pinctrl subsystem [0.108951] NET: Registered protocol family 16 [0.135883] registering PCI controller with io_map_base unset [0.141826] registering PCI controller with io_map_base unset [0.185795] PCI host bridge to bus :00 [0.190072] pci_bus :00: root bus resource [mem 0x3000-0x37ff] [0.197158] pci_bus :00: root bus resource [io 0x800-0x8007fff] [0.204062] pci_bus :00: root bus resource [??? 0x flags 0x0] [0.211057] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] [0.227790] pci :00:01.0: BAR 0: assigned [mem 0x3000-0x30003fff] [0.235861] PCI host bridge to bus :01 [0.240107] pci_bus :01: root bus resource [mem 0x3800-0x3fff] [0.247187] pci_bus :01: root bus resource [io 0x8008000-0x800] [0.254094] pci_bus :01: root bus resource [??? 0x flags 0x0] [0.261080] pci_bus :01: No busn resource found for root bus, will use [bus 01-ff] [0.270342] pci :01:1e.0: bridge configuration invalid ([bus 00-00]), reconfiguring [0.279244] pci :01:1e.0: BAR 10: assigned [mem 0x3800-0x3fff] [0.286364] pci :01:1e.0: BAR 7: assigned [io 0x8008000-0x80080ff] [0.293187] pci :01:1e.0: BAR 8: assigned [io 0x8008400-0x80084ff] [0.38] pci :01:1e.0: CardBus bridge to [bus 02-05] [0.305745] pci :01:1e.0: bridge window [io 0x8008000-0x80080ff] [0.312558] pci :01:1e.0: bridge window [io 0x8008400-0x80084ff] [0.319367] pci :01:1e.0: bridge window [mem 0x3800-0x3fff] [0.336288] clocksource: Switched to clocksource MIPS [0.346380] PCI: Enabling device :00:01.0 ( -> 0002) [0.38
[LEDE-DEV] [PATCH] uqmi: bump package release
fixes: da8990e717e1 ("uqmi: use built-in command for data-link verification")
Signed-off-by: Koen Vandeputte
---
package/network/utils/uqmi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/network/utils/uqmi/Makefile
b/package/network/utils/uqmi/Makefile
index 16e4a5a9118e..21b3c7eba690 100644
--- a/package/network/utils/uqmi/Makefile
+++ b/package/network/utils/uqmi/Makefile
@@ -1,7 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=uqmi
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/uqmi.git
--
2.7.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] imx6: update to Linux 4.14
On 01/02/18 23:35, Tim Harvey wrote: Tested on a Gateworks GW54xx Tim Harvey (4): kernel: add missing config symbols imx6: add support for Linux 4.14 imx6: switch to kernel 4.14 imx6: remove support for 4.9 Hi, karl and hauke posted some comments to the series. I've marked the whole series as "changes requested". please send a v3 with them incorporated. John target/linux/generic/config-4.14 | 9 +- target/linux/imx6/Makefile | 2 +- target/linux/imx6/config-4.14 | 526 + target/linux/imx6/config-4.9 | 497 .../files-4.9/arch/arm/boot/dts/imx6dl-gw5904.dts | 19 - .../files-4.9/arch/arm/boot/dts/imx6q-gw5904.dts | 23 - .../arch/arm/boot/dts/imx6qdl-gw5904.dtsi | 629 - target/linux/imx6/patches-4.14/100-bootargs.patch | 11 + .../linux/imx6/patches-4.14/200-disable-msi.patch | 18 + .../imx6/patches-4.14/300-fix-enumeration.patch| 11 + ...-imx-add-gateworks-ventana-gw5904-support.patch | 18 - target/linux/imx6/patches-4.9/100-bootargs.patch | 11 - .../linux/imx6/patches-4.9/200-disable-msi.patch | 22 - .../imx6/patches-4.9/210-disable-uart-dma.patch| 23 - 14 files changed, 575 insertions(+), 1244 deletions(-) create mode 100644 target/linux/imx6/config-4.14 delete mode 100644 target/linux/imx6/config-4.9 delete mode 100644 target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6dl-gw5904.dts delete mode 100644 target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6q-gw5904.dts delete mode 100644 target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6qdl-gw5904.dtsi create mode 100644 target/linux/imx6/patches-4.14/100-bootargs.patch create mode 100644 target/linux/imx6/patches-4.14/200-disable-msi.patch create mode 100644 target/linux/imx6/patches-4.14/300-fix-enumeration.patch delete mode 100644 target/linux/imx6/patches-4.9/0001-arm-dts-imx-add-gateworks-ventana-gw5904-support.patch delete mode 100644 target/linux/imx6/patches-4.9/100-bootargs.patch delete mode 100644 target/linux/imx6/patches-4.9/200-disable-msi.patch delete mode 100644 target/linux/imx6/patches-4.9/210-disable-uart-dma.patch ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
