Re: [PATCH] ipq40xx: 5.10: refresh config

2021-11-06 Thread Christian Lamparter

On 04/11/2021 16:17, Robert Marko wrote:

On Thu, Nov 4, 2021 at 4:15 PM Christian Lamparter  wrote:


On 04/11/2021 12:53, Robert Marko wrote:

It looks like CONFIG_BLK_CMDLINE_PARSER was forgotten during the Orbi
device merge.
So lets refresh the config with it.


Hmm, is it missing for 5.4 as well?! The generic 5.4 config doesn't
enable it either.


Honestly, I haven't checked 5.4 I stumbled upon this when enabling the
DSA driver combo.


CONFIG_CMDLINE_PARTITION selects CONFIG_BLK_CMDLINE_PARSER.
So that CONFIG_BLK_CMDLINE_PARSER is added during by the refresh, since
it ends up enabled in the generated .config, while it's disabled in the
generic 5.4/5.10 and it's not in config-filter. So no breakage.

(No, I didn't bother with refreshing ipq40xx's 5.4 config.
I found something else when looking in ipq40xx/Makefile:

KERNEL_PATCHVER:=5.10
KERNEL_TESTING_PATCHVER:=5.10

o)

Cheers,
Christian

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


Re: [PATCH 1/5] realtek: Consolidate bootargs

2021-11-04 Thread Christian Lamparter

On 04/11/2021 15:55, Sander Vanheule wrote:

All current devices use identical bootargs, so let's move that to the
common devicetree includes.


hmm,  that "console=ttyS0,..." is fine. But there is a "DT-way" of doing
it with stdout-path as per the documentation:

https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt

(Ideally this node or bootargs should be added by the bootloader/uboot
so they stay in sync.)

Cheers,
Christian



Signed-off-by: Sander Vanheule 
---
  target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi| 4 
  target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi   | 4 
  target/linux/realtek/dts-5.10/rtl8382_allnet_all-sg8208m.dts  | 4 
  target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts | 4 
  target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210.dtsi| 4 
  target/linux/realtek/dts-5.10/rtl8382_inaba_aml2-17gp.dts | 4 
  target/linux/realtek/dts-5.10/rtl838x.dtsi| 2 +-
  target/linux/realtek/dts-5.10/rtl930x.dtsi| 2 +-
  8 files changed, 2 insertions(+), 26 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi 
b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi
index e98a9bfc615b..6eb316231b47 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit.dtsi
@@ -8,10 +8,6 @@
  / {
compatible = "realtek,rtl838x-soc";
  
-	chosen {

-   bootargs = "console=ttyS0,115200";
-   };
-
memory@0 {
device_type = "memory";
reg = <0x0 0x800>;
diff --git a/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi 
b/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi
index 7233f6086c6f..7095006454a9 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi
@@ -13,10 +13,6 @@
led-upgrade = _sys;
};
  
-	chosen {

-   bootargs = "console=ttyS0,115200";
-   };
-
memory@0 {
device_type = "memory";
reg = <0x0 0x800>;
diff --git a/target/linux/realtek/dts-5.10/rtl8382_allnet_all-sg8208m.dts 
b/target/linux/realtek/dts-5.10/rtl8382_allnet_all-sg8208m.dts
index f4ca1686dd08..320cb08ac7de 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_allnet_all-sg8208m.dts
+++ b/target/linux/realtek/dts-5.10/rtl8382_allnet_all-sg8208m.dts
@@ -16,10 +16,6 @@
led-upgrade = _sys;
};
  
-	chosen {

-   bootargs = "console=ttyS0,115200";
-   };
-
memory@0 {
device_type = "memory";
reg = <0x0 0x800>;
diff --git a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts 
b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
index 119eaadc16e6..a0f377c4f4a7 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
+++ b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
@@ -16,10 +16,6 @@
led-upgrade = _power;
};
  
-	chosen {

-   bootargs = "console=ttyS0,115200";
-   };
-
memory@0 {
device_type = "memory";
reg = <0x0 0x800>;
diff --git a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210.dtsi 
b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210.dtsi
index a4811dbf3073..312a36c1a844 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210.dtsi
@@ -13,10 +13,6 @@
led-upgrade = _power;
};
  
-	chosen {

-   bootargs = "console=ttyS0,115200";
-   };
-
memory@0 {
device_type = "memory";
reg = <0x0 0x800>;
diff --git a/target/linux/realtek/dts-5.10/rtl8382_inaba_aml2-17gp.dts 
b/target/linux/realtek/dts-5.10/rtl8382_inaba_aml2-17gp.dts
index 1dc9e272fe3f..30960afff4d9 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_inaba_aml2-17gp.dts
+++ b/target/linux/realtek/dts-5.10/rtl8382_inaba_aml2-17gp.dts
@@ -9,10 +9,6 @@
compatible = "inaba,aml2-17gp", "realtek,rtl838x-soc";
model = "INABA Abaniact AML2-17GP";
  
-	chosen {

-   bootargs = "console=ttyS0,115200";
-   };
-
memory@0 {
device_type = "memory";
reg = <0x0 0x800>;
diff --git a/target/linux/realtek/dts-5.10/rtl838x.dtsi 
b/target/linux/realtek/dts-5.10/rtl838x.dtsi
index a72addcf369d..a33b6d899e2a 100644
--- a/target/linux/realtek/dts-5.10/rtl838x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl838x.dtsi
@@ -65,7 +65,7 @@
};
  
  	chosen {

-   bootargs = "console=ttyS0,38400";
+   bootargs = "console=ttyS0,115200";
};
  
  	cpuintc: cpuintc {

diff --git a/target/linux/realtek/dts-5.10/rtl930x.dtsi 
b/target/linux/realtek/dts-5.10/rtl930x.dtsi

Re: [PATCH] ipq40xx: 5.10: refresh config

2021-11-04 Thread Christian Lamparter

On 04/11/2021 12:53, Robert Marko wrote:

It looks like CONFIG_BLK_CMDLINE_PARSER was forgotten during the Orbi
device merge.
So lets refresh the config with it.


Hmm, is it missing for 5.4 as well?! The generic 5.4 config doesn't
enable it either.

linux/generic/config-5.4:547:# CONFIG_BLK_CMDLINE_PARSER is not set

And Davide's PR just enables CONFIG_CMDLINE_PARTITION


Does this mean that Davide Fioravanti PR never worked?

For the future:
|commit 2164877c7f373e14e55fca20b7c4a9c436fe4462
|Author: Christoph Hellwig 
|Date:   Wed Jul 28 07:37:56 2021 +0200
|
|   block: remove cmdline-parser.c
|
|   cmdline-parser.c is only used by the cmdline faux partition format,
|   so merge the code into that and avoid an indirect call.
|
|   Signed-off-by: Christoph Hellwig 
|   Link: https://lore.kernel.org/r/20210728053756.409654-1-...@lst.de
|   Signed-off-by: Jens Axboe 
So, CONFIG_BLK_CMDLINE_PARSER will be gone with the 5.15 lts :)



Signed-off-by: Robert Marko 
---
  target/linux/ipq40xx/config-5.10 | 1 +
  1 file changed, 1 insertion(+)

diff --git a/target/linux/ipq40xx/config-5.10 b/target/linux/ipq40xx/config-5.10
index 16baa99f4d..779c86fc95 100644
--- a/target/linux/ipq40xx/config-5.10
+++ b/target/linux/ipq40xx/config-5.10
@@ -47,6 +47,7 @@ CONFIG_AT803X_PHY=y
  CONFIG_AUTO_ZRELADDR=y
  CONFIG_BCH=y
  CONFIG_BINFMT_FLAT_ARGVP_ENVP_ON_STACK=y
+CONFIG_BLK_CMDLINE_PARSER=y
  CONFIG_BLK_DEV_LOOP=y
  CONFIG_BLK_MQ_PCI=y
  CONFIG_BOUNCE=y




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


[RFT PATCH] ath9k: OF: qca,disable-(2|5)ghz => ieee80211-freq-limit

2021-10-29 Thread Christian Lamparter
OpenWrt maintains two special out-of-tree DT properties:
"qca,disable-5ghz" and "qca,disable-2ghz". These are implemented
in a mac80211 ath9k patch "550-ath9k-disable-bands-via-dt.patch".

With the things being what they are, now might be a good
point to switch the devices to the generic and upstream
"ieee80211-freq-limit" property. This property is much
broader and works differently. Instead of disabling the
drivers logic which would adds the affected band and
channels. It now disables all channels which are not
within the specified frequency range.

Signed-off-by: Christian Lamparter 
---
 ...-ieee80211-freq-limit-property-to-li.patch | 29 +++
 .../550-ath9k-disable-bands-via-dt.patch  | 15 --
 .../patches/ath9k/552-ath9k-ahb_of.patch  |  8 +
 target/linux/ath79/dts/ar9342_ubnt_wa.dtsi|  2 +-
 .../linux/ath79/dts/ar9344_atheros_db120.dts  |  2 +-
 .../ath79/dts/ar9344_engenius_exx600.dtsi |  4 +--
 target/linux/ath79/dts/ar9344_pcs_cap324.dts  |  4 +--
 .../boot/dts/lantiq/vr9_bt_homehub-v5a.dts|  2 +-
 .../boot/dts/lantiq/vr9_tplink_tdw89x0.dtsi   |  2 +-
 9 files changed, 38 insertions(+), 30 deletions(-)
 create mode 100644 
package/kernel/mac80211/patches/ath9k/040-ath9k-support-DT-ieee80211-freq-limit-property-to-li.patch
 delete mode 100644 
package/kernel/mac80211/patches/ath9k/550-ath9k-disable-bands-via-dt.patch

diff --git 
a/package/kernel/mac80211/patches/ath9k/040-ath9k-support-DT-ieee80211-freq-limit-property-to-li.patch
 
b/package/kernel/mac80211/patches/ath9k/040-ath9k-support-DT-ieee80211-freq-limit-property-to-li.patch
new file mode 100644
index 00..4142cb6ffd
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/ath9k/040-ath9k-support-DT-ieee80211-freq-limit-property-to-li.patch
@@ -0,0 +1,29 @@
+From 03469e79fee9e8e908dae3bd1a80bcd9a66f2a88 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Mon, 11 Oct 2021 18:18:00 +0300
+Subject: ath9k: support DT ieee80211-freq-limit property to limit channels
+
+The common DT property can be used to limit the available channels
+but ath9k has to manually call wiphy_read_of_freq_limits().
+
+I would have put this into ath9k_of_init(). But it didn't work there.
+The reason is that in ath9k_of_init() the channels and bands are not yet
+registered in the wiphy struct. So there isn't any channel to flag as
+disabled.
+
+Signed-off-by: Christian Lamparter 
+Signed-off-by: Kalle Valo 
+Link: https://lore.kernel.org/r/20211009212847.1781986-1-chunk...@gmail.com
+---
+--- a/drivers/net/wireless/ath/ath9k/init.c
 b/drivers/net/wireless/ath/ath9k/init.c
+@@ -1094,6 +1094,8 @@ int ath9k_init_device(u16 devid, struct ath_softc *sc,
+   ARRAY_SIZE(ath9k_tpt_blink));
+ #endif
+ 
++  wiphy_read_of_freq_limits(hw->wiphy);
++
+   /* Register with mac80211 */
+   error = ieee80211_register_hw(hw);
+   if (error)
+
diff --git 
a/package/kernel/mac80211/patches/ath9k/550-ath9k-disable-bands-via-dt.patch 
b/package/kernel/mac80211/patches/ath9k/550-ath9k-disable-bands-via-dt.patch
deleted file mode 100644
index d1593339d2..00
--- a/package/kernel/mac80211/patches/ath9k/550-ath9k-disable-bands-via-dt.patch
+++ /dev/null
@@ -1,15 +0,0 @@
 a/drivers/net/wireless/ath/ath9k/init.c
-+++ b/drivers/net/wireless/ath/ath9k/init.c
-@@ -625,6 +625,12 @@ static int ath9k_of_init(struct ath_soft
- 
-   ath_dbg(common, CONFIG, "parsing configuration from OF node\n");
- 
-+  if (of_property_read_bool(np, "qca,disable-2ghz"))
-+  ah->disable_2ghz = true;
-+
-+  if (of_property_read_bool(np, "qca,disable-5ghz"))
-+  ah->disable_5ghz = true;
-+
-   if (of_property_read_bool(np, "qca,no-eeprom")) {
-   /* ath9k-eeprom--.bin */
-   scnprintf(eeprom_name, sizeof(eeprom_name),
diff --git a/package/kernel/mac80211/patches/ath9k/552-ath9k-ahb_of.patch 
b/package/kernel/mac80211/patches/ath9k/552-ath9k-ahb_of.patch
index 2552bbc7a1..fce6db2167 100644
--- a/package/kernel/mac80211/patches/ath9k/552-ath9k-ahb_of.patch
+++ b/package/kernel/mac80211/patches/ath9k/552-ath9k-ahb_of.patch
@@ -16,7 +16,7 @@
  
  static const struct platform_device_id ath9k_platform_id_table[] = {
{
-@@ -69,6 +77,242 @@ static const struct ath_bus_ops ath_ahb_
+@@ -69,6 +77,236 @@ static const struct ath_bus_ops ath_ahb_
.eeprom_read = ath_ahb_eeprom_read,
  };
  
@@ -218,12 +218,6 @@
 +  else
 +  pdata->led_pin = -1;
 +
-+  if (of_property_read_bool(pdev->dev.of_node, "qca,disable-2ghz"))
-+  pdata->disable_2ghz = true;
-+
-+  if (of_property_read_bool(pdev->dev.of_node, "qca,disable-5ghz"))
-+  pdata->disable_5ghz = true;
-+
 +  if (of_property_read_bool(pdev->dev.of_node, "qca,tx-gain-buffalo"))
 +  pdata->tx_gain_buffalo =

Re: [PATCH] bcm53xx: switch to the upstream DSA-based b53 driver

2021-10-18 Thread Christian Lamparter
Hello,

On Mon, Oct 18, 2021 at 3:06 PM Rafał Miłecki  wrote:
> 1. Drop swconfig
> 2. Simplify network setup
> 3. Verify network config
> 4. Disable Buffalo WZR-900DHP for now - it misses ports definition
>

Nice! MR32's portion of a similar patch (the only change that has
remained... as the DTS is upstream)
in my staging-tree looks very similar.
<https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=ae2a37033ee59f85087101c339e95f99a8e113ec>
> +   meraki,mr32)
> +   ucidef_set_interface_lan "poe"
> +   ;;

I opted not to set the dhcp mode as you did since zeroconf wasn't
supported by the udhcp (maybe that has changed?).
But yes, this should be good.

Reviewed-By: Christian Lamparter 

> Signed-off-by: Rafał Miłecki 
> ---
> diff --git a/target/linux/bcm53xx/Makefile b/target/linux/bcm53xx/Makefile
> index 083f905096..921058d140 100644
> --- a/target/linux/bcm53xx/Makefile
> +++ b/target/linux/bcm53xx/Makefile
> @@ -22,7 +22,7 @@ include $(INCLUDE_DIR)/target.mk
>
>  KERNELNAME:=zImage dtbs
>
> -DEFAULT_PACKAGES += swconfig nvram \
> +DEFAULT_PACKAGES += nvram \
^^^ See below in the config-5.10 / CONFIG_SWCONFIG=y

> diff --git a/target/linux/bcm53xx/config-5.10 
> b/target/linux/bcm53xx/config-5.10
> index 9d98e812bd..73cccf1d3a 100644
> --- a/target/linux/bcm53xx/config-5.10
> +++ b/target/linux/bcm53xx/config-5.10
> @@ -267,10 +282,6 @@ CONFIG_SPI_MASTER=y
>  CONFIG_SPI_MEM=y
>  CONFIG_SRCU=y
>  CONFIG_SWCONFIG=y

-CONFIG_SWCONFIG=y (it should be possible to remove this line too)

(Or does this symbol creep on back during kernel_*config? if so

# CONFIG_SWCONFIG is not set
)

Cheers,
Christian

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


[RFC PATCH v2] gpio-button-hotplug: convert to gpio descriptor (gpiod_) API

2021-08-19 Thread Christian Lamparter
OpenWrt's special gpio-button-hotplug driver is still using
exclusively the legacy GPIO Subsystem gpio_ API.

While it still does work fine for most devices, upstream
linux is starting to convert platform support like that of
the APU2/3/4 to the new GPIOD LOOKUP tables that are not
supported by it.

Hence, this patch replaces the gpio_ calls present in
gpio-button-hotplug with gpiod_ equivalent wherever
it's possible. This allows the driver to use the
gpiod lookup tables and still have a fallback for
legacy platform data code that just sets button->gpio
set to the real button/switch GPIO.

As a bonus: the active_low logic is now being handled
by the linux's gpio subsystem too. Another issue that
was address is the of_handle leak in the dt parser
error path.

Tested with legacy platform data: x86_64: APU2, MX-100
Tested on OF: ATH79; MR18, APM821xx: Netgear WNDR4700,
  RAMIPS: WL-330N3G
  LANTIQ: AVM FritzBox 7360v1

Reported-by: Chris Blake 
Tested-by: Chris Blake 
Reviewed-by: Linus Walleij 
Signed-off-by: Christian Lamparter 
---
 .../src/gpio-button-hotplug.c | 142 --
 1 file changed, 63 insertions(+), 79 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 9575c6245b..fcaf7f59de 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
@@ -242,11 +242,11 @@ static int gpio_button_get_value(struct 
gpio_keys_button_data *bdata)
int val;
 
if (bdata->can_sleep)
-   val = !!gpio_get_value_cansleep(bdata->b->gpio);
+   val = !!gpiod_get_value_cansleep(bdata->gpiod);
else
-   val = !!gpio_get_value(bdata->b->gpio);
+   val = !!gpiod_get_value(bdata->gpiod);
 
-   return val ^ bdata->b->active_low;
+   return val;
 }
 
 static void gpio_keys_handle_button(struct gpio_keys_button_data *bdata)
@@ -365,7 +365,6 @@ gpio_keys_get_devtree_pdata(struct device *dev)
struct device_node *node, *pp;
struct gpio_keys_platform_data *pdata;
struct gpio_keys_button *button;
-   int error;
int nbuttons;
int i = 0;
 
@@ -375,14 +374,12 @@ gpio_keys_get_devtree_pdata(struct device *dev)
 
nbuttons = of_get_child_count(node);
if (nbuttons == 0)
-   return NULL;
+   return ERR_PTR(-EINVAL);
 
pdata = devm_kzalloc(dev, sizeof(*pdata) + nbuttons * (sizeof *button),
GFP_KERNEL);
-   if (!pdata) {
-   error = -ENOMEM;
-   goto err_out;
-   }
+   if (!pdata)
+   return ERR_PTR(-ENOMEM);
 
pdata->buttons = (struct gpio_keys_button *)(pdata + 1);
pdata->nbuttons = nbuttons;
@@ -391,37 +388,13 @@ gpio_keys_get_devtree_pdata(struct device *dev)
of_property_read_u32(node, "poll-interval", >poll_interval);
 
for_each_child_of_node(node, pp) {
-   enum of_gpio_flags flags;
-
-   if (!of_find_property(pp, "gpios", NULL)) {
-   pdata->nbuttons--;
-   dev_warn(dev, "Found button without gpios\n");
-   continue;
-   }
-
button = (struct gpio_keys_button *)(>buttons[i++]);
 
-   button->irq = irq_of_parse_and_map(pp, 0);
-
-   button->gpio = of_get_gpio_flags(pp, 0, );
-   if (button->gpio < 0) {
-   error = button->gpio;
-   if (error != -ENOENT) {
-   if (error != -EPROBE_DEFER)
-   dev_err(dev,
-   "Failed to get gpio flags, 
error: %d\n",
-   error);
-   return ERR_PTR(error);
-   }
-   } else {
-   button->active_low = !!(flags & OF_GPIO_ACTIVE_LOW);
-   }
-
if (of_property_read_u32(pp, "linux,code", >code)) {
-   dev_err(dev, "Button without keycode: 0x%x\n",
-   button->gpio);
-   error = -EINVAL;
-   goto err_out;
+   dev_err(dev, "Button node '%s' without keycode\n",
+   pp->full_name);
+   of_node_put(pp);
+   return ERR_PTR(-EINVAL);
}
 
button->desc = of_get_property(pp, "label", NULL);
@@ -434,17 +407,12 @@ gpio_keys_get_devtree_pdata(struct device *dev)
if (of_property_read_u32(pp, "debounce-interva

Re: [PATCH 1/5] firmware-utils: mkmerakifw-old: replace GPL-2.0-only boilerplate with SPDX

2021-08-08 Thread Christian Lamparter

On 06/08/2021 12:59, Rafał Miłecki wrote:

From: Rafał Miłecki 

This was missed because scancode license scanner was confused by a
comment about Cisco's GPL code github repository.

Cc: Christian Lamparter 
Signed-off-by: Rafał Miłecki 


Acked-by: Christian Lamparter 

Does this help?

Cheers,
Christian

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


[RFC PATCH] gpio-button-hotplug: gpio descriptor API update

2021-08-05 Thread Christian Lamparter
This driver still uses the Legacy GPIO Subsystem gpio_ API.
While it does work fine, it won't supports the new GPIO
LOOKUP tables that have been popping up upstream since v5.0.

For APU2 users > linux 5.4:
Please test if this fixes your reset button.

(DT devices needs to be re-tested as well)

Reported-by: Chris Blake 
Signed-off-by: Christian Lamparter 
---
 .../src/gpio-button-hotplug.c | 83 ---
 1 file changed, 35 insertions(+), 48 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 9575c6245b..bc151645e3 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
@@ -242,11 +242,11 @@ static int gpio_button_get_value(struct 
gpio_keys_button_data *bdata)
int val;
 
if (bdata->can_sleep)
-   val = !!gpio_get_value_cansleep(bdata->b->gpio);
+   val = !!gpiod_get_value_cansleep(bdata->gpiod);
else
-   val = !!gpio_get_value(bdata->b->gpio);
+   val = !!gpiod_get_value(bdata->gpiod);
 
-   return val ^ bdata->b->active_low;
+   return val;
 }
 
 static void gpio_keys_handle_button(struct gpio_keys_button_data *bdata)
@@ -391,35 +391,15 @@ gpio_keys_get_devtree_pdata(struct device *dev)
of_property_read_u32(node, "poll-interval", >poll_interval);
 
for_each_child_of_node(node, pp) {
-   enum of_gpio_flags flags;
-
-   if (!of_find_property(pp, "gpios", NULL)) {
-   pdata->nbuttons--;
-   dev_warn(dev, "Found button without gpios\n");
-   continue;
-   }
-
button = (struct gpio_keys_button *)(>buttons[i++]);
 
-   button->irq = irq_of_parse_and_map(pp, 0);
+   button->gpio = -ENOENT; /* gets filled in later */
 
-   button->gpio = of_get_gpio_flags(pp, 0, );
-   if (button->gpio < 0) {
-   error = button->gpio;
-   if (error != -ENOENT) {
-   if (error != -EPROBE_DEFER)
-   dev_err(dev,
-   "Failed to get gpio flags, 
error: %d\n",
-   error);
-   return ERR_PTR(error);
-   }
-   } else {
-   button->active_low = !!(flags & OF_GPIO_ACTIVE_LOW);
-   }
+   button->irq = irq_of_parse_and_map(pp, 0);
 
if (of_property_read_u32(pp, "linux,code", >code)) {
-   dev_err(dev, "Button without keycode: 0x%x\n",
-   button->gpio);
+   dev_err(dev, "Button node '%s' without keycode\n",
+   pp->full_name);
error = -EINVAL;
goto err_out;
}
@@ -514,7 +494,6 @@ static int gpio_keys_button_probe(struct platform_device 
*pdev,
for (i = 0; i < pdata->nbuttons; i++) {
struct gpio_keys_button *button = [i];
struct gpio_keys_button_data *bdata = >data[i];
-   unsigned int gpio = button->gpio;
 
if (button->wakeup) {
dev_err(dev, "does not support wakeup\n");
@@ -534,26 +513,37 @@ static int gpio_keys_button_probe(struct platform_device 
*pdev,
continue;
}
 
-   error = devm_gpio_request(dev, gpio,
+   bdata->gpiod = devm_gpiod_get_index(dev,
+   button->desc ? button->desc : DRV_NAME, i, GPIOD_IN);
+   if (IS_ERR(bdata->gpiod)) {
+   unsigned gpio;
+
+   error = PTR_ERR(bdata->gpiod);
+
+   /*
+* In case of -ENOENT, there still hope that we might
+* just be using legacy platform data, which has the
+* button->gpio filled in.
+*/
+   if (error != -ENOENT || !gpio_is_valid(button->gpio))
+   return error;
+
+   gpio = button->gpio;
+   error = devm_gpio_request_one(dev, gpio, GPIOF_IN |
+(button->active_low ? GPIOF_ACTIVE_LOW : 
0),
 button->desc ? button->desc : DRV_NAME);
-   if (error) {
-   dev_err(dev, "unable to claim gpio %u, err=%d\n",
-   

Re: [PATCH] ipq40xx: increase SPI frequency for Zyxel NBG6617 The mx25l25635e supports clock speed up to 50Mhz.

2021-07-09 Thread Christian Lamparter

On 09/07/2021 11:15, Dmitry Tunin wrote:

Also remove obsolete "mx25l25635f" hack.


Looks like the subject contains part of the commit message?!
Please try to keep that subject line short enough (like 50-60
letters) so it doesn't wrap on git.openwrt.org / github view.

(while at it please also change the node-name mx25l...@ to flash@)

Thanks
Christian


Signed-off-by: Dmitry Tunin 
---
  .../ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts  | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts 
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
index 4d17325c8d..28a299218b 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
@@ -211,9 +211,9 @@
cs-gpios = < 54 GPIO_ACTIVE_HIGH>;
  
  	mx25l25635f@0 {

-   compatible = "mx25l25635f", "jedec,spi-nor";
+   compatible = "jedec,spi-nor";
reg = <0>;
-   spi-max-frequency = <2400>;
+   spi-max-frequency = <5000>;
status = "okay";
m25p,fast-read;
  




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


Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-17 Thread Christian Lamparter

Hello,

On 15/04/2021 01:51, Linus Walleij wrote:

On Tue, Apr 13, 2021 at 11:37 PM Hauke Mehrtens  wrote:


The target kernel configurations should be small and most of the generic
settings should be done in the target/linux/generic/config-* config file.
The target configuration only contains the extra configuration options
or the options which are different.

(...)

You can add new generic options to target/linux/generic/config-5.10
manually.


OK I get it, I sent a slew of patches to the generic config.

We drive-by contributors just assume the generic config is
Perfect(TM) you know, now I realize I have to contribute to that
effort.



That was nicely worded... Yeah I know, there's no need for this.
In my case: That CoVID workload has bogged me down during the week.
I sometimes have a bit of spare-time on the weekends.

From what I can tell, the situation is: your gemini target would
be the first target that isn't "source-only" (which means it gets
skipped by the builderbots) that likes to fully switch to 5.10.
So you'll get all the fun of having to endure broken packages,
or have to come up with fixes for other stuff to make the buildbot
happy.

This might look overly cautions, but when I foolishly "merged" my
apm82181 testing 5.10 I broke other targets 5.10 support so bad
that the "fix patch" needed a second "fix patch". :(

And as you have seen even something as simple as a default for
a CONFIG_* SYMBOL can a show-stopper due deer-in-the-headlights
moments from crucial dependencies in different packages like musl...


For example do you really need CONFIG_OABI_COMPAT for gemini?

You should try to remove just most of the options which are not SoC
specific.


Yups I managed to diet out a bunch of stuff.



Do you have an update? I've queued your patch with "one weird trick"
(use KERNEL_TESTING_PATCHVER instead of KERNEL_PATCHVER).


Yes, this will cause the buildbot to still built your target with 5.4
but the 5.10 support will be there (behind CONFIG_TESTING_KERNEL).

Cheers,
Christian

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


Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-12 Thread Christian Lamparter

On 12/04/2021 00:11, Linus Walleij wrote:

Only two patches against mainline remains. Switch to v5.10
which works very nicely with all Gemini devices.

Signed-off-by: Linus Walleij 
---
  target/linux/gemini/Makefile  |   2 +-
  target/linux/gemini/config-5.10   | 465 ++
  ...t-fotg2-add-Gemini-specific-handling.patch | 131 +
  ...-DIR-685-partition-table-for-OpenWrt.patch |  37 ++
  4 files changed, 634 insertions(+), 1 deletion(-)
  create mode 100644 target/linux/gemini/config-5.10
  create mode 100644 
target/linux/gemini/patches-5.10/0001-usb-host-fotg2-add-Gemini-specific-handling.patch
  create mode 100644 
target/linux/gemini/patches-5.10/0002-ARM-dts-Augment-DIR-685-partition-table-for-OpenWrt.patch

diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile
index d2acb52facf7..95a5a87eaa4d 100644
--- a/target/linux/gemini/Makefile
+++ b/target/linux/gemini/Makefile
@@ -10,7 +10,7 @@ BOARDNAME:=Cortina Systems CS351x
  FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part
  CPU_TYPE:=fa526
  
-KERNEL_PATCHVER:=5.4

+KERNEL_PATCHVER:=5.10


Hmm, when building this with the BUILDBOT config (CONFIG_BUILDBOT)
and throw in the CONFIG_ALL_* for userspace + kernel modules for
good measure. It fails with the default world build (without the
V=s option) because the following symbols are not yet defined in
either the generic or gemini-specific kernel config.

CONFIG_COMPAT_32BIT_TIME
CONFIG_PCIEASPM
CONFIG_MTD_PHYSMAP_IXP4XX
CONFIG_GPIO_CDEV_V1
CONFIG_CPU_THERMAL
CONFIG_DMA_PERNUMA_CMA

At least CPU_THERMAL is also a show-stopper for apm82181 5.10,
so should these just be added added as either disabled
(# CONFIG_ ... is not set) or in case of CONFIG_PCIEASPM=X
(whatever the default is there) in target/linux/generic/config-5.10?

Or CPU_THERMAL could be an issue for some high-powered x86 or ARM?

Cheers,
Christian

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


Re: [PATCH 1/2] ipq40xx: net: phy: qca807x: fix GPIO driver

2021-03-04 Thread Christian Lamparter

On 04/03/2021 14:36, Robert Marko wrote:

It's my fault, I exported it as a part of the patch series with
unrelated patches and git-send much have picked that up.
There is no 2/2.

Do you want me to export it again and resend it?


Oh no, that's certainly not necessary ;)

Cheers,
Christian

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


Re: [PATCH 1/2] ipq40xx: net: phy: qca807x: fix GPIO driver

2021-03-04 Thread Christian Lamparter

Hello,

is there a PATCH 2/2 for ipq40xx too? Or was that 1/2 in the subject
just because the file got copied around?

Cheers
Christian

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


Re: Enabling SATA via SATA_DWC on Meraki MX60W / APM82181

2021-02-25 Thread Christian Lamparter

Hello Martin,

On 22/02/2021 22:54, Martin Kennedy wrote:


I did make a post a good while ago to gauge interest (there was none).
It is here: 
https://forum.openwrt.org/t/mx60w-any-interest-in-a-diy-nas-guide-need-some-advice-for-sata-pads-and-msata-slot-compatibility/65718



Yeah, this is your personal hobby project, isn't it? There are basically no 
hardware
mods for the APM82181 as compared to the ath79/ramips/mediatek. For engagement, 
one
has to really invest there to make it popular Honestly, the APM82181 seems 
to
stagnate at the "working as intended" level.


I have actually tried kmod-ata-ahci out, but with a potentially
less-suitable ASM1061. Sadly, once the kmod-ata-ahci module has been
kmodloaded, the drives will `ata\d.00: failed to IDENTIFY` -- I
ascribed this to an issue with PCIe init on the platform as you
described on the linuxppc-dev mailing list, though I had not properly
poked the device tree to inform the device of this change. The ASM1061
chipset is known-working on other platforms using OpenWrt (I used two
ASM1061s in an Aerohive AP330 as my NAS for a while).


I found my minipcie<->sata 2-port thingy.  It's an ASMedia Technology Inc. 
ASM1062 Serial ATA Controller [1b21:0612]
I don't have a MX60(W) so I used a Netgear WNDAP660. Hope this still counts...

And would you look at that: :)

[   41.780183] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[  114.081146] kmodloader: loading kernel modules from /etc/modules.d/*
[  114.165797] ahci :43:00.0: version 3.0
[  114.165836] ahci :43:00.0: enabling device (0006 -> 0007)
[  114.234964] ahci :43:00.0: SSS flag set, parallel bus scan disabled
[  114.314662] ahci :43:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 
impl SATA mode
[  114.411770] ahci :43:00.0: flags: 64bit ncq sntf stag led clo pmp pio 
slum part ccc sxs
[  114.519719] scsi host0: ahci
[  114.556879] scsi host1: ahci
[  114.592747] ata1: SATA max UDMA/133 abar m512@0xe0001 port 0xe00010100 
irq 19
[  114.682614] ata2: SATA max UDMA/133 abar m512@0xe0001 port 0xe00010180 
irq 19
[  115.247864] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  115.322963] ata1.00: HPA detected: current 1953523055, native 1953525168
[  115.403754] ata1.00: ATA-8: Hitachi HDT721010SLA360, ST6OA3AA, max UDMA/133
[  115.487348] ata1.00: 1953523055 sectors, multi 0: LBA48 NCQ (depth 32), AA
[  115.661382] ata1.00: configured for UDMA/133
[  115.713002] scsi 0:0:0:0: Direct-Access ATA  Hitachi HDT72101 A3AA 
PQ: 0 ANSI: 5
[  115.817054] sd 0:0:0:0: [sda] 1953523055 512-byte logical blocks: (1.00 
TB/932 GiB)
[  115.909977] sd 0:0:0:0: [sda] Write Protect is off
[  115.967536] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[  115.968179] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[  116.134055]  sda: sda1
[  116.164790] sd 0:0:0:0: [sda] Attached SCSI disk
[  116.240626] ata2: SATA link down (SStatus 0 SControl 300)
[  116.308487] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  116.375543] kmodloader: done loading kernel modules from /etc/modules.d/*
[  116.543762] kmodloader: loading kernel modules from /etc/modules.d/*
[  116.624340] kmodloader: done loading kernel modules from /etc/modules.d/*
[  116.792215] kmodloader: loading kernel modules from /etc/modules.d/*
[  116.872711] kmodloader: done loading kernel modules from /etc/modules.d/*

root@wndap660:/tmp# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 308 MB in  3.02 seconds = 101.87 MB/sec
(This 100 MB/sec is OK for a 1 GiB 3,5" Hitachi HDD Drive from 2009 I think).

I have the suspecion that your problem is caused by lack of proper to MSI(-X) 
there.
While the PCIE Hardware in the SoC has support for MSI (it's pcie) and the 
linux and
DTS has some MSI bits. The linux driver for it needs to be brought into 2021.
What I did was just editing the ahci.c driver in the linux kernel.

I swapped out the existing:

{ PCI_VDEVICE(ASMEDIA, 0x0612), board_ahci }, /* ASM1062 */

with:

{ PCI_VDEVICE(ASMEDIA, 0x0612), board_ahci_nomsi }, /* ASM1062 */

and it then loaded (before it was failing at the same NO_IDENTIFY).

/proc/interrupts also looks "healthy" (for a no-msi setup)

 19:344   UIC  14 Level ahci[:43:00.0]

(Maybe the pci=nomsi kernel parameter would do the trick as well. Could you
adding this to the bootargs in uboot and check if the ahci.c code now works?)

Cheers,
Christian

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


Re: Enabling SATA via SATA_DWC on Meraki MX60W / APM82181

2021-02-22 Thread Christian Lamparter
Hello,

On Sun, Feb 21, 2021 at 8:56 PM Martin Kennedy  wrote:
>
> I would like to get the HDD port on the MX60 / MX60W working.

This is odd... didn't know there is a HDD port on the MX60/MX60W

>
> Knowing that the APM82181 muxes PCIe and SATA, I tried replacing the
> PCIe WLAN module with an mSATA one, and disabling PCIe in the MX60
> device tree, but enabling SATA0/1:

Ok...

[...]

> I have soldered a SATA power+data header onto an MX60W's pads; I have
> bridged solder on four points where 1nF 0102 SMD capacitor should have
> been placed to avoid DC bias. Still, despite a WG Green 3.5" drive,
> Sandisk U100 8GB 2.5" drive and Toshiba 250GB 2.5" HDD all certainly
> powering on on boot, none of these were recognized; instead, I only
> got a 'SATA link down' once the port had been probed and IRQs set up.

This is a very odd request. I could see this as a "challenge" just to
see what it takes
and if it's possible... Maybe make a forum thread too?

Since you went for 2,5" and 3,5" drivers, you could get cheapish
(~10-20 € on ebay)
ready-made minipcie<->sata adaptors available with Marvell brand chips that have
2/4 SATA-Ports (whatever fits). With those you should be able to just
fire up OpenWrt
and load kmod-ata-ahci to get access to the connected SATA drivers
with much less
hassle.

(And the Marvell chips should support SATA-3 + NCQ. The DesignWare
IP-Core inside
the APM82181 can only do SATA-2 and the driver does not have support for NCQ).

Come to think about it, I have one of those minipcie<->sata thingies
at home, I could try
this with a WNDAP620 and a WD HDD. (I don't have any of those mini
sata ssd, so I
can't try that).

> Does DesignWare SATA on the APM82181 require U-boot's involvement to
> initialize? Or am I missing something from the OpenWrt side?

Yes, there's some special sauce in Uboot. You could look at the Netgear's
WNDR4700 UBoot (uses both pcie + sata) and the MyBook Live DUO. Both
Uboots sources are part of their respective GPL drops. The MX60(W) also
has its uboot available on github... And I think (I don't know 100%) there was
some commented code about setting up SATA.

> Would attempting to boot Debian instead be a good idea?

If you are looking for Debian on APM82181, I've made a
"build-your-own-debian" for the MyBook Live (DUO).



You cloud swap out the MyBookLive.dts with that of the MX60(W) and change
the uImage packaging a bit to get a kernel that you can put in the NAND to boot
off. But yea, you could have a good shot at running Debian SID on the MX60.

Cheers and Have fun with your SATA-on-MX60 Project,
Christian

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


Re: [PATCH] x86/64: Add CONFIG_DEVMEM=y for targets/x86/64

2021-02-14 Thread Christian Lamparter

On 14/02/2021 10:33, Bjørn Mork wrote:

Petr Štetiar  writes:


I assume it's for some legacy reasons which don't apply in 2021 to OpenWrt.


Not sure I understand what you mean here.  There was a a request for
this feature, so it obviously applies to OpenWrt.  And it's already
enabled for the ipq807x and rockchip targets, so you can't really claim
that it's not available in OpenWrt either.


Hmm, I think I was bitten by this before... In my case setting a
CONFIG_DEVMEM=y in any of the targets-config like this did not what
its supposed to do.

This was because this setting gets "forced" by the CONFIG KERNEL_DEVMEM in our
own config/Config-kernel.in. So we might as well remove the CONFIG_DEVMEM
from all subtarget configuration. (I think the target/generic/config-X can
stay or there will be edit-wars).

(My best guess how these settings end up in the targets config, is that these
settings get there by accident when the configurations are refreshed upon a
kernel-bump.)

Cheers,
Christian




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


Re: Please revert 98b86296e6 as it breaks several ipq806x devices

2020-12-28 Thread Christian Lamparter

On 28/12/2020 15:27, Adrian Schmutzler wrote:

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Hannu Nyman
Sent: Montag, 28. Dezember 2020 10:12
To: OpenWrt Development List 
Cc: Petr Štetiar ; Christian Lamparter

Subject: Please revert 98b86296e6 as it breaks several ipq806x devices


https://github.com/openwrt/openwrt/commit/57e4cc8261ca6f0b32e4da6922a8f52ef82c4dc6

This is meant as an emergency measure (thus no "Fixes"), and should be properly 
addressed at some point.



hmm, the R7800 must have some crazy bootargs-overrides when these
impact sysupgrade as well. Let's hope there isn't an issue with
the platform.sh + asrock.sh changes.

@hannu: can you please post your R7800's /proc/device-tree/chosen/ files (name 
+ content)
for reference?

Cheers
Christian





Please revert commit 98b86296e6 "ipq806x: add support for ASRock G10" as
it breaks several popular ipq806x devices.

98b86296e6 adds a new kernel config symbol CONFIG_CMDLINE_OVERRIDE
for ipq806x and enables it for all ipq806x devices.

Based on forum discussion and my own experience, that new symbol
apparently changes the kernel command line and breaks several ipq806x
devices. Either the devices do not boot or there are other symptoms.


Symptoms in my own R7800:

* serial console is disabled. It works during u-boot but is silent after kernel
takes over  (as console gets assigned to wrong tty)

* sysupgrade FROM builds with commit 98b86296e6 included does not work.
Debugging that is not feasible, as serial console is broken...



Bug report in:

https://bugs.openwrt.org/index.php?do=details_id=3540

and in

https://github.com/openwrt/openwrt/commit/98b86296e67dd2b467212fe1
a577656e6d3725da#commitcomment-45455875


Things get fixed by reverting the kernel symbol part from 98b86296e6:


|--- a/target/linux/ipq806x/config-5.4 +++
|b/target/linux/ipq806x/config-5.4
@@ -78,7 +78,7 @@ CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKSRC_QCOM=y
CONFIG_CLONE_BACKWARDS=y -CONFIG_CMDLINE_OVERRIDE=y +#
CONFIG_CMDLINE_OVERRIDE is not set CONFIG_COMMON_CLK=y
CONFIG_COMMON_CLK_QCOM=y CONFIG_COMPAT_32BIT_TIME=y|




___
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 v4 7/8] bcm53xx: add Cisco Meraki MR32

2020-09-19 Thread Christian Lamparter
This patch adds support for Cisco Meraki MR32.
The unit was donated by Chris Blake. Thank you!

WARNING:
Only the 1x1:1 abgn Air Marshal WIPS wifi is currently supported by b43:
 b43-phy2: Found PHY: Analog 9, Type 4 (N), Revision 16
 b43-phy2: Found Radio: Manuf 0x17F, ID 0x2057, Revision 9, Version 1
 b43-phy2: Loading firmware version 784.2 (2012-08-15 21:35:19)
 and only as 802.11ABG!

while WIFI1 and WIFI2 (both BCM4352) are not:
 b43-phy0: Broadcom 4352 WLAN found (core revision 42)
 b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)

Hardware Highlights:

SoC:Broadcom BCM53016A1 (1 GHz, 2 cores)
RAM:128 MiB
NAND:   128 MiB Spansion S34ML01G2 (~114 MiB useable)
ETH:1GBit Ethernet Port - PoE
WIFI1:  Broadcom BCM43520 an+ac (2x2:2 - id: 0x4352)
WIFI2:  Broadcom BCM43520 bgn (2x2:2 - id: 0x4352)
WIFI3:  Broadcom BCM43428 abgn (1x1:1 - id: 43428)

BLE:Broadcom BCM20732 (ttyS1)
LEDS:   1 x Programmable RGB Status LED (driven by a PWM)
1 x White LED (GPIO)
1 x Orange LED Fault Indicator (GPIO)
2 x LAN Activity / Speed LEDs (On the RJ45 Port)
BUTTON: one Reset button
MISC:   AT24C64 8KiB EEPROM (i2c - stores Ethernet MAC + Serial#!)
ina219 hardware monitor (i2c)
Kensington Lock

SERIAL:
WARNING: The serial port needs a TTL/RS-232 3V3 level converter!
The Serial setting is 115200-8-N-1. The board has a populated
right angle 1x4 0.1" pinheader.
The pinout is: VCC, RX, TX, GND. (Use a multimeter)

Flashing needs a serial adaptor (due to the lack of a working dropbear on
the original firmware).

This flashing procedure for the MR32 was tested with firmware:
"r23-149867:150252-aacharya".

0. Create a seperate Ethernet LAN which does not have access to the internet.
   Ideally use 192.168.1.2 for your PC. Make sure to reserve 192.168.1.1 it
   will be used later on by the OpenWrt firmware. The original Meraki firmware
   will likely try to setup the network via DHCP Discovery, so make sure your
   PC is running a DHCP-Server (i.e.: dnsmasq)
   '# dnsmasq -i eth# -F 192.168.1.5,192.168.1.50
   Furthermore, the PC needs a supported ssh/http/ftp server in order to
   retrieve the initramfs + dtb file

1. Disassemble the MR32 device by removing all screws (4 screws are located
   under the 4 rubber feets!) and prying open the plastic covers without
   breaking the plastic retention clips. Once inside, remove all the screws
   on the outer metal shielding to get to the PCB. It's not necessary to
   remove the antennas!

2. Connect the serial cable to the serial header.

3. Partially reassemble the outer metal shielding to ensure that the SoC
   has a proper heat sink.

4. Connect the Ethernet patch cable to the device and the power cable.

5. Wait for the device to boot and enter the root shell.
   (rooting is not discussed in detail here please refer to
   Chris Blake - "pwning the meraki mr18" blog post:
   <https://servernetworktech.com/2016/02/pwning-the-meraki-mr18/>
   (The same method works with the MR32's r23-149867:150252-aacharya)

   Wait for the MR32 to enter the "" prompt and enter:
odm serial_num read
   (Verify that it matches what's on the S/N Sticker on the back!)
odm serial_num write Q2XX--XXXV
odm serial_num read
   (Verify that the S/N has changed - and the LED start to flash)

   now to flash the firmware:
odm firmware part.safe "http://192.168.1.2/mr32-initramfs.bin;

Once OpenWrt booted use sysupgrade to permanently install
OpenWrt. To do this: Download the latest sysupgrade.bin file
for the MR32 to the device and use sysupgrade *sysupgrade.bin
to install it.

WARNING: DO NOT DELETE the "storage" ubi volume!

To flash later MR32 Firmwares like r25-201804051805-G885d6d78-dhow-rel
requires in-circut-i2c tools to access the I2C EEPROM AT24C64 next to
the SoC. The idea is pretty much the same as from Step 5 from above:
Change the serial number to Q2XV (should be around 0x7c), then
attach a serial cable, ethernet (but make sure the device can't reach
the internet!) hit "s" (the small s!) during boot to enter the root-shell
and add the following commands to the /storage/config there:

serial_allow_odm true
serial_access_enabled true
serial_access_check false
valid_config true

and then hit exit to let it finish booting.

Signed-off-by: Christian Lamparter 

---

rfc -> v2
- fixed Adrian's comments
- unbroke sysupgrade on other bcm53xx

v2 -> v3
- use florians patch
- make a separate patch for the i2c-gpio -> i2c-hw

v3 -> v4
- remove superflous kmod-hwmon-core
---
 .../bcm53xx/base-files/etc/board.d/02_network |   7 +-
 target/linux/bcm53xx/base-files/etc/diag.sh   |   3 +
 .../lib/preinit/07_set_preinit_iface_bcm53xx  |  14 +
 .../base-files/lib/upgrade/platform.sh|  43 ++-
 target/linux/bcm53xx/image/Makefile   |  27 ++
 .

[PATCH v4 1/8] scripts: mkits.sh make it possible to specify fdt@#

2020-09-19 Thread Christian Lamparter
Some bootloaders are really keen on just one special
fdt in a multi-image fit image. This is a problem, because
currently this is fixed to "fdt@1".

This patch introduces a new device variable:
DEVICE_FDT_NUM that allows to specify the right
fdt number.

If the value is absent "1" will be chosen.

Signed-off-by: Christian Lamparter 
---
 include/image-commands.mk |  1 +
 include/image.mk  |  6 --
 scripts/mkits.sh  | 12 
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/image-commands.mk b/include/image-commands.mk
index 9516801c8d..740d627fc7 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -158,6 +158,7 @@ define Build/fit
-D $(DEVICE_NAME) -o $@.its -k $@ \
$(if $(word 2,$(1)),-d $(word 2,$(1))) -C $(word 1,$(1)) \
-a $(KERNEL_LOADADDR) -e $(if 
$(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
+   $(if $(DEVICE_FDT_NUM),-n $(DEVICE_FDT_NUM)) \
-c $(if $(DEVICE_DTS_CONFIG),$(DEVICE_DTS_CONFIG),"config@1") \
-A $(LINUX_KARCH) -v $(LINUX_VERSION)
PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.new
diff --git a/include/image.mk b/include/image.mk
index 703aeb6816..a1308f47ad 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -432,6 +432,7 @@ define Device/Init
   DEVICE_DTS :=
   DEVICE_DTS_CONFIG :=
   DEVICE_DTS_DIR :=
+  DEVICE_FDT_NUM :=
   SOC :=
 
   BOARD_NAME :=
@@ -453,8 +454,9 @@ DEFAULT_DEVICE_VARS := \
   DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_INITRAMFS_IMAGE KERNEL_SIZE \
   CMDLINE UBOOTENV_IN_UBI KERNEL_IN_UBI BLOCKSIZE PAGESIZE SUBPAGESIZE \
   VID_HDR_OFFSET UBINIZE_OPTS UBINIZE_PARTS MKUBIFS_OPTS DEVICE_DTS \
-  DEVICE_DTS_CONFIG DEVICE_DTS_DIR SOC BOARD_NAME UIMAGE_NAME 
SUPPORTED_DEVICES \
-  IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR UBOOT_PATH IMAGE_SIZE \
+  DEVICE_DTS_CONFIG DEVICE_DTS_DIR DEVICE_FDT_NUM SOC BOARD_NAME \
+  UIMAGE_NAME SUPPORTED_DEVICES IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR \
+  UBOOT_PATH IMAGE_SIZE \
   DEVICE_COMPAT_VERSION DEVICE_COMPAT_MESSAGE \
   DEVICE_VENDOR DEVICE_MODEL DEVICE_VARIANT \
   DEVICE_ALT0_VENDOR DEVICE_ALT0_MODEL DEVICE_ALT0_VARIANT \
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
index 468ef670e6..bb629d6fca 100755
--- a/scripts/mkits.sh
+++ b/scripts/mkits.sh
@@ -16,7 +16,7 @@
 
 usage() {
printf "Usage: %s -A arch -C comp -a addr -e entry" "$(basename "$0")"
-   printf " -v version -k kernel [-D name -d dtb] -o its_file"
+   printf " -v version -k kernel [-D name -n address -d dtb] -o its_file"
 
printf "\n\t-A ==> set architecture to 'arch'"
printf "\n\t-C ==> set compression type 'comp'"
@@ -26,12 +26,15 @@ usage() {
printf "\n\t-v ==> set kernel version to 'version'"
printf "\n\t-k ==> include kernel image 'kernel'"
printf "\n\t-D ==> human friendly Device Tree Blob 'name'"
+   printf "\n\t-n ==> fdt unit-address 'address'"
printf "\n\t-d ==> include Device Tree Blob 'dtb'"
printf "\n\t-o ==> create output file 'its_file'\n"
exit 1
 }
 
-while getopts ":A:a:c:C:D:d:e:k:o:v:" OPTION
+FDTNUM=1
+
+while getopts ":A:a:c:C:D:d:e:k:n:o:v:" OPTION
 do
case $OPTION in
A ) ARCH=$OPTARG;;
@@ -42,6 +45,7 @@ do
d ) DTB=$OPTARG;;
e ) ENTRY_ADDR=$OPTARG;;
k ) KERNEL=$OPTARG;;
+   n ) FDTNUM=$OPTARG;;
o ) OUTPUT=$OPTARG;;
v ) VERSION=$OPTARG;;
* ) echo "Invalid option passed to '$0' (options:$*)"
@@ -61,7 +65,7 @@ ARCH_UPPER=$(echo "$ARCH" | tr '[:lower:]' '[:upper:]')
 # Conditionally create fdt information
 if [ -n "${DTB}" ]; then
FDT_NODE="
-   fdt@1 {
+   fdt@$FDTNUM {
description = \"${ARCH_UPPER} OpenWrt ${DEVICE} device 
tree blob\";
data = /incbin/(\"${DTB}\");
type = \"flat_dt\";
@@ -75,7 +79,7 @@ if [ -n "${DTB}" ]; then
};
};
 "
-   FDT_PROP="fdt = \"fdt@1\";"
+   FDT_PROP="fdt = \"fdt@$FDTNUM\";"
 fi
 
 # Create a default, fully populated DTS file
-- 
2.28.0


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


[PATCH v4 6/8] kernel: package bcm53xx i2c module

2020-09-19 Thread Christian Lamparter
The BCM5301x SoCs do have i2c. Since this is only
being used by the Meraki MR32, this will be packaged
as a module.

Signed-off-by: Christian Lamparter 

---
v3 -> v4
- moved to target/linux/bcm53xx/modules.mk
---
 target/linux/bcm53xx/modules.mk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/target/linux/bcm53xx/modules.mk b/target/linux/bcm53xx/modules.mk
index b3bb42578c..ab3bab3f15 100644
--- a/target/linux/bcm53xx/modules.mk
+++ b/target/linux/bcm53xx/modules.mk
@@ -35,3 +35,18 @@ define KernelPackage/phy-bcm-ns-usb3/description
 endef
 
 $(eval $(call KernelPackage,phy-bcm-ns-usb3))
+
+define KernelPackage/i2c-bcm-iproc
+  TITLE:=Broadcom iProc I2C controller
+  KCONFIG:=CONFIG_I2C_BCM_IPROC
+  DEPENDS:=@TARGET_bcm53xx +kmod-i2c-core
+  SUBMENU:=(I2C_MENU)
+  FILES:=$(LINUX_DIR)/drivers/i2c/busses/i2c-bcm-iproc.ko
+  AUTOLOAD:=$(call AutoLoad,59,i2c-bcm-iproc,1)
+endef
+
+define KernelPackage/i2c-bcm-iproc/description
+ Kernel module for the Broadcom iProc I2C controller.
+endef
+
+$(eval $(call KernelPackage,i2c-bcm-iproc))
-- 
2.28.0


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


[PATCH v4 2/8] build: define PWM_SUPPORT arch feature flag

2020-09-19 Thread Christian Lamparter
As the PWM has its own sub-system in the Linux kernel,
I think it should be handled in the same way as GPIO, RTC, PCI...

This patch introduces a specific feature flag "pwm" and the
"leds-pwm" kernel module as the first customer.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/leds.mk | 16 
 scripts/target-metadata.pl   |  1 +
 target/Config.in |  3 +++
 3 files changed, 20 insertions(+)

diff --git a/package/kernel/linux/modules/leds.mk 
b/package/kernel/linux/modules/leds.mk
index c030b54b39..fe90c6b559 100644
--- a/package/kernel/linux/modules/leds.mk
+++ b/package/kernel/linux/modules/leds.mk
@@ -159,3 +159,19 @@ define KernelPackage/leds-pca963x/description
 endef
 
 $(eval $(call KernelPackage,leds-pca963x))
+
+
+define KernelPackage/leds-pwm
+  SUBMENU:=$(LEDS_MENU)
+  TITLE:=PWM driven LED Support
+  KCONFIG:=CONFIG_LEDS_PWM
+  DEPENDS:= @PWM_SUPPORT
+  FILES:=$(LINUX_DIR)/drivers/leds/leds-pwm.ko
+  AUTOLOAD:=$(call AutoLoad,60,leds-pwm,1)
+endef
+
+define KernelPackage/leds-pwm/description
+ This option enables support for pwm driven LEDs
+endef
+
+$(eval $(call KernelPackage,leds-pwm))
diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index c58f096573..bf6413d315 100755
--- a/scripts/target-metadata.pl
+++ b/scripts/target-metadata.pl
@@ -20,6 +20,7 @@ sub target_config_features(@) {
/^usb$/ and $ret .= "\tselect USB_SUPPORT\n";
/^usbgadget$/ and $ret .= "\tselect USB_GADGET_SUPPORT\n";
/^pcmcia$/ and $ret .= "\tselect PCMCIA_SUPPORT\n";
+   /^pwm$/ and $ret .= "\select PWM_SUPPORT\n";
/^rtc$/ and $ret .= "\tselect RTC_SUPPORT\n";
/^squashfs$/ and $ret .= "\tselect USES_SQUASHFS\n";
/^jffs2$/ and $ret .= "\tselect USES_JFFS2\n";
diff --git a/target/Config.in b/target/Config.in
index 9fead5994f..43de4710df 100644
--- a/target/Config.in
+++ b/target/Config.in
@@ -29,6 +29,9 @@ config PCIE_SUPPORT
 config PCMCIA_SUPPORT
bool
 
+config PWM_SUPPORT
+   bool
+
 config USB_SUPPORT
select AUDIO_SUPPORT
bool
-- 
2.28.0


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


[PATCH v4 4/8] bcm53xx: backport uart2 and pcie2 device-nodes

2020-09-19 Thread Christian Lamparter
These have made their way into -next. This patch
also includes the portion of the bcm53xx kernel
patch refreshes as the hunks in
302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
moved slightly due to the added nodes.

Signed-off-by: Christian Lamparter 
---
v2 -> v3
- backport patches from devicetree/next
- make target/linux/refresh
---
 ...dts-BCM5301X-Specify-uart2-in-the-DT.patch | 30 +++
 ...dts-BCM5301X-Specify-pcie2-in-the-DT.patch | 26 
 ...01X-Update-Northstar-pinctrl-binding.patch |  2 +-
 3 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
 create mode 100644 
target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch

diff --git 
a/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
new file mode 100644
index 00..8cee6745ee
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
@@ -0,0 +1,30 @@
+From 5e396bb05b89e23e98e6d75749b77502e68210a4 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Sat, 22 Aug 2020 18:19:20 +0200
+Subject: [PATCH] ARM: dts: BCM5301X: Specify uart2 in the DT
+
+The BCM53016 in the Meraki MR32 utilizes the third "uart2"
+to connect to a on-board Bluetooth-LE 4.0 BCM20732 chip.
+
+Signed-off-by: Christian Lamparter 
+Reviewed-by: Scott Branden 
+Signed-off-by: Florian Fainelli 
+
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -392,6 +392,15 @@
+   reg = <0x18105000 0x1000>;
+   };
+ 
++  uart2: serial@18008000 {
++  compatible = "ns16550a";
++  reg = <0x18008000 0x20>;
++  clocks = <>;
++  interrupts = ;
++  reg-shift = <2>;
++  status = "disabled";
++  };
++
+   i2c0: i2c@18009000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18009000 0x50>;
diff --git 
a/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
new file mode 100644
index 00..d3e2fbcc9e
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
@@ -0,0 +1,26 @@
+From c4cd6fcae46fd14aed8665b7cf66d0954765a873 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Sat, 22 Aug 2020 18:19:21 +0200
+Subject: [PATCH] ARM: dts: BCM5301X: Specify pcie2 in the DT
+
+The SoC supports three pcie ports. Currently, only
+pcie0 and pcie1 are enabled. This patch adds the
+pcie2 port as well.
+
+Signed-off-by: Christian Lamparter 
+Reviewed-by: Scott Branden 
+Signed-off-by: Florian Fainelli 
+
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -252,6 +252,10 @@
+   reg = <0x00013000 0x1000>;
+   };
+ 
++  pcie2: pcie@14000 {
++  reg = <0x00014000 0x1000>;
++  };
++
+   usb2: usb2@21000 {
+   reg = <0x00021000 0x1000>;
+ 
diff --git 
a/target/linux/bcm53xx/patches-5.4/302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
 
b/target/linux/bcm53xx/patches-5.4/302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
index 77bc68c8ce..1d71647d60 100644
--- 
a/target/linux/bcm53xx/patches-5.4/302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
+++ 
b/target/linux/bcm53xx/patches-5.4/302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
@@ -9,7 +9,7 @@ Signed-off-by: Rafał Miłecki 
 
 --- a/arch/arm/boot/dts/bcm5301x.dtsi
 +++ b/arch/arm/boot/dts/bcm5301x.dtsi
-@@ -401,16 +401,12 @@
+@@ -422,16 +422,12 @@
#size-cells = <1>;
  
cru@100 {
-- 
2.28.0


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


[PATCH v4 8/8] [RFT][WIP] bcm53xx: MR32: replace i2c-gpio with SoC's i2c

2020-09-19 Thread Christian Lamparter
During review of the MR32, Florian Fainelli pointed out that the
SoC has a real I2C-controller. Furthermore, the connected pins
(SDA and SCL) would line up perfectly for use. This patch swaps
out the the bitbanged i2c-gpio with the real deal. It can be
applied once it works.

Signed-off-by: Christian Lamparter 
---
 target/linux/bcm53xx/image/Makefile   |  2 +-
 .../332-Meraki-MR32-use-hw-i2c.patch  | 73 +++
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index 9ceb5f6212..2d90665ee3 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -323,7 +323,7 @@ TARGET_DEVICES += luxul_xwr-3150
 define Device/meraki_mr32
   DEVICE_VENODR := Meraki
   DEVICE_MODEL := MR32
-  DEVICE_PACKAGES := $(B43) kmod-i2c-bcm-iproc kmod-i2c-gpio kmod-eeprom-at24 \
+  DEVICE_PACKAGES := $(B43) kmod-i2c-bcm-iproc kmod-eeprom-at24 \
kmod-leds-pwm kmod-hwmon-ina2xx kmod-bluetooth
   DEVICE_DTS := bcm53016-meraki-mr32
 # Meraki FW r23 tries to resize the part.safe partition before it will
diff --git a/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch 
b/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch
new file mode 100644
index 00..f61b9fdcdc
--- /dev/null
+++ b/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch
@@ -0,0 +1,73 @@
+From: Christian Lamparter 
+Date: Sat, 12 Sep 2020 22:11:12 +0200
+Subject: bcm53xx: Meraki MR32 use hw i2c
+
+replace the i2c-gpio provided i2c functionality with the
+hardware in the SoC. This can be activated once the
+internal i2c works as well as the bit-banged i2c-gpio.
+
+Signed-off-by: Christian Lamparter 
+
+--- a/arch/arm/boot/dts/bcm53016-meraki-mr32.dts
 b/arch/arm/boot/dts/bcm53016-meraki-mr32.dts
+@@ -85,34 +85,6 @@
+   max-brightness = <255>;
+   };
+   };
+-
+-  i2c {
+-  /*
+-   * The platform provided I2C does not budge.
+-   * This is a replacement until I can figure
+-   * out what are the missing bits...
+-   */
+-
+-  compatible = "i2c-gpio";
+-  sda-gpios = < 5 GPIO_ACTIVE_HIGH>;
+-  scl-gpios = < 4 GPIO_ACTIVE_HIGH>;
+-  i2c-gpio,delay-us = <10>; /* close to 100 kHz */
+-  #address-cells = <1>;
+-  #size-cells = <0>;
+-
+-  current_sense: ina219@45 {
+-  compatible = "ti,ina219";
+-  reg = <0x45>;
+-  shunt-resistor = <6>; /* = 60 mOhms */
+-  };
+-
+-  eeprom: eeprom@50 {
+-  compatible = "atmel,24c64";
+-  reg = <0x50>;
+-  pagesize = <32>;
+-  read-only;
+-  };
+-  };
+ };
+ 
+  {
+@@ -196,3 +168,25 @@
+   };
+   };
+ };
++
++ {
++  status = "okay";
++
++  pinctrl-names = "default";
++  pinctrl-0 = <_i2c>;
++
++  clock-frequency = <10>;
++
++  current_sense: ina219@45 {
++  compatible = "ti,ina219";
++  reg = <0x45>;
++  shunt-resistor = <6>; /* = 60 mOhms */
++  };
++
++  eeprom: eeprom@50 {
++  compatible = "atmel,24c64";
++  reg = <0x50>;
++  pagesize = <32>;
++  read-only;
++  };
++};
-- 
2.28.0


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


[PATCH v4 5/8] kernel: add default for new config symbols

2020-09-19 Thread Christian Lamparter
Provide disabled defaults for I2C_SLAVE_EEPROM and IPMB_DEVICE_INTERFACE.

Signed-off-by: Christian Lamparter 
---
 target/linux/generic/config-5.4 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index 6f63b8c5dd..1c28addff4 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -2134,6 +2134,7 @@ CONFIG_HW_RANDOM_TPM=y
 # CONFIG_I2C_SIS630 is not set
 # CONFIG_I2C_SIS96X is not set
 # CONFIG_I2C_SLAVE is not set
+# CONFIG_I2C_SLAVE_EEPROM is not set
 # CONFIG_I2C_SMBUS is not set
 # CONFIG_I2C_STUB is not set
 # CONFIG_I2C_TAOS_EVM is not set
@@ -2394,6 +2395,7 @@ CONFIG_IO_STRICT_DEVMEM=y
 # CONFIG_IP6_NF_TARGET_SYNPROXY is not set
 # CONFIG_IPACK_BUS is not set
 # CONFIG_IPC_NS is not set
+# CONFIG_IPMB_DEVICE_INTERFACE is not set
 # CONFIG_IPMI_HANDLER is not set
 # CONFIG_IPV6 is not set
 # CONFIG_IPV6_FOU is not set
-- 
2.28.0


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


[PATCH v4 3/8] bcm53xx: enable PWM for bcm53xx

2020-09-19 Thread Christian Lamparter
The Meraki MR32 (BCM53016A1) uses the pwm to drive the
tricolor LED. The driver has been available in upstream
for a long time. Only the Device-Tree definition was
missing, but it has been queued recently.

Signed-off-by: Christian Lamparter 
---
v2 -> v3
- backport patches from devicetree/next
---
 target/linux/bcm53xx/Makefile |  2 +-
 target/linux/bcm53xx/config-5.4   |  3 ++
 ...M-dts-BCM5301X-Specify-PWM-in-the-DT.patch | 48 +++
 3 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch

diff --git a/target/linux/bcm53xx/Makefile b/target/linux/bcm53xx/Makefile
index 35f8513801..f980f8a8fb 100644
--- a/target/linux/bcm53xx/Makefile
+++ b/target/linux/bcm53xx/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=bcm53xx
 BOARDNAME:=Broadcom BCM47xx/53xx (ARM)
-FEATURES:=squashfs nand usb pci pcie gpio
+FEATURES:=squashfs nand usb pci pcie gpio pwm
 CPU_TYPE:=cortex-a9
 SUBTARGETS:=generic
 
diff --git a/target/linux/bcm53xx/config-5.4 b/target/linux/bcm53xx/config-5.4
index eacfcb620e..8c7cdf45d5 100644
--- a/target/linux/bcm53xx/config-5.4
+++ b/target/linux/bcm53xx/config-5.4
@@ -308,6 +308,9 @@ CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_IPROC_GPIO is not set
 CONFIG_PINCTRL_NS=y
 # CONFIG_PINCTRL_NS2_MUX is not set
+CONFIG_PWM=y
+CONFIG_PWM_BCM_IPROC=y
+CONFIG_PWM_SYSFS=y
 CONFIG_RATIONAL=y
 CONFIG_RCU_NEED_SEGCBLIST=y
 CONFIG_RCU_STALL_COMMON=y
diff --git 
a/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
new file mode 100644
index 00..335378656c
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
@@ -0,0 +1,48 @@
+From 0ea4b29d149586667d96767f1fc8e57ee942c1b0 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Sat, 22 Aug 2020 18:19:19 +0200
+Subject: [PATCH] ARM: dts: BCM5301X: Specify PWM in the DT
+
+The BCM53016 in the Meraki MR32 uses the on-chip PWM
+controller to drive a tri-color RGB LED. Since I plan
+to use the PWM, I made a label for the pwm's pinmux
+node. This way, it can be easily referenced And
+Also included a label for the i2c since I'm going to
+need it in the future too.
+
+Signed-off-by: Christian Lamparter 
+Acked-by: Scott Branden 
+Signed-off-by: Florian Fainelli 
+
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -350,6 +350,14 @@
+   };
+   };
+ 
++  pwm: pwm@18002000 {
++  compatible = "brcm,iproc-pwm";
++  reg = <0x18002000 0x28>;
++  clocks = <>;
++  #pwm-cells = <3>;
++  status = "disabled";
++  };
++
+   mdio: mdio@18003000 {
+   compatible = "brcm,iproc-mdio";
+   reg = <0x18003000 0x8>;
+@@ -417,12 +425,12 @@
+   function = "spi";
+   };
+ 
+-  i2c {
++  pinmux_i2c: i2c {
+   groups = "i2c_grp";
+   function = "i2c";
+   };
+ 
+-  pwm {
++  pinmux_pwm: pwm {
+   groups = "pwm0_grp", "pwm1_grp",
+"pwm2_grp", "pwm3_grp";
+   function = "pwm";
-- 
2.28.0


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


Re: [PATCH v3 6/8] kernel: package bcm53xx i2c module

2020-09-19 Thread Christian Lamparter

On 2020-09-15 13:47, Daniel Golle wrote:

On Tue, Sep 15, 2020 at 01:28:23PM +0200, Adrian Schmutzler wrote:

Hi,


-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Christian Lamparter
Sent: Samstag, 12. September 2020 23:16
To: openwrt-devel@lists.openwrt.org
Cc: ra...@milecki.pl; ha...@hauke-m.de; f.faine...@gmail.com;
chrisrblak...@gmail.com; Adrian Schmutzler 
Subject: [PATCH v3 6/8] kernel: package bcm53xx i2c module

The BCM5301x SoCs do have i2c. Since this is only being used by the Meraki
MR32, this will be packaged as a module.

Signed-off-by: Christian Lamparter 
---
  package/kernel/linux/modules/i2c.mk | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/package/kernel/linux/modules/i2c.mk
b/package/kernel/linux/modules/i2c.mk
index ca6463c81b..1c8b1b844e 100644
--- a/package/kernel/linux/modules/i2c.mk
+++ b/package/kernel/linux/modules/i2c.mk
@@ -259,3 +259,17 @@ endef
  $(eval $(call KernelPackage,i2c-tiny-usb))


+I2C_BCM_IPROC_MODULES:= \
+  CONFIG_I2C_BCM_IPROC:drivers/i2c/busses/i2c-bcm-iproc
+
+define KernelPackage/i2c-bcm-iproc
+  $(call i2c_defaults,$(I2C_BCM_IPROC_MODULES),59)
+  TITLE:=Broadcom iProc I2C controller
+  DEPENDS:=@TARGET_bcm53xx +kmod-i2c-core endef


More a question than a remark:

I always wonder whether stuff like this (depending on a single target) belongs 
into package/kernel/linux/modules/... or into target/linux/bcm53xx/modules.mk

Is there a general rule or is this mostly depending on circumstances/taste?


I'd say in a case like that (DEPENDS:=@TARGET_bcm53xx) it should go to
target/linux/bcm53xx/modules.mk. However, another idea of that can be
to list in-tree modules in package/kernel/linux/modules/... and target-
specific out-of-tree modules in target/linux/*/modules.mk.
I don't think we got a clear policy regarding that.


The bcm-iproc-i2c is also used by the arm64 stingray and northstar2
chips of broadcom's 802.11ax platform. That said, there isn't any
target for it so I might as well put the it into
target/linux/bcm53xx/modules.mk.

Cheers
Christian

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


Re: [PATCH v2 1/2] ipq40xx: add support for Luma Home WRTQ-329ACN

2020-09-18 Thread Christian Lamparter

On 2020-09-15 16:50, Tomasz Maciej Nowak wrote:

Hi Christian, thanks for looking at this.

W dniu 13.09.2020 o 00:04, Christian Lamparter pisze:

On 2020-08-30 13:28, Tomasz Maciej Nowak wrote:

Luma Home WRTQ-329ACN, also known as Luma WiFi System, is a dual-band
wireless access point.

Specification
SoC: Qualcomm Atheros IPQ4018
RAM: 256 MB DDR3
Flash: 2 MB SPI NOR
     128 MB SPI NAND

[...]


So, because you install from the initramfs and introduced a custom run
command with a custom "kernel1" ubi volume... It might be possible to
cut the extra parts in the sysupgrade and bootargs and unify it with
the generic nand_do_upgrade() crowd.

I've incorperated what maybe could be done in this patch on my
staging tree: [0]

(Note the changes in step 9 (kernel1->kernel), step 10 (ubirmvol ubi_rootfs1 & 
kernel1) and the "step 2 in
back to OEM".

The idea is that we use OpenWrt's existing automount for ubi
and "rootfs" volumes.

(In theory this could make the "back to OEM" even easier.
Because if it works the way I think it does, we could drop
the ubirmvol of ubi_rootfs1 and kernel1 in step 10 of my version.
Next, it should be possible to drop the ubimkvol of
kernel1 and ubi_rootfs1 step 2 in the "Reverting to OEM" section.
This is because the original rootfs1 and kernel1 still exist and
are left untouched - no idea if this works out or not.)


Personally I would like to use whole NAND for OpenWrt, that would simplify 
everything a lot.
Unfortunately some users might be dissatisfied with how things are done in 
OpenWrt and wish
to revert to stock firmware. I'll explain in points what are the current issues 
with this
device. My knowledge is based on what I could dig out from firmware (QSDK) 
without access to
source modifications.


I don't think there's a need to do that. On old (and new) devices that only have
8MiB/16MiB of flash space, it's impossible to keep the vendor firmware around.
There's no obligation to do that. From the looks of it, though. I think it's 
more
of a hassle to fully remove the vendor than to keep it around and praise this as
a feature. So either way, both are fine :-) . If somebody wants to use the full
NAND, she/he could just delete the remaining "kernel1, ubi_rootfs[1]" volumes
and resize the rootfs_data. (This can be done in place).


1. The devices have different flash layouts, some come with
mtd8: 0800 0002 "rootfs"
mtd9: 0041e000 0001f000 "kernel"
mtd10: 026c 0001f000 "ubi_rootfs"
mtd11: 01ff8000 0001f000 "rootfs_data"
mtd12: 0041e000 0001f000 "kernel1"
mtd13: 026c 0001f000 "ubi_rootfs1"

and some

mtd8: 0800 0002 "rootfs"
mtd9: 003a2000 0001f000 "kernel"
mtd10: 02283000 0001f000 "ubi_rootfs"
mtd11: 0062d000 0001f000 "dummy"
mtd12: 01ff8000 0001f000 "rootfs_data"
mtd13: 0041e000 0001f000 "kernel1"
mtd14: 026c 0001f000 "ubi_rootfs1"

this reflects the bootargs in dts.


Ok, that 128 MiB "rootfs" looks to be the "ubi" partition. My best "this could 
be"
guess is that the "dummy" and the different sizes of the kernel vs kernel1 
partition
stems from a update. The dummy would be a temporary filesystem for the stuff 
that
was worth keeping... But I don't know.

I just like to see the use of the established "kernel" and "rootfs" volumes 
whenever
possible.

I did the necessary changes in this version:
<https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=b30fedc765871e7738257eae305674b0069bbd96>

This will repurpose the "kernel" partition (by overwriting it)
and ditch "ubi_rootfs". The big mtd partition "rootfs" is renamed to
"ubi" (this is because OpenWrt will auto-attach the volume - handled
by 490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch)

and the squashfs root is placed in "rootfs". (OpenWrt does
automatically create a ubiblock for volumes called rootfs -
done by 491-ubi-auto-create-ubiblock-device-for-rootfs.patch @Daniel)

What's your opinion? Do you want it in a different way? Or are you
fine with the changes? (I would need to know if this works or not
though)



2. As illustrated above, the device comes with two sets of kernel+ubi_rootfs 
and shared
overlay "rootfs_data". The U-Boot with 'bootipq' command boots the first 
kernel+ubi_rootfs
pair. There is some kind of fallback mechanism to issue boot from the second 
pair, but I was
unable to trigger it (didn't try hammer approach by deleting first 
kernel+ubi_rootfs set).

3. On each reboot the 'bootipq' command rewrites some of U-Boot environments 
variables to
default state. I don't know every one of them and that makes this not a stable 
environment,
which could overwrite our changes. Also this increases flash wear (it's NOR, I 
know

Re: [PATCH v2 1/2] ipq40xx: add support for Luma Home WRTQ-329ACN

2020-09-12 Thread Christian Lamparter

On 2020-08-30 13:28, Tomasz Maciej Nowak wrote:

Luma Home WRTQ-329ACN, also known as Luma WiFi System, is a dual-band
wireless access point.

Specification
SoC: Qualcomm Atheros IPQ4018
RAM: 256 MB DDR3
Flash: 2 MB SPI NOR
128 MB SPI NAND
WIFI: 2.4 GHz 2T2R integrated
   5 GHz 2T2R integrated
Ethernet: 2x 10/100/1000 Mbps QCA8075
USB: 1x 2.0
Bluetooth: 1x 4.0 CSR8510 A10, connected to USB bus
LEDS: 16x multicolor LEDs ring, controlled by MSP430G2403 MCU
Buttons: 1x GPIO controlled
EEPROM: 16 Kbit, compatible with AT24C16
UART: row of 4 holes marked on PCB as J19, starting count from the side
   of J19 marking on PCB
   1. GND, 2. RX, 3. TX, 4. 3.3V
   baud: 115200, parity: none, flow control: none

The device supports OTA or USB flash drive updates, unfotunately they
are signed. Until the signing key is known, the UART access is mandatory
for installation. The difficult part is disassembling the casing, there
are a lot of latches holding it together.

Teardown
Prepare three thin, but sturdy, prying tools. Place the device with back
of it facing upwards. Start with the wall having a small notch. Insert
first tool, until You'll feel resistance and keep it there. Repeat the
procedure for neighbouring walls. With applying a pressure, one edge of
the back cover should pop up. Now carefully slide one of the tools to
free the rest of the latches.
There's no need to solder pins to the UART holes, You can use hook clips,
but wiring them outside the casing, will ease debuging and recovery if
problems occur.

Installation
1. Prepare TFTP server with OpenWrt initramfs image.
2. Connect to UART port (don't connect the voltage pin).
3. Connect to LAN port.
4. Power on the device, carefully observe the console output and when
asked quickly enter the failsafe mode.
5. Invoke 'mount_root'.
6. After the overlayfs is mounted run:
  fw_setenv bootdelay 3
This will allow to access U-Boot shell.
7. Reboot the device and when prompted to stop autoboot, hit any key.
8. Adjust "ipaddr" and "serverip" addresses in U-Boot environment, use
'setenv' to do that, then run following commands:
  tftpboot 0x8400 
  bootm 0x8400
and wait till OpenWrt boots.
9. In OpenWrt command line run following commands:
  fw_setenv openwrt "setenv mtdids nand1=spi_nand; setenv mtdparts 
mtdparts=spi_nand:-(ubi); ubi part ubi; ubi read 0x8400 kernel1; bootm 
0x8400"
  fw_setenv bootcmd "run openwrt"

So, because you install from the initramfs and introduced a custom run
command with a custom "kernel1" ubi volume... It might be possible to
cut the extra parts in the sysupgrade and bootargs and unify it with
the generic nand_do_upgrade() crowed.

I've incorperated what maybe could be done in this patch on my
staging tree: [0]

(Note the changes in step 9 (kernel1->kernel), step 10 (ubirmvol ubi_rootfs1 & 
kernel1) and the "step 2 in
back to OEM".

The idea is that we use OpenWrt's existing automount for ubi
and "rootfs" volumes.

(In theory this could make the "back to OEM" even easier.
Because if it works the way I think it does, we could drop
the ubirmvol of ubi_rootfs1 and kernel1 in step 10 of my version.
Next, it should be possible to drop the ubimkvol of
kernel1 and ubi_rootfs1 step 2 in the "Reverting to OEM" section.
This is because the original rootfs1 and kernel1 still exist and
are left untouched - no idea if this works out or not.)

Note: I've squashed both of your patches into one.

Note2: You don't mention it in your commit. But I'm seeing that you are
using GPIO OPEN_DRAIN for the bitbanged i2c. So, don't you also need
Brain's pinctrl patch that wires up OPEN_DRAIN for this? [1]

Currently, I've added it to the staging tree too (see the parent patch [2]).
If you haven't heard of this patch before, please also give it a quick
spin and see if it changes anything or not. Thanks.

Cheers,
Christian

[0] 

[1] 

[2] 


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


[PATCH v3 8/8] -NOT YET- bcm53xx: MR32: replace i2c-gpio with SoC's i2c

2020-09-12 Thread Christian Lamparter
During review of the MR32, Florian Fainelli pointed out that the
SoC has a real I2C-controller. Furthermore, the connected pins
(SDA and SCL) would line up perfectly for use. This patch swaps
out the the bitbanged i2c-gpio with the real deal.

Signed-off-by: Christian Lamparter 
---
 target/linux/bcm53xx/image/Makefile   |  2 +-
 .../332-Meraki-MR32-use-hw-i2c.patch  | 73 +++
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index 613f2d533d..74d92a0579 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -323,7 +323,7 @@ TARGET_DEVICES += luxul_xwr-3150
 define Device/meraki_mr32
   DEVICE_VENODR := Meraki
   DEVICE_MODEL := MR32
-  DEVICE_PACKAGES := $(B43) kmod-i2c-bcm-iproc kmod-i2c-gpio kmod-eeprom-at24 \
+  DEVICE_PACKAGES := $(B43) kmod-i2c-bcm-iproc kmod-eeprom-at24 \
kmod-leds-pwm kmod-hwmon-core kmod-hwmon-ina2xx kmod-bluetooth
   DEVICE_DTS := bcm53016-meraki-mr32
 # Meraki FW r23 tries to resize the part.safe partition before it will
diff --git a/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch 
b/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch
new file mode 100644
index 00..5ddfd67994
--- /dev/null
+++ b/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch
@@ -0,0 +1,73 @@
+From: Christian Lamparter 
+Date: Sat, 12 Sep 2020 22:11:12 +0200
+Subject: bcm53xx: Meraki MR32 use hw i2c
+
+replace the i2c-gpio provided i2c functionality with the
+hardware in the SoC. This can be activated once the
+internal i2c works as well as the bit-banged i2c-gpio.
+
+Signed-off-by: Christian Lamparter 
+
+--- a/arch/arm/boot/dts/bcm53016-meraki-mr32.dts
 b/arch/arm/boot/dts/bcm53016-meraki-mr32.dts
+@@ -85,34 +85,6 @@
+   max-brightness = <255>;
+   };
+   };
+-
+-  i2c {
+-  /*
+-   * The platform provided I2C does not budge.
+-   * This is a replacement until I can figure
+-   * out what are the missing bits...
+-   */
+-
+-  compatible = "i2c-gpio";
+-  sda-gpios = < 5 GPIO_ACTIVE_HIGH>;
+-  scl-gpios = < 4 GPIO_ACTIVE_HIGH>;
+-  i2c-gpio,delay-us = <10>; /* close to 100 kHz */
+-  #address-cells = <1>;
+-  #size-cells = <0>;
+-
+-  current_sense: ina219@45 {
+-  compatible = "ti,ina219";
+-  reg = <0x45>;
+-  shunt-resistor = <6>; /* = 60 mOhms */
+-  };
+-
+-  eeprom: eeprom@50 {
+-  compatible = "atmel,24c64";
+-  reg = <0x50>;
+-  pagesize = <32>;
+-  read-only;
+-  };
+-  };
+ };
+ 
+  {
+@@ -195,3 +168,25 @@
+   };
+   };
+ };
++
++ {
++  status = "okay";
++
++  pinctrl-names = "default";
++  pinctrl-0 = <_i2c>;
++
++  clock-frequency = <10>;
++
++  current_sense: ina219@45 {
++  compatible = "ti,ina219";
++  reg = <0x45>;
++  shunt-resistor = <6>; /* = 60 mOhms */
++  };
++
++  eeprom: eeprom@50 {
++  compatible = "atmel,24c64";
++  reg = <0x50>;
++  pagesize = <32>;
++  read-only;
++  };
++};
-- 
2.28.0


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


[PATCH v3 8/8] [RFT][WIP] bcm53xx: MR32: replace i2c-gpio with SoC's i2c

2020-09-12 Thread Christian Lamparter
During review of the MR32, Florian Fainelli pointed out that the
SoC has a real I2C-controller. Furthermore, the connected pins
(SDA and SCL) would line up perfectly for use. This patch swaps
out the the bitbanged i2c-gpio with the real deal. It can be
applied once it works.

Signed-off-by: Christian Lamparter 
---
 target/linux/bcm53xx/image/Makefile   |  2 +-
 .../332-Meraki-MR32-use-hw-i2c.patch  | 73 +++
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index 613f2d533d..74d92a0579 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -323,7 +323,7 @@ TARGET_DEVICES += luxul_xwr-3150
 define Device/meraki_mr32
   DEVICE_VENODR := Meraki
   DEVICE_MODEL := MR32
-  DEVICE_PACKAGES := $(B43) kmod-i2c-bcm-iproc kmod-i2c-gpio kmod-eeprom-at24 \
+  DEVICE_PACKAGES := $(B43) kmod-i2c-bcm-iproc kmod-eeprom-at24 \
kmod-leds-pwm kmod-hwmon-core kmod-hwmon-ina2xx kmod-bluetooth
   DEVICE_DTS := bcm53016-meraki-mr32
 # Meraki FW r23 tries to resize the part.safe partition before it will
diff --git a/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch 
b/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch
new file mode 100644
index 00..f61b9fdcdc
--- /dev/null
+++ b/target/linux/bcm53xx/patches-5.4/332-Meraki-MR32-use-hw-i2c.patch
@@ -0,0 +1,73 @@
+From: Christian Lamparter 
+Date: Sat, 12 Sep 2020 22:11:12 +0200
+Subject: bcm53xx: Meraki MR32 use hw i2c
+
+replace the i2c-gpio provided i2c functionality with the
+hardware in the SoC. This can be activated once the
+internal i2c works as well as the bit-banged i2c-gpio.
+
+Signed-off-by: Christian Lamparter 
+
+--- a/arch/arm/boot/dts/bcm53016-meraki-mr32.dts
 b/arch/arm/boot/dts/bcm53016-meraki-mr32.dts
+@@ -85,34 +85,6 @@
+   max-brightness = <255>;
+   };
+   };
+-
+-  i2c {
+-  /*
+-   * The platform provided I2C does not budge.
+-   * This is a replacement until I can figure
+-   * out what are the missing bits...
+-   */
+-
+-  compatible = "i2c-gpio";
+-  sda-gpios = < 5 GPIO_ACTIVE_HIGH>;
+-  scl-gpios = < 4 GPIO_ACTIVE_HIGH>;
+-  i2c-gpio,delay-us = <10>; /* close to 100 kHz */
+-  #address-cells = <1>;
+-  #size-cells = <0>;
+-
+-  current_sense: ina219@45 {
+-  compatible = "ti,ina219";
+-  reg = <0x45>;
+-  shunt-resistor = <6>; /* = 60 mOhms */
+-  };
+-
+-  eeprom: eeprom@50 {
+-  compatible = "atmel,24c64";
+-  reg = <0x50>;
+-  pagesize = <32>;
+-  read-only;
+-  };
+-  };
+ };
+ 
+  {
+@@ -196,3 +168,25 @@
+   };
+   };
+ };
++
++ {
++  status = "okay";
++
++  pinctrl-names = "default";
++  pinctrl-0 = <_i2c>;
++
++  clock-frequency = <10>;
++
++  current_sense: ina219@45 {
++  compatible = "ti,ina219";
++  reg = <0x45>;
++  shunt-resistor = <6>; /* = 60 mOhms */
++  };
++
++  eeprom: eeprom@50 {
++  compatible = "atmel,24c64";
++  reg = <0x50>;
++  pagesize = <32>;
++  read-only;
++  };
++};
-- 
2.28.0


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


[PATCH v3 2/8] build: define PWM_SUPPORT arch feature flag

2020-09-12 Thread Christian Lamparter
As the PWM has its own sub-system in the Linux kernel,
I think it should be handled in the same way as GPIO, RTC, PCI...

This patch introduces a specific feature flag "pwm" and the
"leds-pwm" kernel module as the first customer.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/leds.mk | 16 
 scripts/target-metadata.pl   |  1 +
 target/Config.in |  3 +++
 3 files changed, 20 insertions(+)

diff --git a/package/kernel/linux/modules/leds.mk 
b/package/kernel/linux/modules/leds.mk
index c030b54b39..fe90c6b559 100644
--- a/package/kernel/linux/modules/leds.mk
+++ b/package/kernel/linux/modules/leds.mk
@@ -159,3 +159,19 @@ define KernelPackage/leds-pca963x/description
 endef
 
 $(eval $(call KernelPackage,leds-pca963x))
+
+
+define KernelPackage/leds-pwm
+  SUBMENU:=$(LEDS_MENU)
+  TITLE:=PWM driven LED Support
+  KCONFIG:=CONFIG_LEDS_PWM
+  DEPENDS:= @PWM_SUPPORT
+  FILES:=$(LINUX_DIR)/drivers/leds/leds-pwm.ko
+  AUTOLOAD:=$(call AutoLoad,60,leds-pwm,1)
+endef
+
+define KernelPackage/leds-pwm/description
+ This option enables support for pwm driven LEDs
+endef
+
+$(eval $(call KernelPackage,leds-pwm))
diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index c58f096573..bf6413d315 100755
--- a/scripts/target-metadata.pl
+++ b/scripts/target-metadata.pl
@@ -20,6 +20,7 @@ sub target_config_features(@) {
/^usb$/ and $ret .= "\tselect USB_SUPPORT\n";
/^usbgadget$/ and $ret .= "\tselect USB_GADGET_SUPPORT\n";
/^pcmcia$/ and $ret .= "\tselect PCMCIA_SUPPORT\n";
+   /^pwm$/ and $ret .= "\select PWM_SUPPORT\n";
/^rtc$/ and $ret .= "\tselect RTC_SUPPORT\n";
/^squashfs$/ and $ret .= "\tselect USES_SQUASHFS\n";
/^jffs2$/ and $ret .= "\tselect USES_JFFS2\n";
diff --git a/target/Config.in b/target/Config.in
index 9fead5994f..43de4710df 100644
--- a/target/Config.in
+++ b/target/Config.in
@@ -29,6 +29,9 @@ config PCIE_SUPPORT
 config PCMCIA_SUPPORT
bool
 
+config PWM_SUPPORT
+   bool
+
 config USB_SUPPORT
select AUDIO_SUPPORT
bool
-- 
2.28.0


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


[PATCH v3 7/8] bcm53xx: add Cisco Meraki MR32

2020-09-12 Thread Christian Lamparter
This patch adds support for Cisco Meraki MR32.
The unit was donated by Chris Blake. Thank you!

WARNING:
Only the 1x1:1 abgn Air Marshal WIPS wifi is currently supported by b43:
 b43-phy2: Found PHY: Analog 9, Type 4 (N), Revision 16
 b43-phy2: Found Radio: Manuf 0x17F, ID 0x2057, Revision 9, Version 1
 b43-phy2: Loading firmware version 784.2 (2012-08-15 21:35:19)
 and only as 802.11ABG!

while WIFI1 and WIFI2 (both BCM4352) are not:
 b43-phy0: Broadcom 4352 WLAN found (core revision 42)
 b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)

Hardware Highlights:

SoC:Broadcom BCM53016A1 (1 GHz, 2 cores)
RAM:128 MiB
NAND:   128 MiB Spansion S34ML01G2 (~114 MiB useable)
ETH:1GBit Ethernet Port - PoE
WIFI1:  Broadcom BCM43520 an+ac (2x2:2 - id: 0x4352)
WIFI2:  Broadcom BCM43520 bgn (2x2:2 - id: 0x4352)
WIFI3:  Broadcom BCM43428 abgn (1x1:1 - id: 43428)

BLE:Broadcom BCM20732 (ttyS1)
LEDS:   1 x Programmable RGB Status LED (driven by a PWM)
1 x White LED (GPIO)
1 x Orange LED Fault Indicator (GPIO)
2 x LAN Activity / Speed LEDs (On the RJ45 Port)
BUTTON: one Reset button
MISC:   AT24C64 8KiB EEPROM (i2c - stores Ethernet MAC + Serial#!)
ina219 hardware monitor (i2c)
Kensington Lock

SERIAL:
WARNING: The serial port needs a TTL/RS-232 3V3 level converter!
The Serial setting is 115200-8-N-1. The board has a populated
right angle 1x4 0.1" pinheader.
The pinout is: VCC, RX, TX, GND. (Use a multimeter)

Flashing needs a serial adaptor (due to the lack of a working dropbear on
the original firmware).

This flashing procedure for the MR32 was tested with firmware:
"r23-149867:150252-aacharya".

0. Create a seperate Ethernet LAN which does not have access to the internet.
   Ideally use 192.168.1.2 for your PC. Make sure to reserve 192.168.1.1 it
   will be used later on by the OpenWrt firmware. The original Meraki firmware
   will likely try to setup the network via DHCP Discovery, so make sure your
   PC is running a DHCP-Server (i.e.: dnsmasq)
   '# dnsmasq -i eth# -F 192.168.1.5,192.168.1.50
   Furthermore, the PC needs a supported ssh/http/ftp server in order to
   retrieve the initramfs + dtb file

1. Disassemble the MR32 device by removing all screws (4 screws are located
   under the 4 rubber feets!) and prying open the plastic covers without
   breaking the plastic retention clips. Once inside, remove all the screws
   on the outer metal shielding to get to the PCB. It's not necessary to
   remove the antennas!

2. Connect the serial cable to the serial header.

3. Partially reassemble the outer metal shielding to ensure that the SoC
   has a proper heat sink.

4. Connect the Ethernet patch cable to the device and the power cable.

5. Wait for the device to boot and enter the root shell.
   (rooting is not discussed in detail here please refer to
   Chris Blake - "pwning the meraki mr18" blog post:
   <https://servernetworktech.com/2016/02/pwning-the-meraki-mr18/>
   (The same method works with the MR32's r23-149867:150252-aacharya)

   Wait for the MR32 to enter the "" prompt and enter:
odm serial_num read
   (Verify that it matches what's on the S/N Sticker on the back!)
odm serial_num write Q2XX--XXXV
odm serial_num read
   (Verify that the S/N has changed - and the LED start to flash)

   now to flash the firmware:
odm firmware part.safe "http://192.168.1.2/mr32-initramfs.bin;

Once OpenWrt booted use sysupgrade to permanently install
OpenWrt. To do this: Download the latest sysupgrade.bin file
for the MR32 to the device and use sysupgrade *sysupgrade.bin
to install it.

WARNING: DO NOT DELETE the "storage" ubi volume!

To flash later MR32 Firmwares like r25-201804051805-G885d6d78-dhow-rel
requires in-circut-i2c tools to access the I2C EEPROM AT24C64 next to
the SoC. The idea is pretty much the same as from Step 5 from above:
Change the serial number to Q2XV (should be around 0x7c), then
attach a serial cable, ethernet (but make sure the device can't reach
the internet!) hit "s" (the small s!) during boot to enter the root-shell
and add the following commands to the /storage/config there:

serial_allow_odm true
serial_access_enabled true
serial_access_check false
valid_config true

and then hit exit to let it finish booting.

Signed-off-by: Christian Lamparter 

---

rfc -> v2
- fixed Adrian's comments
- unbroke sysupgrade on other bcm53xx

v2 -> v3
- use florians patch
- make a separate patch for the i2c-gpio -> i2c-hw
---
 .../bcm53xx/base-files/etc/board.d/02_network |   7 +-
 target/linux/bcm53xx/base-files/etc/diag.sh   |   3 +
 .../lib/preinit/07_set_preinit_iface_bcm53xx  |  14 +
 .../base-files/lib/upgrade/platform.sh|  43 ++-
 target/linux/bcm53xx/image/Makefile   |  27 ++
 ...-ARM-BCM5301X-Add-DT-for-Meraki-MR32.patch | 261 

[PATCH v3 1/8] scripts: mkits.sh make it possible to specify fdt@#

2020-09-12 Thread Christian Lamparter
Some bootloaders are really keen on just one special
fdt in a multi-image fit image. This is a problem, because
currently this is fixed to "fdt@1".

This patch introduces a new device variable:
DEVICE_FDT_NUM that allows to specify the right
fdt number.

If the value is absent "1" will be chosen.

Signed-off-by: Christian Lamparter 
---
 include/image-commands.mk |  1 +
 include/image.mk  |  6 --
 scripts/mkits.sh  | 12 
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/image-commands.mk b/include/image-commands.mk
index 9516801c8d..740d627fc7 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -158,6 +158,7 @@ define Build/fit
-D $(DEVICE_NAME) -o $@.its -k $@ \
$(if $(word 2,$(1)),-d $(word 2,$(1))) -C $(word 1,$(1)) \
-a $(KERNEL_LOADADDR) -e $(if 
$(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
+   $(if $(DEVICE_FDT_NUM),-n $(DEVICE_FDT_NUM)) \
-c $(if $(DEVICE_DTS_CONFIG),$(DEVICE_DTS_CONFIG),"config@1") \
-A $(LINUX_KARCH) -v $(LINUX_VERSION)
PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.new
diff --git a/include/image.mk b/include/image.mk
index 703aeb6816..a1308f47ad 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -432,6 +432,7 @@ define Device/Init
   DEVICE_DTS :=
   DEVICE_DTS_CONFIG :=
   DEVICE_DTS_DIR :=
+  DEVICE_FDT_NUM :=
   SOC :=
 
   BOARD_NAME :=
@@ -453,8 +454,9 @@ DEFAULT_DEVICE_VARS := \
   DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_INITRAMFS_IMAGE KERNEL_SIZE \
   CMDLINE UBOOTENV_IN_UBI KERNEL_IN_UBI BLOCKSIZE PAGESIZE SUBPAGESIZE \
   VID_HDR_OFFSET UBINIZE_OPTS UBINIZE_PARTS MKUBIFS_OPTS DEVICE_DTS \
-  DEVICE_DTS_CONFIG DEVICE_DTS_DIR SOC BOARD_NAME UIMAGE_NAME 
SUPPORTED_DEVICES \
-  IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR UBOOT_PATH IMAGE_SIZE \
+  DEVICE_DTS_CONFIG DEVICE_DTS_DIR DEVICE_FDT_NUM SOC BOARD_NAME \
+  UIMAGE_NAME SUPPORTED_DEVICES IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR \
+  UBOOT_PATH IMAGE_SIZE \
   DEVICE_COMPAT_VERSION DEVICE_COMPAT_MESSAGE \
   DEVICE_VENDOR DEVICE_MODEL DEVICE_VARIANT \
   DEVICE_ALT0_VENDOR DEVICE_ALT0_MODEL DEVICE_ALT0_VARIANT \
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
index 468ef670e6..bb629d6fca 100755
--- a/scripts/mkits.sh
+++ b/scripts/mkits.sh
@@ -16,7 +16,7 @@
 
 usage() {
printf "Usage: %s -A arch -C comp -a addr -e entry" "$(basename "$0")"
-   printf " -v version -k kernel [-D name -d dtb] -o its_file"
+   printf " -v version -k kernel [-D name -n address -d dtb] -o its_file"
 
printf "\n\t-A ==> set architecture to 'arch'"
printf "\n\t-C ==> set compression type 'comp'"
@@ -26,12 +26,15 @@ usage() {
printf "\n\t-v ==> set kernel version to 'version'"
printf "\n\t-k ==> include kernel image 'kernel'"
printf "\n\t-D ==> human friendly Device Tree Blob 'name'"
+   printf "\n\t-n ==> fdt unit-address 'address'"
printf "\n\t-d ==> include Device Tree Blob 'dtb'"
printf "\n\t-o ==> create output file 'its_file'\n"
exit 1
 }
 
-while getopts ":A:a:c:C:D:d:e:k:o:v:" OPTION
+FDTNUM=1
+
+while getopts ":A:a:c:C:D:d:e:k:n:o:v:" OPTION
 do
case $OPTION in
A ) ARCH=$OPTARG;;
@@ -42,6 +45,7 @@ do
d ) DTB=$OPTARG;;
e ) ENTRY_ADDR=$OPTARG;;
k ) KERNEL=$OPTARG;;
+   n ) FDTNUM=$OPTARG;;
o ) OUTPUT=$OPTARG;;
v ) VERSION=$OPTARG;;
* ) echo "Invalid option passed to '$0' (options:$*)"
@@ -61,7 +65,7 @@ ARCH_UPPER=$(echo "$ARCH" | tr '[:lower:]' '[:upper:]')
 # Conditionally create fdt information
 if [ -n "${DTB}" ]; then
FDT_NODE="
-   fdt@1 {
+   fdt@$FDTNUM {
description = \"${ARCH_UPPER} OpenWrt ${DEVICE} device 
tree blob\";
data = /incbin/(\"${DTB}\");
type = \"flat_dt\";
@@ -75,7 +79,7 @@ if [ -n "${DTB}" ]; then
};
};
 "
-   FDT_PROP="fdt = \"fdt@1\";"
+   FDT_PROP="fdt = \"fdt@$FDTNUM\";"
 fi
 
 # Create a default, fully populated DTS file
-- 
2.28.0


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


[PATCH v3 3/8] bcm53xx: enable PWM for bcm53xx

2020-09-12 Thread Christian Lamparter
The Meraki MR32 (BCM53016A1) uses the pwm to drive the
tricolor LED. The driver has been available in upstream
for a long time. Only the Device-Tree definition was
missing, but it has been queued recently.

Signed-off-by: Christian Lamparter 
---
v2 -> v3
- backport patches from devicetree/next
---
 target/linux/bcm53xx/Makefile |  2 +-
 target/linux/bcm53xx/config-5.4   |  3 ++
 ...M-dts-BCM5301X-Specify-PWM-in-the-DT.patch | 48 +++
 3 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch

diff --git a/target/linux/bcm53xx/Makefile b/target/linux/bcm53xx/Makefile
index 35f8513801..f980f8a8fb 100644
--- a/target/linux/bcm53xx/Makefile
+++ b/target/linux/bcm53xx/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=bcm53xx
 BOARDNAME:=Broadcom BCM47xx/53xx (ARM)
-FEATURES:=squashfs nand usb pci pcie gpio
+FEATURES:=squashfs nand usb pci pcie gpio pwm
 CPU_TYPE:=cortex-a9
 SUBTARGETS:=generic
 
diff --git a/target/linux/bcm53xx/config-5.4 b/target/linux/bcm53xx/config-5.4
index eacfcb620e..8c7cdf45d5 100644
--- a/target/linux/bcm53xx/config-5.4
+++ b/target/linux/bcm53xx/config-5.4
@@ -308,6 +308,9 @@ CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_IPROC_GPIO is not set
 CONFIG_PINCTRL_NS=y
 # CONFIG_PINCTRL_NS2_MUX is not set
+CONFIG_PWM=y
+CONFIG_PWM_BCM_IPROC=y
+CONFIG_PWM_SYSFS=y
 CONFIG_RATIONAL=y
 CONFIG_RCU_NEED_SEGCBLIST=y
 CONFIG_RCU_STALL_COMMON=y
diff --git 
a/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
new file mode 100644
index 00..335378656c
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
@@ -0,0 +1,48 @@
+From 0ea4b29d149586667d96767f1fc8e57ee942c1b0 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Sat, 22 Aug 2020 18:19:19 +0200
+Subject: [PATCH] ARM: dts: BCM5301X: Specify PWM in the DT
+
+The BCM53016 in the Meraki MR32 uses the on-chip PWM
+controller to drive a tri-color RGB LED. Since I plan
+to use the PWM, I made a label for the pwm's pinmux
+node. This way, it can be easily referenced And
+Also included a label for the i2c since I'm going to
+need it in the future too.
+
+Signed-off-by: Christian Lamparter 
+Acked-by: Scott Branden 
+Signed-off-by: Florian Fainelli 
+
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -350,6 +350,14 @@
+   };
+   };
+ 
++  pwm: pwm@18002000 {
++  compatible = "brcm,iproc-pwm";
++  reg = <0x18002000 0x28>;
++  clocks = <>;
++  #pwm-cells = <3>;
++  status = "disabled";
++  };
++
+   mdio: mdio@18003000 {
+   compatible = "brcm,iproc-mdio";
+   reg = <0x18003000 0x8>;
+@@ -417,12 +425,12 @@
+   function = "spi";
+   };
+ 
+-  i2c {
++  pinmux_i2c: i2c {
+   groups = "i2c_grp";
+   function = "i2c";
+   };
+ 
+-  pwm {
++  pinmux_pwm: pwm {
+   groups = "pwm0_grp", "pwm1_grp",
+"pwm2_grp", "pwm3_grp";
+   function = "pwm";
-- 
2.28.0


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


[PATCH v3 4/8] bcm53xx: backport uart2 and pcie2 device-nodes

2020-09-12 Thread Christian Lamparter
These have made their way into -next. This patch
also includes the portion of the bcm53xx kernel
patch refreshes as the hunks in
302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
moved slightly due to the added nodes.

Signed-off-by: Christian Lamparter 
---
v2 -> v3
- backport patches from devicetree/next
- make target/linux/refresh
---
 ...dts-BCM5301X-Specify-uart2-in-the-DT.patch | 30 +++
 ...dts-BCM5301X-Specify-pcie2-in-the-DT.patch | 26 
 ...01X-Update-Northstar-pinctrl-binding.patch |  2 +-
 3 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
 create mode 100644 
target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch

diff --git 
a/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
new file mode 100644
index 00..8cee6745ee
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
@@ -0,0 +1,30 @@
+From 5e396bb05b89e23e98e6d75749b77502e68210a4 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Sat, 22 Aug 2020 18:19:20 +0200
+Subject: [PATCH] ARM: dts: BCM5301X: Specify uart2 in the DT
+
+The BCM53016 in the Meraki MR32 utilizes the third "uart2"
+to connect to a on-board Bluetooth-LE 4.0 BCM20732 chip.
+
+Signed-off-by: Christian Lamparter 
+Reviewed-by: Scott Branden 
+Signed-off-by: Florian Fainelli 
+
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -392,6 +392,15 @@
+   reg = <0x18105000 0x1000>;
+   };
+ 
++  uart2: serial@18008000 {
++  compatible = "ns16550a";
++  reg = <0x18008000 0x20>;
++  clocks = <>;
++  interrupts = ;
++  reg-shift = <2>;
++  status = "disabled";
++  };
++
+   i2c0: i2c@18009000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18009000 0x50>;
diff --git 
a/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
new file mode 100644
index 00..d3e2fbcc9e
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
@@ -0,0 +1,26 @@
+From c4cd6fcae46fd14aed8665b7cf66d0954765a873 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Sat, 22 Aug 2020 18:19:21 +0200
+Subject: [PATCH] ARM: dts: BCM5301X: Specify pcie2 in the DT
+
+The SoC supports three pcie ports. Currently, only
+pcie0 and pcie1 are enabled. This patch adds the
+pcie2 port as well.
+
+Signed-off-by: Christian Lamparter 
+Reviewed-by: Scott Branden 
+Signed-off-by: Florian Fainelli 
+
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -252,6 +252,10 @@
+   reg = <0x00013000 0x1000>;
+   };
+ 
++  pcie2: pcie@14000 {
++  reg = <0x00014000 0x1000>;
++  };
++
+   usb2: usb2@21000 {
+   reg = <0x00021000 0x1000>;
+ 
diff --git 
a/target/linux/bcm53xx/patches-5.4/302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
 
b/target/linux/bcm53xx/patches-5.4/302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
index 77bc68c8ce..1d71647d60 100644
--- 
a/target/linux/bcm53xx/patches-5.4/302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
+++ 
b/target/linux/bcm53xx/patches-5.4/302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch
@@ -9,7 +9,7 @@ Signed-off-by: Rafał Miłecki 
 
 --- a/arch/arm/boot/dts/bcm5301x.dtsi
 +++ b/arch/arm/boot/dts/bcm5301x.dtsi
-@@ -401,16 +401,12 @@
+@@ -422,16 +422,12 @@
#size-cells = <1>;
  
cru@100 {
-- 
2.28.0


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


[PATCH v3 6/8] kernel: package bcm53xx i2c module

2020-09-12 Thread Christian Lamparter
The BCM5301x SoCs do have i2c. Since this is only
being used by the Meraki MR32, this will be packaged
as a module.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/i2c.mk | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/package/kernel/linux/modules/i2c.mk 
b/package/kernel/linux/modules/i2c.mk
index ca6463c81b..1c8b1b844e 100644
--- a/package/kernel/linux/modules/i2c.mk
+++ b/package/kernel/linux/modules/i2c.mk
@@ -259,3 +259,17 @@ endef
 $(eval $(call KernelPackage,i2c-tiny-usb))
 
 
+I2C_BCM_IPROC_MODULES:= \
+  CONFIG_I2C_BCM_IPROC:drivers/i2c/busses/i2c-bcm-iproc
+
+define KernelPackage/i2c-bcm-iproc
+  $(call i2c_defaults,$(I2C_BCM_IPROC_MODULES),59)
+  TITLE:=Broadcom iProc I2C controller
+  DEPENDS:=@TARGET_bcm53xx +kmod-i2c-core
+endef
+
+define KernelPackage/i2c-bcm-iproc/description
+ Kernel module for the Broadcom iProc I2C controller.
+endef
+
+$(eval $(call KernelPackage,i2c-bcm-iproc))
-- 
2.28.0


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


[PATCH v3 5/8] kernel: add default for new config symbols

2020-09-12 Thread Christian Lamparter
Provide disabled defaults for I2C_SLAVE_EEPROM and IPMB_DEVICE_INTERFACE.

Signed-off-by: Christian Lamparter 
---
 target/linux/generic/config-5.4 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index 6f63b8c5dd..1c28addff4 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -2134,6 +2134,7 @@ CONFIG_HW_RANDOM_TPM=y
 # CONFIG_I2C_SIS630 is not set
 # CONFIG_I2C_SIS96X is not set
 # CONFIG_I2C_SLAVE is not set
+# CONFIG_I2C_SLAVE_EEPROM is not set
 # CONFIG_I2C_SMBUS is not set
 # CONFIG_I2C_STUB is not set
 # CONFIG_I2C_TAOS_EVM is not set
@@ -2394,6 +2395,7 @@ CONFIG_IO_STRICT_DEVMEM=y
 # CONFIG_IP6_NF_TARGET_SYNPROXY is not set
 # CONFIG_IPACK_BUS is not set
 # CONFIG_IPC_NS is not set
+# CONFIG_IPMB_DEVICE_INTERFACE is not set
 # CONFIG_IPMI_HANDLER is not set
 # CONFIG_IPV6 is not set
 # CONFIG_IPV6_FOU is not set
-- 
2.28.0


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


[PATCH v2 7/7] bcm53xx: add Cisco Meraki MR32

2020-09-05 Thread Christian Lamparter
This patch adds support for Cisco Meraki MR32.
The unit was donated by Chris Blake. Thank you!

WARNING:
Only the 1x1:1 abgn Air Marshal WIPS wifi is currently supported by b43:
 b43-phy2: Found PHY: Analog 9, Type 4 (N), Revision 16
 b43-phy2: Found Radio: Manuf 0x17F, ID 0x2057, Revision 9, Version 1
 b43-phy2: Loading firmware version 784.2 (2012-08-15 21:35:19)
 and only as 802.11ABG!

while WIFI1 and WIFI2 (both BCM4352) are not:
 b43-phy0: Broadcom 4352 WLAN found (core revision 42)
 b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)

Hardware Highlights:

SoC:Broadcom BCM53016A1 (1 GHz, 2 cores)
RAM:128 MiB
NAND:   128 MiB Spansion S34ML01G2 (~114 MiB useable)
ETH:1GBit Ethernet Port - PoE
WIFI1:  Broadcom BCM43520 an+ac (2x2:2 - id: 0x4352)
WIFI2:  Broadcom BCM43520 bgn (2x2:2 - id: 0x4352)
WIFI3:  Broadcom BCM43428 abgn (1x1:1 - id: 43428)

BLE:Broadcom BCM20732 (ttyS1)
LEDS:   1 x Programmable RGB Status LED (driven by a PWM)
1 x White LED (GPIO)
1 x Orange LED Fault Indicator (GPIO)
2 x LAN Activity / Speed LEDs (On the RJ45 Port)
BUTTON: one Reset button
MISC:   AT24C64 8KiB EEPROM (i2c - stores Ethernet MAC + Serial#!)
ina219 hardware monitor (i2c)
Kensington Lock

SERIAL:
WARNING: The serial port needs a TTL/RS-232 3V3 level converter!
The Serial setting is 115200-8-N-1. The board has a populated
right angle 1x4 0.1" pinheader.
The pinout is: VCC, RX, TX, GND. (Use a multimeter)

Flashing needs a serial adaptor (due to the lack of a working dropbear on
the original firmware).

This flashing procedure for the MR32 was tested with firmware:
"r23-149867:150252-aacharya".

0. Create a seperate Ethernet LAN which does not have access to the internet.
   Ideally use 192.168.1.2 for your PC. Make sure to reserve 192.168.1.1 it
   will be used later on by the OpenWrt firmware. The original Meraki firmware
   will likely try to setup the network via DHCP Discovery, so make sure your
   PC is running a DHCP-Server (i.e.: dnsmasq)
   '# dnsmasq -i eth# -F 192.168.1.5,192.168.1.50
   Furthermore, the PC needs a supported ssh/http/ftp server in order to
   retrieve the initramfs + dtb file

1. Disassemble the MR32 device by removing all screws (4 screws are located
   under the 4 rubber feets!) and prying open the plastic covers without
   breaking the plastic retention clips. Once inside, remove all the screws
   on the outer metal shielding to get to the PCB. It's not necessary to
   remove the antennas!

2. Connect the serial cable to the serial header.

3. Partially reassemble the outer metal shielding to ensure that the SoC
   has a proper heat sink.

4. Connect the Ethernet patch cable to the device and the power cable.

5. Wait for the device to boot and enter the root shell.
   (rooting is not discussed in detail here please refer to
   Chris Blake - "pwning the meraki mr18" blog post:
   <https://servernetworktech.com/2016/02/pwning-the-meraki-mr18/>
   (The same method works with the MR32's r23-149867:150252-aacharya)

   Wait for the MR32 to enter the "" prompt and enter:
odm serial_num read
   (Verify that it matches what's on the S/N Sticker on the back!)
odm serial_num write Q2XX--XXXV
odm serial_num read
   (Verify that the S/N has changed - and the LED start to flash)

   now to flash the firmware:
odm firmware part.safe "http://192.168.1.2/mr32-initramfs.bin;

Once OpenWrt booted use sysupgrade to permanently install
OpenWrt. To do this: Download the latest sysupgrade.bin file
for the MR32 to the device and use sysupgrade *sysupgrade.bin
to install it.

WARNING: DO NOT DELETE the "storage" ubi volume!

To flash later MR32 Firmwares like r25-201804051805-G885d6d78-dhow-rel
requires in-circut-i2c tools to access the I2C EEPROM AT24C64 next to
the SoC. The idea is pretty much the same as from Step 5 from above:
Change the serial number to Q2XV (should be around 0x7c), then
attach a serial cable, ethernet (but make sure the device can't reach
the internet!) hit "s" (the small s!) during boot to enter the root-shell
and add the following commands to the /storage/config there:

serial_allow_odm true
serial_access_enabled true
serial_access_check false
valid_config true

and then hit exit to let it finish booting.

Signed-off-by: Christian Lamparter 

---

rfc -> v2
- fixed Adrian's comments
- unbroke sysupgrade on other bcm53xx
---
 .../bcm53xx/base-files/etc/board.d/02_network |   7 +-
 target/linux/bcm53xx/base-files/etc/diag.sh   |   3 +
 .../lib/preinit/07_set_preinit_iface_bcm53xx  |  14 +
 .../base-files/lib/upgrade/platform.sh|  43 ++-
 target/linux/bcm53xx/image/Makefile   |  27 ++
 ...-ARM-BCM5301X-Add-DT-for-Meraki-MR32.patch | 281 ++
 .../331-Meraki-MR32-Status-LEDs.patch |  28 ++
 7 files changed, 400 insertions(+), 3 

[PATCH v2 1/7] scripts: mkits.sh make it possible to specify fdt@#

2020-09-05 Thread Christian Lamparter
Some bootloaders are really keen on just one special
fdt in a multi-image fit image. This is a problem, because
currently this is fixed to "fdt@1".

This patch introduces a new device variable:
DEVICE_FDT_NUM that allows to specify the right
fdt number.

If the value is absent "1" will be chosen.

Signed-off-by: Christian Lamparter 
---
 include/image-commands.mk |  1 +
 include/image.mk  |  6 --
 scripts/mkits.sh  | 12 
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/image-commands.mk b/include/image-commands.mk
index 9516801c8d..740d627fc7 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -158,6 +158,7 @@ define Build/fit
-D $(DEVICE_NAME) -o $@.its -k $@ \
$(if $(word 2,$(1)),-d $(word 2,$(1))) -C $(word 1,$(1)) \
-a $(KERNEL_LOADADDR) -e $(if 
$(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
+   $(if $(DEVICE_FDT_NUM),-n $(DEVICE_FDT_NUM)) \
-c $(if $(DEVICE_DTS_CONFIG),$(DEVICE_DTS_CONFIG),"config@1") \
-A $(LINUX_KARCH) -v $(LINUX_VERSION)
PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.new
diff --git a/include/image.mk b/include/image.mk
index 703aeb6816..a1308f47ad 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -432,6 +432,7 @@ define Device/Init
   DEVICE_DTS :=
   DEVICE_DTS_CONFIG :=
   DEVICE_DTS_DIR :=
+  DEVICE_FDT_NUM :=
   SOC :=
 
   BOARD_NAME :=
@@ -453,8 +454,9 @@ DEFAULT_DEVICE_VARS := \
   DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_INITRAMFS_IMAGE KERNEL_SIZE \
   CMDLINE UBOOTENV_IN_UBI KERNEL_IN_UBI BLOCKSIZE PAGESIZE SUBPAGESIZE \
   VID_HDR_OFFSET UBINIZE_OPTS UBINIZE_PARTS MKUBIFS_OPTS DEVICE_DTS \
-  DEVICE_DTS_CONFIG DEVICE_DTS_DIR SOC BOARD_NAME UIMAGE_NAME 
SUPPORTED_DEVICES \
-  IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR UBOOT_PATH IMAGE_SIZE \
+  DEVICE_DTS_CONFIG DEVICE_DTS_DIR DEVICE_FDT_NUM SOC BOARD_NAME \
+  UIMAGE_NAME SUPPORTED_DEVICES IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR \
+  UBOOT_PATH IMAGE_SIZE \
   DEVICE_COMPAT_VERSION DEVICE_COMPAT_MESSAGE \
   DEVICE_VENDOR DEVICE_MODEL DEVICE_VARIANT \
   DEVICE_ALT0_VENDOR DEVICE_ALT0_MODEL DEVICE_ALT0_VARIANT \
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
index 468ef670e6..bb629d6fca 100755
--- a/scripts/mkits.sh
+++ b/scripts/mkits.sh
@@ -16,7 +16,7 @@
 
 usage() {
printf "Usage: %s -A arch -C comp -a addr -e entry" "$(basename "$0")"
-   printf " -v version -k kernel [-D name -d dtb] -o its_file"
+   printf " -v version -k kernel [-D name -n address -d dtb] -o its_file"
 
printf "\n\t-A ==> set architecture to 'arch'"
printf "\n\t-C ==> set compression type 'comp'"
@@ -26,12 +26,15 @@ usage() {
printf "\n\t-v ==> set kernel version to 'version'"
printf "\n\t-k ==> include kernel image 'kernel'"
printf "\n\t-D ==> human friendly Device Tree Blob 'name'"
+   printf "\n\t-n ==> fdt unit-address 'address'"
printf "\n\t-d ==> include Device Tree Blob 'dtb'"
printf "\n\t-o ==> create output file 'its_file'\n"
exit 1
 }
 
-while getopts ":A:a:c:C:D:d:e:k:o:v:" OPTION
+FDTNUM=1
+
+while getopts ":A:a:c:C:D:d:e:k:n:o:v:" OPTION
 do
case $OPTION in
A ) ARCH=$OPTARG;;
@@ -42,6 +45,7 @@ do
d ) DTB=$OPTARG;;
e ) ENTRY_ADDR=$OPTARG;;
k ) KERNEL=$OPTARG;;
+   n ) FDTNUM=$OPTARG;;
o ) OUTPUT=$OPTARG;;
v ) VERSION=$OPTARG;;
* ) echo "Invalid option passed to '$0' (options:$*)"
@@ -61,7 +65,7 @@ ARCH_UPPER=$(echo "$ARCH" | tr '[:lower:]' '[:upper:]')
 # Conditionally create fdt information
 if [ -n "${DTB}" ]; then
FDT_NODE="
-   fdt@1 {
+   fdt@$FDTNUM {
description = \"${ARCH_UPPER} OpenWrt ${DEVICE} device 
tree blob\";
data = /incbin/(\"${DTB}\");
type = \"flat_dt\";
@@ -75,7 +79,7 @@ if [ -n "${DTB}" ]; then
};
};
 "
-   FDT_PROP="fdt = \"fdt@1\";"
+   FDT_PROP="fdt = \"fdt@$FDTNUM\";"
 fi
 
 # Create a default, fully populated DTS file
-- 
2.28.0


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


[PATCH v2 3/7] bcm53xx: enable PWM for bcm53xx

2020-09-05 Thread Christian Lamparter
The Meraki MR32 (BCM53016A1) uses the pwm to drive the
tricolor LED. The driver has been available in upstream
for a long time. Only the Device-Tree definition was
missing, but it has been queued recently.

Signed-off-by: Christian Lamparter 
---
 target/linux/bcm53xx/Makefile |  2 +-
 target/linux/bcm53xx/config-5.4   |  3 ++
 ...M-dts-BCM5301X-Specify-PWM-in-the-DT.patch | 45 +++
 3 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch

diff --git a/target/linux/bcm53xx/Makefile b/target/linux/bcm53xx/Makefile
index 35f8513801..f980f8a8fb 100644
--- a/target/linux/bcm53xx/Makefile
+++ b/target/linux/bcm53xx/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=bcm53xx
 BOARDNAME:=Broadcom BCM47xx/53xx (ARM)
-FEATURES:=squashfs nand usb pci pcie gpio
+FEATURES:=squashfs nand usb pci pcie gpio pwm
 CPU_TYPE:=cortex-a9
 SUBTARGETS:=generic
 
diff --git a/target/linux/bcm53xx/config-5.4 b/target/linux/bcm53xx/config-5.4
index eacfcb620e..8c7cdf45d5 100644
--- a/target/linux/bcm53xx/config-5.4
+++ b/target/linux/bcm53xx/config-5.4
@@ -308,6 +308,9 @@ CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_IPROC_GPIO is not set
 CONFIG_PINCTRL_NS=y
 # CONFIG_PINCTRL_NS2_MUX is not set
+CONFIG_PWM=y
+CONFIG_PWM_BCM_IPROC=y
+CONFIG_PWM_SYSFS=y
 CONFIG_RATIONAL=y
 CONFIG_RCU_NEED_SEGCBLIST=y
 CONFIG_RCU_STALL_COMMON=y
diff --git 
a/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
new file mode 100644
index 00..d7b871bde4
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
@@ -0,0 +1,45 @@
+From 9bd34833986d4af180c6d75a326edb933a17de31 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Wed, 6 Jun 2018 21:01:59 +0200
+Subject: [PATCH] ARM: dts: BCM5301X: Specify PWM in the DT
+
+The BCM53016 in the Meraki MR32 uses the on-chip PWM
+controller to drive a tri-color RGB LED. Since I plan
+to use the PWM, I made a label for the pwm's pinmux
+node. This way, it can be easily referenced.
+
+Signed-off-by: Christian Lamparter 
+Acked-by: Scott Branden 
+
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -350,6 +350,14 @@
+   };
+   };
+ 
++  pwm: pwm@18002000 {
++  compatible = "brcm,iproc-pwm";
++  reg = <0x18002000 0x28>;
++  clocks = <>;
++  #pwm-cells = <3>;
++  status = "disabled";
++  };
++
+   mdio: mdio@18003000 {
+   compatible = "brcm,iproc-mdio";
+   reg = <0x18003000 0x8>;
+@@ -417,12 +425,12 @@
+   function = "spi";
+   };
+ 
+-  i2c {
++  pinmux_i2c: i2c {
+   groups = "i2c_grp";
+   function = "i2c";
+   };
+ 
+-  pwm {
++  pinmux_pwm: pwm {
+   groups = "pwm0_grp", "pwm1_grp",
+"pwm2_grp", "pwm3_grp";
+   function = "pwm";
-- 
2.28.0


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


[PATCH v2 4/7] bcm53xx: backport uart2 and pcie2 device-nodes

2020-09-05 Thread Christian Lamparter
These have made their way into -next.

Signed-off-by: Christian Lamparter 
---
 ...dts-BCM5301X-Specify-uart2-in-the-DT.patch | 37 +++
 ...dts-BCM5301X-Specify-pcie2-in-the-DT.patch | 33 +
 2 files changed, 70 insertions(+)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
 create mode 100644 
target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch

diff --git 
a/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
new file mode 100644
index 00..1fec981146
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
@@ -0,0 +1,37 @@
+From 95c1f0076303922ca401851b6605dc17eb0eb732 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Wed, 6 Jun 2018 21:57:15 +0200
+Subject: [PATCH 1/4] ARM: dts: BCM5301X: Specify uart2 in the DT
+
+The BCM53016 in the Meraki MR32 utilizes the third "uart2"
+to connect to a on-board Bluetooth-LE 4.0 BCM20732 chip.
+
+Signed-off-by: Christian Lamparter 
+Reviewed-by: Scott Branden 
+---
+ arch/arm/boot/dts/bcm5301x.dtsi | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
+index 45cd8c7411dd..eb1290fed235 100644
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -392,6 +392,15 @@ usb3_dmp: syscon@18105000 {
+   reg = <0x18105000 0x1000>;
+   };
+ 
++  uart2: serial@18008000 {
++  compatible = "ns16550a";
++  reg = <0x18008000 0x20>;
++  clocks = <>;
++  interrupts = ;
++  reg-shift = <2>;
++  status = "disabled";
++  };
++
+   i2c0: i2c@18009000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18009000 0x50>;
+-- 
+2.28.0
+
diff --git 
a/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
new file mode 100644
index 00..d4ec31c0ae
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
@@ -0,0 +1,33 @@
+From 5abb709b027a6234c135843764bad383be264162 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Sun, 10 Jun 2018 17:17:53 +0200
+Subject: [PATCH 2/4] ARM: dts: BCM5301X: Specify pcie2 in the DT
+
+The SoC supports three pcie ports. Currently, only
+pcie0 and pcie1 are enabled. This patch adds the
+pcie2 port as well.
+
+Signed-off-by: Christian Lamparter 
+Reviewed-by: Scott Branden 
+---
+ arch/arm/boot/dts/bcm5301x.dtsi | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
+index eb1290fed235..9d9e8fe3f6ae 100644
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -252,6 +252,10 @@ pcie1: pcie@13000 {
+   reg = <0x00013000 0x1000>;
+   };
+ 
++  pcie2: pcie@14000 {
++  reg = <0x00014000 0x1000>;
++  };
++
+   usb2: usb2@21000 {
+   reg = <0x00021000 0x1000>;
+ 
+-- 
+2.28.0
+
-- 
2.28.0


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


[PATCH v2 6/7] kernel: package bcm53xx i2c module

2020-09-05 Thread Christian Lamparter
The BCM5301x SoCs do have i2c. Since this is only
being used by the Meraki MR32, this will be packaged
as a module.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/i2c.mk | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/package/kernel/linux/modules/i2c.mk 
b/package/kernel/linux/modules/i2c.mk
index ca6463c81b..1c8b1b844e 100644
--- a/package/kernel/linux/modules/i2c.mk
+++ b/package/kernel/linux/modules/i2c.mk
@@ -259,3 +259,17 @@ endef
 $(eval $(call KernelPackage,i2c-tiny-usb))
 
 
+I2C_BCM_IPROC_MODULES:= \
+  CONFIG_I2C_BCM_IPROC:drivers/i2c/busses/i2c-bcm-iproc
+
+define KernelPackage/i2c-bcm-iproc
+  $(call i2c_defaults,$(I2C_BCM_IPROC_MODULES),59)
+  TITLE:=Broadcom iProc I2C controller
+  DEPENDS:=@TARGET_bcm53xx +kmod-i2c-core
+endef
+
+define KernelPackage/i2c-bcm-iproc/description
+ Kernel module for the Broadcom iProc I2C controller.
+endef
+
+$(eval $(call KernelPackage,i2c-bcm-iproc))
-- 
2.28.0


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


[PATCH v2 5/7] kernel: add default for new config symbols

2020-09-05 Thread Christian Lamparter
Provide disabled defaults for I2C_SLAVE_EEPROM and IPMB_DEVICE_INTERFACE.

Signed-off-by: Christian Lamparter 
---
 target/linux/generic/config-5.4 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index d543819aad..2f5ab98d26 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -2134,6 +2134,7 @@ CONFIG_HW_RANDOM_TPM=y
 # CONFIG_I2C_SIS630 is not set
 # CONFIG_I2C_SIS96X is not set
 # CONFIG_I2C_SLAVE is not set
+# CONFIG_I2C_SLAVE_EEPROM is not set
 # CONFIG_I2C_SMBUS is not set
 # CONFIG_I2C_STUB is not set
 # CONFIG_I2C_TAOS_EVM is not set
@@ -2394,6 +2395,7 @@ CONFIG_IO_STRICT_DEVMEM=y
 # CONFIG_IP6_NF_TARGET_SYNPROXY is not set
 # CONFIG_IPACK_BUS is not set
 # CONFIG_IPC_NS is not set
+# CONFIG_IPMB_DEVICE_INTERFACE is not set
 # CONFIG_IPMI_HANDLER is not set
 # CONFIG_IPV6 is not set
 # CONFIG_IPV6_FOU is not set
-- 
2.28.0


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


[PATCH v2 2/7] build: define PWM_SUPPORT arch feature flag

2020-09-05 Thread Christian Lamparter
As the PWM has its own sub-system in the Linux kernel,
I think it should be handled in the same way as GPIO, RTC, PCI...

This patch introduces a specific feature flag "pwm" and the
"leds-pwm" kernel module as the first customer.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/leds.mk | 16 
 scripts/target-metadata.pl   |  1 +
 target/Config.in |  3 +++
 3 files changed, 20 insertions(+)

diff --git a/package/kernel/linux/modules/leds.mk 
b/package/kernel/linux/modules/leds.mk
index c030b54b39..fe90c6b559 100644
--- a/package/kernel/linux/modules/leds.mk
+++ b/package/kernel/linux/modules/leds.mk
@@ -159,3 +159,19 @@ define KernelPackage/leds-pca963x/description
 endef
 
 $(eval $(call KernelPackage,leds-pca963x))
+
+
+define KernelPackage/leds-pwm
+  SUBMENU:=$(LEDS_MENU)
+  TITLE:=PWM driven LED Support
+  KCONFIG:=CONFIG_LEDS_PWM
+  DEPENDS:= @PWM_SUPPORT
+  FILES:=$(LINUX_DIR)/drivers/leds/leds-pwm.ko
+  AUTOLOAD:=$(call AutoLoad,60,leds-pwm,1)
+endef
+
+define KernelPackage/leds-pwm/description
+ This option enables support for pwm driven LEDs
+endef
+
+$(eval $(call KernelPackage,leds-pwm))
diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index c58f096573..bf6413d315 100755
--- a/scripts/target-metadata.pl
+++ b/scripts/target-metadata.pl
@@ -20,6 +20,7 @@ sub target_config_features(@) {
/^usb$/ and $ret .= "\tselect USB_SUPPORT\n";
/^usbgadget$/ and $ret .= "\tselect USB_GADGET_SUPPORT\n";
/^pcmcia$/ and $ret .= "\tselect PCMCIA_SUPPORT\n";
+   /^pwm$/ and $ret .= "\select PWM_SUPPORT\n";
/^rtc$/ and $ret .= "\tselect RTC_SUPPORT\n";
/^squashfs$/ and $ret .= "\tselect USES_SQUASHFS\n";
/^jffs2$/ and $ret .= "\tselect USES_JFFS2\n";
diff --git a/target/Config.in b/target/Config.in
index 9fead5994f..43de4710df 100644
--- a/target/Config.in
+++ b/target/Config.in
@@ -29,6 +29,9 @@ config PCIE_SUPPORT
 config PCMCIA_SUPPORT
bool
 
+config PWM_SUPPORT
+   bool
+
 config USB_SUPPORT
select AUDIO_SUPPORT
bool
-- 
2.28.0


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


Re: MR24 wifi broken by recent commit

2020-09-05 Thread Christian Lamparter

Almost lost this in the spam-folder :( .

On 2020-09-03 23:22, Russell Senior wrote:

Christian Lamparter  writes:



On 2020-09-03 10:44, Russell Senior wrote:

commit 9153955095f01a7ac5f2659a671f0229cbad3507 Author: Christian
Lamparter mailto:chunk...@gmail.com>> Date:
Wed Aug 12 18:26:43 2020 +0200

     apm821xx: MR24: enumerate PCIe in device-tree

     This patch adds the pcie-switch and bridge configuration for
the Meraki MR24.

     Signed-off-by: Christian Lamparter mailto:chunk...@gmail.com>>

The symptom is client devices can't see the beacons. Wifi ifaces
appear, can scan and hear other networks, but clients can't see the
MR24's SSIDs. Reverting the commit above and it works normally again.



Thanks for the report. CONFIG_PCI_DEBUG





"ath9k :44:00.0: runtime IRQ mapping not provided by arch"





since DT overwrites the usual PCI(e) enumeration and MSI(x) is



busted there's no choice but to specify legacy INTABCDs.




Can you please try the attached patch?


Your patch fixes it.

I am a little curious, if it works without your commit, what is the
motivation for the commit?



APM82181 needs to move forward. I'm trying to upstream these devices.
Since nobody is commenting on linux-ppcdev, I have to spin the wheels
and preemptively spif-things up from version to version.

In the end, I'm hoping to avoid smart questions about:
"hey, why does this dual-band accesspoint device of yours not define a
single wifi-device in the DT? Like is this even working or what?"

You could tell the linux-ppcdev about your experience with the MR24
by replying to the latest v3 series:
<https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-September/217642.html>

Cheers,
Christian

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


Re: MR24 wifi broken by recent commit

2020-09-03 Thread Christian Lamparter

On 2020-09-03 10:44, Russell Senior wrote:

commit 9153955095f01a7ac5f2659a671f0229cbad3507
Author: Christian Lamparter mailto:chunk...@gmail.com>>
Date:   Wed Aug 12 18:26:43 2020 +0200

     apm821xx: MR24: enumerate PCIe in device-tree

     This patch adds the pcie-switch and bridge configuration for
     the Meraki MR24.

     Signed-off-by: Christian Lamparter <mailto:chunk...@gmail.com>>


The symptom is client devices can't see the beacons. Wifi ifaces appear, 
can scan and hear other networks, but clients can't see the MR24's 
SSIDs. Reverting the commit above and it works normally again.


Thanks for the report. CONFIG_PCI_DEBUG



"ath9k :44:00.0: runtime IRQ mapping not provided by arch"



since DT overwrites the usual PCI(e) enumeration and MSI(x) is

busted there's no choice but to specify legacy INTABCDs.


Can you please try the attached patch?
---
diff --git a/target/linux/apm821xx/dts/meraki-mr24.dts 
b/target/linux/apm821xx/dts/meraki-mr24.dts

index 102df59ef0..b28fd2449f 100644
--- a/target/linux/apm821xx/dts/meraki-mr24.dts
+++ b/target/linux/apm821xx/dts/meraki-mr24.dts
@@ -227,6 +227,7 @@
/* Atheros AR9380 2.4GHz */
compatible = "pci168c,0030";
reg = <0x0043 0 0 0 0>;
+   interrupts = <3>; /* INTC 4.1.1 */
};
};

@@ -241,6 +242,7 @@
/* Atheros AR9380 5GHz */
compatible = "pci168c,0030";
reg = <0x0044 0 0 0 0>;
+   interrupts = <4>; /* INTD 4.1.1 */
};
};
};

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


Re: [RFC PATCH v1 8/8] bcm53xx: add Cisco Meraki MR32

2020-08-30 Thread Christian Lamparter

Hello Adrian,

On 2020-08-30 15:28, Adrian Schmutzler wrote:

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Christian Lamparter
Sent: Sonntag, 30. August 2020 05:04
To: openwrt-devel@lists.openwrt.org
Cc: ra...@milecki.pl; ha...@hauke-m.de; f.faine...@gmail.com;
chrisrblak...@gmail.com
Subject: [RFC PATCH v1 8/8] bcm53xx: add Cisco Meraki MR32


though this is RFC, a few cosmetic remarks I just noticed when reading:


Yes, thank you. I made all the suggested changes... and found some more 
problems as well (I broke the sysupgrade image check by not returning 
the check result). :)


Cheers,
Christian


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


[RFC PATCH v1 4/8] bcm53xx: enable PWM for bcm53xx

2020-08-29 Thread Christian Lamparter
The Meraki MR32 (BCM53016A1) uses the pwm to drive the
tricolor LED. The driver has been available in upstream
for a long time. Only the Device-Tree definition was
missing, but it has been queued recently.

Signed-off-by: Christian Lamparter 
---
 target/linux/bcm53xx/Makefile |  2 +-
 target/linux/bcm53xx/config-5.4   |  3 ++
 ...M-dts-BCM5301X-Specify-PWM-in-the-DT.patch | 45 +++
 3 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch

diff --git a/target/linux/bcm53xx/Makefile b/target/linux/bcm53xx/Makefile
index 35f8513801..f980f8a8fb 100644
--- a/target/linux/bcm53xx/Makefile
+++ b/target/linux/bcm53xx/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=bcm53xx
 BOARDNAME:=Broadcom BCM47xx/53xx (ARM)
-FEATURES:=squashfs nand usb pci pcie gpio
+FEATURES:=squashfs nand usb pci pcie gpio pwm
 CPU_TYPE:=cortex-a9
 SUBTARGETS:=generic
 
diff --git a/target/linux/bcm53xx/config-5.4 b/target/linux/bcm53xx/config-5.4
index eacfcb620e..8c7cdf45d5 100644
--- a/target/linux/bcm53xx/config-5.4
+++ b/target/linux/bcm53xx/config-5.4
@@ -308,6 +308,9 @@ CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_IPROC_GPIO is not set
 CONFIG_PINCTRL_NS=y
 # CONFIG_PINCTRL_NS2_MUX is not set
+CONFIG_PWM=y
+CONFIG_PWM_BCM_IPROC=y
+CONFIG_PWM_SYSFS=y
 CONFIG_RATIONAL=y
 CONFIG_RCU_NEED_SEGCBLIST=y
 CONFIG_RCU_STALL_COMMON=y
diff --git 
a/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
new file mode 100644
index 00..d7b871bde4
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/033-v5.10-ARM-dts-BCM5301X-Specify-PWM-in-the-DT.patch
@@ -0,0 +1,45 @@
+From 9bd34833986d4af180c6d75a326edb933a17de31 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Wed, 6 Jun 2018 21:01:59 +0200
+Subject: [PATCH] ARM: dts: BCM5301X: Specify PWM in the DT
+
+The BCM53016 in the Meraki MR32 uses the on-chip PWM
+controller to drive a tri-color RGB LED. Since I plan
+to use the PWM, I made a label for the pwm's pinmux
+node. This way, it can be easily referenced.
+
+Signed-off-by: Christian Lamparter 
+Acked-by: Scott Branden 
+
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -350,6 +350,14 @@
+   };
+   };
+ 
++  pwm: pwm@18002000 {
++  compatible = "brcm,iproc-pwm";
++  reg = <0x18002000 0x28>;
++  clocks = <>;
++  #pwm-cells = <3>;
++  status = "disabled";
++  };
++
+   mdio: mdio@18003000 {
+   compatible = "brcm,iproc-mdio";
+   reg = <0x18003000 0x8>;
+@@ -417,12 +425,12 @@
+   function = "spi";
+   };
+ 
+-  i2c {
++  pinmux_i2c: i2c {
+   groups = "i2c_grp";
+   function = "i2c";
+   };
+ 
+-  pwm {
++  pinmux_pwm: pwm {
+   groups = "pwm0_grp", "pwm1_grp",
+"pwm2_grp", "pwm3_grp";
+   function = "pwm";
-- 
2.28.0


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


[RFC PATCH v1 7/8] kernel: package bcm53xx i2c module

2020-08-29 Thread Christian Lamparter
The BCM5301x SoCs do have i2c. Since this is only
being used by the Meraki MR32, this will be packaged
as a module.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/i2c.mk | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/package/kernel/linux/modules/i2c.mk 
b/package/kernel/linux/modules/i2c.mk
index ca6463c81b..1c8b1b844e 100644
--- a/package/kernel/linux/modules/i2c.mk
+++ b/package/kernel/linux/modules/i2c.mk
@@ -259,3 +259,17 @@ endef
 $(eval $(call KernelPackage,i2c-tiny-usb))
 
 
+I2C_BCM_IPROC_MODULES:= \
+  CONFIG_I2C_BCM_IPROC:drivers/i2c/busses/i2c-bcm-iproc
+
+define KernelPackage/i2c-bcm-iproc
+  $(call i2c_defaults,$(I2C_BCM_IPROC_MODULES),59)
+  TITLE:=Broadcom iProc I2C controller
+  DEPENDS:=@TARGET_bcm53xx +kmod-i2c-core
+endef
+
+define KernelPackage/i2c-bcm-iproc/description
+ Kernel module for the Broadcom iProc I2C controller.
+endef
+
+$(eval $(call KernelPackage,i2c-bcm-iproc))
-- 
2.28.0


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


[RFC PATCH v1 1/8] base-files: support label-property-less in get_dt_leds

2020-08-29 Thread Christian Lamparter
The "label" property we used and loved has been deprecated upstream by:

|commit c5d18dd6b64e09dd6984bda9bdd55160af537a8c
|Author: Jacek Anaszewski 
|Date:   Sun Jun 9 20:19:04 2019 +0200
|
|dt-bindings: leds: Add properties for LED name construction
|
|Introduce dedicated properties for conveying information about
|LED function and color. Mark old "label" property as deprecated.
|
|Additionally function-enumerator property is being provided
|for the cases when neither function nor color can be used
|for LED differentiation.

in order to be somewhat prepared, this patch adds a fallback
as a last resort to get a proper label based on the node-name.

Signed-off-by: Christian Lamparter 
---
 package/base-files/Makefile| 2 +-
 package/base-files/files/lib/functions/leds.sh | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 7eb3ac1868..2419849a44 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
 include $(INCLUDE_DIR)/feeds.mk
 
 PKG_NAME:=base-files
-PKG_RELEASE:=227
+PKG_RELEASE:=228
 PKG_FLAGS:=nonshared
 
 PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/lib/functions/leds.sh 
b/package/base-files/files/lib/functions/leds.sh
index 43b2fe02ed..14baeb37b4 100644
--- a/package/base-files/files/lib/functions/leds.sh
+++ b/package/base-files/files/lib/functions/leds.sh
@@ -18,7 +18,8 @@ get_dt_led() {
 
[ -n "$ledpath" ] && \
label=$(cat "$ledpath/label" 2>/dev/null) || \
-   label=$(cat "$ledpath/chan-name" 2>/dev/null)
+   label=$(cat "$ledpath/chan-name" 2>/dev/null) || \
+   label=$(basename "$ledpath")
 
echo "$label"
 }
-- 
2.28.0


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


[RFC PATCH v1 2/8] scripts: mkits.sh make it possible to specify fdt@#

2020-08-29 Thread Christian Lamparter
Some bootloaders are really keen on just one special
fdt in a multi-image fit image. This is a problem, because
currently this is fixed to "fdt@1".

This patch introduces a new device variable:
DEVICE_FDT_NUM that allows to specify the right
fdt number.

If the value is absent "1" will be chosen.

Signed-off-by: Christian Lamparter 
---
 include/image-commands.mk |  1 +
 include/image.mk  |  6 --
 scripts/mkits.sh  | 12 
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/image-commands.mk b/include/image-commands.mk
index 9516801c8d..740d627fc7 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -158,6 +158,7 @@ define Build/fit
-D $(DEVICE_NAME) -o $@.its -k $@ \
$(if $(word 2,$(1)),-d $(word 2,$(1))) -C $(word 1,$(1)) \
-a $(KERNEL_LOADADDR) -e $(if 
$(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
+   $(if $(DEVICE_FDT_NUM),-n $(DEVICE_FDT_NUM)) \
-c $(if $(DEVICE_DTS_CONFIG),$(DEVICE_DTS_CONFIG),"config@1") \
-A $(LINUX_KARCH) -v $(LINUX_VERSION)
PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.new
diff --git a/include/image.mk b/include/image.mk
index e8c2cf7100..2b48b8693c 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -415,6 +415,7 @@ define Device/Init
   DEVICE_DTS :=
   DEVICE_DTS_CONFIG :=
   DEVICE_DTS_DIR :=
+  DEVICE_FDT_NUM :=
   SOC :=
 
   BOARD_NAME :=
@@ -436,8 +437,9 @@ DEFAULT_DEVICE_VARS := \
   DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_INITRAMFS_IMAGE KERNEL_SIZE \
   CMDLINE UBOOTENV_IN_UBI KERNEL_IN_UBI BLOCKSIZE PAGESIZE SUBPAGESIZE \
   VID_HDR_OFFSET UBINIZE_OPTS UBINIZE_PARTS MKUBIFS_OPTS DEVICE_DTS \
-  DEVICE_DTS_CONFIG DEVICE_DTS_DIR SOC BOARD_NAME UIMAGE_NAME 
SUPPORTED_DEVICES \
-  IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR UBOOT_PATH IMAGE_SIZE \
+  DEVICE_DTS_CONFIG DEVICE_DTS_DIR DEVICE_FDT_NUM SOC BOARD_NAME \
+  UIMAGE_NAME SUPPORTED_DEVICES IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR \
+  UBOOT_PATH IMAGE_SIZE \
   DEVICE_COMPAT_VERSION DEVICE_COMPAT_MESSAGE \
   DEVICE_VENDOR DEVICE_MODEL DEVICE_VARIANT \
   DEVICE_ALT0_VENDOR DEVICE_ALT0_MODEL DEVICE_ALT0_VARIANT \
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
index 468ef670e6..bb629d6fca 100755
--- a/scripts/mkits.sh
+++ b/scripts/mkits.sh
@@ -16,7 +16,7 @@
 
 usage() {
printf "Usage: %s -A arch -C comp -a addr -e entry" "$(basename "$0")"
-   printf " -v version -k kernel [-D name -d dtb] -o its_file"
+   printf " -v version -k kernel [-D name -n address -d dtb] -o its_file"
 
printf "\n\t-A ==> set architecture to 'arch'"
printf "\n\t-C ==> set compression type 'comp'"
@@ -26,12 +26,15 @@ usage() {
printf "\n\t-v ==> set kernel version to 'version'"
printf "\n\t-k ==> include kernel image 'kernel'"
printf "\n\t-D ==> human friendly Device Tree Blob 'name'"
+   printf "\n\t-n ==> fdt unit-address 'address'"
printf "\n\t-d ==> include Device Tree Blob 'dtb'"
printf "\n\t-o ==> create output file 'its_file'\n"
exit 1
 }
 
-while getopts ":A:a:c:C:D:d:e:k:o:v:" OPTION
+FDTNUM=1
+
+while getopts ":A:a:c:C:D:d:e:k:n:o:v:" OPTION
 do
case $OPTION in
A ) ARCH=$OPTARG;;
@@ -42,6 +45,7 @@ do
d ) DTB=$OPTARG;;
e ) ENTRY_ADDR=$OPTARG;;
k ) KERNEL=$OPTARG;;
+   n ) FDTNUM=$OPTARG;;
o ) OUTPUT=$OPTARG;;
v ) VERSION=$OPTARG;;
* ) echo "Invalid option passed to '$0' (options:$*)"
@@ -61,7 +65,7 @@ ARCH_UPPER=$(echo "$ARCH" | tr '[:lower:]' '[:upper:]')
 # Conditionally create fdt information
 if [ -n "${DTB}" ]; then
FDT_NODE="
-   fdt@1 {
+   fdt@$FDTNUM {
description = \"${ARCH_UPPER} OpenWrt ${DEVICE} device 
tree blob\";
data = /incbin/(\"${DTB}\");
type = \"flat_dt\";
@@ -75,7 +79,7 @@ if [ -n "${DTB}" ]; then
};
};
 "
-   FDT_PROP="fdt = \"fdt@1\";"
+   FDT_PROP="fdt = \"fdt@$FDTNUM\";"
 fi
 
 # Create a default, fully populated DTS file
-- 
2.28.0


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


[RFC PATCH v1 8/8] bcm53xx: add Cisco Meraki MR32

2020-08-29 Thread Christian Lamparter
This patch adds support for Cisco Meraki MR32.
The unit was donated by Chris Blake. Thank you!

WARNING:
Only the 1x1:1 abgn Air Marshal WIPS wifi is currently supported by b43:
 b43-phy2: Found PHY: Analog 9, Type 4 (N), Revision 16
 b43-phy2: Found Radio: Manuf 0x17F, ID 0x2057, Revision 9, Version 1
 b43-phy2: Loading firmware version 784.2 (2012-08-15 21:35:19)
 and only as 802.11ABG!

while WIFI1 and WIFI2 (both BCM4352) are not:
 b43-phy0: Broadcom 4352 WLAN found (core revision 42)
 b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)

Hardware Highlights:

SoC:Broadcom BCM53016A1 (1 GHz, 2 cores)
RAM:128 MiB
NAND:   128 MiB Spansion S34ML01G2 (~114 MiB useable)
ETH:1GBit Ethernet Port - PoE
WIFI1:  Broadcom BCM43520 an+ac (2x2:2 - id: 0x4352)
WIFI2:  Broadcom BCM43520 bgn (2x2:2 - id: 0x4352)
WIFI3:  Broadcom BCM43428 abgn (1x1:1 - id: 43428)

BLE:Broadcom BCM20732 (ttyS1)
LEDS:   1 x Programmable RGB Status LED (driven by a PWM)
1 x White LED (GPIO)
1 x Orange LED Fault Indicator (GPIO)
2 x LAN Activity / Speed LEDs (On the RJ45 Port)
BUTTON: one Reset button
MISC:   AT24C64 8KiB EEPROM (i2c - stores Ethernet MAC + Serial#!)
ina219 hardware monitor (i2c)
Kensington Lock

SERIAL:
WARNING: The serial port needs a TTL/RS-232 3V3 level converter!
The Serial setting is 115200-8-N-1. The board has a populated
right angle 1x4 0.1" pinheader.
The pinout is: VCC, RX, TX, GND. (Use a multimeter)

Flashing needs a serial adaptor (due to the lack of a working dropbear on
the original firmware).

This flashing procedure for the MR32 was tested with firmware:
"r23-149867:150252-aacharya".

0. Create a seperate Ethernet LAN which does not have access to the internet.
   Ideally use 192.168.1.2 for your PC. Make sure to reserve 192.168.1.1 it
   will be used later on by the OpenWrt firmware. The original Meraki firmware
   will likely try to setup the network via DHCP Discovery, so make sure your
   PC is running a DHCP-Server (i.e.: dnsmasq)
   '# dnsmasq -i eth# -F 192.168.1.5,192.168.1.50
   Furthermore, the PC needs a supported ssh/http/ftp server in order to
   retrieve the initramfs + dtb file

1. Disassemble the MR32 device by removing all screws (4 screws are located
   under the 4 rubber feets!) and prying open the plastic covers without
   breaking the plastic retention clips. Once inside, remove all the screws
   on the outer metal shielding to get to the PCB. It's not necessary to
   remove the antennas!

2. Connect the serial cable to the serial header.

3. Partially reassemble the outer metal shielding to ensure that the SoC
   has a proper heat sink.

4. Connect the Ethernet patch cable to the device and the power cable.

5. Wait for the device to boot and enter the root shell.
   (rooting is not discussed in detail here please refer to
   Chris Blake - "pwning the meraki mr18" blog post:
   <https://servernetworktech.com/2016/02/pwning-the-meraki-mr18/>
   (The same method works with the MR32's r23-149867:150252-aacharya)

   Wait for the MR32 to enter the "" prompt and enter:
odm serial_num read
   (Verify that it matches what's on the S/N Sticker on the back!)
odm serial_num write Q2XX--XXXV
odm serial_num read
   (Verify that the S/N has changed - and the LED start to flash)

   now to flash the firmware:
odm firmware part.safe "http://192.168.1.2/mr32-initramfs.bin;

Once OpenWrt booted use sysupgrade to permanently install
OpenWrt. To do this: Download the latest sysupgrade.bin file
for the MR32 to the device and use sysupgrade *sysupgrade.bin
to install it.

WARNING: DO NOT DELETE the "storage" ubi volume!

To flash later MR32 Firmwares like r25-201804051805-G885d6d78-dhow-rel
requires in-circut-i2c tools to access the I2C EEPROM AT24C64 next to
the SoC. The idea is pretty much the same as from Step 5 from above:
Change the serial number to Q2XV (should be around 0x7c), then
attach a serial cable, ethernet (but make sure the device can't reach
the internet!) hit "s" (the small s!) during boot to enter the root-shell
and add the following commands to the /storage/config there:

serial_allow_odm true
serial_access_enabled true
serial_access_check false
valid_config true

and then hit exit to let it finish booting.

Signed-off-by: Christian Lamparter 
---
 .../bcm53xx/base-files/etc/board.d/02_network |   7 +-
 target/linux/bcm53xx/base-files/etc/diag.sh   |   3 +
 .../lib/preinit/07_set_preinit_iface_bcm53xx  |  16 +
 .../base-files/lib/upgrade/platform.sh|  36 ++-
 target/linux/bcm53xx/image/Makefile   |  26 ++
 ...-ARM-BCM5301X-Add-DT-for-Meraki-MR32.patch | 281 ++
 .../331-Meraki-MR32-Status-LEDs.patch |  28 ++
 7 files changed, 394 insertions(+), 3 deletions(-)
 create mode 100644 
target/linux/bcm53xx/base-files/lib/preinit/07_set_preinit_iface

[RFC PATCH v1 3/8] build: define PWM_SUPPORT arch feature flag

2020-08-29 Thread Christian Lamparter
As the PWM has its own sub-system in the Linux kernel,
I think it should be handled in the same way as GPIO, RTC, PCI...

This patch introduces a specific feature flag "pwm" and the
"leds-pwm" kernel module as the first customer.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/leds.mk | 16 
 scripts/target-metadata.pl   |  1 +
 target/Config.in |  3 +++
 3 files changed, 20 insertions(+)

diff --git a/package/kernel/linux/modules/leds.mk 
b/package/kernel/linux/modules/leds.mk
index 59ea6edbcd..4ef64fd907 100644
--- a/package/kernel/linux/modules/leds.mk
+++ b/package/kernel/linux/modules/leds.mk
@@ -145,3 +145,19 @@ define KernelPackage/leds-pca963x/description
 endef
 
 $(eval $(call KernelPackage,leds-pca963x))
+
+
+define KernelPackage/leds-pwm
+  SUBMENU:=$(LEDS_MENU)
+  TITLE:=PWM driven LED Support
+  KCONFIG:=CONFIG_LEDS_PWM
+  DEPENDS:= @PWM_SUPPORT
+  FILES:=$(LINUX_DIR)/drivers/leds/leds-pwm.ko
+  AUTOLOAD:=$(call AutoLoad,60,leds-pwm,1)
+endef
+
+define KernelPackage/leds-pwm/description
+ This option enables support for pwm driven LEDs
+endef
+
+$(eval $(call KernelPackage,leds-pwm))
diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index c58f096573..bf6413d315 100755
--- a/scripts/target-metadata.pl
+++ b/scripts/target-metadata.pl
@@ -20,6 +20,7 @@ sub target_config_features(@) {
/^usb$/ and $ret .= "\tselect USB_SUPPORT\n";
/^usbgadget$/ and $ret .= "\tselect USB_GADGET_SUPPORT\n";
/^pcmcia$/ and $ret .= "\tselect PCMCIA_SUPPORT\n";
+   /^pwm$/ and $ret .= "\select PWM_SUPPORT\n";
/^rtc$/ and $ret .= "\tselect RTC_SUPPORT\n";
/^squashfs$/ and $ret .= "\tselect USES_SQUASHFS\n";
/^jffs2$/ and $ret .= "\tselect USES_JFFS2\n";
diff --git a/target/Config.in b/target/Config.in
index 9fead5994f..43de4710df 100644
--- a/target/Config.in
+++ b/target/Config.in
@@ -29,6 +29,9 @@ config PCIE_SUPPORT
 config PCMCIA_SUPPORT
bool
 
+config PWM_SUPPORT
+   bool
+
 config USB_SUPPORT
select AUDIO_SUPPORT
bool
-- 
2.28.0


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


[RFC PATCH v1 6/8] kernel: add default for new config symbols

2020-08-29 Thread Christian Lamparter
Provide disabled defaults for I2C_SLAVE_EEPROM and IPMB_DEVICE_INTERFACE.

Signed-off-by: Christian Lamparter 
---
 target/linux/generic/config-5.4 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index 19bde7ed61..5612a7500f 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -2114,6 +2114,7 @@ CONFIG_HW_RANDOM_TPM=y
 # CONFIG_I2C_SIS630 is not set
 # CONFIG_I2C_SIS96X is not set
 # CONFIG_I2C_SLAVE is not set
+# CONFIG_I2C_SLAVE_EEPROM is not set
 # CONFIG_I2C_SMBUS is not set
 # CONFIG_I2C_STUB is not set
 # CONFIG_I2C_TAOS_EVM is not set
@@ -2374,6 +2375,7 @@ CONFIG_IO_STRICT_DEVMEM=y
 # CONFIG_IP6_NF_TARGET_SYNPROXY is not set
 # CONFIG_IPACK_BUS is not set
 # CONFIG_IPC_NS is not set
+# CONFIG_IPMB_DEVICE_INTERFACE is not set
 # CONFIG_IPMI_HANDLER is not set
 # CONFIG_IPV6 is not set
 # CONFIG_IPV6_FOU is not set
-- 
2.28.0


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


[RFC PATCH v1 5/8] bcm53xx: backport uart2 and pcie2 device-nodes

2020-08-29 Thread Christian Lamparter
These have made their way into -next.

Signed-off-by: Christian Lamparter 
---
 ...dts-BCM5301X-Specify-uart2-in-the-DT.patch | 37 +++
 ...dts-BCM5301X-Specify-pcie2-in-the-DT.patch | 33 +
 2 files changed, 70 insertions(+)
 create mode 100644 
target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
 create mode 100644 
target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch

diff --git 
a/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
new file mode 100644
index 00..1fec981146
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/034-v5.10-ARM-dts-BCM5301X-Specify-uart2-in-the-DT.patch
@@ -0,0 +1,37 @@
+From 95c1f0076303922ca401851b6605dc17eb0eb732 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Wed, 6 Jun 2018 21:57:15 +0200
+Subject: [PATCH 1/4] ARM: dts: BCM5301X: Specify uart2 in the DT
+
+The BCM53016 in the Meraki MR32 utilizes the third "uart2"
+to connect to a on-board Bluetooth-LE 4.0 BCM20732 chip.
+
+Signed-off-by: Christian Lamparter 
+Reviewed-by: Scott Branden 
+---
+ arch/arm/boot/dts/bcm5301x.dtsi | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
+index 45cd8c7411dd..eb1290fed235 100644
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -392,6 +392,15 @@ usb3_dmp: syscon@18105000 {
+   reg = <0x18105000 0x1000>;
+   };
+ 
++  uart2: serial@18008000 {
++  compatible = "ns16550a";
++  reg = <0x18008000 0x20>;
++  clocks = <>;
++  interrupts = ;
++  reg-shift = <2>;
++  status = "disabled";
++  };
++
+   i2c0: i2c@18009000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18009000 0x50>;
+-- 
+2.28.0
+
diff --git 
a/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
 
b/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
new file mode 100644
index 00..d4ec31c0ae
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-5.4/035-v5.10-ARM-dts-BCM5301X-Specify-pcie2-in-the-DT.patch
@@ -0,0 +1,33 @@
+From 5abb709b027a6234c135843764bad383be264162 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter 
+Date: Sun, 10 Jun 2018 17:17:53 +0200
+Subject: [PATCH 2/4] ARM: dts: BCM5301X: Specify pcie2 in the DT
+
+The SoC supports three pcie ports. Currently, only
+pcie0 and pcie1 are enabled. This patch adds the
+pcie2 port as well.
+
+Signed-off-by: Christian Lamparter 
+Reviewed-by: Scott Branden 
+---
+ arch/arm/boot/dts/bcm5301x.dtsi | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
+index eb1290fed235..9d9e8fe3f6ae 100644
+--- a/arch/arm/boot/dts/bcm5301x.dtsi
 b/arch/arm/boot/dts/bcm5301x.dtsi
+@@ -252,6 +252,10 @@ pcie1: pcie@13000 {
+   reg = <0x00013000 0x1000>;
+   };
+ 
++  pcie2: pcie@14000 {
++  reg = <0x00014000 0x1000>;
++  };
++
+   usb2: usb2@21000 {
+   reg = <0x00021000 0x1000>;
+ 
+-- 
+2.28.0
+
-- 
2.28.0


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


Re: [OpenWrt-Devel] [PATCH] apm821xx: move device definitions to subfiles

2020-06-09 Thread Christian Lamparter

On 2020-06-07 13:13, Adrian Schmutzler wrote:

With several subtargets, the image/Makefile becomes crowded after a
while. Many targets have moved their device definitions to $subtarget.mk
files to have them more organized, let's do this here as well.

While at it, also move subtarget-specific build recipes.

Cc: Christian Lamparter 
Signed-off-by: Adrian Schmutzler 


I guess this is meant in the big picture of the series.
Sure, if this scratches the itch.

Acked-by: Christian Lamparter 

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


Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread Christian Lamparter
On Friday, 29 May 2020 22:32:10 CEST m...@adrianschmutzler.de wrote:
> > > > Or am I completely misled here?
> > >
> > > I believe you are right, it seems DEVICE_TYPE is not evaluated when
> > > set in a device definition.
> > True, question is then, should this really be called "DEVICE"_TYPE?
> > It's not like other DEVICE_* variables (DEVICE_NAME, DEVICE_PACKAGES or
> > DEVICE_DTS).
> > Because the "targets" of ath79/ipq40xx/etc... wouldn't work if they all had 
> > to
> > share a single, common DEVICE_NAME/_DTS/_PACKAGE.
> > 
> > As for the MBLs, if I got this all correctly, that DEVICE_TYPE could be 
> > simply
> > moved to the apm821xx/sata target.mk
> > ---
> > --- a/target/linux/apm821xx/image/Makefile
> > +++ b/target/linux/apm821xx/image/Makefile
> > @@ -251,7 +251,6 @@ define Device/wd_mybooklive
> >DEVICE_VENDOR := Western Digital
> >DEVICE_MODEL := My Book Live Series (Single + Duo)
> >DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-
> > usb-storage kmod-fs-vfat wpad-basic
> > -  DEVICE_TYPE := nas
> >DEVICE_DTS := wd-mybooklive
> >SUPPORTED_DEVICES += mbl wd,mybooklive-duo
> >BLOCKSIZE := 1k
> > --- a/target/linux/apm821xx/sata/target.mk
> > +++ b/target/linux/apm821xx/sata/target.mk
> > @@ -1,5 +1,6 @@
> >  BOARDNAME := Devices which boot from SATA (NAS)  FEATURES += ext4
> > usb ramdisk squashfs rootfs-part boot-part
> > +DEVICE_TYPE := nas
> >  DEFAULT_PACKAGES += badblocks block-mount e2fsprogs kmod-hwmon-
> > drivetemp \
> > kmod-dm kmod-md-mod partx-utils mkf2fs f2fsck
> > 
> > ---
> > And it would work as expected, right?
> > 
> > Cheers,
> > Christian
> > 
> 
> Yes, in this case this would work as expected after change. Of course, this 
> assumes that future additions to the subtarget would be "NAS-devices" as well.
> 
> > True, question is then, should this really be called "DEVICE"_TYPE?
> 
> That's exactly the question we are discussing in 3/3 of this series which 
> went to the openwrt-devel, I only Cc-ed you for the 1/3.

Ah ok, that might explain more than you think. I got hit by a bug interaction
with debian's cyrus-imap in my mail setup: Well, thankfully it's fixed now:
. I know that I
got sliently dropped from various MLs, since the mailsystem generated a ton
of bounces all at once. Sorry!

> I personally tend towards dropping DEVICE_TYPE entirely and separate the
> selection of different subsets for DEFAULT_PACKAGES from providing a config
> option for packages like busybox.

Ok, I guess it's time to say farewell to DEVICE_TYPE then...

The nice thing about DEVICE_TYPE was that it automatically included
a bunch of generally useful packages. On the other hand, if these would all
become default, then there will be more "-$package" showing up in
DEVICE_PACKAGES variables and possibly heated commit wars about whenever a
package should be included or dropped (but that's already happening right
now too).

I liked the idea of the DEVICE_TYPE variable though. But yes, it doesn't
really work the way its named. For this to have any merrit, DEVICE_TYPE
would need to stop meddling with DEFAULT_PACKAGES and add the selected
packages with something like a second "DEVICE_PACKAGES"... and hope that
TARGET_PER_DEVICE_ROOTFS can enforce the barriers between the devices
(well, sadly it can't do that 100%).

Cheers,
Christian



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


Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread Christian Lamparter
On Friday, 29 May 2020 21:32:59 CEST Matthias Schiffer wrote:
> On 5/29/20 7:45 PM, m...@adrianschmutzler.de wrote:
> >>> Consequently, having it set anyway is misleading, so this drops all
> >>> cases.
> >>
> >> Well, I can tell you where it matters for devices.
> >>
> >> You'll have to look at this:
> >>
> >>  >> mk;h=9bd4c14936c1438df2be87e5697f5f5568699d2b;hb=HEAD#l54>
> >>
> >> |# Add device specific packages (here below to allow device type set
> >> |from subtarget) DEFAULT_PACKAGES +=
> >> $(DEFAULT_PACKAGES.$(DEVICE_TYPE))
> >>
> >> So, the MBL gets "DEFAULT_PACKAGES.nas" (block-mount fdisk lsblk
> >> mdadm) over "DEFAULT_PACKAGES.router" (dnsmasq iptables ip6tables ppp
> >> ppp-mod-pppoe firewall odhcpd-ipv6only odhcp6c kmod-ipt-offload) which
> >> makes much more sense for other devices as well.
> > 
> > Hi Christian,
> > 
> > that's exactly my point. Since this is target.mk as far as I can tell this 
> > selection does not work when DEVICE_TYPE is set within the device 
> > definition, but only when it's set in the (sub)target Makefile. As I 
> > understand it (and tested with make menuconfig), DEFAULT_PACKAGES is a 
> > per-target variable, and thus the DEVICE_TYPE from within the device 
> > definition will never be applied, and DEFAULT_PACKAGES.router will be used 
> > anyway for these devices.
> > 
> > Or am I completely misled here?
> 
> I believe you are right, it seems DEVICE_TYPE is not evaluated when set in
> a device definition.
True, question is then, should this really be called "DEVICE"_TYPE?
It's not like other DEVICE_* variables (DEVICE_NAME, DEVICE_PACKAGES or 
DEVICE_DTS).
Because the "targets" of ath79/ipq40xx/etc... wouldn't work if they all had to 
share
a single, common DEVICE_NAME/_DTS/_PACKAGE.

As for the MBLs, if I got this all correctly, that DEVICE_TYPE could be simply 
moved
to the apm821xx/sata target.mk
---
--- a/target/linux/apm821xx/image/Makefile
+++ b/target/linux/apm821xx/image/Makefile
@@ -251,7 +251,6 @@ define Device/wd_mybooklive
   DEVICE_VENDOR := Western Digital
   DEVICE_MODEL := My Book Live Series (Single + Duo)
   DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage 
kmod-fs-vfat wpad-basic
-  DEVICE_TYPE := nas
   DEVICE_DTS := wd-mybooklive
   SUPPORTED_DEVICES += mbl wd,mybooklive-duo
   BLOCKSIZE := 1k
--- a/target/linux/apm821xx/sata/target.mk
+++ b/target/linux/apm821xx/sata/target.mk
@@ -1,5 +1,6 @@
 BOARDNAME := Devices which boot from SATA (NAS)
 FEATURES += ext4 usb ramdisk squashfs rootfs-part boot-part
+DEVICE_TYPE := nas
 DEFAULT_PACKAGES += badblocks block-mount e2fsprogs kmod-hwmon-drivetemp \
kmod-dm kmod-md-mod partx-utils mkf2fs f2fsck
 
---
And it would work as expected, right?

Cheers,
Christian



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


Re: [OpenWrt-Devel] [PATCH 1/3] treewide: drop DEVICE_TYPE when used as device variable

2020-05-29 Thread Christian Lamparter
On Friday, 29 May 2020 19:22:36 CEST Adrian Schmutzler wrote:
> DEVICE_TYPE is a target/subtarget variable, and it does not have
> any effect when set in a device definition. It can only be set
> in a target's or subtarget's Makefile.
> 
> Consequently, having it set anyway is misleading, so this drops
> all cases.

Well, I can tell you where it matters for devices.

You'll have to look at this:



|# Add device specific packages (here below to allow device type set from 
subtarget)
|DEFAULT_PACKAGES += $(DEFAULT_PACKAGES.$(DEVICE_TYPE))

So, the MBL gets "DEFAULT_PACKAGES.nas" (block-mount fdisk lsblk mdadm) over
"DEFAULT_PACKAGES.router" (dnsmasq iptables ip6tables ppp ppp-mod-pppoe 
firewall odhcpd-ipv6only odhcp6c kmod-ipt-offload)
which makes much more sense for other devices as well.

If you want to revert these changes and make this transparent,
you'll probably want to amend each device package list
with the appropriate -package (i.e -ppp -firewall -dnsmasq ...)
all around.

Cheers,
Christian 




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


Re: [OpenWrt-Devel] [PATCH] mvebu, tegra: make CPU subtype default to vfp3-d16

2020-04-01 Thread Christian Lamparter
On Wednesday, 1 April 2020 15:17:31 CEST Tomasz Maciej Nowak wrote:
> W dniu 31.03.2020 o 11:21, Petr Štetiar pisze:
> > Armada 370 and Tegra2 processors have only 16 double-precision
> > registers. The change introduced by commit 8dcc1087602e ("toolchain:
> > ARM: Fix toolchain compilation for gcc 8.x") switched accidentally the
> > toolchain for mvebu cortexa9 subtarget to cpu type with 32
> > double-precision registers.
> > 
> > This stems from gcc defaults which assume "vfpv3-d32" if only "vfpv3" as
> > mfpu is specified. That change resulted in unusable image, in which
> > kernel will kill userspace as soon as it causing "Illegal instruction".
> > 
> > In order to fix those issues Tomas in commit 2d61f8821c7c ("mvebu:
> > cortexa9: correct cpu subtype") and commit 43d1d8851062 ("tegra: correct
> > cpu subtype") changed the CPU subtype to explicit vfpv3-d16 which fixed
> > the above mentioned issue, but on the other end it has resulted in the
> > need of building packages for this new CPU subtype which is not wanted
> > due to the increased infrastructure costs, like disk space and
> > additional build time which is huge for packages feed.
> > 
> > So lets just take a step back and make the vfp3-d16 explicit again.
[...]
> > ---
> >  include/target.mk | 3 +++
> >  target/linux/mvebu/cortexa9/target.mk | 2 +-
> >  target/linux/tegra/Makefile   | 2 +-
> >  3 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/target.mk b/include/target.mk
> > index 9bd4c14936c1..94ea1a9e0001 100644
> > --- a/include/target.mk
> > +++ b/include/target.mk
> > @@ -179,6 +179,9 @@ ifeq ($(DUMP),1)
> >endif
> >ifneq ($(findstring arm,$(ARCH)),)
> >  CPU_TYPE ?= xscale
> > +ifeq ($(CONFIG_SOFT_FLOAT),)
> > +  CPU_CFLAGS_vfpv3 = -mfpu=vfpv3-d16
> > +endif

The question I'm pondering is: Do you really want to maintain this specifc maps
for this (only this arch) or not? Because I do think this will creep up sooner 
or
later again. So we could also defuse this a bit by replacing that monicer 
"vfpv3"
(as this is a gcc/binutils thing and not under our control) with something 
"clearly from OpenWrt". like CPU_CFLAGS_fpu = -mfpu=vfpv3-d16 (if that doesn't
clash with something else).

But then again, I'm not here to tell you what to do. If you want your patch 
as-is
then go for it! :D

Cheers,
Christian




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


Re: [OpenWrt-Devel] [PATCH 1/3] gemini: Add v5.4 kernel patches

2020-03-21 Thread Christian Lamparter
On Saturday, 21 March 2020 14:05:53 CET Linus Walleij wrote:
> This adds the kernel patches needed for the Gemini.
> Just 7 patches, 5 of them are already upstream.
> 
> Notably we backport the patches to use the temperature
> sensor on the hard drive to drive temperature control
> of the NAS chassis. This is required for the DIR-685
> which has no external temperature sensor.
> 

I've made a RFC with a package for the drivetemp previously.



would this work as well?

Cheers,
Christian



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


[OpenWrt-Devel] [RFC PATCH] kernel: backport and package drivetemp hwmon from v5.5

2020-02-29 Thread Christian Lamparter
This patch backports the hwmon drivetemp sensor module from vanilla
linux 5.5 to be available on OpenWrt's 5.4 kernel.

Extract from The upstream commit by Guenter Roeck :
hwmon: Driver for disk and solid state drives with temperature sensors

"Reading the temperature of ATA drives has been supported for years
by userspace tools such as smarttools or hddtemp. The downside of
such tools is that they need to run with super-user privilege, that
the temperatures are not reported by standard tools such as 'sensors'
or 'libsensors', and that drive temperatures are not available for use
in the kernel's thermal subsystem.

This driver solves this problem by adding support for reading the
temperature of ATA drives from the kernel using the hwmon API and
by adding a temperature zone for each drive.

With this driver, the hard disk temperature can be read [...]
using sysfs:

$ grep . /sys/class/hwmon/hwmon9/{name,temp1_input}
/sys/class/hwmon/hwmon9/name:drivetemp
/sys/class/hwmon/hwmon9/temp1_input:23000

If the drive supports SCT transport and reports temperature limits,
those are reported as well.

drivetemp-scsi-0-0
Adapter: SCSI adapter
temp1:+27.0C (low  =  +0.0C, high = +60.0C)
 (crit low = -41.0C, crit = +85.0C)
 (lowest = +23.0C, highest = +34.0C)

The driver attempts to use SCT Command Transport to read the drive
temperature. If the SCT Command Transport feature set is not available,
or if it does not report the drive temperature, drive temperatures may
be readable through SMART attributes. Since SMART attributes are not well
defined, this method is only used as fallback mechanism."

Signed-off-by: Christian Lamparter 
---

My motivation for packaging this module comes from making the
WNDR4700 to behave as close to what the Netgear's firmware does.
The fan should kick in when the drive gets hot and for this to
work, the cooling zones need to have a proper sensor that has
the temperature of the HDD to properly control the cooling device.
---
 package/kernel/linux/modules/hwmon.mk |  15 +
 ...sfs-attributes-for-VPD-pages-0h-and-.patch | 122 +++
 ...-disk-and-solid-state-drives-with-te.patch | 737 ++
 3 files changed, 874 insertions(+)
 create mode 100644 
target/linux/generic/backport-5.4/800-v5.5-scsi-core-Add-sysfs-attributes-for-VPD-pages-0h-and-.patch
 create mode 100644 
target/linux/generic/backport-5.4/801-v5.5-hwmon-Driver-for-disk-and-solid-state-drives-with-te.patch

diff --git a/package/kernel/linux/modules/hwmon.mk 
b/package/kernel/linux/modules/hwmon.mk
index c0a477856e..ed0ee44241 100644
--- a/package/kernel/linux/modules/hwmon.mk
+++ b/package/kernel/linux/modules/hwmon.mk
@@ -77,6 +77,21 @@ endef
 $(eval $(call KernelPackage,hwmon-adt7475))
 
 
+define KernelPackage/hwmon-drivetemp
+  TITLE:=Hard disk drives with temperature sensor
+  KCONFIG:=CONFIG_SENSORS_DRIVETEMP
+  FILES:=$(LINUX_DIR)/drivers/hwmon/drivetemp.ko
+  AUTOLOAD:=$(call AutoLoad,60,drivetemp)
+  $(call AddDepends/hwmon,+kmod-ata-core +kmod-scsi-core)
+endef
+
+define KernelPackage/hwmon-drivetemp/description
+ Kernel module for Hard disk drives with temperature sensor
+endef
+
+$(eval $(call KernelPackage,hwmon-drivetemp))
+
+
 define KernelPackage/hwmon-gpiofan
   TITLE:=Generic GPIO FAN support
   KCONFIG:=CONFIG_SENSORS_GPIO_FAN
diff --git 
a/target/linux/generic/backport-5.4/800-v5.5-scsi-core-Add-sysfs-attributes-for-VPD-pages-0h-and-.patch
 
b/target/linux/generic/backport-5.4/800-v5.5-scsi-core-Add-sysfs-attributes-for-VPD-pages-0h-and-.patch
new file mode 100644
index 00..dc89b279e5
--- /dev/null
+++ 
b/target/linux/generic/backport-5.4/800-v5.5-scsi-core-Add-sysfs-attributes-for-VPD-pages-0h-and-.patch
@@ -0,0 +1,122 @@
+From d188b0675b21d5a6ca27b3e741381813983f4719 Mon Sep 17 00:00:00 2001
+From: Ryan Attard 
+Date: Thu, 26 Sep 2019 11:22:17 -0500
+Subject: [PATCH] scsi: core: Add sysfs attributes for VPD pages 0h and 89h
+
+Add sysfs attributes for the ATA information page and Supported VPD Pages
+page.
+
+Link: 
https://lore.kernel.org/r/20190926162216.56591-1-ryanatt...@ryanattard.info
+Signed-off-by: Ryan Attard 
+Reviewed-by: Bart Van Assche 
+Signed-off-by: Martin K. Petersen 
+---
+ drivers/scsi/scsi.c|  4 
+ drivers/scsi/scsi_sysfs.c  | 19 +++
+ include/scsi/scsi_device.h |  2 ++
+ 3 files changed, 25 insertions(+)
+
+--- a/drivers/scsi/scsi.c
 b/drivers/scsi/scsi.c
+@@ -465,10 +465,14 @@ void scsi_attach_vpd(struct scsi_device
+   return;
+ 
+   for (i = 4; i < vpd_buf->len; i++) {
++  if (vpd_buf->data[i] == 0x0)
++  scsi_update_vpd_page(sdev, 0x0, >vpd_pg0);
+   if (vpd_buf->data[i] == 0x80)
+   scsi_update_vpd_page(sdev, 0x80, >vpd_pg80);
+   if (vpd_buf->data[i] == 0x83)
+   scsi_update_vpd_page(sdev, 0x83, >vpd_pg83);
++

Re: [OpenWrt-Devel] [PATCH 2/2] generic at803x: remove unneeded patches

2020-01-21 Thread Christian Lamparter
Hello,

On Tue, Jan 21, 2020 at 9:11 PM David Bauer  wrote:
>
>  - Remove the "RGMII TX delay fixup" hack and the associated
>DT-property. It was never used in a DT-based platform and
>solved a problem which can be mitigated by using correct
>delays on the MAC side.
>
Can you tell us more about what are these correct
delay bits and where do I have to set them? :-D

Acked-by: Christian Lamparter 

Cheers,
Christian

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


Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-16 Thread Christian Lamparter
Hello,

On Mon, Dec 16, 2019 at 12:27 PM Alberto Bursi
 wrote:
>
>
> On 15/12/19 14:09, Christian Lamparter wrote:
> >
> > But it seems that Ben had a change of heart in this regard. I don't know the
> > details or why, But it makes sense because it would enable his company to 
> > save
> > some money for the systems his company sells:
> >   <https://www.candelatech.com/lf_systems.php> so there is some value
> > in supporting these devices, especially if someone else does all the work
> > for it.
>
> These are wifi/network testing equipment, not network devices.
>
> Also I don't see the value in "saving some money" by using a bit less RAM
>
> when the cheaper system is sold for 3k, and most stuff is above 10k.
>
> You could use standard whitebox x86 stuff at that price point.

I'm glad this is getting some attention and others are chiming in. But
let me tell
you first, that I'm not an opponent of the "American way", I'm trying
to make sense
of it though and also what would happen to the ath10k GPIO patches that got
quietly dropped from your reply there...

As for the "These are wifi/network testing equipment, not network devices."
True and If you are interested you can buy cheaper devices like
<https://www.candelatech.com/ct314_product.php> from the company as well:

"The CT314 is a low-power and affordable applicance with a single 10/100
Ethernet port and one Broadcome 802.11b/g/n Wireless interface. It is targeted
at users who wish to have an inexpensive appliance that can be left at remote
sites for network monitoring and lower speed testing. The maximum throughput
is about 90Mbps bi-directional wired. Wireless throughput is steady at 38Mbps
and can peak at 48Mpbs. The CT314 is based on the Raspberry PI B version 3
platform, running the Ubuntu Server OS. [...]".

I know these have not much to do with the issue at hand ("low-memory system"
support in ath10k(-ct) with OpenWrt). But as Ben explained in the follow-up that
he has a keen interest for supporting the ath10k-ct driver+firmware
and he's doing
a great job with the ath10k-ct issue tracker.

Cheers,
Christian

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


Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-15 Thread Christian Lamparter
On Sunday, 15 December 2019 13:01:14 CET Paul Fertser wrote:
> Thank you for the answer Christian,
> 
> On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote:
> > I think for this to have any chance of moving forward you'll need to
> > pressure your ODMs and if that doesn't work: Go with a different WIFI
> > chip vendor that supports low memory devices, or add more RAM.
> > From what I can tell, Qualcomm nowadays gets what they want "for free"
> > and for the past four-five years, they certainly didn't feel pressured
> > to add "low memory" support to ath10k.
> 
> FWIW, OpenWrt's ath10k vendor is CT now, not QCA, so it's not much
> relevant what do ODMs and (whatever is left from) QCA say, I guess.
Well, not sure what you are trying to say here. But I think Ben is free
to do what he wants as well. For example see the:
"ath10k: add LED and GPIO controlling support for various chipsets"
patch that OpenWrt has been carrying because neither upstream (linux-wireless)
nor CT wants to integrate it.
<https://github.com/openwrt/openwrt/blob/master/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch>

The situation with the "low memory" support wasn't much better. Because
from what I remember, there was a discussion about this very topic between
Ben an Hauke in the past (and you can see how it played out, since you wouldn't
have posted this series if it was integrated back then). 
But it seems that Ben had a change of heart in this regard. I don't know the
details or why, But it makes sense because it would enable his company to save
some money for the systems his company sells:
 <https://www.candelatech.com/lf_systems.php> so there is some value
in supporting these devices, especially if someone else does all the work 
for it.

> It would be kind of weird to force OpenWrt users of certain devices to
> downgrade to upstream ath10k (or to abandon hardware that is working
> fine for them with previous OpenWrt release) just because Atheros no
> longer exist and Qualcomm can't care less about free software
> community, don't you think so?
This is something like "another" 32/4 situation, right? Well, can you tell
me what was the result of that?

> I'll try to find the mailing list posts you're talking about to help
> Ben decide if he is still OK with those patches getting used on
> low-RAM devices in OpenWrt or not.
Well, if you look at ath10k-ct (<https://github.com/greearb/ath10k-ct>),
you see that Ben takes upstream ath10k, adds his patches and pulls upstream
fixes. So if you are willing to work for it anyways, you might as well go
with upstream Linux-wireless and see what they want. After all the QSDK has
the "Low Memory" mode.

Cheers,
Christian



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


Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-15 Thread Christian Lamparter
On Wednesday, 11 December 2019 20:16:52 CET Paul Fertser wrote:
> Hey Ben,
> 
> On Wed, Dec 11, 2019 at 10:06:26AM -0800, Ben Greear wrote:
> > On 12/11/19 6:44 AM, Paul Fertser wrote:
> > > According to many bugreports [0][1][2] the default ath10k-ct kernel
> ...
> > And also if you want to just have the makefile pass a -DBUILD_ATH10K_SMALL 
> > or something
> > like that and #ifdef code in the ath10k-ct driver, then I'd apply that 
> > patch to ath10k-ct
> > so that you don't need the patches.
> 
> I am offering my patch to the OpenWrt maintainers as kind of a
> stop-gap measure to get ath10k-ct working for the release (or in any
> way they think is appropriate). Another approach they can choose is to
> select the upstream ath10k for those devices. Otherwise some
> previously supported boards will require manual intervention to get
> WiFi working after an upgrade.
> 
> Regarding your fwcfg idea, I am not sure it will work as it seems the
> PCI initialisation is happening before fwcfg is parsed and applied.
> 
> Adding a Kconfig option is another possibility.
> 
> But what do you think about an additional module parameter, wouldn't
> it be the cleanest solution in the long run?
> 
> BTW, according to the git logs the patches were initially added by
> Christian Lamparter, so I hope he can clarify the situation a
> bit. Probably there were some performance tests executed back than to
> measure the impact.
> 
Heh no. These patches come up in discussions time and time again. And I
would rather see them being removed alltogether. What I can tell you is
that the Idea of limiting ath10k memory thirst came from Qualcomm itself.

If you look on the ML you can find the old posts like:
<https://www.mail-archive.com/lede-dev@lists.infradead.org/msg04738.html>

And for reference: Here's a independent bootlog (from pepe2k/Piotr Dymacz
no less) with the "Low Memory System" messages for the RT-AC58U:
<https://gist.github.com/pepe2k/eba2766f05ccf4e089347c531c49848b>

>From what I remember Sven Eckelmann also measured the impact from the
patches on the performance and posted his results to the OpenWrt ML
(google will find them).

I think for this to have any chance of moving forward you'll need to
pressure your ODMs and if that doesn't work: Go with a different WIFI
chip vendor that supports low memory devices, or add more RAM.
>From what I can tell, Qualcomm nowadays gets what they want "for free"
and for the past four-five years, they certainly didn't feel pressured
to add "low memory" support to ath10k.

Cheers,
Christian



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


Re: [OpenWrt-Devel] [PATCH] mac80211: switch to upstream owl-loader driver

2019-11-22 Thread Christian Lamparter
On Monday, 18 November 2019 00:34:01 CET Hauke Mehrtens wrote:
> > +--- a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> >  b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> > +@@ -84,6 +84,10 @@
> > +   val = swahb32(val);
> > +   }
> > + 
> > ++#ifdef CONFIG_LANTIQ
> > ++  val = swab32(val);
> > ++#endif
> 
> Lantiq is big endian, are there other big endian system which do not
> need this byte swap?

>From what I vaguely remember (I know that Mathias explained it to me once.),
that special hack was necessary due to Lantiq's pci(e?)-host silicon doing
byteswaps just for 32-bit writes. The only other system that uses the owl-loader
is ath79/ar71xx. This is a big-endian MIPS as well that didn't need the swap.

(That said, I don't remember what was the reason for going with __raw_writel
rather than "iowrite32" though. At least ath9k is using it for the pci access
just fine everywhere.)

Anyone fancy checking out lantiq and ath79 devices with a AR92XX without the
swap above and the __raw_writel replaced by iowrite32?
 
> > ++
> > +   __raw_writel(val, mem + reg);
> > +   usleep_range(100, 120);
> > +   } 

Regards,
Christian



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


[OpenWrt-Devel] [PATCH] mac80211: switch to upstream owl-loader driver

2019-11-16 Thread Christian Lamparter
The Owl Loader (named after the codename that Atheros gave
these devices back in the day) has been accepted upstream.

This patch removes the "misc" driver OpenWrt had and adds
the remaining differences against the version that ships
with 5.4-rc1 into a separate "120-owl-loader-compat.patch"
file that can be cut down once AR71XX is being dealt with.

Note: I decided to keep the existing (kmod-)owl-loader
package name around for now. The kernel module file in
the kmod package will be called ath9k_pci_owl_loader.ko
though.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/wireless.mk  |  21 --
 package/kernel/mac80211/ath.mk|  20 +-
 .../patches/ath/120-owl-loader-compat.patch   |  67 +
 .../generic/files/drivers/misc/owl-loader.c   | 246 --
 .../hack-4.14/835-misc-owl_loader.patch   |  52 
 .../hack-4.19/835-misc-owl_loader.patch   |  52 
 .../hack-4.9/835-misc-owl_loader.patch|  52 
 7 files changed, 86 insertions(+), 424 deletions(-)
 create mode 100644 
package/kernel/mac80211/patches/ath/120-owl-loader-compat.patch
 delete mode 100644 target/linux/generic/files/drivers/misc/owl-loader.c
 delete mode 100644 target/linux/generic/hack-4.14/835-misc-owl_loader.patch
 delete mode 100644 target/linux/generic/hack-4.19/835-misc-owl_loader.patch
 delete mode 100644 target/linux/generic/hack-4.9/835-misc-owl_loader.patch

diff --git a/package/kernel/linux/modules/wireless.mk 
b/package/kernel/linux/modules/wireless.mk
index 7b1c663567..72e2bf477b 100644
--- a/package/kernel/linux/modules/wireless.mk
+++ b/package/kernel/linux/modules/wireless.mk
@@ -41,24 +41,3 @@ define KernelPackage/net-rtl8192su/description
 endef
 
 $(eval $(call KernelPackage,net-rtl8192su))
-
-
-define KernelPackage/owl-loader
-  SUBMENU:=$(WIRELESS_MENU)
-  TITLE:=Owl loader for initializing Atheros PCI(e) Wifi chips
-  DEPENDS:=@PCI_SUPPORT
-  KCONFIG:=CONFIG_OWL_LOADER
-  FILES:=$(LINUX_DIR)/drivers/misc/owl-loader.ko
-  AUTOLOAD:=$(call AutoProbe,owl-loader)
-endef
-
-define KernelPackage/owl-loader/description
-  Kernel module that helps to initialize certain Qualcomm
-  Atheros' PCI(e) Wifi chips, which have the init data
-  (which contains the PCI device ID for example) stored
-  together with the calibration data in the file system.
-
-  This is necessary for devices like the Cisco Meraki Z1.
-endef
-
-$(eval $(call KernelPackage,owl-loader))
diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk
index 64aac41b4d..788131b751 100644
--- a/package/kernel/mac80211/ath.mk
+++ b/package/kernel/mac80211/ath.mk
@@ -1,6 +1,6 @@
 PKG_DRIVERS += \
ath ath5k ath6kl ath6kl-sdio ath6kl-usb ath9k ath9k-common ath9k-htc 
ath10k \
-   carl9170
+   carl9170 owl-loader
 
 PKG_CONFIG_DEPENDS += \
CONFIG_PACKAGE_ATH_DEBUG \
@@ -38,6 +38,7 @@ config-$(CONFIG_PACKAGE_ATH_SPECTRAL) += 
ATH9K_COMMON_SPECTRAL ATH10K_SPECTRAL
 config-$(CONFIG_PACKAGE_ATH_DYNACK) += ATH9K_DYNACK
 config-$(call config_package,ath9k) += ATH9K
 config-$(call config_package,ath9k-common) += ATH9K_COMMON
+config-$(call config_package,owl-loader) += ATH9K_PCI_NO_EEPROM
 config-$(CONFIG_TARGET_ar71xx) += ATH9K_AHB
 config-$(CONFIG_TARGET_ath79) += ATH9K_AHB
 config-$(CONFIG_TARGET_ipq40xx) += ATH10K_AHB
@@ -274,3 +275,20 @@ define KernelPackage/carl9170
   FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/carl9170/carl9170.ko
   AUTOLOAD:=$(call AutoProbe,carl9170)
 endef
+
+define KernelPackage/owl-loader
+  $(call KernelPackage/mac80211/Default)
+  TITLE:=Owl loader for initializing Atheros PCI(e) Wifi chips
+  DEPENDS:=@PCI_SUPPORT +kmod-ath9k
+  
FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.ko
+  AUTOLOAD:=$(call AutoProbe,ath9k_pci_owl_loader)
+endef
+
+define KernelPackage/owl-loader/description
+  Kernel module that helps to initialize certain Qualcomm
+  Atheros' PCI(e) Wifi chips, which have the init data
+  (which contains the PCI device ID for example) stored
+  together with the calibration data in the file system.
+
+  This is necessary for devices like the Cisco Meraki Z1.
+endef
diff --git a/package/kernel/mac80211/patches/ath/120-owl-loader-compat.patch 
b/package/kernel/mac80211/patches/ath/120-owl-loader-compat.patch
new file mode 100644
index 00..256fca45e4
--- /dev/null
+++ b/package/kernel/mac80211/patches/ath/120-owl-loader-compat.patch
@@ -0,0 +1,67 @@
+From: Christian Lamparter 
+Date: Sat, 16 Nov 2019 19:25:24 +0100
+Subject: [PATCH] owl_loader: compatibility patch
+
+This patch includes OpenWrt specific changes that are
+not included in the upstream owl-loader.
+
+These include:
+   - A Byteswap fix for lantiq's PCI code
+
+   - platform data handling for ar71xx
+
+Signed-off-by: Christian Lamparter 
+
+--- a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
 b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
+@@ -84,6 +84,10 @@
+  

Re: [OpenWrt-Devel] [PATCH] ipq40xx: fritz4040 depends on uboot-fritz4040

2019-11-09 Thread Christian Lamparter
On Saturday, 9 November 2019 23:52:17 CET Sven Roederer wrote:
> The "append-uboot" macro is looking for the file 
> "$(STAGING_DIR_IMAGE)/uboot-fritz4040.bin"
> which is provided by the u-boot-fritz4040 package. If this is not build, 
> image creation
> will fail with "file not found".

The FRITZ!Box 4040 is a special case as the "eva.bin" image file needs the
u-boot binary to work as intended.

In OpenWrt's u-boot.mk, the u-boots for a target are usually get built/enabled
because 
adds something like this to the u-boot packages:
|Default: y if (TARGET_ipq40xx_generic_Default || 
TARGET_ipq40xx_generic_DEVICE_avm_fritzbox-4040 || 
TARGET_DEVICE_ipq40xx_generic_DEVICE_avm_fritzbox-4040)

This causes the needed u-boot package to be included automatically.
Unless the package is either deselected actively, or accidentally.
(This can happen when a existing .config in which the device was
previously disabled, is grandfathered in. Because the existing
"not set" will take preference [the diffconfig.pl will catch this]).

Technically, the eva.bin isn't necessary. It allows for an easier
installation, but nobody apart from the 4040 uses the append-uboot
and there have been issues in the past with this as well.

Question is: should we add that dependency, ditch the eva.bin image
(or make it so that it's optional - this requires some changes to
the builtsystem) or decide that "this is a bug elsewhere"?

Cheers,
Christian
> ---
>  target/linux/ipq40xx/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/ipq40xx/image/Makefile 
> b/target/linux/ipq40xx/image/Makefile
> index a9c5e625af..7ae6f36baa 100644
> --- a/target/linux/ipq40xx/image/Makefile
> +++ b/target/linux/ipq40xx/image/Makefile
> @@ -130,7 +130,7 @@ define Device/avm_fritzbox-4040
>   IMAGES = eva.bin sysupgrade.bin
>   IMAGE/eva.bin := append-uboot | pad-to (UBOOT_PARTITION_SIZE) | 
> append-kernel | append-rootfs | pad-rootfs
>   IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | 
> append-metadata
> - DEVICE_PACKAGES := fritz-tffs fritz-caldata
> + DEVICE_PACKAGES := fritz-tffs fritz-caldata u-boot-fritz4040



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


Re: [OpenWrt-Devel] [PATCH] ipq40xx: essedma: Fix dead lock

2019-10-20 Thread Christian Lamparter
On Sunday, October 20, 2019 11:39:41 AM CEST John Crispin wrote:
> On 01/10/2019 11:59, Masafumi UTSUGI wrote:
> > edma_read_append_stats() is called from kernel timer
> > (Bottom half context) but it used spin_lock() to take a lock.
> > Using ethtool command rarely causes deadlock because of this.
> > Change lock function to spin_lock_bh() to avoid this.
> > 
> 
> Hi,
> patch looks good, could you please rebase it for v4.19 and merge the fix 
> directly into the essedma patch ?

Oh, I've already done that yesterday?

https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=3e8fc768f78c6b7f7025dd15264d113da9ad81b2




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


Re: [OpenWrt-Devel] [PATCH] ipq40xx: add label MAC address for FritzBox 4040

2019-09-28 Thread Christian Lamparter
On Monday, September 23, 2019 4:31:38 PM CEST Adrian Schmutzler wrote:
> This adds label MAC address for the AVM FritzBox 4040, the first
> device in ipq40xx target.

I had to look this up a bit more, since my (broken) retail-unit
Fritz!Box 4040 does not have the MAC-Address on the sticker labeled
as "MAC Address" (or something like that).
Instead there is a "CWMP-Account" String/Number which displays the
Address as a "part" of it.

Wouldn't it be better to just go with the "serial number" of the device 
in this case then?

Going deeper: The patch that introduced ucidef_set_label_macaddr describes it as

|commit 469e347f19ce9eefdc16f421b8e1f18ed60c310c
|Author: Adrian Schmutzler 
|Date:   Thu Aug 15 15:13:27 2019 +0200
|
|base-files: provide option to specify label MAC address in board.d
|
|For many devices, MAC addresses cannot be retrieved via the
|device tree alias.
| [...]

... This is somewhat strange in the context of the Fritz!Box 4040.
This is because the extra u-boot we use for the Fritz!Box 4040 makes
a real effort to patch the real mac-address into the device tree
before handing it off to the kernel.

https://github.com/chunkeey/FritzBox-4040-UBOOT/blob/master/board/qcom/ipq40xx_cdp/ipq40xx_cdp.c#L455

So, everything should just "click" with this alias added.

label-mac-device = 

Or does it not?

Cheers,
Christian

> Signed-off-by: Adrian Schmutzler 
> ---
>  target/linux/ipq40xx/base-files/etc/board.d/02_network | 4 
>  1 file changed, 4 insertions(+)
> 
> 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 e5ba7260f3..082724ebfc 100755
> --- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
> +++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
> @@ -77,6 +77,9 @@ ipq40xx_setup_macs()
>   wan_mac=$(mtd_get_mac_binary_ubi Factory 0x5006)
>   lan_mac=$(mtd_get_mac_binary_ubi Factory 0x1006)
>   ;;
> + avm,fritzbox-4040)
> + label_mac=$(cat /sys/class/net/eth0/address)
> + ;;
>   engenius,ens620ext)
>   wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
>   lan_mac=$(macaddr_add "$wan_mac" 1)
> @@ -89,6 +92,7 @@ ipq40xx_setup_macs()
>  
>   [ -n "$lan_mac" ] && ucidef_set_interface_macaddr "lan" $lan_mac
>   [ -n "$wan_mac" ] && ucidef_set_interface_macaddr "wan" $wan_mac
> + [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
>  }
>  
>  board_config_update
> 





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


Re: [OpenWrt-Devel] [PATCH] kernel: fix hw-crypto detection of qce driver

2019-09-23 Thread Christian Lamparter
On Mon, Sep 23, 2019 at 2:28 PM Eneas Queiroz  wrote:
>
> On Fri, Sep 20, 2019 at 5:48 PM Eneas U de Queiroz
>  wrote:
> >
> > This adds the CRYPTO_ALG_KERN_DRIVER_ONLY flag to Qualcomm crypto engine
> > driver algorithms, so that openssl devcrypto can recognize them as
> > hardware-accelerated.
> >
> > Signed-off-by: Eneas U de Queiroz 
>
> I noticed this was moved to ipq40xx, but ipq806x is also enabling the
> qce driver:
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/config-4.14#l119
>
> So I imagine we need to either copy the patch to ipq806x, or disable
> the qce driver in ipq806x/config-4.14.  I don't have enough knowledge
> to decide what to do, so can someone more knowledgeable, please,
> either do it or point me to the right direction.

The upstream qce crypto driver does not support the IPQ806x series.
The ipq806x target used to host ipq40xx, so this driver was enabled as
builtin back then.
But since ipq40xx moved out, it's has become a symbol of "hope"
That maybe some day
the NSS support of the IPQ806x can make use of it

So yeah, if you want to crush the hopes and dreams of the IPQ806X users,
you can disable/remove the driver for the ipq806x target.

Regards,
Christian

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


Re: [OpenWrt-Devel] [PATCH] apm821xx: for Meraki MR24 modify BLOCKSIZE to reduce LEB over-allocation

2019-09-20 Thread Christian Lamparter
Hello,

On Tuesday, September 17, 2019 6:59:28 AM CEST Russell Senior wrote:
> On Meraki MR24, the BLOCKSIZE variable is used to allocate space for the
> kernel blob. The LEB size on MR24 is 15.5k (15872 bytes). In the
> particular instance observed, it was found that reducing blocksize to
> 512 bytes resulted in 3 fewer LEBs being allocated to the kernel ubi
> volume, with no ill effects.
> 
> Signed-off-by: Russell Senior 
> ---
>  target/linux/apm821xx/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/apm821xx/image/Makefile 
> b/target/linux/apm821xx/image/Makefile
> index 8203de39c5..1aa4e0dad3 100644
> --- a/target/linux/apm821xx/image/Makefile
> +++ b/target/linux/apm821xx/image/Makefile
> @@ -127,7 +127,7 @@ define Device/meraki_mr24
>DEVICE_PACKAGES := kmod-spi-gpio -swconfig
>BOARD_NAME := mr24
>DEVICE_DTS := meraki-mr24
> -  BLOCKSIZE := 63k
> +  BLOCKSIZE := 512
>IMAGES := sysupgrade.bin
>DTB_SIZE := 64512
>IMAGE_SIZE := 8191k

The value looks odd, since UBI volumes are always a multiple of the LEB size
and the documentation we have

states that "The erasesize is the block size of the flash [...]".
so in that regard BLOCKSIZE could be 15872 or 16 KiB (if we would stick to
the real, raw value of the flash).

But I don't think a generated image with these parameters would boot anymore.
As the problem here is hidden in "MerakiAdd-dtb" step that is used generate the
KERNEL (for sysupgrade) relies on that  BLOCKSIZE value being a integer 
divisible
of the 63KiB value. Since this magic value (63KiB) is needed to place the
DTB+kernel at the correct offsets for mkmerakifw.

so, what to do? Because it's possible to get rid of the whole logic as well as 
the
MR24 portion of the mkmerakifw by refactoring the u-boot boot commands to just 
load
and boot a multi-file image. The framework is all there since the initramfs 
image is
already utilizing "MuImage-initramfs". This would save even more since this 
makes it
possible to also shrink down the DTB as well. As the "raw" information in there 
is 
just around 10k-15k and the rest of this is fluff. (Some of this fluff is 
needed by
u-boot though. As it needs some space (probably less than 128 bytes) of this 
area to
"add" in values for frequencies and ranges. So it can't be completely removed 
like
with newer u-boots).

So, Would you be willing to do this? 

Regards,
Christian



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


Re: [OpenWrt-Devel] [PATCH v2 2/2] ath10k-ct: update to version 2019-09-09

2019-09-13 Thread Christian Lamparter
On Friday, September 13, 2019 12:15:39 PM CEST Robert Marko wrote:
> Update the ath10k-ct driver version to 
> 5e8cd86f90dac966d12df6ece84ac41458d0e95f
> to enable dynamic VLANs to work.
> Packages refreshed while bump.
> 
> Signed-off-by: Robert Marko 
> 
> Changes from v1:
>   * Fixed wrong mirror hash

Watch out, there's a request to revert the ath10k-ct, since the
previous "ath10k-ct: update to HEAD of 2019-08-14 - 9e5ab2" patch
apparently broke 160MHz.

https://github.com/openwrt/openwrt/commit/e9d875a5371c89a3f351df5aec593ac90ba89ecc#commitcomment-34992683

I didn't see any 160MHz related fixes in the update here... So what to do?
Update or revert?

> ---
>  package/kernel/ath10k-ct/Makefile   | 6 +++---
>  ...h10k-add-support-for-configuring-management-packet.patch | 4 ++--
>  ...h10k-fix-possible-out-of-bound-access-of-ath10k_ra.patch | 2 +-
>  ...h10k-fix-incorrect-multicast-broadcast-rate-settin.patch | 4 ++--
>  .../patches/164-ath10k-commit-rates-from-mac80211.patch | 6 +++---
>  ...-and-GPIO-controlling-support-for-various-chipsets.patch | 6 +++---
>  .../202-ath10k-4.16-use-tpt-trigger-by-default.patch| 4 ++--
>  ...h10k-Limit-available-channels-via-DT-ieee80211-fre.patch | 2 +-
>  ...h10k-Check-if-station-exists-before-forwarding-tx-.patch | 2 +-
>  9 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/package/kernel/ath10k-ct/Makefile 
> b/package/kernel/ath10k-ct/Makefile
> index 05d30891f5..dbf75fe174 100644
> --- a/package/kernel/ath10k-ct/Makefile
> +++ b/package/kernel/ath10k-ct/Makefile
> @@ -8,9 +8,9 @@ PKG_LICENSE_FILES:=
>  
>  PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
>  PKG_SOURCE_PROTO:=git
> -PKG_SOURCE_DATE:=2019-08-14
> -PKG_SOURCE_VERSION:=9e5ab25027e0971fa24ccf93373324c08c4e992d
> -PKG_MIRROR_HASH:=95dc42a5615f80528223859b4f9618feafb5a0a29a9eb4c4bc983f76c74fb535
> +PKG_SOURCE_DATE:=2019-09-09
> +PKG_SOURCE_VERSION:=5e8cd86f90dac966d12df6ece84ac41458d0e95f
> +PKG_MIRROR_HASH:=dc1097f3a7b4b7e346918f206746d00a0b7df07ae3be9b89be55dfaef3cbbe45
>  
>  # Build the 5.2 ath10k-ct driver version.  Other option is "-4.19".
>  # Probably this should match as closely as
> diff --git 
> a/package/kernel/ath10k-ct/patches/161-ath10k-add-support-for-configuring-management-packet.patch
>  
> b/package/kernel/ath10k-ct/patches/161-ath10k-add-support-for-configuring-management-packet.patch
> index d62a1cfcf5..e67003c5a7 100644
> --- 
> a/package/kernel/ath10k-ct/patches/161-ath10k-add-support-for-configuring-management-packet.patch
> +++ 
> b/package/kernel/ath10k-ct/patches/161-ath10k-add-support-for-configuring-management-packet.patch
> @@ -43,7 +43,7 @@ Origin: backport, 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
>   static int ath10k_mac_get_max_vht_mcs_map(u16 mcs_map, int nss)
>   {
>   switch ((mcs_map >> (2 * nss)) & 0x3) {
> -@@ -6388,9 +6404,10 @@ static void ath10k_bss_info_changed(stru
> +@@ -6405,9 +6421,10 @@ static void ath10k_bss_info_changed(stru
>   struct cfg80211_chan_def def;
>   u32 vdev_param, pdev_param, slottime, preamble;
>   u16 bitrate, hw_value;
> @@ -56,7 +56,7 @@ Origin: backport, 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
>   
>   mutex_lock(>conf_mutex);
>   
> -@@ -6596,6 +6613,30 @@ static void ath10k_bss_info_changed(stru
> +@@ -6613,6 +6630,30 @@ static void ath10k_bss_info_changed(stru
>   arvif->vdev_id,  ret);
>   }
>   
> diff --git 
> a/package/kernel/ath10k-ct/patches/162-ath10k-fix-possible-out-of-bound-access-of-ath10k_ra.patch
>  
> b/package/kernel/ath10k-ct/patches/162-ath10k-fix-possible-out-of-bound-access-of-ath10k_ra.patch
> index ab360b7261..a24029983c 100644
> --- 
> a/package/kernel/ath10k-ct/patches/162-ath10k-fix-possible-out-of-bound-access-of-ath10k_ra.patch
> +++ 
> b/package/kernel/ath10k-ct/patches/162-ath10k-fix-possible-out-of-bound-access-of-ath10k_ra.patch
> @@ -26,7 +26,7 @@ Origin: backport, 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
>   if (ath10k_rates[i].bitrate == bitrate)
>   return hw_value_prefix | ath10k_rates[i].hw_value;
>   }
> -@@ -6619,22 +6619,22 @@ static void ath10k_bss_info_changed(stru
> +@@ -6636,22 +6636,22 @@ static void ath10k_bss_info_changed(stru
>   return;
>   }
>   
> diff --git 
> a/package/kernel/ath10k-ct/patches/163-ath10k-fix-incorrect-multicast-broadcast-rate-settin.patch
>  
> b/package/kernel/ath10k-ct/patches/163-ath10k-fix-incorrect-multicast-broadcast-rate-settin.patch
> index 2b550e76df..f6fd75b7e5 100644
> --- 
> a/package/kernel/ath10k-ct/patches/163-ath10k-fix-incorrect-multicast-broadcast-rate-settin.patch
> +++ 
> b/package/kernel/ath10k-ct/patches/163-ath10k-fix-incorrect-multicast-broadcast-rate-settin.patch
> @@ -17,7 +17,7 @@ Origin: other, https://patchwork.kernel.org/patch/10723033/
>  
>  --- a/ath10k-4.19/mac.c
>  

Re: [OpenWrt-Devel] [PATCH 3/3] apm821xx: image: remove unused kernel.dtb from IMAGES

2019-09-13 Thread Christian Lamparter
On Friday, September 13, 2019 3:08:15 AM CEST Yousong Zhou wrote:
> It's a leftover from 2271967f ("pm821xx: utilize build ARTIFACTs")
"apm821xx: utilize build ARTIFACTs"

Otherwise

Acked-by: Christian Lamparter 
> 
> Signed-off-by: Yousong Zhou 
> ---
>  target/linux/apm821xx/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/apm821xx/image/Makefile 
> b/target/linux/apm821xx/image/Makefile
> index acfd478755..8203de39c5 100644
> --- a/target/linux/apm821xx/image/Makefile
> +++ b/target/linux/apm821xx/image/Makefile
> @@ -238,7 +238,7 @@ define Device/wd_mybooklive
>DTB_SIZE := 16384
>KERNEL := kernel-bin | dtb | gzip | uImage gzip
>KERNEL_INITRAMFS := kernel-bin | gzip | dtb | MuImage-initramfs gzip
> -  IMAGES := factory.img.gz kernel.dtb sysupgrade.img.gz
> +  IMAGES := factory.img.gz sysupgrade.img.gz
>ARTIFACTS := apollo3g.dtb
>DEVICE_DTB := apollo3g.dtb
>FILESYSTEMS := ext4 squashfs
> 
> ___
> 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] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-09-01 Thread Christian Lamparter
Hi,

On Sun, Sep 1, 2019 at 1:52 PM Russell Senior  wrote:
> > "Jonas" == Jonas Gorski  writes:
> >> It contains a patch at the end titled: "[PATCH] base-files: pad
> >> root.squashfs to 64KiB in ubi volumes" This is another approach that
> >> just deals with the UBI+squashfs issue but works with
> >> "-nopad". Soo do we all agree there?
>
> Jonas> a) 64k is excessive, we only need 4k (actually 1k would be
> Jonas> enough, since we don't enable CONFIG_SQUASHFS_4K_DEVBLK_SIZE).
>
> Jonas> The referenced issue with 64k page size happens when
> Jonas> loop-mounting a squashfs, since loop defaults to PAGE_SIZE as its
> Jonas> block size. But we never do that in OpenWrt, and we don't support
> Jonas> any targets with that huge PAGE_SIZE - biggest is ARC with 8k.
>
> Jonas> b) it misses the squashfs's in generic sysupgrade images itself -
> Jonas> we need to pad their length as well, to avoid breaking devices
> Jonas> with a sysupgrade image hitting the corner case being flashed
> Jonas> from an unfixed firmware with the old nand.sh.
>
> Jonas> Also IMHO "1c0290c5cc6258c48b8ba46b4f9c85a21de4f875" should be
> Jonas> reverted, for the previously mentioned issues.
>
> Afaict, only devices with LEB sizes of non-integer kilobytes (like the
> MR24 with its 15.5k LEBs) need any intervention at all. Because
> squashfs's are read in 1k blocks, there is a 1 in 62 chance of creating
> a rootfs that is an inopportune size on 15.5k LEBs.  I have a PogoPlug
> v3 with LEBs of 126k, and a MikroTik RouterBOARD 493G with LEBs of
> 124k. Neither of those is affected.
>
> I still kind of like my solution where we explicitly ask for padding for
> devices that need it.

I see, fine.

Tell you what, I'll let the two of you do what you want or not.
My request to the both of you is, that instead of justreverting, please add  a
"why the -nopad has become essentially atechnical debt there". I'm not that
familiar with these devices and their problems, so I don#t think I have anything
more to add.

Goodbye!

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


Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-31 Thread Christian Lamparter
Hello,

On Saturday, August 31, 2019 2:09:55 PM CEST Jonas Gorski wrote:
> On Sat, 31 Aug 2019 at 01:19, Christian Lamparter  wrote:
> >
> > On Friday, August 30, 2019 11:10:54 PM CEST Russell Senior wrote:
> > > >>>>> "Christian" == Christian Lamparter  writes:
> > >
> > > Christian> Ok.
> > >
> > > Christian> I did push a patch titled: "build: remove harmful -nopad
> > > Christian> option from mksquashfs"
> > > Christian> 
> > > <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1c0290c5cc6258c48b8ba46b4f9c85a21de4f875>
> > >
> > > Christian> so, let's see if this triggers more undefined behaviour and
> > > Christian> exposes more hidden broken code.
> > >
> > > Just to re-iterate my earlier worry, if for example:
> > >
> > >   kernel_size + rootfs_with_padding_size
> > >
> > > crosses an erase block boundary that:
> > >
> > >   kernel_size + rootfs_without_padding_size
> > >
> > > does not, then we'll be wasting an erase block of flash space on NOR.
> > Not to worry. I guess that part of the magic is also explained in the wiki:
> > <https://openwrt.org/docs/techref/flash.layout#example_flash_partitioning>
> > <https://openwrt.org/docs/techref/flash.layout#explanations>
> > In case my attempt now gets too confusing :-/.
> >
> > The "rootfs" partition also contains the rootfs_data inside. It should
> > be possible to verify this with any of the routers that use the "firmware"
> > parition label.
> >
> > Please check /proc/mtd. For example on my WNDR3700v2 (which is very similar
> > to your WNDR3800). It looks like this
> >
> > |# cat /proc/mtd
> > |dev:size   erasesize  name
> > |mtd0: 0005 0001 "u-boot"
> > |mtd1: 0002 0001 "u-boot-env"
> > |mtd2: 00f8 0001 "firmware"
> > |mtd3: 0018c440 0001 "kernel"
> > |mtd4: 00df3bc0 0001 "rootfs"
> > |mtd5: 0062 0001 "rootfs_data"
> > |mtd6: 0001 0001 "art
> >
> > The rootfs is 14629824 Bytes = 13.95 MiB. (The kernel + uboot + env + art
> > fills out the remaining ~2MiB to a total of 16 MiB). So the padding we both
> > are talking about already has to exists between the squashfs portion and the
> > jffs2/overlay portion inside the "rootfs" partition and it's a full 
> > erase-size
> > block. Sadly, OpenWrt does not readily print the "end" of just the squashfs
> > partition (as it does with the kernel partition above) and your message from
> > earlier with the three routers didn't include the "squashfs-split" and its
> > results. (I think that maybe this is the missing information that got lost?)
> 
> After a bit more investigation, those devices that use padjffs2 (or
> have the rootfs
> start at an at least 4k aligned offset) will be fine.
> 
> The issue are those devices with an unaligned rootfs start, which put their 
> own
> EOF marker in the image by the firmware util (e.g. brcm63xx or tp-link 
> devices).
> 
> There it can happen that e.g. we get
> 
> 0x18fff2   00 00 00 00
> 0x19000 00 00 00 00 ...  FF FF
> 0x19010 FF FF FF ...
> *
> 0x2 DE AD C0 DE
> 
> The 0xff are only a guess, I haven't checked what the different
> firmware utils use for padding the end of the rootfs - but mksquashfs
> definitely uses 0x00.
> 
> which leads to:
> 
> 1. squashfs-split will put the roofs_data partition start at 0x19000
> because that's the first aligned erase block after the end of the
> rootfs start + squashfs length
> 2. jffs2 will see that the first block is neither a valid jff2 node,
> an EOF marker, nor all 0xff
> 3. jffs2 will refuse to erase/mount the filesystem (AFAIU the code) [1]
> 
> So removing the -nopad might actually break those devices.
> 
> We could fix this case by making sure that mksquashfs and all firmware
> utils use 0xff's to pad (so the erase block will then be treated as
> empty/all 0xff). But then there is the question how jffs2 reacts if
> the first block is 0xff, and the second block is a valid jffs2 node,
> which happens when we sysupgrade with keeping config on NOR devices.
> The jffs2 code isn't the most readable code ... .
>
No need to worry, see one of the previous mails in this thread:

http://lists.infradead.org/pipermail/openwrt-devel/2019-August/018638.html

It contains a patch at the end titled:
"[PATCH] base-files: pad root.squashfs to 64KiB in ubi volumes"
This is another approach that just deals with the UBI+squashfs
issue but works with "-nopad". Soo do we all agree there?  

Cheers,
Christian



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


Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-30 Thread Christian Lamparter
On Friday, August 30, 2019 11:10:54 PM CEST Russell Senior wrote:
> >>>>> "Christian" == Christian Lamparter  writes:
> 
> Christian> Ok.
> 
> Christian> I did push a patch titled: "build: remove harmful -nopad
> Christian> option from mksquashfs"
> Christian> 
> <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1c0290c5cc6258c48b8ba46b4f9c85a21de4f875>
> 
> Christian> so, let's see if this triggers more undefined behaviour and
> Christian> exposes more hidden broken code.
> 
> Just to re-iterate my earlier worry, if for example:
> 
>   kernel_size + rootfs_with_padding_size
> 
> crosses an erase block boundary that:
> 
>   kernel_size + rootfs_without_padding_size
> 
> does not, then we'll be wasting an erase block of flash space on NOR.
Not to worry. I guess that part of the magic is also explained in the wiki:
<https://openwrt.org/docs/techref/flash.layout#example_flash_partitioning>
<https://openwrt.org/docs/techref/flash.layout#explanations>
In case my attempt now gets too confusing :-/.

The "rootfs" partition also contains the rootfs_data inside. It should
be possible to verify this with any of the routers that use the "firmware"
parition label.

Please check /proc/mtd. For example on my WNDR3700v2 (which is very similar
to your WNDR3800). It looks like this

|# cat /proc/mtd
|dev:size   erasesize  name
|mtd0: 0005 0001 "u-boot"
|mtd1: 0002 0001 "u-boot-env"
|mtd2: 00f8 0001 "firmware"
|mtd3: 0018c440 0001 "kernel"
|mtd4: 00df3bc0 0001 "rootfs"
|mtd5: 0062 0001 "rootfs_data"
|mtd6: 0001 0001 "art
 
The rootfs is 14629824 Bytes = 13.95 MiB. (The kernel + uboot + env + art
fills out the remaining ~2MiB to a total of 16 MiB). So the padding we both
are talking about already has to exists between the squashfs portion and the
jffs2/overlay portion inside the "rootfs" partition and it's a full erase-size
block. Sadly, OpenWrt does not readily print the "end" of just the squashfs
partition (as it does with the kernel partition above) and your message from 
earlier with the three routers didn't include the "squashfs-split" and its
results. (I think that maybe this is the missing information that got lost?)

|[0.655975] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
|[0.661058] 4 fixed-partitions partitions found on MTD device spi0.0
|[0.667448] Creating 4 MTD partitions on "spi0.0":
|[0.672234] 0x-0x0005 : "u-boot"
|[0.677910] 0x0005-0x0007 : "u-boot-env"
|[0.683834] 0x0007-0x00ff : "firmware"
|[0.691804] 2 netgear-fw partitions found on MTD device firmware
|[0.697856] Creating 2 MTD partitions on "firmware":
|[0.702818] 0x-0x0018c440 : "kernel"
|[0.708443] 0x0018c440-0x00f8 : "rootfs"
|[0.713960] mtd: device 4 (rootfs) set to be root filesystem
|[0.719688] 1 squashfs-split partitions found on MTD device rootfs
|[0.725870] 0x0096-0x00f8 : "rootfs_data"
|[0.731896] 0x00ff-0x0100 : "art"


That is of course, you don't max-out the rootfs completely (to the last byte)
and leave no space for the overlay/jffs2... But in that case, mksquashfs 
should not need to add any padding since the partition is ending at a 4k block
already. (However, I don't think padjffs2 will be happy.)

> On a side note, I noticed that there were some checks[1] added to
> kernels about a year ago (early august 2018) to squashfs code[1], to
> protect against malformed squash filesystems that might have started
> triggering the boot loop. This might explain why we haven't seen the
> problem earlier (it might have been silently ignored).
> 
> [1] e.g. 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71755ee5350b63fb1f283de8561cdb61b47f4d1d
It's more of an edge case for sure. I think I've must have hit it during
the development as well. I remember having a bad squashfs after a build 
that I just could not read even with the userspace unsquashfs utils either
on my PC. So I think we really want to provide "unsquashfs"/"binwalk" able
root.squashfs for debugging as well.

Cheers,
Christian



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


Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-30 Thread Christian Lamparter
On Thursday, August 29, 2019 1:55:25 PM CEST Russell Senior wrote:
> 
> >> Fwiw, I took a little closer look at the squashfs code. I still don't
> >> quite understand it, but I sprinkled some printk()'s and got a better
> >> idea of what is happening.
> >> 
> >> With a root.squashfs of 6428672 bytes, we get the error in a call:
> >
> > Actually, the 6428672 bytes was from a later trial. Sorry for the
> > confusion. I'm not sure what the real root.squashfs size was
> > anymore. Gah. I'll need to redo it.
> 
> Here are the corresponding numbers from the retry:
> 
> root.squasfs size (from the sysupgrade.bin tarball): 6427978 bytes
> 
> squashfs_read_data(sb=(ptrval),index=0,length=6427970,next_index=16777224,output=(null))
> b=0; bytes=-322; length=8; cur_index=0
> 
> >> 
> >>   
> >> squashfs_read_data(sb=(ptrval),index=0,length=6427986,next_index=16777224,output=
> >>   (null))
> >> 
> >> it enters the loop at fs/squashfs/block.c:122 with b=0; bytes=-338; 
> >> length=8; cur_index=0
> >> 
> >> for (b = 0; bytes < length; b++, cur_index++) {
> >> bh[b] = sb_getblk(sb, cur_index);
> >> if (bh[b] == NULL)
> >> goto block_release;
> >> 
> >> sb_getblk() must return NULL, because it goes to block_release and falls
> >> through to print the error message and exits with an error.
> 
Ok.

I did push a patch titled:
"build: remove harmful -nopad option from mksquashfs"

 

so, let's see if this triggers more undefined behaviour 
and exposes more hidden broken code.

Regards,
Christian



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


Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-25 Thread Christian Lamparter
[Fixed Mathias Email]

On Sunday, August 25, 2019 8:16:48 AM CEST Russell Senior wrote:
> > On Saturday, August 24, 2019 2:18:55 AM CEST Russell Senior wrote:
> > > > What's happening here is that mksquashfs4 is being told
> > > > through the "-nopad" option to "do not pad filesystem to a
> > > > multiple of 4K" [0].
> > > 
> > > > |define Image/mkfs/squashfs |
> > > > $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call
> > > > mkfs_target_dir,$(1)) $@ \ | -nopad -noappend -root-owned \ |
> > > > -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \ | -processors 1 |endef
> > > 
> > > > My guess is that this affects more than just the MR24 (I'm
> > > > looking at you too: pad2jffs and various pad-to $value)
> > > > . I've tried tracking down the change that added the "-nopad"
> > > > and found it in a commit from 2005 titled: "add some changes
> > > > from whiterussian to head" [1] [2]:
> > > 
> > > I agree that other devices where rootfs is squashfs and lives on a ubi
> > > volume are probaby also vulnerable to this problem. Regrettably, I haven't
> > > thought of any other of those devices that I have on hand to test. 
> > > 
> > > > | $(KDIR)/root.squashfs: | @mkdir -p $(KDIR)/root/jffs |-
> > > > $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend
> > > > -root-owned -le |+ $(STAGING_DIR)/bin/mksquashfs-lzma
> > > > $(KDIR)/root $@ -nopad -noappend -root-owned -le
> > > 
> > > 
> > > > So, this is really old...
> > > 
> > > > Question is, should we just drop the -nopad? Since as you
> > > > established, in the described corner-case (see above)
> > > > squashfs needs this 4k padding and the generated squashfs
> > > > could be considered broken otherwise?
> > > 
> > > I'm under the impression that the -nopad makes sense for NOR flash where
> > > the kernel and rootfs are glued together, padding the isolated rootfs
> > > would cause alignment problems or wasted space in the combined blobs.
> > 
> > Yes, that's the nod to padjffs2. That said,
> > <https://sourceforge.net/p/squashfs/mailman/message/28307755/> makes
> > it sound like that apart from the BLOCKSIZE, we also need to PAGE_SIZE?
> > 
> > (I think the APM821XX is a special case, since it can do 64KiB Pages
> > as well as it's 32MiB SLC NAND that uses 16 KiB erase-blocks. So a
> > PAGE can span up to 4 pages.
> > 
> > > 
> > > > (Judging from your
> > > > message, you went through the kernel code. Can you please
> > > > share the place where the lack of the padding is breaking the
> > > > fs?)
> > > 
> > > It's mostly inferred from the fact that I saw the error and kernel
> > > panic, and glancing at the kernel squashfs code. I am not pretending to
> > > understand completely how the squashfs kernel code works, but the
> > > position of the error relative to the size of the rootfs in my panic
> > > case strongly suggests it was trying to read past the end of the ubi
> > > volume.
> > > 
> > > The error comes in the kernel's fs/squashfs/block.c in the
> > > squashfs_read_data() function. There are a bunch of conditions (at least
> > > 5) within the function (see "goto read_failure;") that will lead to that
> > > message being printed.
> > > 
> > Well, that's a pity this could have saved a lot of time.
> > 
> > I've cobbered together a patch that deals with some of the
> > padding issues at "ubimkvol" and "ubinize" time. The idea
> > is that ideally we want to do the padding when we know
> > PAGE_SIZE and the BLOCKSIZE/Erasesize (MR24 blocksize in
> > image/Makefile seems wrong as well...).
> > 
> > But for now, it's set to 64KiB. If this is the way forward
> > we add enable getconf and get the PAGESIZE at runtime. If not,
> > we need to come up with something else.
> > (It's also possible to do some changes in  ubi's block code or
> > squashfs kernel code to mitigate the padding, but I don't think
> > the maintainers will even look at it).
> > 
> > 
> > Regards,
> > Christian
> > ---
> > From 803cab7d585ebb85362357d008067caf645a7f17 Mon Sep 17 00:00:00 2001
> > From: Christian Lamparter 
> > Date: Sat, 24 Aug 2019 12:55:40 +0200
> > Subject: [PATCH] base-files: pad root.squashfs to 64KiB in ubi volumes
> > 
> > SquashFS's HOWTO states in t

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-24 Thread Christian Lamparter
On Saturday, August 24, 2019 2:18:55 AM CEST Russell Senior wrote:
> >>>>> "Christian" == Christian Lamparter  writes:
> 
> > I've posted a similar message to the bugreport:
> > <https://bugs.openwrt.org/index.php?do=details_id=2460>
> 
> I should have filed the bug first and linked it in my patch.
I think it's fine. It depends on whenever there will be a
discussion and where it will take place... But yeah, nobody
can tell in advance how this will go.

On Saturday, August 24, 2019 2:59:31 AM CEST Russell Senior wrote:
> >>>>> "Russell" == Russell Senior  writes:
> 
> >>>>> "Christian" == Christian Lamparter  writes:
> 
> Russell> It's mostly inferred from the fact that I saw the error and
> Russell> kernel panic, and glancing at the kernel squashfs code. I am
> Russell> not pretending to understand completely how the squashfs kernel
> Russell> code works, but the position of the error relative to the size
> Russell> of the rootfs in my panic case strongly suggests it was trying
> Russell> to read past the end of the ubi volume.
> 
> Oh, and I got important help finding this from Jonas Gorski. I was
> remiss in not mentioning that.
> 
Ok, Let's add him to the CC then. As well as some of the 
"ramips: Fix and tidy up IMAGE_SIZE #2226" and 
"[RFC] Use DTS firmware partition to obsolete IMAGE_SIZE #2310"

https://github.com/openwrt/openwrt/pull/2226
https://github.com/openwrt/openwrt/pull/2310

crowd. Because this will likely affect them as well... 
But they might not know it. In any case: "Welcome everyone! :-D".

> > What's happening here is that mksquashfs4 is being told
> > through the "-nopad" option to "do not pad filesystem to a
> > multiple of 4K" [0].
> 
> > |define Image/mkfs/squashfs |
> > $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call
> > mkfs_target_dir,$(1)) $@ \ | -nopad -noappend -root-owned \ |
> > -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \ | -processors 1 |endef
> 
> > My guess is that this affects more than just the MR24 (I'm
> > looking at you too: pad2jffs and various pad-to $value)
> > . I've tried tracking down the change that added the "-nopad"
> > and found it in a commit from 2005 titled: "add some changes
> > from whiterussian to head" [1] [2]:
> 
> I agree that other devices where rootfs is squashfs and lives on a ubi
> volume are probaby also vulnerable to this problem. Regrettably, I haven't
> thought of any other of those devices that I have on hand to test. 
> 
> > | $(KDIR)/root.squashfs: | @mkdir -p $(KDIR)/root/jffs |-
> > $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend
> > -root-owned -le |+ $(STAGING_DIR)/bin/mksquashfs-lzma
> > $(KDIR)/root $@ -nopad -noappend -root-owned -le
> 
> 
> > So, this is really old...
> 
> > Question is, should we just drop the -nopad? Since as you
> > established, in the described corner-case (see above)
> > squashfs needs this 4k padding and the generated squashfs
> > could be considered broken otherwise?
> 
> I'm under the impression that the -nopad makes sense for NOR flash where
> the kernel and rootfs are glued together, padding the isolated rootfs
> would cause alignment problems or wasted space in the combined blobs.

Yes, that's the nod to padjffs2. That said,
<https://sourceforge.net/p/squashfs/mailman/message/28307755/> makes
it sound like that apart from the BLOCKSIZE, we also need to PAGE_SIZE?

(I think the APM821XX is a special case, since it can do 64KiB Pages
as well as it's 32MiB SLC NAND that uses 16 KiB erase-blocks. So a
PAGE can span up to 4 pages.

> 
> > (Judging from your
> > message, you went through the kernel code. Can you please
> > share the place where the lack of the padding is breaking the
> > fs?)
> 
> It's mostly inferred from the fact that I saw the error and kernel
> panic, and glancing at the kernel squashfs code. I am not pretending to
> understand completely how the squashfs kernel code works, but the
> position of the error relative to the size of the rootfs in my panic
> case strongly suggests it was trying to read past the end of the ubi
> volume.
> 
> The error comes in the kernel's fs/squashfs/block.c in the
> squashfs_read_data() function. There are a bunch of conditions (at least
> 5) within the function (see "goto read_failure;") that will lead to that
> message being printed.
> 
Well, that's a pity this could have saved a lot of time.

I've cobbered together a patch that deals with some of the
padding issues at "ubimkvol" and "ubinize" time. The idea
is that ideally we want to do the padding when 

[OpenWrt-Devel] [RFC PATCH 2/2] apm821xx: utilize softoff on the MyBook Live Series

2019-08-23 Thread Christian Lamparter
This was a requested feature on the forum some long time ago.
The original vendor firmware from Western Digital allowed the
device to enter a shutdown-like state and remain there
indefinitely.

Because OpenWrt sets the platform's nowayout watchdog, this
device will reboot after some time even when poweroff gets
called and the kernel supposed to just do its infinite loop
thing.

With this somewhat universal "softoff" the device will be
able to enter a similar-but-different shutdown-like state
with the HDDs in a safer standby mode so it can be moved
and disconnected.

Signed-off-by: Christian Lamparter 
---
 target/linux/apm821xx/image/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/linux/apm821xx/image/Makefile 
b/target/linux/apm821xx/image/Makefile
index acfd478755..82e84f72f9 100644
--- a/target/linux/apm821xx/image/Makefile
+++ b/target/linux/apm821xx/image/Makefile
@@ -230,7 +230,8 @@ ifeq ($(SUBTARGET),sata)
 define Device/wd_mybooklive
   DEVICE_VENDOR := Western Digital
   DEVICE_MODEL := My Book Live Series (Single + Duo)
-  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage 
kmod-fs-vfat wpad-basic
+  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage \
+kmod-fs-vfat wpad-basic softoff
   DEVICE_TYPE := nas
   DEVICE_DTS := wd-mybooklive
   SUPPORTED_DEVICES += mbl wd,mybooklive-duo
-- 
2.23.0


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


[OpenWrt-Devel] [RFC PATCH 1/2] softoff: add softoff utility

2019-08-23 Thread Christian Lamparter
The softoff package replaces the poweroff command with a
scripts that utilize the existing sysupgrade code to perform
a "soft" poweroff (in a way that the device is no longer
responsive). So this makes it safer to disconnect and
be moved.

By design, sysupgrade already stops services and closes
any running application, as well as unmounts any active
partition.
This scripts piggybacks on what's provided by sysupgrade,
but also puts all active SATA/SCSI/UAS/USB-attached HDDs
into standby by telling the kernel they are no longer
needed (and the kernel will do the rest) and tries to
switch all available LEDs to the off state (the trigger
"none" will only switch off managed LEDs) before causes
the device to enter a infinite loop.

This works especially well with embedded devices without a
real poweroff method (many SoC platform drivers just map
the shutdown() to reset()) or suffer because the platform
has a no-way-out watchdog that can trigger a hardware
reboot which can bring the device out of its "poweroff"
state.

Signed-off-by: Christian Lamparter 
---
 package/utils/softoff/Makefile  | 36 +
 package/utils/softoff/files/softoff | 36 +
 2 files changed, 72 insertions(+)
 create mode 100644 package/utils/softoff/Makefile
 create mode 100644 package/utils/softoff/files/softoff

diff --git a/package/utils/softoff/Makefile b/package/utils/softoff/Makefile
new file mode 100644
index 00..28930e9bde
--- /dev/null
+++ b/package/utils/softoff/Makefile
@@ -0,0 +1,36 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=softoff
+PKG_RELEASE:=1
+PKG_LICENSE:=GPL-2.0
+PKG_MAINTAINER:=Christian Lamparter 
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/softoff
+   PKGARCH:=all
+   SECTION:=utils
+   CATEGORY:=Utilities
+   TITLE:=softoff utility
+endef
+
+define Package/softoff/description
+  the softoff package replaces the poweroff command with scripts that
+  utilize the sysupgrade code to perform a "softer" poweroff.
+  The script will try to close any running application, unmount any active
+  partition as well as putting any connected HDD to standby (for shutdown).
+  This allows embedded devices with out a working poweroff method to become
+  unavailable.
+endef
+
+define Build/Compile
+   true
+endef
+
+define Package/softoff/install-overlay
+   $(INSTALL_DIR)  $(1)/sbin
+   $(INSTALL_BIN)  ./files/softoff $(1)/sbin/softoff
+   $(LN) softoff $(1)/sbin/poweroff
+endef
+
+$(eval $(call BuildPackage,softoff))
diff --git a/package/utils/softoff/files/softoff 
b/package/utils/softoff/files/softoff
new file mode 100644
index 00..e25bdba8f2
--- /dev/null
+++ b/package/utils/softoff/files/softoff
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+. /lib/functions.sh
+. /lib/functions/system.sh
+. /lib/upgrade/common.sh
+
+case "$1" in
+stage2)
+   for dev in /sys/block/sd*[a-z]; do
+   [ -d "$dev" ] && echo "1" > "$dev/device/delete"
+   done
+
+   for led in /sys/class/leds/*; do
+   [ -d "$led" ] && {
+   echo "none" > "$led/trigger"
+   echo "0" > "$led/brightness"
+   }
+   done
+
+   while :; do
+   sleep 1;
+   done
+   ;;
+*)
+   install_bin /sbin/upgraded
+   install_bin "$0"
+
+   ifdown -a
+
+   ubus call system sysupgrade "{
+   \"prefix\": $(json_string "$RAM_ROOT"),
+   \"path\": $(json_string "badfile"),
+   \"command\": $(json_string "$0 stage2")
+   }"
+   ;;
+esac
-- 
2.23.0


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


[OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-23 Thread Christian Lamparter
On Thursday, August 22, 2019 1:00:21 PM CEST Russell Senior wrote:
> 
> Using pad-squashfs ensures that the root.squashfs is assigned sufficient
> LEBs on UBI such that all reads of the rootfs succeed, in order to avoid
> read failures and kernel panics.
> 
> This fixes one such kernel panic observed on Meraki MR24 where an
> inopportune-sized unpadded root.squashfs occurred.
> 
> Note: ext4-sysupgrade firmware binaries will build with this patch, but
> they are as nonsensical as before the patch. Finding a way to disable
> ext4 builds for Meraki MR24 is left as a TODO.
> 
> Signed-off-by: Russell Senior 
> ---
>  target/linux/apm821xx/image/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/apm821xx/image/Makefile 
> b/target/linux/apm821xx/image/Makefile
> index acfd478755..53192bb448 100644
> --- a/target/linux/apm821xx/image/Makefile
> +++ b/target/linux/apm821xx/image/Makefile
> @@ -133,7 +133,8 @@ define Device/meraki_mr24
>IMAGE_SIZE := 8191k
>KERNEL := kernel-bin | lzma | uImage lzma | MerakiAdd-dtb | MerakiNAND
>KERNEL_INITRAMFS := kernel-bin | lzma | dtb | MuImage-initramfs lzma
> -  IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
> +  IMAGE/sysupgrade.bin/squashfs := pad-squashfs | sysupgrade-tar | 
> append-metadata
> +  IMAGE/sysupgrade.bin/ext4 := sysupgrade-tar | append-metadata
>UBINIZE_OPTS := -E 5
>SUPPORTED_DEVICES += mr24
>  endef
> 

I've posted a similar message to the bugreport:


What's happening here is that mksquashfs4 is being told through the "-nopad" 
option
to "do not pad filesystem to a multiple of 4K" [0].

|define Image/mkfs/squashfs
|$(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \
|-nopad -noappend -root-owned \
|-comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \
|-processors 1
|endef

My guess is that this affects more than just the MR24 (I'm looking at you too:
pad2jffs and various pad-to $value) . I've tried tracking down the change that
added the "-nopad" and found it in a commit from 2005 titled:
"add some changes from whiterussian to head" [1] [2]:

| $(KDIR)/root.squashfs:
|@mkdir -p $(KDIR)/root/jffs
|-   $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend 
-root-owned -le
|+   $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -nopad -noappend 
-root-owned -le


So, this is really old... 

Question is, should we just drop the -nopad? Since as you established, in
the described corner-case (see above) squashfs needs this 4k padding and
the generated squashfs could be considered broken otherwise?
(Judging from your message, you went through the kernel code. Can you
please share the place where the lack of the padding is breaking the fs?)

Cheers,
Christian

[0] 

[1] 

[2] 




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


Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

2019-08-02 Thread Christian Lamparter
On Friday, August 2, 2019 8:03:17 PM CEST Jeff Kletsky wrote:
> 
> On 8/2/19 7:46 AM, Adrian Schmutzler wrote:
> > This converts all remaining devices to use interrupt-driven
> > gpio-keys compatible instead of gpio-keys-polled.
> > The poll-interval is removed.
> >
> 
> Not that this proposed change makes the situation any different, but 
> many devices have switches that are poorly handled by the "key-press" 
> approach.
> 
> One specific case that has bothered me (but not enough to dig into it) 
> is the Archer C7v2 that has an "rfkill" switch. Not only is it 
> "backwards" (label "Off" is really "wireless on"), but it only responds 
> to changes in state, so its state at boot is not respected. You can't, 
> as I recall, set it for "wireless off", plug in the device, and have the 
> wireless be off when OpenWrt boots.
> 
> The GL-AR300M series and the GL-AR750S also have a multi-position "mode" 
> switch.
> 
> Right now, all these switches have to be toggled twice to have their 
> position be properly respected by the OS if they're not in the 
> "expected" position.
> 
> It would seem that, at some point, switches like these would be better 
> served by a driver that can both detect position, as well as transition. 
> This would likely also require a way to poll the position at 
> "impacted-service start" and ubus support along with changes in existing 
> hotplug scripts.

>From playing around with gpio-keys and the openwrt's gpio-button-hotplug.c
in the past few weeks, I think I can tell you what's happening here.
One (there are more) of the problems is that gpio-keys module gets loaded
even before the procd enters its "preinit" phase (the module is part of 
/etc/modules-boot.d/30-gpio-button-hotplug). And the bad news is that
even once procd hits the preinit phase, it intentionally forwards everything
to the failsafe button events script:

|   [ "if",
|   [ "eq", "SUBSYSTEM", "button" ],
|   [ "exec", "/etc/rc.button/failsafe" ]
|  ]



/etc/rc.button/failsafe itself is also very telling:

|#!/bin/sh
|
|[ "${TYPE}" = "switch" ] || echo ${BUTTON} > /tmp/failsafe_button
|
|return 0

The long and short of this is that initial switch state event is
generated but it has no change of getting processed properly
at the time the driver is loaded as the system isn't ready.

Note: If it was loaded later when procd is in the "init" phase,
then it works because events are then processed by hotplug.json,
which does:
 
[ "if",
[ "and",
[ "has", "BUTTON" ],
[ "eq", "SUBSYSTEM", "button" ]
],
[ "button", "/etc/rc.button/%BUTTON%" ]
],



Then everything would work as you expect.
so, it's not the driver that lets you down here, because it can't
do much about these userspace antics.

(Note: OpenWrt's gpio-button-hotplug.c uses the BUTTON subsystem
event type for both EV_KEY (button) and EV_SW (switches) events.
So don't let this confuse you).

Regards,
Christian



___
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 Christian Lamparter
Hello David,

On Sunday, July 14, 2019 12:55:02 AM CEST David Bauer wrote:
> 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

Yes, that's something that would deserve to get mentioned.

>From my POV, the driver should behave as close to whatever the
idea of the DeviceTree "gpio-keys" and "gpio-keys-polled"
binding is. The catch with this is that upstream Linux isn't the
only OS with a driver for it. For example FreeBSD has a driver
implementing the bindings as well ... and I think the newer FDT 
u-boots could as well in the future(but not yet?). So it is sort
of important for the thing to behave more or less the same across
the platforms. 

(OpenWrt's gpio-button-hotplug has still a few gotchas:
 - no support for irq-only buttons
 - no wake-up support (noboby really implements pm)
 - only a small list of special buttons (in button_map) are supported
 - no autorepeat support (no idea if this is needed or not)).
 - gpio_keys (non polled) doesn't care about pdata->enable/disable

> > 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.

Heh, I was about to mention the wiki (and /lib/preinit/30_failsafe_wait)
the as well in the reply. But I cut that part, because it was too long already.
I was basically praising the author who wrote  "... and *press* a button." and
not something along the line of "change the state of the button" in that
LED-blinkenlights window.

/lib/preinit/30_failsafe_wait also echos
 "Please press button now to enter failsafe" as well as
 "- failsafe button "`cat /tmp/failsafe_button`" was pressed -"

it would be odd(er) if this script triggers when a button is released, no?.
 
> > 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.


Hm, this is what I know about the devilish devolo boards (based on your mails).
(Yes, I read your comment at the end.)

|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.

(current) target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi

|keys {
|compatible = "gpio-keys";
|
|reset {
|  

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

2019-07-13 Thread Christian Lamparter
Hi David,

On Saturday, July 13, 2019 7:53:05 PM CEST David Bauer wrote:
> first of all, i wouldn't have imagined that there is so mush to talk about 
> pressing buttons ;)

Well, if you remember my first versions that I pushed out of the gpio-button
rework were really buggy, so... :(
On the other hand, the "git commit && git push" is just one
"enter" away. ;) We can finish this "right now" and deal with
the "shoot from the hip" later. (Though this is not advised)

> On 13.07.19 18:04, Christian Lamparter wrote:
> > 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 p

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

2019-07-06 Thread Christian Lamparter
On Tuesday, July 2, 2019 11:57:18 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 
> ---

Thank you, I had to play much more around with as the logic around the
has_initial_state variable got me really consfused. Sadly, I had to dump
it down to a notch, so that I can follow. So, here's my version of your version 
;)
sadly with more changes as I got carried away :(

  - removed a now unused variable "int i;" in gpio_keys_polled_probe.
(gcc found it)

  - renamed button_hotplug_event to gpio_keys_handle_button
(From what I know the name "hotplug"(2) came from the udev replacement
daemon from back in the day. Nowadays, this is part of procd. maybe the
whole driver should be renamed?) 

  - "button->active_low = flags & OF_GPIO_ACTIVE_LOW" is more robust(for now).
This only works because  OF_GPIO_ACTIVE_LOW is 0x1.
If it was bigger than 0x1, then this would have never worked.

  - moved the "check if EV_KEY or EV_SW" to gpio_keys_button_probe() +
  - moved the "button map" lookup performed by button_get_index()
to gpio_keys_button_probe
  
I did this to save a few cycles here and there (and the added
warnings might help a poor debugger one day). In my opinion, it
doesn't make sense to always check the type and perform the
lookup for (pretty much at that point) constant values.
(upstream gpio_keys has a sysfs to add new keys. I guess this
is why the dev thought of that).

  - moved the "seen" from the bh_priv to gpio_keys_button_data.
(again, it looks like the developer wanted to make it modular.
but upstream and openwrt have diverted too much)

There's still stuff todo, like converting the gpio accessors to
just use gpiod_get_value_cansleep. But that's for another time...

The remaining question is: Does this still work as expected?

(I think some of the problems related to the "failsafe issues"
could be caused by the wrong polarity, I'm guilty of doing this
as well. I had copied these settings from netgears GPL code and
did not check. Netgear had their own hacked GPIO driver and then
I foolishly applied the same polarity setting for pretty much
all the apm821xx targets). 

Cheers,
Christian
---
>From 2f243a66d4fa62319eb5bde322643da3bfbb7082 Mon Sep 17 00:00:00 2001
From: David Bauer 
Date: Tue, 2 Jul 2019 23:57:18 +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 
Signed-off-by: Christian Lamparter  [further
cleanups, simplification and unification]
---
 .../src/gpio-button-hotplug.c | 141 ++
 1 file changed, 76 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..edd03d2b62 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/s

Re: [OpenWrt-Devel] [PATCH] gemini: Add StorLink SL93512r images

2019-07-06 Thread Christian Lamparter
On Sunday, June 30, 2019 5:07:56 PM CEST Linus Walleij wrote:
> This adds image generation for the StorLink reference design
> SL93512r. This board is now supported upstream in kernel
> v4.19.
> 
> As this image structure is identical to SQ201 and Raidsonic,
> we simply refer to this as "storlink-reference" from now on.
> 
> Signed-off-by: Linus Walleij 

The buildbots are currently in a bit of a pickle:


The gemini-target is failing for some time now.

This is due to this error (see patch):
https://patchwork.ozlabs.org/patch/1128185/

but also:

cp ./ImageInfo-storlink_sl93512r 
/home/luser/owrt/test-chunkeey-20190705-170344/gemini-generic/build_dir/target-arm_fa526_musl_eabi/linux-gemini/tmp/openwrt-gemini-storlink_sl93512r-squashfs-factory.bin.tmp/ImageInfo
cp: cannot stat './ImageInfo-storlink_sl93512r': No such file or directory

This is because the script "Build/storlink-default-images" expects to have
a "target/linux/gemini/image/ImageInfo-storlink_sl93512r".

@Linus: Can you please make a patch that adds the missing file?

Regards,
Christian

> ---
>  target/linux/gemini/image/Makefile | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/target/linux/gemini/image/Makefile 
> b/target/linux/gemini/image/Makefile
> index 5901bbf0c9b2..7b5faa04fd0e 100644
> --- a/target/linux/gemini/image/Makefile
> +++ b/target/linux/gemini/image/Makefile
> @@ -74,14 +74,15 @@ define Build/wiligear-image
>   mv $@.new $@
>  endef
>  
> -# Create the special NAS4220B and Itian Square One SQ201 image
> -# format with the squashfs and overlay inside the "rd.gz" file.
> +# Create the default image format used by the StorLink reference design
> +# SL93512r, Raidsonic NAS4220B and Itian Square One SQ201
> +# with the squashfs and overlay inside the "rd.gz" file.
>  # We pad it out to 6144K which is the size of the initramfs partition.
>  #
>  # The "application" partition is just blank. You can put anything
>  # there when using OpenWRT. We just use that to create the
>  # "sysupgrade" firmware image.
> -define Build/nas4220b-sq201-images
> +define Build/storlink-default-images
>   mkdir -p $@.tmp
>  
>   mv $@ $@.tmp/rd.gz
> @@ -162,15 +163,16 @@ define Device/dlink_dns-313
>  endef
>  TARGET_DEVICES += dlink_dns-313
>  
> -define Device/itian-raidsonic
> +# Default images setup used by the StorLink reference designs
> +define Device/storlink-reference
>   IMAGES := factory.bin
>   IMAGE/factory.bin := append-rootfs | pad-rootfs | pad-to 6144k | \
> - nas4220b-sq201-images $(1)
> + storlink-default-images $(1)
>   DEVICE_PACKAGES := $(GEMINI_NAS_PACKAGES)
>  endef
>  
>  define Device/itian_sq201
> - $(Device/itian-raidsonic)
> + $(Device/storlink-reference)
>   DEVICE_TITLE := ITian Square One SQ201
>   DEVICE_DTS := gemini-sq201
>   DEVICE_PACKAGES += kmod-rt61-pci kmod-usb2-pci
> @@ -178,13 +180,21 @@ endef
>  TARGET_DEVICES += itian_sq201
>  
>  define Device/raidsonic_ib-4220-b
> - $(Device/itian-raidsonic)
> + $(Device/storlink-reference)
>   DEVICE_TITLE := Raidsonic NAS IB-4220-B
>   DEVICE_DTS := gemini-nas4220b
>   DEVICE_TYPE := nas
>  endef
>  TARGET_DEVICES += raidsonic_ib-4220-b
>  
> +define Device/storlink-sl93512r
> + $(Device/storlink-reference)
> + DEVICE_TITLE := StorLink SL93512r
> + DEVICE_DTS := gemini-sl93512r
> +endef
> +TARGET_DEVICES += storlink_sl93512r
> +
> +
>  # The wiliboard images need some changes to be functional and buildable.
>  #
>  # The dts would need to use the ecoscentric,redboot-fis-partitions partition
> 





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


[OpenWrt-Devel] [PATCH] mpc85xx: Use gzip compressed kernel on HiveAP-330

2019-07-05 Thread Christian Lamparter
From: Pawel Dembicki 

After commit 1e41de2f48 ("mpc85xx: convert TL-WDR4900 v1 to simpleImage")
XZ compression of zImage was enabled. This change exposed a problem with
the HiveAP-330 images, which was fixed by foregoing the compression on
the kernel altogether with commit 98089bb8ba8
("mpc85xx: Use uncompressed kernel on the HiveAP-330").

This patch adds back the gzip compression of the kernel image by
utilizing the generic OpenWRT uImage method instead of relying on
the PowerPC bootwrapper script that did it previously.

Compile-tested: p1020/hiveap-330

Tested-by: Chris Blake  [run-tested]
Signed-off-by: Pawel Dembicki 
Signed-off-by: Christian Lamparter 
[filled in even more text]
---
 target/linux/mpc85xx/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/mpc85xx/image/Makefile 
b/target/linux/mpc85xx/image/Makefile
index c582d7a5920..c2ddcb32c5c 100644
--- a/target/linux/mpc85xx/image/Makefile
+++ b/target/linux/mpc85xx/image/Makefile
@@ -85,7 +85,7 @@ define Device/hiveap-330
   DEVICE_TITLE := Aerohive HiveAP-330
   DEVICE_PACKAGES := kmod-tpm-i2c-atmel
   BLOCKSIZE := 128k
-  KERNEL := kernel-bin | uImage none
+  KERNEL := kernel-bin | gzip | uImage gzip
   KERNEL_SIZE := 8m
   KERNEL_INITRAMFS := copy-file $(KDIR)/vmlinux-initramfs | uImage none
   SUPPORTED_DEVICES := aerohive,hiveap-330

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


Re: [OpenWrt-Devel] [PATCHv2] toolchain: Don't force GCC8 on ARC

2019-07-05 Thread Christian Lamparter
On Wednesday, July 3, 2019 10:16:51 PM CEST Rosen Penev wrote:
> When selecting GCC9 under Advanced options, GCC8 still gets selected.
> 
> Signed-off-by: Rosen Penev 
Looks like we came to the same conclusion (see date).

https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=a03fe6d029d81c8ed6a5cd97603f975acf6731d5


> ---
>  v2: Allow selecting GCC9 but not 7 and below
>  toolchain/gcc/Config.version | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> index ef9bbb82e2..2a9dc289db 100644
> --- a/toolchain/gcc/Config.version
> +++ b/toolchain/gcc/Config.version
> @@ -4,7 +4,7 @@ config GCC_VERSION_5
>  
>  config GCC_VERSION_8
>   default y if GCC_USE_VERSION_8
> - default y if arc
> + default y if arc && !GCC_USE_VERSION_9
>   bool
>  
>  config GCC_VERSION_9
> 





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


Re: [OpenWrt-Devel] [PATCH] toolchain: Don't force GCC8 on ARC

2019-06-25 Thread Christian Lamparter
On Monday, June 24, 2019 11:03:23 PM CEST Christian Lamparter wrote:
> On Monday, June 24, 2019 10:01:51 PM CEST Rosen Penev wrote:
> > On Mon, Jun 24, 2019 at 1:00 PM Christian Lamparter  
> > wrote:
> > >
> > > On Saturday, June 22, 2019 8:57:32 PM CEST Rosen Penev wrote:
> > > > On Sat, Jun 22, 2019 at 7:37 AM Christian Lamparter 
> > > >  wrote:
> > > > >
> > > > > On Thursday, June 20, 2019 9:33:04 PM CEST Rosen Penev wrote:
> > > > > > This prevents overriding it to use GCC9.
> > > > > >
> > > > > > Signed-off-by: Rosen Penev 
> > > > > > ---
> > > > > >  toolchain/gcc/Config.version | 1 -
> > > > > >  1 file changed, 1 deletion(-)
> > > > > >
> > > > > > diff --git a/toolchain/gcc/Config.version 
> > > > > > b/toolchain/gcc/Config.version
> > > > > > index ef9bbb82e2..e635244827 100644
> > > > > > --- a/toolchain/gcc/Config.version
> > > > > > +++ b/toolchain/gcc/Config.version
> > > > > > @@ -4,7 +4,6 @@ config GCC_VERSION_5
> > > > > >
> > > > > >  config GCC_VERSION_8
> > > > > >   default y if GCC_USE_VERSION_8
> > > > > > - default y if arc
> > > > > >   bool
> > > > > >
> > > > > >  config GCC_VERSION_9
> > > > > >
> > > > > From what I know this would select the default GCC 7.4.
> > > > It does. On the other hand, if you select Advanced options and select
> > > > to build GCC9, it still builds GCC8.
> > >
> > > Yes, problem here are the buildbots. They always go with the default
> > > so they would upload images compiled with a broken compiler.
> > >
> > > There seems to be also a interaction with toolchain/gcc/Config.in
> > >
> > > |choice
> > > |prompt "GCC compiler Version" if TOOLCHAINOPTS
> > > |default GCC_USE_VERSION_8 if arc
> > > |default GCC_USE_VERSION_7
> > > |help
> > > |  Select the version of gcc you wish to use.
> > > |
> > > |config GCC_USE_VERSION_5
> > > |bool "gcc 5.x"
> > > |depends on !arc
> > > |
> > > |config GCC_USE_VERSION_7
> > > |bool "gcc 7.x"
> > > |depends on !arc
> > > |
> > > |config GCC_USE_VERSION_8
> > > |bool "gcc 8.x"
> > > |
> > > |config GCC_USE_VERSION_9
> > > |bool "gcc 9.x"
> > > |endchoice
> > >
> > > I guess this means that one needs to be creative and pile on the
> > > other workaround and "fixes". I.e.: something like
> > >
> > > ---
> > > diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> > > index ef9bbb82e2..2a9dc289db 100644
> > > --- a/toolchain/gcc/Config.version
> > > +++ b/toolchain/gcc/Config.version
> > > @@ -4,7 +4,7 @@ config GCC_VERSION_5
> > >
> > >  config GCC_VERSION_8
> > > default y if GCC_USE_VERSION_8
> > > -   default y if arc
> > > +   default y if arc && !GCC_USE_VERSION_9
> > > bool
> > >
> > >  config GCC_VERSION_9
> > > ---
> > >
> > > Question is, do we really want to go down that route? Or is there
> > > a better solution? Because this is ugly.
> > I see no problem as the solution will be short lived (until GCC7 goes away).
> 
> The emphasis was really on "something like". I didn't really test this
> properly, so I don't know if it works or has other implications.

Well, I've added the patches to my staging tree for now.
If there's no objection I'm probably going to merged them this weekend.

"toolchain: Don't force GCC8 on ARC"
<https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=fb5958dbd33c51a7ac5e7c3201f4e828b055e9e7>

"gdb-arc: Remove"
<https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=c91519b30fc38ba5ad45066b9c7d4ca0a609a78f>

"gdb: Remove !arc dependency"
<https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=2bf178a2eac10364defa32928877d37d371ae51f>

Regards,
Christian



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


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

2019-06-25 Thread Christian Lamparter
Hi David,

On Monday, June 24, 2019 10:00:06 PM CEST David Bauer wrote:
> Hello Christian,
> >> +
> >> +  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.

Well, from what I can tell the gpio in the apm821xx works differently
than that of the ath79... and the mt7621 will be different as well.

I wonder if making the change brought just enough attention to the
driver and everyone just checked and found some hidden issues.
 
> While we are at it - i haven't forgotten about this one but due to 
> hardware issues, testing is currently a bit cumbersome.

No sweat :) (Yes, it's already too hot). 
 
> > 
> >> +  poll-interval = <20>;
> >> +
> >> +  wps {
> >> +  label = "wps";
> >> +  gpios = < 11 GPIO_ACTIVE_HIGH>;
> >> +  linux,code = ;
> >> +  };
> >> +
> >> +  reset {
> >> +  label = "reset";
> >> +  gpios = < 9 GPIO_ACTIVE_LOW>;
> >> +  linux,code = ;
> >> +  };
> >> +  };
> >> +
> >> +  led-regulator {
> >> +  compatible = "regulator-fixed";
> >> +  regulator-name = "LED-Power";
> >> +  gpio = < 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?

I think we should extend LuCI & friends so it can switch on/off these
regulators ;). (Note: we probably don't want to mess with all regulators
, usb-regulators for example should be controlled by the driver).
> >> +  };
> >> +};
> >> +
> >> + {
> >> +  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?

Is 10MHz even a supported frequency for the SPI-NOR chip? From what I know
the problem arose because of the dodgy 50MHz value for the sysclock for the
MT7621 (I think it's 200 MHz so it's 4 times as fast).

If you look into the mt7621 datasheet you see that the SPI frequency is
generated from the sysclock and the driver just sets the divisor. So the
"10 MHz" spi frequency would actually be "40" MHz".

I think you can measure the time it takes to read the SPI-NOR and check
if the KiB/s match with the selected frequency or not.

(That said, this is wrong on so many other ramips. so.)

Cheers,
Christian



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


Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-001

2019-06-25 Thread Christian Lamparter
On Tuesday, June 25, 2019 10:34:47 AM CEST Daniel Danzberger wrote:
> 
> On 6/24/19 10:17 PM, Christian Lamparter wrote:
> >> diff --git a/target/linux/ramips/dts/AP7621-001.dts 
> >> b/target/linux/ramips/dts/AP7621-001.dts
> >> new file mode 100644
> >> index 00..daab06ec90
> >> --- /dev/null
> >> +++ b/target/linux/ramips/dts/AP7621-001.dts
> >> @@ -0,0 +1,127 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> >> +
> >> +/dts-v1/;
> >> +#include "mt7621.dtsi"
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +/ {
> >> +  compatible = "asiarf,ap7621-001", "mediatek,mt7621-soc";
> >> +  model = "AP7621-001";
> > 
> > Oh boy, this is tricky.
> > 
> > <https://github.com/devicetree-org/devicetree-specification/blob/4b1dac80eaca45b4babf5299452a951008a5d864/source/devicenodes.rst>
> > 'The recommended format ' (for the root node!) ' is 
> > "manufacturer,model-number".'
> > 
> > BUT. Thing is, this string here gets printed on the LuCI system
> > page and from past experience "Manufacturer Model" works best.
> >
> I am not sure if using a blank instead of ',' is a good idea, because of
> sysupgrade and the device tree board detection.
> All other DTS files use ',' in DTS and '_' in their Makefile.
> 
> Are you sure about this one ?
> 
Hm, I think this is a misunderstanding?
The compatible "asiarf,ap7621-001" is fine. But the "model" property could use
the manufacturer.

(Note: The sysupgrade codes uses the first compatible string, not the model)

Cheers,
Christian



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


Re: [OpenWrt-Devel] [PATCH] toolchain: Don't force GCC8 on ARC

2019-06-24 Thread Christian Lamparter
On Monday, June 24, 2019 10:01:51 PM CEST Rosen Penev wrote:
> On Mon, Jun 24, 2019 at 1:00 PM Christian Lamparter  
> wrote:
> >
> > On Saturday, June 22, 2019 8:57:32 PM CEST Rosen Penev wrote:
> > > On Sat, Jun 22, 2019 at 7:37 AM Christian Lamparter  
> > > wrote:
> > > >
> > > > On Thursday, June 20, 2019 9:33:04 PM CEST Rosen Penev wrote:
> > > > > This prevents overriding it to use GCC9.
> > > > >
> > > > > Signed-off-by: Rosen Penev 
> > > > > ---
> > > > >  toolchain/gcc/Config.version | 1 -
> > > > >  1 file changed, 1 deletion(-)
> > > > >
> > > > > diff --git a/toolchain/gcc/Config.version 
> > > > > b/toolchain/gcc/Config.version
> > > > > index ef9bbb82e2..e635244827 100644
> > > > > --- a/toolchain/gcc/Config.version
> > > > > +++ b/toolchain/gcc/Config.version
> > > > > @@ -4,7 +4,6 @@ config GCC_VERSION_5
> > > > >
> > > > >  config GCC_VERSION_8
> > > > >   default y if GCC_USE_VERSION_8
> > > > > - default y if arc
> > > > >   bool
> > > > >
> > > > >  config GCC_VERSION_9
> > > > >
> > > > From what I know this would select the default GCC 7.4.
> > > It does. On the other hand, if you select Advanced options and select
> > > to build GCC9, it still builds GCC8.
> >
> > Yes, problem here are the buildbots. They always go with the default
> > so they would upload images compiled with a broken compiler.
> >
> > There seems to be also a interaction with toolchain/gcc/Config.in
> >
> > |choice
> > |prompt "GCC compiler Version" if TOOLCHAINOPTS
> > |default GCC_USE_VERSION_8 if arc
> > |default GCC_USE_VERSION_7
> > |help
> > |  Select the version of gcc you wish to use.
> > |
> > |config GCC_USE_VERSION_5
> > |bool "gcc 5.x"
> > |depends on !arc
> > |
> > |config GCC_USE_VERSION_7
> > |bool "gcc 7.x"
> > |depends on !arc
> > |
> > |config GCC_USE_VERSION_8
> > |bool "gcc 8.x"
> > |
> > |config GCC_USE_VERSION_9
> > |bool "gcc 9.x"
> > |endchoice
> >
> > I guess this means that one needs to be creative and pile on the
> > other workaround and "fixes". I.e.: something like
> >
> > ---
> > diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> > index ef9bbb82e2..2a9dc289db 100644
> > --- a/toolchain/gcc/Config.version
> > +++ b/toolchain/gcc/Config.version
> > @@ -4,7 +4,7 @@ config GCC_VERSION_5
> >
> >  config GCC_VERSION_8
> > default y if GCC_USE_VERSION_8
> > -   default y if arc
> > +   default y if arc && !GCC_USE_VERSION_9
> > bool
> >
> >  config GCC_VERSION_9
> > ---
> >
> > Question is, do we really want to go down that route? Or is there
> > a better solution? Because this is ugly.
> I see no problem as the solution will be short lived (until GCC7 goes away).

The emphasis was really on "something like". I didn't really test this
properly, so I don't know if it works or has other implications.

Cheers,
Christian



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


Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-ar750

2019-06-24 Thread Christian Lamparter
On Monday, June 24, 2019 10:41:37 AM CEST Luochongjun wrote:
> This patch support gl-ar750 on ath79.

I'm looking at this previous patch for the GL-X750.


And I think you can do better than this gl-ar750 post.

Can you please take the time and amend your patch with the
specification and a short description on how the flash the
initial image. Thanks.

More comments down below.

> 
> Signed-off-by: Luo chongjun 
Please make sure your Name matches exactly (as in bit-for-bit) that of
your E-Mail Client address. Otherwise this needs to be fixed by the
commiter since the openwrt infrastructure does a checks that.

> ---
>  .../etc/hotplug.d/firmware/11-ath10k-caldata   |   1 +
>  target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts | 149 
> +
>  target/linux/ath79/image/generic.mk|   8 ++
>  3 files changed, 158 insertions(+)
>  create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
> 
> diff --git 
> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
> b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 8f0ea1d..6a9cb1c 100644
> --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -116,6 +116,7 @@ case "$FIRMWARE" in
>   ath10kcal_extract "art" 20480 2116
>   ath10kcal_patch_mac $(macaddr_add $(cat 
> /sys/class/net/eth0/address) +1)
>   ;;
> + glinet,gl-ar750|\
>   glinet,gl-ar750s)
>   ath10kcal_extract "art" 20480 2116
>   ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0) 
> +1)
> diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts 
> b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
> new file mode 100644
> index 000..c173f0d
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include 
> +#include 
> +
> +#include "qca953x.dtsi"
> +
> +/ {
> + compatible = "glinet,gl-ar750", "qca,qca9531";
> + model = "GL.iNet GL-AR750";
> +
> + keys {
> + compatible = "gpio-keys-polled";
ath79 should support "gpio-keys".

> +
> + poll-interval = <20>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_disable_pins>;
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + mode {
> +label = "mode";
> +linux,code = ;
> +gpios = < 0 GPIO_ACTIVE_LOW>;
> +};
Please use tabs instead of space for indent.
(scripts/checkpatch.pl can help you find these cases).
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "gl-ar750:green:power";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> +
> + wlan2g {
> + label = "gl-ar750:green:wlan2g";
> + gpios = < 14 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy1tpt";
> + };
> +
> + wlan5g {
> + label = "gl-ar750:green:wlan5g";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0tpt";
> + };
> +
> + };
> +
> +   i2c {
> +compatible = "i2c-gpio";
> +
> +sda-gpios = < 17 GPIO_ACTIVE_LOW>;
> +scl-gpios = < 16 GPIO_ACTIVE_LOW>;
> +
> +/* can be removed on 4.19 */
> +gpios = < 17 GPIO_ACTIVE_LOW>,
> +< 16 GPIO_ACTIVE_LOW>;
Hm, ath79 switched to 4.19. So they can be removed right now ;)
> +
> +};
> +
> +
> +};
> +
> + {
> + status = "okay";
Please add a proper sub node with the right ath10k compatible
(see qcom,ath10k.txt) for the attached pcie chip here.

> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + hub_port: port@1 {
> + reg = <1>;
> + #trigger-source-cells = <0>;
> + };
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + num-cs = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + 

Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-001

2019-06-24 Thread Christian Lamparter
On Monday, June 24, 2019 6:13:20 PM CEST Daniel Danzberger wrote:
> SoC:Mediatek MT7621A
> CPU:4x 880Mhz
> Cache:  32 KB I-Cache and 32 KB D-Cach
> 256 KB L2 Cache (shared by Dual-Core)
> RAM:DDR3 512MB 16bits BUS
> FLASH:  16MB
> Switch: Mediatek Gigabit Switch (1 x LAN, 1 x WAN)
> USB:1x 3.0
> PCI:3x Mini PCIe
> GPS:Quectel L70B
> BTN:Reset
> LED:- Power
> - Ethernet
> - Wifi
> - USB
> UART:  UART is present as Pads with throughholes on the PCB.
>  They are located on left side.
>3.3V - RX - GND - TX / 57600-8N1
>3.3V is the square pad
> 
> Installation
> 
> The stock image is a modified openwrt and can be overflashed via 
> sysupgrade -F
> 
> Signed-off-by: Daniel Danzberger 
> ---
>  .../ramips/base-files/etc/board.d/02_network  |   3 +
>  target/linux/ramips/dts/AP7621-001.dts| 127 ++
>  target/linux/ramips/image/mt7621.mk   |  10 ++
>  3 files changed, 140 insertions(+)
>  create mode 100644 target/linux/ramips/dts/AP7621-001.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..ffd1689263 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -39,6 +39,9 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
> "6@eth0"
>   ;;
> + asiarf,ap7621-001)
> + ucidef_add_switch "switch0" "0:lan" "4:wan" "6@eth0"
> + ;;
>   3g150b|\
>   3g300m|\
>   a5-v11|\
> diff --git a/target/linux/ramips/dts/AP7621-001.dts 
> b/target/linux/ramips/dts/AP7621-001.dts
> new file mode 100644
> index 00..daab06ec90
> --- /dev/null
> +++ b/target/linux/ramips/dts/AP7621-001.dts
> @@ -0,0 +1,127 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +/dts-v1/;
> +#include "mt7621.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "asiarf,ap7621-001", "mediatek,mt7621-soc";
> + model = "AP7621-001";

Oh boy, this is tricky.


'The recommended format ' (for the root node!) ' is 
"manufacturer,model-number".'

BUT. Thing is, this string here gets printed on the LuCI system
page and from past experience "Manugacturer Model" works best.

> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x1c00>, <0x2000 0x400>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,57600";
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 18 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + wlan1 {
> + label = "ap7621-001:orange:wlan1";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + wlan0 {
> + label = "ap7621-001:orange:wlan0";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> +status = "okay";
please use tabs here.

> +
> +flash@0 {
> +compatible = "jedec,spi-nor";
> +reg = <0>;
> +spi-max-frequency = <4000>;
> +
> + partitions {
this needs one more tab.
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
please use tabs to ident most of the properies 
for the rest of the node. (scripts/checkpatch.pl will
catch those lines)

> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "u-boot-env";
> + reg = <0x3 0x2000>;
needs read-only;
> + };
> +
> + partition@32000 {
> + label = "2860";
> + reg = <0x32000 0x4000>;
needs read-only;

> + };
> +
> + partition@36000 {
> + label = "rtdev";
> + reg = <0x36000 0x2000>;
needs read-only;

> + };
> +
> + 

Re: [OpenWrt-Devel] [PATCH] toolchain: Don't force GCC8 on ARC

2019-06-24 Thread Christian Lamparter
On Saturday, June 22, 2019 8:57:32 PM CEST Rosen Penev wrote:
> On Sat, Jun 22, 2019 at 7:37 AM Christian Lamparter  
> wrote:
> >
> > On Thursday, June 20, 2019 9:33:04 PM CEST Rosen Penev wrote:
> > > This prevents overriding it to use GCC9.
> > >
> > > Signed-off-by: Rosen Penev 
> > > ---
> > >  toolchain/gcc/Config.version | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> > > index ef9bbb82e2..e635244827 100644
> > > --- a/toolchain/gcc/Config.version
> > > +++ b/toolchain/gcc/Config.version
> > > @@ -4,7 +4,6 @@ config GCC_VERSION_5
> > >
> > >  config GCC_VERSION_8
> > >   default y if GCC_USE_VERSION_8
> > > - default y if arc
> > >   bool
> > >
> > >  config GCC_VERSION_9
> > >
> > From what I know this would select the default GCC 7.4.
> It does. On the other hand, if you select Advanced options and select
> to build GCC9, it still builds GCC8.

Yes, problem here are the buildbots. They always go with the default
so they would upload images compiled with a broken compiler.

There seems to be also a interaction with toolchain/gcc/Config.in

|choice
|prompt "GCC compiler Version" if TOOLCHAINOPTS
|default GCC_USE_VERSION_8 if arc
|default GCC_USE_VERSION_7
|help
|  Select the version of gcc you wish to use.
|
|config GCC_USE_VERSION_5
|bool "gcc 5.x"
|depends on !arc
|
|config GCC_USE_VERSION_7
|bool "gcc 7.x"
|depends on !arc
|
|config GCC_USE_VERSION_8
|bool "gcc 8.x"
|
|config GCC_USE_VERSION_9
|bool "gcc 9.x"
|endchoice

I guess this means that one needs to be creative and pile on the
other workaround and "fixes". I.e.: something like

---
diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
index ef9bbb82e2..2a9dc289db 100644
--- a/toolchain/gcc/Config.version
+++ b/toolchain/gcc/Config.version
@@ -4,7 +4,7 @@ config GCC_VERSION_5
 
 config GCC_VERSION_8
default y if GCC_USE_VERSION_8
-   default y if arc
+   default y if arc && !GCC_USE_VERSION_9
bool
 
 config GCC_VERSION_9
---

Question is, do we really want to go down that route? Or is there
a better solution? Because this is ugly.

Regards,
Christian



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


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

2019-06-24 Thread Christian Lamparter
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" ?
(From what I know, the machine compatible isn't important
but the ralink,mt7620a-soc looks odd)

> + model = "ASUS RT-AC57U";
> +
> + aliases {
> + led-boot = _power;
> + led-failsafe = _power;
> + led-running = _power;
> + led-upgrade = _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 = < 16 GPIO_ACTIVE_LOW>;
> + };
> +
> + usb {
> + label = "rt-ac57u:blue:usb";
> + gpios = < 15 GPIO_ACTIVE_LOW>;
> + trigger-sources = <_port2>;
> + linux,default-trigger = "usbport";
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys-polled";
The MT7261 should support interrupt-supported gpio-keys.

> + poll-interval = <20>;
> +
> + wps {
> + label = "wps";
> + gpios = < 11 GPIO_ACTIVE_HIGH>;
> + linux,code = ;
> + };
> +
> + reset {
> + label = "reset";
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + led-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "LED-Power";
> + gpio = < 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?

> + };
> +};
> +
> + {
> + 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

> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "config";
> + reg = <0x3 0x1>;
> + read-only;
> + };
> +
> + factory: partition@4 {
> + label = "factory";
> + reg = <0x4 0x1>;
> + read-only;
> + };
> +
> + partition@5 {
> + compatible = "denx,uimage";
> + label = "firmware";
> + reg = <0x5 0xfb>;
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + wifi@0,0 {
> + reg = <0x 0 0 0 0>;
Please add a compatible. (Binding text lists the right one).

> + mediatek,mtd-eeprom = < 0x8000>;
> +
> + led {
> + led-sources = <2>;
> + led-active-low;
> + };
> + };
> +};
> +
> + {
> + wifi@0,0 {
> + reg = <0x 0 0 0 0>;
Please add a compatible. (Binding text lists the right one).
> + mediatek,mtd-eeprom = < 0x>;
> +
> + led {
> + led-active-low;
> + };
> + };
> +};
> +
> + {
> + mtd-mac-address = < 0x4e000>;
> +};
> +
> + {
> + state_default: pinctrl0 {
> + gpio {
> + ralink,group = "sdhci";
> + ralink,function = 

Re: [OpenWrt-Devel] [PATCH] toolchain: Don't force GCC8 on ARC

2019-06-22 Thread Christian Lamparter
On Thursday, June 20, 2019 9:33:04 PM CEST Rosen Penev wrote:
> This prevents overriding it to use GCC9.
> 
> Signed-off-by: Rosen Penev 
> ---
>  toolchain/gcc/Config.version | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> index ef9bbb82e2..e635244827 100644
> --- a/toolchain/gcc/Config.version
> +++ b/toolchain/gcc/Config.version
> @@ -4,7 +4,6 @@ config GCC_VERSION_5
>  
>  config GCC_VERSION_8
>   default y if GCC_USE_VERSION_8
> - default y if arc
>   bool
>  
>  config GCC_VERSION_9
> 
>From what I know this would select the default GCC 7.4.
Do you know if the special ARC patches got into the 7.x branch?
Because from what I can tell (from 7.1) this was a problem and
the reason why GCC 8 was selected since it had the patches from
the beginning.

Regards,
Christian



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


  1   2   3   4   >