[OpenWrt-Devel] [PATCH] ramips: fix switch names for several boards in device tree
Signed-off-by: Roman Yeryomin
---
target/linux/ramips/dts/F5D8235_V1.dts | 4 ++--
target/linux/ramips/dts/F5D8235_V2.dts | 2 +-
target/linux/ramips/dts/WL-351.dts | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/linux/ramips/dts/F5D8235_V1.dts
b/target/linux/ramips/dts/F5D8235_V1.dts
index 9026d82..2e88abd 100644
--- a/target/linux/ramips/dts/F5D8235_V1.dts
+++ b/target/linux/ramips/dts/F5D8235_V1.dts
@@ -68,8 +68,8 @@
ralink,mtd-eeprom = <&u-boot 0x4>;
};
*/
- rtl8367s {
- compatible = "realtek,rtl8367s";
+ rtl8366s {
+ compatible = "realtek,rtl8366s";
gpio-sda = <&gpio0 1 0>;
gpio-sck = <&gpio0 2 0>;
};
diff --git a/target/linux/ramips/dts/F5D8235_V2.dts
b/target/linux/ramips/dts/F5D8235_V2.dts
index 7eaf165..792249c 100644
--- a/target/linux/ramips/dts/F5D8235_V2.dts
+++ b/target/linux/ramips/dts/F5D8235_V2.dts
@@ -63,7 +63,7 @@
};
rtl8366rb {
- compatible = "rtl8367rb";
+ compatible = "rtl8366rb";
gpio-sda = <&gpio0 1 0>;
gpio-sck = <&gpio0 2 0>;
};
diff --git a/target/linux/ramips/dts/WL-351.dts
b/target/linux/ramips/dts/WL-351.dts
index fd30160..81c963b 100644
--- a/target/linux/ramips/dts/WL-351.dts
+++ b/target/linux/ramips/dts/WL-351.dts
@@ -106,7 +106,7 @@
};
rtl8366rb {
- compatible = "rtl8367rb";
+ compatible = "rtl8366rb";
gpio-sda = <&gpio0 1 0>;
gpio-sck = <&gpio0 2 0>;
};
--
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] rpcd, iwinfo: add support for vendor_elements
Signed-off-by: Roman Yeryomin
---
iwinfo.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/iwinfo.c b/iwinfo.c
index 325c07a..6e34ea1 100644
--- a/iwinfo.c
+++ b/iwinfo.c
@@ -317,6 +317,41 @@ rpc_iwinfo_info(struct ubus_context *ctx, struct
ubus_object *obj,
return UBUS_STATUS_OK;
}
+static void
+rpc_iwinfo_add_ve(const char *name, struct iwinfo_scanlist_entry *e)
+{
+ void *c, *d;
+ char oui[7];
+ char *data = NULL;
+ int datalen, i, di;
+
+ d = blobmsg_open_array(&buf, name);
+ for (i = 0; i < IWINFO_VE_MAX; i++) {
+ if (e->ve[i].len < 1)
+ break;
+ c = blobmsg_open_table(&buf, NULL);
+
+ snprintf(oui, sizeof(oui), "%02x%02x%02x", e->ve[i].oui[0],
+ e->ve[i].oui[1],
+ e->ve[i].oui[2]);
+ blobmsg_add_string(&buf, "oui", oui);
+
+ datalen = e->ve[i].len * 2;
+ data = (char *)malloc(datalen + 1);
+ if (!data) {
+ blobmsg_close_table(&buf, c);
+ break;
+ }
+ for (di = 0; di < e->ve[i].len - sizeof(e->ve[i].oui); di++)
+ snprintf(data + di * 2, 3, "%02x", e->ve[i].data[di]);
+ blobmsg_add_string(&buf, "data", data);
+ free(data);
+
+ blobmsg_close_table(&buf, c);
+ }
+ blobmsg_close_array(&buf, d);
+}
+
static int
rpc_iwinfo_scan(struct ubus_context *ctx, struct ubus_object *obj,
struct ubus_request_data *req, const char *method,
@@ -325,7 +360,7 @@ rpc_iwinfo_scan(struct ubus_context *ctx, struct
ubus_object *obj,
int i, rv, len;
void *c, *d;
char mac[18];
- char res[IWINFO_BUFSIZE];
+ char res[IWINFO_MAX_APS * sizeof(struct iwinfo_scanlist_entry)];
struct iwinfo_scanlist_entry *e;
rv = rpc_iwinfo_open(msg);
@@ -363,6 +398,10 @@ rpc_iwinfo_scan(struct ubus_context *ctx, struct
ubus_object *obj,
rpc_iwinfo_add_encryption("encryption", &e->crypto);
+ /* add vendor elements if exist */
+ if (e->ve[0].len)
+ rpc_iwinfo_add_ve("vendor_elements", e);
+
blobmsg_close_table(&buf, d);
}
}
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] iwinfo, nl80211: add support for vendor_elements
Signed-off-by: Roman Yeryomin
---
include/iwinfo.h | 9 +
iwinfo_cli.c | 2 +-
iwinfo_nl80211.c | 7 +++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 95020a4..856525e 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -21,7 +21,9 @@
#define IWINFO_BUFSIZE 24 * 1024
+#define IWINFO_MAX_APS 100
#define IWINFO_ESSID_MAX_SIZE 32
+#define IWINFO_VE_MAX 10
#define IWINFO_80211_A (1 << 0)
#define IWINFO_80211_B (1 << 1)
@@ -119,6 +121,12 @@ struct iwinfo_crypto_entry {
uint8_t auth_algs;
};
+struct iwinfo_ve_entry {
+ uint8_t len;
+ uint8_t oui[3];
+ uint8_t data[255];
+};
+
struct iwinfo_scanlist_entry {
uint8_t mac[6];
uint8_t ssid[IWINFO_ESSID_MAX_SIZE+1];
@@ -128,6 +136,7 @@ struct iwinfo_scanlist_entry {
uint8_t quality;
uint8_t quality_max;
struct iwinfo_crypto_entry crypto;
+ struct iwinfo_ve_entry ve[IWINFO_VE_MAX];
};
struct iwinfo_country_entry {
diff --git a/iwinfo_cli.c b/iwinfo_cli.c
index ed6be54..85f232a 100644
--- a/iwinfo_cli.c
+++ b/iwinfo_cli.c
@@ -565,7 +565,7 @@ static void print_info(const struct iwinfo_ops *iw, const
char *ifname)
static void print_scanlist(const struct iwinfo_ops *iw, const char *ifname)
{
int i, x, len;
- char buf[IWINFO_BUFSIZE];
+ char buf[IWINFO_MAX_APS * sizeof(struct iwinfo_scanlist_entry)];
struct iwinfo_scanlist_entry *e;
if (iw->scanlist(ifname, buf, &len))
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index efc58e6..8c595cd 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -1859,6 +1859,7 @@ static void nl80211_get_scanlist_ie(struct nlattr **bss,
unsigned char *ie = nla_data(bss[NL80211_BSS_INFORMATION_ELEMENTS]);
static unsigned char ms_oui[3] = { 0x00, 0x50, 0xf2 };
int len;
+ int vei = 0;
while (ielen >= 2 && ielen >= ie[1])
{
@@ -1876,6 +1877,12 @@ static void nl80211_get_scanlist_ie(struct nlattr **bss,
break;
case 221: /* Vendor */
+ if (ie[1] >= 4 && vei < IWINFO_VE_MAX) {
+ e->ve[vei].len = ie[1];
+ memcpy(e->ve[vei].oui, ie + 2, 3);
+ memcpy(e->ve[vei].data, ie + 5, ie[1] - 3);
+ vei++;
+ }
if (ie[1] >= 4 && !memcmp(ie + 2, ms_oui, 3) && ie[5]
== 1)
iwinfo_parse_rsn(&e->crypto, ie + 6, ie[1] - 4,
IWINFO_CIPHER_TKIP,
IWINFO_KMGMT_PSK);
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] hostapd: allow to set vendor_elements via /etc/config/wireless
Signed-off-by: Roman Yeryomin
---
package/network/services/hostapd/files/netifd.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/package/network/services/hostapd/files/netifd.sh
b/package/network/services/hostapd/files/netifd.sh
index 23d2e7e..1d1b098 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -164,6 +164,8 @@ hostapd_common_add_bss_config() {
config_add_int mcast_rate
config_add_array basic_rate
config_add_array supported_rates
+
+ config_add_string 'vendor_elements:string'
}
hostapd_set_bss_options() {
@@ -437,6 +439,9 @@ hostapd_set_bss_options() {
) > "$_macfile"
}
+ json_get_vars vendor_elements
+ [ -n "$vendor_elements" ] && append bss_conf
"vendor_elements=$vendor_elements" "$N"
+
append "$var" "$bss_conf" "$N"
return 0
}
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing "fastpath" - Kernel module for speeding up IP forwarding
On 23 December 2014 at 17:02, Tomer Eliyahu wrote: > Hi, > > Our request for uploading the sources is pending approval from > Marvell's legal department. > Hi, Tomer, do you have any updates on this? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Linux 4.x
On 6 June 2015 at 09:21, Dirk Neukirchen wrote: > On 05.06.2015 16:00, Baptiste Clenet wrote: >> Hi OpenWRT developers, >> >> Is there any plan to port OPENWRT on Linux 4.x? (Or is it already done?) >> >> > > > - ar71xx: ar8216/ar8316/ar8xxx driver is broken > on 8337N and some unknown router (reported yesterday on IRC) > look at [3] if anybody is interested That was me, probably. I'm trying 4.0.4 on several ar71xx routers/APs, mostly Ubiquiti. All have the same problem: http://p.tet.rtu.lv/pbzn5sspm/wvtsep/raw I think the problem is inside ag71xx (ethernet driver) and related to timers and/or interrupts but not sure. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 7 May 2015 at 15:49, Felix Fietkau wrote: > On 2015-05-07 08:01, Wojciech Dubowik wrote: >> Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on >> readdir. As far as I remember >> with this patch it went through but I don't know anymore whether I have >> changed sth in config. >> >> Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for >> spi nor flash. >> >> Even with this patch I got some possible dead lock warnings so it might >> be just a partial cure. BTW it's >> a bit scary for future use. Looks like jffs2 doesn't get enough care... > I believe the locking issues are an overlayfs regression, maybe even > the same one as this one (which I fixed years ago): > http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged > > I believe this is the cause of the regression: > > commit 49c21e1cacd74a8c83407c70ad860c994e606e25 > Author: Miklos Szeredi > Date: Sat Dec 13 00:59:42 2014 +0100 > I'm working on 4.0 support for ar71xx and found that /etc/rc.d/S00sysfixtime is not able to finish it's job after second boot after flashing (t.i. after overlayfs is switched to jffs). I've run strace and found that find hangs on the very last getdents64 call (before calling it succesfully many times on previous files/directories). I've reverted every change up to 49c21e1cacd74a8c83407c70ad860c994e606e25 to overlayfs and it started working. Applying 49c21e1cacd74a8c83407c70ad860c994e606e25 back breaks it. So this commit is indeed the cause of regression. Miklos, any ideas how to fix it in current tree? I'm using 4.0.5 now but AFAIK there were no more changes to overlayfs. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink MT76228 port to Linux 4.0, set new IP address fail
On 11 June 2015 at 16:36, Baptiste Clenet wrote: > Hi, > > I've edited patches from Linux 3.18 to make the MT7628 work with Linux 4.0. > OpenWRT launches, I have access to the shell. > Next step, I configure the IP address with /etc/config/network and > /etc/init.d/network reload. Ifconfig shows me my new address IP. > > But, I can't connect via ssh to my board and if I reboot the board, I > get errors at boot: > [ 10.23] jffs2: jffs2_scan_inode_node(): CRC failed on node at > 0x004725bc: Read 0x, calculated 0x149094b5 > I would say it appears one hundred times with different calculated CRC. > and finally the last line is: > [ 11.00] jffs2: notice: (305) jffs2_build_xattr_subsystem: > complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) > and 0 of xref (0 dead, 0 orphan) found. > > > Then, I'm able to access to the shell but I still can't connect via > ssh. The board constantly reports: > > [ 2410.01] ralink_soc_eth 1010.ethernet eth0: transmit timed out > [ 2410.02] ralink_soc_eth 1010.ethernet eth0: dma_cfg:0055 > [ 2410.03] ralink_soc_eth 1010.ethernet eth0: tx_ring=0, > base=00dce000, max=128, ctx=126, dtx=126, fdx=123 > [ 2410.05] ralink_soc_eth 1010.ethernet eth0: rx_ring=0, > base=01a36000, max=128, calc=121, drx=54 > [ 2415.01] ralink_soc_eth 1010.ethernet eth0: transmit timed out > [ 2415.02] ralink_soc_eth 1010.ethernet eth0: dma_cfg:0055 > [ 2415.03] ralink_soc_eth 1010.ethernet eth0: tx_ring=0, > base=00dce000, max=128, ctx=126, dtx=126, fdx=123 > [ 2415.05] ralink_soc_eth 1010.ethernet eth0: rx_ring=0, > base=01a36000, max=128, calc=121, drx=60 > > It seems to be related to ethernet driver. Does anyone know those errors? > I have the "transmit queue time out" error on ar71xx with 4.0.5 also. Situation is very similar because ralink and ar71xx ethernet drivers are maintained in OpenWrt only. I believe it is related to recent timer/clock changes in kernel (in 3.19 AFAIK). But I don't know neither timers nor network Linux stack so well to tell what/where is the problem exactly. If somebody with more experience could point to a possible place to look at that would be awesome. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink MT76228 port to Linux 4.0, set new IP address fail
On 12 June 2015 at 14:30, Baptiste Clenet wrote: > 2015-06-12 11:12 GMT+02:00 Baptiste Clenet : >> 2015-06-11 16:31 GMT+02:00 Roman Yeryomin : >>> On 11 June 2015 at 16:36, Baptiste Clenet wrote: >>>> Hi, >>>> >>>> I've edited patches from Linux 3.18 to make the MT7628 work with Linux 4.0. >>>> OpenWRT launches, I have access to the shell. >>>> Next step, I configure the IP address with /etc/config/network and >>>> /etc/init.d/network reload. Ifconfig shows me my new address IP. >>>> >>>> But, I can't connect via ssh to my board and if I reboot the board, I >>>> get errors at boot: >>>> [ 10.23] jffs2: jffs2_scan_inode_node(): CRC failed on node at >>>> 0x004725bc: Read 0x, calculated 0x149094b5 >>>> I would say it appears one hundred times with different calculated CRC. >>>> and finally the last line is: >>>> [ 11.00] jffs2: notice: (305) jffs2_build_xattr_subsystem: >>>> complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) >>>> and 0 of xref (0 dead, 0 orphan) found. >>>> >>>> >>>> Then, I'm able to access to the shell but I still can't connect via >>>> ssh. The board constantly reports: >>>> >>>> [ 2410.01] ralink_soc_eth 1010.ethernet eth0: transmit timed out >>>> [ 2410.02] ralink_soc_eth 1010.ethernet eth0: dma_cfg:0055 >>>> [ 2410.03] ralink_soc_eth 1010.ethernet eth0: tx_ring=0, >>>> base=00dce000, max=128, ctx=126, dtx=126, fdx=123 >>>> [ 2410.05] ralink_soc_eth 1010.ethernet eth0: rx_ring=0, >>>> base=01a36000, max=128, calc=121, drx=54 >>>> [ 2415.01] ralink_soc_eth 1010.ethernet eth0: transmit timed out >>>> [ 2415.02] ralink_soc_eth 1010.ethernet eth0: dma_cfg:0055 >>>> [ 2415.03] ralink_soc_eth 1010.ethernet eth0: tx_ring=0, >>>> base=00dce000, max=128, ctx=126, dtx=126, fdx=123 >>>> [ 2415.05] ralink_soc_eth 1010.ethernet eth0: rx_ring=0, >>>> base=01a36000, max=128, calc=121, drx=60 >>>> >>>> It seems to be related to ethernet driver. Does anyone know those errors? >>>> >>> >>> I have the "transmit queue time out" error on ar71xx with 4.0.5 also. >>> Situation is very similar because ralink and ar71xx ethernet drivers >>> are maintained in OpenWrt only. >>> I believe it is related to recent timer/clock changes in kernel (in >>> 3.19 AFAIK). But I don't know neither timers nor network Linux stack >>> so well to tell what/where is the problem exactly. >>> >>> If somebody with more experience could point to a possible place to >>> look at that would be awesome. >>> >>> >>> Regards, >>> Roman >> >> Ok, let's see if someone can bring his knowledge on those parts and help us. >> Thanks >> >> Baptiste > > > I'm adding some details about the bug. after reloading > /etc/init.d/network (with an IP modified), WATCHDOG raises an error: > > root@OpenWrt:/# [ 6426.01] [ cut here ] > [ 6426.01] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:303 > dev_watchdog+0x1d8/0x25c() > [ 6426.03] NETDEV WATCHDOG: eth0 (ralink_soc_eth): transmit queue > 0 timed out yes, exactly the same issue here with ar71xx: http://p.tet.rtu.lv/pbzn5sspm/wvtsep/raw ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink MT76228 port to Linux 4.0, set new IP address fail
On 12 June 2015 at 19:45, Baptiste Clenet wrote:
> Watchdog problem solved thanks to Mingyu Li.
> Patch the file ralink_soc_eth.c
>
> @@ -983,8 +983,11 @@ static int fe_poll(struct napi_struct *napi, int budget)
>
> if (!tx_again && (rx_done < budget)) {
> status = fe_reg_r32(FE_REG_FE_INT_STATUS);
> - if (status & (tx_intr | rx_intr ))
> + if (status & (tx_intr | rx_intr )) {
> + /* let napi poll again */
> + rx_done = budget;
> goto poll_again;
> + }
>
> napi_complete(napi);
>
> This solution is related to the ralink board only.
>
OK, similar fix works for ag71xx, will submit a patch...
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ar71xx: fix ethernet for 4.0
Tested on UAP-PRO. Doesn't break 3.18
Signed-off-by: Roman Yeryomin
---
.../files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c | 8 ++--
1 file changed, 6 insertions(+), 2 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 5ef324e..269be75 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
@@ -1060,12 +1060,16 @@ static int ag71xx_poll(struct napi_struct *napi, int
limit)
}
if (rx_done < limit) {
- if (status & RX_STATUS_PR)
+ if (status & RX_STATUS_PR) {
+ rx_done = limit;
goto more;
+ }
status = ag71xx_rr(ag, AG71XX_REG_TX_STATUS);
- if (status & TX_STATUS_PS)
+ if (status & TX_STATUS_PS) {
+ rx_done = limit;
goto more;
+ }
DBG("%s: disable polling mode, rx=%d, tx=%d,limit=%d\n",
dev->name, rx_done, tx_done, limit);
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 11 June 2015 at 13:25, Roman Yeryomin wrote: > On 7 May 2015 at 15:49, Felix Fietkau wrote: >> On 2015-05-07 08:01, Wojciech Dubowik wrote: >>> Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on >>> readdir. As far as I remember >>> with this patch it went through but I don't know anymore whether I have >>> changed sth in config. >>> >>> Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for >>> spi nor flash. >>> >>> Even with this patch I got some possible dead lock warnings so it might >>> be just a partial cure. BTW it's >>> a bit scary for future use. Looks like jffs2 doesn't get enough care... >> I believe the locking issues are an overlayfs regression, maybe even >> the same one as this one (which I fixed years ago): >> http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged >> >> I believe this is the cause of the regression: >> >> commit 49c21e1cacd74a8c83407c70ad860c994e606e25 >> Author: Miklos Szeredi >> Date: Sat Dec 13 00:59:42 2014 +0100 >> > > I'm working on 4.0 support for ar71xx and found that > /etc/rc.d/S00sysfixtime is not able to finish it's job after second > boot after flashing (t.i. after overlayfs is switched to jffs). I've > run strace and found that find hangs on the very last getdents64 call > (before calling it succesfully many times on previous > files/directories). > I've reverted every change up to > 49c21e1cacd74a8c83407c70ad860c994e606e25 to overlayfs and it started > working. Applying 49c21e1cacd74a8c83407c70ad860c994e606e25 back breaks > it. So this commit is indeed the cause of regression. > > Miklos, any ideas how to fix it in current tree? I'm using 4.0.5 now > but AFAIK there were no more changes to overlayfs. > Felix, John, Should I send a patch reverting all changes to overlayfs up to that commit until there is a proper fix? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 15 June 2015 at 15:52, Miklos Szeredi wrote:
> On Mon, Jun 15, 2015 at 10:24:28AM +0200, Felix Fietkau wrote:
>> On 2015-06-15 10:20, Miklos Szeredi wrote:
>> > On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi wrote:
>> >> On 7 May 2015 at 15:49, Felix Fietkau wrote:
>> >>> On 2015-05-07 08:01, Wojciech Dubowik wrote:
>> Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on
>> readdir. As far as I remember
>> with this patch it went through but I don't know anymore whether I have
>> changed sth in config.
>>
>> Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for
>> spi nor flash.
>>
>> Even with this patch I got some possible dead lock warnings so it might
>> be just a partial cure. BTW it's
>> a bit scary for future use. Looks like jffs2 doesn't get enough care...
>> >>> I believe the locking issues are an overlayfs regression, maybe even
>> >>> the same one as this one (which I fixed years ago):
>> >>> http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged
>> >>>
>> >>> I believe this is the cause of the regression:
>> >>>
>> >>> commit 49c21e1cacd74a8c83407c70ad860c994e606e25
>> >>> Author: Miklos Szeredi
>> >>> Date: Sat Dec 13 00:59:42 2014 +0100
>> >>>
>> >>
>> >> I'm working on 4.0 support for ar71xx and found that
>> >> /etc/rc.d/S00sysfixtime is not able to finish it's job after second
>> >> boot after flashing (t.i. after overlayfs is switched to jffs). I've
>> >> run strace and found that find hangs on the very last getdents64 call
>> >> (before calling it succesfully many times on previous
>> >> files/directories).
>> >> I've reverted every change up to
>> >> 49c21e1cacd74a8c83407c70ad860c994e606e25 to overlayfs and it started
>> >> working. Applying 49c21e1cacd74a8c83407c70ad860c994e606e25 back breaks
>> >> it. So this commit is indeed the cause of regression.
>> >>
>> >> Miklos, any ideas how to fix it in current tree? I'm using 4.0.5 now
>> >> but AFAIK there were no more changes to overlayfs.
>> >
>> > What's the full mount setup? (cat /proc/mounts)
>> /dev/root /rom squashfs ro,relatime 0 0
>> proc /proc proc rw,noatime 0 0
>> sysfs /sys sysfs rw,noatime 0 0
>> tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
>> /dev/mtdblock8 /overlay jffs2 rw,noatime 0 0
>> overlayfs:/overlay / overlay
>> rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0
>> tmpfs /dev tmpfs rw,relatime,size=512k,mode=755 0 0
>> devpts /dev/pts devpts rw,relatime,mode=600 0 0
>> debugfs /sys/kernel/debug debugfs rw,noatime 0 0
>>
>> - Felix
>
>
> Following patch should fix the locking issue.
>
> Please test.
>
It worked! Thanks Miklos!
Felix, attaching tested and ready to commit patch.
Or do you want me to send it separately to the list?
Regards,
Roman
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -23,6 +23,7 @@ struct ovl_cache_entry {
u64 ino;
struct list_head l_node;
struct rb_node node;
+ struct ovl_cache_entry *next_maybe_whiteout;
bool is_whiteout;
char name[];
};
@@ -39,7 +40,7 @@ struct ovl_readdir_data {
struct rb_root root;
struct list_head *list;
struct list_head middle;
- struct dentry *dir;
+ struct ovl_cache_entry *first_maybe_whiteout;
int count;
int err;
};
@@ -79,7 +80,7 @@ static struct ovl_cache_entry *ovl_cache
return NULL;
}
-static struct ovl_cache_entry *ovl_cache_entry_new(struct dentry *dir,
+static struct ovl_cache_entry *ovl_cache_entry_new(struct ovl_readdir_data *rdd,
const char *name, int len,
u64 ino, unsigned int d_type)
{
@@ -98,29 +99,8 @@ static struct ovl_cache_entry *ovl_cache
p->is_whiteout = false;
if (d_type == DT_CHR) {
- struct dentry *dentry;
- const struct cred *old_cred;
- struct cred *override_cred;
-
- override_cred = prepare_creds();
- if (!override_cred) {
- kfree(p);
- return NULL;
- }
-
- /*
- * CAP_DAC_OVERRIDE for lookup
- */
- cap_raise(override_cred->cap_effective, CAP_DAC_OVERRIDE);
- old_cred = override_creds(override_cred);
-
- dentry = lookup_one_len(name, dir, len);
- if (!IS_ERR(dentry)) {
- p->is_whiteout = ovl_is_whiteout(dentry);
- dput(dentry);
- }
- revert_creds(old_cred);
- put_cred(override_cred);
+ p->next_maybe_whiteout = rdd->first_maybe_whiteout;
+ rdd->first_maybe_whiteout = p;
}
return p;
}
@@ -148,7 +128,7 @@ static int ovl_cache_entry_add_rb(struct
return 0;
}
- p = ovl_cache_entry_new(rdd->dir, name, len, ino, d_type);
+ p = ovl_cache_entry_new(rdd, name, len, ino, d_type);
if (p == NULL)
return -ENOMEM;
@@ -169,7 +149,7 @@ static int ovl_fill_lower(struct ovl_rea
if (p) {
list_move_tail(&p->l_node, &rdd->middle);
} else {
- p = ovl_cache_entry_new(rdd->dir, name, namelen, ino, d_type);
+ p = ovl_cache_entry_new(rdd, name, namelen, ino, d_type);
if (p == NULL)
rdd->err = -ENOMEM;
else
@@ -219,6 +199,43 @@ static int ovl_fill_merge(struc
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: add 4.0 support
On 14 June 2015 at 20:15, Roman Yeryomin wrote: > Tested on UAP-PRO > Please discard this, it's broken because of 45954. I will send rebased version. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] ar71xx/image: move ubnt images to new BuildCode
On 7 June 2015 at 15:27, Alexander Couzens wrote: > Signed-off-by: Alexander Couzens > --- > target/linux/ar71xx/image/Makefile | 264 > - > 1 file changed, 175 insertions(+), 89 deletions(-) > At least UAP-PRO image is broken after this (applied in 45983): MIPS: machine is Generic AR71XX/AR724X/AR913X based board Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: add 4.0 support
On 15 June 2015 at 19:09, Daniel Golle wrote: > On Mon, Jun 15, 2015 at 06:15:58PM +0300, Roman Yeryomin wrote: >> On 14 June 2015 at 20:15, Roman Yeryomin wrote: >> > Tested on UAP-PRO >> > >> >> Please discard this, it's broken because of 45954. >> I will send rebased version. > > Yes, I saw that and manually fixed it to test on TL-WDR3500. > Apart from the breakage introduced by r45954 (which was trivial to fix) > everything seems to work well. > > Thanks for the good work! > Did you have any problems with overlayfs? Or did you apply the patch from parallel thread? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mac80211: ath9k: fix qca956x name also
Signed-off-by: Roman Yeryomin
---
.../patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch | 8
1 file changed, 8 insertions(+)
diff --git
a/package/kernel/mac80211/patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch
b/package/kernel/mac80211/patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch
index 2674efb..c005c00 100644
---
a/package/kernel/mac80211/patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch
+++
b/package/kernel/mac80211/patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch
@@ -18,3 +18,11 @@ Signed-off-by: Felix Fietkau
}
val = REG_READ(ah, AR_SREV) & AR_SREV_ID;
+@@ -3169,6 +3170,7 @@ static struct {
+ { AR_SREV_VERSION_9550, "9550" },
+ { AR_SREV_VERSION_9565, "9565" },
+ { AR_SREV_VERSION_9531, "9531" },
++ { AR_SREV_VERSION_9561, "956X" },
+ };
+
+ /* For devices with external radios */
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: rework patch for qca953x/956x
On 2 July 2015 at 09:49, wrote:
> From: Miaoqing Pan
>
> Patch cherry-picked from the following location:
> https://www.codeaurora.org/cgit/quic/qsdk/oss/system/openwrt/commit/?h=release/coconut_ioe4531_2.0&id=5c357bf6c763e4140dddcc9a3bc5f005525a9c0e
>
> Changelist,
> - add more register defines
> - add EHCI support
> - fix GPIO pin count to 18
> - fix chained irq disabled
> - fix GMAC0/GMAC1 initial
> - fix WMAC irq number to 47
> - merge the changes of dev-eth.c from the patch to file.
>
> Signed-off-by: Miaoqing Pan
> ---
> .../linux/ar71xx/files/arch/mips/ath79/dev-eth.c | 18 +-
> ...07-MIPS-ath79-add-support-for-QCA953x-SoC.patch | 352
> +
> ...35-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 183 ---
> .../736-MIPS-ath79-fix-chained-irq-disable.patch | 21 +-
> 4 files changed, 387 insertions(+), 187 deletions(-)
>
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
> b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
> index ae3db4c..ff94e2e 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
> @@ -198,6 +198,8 @@ void __init ath79_register_mdio(unsigned int id, u32
> phy_mask)
> case ATH79_SOC_AR9330:
> case ATH79_SOC_AR9331:
> case ATH79_SOC_QCA9533:
> + case ATH79_SOC_QCA9561:
> + case ATH79_SOC_TP9343:
> mdio_dev = &ath79_mdio1_device;
> mdio_data = &ath79_mdio1_data;
> break;
> @@ -256,6 +258,8 @@ void __init ath79_register_mdio(unsigned int id, u32
> phy_mask)
> break;
>
> case ATH79_SOC_QCA9533:
> + case ATH79_SOC_QCA9561:
> + case ATH79_SOC_TP9343:
> mdio_data->builtin_switch = 1;
> break;
>
> @@ -571,6 +575,8 @@ static void __init ath79_init_eth_pll_data(unsigned int
> id)
> case ATH79_SOC_QCA9533:
> case ATH79_SOC_QCA9556:
> case ATH79_SOC_QCA9558:
> + case ATH79_SOC_QCA9561:
> + case ATH79_SOC_TP9343:
> pll_10 = AR934X_PLL_VAL_10;
> pll_100 = AR934X_PLL_VAL_100;
> pll_1000 = AR934X_PLL_VAL_1000;
> @@ -627,6 +633,8 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
> case ATH79_SOC_AR9330:
> case ATH79_SOC_AR9331:
> case ATH79_SOC_QCA9533:
> + case ATH79_SOC_QCA9561:
> + case ATH79_SOC_TP9343:
> pdata->phy_if_mode = PHY_INTERFACE_MODE_MII;
> break;
>
> @@ -687,7 +695,8 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
> case ATH79_SOC_AR7241:
> case ATH79_SOC_AR9330:
> case ATH79_SOC_AR9331:
> - case ATH79_SOC_QCA9533:
> + case ATH79_SOC_QCA9561:
> + case ATH79_SOC_TP9343:
> pdata->phy_if_mode = PHY_INTERFACE_MODE_GMII;
> break;
>
> @@ -697,6 +706,7 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
> case ATH79_SOC_AR9341:
> case ATH79_SOC_AR9342:
> case ATH79_SOC_AR9344:
> + case ATH79_SOC_QCA9533:
> switch (pdata->phy_if_mode) {
> case PHY_INTERFACE_MODE_MII:
> case PHY_INTERFACE_MODE_GMII:
> @@ -986,6 +996,7 @@ void __init ath79_register_eth(unsigned int id)
> case ATH79_SOC_AR9341:
> case ATH79_SOC_AR9342:
> case ATH79_SOC_AR9344:
> + case ATH79_SOC_QCA9533:
> if (id == 0) {
> pdata->reset_bit = AR934X_RESET_GE0_MAC |
>AR934X_RESET_GE0_MDIO;
> @@ -1017,7 +1028,8 @@ void __init ath79_register_eth(unsigned int id)
> pdata->fifo_cfg3 = 0x01f00140;
> break;
>
> - case ATH79_SOC_QCA9533:
> + case ATH79_SOC_QCA9561:
> + case ATH79_SOC_TP9343:
> if (id == 0) {
> pdata->reset_bit = AR933X_RESET_GE0_MAC |
>AR933X_RESET_GE0_MDIO;
> @@ -1123,6 +1135,8 @@ void __init ath79_register_eth(unsigned int id)
> case ATH79_SOC_AR9330:
> case ATH79_SOC_AR9331:
> case ATH79_SOC_QCA9533:
> + case ATH79_SOC_QCA9561:
> + case ATH79_SOC_TP9343:
> pdata->mii_bus_dev = &ath79_mdio1_device.dev;
> break;
>
This will not work for e.g. qca9563 (which has the same id as QCA9561)
because it has single ethernet MAC (GMAC0) which works in SGMII mode
only.
I have several patches regarding qca ethernet in my queue. Not sure
they are correct for 100% cases but will submit them for evaluation.
Regards,
Roman
__
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: rework patch for qca953x/956x
Yes, sorry, forgot to mention it's broken now too.
On 2 July 2015 at 12:34, Pan, Miaoqing wrote:
> No logic changes of qca956x. Just move the eth changes out of the 735 patch
> to 'dev-eth.c' file.
>
> Regards,
> Miaoqing
>
> -Original Message-
> From: Roman Yeryomin [mailto:leroi.li...@gmail.com]
> Sent: Thursday, July 02, 2015 4:55 PM
> To: Pan, Miaoqing
> Cc: OpenWrt Development List
> Subject: Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: rework patch for qca953x/956x
>
> On 2 July 2015 at 09:49, wrote:
>> From: Miaoqing Pan
>>
>> Patch cherry-picked from the following location:
>> https://www.codeaurora.org/cgit/quic/qsdk/oss/system/openwrt/commit/?h
>> =release/coconut_ioe4531_2.0&id=5c357bf6c763e4140dddcc9a3bc5f005525a9c
>> 0e
>>
>> Changelist,
>> - add more register defines
>> - add EHCI support
>> - fix GPIO pin count to 18
>> - fix chained irq disabled
>> - fix GMAC0/GMAC1 initial
>> - fix WMAC irq number to 47
>> - merge the changes of dev-eth.c from the patch to file.
>>
>> Signed-off-by: Miaoqing Pan
>> ---
>> .../linux/ar71xx/files/arch/mips/ath79/dev-eth.c | 18 +-
>> ...07-MIPS-ath79-add-support-for-QCA953x-SoC.patch | 352
>> + ...35-MIPS-ath79-add-support-for-QCA956x-SoC.patch |
>> 183 ---
>> .../736-MIPS-ath79-fix-chained-irq-disable.patch | 21 +-
>> 4 files changed, 387 insertions(+), 187 deletions(-)
>>
>> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
>> b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
>> index ae3db4c..ff94e2e 100644
>> --- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
>> +++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
>> @@ -198,6 +198,8 @@ void __init ath79_register_mdio(unsigned int id, u32
>> phy_mask)
>> case ATH79_SOC_AR9330:
>> case ATH79_SOC_AR9331:
>> case ATH79_SOC_QCA9533:
>> + case ATH79_SOC_QCA9561:
>> + case ATH79_SOC_TP9343:
>> mdio_dev = &ath79_mdio1_device;
>> mdio_data = &ath79_mdio1_data;
>> break;
>> @@ -256,6 +258,8 @@ void __init ath79_register_mdio(unsigned int id, u32
>> phy_mask)
>> break;
>>
>> case ATH79_SOC_QCA9533:
>> + case ATH79_SOC_QCA9561:
>> + case ATH79_SOC_TP9343:
>> mdio_data->builtin_switch = 1;
>> break;
>>
>> @@ -571,6 +575,8 @@ static void __init ath79_init_eth_pll_data(unsigned int
>> id)
>> case ATH79_SOC_QCA9533:
>> case ATH79_SOC_QCA9556:
>> case ATH79_SOC_QCA9558:
>> + case ATH79_SOC_QCA9561:
>> + case ATH79_SOC_TP9343:
>> pll_10 = AR934X_PLL_VAL_10;
>> pll_100 = AR934X_PLL_VAL_100;
>> pll_1000 = AR934X_PLL_VAL_1000; @@ -627,6 +633,8 @@
>> static int __init ath79_setup_phy_if_mode(unsigned int id,
>> case ATH79_SOC_AR9330:
>> case ATH79_SOC_AR9331:
>> case ATH79_SOC_QCA9533:
>> + case ATH79_SOC_QCA9561:
>> + case ATH79_SOC_TP9343:
>> pdata->phy_if_mode = PHY_INTERFACE_MODE_MII;
>> break;
>>
>> @@ -687,7 +695,8 @@ static int __init ath79_setup_phy_if_mode(unsigned int
>> id,
>> case ATH79_SOC_AR7241:
>> case ATH79_SOC_AR9330:
>> case ATH79_SOC_AR9331:
>> - case ATH79_SOC_QCA9533:
>> + case ATH79_SOC_QCA9561:
>> + case ATH79_SOC_TP9343:
>> pdata->phy_if_mode = PHY_INTERFACE_MODE_GMII;
>> break;
>>
>> @@ -697,6 +706,7 @@ static int __init ath79_setup_phy_if_mode(unsigned int
>> id,
>> case ATH79_SOC_AR9341:
>> case ATH79_SOC_AR9342:
>> case ATH79_SOC_AR9344:
>> + case ATH79_SOC_QCA9533:
>> switch (pdata->phy_if_mode) {
>> case PHY_INTERFACE_MODE_MII:
>> case PHY_INTERFACE_MODE_GMII:
>> @@ -986,6 +996,7 @@ void __init ath79_register_eth(unsigned int id)
>> case ATH79_SOC_AR9341:
>> case ATH79_SOC_AR9342:
>> case ATH79_SOC_AR9344:
>> + case ATH79_SOC_QCA9533:
>> if (id == 0) {
>>
[OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images
- it should be BOARDNAME instead of BOARD_NAME - kernel partition should be padded to 1536k (somehow this padding was lost in translation to BuildCode in bc797c73f6328941b2194d144385655ad9297e7c) Signed-off-by: Roman Yeryomin --- target/linux/ar71xx/image/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 3956927..3ca52dd 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -852,18 +852,18 @@ define Device/ubnt-uap-pro MTDPARTS := spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1536k(kernel),14208k(rootfs),256k(cfg)ro,64k(EEPROM)ro,15744k@0x5(firmware) UBNT_TYPE := BZ UBNT_CHIP := ar934x - BOARD_NAME := UAP-PRO + BOARDNAME := UAP-PRO DEVICE_PROFILE := UBNT UAPPRO KERNEL := kernel-bin | patch-cmdline | lzma | uImage lzma | mkubntkernelimage IMAGES := sysupgrade.bin factory.bin - IMAGE/sysupgrade.bin = append-kernel (BLOCKSIZE) | append-rootfs | pad-rootfs | check-size (IMAGE_SIZE) - IMAGE/factory.bin = append-kernel (BLOCKSIZE) | append-rootfs | pad-rootfs | check-size (IMAGE_SIZE) | mkubntimage2 + IMAGE/sysupgrade.bin = append-kernel 1536k | append-rootfs | pad-rootfs | check-size (IMAGE_SIZE) + IMAGE/factory.bin = $$(IMAGE/sysupgrade.bin) | mkubntimage2 endef define Device/ubnt-unifi-outdoor-plus $(Device/ubnt-uap-pro) UBNT_CHIP := ar7240 - BOARD_NAME := UBNT-UOP + BOARDNAME := UBNT-UOP DEVICE_PROFILE := UBNT endef -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images
On 5 July 2015 at 22:05, Alexander Couzens wrote: > Thanks a lot for fixing this. > Do you tested your changes? > Yes, sure ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images
On 5 July 2015 at 23:31, Matt . wrote: > Hi, > > This needs to be patched on ALL versions! After this, we need to point > the main devs of this package to it. > > Sounds like a plan ? > What do you mean ALL versions? This patch is easily backportable into CC if you mean that... Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images
On 6 July 2015 at 12:40, Matt . wrote: > Hi, > > I mean, not only ar71xx. Looks like you don't understand what you are talking about - UAP-PRO exists only under ar71xx target. > Which version is going to be patched, as in BB, CC ? This patch is for trunk, it's up to core devs if they want it to be backported or not. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] gemini: add NAS packages to Raidsonic profile
Signed-off-by: Roman Yeryomin --- target/linux/gemini/raidsonic/target.mk | 7 +++ 1 file changed, 7 insertions(+) diff --git a/target/linux/gemini/raidsonic/target.mk b/target/linux/gemini/raidsonic/target.mk index 56eda4e..d158090 100644 --- a/target/linux/gemini/raidsonic/target.mk +++ b/target/linux/gemini/raidsonic/target.mk @@ -4,6 +4,13 @@ SUBTARGET:=raidsonic BOARDNAME:=Raidsonic NAS42x0 +FEATURES+=usb +DEFAULT_PACKAGES+=kmod-usb2 kmod-md-mod kmod-md-linear kmod-md-multipath \ + kmod-md-raid0 kmod-md-raid1 kmod-md-raid10 kmod-md-raid456 \ + kmod-fs-btrfs kmod-fs-cifs kmod-fs-ext4 kmod-fs-nfs \ + kmod-fs-nfsd kmod-fs-ntfs kmod-fs-reiserfs kmod-fs-vfat \ + kmod-nls-utf8 kmod-usb-storage-extras \ + samba36-server mdadm cfdisk fdisk e2fsprogs badblocks define Target/Description Build firmware images for Raidsonic NAS4220. -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/4] gemini: copy kernel image to BIN_DIR
Signed-off-by: Roman Yeryomin --- target/linux/gemini/image/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/gemini/image/Makefile b/target/linux/gemini/image/Makefile index 7ed1d61..1c51b62 100644 --- a/target/linux/gemini/image/Makefile +++ b/target/linux/gemini/image/Makefile @@ -74,7 +74,8 @@ define Image/Build dd if=$(BIN_DIR)/$(IMG_PREFIX)-$(1).img of=$(BIN_DIR)/rd.gz bs=6144k count=1 # dd if=/dev/zero of=$(BIN_DIR)/hddapp.tgz bs=6144k count=1 dd if=$(BIN_DIR)/$(IMG_PREFIX)-$(1).img of=$(BIN_DIR)/hddapp.tgz bs=6144k count=1 seek=1 - cp $(KDIR)/$(IMG_PREFIX)-nas4220-zImage $(BIN_DIR)/zImage + cp $(KDIR)/$(IMG_PREFIX)-nas4220-zImage $(BIN_DIR)/ + cp $(BIN_DIR)/$(IMG_PREFIX)-nas4220-zImage $(BIN_DIR)/zImage cp ./ImageInfo-ib4220 $(BIN_DIR)/ImageInfo (cd $(BIN_DIR); tar -czf $(IMG_PREFIX)-sysupgrade-ib4220.tar.gz ImageInfo zImage rd.gz hddapp.tgz) mv $(BIN_DIR)/rd.gz $(BIN_DIR)/$(IMG_PREFIX)-nas4220-rd.gz -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/4] gemini: switch to 4.1
Signed-off-by: Roman Yeryomin --- target/linux/gemini/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile index 3667254..42f8c1e 100644 --- a/target/linux/gemini/Makefile +++ b/target/linux/gemini/Makefile @@ -14,7 +14,7 @@ FEATURES:=squashfs pci rtc CPU_TYPE:=fa526 MAINTAINER:=Roman Yeryomin -KERNEL_PATCHVER:=3.18 +KERNEL_PATCHVER:=4.1 KERNELNAME:=zImage -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/4] gemini: copy kernel image to BIN_DIR
On 9 July 2015 at 08:26, John Crispin wrote: > > > On 08/07/2015 23:00, Roman Yeryomin wrote: >> Signed-off-by: Roman Yeryomin >> --- >> target/linux/gemini/image/Makefile | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/target/linux/gemini/image/Makefile >> b/target/linux/gemini/image/Makefile >> index 7ed1d61..1c51b62 100644 >> --- a/target/linux/gemini/image/Makefile >> +++ b/target/linux/gemini/image/Makefile >> @@ -74,7 +74,8 @@ define Image/Build >> dd if=$(BIN_DIR)/$(IMG_PREFIX)-$(1).img of=$(BIN_DIR)/rd.gz bs=6144k >> count=1 >> #dd if=/dev/zero of=$(BIN_DIR)/hddapp.tgz bs=6144k count=1 >> dd if=$(BIN_DIR)/$(IMG_PREFIX)-$(1).img of=$(BIN_DIR)/hddapp.tgz >> bs=6144k count=1 seek=1 >> - cp $(KDIR)/$(IMG_PREFIX)-nas4220-zImage $(BIN_DIR)/zImage >> + cp $(KDIR)/$(IMG_PREFIX)-nas4220-zImage $(BIN_DIR)/ >> + cp $(BIN_DIR)/$(IMG_PREFIX)-nas4220-zImage $(BIN_DIR)/zImage > > this will lead to the same file being int the bin/ folder twice with > different names. is that intentional ? > zImage is packed into sysupgrade image and removed later... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] gemini: add NAS packages to Raidsonic profile
On 9 July 2015 at 08:31, John Crispin wrote: > > > On 08/07/2015 23:00, Roman Yeryomin wrote: >> Signed-off-by: Roman Yeryomin >> --- >> target/linux/gemini/raidsonic/target.mk | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/target/linux/gemini/raidsonic/target.mk >> b/target/linux/gemini/raidsonic/target.mk >> index 56eda4e..d158090 100644 >> --- a/target/linux/gemini/raidsonic/target.mk >> +++ b/target/linux/gemini/raidsonic/target.mk >> @@ -4,6 +4,13 @@ >> >> SUBTARGET:=raidsonic >> BOARDNAME:=Raidsonic NAS42x0 >> +FEATURES+=usb >> +DEFAULT_PACKAGES+=kmod-usb2 kmod-md-mod kmod-md-linear kmod-md-multipath \ >> + kmod-md-raid0 kmod-md-raid1 kmod-md-raid10 kmod-md-raid456 \ >> + kmod-fs-btrfs kmod-fs-cifs kmod-fs-ext4 kmod-fs-nfs \ >> + kmod-fs-nfsd kmod-fs-ntfs kmod-fs-reiserfs kmod-fs-vfat \ >> + kmod-nls-utf8 kmod-usb-storage-extras \ >> + samba36-server mdadm cfdisk fdisk e2fsprogs badblocks > > some of these are not part of trunk. i think there was a policy that > DEFAULT_PACKAGES should only point at stuff in trunk. i guess madm and > badblocks need to be dropped or moved to trunk > OK, will reconsider the list ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Archer C7 CC 15.05-rc1 Ath9K phy1: Failed to stop TX DMA, queues=0x002!
On 10 July 2015 at 05:07, camden lindsay wrote: > I'm sorry, i said ath9k in the subject but the above seems more likely > to be ath10k. > > On Thu, Jul 9, 2015 at 7:03 PM, camden lindsay > wrote: >> Hello- >> >> Thought I should report this, since there was so much discussion and >> confusion on tracker https://dev.openwrt.org/ticket/11862 causing a >> lot of work for some folks here. >> >> ...snip... >> ... >> [2060235.46] ath: phy1: Failed to stop TX DMA, queues=0x002! >> [2060265.46] ath: phy1: Failed to stop TX DMA, queues=0x002! >> [2061047.18] ath: phy1: Failed to stop TX DMA, queues=0x002! >> [2104015.84] ath: phy1: Unable to reset channel, reset status -5 >> [2145012.92] ath10k_pci :01:00.0: SWBA overrun on vdev 0, >> skipped old beacon >> [2145013.03] ath10k_pci :01:00.0: SWBA overrun on vdev 0, >> skipped old beacon It was fixed in trunk (by using newer firmware and driver). Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] gemini: add NAS packages to Raidsonic profile
On 9 July 2015 at 15:29, Roman Yeryomin wrote: > On 9 July 2015 at 08:31, John Crispin wrote: >> >> >> On 08/07/2015 23:00, Roman Yeryomin wrote: >>> Signed-off-by: Roman Yeryomin >>> --- >>> target/linux/gemini/raidsonic/target.mk | 7 +++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/target/linux/gemini/raidsonic/target.mk >>> b/target/linux/gemini/raidsonic/target.mk >>> index 56eda4e..d158090 100644 >>> --- a/target/linux/gemini/raidsonic/target.mk >>> +++ b/target/linux/gemini/raidsonic/target.mk >>> @@ -4,6 +4,13 @@ >>> >>> SUBTARGET:=raidsonic >>> BOARDNAME:=Raidsonic NAS42x0 >>> +FEATURES+=usb >>> +DEFAULT_PACKAGES+=kmod-usb2 kmod-md-mod kmod-md-linear kmod-md-multipath \ >>> + kmod-md-raid0 kmod-md-raid1 kmod-md-raid10 kmod-md-raid456 \ >>> + kmod-fs-btrfs kmod-fs-cifs kmod-fs-ext4 kmod-fs-nfs \ >>> + kmod-fs-nfsd kmod-fs-ntfs kmod-fs-reiserfs kmod-fs-vfat \ >>> + kmod-nls-utf8 kmod-usb-storage-extras \ >>> + samba36-server mdadm cfdisk fdisk e2fsprogs badblocks >> >> some of these are not part of trunk. i think there was a policy that >> DEFAULT_PACKAGES should only point at stuff in trunk. i guess madm and >> badblocks need to be dropped or moved to trunk >> > > OK, will reconsider the list Looked through the list - all of them are in trunk! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] swconfig: libsw.so should be installed into /usr/lib/
otherwise it's not picked up by toolchain: staging_dir/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_musl-1.1.10/lib/gcc/mipsel-openwrt-linux-musl/4.8.3/../../../../mipsel-openwrt-linux-musl/bin/ld: cannot find -lsw Signed-off-by: Roman Yeryomin --- package/network/config/swconfig/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/network/config/swconfig/Makefile b/package/network/config/swconfig/Makefile index 3c2ec3e..b62b059 100644 --- a/package/network/config/swconfig/Makefile +++ b/package/network/config/swconfig/Makefile @@ -46,8 +46,8 @@ define Build/InstallDev $(INSTALL_DIR) $(1)/usr/include $(CP) $(PKG_BUILD_DIR)/swlib.h $(1)/usr/include/ - $(INSTALL_DIR) $(1)/lib - $(CP) $(PKG_BUILD_DIR)/libsw.so $(1)/lib/ + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_BUILD_DIR)/libsw.so $(1)/usr/lib/ endef define Package/swconfig/install -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k fails to load firmware in r46386 on ESR1750
On 17 July 2015 at 16:34, Christian Beier wrote: > > Hi list! > > On an EnGenius ESR1750 running current trunk (r46386), the ath10k driver fails > to load the firmware blob - it did work in Barrier Breaker though. Here's the > failing dmesg bits: > > ---snip--- > [ 72.05] PCI: Enabling device :00:00.0 ( -> 0002) > [ 72.06] ath10k_pci :00:00.0: pci irq legacy interrupts 0 irq_mode > 0 reset_mode 0 > [ 72.28] ath10k_pci :00:00.0: Direct firmware load for > ath10k/cal-pci-:00:00.0.bin failed with error -2 > [ 72.29] ath10k_pci :00:00.0: Falling back to user helper > [ 72.36] firmware ath10k!cal-pci-:00:00.0.bin: > firmware_loading_store: map pages failed > [ 72.46] ath10k_pci :00:00.0: otp calibration failed: 2 > [ 72.47] ath10k_pci :00:00.0: failed to run otp: -22 > [ 72.47] ath10k_pci :00:00.0: could not init core (-22) > [ 72.48] ath10k_pci :00:00.0: could not probe fw (-22) > ---snap--- > > > Barrier Breaker dmesg instead: > ---snip--- > [ 12.44] ath10k_pci :00:00.0: BAR 0: assigned [mem > 0x1000-0x101f 64bit] > [ 12.45] PCI: Enabling device :00:00.0 ( -> 0002) > [ 12.75] ath10k: pci irq legacy irq_mode 0 reset_mode 0 > [ 13.16] ath10k: otp stream is empty, using board.bin contents > [ 14.12] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.3-1 > api 2 htt 2.1 > ---snap--- > > Any hints on this? > Works fine for me on Archer c7 v2 with latest trunk (3.18 kernel): [ 11.93] ath10k_pci :01:00.0: Direct firmware load for ath10k/cal-pci-:01:00.0.bin failed with error -2 [ 11.94] ath10k_pci :01:00.0: Falling back to user helper [ 13.28] ath10k_pci :01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.70-2 api 5 htt 2.1 wmi 5 cal file max_sta 128 but fails hardly on same trunk but 4.0 kernel: [ 11.00] ath10k_pci :01:00.0: Direct firmware load for ath10k/cal-pci-:01:00.0.bin failed with error -2 [ 11.01] ath10k_pci :01:00.0: Falling back to user helper [ 11.28] Unhandled kernel unaligned access[#1]: [ 11.28] CPU: 0 PID: 314 Comm: kworker/u2:2 Not tainted 4.0.7 #1 [ 11.28] Workqueue: ath10k_wq ath10k_core_stop [ath10k_core] [ 11.28] task: 878b4508 ti: 87b12000 task.ti: 87b12000 [ 11.28] $ 0 : 0001 0001 8dde212a [ 11.28] $ 4 : 8dde212a 8717 8717 1762 [ 11.28] $ 8 : 0001 7969 8700c700 [ 11.28] $12 : 0001 0600 [ 11.28] $16 : 87015360 0040 87015dec [ 11.28] $20 : 87804c10 87804c00 [ 11.28] $24 : 8007cdac [ 11.28] $28 : 87b12000 87b13de8 0088 8714f204 [ 11.28] Hi: 0009 [ 11.28] Lo: 0006 [ 11.28] epc : 8714f238 ath10k_core_start+0x158/0x8c0 [ath10k_core] [ 11.28] Not tainted [ 11.28] ra: 8714f204 ath10k_core_start+0x124/0x8c0 [ath10k_core] [ 11.28] Status: 1100fc03 KERNEL EXL IE [ 11.28] Cause : 00800010 [ 11.28] BadVA : 1766 [ 11.28] PrId : 00019750 (MIPS 74Kc) [ 11.28] Modules linked in: ath10k_pci(+) ath10k_core ath mac80211 cfg80211 compat ledtrig_usbdev ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common i p6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables ipv6 arc4 crypto_blkcipher ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_com mon [ 11.28] Process kworker/u2:2 (pid: 314, threadinfo=87b12000, task=878b4508, tls=) [ 11.28] Stack : 9000 8704b54c 0003 00fe 00401c60 004043d0 87015e74 87015360 87015dec 87150ad0 878b4508 8009a3ec 87829928 8716f0e4 4100016c 878b4508 4100016c 0007 87b3b280 87015e74 87804c00 87022900 80092ea4 87b3b280 87804c00 87b3b298 80313c24 0001 8037 87804c00 87b3b280 87804c00 87b3b298 ... [ 11.28] Call Trace: [ 11.28] [<8714f238>] ath10k_core_start+0x158/0x8c0 [ath10k_core] [ 11.28] [<87150ad0>] ath10k_core_stop+0x1fc/0xcbc [ath10k_core] [ 11.28] [ 11.28] Code: 2ce2f001 10400016 3c068717 <8ce50004> 8ce6 0dc53bb1 02002021 00408821 1047 [ 11.48] ---[ end trace 984c21dee33226f1 ]--- [ 11.49] CPU 0 Unable to handle kernel paging request at virtual address fff0, epc == 80097550, ra == 80093c3c Reverting r46244 and r46245 (t.i. making it use board.bin again as in BB in your test) fixes the issue. Maybe ath10k is doing something wrong when doing request_firmware() or maybe it's a kernel regression. Anyway, I'm going to switch to 4.1 very soon, we'll see what happens there. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listin
Re: [OpenWrt-Devel] ath10k fails to load firmware in r46386 on ESR1750
On 17 July 2015 at 18:27, Roman Yeryomin wrote: > > Anyway, I'm going to switch to 4.1 very soon, we'll see what happens there. > OK, just sent 4.1 support patch. Firmware loading on Archer C7 works fine there. Could you test the patch on your device? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k fails to load firmware in r46386 on ESR1750
On 17 July 2015 at 20:54, Matti Laakso wrote: > Hi, > >> On an EnGenius ESR1750 running current trunk (r46386), the ath10k driver >> fails >> to load the firmware blob - it did work in Barrier Breaker though. Here's >> the >> failing dmesg bits: > > It seems this board ran uncalibrated on BB and CC, which is no longer > possible after my patches on trunk. A correct entry needs to be added to > target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata in > order to upload calibration data to the firmware. It should be rather easy, Indeed, didn't notice that Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add 4.1 support
On 19 July 2015 at 21:01, Felix Fietkau wrote: > On 2015-07-17 19:35, Roman Yeryomin wrote: >> Signed-off-by: Roman Yeryomin > Applied with some follow-up fixes. > > Please always refresh patches when adding a new kernel version. Hmm.. I think I did refresh the patches, probaly in other testing branch, sorry for that... > Also, refresh the kernel config and pay close attention to > 'disappearing' config symbols. In this case, CONFIG_NET_DSA got disabled > (along with the marvell 88e6060 driver) because it now requires > SWITCHDEV support. > Refreshing the config also revealed some missing config symbols in the > generic kernel config. I did add some missing symbol but how do you reveal those which were unitentionally disabled like in this case? Is there any automagic? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add 4.1 support
On 20 July 2015 at 07:52, Felix Fietkau wrote: > On 2015-07-20 01:06, Roman Yeryomin wrote: > >>> Also, refresh the kernel config and pay close attention to >>> 'disappearing' config symbols. In this case, CONFIG_NET_DSA got disabled >>> (along with the marvell 88e6060 driver) because it now requires >>> SWITCHDEV support. >>> Refreshing the config also revealed some missing config symbols in the >>> generic kernel config. >> >> I did add some missing symbol but how do you reveal those which were >> unitentionally disabled like in this case? Is there any automagic? > There's no automagic, but if you run make kernel_oldconfig and diff > against the previous config, it's easy to spot deletions and look into them. Oh, right, thanks for the tip! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Restore AP scan patch
On 3 August 2015 at 15:11, openwrt-de...@couprie.net wrote: > Hi Dimitry, > > Does this patch, fix the problem that when a router is a wifi access client > and access point. > The local access point does not work when de wifi access client is not > connected ? > This patch only fixes scanning when in AP mode. The problem you are referring to is different and I'm not sure it can be fixed in the "right" way. Try using 4address mode (aka WDS in hostapd terms). Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multiple Wi-Fi client/AP interfaces on one radio (was: Change OpenWrt Wifi default settings)
On 4 August 2015 at 17:58, Joshua Judson Rosen wrote: > On 2015-08-04 02:26, David Lang wrote: >> A given radio can be either an AP or a client, but not both at once. >> >> so if you use a radio to connect to another AP, you are making it a client, >> and >> in client mode all it can do is connect to that other AP as shows up as the >> SSID >> of that other AP. >> >> you can do this with one radio, while using the other radio (assuming you >> have >> two) to act as an AP for local clients. > > > This is not necessarily true: with at least some hardware/drivers, it's > possible to create multiple virtual interfaces on top of a single radio-- > and separate virtual interfaces can in fact operate in different modes > (e.g.: one in STA mode, two in AP mode, one in mesh mode...). > > Assuming that your hardware/driver is capable of supporting multiple > virtual interfaces on top of the single physical radio, > you can create these interfaces by adding "wifi-iface" stanzas > in /etc/config/wireless, e.g: > > config wifi-device 'radio0' > option type 'mac80211' > option channel '11' > option hwmode '11g' > option path 'platform/ar933x_wmac' > option htmode 'HT20' > option country 'US' > option txpower '20' > > config wifi-iface 'ap1' > option device 'radio0' > option mode 'ap' > option wds '1' > option ssid 'my AP' > option network 'lan' > > config wifi-iface 'mesh1' > option device 'radio0' > option mode 'mesh' > option mesh_id 'my mesh' > option network 'lan' > > > That creates two virtual interfaces using the same physical radio, > and bridges them together onto the OpenWrt "lan network" > (which is itself defined in /etc/config/network). > > > I believe you could also have an interface with "mode 'sta'", but note > that it would also need to use the same channel as the other interfaces-- > which means that the external AP to which you connect it would also > need to use that same channel (11, in the example above). > That's where having multiple *radios* helps: you can run them on > different frequencies (either completely different bands [2.4 GHz vs. 5 GHz], > or on different channels within the same band [e.g. 2.427 GHz = channel 4 > vs. 2.472 GHz = channel 13]) to increase efficiency by multiplexing > less data over a single radio, or to increase compatibility with other > APs outside of your control that you might want to connect to. > > Also note that, if you want to bridge a STA interface onto anything else, > it'll need to be in "WDS" mode _and_ the the AP to which it's connecting > will also need to be in "WDS" mode (note the "option wds '1'", > in my example above), because the standard "3-address mode" of Wi-Fi > isn't bridgeable (and note that WDS "4-address mode" is bridgeable, > but not standardised across different platforms--so you're probably > OK so long as all of your equipment is running Linux and using > the same Wi-Fi driver, but don't expect to bridge a STA interface > that's connected non-Linux Wi-Fi router). > > At least, I've seen this work with Atheros chips. There are some > notes in the wiki about how Broadcom chips have their own, different > solution implemented in hardware; and about how some drivers > don't support this stuff at all Actually 3-address mode bridging is possible with the help of relayd and it even works quite good. But there is an issue (also mentioned in a parallel thread): when client interface cannot connect then AP interface doesn't come up also. Which may not be a problem unless you want to bridge ethernet there also. On the other hand you may not be able to switch the main AP into 4-address mode so relayd is a way out. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
On 4 August 2015 at 23:24, Joshua Judson Rosen wrote: > On 2015-08-04 14:14, Roman Yeryomin wrote: >> On 4 August 2015 at 17:58, Joshua Judson Rosen wrote: >>> On 2015-08-04 02:26, David Lang wrote: >>>> A given radio can be either an AP or a client, but not both at once. >>>> >>>> so if you use a radio to connect to another AP, you are making it a >>>> client, and >>>> in client mode all it can do is connect to that other AP as shows up as >>>> the SSID >>>> of that other AP. >>>> >>>> you can do this with one radio, while using the other radio (assuming you >>>> have >>>> two) to act as an AP for local clients. >>> >>> >>> This is not necessarily true: with at least some hardware/drivers, it's >>> possible to create multiple virtual interfaces on top of a single radio-- >>> and separate virtual interfaces can in fact operate in different modes >>> (e.g.: one in STA mode, two in AP mode, one in mesh mode...). >>> >>> Assuming that your hardware/driver is capable of supporting multiple >>> virtual interfaces on top of the single physical radio, >>> you can create these interfaces by adding "wifi-iface" stanzas >>> in /etc/config/wireless, e.g: >>> >>> config wifi-device 'radio0' >>> option type 'mac80211' >>> option channel '11' >>> option hwmode '11g' >>> option path 'platform/ar933x_wmac' >>> option htmode 'HT20' >>> option country 'US' >>> option txpower '20' >>> >>> config wifi-iface 'ap1' >>> option device 'radio0' >>> option mode 'ap' >>> option wds '1' >>> option ssid 'my AP' >>> option network 'lan' >>> >>> config wifi-iface 'mesh1' >>> option device 'radio0' >>> option mode 'mesh' >>> option mesh_id 'my mesh' >>> option network 'lan' >>> >>> >>> That creates two virtual interfaces using the same physical radio, >>> and bridges them together onto the OpenWrt "lan network" >>> (which is itself defined in /etc/config/network). >>> >>> >>> I believe you could also have an interface with "mode 'sta'", but note >>> that it would also need to use the same channel as the other interfaces-- >>> which means that the external AP to which you connect it would also >>> need to use that same channel (11, in the example above). >>> That's where having multiple *radios* helps: you can run them on >>> different frequencies (either completely different bands [2.4 GHz vs. 5 >>> GHz], >>> or on different channels within the same band [e.g. 2.427 GHz = channel 4 >>> vs. 2.472 GHz = channel 13]) to increase efficiency by multiplexing >>> less data over a single radio, or to increase compatibility with other >>> APs outside of your control that you might want to connect to. >>> >>> Also note that, if you want to bridge a STA interface onto anything else, >>> it'll need to be in "WDS" mode _and_ the the AP to which it's connecting >>> will also need to be in "WDS" mode (note the "option wds '1'", >>> in my example above), because the standard "3-address mode" of Wi-Fi >>> isn't bridgeable (and note that WDS "4-address mode" is bridgeable, >>> but not standardised across different platforms--so you're probably >>> OK so long as all of your equipment is running Linux and using >>> the same Wi-Fi driver, but don't expect to bridge a STA interface >>> that's connected non-Linux Wi-Fi router). >>> >>> At least, I've seen this work with Atheros chips. There are some >>> notes in the wiki about how Broadcom chips have their own, different >>> solution implemented in hardware; and about how some drivers >>> don't support this stuff at all >> >> Actually 3-address mode bridging is possible with the help of relayd > > That's not actually "3-address mode b
Re: [OpenWrt-Devel] optimizing network performance
On 9 January 2016 at 17:21, Roman Yeryomin wrote: > While trying to optimize ag71xx driver performance I've noticed a > weird thing: NAT performance may vary across reboots. > For example on Archer C7 the difference can be 80Mbps: 440 one boot, > 360 another. On AP152 the numbers differ but the difference across > reboots still present. > That is with iperf3, TCP download, 1m average, confirmed environment, > trunk version. > > Did someone notice this before? Is this driver specific? MIPS > specific? Something else? > > Unfortunately I don't have any other board with gigabit ports I can > test with currently. > Such behavior makes it very hard to test any optimizations. > Really? nobody noticed this? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: Mark broken; no working images
On 14 January 2016 at 17:31, wrote: > From: Daniel Dickinson > > To my knowledge there are no working images, nor a way to get them, > even using maximum stripping and dropping of packages, kmods, and > compile options due to the small size of the targets for this > architecture. Therefore mark this arch broken and maybe remove > unless someone decides to fix it. > > Signed-off-by: Daniel Dickinson > --- > target/linux/brcm47xx/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/linux/brcm47xx/Makefile b/target/linux/brcm47xx/Makefile > index e0c44c8..fae1f59 100644 > --- a/target/linux/brcm47xx/Makefile > +++ b/target/linux/brcm47xx/Makefile > @@ -12,6 +12,7 @@ BOARDNAME:=Broadcom BCM47xx/53xx (MIPS) > FEATURES:=squashfs usb > SUBTARGETS:=generic mips74k legacy > MAINTAINER:=Hauke Mehrtens > +DEPENDS:=@BROKEN > > KERNEL_PATCHVER:=4.1 > m? at least Asus rt-n16 and wl-500gp work fine! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: Mark broken; no working images
On 14 January 2016 at 18:25, Daniel Dickinson wrote: > Ah, ok, so there likley there are are pobablly not any working *stock* > devices. That merits the @BROKEN flag - if you're running modified hardware > you can surely build with BROKEN enabled. https://downloads.openwrt.org/snapshots/trunk/brcm47xx/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm2708: fix RPi model B plus support
On 17 January 2016 at 13:15, Felix Fietkau wrote:
> On 2016-01-10 00:13, Roman Yeryomin wrote:
>> Not sure if B+ is used or not (mine has B Plus) so leave both
>>
>> Signed-off-by: Roman Yeryomin
>> ---
>> target/linux/brcm2708/base-files/lib/brcm2708.sh | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/target/linux/brcm2708/base-files/lib/brcm2708.sh
>> b/target/linux/brcm2708/base-files/lib/brcm2708.sh
>> index 13c1aa9..cb4089d 100644
>> --- a/target/linux/brcm2708/base-files/lib/brcm2708.sh
>> +++ b/target/linux/brcm2708/base-files/lib/brcm2708.sh
>> @@ -11,6 +11,7 @@ brcm2708_detect() {
>> "Raspberry Pi Model B Rev"*)
>> board_name="rpi-b"
>> ;;
>> + "Raspberry Pi Model B Plus Rev"* |\
>> "Raspberry Pi Model B+ Rev"*)
> Why would it have "B Plus" instead of "B+"? I only see "B+" in the
> kernel .dts file.
Didn't investigate the exact reason
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New Ubiquiti AC products locked against 3rd party firmware?
https://github.com/openwrt/openwrt/commit/de350dcae493b2b71a0850b1d1d4ee0483552faa On 22 February 2016 at 14:05, valent.turko...@gmail.com wrote: > Nice that you checked... I would understand this stance from a company > that doesn't rely on so much open source software without which they > wouldn't even exists. Shame, just shame. > > On 30 November 2015 at 09:48, John Crispin wrote: >> >> >> On 30/11/2015 09:38, Petr Štetiar wrote: >>> Ben West [2015-11-27 10:00:51]: >>> >>> Hi, >>> This person is reporting a new Ubiquiti AC AP where there the bootloader does an RSA signature check on the firmware image. >>> >>> let's hope, that it would be possible to replace/patch that unfriendly >>> U-Boot. >>> Could anyone else confirm if they've observed the same, and if it now prevents loading OpenWRT, etc? Or at least, confirm if the RSA signature checking by the bootloader was not present before? >>> >>> We're using UBNT products and I can confirm, that there wasn't any RSA >>> firmware signature checking previously and we're able to run OpenWRT on >>> them. >>> Maybe it's time to look around for alternatives... >>> >>> -- ynezz >>> >> >> >> Hi, >> >> i contacted UBNT customer support. they specifically stated that they do >> not want users to install openwrt and prefer not to cooperate with us. >> it is a concious decision to *not* support the free software movement >> and be capitalist pigs. the reasoning given to me was not related to FCC >> ruling but specifically stated that they dont like users installing free >> software on their routers. they prefer to have submissive users that >> will do as they are told. >> >> John >> >> -- Forwarded message -- From: Andrew Margarit | Cucumber WiFI Date: Fri, Nov 27, 2015 at 7:59 AM Subject: Re: [FCC] New AP with the lockdown To: f...@lists.prplfoundation.org Hi there, Just to let you know, I've been looking at the Ubiquiti new AC APs, and it looks like they added a RSA check in the bootloader. Firmware Version: BZ.qca956x.v3.4.7.3284.150911.1650 RSA Signed Firmware. Verfiying please wait... Decrypted hash: f8 2b 45 72 9f e4 5f 46 a0 96 43 37 57 4f 49 ab 43 dc 1e 8c Image hash: f8 2b 45 72 9f e4 5f 46 a0 96 43 37 57 4f 49 ab 43 dc 1e 8c All fun and good! -- Andrew Margarit Wi-FI Chief | Cucumber Tony and...@polkaspots.com cucumberwifi.io twitter/cucumbertony ___ FCC mailing list f...@lists.prplfoundation.org http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/fcc -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> ___ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] fstools/overlayfs race condition
There is a race between `cp -a /tmp/root/* /rom/overlay` from
libfstools/overlay.c and a process creating new file(s) before
pivot(/rom, /mnt) occured.
That is a process can create a file and it will not be copied.
Currently I do additional copy after jffs2 is ready, which is kind of
cumbersome (see attached patch), but there are still few potentially
erroneous scenarios:
1. a process may recreate the file by the time second cp occurs
2. a process may delete a file (not existing at that moment) and
second cp will copy it again
3. a process may want to read created file before second cp occurs
If attached patch is the way to go I will properly submit it.
Otherwise there should be a more fundamental fix but I don't see a way
to fix this properly.
Regards,
Roman
--- a/libfstools/overlay.c
+++ b/libfstools/overlay.c
@@ -223,6 +223,9 @@ jffs2_switch(struct volume *v)
ULOG_INFO("performing overlay whiteout\n");
umount2("/tmp/root", MNT_DETACH);
foreachdir("/overlay/", handle_whiteout);
+ /* try hard to be in sync */
+ ULOG_INFO("syncronizing overlay\n");
+ system("cp -a /tmp/root/upper/* / 2>/dev/null");
}
break;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] fstools/overlayfs race condition
On 7 March 2016 at 15:09, John Crispin wrote: > > > On 07/03/2016 14:03, Roman Yeryomin wrote: >> There is a race between `cp -a /tmp/root/* /rom/overlay` from >> libfstools/overlay.c and a process creating new file(s) before >> pivot(/rom, /mnt) occured. >> That is a process can create a file and it will not be copied. >> >> Currently I do additional copy after jffs2 is ready, which is kind of >> cumbersome (see attached patch), but there are still few potentially >> erroneous scenarios: >> 1. a process may recreate the file by the time second cp occurs >> 2. a process may delete a file (not existing at that moment) and >> second cp will copy it again >> 3. a process may want to read created file before second cp occurs >> >> If attached patch is the way to go I will properly submit it. >> Otherwise there should be a more fundamental fix but I don't see a way >> to fix this properly. >> >> > > Hi Roman > > that race has been there since the day we do overlayfs. i am always > surprised that it has not exploded in a big way yet. the only way i see > are workarounds such as yours or sending out lots of SIGSTOP and the > continues when we copied the files. either way it will be ugly and > require protective gear. > > i'll ponder this and see if we can find a better way Actually I met this long ago, just didn't understand/investigate it was exactly this. What will happen if a process opens a file (t.i. it will have an open descriptor) in tmp root, writes to it and then, in the process of writing, pivot_root() executes? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago
On 18 March 2016 at 04:40, Shankar Unni wrote: > On Wed, Mar 16, 2016 at 1:53 AM, Karl Vogel wrote: >> >> Doesn't look like the SVN server is back yet either. >> >> Are there any plans to resurrect the anon SVN server? Or should everybody >> move to git.openwrt.org instead? >> > > Yeah, I've been waiting for this, too (svn.openwrt.org). > > It would be good to hear an official word from someone as to whether > this is ever going to come back up (i.e. is this only a delay?), or is > it a final decision to turn it off for good. It's dead, Jim. Just switch and free yourself. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago
On 18 March 2016 at 19:36, John Crispin wrote: > > > On 18/03/2016 18:19, Roman Yeryomin wrote: >> On 18 March 2016 at 15:32, John Crispin wrote: >>>> >>>> please use this svn server for now. it will be online for 4-6 weeks so >>>> that people have time to migrate away from svn. i will send out a notice >>>> 1 week before we finally turn it of. please start migrating now. >>> >>> if you do 10 things at once you forget to paste the url :-) >>> >>> svn://svn.mein.io/openwrt >> >> John, you just made people suffer for 4-6 weeks longer :) >> > > > i think you are mistaken, think before you post please. Sorry, maybe it was way too sarcastic but IMO switching from svn to git is fairly simple and there is nothing to dramatize. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago
On 18 March 2016 at 15:32, John Crispin wrote: >> >> please use this svn server for now. it will be online for 4-6 weeks so >> that people have time to migrate away from svn. i will send out a notice >> 1 week before we finally turn it of. please start migrating now. > > if you do 10 things at once you forget to paste the url :-) > > svn://svn.mein.io/openwrt John, you just made people suffer for 4-6 weeks longer :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: move different subtarget image generation to separate makefiles to improve maintainability
- all subtarget specific defines are in their own files
- common defines left in main Makefile
- each subtarget makefile idefed with SUBTARGET
- all subtargets compile tested
- few seems to be broken/unneeded things marked with FIXME
Signed-off-by: Roman Yeryomin
---
target/linux/ramips/image/Makefile | 949 +---
target/linux/ramips/image/mt7620.mk | 160 ++
target/linux/ramips/image/mt7621.mk | 153 ++
target/linux/ramips/image/mt7628.mk | 17 +
target/linux/ramips/image/mt7688.mk | 11 +
target/linux/ramips/image/rt288x.mk | 59 +++
target/linux/ramips/image/rt305x.mk | 392 +++
target/linux/ramips/image/rt3883.mk | 59 +++
8 files changed, 865 insertions(+), 935 deletions(-)
create mode 100644 target/linux/ramips/image/mt7620.mk
create mode 100644 target/linux/ramips/image/mt7621.mk
create mode 100644 target/linux/ramips/image/mt7628.mk
create mode 100644 target/linux/ramips/image/mt7688.mk
create mode 100644 target/linux/ramips/image/rt288x.mk
create mode 100644 target/linux/ramips/image/rt305x.mk
create mode 100644 target/linux/ramips/image/rt3883.mk
diff --git a/target/linux/ramips/image/Makefile
b/target/linux/ramips/image/Makefile
index 0cfb8fb..ddd67a2 100644
--- a/target/linux/ramips/image/Makefile
+++ b/target/linux/ramips/image/Makefile
@@ -52,15 +52,6 @@ define Build/trx
-a 4 -f $(word 2,$^)
endef
-define Build/seama
- $(STAGING_DIR_HOST)/bin/seama -i $@ $(1)
- mv $@.seama $@
-endef
-
-define Build/seama-seal
- $(call Build/seama,-s $@.seama $(1))
-endef
-
define Build/relocate-kernel
( \
dd if=$(KDIR)/loader.bin bs=32 conv=sync && \
@@ -70,51 +61,6 @@ define Build/relocate-kernel
mv $@.new $@
endef
-define Build/ubnt-erx-factory-compat
- echo '21001:6' > $@.compat
- $(TAR) -cf $@ --transform='s/^.*/compat/' $@.compat
- $(RM) $@.compat
-endef
-
-define Build/ubnt-erx-factory-kernel
- if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) ]; then \
- $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp/'
$(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE); \
- \
- md5sum --binary $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) | awk
'{print $$1}'> $@.md5; \
- $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp.md5/' $@.md5; \
- $(RM) $@.md5; \
- fi
-endef
-
-define Build/ubnt-erx-factory-rootfs
- echo "dummy" > $@.rootfs
- $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp/' $@.rootfs
-
- md5sum --binary $@.rootfs | awk '{print $$1}'> $@.md5
- $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp.md5/' $@.md5
- $(RM) $@.md5
- $(RM) $@.rootfs
-endef
-
-define Build/ubnt-erx-factory-version
- echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' > $@.version
- $(TAR) -rf $@ --transform='s/^.*/version.tmp/' $@.version
- $(RM) $@.version
-endef
-
-#We need kernel+initrams fit into kernel partition
-define Build/ubnt-erx-factory-check-size
- @[ $$(($(subst k,* 1024,$(subst m, * 1024k,$(1) -ge "$$($(TAR) -xf
$@ vmlinux.tmp -O | wc -c)" ] || { \
- echo "WARNING: Initramfs kernel for image $@ is too big (kernel
size: $$($(TAR) -xf $@ vmlinux.tmp -O | wc -c), max size $(1))" >&2; \
- $(RM) -f $@; \
- }
-
- @[ "$$($(TAR) -xf $@ vmlinux.tmp -O | wc -c)" -gt 0 ] || { \
- echo "WARNING: Kernel for image $@ not found" >&2; \
- $(RM) -f $@; \
- }
-endef
-
define MkCombineduImage
$(call PatchKernelLzma,$(2),$(3))
if [ `stat -c%s "$(KDIR)/vmlinux-$(2).bin.lzma"` -gt `expr $(4) - 64`
]; then \
@@ -127,7 +73,6 @@ define MkCombineduImage
$(call MkImage,lzma,$(KDIR)/vmlinux-$(2).bin.lzma.combined,$(call
sysupname,$(1),$(2)),$(6))
endef
-
#
# The real magic happens inside these templates
#
@@ -156,23 +101,6 @@ define MkImageSysupgrade/squashfs
fi
endef
-define MkImageTpl/squashfs
- $(eval output_name=$(IMG_PREFIX)-$(2)-$(1)-$(if
$(4),$(4),sysupgrade).bin)
- -$(STAGING_DIR_HOST)/bin/mktplinkfw2 -V "ver. 2.0" -B "$(2)" -j \
- -o $(KDIR)/$(output_name) \
- -k $(KDIR)/vmlinux-$(1)$(4).bin.lzma \
- -r $(KDIR)/root.$(1) && \
- $(CP) $(KDIR)/$(output_name) $(BIN_DIR)/$(output_name)
-endef
-
-define MkImageTpl/initramfs
- $(eval output_name=$(IMG_PREFIX)-$(2)-$(1).bin)
- -$(STAGING_DIR_HOST)/bin/mktplinkfw2 -V "ver. 2.0" -B "$(2)" -c \
- -o $(KDIR)/$(output_name) \
- -k $(KDIR)/vmlinux-$(1).bin.lzma && \
- $(CP) $(KDIR)/$(output_name) $(BIN_DIR)/$(output_name)
-endef
-
# $(1), lowerca
[OpenWrt-Devel] [PATCH 1/5] ramips: mt7621: fix initramfs image for ubnt-erx
Signed-off-by: Roman Yeryomin
---
target/linux/ramips/image/mt7621.mk | 66 +++--
1 file changed, 20 insertions(+), 46 deletions(-)
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index 745611f..76b4e48 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -11,51 +11,28 @@ define Build/seama-seal
$(call Build/seama,-s $@.seama $(1))
endef
-define Build/ubnt-erx-factory-compat
- echo '21001:6' > $@.compat
- $(TAR) -cf $@ --transform='s/^.*/compat/' $@.compat
- $(RM) $@.compat
-endef
-
-define Build/ubnt-erx-factory-kernel
+define Build/ubnt-erx-factory-image
if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) ]; then \
- $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp/'
$(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE); \
+ echo '21001:6' > $(1).compat; \
+ $(TAR) -cf $(1) --transform='s/^.*/compat/' $(1).compat; \
+ \
+ $(TAR) -rf $(1) --transform='s/^.*/vmlinux.tmp/'
$(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE); \
+ md5sum --binary $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) | awk
'{print $$1}'> $(1).md5; \
+ $(TAR) -rf $(1) --transform='s/^.*/vmlinux.tmp.md5/' $(1).md5; \
+ \
+ echo "dummy" > $(1).rootfs; \
+ $(TAR) -rf $(1) --transform='s/^.*/squashfs.tmp/' $(1).rootfs; \
\
- md5sum --binary $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) | awk
'{print $$1}'> $@.md5; \
- $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp.md5/' $@.md5; \
- $(RM) $@.md5; \
+ md5sum --binary $(1).rootfs | awk '{print $$1}'> $(1).md5; \
+ $(TAR) -rf $(1) --transform='s/^.*/squashfs.tmp.md5/' $(1).md5;
\
+ \
+ echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' >
$(1).version; \
+ $(TAR) -rf $(1) --transform='s/^.*/version.tmp/' $(1).version; \
+ \
+ $(CP) $(1) $(BIN_DIR)/; \
fi
endef
-define Build/ubnt-erx-factory-rootfs
- echo "dummy" > $@.rootfs
- $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp/' $@.rootfs
-
- md5sum --binary $@.rootfs | awk '{print $$1}'> $@.md5
- $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp.md5/' $@.md5
- $(RM) $@.md5
- $(RM) $@.rootfs
-endef
-
-define Build/ubnt-erx-factory-version
- echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' > $@.version
- $(TAR) -rf $@ --transform='s/^.*/version.tmp/' $@.version
- $(RM) $@.version
-endef
-
-# We need kernel+initrams fit into kernel partition
-define Build/ubnt-erx-factory-check-size
- @[ $$(($(subst k,* 1024,$(subst m, * 1024k,$(1) -ge "$$($(TAR) -xf
$@ vmlinux.tmp -O | wc -c)" ] || { \
- echo "WARNING: Initramfs kernel for image $@ is too big (kernel
size: $$($(TAR) -xf $@ vmlinux.tmp -O | wc -c), max size $(1))" >&2; \
- $(RM) -f $@; \
- }
-
- @[ "$$($(TAR) -xf $@ vmlinux.tmp -O | wc -c)" -gt 0 ] || { \
- echo "WARNING: Kernel for image $@ not found" >&2; \
- $(RM) -f $@; \
- }
-endef
-
ifeq ($(SUBTARGET),mt7621)
TARGET_DEVICES += mt7621 wsr-600 wsr-1166 dir-860l-b1 firewrt pbr-m1 re6500
sap-g3200u3 ubnt-erx witi wf-2881 zbt-wg2626
endif
@@ -134,12 +111,9 @@ define Device/ubnt-erx
FILESYSTEMS := squashfs
KERNEL_SIZE := 3145728
KERNEL := $(KERNEL_DTB) | uImage lzma
- IMAGES := sysupgrade.tar $(if
$(CONFIG_TARGET_ROOTFS_INITRAMFS),factory-initramfs.tar)
- IMAGE/factory-initramfs.tar := ubnt-erx-factory-compat | \
-ubnt-erx-factory-kernel | \
-ubnt-erx-factory-rootfs | \
-ubnt-erx-factory-version | \
-ubnt-erx-factory-check-size $$(KERNEL_SIZE)
+ IMAGES := sysupgrade.tar
+ KERNEL_INITRAMFS := $$(KERNEL) | check-size $$(KERNEL_SIZE) | \
+ ubnt-erx-factory-image
$(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar
IMAGE/sysupgrade.tar := sysupgrade-nand
endef
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/5] ramips: mt7621: add a device to TARGET_DEVICES after it's definition
Signed-off-by: Roman Yeryomin --- target/linux/ramips/image/mt7621.mk | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 76b4e48..628954f 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -33,29 +33,29 @@ define Build/ubnt-erx-factory-image fi endef -ifeq ($(SUBTARGET),mt7621) - TARGET_DEVICES += mt7621 wsr-600 wsr-1166 dir-860l-b1 firewrt pbr-m1 re6500 sap-g3200u3 ubnt-erx witi wf-2881 zbt-wg2626 -endif - define Device/mt7621 DTS := MT7621 IMAGE_SIZE := $(ralink_default_fw_size_4M) endef +TARGET_DEVICES += mt7621 define Device/wsr-600 DTS := WSR-600 IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += wsr-600 define Device/re6500 DTS := RE6500 endef +TARGET_DEVICES += re6500 define Device/wsr-1166 DTS := WSR-1166 IMAGE/sysupgrade.bin := trx | pad-rootfs IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += wsr-1166 define Device/dir-860l-b1 DTS := DIR-860L-B1 @@ -71,30 +71,36 @@ define Device/dir-860l-b1 seama-seal -m "signature=wrgac13_dlink.2013gui_dir860lb" | \ check-size (IMAGE_SIZE) endef +TARGET_DEVICES += dir-860l-b1 define Device/firewrt DTS := FIREWRT IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += firewrt define Device/pbr-m1 DTS := PBR-M1 IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += pbr-m1 define Device/sap-g3200u3 DTS := SAP-G3200U3 endef +TARGET_DEVICES += sap-g3200u3 define Device/witi DTS := WITI IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += witi define Device/zbt-wg2626 DTS := ZBT-WG2626 IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += zbt-wg2626 define Device/wf-2881 DTS := WF-2881 @@ -105,6 +111,7 @@ define Device/wf-2881 KERNEL := $(KERNEL_DTB) | pad-offset 131072 64 | uImage lzma IMAGE/sysupgrade.bin := append-kernel | append-ubi | check-size (IMAGE_SIZE) endef +TARGET_DEVICES += wf-2881 define Device/ubnt-erx DTS := UBNT-ERX @@ -116,6 +123,7 @@ define Device/ubnt-erx ubnt-erx-factory-image $(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar IMAGE/sysupgrade.tar := sysupgrade-nand endef +TARGET_DEVICES += ubnt-erx # FIXME: is this still needed? define Image/Prepare -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/5] ramips: enable device profiling by dts
Signed-off-by: Roman Yeryomin --- target/linux/ramips/image/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index ddd67a2..6e0349f 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -32,6 +32,7 @@ KERNEL_LOADADDR := $(loadaddr-y) KERNEL_DTB = kernel-bin | patch-dtb | lzma define Device/Default + PROFILES = Default $$(DTS) KERNEL_DEPENDS = $$(wildcard ../dts/$$(DTS).dts) KERNEL := $(KERNEL_DTB) | uImage lzma IMAGES := sysupgrade.bin -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/5] ramips: mt7621: sync MQmaker WiTi profile name to dts name
Signed-off-by: Roman Yeryomin --- target/linux/ramips/mt7621/profiles/mqmaker.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/target/linux/ramips/mt7621/profiles/mqmaker.mk b/target/linux/ramips/mt7621/profiles/mqmaker.mk index ae35e7d..a9c79df 100644 --- a/target/linux/ramips/mt7621/profiles/mqmaker.mk +++ b/target/linux/ramips/mt7621/profiles/mqmaker.mk @@ -5,7 +5,7 @@ # See /LICENSE for more information. # -define Profile/witi +define Profile/WITI NAME:=MQmaker WiTi FEATURES+=rtc PACKAGES:=\ @@ -14,7 +14,7 @@ define Profile/witi kmod-rtc-pcf8563 kmod-i2c-mt7621 endef -define Profile/witi/Description +define Profile/WITI/Description Package set compatible with MQmaker WiTi board. endef -$(eval $(call Profile,witi)) +$(eval $(call Profile,WITI)) -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 5/5] ramips: mt7621: fix Ubiquiti EdgeRouter X profile
Remove unnecessary packages to reduce image size so it fits in initramfs (to enable upgrading from factory firmware). Signed-off-by: Roman Yeryomin --- target/linux/ramips/mt7621/profiles/ubnt.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/ramips/mt7621/profiles/ubnt.mk b/target/linux/ramips/mt7621/profiles/ubnt.mk index b66b206..3f1af02 100644 --- a/target/linux/ramips/mt7621/profiles/ubnt.mk +++ b/target/linux/ramips/mt7621/profiles/ubnt.mk @@ -8,7 +8,8 @@ define Profile/UBNT-ERX NAME:=Ubiquiti EdgeRouter X FEATURES+=nand -usb - PACKAGES:=-kmod-mt76 -wpad-mini -kmod-cfg80211 + PACKAGES:=-kmod-mt76 -kmod-rt2800-pci -kmod-cfg80211 \ + -wpad-mini -iwinfo endef define Profile/UBNT-ERX/Description -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: allow to set arbitrary ip address and netmask
Signed-off-by: Roman Yeryomin
---
package/base-files/files/bin/config_generate | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/package/base-files/files/bin/config_generate
b/package/base-files/files/bin/config_generate
index 4256d3c..03d1a36 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -56,11 +56,11 @@ generate_static_network() {
addr_offset=2
generate_network() {
- local ifname macaddr protocol type
+ local ifname macaddr protocol type ipaddr netmask
json_select network
json_select "$1"
- json_get_vars ifname macaddr protocol
+ json_get_vars ifname macaddr protocol ipaddr netmask
json_select ..
json_select ..
@@ -88,16 +88,18 @@ generate_network() {
case "$protocol" in
static)
- local ipaddr
+ local ipad
case "$1" in
- lan) ipaddr="192.168.1.1" ;;
- *) ipaddr="192.168.$((addr_offset++)).1" ;;
+ lan) ipad=${ipaddr:-"192.168.1.1"} ;;
+ *)
ipad=${ipaddr:-"192.168.$((addr_offset++)).1"} ;;
esac
+ netm=${netmask:-"255.255.255.0"}
+
uci -q batch <<-EOF
set network.$1.proto='static'
- set network.$1.ipaddr='$ipaddr'
- set network.$1.netmask='255.255.255.0'
+ set network.$1.ipaddr='$ipad'
+ set network.$1.netmask='$netm'
set network.$1.ip6assign='60'
EOF
;;
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 3 May 2016 at 23:19, Bruno Randolf wrote: > On 03/05/16 18:59, Jo-Philipp Wich wrote: >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> ... >> Jo-Philipp Wich, >> John Crispin, >> Daniel Golle, >> Felix Fietkau, >> Hauke Mehrtens >> John Crispin >> Matthias Schiffer, >> Steven Barth > > While a fresh start and a more open process is good move, given this > list of supporters it sounds a bit ridiculous... who is left in the > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? Indeed. Looks like silent rebranding. Without public discussion of the issues (and possible ways to fix them) in mailing list Same people, rules and methods. Could you elaborate more and explain how exactly LEDE is going to fix the listed problems? And why it's not possible to fix them inside existing project? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 4 May 2016 at 09:13, Reinoud Koornstra wrote: > On Tue, May 3, 2016 at 7:54 PM, Outback Dingo wrote: >> >> >> On Wed, May 4, 2016 at 12:50 AM, Roman Yeryomin >> wrote: >>> >>> On 3 May 2016 at 23:19, Bruno Randolf wrote: >>> > On 03/05/16 18:59, Jo-Philipp Wich wrote: >>> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >>> >> ... >>> >> Jo-Philipp Wich, >>> >> John Crispin, >>> >> Daniel Golle, >>> >> Felix Fietkau, >>> >> Hauke Mehrtens >>> >> John Crispin >>> >> Matthias Schiffer, >>> >> Steven Barth >>> > >>> > While a fresh start and a more open process is good move, given this >>> > list of supporters it sounds a bit ridiculous... who is left in the >>> > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? >> >> >> come on.. is this a joke? same names, same faces, if you sliced this list >> off from the current dev group, who is actually left anyway on that >> note, if its legit, ill jump onboard and throw my hat in the ring also due >> to my trust and respect for those that are listed. > > I am kind of surprised. > There are still daily checkins in the tree. > Still some people are adding support for boards. > Hence I must not understand the notion of inactiveness. > The value of openwrt is still invaluable. > If rebranding helps pumping additional life into it, why not... I'm not against rebranding but I don't see how it fixes the problem. IMO it only makes it worse. >> >>> >>> >>> Indeed. Looks like silent rebranding. Without public discussion of the >>> issues (and possible ways to fix them) in mailing list Same people, >>> rules and methods. >>> Could you elaborate more and explain how exactly LEDE is going to fix >>> the listed problems? And why it's not possible to fix them inside >>> existing project? >>> >>> ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 4 May 2016 at 10:31, Roman Yeryomin wrote: > On 4 May 2016 at 09:13, Reinoud Koornstra wrote: >> On Tue, May 3, 2016 at 7:54 PM, Outback Dingo wrote: >>> >>> >>> On Wed, May 4, 2016 at 12:50 AM, Roman Yeryomin >>> wrote: >>>> >>>> On 3 May 2016 at 23:19, Bruno Randolf wrote: >>>> > On 03/05/16 18:59, Jo-Philipp Wich wrote: >>>> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >>>> >> ... >>>> >> Jo-Philipp Wich, >>>> >> John Crispin, >>>> >> Daniel Golle, >>>> >> Felix Fietkau, >>>> >> Hauke Mehrtens >>>> >> John Crispin >>>> >> Matthias Schiffer, >>>> >> Steven Barth >>>> > >>>> > While a fresh start and a more open process is good move, given this >>>> > list of supporters it sounds a bit ridiculous... who is left in the >>>> > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? >>> >>> >>> come on.. is this a joke? same names, same faces, if you sliced this list >>> off from the current dev group, who is actually left anyway on that >>> note, if its legit, ill jump onboard and throw my hat in the ring also due >>> to my trust and respect for those that are listed. >> >> I am kind of surprised. >> There are still daily checkins in the tree. >> Still some people are adding support for boards. >> Hence I must not understand the notion of inactiveness. >> The value of openwrt is still invaluable. >> If rebranding helps pumping additional life into it, why not... > > I'm not against rebranding but I don't see how it fixes the problem. > IMO it only makes it worse. > >>> >>>> >>>> >>>> Indeed. Looks like silent rebranding. Without public discussion of the >>>> issues (and possible ways to fix them) in mailing list Same people, >>>> rules and methods. >>>> Could you elaborate more and explain how exactly LEDE is going to fix >>>> the listed problems? And why it's not possible to fix them inside >>>> existing project? >>>> >>>> John, others, "The name LEDE stands for Linux Embedded Development Environment." sounds like build system only. I would vote for separating build system into separate project. Actually, if you remember, I was proposing this several years ago. It would make more sense and would better fit LEDE name. Though "Linux" can be subtracted from there as it's capable of building also MCU projects. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 4 May 2016 at 19:25, Kathy Giori wrote: > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich wrote: >> Hi, >> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> . >> >> The project is founded as a spin-off of the OpenWrt project and shares >> many of the same goals. > > While I appreciate the enthusiasm, I do not see why you cannot apply > these same "principles" of openness and transparency to the OpenWrt > project. Makes no sense to me to branch the project. That simply > divides the resources in the community into fewer numbers working on > each fork. Exactly, tearing down the project and community without any real explanations (and plans to solve the stated issues) is just wrong. > Also wearing my hat within the prpl Foundation, which is funded by > industry sponsorships that in turn provides financial support for > OpenWrt, no one I have spoken to in prpl understands the reason for > this spin-off either. It'll cause more confusion and inefficiency in > industry. prpl will stick with OpenWrt, and I expect most companies > who follow and/or contribute to OpenWrt will stick with it too. > > kathy > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 4 May 2016 at 21:35, Luiz Angelo Daros de Luca wrote: > It is really strange that the decision to create a new project was so opaque > when it was motivated to be a more "transparent project". > They could've started to be more transparent already with the decision to > create a new project. > > Maybe the answer for the need of an external reboot might be not in the > names that jumped into but on those left behind. > Maybe it was easier to create a new project than to boot out the problems. Well, like you said yourself, why they didn't start discussing the problems (and possible solutions) in open space then? Then the reasons would be more or less clear. But now it seems that community will be confused a lot. At least I'm completely confused. > My 2 cents, > > Em qua, 4 de mai de 2016 às 14:50, Roman Yeryomin > escreveu: >> >> On 4 May 2016 at 19:25, Kathy Giori wrote: >> > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich >> > wrote: >> >> Hi, >> >> >> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> >> . >> >> >> >> The project is founded as a spin-off of the OpenWrt project and shares >> >> many of the same goals. >> > >> > While I appreciate the enthusiasm, I do not see why you cannot apply >> > these same "principles" of openness and transparency to the OpenWrt >> > project. Makes no sense to me to branch the project. That simply >> > divides the resources in the community into fewer numbers working on >> > each fork. >> >> Exactly, tearing down the project and community without any real >> explanations (and plans to solve the stated issues) is just wrong. >> >> > Also wearing my hat within the prpl Foundation, which is funded by >> > industry sponsorships that in turn provides financial support for >> > OpenWrt, no one I have spoken to in prpl understands the reason for >> > this spin-off either. It'll cause more confusion and inefficiency in >> > industry. prpl will stick with OpenWrt, and I expect most companies >> > who follow and/or contribute to OpenWrt will stick with it too. >> > >> > kathy >> > ___ >> > openwrt-devel mailing list >> > openwrt-devel@lists.openwrt.org >> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > -- > > Luiz Angelo Daros de Luca > luizl...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 4 May 2016 at 23:19, tapper wrote: > On 04/05/2016 21:01, mbm wrote: >> >> Dear OpenWrt community, >> >> It is with a great amount of surprise that, like all of you, we read >> about the announcement of the LEDE project yesterday, as there was no >> prior announcement nor clues this would happen. >> >> While we recognize the current OpenWrt project suffers from a number of >> issues outlined by Jo-Philip, in each of the 5 bullet points, we do not >> agree with the conclusions withdrawn, and even less so in deciding to >> spin off the OpenWrt project in the first place as a way to fix the >> project and its community. Also, the phrases such as a "reboot" are both >> vague and misleading and the LEDE project failed to identify its true >> nature. The LEDE announcement contains a number of very valid points >> which we hoped we had an opportunity to discuss and attempt to fix, in a >> public manner, before this more radical outcome. At this point, the >> email as well as actions taken are very confusing to a lot of us. >> >> OpenWrt is primarily developed by individuals who may have a day job >> more or less related to the purpose or the technologies of the project, >> but who strive to maintain OpenWrt as independent as possible from any >> company, organization or interest group, thus maintaining its own >> infrastructure (website, forums, mailing-lists, bugtracker...), which >> has been usually at the heart of all debates. >> >> We do acknowledge there has been internal disagreements, on several >> occasions about some directions of the project, about the release model, >> the lack of testing, the centralized infrastructure, however, there have >> been actual work going on under the hoods to solve things one step at a >> time, starting with a more decentralized infrastructure, which was >> discussed with the LEDE developers as well. >> >> At this point, we do not have much to offer to the LEDE developers but >> to encourage them to publicly discuss on >> openwrt-devel@lists.openwrt.org the different items we should all be >> fixing together, and avoid spinning off so that all decisions can be >> taken with the community's involvement, and accountability and >> transparency can rule us as one community. >> >> As a user, developer, contributor, or just community member, whatever >> choice you make, keep the choice that matters to you: the ability to >> utilize superior quality open source software to power whatever embedded >> device that matters to you! >> >> We would like to stress that we do want to have an open discussion and >> resolve matters at hand. Our goal is to work with all parties who can >> and want to contribute to OpenWrt, including the LEDE team. >> >> Sincerely, >> Your OpenWrt team >> __ > > > But just who is "Your OpenWrt team?" > After all the talk about fixing the website and the forum we as the openwrt > end users got jack shit! Even wen we offered to do things for you. > Probably one of the problems is that not all read all communication channels. I think that developers are more used to mailing list. Blaming only those who left doesn't make any sense, IMO all are responsible. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 06:48, Daniel Dickinson wrote: > On 16-05-04 04:01 PM, mbm wrote: >> Dear OpenWrt community, >> >> spin off the OpenWrt project in the first place as a way to fix the >> project and its community. Also, the phrases such as a "reboot" are both >> vague and misleading and the LEDE project failed to identify its true >> nature. The LEDE announcement contains a number of very valid points > > Can you be more specific about what you believe is LEDE's 'true nature'? > >> which we hoped we had an opportunity to discuss and attempt to fix, in a >> public manner, before this more radical outcome. At this point, the >> email as well as actions taken are very confusing to a lot of us. > > This is a guess: perhaps it is connected to the fact that Felix's > n...@openwrt.org address now bounces, and that actions were taken which > were deemed to be over-the-top by the LEDE team? Certainly there is a > great deal more doing on that either side is saying in public (which > might be just as well since there seems to be a fair amount of bad > feelings on both sides). One simple question: If LEDE team members are the ones who were suffering from some non-democratic decisions, why didn't they bring it to public discussion for community? At least on devel maillist? If it was clear problem in remaining OpenWrt team then LEDE would win the community right away or maybe problematic people would just go away. Either way it would be more fair and open. And this is one of my biggest concerns - LEDE team is promoting openness but didn't do their moves openly (looking at maillists it seems they were hiding it for month at least). Hate double standards. >> We do acknowledge there has been internal disagreements, on several >> occasions about some directions of the project, about the release model, >> the lack of testing, the centralized infrastructure, however, there have >> been actual work going on under the hoods to solve things one step at a > > Perhaps 'under-the-hood' is the problem. Did everyone with concerns > know or have insight into what steps were currently being taken and what > was planned, and have planned actions been followed through on, once > *agreed* as a solution? > > Also, is the decision making process egalitarian and democratic amongst > those still actively in the project, or are some 'more equal' than others? > > Regards, > > Daniel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 13:16, John Clark wrote: >>Could you elaborate more and explain how exactly LEDE is going to fix > the listed problems? And why it's not possible to fix them inside > existing project? > > The hasty reasons given and the secret and abrupt severing of ties make me > wonder if a "follow the money" approach will yield more plausible answers to > the questions being raised. maybe a good point, how do you "follow the money"? > On Thu, May 5, 2016 at 5:34 AM, Roman Yeryomin > wrote: >> >> On 5 May 2016 at 06:48, Daniel Dickinson >> wrote: >> > On 16-05-04 04:01 PM, mbm wrote: >> >> Dear OpenWrt community, >> >> >> >> spin off the OpenWrt project in the first place as a way to fix the >> >> project and its community. Also, the phrases such as a "reboot" are >> >> both >> >> vague and misleading and the LEDE project failed to identify its true >> >> nature. The LEDE announcement contains a number of very valid points >> > >> > Can you be more specific about what you believe is LEDE's 'true nature'? >> > >> >> which we hoped we had an opportunity to discuss and attempt to fix, in >> >> a >> >> public manner, before this more radical outcome. At this point, the >> >> email as well as actions taken are very confusing to a lot of us. >> > >> > This is a guess: perhaps it is connected to the fact that Felix's >> > n...@openwrt.org address now bounces, and that actions were taken which >> > were deemed to be over-the-top by the LEDE team? Certainly there is a >> > great deal more doing on that either side is saying in public (which >> > might be just as well since there seems to be a fair amount of bad >> > feelings on both sides). >> >> One simple question: >> If LEDE team members are the ones who were suffering from some >> non-democratic decisions, why didn't they bring it to public >> discussion for community? At least on devel maillist? >> >> If it was clear problem in remaining OpenWrt team then LEDE would win >> the community right away or maybe problematic people would just go >> away. Either way it would be more fair and open. And this is one of my >> biggest concerns - LEDE team is promoting openness but didn't do their >> moves openly (looking at maillists it seems they were hiding it for >> month at least). Hate double standards. >> >> >> >> We do acknowledge there has been internal disagreements, on several >> >> occasions about some directions of the project, about the release >> >> model, >> >> the lack of testing, the centralized infrastructure, however, there >> >> have >> >> been actual work going on under the hoods to solve things one step at a >> > >> > Perhaps 'under-the-hood' is the problem. Did everyone with concerns >> > know or have insight into what steps were currently being taken and what >> > was planned, and have planned actions been followed through on, once >> > *agreed* as a solution? >> > >> > Also, is the decision making process egalitarian and democratic amongst >> > those still actively in the project, or are some 'more equal' than >> > others? >> > >> > Regards, >> > >> > Daniel >> > ___ >> > openwrt-devel mailing list >> > openwrt-devel@lists.openwrt.org >> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 17:43, Daniel Dickinson wrote: > On 16-05-05 05:34 AM, Roman Yeryomin wrote: >> On 5 May 2016 at 06:48, Daniel Dickinson >> wrote: >>> On 16-05-04 04:01 PM, mbm wrote: >>>> Dear OpenWrt community, >>>> > [snip] >> >> One simple question: >> If LEDE team members are the ones who were suffering from some >> non-democratic decisions, why didn't they bring it to public >> discussion for community? At least on devel maillist? >> >> If it was clear problem in remaining OpenWrt team then LEDE would win >> the community right away or maybe problematic people would just go >> away. Either way it would be more fair and open. And this is one of my >> biggest concerns - LEDE team is promoting openness but didn't do their >> moves openly (looking at maillists it seems they were hiding it for >> month at least). Hate double standards. > > Perhaps for fear of repercussions such as what has happened since the > fork where all LEDE members @openwrt.org email addresses have been deleted? AFAIK, that was done after LEDE announcement but IMO was a wrong move anyway. > There are a number of people in the LEDE group I've found to be pretty > decent people, and great to work with, so I find it unlikely that they > simply acted without good reason. This only add more shock to the announcement. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 19:29, Daniel Dickinson wrote: > On 16-05-05 12:24 PM, Daniel Dickinson wrote: >> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >> [snip] >>> > The changes that the Lede guys are suggesting would be welcome, but >>> > splitting the project and community with an ugly fork is very much not >>> > welcome. >>> >>> Let's just say that there are strong personalities who haven't been >>> working well together and that this has been a long time coming; perhaps >>> if something like using a mediator had been considered before things got >>> to this point it would have helped. At this point I'm not sure >>> there is a >>> solution unless both sides are willing to bend a little (I'm really not >>> sure who has been flexible and who has not, but as I have said I suspect >>> a large part of the issue is that 'management' (who aren't and don't, >>> really) has overruled those doing the majority of the work and in an >>> open source project that doesn't fly). >>> >>> I don't disagree. I just see the current state of Openwrt/Lede as a >>> mess for the community. >> >> I agree, I just don't see how the LEDE team could have avoided it >> without giving up and accepting the broken status quo. > > When I say broken I mean I think openwrt was dying and I pointed out not > all that long ago that openwrt was in bad position and that something > needed to change, and I think that may have been *part* of the reason > accepting the status quo was no longer an acceptable answer. I don't believe that those who are in LEDE now couldn't do anything (that means is was dying in their hands). Actually I'm still under impression that they controlled pretty much everything. And the part they didn't control (what exactly?) was only important to them. But I guess we will never know full story, unless both parties are willing to disclose all their private conversations related to project. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 20:09, Daniel Dickinson wrote: > On 16-05-05 12:59 PM, Roman Yeryomin wrote: >> On 5 May 2016 at 19:29, Daniel Dickinson >> wrote: >>> On 16-05-05 12:24 PM, Daniel Dickinson wrote: >>>> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >>>> [snip] > [snip] >>> When I say broken I mean I think openwrt was dying and I pointed out not >>> all that long ago that openwrt was in bad position and that something >>> needed to change, and I think that may have been *part* of the reason >>> accepting the status quo was no longer an acceptable answer. >> >> I don't believe that those who are in LEDE now couldn't do anything >> (that means is was dying in their hands). Actually I'm still under > > I guess the real test will be what happens going forward - if LEDE dies > for the same reasons OpenWrt was dying then that puts paid to LEDE's > story; it it succeeds then it vindicates them. I hope the problems will be resolved and we will have one project. >> impression that they controlled pretty much everything. And the part >> they didn't control (what exactly?) was only important to them. > > I have no clue about this part, I'm not exactly in the loop. I think > part of the problem has been that there is no means to add new > developers, and that suggestions for adding developers have been opposed > (that's a guess though). I don't think it was opposed. And I don't think it was a major problem. >> But I guess we will never know full story, unless both parties are >> willing to disclose all their private conversations related to >> project. > > Yeah, pretty much we're left guessing unless there is more information > given. I'm thinking the LEDE split was not like a conspiratorial split > where everything is carefully planned out and orchestrated, but more of > a rapid response (given that this isn't part of paid work for the most > of them, and even then the LEDE split wouldn't likely be part of the > job/contract) to something behind the scenes. Even if the LEDE team is > unable to post to this list, I hope they give more information using the > avenues available to them, once they get the chance to do so. Look at mailing list, commits and domain. It was all started back in March and was not disclosed. That means the plans were even earlier. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 6 May 2016 at 03:53, Luka Perkov wrote: >>On 2016-05-05 20:22, mbm wrote: >>> On 5/5/2016 7:40 AM, Felix Fietkau wrote: Many of the changes that we previously tried to introduce were often squashed by internal disagreements. Resulting discussions often turned toxic quickly and led to nothing being done to address the issues. Setting up the LEDE project was our way of creating a testbed for changes that we believe are important for the survival of the project. >>> >>> Change is not easy. Discussions need to happen. The problem is simply >>> kicking out people you didn't agree with by starting a new organization >>> in secret; you've created the public perception that we're somehow >>> against you when really we all want the same things. >> >> Years of internal discussion led nowhere. Maybe it helps now that we're >> making the whole issue public. > > For the sake of transparency, we've had public discussions, about a number of > things, for example switching to Git: > > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036480.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036486.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036500.html > > And based on these inputs from you the switch was not made even though several > OpenWrt developers wanted to switch. > > Also, server outages can happen to anybody: > - https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038547.html > > However, we do not want to point fingers. What we do want is to make a great > community around OpenWrt and to drive innovation - just like it has been done > for more then a decade now. > > There has been a long history - mostly good, sometimes bad - since the project > started from a garage project, to now having a project used by an awesome > amount of users. This can be seen from the constructive discussions in this > list on a daily basis, and in this very thread. Also, the project is used as > the main SDK by many silicon vendors internally, and by vast number of > companies on the embedded market. > > We are open for a discussion and would like to keep the OpenWrt's and it's > community interests in the first place. Splitting the project does not make > sense. Do you agree? > We appreciate your effort to have an open discussion about this, however the sudden deletion of our widely published openwrt.org email addresses somewhat undermines this. We will not respond in kind and we will continue to maintain the critical parts of OpenWrt infrastructure that we control. >>> >>> Let's be clear on this subject; no commit access was revoked, you still >>> have full read and write access to the entire OpenWrt tree. >>> >>> Email forwarding was temporarily disabled following the LEDE announcement >>> - LEDE's own rules prohibit project based email addresses >> No, they don't. They state that the LEDE project won't provide project >> email addresses. Interpreting that as meaning that we shouldn't be able >> to access our openwrt.org addresses is more than a bit of a stretch. > > In any case, due to the events that happened and the fact that the OpenWrt > name > is being used in a manner opposite of the projects best interest, we felt that > these actions were needed in order to avoid the further damages to the > project. > >>> - It's unclear if LEDE still represents OpenWrt >> So? Asking us to not send any further emails about LEDE from our >> openwrt.org addresses should have been enough. > > Actually, this was discussed on #lede-adm. IRC history is hard to follow, I'd better assume that something not written here never happened. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote:
>
> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2]
> closed Felix'es OpenWRT email account (bad choice! emails bouncing).
> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project
> is in some kind of conflict.
>
> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349
>
> [2]
> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335
OK, so, after porting the patch to 4.1 openwrt kernel and playing a
bit with fq_codel limits I was able to get 420Mbps UDP like this:
tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256
This is certainly better than 30Mbps but still more than two times
less than before (900).
TCP also improved a little (550 to ~590).
Felix, others, do you want to see the ported patch, maybe I did something wrong?
Doesn't look like it will save ath10k from performance regression.
>
> On Fri, 6 May 2016 11:42:43 +0200
> Jesper Dangaard Brouer wrote:
>
>> Hi Felix,
>>
>> This is an important fix for OpenWRT, please read!
>>
>> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024,
>> without also adjusting q->flows_cnt. Eric explains below that you must
>> also adjust the buckets (q->flows_cnt) for this not to break. (Just
>> adjust it to 128)
>>
>> Problematic OpenWRT commit in question:
>> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e
>> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from
>> causing too much cpu load with higher speed (#21326)")
>>
>>
>> I also highly recommend you cherry-pick this very recent commit:
>> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()")
>> https://git.kernel.org/davem/net-next/c/9d18562a227
>>
>> This should fix very high CPU usage in-case fq_codel goes into drop mode.
>> The problem is that drop mode was considered rare, and implementation
>> wise it was chosen to be more expensive (to save cycles on normal mode).
>> Unfortunately is it easy to trigger with an UDP flood. Drop mode is
>> especially expensive for smaller devices, as it scans a 4K big array,
>> thus 64 cache misses for small devices!
>>
>> The fix is to allow drop-mode to bulk-drop more packets when entering
>> drop-mode (default 64 bulk drop). That way we don't suddenly
>> experience a significantly higher processing cost per packet, but
>> instead can amortize this.
>>
>> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk
>> drop, given we also recommend bucket size to be 128 ? (thus the amount
>> of memory to scan is less, but their CPU is also much smaller).
>>
>> --Jesper
>>
>>
>> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet
>> wrote:
>>
>> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote:
>> > > On 5 May 2016 at 19:12, Eric Dumazet wrote:
>> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote:
>> > > >
>> > > >>
>> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn
>> > > >> Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0)
>> > > >> backlog 0b 0p requeues 0
>> > > >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>> > > >> new_flows_len 0 old_flows_len 0
>> > > >
>> > > >
>> > > > Limit of 1024 packets and 1024 flows is not wise I think.
>> > > >
>> > > > (If all buckets are in use, each bucket has a virtual queue of 1
>> > > > packet,
>> > > > which is almost the same than having no queue at all)
>> > > >
>> > > > I suggest to have at least 8 packets per bucket, to let Codel have a
>> > > > chance to trigger.
>> > > >
>> > > > So you could either reduce number of buckets to 128 (if memory is
>> > > > tight), or increase limit to 8192.
>> > >
>> > > Will try, but what I've posted is default, I didn't change/configure
>> > > that.
>> >
>> > fq_codel has a default of 10240 packets and 1024 buckets.
>> >
>> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413
>> >
>> > If someone changed that in the linux variant you use, he probably should
>> > explain the rationale.
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> Author of http://www.iptv-analyzer.org
> LinkedIn: http://www.linkedin.com/in/brouer
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 6 May 2016 at 21:43, Roman Yeryomin wrote:
> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote:
>>
>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2]
>> closed Felix'es OpenWRT email account (bad choice! emails bouncing).
>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project
>> is in some kind of conflict.
>>
>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349
>>
>> [2]
>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335
>
> OK, so, after porting the patch to 4.1 openwrt kernel and playing a
> bit with fq_codel limits I was able to get 420Mbps UDP like this:
> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256
Forgot to mention, I've reduced drop_batch_size down to 32
> This is certainly better than 30Mbps but still more than two times
> less than before (900).
> TCP also improved a little (550 to ~590).
>
> Felix, others, do you want to see the ported patch, maybe I did something
> wrong?
> Doesn't look like it will save ath10k from performance regression.
>
>>
>> On Fri, 6 May 2016 11:42:43 +0200
>> Jesper Dangaard Brouer wrote:
>>
>>> Hi Felix,
>>>
>>> This is an important fix for OpenWRT, please read!
>>>
>>> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024,
>>> without also adjusting q->flows_cnt. Eric explains below that you must
>>> also adjust the buckets (q->flows_cnt) for this not to break. (Just
>>> adjust it to 128)
>>>
>>> Problematic OpenWRT commit in question:
>>> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e
>>> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from
>>> causing too much cpu load with higher speed (#21326)")
>>>
>>>
>>> I also highly recommend you cherry-pick this very recent commit:
>>> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()")
>>> https://git.kernel.org/davem/net-next/c/9d18562a227
>>>
>>> This should fix very high CPU usage in-case fq_codel goes into drop mode.
>>> The problem is that drop mode was considered rare, and implementation
>>> wise it was chosen to be more expensive (to save cycles on normal mode).
>>> Unfortunately is it easy to trigger with an UDP flood. Drop mode is
>>> especially expensive for smaller devices, as it scans a 4K big array,
>>> thus 64 cache misses for small devices!
>>>
>>> The fix is to allow drop-mode to bulk-drop more packets when entering
>>> drop-mode (default 64 bulk drop). That way we don't suddenly
>>> experience a significantly higher processing cost per packet, but
>>> instead can amortize this.
>>>
>>> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk
>>> drop, given we also recommend bucket size to be 128 ? (thus the amount
>>> of memory to scan is less, but their CPU is also much smaller).
>>>
>>> --Jesper
>>>
>>>
>>> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet
>>> wrote:
>>>
>>> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote:
>>> > > On 5 May 2016 at 19:12, Eric Dumazet wrote:
>>> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote:
>>> > > >
>>> > > >>
>>> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>>> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn
>>> > > >> Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0)
>>> > > >> backlog 0b 0p requeues 0
>>> > > >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>> > > >> new_flows_len 0 old_flows_len 0
>>> > > >
>>> > > >
>>> > > > Limit of 1024 packets and 1024 flows is not wise I think.
>>> > > >
>>> > > > (If all buckets are in use, each bucket has a virtual queue of 1
>>> > > > packet,
>>> > > > which is almost the same than having no queue at all)
>>> > > >
>>> > > > I suggest to have at least 8 packets per bucket, to let Codel have a
>>> > > > chance to trigger.
>>> > > >
>>> > > > So you could either reduce number of buckets to 128 (if memory is
>>> > > > tight), or increase limit to 8192.
>>> > >
>>> > > Will try, but what I've posted is default, I didn't change/configure
>>> > > that.
>>> >
>>> > fq_codel has a default of 10240 packets and 1024 buckets.
>>> >
>>> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413
>>> >
>>> > If someone changed that in the linux variant you use, he probably should
>>> > explain the rationale.
>>
>> --
>> Best regards,
>> Jesper Dangaard Brouer
>> MSc.CS, Principal Kernel Engineer at Red Hat
>> Author of http://www.iptv-analyzer.org
>> LinkedIn: http://www.linkedin.com/in/brouer
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 6 May 2016 at 22:43, Dave Taht wrote: > On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote: >> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>> >>>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2] >>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>> is in some kind of conflict. >>>> >>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>> >>>> [2] >>>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>> >>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >> >> Forgot to mention, I've reduced drop_batch_size down to 32 > > 0) Not clear to me if that's the right line, there are 4 wifi queues, > and the third one > is the BE queue. That was an example, sorry, should have stated that. I've applied same settings to all 4 queues. > That is too low a limit, also, for normal use. And: > for the purpose of this particular UDP test, flows 16 is ok, but not > ideal. I played with different combinations, it doesn't make any (significant) difference: 20-30Mbps, not more. What numbers would you propose? > 1) What's the tcp number (with a simultaneous ping) with this latest patchset? > (I care about tcp performance a lot more than udp floods - surviving a > udp flood yes, performance, no) During the test (both TCP and UDP) it's roughly 5ms in average, not running tests ~2ms. Actually I'm now wondering if target is working at all, because I had same result with target 80ms.. So, yes, latency is good, but performance is poor. > before/after? > > tc -s qdisc show dev wlan0 during/after results? during the test: qdisc mq 0: root Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues 17) backlog 1545794b 1021p requeues 17 qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues 17) backlog 1541252b 1018p requeues 17 maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 after the test (60sec): qdisc mq 0: root Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) backlog 0b 0p requeues 28 qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) backlog 0b 0p requeues 28 maxpacket 1514 drop_overlimit 2770176 new_flow_count 64 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 > IF you are doing builds for the archer c7v2, I can join in on this... (?) I'm not
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 16 May 2016 at 02:07, Eric Dumazet wrote: > On Mon, 2016-05-16 at 01:34 +0300, Roman Yeryomin wrote: > >> qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 >> target 80.0ms ce_threshold 32us interval 100.0ms ecn >> Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues >> 17) >> backlog 1541252b 1018p requeues 17 >> maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 >> new_flows_len 0 old_flows_len 1 > > Why do you have ce_threshold set ? You really should not (even if it > does not matter for the kind of traffic you have at this moment) No idea, it was there always. How do I unset it? Setting it to 0 doesn't help. > If your expected link speed is around 1Gbps, or 80,000 packets per > second, then you have to understand that 1024 packets limit is about 12 > ms at most. > > Even if the queue is full, max sojourn time of a packet would be 12 ms. > > I really do not see how 'target 80 ms' could be hit. Well, as I said, I've tried different options. Neither target 20ms (as Dave proposed) not 12ms save the situation. > You basically have FQ, with no Codel effect, but with the associated > cost of Codel (having to take timestamps) > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 16 May 2016 at 01:34, Roman Yeryomin wrote: > On 6 May 2016 at 22:43, Dave Taht wrote: >> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin >> wrote: >>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>>> >>>>> I've created a OpenWRT ticket[1] on this issue, as it seems that >>>>> someone[2] >>>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>>> is in some kind of conflict. >>>>> >>>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>>> >>>>> [2] >>>>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>>> >>>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >>> >>> Forgot to mention, I've reduced drop_batch_size down to 32 >> >> 0) Not clear to me if that's the right line, there are 4 wifi queues, >> and the third one >> is the BE queue. > > That was an example, sorry, should have stated that. I've applied same > settings to all 4 queues. > >> That is too low a limit, also, for normal use. And: >> for the purpose of this particular UDP test, flows 16 is ok, but not >> ideal. > > I played with different combinations, it doesn't make any > (significant) difference: 20-30Mbps, not more. > What numbers would you propose? > >> 1) What's the tcp number (with a simultaneous ping) with this latest >> patchset? >> (I care about tcp performance a lot more than udp floods - surviving a >> udp flood yes, performance, no) > > During the test (both TCP and UDP) it's roughly 5ms in average, not > running tests ~2ms. Actually I'm now wondering if target is working at > all, because I had same result with target 80ms.. > So, yes, latency is good, but performance is poor. > >> before/after? >> >> tc -s qdisc show dev wlan0 during/after results? > > during the test: > > qdisc mq 0: root > Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues 17) > backlog 1545794b 1021p requeues 17 > qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues 17) > backlog 1541252b 1018p requeues 17 > maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 > new_flows_len 0 old_flows_len 1 > qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > > > after the test (60sec): > > qdisc mq 0: root > Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) > backlog 0b 0p requeues 28 > qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 3084996052 bytes 2037744 pkt (dropped 277017
Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 16 May 2016 at 11:12, David Lang wrote: > On Mon, 16 May 2016, Roman Yeryomin wrote: > >> On 6 May 2016 at 22:43, Dave Taht wrote: >>> >>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin >>> wrote: >>>> >>>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>>> >>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer >>>>> wrote: >>>>>> >>>>>> >> >>> That is too low a limit, also, for normal use. And: >>> for the purpose of this particular UDP test, flows 16 is ok, but not >>> ideal. >> >> >> I played with different combinations, it doesn't make any >> (significant) difference: 20-30Mbps, not more. >> What numbers would you propose? > > > How many different flows did you have going at once? I believe that the > reason for higher numbers isn't for throughput, but to allow for more flows > to be isolated from each other. If you have too few buckets, different flows > will end up being combined into one bucket so that one will affect the other > more. I'm testing with one flow, I never saw bigger performance with more flows (e.g. -P8 to iperf3). Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 16 May 2016 at 19:04, Dave Taht wrote: > On Mon, May 16, 2016 at 1:14 AM, Roman Yeryomin wrote: >> On 16 May 2016 at 01:34, Roman Yeryomin wrote: >>> On 6 May 2016 at 22:43, Dave Taht wrote: >>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin >>>> wrote: >>>>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>>>>> >>>>>>> I've created a OpenWRT ticket[1] on this issue, as it seems that >>>>>>> someone[2] >>>>>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>>>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>>>>> is in some kind of conflict. >>>>>>> >>>>>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>>>>> >>>>>>> [2] >>>>>>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>>>>> >>>>>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>>>>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>>>>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >>>>> >>>>> Forgot to mention, I've reduced drop_batch_size down to 32 >>>> >>>> 0) Not clear to me if that's the right line, there are 4 wifi queues, >>>> and the third one >>>> is the BE queue. >>> >>> That was an example, sorry, should have stated that. I've applied same >>> settings to all 4 queues. >>> >>>> That is too low a limit, also, for normal use. And: >>>> for the purpose of this particular UDP test, flows 16 is ok, but not >>>> ideal. >>> >>> I played with different combinations, it doesn't make any >>> (significant) difference: 20-30Mbps, not more. >>> What numbers would you propose? >>> >>>> 1) What's the tcp number (with a simultaneous ping) with this latest >>>> patchset? >>>> (I care about tcp performance a lot more than udp floods - surviving a >>>> udp flood yes, performance, no) >>> >>> During the test (both TCP and UDP) it's roughly 5ms in average, not >>> running tests ~2ms. Actually I'm now wondering if target is working at >>> all, because I had same result with target 80ms.. >>> So, yes, latency is good, but performance is poor. >>> >>>> before/after? >>>> >>>> tc -s qdisc show dev wlan0 during/after results? >>> >>> during the test: >>> >>> qdisc mq 0: root >>> Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues >>> 17) >>> backlog 1545794b 1021p requeues 17 >>> qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues >>> 17) >>> backlog 1541252b 1018p requeues 17 >>> maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 >>> new_flows_len 0 old_flows_len 1 >>> qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> >>> >>> after the test (60sec): >>> >>> qdisc mq 0: root >>> Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues >>> 28) &g
Re: [OpenWrt-Devel] OpenWrt / LEDE
On 24 May 2016 at 23:31, Hauke Mehrtens wrote: > Hi, > > As it looks like the IRC meeting will not happen, because not so big > interest by the people not already involved in LEDE and problems finding > a time, lets discuss on the mailing list like suggested by Jow. > > Currently it looks like only Luka is working on OpenWrt as he committed > many patches from LEDE to OpenWrt, which is fine. > > What will happen to the OpenWrt project? To me it looks like nobody > except Luka is interested in working on OpenWrt. Are there any plans to > continue the OpenWrt project or will it just die, only nobody wants to > say it? > Currently this is a bad situation for people that want to contribute > patches because they do not exactly know were to contribute, some post > them just to both list which is probably the best solution for the time > we do not have a real solution. > > I do not plan to contribute much to OpenWrt any more and I do not know > if I can commit anything any more, at least it looks like I was kicked > from the openwrt-hackers mailing list without informing me. I believe LEDE didn't plan to contribute to OpenWrt from the very beginning. LEDE words are pretty contrary to the works. > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? How many devs do you think it's possible to attract to OpenWrt having the promotion LEDE does and remembering the fact that most active devs went to LEDE? Same rules could be applied inside OpenWrt as I see it. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
On 24 May 2016 at 18:51, Eric Schultz wrote: > I think this is a great idea! I very much support a move to Github; despite > it's issues, it's just where development is happening today. Keeping a > non-Github channel for submitting patches is also a great idea I think. > > My free-software side worries about using something non-free like drone.io > for CI but this is a huge task certainly and I'm not sure a free tool would > meet everyone's needs (plus there's the huge added burden of maintenance). How about something like kernelci.org? I'm not sure how to run all this https://github.com/kernelci but the result looks very interesting. > Eric > > On Tue, May 24, 2016 at 9:06 AM, Luka Perkov wrote: >> >> Dear OpenWrt mailing list readers, >> >> as the subject says I'd like to make proposal to move the OpenWrt >> codebase to Git. This was already discussed before [1] and now when >> there are no blockers [2] for this change I'd like that we as a >> community move forward with this switch. >> >> Also, I'd like to propose that we move the project to GitHub and here >> are the reasons why I see this as a good decision: >> >> * GitHub will allow people to contribute more easily >> >> The bigger amount of contributions has already happened and can be seen >> on the packages feed which is already hosted on GitHub. With this I'm >> also hoping to avoid comments regarding invalid patches on the mailing >> list. >> >> For now I am proposing that the current development workflow is also >> accepted - aka. patches that are sent to the mailing list are also >> accepted. >> >> * GitHub and similar services will allow us to integrate more easily >> with other projects >> >> Here specifically I mean integration with modern CI. Here is an example >> of integration with drone.io [3][4]. At the moment this is only in the >> POC stage but what I'd like to do down the line is to: >> >> - build OpenWrt images for all architectures for every pull request >> >> - build OpenWrt package binary for every package pull request for all >> architectures and make it available for download >> >> - build and host OpenWrt qemu and/or Docker image for every pull request >> >> This will allow easy review of the work since flags will be shown in the >> pull request if the build was sucessful or not. Also, this will allow >> people to test changes without building the image and thus lowering the >> time that needs to be spent on maintenance work. >> >> If this proposal gets accepted I'll be sending out an email to get >> access to more build servers so this new build infrastructure can >> properly support the project in a timely fashion. >> >> Please share your thoughts regarding this proposal. >> >> Regards, >> Luka >> >> [1] >> https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html >> [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html >> [3] https://github.com/makkrnic/openwrt-qemu-x86 >> [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > > -- > Eric Schultz, Community Manager, prpl Foundation > http://www.prplfoundation.org > eschu...@prplfoundation.org > cell: 920-539-0404 > skype: ericschultzwi > @EricPrpl > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] rb532: prepare switch to 4.1
Signed-off-by: Roman Yeryomin --- target/linux/rb532/config-3.18 | 146 - target/linux/rb532/config-default | 146 + .../rb532/patches-3.18/001-cmdline_hack.patch | 20 --- .../rb532/patches-3.18/002-rb532_nand_fixup.patch | 47 --- ...tion_info-rename-rootfs-to-rootfs_onboard.patch | 11 -- target/linux/rb532/patches/001-cmdline_hack.patch | 20 +++ .../linux/rb532/patches/002-rb532_nand_fixup.patch | 47 +++ ...tion_info-rename-rootfs-to-rootfs_onboard.patch | 11 ++ 8 files changed, 224 insertions(+), 224 deletions(-) delete mode 100644 target/linux/rb532/config-3.18 create mode 100644 target/linux/rb532/config-default delete mode 100644 target/linux/rb532/patches-3.18/001-cmdline_hack.patch delete mode 100644 target/linux/rb532/patches-3.18/002-rb532_nand_fixup.patch delete mode 100644 target/linux/rb532/patches-3.18/004-rb532_partition_info-rename-rootfs-to-rootfs_onboard.patch create mode 100644 target/linux/rb532/patches/001-cmdline_hack.patch create mode 100644 target/linux/rb532/patches/002-rb532_nand_fixup.patch create mode 100644 target/linux/rb532/patches/004-rb532_partition_info-rename-rootfs-to-rootfs_onboard.patch diff --git a/target/linux/rb532/config-3.18 b/target/linux/rb532/config-3.18 deleted file mode 100644 index 246c5d2..000 --- a/target/linux/rb532/config-3.18 +++ /dev/null @@ -1,146 +0,0 @@ -CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y -CONFIG_ARCH_DISCARD_MEMBLOCK=y -CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y -CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y -CONFIG_ARCH_HIBERNATION_POSSIBLE=y -CONFIG_ARCH_REQUIRE_GPIOLIB=y -CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y -CONFIG_ATA=y -CONFIG_BLK_DEV_SD=y -CONFIG_CC_OPTIMIZE_FOR_SIZE=y -CONFIG_CEVT_R4K=y -CONFIG_CLONE_BACKWARDS=y -CONFIG_CPU_GENERIC_DUMP_TLB=y -CONFIG_CPU_HAS_PREFETCH=y -CONFIG_CPU_HAS_SYNC=y -CONFIG_CPU_LITTLE_ENDIAN=y -CONFIG_CPU_MIPS32=y -CONFIG_CPU_MIPS32_R1=y -CONFIG_CPU_MIPSR1=y -CONFIG_CPU_R4K_CACHE_TLB=y -CONFIG_CPU_R4K_FPU=y -CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_HIGHMEM=y -CONFIG_CRC16=y -CONFIG_CRYPTO_CRC32C=y -CONFIG_CRYPTO_HASH=y -CONFIG_CRYPTO_HASH2=y -CONFIG_CSRC_R4K=y -CONFIG_DMA_NONCOHERENT=y -# CONFIG_ENABLE_WARN_DEPRECATED is not set -CONFIG_EXT4_FS=y -CONFIG_FS_MBCACHE=y -CONFIG_GENERIC_ATOMIC64=y -CONFIG_GENERIC_CLOCKEVENTS=y -CONFIG_GENERIC_CLOCKEVENTS_BUILD=y -CONFIG_GENERIC_CMOS_UPDATE=y -CONFIG_GENERIC_IO=y -CONFIG_GENERIC_IRQ_SHOW=y -CONFIG_GENERIC_PCI_IOMAP=y -CONFIG_GENERIC_SMP_IDLE_THREAD=y -CONFIG_GPIOLIB=y -CONFIG_GPIO_DEVRES=y -CONFIG_GPIO_SYSFS=y -CONFIG_HARDWARE_WATCHPOINTS=y -CONFIG_HAS_DMA=y -CONFIG_HAS_IOMEM=y -CONFIG_HAS_IOPORT=y -# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DMA_API_DEBUG=y -CONFIG_HAVE_DMA_ATTRS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y -CONFIG_HAVE_GENERIC_DMA_COHERENT=y -CONFIG_HAVE_GENERIC_HARDIRQS=y -CONFIG_HAVE_IDE=y -CONFIG_HAVE_MEMBLOCK=y -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE_NET_DSA=y -CONFIG_HAVE_OPROFILE=y -CONFIG_HAVE_PERF_EVENTS=y -# CONFIG_HIGH_RES_TIMERS is not set -CONFIG_HW_HAS_PCI=y -CONFIG_HW_RANDOM=y -CONFIG_HZ=250 -# CONFIG_HZ_100 is not set -CONFIG_HZ_250=y -CONFIG_HZ_PERIODIC=y -CONFIG_IMAGE_CMDLINE_HACK=y -CONFIG_INITRAMFS_SOURCE="" -CONFIG_IRQ_CPU=y -CONFIG_IRQ_FORCED_THREADING=y -CONFIG_IRQ_WORK=y -CONFIG_JBD2=y -CONFIG_KEXEC=y -CONFIG_KORINA=y -CONFIG_LEDS_MIKROTIK_RB532=y -CONFIG_MIKROTIK_RB532=y -CONFIG_MIPS=y -# CONFIG_MIPS_HUGE_TLB_SUPPORT is not set -CONFIG_MIPS_L1_CACHE_SHIFT=4 -# CONFIG_MIPS_MACHINE is not set -CONFIG_MIPS_MT_DISABLED=y -CONFIG_MODULES_USE_ELF_REL=y -CONFIG_MTD_BLOCK2MTD=y -CONFIG_MTD_CFI_ADV_OPTIONS=y -# CONFIG_MTD_CFI_AMDSTD is not set -CONFIG_MTD_CFI_GEOMETRY=y -# CONFIG_MTD_CFI_INTELEXT is not set -# CONFIG_MTD_COMPLEX_MAPPINGS is not set -CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_ECC=y -CONFIG_MTD_NAND_PLATFORM=y -CONFIG_MTD_PHYSMAP=y -# CONFIG_MTD_ROOTFS_ROOT_DEV is not set -CONFIG_MTD_ROOTFS_SPLIT=y -# CONFIG_MTD_SM_COMMON is not set -# CONFIG_MTD_SPLIT is not set -CONFIG_NEED_DMA_MAP_STATE=y -CONFIG_NEED_PER_CPU_KM=y -CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y -CONFIG_PAGEFLAGS_EXTENDED=y -CONFIG_PATA_RB532=y -CONFIG_PCI=y -CONFIG_PCI_DISABLE_COMMON_QUIRKS=y -CONFIG_PCI_DOMAINS=y -CONFIG_PERF_USE_VMALLOC=y -# CONFIG_PREEMPT_RCU is not set -CONFIG_RC32434_WDT=y -# CONFIG_RCU_STALL_COMMON is not set -CONFIG_SCSI=y -# CONFIG_SCSI_LOWLEVEL is not set -# CONFIG_SCSI_MULTI_LUN is not set -# CONFIG_SCSI_PROC_FS is not set -# CONFIG_SWAP is not set -CONFIG_SWAP_IO_SPACE=y -CONFIG_SYS_HAS_CPU_MIPS32_R1=y -CONFIG_SYS_SUPPORTS_32BI
Re: [OpenWrt-Devel] SVN to GIT transition
On 9 October 2015 at 21:22, Jo-Philipp Wich wrote: > Hi. > >> Moving to Git seemed to have lots of traction at the summit, and I'll >> add my voice that this sounds like a step in the right direction for >> OpenWrt. I'm assuming that we would want to do a proper SVN to Git >> conversion, and Eric's help on this would be great, I think. My >> discussion with Eric is over on Google+ and marked public: >> https://plus.google.com/+JonathanBennett87/posts/bMPMjn7ZcJS > > Why does the core system need to migrate from svn to git? > I thought everybody is using git anyway already. Are there people still using svn? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] kernel: add ath3k module package
On 10 October 2015 at 00:22, Pushpal Sidhu wrote: > Adds a package for the ath3k kernel module, present in 3.18/4.0/4.1 kernels > > Signed-off-by: Pushpal Sidhu > --- > package/kernel/linux/modules/other.mk | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/package/kernel/linux/modules/other.mk > b/package/kernel/linux/modules/other.mk > index d438fbe..8620bca 100644 > --- a/package/kernel/linux/modules/other.mk > +++ b/package/kernel/linux/modules/other.mk > @@ -78,6 +78,25 @@ endef > > $(eval $(call KernelPackage,bluetooth)) > > +define KernelPackage/ath3k > + SUBMENU:=$(OTHER_MENU) > + TITLE:=ATH3K Kernel Module support > + DEPENDS:=+kmod-bluetooth > + KCONFIG:= \ > + CONFIG_BT_ATH3K \ > + CONFIG_BT_HCIUART_ATH3K > + $(call AddDepends/bluetooth) > + FILES:= \ > + $(LINUX_DIR)/drivers/bluetooth/ath3k.ko > + AUTOLOAD:=$(call AutoProbe,ath3k) > +endef > + > +define KernelPackage/ath3k/description > + Kernel support for ATH3K Module > +endef > + > +$(eval $(call KernelPackage,ath3k)) > + IMO this should depend on ar3k-firmware because it will not work without that anyway Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 12 October 2015 at 10:36, Felix Fietkau wrote: > On 2015-10-12 08:38, Steven Barth wrote: >> Let's face it though: the current workflow wrt. core patches is crappy. >> >> 1. Go to patchwork, see if there is a patch >> 2. If you want to comment, switch to mail client, find thread, write reply. >> 3. If you want to commit: download patch, go to command line, see if it >> applies >> 4. Then manually go back to patchwork and adjust the status of the patch. >> 5. Upon merging go back to mail and write a mail ala "Patch Accepted". > Step 5 is unnecessary, patchwork sends emails on status changes. I think that workflow changes could introduce some pain but those can be left aside (t.i. kept as is for now) until people get used to git more and, maybe, develop some new/optimized workflow. One benefit what git would give, independently from which (main) workflow is used, is branching, which, IMO, is quite cumbersome right now. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 12 October 2015 at 12:04, Holger Levsen wrote: > Hi, > > (just a tiny datapoint...) > > On Montag, 12. Oktober 2015, Felix Fietkau wrote: >> Which part is cumbersome for you and how exactly would switching the >> main repo to git solve it? > > *g* > > that reminded me to check, and indeed, I only use > git://git.openwrt.org/openwrt.git anyway :) > Exactly. Cumbersome is having multiple repositories, which was probably a workaround to painful (as opposed to git) branching in svn. At least it looks like that. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 12 October 2015 at 16:34, Felix Fietkau wrote: > On 2015-10-12 15:09, Javier Domingo Cansino wrote: >> Right now, the revision number (r) is really useful to figure >> out what particular openwrt version is being used, when people report >> bugs. The commit hash cannot be used as a replacement, since it might be >> one that isn't present in the official repo. >> When using tags as a starting point (via git describe), somebody has to >> create those tags, which is cumbersome (and would mean adding lots of >> useless ones). >> >> The tags would be the major versions and RCs. I don't believe other tags >> should be used. >> >> Apart from that, I understand that if someone cloned the SVN repo (full >> svn history), created it's own server, and developed on top of a given >> revision X, the same problem would arise. > I haven't seen a single instance of somebody doing this, and in my > opinion it would be kind of stupid anyway :) > We don't even advertise the SVN server URL to users anymore for a reason. > IMO git describe --dirty would work perfectly. You would see a short hash and if user modified it or not. For users it would work even better than svn revision. For devs or users who do commit locally both svn and git "revisions" can be "spoofed" anyway so it just useless. oh.. sorry, I forgot that you cannot commit locally with svn... Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 12 October 2015 at 22:21, Jonathan Bennett wrote: > > > On Mon, Oct 12, 2015 at 2:11 PM David Lang wrote: >> >> On Mon, 12 Oct 2015, Felix Fietkau wrote: >> >> > On 2015-10-12 16:11, Roman Yeryomin wrote: >> >> On 12 October 2015 at 16:34, Felix Fietkau wrote: >> >>> On 2015-10-12 15:09, Javier Domingo Cansino wrote: >> >>>> Right now, the revision number (r) is really useful to >> >>>> figure >> >>>> out what particular openwrt version is being used, when people >> >>>> report >> >>>> bugs. The commit hash cannot be used as a replacement, since it >> >>>> might be >> >>>> one that isn't present in the official repo. >> >>>> When using tags as a starting point (via git describe), somebody >> >>>> has to >> >>>> create those tags, which is cumbersome (and would mean adding >> >>>> lots of >> >>>> useless ones). >> >>>> >> >>>> The tags would be the major versions and RCs. I don't believe other >> >>>> tags >> >>>> should be used. >> >>>> >> >>>> Apart from that, I understand that if someone cloned the SVN repo >> >>>> (full >> >>>> svn history), created it's own server, and developed on top of a >> >>>> given >> >>>> revision X, the same problem would arise. >> >>> I haven't seen a single instance of somebody doing this, and in my >> >>> opinion it would be kind of stupid anyway :) >> >>> We don't even advertise the SVN server URL to users anymore for a >> >>> reason. >> >>> >> >> >> >> IMO git describe --dirty would work perfectly. You would see a short >> >> hash and if user modified it or not. >> > If the user made a local commit, the short hash becomes useless. >> >> if the user does a SVN checkout and then modifies things, the r is >> also >> not valid (although it does give you an idea where things branched) >> >> David Lang > > His point is that users don't ever do an SVN checkout. Because the r number > is baked into the image, it's a really easy and obvious way for an end user > to report the revision in a bug report. I can see the advantage in this. > If we are to move to git, we would want some way to preserve this feature, > that is a super easy way for a user to report the revision. We could bake > the short hash into the image, but this would not be useful if any commits > were added locally, whereas the r number would still show some useful > information. > > Would it be possible to track the revision number in an automated way even > in a git repo? So store the r number, and automatically increment on > commits. Not sure if that's an option, but it seems like it might address > the problem. > If a user is smart enough to commit something locally then he knows what he is doing and is smart enough to report the changes he made. It's so simple. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 13 October 2015 at 00:18, Bruno Randolf wrote: > On 10/12/2015 03:22 PM, Felix Fietkau wrote: When using tags as a starting point (via git describe), somebody has to create those tags, which is cumbersome (and would mean adding lots of useless ones). >>> >>> What's cumbersome? And why would you have to create useless tags? >>> >> Many people follow current trunk, and we need to have precise version >> information for that when they report a bug. We don't want to regularly >> tag stuff just to keep reported version information up to date. > > You don't need to. Try this in your OpenWRT trunk git repo: > > git tag -a r 753606a51c979440e10771f0d11494b7b7c1eac2 > > (Tagging the very first commit with "r".) > > Now do: > > git describe > > r-35387-g83c5a41 > Bruno, +100500! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 13 October 2015 at 10:50, Bruno Randolf wrote: > On 10/12/2015 10:53 PM, Felix Fietkau wrote: >>> git describe >>> >>> r-35387-g83c5a41 >>> >>> If you prefer, cut the last part and get "r-35387". >>> >>> Looks familiar? Now you even have real linear numbering in each branch, >>> without the gaps you get when committing to different branches in SVN + >>> the unique hash. Need to look up the commit? Use the hash (g83c5a41). >>> >>> Of course "r" is just an example to show the familiarity with SVN >>> revisions, you could choose whatever seems fit, for example at this >>> moment it would make sense to tag the moment when 15.05 was branched off >>> from trunk as "dd", then you'd get "dd-number-hash" in trunk and >>> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to >>> use "git describe --tags" because the tag was not created with -a). >> >> That looks quite interesting. The issue I see with that is if somebody >> adds a local commit on top and builds the tree, the number behind 'r' is >> misleading and the hash is useless. > > Right, I see, the ambiguous numbering with local commits may be a weak > point. But then, if you don't find the hash in the OpenWRT git, you also > know that it's not a clean copy of trunk and that's also valuable > information. People should report bugs from clean trunk, not containing > random, unknown, additional commits. > and then, again, if a user is able to commit something usually that means he is able to understand that reporting his local changes doesn't make sense. Though, I still think that appropriate, meaningful tags will be a better option to just r (which would be just svn legacy). Not sure but probably both options could be used in parallel. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] proto 'none' overwriting tun interfaces
On 13 October 2015 at 03:16, wrote: > Hi all, > > I've been compiling OpenWRT builds for my home router (Netgear WNDR3800 and > now a WD MyNet N750) for a number of years. I just recently encountered a > problem with the OpenVPN tun interfaces are showing up without IP addresses > after a reboot. I have the following in my /etc/config/network: > > config interface 'vpn_udp' > option ifname 'tun0' > option proto 'none' > > config interface 'vpn_tcp' > option ifname 'tun1' > option proto 'none' > Why do you use proto=none? Isn't it supposed to be used to actually disable/deconfigure that interface? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 13 October 2015 at 23:08, David Lang wrote: > On Tue, 13 Oct 2015, Roman Yeryomin wrote: > >>> >>> Would it be possible to track the revision number in an automated way >>> even >>> in a git repo? So store the r number, and automatically increment on >>> commits. Not sure if that's an option, but it seems like it might >>> address >>> the problem. >>> >> >> If a user is smart enough to commit something locally then he knows >> what he is doing and is smart enough to report the changes he made. >> It's so simple. > > > I think the concern is that someone may do this and then make the resulting > images available to others to install. Someone can do this (change the revision) very easily now too (and this is good, because allows using internal revision numbers for custom fw builders), so there is no way you can protect from this (I would even say there is no point in protecting from this). Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 14 October 2015 at 00:20, David Lang wrote: > On Wed, 14 Oct 2015, Roman Yeryomin wrote: > >> On 13 October 2015 at 23:08, David Lang wrote: >>> >>> On Tue, 13 Oct 2015, Roman Yeryomin wrote: >>> >>>>> >>>>> Would it be possible to track the revision number in an automated way >>>>> even >>>>> in a git repo? So store the r number, and automatically increment on >>>>> commits. Not sure if that's an option, but it seems like it might >>>>> address >>>>> the problem. >>>>> >>>> >>>> If a user is smart enough to commit something locally then he knows >>>> what he is doing and is smart enough to report the changes he made. >>>> It's so simple. >>> >>> >>> >>> I think the concern is that someone may do this and then make the >>> resulting >>> images available to others to install. >> >> >> Someone can do this (change the revision) very easily now too (and >> this is good, because allows using internal revision numbers for >> custom fw builders), so there is no way you can protect from this (I >> would even say there is no point in protecting from this). > > > I think it's a good idea to encourage other builders to have a unique id in > there. That's why I was talking earlier about adding the initials of the > builder to the version string. > > Even if they are compiling the same code, there are enough different ways to > configure things that can cause problems that it's worth knowing if it's a > stock build or a custom one. You can put any initials (or other info) into your version number or other configurable identifiers, but, IMO, forcing this is a bad idea. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 14 October 2015 at 10:10, Felix Fietkau wrote: > On 2015-10-13 10:45, Roman Yeryomin wrote: >> On 13 October 2015 at 10:50, Bruno Randolf wrote: >>> On 10/12/2015 10:53 PM, Felix Fietkau wrote: >>>>> git describe >>>>> >>>>> r-35387-g83c5a41 >>>>> >>>>> If you prefer, cut the last part and get "r-35387". >>>>> >>>>> Looks familiar? Now you even have real linear numbering in each branch, >>>>> without the gaps you get when committing to different branches in SVN + >>>>> the unique hash. Need to look up the commit? Use the hash (g83c5a41). >>>>> >>>>> Of course "r" is just an example to show the familiarity with SVN >>>>> revisions, you could choose whatever seems fit, for example at this >>>>> moment it would make sense to tag the moment when 15.05 was branched off >>>>> from trunk as "dd", then you'd get "dd-number-hash" in trunk and >>>>> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to >>>>> use "git describe --tags" because the tag was not created with -a). >>>> >>>> That looks quite interesting. The issue I see with that is if somebody >>>> adds a local commit on top and builds the tree, the number behind 'r' is >>>> misleading and the hash is useless. >>> >>> Right, I see, the ambiguous numbering with local commits may be a weak >>> point. But then, if you don't find the hash in the OpenWRT git, you also >>> know that it's not a clean copy of trunk and that's also valuable >>> information. People should report bugs from clean trunk, not containing >>> random, unknown, additional commits. >>> >> >> and then, again, if a user is able to commit something usually that >> means he is able to understand that reporting his local changes >> doesn't make sense. > People report bugs all the time, and if I'm lucky enough to have a bug > report containing revision information, I want to maximize the > likelihood of that revision information being useful (even if there are > some local commits on top of that). > Any assumptions about users thinking carefully if the revision info that > they're posting is meaningful enough is flawed. People usually just post > whatever is in the banner file. > Often bug reports can be anonymous, or reporters just don't respond > after posting the ticket. I don't want to compromise any remaining > usefulness of such tickets. git describe origin is solving all your worries Then you can add his local commit hash if there are any and dirty flag to indicate if uncommited changes are present. Much better than svn revision in all ways. >> Though, I still think that appropriate, meaningful tags will be a >> better option to just r (which would be just svn legacy). >> Not sure but probably both options could be used in parallel. > A fake 'r' value is useless if I can't use it to look up the > corresponding OpenWrt commit. see above Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add 4.1 support
On 18 October 2015 at 00:16, Stijn Tintel wrote: > On 17-07-15 19:35, Roman Yeryomin wrote: >> Signed-off-by: Roman Yeryomin >> --- >> > Hi Roman, > > Since ar71xx uses 4.1 kernel by default, MAC addresses on my Ubiquiti > RSPro's are random. I suspect it is due to the changes in > 506-MIPS-ath79-prom-parse-redboot-args.patch. I reported the problem > here: https://dev.openwrt.org/ticket/20642. Do you mind having a look at it? Those changes didn't affect functionality, it was a port to new prom API. Also seems you have the board correctly detected - it means prom code is working. Are you sure the bootloader is passing ethaddr as it should? Sorry, I don't have the hw to test. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] kernel: add overlayfs stacking fix from upstream
Overlayfs stacking was broken in 4.1.12 but now fixed in upstream branch.
Stacking allows experimenting with configurations without the need to
reset a device to factory config.
Signed-off-by: Roman Yeryomin
---
.../patches-4.1/510-fs-overlay-fix-stacking.patch | 38 ++
1 file changed, 38 insertions(+)
create mode 100644
target/linux/generic/patches-4.1/510-fs-overlay-fix-stacking.patch
diff --git a/target/linux/generic/patches-4.1/510-fs-overlay-fix-stacking.patch
b/target/linux/generic/patches-4.1/510-fs-overlay-fix-stacking.patch
new file mode 100644
index 000..5db52d3
--- /dev/null
+++ b/target/linux/generic/patches-4.1/510-fs-overlay-fix-stacking.patch
@@ -0,0 +1,38 @@
+From 1c8a47df36d72ace8cf78eb6c228aa0f8027d3c2 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi
+Date: Mon, 12 Oct 2015 15:56:20 +0200
+Subject: ovl: fix open in stacked overlay
+
+If two overlayfs filesystems are stacked on top of each other, then we need
+recursion in ovl_d_select_inode().
+
+I guess d_backing_inode() is supposed to do that. But currently it doesn't
+and that functionality is open coded in vfs_open(). This is now copied
+into ovl_d_select_inode() to fix this regression.
+
+Reported-by: Alban Crequy
+Signed-off-by: Miklos Szeredi
+Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay...")
+Cc: David Howells
+Cc: # v4.2+
+---
+ fs/overlayfs/inode.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
+index d9da5a4..ec0c2a0 100644
+--- a/fs/overlayfs/inode.c
b/fs/overlayfs/inode.c
+@@ -363,6 +363,9 @@ struct inode *ovl_d_select_inode(struct dentry *dentry,
unsigned file_flags)
+ ovl_path_upper(dentry, &realpath);
+ }
+
++ if (realpath.dentry->d_flags & DCACHE_OP_SELECT_INODE)
++ return realpath.dentry->d_op->d_select_inode(realpath.dentry,
file_flags);
++
+ return d_backing_inode(realpath.dentry);
+ }
+
+--
+cgit v0.11.2
+
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] kernel: add overlayfs stacking fix from upstream
On 1 December 2015 at 00:42, Roman Yeryomin wrote: > Overlayfs stacking was broken in 4.1.12 but now fixed in upstream branch. > Stacking allows experimenting with configurations without the need to > reset a device to factory config. > Hauke, you commited kernel upgrade but without this patch 4.1 overlayfs stacking is broken. I understand is not a very common usecase but do you mind commiting this patch also? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] firmware-utils: allow mkfwimage2 to use - in partition names
Signed-off-by: Roman Yeryomin --- tools/firmware-utils/src/mkfwimage2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/firmware-utils/src/mkfwimage2.c b/tools/firmware-utils/src/mkfwimage2.c index 993c3d4..146b2ad 100644 --- a/tools/firmware-utils/src/mkfwimage2.c +++ b/tools/firmware-utils/src/mkfwimage2.c @@ -212,7 +212,7 @@ static int image_layout_add_partition(const char *part_desc) } d = &im.parts[im.part_count]; - t = sscanf(part_desc, "%15[0-9a-zA-Z]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%256s", + t = sscanf(part_desc, "%15[-0-9a-zA-Z]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%256s", d->partition_name, offset, length, -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] fstools: allow to stack another overlay on top of existing one
`mount_root ram' will pivot existing root to ram even if it was
overlayfs already. Useful when playing with new configurations
as it allows to preserve existing/stable configuration.
Signed-off-by: Roman Yeryomin
---
mount_root.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mount_root.c b/mount_root.c
index 7b69c7f..bf70265 100644
--- a/mount_root.c
+++ b/mount_root.c
@@ -117,6 +117,8 @@ int main(int argc, char **argv)
{
if (argc < 2)
return start(argc, argv);
+ if (!strcmp(argv[1], "ram"))
+ return ramoverlay();
if (!strcmp(argv[1], "stop"))
return stop(argc, argv);
if (!strcmp(argv[1], "done"))
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: allow timezone to be overriden by zonename (proper zoneinfo support)
Signed-off-by: Roman Yeryomin
---
package/base-files/Makefile| 4 ++--
package/base-files/files/etc/init.d/system | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 1367fa9..bf32f63 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
include $(INCLUDE_DIR)/version.mk
PKG_NAME:=base-files
-PKG_RELEASE:=164
+PKG_RELEASE:=165
PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
PKG_BUILD_DEPENDS:=usign/host
@@ -161,7 +161,7 @@ define Package/base-files/install
rm -f $(1)/var
$(LN) /tmp $(1)/var
mkdir -p $(1)/etc
- $(LN) /tmp/resolv.conf /tmp/fstab /tmp/TZ $(1)/etc/
+ $(LN) /tmp/resolv.conf /tmp/fstab /tmp/TZ /tmp/localtime $(1)/etc/
chmod 0600 $(1)/etc/shadow
chmod 1777 $(1)/tmp
diff --git a/package/base-files/files/etc/init.d/system
b/package/base-files/files/etc/init.d/system
index 6388d62..531aa8c 100755
--- a/package/base-files/files/etc/init.d/system
+++ b/package/base-files/files/etc/init.d/system
@@ -27,7 +27,8 @@ system_config() {
echo "$hostname" > /proc/sys/kernel/hostname
[ -z "$conloglevel" -a -z "$buffersize" ] || dmesg ${conloglevel:+-n
$conloglevel} ${buffersize:+-s $buffersize}
echo "$timezone" > /tmp/TZ
- [ -n "$zonename" ] && [ -f "/usr/share/zoneinfo/$zonename" ] && ln -s
"/usr/share/zoneinfo/$zonename" /tmp/localtime
+ [ -n "$zonename" ] && [ -f "/usr/share/zoneinfo/$zonename" ] && \
+ ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm -f
/tmp/TZ
# apply timezone to kernel
date -k
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] kernel: move at803x phy patch to generic
Signed-off-by: Roman Yeryomin
---
...t-phy-at803x-allow-to-configure-via-pdata.patch | 180 -
...t-phy-at803x-allow-to-configure-via-pdata.patch | 180 +
...t-phy-at803x-allow-to-configure-via-pdata.patch | 180 +
...t-phy-at803x-allow-to-configure-via-pdata.patch | 180 +
...t-phy-at803x-allow-to-configure-via-pdata.patch | 180 +
5 files changed, 720 insertions(+), 180 deletions(-)
delete mode 100644
target/linux/ar71xx/patches-4.1/425-net-phy-at803x-allow-to-configure-via-pdata.patch
create mode 100644
target/linux/generic/patches-3.18/734-net-phy-at803x-allow-to-configure-via-pdata.patch
create mode 100644
target/linux/generic/patches-4.1/734-net-phy-at803x-allow-to-configure-via-pdata.patch
create mode 100644
target/linux/generic/patches-4.3/734-net-phy-at803x-allow-to-configure-via-pdata.patch
create mode 100644
target/linux/generic/patches-4.4/734-net-phy-at803x-allow-to-configure-via-pdata.patch
diff --git
a/target/linux/ar71xx/patches-4.1/425-net-phy-at803x-allow-to-configure-via-pdata.patch
b/target/linux/ar71xx/patches-4.1/425-net-phy-at803x-allow-to-configure-via-pdata.patch
deleted file mode 100644
index 53abcc3..000
---
a/target/linux/ar71xx/patches-4.1/425-net-phy-at803x-allow-to-configure-via-pdata.patch
+++ /dev/null
@@ -1,180 +0,0 @@
a/drivers/net/phy/at803x.c
-+++ b/drivers/net/phy/at803x.c
-@@ -12,12 +12,14 @@
- */
-
- #include
-+#include
- #include
- #include
- #include
- #include
- #include
- #include
-+#include
-
- #define AT803X_INTR_ENABLE0x12
- #define AT803X_INTR_STATUS0x13
-@@ -34,8 +36,16 @@
- #define AT803X_INER 0x0012
- #define AT803X_INER_INIT 0xec00
- #define AT803X_INSR 0x0013
-+
-+#define AT803X_PCS_SMART_EEE_CTRL30x805D
-+#define AT803X_SMART_EEE_CTRL3_LPI_TX_DELAY_SEL_MASK 0x3
-+#define AT803X_SMART_EEE_CTRL3_LPI_TX_DELAY_SEL_SHIFT 12
-+#define AT803X_SMART_EEE_CTRL3_LPI_EN BIT(8)
-+
- #define AT803X_DEBUG_ADDR 0x1D
- #define AT803X_DEBUG_DATA 0x1E
-+#define AT803X_DBG0_REG 0x00
-+#define AT803X_DEBUG_RGMII_RX_CLK_DLY BIT(8)
- #define AT803X_DEBUG_SYSTEM_MODE_CTRL 0x05
- #define AT803X_DEBUG_RGMII_TX_CLK_DLY BIT(8)
-
-@@ -50,6 +60,7 @@ MODULE_LICENSE("GPL");
- struct at803x_priv {
- bool phy_reset:1;
- struct gpio_desc *gpiod_reset;
-+ int prev_speed;
- };
-
- struct at803x_context {
-@@ -61,6 +72,43 @@ struct at803x_context {
- u16 led_control;
- };
-
-+static u16
-+at803x_dbg_reg_rmw(struct phy_device *phydev, u16 reg, u16 clear, u16 set)
-+{
-+ struct mii_bus *bus = phydev->bus;
-+ int val;
-+
-+ mutex_lock(&bus->mdio_lock);
-+
-+ bus->write(bus, phydev->addr, AT803X_DEBUG_ADDR, reg);
-+ val = bus->read(bus, phydev->addr, AT803X_DEBUG_DATA);
-+ if (val < 0) {
-+ val = 0x;
-+ goto out;
-+ }
-+
-+ val &= ~clear;
-+ val |= set;
-+ bus->write(bus, phydev->addr, AT803X_DEBUG_DATA, val);
-+
-+out:
-+ mutex_unlock(&bus->mdio_lock);
-+ return val;
-+}
-+
-+static inline void
-+at803x_dbg_reg_set(struct phy_device *phydev, u16 reg, u16 set)
-+{
-+ at803x_dbg_reg_rmw(phydev, reg, 0, set);
-+}
-+
-+static inline void
-+at803x_dbg_reg_clr(struct phy_device *phydev, u16 reg, u16 clear)
-+{
-+ at803x_dbg_reg_rmw(phydev, reg, clear, 0);
-+}
-+
-+
- /* save relevant PHY registers to private copy */
- static void at803x_context_save(struct phy_device *phydev,
- struct at803x_context *context)
-@@ -209,8 +257,16 @@ static int at803x_probe(struct phy_devic
- return 0;
- }
-
-+static void at803x_disable_smarteee(struct phy_device *phydev)
-+{
-+ phy_write_mmd(phydev, MDIO_MMD_PCS, AT803X_PCS_SMART_EEE_CTRL3,
-+ 1 << AT803X_SMART_EEE_CTRL3_LPI_TX_DELAY_SEL_SHIFT);
-+ phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
-+}
-+
- static int at803x_config_init(struct phy_device *phydev)
- {
-+ struct at803x_platform_data *pdata;
- int ret;
-
- ret = genphy_config_init(phydev);
-@@ -228,6 +284,26 @@ static int at803x_config_init(struct phy
- return ret;
- }
-
-+ pdata = dev_get_platdata(&phydev->dev);
-+ if (pdata) {
-+ if (pdata->disable_smarteee)
-+ at803x_disable_smarteee(phydev);
-+
-+ if (pdata->enable_rgmii_rx_delay)
-+ at803x_dbg_reg_set(phydev, AT803X_DBG0_REG,
-+ AT803X_DEBUG_RGMII_RX_CLK_DLY);
-+ else
-+ at803x_dbg_reg_clr(phydev, AT803X_DBG0_REG,
-+
[OpenWrt-Devel] [PATCH 2/2] kernel: add at803x fix for sgmii mode
Some (possibly broken) bootloaders incorreclty initialize at8033
phy. This patch enables sgmii autonegotiation mode.
Signed-off-by: Roman Yeryomin
---
.../735-net-phy-at803x-fix-at8033-sgmii-mode.patch | 96 ++
.../735-net-phy-at803x-fix-at8033-sgmii-mode.patch | 96 ++
.../735-net-phy-at803x-fix-at8033-sgmii-mode.patch | 96 ++
.../735-net-phy-at803x-fix-at8033-sgmii-mode.patch | 96 ++
4 files changed, 384 insertions(+)
create mode 100644
target/linux/generic/patches-3.18/735-net-phy-at803x-fix-at8033-sgmii-mode.patch
create mode 100644
target/linux/generic/patches-4.1/735-net-phy-at803x-fix-at8033-sgmii-mode.patch
create mode 100644
target/linux/generic/patches-4.3/735-net-phy-at803x-fix-at8033-sgmii-mode.patch
create mode 100644
target/linux/generic/patches-4.4/735-net-phy-at803x-fix-at8033-sgmii-mode.patch
diff --git
a/target/linux/generic/patches-3.18/735-net-phy-at803x-fix-at8033-sgmii-mode.patch
b/target/linux/generic/patches-3.18/735-net-phy-at803x-fix-at8033-sgmii-mode.patch
new file mode 100644
index 000..117f15d
--- /dev/null
+++
b/target/linux/generic/patches-3.18/735-net-phy-at803x-fix-at8033-sgmii-mode.patch
@@ -0,0 +1,96 @@
+--- a/drivers/net/phy/at803x.c
b/drivers/net/phy/at803x.c
+@@ -36,6 +36,9 @@
+ #define AT803X_INER 0x0012
+ #define AT803X_INER_INIT 0xec00
+ #define AT803X_INSR 0x0013
++#define AT803X_REG_CHIP_CONFIG0x1f
++#define AT803X_BT_BX_REG_SEL 0x8000
++#define AT803X_SGMII_ANEG_EN 0x1000
+
+ #define AT803X_PCS_SMART_EEE_CTRL30x805D
+ #define AT803X_SMART_EEE_CTRL3_LPI_TX_DELAY_SEL_MASK 0x3
+@@ -49,9 +52,10 @@
+ #define AT803X_DEBUG_SYSTEM_MODE_CTRL 0x05
+ #define AT803X_DEBUG_RGMII_TX_CLK_DLY BIT(8)
+
+-#define ATH8030_PHY_ID 0x004dd076
+-#define ATH8031_PHY_ID 0x004dd074
+-#define ATH8035_PHY_ID 0x004dd072
++#define AT803X_PHY_ID_MASK0xffef
++#define ATH8030_PHY_ID0x004dd076
++#define ATH8031_PHY_ID0x004dd074
++#define ATH8035_PHY_ID0x004dd072
+
+ MODULE_DESCRIPTION("Atheros 803x PHY driver");
+ MODULE_AUTHOR("Matus Ujhelyi");
+@@ -268,6 +272,27 @@ static int at803x_config_init(struct phy
+ {
+ struct at803x_platform_data *pdata;
+ int ret;
++ u32 v;
++
++ if (phydev->drv->phy_id == ATH8031_PHY_ID &&
++ phydev->interface == PHY_INTERFACE_MODE_SGMII)
++ {
++ v = phy_read(phydev, AT803X_REG_CHIP_CONFIG);
++ /* select SGMII/fiber page */
++ ret = phy_write(phydev, AT803X_REG_CHIP_CONFIG,
++ v & ~AT803X_BT_BX_REG_SEL);
++ if (ret)
++ return ret;
++ /* enable SGMII autonegotiation */
++ ret = phy_write(phydev, MII_BMCR, AT803X_SGMII_ANEG_EN);
++ if (ret)
++ return ret;
++ /* select copper page */
++ ret = phy_write(phydev, AT803X_REG_CHIP_CONFIG,
++ v | AT803X_BT_BX_REG_SEL);
++ if (ret)
++ return ret;
++ }
+
+ ret = genphy_config_init(phydev);
+ if (ret < 0)
+@@ -394,7 +419,7 @@ static struct phy_driver at803x_driver[]
+ /* ATHEROS 8035 */
+ .phy_id = ATH8035_PHY_ID,
+ .name = "Atheros 8035 ethernet",
+- .phy_id_mask= 0xffef,
++ .phy_id_mask= AT803X_PHY_ID_MASK,
+ .probe = at803x_probe,
+ .config_init= at803x_config_init,
+ .link_change_notify = at803x_link_change_notify,
+@@ -413,7 +438,7 @@ static struct phy_driver at803x_driver[]
+ /* ATHEROS 8030 */
+ .phy_id = ATH8030_PHY_ID,
+ .name = "Atheros 8030 ethernet",
+- .phy_id_mask= 0xffef,
++ .phy_id_mask= AT803X_PHY_ID_MASK,
+ .probe = at803x_probe,
+ .config_init= at803x_config_init,
+ .link_change_notify = at803x_link_change_notify,
+@@ -431,8 +456,8 @@ static struct phy_driver at803x_driver[]
+ }, {
+ /* ATHEROS 8031 */
+ .phy_id = ATH8031_PHY_ID,
+- .name = "Atheros 8031 ethernet",
+- .phy_id_mask= 0xffef,
++ .name = "Atheros 8031/8033 ethernet",
++ .phy_id_mask= AT803X_PHY_ID_MASK,
+ .probe = at803x_probe,
+ .config_init= at803x_config_init,
+ .link_change_notify = at
[OpenWrt-Devel] [PATCH 1/3] ar71xx: update QCA956x support
- separate qca956x and tp9343 (they use different IDs)
- rename qca9561->qca956x for consistency
- add missing bits (device reset, gpio output select)
- fix wmac setup
Signed-off-by: Roman Yeryomin
---
...21-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 131 ++---
...79-add-gpio-func-register-for-QCA955x-SoC.patch | 7 +-
2 files changed, 92 insertions(+), 46 deletions(-)
diff --git
a/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
b/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
index ca92d0e..888a7b6 100644
---
a/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
+++
b/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
@@ -129,7 +129,7 @@
qca953x_clocks_init();
else if (soc_is_qca955x())
qca955x_clocks_init();
-+ else if (soc_is_qca956x())
++ else if (soc_is_qca956x() || soc_is_tp9343())
+ qca956x_clocks_init();
else
BUG();
@@ -140,7 +140,7 @@
reg = QCA953X_RESET_REG_RESET_MODULE;
else if (soc_is_qca955x())
reg = QCA955X_RESET_REG_RESET_MODULE;
-+ else if (soc_is_qca956x())
++ else if (soc_is_qca956x() || soc_is_tp9343())
+ reg = QCA956X_RESET_REG_RESET_MODULE;
else
panic("Reset register not defined for this SOC");
@@ -149,20 +149,30 @@
reg = QCA953X_RESET_REG_RESET_MODULE;
else if (soc_is_qca955x())
reg = QCA955X_RESET_REG_RESET_MODULE;
-+ else if (soc_is_qca956x())
++ else if (soc_is_qca956x() || soc_is_tp9343())
+ reg = QCA956X_RESET_REG_RESET_MODULE;
else
panic("Reset register not defined for this SOC");
+@@ -133,6 +137,8 @@ u32 ath79_device_reset_get(u32 mask)
+ reg = AR933X_RESET_REG_RESET_MODULE;
+ else if (soc_is_ar934x())
+ reg = AR934X_RESET_REG_RESET_MODULE;
++ else if (soc_is_qca956x() || soc_is_tp9343())
++ reg = QCA956X_RESET_REG_RESET_MODULE;
+ else
+ BUG();
+
--- a/arch/mips/ath79/dev-common.c
+++ b/arch/mips/ath79/dev-common.c
-@@ -94,7 +94,8 @@ void __init ath79_register_uart(void)
+@@ -94,7 +94,9 @@ void __init ath79_register_uart(void)
soc_is_ar913x() ||
soc_is_ar934x() ||
soc_is_qca953x() ||
- soc_is_qca955x()) {
+ soc_is_qca955x() ||
-+ soc_is_qca956x()) {
++ soc_is_qca956x() ||
++ soc_is_tp9343()) {
ath79_uart_data[0].uartclk = uart_clk_rate;
platform_device_register(&ath79_uart_device);
} else if (soc_is_ar933x()) {
@@ -192,14 +202,14 @@
qca953x_usb_setup();
else if (soc_is_qca955x())
qca955x_usb_setup();
-+ else if (soc_is_qca9561())
++ else if (soc_is_qca956x())
+ qca956x_usb_setup();
else
BUG();
}
--- a/arch/mips/ath79/dev-wmac.c
+++ b/arch/mips/ath79/dev-wmac.c
-@@ -189,6 +189,24 @@ static void qca955x_wmac_setup(void)
+@@ -189,6 +189,26 @@ static void qca955x_wmac_setup(void)
ath79_wmac_data.is_clk_25mhz = true;
}
@@ -219,6 +229,8 @@
+ ath79_wmac_data.is_clk_25mhz = false;
+ else
+ ath79_wmac_data.is_clk_25mhz = true;
++
++ ath79_wmac_data.get_mac_revision = ar93xx_get_soc_revision;
+}
+
static bool __init
@@ -228,7 +240,7 @@
qca953x_wmac_setup();
else if (soc_is_qca955x())
qca955x_wmac_setup();
-+ else if (soc_is_qca956x())
++ else if (soc_is_qca956x() || soc_is_tp9343())
+ qca956x_wmac_setup();
else
BUG();
@@ -240,27 +252,38 @@
case REV_ID_MAJOR_QCA9556:
case REV_ID_MAJOR_QCA9558:
+ case REV_ID_MAJOR_TP9343:
-+ case REV_ID_MAJOR_QCA9561:
++ case REV_ID_MAJOR_QCA956X:
_prom_putchar = prom_putchar_ar71xx;
break;
--- a/arch/mips/ath79/gpio.c
+++ b/arch/mips/ath79/gpio.c
-@@ -148,7 +148,8 @@ static void __iomem *ath79_gpio_get_func
+@@ -148,7 +148,10 @@ static void __iomem *ath79_gpio_get_func
soc_is_ar913x() ||
soc_is_ar933x())
reg = AR71XX_GPIO_REG_FUNC;
- else if (soc_is_ar934x() || soc_is_qca953x())
+ else if (soc_is_ar934x() ||
-+ soc_is_qca953x() || soc_is_qca956x())
++ soc_is_qca953x() ||
++ soc_is_qca956x() ||
++ soc_is_tp9343())
reg = AR934X_GPIO_REG_FUNC;
else
BUG();
-@@ -228,12 +229,15 @@ void __init ath79_gpio_init(void)
+@@ -187,7 +190,7 @@ void __init ath79_gpio_output_select(uns
+ unsigned int reg;
+ u32 t, s;
+
+- BUG_ON(!soc_is_ar934x() &&
[OpenWrt-Devel] [PATCH 2/3] ar71xx: add support for QCA956x ethernet
Signed-off-by: Roman Yeryomin
---
...PS-ath79-add-support-for-QCA956x-ethernet.patch | 166 +
1 file changed, 166 insertions(+)
create mode 100644
target/linux/ar71xx/patches-4.1/622-MIPS-ath79-add-support-for-QCA956x-ethernet.patch
diff --git
a/target/linux/ar71xx/patches-4.1/622-MIPS-ath79-add-support-for-QCA956x-ethernet.patch
b/target/linux/ar71xx/patches-4.1/622-MIPS-ath79-add-support-for-QCA956x-ethernet.patch
new file mode 100644
index 000..6a6a2e4
--- /dev/null
+++
b/target/linux/ar71xx/patches-4.1/622-MIPS-ath79-add-support-for-QCA956x-ethernet.patch
@@ -0,0 +1,166 @@
+--- a/arch/mips/ath79/dev-eth.c
b/arch/mips/ath79/dev-eth.c
+@@ -198,7 +198,6 @@ void __init ath79_register_mdio(unsigned
+ case ATH79_SOC_AR9330:
+ case ATH79_SOC_AR9331:
+ case ATH79_SOC_QCA9533:
+- case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
+ mdio_dev = &ath79_mdio1_device;
+ mdio_data = &ath79_mdio1_data;
+@@ -209,6 +208,7 @@ void __init ath79_register_mdio(unsigned
+ case ATH79_SOC_AR9344:
+ case ATH79_SOC_QCA9556:
+ case ATH79_SOC_QCA9558:
++ case ATH79_SOC_QCA956X:
+ if (id == 0) {
+ mdio_dev = &ath79_mdio0_device;
+ mdio_data = &ath79_mdio0_data;
+@@ -258,7 +258,6 @@ void __init ath79_register_mdio(unsigned
+ break;
+
+ case ATH79_SOC_QCA9533:
+- case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
+ mdio_data->builtin_switch = 1;
+ break;
+@@ -268,6 +267,11 @@ void __init ath79_register_mdio(unsigned
+ mdio_data->is_ar934x = 1;
+ break;
+
++ case ATH79_SOC_QCA956X:
++ if (id == 1)
++ mdio_data->builtin_switch = 1;
++ break;
++
+ default:
+ break;
+ }
+@@ -387,6 +391,16 @@ static void qca955x_set_speed_sgmii(int
+ iounmap(base);
+ }
+
++static void qca956x_set_speed_sgmii(int speed)
++{
++ void __iomem *base;
++ u32 val = ath79_get_eth_pll(0, speed);
++
++ base = ioremap_nocache(AR71XX_PLL_BASE, AR71XX_PLL_SIZE);
++ __raw_writel(val, base + QCA955X_PLL_ETH_SGMII_CONTROL_REG);
++ iounmap(base);
++}
++
+ static void ath79_set_speed_dummy(int speed)
+ {
+ }
+@@ -517,6 +531,10 @@ struct ag71xx_switch_platform_data ath79
+ #define AR934X_PLL_VAL_1000x0101
+ #define AR934X_PLL_VAL_10 0x1616
+
++#define QCA956X_PLL_VAL_1000 0x0300
++#define QCA956X_PLL_VAL_100 0x0101
++#define QCA956X_PLL_VAL_100x1919
++
+ static void __init ath79_init_eth_pll_data(unsigned int id)
+ {
+ struct ath79_eth_pll_data *pll_data;
+@@ -575,13 +593,18 @@ static void __init ath79_init_eth_pll_da
+ case ATH79_SOC_QCA9533:
+ case ATH79_SOC_QCA9556:
+ case ATH79_SOC_QCA9558:
+- case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
+ pll_10 = AR934X_PLL_VAL_10;
+ pll_100 = AR934X_PLL_VAL_100;
+ pll_1000 = AR934X_PLL_VAL_1000;
+ break;
+
++ case ATH79_SOC_QCA956X:
++ pll_10 = QCA956X_PLL_VAL_10;
++ pll_100 = QCA956X_PLL_VAL_100;
++ pll_1000 = QCA956X_PLL_VAL_1000;
++ break;
++
+ default:
+ BUG();
+ }
+@@ -656,6 +679,7 @@ static int __init ath79_setup_phy_if_mod
+
+ case ATH79_SOC_QCA9556:
+ case ATH79_SOC_QCA9558:
++ case ATH79_SOC_QCA956X:
+ switch (pdata->phy_if_mode) {
+ case PHY_INTERFACE_MODE_MII:
+ case PHY_INTERFACE_MODE_RGMII:
+@@ -666,11 +690,6 @@ static int __init ath79_setup_phy_if_mod
+ }
+ break;
+
+- case ATH79_SOC_QCA9561:
+- if (!pdata->phy_if_mode)
+- pdata->phy_if_mode = PHY_INTERFACE_MODE_MII;
+- break;
+-
+ default:
+ BUG();
+ }
+@@ -699,7 +718,7 @@ static int __init ath79_setup_phy_if_mod
+ case ATH79_SOC_AR7241:
+ case ATH79_SOC_AR9330:
+ case ATH79_SOC_AR9331:
+- case ATH79_SOC_QCA9561:
++ case ATH79_SOC_QCA956X:
+ case ATH79_SOC_TP9343:
+ pdata->phy_if_mode = PHY_INTERFACE_MODE_GMII;
+ break;
+@@ -1032,7 +1051,6 @@ void __init ath79_register_eth(unsigned
+ pdata->fifo_cfg3 = 0x01f00140;
+ break;
+
+- case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
+ if (id == 0) {
+ pdata->reset_bit = AR933X_RESET_GE0_MAC |
+@@ -1100,6 +1118,34 @@ void __init ath79_register_eth(unsigned
+ pdata->fifo_cfg3 = 0x01
