from:"David Bauer"

[PATCH 2/3] hostapd: ubus: add VHT capabilities to client list

2020-11-04 Thread David Bauer

This adds parsed VHT capability information to the hostapd
get_clients method.

Signed-off-by: David Bauer 
---
 .../services/hostapd/src/src/ap/ubus.c| 71 +++
 1 file changed, 71 insertions(+)

diff --git a/package/network/services/hostapd/src/src/ap/ubus.c 
b/package/network/services/hostapd/src/src/ap/ubus.c
index 3bad4d2e0f..3e5598b3cd 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.c
+++ b/package/network/services/hostapd/src/src/ap/ubus.c
@@ -209,6 +209,75 @@ hostapd_bss_reload(struct ubus_context *ctx, struct 
ubus_object *obj,
return ret;
 }
 
+
+static void
+hostapd_parse_vht_map_blobmsg(uint16_t map)
+{
+   char label[4];
+   int16_t val;
+   int i;
+
+   for (i = 0; i < 8; i++) {
+   snprintf(label, 4, "%dss", i + 1);
+
+   val = (map & (BIT(1) | BIT(0))) + 7;
+   blobmsg_add_u16(&b, label, val == 10 ? -1 : val);
+   map = map >> 2;
+   }
+}
+
+static void
+hostapd_parse_vht_capab_blobmsg(struct ieee80211_vht_capabilities *vhtc)
+{
+   void *supported_mcs;
+   void *map;
+   int i;
+
+   static const struct {
+   const char *name;
+   uint32_t flag;
+   } vht_capas[] = {
+   { "su_beamformee", VHT_CAP_SU_BEAMFORMEE_CAPABLE },
+   { "mu_beamformee", VHT_CAP_MU_BEAMFORMEE_CAPABLE },
+   };
+
+   for (i = 0; i < ARRAY_SIZE(vht_capas); i++)
+   blobmsg_add_u8(&b, vht_capas[i].name,
+   !!(vhtc->vht_capabilities_info & 
vht_capas[i].flag));
+
+   supported_mcs = blobmsg_open_table(&b, "mcs_map");
+
+   /* RX map */
+   map = blobmsg_open_table(&b, "rx");
+   
hostapd_parse_vht_map_blobmsg(le_to_host16(vhtc->vht_supported_mcs_set.rx_map));
+   blobmsg_close_table(&b, map);
+
+   /* TX map */
+   map = blobmsg_open_table(&b, "tx");
+   
hostapd_parse_vht_map_blobmsg(le_to_host16(vhtc->vht_supported_mcs_set.tx_map));
+   blobmsg_close_table(&b, map);
+
+   blobmsg_close_table(&b, supported_mcs);
+}
+
+static void
+hostapd_parse_capab_blobmsg(struct sta_info *sta)
+{
+   void *r, *v;
+
+   v = blobmsg_open_table(&b, "capabilities");
+
+   if (sta->vht_capabilities) {
+   r = blobmsg_open_table(&b, "vht");
+   hostapd_parse_vht_capab_blobmsg(sta->vht_capabilities);
+   blobmsg_close_table(&b, r);
+   }
+
+   /* ToDo: Add HT / HE capability parsing */
+
+   blobmsg_close_table(&b, v);
+}
+
 static int
 hostapd_bss_get_clients(struct ubus_context *ctx, struct ubus_object *obj,
struct ubus_request_data *req, const char *method,
@@ -281,6 +350,8 @@ hostapd_bss_get_clients(struct ubus_context *ctx, struct 
ubus_object *obj,
blobmsg_add_u32(&b, "signal", sta_driver_data.signal);
}
 
+   hostapd_parse_capab_blobmsg(sta);
+
blobmsg_close_table(&b, c);
}
blobmsg_close_array(&b, list);
-- 
2.29.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/3] hostapd: ubus: add driver information to client list

2020-11-04 Thread David Bauer

This adds information from mac80211 to hostapd get_client ubus function.
This way, TX as well as RX status information as well as the signal can
be determined.

Signed-off-by: David Bauer 
---
 .../services/hostapd/src/src/ap/ubus.c| 24 +++
 1 file changed, 24 insertions(+)

diff --git a/package/network/services/hostapd/src/src/ap/ubus.c 
b/package/network/services/hostapd/src/src/ap/ubus.c
index 33b9995e06..3bad4d2e0f 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.c
+++ b/package/network/services/hostapd/src/src/ap/ubus.c
@@ -215,6 +215,7 @@ hostapd_bss_get_clients(struct ubus_context *ctx, struct 
ubus_object *obj,
struct blob_attr *msg)
 {
struct hostapd_data *hapd = container_of(obj, struct hostapd_data, 
ubus.obj);
+   struct hostap_sta_driver_data sta_driver_data;
struct sta_info *sta;
void *list, *c;
char mac_buf[20];
@@ -257,6 +258,29 @@ hostapd_bss_get_clients(struct ubus_context *ctx, struct 
ubus_object *obj,
if (retrieve_sta_taxonomy(hapd, sta, r, 1024) > 0)
blobmsg_add_string_buffer(&b);
 #endif
+
+   /* Driver information */
+   if (hostapd_drv_read_sta_data(hapd, &sta_driver_data, 
sta->addr) >= 0) {
+   r = blobmsg_open_table(&b, "bytes");
+   blobmsg_add_u64(&b, "rx", sta_driver_data.rx_bytes);
+   blobmsg_add_u64(&b, "tx", sta_driver_data.tx_bytes);
+   blobmsg_close_table(&b, r);
+   r = blobmsg_open_table(&b, "airtime");
+   blobmsg_add_u64(&b, "rx", sta_driver_data.rx_airtime);
+   blobmsg_add_u64(&b, "tx", sta_driver_data.tx_airtime);
+   blobmsg_close_table(&b, r);
+   r = blobmsg_open_table(&b, "packets");
+   blobmsg_add_u32(&b, "rx", sta_driver_data.rx_packets);
+   blobmsg_add_u32(&b, "tx", sta_driver_data.tx_packets);
+   blobmsg_close_table(&b, r);
+   r = blobmsg_open_table(&b, "rate");
+   /* Rate in kbits */
+   blobmsg_add_u32(&b, "rx", 
sta_driver_data.current_rx_rate * 100);
+   blobmsg_add_u32(&b, "tx", 
sta_driver_data.current_tx_rate * 100);
+   blobmsg_close_table(&b, r);
+   blobmsg_add_u32(&b, "signal", sta_driver_data.signal);
+   }
+
blobmsg_close_table(&b, c);
}
blobmsg_close_array(&b, list);
-- 
2.29.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 3/3] hostapd: ubus: add get_status method

2020-11-04 Thread David Bauer

This adds a new get_status method to a hostapd interface, which
provides information about the current interface status.

Signed-off-by: David Bauer 
---
 .../services/hostapd/src/src/ap/ubus.c| 40 +++
 1 file changed, 40 insertions(+)

diff --git a/package/network/services/hostapd/src/src/ap/ubus.c 
b/package/network/services/hostapd/src/src/ap/ubus.c
index 3e5598b3cd..92fe06bb44 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.c
+++ b/package/network/services/hostapd/src/src/ap/ubus.c
@@ -375,6 +375,45 @@ hostapd_bss_get_features(struct ubus_context *ctx, struct 
ubus_object *obj,
return 0;
 }
 
+static int
+hostapd_bss_get_status(struct ubus_context *ctx, struct ubus_object *obj,
+  struct ubus_request_data *req, const char *method,
+  struct blob_attr *msg)
+{
+   struct hostapd_data *hapd = container_of(obj, struct hostapd_data, 
ubus.obj);
+   void *airtime_table, *dfs_table;
+   struct os_reltime now;
+   char phy_name[17];
+   char mac_buf[20];
+
+   blob_buf_init(&b, 0);
+   blobmsg_add_string(&b, "status", 
hostapd_state_text(hapd->iface->state));
+   blobmsg_add_u32(&b, "freq", hapd->iface->freq);
+
+   snprintf(phy_name, 17, "%s", hapd->iface->phy);
+   blobmsg_add_string(&b, "phy", phy_name);
+
+   /* Airtime */
+   airtime_table = blobmsg_open_table(&b, "airtime");
+   blobmsg_add_u64(&b, "time", hapd->iface->last_channel_time);
+   blobmsg_add_u64(&b, "time_busy", hapd->iface->last_channel_time_busy);
+   blobmsg_add_u16(&b, "utilization", hapd->iface->channel_utilization);
+   blobmsg_close_table(&b, airtime_table);
+
+   /* DFS */
+   dfs_table = blobmsg_open_table(&b, "dfs");
+   blobmsg_add_u32(&b, "cac_seconds", hapd->iface->dfs_cac_ms / 1000);
+   blobmsg_add_u8(&b, "cac_active", !!(hapd->iface->cac_started));
+   os_reltime_age(&hapd->iface->dfs_cac_start, &now);
+   blobmsg_add_u32(&b, "cac_seconds_left",
+   hapd->iface->cac_started ? hapd->iface->dfs_cac_ms / 
1000 - now.sec : 0);
+   blobmsg_close_table(&b, dfs_table);
+
+   ubus_send_reply(ctx, req, b.head);
+
+   return 0;
+}
+
 enum {
NOTIFY_RESPONSE,
__NOTIFY_MAX
@@ -1334,6 +1373,7 @@ hostapd_wnm_disassoc_imminent(struct ubus_context *ctx, 
struct ubus_object *obj,
 static const struct ubus_method bss_methods[] = {
UBUS_METHOD_NOARG("reload", hostapd_bss_reload),
UBUS_METHOD_NOARG("get_clients", hostapd_bss_get_clients),
+   UBUS_METHOD_NOARG("get_status", hostapd_bss_get_status),
UBUS_METHOD("del_client", hostapd_bss_del_client, del_policy),
UBUS_METHOD_NOARG("list_bans", hostapd_bss_list_bans),
 #ifdef CONFIG_WPS
-- 
2.29.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] scripts: download.pl: retry download using filename

2020-11-18 Thread David Bauer

With this commit, the download script will try downloading source files
using the filename instead of the url-filename in case the previous
download attempt using the url-filename failed.

This is required, as the OpenWrt sources mirrors serve files using the
filename files might be renamed to after downloading. If the original
mirror for a file where url-filename and filename do not match goes
down, the download failed prior to this patch.

Further improvement can be done by performing this only for the
OpenWrt sources mirrors.

Signed-off-by: David Bauer 
---
 scripts/download.pl | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/download.pl b/scripts/download.pl
index cdccae133f..351b06a08b 100755
--- a/scripts/download.pl
+++ b/scripts/download.pl
@@ -93,6 +93,7 @@ $hash_cmd or ($file_hash eq "skip") or die "Cannot find 
appropriate hash command
 sub download
 {
my $mirror = shift;
+   my $download_filename = shift;
 
$mirror =~ s!/$!!;
 
@@ -139,7 +140,7 @@ sub download
}
};
} else {
-   my @cmd = download_cmd("$mirror/$url_filename");
+   my @cmd = download_cmd("$mirror/$download_filename");
print STDERR "+ ".join(" ",@cmd)."\n";
open(FETCH_FD, '-|', @cmd) or die "Cannot launch curl or 
wget.\n";
$hash_cmd and do {
@@ -265,7 +266,10 @@ while (!-f "$target/$filename") {
my $mirror = shift @mirrors;
$mirror or die "No more mirrors to try - giving up.\n";
 
-   download($mirror);
+   download($mirror, $url_filename);
+   if (!-f "$target/$filename" && $url_filename ne $filename) {
+   download($mirror, $filename);
+   }
 }
 
 $SIG{INT} = \&cleanup;
-- 
2.29.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ath79: sysupgrade format policy for ar71xx migrations

2021-01-02 Thread David Bauer

Hi Sven,

sorry for the late reply.

Firs to fall, there is no real policy on that one, as OpenWrt itself does not
advertise support for cross-target upgrades. It might work, or it might not.

On 11/25/20 8:53 AM, Sven Eckelmann wrote:
> On Tuesday, 24 November 2020 08:58:04 CET Sven Eckelmann wrote:
> [...]
>> Now to the actual question:
> 
> I will just add some extra info to the options shown below. Maybe it makes 
> then more sense why I've added two gluon developers to the Cc.
> 
>> What should the OpenMesh devices use as images for ath79:
>>
>> 1. CE01 factory + sysupgrade-tar (like the OpenMesh IPQ40xx devices)
> 
> This would say this makes definitely sense for new devices. But in freifunk-
> gluon's context, this would mean that the autoupdater cannot automatically 
> upgrade from ar71xx to ath79.

I don't have a great overview over the current situation, but as much as i would
like to avoid having to push a pre-ath79 upgrade firmware with integrated 
per-device
upgrade paths, i think we can hardly avoid having to do such a thing, the 
alternative
being to EOL said boards.

In this specific case, adding a second sysupgrade image (be it 
gluon-downstream) and using
this as a transition image for the older releases might work or would it? We 
might also
modify the autoupdater to first try fetching an image specific to the target 
the device is
currently running to provide an upgrade paths for both targets. What do you 
think?

Best wishes
David

> 
> So if this is preferred, then there is at least a manual way to upgrade a 
> freifunk-gluon node to ath79. And this would be a "good" opportunity to get 
> rid of the CE01 upgrade code.
> 
> But maybe there is also a solution for this in gluon's context. David and 
> Matthias might know more about this.
> 
>> 2. CE01 factory + CE01 sysupgrade (like ar71xx)
> 
> At the moment, I would rather drop the factory image and not use this option. 
> This would (in my eyes) only be necessary when some tools are not able to 
> deal 
> with the metadata at the end of the sysupgrade image.
> 
>> 3. CE01 sysupgrade (like ar71xx but avoid having two files with the same 
>>content)
> 
> With this option, we would (hopefully) have a clean upgrade path with 
> freifunk-gluon's autoupdater. The dualboot_datachk sysupgrade code can be 
> adjusted to just work with CE01 images by creating some kind of hybrid 
> between 
> the old upgrade/openmesh.sh and the new upgrade/dualboot_datachk.sh. Or the 
> old upgrade/openmesh.sh (minus some unnecessary steps) can just be reused.
> 
> Kind regards,
>   Sven
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ramips: add support for Ubiquiti UniFi 6 Lite

2021-01-02 Thread David Bauer

ed bootloader to the device. Also install the
   kmod-mtd-rw package using opkg and load it.

   $ insmod mtd-rw.ko i_want_a_brick=1

   Write the patched bootloader to mtd0

   $ mtd write patched_uboot.bin u-boot

10. Erase the kernel1 partition, as the bootloader might otherwise
decide to boot from there.

$ mtd erase kernel1

11. Transfer the OpenWrt sysupgrade image to the device and install
using sysupgrade.

FIT configurations
--

In the future, the MT7621 UniFi6 family can be supported by a single
OpenWrt image.

config@1: U6 Lite
config@2: U6 IW
config@3: U6 Mesh
config@4: U6 Extender
config@5: U6 LR-EA (Early Access - GA is MT7622)

Signed-off-by: David Bauer 
---
 .../ramips/dts/mt7621_ubnt_unifi-6-lite.dts   |  83 
 .../ramips/dts/mt7621_ubnt_unifi-nanohd.dts   |  79 +--
 .../linux/ramips/dts/mt7621_ubnt_unifi.dtsi   |  81 
 target/linux/ramips/image/mt7621.mk   |  10 +
 .../mt7621/base-files/etc/board.d/02_network  |   3 +-
 target/linux/ramips/mt7621/config-5.4 |   1 +
 ...an-up-boot_command_line-initializati.patch | 192 ++
 ...2-MIPS-Always-define-builtin_cmdline.patch |  44 
 ...-MIPS-add-bootargs-override-property.patch |  63 ++
 9 files changed, 479 insertions(+), 77 deletions(-)
 create mode 100644 target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts
 create mode 100644 target/linux/ramips/dts/mt7621_ubnt_unifi.dtsi
 create mode 100644 
target/linux/ramips/patches-5.4/0001-MIPS-cmdline-Clean-up-boot_command_line-initializati.patch
 create mode 100644 
target/linux/ramips/patches-5.4/0002-MIPS-Always-define-builtin_cmdline.patch
 create mode 100644 
target/linux/ramips/patches-5.4/0010-MIPS-add-bootargs-override-property.patch

diff --git a/target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts 
b/target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts
new file mode 100644
index 00..1e40a13079
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621_ubnt_unifi.dtsi"
+
+/ {
+   compatible = "ubnt,unifi-6-lite", "mediatek,mt7621-soc";
+   model = "Ubiquiti UniFi 6 Lite";
+
+   chosen {
+   bootargs-override = "console=ttyS0,115200";
+   };
+};
+
+&spi0 {
+   status = "okay";
+
+   flash@0 {
+   compatible = "mx25l25635f", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <5000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x6>;
+   read-only;
+   };
+
+   partition@6 {
+   label = "u-boot-env";
+   reg = <0x6 0x1>;
+   read-only;
+   };
+
+   factory: partition@7 {
+   label = "factory";
+   reg = <0x7 0x4>;
+   read-only;
+   };
+
+   eeprom: partition@8 {
+   label = "eeprom";
+   reg = <0xb 0x1>;
+   read-only;
+   };
+
+   partition@9 {
+   label = "bs";
+   reg = <0xc 0x1>;
+   };
+
+   partition@a {
+   label = "cfg";
+   reg = <0xd 0x10>;
+   read-only;
+   };
+
+   partition@1a {
+   compatible = "denx,fit";
+   label = "firmware";
+   reg = <0x1d 0xf1>;
+   };
+
+   partition@10d {
+   label = "kernel1";
+   reg = <0x10e 0xf1>;
+   };
+   };
+   };
+};
+
+&wlan_2g {
+   mtd-mac-address = <&eeprom 0x0>;
+};
+
+&wlan_5g {
+   mediatek,mtd-eeprom = <&factory 0x2>;
+   mtd-mac-address = <&eeprom 0x6>;
+};
diff --git a/target/linux/ramips/dts/mt7621_ubnt_unifi-nanohd.dts 
b/target/linux/ramips/dts/mt7621_ubnt_uni

[PATCH] iw: enable HE PHY information for iw-tiny

2021-01-07 Thread David Bauer

Currently PHY information obtained from "iw phy" lacks information about
a PHYs HE capabilities when using the by default installed iw-tiny.

As there are already 802.11ax supported devices, enabled printing this
information for the by-default installed iw variant.

Signed-off-by: David Bauer 
---
 package/network/utils/iw/Makefile |  2 +-
 .../utils/iw/patches/200-reduce_size.patch| 38 ++-
 2 files changed, 12 insertions(+), 28 deletions(-)

diff --git a/package/network/utils/iw/Makefile 
b/package/network/utils/iw/Makefile
index 90e6782911..6eb10c837f 100644
--- a/package/network/utils/iw/Makefile
+++ b/package/network/utils/iw/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=iw
 PKG_VERSION:=5.8
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@KERNEL/software/network/iw
diff --git a/package/network/utils/iw/patches/200-reduce_size.patch 
b/package/network/utils/iw/patches/200-reduce_size.patch
index 24eb96537b..1e8286300b 100644
--- a/package/network/utils/iw/patches/200-reduce_size.patch
+++ b/package/network/utils/iw/patches/200-reduce_size.patch
@@ -38,23 +38,7 @@
  
 --- a/info.c
 +++ b/info.c
-@@ -167,6 +167,7 @@ static int print_phy_handler(struct nl_m
-   tb_band[NL80211_BAND_ATTR_VHT_MCS_SET])
-   
print_vht_info(nla_get_u32(tb_band[NL80211_BAND_ATTR_VHT_CAPA]),
-  
nla_data(tb_band[NL80211_BAND_ATTR_VHT_MCS_SET]));
-+#ifdef IW_FULL
-   if (tb_band[NL80211_BAND_ATTR_IFTYPE_DATA]) {
-   struct nlattr *nl_iftype;
-   int rem_band;
-@@ -174,6 +175,7 @@ static int print_phy_handler(struct nl_m
-   nla_for_each_nested(nl_iftype, 
tb_band[NL80211_BAND_ATTR_IFTYPE_DATA], rem_band)
-   print_he_info(nl_iftype);
-   }
-+#endif
-   if (tb_band[NL80211_BAND_ATTR_FREQS]) {
-   if (!band_had_freq) {
-   printf("\t\tFrequencies:\n");
-@@ -216,6 +218,7 @@ next:
+@@ -216,6 +216,7 @@ next:
}
}
  
@@ -62,7 +46,7 @@
if (tb_band[NL80211_BAND_ATTR_RATES]) {
printf("\t\tBitrates (non-HT):\n");
nla_for_each_nested(nl_rate, 
tb_band[NL80211_BAND_ATTR_RATES], rem_rate) {
-@@ -232,6 +235,7 @@ next:
+@@ -232,6 +233,7 @@ next:
printf("\n");
}
}
@@ -70,7 +54,7 @@
}
}
  
-@@ -297,6 +301,7 @@ next:
+@@ -297,6 +299,7 @@ next:
printf("\tCoverage class: %d (up to %dm)\n", coverage, 450 * 
coverage);
}
  
@@ -78,7 +62,7 @@
if (tb_msg[NL80211_ATTR_CIPHER_SUITES]) {
int num = nla_len(tb_msg[NL80211_ATTR_CIPHER_SUITES]) / 
sizeof(__u32);
int i;
-@@ -308,6 +313,7 @@ next:
+@@ -308,6 +311,7 @@ next:
cipher_name(ciphers[i]));
}
}
@@ -86,7 +70,7 @@
  
if (tb_msg[NL80211_ATTR_WIPHY_ANTENNA_AVAIL_TX] &&
tb_msg[NL80211_ATTR_WIPHY_ANTENNA_AVAIL_RX])
-@@ -327,11 +333,13 @@ next:
+@@ -327,11 +331,13 @@ next:
printf("\t\t * %s\n", iftype_name(nla_type(nl_mode)));
}
  
@@ -100,7 +84,7 @@
  
if (tb_msg[NL80211_ATTR_INTERFACE_COMBINATIONS]) {
struct nlattr *nl_combi;
-@@ -428,6 +436,7 @@ broken_combination:
+@@ -428,6 +434,7 @@ broken_combination:
printf("\tinterface combinations are not supported\n");
}
  
@@ -108,7 +92,7 @@
if (tb_msg[NL80211_ATTR_SUPPORTED_COMMANDS]) {
printf("\tSupported commands:\n");
nla_for_each_nested(nl_cmd, 
tb_msg[NL80211_ATTR_SUPPORTED_COMMANDS], rem_cmd)
-@@ -525,6 +534,7 @@ broken_combination:
+@@ -525,6 +532,7 @@ broken_combination:
printf("\t\t * wake up on TCP connection\n");
}
}
@@ -116,7 +100,7 @@
  
if (tb_msg[NL80211_ATTR_ROAM_SUPPORT])
printf("\tDevice supports roaming.\n");
-@@ -563,6 +573,7 @@ broken_combination:
+@@ -563,6 +571,7 @@ broken_combination:
}
}
  
@@ -124,7 +108,7 @@
if (tb_msg[NL80211_ATTR_FEATURE_FLAGS]) {
unsigned int features = 
nla_get_u32(tb_msg[NL80211_ATTR_FEATURE_FLAGS]);
  
-@@ -627,6 +638,7 @@ broken_combination:
+@@ -627,6 +636,7 @@ broken_combination:
if (features & NL80211_FEATURE_ND_RANDOM_MAC_ADDR)
printf("\tDevice supports randomizing MAC-addr in 
net-detect scans.\

Re: ath10k-ct all hash values are different?

2021-01-15 Thread David Bauer


Hi Ben,

On 1/14/21 7:14 PM, Ben Greear wrote:

On 1/14/21 10:05 AM, Ben Greear wrote:

On 1/13/21 4:58 PM, Sven Roederer wrote:

Ben,

seems to me, that at least 
"firmware-5-ct-full-community-12.bin-lede.013" is

still not recovered. File is there, but contains only 0x00.
This seems to cause my fresh build of 19.07.5 to fail.


Yes, I verified that 9980 firmware is not recovered.  I'm not sure we 
have any local copy of
that old file.  Maybe someone else that has compiled this in the past 
has a working

copy they could send me to repopulate my web server?


If my grep is correct, these files are also corrupted, so if someone has 
these
cached somewhere, please send these to me I'll get them re-populated as 
well.


They should all be cached on the sources mirror. [0] Sadly downloads 
from their fail for older releases, so fixing them on your 
download-server would be great.


[0] http://sources.openwrt.org/

Best wishes
David



[greearb@ww2 downloads]$ find . -name "firmware-*lede*" -print|xargs 
grep -L ATH10

./firmware-2-ct-full-htt-mgt-community-22.bin.lede.020
./firmware-2-ct-full-community-22.bin.lede.003
./ath10k-9984-10-4b/firmware-5-ct-full-community-12.bin-lede.016
./ath10k-9984-10-4b/firmware-5-ct-full-community-12.bin-lede.020
./ath10k-9984-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.020
./ath10k-9984-10-4b/firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.020
./ath10k-9984-10-4b/firmware-5-ct-htt-mgt-community-12.bin-lede.020
./ath10k-9984-10-4b/firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.021
./ath10k-9984-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.016
./ath10k-9984-10-4/firmware-5-ct-full-community-7.bin-lede.001
./ath10k-9984-10-4/firmware-5-ct-full-community-8.bin-lede.006
./ath10k-9984-10-4/firmware-5-ct-full-community-7.bin-lede.004
./ath10k-9984-10-4/firmware-5-ct-full-community-9.bin-lede.003
./firmware-2-ct-full-htt-mgt-community-22.bin.lede.003
./firmware-2-ct-full-community-22.bin.lede.016
./ath10k-9887/firmware-2-ct-full-htt-mgt-community-22.bin.lede.020
./ath10k-9887/firmware-2-ct-full-community-22.bin.lede.020
./ath10k-9887/firmware-2-ct-full-htt-mgt-community-22.bin.lede.004
./ath10k-9887/firmware-2-ct-full-community-22.bin.lede.004
./firmware-2-ct-full-community-22.bin.lede.020
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.006
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.012
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.007
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.016
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.020
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.008
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.001
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.020
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.003
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.018
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.002
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.005
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.003
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.013
./ath10k-10-4b/firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.020
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.009
./ath10k-10-4b/firmware-5-ct-htt-mgt-community-12.bin-lede.020
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.010
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.015
./ath10k-10-4b/firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.021
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.017
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.016
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.014
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.007
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.004
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
./ath10k-10-4b/firmware-5-ct-htt-mgt-community-12.bin-lede.018
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.005
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.002
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.014
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.004
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.011
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.011
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.012
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.017
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.013
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.006
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.001
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.010
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.008
./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.009
./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.015
./firmware-2-ct-full

[PATCH] rockchip: use stable MAC-address for NanoPi R2S

2021-01-16 Thread David Bauer

The NanoPi R2S does not have a board specific MAC address written inside
e.g. an EEPROM, hence why it is randomly generated on first boot.

The issue with that however is the lack of a driver for the PRNG.
It often results to the same MAC address used on multiple boards by
default, as urngd is not active at this early stage resulting in low
available entropy.

There is however a semi-unique identifier available to us, which is the
CID of the used SD card. It is unique to each SD card, hence we can use
it to generate the MAC address used for LAN and WAN.

Signed-off-by: David Bauer 
---
 .../rockchip/armv8/base-files/etc/board.d/02_network | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/linux/rockchip/armv8/base-files/etc/board.d/02_network 
b/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
index e129fd6a67..48133c81a1 100755
--- a/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
+++ b/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
@@ -17,6 +17,13 @@ rockchip_setup_interfaces()
esac
 }
 
+nanopi_r2s_generate_mac()
+{
+   local sd_hash=$(sha256sum 
/sys/devices/platform/ff50.dwmmc/mmc_host/mmc0/mmc0:*/cid)
+   local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1 
count=12 2>/dev/null)")
+   echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
+}
+
 rockchip_setup_macs()
 {
local board="$1"
@@ -26,7 +33,7 @@ rockchip_setup_macs()
 
case "$board" in
friendlyarm,nanopi-r2s)
-   wan_mac=$(macaddr_random)
+   wan_mac=$(nanopi_r2s_generate_mac)
lan_mac=$(macaddr_add "$wan_mac" +1)
;;
esac
-- 
2.30.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: replace obsolete mx25l25635f hack

2021-01-21 Thread David Bauer

Hi,

On 1/21/21 5:21 AM, DENG Qingfang wrote:
> The kernel bump to 5.4 removed the mx25l25635f hack, and the upstream
> property "broken-flash-reset" should be used instead.

Is this dependent on board design? The need for the old hack should be fixed by
this upstream commit [0]. Given that commit adds SNOR_F_4B_OPCODES for the
mx25l25635f, it should in turn disable the hack enabled by broken-flash-reset, 
as
this is dependend on 4B opcodes not being supported. [1]

Or am i missing something here?

[0] 
https://github.com/torvalds/linux/commit/2bffa65da43e399079dad5947c6aa9ab3cfa4ad4
[1] 
https://github.com/torvalds/linux/blob/master/drivers/mtd/spi-nor/core.c#L3270

Best wishes
David

> 
> Signed-off-by: DENG Qingfang 
> ---
>  target/linux/ramips/dts/mt7620a_youku_yk1.dts| 3 ++-
>  target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts  | 3 ++-
>  target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts | 3 ++-
>  target/linux/ramips/dts/mt7621_ubnt_unifi-nanohd.dts | 3 ++-
>  4 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/target/linux/ramips/dts/mt7620a_youku_yk1.dts 
> b/target/linux/ramips/dts/mt7620a_youku_yk1.dts
> index 86e2031aa6..a3e73e52a7 100644
> --- a/target/linux/ramips/dts/mt7620a_youku_yk1.dts
> +++ b/target/linux/ramips/dts/mt7620a_youku_yk1.dts
> @@ -67,10 +67,11 @@
>   status = "okay";
>  
>   flash@0 {
> - compatible = "mx25l25635f", "jedec,spi-nor";
> + compatible = "jedec,spi-nor";
>   reg = <0>;
>   spi-max-frequency = <2500>;
>   m25p,fast-read;
> + broken-flash-reset;
>  
>   partitions {
>   compatible = "fixed-partitions";
> diff --git a/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts 
> b/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
> index 49eeb46d5f..e805454bf6 100644
> --- a/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
> +++ b/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
> @@ -65,10 +65,11 @@
>   status = "okay";
>  
>   flash@0 {
> - compatible = "mx25l25635f", "jedec,spi-nor";
> + compatible = "jedec,spi-nor";
>   reg = <0>;
>   spi-max-frequency = <8000>;
>   m25p,fast-read;
> + broken-flash-reset;
>  
>   partitions {
>   compatible = "fixed-partitions";
> diff --git a/target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts 
> b/target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts
> index f5425ccfee..2454e640a9 100644
> --- a/target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts
> +++ b/target/linux/ramips/dts/mt7621_ubnt_unifi-6-lite.dts
> @@ -15,9 +15,10 @@
>   status = "okay";
>  
>   flash@0 {
> - compatible = "mx25l25635f", "jedec,spi-nor";
> + compatible = "jedec,spi-nor";
>   reg = <0>;
>   spi-max-frequency = <5000>;
> + broken-flash-reset;
>  
>   partitions {
>   compatible = "fixed-partitions";
> diff --git a/target/linux/ramips/dts/mt7621_ubnt_unifi-nanohd.dts 
> b/target/linux/ramips/dts/mt7621_ubnt_unifi-nanohd.dts
> index 401868362e..d5ed78d03f 100644
> --- a/target/linux/ramips/dts/mt7621_ubnt_unifi-nanohd.dts
> +++ b/target/linux/ramips/dts/mt7621_ubnt_unifi-nanohd.dts
> @@ -11,9 +11,10 @@
>   status = "okay";
>  
>   flash@0 {
> - compatible = "mx25l25635f", "jedec,spi-nor";
> + compatible = "jedec,spi-nor";
>   reg = <0>;
>   spi-max-frequency = <5000>;
> + broken-flash-reset;
>  
>   partitions {
>   compatible = "fixed-partitions";
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] mac80211: convert UniFi Outdoor+ HSR support to OF

2021-01-22 Thread David Bauer

Enable support for the Ubiquiti UniFi Outdoor+ RF filter via
device-tree. The old way of using platform data is not required anymore,
as it was only used on the now removed ar71xx target.

Signed-off-by: David Bauer 
---
 .../ath/551-ath9k_ubnt_uap_plus_hsr.patch | 35 ++-
 .../files/include/linux/ath9k_platform.h  |  2 --
 2 files changed, 10 insertions(+), 27 deletions(-)

diff --git 
a/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch 
b/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch
index 4454baeef1..24cffb0e0e 100644
--- a/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch
+++ b/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch
@@ -1,27 +1,26 @@
 --- a/drivers/net/wireless/ath/ath9k/channel.c
 +++ b/drivers/net/wireless/ath/ath9k/channel.c
-@@ -15,6 +15,8 @@
+@@ -15,6 +15,7 @@
   */
  
  #include "ath9k.h"
-+#include 
 +#include "hsr.h"
  
  /* Set/change channels.  If the channel is really being changed, it's done
   * by reseting the chip.  To accomplish this we must first cleanup any pending
-@@ -22,6 +24,7 @@
+@@ -22,6 +23,7 @@
   */
  static int ath_set_channel(struct ath_softc *sc)
  {
-+  struct ath9k_platform_data *pdata = sc->dev->platform_data;
++  struct device_node *np = sc->dev->of_node;
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hw *hw = sc->hw;
-@@ -42,6 +45,11 @@ static int ath_set_channel(struct ath_so
+@@ -42,6 +44,11 @@ static int ath_set_channel(struct ath_so
ath_dbg(common, CONFIG, "Set channel: %d MHz width: %d\n",
chan->center_freq, chandef->width);
  
-+  if (pdata && pdata->ubnt_hsr) {
++  if (of_property_read_bool(np, "ath9k,ubnt-hsr")) {
 +  ath9k_hsr_enable(ah, chandef->width, chan->center_freq);
 +  ath9k_hsr_status(ah);
 +  }
@@ -332,30 +331,27 @@
 +#endif /* HSR_H */
 --- a/drivers/net/wireless/ath/ath9k/main.c
 +++ b/drivers/net/wireless/ath/ath9k/main.c
-@@ -16,8 +16,10 @@
- 
- #include 
+@@ -18,6 +18,7 @@
  #include 
-+#include 
  #include "ath9k.h"
  #include "btcoex.h"
 +#include "hsr.h"
  
  u8 ath9k_parse_mpdudensity(u8 mpdudensity)
  {
-@@ -649,6 +651,7 @@ void ath_reset_work(struct work_struct *
+@@ -649,6 +650,7 @@ void ath_reset_work(struct work_struct *
  static int ath9k_start(struct ieee80211_hw *hw)
  {
struct ath_softc *sc = hw->priv;
-+  struct ath9k_platform_data *pdata = sc->dev->platform_data;
++  struct device_node *np = sc->dev->of_node;
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_channel *curchan = sc->cur_chan->chandef.chan;
-@@ -727,6 +730,11 @@ static int ath9k_start(struct ieee80211_
+@@ -727,6 +729,11 @@ static int ath9k_start(struct ieee80211_
  AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
}
  
-+  if (pdata && pdata->ubnt_hsr) {
++  if (of_property_read_bool(np, "ath9k,ubnt-hsr")) {
 +  ath9k_hsr_init(ah);
 +  ath9k_hsr_disable(ah);
 +  }
@@ -373,17 +369,6 @@
  
  ath9k-$(CPTCFG_ATH9K_DEBUGFS) += debug.o
  
 a/include/linux/ath9k_platform.h
-+++ b/include/linux/ath9k_platform.h
-@@ -53,6 +53,8 @@ struct ath9k_platform_data {
-   unsigned num_btns;
-   const struct gpio_keys_button *btns;
-   unsigned btn_poll_interval;
-+
-+  bool ubnt_hsr;
- };
- 
- #endif /* _LINUX_ATH9K_PLATFORM_H */
 --- a/local-symbols
 +++ b/local-symbols
 @@ -112,6 +112,7 @@ ATH9K_WOW=
diff --git a/target/linux/generic/files/include/linux/ath9k_platform.h 
b/target/linux/generic/files/include/linux/ath9k_platform.h
index f1f2ad419c..e210108568 100644
--- a/target/linux/generic/files/include/linux/ath9k_platform.h
+++ b/target/linux/generic/files/include/linux/ath9k_platform.h
@@ -53,8 +53,6 @@ struct ath9k_platform_data {
unsigned num_btns;
const struct gpio_keys_button *btns;
unsigned btn_poll_interval;
-
-   bool ubnt_hsr;
 };
 
 #endif /* _LINUX_ATH9K_PLATFORM_H */
-- 
2.30.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] ath79: add support for Ubiquiti UniFi AP Outdoor+

2021-01-22 Thread David Bauer

Hardware

Atheros AR7241
16M SPI-NOR
64M DDR2
Atheros AR9283 2T2R b/g/n
2x Fast Ethernet (built-in)

Installation


Transfer the Firmware update to the device using SCP.

Install using fwupdate.real -m  -d

Signed-off-by: David Bauer 
---
 .../dts/ar7241_ubnt_unifi-ap-outdoor-plus.dts | 102 ++
 target/linux/ath79/dts/ar7241_ubnt_unifi.dts  |  45 +---
 target/linux/ath79/dts/ar7241_ubnt_unifi.dtsi |  52 +
 .../generic/base-files/etc/board.d/02_network |   3 +-
 .../etc/hotplug.d/firmware/10-ath9k-eeprom|   3 +-
 target/linux/ath79/image/generic-ubnt.mk  |  30 --
 6 files changed, 180 insertions(+), 55 deletions(-)
 create mode 100644 target/linux/ath79/dts/ar7241_ubnt_unifi-ap-outdoor-plus.dts
 create mode 100644 target/linux/ath79/dts/ar7241_ubnt_unifi.dtsi

diff --git a/target/linux/ath79/dts/ar7241_ubnt_unifi-ap-outdoor-plus.dts 
b/target/linux/ath79/dts/ar7241_ubnt_unifi-ap-outdoor-plus.dts
new file mode 100644
index 00..936850b7df
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_ubnt_unifi-ap-outdoor-plus.dts
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar7241_ubnt_unifi.dtsi"
+
+/ {
+   compatible = "ubnt,unifi-ap-outdoor-plus", "qca,ar7241";
+   model = "Ubiquiti UniFi AP Outdoor+";
+
+   aliases {
+   led-boot = &led_white;
+   led-failsafe = &led_white;
+   led-running = &led_white;
+   led-upgrade = &led_white;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_white: white {
+   label = "blue";
+   gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
+   };
+
+   blue {
+   label = "white";
+   gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+&spi {
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <5000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   uboot: partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x4>;
+   read-only;
+   };
+
+   partition@4 {
+   label = "u-boot-env";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0xf6>;
+
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "kernel";
+   reg = <0x0 0x30>;
+   /* Can be resized w/o issues.
+* U-Boot can load kernel from the
+* entirety of the "firmware" partition 
space.
+*/
+   };
+
+   partition@30 {
+   label = "rootfs";
+   reg = <0x30 0xc6>;
+   };
+   };
+
+   partition@fb {
+   label = "cfg";
+   reg = <0xfb 0x4>;
+   read-only;
+   };
+
+   art: partition@ff {
+   label = "art";
+   reg = <0xff 0x1>;
+   read-only;
+   };
+   };
+   };
+};
+
+ð1 {
+   status = "okay";
+
+   mtd-mac-address = <&art 0x6>;
+};
+
+&wifi {
+   ath9k,ubnt-hsr;
+};
diff --git a/target/linux/ath79/dts/ar7241_ubnt_unifi.dts 
b/target/linux/ath79/dts/ar7241_ubnt_unifi.dts
index bdb4c61a48..287e8cc7db 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_unifi.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_unifi.dts
@@ -1,9 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later OR MIT
 
-#includ

[PATCH iwinfo] iwinfo: add basic IEEE 802.11ax support

2021-02-03 Thread David Bauer

This adds basic support for IEEE 802.11ax when requesting HW or HT
Modelist for a PHY from iwinfo. This way, applications using iwinfo can
detect HE phys.

Signed-off-by: David Bauer 
---
 api/nl80211.h| 38 ++
 include/iwinfo.h |  8 +++-
 iwinfo_cli.c |  3 ++-
 iwinfo_lib.c |  7 ++-
 iwinfo_lua.c |  3 +++
 iwinfo_nl80211.c | 34 ++
 6 files changed, 90 insertions(+), 3 deletions(-)

diff --git a/api/nl80211.h b/api/nl80211.h
index 5b7b5eb..3d252e4 100644
--- a/api/nl80211.h
+++ b/api/nl80211.h
@@ -2582,6 +2582,41 @@ enum nl80211_mpath_info {
NL80211_MPATH_INFO_MAX = __NL80211_MPATH_INFO_AFTER_LAST - 1
 };
 
+/**
+ * enum nl80211_band_iftype_attr - Interface type data attributes
+ *
+ * @__NL80211_BAND_IFTYPE_ATTR_INVALID: attribute number 0 is reserved
+ * @NL80211_BAND_IFTYPE_ATTR_IFTYPES: nested attribute containing a flag 
attribute
+ * for each interface type that supports the band data
+ * @NL80211_BAND_IFTYPE_ATTR_HE_CAP_MAC: HE MAC capabilities as in HE
+ * capabilities IE
+ * @NL80211_BAND_IFTYPE_ATTR_HE_CAP_PHY: HE PHY capabilities as in HE
+ * capabilities IE
+ * @NL80211_BAND_IFTYPE_ATTR_HE_CAP_MCS_SET: HE supported NSS/MCS as in HE
+ * capabilities IE
+ * @NL80211_BAND_IFTYPE_ATTR_HE_CAP_PPE: HE PPE thresholds information as
+ * defined in HE capabilities IE
+ * @NL80211_BAND_IFTYPE_ATTR_MAX: highest band HE capability attribute 
currently
+ * defined
+ * @NL80211_BAND_IFTYPE_ATTR_HE_6GHZ_CAPA: HE 6GHz band capabilities (__le16),
+ * given for all 6 GHz band channels
+ * @__NL80211_BAND_IFTYPE_ATTR_AFTER_LAST: internal use
+ */
+enum nl80211_band_iftype_attr {
+   __NL80211_BAND_IFTYPE_ATTR_INVALID,
+
+   NL80211_BAND_IFTYPE_ATTR_IFTYPES,
+   NL80211_BAND_IFTYPE_ATTR_HE_CAP_MAC,
+   NL80211_BAND_IFTYPE_ATTR_HE_CAP_PHY,
+   NL80211_BAND_IFTYPE_ATTR_HE_CAP_MCS_SET,
+   NL80211_BAND_IFTYPE_ATTR_HE_CAP_PPE,
+   NL80211_BAND_IFTYPE_ATTR_HE_6GHZ_CAPA,
+
+   /* keep last */
+   __NL80211_BAND_IFTYPE_ATTR_AFTER_LAST,
+   NL80211_BAND_IFTYPE_ATTR_MAX = __NL80211_BAND_IFTYPE_ATTR_AFTER_LAST - 1
+};
+
 /**
  * enum nl80211_band_attr - band attributes
  * @__NL80211_BAND_ATTR_INVALID: attribute number 0 is reserved
@@ -2597,6 +2632,8 @@ enum nl80211_mpath_info {
  * @NL80211_BAND_ATTR_VHT_MCS_SET: 32-byte attribute containing the MCS set as
  * defined in 802.11ac
  * @NL80211_BAND_ATTR_VHT_CAPA: VHT capabilities, as in the HT information IE
+ * @NL80211_BAND_ATTR_IFTYPE_DATA: nested array attribute, with each entry 
using
+ * attributes from &enum nl80211_band_iftype_attr
  * @NL80211_BAND_ATTR_MAX: highest band attribute currently defined
  * @__NL80211_BAND_ATTR_AFTER_LAST: internal use
  */
@@ -2612,6 +2649,7 @@ enum nl80211_band_attr {
 
NL80211_BAND_ATTR_VHT_MCS_SET,
NL80211_BAND_ATTR_VHT_CAPA,
+   NL80211_BAND_ATTR_IFTYPE_DATA,
 
/* keep last */
__NL80211_BAND_ATTR_AFTER_LAST,
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 5e64294..d1753ef 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -29,6 +29,7 @@
 #define IWINFO_80211_N   (1 << 3)
 #define IWINFO_80211_AC  (1 << 4)
 #define IWINFO_80211_AD  (1 << 5)
+#define IWINFO_80211_AX  (1 << 6)
 
 #define IWINFO_CIPHER_NONE   (1 << 0)
 #define IWINFO_CIPHER_WEP40  (1 << 1)
@@ -89,8 +90,13 @@ enum iwinfo_htmode {
IWINFO_HTMODE_VHT80_80   = (1 << 5),
IWINFO_HTMODE_VHT160 = (1 << 6),
IWINFO_HTMODE_NOHT   = (1 << 7),
+   IWINFO_HTMODE_HE20   = (1 << 8),
+   IWINFO_HTMODE_HE40   = (1 << 9),
+   IWINFO_HTMODE_HE80   = (1 << 10),
+   IWINFO_HTMODE_HE80_80= (1 << 11),
+   IWINFO_HTMODE_HE160  = (1 << 12),
 
-   IWINFO_HTMODE_COUNT  = 8
+   IWINFO_HTMODE_COUNT  = 13
 };
 
 extern const char *IWINFO_HTMODE_NAMES[IWINFO_HTMODE_COUNT];
diff --git a/iwinfo_cli.c b/iwinfo_cli.c
index 0332bc2..c18ea49 100644
--- a/iwinfo_cli.c
+++ b/iwinfo_cli.c
@@ -282,7 +282,8 @@ static char * format_hwmodes(int modes)
(modes & IWINFO_80211_G) ? "g" : "",
(modes & IWINFO_80211_N) ? "n" : "",
(modes & IWINFO_80211_AC) ? "ac" : "",
-   (modes & IWINFO_80211_AD) ? "ad" : "");
+   (modes & IWINFO_80211_AD) ? "ad" : "",
+   (modes & IWINFO_80211_AX) ? "ax" : "");
 
return buf;
 }
diff --git a/iwinfo_lib.c b/iwinfo_lib.c
index 7a33a35..70b080c 100644
--- a/iwinfo_lib.c
+++ b/iwinfo_lib.c
@@ -65,7 +65,12 @@ const char *IWINFO_HTMODE_NAMES[] = {
"VHT80",
"VHT80+80&quo

[PATCH] sdk: expose binary strip settings

2021-02-07 Thread David Bauer

Expose the SDK options for binary stripping to the menuconfig. This
way, packages can easily be built with debug symbols using the SDK.

Signed-off-by: David Bauer 
---
 target/sdk/files/Config.in | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/target/sdk/files/Config.in b/target/sdk/files/Config.in
index 4393daab5b..f687992497 100644
--- a/target/sdk/files/Config.in
+++ b/target/sdk/files/Config.in
@@ -18,6 +18,52 @@ menu "Global build settings"
bool "Cryptographically sign package lists"
default y
 
+   comment "Package build options"
+
+   config DEBUG
+   bool
+   prompt "Compile packages with debugging info"
+   default n
+   help
+ Adds -g3 to the CFLAGS.
+
+   comment "Stripping options"
+
+   choice
+   prompt "Binary stripping method"
+   default USE_STRIP   if EXTERNAL_TOOLCHAIN
+   default USE_STRIP   if USE_GLIBC
+   default USE_SSTRIP
+   help
+ Select the binary stripping method you wish to use.
+
+   config NO_STRIP
+   bool "none"
+   help
+ This will install unstripped binaries (useful for 
native
+ compiling/debugging).
+
+   config USE_STRIP
+   bool "strip"
+   help
+ This will install binaries stripped using strip from 
binutils.
+
+   config USE_SSTRIP
+   bool "sstrip"
+   depends on !USE_GLIBC
+   help
+ This will install binaries stripped using sstrip.
+   endchoice
+
+   config STRIP_ARGS
+   string
+   prompt "Strip arguments"
+   depends on USE_STRIP
+   default "--strip-unneeded --remove-section=.comment 
--remove-section=.note" if DEBUG
+   default "--strip-all"
+   help
+ Specifies arguments passed to the strip command when 
stripping binaries.
+
 endmenu
 
 menu "Advanced configuration options (for developers)"
-- 
2.30.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] mediatek: add Ubiquiti LED driver

2021-02-15 Thread David Bauer

Add a driver for controlling the RGB LED via Ubiquitis own "LEDBAR" LED
controller based on the Holtek HT32F52241 MCU.

This driver is initially used by the Ubiquiti UniFi 6 LR, however
judging from FCC pictures the MCU is also found on the U6-Mesh as well
as the U6-Extender.

Signed-off-by: David Bauer 
---
 .../files-5.4/drivers/leds/leds-ubnt-ledbar.c | 210 ++
 target/linux/mediatek/mt7622/config-5.4   |   1 +
 target/linux/mediatek/mt7623/config-5.4   |   1 +
 target/linux/mediatek/mt7629/config-5.4   |   1 +
 .../patches-5.4/1021-ubnt-ledbar-driver.patch |  29 +++
 5 files changed, 242 insertions(+)
 create mode 100644 
target/linux/mediatek/files-5.4/drivers/leds/leds-ubnt-ledbar.c
 create mode 100644 
target/linux/mediatek/patches-5.4/1021-ubnt-ledbar-driver.patch

diff --git a/target/linux/mediatek/files-5.4/drivers/leds/leds-ubnt-ledbar.c 
b/target/linux/mediatek/files-5.4/drivers/leds/leds-ubnt-ledbar.c
new file mode 100644
index 00..1f50038b8c
--- /dev/null
+++ b/target/linux/mediatek/files-5.4/drivers/leds/leds-ubnt-ledbar.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * Driver for the Ubiquiti RGB LED controller (LEDBAR).
+ * This Controller is based on a Holtek HT32F52241 and connected
+ * via I2C.
+ *
+ *  - The Controller needs an enable signal set to high when
+ *performing a transaction. On the U6-LR, this is located
+ *at Pin 18 (R6902)
+ *
+ *  - The Pin is also printed when calling the "usetled" function
+ *contained in the ubntapp bootloader application.
+ */
+
+#define UBNT_LEDBAR_MAX_BRIGHTNESS 0xff
+
+#define UBNT_LEDBAR_TRANSACTION_LENGTH 8
+#define UBNT_LEDBAR_TRANSACTION_SUCCESS0xaa
+
+#define UBNT_LEDBAR_TRANSACTION_BLUE_IDX   2
+#define UBNT_LEDBAR_TRANSACTION_GREEN_IDX  3
+#define UBNT_LEDBAR_TRANSACTION_RED_IDX4
+
+struct ubnt_ledbar {
+   struct mutex lock;
+   struct i2c_client *client;
+   struct led_classdev led_red;
+   struct led_classdev led_green;
+   struct led_classdev led_blue;
+   struct gpio_desc *enable_gpio;
+};
+
+static int ubnt_ledbar_perform_transaction(struct ubnt_ledbar *ledbar,
+  char *transaction)
+{
+   int ret;
+   int i;
+
+   for (i = 0; i < UBNT_LEDBAR_TRANSACTION_LENGTH; i++)
+   i2c_smbus_write_byte(ledbar->client, transaction[i]);
+
+   return i2c_smbus_read_byte(ledbar->client);
+}
+
+static int ubnt_ledbar_apply_state(struct ubnt_ledbar *ledbar)
+{
+   char setup_msg[UBNT_LEDBAR_TRANSACTION_LENGTH] = {0x40, 0x10, 0x00, 
0x00,
+ 0x00, 0x00, 0x00, 
0x11};
+   char led_msg[UBNT_LEDBAR_TRANSACTION_LENGTH] = {0x40, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x01, 0x00};
+   char i2c_response;
+   int ret = 0;
+
+   mutex_lock(&ledbar->lock);
+
+   led_msg[UBNT_LEDBAR_TRANSACTION_BLUE_IDX] = ledbar->led_blue.brightness;
+   led_msg[UBNT_LEDBAR_TRANSACTION_GREEN_IDX] = 
ledbar->led_green.brightness;
+   led_msg[UBNT_LEDBAR_TRANSACTION_RED_IDX] = ledbar->led_red.brightness;
+
+   gpiod_set_raw_value(ledbar->enable_gpio, 1);
+
+   msleep(10);
+
+   i2c_response = ubnt_ledbar_perform_transaction(ledbar, setup_msg);
+   if (i2c_response != UBNT_LEDBAR_TRANSACTION_SUCCESS) {
+   dev_err(&ledbar->client->dev, "Error initializing LED 
transaction: %02x\n", ret);
+   ret = -EINVAL;
+   goto out_gpio;
+   }
+
+   i2c_response = ubnt_ledbar_perform_transaction(ledbar, led_msg);
+   if (i2c_response != UBNT_LEDBAR_TRANSACTION_SUCCESS) {
+   dev_err(&ledbar->client->dev, "Failed LED transaction: %02x\n", 
ret);
+   ret = -EINVAL;
+   goto out_gpio;
+   }
+
+   msleep(10);
+out_gpio:
+   gpiod_set_raw_value(ledbar->enable_gpio, 0);
+
+   mutex_unlock(&ledbar->lock);
+
+   return ret;
+}
+
+#define UBNT_LEDBAR_CONTROL_RGBS(name) \
+static int ubnt_ledbar_set_##name##_brightness(struct led_classdev *led_cdev,\
+   enum led_brightness value)  \
+{  \
+   struct ubnt_ledbar *ledbar = \
+   container_of(led_cdev, struct ubnt_ledbar, led_##name); 
\
+   int ret; \
+   led_cdev->brightness = value; \
+   ret = ubnt_ledbar_apply_state(ledbar); \
+   return ret; \
+}
+
+UBNT_LEDBAR_CONTROL_RGBS(red);
+UBNT_LEDBAR_CONTROL_RGBS(green);
+UBNT_LEDBAR_CONTROL_RGBS(blue);
+
+
+static int ubnt_ledbar_init_led(struct device_node *np, struct ubnt_ledbar 
*l

[PATCH 2/2] mediatek: add support for Ubiquiti UniFi 6 LR

2021-02-15 Thread David Bauer

Hardware


MediaTek MT7622
512MB DDR3 RAM
64M SPI-NOR Flash (Winbond W25Q512JV)
MediaTek MT7622 802.11bgn 4T4R WMAC
MediaTek MT7915 802.11ax 4T4R
Marvell AQR1112 100/1000/2500 NBase-T PHY
Holtek HT32F52241 LED controller
Reset Switch

UART


CPU UART0 at the pinout next to the Holtek MCU.

Pinout (first pin next to SoC / MCU)

0 3V3
1 RX
2 TX
3 GND

Settings are 115200 8N1.

Opening the case


Opening the case is not a nice task, as itis glued together. Insert a
flat knife between the front and back casing below the ethernet port.
Open up a gap this way and insert a flat scredriver, remove the knife.

Work your way around the casing by applying force to seperate the front
and back casing. This losens the glue and opens the plastic clips. Be
gentle, as these clips are very cheap and break quickly.

Installation


1. Connect to the booted device at 192.168.1.20 using username/password
   "ubnt".

2. Transfer the OpenWrt sysupgrade image to the device using SCP.

3. Check the mtd partition number for bs / kernel0 / kernel1

   $ cat /proc/mtd

4. Set the bootselect flag to boot from kernel0

   $ dd if=/dev/zero bs=1 count=1 of=/dev/mtdblock6

5. Write the OpenWrt sysupgrade image to both kernel0 as well as kernel1

   $ dd if=openwrt.bin of=/dev/mtdblock8
   $ dd if=openwrt.bin of=/dev/mtdblock9

6. Reboot the device. It should boot into OpenWrt.

Signed-off-by: David Bauer 
---
 .../lib/preinit/05_set_preinit_iface  |  10 +-
 .../dts/mediatek/mt7622-ubnt-unifi-6-lr.dts   | 327 ++
 target/linux/mediatek/image/mt7622.mk |   9 +
 .../mt7622/base-files/etc/board.d/02_network  |   3 +
 target/linux/mediatek/mt7622/config-5.4   |   6 +-
 .../patches-5.4/1020-spi-nor-w25q512jv.patch  |  25 ++
 6 files changed, 378 insertions(+), 2 deletions(-)
 create mode 100644 
target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7622-ubnt-unifi-6-lr.dts
 create mode 100644 
target/linux/mediatek/patches-5.4/1020-spi-nor-w25q512jv.patch

diff --git a/target/linux/mediatek/base-files/lib/preinit/05_set_preinit_iface 
b/target/linux/mediatek/base-files/lib/preinit/05_set_preinit_iface
index f39e8aee8d..3ac856d1c4 100644
--- a/target/linux/mediatek/base-files/lib/preinit/05_set_preinit_iface
+++ b/target/linux/mediatek/base-files/lib/preinit/05_set_preinit_iface
@@ -1,6 +1,14 @@
 set_preinit_iface() {
ip link set eth0 up
-   ifname=lan1
+
+   case $(board_name) in
+   ubnt,unifi-6-lr)
+   ifname=eth0
+   ;;
+   *)
+   ifname=lan1
+   ;;
+   esac
 }
 
 boot_hook_add preinit_main set_preinit_iface
diff --git 
a/target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7622-ubnt-unifi-6-lr.dts
 
b/target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7622-ubnt-unifi-6-lr.dts
new file mode 100644
index 00..1f410b1d47
--- /dev/null
+++ 
b/target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7622-ubnt-unifi-6-lr.dts
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/dts-v1/;
+#include 
+#include 
+#include 
+
+#include "mt7622.dtsi"
+#include "mt6380.dtsi"
+
+/ {
+   model = "Ubiquiti UniFi 6 LR";
+   compatible = "ubnt,unifi-6-lr", "mediatek,mt7622";
+
+   aliases {
+   led-boot = &led_blue;
+   led-failsafe = &led_blue;
+   led-running = &led_blue;
+   led-upgrade = &led_blue;
+   label-mac-device = &gmac0;
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   bootargs = "earlycon=uart8250,mmio32,0x11002000 swiotlb=512 
console=ttyS0,115200n8";
+   };
+
+   cpus {
+   cpu@0 {
+   proc-supply = <&mt6380_vcpu_reg>;
+   sram-supply = <&mt6380_vm_reg>;
+   };
+
+   cpu@1 {
+   proc-supply = <&mt6380_vcpu_reg>;
+   sram-supply = <&mt6380_vm_reg>;
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   linux,code = ;
+   gpios = <&pio 62 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   memory {
+   reg = <0 0x4000 0 0x3f00>;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator-3p3v {
+   compat

[PATCH] mpc85xx-p1010: add Kernel 5.10 support

2021-02-16 Thread David Bauer

Tested on: Sophos RED 15W

The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the
default kernel.

When building with all kmods enabled, the resulting kernel image
exceeds the maximum size the bootloader reads from the flash.

For more information, see GitHub issue #1773

Signed-off-by: David Bauer 
---
 target/linux/mpc85xx/config-5.10  | 280 ++
 target/linux/mpc85xx/p1010/target.mk  |   2 +
 ...85xx-add-gpio-keys-to-of-match-table.patch |  10 +
 ...0-powerpc-85xx-tl-wdr4900-v1-support.patch |  83 ++
 .../101-powerpc-85xx-hiveap-330-support.patch |  30 ++
 .../102-powerpc-add-cmdline-override.patch|  37 +++
 .../103-powerpc-85xx-red-15w-rev1.patch   |  29 ++
 ...change-P2020RDB-dts-file-for-OpenWRT.patch | 162 ++
 .../105-powerpc-85xx-panda-support.patch  |  30 ++
 .../106-powerpc-85xx-ws-ap3710i-support.patch |  30 ++
 ...ootwrapper-disable-uImage-generation.patch |  42 +++
 11 files changed, 735 insertions(+)
 create mode 100644 target/linux/mpc85xx/config-5.10
 create mode 100644 
target/linux/mpc85xx/patches-5.10/001-powerpc-85xx-add-gpio-keys-to-of-match-table.patch
 create mode 100644 
target/linux/mpc85xx/patches-5.10/100-powerpc-85xx-tl-wdr4900-v1-support.patch
 create mode 100644 
target/linux/mpc85xx/patches-5.10/101-powerpc-85xx-hiveap-330-support.patch
 create mode 100644 
target/linux/mpc85xx/patches-5.10/102-powerpc-add-cmdline-override.patch
 create mode 100644 
target/linux/mpc85xx/patches-5.10/103-powerpc-85xx-red-15w-rev1.patch
 create mode 100644 
target/linux/mpc85xx/patches-5.10/104-powerpc-mpc85xx-change-P2020RDB-dts-file-for-OpenWRT.patch
 create mode 100644 
target/linux/mpc85xx/patches-5.10/105-powerpc-85xx-panda-support.patch
 create mode 100644 
target/linux/mpc85xx/patches-5.10/106-powerpc-85xx-ws-ap3710i-support.patch
 create mode 100644 
target/linux/mpc85xx/patches-5.10/900-powerpc-bootwrapper-disable-uImage-generation.patch

diff --git a/target/linux/mpc85xx/config-5.10 b/target/linux/mpc85xx/config-5.10
new file mode 100644
index 00..cb0d08ba91
--- /dev/null
+++ b/target/linux/mpc85xx/config-5.10
@@ -0,0 +1,280 @@
+# CONFIG_40x is not set
+# CONFIG_44x is not set
+# CONFIG_ADVANCED_OPTIONS is not set
+CONFIG_AR8216_PHY=y
+CONFIG_AR8216_PHY_LEDS=y
+CONFIG_ARCH_32BIT_OFF_T=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_KEEP_MEMBLOCK=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
+CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
+CONFIG_ARCH_MMAP_RND_BITS=11
+CONFIG_ARCH_MMAP_RND_BITS_MAX=17
+CONFIG_ARCH_MMAP_RND_BITS_MIN=11
+CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=17
+CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
+CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARCH_WEAK_RELEASE_ACQUIRE=y
+CONFIG_ASN1=y
+CONFIG_AUDIT_ARCH=y
+CONFIG_BLK_MQ_PCI=y
+CONFIG_BOOKE=y
+CONFIG_BOOKE_WDT=y
+# CONFIG_BSC9131_RDB is not set
+# CONFIG_BSC9132_QDS is not set
+# CONFIG_C293_PCIE is not set
+CONFIG_CLONE_BACKWARDS=y
+CONFIG_CLZ_TAB=y
+CONFIG_CMDLINE="console=ttyS0,115200"
+CONFIG_CMDLINE_FROM_BOOTLOADER=y
+# CONFIG_CMDLINE_OVERRIDE is not set
+# CONFIG_COMMON_CLK is not set
+CONFIG_COMPAT_32BIT_TIME=y
+# CONFIG_CORENET_GENERIC is not set
+# CONFIG_CPM2 is not set
+CONFIG_CPU_BIG_ENDIAN=y
+CONFIG_CRYPTO_AEAD=y
+CONFIG_CRYPTO_AEAD2=y
+# CONFIG_CRYPTO_AES_PPC_SPE is not set
+CONFIG_CRYPTO_AKCIPHER=y
+CONFIG_CRYPTO_AKCIPHER2=y
+CONFIG_CRYPTO_AUTHENC=y
+CONFIG_CRYPTO_HASH=y
+CONFIG_CRYPTO_HASH2=y
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_LIB_POLY1305_RSIZE=1
+CONFIG_CRYPTO_MANAGER=y
+CONFIG_CRYPTO_MANAGER2=y
+# CONFIG_CRYPTO_MD5_PPC is not set
+CONFIG_CRYPTO_NULL=y
+CONFIG_CRYPTO_NULL2=y
+CONFIG_CRYPTO_RNG=y
+CONFIG_CRYPTO_RNG2=y
+CONFIG_CRYPTO_RSA=y
+# CONFIG_CRYPTO_SHA1_PPC is not set
+# CONFIG_CRYPTO_SHA1_PPC_SPE is not set
+# CONFIG_CRYPTO_SHA256_PPC_SPE is not set
+CONFIG_DATA_SHIFT=12
+CONFIG_DEBUG_BUGVERBOSE=y
+CONFIG_DNOTIFY=y
+CONFIG_DTC=y
+# CONFIG_E200 is not set
+CONFIG_E500=y
+# CONFIG_E5500_CPU is not set
+# CONFIG_E6500_CPU is not set
+CONFIG_EARLY_PRINTK=y
+CONFIG_EDAC_ATOMIC_SCRUB=y
+CONFIG_EDAC_SUPPORT=y
+CONFIG_ENABLE_MUST_CHECK=y
+CONFIG_FIXED_PHY=y
+CONFIG_FSL_BOOKE=y
+CONFIG_FSL_EMB_PERFMON=y
+# CONFIG_FSL_ENETC_MDIO is not set
+# CONFIG_FSL_FMAN is not set
+CONFIG_FSL_LBC=y
+CONFIG_FSL_PCI=y
+CONFIG_FSL_PQ_MDIO=y
+CONFIG_FSL_SOC=y
+CONFIG_FSL_SOC_BOOKE=y
+CONFIG_FW_LOADER_PAGED_BUF=y
+CONFIG_GENERIC_ALLOCATOR=y
+CONFIG_GENERIC_ATOMIC64=y
+CONFIG_GENERIC_BUG=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_CPU=y
+CONFIG_GENERIC_CPU_AUTOPROBE=y
+CONFIG_GENERIC_CPU_VULNERABILITIES=y
+CONFIG_GENERIC_EARLY_IOREMAP=y
+CONFIG_GENERIC_IRQ_SHOW=y
+CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
+CONFIG_GENERIC_ISA_DMA=y
+CONFIG_GENERIC_PCI_IOMAP=y
+CONFIG_GENERIC_SMP_IDLE_THREAD=y
+CONFIG_GENERIC_STRNCPY_FROM_USER=y
+CONFIG_GENERIC_STRNLEN_USER=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GEN_RTC=y
+# CONFIG_GE_IMP3A is not set
+CONFIG_GIANFAR=y
+CONFIG

[PATCH] rockchip: add Kernel 5.10 support

2021-02-16 Thread David Bauer

Remove all upstreamed patches and add the kernel configuration for
version 5.10.

The Rock Pi 4 was split in multiple versions. Add a DTS with the old
name in order to keep compatibility while having kernel 5.4 and 5.10 in
parallel. Switch to the Rock Pi 4A DTS once Kernel 5.4 support is
removed.

Tested-on: Nanoi R2S

Signed-off-by: David Bauer 
---
 target/linux/rockchip/Makefile|   1 +
 target/linux/rockchip/armv8/config-5.10   | 673 ++
 target/linux/rockchip/armv8/config-5.4| 165 -
 target/linux/rockchip/config-default  | 297 
 .../boot/dts/rockchip/rk3399-rock-pi-4.dts|  19 +
 ...-r8152-add-LED-configuration-from-OF.patch |  74 ++
 ...et-add-RTL8152-binding-documentation.patch |  54 ++
 ...-rockchip-use-system-LED-for-OpenWrt.patch |  31 +
 ...usb3-controller-node-for-RK3328-SoCs.patch |  62 ++
 ...ckchip-enable-LAN-port-on-NanoPi-R2S.patch |  60 ++
 ...dd-OF-node-for-USB-eth-on-NanoPi-R2S.patch |  28 +
 ...-host-by-default-on-rk3399-rock-pi-4.patch |  32 +
 12 files changed, 1178 insertions(+), 318 deletions(-)
 create mode 100644 target/linux/rockchip/armv8/config-5.10
 delete mode 100644 target/linux/rockchip/config-default
 create mode 100644 
target/linux/rockchip/files-5.10/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
 create mode 100644 
target/linux/rockchip/patches-5.10/002-net-usb-r8152-add-LED-configuration-from-OF.patch
 create mode 100644 
target/linux/rockchip/patches-5.10/003-dt-bindings-net-add-RTL8152-binding-documentation.patch
 create mode 100644 
target/linux/rockchip/patches-5.10/100-rockchip-use-system-LED-for-OpenWrt.patch
 create mode 100644 
target/linux/rockchip/patches-5.10/101-dts-rockchip-add-usb3-controller-node-for-RK3328-SoCs.patch
 create mode 100644 
target/linux/rockchip/patches-5.10/102-rockchip-enable-LAN-port-on-NanoPi-R2S.patch
 create mode 100644 
target/linux/rockchip/patches-5.10/103-arm64-rockchip-add-OF-node-for-USB-eth-on-NanoPi-R2S.patch
 create mode 100644 
target/linux/rockchip/patches-5.10/104-rockchip-use-USB-host-by-default-on-rk3399-rock-pi-4.patch

diff --git a/target/linux/rockchip/Makefile b/target/linux/rockchip/Makefile
index bcc0cc3f8f..7aeb0a3d55 100644
--- a/target/linux/rockchip/Makefile
+++ b/target/linux/rockchip/Makefile
@@ -8,6 +8,7 @@ FEATURES:=ext4 audio usb usbgadget display gpio fpu rootfs-part 
boot-part squash
 SUBTARGETS:=armv8
 
 KERNEL_PATCHVER=5.4
+KERNEL_TESTING_PATCHVER=5.10
 
 define Target/Description
Build firmware image for Rockchip SoC devices.
diff --git a/target/linux/rockchip/armv8/config-5.10 
b/target/linux/rockchip/armv8/config-5.10
new file mode 100644
index 00..80230a722b
--- /dev/null
+++ b/target/linux/rockchip/armv8/config-5.10
@@ -0,0 +1,673 @@
+CONFIG_64BIT=y
+CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_KEEP_MEMBLOCK=y
+CONFIG_ARCH_MMAP_RND_BITS=18
+CONFIG_ARCH_MMAP_RND_BITS_MAX=33
+CONFIG_ARCH_MMAP_RND_BITS_MIN=18
+CONFIG_ARCH_MMAP_RND_COMPAT_BITS=11
+CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
+CONFIG_ARCH_PROC_KCORE_TEXT=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ARCH_SPARSEMEM_DEFAULT=y
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
+CONFIG_ARCH_STACKWALK=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARC_EMAC_CORE=y
+CONFIG_ARM64=y
+CONFIG_ARM64_4K_PAGES=y
+CONFIG_ARM64_CNP=y
+# CONFIG_ARM64_ERRATUM_1165522 is not set
+# CONFIG_ARM64_ERRATUM_1286807 is not set
+# CONFIG_ARM64_ERRATUM_1418040 is not set
+CONFIG_ARM64_ERRATUM_819472=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_826319=y
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_832075=y
+CONFIG_ARM64_ERRATUM_843419=y
+CONFIG_ARM64_ERRATUM_845719=y
+CONFIG_ARM64_ERRATUM_858921=y
+CONFIG_ARM64_HW_AFDBM=y
+CONFIG_ARM64_MODULE_PLTS=y
+CONFIG_ARM64_PAGE_SHIFT=12
+CONFIG_ARM64_PAN=y
+CONFIG_ARM64_PA_BITS=48
+CONFIG_ARM64_PA_BITS_48=y
+CONFIG_ARM64_PTR_AUTH=y
+CONFIG_ARM64_RAS_EXTN=y
+CONFIG_ARM64_SVE=y
+# CONFIG_ARM64_SW_TTBR0_PAN is not set
+CONFIG_ARM64_TAGGED_ADDR_ABI=y
+CONFIG_ARM64_UAO=y
+CONFIG_ARM64_VA_BITS=48
+# CONFIG_ARM64_VA_BITS_39 is not set
+CONFIG_ARM64_VA_BITS_48=y
+CONFIG_ARM64_VHE=y
+CONFIG_ARM64_WORKAROUND_CLEAN_CACHE=y
+# CONFIG_ARMV8_DEPRECATED is not set
+CONFIG_ARM_AMBA=y
+CONFIG_ARM_ARCH_TIMER=y
+CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y
+CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND=y
+CONFIG_ARM_CPUIDLE=y
+CONFIG_ARM_GIC=y
+CONFIG_ARM_GIC_V2M=y
+CONFIG_ARM_GIC_V3=y
+CONFIG_ARM_GIC_V3_ITS=y
+CONFIG_ARM_GIC_V3_ITS_PCI=y
+CONFIG_ARM_MHU=y
+CONFIG_ARM_PSCI_CPUIDLE=y
+CONFIG_ARM_PSCI_CPUIDLE_DOMAIN=y
+CONFIG_ARM_PSCI_FW=y
+# CONFIG_ARM_RK3399_DMC_DEVFREQ is not set
+# CONFIG_ARM_SCMI_PROTOCOL is not set
+CONFIG_ARM_SCPI_CPUFREQ=y
+CONFIG_ARM_SCPI_POWER_DOMAIN=y
+CONFIG_ARM_SCPI_PROTOCOL=y
+CONFIG_ARM_SMMU=y
+CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y
+# CONFIG_ARM_SMMU_LEGACY_DT_BINDINGS is not set
+CONFIG_ARM_SMMU_V3=y
+# CONFIG_ARM_SMMU_V3_SVA is not set
+CONFIG_AUDIT_ARCH_COMPAT_GENERIC=y

[PATCH] generic: don't lock when recursively deleting partitions

2021-02-16 Thread David Bauer

When recursively deleting partitions, don't acquire the masters
partition lock twice. Otherwise the process endy up in a deadlocked
state.

Signed-off-by: David Bauer 
---
 ...when-recursively-deleting-partitions.patch | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 
target/linux/generic/pending-5.10/499-mtd-don-t-lock-when-recursively-deleting-partitions.patch

diff --git 
a/target/linux/generic/pending-5.10/499-mtd-don-t-lock-when-recursively-deleting-partitions.patch
 
b/target/linux/generic/pending-5.10/499-mtd-don-t-lock-when-recursively-deleting-partitions.patch
new file mode 100644
index 00..505131b684
--- /dev/null
+++ 
b/target/linux/generic/pending-5.10/499-mtd-don-t-lock-when-recursively-deleting-partitions.patch
@@ -0,0 +1,24 @@
+From: David Bauer 
+Date: Wed, 17 Feb 2021 03:21:39 +0100
+Subject: [PATCH] mtd: don't lock when recursively deleting partitions
+
+When recursively deleting partitions, don't acquire the masters
+partition lock twice. Otherwise the process endy up in a deadlocked
+state.
+
+Signed-off-by: David Bauer 
+---
+ drivers/mtd/mtdpart.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/mtdpart.c
 b/drivers/mtd/mtdpart.c
+@@ -474,7 +474,7 @@ static int __del_mtd_partitions(struct m
+ 
+   list_for_each_entry_safe(child, next, &mtd->partitions, part.node) {
+   if (mtd_has_partitions(child))
+-  del_mtd_partitions(child);
++  __del_mtd_partitions(child);
+ 
+   pr_info("Deleting %s MTD partition\n", child->name);
+   ret = del_mtd_device(child);
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mpc85xx-p1010: add Kernel 5.10 support

2021-02-16 Thread David Bauer

Hi Daniel,

On 2/17/21 4:21 AM, Daniel Golle wrote:
> On Tue, Feb 16, 2021 at 11:48:04PM +0100, David Bauer wrote:
>> Tested on: Sophos RED 15W
>>
>> The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the
>> default kernel.
> 
> That's sad. Why?

See the next sentence ;) as well as this GitHub issue:
https://github.com/openwrt/openwrt/pull/1773

Best
David
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mpc85xx-p1010: add Kernel 5.10 support

2021-02-17 Thread David Bauer

Hi,

On 2/17/21 9:20 AM, Perry wrote:
> Hello,
> 
> I thought the kernel size issue was resolved by 
> 1e41de2f48e284c9d6658f9403365651178f6826
> 
> Also, the linked PR #1773 has a happy ending.
> 
> Is the simpleImage no longer a viable solution? Could you explain why not?

the issue was resolved for v5.4 with using a different PPC bootwrapper. However,
as the kernel grew again with v5.10, this was already back then set to break 
again in
the future, as the bootwrapper only enables a more efficient compression but 
does not by
itself read from the flash.

Best wishes
David

> 
> Greetings
> Perry 
> 
> On February 17, 2021 5:59:28 AM GMT+01:00, David Bauer  
> wrote:
>> Hi Daniel,
>>
>> On 2/17/21 4:21 AM, Daniel Golle wrote:
>>> On Tue, Feb 16, 2021 at 11:48:04PM +0100, David Bauer wrote:
>>>> Tested on: Sophos RED 15W
>>>>
>>>> The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the
>>>> default kernel.
>>>
>>> That's sad. Why?
>>
>> See the next sentence ;) as well as this GitHub issue:
>> https://github.com/openwrt/openwrt/pull/1773
>>
>> Best
>> David
>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mpc85xx-p1010: add Kernel 5.10 support

2021-02-18 Thread David Bauer

Hi,

On 2/18/21 6:16 PM, Adrian Schmutzler wrote:
> Hi,
> 
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of David Bauer
>> Sent: Dienstag, 16. Februar 2021 23:48
>> To: openwrt-devel@lists.openwrt.org
>> Subject: [PATCH] mpc85xx-p1010: add Kernel 5.10 support
> 
> no offense, but I wonder whether bumping by subtargets is really the way to 
> go here?

I'd rater bump a subtarget for which i at least know a board boots with the 
patches
than bump the complete target and break 2/3 subtargets in the process.

Best wishes
David

> 
> Best
> 
> Adrian
> 
>>
>> Tested on: Sophos RED 15W
>>
>> The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the
>> default kernel.
>>
>> When building with all kmods enabled, the resulting kernel image exceeds
>> the maximum size the bootloader reads from the flash.
>>
>> For more information, see GitHub issue #1773
>>
>> Signed-off-by: David Bauer 
>> ---
>>  target/linux/mpc85xx/config-5.10  | 280 ++
>>  target/linux/mpc85xx/p1010/target.mk  |   2 +
>>  ...85xx-add-gpio-keys-to-of-match-table.patch |  10 +  ...0-powerpc-85xx-tl-
>> wdr4900-v1-support.patch |  83 ++  .../101-powerpc-85xx-hiveap-330-
>> support.patch |  30 ++
>>  .../102-powerpc-add-cmdline-override.patch|  37 +++
>>  .../103-powerpc-85xx-red-15w-rev1.patch   |  29 ++
>>  ...change-P2020RDB-dts-file-for-OpenWRT.patch | 162 ++
>>  .../105-powerpc-85xx-panda-support.patch  |  30 ++
>>  .../106-powerpc-85xx-ws-ap3710i-support.patch |  30 ++  ...ootwrapper-
>> disable-uImage-generation.patch |  42 +++
>>  11 files changed, 735 insertions(+)
>>  create mode 100644 target/linux/mpc85xx/config-5.10  create mode 100644
>> target/linux/mpc85xx/patches-5.10/001-powerpc-85xx-add-gpio-keys-to-of-
>> match-table.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/100-powerpc-85xx-
>> tl-wdr4900-v1-support.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/101-powerpc-85xx-
>> hiveap-330-support.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/102-powerpc-add-
>> cmdline-override.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/103-powerpc-85xx-
>> red-15w-rev1.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/104-powerpc-
>> mpc85xx-change-P2020RDB-dts-file-for-OpenWRT.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/105-powerpc-85xx-
>> panda-support.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/106-powerpc-85xx-
>> ws-ap3710i-support.patch
>>  create mode 100644 target/linux/mpc85xx/patches-5.10/900-powerpc-
>> bootwrapper-disable-uImage-generation.patch
>>
>> diff --git a/target/linux/mpc85xx/config-5.10 b/target/linux/mpc85xx/config-
>> 5.10
>> new file mode 100644
>> index 00..cb0d08ba91
>> --- /dev/null
>> +++ b/target/linux/mpc85xx/config-5.10
>> @@ -0,0 +1,280 @@
>> +# CONFIG_40x is not set
>> +# CONFIG_44x is not set
>> +# CONFIG_ADVANCED_OPTIONS is not set
>> +CONFIG_AR8216_PHY=y
>> +CONFIG_AR8216_PHY_LEDS=y
>> +CONFIG_ARCH_32BIT_OFF_T=y
>> +CONFIG_ARCH_HIBERNATION_POSSIBLE=y
>> +CONFIG_ARCH_KEEP_MEMBLOCK=y
>> +CONFIG_ARCH_MAY_HAVE_PC_FDC=y
>> +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
>> +CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
>> +CONFIG_ARCH_MMAP_RND_BITS=11
>> +CONFIG_ARCH_MMAP_RND_BITS_MAX=17
>> +CONFIG_ARCH_MMAP_RND_BITS_MIN=11
>> +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=17
>> +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
>> +CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
>> +CONFIG_ARCH_SUSPEND_POSSIBLE=y
>> +CONFIG_ARCH_WEAK_RELEASE_ACQUIRE=y
>> +CONFIG_ASN1=y
>> +CONFIG_AUDIT_ARCH=y
>> +CONFIG_BLK_MQ_PCI=y
>> +CONFIG_BOOKE=y
>> +CONFIG_BOOKE_WDT=y
>> +# CONFIG_BSC9131_RDB is not set
>> +# CONFIG_BSC9132_QDS is not set
>> +# CONFIG_C293_PCIE is not set
>> +CONFIG_CLONE_BACKWARDS=y
>> +CONFIG_CLZ_TAB=y
>> +CONFIG_CMDLINE="console=ttyS0,115200"
>> +CONFIG_CMDLINE_FROM_BOOTLOADER=y
>> +# CONFIG_CMDLINE_OVERRIDE is not set
>> +# CONFIG_COMMON_CLK is not set
>> +CONFIG_COMPAT_32BIT_TIME=y
>> +# CONFIG_CORENET_GENERIC is not set
>> +# CONFIG_CPM2 is not set
>> +CONFIG_CPU_BIG_ENDIAN=y
>> +CONFIG_CRYPTO_AEAD=y
>> +CONFIG_CRYPTO_AEAD2=y
>> +# CONFIG_CRYPTO_AES_PPC_SPE is not set
>> +CONFIG_CRYPTO_AKCIPHER=y
>> +CONFIG_CRYPTO_AKCIPHER2=y
>> +CONFIG_CRYPT

[PATCH] openssl: update package sources

2021-02-18 Thread David Bauer

OpenSSL downloads itself are distributed using Akamai CDN, so use these
sources as the highest priority.

Remove a stale mirror which seems to be offline for a longer time
already.

Add fallbacks to the old release path also for the mirrors.

Signed-off-by: David Bauer 
---
 package/libs/openssl/Makefile | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
index 4fb4cb2784..7dbbd65026 100644
--- a/package/libs/openssl/Makefile
+++ b/package/libs/openssl/Makefile
@@ -19,11 +19,13 @@ PKG_BUILD_PARALLEL:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:= \
+   http://www.openssl.org/source/ \
+   http://www.openssl.org/source/old/$(PKG_BASE)/ \
http://ftp.fi.muni.cz/pub/openssl/source/ \
-   http://ftp.linux.hr/pub/openssl/source/ \
+   http://ftp.fi.muni.cz/pub/openssl/source/old/$(PKG_BASE)/ \
ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/ \
-   http://www.openssl.org/source/ \
-   http://www.openssl.org/source/old/$(PKG_BASE)/
+   ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/old/$(PKG_BASE)/
+
 PKG_HASH:=aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf
 
 PKG_LICENSE:=OpenSSL
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] include: use cpio from staging dir

2021-02-27 Thread David Bauer

As we built our own CPIO now, use this version instead of whatever the
host may or may not provide.

Signed-off-by: David Bauer 
---
 include/image.mk   | 2 +-
 include/kernel-defaults.mk | 2 +-
 include/unpack.mk  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/image.mk b/include/image.mk
index 48911e4057..7f0d27b746 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -301,7 +301,7 @@ endif
 
 ifdef CONFIG_TARGET_ROOTFS_CPIOGZ
   define Image/Build/cpiogz
-   ( cd $(TARGET_DIR); find . | cpio -o -H newc -R root:root | gzip -9n 
>$(BIN_DIR)/$(IMG_ROOTFS).cpio.gz )
+   ( cd $(TARGET_DIR); find . | $(STAGING_DIR_HOST)/bin/cpio -o -H newc -R 
root:root | gzip -9n >$(BIN_DIR)/$(IMG_ROOTFS).cpio.gz )
   endef
 endif
 
diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 4b39296f8c..c246857cd3 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -163,7 +163,7 @@ ifeq ($(CONFIG_TARGET_ROOTFS_INITRAMFS_SEPERATE),y)
 ifeq ($(CONFIG_EXTERNAL_CPIO),y)
$(CP) $(CONFIG_EXTERNAL_CPIO) $(KERNEL_BUILD_DIR)/initrd.cpio
 else
-   ( cd $(TARGET_DIR); find . | cpio -o -H newc -R root:root > 
$(KERNEL_BUILD_DIR)/initrd.cpio )
+   ( cd $(TARGET_DIR); find . | $(STAGING_DIR_HOST)/bin/cpio -o -H newc -R 
root:root > $(KERNEL_BUILD_DIR)/initrd.cpio )
 endif
$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_BZIP2),bzip2 -9 -c < 
$(KERNEL_BUILD_DIR)/initrd.cpio > $(KERNEL_BUILD_DIR)/initrd.cpio.bzip2)
$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_GZIP),gzip -f -S .gzip -9n 
$(KERNEL_BUILD_DIR)/initrd.cpio)
diff --git a/include/unpack.mk b/include/unpack.mk
index 6a56b8e742..ebece69978 100644
--- a/include/unpack.mk
+++ b/include/unpack.mk
@@ -40,7 +40,7 @@ ifeq ($(strip $(UNPACK_CMD)),)
   UNPACK_CMD=$(DECOMPRESS_CMD) $(TAR_CMD)
 endif
 ifeq ($(EXT),cpio)
-  UNPACK_CMD=$(DECOMPRESS_CMD) (cd $(1)/..; cpio -i -d)
+  UNPACK_CMD=$(DECOMPRESS_CMD) (cd $(1)/..; $(STAGING_DIR_HOST)/bin/cpio 
-i -d)
 endif
 ifeq ($(EXT),zip)
   UNPACK_CMD=$(UNZIP_CMD)
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] tools: add cpio

2021-02-27 Thread David Bauer

meditak-mt7622 as well as mediatek-mt7623 require CPIO to create their
initramfs images. So build CPIO as part of the host toolchain.

Signed-off-by: David Bauer 
---
 tools/Makefile|  2 +-
 tools/cpio/Makefile   | 14 +
 .../patches/001-duplicate-program-name.patch  | 20 +++
 3 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 tools/cpio/Makefile
 create mode 100644 tools/cpio/patches/001-duplicate-program-name.patch

diff --git a/tools/Makefile b/tools/Makefile
index a2665dbc9a..65e0493e14 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -21,7 +21,7 @@ ifneq 
($(CONFIG_SDK)$(CONFIG_PACKAGE_kmod-b43)$(CONFIG_PACKAGE_b43legacy-firmwar
   BUILD_B43_TOOLS = y
 endif
 
-tools-y += autoconf autoconf-archive automake bc bison cmake dosfstools
+tools-y += autoconf autoconf-archive automake bc bison cmake cpio dosfstools
 tools-y += e2fsprogs fakeroot findutils firmware-utils flex gengetopt
 tools-y += libressl libtool lzma m4 make-ext4fs missing-macros mkimage
 tools-y += mklibs mm-macros mtd-utils mtools padjffs2 patch-image
diff --git a/tools/cpio/Makefile b/tools/cpio/Makefile
new file mode 100644
index 00..2852209847
--- /dev/null
+++ b/tools/cpio/Makefile
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=cpio
+PKG_CPE_ID:=cpe:/a:gnu:cpio
+PKG_VERSION:=2.13
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
+PKG_SOURCE_URL:=@GNU/cpio
+PKG_HASH:=eab5bdc5ae1df285c59f2a4f140a98fc33678a0bf61bdba67d9436ae26b46f6d
+
+include $(INCLUDE_DIR)/host-build.mk
+
+$(eval $(call HostBuild))
diff --git a/tools/cpio/patches/001-duplicate-program-name.patch 
b/tools/cpio/patches/001-duplicate-program-name.patch
new file mode 100644
index 00..57ff4c3cad
--- /dev/null
+++ b/tools/cpio/patches/001-duplicate-program-name.patch
@@ -0,0 +1,20 @@
+author Sergey Poznyakoff 
+
+https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=641d3f489cf6238bb916368d4ba0d9325a235afb
+
+* src/global.c: Remove superfluous declaration of program_name
+
+diff --git a/src/global.c b/src/global.c
+index fb3abe9..acf92bc 100644
+--- a/src/global.c
 b/src/global.c
+@@ -184,9 +184,6 @@ unsigned int warn_option = 0;
+ /* Extract to standard output? */
+ bool to_stdout_option = false;
+ 
+-/* The name this program was run with.  */
+-char *program_name;
+-
+ /* A pointer to either lstat or stat, depending on whether
+dereferencing of symlinks is done for input files.  */
+ int (*xstat) ();
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] generic: enable netlink ethtool interface

2021-03-04 Thread David Bauer

The virtual cable tester depends on the netlink interface for ethtool.
Thus, enable it in the generic kernel configuration.

Signed-off-by: David Bauer 
---
 target/linux/generic/config-5.10 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10
index 0fd3e0f5a8..a51605592d 100644
--- a/target/linux/generic/config-5.10
+++ b/target/linux/generic/config-5.10
@@ -1715,7 +1715,7 @@ CONFIG_EPOLL=y
 # CONFIG_ET131X is not set
 CONFIG_ETHERNET=y
 # CONFIG_ETHOC is not set
-# CONFIG_ETHTOOL_NETLINK is not set
+CONFIG_ETHTOOL_NETLINK=y
 CONFIG_EVENTFD=y
 # CONFIG_EVM is not set
 # CONFIG_EXFAT_FS is not set
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] ethtool: add netlink build variant

2021-03-04 Thread David Bauer

Netlink support is required for using the virtual cable tester
functionality. Thus, add a build variant with enabled netlink
support.

Signed-off-by: David Bauer 
---
 package/network/utils/ethtool/Makefile | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/package/network/utils/ethtool/Makefile 
b/package/network/utils/ethtool/Makefile
index 3efc90490b..ab068b9c20 100644
--- a/package/network/utils/ethtool/Makefile
+++ b/package/network/utils/ethtool/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ethtool
 PKG_VERSION:=5.10
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_MAINTAINER:=Felix Fietkau 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
@@ -34,28 +34,46 @@ define Package/ethtool
   URL:=http://www.kernel.org/pub/software/network/ethtool/
 endef
 
+define Package/ethtool-netlink
+  $(Package/ethtool)
+  TITLE += (netlink support)
+  VARIANT:=netlink
+  PROVIDES:=ethtool
+  CONFLICTS:=ethtool
+  DEPENDS:=+libmnl
+endef
+
 define Package/ethtool/description
  ethtool is a small utility for examining and tuning your ethernet-based
  network interface
 endef
 
+Package/ethtool-netlink/description:=$(Package/ethtool/description)
+
 define Package/ethtool/config
config ETHTOOL_PRETTY_DUMP
-   depends on PACKAGE_ethtool
+   depends on PACKAGE_ethtool || PACKAGE_ethtool-netlink
bool "Enable pretty printing"
 endef
 
-CONFIGURE_ARGS += --disable-netlink
-
 ifeq ($(CONFIG_ETHTOOL_PRETTY_DUMP),y)
 CONFIGURE_ARGS += --enable-pretty-dump
 else
 CONFIGURE_ARGS += --disable-pretty-dump
 endif
 
+ifeq ($(BUILD_VARIANT),netlink)
+CONFIGURE_ARGS += --enable-netlink
+else
+CONFIGURE_ARGS += --disable-netlink
+endif
+
 define Package/ethtool/install
$(INSTALL_DIR) $(1)/usr/sbin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/ethtool $(1)/usr/sbin
 endef
 
+Package/ethtool-netlink/install=$(Package/ethtool/install)
+
 $(eval $(call BuildPackage,ethtool))
+$(eval $(call BuildPackage,ethtool-netlink))
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 2/2] generic: enable netlink ethtool interface

2021-03-05 Thread David Bauer




On 3/5/21 12:57 AM, Paul Spooren wrote:
> What's the size change?

48 kiB

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ath79: drop cs-gpios property

2021-04-15 Thread David Bauer

The spi-ath79 driver performs the chipselect by writing to dedicated
register in the SPI register block. So the GPIO numbers were not used.

Tested-on: Enterasys WS-AP3705i

Signed-off-by: David Bauer 
---
 target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi| 1 -
 target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi  | 2 --
 target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts | 2 --
 target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts  | 2 --
 4 files changed, 7 deletions(-)

diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi 
b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi
index 109ed0caf3..b8176dc059 100644
--- a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi
+++ b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi
@@ -219,7 +219,6 @@
 &spi {
status = "okay";
 
-   cs-gpios = <0>, <0>;
 
flash0: flash@0 {
compatible = "jedec,spi-nor";
diff --git a/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi 
b/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
index 98f6759eac..df28111598 100644
--- a/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
+++ b/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
@@ -107,8 +107,6 @@
 &spi {
status = "okay";
 
-   cs-gpios = <0>, <0>;
-
flash0: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
diff --git a/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts 
b/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
index 7cb051a475..111d06491e 100644
--- a/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
+++ b/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
@@ -163,8 +163,6 @@
 &spi {
status = "okay";
 
-   cs-gpios = <0>, <0>;
-
flash0: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
diff --git a/target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts 
b/target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts
index 52becec18b..8f8276255a 100644
--- a/target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts
+++ b/target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts
@@ -114,8 +114,6 @@
 &spi {
status = "okay";
 
-   cs-gpios = <0>, <0>;
-
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
-- 
2.31.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ath79: drop cs-gpios property

2021-04-16 Thread David Bauer

Hi,

On 4/16/21 4:12 AM, Chuanhong Guo wrote:
> Hi!
> 
> On Fri, Apr 16, 2021 at 4:43 AM David Bauer  wrote:
>>
>> The spi-ath79 driver performs the chipselect by writing to dedicated
>> register in the SPI register block. So the GPIO numbers were not used.
> 
> This is cs-gpios is a hack to override incorrect num_chipselects in spi-ath79
> driver (which is set to fixed 1). spi-ath79 should be patched to fix
> this problem
> before cs-gpios for ar7161/ar7242 devices can be dropped.

Thanks for the hint, i missed ar93xx uses the newer SPI driver.

Looking at spi-ath79, the number of CS lines can be modified using platform
data, however all datasheets from ar71xx up to qca956x i could get my hand on
list 3 chipselect lines available - so a patch which sets the CS count to 3
should be sufficient?

I have some other SPI patches waiting to be sent upstream, so I can take care
of that.

Best wishes
David

> It's not needed on ar9344 because the new spi-ar934x driver doesn't have
> this problem.
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 3/3] ipq40xx: add support for FritzBox 7530

2019-02-27 Thread David Bauer

Hello Christian,

On 26.02.19 23:17, Christian Lamparter wrote:
> Hello David,
> 
> On Tuesday, February 26, 2019 12:15:41 AM CET David Bauer wrote:
>> On 25.02.19 23:10, Christian Lamparter wrote:
>>> On Wednesday, February 20, 2019 6:02:21 PM CET Christian Lamparter wrote:
>>>> On Monday, February 18, 2019 11:58:34 PM CET David Bauer wrote:
>>>>> diff --git 
>>>>> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
>>>>>  
>>>>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
>>>>> new file mode 100644
>>>>> index 00..b2a33468bb
>>>>> --- /dev/null
>>>>> +++ 
>>>>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
>>>>> @@ -0,0 +1,305 @@
>>>>> +&pcie0 {
>>>>> + status = "okay";
>>>>> +
>>>>> + ranges = <0x8100 0 0x4020 0x4020
>>>>> + 0 0x0010   /* downstream I/O */
>>>>> + 0x8200 0 0x4800 0x4800
>>>>> + 0 0x1000>; /* non-prefetchable memory */
>>>>
>>>> Let me dig out my MR33 (will have to wait until the Weekend) and see if 
>>>> this
>>>> should be put into the qcom-ipq4019.dtsi as well.
>>>
>>> And it didn't work. While the pcie enumeration worked fine. 
>>> The QCA9887 was no longer attaching. As soon as the driver was
>>> loaded it failed due to:
>>>
>>> [8.888466] ath10k_pci :01:00.0: enabling device (0140 -> 0142)
>>> [8.934145] ath10k_pci :01:00.0: failed to wake up device : -110
>>> [8.935258] ath10k: failed to probe PCI : -110, retry-count: 0
>>> [8.949596] ath10k 4.19 driver, optimized for CT firmware, probing pci 
>>> device: 0x50.
>>> [8.989503] ath10k_pci :01:00.0: failed to wake up device : -110
>>> [8.989899] ath10k: failed to probe PCI : -110, retry-count: 1
>>> [9.005086] ath10k 4.19 driver, optimized for CT firmware, probing pci 
>>> device: 0x50.
>>> [9.046821] ath10k_pci :01:00.0: failed to wake up device : -110
>>> [9.049851] ath10k: failed to probe PCI : -110, retry-count: 2
>>> [9.062448] ath10k 4.19 driver, optimized for CT firmware, probing pci 
>>> device: 0x50.
>>> [9.099055] ath10k_pci :01:00.0: failed to wake up device : -110
>>> [9.099442] ath10k: failed to probe PCI : -110, retry-count: 3
>>> [...]
>>> [9.489869] ath10k: failed to probe PCI : -110, retry-count: 10
>>> [9.503780] ath10k_pci: probe of :01:00.0 failed with error -110
>>> [...]
>>>
>>> But I think we can fix the problem. Because according to the old
>>> qcom-ipq40xx.dtsi I dug up:
>>>
>>> <https://github.com/gl-inet/openwrt-imagebuilder-ipq806x/blob/master/build_dir/target-arm_cortex-a7_uClibc-1.0.14_eabi/linux-ipq806x/linux-3.14.77/arch/arm/boot/dts/qcom-ipq40xx.dtsi#L631>
>>>
>>> The non-prefetchable memory area window size should be 0x00d0.
>>>
>>> ranges =<0x8100 0 0x4020 0x4020 0 0x0010>, /* 
>>> downstream I/O */
>>> <0x8200 0 0x4030 0x4030 0 
>>> 0x00d0>; /* non-prefetchable memory */
>>>
>>> (yes, I'll be preparing a patch for linux-msm-arm. Can you please let
>>> me know if does indeed finally let you enumerate the device?)
>>
>> It seems to work with your proposed change:
>>
>> [0.042117] OF: PCI: host bridge /soc/pci@4000 ranges:
>> [0.042152] OF: PCI:IO 0x4020..0x402f -> 0x4020
>> [0.042171] OF: PCI:   MEM 0x4030..0x40ff -> 0x4030
>> [0.259505] qcom-pcie 4000.pci: link up
>> [0.259649] qcom-pcie 4000.pci: PCI host bridge to bus :00
>> [0.259671] pci_bus :00: root bus resource [bus 00-ff]
>> [0.259687] pci_bus :00: root bus resource [io  0x-0xf]
>> (bus address [0x4020-0x402f])
>> [0.259700] pci_bus :00: root bus resource [mem
>> 0x4030-0x40ff]
>> [0.259742] pci :00:00.0: [17cb:1001] type 01 class 0x060400
>> [0.259776] pci :00:00.0: reg 0x10: [mem 0x-0x0fff 64bit]
>> [0.259829] pci :00:00.0: PME# supported from D0 D3hot
>> [0.260015] PCI: bus0: Fast back to back transfers dis

Re: [OpenWrt-Devel] [PATCH v2 3/3] ipq40xx: add support for FritzBox 7530

2019-02-27 Thread David Bauer


Hello Christian,

On 27.02.19 13:03, David Bauer wrote:

Hello Christian,

On 26.02.19 23:17, Christian Lamparter wrote:

Hello David,

On Tuesday, February 26, 2019 12:15:41 AM CET David Bauer wrote:

On 25.02.19 23:10, Christian Lamparter wrote:

On Wednesday, February 20, 2019 6:02:21 PM CET Christian Lamparter wrote:

On Monday, February 18, 2019 11:58:34 PM CET David Bauer wrote:

diff --git 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
new file mode 100644
index 00..b2a33468bb
--- /dev/null
+++ 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
@@ -0,0 +1,305 @@
+&pcie0 {
+   status = "okay";
+
+   ranges = <0x8100 0 0x4020 0x4020
+   0 0x0010   /* downstream I/O */
+   0x8200 0 0x4800 0x4800
+   0 0x1000>; /* non-prefetchable memory */


Let me dig out my MR33 (will have to wait until the Weekend) and see if this
should be put into the qcom-ipq4019.dtsi as well.


And it didn't work. While the pcie enumeration worked fine.
The QCA9887 was no longer attaching. As soon as the driver was
loaded it failed due to:

[8.888466] ath10k_pci :01:00.0: enabling device (0140 -> 0142)
[8.934145] ath10k_pci :01:00.0: failed to wake up device : -110
[8.935258] ath10k: failed to probe PCI : -110, retry-count: 0
[8.949596] ath10k 4.19 driver, optimized for CT firmware, probing pci 
device: 0x50.
[8.989503] ath10k_pci :01:00.0: failed to wake up device : -110
[8.989899] ath10k: failed to probe PCI : -110, retry-count: 1
[9.005086] ath10k 4.19 driver, optimized for CT firmware, probing pci 
device: 0x50.
[9.046821] ath10k_pci :01:00.0: failed to wake up device : -110
[9.049851] ath10k: failed to probe PCI : -110, retry-count: 2
[9.062448] ath10k 4.19 driver, optimized for CT firmware, probing pci 
device: 0x50.
[9.099055] ath10k_pci :01:00.0: failed to wake up device : -110
[9.099442] ath10k: failed to probe PCI : -110, retry-count: 3
[...]
[9.489869] ath10k: failed to probe PCI : -110, retry-count: 10
[9.503780] ath10k_pci: probe of :01:00.0 failed with error -110
[...]

But I think we can fix the problem. Because according to the old
qcom-ipq40xx.dtsi I dug up:

<https://github.com/gl-inet/openwrt-imagebuilder-ipq806x/blob/master/build_dir/target-arm_cortex-a7_uClibc-1.0.14_eabi/linux-ipq806x/linux-3.14.77/arch/arm/boot/dts/qcom-ipq40xx.dtsi#L631>

The non-prefetchable memory area window size should be 0x00d0.

ranges =<0x8100 0 0x4020 0x4020 0 0x0010>, /* 
downstream I/O */
<0x8200 0 0x4030 0x4030 0 
0x00d0>; /* non-prefetchable memory */

(yes, I'll be preparing a patch for linux-msm-arm. Can you please let
me know if does indeed finally let you enumerate the device?)


It seems to work with your proposed change:

[0.042117] OF: PCI: host bridge /soc/pci@4000 ranges:
[0.042152] OF: PCI:IO 0x4020..0x402f -> 0x4020
[0.042171] OF: PCI:   MEM 0x4030..0x40ff -> 0x4030
[0.259505] qcom-pcie 4000.pci: link up
[0.259649] qcom-pcie 4000.pci: PCI host bridge to bus :00
[0.259671] pci_bus :00: root bus resource [bus 00-ff]
[0.259687] pci_bus :00: root bus resource [io  0x-0xf]
(bus address [0x4020-0x402f])
[0.259700] pci_bus :00: root bus resource [mem
0x4030-0x40ff]
[0.259742] pci :00:00.0: [17cb:1001] type 01 class 0x060400
[0.259776] pci :00:00.0: reg 0x10: [mem 0x-0x0fff 64bit]
[0.259829] pci :00:00.0: PME# supported from D0 D3hot
[0.260015] PCI: bus0: Fast back to back transfers disabled
[0.260195] pci :01:00.0: [8086:09a9] type 00 class 0x028000
[0.260312] pci :01:00.0: reg 0x10: [mem 0x-0x007f]
[0.260790] pci :01:00.0: supports D1 D2
[0.260797] pci :01:00.0: PME# supported from D0 D1 D3hot D3cold
[0.261043] PCI: bus1: Fast back to back transfers disabled
[0.261095] pci :00:00.0: BAR 8: assigned [mem 0x4080-0x40ff]
[0.261112] pci :00:00.0: BAR 0: assigned [mem
0x4030-0x40300fff 64bit]
[0.261136] pci :01:00.0: BAR 0: assigned [mem 0x4080-0x40ff]
[0.261164] pci :00:00.0: PCI bridge to [bus 01-ff]
[0.261180] pci :00:00.0:   bridge window [mem 0x4080-0x40ff]
[0.261891] pcieport :00:00.0: AER enabled with IRQ 93

See
https://github.com/blocktrron/openwrt/commit/cc1a94b2e1616d33698852df38ae23f72f193b74

How should we proceed on this device? Should i resend a v3 or will you
remove the ranges property and backport the patch you prepare for upstream?


Sorry for the late repl

[OpenWrt-Devel] [PATCH] ath10k-ct: limit available channels via DT

2019-03-04 Thread David Bauer

This backports upstream commit

34d5629 ath10k: limit available channels via DT ieee80211-freq-limit

to the 4.19 ath10k-ct version. Without this patch, disabled channels
are still listed as a supported configuration for the radio.

The identical patch was also backported by OpenWRT to the non-ct driver.
It can be dropped as soon as we switch to an ath10k-ct version based on
4.20 or higher.

Signed-off-by: David Bauer 
---
 ...ilable-channels-via-DT-ieee80211-fre.patch | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100644 
package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch

diff --git 
a/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch
 
b/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch
new file mode 100644
index 00..de4f98549a
--- /dev/null
+++ 
b/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch
@@ -0,0 +1,39 @@
+From bbf0a8af2261bc7ae39b227ff6a1e9f45a008c27 Mon Sep 17 00:00:00 2001
+From: Sven Eckelmann 
+Date: Mon, 30 Jul 2018 17:31:41 +0200
+Subject: [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit
+
+Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in
+the RX and TX path. These filtered channel can in theory still be used by
+the hardware but the signal strength is reduced so much that it makes no
+sense.
+
+There is already a DT property to limit the available channels but ath10k
+has to manually call this functionality to limit the currrently set wiphy
+channels further.
+
+Signed-off-by: Sven Eckelmann 
+
+Forwarded: https://patchwork.kernel.org/patch/10549245/
+---
+ drivers/net/wireless/ath/ath10k/mac.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/ath10k-4.19/mac.c
 b/ath10k-4.19/mac.c
+@@ -18,6 +18,7 @@
+ 
+ #include "mac.h"
+ 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -8390,6 +8391,7 @@ int ath10k_mac_register(struct ath10k *a
+   ar->hw->wiphy->bands[NL80211_BAND_5GHZ] = band;
+   }
+ 
++  wiphy_read_of_freq_limits(ar->hw->wiphy);
+   ath10k_mac_setup_ht_vht_cap(ar);
+ 
+   ar->hw->wiphy->interface_modes =
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath10k-ct: limit available channels via DT

2019-03-05 Thread David Bauer

Hello Ben,

On 04.03.19 18:49, Ben Greear wrote:
> I've stopped any serious development on my 4.19 kernel, and am mostly
> using 4.20 now.  So, might be worth moving OpenWRT ath10k-ct to use the
> 4.20
> kernel if it is not already doing so?

I thought about the same - as OpenWRT 19.x is set to be branched rather
soon (to my knowledge) i was more comfortable adding that one patch
instead of switching the whole driver version.

But someone who is more familiar should make the decision here. IMHO.
either the version bump or the patch should be included in the next
stable release.

Best wishes
David

> 
> Thanks,
> Ben
> 
> On 3/4/19 9:03 AM, David Bauer wrote:
>> This backports upstream commit
>>
>> 34d5629 ath10k: limit available channels via DT ieee80211-freq-limit
>>
>> to the 4.19 ath10k-ct version. Without this patch, disabled channels
>> are still listed as a supported configuration for the radio.
>>
>> The identical patch was also backported by OpenWRT to the non-ct driver.
>> It can be dropped as soon as we switch to an ath10k-ct version based on
>> 4.20 or higher.
>>
>> Signed-off-by: David Bauer 
>> ---
>>   ...ilable-channels-via-DT-ieee80211-fre.patch | 39 +++
>>   1 file changed, 39 insertions(+)
>>   create mode 100644
>> package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch
>>
>>
>> diff --git
>> a/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch
>> b/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch
>>
>> new file mode 100644
>> index 00..de4f98549a
>> --- /dev/null
>> +++
>> b/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch
>>
>> @@ -0,0 +1,39 @@
>> +From bbf0a8af2261bc7ae39b227ff6a1e9f45a008c27 Mon Sep 17 00:00:00 2001
>> +From: Sven Eckelmann 
>> +Date: Mon, 30 Jul 2018 17:31:41 +0200
>> +Subject: [PATCH] ath10k: Limit available channels via DT
>> ieee80211-freq-limit
>> +
>> +Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special
>> filters in
>> +the RX and TX path. These filtered channel can in theory still be
>> used by
>> +the hardware but the signal strength is reduced so much that it makes no
>> +sense.
>> +
>> +There is already a DT property to limit the available channels but
>> ath10k
>> +has to manually call this functionality to limit the currrently set
>> wiphy
>> +channels further.
>> +
>> +Signed-off-by: Sven Eckelmann 
>> +
>> +Forwarded: https://patchwork.kernel.org/patch/10549245/
>> +---
>> + drivers/net/wireless/ath/ath10k/mac.c | 2 ++
>> + 1 file changed, 2 insertions(+)
>> +
>> +--- a/ath10k-4.19/mac.c
>>  b/ath10k-4.19/mac.c
>> +@@ -18,6 +18,7 @@
>> +
>> + #include "mac.h"
>> +
>> ++#include 
>> + #include 
>> + #include 
>> + #include 
>> +@@ -8390,6 +8391,7 @@ int ath10k_mac_register(struct ath10k *a
>> + ar->hw->wiphy->bands[NL80211_BAND_5GHZ] = band;
>> + }
>> +
>> ++    wiphy_read_of_freq_limits(ar->hw->wiphy);
>> + ath10k_mac_setup_ht_vht_cap(ar);
>> +
>> + ar->hw->wiphy->interface_modes =
>>
> 
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-05 Thread David Bauer

Hardware

CPU:   Qualcomm IPQ4019
RAM:   256M
FLASH: 128M NAND
ETH:   Qualcomm QCA8072
WiFi2: IPQ4019 2T2R 2SS b/g/n
WiFi5: IPQ4019 2T2R 2SS n/ac
WiFi5: QCA9984 4T4R 4SS n/ac
LED:- Connect green/blue/red
- Power green
BTN:   WPS/Connect
UART:  115200n8 3.3V
   VCC - RX - TX - GND (Square is VCC)

Installation

1. Grab the uboot for the Device from the 'u-boot-fritz3000'
   subdirectory. Place it in the same directory as the 'eva_ramboot.py'
   script. It is located in the 'scripts/flashing' subdirectory of the
   OpenWRT tree.

2. Assign yourself the IP address 192.168.178.10/24. Connect your
   Computer to one of the boxes LAN ports.

3. Connect Power to the Box. As soon as the LAN port of your computer
   shows link, load the U-Boot to the box using following command.

   > ./eva_ramboot.py --offset 0x8500 192.168.178.1 uboot-fritz3000.bin

4. The U-Boot will now start. Now assign yourself the IP address
   192.168.1.70/24. Copy the OpenWRT initramfs (!) image to a TFTP
   server root directory and rename it to 'FRITZ3000.bin'.

5. The Box will now boot OpenWRT from RAM. This can take up to two
   minutes.

6. Copy the U-Boot and the OpenWRT sysupgrade (!) image to the Box using
   scp. SSH into the Box and first write the Bootloader to both previous
   kernel partitions.

   > mtd write /path/to/uboot-fritz3000.bin uboot0
   > mtd write /path/to/uboot-fritz3000.bin uboot1

7. Remove the AVM filesystem partitions to make room for our kernel +
   rootfs + overlayfs.

   > ubirmvol /dev/ubi0 --name=avm_filesys_0
   > ubirmvol /dev/ubi0 --name=avm_filesys_1

8. Flash OpenWRT peristently using sysupgrade.

   > sysupgrade -n /path/to/openwrt-sysupgrade.bin

Signed-off-by: David Bauer 
---
 package/boot/uboot-fritz4040/Makefile |   7 +-
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  10 +-
 .../base-files/lib/upgrade/platform.sh|   1 +
 .../dts/qcom-ipq4019-fritzrepeater-3000.dts   | 261 +
 .../dts/qcom-ipq4019-fritzrepeater-3000.dts   | 265 ++
 target/linux/ipq40xx/image/Makefile   |   9 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 9 files changed, 555 insertions(+), 5 deletions(-)
 create mode 100644 
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts

diff --git a/package/boot/uboot-fritz4040/Makefile 
b/package/boot/uboot-fritz4040/Makefile
index 3182842c89..015ca1deb9 100644
--- a/package/boot/uboot-fritz4040/Makefile
+++ b/package/boot/uboot-fritz4040/Makefile
@@ -25,6 +25,11 @@ define U-Boot/Default
   UBOOT_IMAGE:=uboot-$(1).bin
 endef
 
+define U-Boot/fritz3000
+  NAME:=FritzRepeater 3000
+  BUILD_DEVICES:=avm_fritzrepeater-3000
+endef
+
 define U-Boot/fritz4040
   NAME:=FritzBox 4040
   BUILD_DEVICES:=avm_fritzbox-4040
@@ -61,6 +66,6 @@ define Package/u-boot/install
$(INSTALL_BIN) $(PKG_BUILD_DIR)/upload-to-f4040.sh $(1)/
 endef
 
-UBOOT_TARGETS := fritz4040 fritz7530
+UBOOT_TARGETS := fritz3000 fritz4040 fritz7530
 
 $(eval $(call BuildPackage/U-Boot))
diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network 
b/target/linux/ipq40xx/base-files/etc/board.d/02_network
index 9c232d49f7..5f1f87974a 100755
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -37,6 +37,7 @@ ipq40xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0u@eth0" "1:lan" "2:lan" "3:lan" "4:lan"
;;
+   avm,fritzrepeater-3000|\
compex,wpj428)
ucidef_set_interface_lan "eth0 eth1"
;;
diff --git 
a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 1264d2ef36..8520dfb41d 100644
--- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -111,6 +111,10 @@ case "$FIRMWARE" in
ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
/lib/firmware/ath10k/QCA9888/hw2.0/board.bin
;;
+   avm,fritzrepeater-3000)
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
+   ;;
openmesh,a62)
ath10kcal_extract "0:ART"

[OpenWrt-Devel] [PATCH 1/2] uboot-fritz4040: bump version to 2019-03-03

2019-03-05 Thread David Bauer

Adds support for the AVM FRITZ!Repeater 3000

Signed-off-by: David Bauer 
---
 package/boot/uboot-fritz4040/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/boot/uboot-fritz4040/Makefile 
b/package/boot/uboot-fritz4040/Makefile
index 9af09afcd1..3182842c89 100644
--- a/package/boot/uboot-fritz4040/Makefile
+++ b/package/boot/uboot-fritz4040/Makefile
@@ -10,9 +10,9 @@ include $(INCLUDE_DIR)/kernel.mk
 
 PKG_SOURCE_URL:=https://github.com/chunkeey/FritzBox-4040-UBOOT
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_VERSION:=d306cce36f98a0a67becc42f20df4b22f1d1465f
-PKG_SOURCE_DATE:=2019-02-08
-PKG_MIRROR_HASH:=715380605dd0cd6ffd65a18b34127bd57dfe9fb0a0164bf8aca703ee018d8070
+PKG_SOURCE_VERSION:=5f383305f4f0be631b51f89e3dc717318057bde9
+PKG_SOURCE_DATE:=2019-03-03
+PKG_MIRROR_HASH:=cb9153480648776cce21f038de8153a0f033066e3d44476ed4c802b48f500fae
 
 PKG_RELEASE:=1
 
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-08 Thread David Bauer

Hello Christian,

first of all, thanks for the review!

On 08.03.19 22:23, Christian Lamparter wrote:
> On Tuesday, March 5, 2019 7:38:38 PM CET David Bauer wrote:
>> Hardware
>> 
>> CPU:   Qualcomm IPQ4019
>> RAM:   256M
>> FLASH: 128M NAND
> Sorry for being nosy. Did you get any chance to open up the device
> and write down what RAM and flash chips are used in your unit?

Will be contained in the v2. In the meantime:

RAM:  NANYA NT5CC128M16JR-EK
NAND: Macronix MX30LF1G18AC-XKI

> [...]
>> diff --git 
>> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
>>  
>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
>> new file mode 100644
>> index 00..b73a214c09
>> --- /dev/null
>> +++ 
>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
>> @@ -0,0 +1,261 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> +
>> +#include "qcom-ipq4019.dtsi"
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/ {
>> +model = "AVM FRITZ!Repeater 3000";
>> +compatible = "avm,fritzrepeater-3000";
>> +
>> +aliases {
>> +led-boot = &power_led;
>> +led-failsafe = &power_led;
>> +led-running = &power_led;
>> +led-upgrade = &power_led;
>> +};
>> +
>> +keys {
> Since it's a single "key" or "button" you can of course
> also call this node "key" or "button". Whatever fits the
> best.

Thanks, will fix that.

> 
>> +compatible = "gpio-keys";
>> +
>> +connect {
>> +label = "Connect";
>> +gpios = <&tlmm 10 GPIO_ACTIVE_LOW>;
>> +linux,code = ;
>> +};
>> +};
>> +
>> +leds {
>> +compatible = "gpio-leds";
>> +
>> +connect_red {
>> +label = "fritzwlan-3000:red:connect";
>> +gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +connect_green {
>> +label = "fritzwlan-3000:green:connect";
>> +gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +connect_blue {
>> +label = "fritzwlan-3000:blue:connect";
>> +gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
>> +};
> Just a question: Are the "connect" LED three different LEDs
> or just one RGB LED?

It's 3 separate LEDs on the PCB, but they are directed to the same spot
on the case, so technically it works like a RGB LED.

>> +
>> +power_led: power {
>> +label = "fritzwlan-3000:green:power";
>> +gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
>> +};
>> +};
>> +};
>> +
>> +&tlmm {
>> +serial_0_pins: serial_pinmux {
>> +mux {
>> +pins = "gpio16", "gpio17";
>> +function = "blsp_uart0";
>> +bias-disable;
>> +};
>> +};
>> +
>> +nand_pins: nand_pins {
>> +pullups {
>> +pins = "gpio53", "gpio58", "gpio59";
>> +function = "qpic";
>> +bias-pull-up;
>> +};
>> +
>> +pulldowns {
>> +pins = "gpio54", "gpio55", "gpio56",
>> +"gpio57", "gpio60", "gpio61",
>> +"gpio62", "gpio63", "gpio64",
>> +"gpio65", "gpio66", "gpio67",
>> +"gpio68", "gpio69";
>> +function = "qpic";
>> +bias-pull-down;
>> +};
>> +};
>> +};
>> +
>> +&nand {
>> +pinctrl-0 = <&nand_pins>;
>> +pinctrl-names = "default";
>> +status = "okay";
>> +cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
> cs-gpios? Oh no! th

[OpenWrt-Devel] [PATCH v2 1/2] uboot-fritz4040: bump version to 2019-03-03

2019-03-08 Thread David Bauer

Adds support for the AVM FRITZ!Repeater 3000

Signed-off-by: David Bauer 
---
 package/boot/uboot-fritz4040/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/boot/uboot-fritz4040/Makefile 
b/package/boot/uboot-fritz4040/Makefile
index 9af09afcd1..3182842c89 100644
--- a/package/boot/uboot-fritz4040/Makefile
+++ b/package/boot/uboot-fritz4040/Makefile
@@ -10,9 +10,9 @@ include $(INCLUDE_DIR)/kernel.mk
 
 PKG_SOURCE_URL:=https://github.com/chunkeey/FritzBox-4040-UBOOT
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_VERSION:=d306cce36f98a0a67becc42f20df4b22f1d1465f
-PKG_SOURCE_DATE:=2019-02-08
-PKG_MIRROR_HASH:=715380605dd0cd6ffd65a18b34127bd57dfe9fb0a0164bf8aca703ee018d8070
+PKG_SOURCE_VERSION:=5f383305f4f0be631b51f89e3dc717318057bde9
+PKG_SOURCE_DATE:=2019-03-03
+PKG_MIRROR_HASH:=cb9153480648776cce21f038de8153a0f033066e3d44476ed4c802b48f500fae
 
 PKG_RELEASE:=1
 
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-08 Thread David Bauer

Hardware

CPU:   Qualcomm IPQ4019
RAM:   256M (NANYA NT5CC128M16JR-EK)
FLASH: 128M NAND (Macronix MX30LF1G18AC-XKI)
ETH:   Qualcomm QCA8072
WiFi2: IPQ4019 2T2R 2SS b/g/n
WiFi5: IPQ4019 2T2R 2SS n/ac
WiFi5: QCA9984 4T4R 4SS n/ac
LED:- Connect green/blue/red
- Power green
BTN:   WPS/Connect
UART:  115200n8 3.3V
   VCC - RX - TX - GND (Square is VCC)

Installation

1. Grab the uboot for the Device from the 'u-boot-fritz3000'
   subdirectory. Place it in the same directory as the 'eva_ramboot.py'
   script. It is located in the 'scripts/flashing' subdirectory of the
   OpenWRT tree.

2. Assign yourself the IP address 192.168.178.10/24. Connect your
   Computer to one of the boxes LAN ports.

3. Connect Power to the Box. As soon as the LAN port of your computer
   shows link, load the U-Boot to the box using following command.

   > ./eva_ramboot.py --offset 0x8500 192.168.178.1 uboot-fritz3000.bin

4. The U-Boot will now start. Now assign yourself the IP address
   192.168.1.70/24. Copy the OpenWRT initramfs (!) image to a TFTP
   server root directory and rename it to 'FRITZ3000.bin'.

5. The Box will now boot OpenWRT from RAM. This can take up to two
   minutes.

6. Copy the U-Boot and the OpenWRT sysupgrade (!) image to the Box using
   scp. SSH into the Box and first write the Bootloader to both previous
   kernel partitions.

   > mtd write /path/to/uboot-fritz3000.bin uboot0
   > mtd write /path/to/uboot-fritz3000.bin uboot1

7. Remove the AVM filesystem partitions to make room for our kernel +
   rootfs + overlayfs.

   > ubirmvol /dev/ubi0 --name=avm_filesys_0
   > ubirmvol /dev/ubi0 --name=avm_filesys_1

8. Flash OpenWRT peristently using sysupgrade.

   > sysupgrade -n /path/to/openwrt-sysupgrade.bin

Signed-off-by: David Bauer 
---
v2:
 - remove cs-gpio property from nand node
 - add device-specific BDF package
 - add RAM and NAND chip model information

 package/boot/uboot-fritz4040/Makefile |   7 +-
 package/firmware/ipq-wifi/Makefile|   3 +-
 .../ipq-wifi/board-avm_fritzrepeater-3000.bin | Bin 0 -> 24332 bytes
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  10 +-
 .../base-files/lib/upgrade/platform.sh|   1 +
 .../dts/qcom-ipq4019-fritzrepeater-3000.dts   | 260 +
 .../dts/qcom-ipq4019-fritzrepeater-3000.dts   | 264 ++
 target/linux/ipq40xx/image/Makefile   |   9 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 11 files changed, 555 insertions(+), 6 deletions(-)
 create mode 100644 package/firmware/ipq-wifi/board-avm_fritzrepeater-3000.bin
 create mode 100644 
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts

diff --git a/package/boot/uboot-fritz4040/Makefile 
b/package/boot/uboot-fritz4040/Makefile
index 3182842c89..015ca1deb9 100644
--- a/package/boot/uboot-fritz4040/Makefile
+++ b/package/boot/uboot-fritz4040/Makefile
@@ -25,6 +25,11 @@ define U-Boot/Default
   UBOOT_IMAGE:=uboot-$(1).bin
 endef
 
+define U-Boot/fritz3000
+  NAME:=FritzRepeater 3000
+  BUILD_DEVICES:=avm_fritzrepeater-3000
+endef
+
 define U-Boot/fritz4040
   NAME:=FritzBox 4040
   BUILD_DEVICES:=avm_fritzbox-4040
@@ -61,6 +66,6 @@ define Package/u-boot/install
$(INSTALL_BIN) $(PKG_BUILD_DIR)/upload-to-f4040.sh $(1)/
 endef
 
-UBOOT_TARGETS := fritz4040 fritz7530
+UBOOT_TARGETS := fritz3000 fritz4040 fritz7530
 
 $(eval $(call BuildPackage/U-Boot))
diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index 9a00832ca2..d273667f68 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -18,7 +18,7 @@ endef
 # Please send a mail with your device-specific board files upstream.
 # You can find instructions and examples on the linux-wireless wiki:
 # <https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles>
-ALLWIFIBOARDS:=alfa-network_ap120c-ac asus_map-ac2200 avm_fritzbox-7530 
engenius_eap1300 linksys_ea6350v3 qxwlan_e2600ac
+ALLWIFIBOARDS:=alfa-network_ap120c-ac asus_map-ac2200 avm_fritzbox-7530 
avm_fritzrepeater-3000 engenius_eap1300 linksys_ea6350v3 qxwlan_e2600ac
 ALLWIFIPACKAGES:=$(foreach BOARD,$(ALLWIFIBOARDS),ipq-wifi-$(BOARD))
 
 define Package/ipq-wifi-default
@@ -57,6 +57,7 @@ $(eval $(call 
generate-ipq-wifi-package,alfa-network_ap120c-ac,board-alfa-networ
 $(eval $(call 
generate-ipq-wifi-package,asus_map-ac2200,board-map-ac2200.bin,ASUS MAP-AC2200))
 $(eval $(call 
generate-ipq-wifi-package,engenius_eap1300,board-engenius_eap1300.bin,EnGenius 
EAP1300))
 $(eval $(call 
generate-ipq-wifi-package,avm_fritzbox-7530,board-avm_fritzbox-7530.bin,AVM 
FRITZ!Box 7530))
+$(eval $(call 
generate-ipq-w

Re: [OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-08 Thread David Bauer

Hello Christian,

missed one thing (which might also be interesting to others)

On 08.03.19 22:23, Christian Lamparter wrote:
> Didn't find any GPL sources or firmware releases for this device yet. So, I
> would much rather err on the side of caution and change this so that the 
> device gets its own variant. Even if the boarddata is seemingly shared between
> "different" devices from the same vendor.
> 

While the GPL tarball for the Repeater 3000 is missing, everything is
contained in the tarball for the FRITZ!Box 7530. [0]
Although maybe not relevant for this particular device, the tarball also
contains code for the new QCN550x series from Qualcomm.

They also put up a factory image on their FTP in the last days which can
be found here. [1]

[0] http://osp.avm.de/fritzbox/fritzbox-7530/
[1] http://ftp.avm.de/fritzwlan/fritzrepeater-3000/deutschland/fritz.os/

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq40xx: fix FRITZBox 7530 NAND controller node

2019-03-08 Thread David Bauer

This removes the 'cs-gpios' property from the AVM FRITZ!Box 7530 NAND
controller node. As pointed out by Christian Lamparter, the property is
not needed by the Qualcomm NAND controller driver.

Signed-off-by: David Bauer 
---
 .../files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts  | 1 -
 .../files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts  | 1 -
 2 files changed, 2 deletions(-)

diff --git 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
index 45c4864855..ce117b451a 100644
--- 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
+++ 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
@@ -167,7 +167,6 @@
pinctrl-0 = <&nand_pins>;
pinctrl-names = "default";
status = "okay";
-   cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
 
nand@0 {
partitions {
diff --git 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
index 53f83f411b..b04a61dc04 100644
--- 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
+++ 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
@@ -171,7 +171,6 @@
pinctrl-0 = <&nand_pins>;
pinctrl-names = "default";
status = "okay";
-   cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
 
nand@0 {
partitions {
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-10 Thread David Bauer

Hello Christian,

On 10.03.19 20:27, Christian Lamparter wrote:
> On Saturday, March 9, 2019 12:20:54 AM CET David Bauer wrote:
>> Hardware
>> 
>> CPU:   Qualcomm IPQ4019
>> RAM:   256M (NANYA NT5CC128M16JR-EK)
>> FLASH: 128M NAND (Macronix MX30LF1G18AC-XKI)
>> ETH:   Qualcomm QCA8072
>> WiFi2: IPQ4019 2T2R 2SS b/g/n
>> WiFi5: IPQ4019 2T2R 2SS n/ac
>> WiFi5: QCA9984 4T4R 4SS n/ac
>> LED:- Connect green/blue/red
>> - Power green
>> BTN:   WPS/Connect
>> UART:  115200n8 3.3V
>>VCC - RX - TX - GND (Square is VCC)
>>
>> Installation
>> 
>> 1. Grab the uboot for the Device from the 'u-boot-fritz3000'
>>subdirectory. Place it in the same directory as the 'eva_ramboot.py'
>>script. It is located in the 'scripts/flashing' subdirectory of the
>>OpenWRT tree.
>>
>> 2. Assign yourself the IP address 192.168.178.10/24. Connect your
>>Computer to one of the boxes LAN ports.
>>
>> 3. Connect Power to the Box. As soon as the LAN port of your computer
>>shows link, load the U-Boot to the box using following command.
>>
>>> ./eva_ramboot.py --offset 0x8500 192.168.178.1 uboot-fritz3000.bin
>>
>> 4. The U-Boot will now start. Now assign yourself the IP address
>>192.168.1.70/24. Copy the OpenWRT initramfs (!) image to a TFTP
>>server root directory and rename it to 'FRITZ3000.bin'.
>>
>> 5. The Box will now boot OpenWRT from RAM. This can take up to two
>>minutes.
>>
>> 6. Copy the U-Boot and the OpenWRT sysupgrade (!) image to the Box using
>>scp. SSH into the Box and first write the Bootloader to both previous
>>kernel partitions.
>>
>>> mtd write /path/to/uboot-fritz3000.bin uboot0
>>> mtd write /path/to/uboot-fritz3000.bin uboot1
>>
>> 7. Remove the AVM filesystem partitions to make room for our kernel +
>>rootfs + overlayfs.
>>
>>> ubirmvol /dev/ubi0 --name=avm_filesys_0
>>> ubirmvol /dev/ubi0 --name=avm_filesys_1
>>
>> 8. Flash OpenWRT peristently using sysupgrade.
>>
>>> sysupgrade -n /path/to/openwrt-sysupgrade.bin
>>
>> Signed-off-by: David Bauer 
>> ---
>> diff --git a/target/linux/ipq40xx/image/Makefile 
>> b/target/linux/ipq40xx/image/Makefile
>> index 3a7ecf39eb..49ff71c6bc 100644
>> --- a/target/linux/ipq40xx/image/Makefile
>> +++ b/target/linux/ipq40xx/image/Makefile
>> @@ -130,6 +130,15 @@ define Device/avm_fritzbox-7530
>>  endef
>>  TARGET_DEVICES += avm_fritzbox-7530
>>  
>> +define Device/avm_fritzrepeater-3000
>> +$(call Device/FitImageLzma)
>> +DEVICE_DTS := qcom-ipq4019-fritzrepeater-3000
>> +DEVICE_TITLE := AVM Fritz!Repeater 3000
>> +DEVICE_PACKAGES := ath10k-firmware-qca9984-ct fritz-caldata 
>> ipq-wifi-avm_fritzrepeater-3000
> The fritz-tffs-nand was just added to openwrt. 
> 
> <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=50717510e7e556cbc9ef05887900a7dc93a57793>
> 
> Should I add it in place? (And for the 7530 as well?)

I will submit a follow-up patch regarding tis topic as it was merged
without this issue addressed. I have already prepared a patch for this,
but will test it tomorrow on all 3 affected devices (7530, 3000 and 7412).

Best wishes
David

> 
> Cheers,
> Christian
> 
> 
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3 2/3] fritz-tools: add support for IPQ40xx platform

2019-03-11 Thread David Bauer

AVM devices based on Qualcomm IPQ40xx do not store sector health
information in the OOB area. Make this check optional to support this
platform.

Signed-off-by: David Bauer 
---
 package/utils/fritz-tools/src/fritz_tffs_nand_read.c | 12 ++--
 target/linux/ipq40xx/image/Makefile  |  2 +-
 .../linux/lantiq/base-files/etc/board.d/02_network   |  4 ++--
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/package/utils/fritz-tools/src/fritz_tffs_nand_read.c 
b/package/utils/fritz-tools/src/fritz_tffs_nand_read.c
index db77d2f5b4..ded0577cf3 100644
--- a/package/utils/fritz-tools/src/fritz_tffs_nand_read.c
+++ b/package/utils/fritz-tools/src/fritz_tffs_nand_read.c
@@ -67,6 +67,7 @@ static char *mtddev;
 static char *name_filter = NULL;
 static bool show_all = false;
 static bool print_all_key_names = false;
+static bool read_oob_sector_health = false;
 static bool swap_bytes = false;
 static uint8_t readbuf[TFFS_SECTOR_SIZE];
 static uint8_t oobbuf[TFFS_SECTOR_OOB_SIZE];
@@ -191,7 +192,7 @@ static int find_entry(uint32_t id, struct tffs_entry *entry)
uint32_t read_id = read_uint32(readbuf, 0x00);
uint32_t read_len = read_uint32(readbuf, 0x04);
uint32_t read_rev = read_uint32(readbuf, 0x0c);
-   if (oob_id != read_id || oob_len != read_len || oob_rev 
!= read_rev) {
+   if (read_oob_sector_health && (oob_id != read_id || 
oob_len != read_len || oob_rev != read_rev)) {
fprintf(stderr, "Warning: sector has 
inconsistent metadata\n");
continue;
}
@@ -360,6 +361,9 @@ static int show_matching_key_value(struct 
tffs_key_name_table *key_names)
 
 static int check_sector(off_t pos)
 {
+   if (!read_oob_sector_health) {
+   return 1;
+   }
if (read_sectoroob(pos)) {
return 0;
}
@@ -450,6 +454,7 @@ static void usage(int status)
"  -h  show this screen\n"
"  -l  list all supported keys\n"
"  -ndisplay the value of the given key\n"
+   "  -o  read OOB information about sector health\n"
);
 
exit(status);
@@ -460,7 +465,7 @@ static void parse_options(int argc, char *argv[])
while (1) {
int c;
 
-   c = getopt(argc, argv, "abd:hln:");
+   c = getopt(argc, argv, "abd:hln:o");
if (c == -1)
break;
 
@@ -489,6 +494,9 @@ static void parse_options(int argc, char *argv[])
show_all = false;
print_all_key_names = false;
break;
+   case 'o':
+   read_oob_sector_health = true;
+   break;
default:
usage(EXIT_FAILURE);
break;
diff --git a/target/linux/ipq40xx/image/Makefile 
b/target/linux/ipq40xx/image/Makefile
index 3a7ecf39eb..e2805c1d9e 100644
--- a/target/linux/ipq40xx/image/Makefile
+++ b/target/linux/ipq40xx/image/Makefile
@@ -125,7 +125,7 @@ define Device/avm_fritzbox-7530
$(call Device/FitImageLzma)
DEVICE_DTS := qcom-ipq4019-fritzbox-7530
DEVICE_TITLE := AVM Fritz!Box 7530
-   DEVICE_PACKAGES := fritz-caldata ipq-wifi-avm_fritzbox-7530
+   DEVICE_PACKAGES := fritz-caldata fritz-tffs-nand 
ipq-wifi-avm_fritzbox-7530
IMAGES := sysupgrade.bin
 endef
 TARGET_DEVICES += avm_fritzbox-7530
diff --git a/target/linux/lantiq/base-files/etc/board.d/02_network 
b/target/linux/lantiq/base-files/etc/board.d/02_network
index c79fb2d136..a6a9e4d29d 100755
--- a/target/linux/lantiq/base-files/etc/board.d/02_network
+++ b/target/linux/lantiq/base-files/etc/board.d/02_network
@@ -169,8 +169,8 @@ avm,fritz7362sl)
 avm,fritz7412)
tffsdev=$(find_mtd_chardev "nand-tffs")
annex="b"
-   lan_mac=$(/usr/bin/fritz_tffs_nand -d $tffsdev -n maca)
-   wan_mac=$(/usr/bin/fritz_tffs_nand -d $tffsdev -n macdsl)
+   lan_mac=$(/usr/bin/fritz_tffs_nand -d $tffsdev -n maca -o)
+   wan_mac=$(/usr/bin/fritz_tffs_nand -d $tffsdev -n macdsl -o)
ucidef_set_interface_lan 'eth0'
;;
 
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3 1/3] uboot-fritz4040: bump version to 2019-03-03

2019-03-11 Thread David Bauer

Adds support for the AVM FRITZ!Repeater 3000

Signed-off-by: David Bauer 
---
 package/boot/uboot-fritz4040/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/boot/uboot-fritz4040/Makefile 
b/package/boot/uboot-fritz4040/Makefile
index 9af09afcd1..3182842c89 100644
--- a/package/boot/uboot-fritz4040/Makefile
+++ b/package/boot/uboot-fritz4040/Makefile
@@ -10,9 +10,9 @@ include $(INCLUDE_DIR)/kernel.mk
 
 PKG_SOURCE_URL:=https://github.com/chunkeey/FritzBox-4040-UBOOT
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_VERSION:=d306cce36f98a0a67becc42f20df4b22f1d1465f
-PKG_SOURCE_DATE:=2019-02-08
-PKG_MIRROR_HASH:=715380605dd0cd6ffd65a18b34127bd57dfe9fb0a0164bf8aca703ee018d8070
+PKG_SOURCE_VERSION:=5f383305f4f0be631b51f89e3dc717318057bde9
+PKG_SOURCE_DATE:=2019-03-03
+PKG_MIRROR_HASH:=cb9153480648776cce21f038de8153a0f033066e3d44476ed4c802b48f500fae
 
 PKG_RELEASE:=1
 
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3 3/3] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-11 Thread David Bauer

Hardware

CPU:   Qualcomm IPQ4019
RAM:   256M (NANYA NT5CC128M16JR-EK)
FLASH: 128M NAND (Macronix MX30LF1G18AC-XKI)
ETH:   Qualcomm QCA8072
WiFi2: IPQ4019 2T2R 2SS b/g/n
WiFi5: IPQ4019 2T2R 2SS n/ac
WiFi5: QCA9984 4T4R 4SS n/ac
LED:- Connect green/blue/red
- Power green
BTN:   WPS/Connect
UART:  115200n8 3.3V
   VCC - RX - TX - GND (Square is VCC)

Installation

1. Grab the uboot for the Device from the 'u-boot-fritz3000'
   subdirectory. Place it in the same directory as the 'eva_ramboot.py'
   script. It is located in the 'scripts/flashing' subdirectory of the
   OpenWRT tree.

2. Assign yourself the IP address 192.168.178.10/24. Connect your
   Computer to one of the boxes LAN ports.

3. Connect Power to the Box. As soon as the LAN port of your computer
   shows link, load the U-Boot to the box using following command.

   > ./eva_ramboot.py --offset 0x8500 192.168.178.1 uboot-fritz3000.bin

4. The U-Boot will now start. Now assign yourself the IP address
   192.168.1.70/24. Copy the OpenWRT initramfs (!) image to a TFTP
   server root directory and rename it to 'FRITZ3000.bin'.

5. The Box will now boot OpenWRT from RAM. This can take up to two
   minutes.

6. Copy the U-Boot and the OpenWRT sysupgrade (!) image to the Box using
   scp. SSH into the Box and first write the Bootloader to both previous
   kernel partitions.

   > mtd write /path/to/uboot-fritz3000.bin uboot0
   > mtd write /path/to/uboot-fritz3000.bin uboot1

7. Remove the AVM filesystem partitions to make room for our kernel +
   rootfs + overlayfs.

   > ubirmvol /dev/ubi0 --name=avm_filesys_0
   > ubirmvol /dev/ubi0 --name=avm_filesys_1

8. Flash OpenWRT peristently using sysupgrade.

   > sysupgrade -n /path/to/openwrt-sysupgrade.bin

Signed-off-by: David Bauer 
---
 package/boot/uboot-fritz4040/Makefile |   7 +-
 package/firmware/ipq-wifi/Makefile|   3 +-
 .../ipq-wifi/board-avm_fritzrepeater-3000.bin | Bin 0 -> 24332 bytes
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  10 +-
 .../base-files/lib/upgrade/platform.sh|   1 +
 .../dts/qcom-ipq4019-fritzrepeater-3000.dts   | 260 +
 .../dts/qcom-ipq4019-fritzrepeater-3000.dts   | 264 ++
 target/linux/ipq40xx/image/Makefile   |   9 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 11 files changed, 555 insertions(+), 6 deletions(-)
 create mode 100644 package/firmware/ipq-wifi/board-avm_fritzrepeater-3000.bin
 create mode 100644 
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts

diff --git a/package/boot/uboot-fritz4040/Makefile 
b/package/boot/uboot-fritz4040/Makefile
index 3182842c89..015ca1deb9 100644
--- a/package/boot/uboot-fritz4040/Makefile
+++ b/package/boot/uboot-fritz4040/Makefile
@@ -25,6 +25,11 @@ define U-Boot/Default
   UBOOT_IMAGE:=uboot-$(1).bin
 endef
 
+define U-Boot/fritz3000
+  NAME:=FritzRepeater 3000
+  BUILD_DEVICES:=avm_fritzrepeater-3000
+endef
+
 define U-Boot/fritz4040
   NAME:=FritzBox 4040
   BUILD_DEVICES:=avm_fritzbox-4040
@@ -61,6 +66,6 @@ define Package/u-boot/install
$(INSTALL_BIN) $(PKG_BUILD_DIR)/upload-to-f4040.sh $(1)/
 endef
 
-UBOOT_TARGETS := fritz4040 fritz7530
+UBOOT_TARGETS := fritz3000 fritz4040 fritz7530
 
 $(eval $(call BuildPackage/U-Boot))
diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index 9a00832ca2..d273667f68 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -18,7 +18,7 @@ endef
 # Please send a mail with your device-specific board files upstream.
 # You can find instructions and examples on the linux-wireless wiki:
 # <https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles>
-ALLWIFIBOARDS:=alfa-network_ap120c-ac asus_map-ac2200 avm_fritzbox-7530 
engenius_eap1300 linksys_ea6350v3 qxwlan_e2600ac
+ALLWIFIBOARDS:=alfa-network_ap120c-ac asus_map-ac2200 avm_fritzbox-7530 
avm_fritzrepeater-3000 engenius_eap1300 linksys_ea6350v3 qxwlan_e2600ac
 ALLWIFIPACKAGES:=$(foreach BOARD,$(ALLWIFIBOARDS),ipq-wifi-$(BOARD))
 
 define Package/ipq-wifi-default
@@ -57,6 +57,7 @@ $(eval $(call 
generate-ipq-wifi-package,alfa-network_ap120c-ac,board-alfa-networ
 $(eval $(call 
generate-ipq-wifi-package,asus_map-ac2200,board-map-ac2200.bin,ASUS MAP-AC2200))
 $(eval $(call 
generate-ipq-wifi-package,engenius_eap1300,board-engenius_eap1300.bin,EnGenius 
EAP1300))
 $(eval $(call 
generate-ipq-wifi-package,avm_fritzbox-7530,board-avm_fritzbox-7530.bin,AVM 
FRITZ!Box 7530))
+$(eval $(call 
generate-ipq-wifi-package,avm_fritzrepeater-3000,board-avm_fritzrepeater-3000.bin,AVM
 FRITZ!Repeater 3000))
 $(eval $(call 
generate-i

[OpenWrt-Devel] [PATCH] lantiq: disable VMMC for AVM FRITZ!Box 7412

2019-03-11 Thread David Bauer

This commit disables the VMMC for the AVM FRITZ!Box 7412 due to missing
support for the FXS ports (attached via the Dialog DECT chip according
to the original author).

This allows us to activate the second VPE of the CPU and SMP support.

Run-tested on AVM FRITZ!Box 7412.

Signed-off-by: David Bauer 
---
 .../linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7412.dts | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7412.dts 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7412.dts
index 3059c12858..093908db82 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7412.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7412.dts
@@ -11,7 +11,7 @@
model = "AVM FRITZ!Box 7412";
 
chosen {
-   bootargs = "console=ttyLTQ0,115200 mem=126M 
vpe1_load_addr=0x87e0 vpe1_mem=2M maxvpes=1 maxtcs=1 nosmp";
+   bootargs = "console=ttyLTQ0,115200";
};
 
aliases {
@@ -225,6 +225,3 @@
};
 };
 
-&vmmc {
-   status = "okay";
-};
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: add Netgear EX6150

2019-03-21 Thread David Bauer

SoC:   MediaTek MT7621
RAM:   64M (Winbond W9751G6KB-25)
FLASH: 16MB (Macronix MX25L12835F)
WiFi:  MediaTek MT7662E bgn 2SS
WiFi:  MediaTek MT7662E nac 2SS
BTN:   ON/OFF - Reset - WPS - AP/Extender toggle
LED:- Arrow Right (blue)
- Arrow Left (blue)
- WiFi 1 (red/green)
- WiFi 2 (red/green)
- Power (green/amber)
- WPS (Green)
UART:  UART is present as Pads on the backside of the PCB. They are
   located on the other side of the Ethernet port.
   3.3V - GND - TX - RX / 57600-8N1
   3.3V is the nearest one to the antenna connectors

Installation

Update the factory image via the Netgear web-interfaces (by default:
192.168.1.250/24).

You can also use the factory image with the nmrpflash tool.
For more information see https://github.com/jclehner/nmrpflash

Signed-off-by: David Bauer 
---
 .../ramips/base-files/etc/board.d/01_leds |   4 +
 .../ramips/base-files/etc/board.d/02_network  |   1 +
 target/linux/ramips/dts/EX6150.dts| 245 ++
 target/linux/ramips/image/mt7621.mk   |  11 +
 4 files changed, 261 insertions(+)
 create mode 100644 target/linux/ramips/dts/EX6150.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 9cca231ab6..1aaab994c1 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -264,6 +264,10 @@ mtc,wr1201)
 mzk-ex750np)
set_wifi_led "$boardname:red:wifi"
;;
+netgear,ex6150)
+   ucidef_set_led_wlan "wlan2g" "WiFi 2.4GHz" "$boardname:green:router" 
"phy1tpt"
+   ucidef_set_led_wlan "wlan5g" "WiFi 5GHz" "$boardname:green:client" 
"phy0tpt"
+   ;;
 netgear,r6120)
ucidef_set_led_switch "lan" "lan" "$boardname:green:lan" "switch0" 
"0x0f"
ucidef_set_led_switch "wan" "wan" "$boardname:green:wan" "switch0" 
"0x10"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 890efa0d93..568ad97c73 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -368,6 +368,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "5:wan" "6@eth0"
;;
+   netgear,ex6150|\
re350-v1)
ucidef_add_switch "switch0" \
"0:lan" "6@eth0"
diff --git a/target/linux/ramips/dts/EX6150.dts 
b/target/linux/ramips/dts/EX6150.dts
new file mode 100644
index 00..540fa513b8
--- /dev/null
+++ b/target/linux/ramips/dts/EX6150.dts
@@ -0,0 +1,245 @@
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "netgear,ex6150", "mediatek,mt7621-soc";
+   model = "Netgear EX6150";
+
+   aliases {
+   led-boot = &power_green;
+   led-failsafe = &power_amber;
+   led-running = &power_green;
+   led-upgrade = &power_amber;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x400>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   power_amber: power_amber {
+   label = "ex6150:amber:power";
+   gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
+   };
+
+   power_green: power_green {
+   label = "ex6150:green:power";
+   gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+   };
+
+   wps {
+   label = "ex6150:green:wps";
+   gpios = <&gpio0 16 GPIO_ACTIVE_LOW>;
+   };
+
+   rightarrow {
+   label = "ex6150:blue:rightarrow";
+   gpios = <&gpio0 28 GPIO_ACTIVE_LOW>;
+   };
+
+   leftarrow {
+   label = "ex6150:blue:leftarrow";
+   gpios = <&gpio0 31 GPIO_ACTIVE_LOW>;
+   };
+
+   router_green {
+   label = "ex6150:green:router";
+   gpios = <&gpio0 29 GPIO_ACTIVE_LOW>;
+   };
+
+   router_red {
+   label = "ex6150:red:router";
+

[OpenWrt-Devel] [PATCH] ramips: enable R6120 USB power

2019-03-28 Thread David Bauer

Enable the USB power for the Netgear R6120. Otherwise, no power is
supplied to an attached USB device.

Signed-off-by: David Bauer 
---
 target/linux/ramips/dts/R6120.dts  | 15 ++-
 target/linux/ramips/mt76x8/config-4.14 |  2 ++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/R6120.dts 
b/target/linux/ramips/dts/R6120.dts
index 07b1a165d3..d263c7824b 100644
--- a/target/linux/ramips/dts/R6120.dts
+++ b/target/linux/ramips/dts/R6120.dts
@@ -65,13 +65,26 @@
gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
};
};
+
+   usb-regulator {
+   compatible = "regulator-fixed";
+
+   regulator-name = "USB-power";
+   gpio = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   enable-active-high;
+
+   regulator-always-on;
+   };
 };
 
 &pinctrl {
state_default: pinctrl0 {
gpio {
ralink,group = "p0led_an", "p1led_an", "p2led_an",
-  "p3led_an", "p4led_an", "wdt", "wled_an";
+  "p3led_an", "p4led_an", "wdt",
+  "wled_an", "uart1";
ralink,function = "gpio";
};
};
diff --git a/target/linux/ramips/mt76x8/config-4.14 
b/target/linux/ramips/mt76x8/config-4.14
index 62e51cbe43..5bcb948585 100644
--- a/target/linux/ramips/mt76x8/config-4.14
+++ b/target/linux/ramips/mt76x8/config-4.14
@@ -192,6 +192,8 @@ CONFIG_RALINK=y
 # CONFIG_RCU_STALL_COMMON is not set
 CONFIG_REGMAP=y
 CONFIG_REGMAP_MMIO=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_RESET_CONTROLLER=y
 # CONFIG_SCHED_INFO is not set
 # CONFIG_SCSI_DMA is not set
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: add missing SPDX identifier for EX6150

2019-03-29 Thread David Bauer

This adds the SPDX license identifier for the NETGEAR EX6150. It was
missed when submitting the original patch.

Signed-off-by: David Bauer 
---
 target/linux/ramips/dts/EX6150.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/dts/EX6150.dts 
b/target/linux/ramips/dts/EX6150.dts
index 729173bdd6..a5827f270d 100644
--- a/target/linux/ramips/dts/EX6150.dts
+++ b/target/linux/ramips/dts/EX6150.dts
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
 /dts-v1/;
 
 #include "mt7621.dtsi"
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for OCEDO Ursus

2019-04-02 Thread David Bauer

Hello,

I've tried your suggenstions on my unit (and try to provide some
information from my work with the other two APs from OCEDO/Riverbed).

On 02.04.19 00:19, Petr Štetiar wrote:
> markus.sche...@gmail.com  [2019-03-21 16:43:27]:
> 
> Hi,
> 
>> +label = "ursus:green:wlan2";
>> +label = "ursus:green:wlan5";
> 
> could we please make it wlan2g and wlan5g in order to stay consistent?
> 
> I found this old PR[1] for ar71xx, which makes me wonder if the stuff bellow
> is correct.
> 
>> +&mdio0 {
>> +status = "okay";
>> +
>> +phy1: ethernet-phy@1 {
>> +reg = <1>;
>> +};
>> +
> 
> In that ar71xx code it seems, that phy2 is connected through GMAC1/SGMII. Can
> you please explain in your commit message what is connected where in more
> details?

The OCEDO Ursus / Riverbed AP5r is a bit odd here as the MDIO lines for
the GMAC1 PHY is connected to the MDIO interface of GMAC0 (nothing
connected to GMAC1 MDIO). This is also how it's interfaced in the ar71xx
PR from last year ago.

> 
>> +phy2: ethernet-phy@2 {
>> +reg = <2>;
>> +};
>> +};
>> +
>> +ð0 {
>> +status = "okay";
> 
> add newline here
> 
>> +mtd-mac-address = <&art 0x00>;
>> +phy-handle = <&phy1>;
>> +pll-data = <0xa600 0x8101 0x80001313>;
> 
>   pll-data = <0xae00 0xa101 0xa0001313>;

I'm experiencing low throughput with this. The PLL-values from the PR
also match the ones i get via devmem from the vendor SteelWrt.

> 
> what is expected phy-mode here?

This information seems to be redundant to me as QCA9558 only supports
RGMII/SGMII and this information is already present in the inherited
qca9557.dtsi. While we could (theoretically) use the mux to switch the
interfaces between the GMACs i don't see support for it currently
neither in ar71xx nor ath79.

> 
>> +ð1 {
>> +status = "okay";
> 
> add newline here
> 
>> +mtd-mac-address = <&art 0x12>;
> 
>   mtd-mac-address = <&art 0xc>; ?

It seems the original firmware derives the MAC addresses for the
interfaces from the local OCEDO/Riverbed gateway the AP is connected to
(note the devices are not intended to be used independently). The device
itself has 4 unique addresses stored in the ART partition. The first one
used for eth0 (only MAC address matching the original firmware), the
other ones seem to be for IPSec tunnels but they are also device-unique.

Because of that, I've decided to distribute the 3 i had for the Raccoon
and Koala across eth0/wlan0/wlan1. This patch seems to match the scheme
of the existing two, adding the forth IP address to eth1, which i would
also aim for.

> 
>> +phy-handle = <&phy2>;
>> +pll-data = <0x3000101 0x101 0x1313>;
> 
> what is expected phy-mode here?
> 
>   pll-data = <0x030 0x101 0x1313>;

I get around ~2% of packet-loss with these. I know they are used in the
ar71xx PR, but as the ones currently used in this patch are matching the
ones from SteelWrt I'm more confident with whats present here.

Best wishes
David

> 
> 1. 
> https://github.com/openwrt/openwrt/pull/1016/commits/6bc138ec46ce956783aba7f8c83608982030a8be
> 
> -- ynezz
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for OCEDO Ursus

2019-04-06 Thread David Bauer

Hello Petr,

sorry for the late reply, I was very busy last week.

On 03.04.19 09:35, Petr Štetiar wrote:
> ok, so it seems like this patch is fine with you and you've already tested it
> as it is, so can I add your Tested-by or Reviewed-by as well?

Tested-by: David Bauer 

Maybe you can alter the LED names and the newline issue on your side
avoiding a v2 :)

Best wishes
David

> 
> -- ynezz
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] mpc85xx: remove USB support from kernel

2019-04-08 Thread David Bauer

This removes USB support from the compiled kernel. Because of this, the
kernel is just small enough for the TP-Link WDR4900 to boot the
resulting kernel.

This is necessary to support the WDR4900 in the upcoming 19.xx release.
In the long run, this should be fixed with a second stage bootloader, as
the vendor bootloader only loads the first 2684k bytes.

Signed-off-by: David Bauer 
---
 target/linux/mpc85xx/Makefile| 2 +-
 target/linux/mpc85xx/config-4.14 | 7 ---
 target/linux/mpc85xx/config-4.19 | 7 ---
 3 files changed, 1 insertion(+), 15 deletions(-)

diff --git a/target/linux/mpc85xx/Makefile b/target/linux/mpc85xx/Makefile
index 370ef81f15..02fdc2f53d 100644
--- a/target/linux/mpc85xx/Makefile
+++ b/target/linux/mpc85xx/Makefile
@@ -22,6 +22,6 @@ include $(INCLUDE_DIR)/target.mk
 
 DEFAULT_PACKAGES += \
kmod-input-core kmod-input-gpio-keys kmod-button-hotplug \
-   kmod-leds-gpio swconfig kmod-ath9k wpad-basic
+   kmod-leds-gpio swconfig kmod-ath9k wpad-basic kmod-usb2-fsl
 
 $(eval $(call BuildTarget))
diff --git a/target/linux/mpc85xx/config-4.14 b/target/linux/mpc85xx/config-4.14
index f057e5c910..f2337210d4 100644
--- a/target/linux/mpc85xx/config-4.14
+++ b/target/linux/mpc85xx/config-4.14
@@ -354,13 +354,6 @@ CONFIG_UCC=y
 CONFIG_UCC_FAST=y
 CONFIG_UCC_GETH=y
 # CONFIG_UGETH_TX_ON_DEMAND is not set
-CONFIG_USB=y
-CONFIG_USB_COMMON=y
-CONFIG_USB_EHCI_FSL=y
-CONFIG_USB_EHCI_HCD=y
-# CONFIG_USB_EHCI_HCD_PLATFORM is not set
-CONFIG_USB_EHCI_HCD_PPC_OF=y
-CONFIG_USB_FHCI_HCD=y
 CONFIG_USB_SUPPORT=y
 CONFIG_VDSO32=y
 # CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
diff --git a/target/linux/mpc85xx/config-4.19 b/target/linux/mpc85xx/config-4.19
index c92edcfa37..df4d741c27 100644
--- a/target/linux/mpc85xx/config-4.19
+++ b/target/linux/mpc85xx/config-4.19
@@ -315,13 +315,6 @@ CONFIG_UCC=y
 CONFIG_UCC_FAST=y
 CONFIG_UCC_GETH=y
 # CONFIG_UGETH_TX_ON_DEMAND is not set
-CONFIG_USB=y
-CONFIG_USB_COMMON=y
-CONFIG_USB_EHCI_FSL=y
-CONFIG_USB_EHCI_HCD=y
-# CONFIG_USB_EHCI_HCD_PLATFORM is not set
-CONFIG_USB_EHCI_HCD_PPC_OF=y
-CONFIG_USB_FHCI_HCD=y
 CONFIG_USB_SUPPORT=y
 CONFIG_VDSO32=y
 # CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] kernel: usb: add FSL EHCI package

2019-04-08 Thread David Bauer

Add kernel module package for the Freescale USB2 EHCI used on the
mpc85xx platform.

Signed-off-by: David Bauer 
---
 package/kernel/linux/modules/usb.mk | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/package/kernel/linux/modules/usb.mk 
b/package/kernel/linux/modules/usb.mk
index 88bb4a91eb..f11758c662 100644
--- a/package/kernel/linux/modules/usb.mk
+++ b/package/kernel/linux/modules/usb.mk
@@ -385,8 +385,7 @@ define KernelPackage/usb2
CONFIG_USB_EHCI_MXC=y \
CONFIG_USB_OCTEON_EHCI=y \
CONFIG_USB_EHCI_HCD_ORION=y \
-   CONFIG_USB_EHCI_HCD_AT91=y \
-   CONFIG_USB_EHCI_FSL
+   CONFIG_USB_EHCI_HCD_AT91=y
   FILES:= \
$(LINUX_DIR)/drivers/usb/host/ehci-platform.ko
   ifneq ($(wildcard $(LINUX_DIR)/drivers/usb/host/ehci-orion.ko),)
@@ -406,6 +405,26 @@ endef
 $(eval $(call KernelPackage,usb2))
 
 
+define KernelPackage/usb2-fsl
+  TITLE:=Support for Freescale USB2 controllers
+  DEPENDS:=+kmod-usb-ehci @TARGET_mpc85xx
+  KCONFIG:= \
+   CONFIG_USB_EHCI_HCD_PPC_OF=y \
+   CONFIG_USB_EHCI_FSL=y
+  FILES:= \
+   $(LINUX_DIR)/drivers/usb/host/ehci-fsl.ko \
+   $(LINUX_DIR)/drivers/usb/host/fsl-mph-dr-of.ko
+  AUTOLOAD:=$(call AutoLoad,42,ehci-fsl fsl-mph-dr-of,1)
+  $(call AddDepends/usb)
+endef
+
+define KernelPackage/usb2-fsl/description
+ Kernel support for Freescale USB2 (EHCI) controllers
+endef
+
+$(eval $(call KernelPackage,usb2-fsl))
+
+
 define KernelPackage/usb2-pci
   TITLE:=Support for PCI USB2 controllers
   DEPENDS:=@PCI_SUPPORT +kmod-usb2
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/3] mpc85xx: clean up device package selection

2019-04-08 Thread David Bauer

Remove wireless and USB packages from the device-specific package
selection as they are already selected by the target itself.

Signed-off-by: David Bauer 
---
 target/linux/mpc85xx/image/Makefile | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/target/linux/mpc85xx/image/Makefile 
b/target/linux/mpc85xx/image/Makefile
index 55870764fb..d2c3ae1861 100644
--- a/target/linux/mpc85xx/image/Makefile
+++ b/target/linux/mpc85xx/image/Makefile
@@ -48,7 +48,6 @@ ifeq ($(SUBTARGET),generic)
 
 define Device/tl-wdr4900-v1
   DEVICE_TITLE := TP-Link TL-WDR4900
-  DEVICE_PACKAGES := kmod-ath9k wpad-basic
   TPLINK_HWID := 0x4901
   TPLINK_HWREV := 1
   TPLINK_FLASHLAYOUT := 16Mppc
@@ -64,7 +63,6 @@ TARGET_DEVICES += tl-wdr4900-v1
 
 define Device/red-15w-rev1
   DEVICE_TITLE := Sophos RED 15w Rev.1
-  DEVICE_PACKAGES := kmod-usb2
   # Original firmware uses a dedicated DTB-partition.
   # The bootloader however supports FIT-images.
   KERNEL = kernel-bin | gzip | fit gzip $(KDIR)/image-$$(DEVICE_DTS).dtb
@@ -80,7 +78,7 @@ ifeq ($(SUBTARGET),p1020)
 
 define Device/hiveap-330
   DEVICE_TITLE := Aerohive HiveAP-330
-  DEVICE_PACKAGES := kmod-ath9k wpad-basic kmod-tpm-i2c-atmel
+  DEVICE_PACKAGES := kmod-tpm-i2c-atmel
   BLOCKSIZE := 128k
   KERNEL_NAME := zImage
   KERNEL_SIZE := 8m
@@ -97,7 +95,7 @@ TARGET_DEVICES += hiveap-330
 
 define Device/panda
   DEVICE_TITLE := OCEDO Panda
-  DEVICE_PACKAGES := kmod-rtc-ds1307 kmod-usb2 uboot-envtools
+  DEVICE_PACKAGES := kmod-rtc-ds1307 uboot-envtools
   KERNEL = kernel-bin | gzip | fit gzip $(KDIR)/image-$$(DEVICE_DTS).dtb
   PAGESIZE := 2048
   SUBPAGESIZE := 512
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/4] ath79: enable QCA955x SGMII workaround

2019-04-11 Thread David Bauer

Enable the QCA955x SGMII workaround for all devices which sport the
AR8033 + QCA955x combination which is known to show the link-stuck
symptoms.

Signed-off-by: David Bauer 
---
 target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi | 6 ++
 target/linux/ath79/dts/qca9558_ocedo_ursus.dts | 6 ++
 target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi 
b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
index 9937186b1e..e2d1b7cc94 100644
--- a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
@@ -131,6 +131,7 @@
 &mdio1 {
phy1: ethernet-phy@1 {
reg = <1>;
+   at803x-override-sgmii-link-check;
};
 };
 
@@ -139,6 +140,11 @@
mtd-mac-address-increment = <1>;
phy-handle = <&phy1>;
pll-data = <0x03000101 0x0101 0x1313>;
+   qca955x-sgmii-fixup;
+
+   gmac-config {
+   device = <&gmac>;
+   };
 };
 
 &wmac {
diff --git a/target/linux/ath79/dts/qca9558_ocedo_ursus.dts 
b/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
index 1a92da3946..53bfa51fd2 100644
--- a/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
+++ b/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
@@ -119,6 +119,7 @@
 
phy2: ethernet-phy@2 {
reg = <2>;
+   at803x-override-sgmii-link-check;
};
 };
 
@@ -144,4 +145,9 @@
mtd-mac-address = <&art 0x12>;
phy-handle = <&phy2>;
pll-data = <0x3000101 0x101 0x1313>;
+   qca955x-sgmii-fixup;
+
+   gmac-config {
+   device = <&gmac>;
+   };
 };
diff --git a/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts 
b/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts
index 1e3cf40f71..d05e844d63 100644
--- a/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts
+++ b/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts
@@ -146,6 +146,7 @@
phy1: ethernet-phy@1 {
reg = <1>;
phy-mode = "sgmii";
+   at803x-override-sgmii-link-check;
};
 };
 
@@ -165,4 +166,9 @@
 
phy-handle = <&phy1>;
phy-mode = "sgmii";
+   qca955x-sgmii-fixup;
+
+   gmac-config {
+   device = <&gmac>;
+   };
 };
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/4] ath79: fix QCA955x GMAC register size

2019-04-11 Thread David Bauer

The register size of the QCA955x currently matches the size stated in
the datasheet. However, there are more hidden GMAC registers which are
needed for the SGMII workaround to work.

Signed-off-by: David Bauer 
---
 target/linux/ath79/dts/qca9557.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/dts/qca9557.dtsi 
b/target/linux/ath79/dts/qca9557.dtsi
index fefb91c39a..b726a382ee 100644
--- a/target/linux/ath79/dts/qca9557.dtsi
+++ b/target/linux/ath79/dts/qca9557.dtsi
@@ -223,7 +223,7 @@
 
gmac: gmac@1807 {
compatible = "qca,qca9550-gmac";
-   reg = <0x1807 0x14>;
+   reg = <0x1807 0x58>;
};
 
wmac: wmac@1810 {
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/4] ath79: add QCA955x SGMII link loss workaround

2019-04-11 Thread David Bauer

This commit adds a workaround for the loss of the SGMII link observed on
the QCA955x generation of SoCs. The workaround originates part from the
U-Boot source code, part from the implementation from AVM found in the
GPL tarball for the AVM FRITZ!WLAN Repeater 450E.

The bug results in a stuck SGMII link between the PHY device and the SoC
side. This has only been observed with the Atheros AR8033 PHY and most
likely all devices using such combination are affected.

It is worked around by reading a hidden SGMII status register and
issuing a SGMII PHY reset until the link becomes useable again.

Signed-off-by: David Bauer 
---
 .../net/ethernet/atheros/ag71xx/ag71xx_main.c | 108 ++
 ...9-add-missing-QCA955x-GMAC-registers.patch |  91 +++
 ...9-add-missing-QCA955x-GMAC-registers.patch |  91 +++
 3 files changed, 290 insertions(+)
 create mode 100644 
target/linux/ath79/patches-4.14/0038-MIPS-ath79-add-missing-QCA955x-GMAC-registers.patch
 create mode 100644 
target/linux/ath79/patches-4.19/0038-MIPS-ath79-add-missing-QCA955x-GMAC-registers.patch

diff --git 
a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c 
b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 8cff56a11a..a7565e6ffb 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -559,6 +559,112 @@ static void ath79_set_pll(struct ag71xx *ag)
udelay(100);
 }
 
+static void ag71xx_bit_set(void __iomem *reg, u32 bit)
+{
+   u32 val;
+
+   val = __raw_readl(reg) | bit;
+   __raw_writel(val, reg);
+   __raw_readl(reg);
+}
+
+static void ag71xx_bit_clear(void __iomem *reg, u32 bit)
+{
+   u32 val;
+
+   val = __raw_readl(reg) & ~bit;
+   __raw_writel(val, reg);
+   __raw_readl(reg);
+}
+
+static void ag71xx_sgmii_init_qca955x(struct device_node *np)
+{
+   struct device_node *np_dev;
+   void __iomem *gmac_base;
+   u32 mr_an_status;
+   u32 sgmii_status;
+   u8 tries = 0;
+   int err = 0;
+
+   np = of_get_child_by_name(np, "gmac-config");
+   if (!np)
+   return;
+
+   np_dev = of_parse_phandle(np, "device", 0);
+   if (!np_dev)
+   goto out;
+
+   gmac_base = of_iomap(np_dev, 0);
+   if (!gmac_base) {
+   pr_err("%pOF: can't map GMAC registers\n", np_dev);
+   err = -ENOMEM;
+   goto err_iomap;
+   }
+
+   mr_an_status = __raw_readl(gmac_base + QCA955X_GMAC_REG_MR_AN_STATUS);
+   if (!(mr_an_status & QCA955X_MR_AN_STATUS_AN_ABILITY))
+   goto sgmii_out;
+
+   /* SGMII reset sequence */
+   __raw_writel(QCA955X_SGMII_RESET_RX_CLK_N_RESET,
+gmac_base + QCA955X_GMAC_REG_SGMII_RESET);
+   __raw_readl(gmac_base + QCA955X_GMAC_REG_SGMII_RESET);
+   udelay(10);
+
+   ag71xx_bit_set(gmac_base + QCA955X_GMAC_REG_SGMII_RESET,
+  QCA955X_SGMII_RESET_HW_RX_125M_N);
+   udelay(10);
+
+   ag71xx_bit_set(gmac_base + QCA955X_GMAC_REG_SGMII_RESET,
+  QCA955X_SGMII_RESET_RX_125M_N);
+   udelay(10);
+
+   ag71xx_bit_set(gmac_base + QCA955X_GMAC_REG_SGMII_RESET,
+  QCA955X_SGMII_RESET_TX_125M_N);
+   udelay(10);
+
+   ag71xx_bit_set(gmac_base + QCA955X_GMAC_REG_SGMII_RESET,
+  QCA955X_SGMII_RESET_RX_CLK_N);
+   udelay(10);
+
+   ag71xx_bit_set(gmac_base + QCA955X_GMAC_REG_SGMII_RESET,
+  QCA955X_SGMII_RESET_TX_CLK_N);
+   udelay(10);
+
+   /*
+* The following is what QCA has to say about what happens here:
+*
+* Across resets SGMII link status goes to weird state.
+* If SGMII_DEBUG register reads other than 0x1f or 0x10,
+* we are for sure in a bad  state.
+*
+* Issue a PHY reset in MR_AN_CONTROL to keep going.
+*/
+   do {
+   ag71xx_bit_set(gmac_base + QCA955X_GMAC_REG_MR_AN_CONTROL,
+  QCA955X_MR_AN_CONTROL_PHY_RESET |
+  QCA955X_MR_AN_CONTROL_AN_ENABLE);
+   udelay(200);
+   ag71xx_bit_clear(gmac_base + QCA955X_GMAC_REG_MR_AN_CONTROL,
+QCA955X_MR_AN_CONTROL_PHY_RESET);
+   mdelay(300);
+   sgmii_status = __raw_readl(gmac_base + 
QCA955X_GMAC_REG_SGMII_DEBUG) &
+  QCA955X_SGMII_DEBUG_TX_STATE_MASK;
+
+   if (tries++ >= 20) {
+   pr_err("ag71xx: max retries for SGMII fixup 
exceeded\n");
+   break;
+   }
+   } while (!(sgmii_status == 0xf || sgmii_status == 0x10));
+
+sgmii_out:
+   iounmap(gmac_base);
+err_iomap:
+   of_node_p

[OpenWrt-Devel] [PATCH 3/4] ath79: allow to override AR8033 SGMII aneg status

2019-04-11 Thread David Bauer

In order to make the QCA955x SGMII workaround work, the unsuccessful
SGMII autonegotiation on the AR8033 should not block the PHY
state-machine.

Otherwise, the ag71xx driver never becomes aware of the copper-side
link-establishment and the workaround is never executed.

Signed-off-by: David Bauer 
---
 .../425-at803x-allow-sgmii-aneg-override.patch   | 16 
 .../425-at803x-allow-sgmii-aneg-override.patch   | 16 
 2 files changed, 32 insertions(+)
 create mode 100644 
target/linux/ath79/patches-4.14/425-at803x-allow-sgmii-aneg-override.patch
 create mode 100644 
target/linux/ath79/patches-4.19/425-at803x-allow-sgmii-aneg-override.patch

diff --git 
a/target/linux/ath79/patches-4.14/425-at803x-allow-sgmii-aneg-override.patch 
b/target/linux/ath79/patches-4.14/425-at803x-allow-sgmii-aneg-override.patch
new file mode 100644
index 00..0ac6af38f3
--- /dev/null
+++ b/target/linux/ath79/patches-4.14/425-at803x-allow-sgmii-aneg-override.patch
@@ -0,0 +1,16 @@
+--- a/drivers/net/phy/at803x.c
 b/drivers/net/phy/at803x.c
+@@ -484,6 +484,13 @@ static int at803x_aneg_done(struct phy_d
+   if (!(phy_read(phydev, AT803X_PSSR) & AT803X_PSSR_MR_AN_COMPLETE)) {
+   pr_warn("803x_aneg_done: SGMII link is not ok\n");
+   aneg_done = 0;
++#ifdef CONFIG_OF_MDIO
++  if (phydev->mdio.dev.of_node && 
++  of_property_read_bool(phydev->mdio.dev.of_node,
++  "at803x-override-sgmii-link-check")) {
++  aneg_done = 1;
++  }
++#endif
+   }
+   /* switch back to copper page */
+   phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SEL);
diff --git 
a/target/linux/ath79/patches-4.19/425-at803x-allow-sgmii-aneg-override.patch 
b/target/linux/ath79/patches-4.19/425-at803x-allow-sgmii-aneg-override.patch
new file mode 100644
index 00..0ac6af38f3
--- /dev/null
+++ b/target/linux/ath79/patches-4.19/425-at803x-allow-sgmii-aneg-override.patch
@@ -0,0 +1,16 @@
+--- a/drivers/net/phy/at803x.c
 b/drivers/net/phy/at803x.c
+@@ -484,6 +484,13 @@ static int at803x_aneg_done(struct phy_d
+   if (!(phy_read(phydev, AT803X_PSSR) & AT803X_PSSR_MR_AN_COMPLETE)) {
+   pr_warn("803x_aneg_done: SGMII link is not ok\n");
+   aneg_done = 0;
++#ifdef CONFIG_OF_MDIO
++  if (phydev->mdio.dev.of_node && 
++  of_property_read_bool(phydev->mdio.dev.of_node,
++  "at803x-override-sgmii-link-check")) {
++  aneg_done = 1;
++  }
++#endif
+   }
+   /* switch back to copper page */
+   phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SEL);
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: add support for GL.iNet VIXMINI

2019-04-12 Thread David Bauer

Hardware

SoC:   MediaTek MT7628NN
RAM:   64M DDR2 (Etron EM68B16CWQD-25H)
FLASH: 8M (Winbond W25Q64JVSIQ)
LED:   Power - WLAN
BTN:   Reset
UART:  115200 8N1
   TX and RX are labled on the board as pads next to the SoC

Installation via web-interface
--
1. Visit the web-interface at 192.168.8.1
   Note: The ethernet port is by default WAN. So you need to connect to
   the router via WiFi

2. Navigate to the Update tab on the left side.

3. Select "Local Update"

4. Upload the OpenWrt sysupgrade image.
   Note: Make sure you select not to preserve the configuration.

Installation via U-Boot
---
1. Hold down the reset button while powering on the device.
   Wait for the LED to flash 5 times.

2. Assign yourself a static IPv4 in 192.168.1.0/24

3. Upload the OpenWrt sysupgrade image at 192.168.1.1.

Signed-off-by: David Bauer 
---
 .../ramips/base-files/etc/board.d/02_network  |   1 +
 target/linux/ramips/dts/VIXMINI.dts   | 114 ++
 target/linux/ramips/image/mt76x8.mk   |   8 ++
 3 files changed, 123 insertions(+)
 create mode 100644 target/linux/ramips/dts/VIXMINI.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 5fcf437fbd..89cdf57b3e 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -367,6 +367,7 @@ ramips_setup_interfaces()
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "5:wan" "6@eth0"
;;
dlink,dir-510l|\
+   glinet,vixmini|\
netgear,ex6150|\
re350-v1)
ucidef_add_switch "switch0" \
diff --git a/target/linux/ramips/dts/VIXMINI.dts 
b/target/linux/ramips/dts/VIXMINI.dts
new file mode 100644
index 00..5a52fe2a1b
--- /dev/null
+++ b/target/linux/ramips/dts/VIXMINI.dts
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7628an.dtsi"
+
+#include 
+#include 
+
+/{
+   compatible = "glinet,vixmini", "mediatek,mt7628an-soc";
+   model = "GL.iNet VIXMINI";
+
+   aliases {
+   led-boot = &led_power;
+   led-failsafe = &led_power;
+   led-running = &led_power;
+   led-upgrade = &led_power;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x400>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "vixmini:blue:power";
+   default-state = "on";
+   gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+   };
+
+   wlan {
+   label = "vixmini:white:wlan";
+   gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
+   linux,default-trigger = "phy0tpt";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys-polled";
+   poll-interval = <20>;
+
+   reset {
+   label = "reset";
+   gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+};
+
+&pinctrl {
+   state_default: pinctrl0 {
+   gpio {
+   ralink,group = "wdt", "wled_an", "p1led_an";
+   ralink,function = "gpio";
+   };
+   };
+};
+
+ðernet {
+   mtd-mac-address = <&factory 0x4>;
+};
+
+&wmac {
+   status = "okay";
+
+   ralink,mtd-eeprom = <&factory 0x0>;
+};
+
+&spi0 {
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+

Re: [OpenWrt-Devel] [PATCH] ath79: Add SUPPORTED_DEVICES for Archer C7 v1/v2

2019-04-21 Thread David Bauer

Hello Christian,

On 20.04.19 20:59, Christian Lamparter wrote:
> On Wednesday, April 17, 2019 3:45:52 PM CEST Adrian Schmutzler wrote:
>> The identifier for both devices is "archer-c7" on ar71xx, set here:
>> https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/base-files/lib/ar71xx.sh#L348
>> https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/base-files/lib/ar71xx.sh#L511
>>
>> Signed-off-by: Adrian Schmutzler 
>> ---
>>  target/linux/ath79/image/generic-tp-link.mk | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/target/linux/ath79/image/generic-tp-link.mk 
>> b/target/linux/ath79/image/generic-tp-link.mk
>> index 6853f12341..db1eabd420 100644
>> --- a/target/linux/ath79/image/generic-tp-link.mk
>> +++ b/target/linux/ath79/image/generic-tp-link.mk
>> @@ -70,6 +70,7 @@ define Device/tplink_archer-c7-v1
>>DEVICE_TITLE := TP-Link Archer C7 v1
>>DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport 
>> kmod-ath10k-ct ath10k-firmware-qca988x-ct
>>TPLINK_HWID := 0x7501
>> +  SUPPORTED_DEVICES += archer-c7
>>  endef
>>  TARGET_DEVICES += tplink_archer-c7-v1
>>  
>> @@ -79,6 +80,7 @@ define Device/tplink_archer-c7-v2
>>DEVICE_TITLE := TP-Link Archer C7 v2
>>DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport 
>> kmod-ath10k-ct ath10k-firmware-qca988x-ct
>>TPLINK_HWID := 0xc702
>> +  SUPPORTED_DEVICES += archer-c7
> In case of the v2, I think there's still the problem that a straight up 
> upgrade
> from ar71xx to ath79 will affect the 5GHz ath10k wireless because it now has a
> new device path and hence a new default configuration (where the card is 
> disabled) is created.

I recall upgrading my OCEDO Koala (which uses the same 9558/9880 combo)
from ar71xx to ath79 and the PCIe path being consistent on both platforms.

This however might have changed in the meantime, so someone should
probably confirm this with a real C7.

Best wishes
David

> 
> Tomasz Maciej Nowak worked on the WMAC part already (that's why the C7 v1
> hunk should be fine! But I think untested) in his series for the EPG5000.
> .
> 
> So I think that maybe it's possible to extend the migration script for
> pcie devices as well.
> 
> Cheers,
> Christian
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Add SUPPORTED_DEVICES for Archer C7 v1/v2

2019-04-21 Thread David Bauer


Hello Christian,

On 21.04.19 14:17, Christian Lamparter wrote:

Hello David,

On Sunday, April 21, 2019 11:42:52 AM CEST David Bauer wrote:

On 20.04.19 20:59, Christian Lamparter wrote:

On Wednesday, April 17, 2019 3:45:52 PM CEST Adrian Schmutzler wrote:

The identifier for both devices is "archer-c7" on ar71xx, set here:
https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/base-files/lib/ar71xx.sh#L348
https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/base-files/lib/ar71xx.sh#L511

Signed-off-by: Adrian Schmutzler 
---
  target/linux/ath79/image/generic-tp-link.mk | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/target/linux/ath79/image/generic-tp-link.mk 
b/target/linux/ath79/image/generic-tp-link.mk
index 6853f12341..db1eabd420 100644
--- a/target/linux/ath79/image/generic-tp-link.mk
+++ b/target/linux/ath79/image/generic-tp-link.mk
@@ -70,6 +70,7 @@ define Device/tplink_archer-c7-v1
DEVICE_TITLE := TP-Link Archer C7 v1
DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport 
kmod-ath10k-ct ath10k-firmware-qca988x-ct
TPLINK_HWID := 0x7501
+  SUPPORTED_DEVICES += archer-c7
  endef
  TARGET_DEVICES += tplink_archer-c7-v1
  
@@ -79,6 +80,7 @@ define Device/tplink_archer-c7-v2

DEVICE_TITLE := TP-Link Archer C7 v2
DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport 
kmod-ath10k-ct ath10k-firmware-qca988x-ct
TPLINK_HWID := 0xc702
+  SUPPORTED_DEVICES += archer-c7

In case of the v2, I think there's still the problem that a straight up upgrade
from ar71xx to ath79 will affect the 5GHz ath10k wireless because it now has a
new device path and hence a new default configuration (where the card is
disabled) is created.


I recall upgrading my OCEDO Koala (which uses the same 9558/9880 combo)
from ar71xx to ath79 and the PCIe path being consistent on both platforms.

This however might have changed in the meantime, so someone should
probably confirm this with a real C7.


On my C7 v1 with a QCA9880v2 the ar71xx installation back in
2018-08-17 looked like this:

config wifi-device 'radio0'
 option type 'mac80211'
 option country  'DE'
 option channel  'auto'
 option hwmode   '11g'
 option path 'platform/qca955x_wmac'
 option htmode   'HT20'
 option disabled '0'
 option txpower  '10'

config wifi-device 'radio1'
 option type 'mac80211'
 option channel  '52'
 option country  'DE'
 option hwmode   '11a'
 option path 'pci:01/:01:00.0'
 option htmode   'VHT80'
 option disabled '0'
 option txpower  '14'

vs ath79 (today):

config wifi-device 'radio0'
 option type 'mac80211'
 option country  'DE'
 option channel  'auto'
 option hwmode   '11g'
 option path 'platform/ahb/ahb:apb/1810.wmac'
 option htmode   'HT20'
 option disabled '0'
 option txpower  '10'

config wifi-device 'radio1'
 option type 'mac80211'
 option channel  '52'
 option country  'DE'
 option hwmode   '11a'
 option path 'pci:00/:00:00.0'
 option htmode   'VHT80'
 option disabled '0'
 option txpower  '14'

so the path changed from "pci:01/:01:00.0" to
"pci:00/:00:00.0". But again this is on a C7 v1.

Based on the bootlog on the wiki for 18.06.1 :
https://openwrt.org/toh/tp-link/archer-c7-1750#boot_logs
The ar71xx image enabling both pcie Root Complexes of the QCA955x.
But unfortunately the pcie slot of the C7 is wired to the second RC,
so the ath10k card gets pci:01/:01:00.0. Does anybody want to
test what happens if the ath79 C7 v2 DTS enables "pcie0" too? It might
work, but it might not (depending on whenever it might end up in a
different pci domain like pci0001:00.).


Damn, you are right. The Koala has it's only PCIe endpoint wired to the 
first bus, so this works fine.


Regarding enabling the first bus: Personally, I would prefer a migration 
script over enabling a non-wired interface. There is already a migration 
script for exactly this case in the mpc85xx target, so most of this work 
is probably straight up copy-paste ;)


Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: fix OCEDO Raccoon 10Mbit PLL value

2019-04-22 Thread David Bauer

This corrects the PLL value for 10 Mbit/s links on the OCEDO Raccoon.
Prior to this patch, 10 Mbit/s links would not transmit data.

It is worth mentioning that the vendor firmware used the same PLL
settings and 10Mbit/s was also not working there.

All other link-modes are working correctly without any packet loss.

Signed-off-by: David Bauer 
---
 target/linux/ath79/dts/ar9344_ocedo_raccoon.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts 
b/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
index 0875c319b9..a1a912383f 100644
--- a/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
+++ b/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
@@ -169,8 +169,7 @@
 ð0 {
status = "okay";
 
-   /* default for ar934x, except for 1000M */
-   pll-data = <0x0600 0x0101 0x1616>;
+   pll-data = <0x0600 0x0101 0x1313>;
 
mtd-mac-address = <&art 0x0>;
 
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] lantiq: image: build initramfs only for FRITZ7362SL

2019-05-06 Thread David Bauer

Hello Petr,

On 05.05.19 22:14, Petr Štetiar wrote:
> Commit "lantiq/xrx200: enable initramfs images" enabled creation of
> initramfs images for all devices in lantiq's xrx200 subtarget, just
> because FRITZ7362SL needs initramfs during OpenWrt instalation.

The FRITZ!Box 7412 also needs an initramfs for initial installation [1],
so it would be nice if it was included in this patch.

[1]
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=20f48c8ae334f8502e756282995cc84d89fa81c1

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ramips: add support for Xiaomi Mi Router 4A (100M Edition)

2019-05-06 Thread David Bauer

Hello Markus,

see my comments inline:

On 06.05.19 11:15, Markus Scheck wrote:
> - SoC:  MediaTek MT7628AN
> - Flash:16MB (Winbond W25Q128JV)
> - RAM:  64MB
> - Serial:   As marked on PCB, 3V3 logic, baudrate is 115200
> - Ethernet: 3x 10/100 Mbps (switched, 2x LAN + WAN)
> - WIFI0:MT7628AN 2.4GHz 802.11b/g/n
> - WIFI1:MT7612EN 5GHz 802.11ac
> - Antennas: 4x external (2 per radio), non-detachable
> - LEDs: Programmable power-LED (two-colored, yellow/blue)
> Non-programmable internet-LED (shows WAN-activity)
> - Buttons:  Reset
> 
> INSTALLATION:
> 
> 1. Connect to the serial port of the router and power it up.
>If you get a prompt asking for boot-mode, go to step 3.
> 2. Unplug the router after
>> Erasing SPI Flash...
>> raspi_erase: offs:2 len:1
>occurs on the serial port. Plug the router back in.
> 3. At the prompt select option 2 (Load system code then
>write to Flash via TFTP.)
> 4. Enter 192.168.1.1 as the device IP and 192.168.1.2 as the
>Server-IP.
> 5. Connect your computer to LAN1 and assign it as 192.168.1.2/24.
> 6. Rename the sysupgrade image to test.bin and serve it via TFTP.
> 7. Enter test.bin on the serial console and press enter.
> 
> Signed-off-by: Markus Scheck 
> ---
>  .../ramips/base-files/etc/board.d/02_network  |   4 +
>  target/linux/ramips/base-files/lib/ramips.sh  |   3 +
>  target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts | 147 ++
>  target/linux/ramips/image/mt76x8.mk   |   8 +
>  4 files changed, 162 insertions(+)
>  create mode 100644 target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index c2646876a2..29a1e7b54c 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -450,6 +450,10 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
>   ;;
> + xiaomi,mir4a-100m)
> + ucidef_add_switch "switch0" \
> + "4:lan:1" "2:lan:2" "0:wan" "6t@eth0"
> + ;;

You can replace "6t@eth0" with "6@eth0". Tagging is always used by default.

>   zbtlink,zbt-we1226|\
>   y1)
>   ucidef_add_switch "switch0" \
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
> b/target/linux/ramips/base-files/lib/ramips.sh
> index 093303892c..a9e7e746cd 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -649,6 +649,9 @@ ramips_board_detect() {
>   *"X8")
>   name="x8"
>   ;;
> + *"Xiaomi Mi Router 4A (100M Edition)")
> + name="xiaomi,mir4a-100m"
> + ;;
>   *"Y1")
>   name="y1"
>   ;;

You can completely omit this change in ramips.sh. By default, the
boardname is extracted from the machines compatible-string in it's
device-tree. :)

> diff --git a/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts 
> b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
> new file mode 100644
> index 00..b843bb203e
> --- /dev/null
> +++ b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
> @@ -0,0 +1,147 @@
> +//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "mt7628an.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "xiaomi,mir4a-100m", "mediatek,mt7628an-soc";
> + model = "Xiaomi Mi Router 4A (100M Edition)";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x400>;
> + };
> +
> + aliases {
> + led-boot = &power_yellow;
> + led-failsafe = &power_yellow;
> + led-running = &power_blue;
> + led-upgrade = &power_yellow;
> + };

This might be a matter of personal preference, but i would use the blue
indicator for led-boot instead of the yellow one.

> +
> + gpio-leds {

Rename the node (not the compatible) from 'gpio-leds' to 'leds'.

> + compatible = "gpio-leds";
> +
> + power_blue: power_blue {
> + label = "mir4a-100m:blue:power";
> + gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + power_yellow: power_yellow {
> + label = "mir4a-100m:yellow:power";
> + gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio-keys {

Rename the node (not the compatible) from 'gpio-keys' to 'keys'.

> + compatible = "gpio-keys-polled";
> + poll-interval = <20>;
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
> +

[OpenWrt-Devel] [PATCH] ramips: fix R6120 factory image

2019-05-09 Thread David Bauer

The factory firmware omits the JFFS2 end-marker while flashing via
web-interface. Add a 64k padding after the marker fixes this problem.

When the end-marker is not present, OpenWRT won't save the overlayfs
after initial flash.

Reported-by: Andreas Ziegler 
Signed-off-by: David Bauer 
---
 target/linux/ramips/image/mt76x8.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ramips/image/mt76x8.mk 
b/target/linux/ramips/image/mt76x8.mk
index 571ddf3d51..ba3354a8a6 100644
--- a/target/linux/ramips/image/mt76x8.mk
+++ b/target/linux/ramips/image/mt76x8.mk
@@ -135,7 +135,7 @@ define Device/netgear_r6120
   IMAGES += factory.img
   IMAGE/default := append-kernel | pad-to (BLOCKSIZE)| append-rootfs | 
pad-rootfs
   IMAGE/sysupgrade.bin := $$(IMAGE/default) | append-metadata | check-size 
(IMAGE_SIZE)
-  IMAGE/factory.img := pad-extra 576k | $$(IMAGE/default) | \
+  IMAGE/factory.img := pad-extra 576k | $$(IMAGE/default) | pad-to 
(BLOCKSIZE) | \
sercom-footer | pad-to 128 | zip R6120.bin | sercom-seal
 endef
 TARGET_DEVICES += netgear_r6120
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Add missing read-only properties

2019-05-10 Thread David Bauer

Hello Adrian,

On 09.05.19 13:50, Adrian Schmutzler wrote:
> The read-only properties for non-firmware partitions seem to have
> been assigned rather randomly.
> I went through the DTS files in ath79 and assigned the read-only
> to all partitions that seem to require protection.
> diff --git a/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts 
> b/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
> index 0875c319b9..c5b4775167 100644
> --- a/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
> +++ b/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
> @@ -100,6 +100,7 @@
>   partition@4 {
>   label = "u-boot-env";
>   reg = <0x04 0x01>;
> + read-only;
>   };
>  
>   partition@5 {
> diff --git a/target/linux/ath79/dts/qca9558_ocedo_koala.dts 
> b/target/linux/ath79/dts/qca9558_ocedo_koala.dts
> index 23835492a3..2b861ec8c0 100644
> --- a/target/linux/ath79/dts/qca9558_ocedo_koala.dts
> +++ b/target/linux/ath79/dts/qca9558_ocedo_koala.dts
> @@ -95,6 +95,7 @@
>   partition@4 {
>   label = "u-boot-env";
>   reg = <0x04 0x01>;
> + read-only;
>   };
>  
>   partition@5 {
> diff --git a/target/linux/ath79/dts/qca9558_ocedo_ursus.dts 
> b/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
> index 1a92da3946..926cc70e4d 100644
> --- a/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
> +++ b/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
> @@ -68,6 +68,7 @@
>   partition@4 {
>   label = "u-boot-env";
>   reg = <0x04 0x01>;
> + read-only;
>   };
>  
>   partition@5 {


This would break the current flashing instructions, which require to set
the correct partition to boot from the initramfs. [0]

I would prefer not to add read-only flags on uboot-environment without a
real reason. However, I'm fine with adding read-only on ART partitions.

[0]
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c4931713df8ffb3c4e5c1be7d0b6d4aa96a7dd4c

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

2019-06-11 Thread David Bauer

Hello,

On 05.06.19 22:23, Christian Lamparter wrote:
> I had to attach the patch as a file since gmail's webmail interface now seems 
> to
> eat all the tabs. I hope this still gets through.

I ran into problems booting multiple QCA9558 boards, namely the OCEDO
Koala and the devolo WiFi pro 1200e with the current master. Both
devices always go into failsafe mode when powering on.

I haven't dug deeper into this issue, but reverting 6c5bfaac84 leads
into both boards booting normally.

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

2019-06-13 Thread David Bauer

Hello Petr,

On 13.06.19 21:50, Petr Štetiar wrote:
> David Bauer  [2019-06-11 23:52:46]:
> 
> Hi,
> 
>> I ran into problems booting multiple QCA9558 boards, namely the OCEDO
>> Koala and the devolo WiFi pro 1200e with the current master. Both
>> devices always go into failsafe mode when powering on.
> 
> ar71xx or ath79? Can you test if it happens also with the interrupt based
> `gpio-keys` variant?

I did some further testing, the issue on my Koala was a hardware fault
(the reset switch was physically broken m( ). With the hardware button
fixed, it does not show this behavior.

This was expected though as it uses polled gpio-keys instead of the
interrupt based ones.

The devolo WiFi pro 1200e is ath79 with the interrupt-based gpio-keys.
The issue is not present when using polled gpio-keys. The device does
not go into failsafe when using polled GPIO keys.

> 
>> I haven't dug deeper into this issue, but reverting 6c5bfaac84 leads
>> into both boards booting normally.
> 
> could you please compile kernel with `CONFIG_KERNEL_DYNAMIC_DEBUG=y` and then
> add to the kernel cmdline `gpio_button_hotplug.dyndbg='file gpio-button* +p'`
> (or to modprobe args) and provide the output?

I did some further testing and i think i've found the culprit - On
probe the GPIO reads high. Shortly after probe, an interrupt is received
and the GPIO switched to low which triggers a button event and therefore
sends the device into failsafe. I suppose the GPIO has just switched to
a stable state which triggers this interrupt.

I've prepared a patch which reads the initial state after the debounce
interval on probe to ensure only real button presses will trigger an
event. I will send this patch shortly.

Best wishes
David

> 
> Thanks.
> 
> -- ynezz
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: read initial state

2019-06-13 Thread David Bauer

This commit reads the initial state for interrupt triggered gpio-keys.
Without this commit, the switch to the initial stable input-state
triggers a button-event. Button events are now only triggered when the
button state differs fromt the initial state.

Effectively, this reverts commit 6c5bfaac84b0 ("gpio-button-hotplug:
gpio-keys: fix always missing first event"), but in addition, we read
the initial button state on driver probe. This commit caused some devices
to enter failsafe mode every time when booting.

Run-tested on devolo WiFi pro 1200e & 1200i.

Signed-off-by: David Bauer 
---
 .../src/gpio-button-hotplug.c  | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
index daa4b2a4f7..5bc783e015 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
@@ -341,8 +341,16 @@ static void gpio_keys_irq_work_func(struct work_struct 
*work)
struct gpio_keys_button_data *bdata = container_of(work,
struct gpio_keys_button_data, work.work);
 
-   button_hotplug_event(bdata, bdata->b->type ?: EV_KEY,
-gpio_button_get_value(bdata));
+   int state = gpio_button_get_value(bdata);
+
+   if (state != bdata->last_state) {
+   unsigned int type = bdata->b->type ?: EV_KEY;
+
+   if (bdata->last_state != -1 || type == EV_SW)
+   button_hotplug_event(bdata, type, state);
+
+   bdata->last_state = state;
+   }
 }
 
 static irqreturn_t button_handle_irq(int irq, void *_bdata)
@@ -607,6 +615,9 @@ static int gpio_keys_probe(struct platform_device *pdev)
 
INIT_DELAYED_WORK(&bdata->work, gpio_keys_irq_work_func);
 
+   schedule_delayed_work(&bdata->work,
+ msecs_to_jiffies(bdata->software_debounce));
+
ret = devm_request_threaded_irq(&pdev->dev,
bdata->irq, NULL, button_handle_irq,
irqflags, dev_name(&pdev->dev), bdata);
@@ -620,9 +631,6 @@ static int gpio_keys_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "gpio:%d has irq:%d\n",
button->gpio, bdata->irq);
}
-
-   if (bdata->b->type == EV_SW)
-   button_hotplug_event(bdata, EV_SW, 
gpio_button_get_value(bdata));
}
 
return 0;
-- 
2.22.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: read initial state

2019-06-16 Thread David Bauer

Hello Linus,

On 15.06.19 10:26, Linus Walleij wrote:
> Without any detailed knowledge I'd say the most common cause
> is the underlying GPIO chip implementation. There are often transient
> line events when the system is powered up and initialized and it
> is often necessary for the gpio_chip driver to clear any interrupt
> flags in hardware before setting up the gpio chip, especially the
> irqchip portions of it.
> 
> I tried to half-guess what gpio chip this is using and since it
> is WiFi pro 1200e I guess ths gpio driver is
> drivers/gpio-ath79.c which does indeed initialize an
> irqchip without clearing the interrupts first.
> 
> Can you try this patch, if this solves the problem I will commit
> it upstream as well:

Thanks for your patch. I've tested it on my device but sadly, i still
see the ghost presses.

It seems the input is indeed not stable after setting the GPIO
direction. With the following patch applied, i get zero ghost presses
and the buttons work as expected. However I'm not sure if this approach
is the right one to fix the underlying issue.


>From 2b0c12c9c9aa1955a1fa42234597601148bcf548 Mon Sep 17 00:00:00 2001
From: David Bauer 
Date: Sun, 16 Jun 2019 16:20:49 +0200
Subject: [PATCH] gpio: ath79: circumvent ghost interrupts

The ath79 gpio driver may emit "ghost interrupts" in case the interrupts
are registered directly after setting the GPIO direction.

This patch adds a short delay before activating interrupts on any line
to make sure no ghost interrupts will be registered.

Signed-off-by: David Bauer 
---
 drivers/gpio/gpio-ath79.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
index 0a553d676042..238f5bdbe7a8 100644
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -12,6 +12,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -96,6 +97,12 @@ static void ath79_gpio_irq_enable(struct irq_data *data)
u32 mask = BIT(irqd_to_hwirq(data));
unsigned long flags;
 
+   /*
+* The input can be unstable after configuring GPIO direction.
+* Wait a bit to assert the input is stable.
+*/
+   msleep(25);
+
raw_spin_lock_irqsave(&ctrl->lock, flags);
ath79_gpio_update_bits(ctrl, AR71XX_GPIO_REG_INT_ENABLE, mask, mask);
ath79_gpio_update_bits(ctrl, AR71XX_GPIO_REG_INT_MASK, mask, mask);
-- 
2.22.0


Best wishes
David





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: read initial state

2019-06-17 Thread David Bauer

Hello Linus,

On 17.06.19 01:42, Linus Walleij wrote:
> It shows what the problem is for sure. delays are forbidden in
> irqchip callback functions since they are all called from
> IRQ context with IRQs disabled though.

Good to know, thanks!

>> @@ -96,6 +97,12 @@ static void ath79_gpio_irq_enable(struct irq_data *data)
> 
>> u32 mask = BIT(irqd_to_hwirq(data));
>> unsigned long flags;
>>
>> +   /*
>> +* The input can be unstable after configuring GPIO direction.
>> +* Wait a bit to assert the input is stable.
>> +*/
>> +   msleep(25);
>> +
>> raw_spin_lock_irqsave(&ctrl->lock, flags);
>> ath79_gpio_update_bits(ctrl, AR71XX_GPIO_REG_INT_ENABLE, mask, mask);
>> ath79_gpio_update_bits(ctrl, AR71XX_GPIO_REG_INT_MASK, mask, mask);
> 
> After this and before the raw_spin_unlock() try to read the status
> register until it
> eads zero for the requested IRQ:
> 
> while (ath79_gpio_read(ctrl, AR71XX_GPIO_REG_INT_PENDING) & mask) {}
> 
> This way we wait for the status to go low before we allow any IRQs to
> fire after enableing.

Thanks for your suggestion. However, with your suggestion i still see the ghost 
press on bootup :(
Just to clarify - I do not see multiple ghost presses, just one. The button is 
active low. 

After configuring the GPIO direction to input, the value of the GPIO reads 0 
(pressed).
After ~10ms, this changes to 1 (not pressed). I suppose your proposed solution 
does not work
as interrupts are only registered after configuring the GPIO line as input and 
the GPIO line
changes after registering the interrupt. So we are reading the interrupt state 
too early.

(I might have repeated myself with this explanation but I was not sure if I've 
given
all the relevant facts "in one piece" yet)

I'm not sure where we can go from here. I have two ideas,
but I'm not sure if they are feasible:

First:
If delays are allowed there, we could add a 20ms delay when configuring the 
GPIO line
direction as input. This way we could also assure the line is stable for 
"normal" value
reads. We would need to override the direction_input method provided by 
gpio-mmio for this.

Second:
We could store the kernel uptime together with the GPIO line and for how long 
interrupts
should be ignored within the driver. This could be checked when an interrupt is 
fired.

I do not really like the second idea as dropping interrupts without feedback is 
probably not
what we want.

Do you have another idea how we could solve this?

Best wishes
David

> 
> Maybe not so good since we may want to turn on IRQs that are asserted
> at some point, but worth a try.
> 
> Yours,
> Linus Walleij
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: read initial state

2019-06-18 Thread David Bauer

Hello Linus,

On 17.06.19 22:26, Linus Walleij wrote:
> Hm this sounds like something that would be solved by debouncing.
> It might even be a bounce effect of sorts, it can be a capacitance
> or something in the mechanics causing this.
> 
> If you look in:
> drivers/input/keyboard/gpio_keys.c
> you will see that GPIO keys in the input subsystem has debouncing
> support. I guess something like this needs to be copied over to
> the OpenWrt netlink thingie.

Thanks for your evaluation. So the underlying GPIO driver does not seem to be 
the
culprit here.

> If the GPIO driver supports debounce (some do, it doesn't look like
> the ath79 does) that can be utilized. If someone can double-check
> the ath79 datasheet to check if it can do debounce that'd be great
> because it would solve this in hardware.

I've had a short look on the QCA9558 datasheet and it doesn't seem
like the driver supports debouncing.

>> If delays are allowed there, we could add a 20ms delay when configuring the 
>> GPIO line
>> direction as input. This way we could also assure the line is stable for 
>> "normal" value
>> reads. We would need to override the direction_input method provided by 
>> gpio-mmio for this.
> 
> That's like an initial debounce.

I've had a deeper look on

drivers/input/keyboard/gpio_keys.c

and i think I've understood the problem now as we finally found the "right 
level" of
the problem ;)

Upstream gpio_keys reports current state of all buttons on driver probe in
gpio_keys_open()

/* Report current state of buttons that are connected to GPIOs */
gpio_keys_report_state(ddata);

When an interrupt is handled, a job is created (or it's delay modified).
So the job is not executed if a GPIO is unstable for the debounce interval.

The job executes gpio_keys_gpio_work_func() as soon as it's state is stable,
which reports an input_event() in gpio_keys_gpio_report_event().

This event however is not handed down in the input subsystem if the value equals
the last state. As we are not using the input subsystem, we need to keep track 
of
the last button state ourselves.

Correct me if I'm wrong with anything above. :)

@Christian
If I'm not mistaken is kinda what I've implemented with my initial patch.
However, i think the logic is better placed elsewhere. I will send
a reworked patch shortly.

> 
>> Second:
>> We could store the kernel uptime together with the GPIO line and for how 
>> long interrupts
>> should be ignored within the driver. This could be checked when an interrupt 
>> is fired.
> 
> The third alternative is common software debounce. I.e. wait for any
> value to stabilize before reporting keys. Some extra interrupts more
> or less doesn't matter, we just frame it with some timer.
> 
>> I do not really like the second idea as dropping interrupts without feedback 
>> is probably not
>> what we want.
> 
> I think it makes a lot of sense on mechanical pushbuttons to
> implement generic debounce.

This is, however, not the job of the GPIO driver or is it?

Best wishes
David

> Yours,
> Linus Walleij
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] gpio-button-hotplug: mind debounce interval consistently

2019-06-18 Thread David Bauer

This patch implements consistent handling of the debounce interval set
for the GPIO buttons. Hotplug events will only be fired if

1. It's the initial stable state (no state-change for duration of the
debounce interval) for a switch. Buttons will not trigger an event for
the initial stable state.

2. The input changes it's state and remains stable for the debounce
interval.

Prior to this patch, this was handled inconsistently for interrupt-based
an polled gpio-keys. We unify the shared logic in button_hotplug_event
and modify both implementations to read the initial state.

Run-tested for 'gpio-keys' and 'gpio-keys-polled' on

 - devolo WiFi pro 1200e
 - devolo WiFi pro 1750c
 - devolo WiFi pro 1750x

Signed-off-by: David Bauer 
---
 .../src/gpio-button-hotplug.c | 42 +--
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
index e63d414284..25150344e0 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
@@ -241,6 +241,7 @@ static int button_get_index(unsigned int code)
 static void button_hotplug_event(struct gpio_keys_button_data *data,
   unsigned int type, int value)
 {
+   int last_state = data->last_state;
struct bh_priv *priv = &data->bh;
unsigned long seen = jiffies;
int btn;
@@ -250,6 +251,14 @@ static void button_hotplug_event(struct 
gpio_keys_button_data *data,
if ((type != EV_KEY) && (type != EV_SW))
return;
 
+   if (value == last_state)
+   return;
+
+   data->last_state = value;
+
+   if (last_state == -1 && type != EV_SW)
+   return;
+
btn = button_get_index(data->b->code);
if (btn < 0)
return;
@@ -285,22 +294,14 @@ static int gpio_button_get_value(struct 
gpio_keys_button_data *bdata)
 
 static void gpio_keys_polled_check_state(struct gpio_keys_button_data *bdata)
 {
-   int state = gpio_button_get_value(bdata);
-
-   if (state != bdata->last_state) {
-   unsigned int type = bdata->b->type ?: EV_KEY;
-
-   if (bdata->count < bdata->threshold) {
-   bdata->count++;
-   return;
-   }
-
-   if (bdata->last_state != -1 || type == EV_SW)
-   button_hotplug_event(bdata, type, state);
-
-   bdata->last_state = state;
+   if (bdata->count < bdata->threshold) {
+   bdata->count++;
+   return;
}
 
+   button_hotplug_event(bdata, bdata->b->type ?: EV_KEY,
+   gpio_button_get_value(bdata));
+
bdata->count = 0;
 }
 
@@ -351,8 +352,8 @@ static irqreturn_t button_handle_irq(int irq, void *_bdata)
struct gpio_keys_button_data *bdata =
(struct gpio_keys_button_data *) _bdata;
 
-   schedule_delayed_work(&bdata->work,
- msecs_to_jiffies(bdata->software_debounce));
+   mod_delayed_work(system_wq, &bdata->work,
+msecs_to_jiffies(bdata->software_debounce));
 
return IRQ_HANDLED;
 }
@@ -608,6 +609,9 @@ static int gpio_keys_probe(struct platform_device *pdev)
 
INIT_DELAYED_WORK(&bdata->work, gpio_keys_irq_work_func);
 
+   schedule_delayed_work(&bdata->work,
+ 
msecs_to_jiffies(bdata->software_debounce));
+
ret = devm_request_threaded_irq(&pdev->dev,
bdata->irq, NULL, button_handle_irq,
irqflags, dev_name(&pdev->dev), bdata);
@@ -621,9 +625,6 @@ static int gpio_keys_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "gpio:%d has irq:%d\n",
button->gpio, bdata->irq);
}
-
-   if (bdata->b->type == EV_SW)
-   button_hotplug_event(bdata, EV_SW, 
gpio_button_get_value(bdata));
}
 
return 0;
@@ -648,9 +649,6 @@ static int gpio_keys_polled_probe(struct platform_device 
*pdev)
if (pdata->enable)
pdata->enable(bdev->dev);
 
-   for (i = 0; i < pdata->nbuttons; i++)
-   gpio_keys_polled_check_state(&bdev->data[i]);
-
gpio_keys_polled_queue_work(bdev);
 
return ret;
-- 
2.22.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: correct various phy-mode properties

2019-06-18 Thread David Bauer

Upstream commit 6d4cd04 changes how the internal delays of the AR803x
based PHYs are enabled. With this commit, all internal delays are
disabled on driver probe and enabled based on the 'phy-mode' property in
the device-tree.

Before this commit, the RX delay was always enabled upon soft-reset
while the TX delay retained it's previous state. A hard reset enabled
the RX delay while the TX delay was disabled.

Because of this inconsistency, wrongly specified PHY-modes were working
correctly while the hardware was in a different state.

Fix the PHY-modes of some affected devices (and clean up misplaced
properties along the way) to keep the devices working flawlessly with
kernels >= 5.1.

Signed-off-by: David Bauer 
---
 target/linux/ath79/dts/ar9344_ocedo_raccoon.dts| 3 +--
 target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts | 1 +
 target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts | 4 
 target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts | 1 +
 target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi | 1 +
 target/linux/ath79/dts/qca9558_ocedo_koala.dts | 2 --
 6 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts 
b/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
index a1a912383f..812da3dea5 100644
--- a/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
+++ b/target/linux/ath79/dts/ar9344_ocedo_raccoon.dts
@@ -162,7 +162,6 @@
 
phy0: ethernet-phy@0 {
reg = <0>;
-   phy-mode = "rgmii";
};
 };
 
@@ -173,6 +172,6 @@
 
mtd-mac-address = <&art 0x0>;
 
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-handle = <&phy0>;
 };
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts 
b/target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts
index 5900d8b487..a844ce777c 100644
--- a/target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts
@@ -40,6 +40,7 @@
 
 ð0 {
pll-data = <0xbe00 0x8101 0x80001313>;
+   phy-mode = "rgmii-id";
 };
 
 &gmac_config {
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts 
b/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts
index b5a2954406..567f3c9ee4 100644
--- a/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts
@@ -38,6 +38,10 @@
};
 };
 
+ð0 {
+   phy-mode = "rgmii-id";
+};
+
 &gmac_config {
rxdv-delay = <3>;
rxd-delay = <3>;
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts 
b/target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts
index bd3702eb36..e0bdd20937 100644
--- a/target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts
@@ -40,6 +40,7 @@
 
 ð0 {
pll-data = <0xbe00 0x8101 0x80001313>;
+   phy-mode = "rgmii-id";
 };
 
 &gmac_config {
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi 
b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
index 9937186b1e..cfd43c8e8a 100644
--- a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
@@ -115,6 +115,7 @@
 
mtd-mac-address = <&art 0x00>;
phy-handle = <&phy4>;
+   phy-mode = "rgmii-rxid";
pll-data = <0xae00 0x8101 0x80001313>;
 
gmac_config: gmac-config {
diff --git a/target/linux/ath79/dts/qca9558_ocedo_koala.dts 
b/target/linux/ath79/dts/qca9558_ocedo_koala.dts
index 23835492a3..a80155b08c 100644
--- a/target/linux/ath79/dts/qca9558_ocedo_koala.dts
+++ b/target/linux/ath79/dts/qca9558_ocedo_koala.dts
@@ -142,8 +142,6 @@
 
phy5: ethernet-phy@5 {
reg = <5>;
-   phy-mode = "rgmii-rxid";
-
at803x-disable-smarteee;
};
 };
-- 
2.22.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] gpio-button-hotplug: mind debounce interval consistently

2019-06-20 Thread David Bauer

Hello Christian,

On 20.06.19 17:21, Christian Lamparter wrote:
> On Tuesday, June 18, 2019 1:06:12 PM CEST David Bauer wrote:
>> This patch implements consistent handling of the debounce interval set
>> for the GPIO buttons. Hotplug events will only be fired if
>>
>> 1. It's the initial stable state (no state-change for duration of the
>> debounce interval) for a switch. Buttons will not trigger an event for
>> the initial stable state.
>>
>> 2. The input changes it's state and remains stable for the debounce
>> interval.
>>
>> Prior to this patch, this was handled inconsistently for interrupt-based
>> an polled gpio-keys. We unify the shared logic in button_hotplug_event
>> and modify both implementations to read the initial state.
>>
>> Run-tested for 'gpio-keys' and 'gpio-keys-polled' on
>>
>>  - devolo WiFi pro 1200e
>>  - devolo WiFi pro 1750c
>>  - devolo WiFi pro 1750x
>>
>> Signed-off-by: David Bauer 
>> ---
>>  .../src/gpio-button-hotplug.c | 42 +--
>>  1 file changed, 20 insertions(+), 22 deletions(-)
>>
>> diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
>> b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
>> index e63d414284..25150344e0 100644
>> --- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
>> +++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
>> @@ -241,6 +241,7 @@ static int button_get_index(unsigned int code)
>>  static void button_hotplug_event(struct gpio_keys_button_data *data,
>> unsigned int type, int value)
>>  {
>> +int last_state = data->last_state;
>>  struct bh_priv *priv = &data->bh;
>>  unsigned long seen = jiffies;
>>  int btn;
>> @@ -250,6 +251,14 @@ static void button_hotplug_event(struct 
>> gpio_keys_button_data *data,
>>  if ((type != EV_KEY) && (type != EV_SW))
>>  return;
>>  
>> +if (value == last_state)
>> +return;
>> +
>> +data->last_state = value;
>> +
>> +if (last_state == -1 && type != EV_SW)
>> +return;
>> +
>>  btn = button_get_index(data->b->code);
>>  if (btn < 0)
>>  return;
>> @@ -285,22 +294,14 @@ static int gpio_button_get_value(struct 
>> gpio_keys_button_data *bdata)
>>  
>>  static void gpio_keys_polled_check_state(struct gpio_keys_button_data 
>> *bdata)
>>  {
>> -int state = gpio_button_get_value(bdata);
>> -
>> -if (state != bdata->last_state) {
>> -unsigned int type = bdata->b->type ?: EV_KEY;
>> -
>> -if (bdata->count < bdata->threshold) {
>> -bdata->count++;
>> -return;
>> -}
>> -
>> -if (bdata->last_state != -1 || type == EV_SW)
>> -button_hotplug_event(bdata, type, state);
>> -
>> -bdata->last_state = state;
>> +if (bdata->count < bdata->threshold) {
>> +bdata->count++;
>> +return;
>>  }
>>  
>> +button_hotplug_event(bdata, bdata->b->type ?: EV_KEY,
>> +gpio_button_get_value(bdata));
>> +
>>  bdata->count = 0;
>>  }
> Doesn't this change the logic of the gpio-key-polled software-debounce
> a bit too aggressivly?
> 
> Previously, for the button event to happen the button new state had to
> be stable for bdata->threshold counts.
> 
> Whereas now, bdata->count is counted upwards on every "tick" and once
> bdata->count == bdata->threshold matches the "current state" gets passed
> on. This seems that it would interfere with the debounce since a signal
> doesn't have to be asserted stable for the whole duration now, instead
> it now just has to show up "just before" the
> bdata->count == bdata->threshold tick in order to be noticed. 

You are right, i will rework this part.

>> @@ -351,8 +352,8 @@ static irqreturn_t button_handle_irq(int irq, void 
>> *_bdata)
>>  struct gpio_keys_button_data *bdata =
>>  (struct gpio_keys_button_data *) _bdata;
>>  
>> -schedule_delayed_work(&bdata->work,
>> -  msecs_to_jiffies(bdata->software_debounce));
>> +mod_delayed_work(system_wq, &bdata->work,
>> +

[OpenWrt-Devel] [PATCH] ramips: add support for ASUS RT-AC57U

2019-06-24 Thread David Bauer

SoC:   MediaTek MT7621AT
RAM:   128M (Winbond W631GG6KB-15)
FLASH: 16MB (Spansion S25FL128SA)
WiFi:  MediaTek MT7603EN bgn 2SS
WiFi:  MediaTek MT7612EN nac 2SS
BTN:   Reset - WPS
LED:- Power
- LAN {1-4}
- WAN
- WiFi 2.4 GHz
- WiFi 5 GHz
- USB
UART:  UART is present next to the Power LED.
   TX - RX - GND - 3V3 / 57600-8N1
   3V3 is the nearest one to the Power LED.

Installation

Via TFTP:
1. Set your computers IP-Address to 192.168.1.75.
2. Power up the Router with the Reset button pressed.
3. Release the Reset button after 5 seconds.
4. Upload OpenWRT sysupgrade image via TFTP:
 > tftp -4 -v -m binary 192.168.1.1 -c put 

Via SSH:
Note: User/password for SSH is identical with the one used in the
Web-interface.
1. Complete the initial setup wizard.
2. Activate SSH under "Administration" -> "System".
3. Transfer the OpenWrt sysupgrade image via scp:
 > scp owrt.bin admin@192.168.1.1:/tmp
4. Connect via SSH to the router.
 > ssh admin@192.168.1.1
5. Write the OpenWrt image to flash.
 > mtd-write -i /tmp/owrt.bin -d linux
6. Reboot the router
 > reboot

Signed-off-by: David Bauer 
---
 .../ramips/base-files/etc/board.d/02_network  |  10 +-
 target/linux/ramips/dts/RT-AC57U.dts  | 150 ++
 target/linux/ramips/image/mt7621.mk   |   8 +
 3 files changed, 164 insertions(+), 4 deletions(-)
 create mode 100644 target/linux/ramips/dts/RT-AC57U.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 52204eacbf..1efbbf586e 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -215,6 +215,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "6t@eth0"
;;
+   asus,rt-ac57u|\
atp-52b|\
awm002-evb-4M|\
awm002-evb-8M|\
@@ -497,6 +498,11 @@ ramips_setup_macs()
wmdr-143n)
lan_mac=$(cat /sys/class/net/eth0/address)
;;
+   asus,rt-ac57u|\
+   vr500)
+   lan_mac=$(mtd_get_mac_binary factory 57344)
+   wan_mac=$(mtd_get_mac_binary factory 57350)
+   ;;
carambola|\
freestation5|\
w502u|\
@@ -649,10 +655,6 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_ascii u-boot-env LAN_MAC_ADDR)
wan_mac=$(mtd_get_mac_ascii u-boot-env WAN_MAC_ADDR)
;;
-   vr500)
-   lan_mac=$(mtd_get_mac_binary factory 57344)
-   wan_mac=$(mtd_get_mac_binary factory 57350)
-   ;;
w306r-v20)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 5)
diff --git a/target/linux/ramips/dts/RT-AC57U.dts 
b/target/linux/ramips/dts/RT-AC57U.dts
new file mode 100644
index 00..c9eb2a5223
--- /dev/null
+++ b/target/linux/ramips/dts/RT-AC57U.dts
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asus,rt-ac57u", "ralink,mt7620a-soc";
+   model = "ASUS RT-AC57U";
+
+   aliases {
+   led-boot = &led_power;
+   led-failsafe = &led_power;
+   led-running = &led_power;
+   led-upgrade = &led_power;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "rt-ac57u:blue:power";
+   gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   };
+
+   usb {
+   label = "rt-ac57u:blue:usb";
+   gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+   trigger-sources = <&ehci_port2>;
+   linux,default-trigger = "usbport";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys-polled";
+   poll-interval = <20>;
+
+   wps {
+   label = "wps";
+   gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   };
+
+   reset {
+   label = "reset";
+   gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+

Re: [OpenWrt-Devel] [PATCH] ramips: add support for ASUS RT-AC57U

2019-06-24 Thread David Bauer


Hello Christian,

On 24.06.19 21:19, Christian Lamparter wrote:

On Monday, June 24, 2019 2:31:57 PM CEST David Bauer wrote:

Some comments below.


diff --git a/target/linux/ramips/dts/RT-AC57U.dts 
b/target/linux/ramips/dts/RT-AC57U.dts
--- /dev/null
+++ b/target/linux/ramips/dts/RT-AC57U.dts
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asus,rt-ac57u", "ralink,mt7620a-soc";

"mediatek,mt7621-soc" ?


Whoops, you are right.  I will change this to

"mediatek,mt7621-soc"


(From what I know, the machine compatible isn't important
but the ralink,mt7620a-soc looks odd)


+   model = "ASUS RT-AC57U";
+
+   aliases {
+   led-boot = &led_power;
+   led-failsafe = &led_power;
+   led-running = &led_power;
+   led-upgrade = &led_power;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "rt-ac57u:blue:power";
+   gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   };
+
+   usb {
+   label = "rt-ac57u:blue:usb";
+   gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+   trigger-sources = <&ehci_port2>;
+   linux,default-trigger = "usbport";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys-polled";

The MT7261 should support interrupt-supported gpio-keys.


I will try your suggestion, however i suspect we will face the same 
issues we have on the ath79 platform currently.


While we are at it - i haven't forgotten about this one but due to 
hardware issues, testing is currently a bit cumbersome.





+   poll-interval = <20>;
+
+   wps {
+   label = "wps";
+   gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   };
+
+   reset {
+   label = "reset";
+   gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   led-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "LED-Power";
+   gpio = <&gpio1 14 GPIO_ACTIVE_LOW>;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;

Just curious, is this regulator related to ASUS "Night mode"
feature? Also did you measure the voltages or is there a
3v3 LED driver on the board?


I suppose it is as the PHY LEDs seem to be controlled in hardware and so 
can't be toggled from software. The voltage is the one that goes to the 
LEDs.


Thinking about this, do you think we are better off using a "fake" LED 
for this that we set default on? A user is then able to turn off even 
the LEDs we can't control in software. We could name it something like 
"rt-ac57u:power:led". However, this would violate the naming scheme.


What do you think?




+   };
+};
+
+&spi0 {
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;

I haven't said much about the spi-max-frequencies before
but from what I know thanks to the threads like
"ramips: Increase GB-PC1 SPI frequency to 80MHz" the original
these values are off. And once the target switches to 4.19 (and
uses the upstream mt7621a.dtsi + spi-driver) this needs to be
reworked on all devices I think


I just head a quick look over this thread and the driver. I might be 
missing something, but shouldn't the spi bus run with 10 MHz in this case?


I don't doubt that we might be able to run higher frequencies, but the 
issue you pointed out in the thread seems to only apply to frequencies > 
25MHz.


Shall i test if the device runs with the current max of 25MHz and change 
the frequency accordingly?





+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+

[OpenWrt-Devel] [PATCH v2] gpio-button-hotplug: mind debounce interval consistently

2019-07-02 Thread David Bauer

This patch implements consistent handling of the debounce interval set
for the GPIO buttons. Hotplug events will only be fired if

1. It's the initial stable state (no state-change for duration of the
debounce interval) for a switch. Buttons will not trigger an event for
the initial stable state.

2. The input changes it's state and remains stable for the debounce
interval.

Prior to this patch, this was handled inconsistently for interrupt-based
an polled gpio-keys. We unify the shared logic in button_hotplug_event
and modify both implementations to read the initial state.

Run-tested for 'gpio-keys' and 'gpio-keys-polled' on

 - devolo WiFi pro 1200e
 - devolo WiFi pro 1750c
 - devolo WiFi pro 1750x

Signed-off-by: David Bauer 
---
v2:
 - Debounce interval is now correctly considered  for polled GPIO-keys

 .../src/gpio-button-hotplug.c | 40 ---
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
index e63d414284..67b4549cc2 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
@@ -57,6 +57,7 @@ struct bh_map {
 struct gpio_keys_button_data {
struct delayed_work work;
struct bh_priv bh;
+   int has_initial_state;
int last_state;
int count;
int threshold;
@@ -241,6 +242,7 @@ static int button_get_index(unsigned int code)
 static void button_hotplug_event(struct gpio_keys_button_data *data,
   unsigned int type, int value)
 {
+   int last_state = data->last_state;
struct bh_priv *priv = &data->bh;
unsigned long seen = jiffies;
int btn;
@@ -250,6 +252,15 @@ static void button_hotplug_event(struct 
gpio_keys_button_data *data,
if ((type != EV_KEY) && (type != EV_SW))
return;
 
+   data->last_state = value;
+
+   if (!data->has_initial_state) {
+   data->has_initial_state = 1;
+   if (type != EV_SW)
+   return;
+   } else if (value == last_state)
+   return;
+
btn = button_get_index(data->b->code);
if (btn < 0)
return;
@@ -285,19 +296,22 @@ static int gpio_button_get_value(struct 
gpio_keys_button_data *bdata)
 
 static void gpio_keys_polled_check_state(struct gpio_keys_button_data *bdata)
 {
+   int has_initial_state = bdata->has_initial_state;
+   int last_state = bdata->last_state;
int state = gpio_button_get_value(bdata);
 
-   if (state != bdata->last_state) {
-   unsigned int type = bdata->b->type ?: EV_KEY;
+   if (!has_initial_state && bdata->last_state == -1) {
+   bdata->last_state = state;
+   return;
+   }
 
+   if (state != last_state || (!has_initial_state && last_state == state)) 
{
if (bdata->count < bdata->threshold) {
bdata->count++;
return;
}
-
-   if (bdata->last_state != -1 || type == EV_SW)
-   button_hotplug_event(bdata, type, state);
-
+   button_hotplug_event(bdata, bdata->b->type ?: EV_KEY, state);
+   } else if (!has_initial_state && last_state != state) {
bdata->last_state = state;
}
 
@@ -351,8 +365,8 @@ static irqreturn_t button_handle_irq(int irq, void *_bdata)
struct gpio_keys_button_data *bdata =
(struct gpio_keys_button_data *) _bdata;
 
-   schedule_delayed_work(&bdata->work,
- msecs_to_jiffies(bdata->software_debounce));
+   mod_delayed_work(system_wq, &bdata->work,
+msecs_to_jiffies(bdata->software_debounce));
 
return IRQ_HANDLED;
 }
@@ -540,6 +554,7 @@ static int gpio_keys_button_probe(struct platform_device 
*pdev,
}
 
bdata->can_sleep = gpio_cansleep(gpio);
+   bdata->has_initial_state = 0;
bdata->last_state = -1;
 
if (bdev->polled) {
@@ -608,6 +623,9 @@ static int gpio_keys_probe(struct platform_device *pdev)
 
INIT_DELAYED_WORK(&bdata->work, gpio_keys_irq_work_func);
 
+   schedule_delayed_work(&bdata->work,
+ 
msecs_to_jiffies(bdata->software_debounce));
+
ret = devm_request_threaded_irq(&pdev->dev,
bdata->irq, NULL, button_handle_irq,
irqflags, dev_name(&pdev->dev), bdata);
@@ -621,9 +639,6 @@ static int gpio_keys_probe(struct platform_device *pdev)
dev_dbg(&pdev

[OpenWrt-Devel] [PATCH v2] ramips: add support for ASUS RT-AC57U

2019-07-03 Thread David Bauer

SoC:   MediaTek MT7621AT
RAM:   128M (Winbond W631GG6KB-15)
FLASH: 16MB (Spansion S25FL128SA)
WiFi:  MediaTek MT7603EN bgn 2SS
WiFi:  MediaTek MT7612EN nac 2SS
BTN:   Reset - WPS
LED:- Power
- LAN {1-4}
- WAN
- WiFi 2.4 GHz
- WiFi 5 GHz
- USB
UART:  UART is present next to the Power LED.
   TX - RX - GND - 3V3 / 57600-8N1
   3V3 is the nearest one to the Power LED.

Installation

Via TFTP:
1. Set your computers IP-Address to 192.168.1.75.
2. Power up the Router with the Reset button pressed.
3. Release the Reset button after 5 seconds.
4. Upload OpenWRT sysupgrade image via TFTP:
 > tftp -4 -v -m binary 192.168.1.1 -c put 

Via SSH:
Note: User/password for SSH is identical with the one used in the
Web-interface.
1. Complete the initial setup wizard.
2. Activate SSH under "Administration" -> "System".
3. Transfer the OpenWrt sysupgrade image via scp:
 > scp owrt.bin admin@192.168.1.1:/tmp
4. Connect via SSH to the router.
 > ssh admin@192.168.1.1
5. Write the OpenWrt image to flash.
 > mtd-write -i /tmp/owrt.bin -d linux
6. Reboot the router
 > reboot

Signed-off-by: David Bauer 
---
v2:
 - Fixed SoC compatible
 - Switch to using interrupt-based gpio-keys

 .../ramips/base-files/etc/board.d/02_network  |  10 +-
 target/linux/ramips/dts/RT-AC57U.dts  | 153 ++
 target/linux/ramips/image/mt7621.mk   |   8 +
 3 files changed, 167 insertions(+), 4 deletions(-)
 create mode 100644 target/linux/ramips/dts/RT-AC57U.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index b13590566c..814f38bb07 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -219,6 +219,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "6t@eth0"
;;
+   asus,rt-ac57u|\
atp-52b|\
awm002-evb-4M|\
awm002-evb-8M|\
@@ -502,6 +503,11 @@ ramips_setup_macs()
wmdr-143n)
lan_mac=$(cat /sys/class/net/eth0/address)
;;
+   asus,rt-ac57u|\
+   vr500)
+   lan_mac=$(mtd_get_mac_binary factory 57344)
+   wan_mac=$(mtd_get_mac_binary factory 57350)
+   ;;
carambola|\
freestation5|\
w502u|\
@@ -654,10 +660,6 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_ascii u-boot-env LAN_MAC_ADDR)
wan_mac=$(mtd_get_mac_ascii u-boot-env WAN_MAC_ADDR)
;;
-   vr500)
-   lan_mac=$(mtd_get_mac_binary factory 57344)
-   wan_mac=$(mtd_get_mac_binary factory 57350)
-   ;;
w306r-v20)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 5)
diff --git a/target/linux/ramips/dts/RT-AC57U.dts 
b/target/linux/ramips/dts/RT-AC57U.dts
new file mode 100644
index 00..e757716ffb
--- /dev/null
+++ b/target/linux/ramips/dts/RT-AC57U.dts
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asus,rt-ac57u", "mediatek,mt7621-soc";
+   model = "ASUS RT-AC57U";
+
+   aliases {
+   led-boot = &led_power;
+   led-failsafe = &led_power;
+   led-running = &led_power;
+   led-upgrade = &led_power;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "rt-ac57u:blue:power";
+   gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   };
+
+   usb {
+   label = "rt-ac57u:blue:usb";
+   gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+   trigger-sources = <&ehci_port2>;
+   linux,default-trigger = "usbport";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   wps {
+   label = "wps";
+   gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   debounce-interval = <60>;
+   };
+
+   reset {
+   label = "reset";
+   gpios = <&g

Re: [OpenWrt-Devel] [PATCH v2] gpio-button-hotplug: mind debounce interval consistently

2019-07-09 Thread David Bauer

Hello Christian,

thanks for your reworked patch. I think i found two bugs around the debounce
interval for both flavors. I'll have to admit, they are both edgecases ;)

On 06.07.19 23:57, Christian Lamparter wrote
> -static void gpio_keys_polled_check_state(struct gpio_keys_button_data *bdata)
> +static void gpio_keys_handle_button(struct gpio_keys_button_data *bdata)
>   {
> + unsigned int type = bdata->b->type ?: EV_KEY;
>   int state = gpio_button_get_value(bdata);
> + unsigned long seen = jiffies;
>   
> - if (state != bdata->last_state) {
> - unsigned int type = bdata->b->type ?: EV_KEY;
> + pr_debug(PFX "event type=%u, code=%u, pressed=%d\n",
> +  type, bdata->b->code, state);
> +
> + /* is this the initialization state? */
> + if (bdata->last_state == -1) {
> + /*
> +  * Don't advertise unpressed buttons on initialization.
> +  * Just save their state and continue otherwise this
> +  * can cause OpenWrt to enter failsafe.
> +  */
> + if (type == EV_KEY && state == 0)
> + goto set_state;

As we are calling gpio_keys_handle_button every poll-interval, we need 
to make sure we save the initial state AFTER the button has been stable 
for the debounce interval. For irq-based keys we get this "for free" as 
we modify the execution timer for the irq handling function.

However, we need to track the button state for the polled GPIO keys, so 
we cannot piggy-back on the last_state for deciding if the initial state 
is already set. We could use negative numbers for that, but i think this 
is more hacky than using a dedicated variable for keeping track.

This was the reason for my 'has_initial_state' variable. :)

> + /*
> +  * But we are very interested in pressed buttons and
> +  * initial switch state. These will be reported to
> +  * userland.
> +  */
> + } else if (bdata->last_state == state) {
> + /* reset asserted counter (only relevant for polled keys) */

This is also needed for irq-driven keys. If the state changes two times 
within the debounce interval, gpio_keys_handle_button is still executed 
and we need to terminate here. Otherwise, we would skip a "release" or
"push" action.

I did rework those two parts a bit and tested it with the irq and
polled flavors without a problem. See below:


>From b751bb6f4088b4a16c378006fed4e071f905d9e0 Mon Sep 17 00:00:00 2001
From: David Bauer 
Date: Wed, 10 Jul 2019 00:22:56 +0200
Subject: [PATCH] gpio-button-hotplug: unify polled and interrupt code

This patch unifies the polled and interrupt-driven gpio_keys code
paths as well implements consistent handling of the debounce
interval set for the GPIO buttons and switches.

Hotplug events will only be fired if

1. The input changes its state and remains stable for the duration
   of the debounce interval (default is 5 ms).

2. In the initial stable ((no state-change for duration of the
   debounce interval) state once the driver module gets loaded.

   Switch type inputs will always report their stable state.
   Unpressed buttons will not trigger an event for the initial
   stable state. Whereas pressed buttons will trigger an event.
   This is consistent with upstream's gpio-key driver that uses
   the input subsystem (and dont use autorepeat).

Prior to this patch, this was handled inconsistently for interrupt-based
an polled gpio-keys. Hence this patch unifies the shared logic into the
gpio_keys_handle_button() function and modify both implementations to
handle the initial state properly.

Run-tested for 'gpio-keys' and 'gpio-keys-polled' on

 - devolo WiFi pro 1200e
 - devolo WiFi pro 1750c
 - devolo WiFi pro 1750x
 - Netgear WNDR4700
 - Meraki MR24

Signed-off-by: David Bauer 
[further cleanups, simplification and unification]
Signed-off-by: Christian Lamparter 
[reworked initial state logic, fix initial debounce for polled keys]
Signed-off-by: David Bauer 
---
 .../src/gpio-button-hotplug.c | 151 ++
 1 file changed, 86 insertions(+), 65 deletions(-)

diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
index e63d414284..a5a5ebed23 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
@@ -35,10 +35,6 @@
 #define DRV_NAME   "gpio-keys"
 #define PFXDRV_NAME ": "
 
-struct bh_priv {
-   unsigned long   seen;
-};
-
 struct bh_event {
const char  *name;
unsigned inttype;
@@ -56,8 +52,10 @@ struct bh_map {
 
 s

[OpenWrt-Devel] [PATCH v3] ramips: add support for ASUS RT-AC57U

2019-07-10 Thread David Bauer

SoC:   MediaTek MT7621AT
RAM:   128M (Winbond W631GG6KB-15)
FLASH: 16MB (Spansion S25FL128SA)
WiFi:  MediaTek MT7603EN bgn 2SS
WiFi:  MediaTek MT7612EN nac 2SS
BTN:   Reset - WPS
LED:- Power
- LAN {1-4}
- WAN
- WiFi 2.4 GHz
- WiFi 5 GHz
- USB
UART:  UART is present next to the Power LED.
   TX - RX - GND - 3V3 / 57600-8N1
   3V3 is the nearest one to the Power LED.

Installation

Via TFTP:
1. Set your computers IP-Address to 192.168.1.75.
2. Power up the Router with the Reset button pressed.
3. Release the Reset button after 5 seconds.
4. Upload OpenWRT sysupgrade image via TFTP:
 > tftp -4 -v -m binary 192.168.1.1 -c put 

Via SSH:
Note: User/password for SSH is identical with the one used in the
Web-interface.
1. Complete the initial setup wizard.
2. Activate SSH under "Administration" -> "System".
3. Transfer the OpenWrt sysupgrade image via scp:
 > scp owrt.bin admin@192.168.1.1:/tmp
4. Connect via SSH to the router.
 > ssh admin@192.168.1.1
5. Write the OpenWrt image to flash.
 > mtd-write -i /tmp/owrt.bin -d linux
6. Reboot the router
 > reboot

Signed-off-by: David Bauer 
---
v2:
 - Fixed SoC compatible
 - Switch to using interrupt-based gpio-keys
v3:
 - Rebased on current master

 .../ramips/base-files/etc/board.d/02_network  |   2 +
 .../linux/ramips/dts/mt7621_asus_rt-ac57u.dts | 153 ++
 target/linux/ramips/image/mt7621.mk   |   9 ++
 3 files changed, 164 insertions(+)
 create mode 100644 target/linux/ramips/dts/mt7621_asus_rt-ac57u.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 090749e1ba..82d2b234e3 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -187,6 +187,7 @@ ramips_setup_interfaces()
argus,atp-52b|\
asiarf,awm002-evb-4m|\
asiarf,awm002-evb-8m|\
+   asus,rt-ac57u|\
asus,rt-n14u|\
bdcom,wap2100-sk|\
dlink,dir-645|\
@@ -642,6 +643,7 @@ ramips_setup_macs()
wan_mac=$(mtd_get_mac_binary factory 4)
lan_mac=$(mtd_get_mac_binary factory 46)
;;
+   asus,rt-ac57u|\
planex,vr500)
lan_mac=$(mtd_get_mac_binary factory 57344)
wan_mac=$(mtd_get_mac_binary factory 57350)
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac57u.dts 
b/target/linux/ramips/dts/mt7621_asus_rt-ac57u.dts
new file mode 100644
index 00..e757716ffb
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac57u.dts
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asus,rt-ac57u", "mediatek,mt7621-soc";
+   model = "ASUS RT-AC57U";
+
+   aliases {
+   led-boot = &led_power;
+   led-failsafe = &led_power;
+   led-running = &led_power;
+   led-upgrade = &led_power;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "rt-ac57u:blue:power";
+   gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   };
+
+   usb {
+   label = "rt-ac57u:blue:usb";
+   gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+   trigger-sources = <&ehci_port2>;
+   linux,default-trigger = "usbport";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   wps {
+   label = "wps";
+   gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   debounce-interval = <60>;
+   };
+
+   reset {
+   label = "reset";
+   gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   debounce-interval = <60>;
+   };
+   };
+
+   led-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "LED-Power";
+   gpio = <&gpio1 14 GPIO_ACTIVE_LOW>;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+};
+
+&spi0 {
+   status = "okay";
+
+

Re: [OpenWrt-Devel] [PATCH] [RFC] ar71xx: fix Mikrotik wAP AC QCA955X SGMII link loss

2019-07-10 Thread David Bauer

Hello Etienne,

sorry for my late reply.

On 7/7/19 7:26 AM, Etienne Champetier wrote:
> This commit rework
> "ar71xx: allow to override at803x sgmii aneg status" 
> (4e39e213af7e3e0cd747403e8c227e145cfef988)
> by moving override_sgmii_aneg param from "at803x_platform_data" to "device" 
> struct
> Not sure if it's the right place for it, but wAP AC uses 
> "mdio_gpio_platform_data" struct,
> so the current patch is currently accessing some random memory.

This commit moves 'override_sgmii_aneg' to the generic device struct,
which is less than an ideal place for it. 'override_sgmii_aneg' enables a
hack which overrides an early exit in the PHY state-machine. Otherwise, the
ethernet driver is never informed of the link state-change and does not do it's
fixup work while the PHY driver cries over the broken link.

There's nothing wrong with adding the 'mdio_gpio_platform_data' struct as 
platform_data
for the mdio-gpio device. Remember, the platform-data is only for the device 
providing the
mdio-bus, not the mdio device (the PHY).

Have a look how it's done for the AVM FRITZ!WLAN Repeater 450E 
(mach-fritz450e.c).
The 'mdio_board_info' struct (which contains the 'at803x_platform_data' struct) 
is registered
to the mdio-device by calling 'mdiobus_register_board_info' in the 
initiaization code.
Your bus-id is most likely 'mdio-gpio.0'.

I hope this helps you into the right direction :)

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] gpio-button-hotplug: mind debounce interval consistently

2019-07-13 Thread David Bauer

Hello Christian,

first of all, i wouldn't have imagined that there is so mush to talk about 
pressing buttons ;)

On 13.07.19 18:04, Christian Lamparter wrote:
> Hello David,
> 
> On Wednesday, July 10, 2019 12:31:12 AM CEST David Bauer wrote:
>> thanks for your reworked patch. I think i found two bugs around the debounce
>> interval for both flavors. I'll have to admit, they are both edgecases ;)
>>
>> On 06.07.19 23:57, Christian Lamparter wrote
>>> -static void gpio_keys_polled_check_state(struct gpio_keys_button_data 
>>> *bdata)
>>> +static void gpio_keys_handle_button(struct gpio_keys_button_data *bdata)
>>>   {
>>> +   unsigned int type = bdata->b->type ?: EV_KEY;
>>> int state = gpio_button_get_value(bdata);
>>> +   unsigned long seen = jiffies;
>>>   
>>> -   if (state != bdata->last_state) {
>>> -   unsigned int type = bdata->b->type ?: EV_KEY;
>>> +   pr_debug(PFX "event type=%u, code=%u, pressed=%d\n",
>>> +type, bdata->b->code, state);
>>> +
>>> +   /* is this the initialization state? */
>>> +   if (bdata->last_state == -1) {
>>> +   /*
>>> +* Don't advertise unpressed buttons on initialization.
>>> +* Just save their state and continue otherwise this
>>> +* can cause OpenWrt to enter failsafe.
>>> +*/
>>> +   if (type == EV_KEY && state == 0)
>>> +   goto set_state;
>>
>> As we are calling gpio_keys_handle_button every poll-interval, we need 
>> to make sure we save the initial state AFTER the button has been stable 
>> for the debounce interval. For irq-based keys we get this "for free" as 
>> we modify the execution timer for the irq handling function.
> 
> Ah, I think due to how the patch looks (as in this mail and not applied
> to the source code) this feature/behavior got lost there. 
> 
> I've added the gpio_keys_handle_button() below after that version of the
> patch is applied.
> 
> ---
> static void gpio_keys_handle_button(struct gpio_keys_button_data *bdata)
> {
> unsigned int type = bdata->b->type ?: EV_KEY;
> int state = gpio_button_get_value(bdata);
> unsigned long seen = jiffies;
> 
> pr_debug(PFX "event type=%u, code=%u, pressed=%d\n",
>  type, bdata->b->code, state);
> 
> /* is this the initialization state? */
> if (bdata->last_state == -1) {
> /*
>  * Don't advertise unpressed buttons on initialization.
>  * Just save their state and continue otherwise this
>  * can cause OpenWrt to enter failsafe.
>  */
> if (type == EV_KEY && state == 0)
> goto set_state;
> /*
>  * But we are very interested in pressed buttons and
>  * initial switch state. These will be reported to
>  * userland.
>  */
> } else if (bdata->last_state == state) {
> /* reset asserted counter (only relevant for polled keys) */
> bdata->count = 0;
> return;
> }
> 
> if (bdata->count < bdata->threshold) {
> bdata->count++;
> return;
> }
> 
> if (bdata->seen == 0)
> bdata->seen = seen;
> 
> button_hotplug_create_event(button_map[bdata->map_entry].name, type,
> (seen - bdata->seen) / HZ, state);
> bdata->seen = seen;
> 
> set_state:
> bdata->last_state = state;
> bdata->count = 0;
> }
> ---
> 
> The pressed button state (for the polled) version will now always have to be
> stable for the debounce-duration (including on the initial state). That's
> guaranteed by the "if (bdata->count < bdata->threshold) { count++;return; }"
> path. If there's a laps during the initial state then last_state gets set to
> 0 and the counter is reset. But this bogus "released" event is not reported
> to userspace, so if it's an inital pressed state it will still be reported
> correctly, altough it might take another full debounce-duration. 

Hmm, i might have some problems grasping here, but let's take the following
situation:

 goto set_state called here
 |
0510   15   20   25   30
|||||||
110

Re: [OpenWrt-Devel] [PATCH v2] gpio-button-hotplug: mind debounce interval consistently

2019-07-13 Thread David Bauer

Hello Christian,

On 7/14/19 12:04 AM, Christian Lamparter wrote:
> The "goto set_setstate;" only happens if state = 0 (Which in gpio-button
> context means) that the button is in an unpressed state.

Okay, you are right, this is one thing i missed.

If we suspect, the polarity is correctly set for every board, your code is 
completely
right and should behave the same for polled and irq based keys.

So, the question is primarily if we want a event if a button is pressed 
continuously
on bootup. I think this is the point where our expectations differ.

I might be a bit late for this realization, sorry for that :D

> You can see that gpio_keys_polled_check_state() always "ate" initial
> state event for polled buttons (yes, both states - pressed and unpressed -) 
> got
> ignored.  Which I think is very wrong... mostly because it goes against the 
> decades of experience I have with "holding down buttons while powering up 
> devices"
> and expect them to get noticed properly :D. That's why my code only eats the 
> initial
> unpressed/0 event, but reports the pressed button event. This should still be
> compatible with the current failsafe setup. 

Honestly, i think our expectations divert here a little ;)

OpenWrt Wiki states "It listens for a button press inside a specific two second 
window,
which is indicated with LEDs and by transmitting an UDP package."

and

"Recommended for most users: Wait for a flashing LED and press a button.
This is usually the easiest method once you figure out the correct moment."

So yes, this differs from the usual "Hold a button and insert power". However,
entering failsafe on any button state change event would be the behavior i 
suspect.

> Related Note: 
> As for the sudden burst of the "device is always entering failsafe".
> I can see how this is causing problems now. Because if the polarity of
> a button was declared (or that got copied from another device without
> checking ;) ) with the wrong way; This will now become a problem because
> it "physically unpressed" button gets reported as "pressed" and this causes
> the device to always enter failsafe (unless the very button with the wrong
> polarity is pressed, which in this context means unpressed).

This is - sadly - not the reason why I'm observing this issue :(
Polarity is correctly declared for my devolo board.

> However, I think this is a problem of the individual dts/board support code.
> But sadly I have currently no time to monitor the forums, bugtracker, ML or
> github for these problems... so what to do?

This is clearly nothing we should worry about. I made myself also guilty of this
mistake and it makes things weird in so many ways.

It's a bug in the boards integration and nothing we have to catch on our layer 
:)

>> You are right. Your commit was relating to the reset of the counter, my 
>> remark was
>> about "There should be no events in case last_state == current_state also 
>> for irq
>> keys. So no functional problem to see here :)
> 
> Ok, so this is fine?

Yes :)

> 
> As everyone who follows the thread can see: The struggle is real!
> Even for something as seemingly simple and benign as a gpio-button.

Okay, so how do we want to proceed? I would propose to merge your iteration
(as it was working for me in both modes) to master, wait for people to complain
and then pickit to 19.07? It should be an improvement over the current situation
anyways. I would view the failsafe mode on a continuous press as a new 
"feature" here ;) 

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: enable QCA955x SGMII fixup on Mikrotik wAP AC

2019-07-14 Thread David Bauer

Hi Etienne,

one small remark:

On 14.07.19 04:43, Etienne Champetier wrote:
>   ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 0);
>   ath79_eth1_data.mii_bus_dev = &rbwapgsc_phy_device.dev;
>   ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_SGMII;
>   ath79_eth1_data.phy_mask = BIT(RBWAPGSC_MDIO_PHYADDR);
> + ath79_eth1_data.enable_sgmii_fixup = 1;

This should be dropped as it's not necessary anymore.

Best wishes
David

>   ath79_eth1_pll_data.pll_1000 = 0x03000101;
>   ath79_eth1_pll_data.pll_100 = 0x8101;
>   ath79_eth1_pll_data.pll_10 = 0x80001313;
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: enable QCA955x SGMII fixup on Mikrotik wAP AC

2019-07-15 Thread David Bauer

Hello Etienne,

On 15.07.19 04:30, Etienne Champetier wrote:
> Hi David,
> 
> Le dim. 14 juil. 2019 à 04:25, David Bauer  a écrit :
>>
>> Hi Etienne,
>>
>> one small remark:
>>
>> On 14.07.19 04:43, Etienne Champetier wrote:
>>>   ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 0);
>>>   ath79_eth1_data.mii_bus_dev = &rbwapgsc_phy_device.dev;
>>>   ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_SGMII;
>>>   ath79_eth1_data.phy_mask = BIT(RBWAPGSC_MDIO_PHYADDR);
>>> + ath79_eth1_data.enable_sgmii_fixup = 1;
>>
>> This should be dropped as it's not necessary anymore.
> 
> Did some more tests and it's definitely needed (here this is ar71xx &
> Linux 4.14)
> It's still used for other boards, could you detail why it's not needed
> anymore, since what version, reference some commits ?

You are right, it is needed. I was only focused on the workaround for the PHY 
side,
but we indeed explicitly need to enable the MAC side workaround too.

So this looks good to me.

Best wishes
David

> 
> Thanks
> Etienne
> 
>>
>> Best wishes
>> David
>>
>>>   ath79_eth1_pll_data.pll_1000 = 0x03000101;
>>>   ath79_eth1_pll_data.pll_100 = 0x8101;
>>>   ath79_eth1_pll_data.pll_10 = 0x80001313;
>>>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: fix HiveAP 121 PLL for 1000M

2019-07-30 Thread David Bauer

The Aerohive HiveAP 121 has the wrong PLL value set for Gigabit speeds,
leading to packet-loss. 10M and 100M work fine.

This commit sets the Gigabit Ethernet PLL value to the correct value,
fixing packet loss.

Confirmed with iperf and floodping.

Signed-off-by: David Bauer 
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-hiveap-121.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-hiveap-121.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-hiveap-121.c
index 363d73dd53..5cbb2054f7 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-hiveap-121.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-hiveap-121.c
@@ -111,7 +111,7 @@ static void __init hiveap_121_setup(void)
ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
ath79_eth0_data.phy_mask = BIT(HIVEAP_121_LAN_PHYADDR);
-   ath79_eth0_pll_data.pll_1000 = 0x0e00;
+   ath79_eth0_pll_data.pll_1000 = 0x0600;
ath79_eth0_pll_data.pll_100 = 0x0101;
ath79_eth0_pll_data.pll_10 = 0x1313;
ath79_register_eth(0);
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] lantiq: correct Fritz!Box 7412 button logic level

2019-08-09 Thread David Bauer

The AVM FRITZ!Box 7412 buttons are both active low, which is currently
incorrectly defined in the device-tree.

This leads to the device booting directly into failsafe.

Signed-off-by: David Bauer 
---
 target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts 
b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts
index baf3d69fb5..97817595e9 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts
@@ -34,13 +34,13 @@

wps {
label = "wps";
-   gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+   gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
linux,code = ;
};

dect {
label = "dect";
-   gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
+   gpios = <&gpio 2 GPIO_ACTIVE_LOW>;
linux,code = ;
};
};
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] lantiq: enable second VPE on Fritz!Box 7412

2019-08-09 Thread David Bauer

The AVM Fritz!Box 7412 does not use the VMMC part of the Lantiq chip but
rather a proprietary solution based on the DECT chip for the FXS ports.

Therefore, the second VPE can be enabled for use with OpenWrt.

Signed-off-by: David Bauer 
---
 target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts | 2 +-
 target/linux/lantiq/image/Makefile | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts 
b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts
index 97817595e9..111ef1b320 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7412.dts
@@ -11,7 +11,7 @@
model = "AVM FRITZ!Box 7412";
 
chosen {
-   bootargs = "console=ttyLTQ0,115200 mem=126M 
vpe1_load_addr=0x87e0 vpe1_mem=2M maxvpes=1 maxtcs=1 nosmp";
+   bootargs = "console=ttyLTQ0,115200";
};
 
aliases {
diff --git a/target/linux/lantiq/image/Makefile 
b/target/linux/lantiq/image/Makefile
index 2352cb6b5e..f71a262c82 100644
--- a/target/linux/lantiq/image/Makefile
+++ b/target/linux/lantiq/image/Makefile
@@ -673,7 +673,7 @@ define Device/avm_fritz7412
   KERNEL_SIZE := 4096k
   IMAGE_SIZE := 49152k
   DEVICE_TITLE := AVM FRITZ!Box 7412
-  DEVICE_PACKAGES := kmod-ath9k kmod-owl-loader wpad-basic kmod-ltq-tapi 
kmod-ltq-vmmc fritz-tffs-nand fritz-caldata
+  DEVICE_PACKAGES := kmod-ath9k kmod-owl-loader wpad-basic fritz-tffs-nand 
fritz-caldata
 endef
 TARGET_DEVICES += avm_fritz7412
 
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lantiq: unify Fritz!Box LED mappings

2019-08-11 Thread David Bauer

This commit unifies the LED mapping of the AVM Fritz!Box routers, which
have a combined Power/DSL LED.

With the stock firmware, the Power LED has the following
characteristics:

 - Blink when DSL sync is being established
 - Solid when DSL sync is present

We can't completely resemble this behavior in OpenWrt. Currently, the
Power LED is completely off, when DSL sync is missing. This is not
really helpful, as a user might have the impression, that he bricked his
device.

Instead, map the Info-LED to the state of the DSL connection.
There is no consistent behavior for the Info-LED in the stock
firmware, as the user can set it's function by himself. The DSL
connection state is one possible option for the Info LED there.

Also use the red Power LED to indicate a running upgrade, in case the
board has a two-color Power LED.

Signed-off-by: David Bauer 
---
 .../linux/lantiq/files/arch/mips/boot/dts/FRITZ3370-REV2.dtsi  | 2 +-
 target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7312.dts | 3 +--
 target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7320.dts | 3 +--
 target/linux/lantiq/files/arch/mips/boot/dts/FRITZ736X.dtsi| 3 ++-
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ3370-REV2.dtsi 
b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ3370-REV2.dtsi
index f23d2d2cf5..02e9589969 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ3370-REV2.dtsi
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ3370-REV2.dtsi
@@ -15,7 +15,7 @@
led-boot = &power_green;
led-failsafe = &power_red;
led-running = &power_green;
-   led-upgrade = &power_green;
+   led-upgrade = &power_red;
 
led-dsl = &dsl;
led-internet = &info_green;
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7312.dts 
b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7312.dts
index 811f78f934..0190dd2f01 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7312.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7312.dts
@@ -18,8 +18,7 @@
led-running = &power;
led-upgrade = &power;
 
-   led-internet = &info_green;
-   led-dsl = &power;
+   led-dsl = &info_green;
led-wifi = &wlan;
};
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7320.dts 
b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7320.dts
index 40348b1d59..6c0dad873f 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7320.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ7320.dts
@@ -18,8 +18,7 @@
led-running = &power;
led-upgrade = &power;
 
-   led-internet = &info_green;
-   led-dsl = &power;
+   led-dsl = &info_green;
led-wifi = &wlan;
};
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ736X.dtsi 
b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ736X.dtsi
index 82546a3572..57033eb4a9 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ736X.dtsi
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/FRITZ736X.dtsi
@@ -17,7 +17,8 @@
led-boot = &power_green;
led-failsafe = &power_red;
led-running = &power_green;
-   led-upgrade = &power_green;
+   led-upgrade = &power_red;
+
led-dsl = &info_green;
led-wifi = &wifi;
};
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq40xx: fix AVM NAND caldata extraction

2019-08-13 Thread David Bauer

The AVM Fritz!Box 7530 (and probably other AVM IPQ4019 NAND devices)
has it's caldata not stored consistently, but instead at currently
3 known possible offsets.

As we get a non-zero exit code from fritz_cal_extract, simply try all
three possible offsets on both bootloader partitions, until a matching
caldata for each radio is found.

Reported-by: Hauke Mehrtens 
Signed-off-by: David Bauer 
---
 .../etc/hotplug.d/firmware/11-ath10k-caldata   | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git 
a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 1e64b93a46..5f7e5f4923 100644
--- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -112,7 +112,11 @@ case "$FIRMWARE" in
;;
avm,fritzrepeater-3000)
/usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
-   /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x212 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
;;
linksys,ea8300)
ath10kcal_extract "ART" 36864 12064
@@ -146,7 +150,11 @@ case "$FIRMWARE" in
avm,fritzbox-7530 |\
avm,fritzrepeater-3000)
/usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x207 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
-   /usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x207 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x207 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x207 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x207 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x207 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x207 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
;;
compex,wpj428 |\
engenius,eap1300 |\
@@ -203,7 +211,11 @@ case "$FIRMWARE" in
avm,fritzbox-7530 |\
avm,fritzrepeater-3000)
/usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
-   /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1") || \
+   /usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
;;
compex,wpj428 |\
engenius,eap1300 |\
-- 
2.22.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MAC addresses read by ralink,mtd-eeprom

2019-08-15 Thread David Bauer

Hello Adrian,

On 8/15/19 1:26 PM, Adrian Schmutzler wrote:
> My current understanding of ralink,mtd-eeprom for &wmac is that this reads 
> the MAC address "automatically" if it's in the correct location (start+4).

This is correct, the MAC address is stored as 3 16bit words within the EEPROM 
data, beginning at
the third word of the EEPROM data.

See
https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ralink/rt2x00/rt2800.h#L2590
or
https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ralink/rt2x00/rt2800lib.c#L9187

> Does this mean that e.g. in the following configuration I can tell that &wmac 
> and ðernet have the _same_ MAC address (without checking on device):
> 
> ðernet {
>   mtd-mac-address = <&factory 0x4>;
>   mediatek,portmap = "w";
> };
> &wmac {
>   ralink,mtd-eeprom = <&factory 0>;
> };

If the MAC address is not altered via userspace: correct

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: add factory image for NETGEAR R6220

2019-08-27 Thread David Bauer

This adds an easy-installation factory image for the NETGEAR R6220
router. The factory image can either be flashed via the vendor Web-UI or
the bootloader using nmrpflash.

Tested with NETGEAR V1.1.0.86 firmware.

Signed-off-by: David Bauer 
---
 target/linux/ramips/image/mt7621.mk | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index 5dc8efe7c5..a00e6280c7 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -397,7 +397,12 @@ define Device/netgear_r6220
   KERNEL_SIZE := 4096k
   IMAGE_SIZE := 28672k
   UBINIZE_OPTS := -E 5
-  IMAGES += kernel.bin rootfs.bin
+  SERCOMM_HWID := AYA
+  SERCOMM_HWVER := A001
+  SERCOMM_SWVER := 0x0086
+  IMAGES += factory.img kernel.bin rootfs.bin
+  IMAGE/factory.img := pad-extra 2048k | append-kernel | pad-to 6144k | 
append-ubi | \
+   pad-to (BLOCKSIZE) | sercom-footer | pad-to 128 | zip R6220.bin | 
sercom-seal
   IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
   IMAGE/kernel.bin := append-kernel
   IMAGE/rootfs.bin := append-ubi | check-size (IMAGE_SIZE)
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lua: create lua symlink for host installation

2019-08-28 Thread David Bauer

Since the binaries for both lua as well as lua5.3 contain the version
number, invocations of the "lua" binary are failing, as it's not created
anymore for the host package.

Fixes: fe59b46 ("lua: include version number in installed files")
Signed-off-by: David Bauer 
---
 package/utils/lua/Makefile| 4 +++-
 package/utils/lua5.3/Makefile | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/package/utils/lua/Makefile b/package/utils/lua/Makefile
index a2870448bd..e376e8c472 100644
--- a/package/utils/lua/Makefile
+++ b/package/utils/lua/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=lua
 PKG_VERSION:=5.1.5
-PKG_RELEASE:=5
+PKG_RELEASE:=6
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
@@ -133,6 +133,8 @@ define Host/Install
$(MAKE) -C $(HOST_BUILD_DIR) \
INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
install
+
+   $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.1 $(STAGING_DIR_HOSTPKG)/bin/lua
 endef
 
 define Build/InstallDev
diff --git a/package/utils/lua5.3/Makefile b/package/utils/lua5.3/Makefile
index c9e9bebb1a..7f835dd41f 100644
--- a/package/utils/lua5.3/Makefile
+++ b/package/utils/lua5.3/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=lua
 PKG_VERSION:=5.3.5
-PKG_RELEASE:=4
+PKG_RELEASE:=5
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
@@ -118,6 +118,8 @@ define Host/Install
$(MAKE) -C $(HOST_BUILD_DIR) \
INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
install
+
+   $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.3 $(STAGING_DIR_HOSTPKG)/bin/lua
 endef
 
 define Build/InstallDev
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] lua: create lua symlink for host installation

2019-08-28 Thread David Bauer

Hello Karl,

the version built last is the one which will have the symlink set.
However, i think this is not the ideal solution in terms of
reproducibility, so we should probably only symlink lua5.1 for
the Host installation?

A bit more background on this topic (as I've forgotten to add this
to the commit message): LuaSrcDiet currently fails silently as it
expects a "lua" named binary in it's path. I suspect there could be
more silent breakage because of this currently.

Best wishes
David

On 8/28/19 10:53 PM, Karl Palsson wrote:
> 
> How is this meant to work when you have both?
> 
> David Bauer  wrote:
>> Since the binaries for both lua as well as lua5.3 contain the
>> version number, invocations of the "lua" binary are failing, as
>> it's not created anymore for the host package.
>>
>> Fixes: fe59b46 ("lua: include version number in installed
>> files") Signed-off-by: David Bauer 
>> ---
>>  package/utils/lua/Makefile| 4 +++-
>>  package/utils/lua5.3/Makefile | 4 +++-
>>  2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/utils/lua/Makefile
>> b/package/utils/lua/Makefile index a2870448bd..e376e8c472
>> 100644
>> --- a/package/utils/lua/Makefile
>> +++ b/package/utils/lua/Makefile
>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>>  
>>  PKG_NAME:=lua
>>  PKG_VERSION:=5.1.5
>> -PKG_RELEASE:=5
>> +PKG_RELEASE:=6
>>  
>>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>>  PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
>> @@ -133,6 +133,8 @@ define Host/Install
>>  $(MAKE) -C $(HOST_BUILD_DIR) \
>>  INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
>>  install
>> +
>> +$(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.1 $(STAGING_DIR_HOSTPKG)/bin/lua
>>  endef
>>  
>>  define Build/InstallDev
>> diff --git a/package/utils/lua5.3/Makefile
>> b/package/utils/lua5.3/Makefile index c9e9bebb1a..7f835dd41f
>> 100644
>> --- a/package/utils/lua5.3/Makefile
>> +++ b/package/utils/lua5.3/Makefile
>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>>  
>>  PKG_NAME:=lua
>>  PKG_VERSION:=5.3.5
>> -PKG_RELEASE:=4
>> +PKG_RELEASE:=5
>>  
>>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>>  PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
>> @@ -118,6 +118,8 @@ define Host/Install
>>  $(MAKE) -C $(HOST_BUILD_DIR) \
>>  INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
>>  install
>> +
>> +$(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.3 $(STAGING_DIR_HOSTPKG)/bin/lua
>>  endef
>>  
>>  define Build/InstallDev
>> -- 
>> 2.23.0
>>
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 1/3] lua: create lua symlink for host installation

2019-08-29 Thread David Bauer

Since the binaries for both lua as well as lua5.3 contain the version
number, invocations of the "lua" binary are failing, as it's not created
anymore for the host package.

Fixes: fe59b46 ("lua: include version number in installed files")
Signed-off-by: David Bauer 
---
v2:
 - drop symlink creation for lua5.3

 package/utils/lua/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/package/utils/lua/Makefile b/package/utils/lua/Makefile
index a2870448bd..e376e8c472 100644
--- a/package/utils/lua/Makefile
+++ b/package/utils/lua/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=lua
 PKG_VERSION:=5.1.5
-PKG_RELEASE:=5
+PKG_RELEASE:=6
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
@@ -133,6 +133,8 @@ define Host/Install
$(MAKE) -C $(HOST_BUILD_DIR) \
INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
install
+
+   $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.1 $(STAGING_DIR_HOSTPKG)/bin/lua
 endef
 
 define Build/InstallDev
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: disable badblock shifting for MT7621 NAND

2019-08-29 Thread David Bauer

The MediaTek MT7621 NAND driver currently intransparently shifts NAND
pages when a block is marked as bad. Because of this, offsets for e.g.
caldata and MAC-addresses seem to be off.

This is, howeer, not a task for the mtd NAND driver, as the flash
translation layer is tasked with this.

This patch disables this badblock shifting. This fix was originally
proposed by Jo-Philipp Wich at
https://bugs.openwrt.org/index.php?do=details&task_id=1926

Fixes FS#1926 ("MTD partition offset not correctly mapped when bad
eraseblocks present")
Signed-off-by: David Bauer 
---
 .../ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/target/linux/ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch 
b/target/linux/ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch
index d50e689110..03b2b36db9 100644
--- a/target/linux/ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch
+++ b/target/linux/ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch
@@ -3578,7 +3578,7 @@ Signed-off-by: John Crispin 
 +  if (!err) {
 +  MSG(INIT, "[mtk_nand] probe successfully!\n");
 +  nand_disable_clock();
-+  shift_on_bbt = 1;
++  shift_on_bbt = 0;
 +  if (load_fact_bbt(mtd) == 0) {
 +  int i;
 +  for (i = 0; i < 0x100; i++)
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mtd-mac-address on MT7610E chip

2019-09-02 Thread David Bauer

Hello Adrian,

On 9/2/19 6:13 PM, Adrian Schmutzler wrote:
> Hi,
> 
> we just have encountered the case of a 5 GHz radio on a MT7610E chip that 
> does not provide its MAC address via caldata.
> 
> We tried the following:
> 
> &pcie0 {
>   wifi@0,0 {
>   reg = <0x 0 0 0 0>;
>   mediatek,mtd-eeprom = <&factory 0x8000>;
>   ieee80211-freq-limit = <500 600>;
>   mtd-mac-address = <&factory 0x28>;
>   mtd-mac-address-increment = <2>;
>   };
> };
> 
> But the device insists on using the address from 0x8004.
> 
> Any ideas? Is mtd-mac-address(-increment) not implemented for this chip?

This issue persists for quite some time, the mt76 driver does not
call mt76_eeprom_override upon initialization. I'm sadly not aware why
this is the case. A PR for this is open in mt76 for quite some time.

You might have some luck pinging mbd directly or going thru linux-wireless.

See https://github.com/openwrt/mt76/pull/209

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Add LED migration for several Archer Cxx devices

2019-09-02 Thread David Bauer

Hello Adrian

On 9/2/19 11:10 AM, Adrian Schmutzler wrote:
> Several Archer Cxx devices were using board-specific LED names in
> ar71xx, which were changed to "tp-link:*" in ath79.
> 
> This patch adds migration for them.

Have you run-tested this patch? For me i ran into the issue of the device
not being reachable via Ethernet, as the Ethernet MACs were swapped.

Has anyone yet tried to find an migration approach for this? I assume this
could be tricky, as we might need to update the board.json also in this run.

Regarding the actual patch: I assume the LEDs were migrated (as the WAN Ethernet
got illuminated), but i want to hear your opinion on how we should proceed with
the Ethernet migration. :)

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] ar71xx: allow to override at803x sgmii aneg status

2018-08-06 Thread David Bauer

When checking the outcome of the PHY autonegotiation status, at803x
currently returns false in case the SGMII side is not established.

Due to a hardware-bug, ag71xx needs to fixup the SoCs SGMII side, which
it can't as it is not aware of the link-establishment.

This commit allows to ignore the SGMII side autonegotiation status to
allow ag71xx to do the fixup work.

Signed-off-by: David Bauer 
---
 .../files/arch/mips/ath79/mach-fritz450e.c|  1 +
 ...at803x-add-sgmii-aneg-override-pdata.patch | 42 +++
 2 files changed, 43 insertions(+)
 create mode 100644 
target/linux/ar71xx/patches-4.9/903-at803x-add-sgmii-aneg-override-pdata.patch

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c
index e48ddd65e7..4e99834d27 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c
@@ -122,6 +122,7 @@ static struct gpio_keys_button fritz450E_gpio_keys[] 
__initdata = {
 static struct at803x_platform_data fritz450E_at803x_data = {
.disable_smarteee = 1,
.has_reset_gpio = 1,
+   .override_sgmii_aneg = 1,
.reset_gpio = FRITZ450E_GPIO_PHY_RESET,
 };
 
diff --git 
a/target/linux/ar71xx/patches-4.9/903-at803x-add-sgmii-aneg-override-pdata.patch
 
b/target/linux/ar71xx/patches-4.9/903-at803x-add-sgmii-aneg-override-pdata.patch
new file mode 100644
index 00..9c922d155d
--- /dev/null
+++ 
b/target/linux/ar71xx/patches-4.9/903-at803x-add-sgmii-aneg-override-pdata.patch
@@ -0,0 +1,42 @@
+Index: linux-4.9.111/drivers/net/phy/at803x.c
+===
+--- linux-4.9.111.orig/drivers/net/phy/at803x.c
 linux-4.9.111/drivers/net/phy/at803x.c
+@@ -461,12 +461,15 @@ static void at803x_link_change_notify(st
+ 
+ static int at803x_aneg_done(struct phy_device *phydev)
+ {
++  struct at803x_platform_data *pdata;
+   int ccr;
+ 
+   int aneg_done = genphy_aneg_done(phydev);
+   if (aneg_done != BMSR_ANEGCOMPLETE)
+   return aneg_done;
+ 
++  pdata = dev_get_platdata(&phydev->mdio.dev);
++
+   /*
+* in SGMII mode, if copper side autoneg is successful,
+* also check SGMII side autoneg result
+@@ -481,7 +484,8 @@ static int at803x_aneg_done(struct phy_d
+   /* check if the SGMII link is OK. */
+   if (!(phy_read(phydev, AT803X_PSSR) & AT803X_PSSR_MR_AN_COMPLETE)) {
+   pr_warn("803x_aneg_done: SGMII link is not ok\n");
+-  aneg_done = 0;
++  if (!pdata || !pdata->override_sgmii_aneg)
++  aneg_done = 0;
+   }
+   /* switch back to copper page */
+   phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SEL);
+Index: linux-4.9.111/include/linux/platform_data/phy-at803x.h
+===
+--- linux-4.9.111.orig/include/linux/platform_data/phy-at803x.h
 linux-4.9.111/include/linux/platform_data/phy-at803x.h
+@@ -7,6 +7,7 @@ struct at803x_platform_data {
+   int enable_rgmii_rx_delay:1;
+   int fixup_rgmii_tx_delay:1;
+   int has_reset_gpio:1;
++  int override_sgmii_aneg:1;
+   int reset_gpio;
+ };
+ 
-- 
2.18.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

1 2 3 4 5 >

1 - 100 of 404 matches

Mail list logo