Re: [LEDE-DEV] [PATCH lede-17.01 1/4] x86/generic: use HIGHMEM64G instead of HIGHMEM4G to fix PAE and Xen
Hi, On 25-07-17, Sven Roederer wrote: > On Samstag, 15. Juli 2017 22:57:53 CEST Baptiste Jonglez wrote: > > From: Baptiste Jonglez > > > > This is a backport of 641a65fd062987a456216cc4fa91ff2910528261 in master. > > > > This change re-enables PAE for the 32-bit x86 subtarget, which is > > interesting in its own right but also necessary for Xen support. > > > > Baptiste, > > thanks for fixing the Xen and Xen-serial-console support. > i added these patches to out Freifunk-builds and can happily run this images > on my vm-host again. Glad to hear that it also works for you! > Hope they will find their way into the repo soon. This patch series was merged in master but not yet in lede-17.01. I don't know if another 17.01 point release is expected, but I think it should be merged in any case. Baptiste signature.asc Description: PGP signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 4/4] ramips/RT5350F-OLINUXINO(-EVB) dts: enable ttyS1
The RT5350F's second UART pins are available on the base module and on
the EVB as well, so enable it in the device tree.
Additionaly, the uartlite@c00 and uart@500 nodes swapped in rt5350.dtsi
to keep the serial console as ttyS0.
Signed-off-by: Zoltan Gyarmati
---
target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi | 11 +-
target/linux/ramips/dts/rt5350.dtsi| 30 +-
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
index 955a13cddd..1632f3c085 100644
--- a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
+++ b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
@@ -46,9 +46,13 @@
&pinctrl {
state_default: pinctrl0 {
gpio {
- ralink,group = "jtag", "rgmii", "mdio", "uartf";
+ ralink,group = "jtag", "rgmii", "mdio";
ralink,function = "gpio";
};
+ uartf_gpio {
+ ralink,group = "uartf";
+ ralink,function = "gpio uartf";
+ };
};
};
@@ -77,3 +81,8 @@
&i2c {
status = "okay";
};
+
+&uart {
+ status = "okay";
+};
+
diff --git a/target/linux/ramips/dts/rt5350.dtsi
b/target/linux/ramips/dts/rt5350.dtsi
index a92c113043..f027e17d9d 100644
--- a/target/linux/ramips/dts/rt5350.dtsi
+++ b/target/linux/ramips/dts/rt5350.dtsi
@@ -83,21 +83,6 @@
interrupts = <3>;
};
- uart: uart@500 {
- compatible = "ralink,rt5350-uart",
"ralink,rt2880-uart", "ns16550a";
- reg = <0x500 0x100>;
-
- resets = <&rstctrl 12>;
- reset-names = "uart";
-
- interrupt-parent = <&intc>;
- interrupts = <5>;
-
- reg-shift = <2>;
-
- status = "disabled";
- };
-
gpio0: gpio@600 {
compatible = "ralink,rt5350-gpio", "ralink,rt2880-gpio";
reg = <0x600 0x34>;
@@ -221,6 +206,21 @@
reg-shift = <2>;
};
+ uart: uart@500 {
+ compatible = "ralink,rt5350-uart",
"ralink,rt2880-uart", "ns16550a";
+ reg = <0x500 0x100>;
+
+ resets = <&rstctrl 12>;
+ reset-names = "uart";
+
+ interrupt-parent = <&intc>;
+ interrupts = <5>;
+
+ reg-shift = <2>;
+
+ status = "disabled";
+ };
+
systick: systick@d00 {
compatible = "ralink,rt5350-systick",
"ralink,cevt-systick";
reg = <0xd00 0x10>;
--
2.14.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 3/4] ramips/RT5350F-OLINUXINO(-EVB) dts: enable i2c
The RT5350F i2c pins is available on the base module and on
the EVB as well, so enable it in the dts.
Signed-off-by: Zoltan Gyarmati
---
target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
index 784001c0d5..955a13cddd 100644
--- a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
+++ b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
@@ -73,3 +73,7 @@
&ohci {
status = "okay";
};
+
+&i2c {
+ status = "okay";
+};
--
2.14.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/4] ramips/RT5350F-OLINUXINO(-EVB) dts: introduce RT5350F-OLINUXINO.dtsi
The RT5350F-OLINUXINO(-EVB).dts files' content are nearly the same, so to avoid
code duplication this patch creates RT5350F-OLINUXINO.dtsi file which
covers the base board's features. The corresponding RT5350F-OLINUXINO.dts
just includes the new .dtsi and the RT5350F-OLINUXINO-EVB.dts adds the EVB
specific GPIO config.
Signed-off-by: Zoltan Gyarmati
---
target/linux/ramips/dts/RT5350F-OLINUXINO-EVB.dts | 71 +-
target/linux/ramips/dts/RT5350F-OLINUXINO.dts | 71 +-
target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi| 74 +++
3 files changed, 76 insertions(+), 140 deletions(-)
create mode 100644 target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO-EVB.dts
b/target/linux/ramips/dts/RT5350F-OLINUXINO-EVB.dts
index 7811ee20d7..5c7b3c7c42 100644
--- a/target/linux/ramips/dts/RT5350F-OLINUXINO-EVB.dts
+++ b/target/linux/ramips/dts/RT5350F-OLINUXINO-EVB.dts
@@ -1,6 +1,6 @@
/dts-v1/;
-#include "rt5350.dtsi"
+#include "RT5350F-OLINUXINO.dtsi"
#include
@@ -30,72 +30,3 @@
};
};
};
-
-&spi0 {
- status = "okay";
-
- m25p80@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <1000>;
-
- partition@0 {
- label = "u-boot";
- reg = <0x0 0x3>;
- read-only;
- };
-
- partition@3 {
- label = "u-boot-env";
- reg = <0x3 0x1>;
- read-only;
- };
-
- factory: partition@4 {
- label = "factory";
- reg = <0x4 0x1>;
- read-only;
- };
-
- partition@5 {
- label = "firmware";
- reg = <0x5 0x7b>;
- };
- };
-};
-
-&gpio1 {
- status = "okay";
-};
-
-&pinctrl {
- state_default: pinctrl0 {
- gpio {
- ralink,group = "jtag", "rgmii", "mdio", "uartf";
- ralink,function = "gpio";
- };
- };
-};
-
-ðernet {
- mtd-mac-address = <&factory 0x4>;
-};
-
-&esw {
- mediatek,portmap = <0x2f>;
- mediatek,led_polarity = <0x17>;
-};
-
-&wmac {
- ralink,mtd-eeprom = <&factory 0>;
-};
-
-&ehci {
- status = "okay";
-};
-
-&ohci {
- status = "okay";
-};
diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO.dts
b/target/linux/ramips/dts/RT5350F-OLINUXINO.dts
index 6ee3daeaa1..2e0dcb1558 100644
--- a/target/linux/ramips/dts/RT5350F-OLINUXINO.dts
+++ b/target/linux/ramips/dts/RT5350F-OLINUXINO.dts
@@ -1,77 +1,8 @@
/dts-v1/;
-#include "rt5350.dtsi"
+#include "RT5350F-OLINUXINO.dtsi"
/ {
compatible = "olimex,rt5350f-olinuxino", "ralink,rt5350-soc";
model = "Olimex RT5350F-OLinuXino";
};
-
-&spi0 {
- status = "okay";
-
- m25p80@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <1000>;
-
- partition@0 {
- label = "u-boot";
- reg = <0x0 0x3>;
- read-only;
- };
-
- partition@3 {
- label = "u-boot-env";
- reg = <0x3 0x1>;
- read-only;
- };
-
- factory: partition@4 {
- label = "factory";
- reg = <0x4 0x1>;
- read-only;
- };
-
- partition@5 {
- label = "firmware";
- reg = <0x5 0x7b>;
- };
- };
-};
-
-&gpio1 {
- status = "okay";
-};
-
-&pinctrl {
- state_default: pinctrl0 {
- gpio {
- ralink,group = "jtag", "rgmii", "mdio", "uartf";
- ralink,function = "gpio";
- };
- };
-};
-
-ðernet {
- mtd-mac-address = <&factory 0x4>;
-};
-
-&esw {
- mediatek,portmap = <0x2f>;
- mediatek,led_polarity = <0x17>;
-};
-
-&wmac {
- ralink,mtd-eeprom = <&factory 0>;
-};
-
-&ehci {
- status = "okay";
-};
-
-&ohci {
- status = "okay";
-};
diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
new file mode 100644
index 00..f5bf84
--- /dev/null
+++ b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
@@ -0,0 +1,74 @@
+#include "rt5350.dtsi"
+
+/ {
+ compatible = "olimex,rt5350f-olinuxino", "ralink,rt5350-soc";
+};
+
+&spi0 {
+
[LEDE-DEV] [PATCH 0/4] ramips/RT5350F-OLINUXINO(-EVB) improve device tree support
This patchset aims to improve the device tree support for the RT5350F-OLINUXINO(-EVB) boards. Some of the changes are coming from the HW vendor's own OpenWrt fork at https://github.com/OLIMEX/openwrt which is rather outdated by now, so i've synced/rebased the patches and tested them. Zoltan Gyarmati (4): ramips/RT5350F-OLINUXINO(-EVB) dts: introduce RT5350F-OLINUXINO.dtsi ramips/RT5350F-OLINUXINO(-EVB) dts: invert WiFi LED polarity ramips/RT5350F-OLINUXINO(-EVB) dts: enable i2c ramips/RT5350F-OLINUXINO(-EVB) dts: enable ttyS1 target/linux/ramips/dts/RT5350F-OLINUXINO-EVB.dts | 71 +- target/linux/ramips/dts/RT5350F-OLINUXINO.dts | 71 +- target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi| 88 +++ target/linux/ramips/dts/rt5350.dtsi | 30 4 files changed, 105 insertions(+), 155 deletions(-) create mode 100644 target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi -- 2.14.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/4] ramips/RT5350F-OLINUXINO(-EVB) dts: invert WiFi LED polarity
The polarity of WLAN_ACT LED on the base module needs to inverted
in order to be 'on' when the WiFi interface is active
Signed-off-by: Zoltan Gyarmati
---
target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
index f5bf84..784001c0d5 100644
--- a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
+++ b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
@@ -63,6 +63,7 @@
&wmac {
ralink,mtd-eeprom = <&factory 0>;
+ ralink,led-polarity = <1>;
};
&ehci {
--
2.14.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621
Hi, On Sat, Aug 26, 2017 at 4:47 PM, Kristian Evensen wrote: > I guess our common theory is that something is causing TX interrupts > not to be enabled again. After reading up on NAPI > (https://wiki.linuxfoundation.org/networking/napi), it seems that the > recommended way of using NAPI on clear-on-write devices (like the > RT5350) is to use NAPI for RX and do TX in the interrupt handler. In > the current driver, both TX and RX is handled in the NAPI-callback > fe_poll(). I have modified the driver to split RX and TX, so now > fe_poll() only deals with RX and TX is dealt with in fe_handle_irq(). > I have attached the (messy) patch I am currently testing. If this is > an OK solution, I will clean up the patch and submit is to the list. I > will leave my tests running overnight and report back if anything pops > up. I did not have to wait very long before anything. Unfortunately, my router crashed right after I sent the previous email. So I guess that means back to the drawing board. -Kristian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621
Hello again,
On Sat, Aug 26, 2017 at 12:38 PM, Kristian Evensen
wrote:
> Hi,
>
> On Sat, Aug 26, 2017 at 7:43 AM, Mingyu Li wrote:
>> Hi.
>>
>> i check the code again. found xmit_more can cause tx timeout. you can
>> reference this.
>> https://www.mail-archive.com/netdev@vger.kernel.org/msg123334.html
>> so the patch should be like this. edit mtk_eth_soc.c
>>
>> tx_num = fe_cal_txd_req(skb);
>> if (unlikely(fe_empty_txd(ring) <= tx_num)) {
>> +if (skb->xmit_more)
>> +fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
>> netif_stop_queue(dev);
>> netif_err(priv, tx_queued, dev,
>> "Tx Ring full when queue awake!\n");
>>
>> but i am not sure. maybe the pause frame cause the problem.
>
> Thanks for the patch. I tested it, but I unfortunately still see the
> error. I also added a print-statement inside the conditional and can
> see that the condition is never hit. I also don't see the "Tx Ring
> full"-message. One difference which I noticed now though, is that I
> don't see the bursty bandwidth pattern I described earlier (32, 0, 32,
> 0, ...). With your patch, it is always 32, 0, crash.
I spent some more time looking into this today and think I might have
been able to solve the issue. My test has been running for ~2 hours
now without any errors (before it would best-case work for 10-15
minutes), and I do not see any performance regressions. Before going
into detail, I should probably point out that I am not very familiar
with driver development, so my observation changes might not be
appropriate/correct :)
I guess our common theory is that something is causing TX interrupts
not to be enabled again. After reading up on NAPI
(https://wiki.linuxfoundation.org/networking/napi), it seems that the
recommended way of using NAPI on clear-on-write devices (like the
RT5350) is to use NAPI for RX and do TX in the interrupt handler. In
the current driver, both TX and RX is handled in the NAPI-callback
fe_poll(). I have modified the driver to split RX and TX, so now
fe_poll() only deals with RX and TX is dealt with in fe_handle_irq().
I have attached the (messy) patch I am currently testing. If this is
an OK solution, I will clean up the patch and submit is to the list. I
will leave my tests running overnight and report back if anything pops
up.
I guess that Johns new driver is the future for mtk_sock_eth, but I
believe that fixing this issue for the current driver is worthwhile.
As things are now, is it possible to DDOS RT5350-based routers running
LEDE 17.01 by just sending the correct type of traffic.
-Kristian
From 98ce0313cd8654fe69028c19b6f08da1d0671d75 Mon Sep 17 00:00:00 2001
From: Kristian Evensen
Date: Sat, 26 Aug 2017 16:05:44 +0200
Subject: [PATCH] [FIX] Move TX out of Napi
This is a broken patch only meant for backup.
---
.../drivers/net/ethernet/mtk/mtk_eth_soc.c | 36 +-
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
index 5b354a6563..af865826e8 100644
--- a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
+++ b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
@@ -684,10 +684,13 @@ static int fe_tx_map_dma(struct sk_buff *skb, struct net_device *dev,
*/
wmb();
if (unlikely(fe_empty_txd(ring) <= ring->tx_thresh)) {
+pr_info_ratelimited("netif_stop_queue %u %u\n", fe_empty_txd(ring), ring->tx_thresh);
netif_stop_queue(dev);
smp_mb();
- if (unlikely(fe_empty_txd(ring) > ring->tx_thresh))
+ if (unlikely(fe_empty_txd(ring) > ring->tx_thresh)) {
+pr_info_ratelimited("netif_wake_queue\n");
netif_wake_queue(dev);
+}
}
if (netif_xmit_stopped(netdev_get_tx_queue(dev, 0)) || !skb->xmit_more)
@@ -781,6 +784,10 @@ static int fe_start_xmit(struct sk_buff *skb, struct net_device *dev)
tx_num = fe_cal_txd_req(skb);
if (unlikely(fe_empty_txd(ring) <= tx_num)) {
+if (skb->xmit_more) {
+pr_info_ratelimited("SKB XMIT_MORE\n");
+fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
+}
netif_stop_queue(dev);
netif_err(priv, tx_queued, dev,
"Tx Ring full when queue awake!\n");
@@ -967,11 +974,12 @@ static int fe_poll(struct napi_struct *napi, int budget)
status_reg = FE_REG_FE_INT_STATUS;
}
+/*
if (status & tx_intr) {
fe_reg_w32(tx_intr, FE_REG_FE_INT_STATUS);
tx_done = fe_poll_tx(priv);
status = fe_reg_r32(FE_REG_FE_INT_STATUS);
- }
+ }*/
if (status & rx_intr)
rx_done = fe_poll_rx(napi, budget, priv, rx_intr);
@@ -1042,18 +1050,30 @@ static irqreturn_t fe_handle_irq(int irq, void *dev)
{
struct fe_priv *priv = netdev_priv(dev);
u32 status, int_mask;
+u32 tx_intr, rx_intr;
+
+ tx_intr = priv->soc->tx_int;
+ rx_in
[LEDE-DEV] [PATCH] scripts/dowload.pl: use glob to expand target dir
If CONFIG_DOWNLOAD_FOLDER is set to for example "~/dl", the download script fails to create the .hash and .dl files with the following errors: Cannot create file ~/dl/dropbear-2017.75.tar.bz2.dl: No such file or directory sh: 1: cannot create ~/dl/dropbear-2017.75.tar.bz2.hash: Directory nonexistent If the tarball already exists in the ~/dl dir, it's properly found and used, so this issue only affects the download.pl script. This patch calls glob() on the target dir parameter, which will expand `~`. --- scripts/download.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/download.pl b/scripts/download.pl index 645ac8546c..bf9fe8c761 100755 --- a/scripts/download.pl +++ b/scripts/download.pl @@ -16,7 +16,7 @@ use Text::ParseWords; @ARGV > 2 or die "Syntax: $0 [ ...]\n"; my $url_filename; -my $target = shift @ARGV; +my $target = glob(shift @ARGV); my $filename = shift @ARGV; my $file_hash = shift @ARGV; $url_filename = shift @ARGV unless $ARGV[0] =~ /:\/\//; -- 2.14.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm63xx: Add Sercomm AD1018 support
2017-08-26 12:26 GMT+02:00 Jonas Gorski :
> Hi,
>> +};
>> +
>> +&leds {
>> + status = "ok";
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_led0 &pinctrl_led1 &pinctrl_serial_led
>> +&pinctrl_ephy0_spd_led &pinctrl_ephy1_act_led
>> +&pinctrl_ephy2_act_led &pinctrl_ephy3_act_led>;
>
> What's up with ephy1~3 using act, but 0 using the spd led? is this
> intentional?
Yes, it is intentional. The "FIBRE" port (port0) uses an spd LED
whereas the rest of "LAN1-3" (ports3-1) use act LEDs.
>> +
>> + brcm,serial-leds;
>> + brcm,serial-shift-inv;
>> + brcm,serial-dat-low;
>> +
>> + inet_red@0 {
>> + reg = <0>;
>> + active-low;
>> + label = "AD1018:red:internet";
>> + };
>> +
>> + inet_green@1 {
>> + reg = <1>;
>> + active-low;
>> + label = "AD1018:green:internet";
>> + };
>> +
>> + power_green@8 {
>> + reg = <8>;
>> + active-low;
>> + label = "AD1018:green:power";
>> + default-state = "on";
>> + };
>> +
>> + adsl_green@10 {
>> + reg = <10>;
>> + active-low;
>> + label = "AD1018:green:adsl";
>> + };
>> +
>> + adsl_red@11 {
>> + reg = <11>;
>> + active-low;
>> + label = "AD1018:red:adsl";
>> + };
>> + phone_green@12 {
>> + reg = <12>;
>> + active-low;
>> + label = "AD1018:green:phone";
>> + };
>> +
>> + wps_green@13 {
>> + reg = <13>;
>> + active-low;
>> + label = "AD1018:green:wps";
>> + };
>> +
>> + wifi_green@14 {
>> + reg = <14>;
>> + active-low;
>> + label = "AD1018:green:wifi";
>> + };
>> +
>> + ephy0_spd@17 {
>> + reg = <17>;
>> + brcm,hardware-controlled;
>> + };
>> +};
>> +
>> +&hsspi {
>> + status = "ok";
>> +
>> + flash@0 {
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <1667>;
>> + spi-tx-bus-width = <2>;
>> + spi-rx-bus-width = <2>;
>> + reg = <0>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + linux,part-probe = "bcm63xxpart";
>
> Partitions please.
>
I would prefer leave it without partitioning. This way we can use an
8, 16 or 32 MB SPI NOR flash without redefining partitions with a
custom firmware.
Regards
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621
Hi,
On Sat, Aug 26, 2017 at 7:43 AM, Mingyu Li wrote:
> Hi.
>
> i check the code again. found xmit_more can cause tx timeout. you can
> reference this.
> https://www.mail-archive.com/netdev@vger.kernel.org/msg123334.html
> so the patch should be like this. edit mtk_eth_soc.c
>
> tx_num = fe_cal_txd_req(skb);
> if (unlikely(fe_empty_txd(ring) <= tx_num)) {
> +if (skb->xmit_more)
> +fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
> netif_stop_queue(dev);
> netif_err(priv, tx_queued, dev,
> "Tx Ring full when queue awake!\n");
>
> but i am not sure. maybe the pause frame cause the problem.
Thanks for the patch. I tested it, but I unfortunately still see the
error. I also added a print-statement inside the conditional and can
see that the condition is never hit. I also don't see the "Tx Ring
full"-message. One difference which I noticed now though, is that I
don't see the bursty bandwidth pattern I described earlier (32, 0, 32,
0, ...). With your patch, it is always 32, 0, crash.
-Kristian
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] sdk: automatically use all CPU cores for xz
On 18 August 2017 at 15:06, Karl Palsson wrote: > > Bjørn Mork wrote: >> This looks yucky. Experimenting a bit, I see that the result >> with >> >> a) -T 0 depends on multi-core vs single-core >> b) -T 1 is always different from the output of -T x where x > 1 >> c) -T x where x > 1 is independent of both x and the actual number of >> cores >> >> So you will not get reproducible results with either "-T 0" or >> "-T ". > > Sure, but -T 0 will be ok for _any_ computer with more than one > core. Which is enough of them now, and enough for people doing > builds that care about reproducibility, and certainly enough of > them to appreciate the dramatically sped up builds. To get this discussion further I, if getting the -j value is far from easy, especially in a portable way (as googling suggest), I suggest adding a config option for enabling parallel XZ compression, either as a bool or directly as a integer for the amount of threads to use, defaulting to n/1. The int option is probably the best as it gives the most control over it. Then those that case about speed can enable it/set it 0, and those that want to use their PC for other things at the same time can leave it at 1 or an appropriate value so it doesn't take over the whole system during compression. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm63xx: Add Sercomm AD1018 support
Hi,
On 20 August 2017 at 17:32, Daniel Gonzalez Cabanelas wrote:
> Add support for the Sercomm AD1018 router
>
> This a BCM6328 based board, 128 MB RAM, 128 MiB NAND flash,
> with an onboard BCM43217 wifi, 4 ethernet ports and 1 USB
> host port (not soldered).
>
> Since NAND flash chips aren't still supported in brcm63xx, the
> support is for now added to work only with SPI flash chips. Therefore
> hardware modding for soldering a new SPI flash chip is required
> to make the board work with LEDE (tested and working OK).
>
> Signed-off-by: Daniel Gonzalez Cabanelas
> ---
> .../linux/brcm63xx/base-files/etc/board.d/01_leds | 3 +
> .../brcm63xx/base-files/etc/board.d/02_network | 1 +
> target/linux/brcm63xx/base-files/etc/diag.sh | 3 +
> target/linux/brcm63xx/base-files/lib/brcm63xx.sh | 3 +
> target/linux/brcm63xx/dts/ad1018.dts | 132
> +
> target/linux/brcm63xx/image/bcm63xx.mk | 12 ++
> .../brcm63xx/patches-4.4/580-board_AD1018.patch| 99
> 7 files changed, 253 insertions(+)
> create mode 100644 target/linux/brcm63xx/dts/ad1018.dts
> create mode 100644 target/linux/brcm63xx/patches-4.4/580-board_AD1018.patch
>
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> index ef70cde..5503328 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> @@ -15,6 +15,9 @@ a4001n1)
> a4001n)
> ucidef_set_led_usbdev "usb" "USB" "A4001N:green:usb" "1-1"
> ;;
> +ad1018)
> + ucidef_set_led_netdev "wlan0" "WLAN" "AD1018:green:wifi" "wlan0"
> + ;;
> ar-5315u)
> ucidef_set_led_usbdev "usb" "USB" "AR-5315u:green:usb" "1-1"
> ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> index 9addba6..826d271 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> @@ -98,6 +98,7 @@ vr-3026e)
> "0:lan:1" "1:lan:2" "2:lan:3" "3:lan:4" "8t@eth0"
> ;;
>
> +ad1018 |\
> ar-5315u |\
> vh4032n)
> ucidef_add_switch "switch0" \
> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh
> b/target/linux/brcm63xx/base-files/etc/diag.sh
> index 700c9ea..2663a2c 100644
> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
> @@ -12,6 +12,9 @@ set_state() {
> a4001n)
> status_led="A4001N:green:power"
> ;;
> + ad1018)
> + status_led="AD1018:green:power"
> + ;;
> ar-5315u)
> status_led="AR-5315u:green:power"
> ;;
> diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> index 3f46633..ae67d9b 100755
> --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> @@ -228,6 +228,9 @@ brcm63xx_dt_detect() {
> "Sagem F@ST2704V2")
> board_name="fast2704v2"
> ;;
> + "Sercomm AD1018")
> + board_name="ad1018"
> + ;;
> "SFR Neuf Box 4"*)
> board_name="neufbox4"
> ;;
> diff --git a/target/linux/brcm63xx/dts/ad1018.dts
> b/target/linux/brcm63xx/dts/ad1018.dts
> new file mode 100644
> index 000..b2c8654
> --- /dev/null
> +++ b/target/linux/brcm63xx/dts/ad1018.dts
> @@ -0,0 +1,132 @@
> +/dts-v1/;
> +
> +#include "bcm6328.dtsi"
> +
> +#include
> +
> +/ {
> + model = "Sercomm AD1018";
> + compatible = "sercomm,ad1018", "brcm,bcm6328";
Since this is a modified version, I would suggest naming it ad1018-nor
/ "Sercomm AD1018 (NOR)", in case we ever support the NAND variant to
tell them apart. Or "Sercomm AD1018 (SPI flash mod)" as you used in
the device definition.
This doesn't need to be reflected i the led naming, so we can just
move the common part into a .dtsi file when adding support for the
original NAND variant.
> +
> + chosen {
> + bootargs = "root=/dev/mtdblock2 rootfstype=squashfs,jffs2
> noinitrd console=ttyS0,115200";
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <20>;
> + debounce-interval = <60>;
> +
> + wps {
> + label = "wps";
> + gpios = <&pinctrl 24 1>;
> + linux,code = ;
> + };
> + wifi {
> + label = "wifi";
> + gpios = <&pinctrl 25 1>;
> + linux,code = ;
> + };
> + r
Re: [LEDE-DEV] IPv6 link locals, vlans and bridging
On 25/08/17 14:54, Baptiste Jonglez wrote: On 25-08-17, Kevin Darbyshire-Bryant wrote: Are you sure it's related to your complex bridging setup? Maybe dnsmasq just fails to answer on link-local IPv6 addresses in all cases? This was already reported before: https://bugs.lede-project.org/index.php?do=details&task_id=677 Baptiste Hi Baptiste, So now everything is working perfectly. I have apparently changed nothing (in that I've returned everything back to normal after some testing/fiddling) dnsmasq correctly responds to requests to link-local addresses both on the router (which it always did) and from a variety of clients. I'm totally confused. What I *am* becoming increasingly suspicious of is clients ability to understand the interface identifier syntax found in resolv.conf .eg. %wlan0 ie. nameserver fe80::62e3:27ff:feaf:9e50%wlan0 (Actually I was very impressed that the dhcpv6 client understood the fact it has received a link local address fe80::62e3:27ff:feaf:9e50 and knew to add the interface id!) I'm doing a little bit of playing with 'dnseval' and that doesn't get link-local interface id syntax. Confused, Kevin ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] GPIO-JTAG: Compex WPQ864:
Hello, My immediate need is to figure out if some pins on a Compex WPQ864 are free to be used as GPIO pins. Compex guys have said that JTAG pins can be used. Can someone in this community guide me regarding this? 1. I have read the documentation files from the code base, like GPIO.txt, gpio-legacy.txt, board.txt, consumer.txt etc., and got some idea of how to use GPIOs. But I don't seem to get hold of a starting point. 2. I can't figure out where in the code is the GPIO mapping to be found? How to change a JTAG into a GPIO, and vice versa? How to fill in the dev argument for the get/set/direction/put calls of gpiod_*? If I get to know the code location of GPIO mapping, perhaps I can figure out the con_id argument for these calls. -- Regards, Neeraj Sallh ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
