[PATCH 1/2] ipq806x: chromium: Disable kernel's CONFIG_QCOM_SPM

[Brian Norris]

The qcom spm driver is currently broken for IPQ8064 OnHub devices on
kernel 6.1, such that it hangs the system when booting, much to the
consternation of users. This is especially bad as these devices don't
yet have a fully-supported release branch, and are still sometimes
landing on snapshot builds.

OnHub devices have their own kernel config, so it's not that wide of an
impact to disable this.

I haven't fully gotten to the bottom of this, but:

(a) The vendor kernel didn't have any SPM driver at all, and didn't
utilize cpuidle.
(b) The device tree has never included any (non-disabled) cpuidle
states, so even when this driver was present on 5.15 (last
known-working kernel), it didn't actually do anything -- it bailed
early, before ever doing any SPM initialization.
(c) Refactoring in Linux 5.16 [1] caused the SPM driver to be activated
unconditionally, including setting us into standby mode
(PM_SLEEP_MODE_STBY) by default.

Removing the one PM_SLEEP_MODE_STBY line from drivers/soc/qcom/spm.c
seems to fix the problem, but that isn't much different than simply
disabling the driver, so I go with that for now.

I also disable CONFIG_ARM_QCOM_SPM_CPUIDLE, becuase it 'select's
QCOM_SPM.

NB: it's possible there's some other deeper root cause involved in here.
For one, I notice that CPU hotplug (e.g., echo 0 >
/sys/devices/system/cpu/cpu1/online, echo 1 > ...) doesn't work right
either. Perhaps there's some mismatch on upstream Linux qcom-scm
behavior and the old boot firmware used for these systems? It wouldn't
be the first time, as we've had some similar incompatibilities on the
next generation of these devices, Google WiFi [2].

[1] Commit 60f3692b5f0b ("cpuidle: qcom_spm: Detach state machine from
main SPM handling")
[2] [RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
https://lore.kernel.org/linux-arm-kernel/20200913201608.GA3162100@bDebian/

Signed-off-by: Brian Norris 
---

 target/linux/ipq806x/chromium/config-default | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/ipq806x/chromium/config-default 
b/target/linux/ipq806x/chromium/config-default
index d7db9f7db35a..927aba360f4a 100644
--- a/target/linux/ipq806x/chromium/config-default
+++ b/target/linux/ipq806x/chromium/config-default
@@ -1,7 +1,9 @@
+# CONFIG_ARM_QCOM_SPM_CPUIDLE is not set
 CONFIG_BLK_DEV_SD=y
 CONFIG_LEDS_LP5523=y
 CONFIG_LEDS_LP55XX_COMMON=y
 CONFIG_PHY_QCOM_IPQ806X_USB=y
+# CONFIG_QCOM_SPM is not set
 CONFIG_SCSI=y
 CONFIG_SCSI_COMMON=y
 CONFIG_SG_POOL=y
-- 
2.40.1


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

[PATCH 2/2] ipq806x: onhub: Enable adm_dma node

[Brian Norris]

One of our SPI devices references this node, but we never enabled it.
This clutters up probe deferral logs.

(NB: this SPI device still doesn't have a real driver, so it's just here
for documentation and/or tinkering.)

Signed-off-by: Brian Norris 
---

 .../ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi   | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi 
b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
index 549c46202619..536610595474 100644
--- a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
+++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
@@ -288,6 +288,10 @@
};
 };
 
+_dma {
+   status = "okay";
+};
+
  {
status = "okay";
phy-mode = "rgmii";
-- 
2.40.1


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

Re: [PATCH] ipq40xx: google (gale) add LED aliases

[Brian Norris]

Hi,

On Mon, Mar 27, 2023 at 07:29:39AM +0200, open...@aiyionpri.me wrote:
> From: Jan-Niklas Burfeind 
> 
> this is similar to
> commit 583ac0e11df7 ("mpc85xx: update lp5521 led-controller node for
> 5.10")
> 
> Google uses white for running and red for an issue
> 
> Signed-off-by: Jan-Niklas Burfeind 
> ---
> Good morning.
> 
> Currently the tristate LED does not have an assigned function,
> while it does have several in stock firmware.
> 
> Once the multi-intensity section becomes active, the device should use
> white/blueish light as running indicator.
> For now blue is used for LED_RUNNING.
> 
> If there's a way to use white instead of blue, just let me know;
> I'd gladly fix that at once.

I'll admit, I wasn't familiar with these led-* aliases (and the custom
package/base-files/files/lib/functions/leds.sh that parses them) until
now. But it looks like they only support a single LED for a given
function, so while we might like to enable the red, blue and green (to
get white), that doesn't seem possible without switching over the to
full multi-color LED device tree binding. But then, I don't think LUCI
knows how to configure multi-color LEDs yet.

I guess the choices you made here are better than the "nothing" that is
currently here, so:

Reviewed-by: Brian Norris 

One more note below:

> --- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
> +++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts

> @@ -255,12 +259,13 @@
>   clock-mode = /bits/ 8 <1>;
>  
>  #if 1
> - led@0 {
> + led0_red: led@0 {
>   reg = <0>;
>   chan-name = "LED0_Red";
>   led-cur = /bits/ 8 <0x64>;
>   max-cur = /bits/ 8 <0x78>;
>   color = ;
> + function = LED_FUNCTION_FAULT;

Are you sure this 'function' property is actually doing anything? I know
the common DT bindings provide this, but I'm pretty sure the lp5523
driver doesn't actually use it for anything -- it derives its LED names
from either 'chan-name' or as a combination of a few other properties
('label', channel number, etc.).

I guess it's not wrong, per se, to include it, but I did purposely only
specify the properties that made sense for this driver.

Same comment applies to the other 'function' uses.

Brian

>   };
>  
>   led@1 {
> @@ -271,12 +276,13 @@
>   color = ;
>   };
>  
> - led@2 {
> + led0_blue: led@2 {
>   reg = <2>;
>   chan-name = "LED0_Blue";
>   led-cur = /bits/ 8 <0x64>;
>   max-cur = /bits/ 8 <0x78>;
>   color = ;
> + function = LED_FUNCTION_POWER;
>   };
>  #else
>   /*
> @@ -285,6 +291,7 @@
>* # echo 255 > /sys/class/leds/tricolor/brightness
>*/
>   multi-led@2 {
> + function = LED_FUNCTION_POWER;
>   reg = <2>;
>   color = ;
>   #address-cells = <1>;
> -- 
> 2.40.0
> 

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

Re: [PATCH v2] ipq40xx: google (gale) add reset button

[Brian Norris]

On Sun, Mar 26, 2023 at 10:50:42PM +0200, open...@aiyionpri.me wrote:
> From: Jan-Niklas Burfeind 
> 
> add the external button (GPIO 57) as reset button
> 
> Co-authored-by: Brian Norris 
> Signed-off-by: Jan-Niklas Burfeind 
> ---
> 
> I added the phandle for fw_pinmux and used it as you suggested.
> Furthermore added the function gpio similar to your referenced PR.
> 
> Hopefully this reflects your intentions.
> 
> I just compiled and tested it again, resetting still works with the
> added changes.
> 
> Have a nice evening everyone and thanks for reviewing this
> aiyion

Thanks for the v2. Looks and works fine for me:

Reviewed-by: Brian Norris 
Tested-by: Brian Norris 

I think you have an extra space in the patch subject, but presumably
somebody could fix that one up when committing it for real.

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

Re: [PATCH] ipq40xx: google (gale) add reset button

[Brian Norris]

Hey,

On Sun, Mar 26, 2023 at 6:29 AM  wrote:
>
> From: Jan-Niklas Burfeind 
>
> add the external button (GPIO 57) as reset button
>
> Signed-off-by: Jan-Niklas Burfeind 
> ---
>
> Good afternoon everyone.
> This is just a minor addition to the google wifi router
> OpenWrt supports.
>
> I hope I didn't miss anything.
>
> Yours
> aiyion

Thanks for doing this! This looks pretty good, although I'd make a
small addition. See below:

>  .../files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts  | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git 
> a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts 
> b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
> index 65f5933305..85ce73afb3 100644
> --- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
> +++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
> @@ -49,6 +49,16 @@
> };
> };
> };
> +
> +   keys {
> +   compatible = "gpio-keys";
> +
> +   reset {
> +   label = "reset";
> +   gpios = < 57 GPIO_ACTIVE_LOW>;

Normally, you want a pinctrl setting too, to tell the pin controller
how to configure any biases, pull-ups/downs, etc. In this case, the
configuration is trivial, so it probably doesn't make much difference,
but for completeness, we should still add it. See how below we have
this pinmux definition already:

fw_pinmux {
  wp {
pins = "gpio53";
output-low;
  };
  recovery {
pins = "gpio57";
bias-none;
  };
  developer {
pins = "gpio41";
bias-none;
  };
};

So, you just need to add a phandle reference, and it'll look something like:

keys {
  compatible = "gpio-keys";
  pinctrl-0 = <_pinmux>;
  pinctrl-names = "default";
  ...
};
...
fw_pinmux: fw_pinmux {
  recovery {
...
  };
};

You can see an approximately similar change I made recently here:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=4c1d7787d460cd0798eb01a42c6a8a7fc96e2999

If you have trouble with that, I can play with it myself and send an
updated version 2.

Thanks,
Brian

> +   linux,code = ;
> +   };
> +   };
>  };
>
>   {
> --
> 2.40.0
>

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

[PATCH] ipq806x: Add buttons to OnHub

[Brian Norris]

From: Alan Luck 

These are the factory reset button (external) and "developer mode"
button (hidden inside the case (ASUS) or under a screw in the base
(TP-Link)) found on the TP-Link and ASUS OnHub devices.

Signed-off-by: Alan Luck 
[Brian: add description; factor out for both ASUS and TP-Link; use
existing pinmux definitions; add keycode for dev button]
Signed-off-by: Brian Norris 
---

 .../arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi | 28 +++
 1 file changed, 28 insertions(+)

diff --git 
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi 
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
index 25ba71da00ef..549c46202619 100644
--- a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
+++ b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
@@ -5,6 +5,7 @@
 
 #include "qcom-ipq8064-smb208.dtsi"
 #include 
+#include 
 #include 
 
 / {
@@ -30,6 +31,28 @@
};
};
 
+   keys {
+   compatible = "gpio-keys";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   reset {
+   label = "reset";
+   gpios = <_pinmux 16 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   debounce-interval = <60>;
+   wakeup-source;
+   };
+
+   dev {
+   label = "dev";
+   gpios = <_pinmux 15 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   debounce-interval = <60>;
+   wakeup-source;
+   };
+   };
+
mdio: mdio {
compatible = "virtual,mdio-gpio";
#address-cells = <1>;
@@ -227,12 +250,17 @@
pins = "gpio17";
output-low;
};
+   };
+
+   button_pins: button_pins {
recovery {
pins = "gpio16";
+   function = "gpio";
bias-none;
};
developer {
pins = "gpio15";
+   function = "gpio";
bias-none;
};
};
-- 
2.39.1


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

Re: [PATCH] octeontx: kernel: add USB storage boot support

[Brian Norris]

On Fri, Feb 24, 2023 at 12:18 AM Rafał Miłecki  wrote:
>
>  24 lut 2023 o 00:28 Tim Harvey  napisał(a):
> > Enable BLK_DEV_SD and USB_STORAGE so that rootfs can be on a USB Mass
> > Storage device.
> >
> > This increases the kernel Image by 66KiB
>
> Do we have any device that has firmware installed on USB storage
> device and it boots from it?

Not sure if you're asking specifically about Tim's / octeontx's case
or in general, but see the ipq806x and ipq40xx "chromium" sub-targets.
The Google WiFi and the OnHub devices can boot from USB storage; and
this is the primary way to install OpenWrt on them. Because of kernel
config complaints, I made them separate sub-targets to include
USB_STORAGE drivers.

Brian

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

[PATCH 2/3] ipq806x: chromium: Enable kmod-ramoops by default

[Brian Norris]

Chromium devices (like OnHub) have ramoops memory reserved by the
bootloader. Let's enable the ramoops kernel module by default, so we get
better crash logging.

Signed-off-by: Brian Norris 
---

 target/linux/ipq806x/image/chromium.mk | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/linux/ipq806x/image/chromium.mk 
b/target/linux/ipq806x/image/chromium.mk
index f908472419d1..ba989299760e 100644
--- a/target/linux/ipq806x/image/chromium.mk
+++ b/target/linux/ipq806x/image/chromium.mk
@@ -35,10 +35,14 @@ define Device/OnhubImage
IMAGES := factory.bin sysupgrade.bin
IMAGE/factory.bin := cros-gpt | append-kernel-part | append-rootfs
IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
+   # Note: Chromium/Depthcharge-based bootloaders insert a reserved-memory
+   # ramoops node into the Device Tree automatically, so we can use
+   # kmod-ramoops.
DEVICE_PACKAGES := ath10k-firmware-qca988x-ct e2fsprogs kmod-fs-ext4 
losetup \
   partx-utils mkf2fs kmod-fs-f2fs \
   ucode kmod-google-firmware kmod-tpm-i2c-infineon \
-  kmod-sound-soc-ipq8064-storm kmod-usb-storage
+  kmod-sound-soc-ipq8064-storm kmod-usb-storage \
+  kmod-ramoops
 endef
 
 define Device/asus_onhub
-- 
2.39.1


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

[PATCH 3/3] ipq40xx: chromium: Enable kmod-ramoops by default

[Brian Norris]

Chromium devices (like Google WiFi) have ramoops memory reserved by the
bootloader. Let's enable the ramoops kernel module by default, so we get
better crash logging.

Signed-off-by: Brian Norris 
---

 target/linux/ipq40xx/image/chromium.mk | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/linux/ipq40xx/image/chromium.mk 
b/target/linux/ipq40xx/image/chromium.mk
index 2abd2df02ae4..f6ac69ecf143 100644
--- a/target/linux/ipq40xx/image/chromium.mk
+++ b/target/linux/ipq40xx/image/chromium.mk
@@ -30,7 +30,11 @@ define Device/google_wifi
KERNEL_NAME := zImage
IMAGES += factory.bin
IMAGE/factory.bin := cros-gpt | append-kernel-part | append-rootfs
+   # Note: Chromium/Depthcharge-based bootloaders insert a reserved-memory
+   # ramoops node into the Device Tree automatically, so we can use
+   # kmod-ramoops.
DEVICE_PACKAGES := partx-utils mkf2fs e2fsprogs \
-  kmod-fs-ext4 kmod-fs-f2fs kmod-google-firmware
+  kmod-fs-ext4 kmod-fs-f2fs kmod-google-firmware \
+  kmod-ramoops
 endef
 TARGET_DEVICES += google_wifi
-- 
2.39.1


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

[PATCH 1/3] kernel: kmod-ramoops: Include pstore console support

[Brian Norris]

Pstore ramoops support is useful even when there isn't an explicit
panic/crash. We can log all kernel messages via a "console", and then
retrieve them in the event of some non-kernel-panic reset (e.g.,
watchdog).

Since the buffer memory is already reserved, there isn't much overhead
to doing this.

The new console files will show up as:

  /sys/fs/pstore/console-ramoops-N

Cc: Hannu Nyman 
Signed-off-by: Brian Norris 
---

 package/kernel/linux/modules/other.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index 2bd15dfe67e1..1369a4ad54f1 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -834,7 +834,8 @@ define KernelPackage/ramoops
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Ramoops (pstore-ram)
   DEFAULT:=m if ALL_KMODS
-  KCONFIG:=CONFIG_PSTORE_RAM
+  KCONFIG:=CONFIG_PSTORE_RAM \
+   CONFIG_PSTORE_CONSOLE=y
   DEPENDS:=+kmod-pstore +kmod-reed-solomon
   FILES:= $(LINUX_DIR)/fs/pstore/ramoops.ko
   AUTOLOAD:=$(call AutoLoad,30,ramoops,1)
-- 
2.39.1


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

Re: [PATCH fstools v2] partname: Correct fstools_partname_fallback_scan comparison

[Brian Norris]

Hi Ansuel (or others),

On Wed, Jan 25, 2023 at 10:18 PM Brian Norris
 wrote:
>
> Commit 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
> option") had two problems:
>
> 1. The strcmp() aborted when the param *matched* 1; we wanted the
>inverse
> 2. It was too aggressive about skipping the fallback behavior. For
>devices that had no root= parameter, they would always attempt the
>fallback scan.
>
> Fix both of those.
>
> Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan 
> option")
> Signed-off-by: Brian Norris 

Would you be able to look at this soon? Your emergency fix broke
multiple things, and I'd like to get TP-Link OnHub back in shape so
others can rely on snapshot builds.

Thanks,
Brian

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

[PATCH] kernel: modules: add lkdtm module

[Brian Norris]

Useful for debugging panic/error handling, crash logging, and more.

Signed-off-by: Brian Norris 
---

 package/kernel/linux/modules/other.mk | 16 
 1 file changed, 16 insertions(+)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index c5f944ed3194..2bd15dfe67e1 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -243,6 +243,22 @@ endef
 $(eval $(call KernelPackage,gpio-f7188x))
 
 
+define KernelPackage/lkdtm
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=Linux Kernel Dump Test Tool Module
+  KCONFIG:=CONFIG_LKDTM
+  FILES:=$(LINUX_DIR)/drivers/misc/lkdtm/lkdtm.ko
+  AUTOLOAD:=$(call AutoProbe,lkdtm)
+endef
+
+define KernelPackage/lkdtm/description
+ This module enables testing of the different dumping mechanisms by inducing
+ system failures at predefined crash points.
+endef
+
+$(eval $(call KernelPackage,lkdtm))
+
+
 define KernelPackage/pinctrl-mcp23s08
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Microchip MCP23xxx I/O expander
-- 
2.39.0


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

[PATCH fstools v2] partname: Correct fstools_partname_fallback_scan comparison

[Brian Norris]

Commit 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
option") had two problems:

1. The strcmp() aborted when the param *matched* 1; we wanted the
   inverse
2. It was too aggressive about skipping the fallback behavior. For
   devices that had no root= parameter, they would always attempt the
   fallback scan.

Fix both of those.

Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan 
option")
Signed-off-by: Brian Norris 
---

Changes in v2:
 * Also restore the pre-1ea5855e980c fallback behavior when no root= is
   provided

 libfstools/partname.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f42322a49d5b..004b249a7fdb 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -121,6 +121,8 @@ static struct volume *partname_volume_find(char *name)
char *rootdev = NULL, *devname, *tmp;
int j;
bool found = false;
+   bool allow_fallback = false;
+   bool has_root = false;
glob_t gl;
 
if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname", 
rootparam, sizeof(rootparam))) {
@@ -128,24 +130,29 @@ static struct volume *partname_volume_find(char *name)
return NULL;
}
 
-   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam)) && rootparam[0] == '/') {
+   /*
+* Some device may contains a GPT partition named rootfs_data that may 
not be suitable.
+* To save from regression with old implementation that doesn't use 
fstools_ignore_partname to
+* explicitly say that that partname scan should be ignored, make 
explicit that scanning each
+* partition should be done by providing 
fstools_partname_fallback_scan=1 and skip partname scan
+* in every other case.
+*/
+   if (get_var_from_file("/proc/cmdline", 
"fstools_partname_fallback_scan", rootparam, sizeof(rootparam))) {
+   if (!strcmp("1", rootparam))
+   allow_fallback = true;
+   }
+
+   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam)))
+   has_root = true;
+
+   if (has_root && rootparam[0] == '/') {
rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
} else {
-   /*
-* Some device may contains a GPT partition named rootfs_data 
that may not be suitable.
-* To save from regression with old implementation that doesn't 
use fstools_ignore_partname to
-* explicitly say that that parname scan should be ignored, 
make explicit that scanning each
-* partition should be done by providing 
fstools_partname_fallback_scan=1 and skip partname scan
-* in every other case.
-*/
-   if (!get_var_from_file("/proc/cmdline", 
"fstools_partname_fallback_scan", rootparam, sizeof(rootparam)))
+   /* For compatibility, devices with root= params must explicitly 
opt into this fallback. */
+   if (has_root && !allow_fallback)
return NULL;
-
-   if (!strcmp("1", rootparam))
-   return NULL;
-
/* no useful 'root=' kernel cmdline parameter, find on any 
block device */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
block_dir_name);
}
-- 
2.39.0


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

[PATCH] ipq806x: onhub: Enable fstools_partname_fallback_scan

[Brian Norris]

When fstools is unable to parse our root=<...> arg correctly, it can
fall back to scanning all block devices for a 'rootfs_data' partition.
This fallback was deemed wrong (or at least, a breaking/incompatible
change) for some targets, so we're forced to opt back into it with
fstools_partname_fallback_scan=1.

Without this, OnHub devices will use a rootfs-appended loop device for
rootfs_data instead of the intended 3rd partition.

NB: it would be nice to allow this rootfs_data partition by default in
fstools, but in chats with Ansuel, it sounds like it would be
intractable to locate all potentially-breaking targets programmatically.
Perhaps we can reconsider (and leverage DEVICE_COMPAT_VERSION for the
upgrade-incompatible targets) in the future.

While I'm at it, just move all the boot args into the 'cros-vboot'
build rule, instead of using the custom bootargs-append. All cros-vboot
subtargets here are using the same rootwait (to support both eMMC and
USB boot) and root/partition args.

Signed-off-by: Brian Norris 
---
This patch is only useful once we commit this (and pull in new fstools):
  
https://patchwork.ozlabs.org/project/openwrt/patch/20230125062814.2517900-1-computersforpe...@gmail.com/
  [fstools] partname: Correct fstools_partname_fallback_scan comparison

 .../files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts  | 4 
 .../arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts   | 4 
 target/linux/ipq806x/image/chromium.mk| 4 +++-
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git 
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts 
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts
index 5b60ddb04b3f..442bcf19a675 100644
--- 
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts
+++ 
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts
@@ -11,10 +11,6 @@
 / {
model = "ASUS OnHub";
compatible = "asus,onhub", "google,arkham", "qcom,ipq8064";
-
-   chosen {
-   bootargs-append = " rootwait";
-   };
 };
 
 _pinmux {
diff --git 
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
 
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
index 6dd39f0d9584..6adc6be4aec6 100644
--- 
a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
+++ 
b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
@@ -11,10 +11,6 @@
 / {
model = "TP-Link OnHub";
compatible = "tplink,onhub", "google,whirlwind-sp5", "qcom,ipq8064";
-
-   chosen {
-   bootargs-append = " rootwait";
-   };
 };
 
 _pinmux {
diff --git a/target/linux/ipq806x/image/chromium.mk 
b/target/linux/ipq806x/image/chromium.mk
index 16af6b95ba6c..f908472419d1 100644
--- a/target/linux/ipq806x/image/chromium.mk
+++ b/target/linux/ipq806x/image/chromium.mk
@@ -20,7 +20,9 @@ endef
 # (PARTNROFF=1) partition as their rootfs.
 define Build/cros-vboot
$(STAGING_DIR_HOST)/bin/cros-vbutil \
-   -k $@ -c "root=PARTUUID=%U/PARTNROFF=1" -o $@.new
+   -k $@ \
+   -c "root=PARTUUID=%U/PARTNROFF=1 rootwait 
fstools_partname_fallback_scan=1" \
+   -o $@.new
@mv $@.new $@
 endef
 
-- 
2.39.0


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

Re: [PATCH fstools] partname: Correct fstools_partname_fallback_scan comparison

[Brian Norris]

On Tue, Jan 24, 2023 at 10:28:14PM -0800, Brian Norris wrote:
> We want to return NULL if the param does *not* match 1 -- i.e., a
> non-zero strcmp().
> 
> Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan 
> option")

Hmm, sorry for the quick self-reply, but after rereading, I noticed
there's a second reason commit 1ea5855e980c may be incorrect:

This fallback *used* to (pre-1ea5855e980c) be used for any block device
(eMMC, SATA, etc.) where we *didn't* specify root= in the boot args.
This could perhaps happen with initramfs systems? (Sorry, I'm not
extremely familiar with the openwrt ecosystem.)

So do we need to refactor this again, so that we allow the fallback in
either (or both) of these cases:

(1) no root= arg
(2) root= (where XXX is not a /device/path) +
fstools_partname_fallback_scan=1

?

Anyway, it's probably at least safe to apply my bugfix, but we might
need more.

Brian

> Signed-off-by: Brian Norris 
> ---
> 
>  libfstools/partname.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libfstools/partname.c b/libfstools/partname.c
> index f42322a49d5b..82c723c02097 100644
> --- a/libfstools/partname.c
> +++ b/libfstools/partname.c
> @@ -143,7 +143,7 @@ static struct volume *partname_volume_find(char *name)
>   if (!get_var_from_file("/proc/cmdline", 
> "fstools_partname_fallback_scan", rootparam, sizeof(rootparam)))
>   return NULL;
>  
> - if (!strcmp("1", rootparam))
> + if (strcmp("1", rootparam))
>   return NULL;
>  
>   /* no useful 'root=' kernel cmdline parameter, find on any 
> block device */
> -- 
> 2.39.0
> 

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

[PATCH fstools] partname: Correct fstools_partname_fallback_scan comparison

[Brian Norris]

We want to return NULL if the param does *not* match 1 -- i.e., a
non-zero strcmp().

Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan 
option")
Signed-off-by: Brian Norris 
---

 libfstools/partname.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f42322a49d5b..82c723c02097 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -143,7 +143,7 @@ static struct volume *partname_volume_find(char *name)
if (!get_var_from_file("/proc/cmdline", 
"fstools_partname_fallback_scan", rootparam, sizeof(rootparam)))
return NULL;
 
-   if (!strcmp("1", rootparam))
+   if (strcmp("1", rootparam))
return NULL;
 
/* no useful 'root=' kernel cmdline parameter, find on any 
block device */
-- 
2.39.0


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

Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

On Sat, Jan 21, 2023 at 02:23:08AM +0100, Christian Marangi wrote:
> On Fri, Jan 20, 2023 at 05:17:43PM -0800, Brian Norris wrote:
> > On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi  
> > wrote:
> > > added the changed to my staging repo and testing them here
> > > https://github.com/openwrt/openwrt/pull/11843.
> > >
> > > Merged the fstools requirement. If CI tests doesn't have problems, i
> > > will merge this in master.
> > 
> > I see you've merged them to master. Thanks for looking and for
> > merging! I'll keep an eye out myself, but feel free to let me know if
> > anything goes wrong.
> > 
> > One preemptive heads up: I know my ASoC/sound patch already got merged
> > to Linux v5.15.89, so that patch should drop out whenever openwrt
> > pulls it in. Presumably whoever does that upgrade will notice the
> > conflict/redundancy eventually.
> > 
> 
> Yes CI test will catch that and will just fail.

Good enough.

> Now I think I have to
> ask someone to reboot buildbot again for the new subtarget... Or it will be
> picked automatically?

I'm certainly not the expert, but last I dealt with this I hear it
needed a restart:

https://github.com/openwrt/openwrt/pull/9276#issuecomment-1085448201

Brian

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

Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi  wrote:
> added the changed to my staging repo and testing them here
> https://github.com/openwrt/openwrt/pull/11843.
>
> Merged the fstools requirement. If CI tests doesn't have problems, i
> will merge this in master.

I see you've merged them to master. Thanks for looking and for
merging! I'll keep an eye out myself, but feel free to let me know if
anything goes wrong.

One preemptive heads up: I know my ASoC/sound patch already got merged
to Linux v5.15.89, so that patch should drop out whenever openwrt
pulls it in. Presumably whoever does that upgrade will notice the
conflict/redundancy eventually.

Thanks,
Brian

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

Re: [PATCH v3 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

On Fri, Jan 13, 2023 at 5:40 AM Linus Walleij  wrote:
>
> Hi Brian!
>
> I have this device, so as soon as I manage to find time for opening it up
> and mounting a UART I will test your patch set!

Hi Linus! Glad to see you're interested.

> On Wed, Jan 11, 2023 at 8:13 AM Brian Norris
>  wrote:
>
> > TP-Link and ASUS OnHub devices are very similar, sharing many of the
> > same characteristics and much of their Device Tree. They both run a
> > version of ChromeOS for their factory firmware, and so installation
> > instructions look very similar to Google Wifi [1].
> (...)
> >  create mode 100644 
> > target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts
> >  create mode 100644 
> > target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
> >  create mode 100644 
> > target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts
>
> Could you please submit these device trees upstream to the
> Linux kernel as well?
>
> I don't know your immediate plans, if your idea is to put it into
> OpenWrt first, but I'm sure the Qualcomm maintainers
> Bjorn and Krzysztof would be delighted to take a look.
> A small patch to Documentation/devicetree/bindings/arm/qcom.yaml
> adding the new compatibles is needed too.
>
> If you don't have time for this I understand, I can volunteer
> to push it upstream and iron out any snags in that case.

That's not currently my interest. My current motivation is to get this
into OpenWrt, since these devices are no longer supported by Google as
of January 11, and a lot of people are interested in taking back
control of their hardware.

And, I think there are at least a handful of important things missing
from upstream such that either the device tree would not fit
upstream's typical review process (non-upstream bindings), or else
would be missing major features (USB, and possibly more), which
wouldn't serve the primary goal (of making these devices usable again
as quickly as possible).

So, maybe I could take a stab at things eventually, but not
immediately. In case you want to help (which would be very welcome!),
here's one missing piece:
target/linux/ipq806x/patches-5.15/850-soc-add-qualcomm-syscon.patch
I'd bet that needs to get reworked into some kind of integration with
the USB and/or PHY driver(s). And I'm sure there's more if you look
through target/linux/ipq806x/patches-5.15/. But hey, getting it
running yourself to play with would be a good start, and I'd love to
have some company on this potentially-upstreaming journey ;)

BTW, if you're interested in this sort of thing (and perhaps have
other Google-related hardware?), I took some notes on my last
(failed/stalled)-upstreaming efforts, for Google Wifi:
https://openwrt.org/toh/google/wifi#upstreaming_notes
That's another can of worms, since I think the upstream maintainers
would prefer to ignore "legacy" firmware that doesn't work exactly the
same as whatever modern chips they're playing with...
...so you're left with upstream not really supporting most Qualcomm
hardware. *shrug*

Brian

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

[PATCH v4 4/7] ipq806x: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling

[Brian Norris]

This fixes device tree registration for 'qcom,lpass-cpu' as used by
qcom-ipq8064 SoCs, and allows speaker audio to function.

This patch has been submitted (and merged, for -next; likely v6.3)
upstream.

Signed-off-by: Brian Norris 
---

(no changes since v2)

Changes in v2:
 * Add upstream (-next) notes
 * Renumber to 0xx-v6.3-*.patch

 ...cpu-Fix-fallback-SD-line-index-handl.patch | 42 +++
 1 file changed, 42 insertions(+)
 create mode 100644 
target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch

diff --git 
a/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
 
b/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
new file mode 100644
index ..099dc606114e
--- /dev/null
+++ 
b/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
@@ -0,0 +1,42 @@
+From: Brian Norris 
+Date: Thu, 15 Dec 2022 01:33:45 -0800
+Subject: [PATCH] ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+
+[[ Submitted upstream as:
+   
https://lore.kernel.org/all/20221231061545.2110253-1-computersforpe...@gmail.com/
+   Currently queued for -next (v6.3?) as:
+   000bca8d706d ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+]]
+
+These indices should reference the ID placed within the dai_driver
+array, not the indices of the array itself.
+
+This fixes commit 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD
+lines configurable"), which among others, broke IPQ8064 audio
+(sound/soc/qcom/lpass-ipq806x.c) because it uses ID 4 but we'd stop
+initializing the mi2s_playback_sd_mode and mi2s_capture_sd_mode arrays
+at ID 0.
+
+Fixes: 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD lines configurable")
+Cc: 
+Signed-off-by: Brian Norris 
+---
+ sound/soc/qcom/lpass-cpu.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/qcom/lpass-cpu.c
 b/sound/soc/qcom/lpass-cpu.c
+@@ -851,10 +851,11 @@ static void of_lpass_cpu_parse_dai_data(
+   struct lpass_data *data)
+ {
+   struct device_node *node;
+-  int ret, id;
++  int ret, i, id;
+ 
+   /* Allow all channels by default for backwards compatibility */
+-  for (id = 0; id < data->variant->num_dai; id++) {
++  for (i = 0; i < data->variant->num_dai; i++) {
++  id = data->variant->dai_driver[i].id;
+   data->mi2s_playback_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+   data->mi2s_capture_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+   }
-- 
2.39.0


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

[PATCH v4 6/7] ucode: update to latest Git HEAD

[Brian Norris]

To bring in isatty() support.

Includes new commits:

be30472bfdbb fs: add `isatty()` function
98637e08dba5 Merge pull request #136 from blogic/master
0a58d510529e nl80211: add support for NL80211_ATTR_MPATH_INFO

Signed-off-by: Brian Norris 
---

Changes in v4:
 * Clean up commit message

Changes in v3:
 * New patch

 package/utils/ucode/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/utils/ucode/Makefile b/package/utils/ucode/Makefile
index 228403e04156..3913fd2aa432 100644
--- a/package/utils/ucode/Makefile
+++ b/package/utils/ucode/Makefile
@@ -12,9 +12,9 @@ PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=https://github.com/jow-/ucode.git
-PKG_SOURCE_DATE:=2023-01-07
-PKG_SOURCE_VERSION:=1e4d20932646f90523d21ea358c72901e3ee689e
-PKG_MIRROR_HASH:=8c43b9a0a80c3de92961caad65c934bd3989e6f7f9389f676d91e2e926c9e4a6
+PKG_SOURCE_DATE:=2023-01-09
+PKG_SOURCE_VERSION:=8dad974baa4696fcba85837fa70cde8b68dd7c12
+PKG_MIRROR_HASH:=91494352ac298ac2735d62355837a1f18e366999c9e940613e6fa3265edc0364
 PKG_MAINTAINER:=Jo-Philipp Wich 
 PKG_LICENSE:=ISC
 
-- 
2.39.0


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

[PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

TP-Link and ASUS OnHub devices are very similar, sharing many of the
same characteristics and much of their Device Tree. They both run a
version of ChromeOS for their factory firmware, and so installation
instructions look very similar to Google Wifi [1].

Things I've tested, and are working:

 * Ethernet
 * WiFi (2.4 and 5 GHz)
 * LEDs
 * USB
 * eMMC
 * Serial console (if you wire it up yourself)
 * 2x CPU
 * Speaker

== Installation instructions summary ==

1. Flash *-factory.bin to a USB drive (e.g., with `dd`)
2. Insert USB drive, to boot OpenWrt from USB
3. Copy the same *-factory.bin over to device, and flash it to eMMC to
   make OpenWrt permanent

== Developer mode, booting from USB (Step 2) ==

To enter Developer Mode and boot OpenWrt from a USB stick:

1. Unplug power
2. Gain access to the "developer switch" through the bottom of the
   device
3. Hold down the "reset switch" (near the USB port / power plug)
4. Plug power back in
5. The LED on the device should turn white, then blink orange, then
   red. Release the reset switch.
6. Insert USB drive with OpenWrt factory.bin
7. Press the hidden developer switch under the device to boot to USB;
   you should see some activity lights (if you have any) on your USB
   drive
8. Depending on your configuration, the router's LED(s) should come on.
   You're now running OpenWrt off a USB stick.

These instructions are derived from:

https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub
https://www.exploitee.rs/index.php/Asus_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub

~~Finding the developer switch:~~ for TP-Link, the developer switch is
on the bottom of the device, underneath some of the rubber padding and a
screw. For ASUS, remove the entire base, via 4 screws under the rubber
feet. See the Exploitee instructions for more info and photos.

== Making OpenWrt permanent (on eMMC) (Step 3) ==

Once you're running OpenWrt via USB:

1. Connect Ethernet to the LAN port; router's LAN address should be at
   192.168.1.1
2. Connect another system to the router's LAN, and copy the factory.bin
   image over, via SCP and SSH:

 scp -O openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin 
root@192.168.1.1:
 ssh root@192.168.1.1 -C "dd if=/dev/zero bs=512 seek=7552991 
of=/dev/mmcblk0 count=33 && \
 dd if=/root/openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin 
of=/dev/mmcblk0"
3. Reboot and remove the USB drive.

== Developer mode beep ==

Note that every time you boot the OnHub in developer mode, the device
will play a loud "beep" after a few seconds. This is described in the
Chromium docs [2], and is intended to make it clear that the device is
not running Google software. It is nontrivial to completely disable this
beep, although it's possible to "acknowledge" developer mode (and skip
the beep) by using a USB keyboard to press CTRL+D every time you boot.

[1] https://openwrt.org/toh/google/wifi
[2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md

Signed-off-by: Brian Norris 
---
 * There might be better ways to handle the multi-color LED support,
   but for now, each color is a separate LED
 * A variety of people have been interested in this work, and a few have
   tested versions of it already:
 https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899
 * This is dependent on an fstools change, to ensure it can find our
   'rootfs_data' properly:
 [PATCH fstools v2] partname: Ignore root=PARTUUID...
 
https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/

Changes in v4:
 * move LED configuration to device tree

Changes in v3:
 * use 'ucode' for base64, to reduce dependency complexity and avoid
   bringing in coreutils
 * simplify installation instructions
 * add back in second CPU / drop maxcpus=1 (I had apparently already
   fixed this, but kept the maxcpus=1)

Changes in v2:
 * Drop custom ath10k base64 property
 * Provide base64 caldata parsing via
   /etc/hotplug.d/firmware/11-ath10k-caldata instead
 * add coreutils-base64 dependency
 * add 3rd (rootfs_data) partition, to better handle sysupgrade and
   utilize the whole disk

 target/linux/ipq806x/Makefile |   4 +-
 .../ipq806x/base-files/etc/board.d/02_network |   6 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  35 ++
 .../base-files/lib/upgrade/platform.sh|  19 +
 .../base-files/usr/bin/base64decode.uc|  23 +
 target/linux/ipq806x/chromium/config-default  |  13 +
 target/linux/ipq806x/chromium/target.mk   |   2 +
 .../arm/boot/dts/qcom-ipq8064-asus-onhub.dts  |  96 
 .../arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi | 463 ++
 .../boot/dts/qcom-ipq8064-tplink-onhub.dts| 213 
 target/linux/ipq806x/generic/target.mk|   1 +
 target/linux/ipq806x/image/chromium.mk|  58 +++
 12 files chan

[PATCH v4 2/7] ipq806x: Point to externally compiled dtbs in recipes

[Brian Norris]

Similar to commit 4d8b42d8a777 ("ipq40xx: point to externally compiled
dtbs in recipes").

Currently, we patch our DTS files into the kernel source tree, so the
kernel build process will produce DTBs for us. The kernel-to-DTS
dependency can cause buildroot to perform excessive rebuilds of the
kernel though, which slows down device development iteration.

Buildroot also compiles DTBs on its own, to
$(KDIR)/image-$(DEVICE_DTS).dtb. With small adjustments, we can leverage
this, and stop patching DTS files into the kernel Makefile at the same
time.

Signed-off-by: Brian Norris 
---

(no changes since v2)

Changes in v2:
 * Improve commit description

 target/linux/ipq806x/image/Makefile   |  5 +--
 .../0069-arm-boot-add-dts-files.patch | 43 ---
 .../0069-arm-boot-add-dts-files.patch | 43 ---
 3 files changed, 2 insertions(+), 89 deletions(-)
 delete mode 100644 
target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
 delete mode 100644 
target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch

diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile
index f4f829b35c65..8c1fc88010cd 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -5,7 +5,6 @@ include $(INCLUDE_DIR)/image.mk
 
 define Device/Default
PROFILES := Default
-   KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts)
KERNEL_LOADADDR = 0x42208000
DEVICE_DTS = $$(SOC)-$(lastword $(subst _, ,$(1)))
DEVICE_DTS_CONFIG := config@1
@@ -22,13 +21,13 @@ endef
 
 define Device/FitImage
KERNEL_SUFFIX := -fit-uImage.itb
-   KERNEL = kernel-bin | gzip | fit gzip $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+   KERNEL = kernel-bin | gzip | fit gzip $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
 endef
 
 define Device/FitImageLzma
KERNEL_SUFFIX := -fit-uImage.itb
-   KERNEL = kernel-bin | lzma | fit lzma $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+   KERNEL = kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
 endef
 
diff --git 
a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch 
b/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 4c42f40e3d78..
--- a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin 

- arch/arm/boot/dts/Makefile | 8 
- 1 file changed, 8 insertions(+)
-
 a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -909,8 +909,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom-ipq4019-ap.dk04.1-c3.dtb \
-   qcom-ipq4019-ap.dk07.1-c1.dtb \
-   qcom-ipq4019-ap.dk07.1-c2.dtb \
-+  qcom-ipq8062-wg2600hp3.dtb \
-   qcom-ipq8064-ap148.dtb \
-   qcom-ipq8064-rb3011.dtb \
-+  qcom-ipq8064-c2600.dtb \
-+  qcom-ipq8064-d7800.dtb \
-+  qcom-ipq8064-db149.dtb \
-+  qcom-ipq8064-ap161.dtb \
-+  qcom-ipq8064-ea7500-v1.dtb \
-+  qcom-ipq8064-ea8500.dtb \
-+  qcom-ipq8064-g10.dtb \
-+  qcom-ipq8064-r7500.dtb \
-+  qcom-ipq8064-r7500v2.dtb \
-+  qcom-ipq8064-unifi-ac-hd.dtb \
-+  qcom-ipq8064-wg2600hp.dtb \
-+  qcom-ipq8064-wpq864.dtb \
-+  qcom-ipq8064-wxr-2533dhp.dtb \
-+  qcom-ipq8065-nbg6817.dtb \
-+  qcom-ipq8065-r7800.dtb \
-+  qcom-ipq8065-rt4230w-rev6.dtb \
-+  qcom-ipq8065-tr4400-v2.dtb \
-+  qcom-ipq8065-xr500.dtb \
-+  qcom-ipq8068-ecw5410.dtb \
-+  qcom-ipq8068-mr42.dtb \
-+  qcom-ipq8068-mr52.dtb \
-   qcom-msm8660-surf.dtb \
-   qcom-msm8960-cdp.dtb \
-   qcom-msm8974-fairphone-fp2.dtb \
diff --git 
a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch 
b/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 698df248fb57..
--- a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin 

- arch/arm/boot/dts/Makefile | 8 
- 1 file changed, 8 insertions(+)
-
 a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -957,8 +957,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom-ipq4019-ap.dk04.1-c3.dtb \
-   qcom-ipq4019-ap.dk07.1-c1.dtb \
-   qcom-ipq4019-ap.dk07.1-c2.dtb \
-+  qcom-ipq8062-wg2600hp3.dtb \
-   qcom-ipq8064-ap148.dtb \
-   qcom-ipq8064-rb3011.dtb \
-+  qcom-ipq8064-c2600.dtb \
-+  qcom-ipq8064-d7800.dtb \
-+  qcom-ipq8064

[PATCH v4 1/7] base-files: Remove nand.sh dependency from emmc upgrade

[Brian Norris]

emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.

Rename identify_magic() to identify_magic_long() to match the common.sh
style and make it clear it pairs with other *_long() variants (and not,
say *_word()).

Signed-off-by: Brian Norris 
---

(no changes since v1)

 .../base-files/files/lib/upgrade/common.sh| 27 
 package/base-files/files/lib/upgrade/emmc.sh  |  2 +-
 package/base-files/files/lib/upgrade/nand.sh  | 32 ++-
 3 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 5af061f6a439..53b8865a5788 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -127,6 +127,33 @@ get_magic_fat32() {
(get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
 }
 
+identify_magic_long() {
+   local magic=$1
+   case "$magic" in
+   "55424923")
+   echo "ubi"
+   ;;
+   "31181006")
+   echo "ubifs"
+   ;;
+   "68737173")
+   echo "squashfs"
+   ;;
+   "d00dfeed")
+   echo "fit"
+   ;;
+   "4349"*)
+   echo "combined"
+   ;;
+   "1f8b"*)
+   echo "gzip"
+   ;;
+   *)
+   echo "unknown $magic"
+   ;;
+   esac
+}
+
 part_magic_efi() {
local magic=$(get_magic_gpt "$@")
[ "$magic" = "EFI PART" ]
diff --git a/package/base-files/files/lib/upgrade/emmc.sh 
b/package/base-files/files/lib/upgrade/emmc.sh
index c3b02864aa91..49cffe1c658b 100644
--- a/package/base-files/files/lib/upgrade/emmc.sh
+++ b/package/base-files/files/lib/upgrade/emmc.sh
@@ -58,7 +58,7 @@ emmc_copy_config() {
 }
 
 emmc_do_upgrade() {
-   local file_type=$(identify $1)
+   local file_type=$(identify_magic_long "$(get_magic_long "$1")")
 
case "$file_type" in
"fit")  emmc_upgrade_fit $1;;
diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index a8e3cab0b8b1..a1dbd6e2663d 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -65,40 +65,12 @@ get_magic_long_tar() {
(tar xO${3}f "$1" "$2" | dd bs=4 count=1 | hexdump -v -n 4 -e '1/1 
"%02x"') 2> /dev/null
 }
 
-identify_magic() {
-   local magic=$1
-   case "$magic" in
-   "55424923")
-   echo "ubi"
-   ;;
-   "31181006")
-   echo "ubifs"
-   ;;
-   "68737173")
-   echo "squashfs"
-   ;;
-   "d00dfeed")
-   echo "fit"
-   ;;
-   "4349"*)
-   echo "combined"
-   ;;
-   "1f8b"*)
-   echo "gzip"
-   ;;
-   *)
-   echo "unknown $magic"
-   ;;
-   esac
-}
-
-
 identify() {
-   identify_magic $(nand_get_magic_long "$@")
+   identify_magic_long $(nand_get_magic_long "$@")
 }
 
 identify_tar() {
-   identify_magic $(get_magic_long_tar "$@")
+   identify_magic_long $(get_magic_long_tar "$@")
 }
 
 identify_if_gzip() {
-- 
2.39.0


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

[PATCH v4 5/7] ipq806x: Add kmod-sound-soc-ipq8064-storm

[Brian Norris]

For IPQ8064 systems based off the "Google Storm" reference platform,
such as the TP-Link OnHub.

Signed-off-by: Brian Norris 
---

(no changes since v2)

Changes in v2:
 * Drop CONFIG_IPQ_LCC_806X=y, and merge CONFIG_IPQ_LCC_806X=m into this
   package
 * Move package to the ipq806x target
 * Slim AutoLoad list; switch to AutoProbe

 target/linux/ipq806x/modules.mk | 29 +
 1 file changed, 29 insertions(+)

diff --git a/target/linux/ipq806x/modules.mk b/target/linux/ipq806x/modules.mk
index 605504b0c338..a2b844d0f03c 100644
--- a/target/linux/ipq806x/modules.mk
+++ b/target/linux/ipq806x/modules.mk
@@ -14,3 +14,32 @@ define KernelPackage/phy-qcom-ipq806x-usb/description
 endef
 
 $(eval $(call KernelPackage,phy-qcom-ipq806x-usb))
+
+
+define KernelPackage/sound-soc-ipq8064-storm
+  TITLE:=Qualcomm IPQ8064 SoC support for Google Storm
+  DEPENDS:=@TARGET_ipq806x +kmod-sound-soc-core
+  KCONFIG:=\
+   CONFIG_IPQ_LCC_806X \
+   CONFIG_SND_SOC_QCOM \
+   CONFIG_SND_SOC_STORM \
+   CONFIG_SND_SOC_APQ8016_SBC=n \
+   CONFIG_SND_SOC_SC7180=n
+  FILES:=\
+   $(LINUX_DIR)/drivers/clk/qcom/lcc-ipq806x.ko \
+   $(LINUX_DIR)/sound/soc/codecs/snd-soc-max98357a.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-cpu.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-ipq806x.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-platform.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-storm.ko
+  AUTOLOAD:=$(call AutoProbe,lcc-ipq806x \
+   snd-soc-max98357a snd-soc-lpass-ipq806x snd-soc-storm)
+  $(call AddDepends/sound)
+endef
+
+define KernelPackage/sound-soc-ipq8064-storm/description
+ Provides sound support for the Google Storm platform, with a Qualcomm IPQ8064
+ SoC.
+endef
+
+$(eval $(call KernelPackage,sound-soc-ipq8064-storm))
-- 
2.39.0


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

[PATCH v4 3/7] ipq806x: config-5.15: Normalize

[Brian Norris]

Refresh target config with `make kernel_menuconfig`, then save the
result. This drops missing symbols or otherwise accounts for defaults.
It should not change any functionality.

Signed-off-by: Brian Norris 
---

(no changes since v2)

Changes in v2:
 * Improve description

 target/linux/ipq806x/config-5.15 | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/target/linux/ipq806x/config-5.15 b/target/linux/ipq806x/config-5.15
index 72017e7528f1..0bd6dde11cbc 100644
--- a/target/linux/ipq806x/config-5.15
+++ b/target/linux/ipq806x/config-5.15
@@ -34,13 +34,14 @@ CONFIG_ARM_CPU_SUSPEND=y
 # CONFIG_ARM_CPU_TOPOLOGY is not set
 CONFIG_ARM_GIC=y
 CONFIG_ARM_HAS_SG_CHAIN=y
+# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set
+# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set
 CONFIG_ARM_L1_CACHE_SHIFT=6
 CONFIG_ARM_L1_CACHE_SHIFT_6=y
 CONFIG_ARM_MODULE_PLTS=y
 CONFIG_ARM_PATCH_IDIV=y
 CONFIG_ARM_PATCH_PHYS_VIRT=y
 # CONFIG_ARM_QCOM_CPUFREQ_HW is not set
-CONFIG_ARM_QCOM_CPUFREQ_KRAIT=y
 CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y
 CONFIG_ARM_QCOM_SPM_CPUIDLE=y
 # CONFIG_ARM_SMMU is not set
@@ -98,13 +99,11 @@ CONFIG_CRC16=y
 # CONFIG_CRC32_SARWATE is not set
 CONFIG_CRC32_SLICEBY8=y
 CONFIG_CRC8=y
-CONFIG_CRYPTO_BLAKE2S=y
 CONFIG_CRYPTO_DEFLATE=y
 CONFIG_CRYPTO_DEV_QCOM_RNG=y
 CONFIG_CRYPTO_DRBG=y
 CONFIG_CRYPTO_DRBG_HMAC=y
 CONFIG_CRYPTO_DRBG_MENU=y
-CONFIG_CRYPTO_GF128MUL=y
 CONFIG_CRYPTO_HASH_INFO=y
 CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_HW=y
@@ -112,7 +111,6 @@ CONFIG_CRYPTO_JITTERENTROPY=y
 CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
 CONFIG_CRYPTO_LIB_SHA256=y
 CONFIG_CRYPTO_LZO=y
-CONFIG_CRYPTO_NULL2=y
 CONFIG_CRYPTO_RNG=y
 CONFIG_CRYPTO_RNG2=y
 CONFIG_CRYPTO_SHA256=y
@@ -127,8 +125,6 @@ CONFIG_DEVFREQ_GOV_PASSIVE=y
 # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set
 # CONFIG_DEVFREQ_GOV_USERSPACE is not set
 # CONFIG_DEVFREQ_THERMAL is not set
-# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set
-# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set
 CONFIG_DMADEVICES=y
 CONFIG_DMA_ENGINE=y
 CONFIG_DMA_OF=y
@@ -143,6 +139,7 @@ CONFIG_DWMAC_IPQ806X=y
 CONFIG_DYNAMIC_DEBUG=y
 CONFIG_EDAC_ATOMIC_SCRUB=y
 CONFIG_EDAC_SUPPORT=y
+CONFIG_ETHERNET_PACKET_MANGLE=y
 CONFIG_FIXED_PHY=y
 CONFIG_FIX_EARLYCON_MEM=y
 CONFIG_FWNODE_MDIO=y
@@ -152,10 +149,12 @@ CONFIG_GENERIC_BUG=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
 CONFIG_GENERIC_CPU_AUTOPROBE=y
+CONFIG_GENERIC_CPU_VULNERABILITIES=y
 CONFIG_GENERIC_EARLY_IOREMAP=y
 CONFIG_GENERIC_GETTIMEOFDAY=y
 CONFIG_GENERIC_IDLE_POLL_SETUP=y
 CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
+CONFIG_GENERIC_IRQ_MIGRATION=y
 CONFIG_GENERIC_IRQ_MULTI_HANDLER=y
 CONFIG_GENERIC_IRQ_SHOW=y
 CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
@@ -173,6 +172,7 @@ CONFIG_GENERIC_STRNCPY_FROM_USER=y
 CONFIG_GENERIC_STRNLEN_USER=y
 CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GENERIC_VDSO_32=y
+CONFIG_GLOB=y
 CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_CDEV=y
 CONFIG_GRO_CELLS=y
@@ -185,6 +185,7 @@ CONFIG_HAS_IOPORT_MAP=y
 CONFIG_HAVE_SMP=y
 CONFIG_HIGHMEM=y
 # CONFIG_HIGHPTE is not set
+CONFIG_HOTPLUG_CPU=y
 CONFIG_HWMON=y
 CONFIG_HWSPINLOCK=y
 CONFIG_HWSPINLOCK_QCOM=y
@@ -214,12 +215,12 @@ CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y
 CONFIG_IRQ_FORCED_THREADING=y
 CONFIG_IRQ_WORK=y
 CONFIG_KMAP_LOCAL=y
+CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY=y
 CONFIG_KPSS_XCC=y
 CONFIG_KRAITCC=y
 CONFIG_KRAIT_CLOCKS=y
 CONFIG_KRAIT_L2_ACCESSORS=y
 CONFIG_LIBFDT=y
-CONFIG_LLD_VERSION=0
 CONFIG_LOCK_DEBUGGING_SUPPORT=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
 CONFIG_LZO_COMPRESS=y
@@ -300,6 +301,7 @@ CONFIG_NR_CPUS=2
 CONFIG_NVMEM=y
 CONFIG_NVMEM_QCOM_QFPROM=y
 # CONFIG_NVMEM_SPMI_SDAM is not set
+CONFIG_NVMEM_SYSFS=y
 CONFIG_OF=y
 CONFIG_OF_ADDRESS=y
 CONFIG_OF_EARLY_FLATTREE=y
@@ -308,7 +310,6 @@ CONFIG_OF_GPIO=y
 CONFIG_OF_IRQ=y
 CONFIG_OF_KOBJ=y
 CONFIG_OF_MDIO=y
-CONFIG_OF_NET=y
 CONFIG_OLD_SIGACTION=y
 CONFIG_OLD_SIGSUSPEND3=y
 CONFIG_PADATA=y
@@ -397,7 +398,7 @@ CONFIG_QCOM_SCM=y
 # CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is not set
 CONFIG_QCOM_SMEM=y
 # CONFIG_QCOM_SMSM is not set
-# CONFIG_QCOM_SOCINFO is not set
+CONFIG_QCOM_SOCINFO=y
 CONFIG_QCOM_TCSR=y
 CONFIG_QCOM_TSENS=y
 CONFIG_QCOM_WDT=y
@@ -452,6 +453,7 @@ CONFIG_SMP_ON_UP=y
 # CONFIG_SM_VIDEOCC_8150 is not set
 # CONFIG_SM_VIDEOCC_8250 is not set
 CONFIG_SOCK_RX_QUEUE_MAPPING=y
+CONFIG_SOC_BUS=y
 CONFIG_SPARSE_IRQ=y
 CONFIG_SPI=y
 CONFIG_SPI_MASTER=y
-- 
2.39.0


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

Re: [PATCH v3 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

Hi Christian,

On Thu, Jan 12, 2023 at 6:34 AM Christian Marangi  wrote:
> On Tue, Jan 10, 2023 at 11:06:52PM -0800, Brian Norris wrote:
> > diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds 
> > b/target/linux/ipq806x/base-files/etc/board.d/01_leds
> > index 2b259b903614..80a337c6a4d4 100644
> > --- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
> > +++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
> > @@ -9,6 +9,9 @@ board_config_update
> >  board=$(board_name)
> >
> >  case "$board" in
> > +asus,onhub)
> > + ucidef_set_led_default "status" "STATUS" "LED_Green" "1"
>
> Can't we set this directly in the dt?

I suppose. I guess that's "linux,default-trigger"? Confusingly,
there's also "default-state" in the common bindings, but it's only
supported for a handful of drivers.

Downside: IIUC, this will no longer reflect in the UCI configuration,
and so it's less obvious how to override things. Especially when, like
the TP-Link version, you have 18 (!!) LEDs (or, 6 x 3-color LEDs), and
you have to guess as to which ones to override. But I can live with
that if that's deemed better.

> Also I think we should use a more
> descriptive name.

Sure. What do you think would be better? For ASUS, it's only a single
(set of) LEDs, so maybe I could go with "{red,green,blue}:status"
naming like I see on some others.

But how about TP-Link? There are 6 x 3-color LEDs strung in a ring
around the top. There's not really any particular function assigned to
them, and there isn't much visual separation between them (they
overlap in a sort of gradient). So, "{red,green,blue}:status{0..5}"?
Or "{red,green,blue}:ring{0..5}"?

There are some photos here, if you need inspiration:
https://openwrt.org/inbox/toh/google/onhub_tp-link_tgr1900
https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub

> > + ;;
> >  buffalo,wxr-2533dhp)
> >   ucidef_set_led_wlan "wlan" "WLAN" "white:wireless" "phy0tpt"
> >   ucidef_set_led_switch "wan" "WAN" "white:internet" "switch0" "0x20"
> > @@ -58,6 +61,14 @@ tplink,c2600)
> >   ucidef_set_led_switch "wan" "wan" "white:wan" "switch0" "0x20"
> >   ucidef_set_led_switch "lan" "lan" "white:lan" "switch0" "0x1e"
> >   ;;
> > +tplink,onhub)
> > + ucidef_set_led_default "led0_red" "LED0_Red" "LED0_Red" "1"
> > + ucidef_set_led_default "led1_green" "LED1_Green" "LED1_Green" "1"
> > + ucidef_set_led_default "led2_blue" "LED2_Blue" "LED2_Blue" "1"
> > + ucidef_set_led_default "led3_red" "LED3_Red" "LED3_Red" "1"
> > + ucidef_set_led_default "led4_green" "LED4_Green" "LED4_Green" "1"
> > + ucidef_set_led_default "led5_blue" "LED5_Blue" "LED5_Blue" "1"
> > + ;;
>
> Same here.
>
> Aside from these leds problem rest of the series looks OK. I have just
> some concern about the changed name in patch 1 for downstream project
> but we can live with that.

Thanks,
Brian

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

Re: [PATCH v3 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

On Thu, Jan 12, 2023 at 9:48 AM Christian Marangi  wrote:
> On Thu, Jan 12, 2023 at 09:35:03AM -0800, Brian Norris wrote:
> > On Thu, Jan 12, 2023 at 6:34 AM Christian Marangi  
> > wrote:
> > Downside: IIUC, this will no longer reflect in the UCI configuration,
> > and so it's less obvious how to override things. Especially when, like
> > the TP-Link version, you have 18 (!!) LEDs (or, 6 x 3-color LEDs), and
> > you have to guess as to which ones to override. But I can live with
> > that if that's deemed better.
>
> It's not needed to have an UCI conf reflecting the state... If someone
> needs to configure the led the current configuration is ignored anyway
> as it will be changed to what the user wants.

Right, but with the ucidef approach, the default state will be in the
UCI configuration already, and so the user only has to delete (or
rewrite) entries to turn off (or change) LEDs. With defaults in the
DTS, there's no default UCI entry, and the user has to learn which of
the 18 LEDs they want to override. For the TP-Link ring especially,
this could be non-obvious. Maybe that'd get better if (L)UCI did a
better job with multi-color LEDs, so there'd only be 6 things to
configure instead of 18.

> >
> > > Also I think we should use a more
> > > descriptive name.
> >
> > Sure. What do you think would be better? For ASUS, it's only a single
> > (set of) LEDs, so maybe I could go with "{red,green,blue}:status"
> > naming like I see on some others.
>
> Yes the pattern is color:function... Ideally everything should be
> handled with standard linux binding instead of declaring a label...
>
> So using function-enumerator, color and function.
> If something is not here [1] then label are required
>
> [1] 
> https://elixir.bootlin.com/linux/latest/source/include/dt-bindings/leds/common.h

I'll play around with this. Last I checked, the lp5523 driver didn't
end up with very nice names without specifying a "chan-name" and/or
"label" (again, individual drivers seem to have a lot of leeway
despite the "common" bindings), but I'll check again later today.

Brian

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

[PATCH v3 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

TP-Link and ASUS OnHub devices are very similar, sharing many of the
same characteristics and much of their Device Tree. They both run a
version of ChromeOS for their factory firmware, and so installation
instructions look very similar to Google Wifi [1].

Things I've tested, and are working:

 * Ethernet
 * WiFi (2.4 and 5 GHz)
 * LEDs
 * USB
 * eMMC
 * Serial console (if you wire it up yourself)
 * 2x CPU
 * Speaker

== Installation instructions summary ==

1. Flash *-factory.bin to a USB drive (e.g., with `dd`)
2. Insert USB drive, to boot OpenWrt from USB
3. Copy the same *-factory.bin over to device, and flash it to eMMC to
   make OpenWrt permanent

== Developer mode, booting from USB (Step 2) ==

To enter Developer Mode and boot OpenWrt from a USB stick:

1. Unplug power
2. Gain access to the "developer switch" through the bottom of the
   device
3. Hold down the "reset switch" (near the USB port / power plug)
4. Plug power back in
5. The LED on the device should turn white, then blink orange, then
   red. Release the reset switch.
6. Insert USB drive with OpenWrt factory.bin
7. Press the hidden developer switch under the device to boot to USB;
   you should see some activity lights (if you have any) on your USB
   drive
8. Depending on your configuration, the router's LED(s) should come on.
   You're now running OpenWrt off a USB stick.

These instructions are derived from:

https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub
https://www.exploitee.rs/index.php/Asus_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub

~~Finding the developer switch:~~ for TP-Link, the developer switch is
on the bottom of the device, underneath some of the rubber padding and a
screw. For ASUS, remove the entire base, via 4 screws under the rubber
feet. See the Exploitee instructions for more info and photos.

== Making OpenWrt permanent (on eMMC) (Step 3) ==

Once you're running OpenWrt via USB:

1. Connect Ethernet to the LAN port; router's LAN address should be at
   192.168.1.1
2. Connect another system to the router's LAN, and copy the factory.bin
   image over, via SCP and SSH:

 scp -O openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin 
root@192.168.1.1:
 ssh root@192.168.1.1 -C "dd if=/dev/zero bs=512 seek=7552991 
of=/dev/mmcblk0 count=33 && \
 dd if=/root/openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin 
of=/dev/mmcblk0"
3. Reboot and remove the USB drive.

== Developer mode beep ==

Note that every time you boot the OnHub in developer mode, the device
will play a loud "beep" after a few seconds. This is described in the
Chromium docs [2], and is intended to make it clear that the device is
not running Google software. It is nontrivial to completely disable this
beep, although it's possible to "acknowledge" developer mode (and skip
the beep) by using a USB keyboard to press CTRL+D every time you boot.

[1] https://openwrt.org/toh/google/wifi
[2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md

Signed-off-by: Brian Norris 
---
 * There might be better ways to handle the multi-color LED support,
   but for now, each color is a separate LED
 * A variety of people have been interested in this work, and a few have
   tested versions of it already:
 https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899
 * This is dependent on an fstools change, to ensure it can find our
   'rootfs_data' properly:
 [PATCH fstools v2] partname: Ignore root=PARTUUID...
 
https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/

Changes in v3:
 * use 'ucode' for base64, to reduce dependency complexity and avoid
   bringing in coreutils
 * simplify installation instructions
 * add back in second CPU / drop maxcpus=1 (I had apparently already
   fixed this, but kept the maxcpus=1)

Changes in v2:
 * Drop custom ath10k base64 property
 * Provide base64 caldata parsing via
   /etc/hotplug.d/firmware/11-ath10k-caldata instead
 * add coreutils-base64 dependency
 * add 3rd (rootfs_data) partition, to better handle sysupgrade and
   utilize the whole disk

 target/linux/ipq806x/Makefile |   4 +-
 .../ipq806x/base-files/etc/board.d/01_leds|  11 +
 .../ipq806x/base-files/etc/board.d/02_network |   6 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  35 ++
 .../base-files/lib/upgrade/platform.sh|  19 +
 .../base-files/usr/bin/base64decode.uc|  23 +
 target/linux/ipq806x/chromium/config-default  |  13 +
 target/linux/ipq806x/chromium/target.mk   |   2 +
 .../arm/boot/dts/qcom-ipq8064-asus-onhub.dts  |  95 
 .../arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi | 463 ++
 .../boot/dts/qcom-ipq8064-tplink-onhub.dts| 207 
 target/linux/ipq806x/generic/target.mk|   1 +
 target/linux/ipq806x/image/chromium.mk|  58 +++
 13 files chan

[PATCH v3 5/7] ipq806x: Add kmod-sound-soc-ipq8064-storm

[Brian Norris]

For IPQ8064 systems based off the "Google Storm" reference platform,
such as the TP-Link OnHub.

Signed-off-by: Brian Norris 
---

(no changes since v2)

Changes in v2:
 * Drop CONFIG_IPQ_LCC_806X=y, and merge CONFIG_IPQ_LCC_806X=m into this
   package
 * Move package to the ipq806x target
 * Slim AutoLoad list; switch to AutoProbe

 target/linux/ipq806x/modules.mk | 29 +
 1 file changed, 29 insertions(+)

diff --git a/target/linux/ipq806x/modules.mk b/target/linux/ipq806x/modules.mk
index 605504b0c338..a2b844d0f03c 100644
--- a/target/linux/ipq806x/modules.mk
+++ b/target/linux/ipq806x/modules.mk
@@ -14,3 +14,32 @@ define KernelPackage/phy-qcom-ipq806x-usb/description
 endef
 
 $(eval $(call KernelPackage,phy-qcom-ipq806x-usb))
+
+
+define KernelPackage/sound-soc-ipq8064-storm
+  TITLE:=Qualcomm IPQ8064 SoC support for Google Storm
+  DEPENDS:=@TARGET_ipq806x +kmod-sound-soc-core
+  KCONFIG:=\
+   CONFIG_IPQ_LCC_806X \
+   CONFIG_SND_SOC_QCOM \
+   CONFIG_SND_SOC_STORM \
+   CONFIG_SND_SOC_APQ8016_SBC=n \
+   CONFIG_SND_SOC_SC7180=n
+  FILES:=\
+   $(LINUX_DIR)/drivers/clk/qcom/lcc-ipq806x.ko \
+   $(LINUX_DIR)/sound/soc/codecs/snd-soc-max98357a.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-cpu.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-ipq806x.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-platform.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-storm.ko
+  AUTOLOAD:=$(call AutoProbe,lcc-ipq806x \
+   snd-soc-max98357a snd-soc-lpass-ipq806x snd-soc-storm)
+  $(call AddDepends/sound)
+endef
+
+define KernelPackage/sound-soc-ipq8064-storm/description
+ Provides sound support for the Google Storm platform, with a Qualcomm IPQ8064
+ SoC.
+endef
+
+$(eval $(call KernelPackage,sound-soc-ipq8064-storm))
-- 
2.39.0


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

[PATCH v3 6/7] ucode: Update to latest

[Brian Norris]

To bring in isatty() support.

Includes new commits:

dad974baa46 Merge pull request #137 from ynezz/ynezz/isatty
be30472bfdbb fs: add `isatty()` function
98637e08dba5 Merge pull request #136 from blogic/master
0a58d510529e nl80211: add support for NL80211_ATTR_MPATH_INFO

Signed-off-by: Brian Norris 
---

(no changes since v1)

 package/utils/ucode/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/utils/ucode/Makefile b/package/utils/ucode/Makefile
index 228403e04156..3913fd2aa432 100644
--- a/package/utils/ucode/Makefile
+++ b/package/utils/ucode/Makefile
@@ -12,9 +12,9 @@ PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=https://github.com/jow-/ucode.git
-PKG_SOURCE_DATE:=2023-01-07
-PKG_SOURCE_VERSION:=1e4d20932646f90523d21ea358c72901e3ee689e
-PKG_MIRROR_HASH:=8c43b9a0a80c3de92961caad65c934bd3989e6f7f9389f676d91e2e926c9e4a6
+PKG_SOURCE_DATE:=2023-01-09
+PKG_SOURCE_VERSION:=8dad974baa4696fcba85837fa70cde8b68dd7c12
+PKG_MIRROR_HASH:=91494352ac298ac2735d62355837a1f18e366999c9e940613e6fa3265edc0364
 PKG_MAINTAINER:=Jo-Philipp Wich 
 PKG_LICENSE:=ISC
 
-- 
2.39.0


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

[PATCH v3 4/7] ipq806x: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling

[Brian Norris]

This fixes device tree registration for 'qcom,lpass-cpu' as used by
qcom-ipq8064 SoCs, and allows speaker audio to function.

This patch has been submitted (and merged, for -next; likely v6.3)
upstream.

Signed-off-by: Brian Norris 
---

(no changes since v2)

Changes in v2:
 * Add upstream (-next) notes
 * Renumber to 0xx-v6.3-*.patch

 ...cpu-Fix-fallback-SD-line-index-handl.patch | 42 +++
 1 file changed, 42 insertions(+)
 create mode 100644 
target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch

diff --git 
a/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
 
b/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
new file mode 100644
index ..099dc606114e
--- /dev/null
+++ 
b/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
@@ -0,0 +1,42 @@
+From: Brian Norris 
+Date: Thu, 15 Dec 2022 01:33:45 -0800
+Subject: [PATCH] ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+
+[[ Submitted upstream as:
+   
https://lore.kernel.org/all/20221231061545.2110253-1-computersforpe...@gmail.com/
+   Currently queued for -next (v6.3?) as:
+   000bca8d706d ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+]]
+
+These indices should reference the ID placed within the dai_driver
+array, not the indices of the array itself.
+
+This fixes commit 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD
+lines configurable"), which among others, broke IPQ8064 audio
+(sound/soc/qcom/lpass-ipq806x.c) because it uses ID 4 but we'd stop
+initializing the mi2s_playback_sd_mode and mi2s_capture_sd_mode arrays
+at ID 0.
+
+Fixes: 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD lines configurable")
+Cc: 
+Signed-off-by: Brian Norris 
+---
+ sound/soc/qcom/lpass-cpu.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/qcom/lpass-cpu.c
 b/sound/soc/qcom/lpass-cpu.c
+@@ -851,10 +851,11 @@ static void of_lpass_cpu_parse_dai_data(
+   struct lpass_data *data)
+ {
+   struct device_node *node;
+-  int ret, id;
++  int ret, i, id;
+ 
+   /* Allow all channels by default for backwards compatibility */
+-  for (id = 0; id < data->variant->num_dai; id++) {
++  for (i = 0; i < data->variant->num_dai; i++) {
++  id = data->variant->dai_driver[i].id;
+   data->mi2s_playback_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+   data->mi2s_capture_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+   }
-- 
2.39.0


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

[PATCH v3 1/7] base-files: Remove nand.sh dependency from emmc upgrade

[Brian Norris]

emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.

Rename identify_magic() to identify_magic_long() to match the common.sh
style and make it clear it pairs with other *_long() variants (and not,
say *_word()).

Signed-off-by: Brian Norris 
---

(no changes since v1)

 .../base-files/files/lib/upgrade/common.sh| 27 
 package/base-files/files/lib/upgrade/emmc.sh  |  2 +-
 package/base-files/files/lib/upgrade/nand.sh  | 32 ++-
 3 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 5af061f6a439..53b8865a5788 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -127,6 +127,33 @@ get_magic_fat32() {
(get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
 }
 
+identify_magic_long() {
+   local magic=$1
+   case "$magic" in
+   "55424923")
+   echo "ubi"
+   ;;
+   "31181006")
+   echo "ubifs"
+   ;;
+   "68737173")
+   echo "squashfs"
+   ;;
+   "d00dfeed")
+   echo "fit"
+   ;;
+   "4349"*)
+   echo "combined"
+   ;;
+   "1f8b"*)
+   echo "gzip"
+   ;;
+   *)
+   echo "unknown $magic"
+   ;;
+   esac
+}
+
 part_magic_efi() {
local magic=$(get_magic_gpt "$@")
[ "$magic" = "EFI PART" ]
diff --git a/package/base-files/files/lib/upgrade/emmc.sh 
b/package/base-files/files/lib/upgrade/emmc.sh
index c3b02864aa91..49cffe1c658b 100644
--- a/package/base-files/files/lib/upgrade/emmc.sh
+++ b/package/base-files/files/lib/upgrade/emmc.sh
@@ -58,7 +58,7 @@ emmc_copy_config() {
 }
 
 emmc_do_upgrade() {
-   local file_type=$(identify $1)
+   local file_type=$(identify_magic_long "$(get_magic_long "$1")")
 
case "$file_type" in
"fit")  emmc_upgrade_fit $1;;
diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index a8e3cab0b8b1..a1dbd6e2663d 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -65,40 +65,12 @@ get_magic_long_tar() {
(tar xO${3}f "$1" "$2" | dd bs=4 count=1 | hexdump -v -n 4 -e '1/1 
"%02x"') 2> /dev/null
 }
 
-identify_magic() {
-   local magic=$1
-   case "$magic" in
-   "55424923")
-   echo "ubi"
-   ;;
-   "31181006")
-   echo "ubifs"
-   ;;
-   "68737173")
-   echo "squashfs"
-   ;;
-   "d00dfeed")
-   echo "fit"
-   ;;
-   "4349"*)
-   echo "combined"
-   ;;
-   "1f8b"*)
-   echo "gzip"
-   ;;
-   *)
-   echo "unknown $magic"
-   ;;
-   esac
-}
-
-
 identify() {
-   identify_magic $(nand_get_magic_long "$@")
+   identify_magic_long $(nand_get_magic_long "$@")
 }
 
 identify_tar() {
-   identify_magic $(get_magic_long_tar "$@")
+   identify_magic_long $(get_magic_long_tar "$@")
 }
 
 identify_if_gzip() {
-- 
2.39.0


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

[PATCH v3 2/7] ipq806x: Point to externally compiled dtbs in recipes

[Brian Norris]

Similar to commit 4d8b42d8a777 ("ipq40xx: point to externally compiled
dtbs in recipes").

Currently, we patch our DTS files into the kernel source tree, so the
kernel build process will produce DTBs for us. The kernel-to-DTS
dependency can cause buildroot to perform excessive rebuilds of the
kernel though, which slows down device development iteration.

Buildroot also compiles DTBs on its own, to
$(KDIR)/image-$(DEVICE_DTS).dtb. With small adjustments, we can leverage
this, and stop patching DTS files into the kernel Makefile at the same
time.

Signed-off-by: Brian Norris 
---

(no changes since v2)

Changes in v2:
 * Improve commit description

 target/linux/ipq806x/image/Makefile   |  5 +--
 .../0069-arm-boot-add-dts-files.patch | 43 ---
 .../0069-arm-boot-add-dts-files.patch | 43 ---
 3 files changed, 2 insertions(+), 89 deletions(-)
 delete mode 100644 
target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
 delete mode 100644 
target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch

diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile
index f4f829b35c65..8c1fc88010cd 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -5,7 +5,6 @@ include $(INCLUDE_DIR)/image.mk
 
 define Device/Default
PROFILES := Default
-   KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts)
KERNEL_LOADADDR = 0x42208000
DEVICE_DTS = $$(SOC)-$(lastword $(subst _, ,$(1)))
DEVICE_DTS_CONFIG := config@1
@@ -22,13 +21,13 @@ endef
 
 define Device/FitImage
KERNEL_SUFFIX := -fit-uImage.itb
-   KERNEL = kernel-bin | gzip | fit gzip $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+   KERNEL = kernel-bin | gzip | fit gzip $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
 endef
 
 define Device/FitImageLzma
KERNEL_SUFFIX := -fit-uImage.itb
-   KERNEL = kernel-bin | lzma | fit lzma $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+   KERNEL = kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
 endef
 
diff --git 
a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch 
b/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 4c42f40e3d78..
--- a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin 

- arch/arm/boot/dts/Makefile | 8 
- 1 file changed, 8 insertions(+)
-
 a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -909,8 +909,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom-ipq4019-ap.dk04.1-c3.dtb \
-   qcom-ipq4019-ap.dk07.1-c1.dtb \
-   qcom-ipq4019-ap.dk07.1-c2.dtb \
-+  qcom-ipq8062-wg2600hp3.dtb \
-   qcom-ipq8064-ap148.dtb \
-   qcom-ipq8064-rb3011.dtb \
-+  qcom-ipq8064-c2600.dtb \
-+  qcom-ipq8064-d7800.dtb \
-+  qcom-ipq8064-db149.dtb \
-+  qcom-ipq8064-ap161.dtb \
-+  qcom-ipq8064-ea7500-v1.dtb \
-+  qcom-ipq8064-ea8500.dtb \
-+  qcom-ipq8064-g10.dtb \
-+  qcom-ipq8064-r7500.dtb \
-+  qcom-ipq8064-r7500v2.dtb \
-+  qcom-ipq8064-unifi-ac-hd.dtb \
-+  qcom-ipq8064-wg2600hp.dtb \
-+  qcom-ipq8064-wpq864.dtb \
-+  qcom-ipq8064-wxr-2533dhp.dtb \
-+  qcom-ipq8065-nbg6817.dtb \
-+  qcom-ipq8065-r7800.dtb \
-+  qcom-ipq8065-rt4230w-rev6.dtb \
-+  qcom-ipq8065-tr4400-v2.dtb \
-+  qcom-ipq8065-xr500.dtb \
-+  qcom-ipq8068-ecw5410.dtb \
-+  qcom-ipq8068-mr42.dtb \
-+  qcom-ipq8068-mr52.dtb \
-   qcom-msm8660-surf.dtb \
-   qcom-msm8960-cdp.dtb \
-   qcom-msm8974-fairphone-fp2.dtb \
diff --git 
a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch 
b/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 698df248fb57..
--- a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin 

- arch/arm/boot/dts/Makefile | 8 
- 1 file changed, 8 insertions(+)
-
 a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -957,8 +957,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom-ipq4019-ap.dk04.1-c3.dtb \
-   qcom-ipq4019-ap.dk07.1-c1.dtb \
-   qcom-ipq4019-ap.dk07.1-c2.dtb \
-+  qcom-ipq8062-wg2600hp3.dtb \
-   qcom-ipq8064-ap148.dtb \
-   qcom-ipq8064-rb3011.dtb \
-+  qcom-ipq8064-c2600.dtb \
-+  qcom-ipq8064-d7800.dtb \
-+  qcom-ipq8064

[PATCH v3 3/7] ipq806x: config-5.15: Normalize

[Brian Norris]

Refresh target config with `make kernel_menuconfig`, then save the
result. This drops missing symbols or otherwise accounts for defaults.
It should not change any functionality.

Signed-off-by: Brian Norris 
---

(no changes since v2)

Changes in v2:
 * Improve description

 target/linux/ipq806x/config-5.15 | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/target/linux/ipq806x/config-5.15 b/target/linux/ipq806x/config-5.15
index 72017e7528f1..0bd6dde11cbc 100644
--- a/target/linux/ipq806x/config-5.15
+++ b/target/linux/ipq806x/config-5.15
@@ -34,13 +34,14 @@ CONFIG_ARM_CPU_SUSPEND=y
 # CONFIG_ARM_CPU_TOPOLOGY is not set
 CONFIG_ARM_GIC=y
 CONFIG_ARM_HAS_SG_CHAIN=y
+# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set
+# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set
 CONFIG_ARM_L1_CACHE_SHIFT=6
 CONFIG_ARM_L1_CACHE_SHIFT_6=y
 CONFIG_ARM_MODULE_PLTS=y
 CONFIG_ARM_PATCH_IDIV=y
 CONFIG_ARM_PATCH_PHYS_VIRT=y
 # CONFIG_ARM_QCOM_CPUFREQ_HW is not set
-CONFIG_ARM_QCOM_CPUFREQ_KRAIT=y
 CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y
 CONFIG_ARM_QCOM_SPM_CPUIDLE=y
 # CONFIG_ARM_SMMU is not set
@@ -98,13 +99,11 @@ CONFIG_CRC16=y
 # CONFIG_CRC32_SARWATE is not set
 CONFIG_CRC32_SLICEBY8=y
 CONFIG_CRC8=y
-CONFIG_CRYPTO_BLAKE2S=y
 CONFIG_CRYPTO_DEFLATE=y
 CONFIG_CRYPTO_DEV_QCOM_RNG=y
 CONFIG_CRYPTO_DRBG=y
 CONFIG_CRYPTO_DRBG_HMAC=y
 CONFIG_CRYPTO_DRBG_MENU=y
-CONFIG_CRYPTO_GF128MUL=y
 CONFIG_CRYPTO_HASH_INFO=y
 CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_HW=y
@@ -112,7 +111,6 @@ CONFIG_CRYPTO_JITTERENTROPY=y
 CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
 CONFIG_CRYPTO_LIB_SHA256=y
 CONFIG_CRYPTO_LZO=y
-CONFIG_CRYPTO_NULL2=y
 CONFIG_CRYPTO_RNG=y
 CONFIG_CRYPTO_RNG2=y
 CONFIG_CRYPTO_SHA256=y
@@ -127,8 +125,6 @@ CONFIG_DEVFREQ_GOV_PASSIVE=y
 # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set
 # CONFIG_DEVFREQ_GOV_USERSPACE is not set
 # CONFIG_DEVFREQ_THERMAL is not set
-# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set
-# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set
 CONFIG_DMADEVICES=y
 CONFIG_DMA_ENGINE=y
 CONFIG_DMA_OF=y
@@ -143,6 +139,7 @@ CONFIG_DWMAC_IPQ806X=y
 CONFIG_DYNAMIC_DEBUG=y
 CONFIG_EDAC_ATOMIC_SCRUB=y
 CONFIG_EDAC_SUPPORT=y
+CONFIG_ETHERNET_PACKET_MANGLE=y
 CONFIG_FIXED_PHY=y
 CONFIG_FIX_EARLYCON_MEM=y
 CONFIG_FWNODE_MDIO=y
@@ -152,10 +149,12 @@ CONFIG_GENERIC_BUG=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
 CONFIG_GENERIC_CPU_AUTOPROBE=y
+CONFIG_GENERIC_CPU_VULNERABILITIES=y
 CONFIG_GENERIC_EARLY_IOREMAP=y
 CONFIG_GENERIC_GETTIMEOFDAY=y
 CONFIG_GENERIC_IDLE_POLL_SETUP=y
 CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
+CONFIG_GENERIC_IRQ_MIGRATION=y
 CONFIG_GENERIC_IRQ_MULTI_HANDLER=y
 CONFIG_GENERIC_IRQ_SHOW=y
 CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
@@ -173,6 +172,7 @@ CONFIG_GENERIC_STRNCPY_FROM_USER=y
 CONFIG_GENERIC_STRNLEN_USER=y
 CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GENERIC_VDSO_32=y
+CONFIG_GLOB=y
 CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_CDEV=y
 CONFIG_GRO_CELLS=y
@@ -185,6 +185,7 @@ CONFIG_HAS_IOPORT_MAP=y
 CONFIG_HAVE_SMP=y
 CONFIG_HIGHMEM=y
 # CONFIG_HIGHPTE is not set
+CONFIG_HOTPLUG_CPU=y
 CONFIG_HWMON=y
 CONFIG_HWSPINLOCK=y
 CONFIG_HWSPINLOCK_QCOM=y
@@ -214,12 +215,12 @@ CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y
 CONFIG_IRQ_FORCED_THREADING=y
 CONFIG_IRQ_WORK=y
 CONFIG_KMAP_LOCAL=y
+CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY=y
 CONFIG_KPSS_XCC=y
 CONFIG_KRAITCC=y
 CONFIG_KRAIT_CLOCKS=y
 CONFIG_KRAIT_L2_ACCESSORS=y
 CONFIG_LIBFDT=y
-CONFIG_LLD_VERSION=0
 CONFIG_LOCK_DEBUGGING_SUPPORT=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
 CONFIG_LZO_COMPRESS=y
@@ -300,6 +301,7 @@ CONFIG_NR_CPUS=2
 CONFIG_NVMEM=y
 CONFIG_NVMEM_QCOM_QFPROM=y
 # CONFIG_NVMEM_SPMI_SDAM is not set
+CONFIG_NVMEM_SYSFS=y
 CONFIG_OF=y
 CONFIG_OF_ADDRESS=y
 CONFIG_OF_EARLY_FLATTREE=y
@@ -308,7 +310,6 @@ CONFIG_OF_GPIO=y
 CONFIG_OF_IRQ=y
 CONFIG_OF_KOBJ=y
 CONFIG_OF_MDIO=y
-CONFIG_OF_NET=y
 CONFIG_OLD_SIGACTION=y
 CONFIG_OLD_SIGSUSPEND3=y
 CONFIG_PADATA=y
@@ -397,7 +398,7 @@ CONFIG_QCOM_SCM=y
 # CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is not set
 CONFIG_QCOM_SMEM=y
 # CONFIG_QCOM_SMSM is not set
-# CONFIG_QCOM_SOCINFO is not set
+CONFIG_QCOM_SOCINFO=y
 CONFIG_QCOM_TCSR=y
 CONFIG_QCOM_TSENS=y
 CONFIG_QCOM_WDT=y
@@ -452,6 +453,7 @@ CONFIG_SMP_ON_UP=y
 # CONFIG_SM_VIDEOCC_8150 is not set
 # CONFIG_SM_VIDEOCC_8250 is not set
 CONFIG_SOCK_RX_QUEUE_MAPPING=y
+CONFIG_SOC_BUS=y
 CONFIG_SPARSE_IRQ=y
 CONFIG_SPI=y
 CONFIG_SPI_MASTER=y
-- 
2.39.0


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

Re: [PATCH fstools v2] partname: Ignore root=PARTUUID...

[Brian Norris]

On Mon, Jan 9, 2023 at 3:20 PM Christian Marangi  wrote:
> On Mon, Jan 09, 2023 at 02:34:48PM -0800, Brian Norris wrote:
> > On Mon, Jan 9, 2023 at 1:53 PM Christian Marangi  
> > wrote:
> > >
> > > On Fri, Jan 06, 2023 at 06:04:22PM -0800, Brian Norris wrote:
> > > > We're assuming all root= arguments are /dev/ paths, but many targets
> > > > utilize root=PARTUUID= strategies. At least allow them to fall back
> > > > to scanning all block devices.
> > > >
> > > > Signed-off-by: Brian Norris 
> > >
> > > Can you elaborate this a bit more?
> >
> > This function currently assumes that if it can find a "root=" line,
> > then it can parse it and use it to find "rootfs_data" on the same
> > disk. But the rootdevname() function really chokes (does completely
> > the wrong thing) when given "PARTUUID=". So this parser becomes
> > useless.
> >
> > > This is dependent of the google based
> > > devices with ipq806x but why?
> >
> > I guess it's not *strictly* a dependency, but as-is, things aren't great.
> >
> > With the above choking, I believe fstools will fall back to
> > rootdisk.c, which will place rootfs_data in a different place --
> > appended to the squashfs filesystem, via a custom loopback device.
> > This works OK I suppose, but has its downsides.
> >
> > But the real kicker is that if fstools / partname.c eventually learns
> > how to find the right 'rootfs_data' partition, then suddenly our data
> > filesystem will move, and that's not great for sysupgrade. So I'd like
> > to get it right from the start, rather than change between rootdisk.c
> > and partname.c approaches arbitrarily.
> >
> > > In theory we should have other device with sd card/eMMC that use uuid to
> > > select the partition...
> >
> > Right. Search the tree for the "root=PARTUUID=" string, and you'll
> > find several. (Some breadcrumbs in rockchip, x86, imx, and more.)
> > Presumably they would run into the same problem if they tried to use a
> > dedicated data partition on a block device -- right now, I believe
> > Rockchip restricts itself to a 2-partition layout, for instance. Which
> > is why I didn't specifically call this a ipq806x / Google-specific
> > thing.
> >
>
> This is what gets me most confused... The patch is correct and looks
> good... Just what I can't understand is how things worked till today...
>
> They all fallback to rootdisk.c? It's worth to check and have some proof
> of this theory.
>
> Since we are playing with the function mounting root the main concern
> here is that we brake any device using PARTUUID that somehow are working
> now so we need to be carefull in what we change as the risk of causing
> regression is behind the corner.

Totally understood.

> So we should just find a way to understand why thing are working (or are
> not working and are using an alternative way currently) Just that and
> this can be merged.

I don't have any of these targets. (I suppose I could try to figure
out how, if at all, the x86/generic target is handling this. But it
seems like a very flexible target that can be used in many ways, and
I'm not sure I'd find the Right(TM) ones to test.)

But looking at sources, I see imx (Build/imx-combined-image) and
rockchip (Build/pine64-img) are doing 2-partition layouts, with
$(SCRIPT_DIR)/gen_image_generic.sh. So that skips "partname" and just
does "rootdisk".

On the other hand, Device/glinet_gl-b2200 is one of the few I could
find with a 3-partition (with rootfs_data partition) layout
(qsdk-ipq-app-gpt), and it has an explicit "root=/dev/mmcblk0p2" in
its bootargs. (A related key point: it's the only one using
`CI_DATAPART` for emmc.sh sysupgrade.)

Most (all?) remaining rootfs_data references I see are related to
MTD/UBI, and shouldn't really be relevant.

So I don't have a full proof of it, but it appears that all relevant
users are either 2-partition layouts that use rootdisk.c, or else
using partname.c with a rootfs_data partition but only using /dev
paths for root=. Exceptions would be if someone was manually modifying
their partition layout with a spare rootfs_data partition, in which
case it's possible this could pick it up now. I'm not sure we can
guard against all local customizations though.

I can try to look or play around some more, if you have hints on what
I should investigate. Or wait around for someone (Daniel?) who has
more background in this area?

> > > Also can't we just ignore the device bootargs
> > > and provide a custom one?
> >
> > This isn't about the device (as in, baked into a bootloader) boot

Re: [PATCH fstools v2] partname: Ignore root=PARTUUID...

[Brian Norris]

On Mon, Jan 9, 2023 at 1:53 PM Christian Marangi  wrote:
>
> On Fri, Jan 06, 2023 at 06:04:22PM -0800, Brian Norris wrote:
> > We're assuming all root= arguments are /dev/ paths, but many targets
> > utilize root=PARTUUID= strategies. At least allow them to fall back
> > to scanning all block devices.
> >
> > Signed-off-by: Brian Norris 
>
> Can you elaborate this a bit more?

This function currently assumes that if it can find a "root=" line,
then it can parse it and use it to find "rootfs_data" on the same
disk. But the rootdevname() function really chokes (does completely
the wrong thing) when given "PARTUUID=". So this parser becomes
useless.

> This is dependent of the google based
> devices with ipq806x but why?

I guess it's not *strictly* a dependency, but as-is, things aren't great.

With the above choking, I believe fstools will fall back to
rootdisk.c, which will place rootfs_data in a different place --
appended to the squashfs filesystem, via a custom loopback device.
This works OK I suppose, but has its downsides.

But the real kicker is that if fstools / partname.c eventually learns
how to find the right 'rootfs_data' partition, then suddenly our data
filesystem will move, and that's not great for sysupgrade. So I'd like
to get it right from the start, rather than change between rootdisk.c
and partname.c approaches arbitrarily.

> In theory we should have other device with sd card/eMMC that use uuid to
> select the partition...

Right. Search the tree for the "root=PARTUUID=" string, and you'll
find several. (Some breadcrumbs in rockchip, x86, imx, and more.)
Presumably they would run into the same problem if they tried to use a
dedicated data partition on a block device -- right now, I believe
Rockchip restricts itself to a 2-partition layout, for instance. Which
is why I didn't specifically call this a ipq806x / Google-specific
thing.

> Also can't we just ignore the device bootargs
> and provide a custom one?

This isn't about the device (as in, baked into a bootloader) bootargs;
see "root=PARTUUID=%U/PARTNROFF=1" in my patch 7:
https://patchwork.ozlabs.org/project/openwrt/patch/20230107074945.2140362-7-computersforpe...@gmail.com/
This is a better way of specifying root devices (say, rather than
memorizing a "/dev/mmcblk0" or similar, which is *not* a stable
contract; it also means boot-from-USB won't work), except that fstools
doesn't like it. (And again, there are several other existing
openwrt.git users for it.)

Brian

> > ---
> >
> > Changes in v2:
> >  * fstools, not fsutils (sorry for the noise)
> >
> >  libfstools/partname.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libfstools/partname.c b/libfstools/partname.c
> > index f59c52eb8f3c..9c27015643ad 100644
> > --- a/libfstools/partname.c
> > +++ b/libfstools/partname.c
> > @@ -128,12 +128,12 @@ static struct volume *partname_volume_find(char *name)
> >   return NULL;
> >   }
> >
> > - if (get_var_from_file("/proc/cmdline", "root", rootparam, 
> > sizeof(rootparam))) {
> > + if (get_var_from_file("/proc/cmdline", "root", rootparam, 
> > sizeof(rootparam)) && rootparam[0] == '/') {
> >   rootdev = rootdevname(rootparam);
> >   /* find partition on same device as rootfs */
> >   snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
> > block_dir_name, rootdev);
> >   } else {
> > - /* no 'root=' kernel cmdline parameter, find on any block 
> > device */
> > + /* no useful 'root=' kernel cmdline parameter, find on any 
> > block device */
> >   snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
> > block_dir_name);
> >   }
> >
> > --
> > 2.39.0
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> --
> Ansuel

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

Re: [PATCH v2 6/7] coreutils: Import from packages feed

[Brian Norris]

On Mon, Jan 9, 2023 at 11:56 AM Christian Marangi  wrote:
> On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote:
> > For my use, it feels like a simplified form (which only needs to be a
> > stdin/stdout pipeline) would be pretty easy to inline into the
> > caldata/firmware-loader script:
> >
> >   ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
> >
>
> Ok a single line solution will be ideal and easy to include in the
> hotplug script.

Sounds good.

> > > 2. Ucode is part of the core packages? Or an optional dependency for
> > > luci and fw4? In theory it should be always present or as a safe thing
> > > we should add ucode in the required packages for this target?
> >
> > So far I don't find it as a strict core dependency, but just happens
> > to be available by default due to dependencies. I guess similar
> > questions to the busybox, coreutils, etc., stuff -- whether we're OK
> > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
> >
>
> If it's not a strict core dependency I would just put ucode as a
> dependency for the needed devices and be done with it. It's not a low
> space target and ucode is not that big and for sure smaller than lua,
> openssl and easier to implement than moving coreutils from feeds to
> core.

Sounds good to me.

Thanks all for the help.

> Think with v3 and this implemented the series is ready.

Great! Unfortunately, I'm still dependent on an outstanding patch for
the fstools project:
https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/
See also patch 7's notes.

I guess I could revert to the 2-partition layout (which does not
depend on the fstools change) for the time being, so snapshots would
work. I'm still trying to figure out what the best partitioning and
syupgrade strategy is best for disk space flexibility and for
reliability (e.g., not clobbering rootfs_data when it's appended to
rootfs) on block devices...

Brian

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

Re: [PATCH v2 6/7] coreutils: Import from packages feed

[Brian Norris]

On Mon, Jan 9, 2023 at 11:21 AM Christian Marangi  wrote:
>
> On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote:
> > Petr Štetiar  [2023-01-09 11:50:37]:
> >
> > Hi,
> >
> > > BTW ucode has `b64dec()`[1] so perhaps another viable option.
> > >
> > > 1. https://github.com/jow-/ucode#663-b64decstr
> >
> > wanted to refresh my ucode brain cells, so I've explored feasibility of that
> > suggestion and it seems to work just fine:
> >
> >   #!/usr/bin/ucode
> >
> >   import { stdin, open, error } from 'fs';
> >
> >   if (length(ARGV) == 0 && stdin.isatty()) {
> >   warn("usage: b64decode [stdin|path]\n");
> >   exit(1);
> >   }
> >
> >   let fp = stdin;
> >   let source = ARGV[0];
> >
> >   if (source) {
> >   fp = open(source);
> >   if (!fp) {
> >   warn(`b64decode: unable to open ${source}: 
> > ${error()}\n`);
> >   exit(1);
> >   }
> >   }
> >
> >   print(b64dec(fp.read("all")));
> >   fp.close();
> >   exit(0);
> >
> > BTW it needs recent ucode with fs.stdin.isatty() support[1].
> >
> > Thanks Jo for helping me making above script more idiomatic. IMO it looks 
> > more
> > human readable, portable and maintanable then that awk based solution.
> >
> > 1. 
> > https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1

I sidestepped the isatty() stuff (below), and this works for me too.

> Thanks for helping with this. I really like the ucode way. Just a few
> question:
> 1. How this should be handled? A script that the target will provide?
> Part of a common function?

For my use, it feels like a simplified form (which only needs to be a
stdin/stdout pipeline) would be pretty easy to inline into the
caldata/firmware-loader script:

  ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'

> 2. Ucode is part of the core packages? Or an optional dependency for
> luci and fw4? In theory it should be always present or as a safe thing
> we should add ucode in the required packages for this target?

So far I don't find it as a strict core dependency, but just happens
to be available by default due to dependencies. I guess similar
questions to the busybox, coreutils, etc., stuff -- whether we're OK
with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.

Brian

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

Re: [PATCH v2 6/7] coreutils: Import from packages feed

[Brian Norris]

On Sun, Jan 8, 2023 at 1:37 PM Thibaut  wrote:
> > Le 8 janv. 2023 à 21:53, Christian Marangi  a écrit :
> >
> > On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote:
> >> Brian Norris  [2023-01-06 23:49:44]:
> >>
> >> Hi Brian,
> >>
> >>> I need to express a per-target dependency on the 'base64' utility, and
> >>> that's seemingly impossible to do for busybox.
> >>
> >>  --- a/target/linux/ipq806x/Makefile
> >>  +++ b/target/linux/ipq806x/Makefile
> >>  @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15
> >>   KERNELNAME:=zImage Image dtbs
> >>
> >>   include $(INCLUDE_DIR)/target.mk
> >>  +
> >>  +DEPENDS:= \
> >>  +   +@BUSYBOX_DEFAULT_BASE64
> >>  +

Thanks! That does indeed work for me. And I might just throw it into
target/linux/ipq806x/chromium/target.mk instead, since the generic
target won't be using base64.

> > Is this already used for other target? Wonder if this special thing
> > would cause some problem for packages of this target? Like discrepancy
> > with stage2 and final image?

stage2 as in sysupgrade? I don't immediately see how that would be a
problem, but maybe I'm not understanding well enough.

> AFAICT this isn’t used anywhere so far (at least according to a quick git 
> grep).

Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in
the current tree or in the git history.

And I can't even find anyone doing a bare 'DEPENDS:=' in their
Makefile under target/linux/ at all. All usages are as part of
packages (modules), not device/target specifications.

> > Anyway this looks to be the best solution for the problem.
>
> I wonder if it’s such a good idea to have discrepancies in busybox features 
> between targets?

I don't think I know enough about OpenWrt development yet to have a
good answer on this, so I'll let you all try to answer this.

But if I don't hear some specific negatives or some other consensus
within a day or few, I'll try BUSYBOX_DEFAULT_BASE64 for a v3.

Of course, I can also hold off sending if people were actively looking
at the other parts of this series still.

Brian

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

[PATCH v2 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

TP-Link and ASUS OnHub devices are very similar, sharing many of the
same characteristics and much of their Device Tree. They both run a
version of ChromeOS for their factory firmware, and so installation
instructions look very similar to Google Wifi [1].

Things that work:

 * Ethernet
 * WiFi (2.4 and 5 GHz)
 * LEDs
 * USB
 * eMMC
 * Serial console (if you wire it up yourself)
 * 1 CPU
 * Speaker; I think I've worked out the kinks (with the parent patches,
   and tweaking pin configuration a bit)

Things that don't work:

 * The second CPU; bringing up the second CPU seems to hang right now,
   so I disable it with "maxcpus=1".

== Installation instructions summary ==

1. Flash *-factory.bin to a USB drive (e.g., with `dd`)
2. Enter Developer Mode
3. Insert USB drive, to boot OpenWrt from USB
4. Copy the same *-factory.bin over to device, and flash it to eMMC to
   make OpenWrt permanent

== Developer mode (Step 2) ==

To enter Developer Mode [2], follow these steps:

1. Unplug power
2. Gain access to the "developer switch" through the bottom of the
   device
3. Plug a USB keyboard into the device's USB port
4. Hold down the "reset switch" (near the USB port / power plug)
5. Plug power back in
6. The LED on the device should turn white, then blink orange, then
   red. Release the reset switch.
7. Press CTRL+D on the keyboard. The LED should now start blinking
   purple.
8. Press and release the hidden "developer switch" under the device.
9. The device should reboot, and start blinking purple again. You have
   successfully entered developer mode.
10. Unplug power

These instructions are derived from:

https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub
https://www.exploitee.rs/index.php/Asus_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub

~~Finding the developer switch:~~ for TP-Link, the developer switch is
on the bottom of the device, underneath some of the rubber padding and a
screw. For ASUS, remove the entire base, via 4 screws under the rubber
feet. See the Exploitee instructions for more info and photos.

== Booting from USB (Step 3) ==

After entering developer mode:

1. Unplug power
2. Insert USB drive with OpenWrt factory.bin
3. Plug power; after a few seconds, the device should start blinking
   purple
4. Press the hidden developer switch under the device to boot to USB;
   you should see some activity lights (if you have any) on your USB
   drive
5. Depending on your configuration, the router's LED(s) should come on.
   You're now running OpenWrt off a USB stick.

== Making OpenWrt permanent (on eMMC) (Step 4) ==

Once you're running OpenWrt via USB:

1. Connect Ethernet to the LAN port; router's LAN address should be at
   192.168.1.1
2. Connect another system to the router's LAN, and copy the factory.bin
   image over, via SCP and SSH:

 scp -O openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin 
root@192.168.1.1:
 ssh root@192.168.1.1 -C "dd if=/dev/zero bs=512 seek=7552991 
of=/dev/mmcblk0 count=33 && \
 dd if=/root/openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin 
of=/dev/mmcblk0"
3. Reboot and remove the USB drive.

== Developer mode beep ==

Note that every time you boot the OnHub in developer mode, the device
will play a loud "beep" after a few seconds. This is described in the
Chromium docs [2], and is intended to make it clear that the device is
not running Google software. It is nontrivial to completely disable this
beep, although it's possible to "acknowledge" developer mode (and skip
the beep) by using a USB keyboard to press CTRL+D every time you boot.

[1] https://openwrt.org/toh/google/wifi
[2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md

Signed-off-by: Brian Norris 
---
 * There might be better ways to handle the multi-color LED support,
   but for now, each color is a separate LED
 * A variety of people have been interested in this work, and a few have
   tested versions of it already:
 https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899
 * This is dependent on an fstools change, to ensure it can find our
   'rootfs_data' properly:
 [PATCH fstools v2] partname: Ignore root=PARTUUID...
 
https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/

Changes in v2:
 * Drop custom ath10k base64 property
 * Provide base64 caldata parsing via
   /etc/hotplug.d/firmware/11-ath10k-caldata instead
 * add coreutils-base64 dependency
 * add 3rd (rootfs_data) partition, to better handle sysupgrade and
   utilize the whole disk

 target/linux/ipq806x/Makefile |   4 +-
 .../ipq806x/base-files/etc/board.d/01_leds|  11 +
 .../ipq806x/base-files/etc/board.d/02_network |   6 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  35 ++
 .../base-files/lib/upgrade/platform.sh|  19 +
 target/linux/ipq

[PATCH v2 6/7] coreutils: Import from packages feed

[Brian Norris]

I need to express a per-target dependency on the 'base64' utility, and
that's seemingly impossible to do for busybox. Pull in coreutils to make
that easier.

Signed-off-by: Brian Norris 
---
 * New in v2


(no changes since v1)

 package/utils/coreutils/Makefile  | 153 ++
 .../patches/001-no_docs_man_tests.patch   |  93 +++
 2 files changed, 246 insertions(+)
 create mode 100644 package/utils/coreutils/Makefile
 create mode 100644 package/utils/coreutils/patches/001-no_docs_man_tests.patch

diff --git a/package/utils/coreutils/Makefile b/package/utils/coreutils/Makefile
new file mode 100644
index ..d1af3ce962f1
--- /dev/null
+++ b/package/utils/coreutils/Makefile
@@ -0,0 +1,153 @@
+#
+# Copyright (C) 2008-2014 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=coreutils
+PKG_VERSION:=9.1
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
+PKG_SOURCE_URL:=@GNU/coreutils
+PKG_HASH:=61a1f410d78ba7e7f37a5a4f50e6d1320aca33375484a3255eddf17a38580423
+
+PKG_MAINTAINER:=Jo-Philipp Wich 
+PKG_LICENSE:=GPL-3.0-or-later
+PKG_LICENSE_FILES:=COPYING
+PKG_CPE_ID:=cpe:/a:gnu:coreutils
+
+PKG_INSTALL:=1
+PKG_BUILD_PARALLEL:=1
+
+include $(INCLUDE_DIR)/package.mk
+
+COREUTILS_APPLETS := \
+   base32 base64 basename basenc b2sum cat chcon chgrp chmod chown chroot  
\
+   cksum comm cp csplit cut date dd df dir dircolors dirname du echo env   
\
+   expand expr factor false fmt fold groups head hostid id install join
\
+   kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl 
\
+   nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd
\
+   readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum   
\
+   sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum
\
+   sync tac tail tee test timeout touch tr true truncate tsort tty uname   
\
+   unexpand uniq unlink uptime users vdir wc who whoami yes
+
+DIR_BIN := \
+   base64 cat chgrp chmod chown cp date dd df echo false kill link ln ls   
\
+   mkdir mknod mktemp mv nice printenv pwd rm rmdir sleep stat stty sync   
\
+   touch true uname
+
+DIR_USR_BIN := \
+   basename chcon cksum comm cut dirname du env expand expr factor fold
\
+   groups head hostid id install logname md5sum mkfifo nl nohup nproc od   
\
+   paste printf readlink realpath runcon seq sha1sum sha256sum sha512sum   
\
+   shred shuf sort split sum tac tail tee test timeout tr truncate tty 
\
+   unexpand uniq unlink uptime users wc who whoami yes
+
+DIR_USR_SBIN := \
+   chroot
+
+# BusyBox does not provide these yet
+DIR_OTHERS := \
+   base32 b2sum basenc csplit dir dircolors fmt join numfmt pathchk pinky  
\
+   pr ptx sha224sum sha384sum stdbuf tsort vdir
+
+$(eval $(foreach 
a,$(DIR_BIN),ALTS_$(a):=300:/bin/$(a):/usr/libexec/$(a)-coreutils$(newline)))
+$(eval $(foreach 
a,$(DIR_USR_BIN),ALTS_$(a):=300:/usr/bin/$(a):/usr/libexec/$(a)-coreutils$(newline)))
+$(eval $(foreach 
a,$(DIR_USR_SBIN),ALTS_$(a):=300:/usr/sbin/$(a):/usr/libexec/$(a)-coreutils$(newline)))
+
+DEPENDS_sort = +libpthread
+DEPENDS_timeout = +librt
+DEPENDS_expr = +libgmp
+DEPENDS_factor = +libgmp
+DEPENDS_cp = +libacl
+DEPENDS_dir = +libacl +libcap
+DEPENDS_install = +libacl
+DEPENDS_ls = +libacl +libcap
+DEPENDS_mv = +libacl
+DEPENDS_vdir = +libacl +libcap
+
+FILES_stdbuf := usr/lib/coreutils/libstdbuf.so
+
+define Package/coreutils/Default
+  SECTION:=utils
+  CATEGORY:=Utilities
+  TITLE:=The GNU core utilities
+  URL:=http://www.gnu.org/software/coreutils/
+endef
+
+define Package/coreutils
+  $(call Package/coreutils/Default)
+  TITLE:=The GNU core utilities
+  MENU:=1
+endef
+
+define Package/coreutils/description
+ Full versions of standard GNU utilities. If an equivalent Busybox applet is
+ available, you should consider compiling that instead as Busybox applets are
+ usually smaller, at the expense of reduced functionality.
+endef
+
+define GenPlugin
+ define Package/$(1)
+   $(call Package/coreutils/Default)
+   DEPENDS:=coreutils $(DEPENDS_$(2))
+   TITLE:=Utility $(2) from the GNU core utilities
+   ALTERNATIVES:=$(ALTS_$(2))
+ endef
+
+ define Package/$(1)/description
+  Full version of standard GNU $(2) utility.
+ endef
+endef
+
+$(foreach a,$(COREUTILS_APPLETS),$(eval $(call GenPlugin,coreutils-$(a),$(a
+
+CONFIGURE_VARS += \
+   gl_cv_func_mbrtowc_incomplete_state=yes \
+   gl_cv_func_mbrtowc_retval=yes \
+   gl_cv_func_wcrtomb_retval=yes \
+   ac_cv_header_selinux_context_h=no \
+   ac_cv_header_selinux_flash_h=no \
+   ac_cv_header_selinux_selinux_h=no \
+   ac_cv_search_setfilecon=no
+
+CONFIGURE_ARGS += \
+   --disable-xattr \
+   --enable-install-program=su \
+   --enable-threads=posix \
+   --enable-acl

[PATCH v2 5/7] ipq806x: Add kmod-sound-soc-ipq8064-storm

[Brian Norris]

For IPQ8064 systems based off the "Google Storm" reference platform,
such as the TP-Link OnHub.

Signed-off-by: Brian Norris 
---

Changes in v2:
 * Drop CONFIG_IPQ_LCC_806X=y, and merge CONFIG_IPQ_LCC_806X=m into this
   package
 * Move package to the ipq806x target
 * Slim AutoLoad list; switch to AutoProbe

 target/linux/ipq806x/modules.mk | 29 +
 1 file changed, 29 insertions(+)

diff --git a/target/linux/ipq806x/modules.mk b/target/linux/ipq806x/modules.mk
index 605504b0c338..a2b844d0f03c 100644
--- a/target/linux/ipq806x/modules.mk
+++ b/target/linux/ipq806x/modules.mk
@@ -14,3 +14,32 @@ define KernelPackage/phy-qcom-ipq806x-usb/description
 endef
 
 $(eval $(call KernelPackage,phy-qcom-ipq806x-usb))
+
+
+define KernelPackage/sound-soc-ipq8064-storm
+  TITLE:=Qualcomm IPQ8064 SoC support for Google Storm
+  DEPENDS:=@TARGET_ipq806x +kmod-sound-soc-core
+  KCONFIG:=\
+   CONFIG_IPQ_LCC_806X \
+   CONFIG_SND_SOC_QCOM \
+   CONFIG_SND_SOC_STORM \
+   CONFIG_SND_SOC_APQ8016_SBC=n \
+   CONFIG_SND_SOC_SC7180=n
+  FILES:=\
+   $(LINUX_DIR)/drivers/clk/qcom/lcc-ipq806x.ko \
+   $(LINUX_DIR)/sound/soc/codecs/snd-soc-max98357a.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-cpu.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-ipq806x.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-platform.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-storm.ko
+  AUTOLOAD:=$(call AutoProbe,lcc-ipq806x \
+   snd-soc-max98357a snd-soc-lpass-ipq806x snd-soc-storm)
+  $(call AddDepends/sound)
+endef
+
+define KernelPackage/sound-soc-ipq8064-storm/description
+ Provides sound support for the Google Storm platform, with a Qualcomm IPQ8064
+ SoC.
+endef
+
+$(eval $(call KernelPackage,sound-soc-ipq8064-storm))
-- 
2.39.0


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

[PATCH v2 4/7] ipq806x: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling

[Brian Norris]

This fixes device tree registration for 'qcom,lpass-cpu' as used by
qcom-ipq8064 SoCs, and allows speaker audio to function.

This patch has been submitted (and merged, for -next; likely v6.3)
upstream.

Signed-off-by: Brian Norris 
---

Changes in v2:
 * Add upstream (-next) notes
 * Renumber to 0xx-v6.3-*.patch

 ...cpu-Fix-fallback-SD-line-index-handl.patch | 42 +++
 1 file changed, 42 insertions(+)
 create mode 100644 
target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch

diff --git 
a/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
 
b/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
new file mode 100644
index ..099dc606114e
--- /dev/null
+++ 
b/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
@@ -0,0 +1,42 @@
+From: Brian Norris 
+Date: Thu, 15 Dec 2022 01:33:45 -0800
+Subject: [PATCH] ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+
+[[ Submitted upstream as:
+   
https://lore.kernel.org/all/20221231061545.2110253-1-computersforpe...@gmail.com/
+   Currently queued for -next (v6.3?) as:
+   000bca8d706d ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+]]
+
+These indices should reference the ID placed within the dai_driver
+array, not the indices of the array itself.
+
+This fixes commit 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD
+lines configurable"), which among others, broke IPQ8064 audio
+(sound/soc/qcom/lpass-ipq806x.c) because it uses ID 4 but we'd stop
+initializing the mi2s_playback_sd_mode and mi2s_capture_sd_mode arrays
+at ID 0.
+
+Fixes: 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD lines configurable")
+Cc: 
+Signed-off-by: Brian Norris 
+---
+ sound/soc/qcom/lpass-cpu.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/qcom/lpass-cpu.c
 b/sound/soc/qcom/lpass-cpu.c
+@@ -851,10 +851,11 @@ static void of_lpass_cpu_parse_dai_data(
+   struct lpass_data *data)
+ {
+   struct device_node *node;
+-  int ret, id;
++  int ret, i, id;
+ 
+   /* Allow all channels by default for backwards compatibility */
+-  for (id = 0; id < data->variant->num_dai; id++) {
++  for (i = 0; i < data->variant->num_dai; i++) {
++  id = data->variant->dai_driver[i].id;
+   data->mi2s_playback_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+   data->mi2s_capture_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+   }
-- 
2.39.0


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

[PATCH v2 3/7] ipq806x: config-5.15: Normalize

[Brian Norris]

Refresh target config with `make kernel_menuconfig`, then save the
result. This drops missing symbols or otherwise accounts for defaults.
It should not change any functionality.

Signed-off-by: Brian Norris 
---

Changes in v2:
 * Improve description

 target/linux/ipq806x/config-5.15 | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/target/linux/ipq806x/config-5.15 b/target/linux/ipq806x/config-5.15
index 72017e7528f1..0bd6dde11cbc 100644
--- a/target/linux/ipq806x/config-5.15
+++ b/target/linux/ipq806x/config-5.15
@@ -34,13 +34,14 @@ CONFIG_ARM_CPU_SUSPEND=y
 # CONFIG_ARM_CPU_TOPOLOGY is not set
 CONFIG_ARM_GIC=y
 CONFIG_ARM_HAS_SG_CHAIN=y
+# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set
+# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set
 CONFIG_ARM_L1_CACHE_SHIFT=6
 CONFIG_ARM_L1_CACHE_SHIFT_6=y
 CONFIG_ARM_MODULE_PLTS=y
 CONFIG_ARM_PATCH_IDIV=y
 CONFIG_ARM_PATCH_PHYS_VIRT=y
 # CONFIG_ARM_QCOM_CPUFREQ_HW is not set
-CONFIG_ARM_QCOM_CPUFREQ_KRAIT=y
 CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y
 CONFIG_ARM_QCOM_SPM_CPUIDLE=y
 # CONFIG_ARM_SMMU is not set
@@ -98,13 +99,11 @@ CONFIG_CRC16=y
 # CONFIG_CRC32_SARWATE is not set
 CONFIG_CRC32_SLICEBY8=y
 CONFIG_CRC8=y
-CONFIG_CRYPTO_BLAKE2S=y
 CONFIG_CRYPTO_DEFLATE=y
 CONFIG_CRYPTO_DEV_QCOM_RNG=y
 CONFIG_CRYPTO_DRBG=y
 CONFIG_CRYPTO_DRBG_HMAC=y
 CONFIG_CRYPTO_DRBG_MENU=y
-CONFIG_CRYPTO_GF128MUL=y
 CONFIG_CRYPTO_HASH_INFO=y
 CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_HW=y
@@ -112,7 +111,6 @@ CONFIG_CRYPTO_JITTERENTROPY=y
 CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
 CONFIG_CRYPTO_LIB_SHA256=y
 CONFIG_CRYPTO_LZO=y
-CONFIG_CRYPTO_NULL2=y
 CONFIG_CRYPTO_RNG=y
 CONFIG_CRYPTO_RNG2=y
 CONFIG_CRYPTO_SHA256=y
@@ -127,8 +125,6 @@ CONFIG_DEVFREQ_GOV_PASSIVE=y
 # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set
 # CONFIG_DEVFREQ_GOV_USERSPACE is not set
 # CONFIG_DEVFREQ_THERMAL is not set
-# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set
-# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set
 CONFIG_DMADEVICES=y
 CONFIG_DMA_ENGINE=y
 CONFIG_DMA_OF=y
@@ -143,6 +139,7 @@ CONFIG_DWMAC_IPQ806X=y
 CONFIG_DYNAMIC_DEBUG=y
 CONFIG_EDAC_ATOMIC_SCRUB=y
 CONFIG_EDAC_SUPPORT=y
+CONFIG_ETHERNET_PACKET_MANGLE=y
 CONFIG_FIXED_PHY=y
 CONFIG_FIX_EARLYCON_MEM=y
 CONFIG_FWNODE_MDIO=y
@@ -152,10 +149,12 @@ CONFIG_GENERIC_BUG=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
 CONFIG_GENERIC_CPU_AUTOPROBE=y
+CONFIG_GENERIC_CPU_VULNERABILITIES=y
 CONFIG_GENERIC_EARLY_IOREMAP=y
 CONFIG_GENERIC_GETTIMEOFDAY=y
 CONFIG_GENERIC_IDLE_POLL_SETUP=y
 CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
+CONFIG_GENERIC_IRQ_MIGRATION=y
 CONFIG_GENERIC_IRQ_MULTI_HANDLER=y
 CONFIG_GENERIC_IRQ_SHOW=y
 CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
@@ -173,6 +172,7 @@ CONFIG_GENERIC_STRNCPY_FROM_USER=y
 CONFIG_GENERIC_STRNLEN_USER=y
 CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GENERIC_VDSO_32=y
+CONFIG_GLOB=y
 CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_CDEV=y
 CONFIG_GRO_CELLS=y
@@ -185,6 +185,7 @@ CONFIG_HAS_IOPORT_MAP=y
 CONFIG_HAVE_SMP=y
 CONFIG_HIGHMEM=y
 # CONFIG_HIGHPTE is not set
+CONFIG_HOTPLUG_CPU=y
 CONFIG_HWMON=y
 CONFIG_HWSPINLOCK=y
 CONFIG_HWSPINLOCK_QCOM=y
@@ -214,12 +215,12 @@ CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y
 CONFIG_IRQ_FORCED_THREADING=y
 CONFIG_IRQ_WORK=y
 CONFIG_KMAP_LOCAL=y
+CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY=y
 CONFIG_KPSS_XCC=y
 CONFIG_KRAITCC=y
 CONFIG_KRAIT_CLOCKS=y
 CONFIG_KRAIT_L2_ACCESSORS=y
 CONFIG_LIBFDT=y
-CONFIG_LLD_VERSION=0
 CONFIG_LOCK_DEBUGGING_SUPPORT=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
 CONFIG_LZO_COMPRESS=y
@@ -300,6 +301,7 @@ CONFIG_NR_CPUS=2
 CONFIG_NVMEM=y
 CONFIG_NVMEM_QCOM_QFPROM=y
 # CONFIG_NVMEM_SPMI_SDAM is not set
+CONFIG_NVMEM_SYSFS=y
 CONFIG_OF=y
 CONFIG_OF_ADDRESS=y
 CONFIG_OF_EARLY_FLATTREE=y
@@ -308,7 +310,6 @@ CONFIG_OF_GPIO=y
 CONFIG_OF_IRQ=y
 CONFIG_OF_KOBJ=y
 CONFIG_OF_MDIO=y
-CONFIG_OF_NET=y
 CONFIG_OLD_SIGACTION=y
 CONFIG_OLD_SIGSUSPEND3=y
 CONFIG_PADATA=y
@@ -397,7 +398,7 @@ CONFIG_QCOM_SCM=y
 # CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is not set
 CONFIG_QCOM_SMEM=y
 # CONFIG_QCOM_SMSM is not set
-# CONFIG_QCOM_SOCINFO is not set
+CONFIG_QCOM_SOCINFO=y
 CONFIG_QCOM_TCSR=y
 CONFIG_QCOM_TSENS=y
 CONFIG_QCOM_WDT=y
@@ -452,6 +453,7 @@ CONFIG_SMP_ON_UP=y
 # CONFIG_SM_VIDEOCC_8150 is not set
 # CONFIG_SM_VIDEOCC_8250 is not set
 CONFIG_SOCK_RX_QUEUE_MAPPING=y
+CONFIG_SOC_BUS=y
 CONFIG_SPARSE_IRQ=y
 CONFIG_SPI=y
 CONFIG_SPI_MASTER=y
-- 
2.39.0


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

[PATCH v2 2/7] ipq806x: Point to externally compiled dtbs in recipes

[Brian Norris]

Similar to commit 4d8b42d8a777 ("ipq40xx: point to externally compiled
dtbs in recipes").

Currently, we patch our DTS files into the kernel source tree, so the
kernel build process will produce DTBs for us. The kernel-to-DTS
dependency can cause buildroot to perform excessive rebuilds of the
kernel though, which slows down device development iteration.

Buildroot also compiles DTBs on its own, to
$(KDIR)/image-$(DEVICE_DTS).dtb. With small adjustments, we can leverage
this, and stop patching DTS files into the kernel Makefile at the same
time.

Signed-off-by: Brian Norris 
---

Changes in v2:
 * Improve commit description

 target/linux/ipq806x/image/Makefile   |  5 +--
 .../0069-arm-boot-add-dts-files.patch | 43 ---
 .../0069-arm-boot-add-dts-files.patch | 43 ---
 3 files changed, 2 insertions(+), 89 deletions(-)
 delete mode 100644 
target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
 delete mode 100644 
target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch

diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile
index f4f829b35c65..8c1fc88010cd 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -5,7 +5,6 @@ include $(INCLUDE_DIR)/image.mk
 
 define Device/Default
PROFILES := Default
-   KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts)
KERNEL_LOADADDR = 0x42208000
DEVICE_DTS = $$(SOC)-$(lastword $(subst _, ,$(1)))
DEVICE_DTS_CONFIG := config@1
@@ -22,13 +21,13 @@ endef
 
 define Device/FitImage
KERNEL_SUFFIX := -fit-uImage.itb
-   KERNEL = kernel-bin | gzip | fit gzip $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+   KERNEL = kernel-bin | gzip | fit gzip $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
 endef
 
 define Device/FitImageLzma
KERNEL_SUFFIX := -fit-uImage.itb
-   KERNEL = kernel-bin | lzma | fit lzma $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+   KERNEL = kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
 endef
 
diff --git 
a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch 
b/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 4c42f40e3d78..
--- a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin 

- arch/arm/boot/dts/Makefile | 8 
- 1 file changed, 8 insertions(+)
-
 a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -909,8 +909,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom-ipq4019-ap.dk04.1-c3.dtb \
-   qcom-ipq4019-ap.dk07.1-c1.dtb \
-   qcom-ipq4019-ap.dk07.1-c2.dtb \
-+  qcom-ipq8062-wg2600hp3.dtb \
-   qcom-ipq8064-ap148.dtb \
-   qcom-ipq8064-rb3011.dtb \
-+  qcom-ipq8064-c2600.dtb \
-+  qcom-ipq8064-d7800.dtb \
-+  qcom-ipq8064-db149.dtb \
-+  qcom-ipq8064-ap161.dtb \
-+  qcom-ipq8064-ea7500-v1.dtb \
-+  qcom-ipq8064-ea8500.dtb \
-+  qcom-ipq8064-g10.dtb \
-+  qcom-ipq8064-r7500.dtb \
-+  qcom-ipq8064-r7500v2.dtb \
-+  qcom-ipq8064-unifi-ac-hd.dtb \
-+  qcom-ipq8064-wg2600hp.dtb \
-+  qcom-ipq8064-wpq864.dtb \
-+  qcom-ipq8064-wxr-2533dhp.dtb \
-+  qcom-ipq8065-nbg6817.dtb \
-+  qcom-ipq8065-r7800.dtb \
-+  qcom-ipq8065-rt4230w-rev6.dtb \
-+  qcom-ipq8065-tr4400-v2.dtb \
-+  qcom-ipq8065-xr500.dtb \
-+  qcom-ipq8068-ecw5410.dtb \
-+  qcom-ipq8068-mr42.dtb \
-+  qcom-ipq8068-mr52.dtb \
-   qcom-msm8660-surf.dtb \
-   qcom-msm8960-cdp.dtb \
-   qcom-msm8974-fairphone-fp2.dtb \
diff --git 
a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch 
b/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 698df248fb57..
--- a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin 

- arch/arm/boot/dts/Makefile | 8 
- 1 file changed, 8 insertions(+)
-
 a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -957,8 +957,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom-ipq4019-ap.dk04.1-c3.dtb \
-   qcom-ipq4019-ap.dk07.1-c1.dtb \
-   qcom-ipq4019-ap.dk07.1-c2.dtb \
-+  qcom-ipq8062-wg2600hp3.dtb \
-   qcom-ipq8064-ap148.dtb \
-   qcom-ipq8064-rb3011.dtb \
-+  qcom-ipq8064-c2600.dtb \
-+  qcom-ipq8064-d7800.dtb \
-+  qcom-ipq8064-db149.dtb \
-+  qcom-ipq8064

[PATCH v2 1/7] base-files: Remove nand.sh dependency from emmc upgrade

[Brian Norris]

emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.

Rename identify_magic() to identify_magic_long() to match the common.sh
style and make it clear it pairs with other *_long() variants (and not,
say *_word()).

Signed-off-by: Brian Norris 
---

(no changes since v1)

 .../base-files/files/lib/upgrade/common.sh| 27 
 package/base-files/files/lib/upgrade/emmc.sh  |  2 +-
 package/base-files/files/lib/upgrade/nand.sh  | 32 ++-
 3 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 5af061f6a439..53b8865a5788 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -127,6 +127,33 @@ get_magic_fat32() {
(get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
 }
 
+identify_magic_long() {
+   local magic=$1
+   case "$magic" in
+   "55424923")
+   echo "ubi"
+   ;;
+   "31181006")
+   echo "ubifs"
+   ;;
+   "68737173")
+   echo "squashfs"
+   ;;
+   "d00dfeed")
+   echo "fit"
+   ;;
+   "4349"*)
+   echo "combined"
+   ;;
+   "1f8b"*)
+   echo "gzip"
+   ;;
+   *)
+   echo "unknown $magic"
+   ;;
+   esac
+}
+
 part_magic_efi() {
local magic=$(get_magic_gpt "$@")
[ "$magic" = "EFI PART" ]
diff --git a/package/base-files/files/lib/upgrade/emmc.sh 
b/package/base-files/files/lib/upgrade/emmc.sh
index c3b02864aa91..49cffe1c658b 100644
--- a/package/base-files/files/lib/upgrade/emmc.sh
+++ b/package/base-files/files/lib/upgrade/emmc.sh
@@ -58,7 +58,7 @@ emmc_copy_config() {
 }
 
 emmc_do_upgrade() {
-   local file_type=$(identify $1)
+   local file_type=$(identify_magic_long "$(get_magic_long "$1")")
 
case "$file_type" in
"fit")  emmc_upgrade_fit $1;;
diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index a8e3cab0b8b1..a1dbd6e2663d 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -65,40 +65,12 @@ get_magic_long_tar() {
(tar xO${3}f "$1" "$2" | dd bs=4 count=1 | hexdump -v -n 4 -e '1/1 
"%02x"') 2> /dev/null
 }
 
-identify_magic() {
-   local magic=$1
-   case "$magic" in
-   "55424923")
-   echo "ubi"
-   ;;
-   "31181006")
-   echo "ubifs"
-   ;;
-   "68737173")
-   echo "squashfs"
-   ;;
-   "d00dfeed")
-   echo "fit"
-   ;;
-   "4349"*)
-   echo "combined"
-   ;;
-   "1f8b"*)
-   echo "gzip"
-   ;;
-   *)
-   echo "unknown $magic"
-   ;;
-   esac
-}
-
-
 identify() {
-   identify_magic $(nand_get_magic_long "$@")
+   identify_magic_long $(nand_get_magic_long "$@")
 }
 
 identify_tar() {
-   identify_magic $(get_magic_long_tar "$@")
+   identify_magic_long $(get_magic_long_tar "$@")
 }
 
 identify_if_gzip() {
-- 
2.39.0


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

[PATCH fsutils] partname: Ignore root=PARTUUID...

[Brian Norris]

We're assuming all root= arguments are /dev/ paths, but many targets
utilize root=PARTUUID= strategies. At least allow them to fall back
to scanning all block devices.

Signed-off-by: Brian Norris 
---

 libfstools/partname.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f59c52eb8f3c..9c27015643ad 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -128,12 +128,12 @@ static struct volume *partname_volume_find(char *name)
return NULL;
}
 
-   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam))) {
+   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam)) && rootparam[0] == '/') {
rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
} else {
-   /* no 'root=' kernel cmdline parameter, find on any block 
device */
+   /* no useful 'root=' kernel cmdline parameter, find on any 
block device */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
block_dir_name);
}
 
-- 
2.39.0


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

[PATCH fstools v2] partname: Ignore root=PARTUUID...

[Brian Norris]

We're assuming all root= arguments are /dev/ paths, but many targets
utilize root=PARTUUID= strategies. At least allow them to fall back
to scanning all block devices.

Signed-off-by: Brian Norris 
---

Changes in v2:
 * fstools, not fsutils (sorry for the noise)

 libfstools/partname.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libfstools/partname.c b/libfstools/partname.c
index f59c52eb8f3c..9c27015643ad 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -128,12 +128,12 @@ static struct volume *partname_volume_find(char *name)
return NULL;
}
 
-   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam))) {
+   if (get_var_from_file("/proc/cmdline", "root", rootparam, 
sizeof(rootparam)) && rootparam[0] == '/') {
rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
block_dir_name, rootdev);
} else {
-   /* no 'root=' kernel cmdline parameter, find on any block 
device */
+   /* no useful 'root=' kernel cmdline parameter, find on any 
block device */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
block_dir_name);
}
 
-- 
2.39.0


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

Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

[Brian Norris]

On Fri, Jan 6, 2023 at 12:39 AM Thibaut  wrote:
> > Le 6 janv. 2023 à 04:48, Brian Norris  a écrit 
> > :

> Indeed. Coreutils seems like a better choice here.

OK. So I guess I just copy/paste it back into the openwrt tree from
the packages feed, and then later clean it out of packages.git?

> As an aside (and documentation for similar cases with devices that have 
> smaller storage), note that if you don’t want to store the extracted firmware 
> to permanent storage, caldata_sysfsload_from_file() offers an alternative to 
> this.

Thanks. I was trying to grok why there were at least two variants in
caldata.sh; I liked (and imitated) the caldata_sysfsload_from_file()
approach better.

> > [1] Although the default partitioning sets
> > CONFIG_TARGET_ROOTFS_PARTSIZE=200, which limits the default build
> > unnecessarily to ~128MiB. I still need to figure out the best way to
> > fix that:
>
> You can probably adjust this on your target-specific config,

I suppose, although that's still in the same problem space of "how to
set a CONFIG_* default from a target" -- that also can't be done in
DEVICE_PACKAGES. (And again, I'm a little new at this, so bear with
me.)

I could also just hardcode something better I guess. I see others do this:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq40xx/image/generic.mk;h=f92e11c797127344c6e14d6292956eeca8f048eb;hb=d3e89e69c52115d1c02f5c16a4aa6b721e003578#l103
(Build/qsdk-ipq-app-gpt)

> but the reason for keeping it small is to keep sysupgrade times reasonable, 
> IIRC.

Ah, makes sense.

BTW, speaking of sysupgrade (and maybe this deserves a change of
Subject if this discussion goes very far): I've found that the emmc.sh
upgrade helpers still don't seem very reliable when the rootfs size
changes (and so the "f2fs loop-mounted rootfs_data appended to the
rootfs" has to move). sysupgrade can be a bit hard to debug, since you
lose access to many normal services along the way, so I'm not 100%
sure, but it seems like the two filesystems (rootfs and data/overlay)
collide, and that a separate rootfs_data partition (such as the one in
the glinet_gl-b2200 target above) would work better. Am I missing
something here? It seems that sysupgrade is very ad-hoc in openwrt,
and that eMMC/block support is still somewhat underdeveloped, so maybe
there aren't really any conventions here, and one just does whatever
works for them? I'm thinking of just adding the rootfs_data partition
to suck up the remaining GBs of disk (and maybe adding to the Google
Wifi target too), but I'm still not sure of the Best solution.

As a bonus, with a rootfs_data partition, the sysupgrade could
potentially be a lot simpler (and does not need to scale with the size
of the rootfs_data contents), because the filesystem could mostly just
stay in-place.

Brian

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

Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

[Brian Norris]

On Thu, Jan 5, 2023 at 7:12 PM Stefan Lippers-Hollmann  wrote:
> On 2023-01-06, Christian Marangi wrote:
> > On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote:
> > > On Thu, Jan 5, 2023 at 11:59 AM Brian Norris
> [...]
> > > Do I need to create some intermediate/stub package just to express the
> > > dependency, or is there some better way?
> > >
> >
> > In theory there is [1] coreutils-base64 as a separate package but I
> > think we have to move that to core packages as it's part of the feeds
> > package.

coreutils definitely works. (busybox would too, except I just can't
get the dependency mechanics right.)

> There would be another alternative for base64 functionality, openssl...
> While not the lightest package, it's already available in main and
> with DEVICE_PACKAGES a relatively low-maintenance alternative.
>
> openssl enc -base64 -in foo -out foo.base64
> openssl enc -d -base64 -in foo.base64 -out foo

I have to throw "-A" in there apparently, since openssl is apparently
too strict on (lack of) line wrapping in the data source, but that
works too.

> With root/ overlay on eMMC, this shouldn't be too heavy for this
> kind of hardware.

Yeah, should be no big deal on space. These devices have ~4GB storage
[1]. Does anybody care on non-disk-space grounds? Like "lack of
choice"? (I guess one can install multiple SSL libraries.)

So what do you all think? Pick my favorite? I suppose I kinda like the
'base64' (either coreutils or busybox) option, since it's a bit of a
simpler tool, and has multiple options (in case somebody is trying to
slim things for some reason). But openssl is easiest from a friction
point of view, since it's just a DEVICE_PACKAGES dependency away,
instead of porting over something from feeds.

Brian

[1] Although the default partitioning sets
CONFIG_TARGET_ROOTFS_PARTSIZE=200, which limits the default build
unnecessarily to ~128MiB. I still need to figure out the best way to
fix that:
https://openwrt.org/toh/google/wifi#expanding_storage_optional

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

Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

[Brian Norris]

In case you are open to giving more helpful tips to a relative
newcomer to openwrt development:

On Thu, Jan 5, 2023 at 11:59 AM Brian Norris
 wrote:
> I'll just need to
> force a 'base64' utility into these images

This is turning out to be nontrivial. The only in-tree base64 tool is
a busybox tool, and it's not enabled in the default busybox
configuration. I don't see an easy way for a target to change this
default. I *do* see package dependencies that do this (like
DEPENDS:=+@BUSYBOX_CONFIG_), but I don't think that works in
a target (e.g., adding to DEVICE_PACKAGES).

Do I need to create some intermediate/stub package just to express the
dependency, or is there some better way?

Brian

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

Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

[Brian Norris]

On Thu, Jan 5, 2023 at 11:02 AM Robert Marko  wrote:
> On Thu, 5 Jan 2023 at 19:47, Brian Norris  wrote:
> > On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote:
> > > Also on top of that the besto solution for these special case is to
> > > parse the base64 data in userspace a produce a calibration bin to pass
> > > with sysfs. A patch and some code to decode base64 seems overkill to me.
> >
> > I'd love something that's more pleasant than in-kernel base64. Is there
> > some sysfs method for this that I'm not aware of? The closest I find is:
> >
> > /sys/kernel/debug/ieee80211/*/ath10k/cal_data
> >
> > But that's read-only, not read-write. And it's not completely obvious to
> > me that this data can be (re)written to the target radio arbitrarily, so
> > I suppose the API would be a bit fiddly -- that one has to know to write
> > this file before ever bringing up the interface (but after loading the
> > driver/module).
> >
> > Without a user space API, this is the best I came up with.
>
> You can extract and provide the caldata from userspace by acting on the 
> hotplug
> event that kernel files after request_firmware() fails, look at what
> Fritzbox devices are doing in:
> https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata

Awesome, I had an inkling that other devices would probably have some
similar problems, but I didn't find exactly how they're handling it.

And wow, I didn't realize there was a uevent/sysfs method for filling
in the gaps on missing /lib/firmware files. TIL.

> Basically, you trigger on the requested file and device and then you
> can just use a userspace
> script or binary to actually provide that file.

Yep, this totally looks like it'll work for me. I'll just need to
force a 'base64' utility into these images, but otherwise, looks
pretty easy.

> That would probably work best here as I dont know if upstream will
> accept adding a base64
> method just for one or 2 devices.

Yeah, I figured this is arcane enough (and not really a typical job
for DT bindings) that we'd need to patch up something ourselves. I'm
glad to not have to approach the "convince upstream" question on this
ugly patch, and even more glad to find a way do this without modifying
the kernel/driver.

Thanks a lot,
Brian

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

Re: [PATCH 5/8] ipq8064: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling

[Brian Norris]

Hi Christian, Robert,

On Wed, Jan 04, 2023 at 02:30:23PM +0100, Robert Marko wrote:
> On Wed, 4 Jan 2023 at 14:04, Christian Marangi  wrote:
> >
> > On Mon, Jan 02, 2023 at 03:25:31PM -0800, Brian Norris wrote:
> > > This fixes device tree registration for 'qcom,lpass-cpu' as used by
> > > qcom-ipq8064 SoCs, and allows speaker audio to function.
> > >
> > > This patch has been submitted (and merged, for -next) upstream.
> >
> > Considering it's tagged for stable and assuming it will be part of 6.2
> > wonder if it's a good idea to add the kernel tag to better track this?

I first wrote this when I had just posted the patch; didn't expect it to
land so quickly!

But what do you mean: just tweak the commit title to 'kernel: ...'? Or
move this to the generic kernel patches
(target/linux/generic/backport-5.15/)?

> Also, the 900 prefix isn't really meant for backports.

Ack. I only just noticed target/linux/generic/PATCHES. So I guess that's
one of these?

  0xx - upstream backports
  1xx - code awaiting upstream merge

Thanks,
Brian

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

Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

[Brian Norris]

Hi Christian,

On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote:
> On Mon, Jan 02, 2023 at 03:25:33PM -0800, Brian Norris wrote:
> > See the patch notes about the stock firmware for TP-Link Onhub and
> > https://chromium-review.googlesource.com/243115.
> > 
> > As noted there, the production firmware for Google OnHub devices only
> > provide the *-base64 Device Tree property, and so either the kernel or
> > some user space mechanism needs to know how to parse/convert this
> > property.
...
>
> Aside from this, I notice this is actually NOT used in the 2 device you
> are proposing. I'm totally missing something or this is not needed at
> all?

It's provided by the production firmware, which patches it into the
device tree on its own. So you're not going to find it in the kernel or
DTS sources.

If you want to look at its source though, it's here:
https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/firmware-storm-6315.B/src/board/storm/wifi_calibration.c

And unfortunately, systems I'm looking at were only programmed with the
base64 VPD:

# ls -1 /sys/firmware/vpd/ro/wifi*
/sys/firmware/vpd/ro/wifi_base64_calibration0
/sys/firmware/vpd/ro/wifi_base64_calibration1
/sys/firmware/vpd/ro/wifi_base64_calibration2

> Also on top of that the besto solution for these special case is to
> parse the base64 data in userspace a produce a calibration bin to pass
> with sysfs. A patch and some code to decode base64 seems overkill to me.

I'd love something that's more pleasant than in-kernel base64. Is there
some sysfs method for this that I'm not aware of? The closest I find is:

/sys/kernel/debug/ieee80211/*/ath10k/cal_data

But that's read-only, not read-write. And it's not completely obvious to
me that this data can be (re)written to the target radio arbitrarily, so
I suppose the API would be a bit fiddly -- that one has to know to write
this file before ever bringing up the interface (but after loading the
driver/module).

Without a user space API, this is the best I came up with.

Brian

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

Re: [PATCH 2/8] ipq806x: Point to externally compiled dtbs in recipes

[Brian Norris]

On Wed, Jan 04, 2023 at 01:50:17PM +0100, Christian Marangi wrote:
> On Mon, Jan 02, 2023 at 03:25:28PM -0800, Brian Norris wrote:
> > See also:
> > 
> > commit 4d8b42d8a7774070ac0439915f8de1430db9a8e3
> > Author: Tomasz Maciej Nowak 
> > Date:   Thu Aug 25 20:26:11 2022 +0200
> > 
> > ipq40xx: point to externally compiled dtbs in recipes
> > 
> > Adjusting dts will cause a rebuild of whole kernel as the buildroot
> > considers this a part of kernel source. It's a royal PITA when trying to
> > prepare support for new device, since this takes a lot of time on slower
> > systems. As it stands, buildroot itself, with own rule, also compiles
> > dtbs and the results are $(KDIR)/image-$(DEVICE_DTS).dtb. With setting
> > DEVICE_DTS_DIR to directory holding the device dts (similarly to some
> > other targets), buildroot doesn't consider changed dts as part of kernel
> > source and rebuilds only dtb. This really speeds up development. And
> > since the kernel built dts are no longer used, drop the paches adding
> > dtses to its build.
> > 
> > In a similar fashion, we can drop the DTS patch.
> 
> Can we improve the commit description without appending the commit
> description of another commit? Seems wrong to me.

Sure. I suppose I can liberally borrow (and reference) the description
instead of quoting.

> If you already found a similar commit description feel free to link as I
> could be totally wrong about this.

Eh, my quick search didn't really find any. The closest was something
like this:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=0dc58214896aacf67a3759495d70e2b4e9c160d8
where at least some of the larger metadata (author, commiter, dates)
were pasted.

Brian

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

Re: [PATCH 1/8] base-files: Remove nand.sh dependency from emmc upgrade

[Brian Norris]

Hi Christian,

On Wed, Jan 04, 2023 at 01:40:57PM +0100, Christian Marangi wrote:
> On Mon, Jan 02, 2023 at 03:25:27PM -0800, Brian Norris wrote:
> > --- a/package/base-files/files/lib/upgrade/common.sh
> > +++ b/package/base-files/files/lib/upgrade/common.sh
> > @@ -127,6 +127,33 @@ get_magic_fat32() {
> > (get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
> >  }
> >  
> > +identify_magic_long() {
...

> > diff --git a/package/base-files/files/lib/upgrade/nand.sh 
> > b/package/base-files/files/lib/upgrade/nand.sh
> > index a8e3cab0b8b1..a1dbd6e2663d 100644
> > --- a/package/base-files/files/lib/upgrade/nand.sh
> > +++ b/package/base-files/files/lib/upgrade/nand.sh
> > @@ -65,40 +65,12 @@ get_magic_long_tar() {

> >  identify() {
> > -   identify_magic $(nand_get_magic_long "$@")
> > +   identify_magic_long $(nand_get_magic_long "$@")
> 
> Should we really change the name from identify_magic to
> identify_magic_long?

I was trying to match the conventions of common.sh, where I moved the
helper to. common.sh has get_magic_word() and get_magic_long() (and
other suffixed helpers for specific purposes), and it's important the
caller uses the correct ones. While this identify function could
partially work (it can identify "combined" and "gzip") with just a
'word' of data, it would be misleading.

Is there a reason *not* to change the name?

Thanks,
Brian

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

[PATCH 8/8] ipq806x: Initial TP-Link and ASUS OnHub support

[Brian Norris]

TP-Link and ASUS OnHub devices are very similar, sharing many of the
same characteristics and much of their Device Tree. They both run a
version of ChromeOS for their factory firmware, and so installation
instructions look very similar to Google Wifi [1].

Things that work:

 * Ethernet
 * WiFi (2.4 and 5 GHz)
 * LEDs
 * USB
 * eMMC
 * Serial console (if you wire it up yourself)
 * 1 CPU
 * Speaker; I think I've worked out the kinks (with the parent patches,
   and tweaking pin configuration a bit)

Things that don't work:

 * The second CPU; bringing up the second CPU seems to hang right now,
   so I disable it with "maxcpus=1".

== Installation instructions summary ==

1. Flash *-factory.bin to a USB drive (e.g., with `dd`)
2. Enter Developer Mode
3. Insert USB drive, to boot OpenWrt from USB
4. Copy the same *-factory.bin over to device, and flash it to eMMC to
   make OpenWrt permanent

== Developer mode (Step 2) ==

To enter Developer Mode [2], follow these steps:

1. Unplug power
2. Gain access to the "developer switch" through the bottom of the
   device
3. Plug a USB keyboard into the device's USB port
4. Hold down the "reset switch" (near the USB port / power plug)
5. Plug power back in
6. The LED on the device should turn white, then blink orange, then
   red. Release the reset switch.
7. Press CTRL+D on the keyboard. The LED should now start blinking
   purple.
8. Press and release the hidden "developer switch" under the device.
9. The device should reboot, and start blinking purple again. You have
   successfully entered developer mode.
10. Unplug power

These instructions are derived from:

https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub
https://www.exploitee.rs/index.php/Asus_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub

~~Finding the developer switch:~~ for TP-Link, the developer switch is
on the bottom of the device, underneath some of the rubber padding and a
screw. For ASUS, remove the entire base, via 4 screws under the rubber
feet. See the Exploitee instructions for more info and photos.

== Booting from USB (Step 3) ==

After entering developer mode:

1. Unplug power
2. Insert USB drive with OpenWrt factory.bin
3. Plug power; after a few seconds, the device should start blinking
   purple
4. Press the hidden developer switch under the device to boot to USB;
   you should see some activity lights (if you have any) on your USB
   drive
5. Depending on your configuration, the router's LED(s) should come on.
   You're now running OpenWrt off a USB stick.

== Making OpenWrt permanent (on eMMC) (Step 4) ==

Once you're running OpenWrt via USB:

1. Connect Ethernet to the LAN port; router's LAN address should be at
   192.168.1.1
2. Connect another system to the router's LAN, and copy the factory.bin
   image over, via SCP and SSH:

 scp -O openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin 
root@192.168.1.1:
 ssh root@192.168.1.1 -C "dd if=/dev/zero bs=512 seek=7552991 
of=/dev/mmcblk0 count=33 && \
 dd if=/root/openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin 
of=/dev/mmcblk0"
3. Reboot and remove the USB drive.

== Developer mode beep ==

Note that every time you boot the OnHub in developer mode, the device
will play a loud "beep" after a few seconds. This is described in the
Chromium docs [2], and is intended to make it clear that the device is
not running Google software. It is nontrivial to completely disable this
beep, although it's possible to "acknowledge" developer mode (and skip
the beep) by using a USB keyboard to press CTRL+D every time you boot.

[1] https://openwrt.org/toh/google/wifi
[2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md

Signed-off-by: Brian Norris 
---
 * We could perhaps factor out some of the cros-vboot stuff that's
   shared with google,wifi into a common location?
 * There might be better ways to handle the multi-color LED support,
   but for now, each color is a separate LED
 * A variety of people have been interested in this work, and a few have
   tested versions of it already:
 https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899

 target/linux/ipq806x/Makefile |   4 +-
 .../ipq806x/base-files/etc/board.d/01_leds|  11 +
 .../ipq806x/base-files/etc/board.d/02_network |   6 +
 .../base-files/lib/upgrade/platform.sh|  18 +
 target/linux/ipq806x/chromium/config-default  |  13 +
 target/linux/ipq806x/chromium/target.mk   |   2 +
 .../arm/boot/dts/qcom-ipq8064-asus-onhub.dts  |  95 
 .../arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi | 466 ++
 .../boot/dts/qcom-ipq8064-tplink-onhub.dts| 207 
 target/linux/ipq806x/generic/target.mk|   1 +
 target/linux/ipq806x/image/Makefile   |   1 +
 target/linux/ipq806x/image/chromium.mk|  55 +++
 12 files changed, 877 insertio

[PATCH 4/8] ipq806x: Enable CONFIG_IPQ_LCC_806X

[Brian Norris]

Clock controller used by some IP blocks (e.g., LPASS / audio) on
IPQ8064.

Signed-off-by: Brian Norris 
---

 target/linux/ipq806x/config-5.15 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ipq806x/config-5.15 b/target/linux/ipq806x/config-5.15
index 5082bc840be3..31bb729c85e9 100644
--- a/target/linux/ipq806x/config-5.15
+++ b/target/linux/ipq806x/config-5.15
@@ -207,7 +207,7 @@ CONFIG_IOMMU_SUPPORT=y
 # CONFIG_IPQ_GCC_6018 is not set
 CONFIG_IPQ_GCC_806X=y
 # CONFIG_IPQ_GCC_8074 is not set
-# CONFIG_IPQ_LCC_806X is not set
+CONFIG_IPQ_LCC_806X=y
 CONFIG_IRQCHIP=y
 CONFIG_IRQ_DOMAIN=y
 CONFIG_IRQ_DOMAIN_HIERARCHY=y
-- 
2.39.0


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

[PATCH 2/8] ipq806x: Point to externally compiled dtbs in recipes

[Brian Norris]

See also:

commit 4d8b42d8a7774070ac0439915f8de1430db9a8e3
Author: Tomasz Maciej Nowak 
Date:   Thu Aug 25 20:26:11 2022 +0200

ipq40xx: point to externally compiled dtbs in recipes

Adjusting dts will cause a rebuild of whole kernel as the buildroot
considers this a part of kernel source. It's a royal PITA when trying to
prepare support for new device, since this takes a lot of time on slower
systems. As it stands, buildroot itself, with own rule, also compiles
dtbs and the results are $(KDIR)/image-$(DEVICE_DTS).dtb. With setting
DEVICE_DTS_DIR to directory holding the device dts (similarly to some
other targets), buildroot doesn't consider changed dts as part of kernel
source and rebuilds only dtb. This really speeds up development. And
since the kernel built dts are no longer used, drop the paches adding
dtses to its build.

In a similar fashion, we can drop the DTS patch.

Signed-off-by: Brian Norris 
---

 target/linux/ipq806x/image/Makefile   |  5 +--
 .../0069-arm-boot-add-dts-files.patch | 43 ---
 .../0069-arm-boot-add-dts-files.patch | 43 ---
 3 files changed, 2 insertions(+), 89 deletions(-)
 delete mode 100644 
target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
 delete mode 100644 
target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch

diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile
index f4f829b35c65..8c1fc88010cd 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -5,7 +5,6 @@ include $(INCLUDE_DIR)/image.mk
 
 define Device/Default
PROFILES := Default
-   KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts)
KERNEL_LOADADDR = 0x42208000
DEVICE_DTS = $$(SOC)-$(lastword $(subst _, ,$(1)))
DEVICE_DTS_CONFIG := config@1
@@ -22,13 +21,13 @@ endef
 
 define Device/FitImage
KERNEL_SUFFIX := -fit-uImage.itb
-   KERNEL = kernel-bin | gzip | fit gzip $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+   KERNEL = kernel-bin | gzip | fit gzip $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
 endef
 
 define Device/FitImageLzma
KERNEL_SUFFIX := -fit-uImage.itb
-   KERNEL = kernel-bin | lzma | fit lzma $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+   KERNEL = kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
 endef
 
diff --git 
a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch 
b/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 4c42f40e3d78..
--- a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin 

- arch/arm/boot/dts/Makefile | 8 
- 1 file changed, 8 insertions(+)
-
 a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -909,8 +909,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom-ipq4019-ap.dk04.1-c3.dtb \
-   qcom-ipq4019-ap.dk07.1-c1.dtb \
-   qcom-ipq4019-ap.dk07.1-c2.dtb \
-+  qcom-ipq8062-wg2600hp3.dtb \
-   qcom-ipq8064-ap148.dtb \
-   qcom-ipq8064-rb3011.dtb \
-+  qcom-ipq8064-c2600.dtb \
-+  qcom-ipq8064-d7800.dtb \
-+  qcom-ipq8064-db149.dtb \
-+  qcom-ipq8064-ap161.dtb \
-+  qcom-ipq8064-ea7500-v1.dtb \
-+  qcom-ipq8064-ea8500.dtb \
-+  qcom-ipq8064-g10.dtb \
-+  qcom-ipq8064-r7500.dtb \
-+  qcom-ipq8064-r7500v2.dtb \
-+  qcom-ipq8064-unifi-ac-hd.dtb \
-+  qcom-ipq8064-wg2600hp.dtb \
-+  qcom-ipq8064-wpq864.dtb \
-+  qcom-ipq8064-wxr-2533dhp.dtb \
-+  qcom-ipq8065-nbg6817.dtb \
-+  qcom-ipq8065-r7800.dtb \
-+  qcom-ipq8065-rt4230w-rev6.dtb \
-+  qcom-ipq8065-tr4400-v2.dtb \
-+  qcom-ipq8065-xr500.dtb \
-+  qcom-ipq8068-ecw5410.dtb \
-+  qcom-ipq8068-mr42.dtb \
-+  qcom-ipq8068-mr52.dtb \
-   qcom-msm8660-surf.dtb \
-   qcom-msm8960-cdp.dtb \
-   qcom-msm8974-fairphone-fp2.dtb \
diff --git 
a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch 
b/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 698df248fb57..
--- a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin 

- arch/arm/boot/dts/Makefile | 8 
- 1 file changed, 8 insertions(+)
-
 a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -957,8 +957,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
-   qcom

[PATCH 1/8] base-files: Remove nand.sh dependency from emmc upgrade

[Brian Norris]

emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.

Signed-off-by: Brian Norris 
---

 .../base-files/files/lib/upgrade/common.sh| 27 
 package/base-files/files/lib/upgrade/emmc.sh  |  2 +-
 package/base-files/files/lib/upgrade/nand.sh  | 32 ++-
 3 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 5af061f6a439..53b8865a5788 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -127,6 +127,33 @@ get_magic_fat32() {
(get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
 }
 
+identify_magic_long() {
+   local magic=$1
+   case "$magic" in
+   "55424923")
+   echo "ubi"
+   ;;
+   "31181006")
+   echo "ubifs"
+   ;;
+   "68737173")
+   echo "squashfs"
+   ;;
+   "d00dfeed")
+   echo "fit"
+   ;;
+   "4349"*)
+   echo "combined"
+   ;;
+   "1f8b"*)
+   echo "gzip"
+   ;;
+   *)
+   echo "unknown $magic"
+   ;;
+   esac
+}
+
 part_magic_efi() {
local magic=$(get_magic_gpt "$@")
[ "$magic" = "EFI PART" ]
diff --git a/package/base-files/files/lib/upgrade/emmc.sh 
b/package/base-files/files/lib/upgrade/emmc.sh
index c3b02864aa91..49cffe1c658b 100644
--- a/package/base-files/files/lib/upgrade/emmc.sh
+++ b/package/base-files/files/lib/upgrade/emmc.sh
@@ -58,7 +58,7 @@ emmc_copy_config() {
 }
 
 emmc_do_upgrade() {
-   local file_type=$(identify $1)
+   local file_type=$(identify_magic_long "$(get_magic_long "$1")")
 
case "$file_type" in
"fit")  emmc_upgrade_fit $1;;
diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index a8e3cab0b8b1..a1dbd6e2663d 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -65,40 +65,12 @@ get_magic_long_tar() {
(tar xO${3}f "$1" "$2" | dd bs=4 count=1 | hexdump -v -n 4 -e '1/1 
"%02x"') 2> /dev/null
 }
 
-identify_magic() {
-   local magic=$1
-   case "$magic" in
-   "55424923")
-   echo "ubi"
-   ;;
-   "31181006")
-   echo "ubifs"
-   ;;
-   "68737173")
-   echo "squashfs"
-   ;;
-   "d00dfeed")
-   echo "fit"
-   ;;
-   "4349"*)
-   echo "combined"
-   ;;
-   "1f8b"*)
-   echo "gzip"
-   ;;
-   *)
-   echo "unknown $magic"
-   ;;
-   esac
-}
-
-
 identify() {
-   identify_magic $(nand_get_magic_long "$@")
+   identify_magic_long $(nand_get_magic_long "$@")
 }
 
 identify_tar() {
-   identify_magic $(get_magic_long_tar "$@")
+   identify_magic_long $(get_magic_long_tar "$@")
 }
 
 identify_if_gzip() {
-- 
2.39.0


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

[PATCH 6/8] kernel: Add kmod-sound-soc-ipq8064-storm

[Brian Norris]

For IPQ8064 systems based off the "Google Storm" reference platform,
such as the TP-Link OnHub.

Signed-off-by: Brian Norris 
---

 package/kernel/linux/modules/sound.mk | 24 
 target/linux/generic/config-5.10  |  3 +++
 target/linux/generic/config-5.15  |  3 +++
 3 files changed, 30 insertions(+)

diff --git a/package/kernel/linux/modules/sound.mk 
b/package/kernel/linux/modules/sound.mk
index 2bfa146207aa..92ad8bceed9b 100644
--- a/package/kernel/linux/modules/sound.mk
+++ b/package/kernel/linux/modules/sound.mk
@@ -254,6 +254,30 @@ endef
 $(eval $(call KernelPackage,sound-soc-imx-sgtl5000))
 
 
+define KernelPackage/sound-soc-ipq8064-storm
+  TITLE:=Qualcomm IPQ8064 SoC support for Google Storm
+  KCONFIG:=\
+   CONFIG_SND_SOC_QCOM \
+   CONFIG_SND_SOC_STORM
+  FILES:=\
+   $(LINUX_DIR)/sound/soc/codecs/snd-soc-max98357a.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-cpu.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-ipq806x.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-platform.ko \
+   $(LINUX_DIR)/sound/soc/qcom/snd-soc-storm.ko
+  AUTOLOAD:=$(call AutoLoad,57,snd-soc-max98357a snd-soc-lpass-cpu \
+   snd-soc-lpass-ipq806x snd-soc-lpass-platform snd-soc-storm)
+  DEPENDS:=@TARGET_ipq806x +kmod-sound-soc-core
+  $(call AddDepends/sound)
+endef
+
+define KernelPackage/sound-soc-ipq8064-storm/description
+ Support for Qualcomm IPQ8064 / Google Storm Platform sound
+endef
+
+$(eval $(call KernelPackage,sound-soc-ipq8064-storm))
+
+
 define KernelPackage/sound-soc-spdif
   TITLE:=SoC S/PDIF codec support
   KCONFIG:=CONFIG_SND_SOC_SPDIF
diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10
index a2dc9b90b1fc..324401244155 100644
--- a/target/linux/generic/config-5.10
+++ b/target/linux/generic/config-5.10
@@ -5649,6 +5649,7 @@ CONFIG_SND_PROC_FS=y
 # CONFIG_SND_SOC_AMD_ACP is not set
 # CONFIG_SND_SOC_AMD_ACP3x is not set
 # CONFIG_SND_SOC_AMD_RENOIR is not set
+# CONFIG_SND_SOC_APQ8016_SBC is not set
 # CONFIG_SND_SOC_AU1XAUDIO is not set
 # CONFIG_SND_SOC_AU1XPSC is not set
 # CONFIG_SND_SOC_BD28623 is not set
@@ -5786,6 +5787,7 @@ CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y
 # CONFIG_SND_SOC_RT5616 is not set
 # CONFIG_SND_SOC_RT5631 is not set
 # CONFIG_SND_SOC_RT5677_SPI is not set
+# CONFIG_SND_SOC_SC7180 is not set
 # CONFIG_SND_SOC_SGTL5000 is not set
 # CONFIG_SND_SOC_SIMPLE_AMPLIFIER is not set
 # CONFIG_SND_SOC_SIRF_AUDIO_CODEC is not set
@@ -5795,6 +5797,7 @@ CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y
 # CONFIG_SND_SOC_SSM2602_I2C is not set
 # CONFIG_SND_SOC_SSM2602_SPI is not set
 # CONFIG_SND_SOC_SSM4567 is not set
+# CONFIG_SND_SOC_STORM is not set
 # CONFIG_SND_SOC_STA32X is not set
 # CONFIG_SND_SOC_STA350 is not set
 # CONFIG_SND_SOC_STI_SAS is not set
diff --git a/target/linux/generic/config-5.15 b/target/linux/generic/config-5.15
index df9755b19e68..5ccc1dc41594 100644
--- a/target/linux/generic/config-5.15
+++ b/target/linux/generic/config-5.15
@@ -5940,6 +5940,7 @@ CONFIG_SND_PROC_FS=y
 # CONFIG_SND_SOC_AMD_ACP3x is not set
 # CONFIG_SND_SOC_AMD_ACP5x is not set
 # CONFIG_SND_SOC_AMD_RENOIR is not set
+# CONFIG_SND_SOC_APQ8016_SBC is not set
 # CONFIG_SND_SOC_AU1XAUDIO is not set
 # CONFIG_SND_SOC_AU1XPSC is not set
 # CONFIG_SND_SOC_BD28623 is not set
@@ -6097,6 +6098,7 @@ CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y
 # CONFIG_SND_SOC_RT5640 is not set
 # CONFIG_SND_SOC_RT5659 is not set
 # CONFIG_SND_SOC_RT5677_SPI is not set
+# CONFIG_SND_SOC_SC7180 is not set
 # CONFIG_SND_SOC_SGTL5000 is not set
 # CONFIG_SND_SOC_SIMPLE_AMPLIFIER is not set
 # CONFIG_SND_SOC_SIMPLE_MUX is not set
@@ -6111,6 +6113,7 @@ CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y
 # CONFIG_SND_SOC_STA32X is not set
 # CONFIG_SND_SOC_STA350 is not set
 # CONFIG_SND_SOC_STI_SAS is not set
+# CONFIG_SND_SOC_STORM is not set
 # CONFIG_SND_SOC_TAS2552 is not set
 # CONFIG_SND_SOC_TAS2562 is not set
 # CONFIG_SND_SOC_TAS2764 is not set
-- 
2.39.0


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

[PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

[Brian Norris]

See the patch notes about the stock firmware for TP-Link Onhub and
https://chromium-review.googlesource.com/243115.

As noted there, the production firmware for Google OnHub devices only
provide the *-base64 Device Tree property, and so either the kernel or
some user space mechanism needs to know how to parse/convert this
property.

I haven't submitted this patch upstream. However, it applies relatively
cleanly to the tree even after almost 8 years, so it doesn't seem too
hard to maintain.

Signed-off-by: Brian Norris 
---

 .../970-ath10k-calibration-base64.patch   | 249 ++
 1 file changed, 249 insertions(+)
 create mode 100644 
package/kernel/ath10k-ct/patches/970-ath10k-calibration-base64.patch

diff --git 
a/package/kernel/ath10k-ct/patches/970-ath10k-calibration-base64.patch 
b/package/kernel/ath10k-ct/patches/970-ath10k-calibration-base64.patch
new file mode 100644
index ..739bdee9ccf4
--- /dev/null
+++ b/package/kernel/ath10k-ct/patches/970-ath10k-calibration-base64.patch
@@ -0,0 +1,249 @@
+Adapted from:
+https://chromium-review.googlesource.com/307062
+
+This "hack" remained in the production kernel, and so the production firmware
+for Google OnHub still only knows how to patch the *-base64 Device Tree
+property.
+
+CHROMIUM: HACK: ath10k: read calibration data in base64 format from DT
+
+ Chrome OS firmware doesn't support binary format in VPD currently.
+ As a workaround, the firmware stores the calibration data in base64
+ format in the same node with the different name:
+
+   qcom,ath10k-calibration-data-base64 = [ 01 02 03 ... ];
+
+   Since the original property "qcom,ath10k-calibration-data" is always
+   looked for first, it should have an invalid size (e.g. 1).
+
+   BUG=chrome-os-partner:35262
+   TEST=build/boot on storm suceeded. Setup Storm board as AP using
+   hostapd and
+   connected to the board using another device. Device was able to
+   connect to
+   the internet and load multiple websites.
+
+   Change-Id: I95675a803fad3b94977ecd0977bd9980779ad7e9
+   Signed-off-by: Toshi Kikuchi 
+   Reviewed-on: https://chromium-review.googlesource.com/243115
+   Reviewed-by: Grant Grundler 
+
+Change-Id: I17874f0ed03e28d279b08fe70aca70af57c90bda
+Signed-off-by: Anilkumar Kolli 
+Reviewed-on: https://chromium-review.googlesource.com/307062
+Commit-Ready: Grant Grundler 
+Tested-by: Grant Grundler 
+Reviewed-by: Srinivasa duvvuri 
+Reviewed-by: Grant Grundler 
+--- a/ath10k-5.15/Makefile
 b/ath10k-5.15/Makefile
+@@ -4,6 +4,7 @@ ath10k_core-y += mac.o \
+debug.o \
+core.o \
+coredump.o \
++   decode64.o \
+htc.o \
+htt.o \
+htt_rx.o \
+--- a/ath10k-5.15/core.c
 b/ath10k-5.15/core.c
+@@ -18,6 +18,7 @@
+ #include 
+ 
+ #include "core.h"
++#include "decode64.h"
+ #include "mac.h"
+ #include "htc.h"
+ #include "hif.h"
+@@ -2167,6 +2168,73 @@ static int ath10k_download_cal_file(stru
+   return 0;
+ }
+ 
++static int ath10k_download_cal_dt_base64(struct ath10k *ar)
++{
++  struct device_node *node;
++  int data_len;
++  void *data;
++  int ret;
++
++  node = ar->dev->of_node;
++  if (!node)
++  /* Device Tree is optional, don't print any warnings if
++   * there's no node for ath10k.
++   */
++  return -ENOENT;
++
++  if (!of_get_property(node, "qcom,ath10k-calibration-data-base64",
++   _len)) {
++  /* The calibration data node is optional */
++  return -ENOENT;
++  }
++
++  data = kmalloc(data_len, GFP_KERNEL);
++  if (!data) {
++  ret = -ENOMEM;
++  goto out;
++  }
++
++  ret = of_property_read_u8_array(node,
++  "qcom,ath10k-calibration-data-base64",
++  data, data_len);
++  if (ret) {
++  ath10k_warn(ar,
++  "failed to read calibration data (base64) from DT: %d\n",
++  ret);
++  goto out_free;
++  }
++
++  data_len = strip_nl(data, data + data_len, data);
++  data_len = decode64(data, data + data_len, data);
++  if (data_len < 0) {
++  ath10k_warn(ar,
++  "base64 decoder found invalid input\n");
++  ret = -EINVAL;
++  goto out_free;
++  }
++
++  if (data_len != ar->hw_params.cal_data_len) {
++  ath10k_warn(ar, "invalid calibration data length in DT: %d\n",
++  data_len);
++  ret = -EMSGSIZE;
++  goto out_free;
++  }
++
++  ret = ath10k_download_board_data(ar, data, data_len);
++  if (ret) {
++  ath10k_warn(ar, "failed to download base64

[PATCH 3/8] ipq806x: config-5.15: Normalize

[Brian Norris]

Normalize = `make kernel_menuconfig`, save.

Signed-off-by: Brian Norris 
---

 target/linux/ipq806x/config-5.15 | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/target/linux/ipq806x/config-5.15 b/target/linux/ipq806x/config-5.15
index 7ea97ff89ec3..5082bc840be3 100644
--- a/target/linux/ipq806x/config-5.15
+++ b/target/linux/ipq806x/config-5.15
@@ -34,13 +34,14 @@ CONFIG_ARM_CPU_SUSPEND=y
 # CONFIG_ARM_CPU_TOPOLOGY is not set
 CONFIG_ARM_GIC=y
 CONFIG_ARM_HAS_SG_CHAIN=y
+# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set
+# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set
 CONFIG_ARM_L1_CACHE_SHIFT=6
 CONFIG_ARM_L1_CACHE_SHIFT_6=y
 CONFIG_ARM_MODULE_PLTS=y
 CONFIG_ARM_PATCH_IDIV=y
 CONFIG_ARM_PATCH_PHYS_VIRT=y
 # CONFIG_ARM_QCOM_CPUFREQ_HW is not set
-CONFIG_ARM_QCOM_CPUFREQ_KRAIT=y
 CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y
 CONFIG_ARM_QCOM_SPM_CPUIDLE=y
 # CONFIG_ARM_SMMU is not set
@@ -98,13 +99,11 @@ CONFIG_CRC16=y
 # CONFIG_CRC32_SARWATE is not set
 CONFIG_CRC32_SLICEBY8=y
 CONFIG_CRC8=y
-CONFIG_CRYPTO_BLAKE2S=y
 CONFIG_CRYPTO_DEFLATE=y
 CONFIG_CRYPTO_DEV_QCOM_RNG=y
 CONFIG_CRYPTO_DRBG=y
 CONFIG_CRYPTO_DRBG_HMAC=y
 CONFIG_CRYPTO_DRBG_MENU=y
-CONFIG_CRYPTO_GF128MUL=y
 CONFIG_CRYPTO_HASH_INFO=y
 CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_HW=y
@@ -112,7 +111,6 @@ CONFIG_CRYPTO_JITTERENTROPY=y
 CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
 CONFIG_CRYPTO_LIB_SHA256=y
 CONFIG_CRYPTO_LZO=y
-CONFIG_CRYPTO_NULL2=y
 CONFIG_CRYPTO_RNG=y
 CONFIG_CRYPTO_RNG2=y
 CONFIG_CRYPTO_SHA256=y
@@ -127,8 +125,6 @@ CONFIG_DEVFREQ_GOV_PASSIVE=y
 # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set
 # CONFIG_DEVFREQ_GOV_USERSPACE is not set
 # CONFIG_DEVFREQ_THERMAL is not set
-# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set
-# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set
 CONFIG_DMADEVICES=y
 CONFIG_DMA_ENGINE=y
 CONFIG_DMA_OF=y
@@ -143,6 +139,7 @@ CONFIG_DWMAC_IPQ806X=y
 CONFIG_DYNAMIC_DEBUG=y
 CONFIG_EDAC_ATOMIC_SCRUB=y
 CONFIG_EDAC_SUPPORT=y
+CONFIG_ETHERNET_PACKET_MANGLE=y
 CONFIG_FIXED_PHY=y
 CONFIG_FIX_EARLYCON_MEM=y
 CONFIG_FWNODE_MDIO=y
@@ -152,10 +149,12 @@ CONFIG_GENERIC_BUG=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
 CONFIG_GENERIC_CPU_AUTOPROBE=y
+CONFIG_GENERIC_CPU_VULNERABILITIES=y
 CONFIG_GENERIC_EARLY_IOREMAP=y
 CONFIG_GENERIC_GETTIMEOFDAY=y
 CONFIG_GENERIC_IDLE_POLL_SETUP=y
 CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
+CONFIG_GENERIC_IRQ_MIGRATION=y
 CONFIG_GENERIC_IRQ_MULTI_HANDLER=y
 CONFIG_GENERIC_IRQ_SHOW=y
 CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
@@ -173,6 +172,7 @@ CONFIG_GENERIC_STRNCPY_FROM_USER=y
 CONFIG_GENERIC_STRNLEN_USER=y
 CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GENERIC_VDSO_32=y
+CONFIG_GLOB=y
 CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_CDEV=y
 CONFIG_GRO_CELLS=y
@@ -185,6 +185,7 @@ CONFIG_HAS_IOPORT_MAP=y
 CONFIG_HAVE_SMP=y
 CONFIG_HIGHMEM=y
 # CONFIG_HIGHPTE is not set
+CONFIG_HOTPLUG_CPU=y
 CONFIG_HWMON=y
 CONFIG_HWSPINLOCK=y
 CONFIG_HWSPINLOCK_QCOM=y
@@ -214,12 +215,12 @@ CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y
 CONFIG_IRQ_FORCED_THREADING=y
 CONFIG_IRQ_WORK=y
 CONFIG_KMAP_LOCAL=y
+CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY=y
 CONFIG_KPSS_XCC=y
 CONFIG_KRAITCC=y
 CONFIG_KRAIT_CLOCKS=y
 CONFIG_KRAIT_L2_ACCESSORS=y
 CONFIG_LIBFDT=y
-CONFIG_LLD_VERSION=0
 CONFIG_LOCK_DEBUGGING_SUPPORT=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
 CONFIG_LZO_COMPRESS=y
@@ -299,6 +300,7 @@ CONFIG_NO_HZ_IDLE=y
 CONFIG_NR_CPUS=2
 CONFIG_NVMEM=y
 # CONFIG_NVMEM_SPMI_SDAM is not set
+CONFIG_NVMEM_SYSFS=y
 CONFIG_OF=y
 CONFIG_OF_ADDRESS=y
 CONFIG_OF_EARLY_FLATTREE=y
@@ -307,7 +309,6 @@ CONFIG_OF_GPIO=y
 CONFIG_OF_IRQ=y
 CONFIG_OF_KOBJ=y
 CONFIG_OF_MDIO=y
-CONFIG_OF_NET=y
 CONFIG_OLD_SIGACTION=y
 CONFIG_OLD_SIGSUSPEND3=y
 CONFIG_PADATA=y
@@ -397,7 +398,7 @@ CONFIG_QCOM_SCM=y
 # CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is not set
 CONFIG_QCOM_SMEM=y
 # CONFIG_QCOM_SMSM is not set
-# CONFIG_QCOM_SOCINFO is not set
+CONFIG_QCOM_SOCINFO=y
 CONFIG_QCOM_TCSR=y
 CONFIG_QCOM_TSENS=y
 CONFIG_QCOM_WDT=y
@@ -452,6 +453,7 @@ CONFIG_SMP_ON_UP=y
 # CONFIG_SM_VIDEOCC_8150 is not set
 # CONFIG_SM_VIDEOCC_8250 is not set
 CONFIG_SOCK_RX_QUEUE_MAPPING=y
+CONFIG_SOC_BUS=y
 CONFIG_SPARSE_IRQ=y
 CONFIG_SPI=y
 CONFIG_SPI_MASTER=y
-- 
2.39.0


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

[PATCH 5/8] ipq8064: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling

[Brian Norris]

This fixes device tree registration for 'qcom,lpass-cpu' as used by
qcom-ipq8064 SoCs, and allows speaker audio to function.

This patch has been submitted (and merged, for -next) upstream.

Signed-off-by: Brian Norris 
---

 ...cpu-Fix-fallback-SD-line-index-handl.patch | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100644 
target/linux/ipq806x/patches-5.15/902-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch

diff --git 
a/target/linux/ipq806x/patches-5.15/902-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
 
b/target/linux/ipq806x/patches-5.15/902-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
new file mode 100644
index ..0bdab5dc62a5
--- /dev/null
+++ 
b/target/linux/ipq806x/patches-5.15/902-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
@@ -0,0 +1,39 @@
+From: Brian Norris 
+Date: Thu, 15 Dec 2022 01:33:45 -0800
+Subject: [PATCH] ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+
+[[ Submitted upstream as:
+   
https://lore.kernel.org/all/20221231061545.2110253-1-computersforpe...@gmail.com/
 ]]
+
+These indices should reference the ID placed within the dai_driver
+array, not the indices of the array itself.
+
+This fixes commit 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD
+lines configurable"), which among others, broke IPQ8064 audio
+(sound/soc/qcom/lpass-ipq806x.c) because it uses ID 4 but we'd stop
+initializing the mi2s_playback_sd_mode and mi2s_capture_sd_mode arrays
+at ID 0.
+
+Fixes: 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD lines configurable")
+Cc: 
+Signed-off-by: Brian Norris 
+---
+ sound/soc/qcom/lpass-cpu.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/qcom/lpass-cpu.c
 b/sound/soc/qcom/lpass-cpu.c
+@@ -851,10 +851,11 @@ static void of_lpass_cpu_parse_dai_data(
+   struct lpass_data *data)
+ {
+   struct device_node *node;
+-  int ret, id;
++  int ret, i, id;
+ 
+   /* Allow all channels by default for backwards compatibility */
+-  for (id = 0; id < data->variant->num_dai; id++) {
++  for (i = 0; i < data->variant->num_dai; i++) {
++  id = data->variant->dai_driver[i].id;
+   data->mi2s_playback_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+   data->mi2s_capture_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+   }
-- 
2.39.0


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

[PATCH] base-files: Remove nand.sh dependency from emmc upgrade

[Brian Norris]

emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.

Signed-off-by: Brian Norris 
---
 .../base-files/files/lib/upgrade/common.sh| 27 
 package/base-files/files/lib/upgrade/emmc.sh  |  2 +-
 package/base-files/files/lib/upgrade/nand.sh  | 32 ++-
 3 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 5af061f6a439..53b8865a5788 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -127,6 +127,33 @@ get_magic_fat32() {
(get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
 }
 
+identify_magic_long() {
+   local magic=$1
+   case "$magic" in
+   "55424923")
+   echo "ubi"
+   ;;
+   "31181006")
+   echo "ubifs"
+   ;;
+   "68737173")
+   echo "squashfs"
+   ;;
+   "d00dfeed")
+   echo "fit"
+   ;;
+   "4349"*)
+   echo "combined"
+   ;;
+   "1f8b"*)
+   echo "gzip"
+   ;;
+   *)
+   echo "unknown $magic"
+   ;;
+   esac
+}
+
 part_magic_efi() {
local magic=$(get_magic_gpt "$@")
[ "$magic" = "EFI PART" ]
diff --git a/package/base-files/files/lib/upgrade/emmc.sh 
b/package/base-files/files/lib/upgrade/emmc.sh
index c3b02864aa91..49cffe1c658b 100644
--- a/package/base-files/files/lib/upgrade/emmc.sh
+++ b/package/base-files/files/lib/upgrade/emmc.sh
@@ -58,7 +58,7 @@ emmc_copy_config() {
 }
 
 emmc_do_upgrade() {
-   local file_type=$(identify $1)
+   local file_type=$(identify_magic_long "$(get_magic_long "$1")")
 
case "$file_type" in
"fit")  emmc_upgrade_fit $1;;
diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index 1019b9927c02..3907d868f879 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -63,40 +63,12 @@ get_magic_long_tar() {
(tar xO${3}f "$1" "$2" | dd bs=4 count=1 | hexdump -v -n 4 -e '1/1 
"%02x"') 2> /dev/null
 }
 
-identify_magic() {
-   local magic=$1
-   case "$magic" in
-   "55424923")
-   echo "ubi"
-   ;;
-   "31181006")
-   echo "ubifs"
-   ;;
-   "68737173")
-   echo "squashfs"
-   ;;
-   "d00dfeed")
-   echo "fit"
-   ;;
-   "4349"*)
-   echo "combined"
-   ;;
-   "1f8b"*)
-   echo "gzip"
-   ;;
-   *)
-   echo "unknown $magic"
-   ;;
-   esac
-}
-
-
 identify() {
-   identify_magic $(nand_get_magic_long "$@")
+   identify_magic_long $(nand_get_magic_long "$@")
 }
 
 identify_tar() {
-   identify_magic $(get_magic_long_tar "$@")
+   identify_magic_long $(get_magic_long_tar "$@")
 }
 
 identify_if_gzip() {
-- 
2.35.1


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

[PATCH] base-files: upgrade: Fix export_partdevice() quoting

[Brian Norris]

$BOOTDEV_MAJOR may be empty for many of the uevents parsed in this
function. This condition thus tends to fail benignly (we just skip to
the next device), but it can really clutter the stage2 sysupgrade
stderr, since it looks like the "=" operand doesn't have an appropriate
left-hand argument.

Signed-off-by: Brian Norris 
---
 package/base-files/files/lib/upgrade/common.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 53b8865a5788..af1182cb16a3 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -232,7 +232,7 @@ export_partdevice() {
while read line; do
export -n "$line"
done < "$uevent"
-   if [ $BOOTDEV_MAJOR = $MAJOR -a $(($BOOTDEV_MINOR + $offset)) = 
$MINOR -a -b "/dev/$DEVNAME" ]; then
+   if [ "$BOOTDEV_MAJOR" = "$MAJOR" -a $(($BOOTDEV_MINOR + 
$offset)) = "$MINOR" -a -b "/dev/$DEVNAME" ]; then
export "$var=$DEVNAME"
return 0
fi
-- 
2.35.1


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

[PATCH] ipq40xx: Convert Google Wifi to DSA, reenable

[Brian Norris]

Undo parts of these:

116feb4a1cad ipq40xx: remove non-converted network configs
db19efee9512 ipq40xx: disable boards not converted to DSA

Reintroduce the DT paths /soc/edma@c08/gmac{0,1}, because the stock
bootloader has memorized them (instead of following aliases); then plug
the MAC address back in via 05_set_iface_mac_ipq40xx.sh, since the
'local-mac-address' property is no longer in the correct node.

Cc: David Bauer 
Cc: Robert Marko 
Signed-off-by: Brian Norris 
---
 .../ipq40xx/base-files/etc/board.d/02_network |  5 +++
 .../arch/arm/boot/dts/qcom-ipq4019-wifi.dts   | 42 +++
 target/linux/ipq40xx/image/chromium.mk|  3 +-
 3 files changed, 48 insertions(+), 2 deletions(-)

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 36f1f7c24a55..0cfcac513c7a 100644
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -31,6 +31,7 @@ ipq40xx_setup_interfaces()
cilab,meshpoint-one|\
edgecore,ecw5211|\
glinet,gl-b2200|\
+   google,wifi|\
luma,wrtq-329acn|\
mikrotik,cap-ac|\
netgear,wac510|\
@@ -114,6 +115,10 @@ ipq40xx_setup_macs()
ezviz,cs-w3-wd1200g-eup)
label_mac=$(mtd_get_mac_binary "ART" 0x6)
;;
+   google,wifi)
+   wan_mac=$(get_mac_label)
+   lan_mac=$(macaddr_add "$wan_mac" 1)
+   ;;
linksys,ea6350v3|\
linksys,ea8300  |\
linksys,mr8300)
diff --git a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts 
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
index 643449f8e4c8..65f593330558 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
@@ -13,6 +13,10 @@
model = "Google WiFi (Gale)";
compatible = "google,wifi", "google,gale-v2", "qcom,ipq4019";
 
+   aliases {
+   label-mac-device = 
+   };
+
chosen {
/*
 * rootwait: in case we're booting from slow/async USB storage.
@@ -25,6 +29,26 @@
device_type = "memory";
reg = <0x8000 0x2000>; /* 512MB */
};
+
+   soc {
+   edma@c08 {
+   /*
+* Factory bootloader (depthcharge) will fail to boot
+* if this exact path (soc/edma@c08/gmac0) doesn't
+* exist.
+*/
+   gmac0: gmac0 {
+   };
+
+   /*
+* Factory bootloader (depthcharge) will fail to boot
+* if this exact path (soc/edma@c08/gmac1) doesn't
+* exist.
+*/
+   gmac1 {
+   };
+   };
+   };
 };
 
  {
@@ -325,6 +349,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
pinctrl-0 = <_pins>;
@@ -344,6 +372,20 @@
non-removable;
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   label = "lan";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/target/linux/ipq40xx/image/chromium.mk 
b/target/linux/ipq40xx/image/chromium.mk
index 7410794fb4c7..2abd2df02ae4 100644
--- a/target/linux/ipq40xx/image/chromium.mk
+++ b/target/linux/ipq40xx/image/chromium.mk
@@ -33,5 +33,4 @@ define Device/google_wifi
DEVICE_PACKAGES := partx-utils mkf2fs e2fsprogs \
   kmod-fs-ext4 kmod-fs-f2fs kmod-google-firmware
 endef
-# Missing DSA Setup
-#TARGET_DEVICES += google_wifi
+TARGET_DEVICES += google_wifi
-- 
2.35.1


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

Re: [PATCH] octeon: fix unstable eMMC on ER-8

[Brian Norris]

Hi Yu,

On Fri, Sep 02, 2022 at 05:34:21PM -0600, Yu Zhao wrote:
> On Thu, Sep 1, 2022 at 12:54 AM Brian Norris
>  wrote:
> > On Mon, Aug 01, 2022 at 01:50:36AM -0600, Yu Zhao via openwrt-devel wrote:
> > > This patch adds the DTS [8] from the stock firmware [2], and makes
> > > ER-8 use it. Interestingly, the only change in the device tree after
> > > this patch is the eMMC clock speed [9].
> >
> > This usually means it'd be a better idea to share the DTS source
> > (probably as a DTSI) and only override a single property.
> >
> > I haven't built a full octeon image yet nor grokked this target's
> > Makefile device definitions; what DTS are you replacing, anyway?
> 
> Currently the kernel uses DTS passed in from the bootloader. Please
> read the whole commit message :)

Sorry, I did miss that. So that means we don't necessarily have a good
starting point (like a per-SoC DTSI file).

> > Seems
> > very likely that you're repeating too much. At a minimum, I bet a large
> > chunk of this file can be replaced with just:
> >
> > #include "cn71xx.dtsi"
> 
> One of the reasons is that cn61xx is too different from cn71xx.

OK, I didn't do a proper diff -- in part because this DTS isn't really
in a readable form. If it's truly not related to SoCs for which we
already have DTSI files, then maybe the '#include' comments can be
ignored.

I still would recommend looking at the other comments about phandles and
DTS style.

> > > # dtc -I fs -O dts /proc/device-tree/ -o ubnt_e200.dts
> 
> The second reason is that I consider this new DTS file "auto
> generated". IOW, it's not supposed to be edited.

What about the next person who finds a problem they need to fix?

> I see no need to study the DTS as long as it works.

This sounds like you're suggesting that decompiled assembly files are
also acceptable source material to merge into OpenWrt. Sure, they might
work, but they are not the preferred form to work with in the event they
need future fixes.

Anyway, I only showed up since I like to see stuff get reviewed and
merged (and you pinged the list for merging). I suspect anybody
reviewing your work for merging would have essentially the same sorts of
comments about how to write DTS files. But I'm not an OpenWrt committer,
and you're free to continue to wait around for one to respond, and see
what they say.

Regards,
Brian

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

Re: [PATCH] octeon: fix unstable eMMC on ER-8

[Brian Norris]

Hi Yu,

On Mon, Aug 01, 2022 at 01:50:36AM -0600, Yu Zhao via openwrt-devel wrote:
> This patch adds the DTS [8] from the stock firmware [2], and makes
> ER-8 use it. Interestingly, the only change in the device tree after
> this patch is the eMMC clock speed [9].

This usually means it'd be a better idea to share the DTS source
(probably as a DTSI) and only override a single property.

I haven't built a full octeon image yet nor grokked this target's
Makefile device definitions; what DTS are you replacing, anyway? Seems
very likely that you're repeating too much. At a minimum, I bet a large
chunk of this file can be replaced with just:

#include "cn71xx.dtsi"

> # dtc -I fs -O dts /proc/device-tree/ -o ubnt_e200.dts

That's cute, but that doesn't quite produce a proper (in terms of
readability and usability) source file. Source files have things like
labels and reference/pandle syntax, instead of bare 'phandle' properties
with indexes.

A few notes to that end below, as well as other tips on how these kinds
of files are typically written. You might also consider reading through
a few other files (e.g., in the arch/mips/boot/dts/cavium-octeon
directory) to see what they look like.

> --- /dev/null
> +++ b/target/linux/octeon/files/arch/mips/boot/dts/cavium-octeon/ubnt_e200.dts
> @@ -0,0 +1,388 @@
> +/dts-v1/;
> +
> +/ {
> + compatible = "ubnt,e200";
> + interrupt-parent = <0x01>;

This (and any other interrupt-parent) should be a <> reference,
not a bare integer. e.g.:

interrupt-parent = <>;

> + model = "ubnt,e200";
> + #address-cells = <0x02>;
> + #size-cells = <0x02>;

#{address,size}-cells are almost always spelled out in decimal, not hex.

#address-cells = <2>;
#size-cells = <2>;

(Same for pretty much anything else that's not an address or length.)

> + memory {
> + reg = <0x00 0x00 0x00 0x1000 0x00 0x2000 0x00 
> 0x7000>;
> + device_type = "memory";
> + };
> +
> + soc@0 {
> + compatible = "simple-bus";
> + ranges;
> + #address-cells = <0x02>;
> + #size-cells = <0x02>;
> +
> + dma-engine@118000108 {
> + interrupts = <0x00 0x3f>;
> + compatible = "cavium,octeon-5750-bootbus-dma";
> + reg = <0x11800 0x108 0x00 0x08>;
> + };
> +
> + interrupt-controller@10700 {

If you give this a proper label like all other cavium DTs do, then you
could refer to it by name. e.g.:

/ {
...
interrupt-parent = <>;
...
ciu: interrupt-controller@10700 {

> + interrupt-controller;
> + compatible = "cavium,octeon-3860-ciu";
> + reg = <0x10700 0x00 0x00 0x7000>;
> + #interrupt-cells = <0x02>;
> + phandle = <0x01>;
> + linux,phandle = <0x01>;

Drop the 'phandle' and 'linux,phandle' properties. Any time you see
these, that means the source should *really* have a label instead, and
references to that label should be made using _label_name.

> + };

...

> + interface@1 {
> + compatible = "cavium,octeon-3860-pip-interface";
> + reg = <0x01>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> +
> + ethernet@0 {
> + compatible = 
> "cavium,octeon-3860-pip-port";
> + phy-handle = <0x09>;
> + reg = <0x00>;

When the 'reg' is just an index (like a "port" number in this case),
it probably makes more sense in decimal.

> + local-mac-address = [00 00 00 00 00 00];
> + };

...

> + mmc@118002000 {
> + interrupts = <0x01 0x13 0x00 0x3f>;
> + compatible = "cavium,octeon-6130-mmc";
> + reg = <0x11800 0x2000 0x00 0x100 0x11800 0x168 0x00 
> 0x20>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> +
> + mmc-slot@0 {
> + cavium,bus-max-width = <0x08>;
> + compatible = 
> "cavium,octeon-6130-mmc-slot\0mmc-spi-slot";

Instead of including 'nil' characters in the midst of a string, try the
common syntax:

compatible = "cavium,octeon-6130-mmc-slot", 
"mmc-spi-slot";

> + voltage-ranges = <0xce4 0xce4>;

These are much better spelled out in decimal:

voltage-ranges = <3300 3300>;

> + reg = <0x00>;
> + spi-max-frequency = <0x18cba80>;

Decimal.

> + 

Re: [PATCH firmware-utils 1/2] ptgen: add Chromium OS kernel partition support

[Brian Norris]

On Fri, Jan 28, 2022 at 12:53:04PM +, Daniel Golle wrote:
> I'll apply your patches as-is.
> 
> 
> Thank you!

Thanks for reviewing and merging!

Now to get the rest of the Google WiFi stuff [1] in good enough shape to
merge. (Maybe it is already? Although I'm unsure if there are side
effects for other ipq40xx firmwares.) And maybe even OnHub for good
measure.

Brian

[1] https://github.com/computersforpeace/openwrt/commits/gale

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

Re: [PATCH firmware-utils 1/2] ptgen: add Chromium OS kernel partition support

[Brian Norris]

On Thu, Jan 27, 2022 at 5:34 AM Daniel Golle  wrote:
>
> Hi Brian,

Hi Daniel,

> thank you for taking care of liberating the Google devices ;)

;)

> Please see my comments inline below:
>
> On Sat, Jan 15, 2022 at 09:48:30PM -0800, Brian Norris wrote:
> > Chrom{ium,e} OS (shortened as "CrOS") bootloaders use a custom GPT
> > partition type to locate their kernel(s), with custom attributes for
> > noting properties around which partition(s) should be active and how
> > many times they've been tried as part of their A/B in-place upgrade
> > system.
> >
> > OpenWRT doesn't use A/B updates for upgrades (instead, just shutting
> > things down far enough to reprogram the necessary partitions), so all we
> > need to do is tell the bootloader which one is the kernel partition, and
> > how to use it (i.e., set the "successful" and "priority" attributes).
> >
> > ptgen already supports some basic GPT partition creation, so just
> > add support for a '-T ' argument. Currently, this
> > only supports '-T cros_kernel', but it could be extended if there are
> > other GPT partition types needed.
> >
> > For GPT attribute and GUID definitions, see the CrOS verified boot
> > sources:
> >
> > https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/lib/cgptlib/include/cgptlib_internal.h
> > https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/include/gpt.h
> >
> > Wikipedia (!!) even notes the GUIDs:
> > https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
> >
> > The GUID is also recognized in fdisk, and likely other utilities, but
> > creation/manipulation is typically done via the 'cgpt' utility, provided
> > as part of the Chromium vboot_reference project.
> >
> > Signed-off-by: Brian Norris 
> > ---
> >  src/ptgen.c | 43 ++-
> >  1 file changed, 38 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/ptgen.c b/src/ptgen.c
> > index 69757c1fc7dc..7220dde42b92 100644
> > --- a/src/ptgen.c
> > +++ b/src/ptgen.c
> > @@ -70,6 +70,10 @@ typedef struct {
> >   GUID_INIT( 0x21686148, 0x6449, 0x6E6F, \
> >   0x74, 0x4E, 0x65, 0x65, 0x64, 0x45, 0x46, 0x49)
> >
> > +#define GUID_PARTITION_CHROME_OS_KERNEL \
> > + GUID_INIT( 0xFE3A2A5D, 0x4F32, 0x41A7, \
> > + 0xB7, 0x25, 0xAC, 0xCC, 0x32, 0x85, 0xA3, 0x09)
> > +
> >  #define GUID_PARTITION_LINUX_FIT_GUID \
> >   GUID_INIT( 0xcae9be83, 0xb15f, 0x49cc, \
> >   0x86, 0x3f, 0x08, 0x1b, 0x74, 0x4a, 0x2d, 0x93)
> > @@ -116,7 +120,9 @@ struct partinfo {
> >   int hybrid;
> >   char *name;
> >   short int required;
> > + bool has_guid;
> >   guid_t guid;
> > + uint64_t gattr;  /* GPT partition attributes */
> >  };
> >
> >  /* GPT Partition table header */
> > @@ -256,6 +262,23 @@ static inline int guid_parse(char *buf, guid_t *guid)
> >   return 0;
> >  }
> >
> > +/*
> > + * Map GPT partition types to partition GUIDs.
> > + * NB: not all GPT partition types have an equivalent MBR type.
> > + */
> > +static inline bool parse_gpt_parttype(const char *type, struct partinfo 
> > *part)
> > +{
> > + if (!strcmp(type, "cros_kernel")) {
> > + part->has_guid = true;
> > + part->guid = GUID_PARTITION_CHROME_OS_KERNEL;
> > + /* Default attributes: bootable kernel. */
> > + part->gattr = (1ULL << 48) |  /* priority=1 */
> > +   (1ULL << 56);  /* success=1 */
> > + return true;
> > + }
> > + return false;
> > +}
> > +
> >  /* init an utf-16 string from utf-8 string */
> >  static inline void init_utf16(char *str, uint16_t *buf, unsigned bufsize)
> >  {
> > @@ -416,6 +439,7 @@ static int gen_gptable(uint32_t signature, guid_t guid, 
> > unsigned nr)
> >   to_chs(sect - 1, pte[1].chs_end);
> >   pmbr++;
> >   }
> > + gpte[i].attr = parts[i].gattr;
> >
> >   if (parts[i].name)
> >   init_utf16(parts[i].name, (uint16_t *)gpte[i].name, 
> > GPT_ENTRY_NAME_SIZE / sizeof(uint16_t));
> > @@ -523,7 +547,9 @@ fail:
> >
> >  static void usage(char *prog)
> >  {
> > - fprintf(stderr, "Usage: %s [-v] [-n

[PATCH firmware-utils 1/2] ptgen: add Chromium OS kernel partition support

[Brian Norris]

Chrom{ium,e} OS (shortened as "CrOS") bootloaders use a custom GPT
partition type to locate their kernel(s), with custom attributes for
noting properties around which partition(s) should be active and how
many times they've been tried as part of their A/B in-place upgrade
system.

OpenWRT doesn't use A/B updates for upgrades (instead, just shutting
things down far enough to reprogram the necessary partitions), so all we
need to do is tell the bootloader which one is the kernel partition, and
how to use it (i.e., set the "successful" and "priority" attributes).

ptgen already supports some basic GPT partition creation, so just
add support for a '-T ' argument. Currently, this
only supports '-T cros_kernel', but it could be extended if there are
other GPT partition types needed.

For GPT attribute and GUID definitions, see the CrOS verified boot
sources:

https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/lib/cgptlib/include/cgptlib_internal.h
https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/include/gpt.h

Wikipedia (!!) even notes the GUIDs:
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

The GUID is also recognized in fdisk, and likely other utilities, but
creation/manipulation is typically done via the 'cgpt' utility, provided
as part of the Chromium vboot_reference project.

Signed-off-by: Brian Norris 
---
 src/ptgen.c | 43 ++-
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/src/ptgen.c b/src/ptgen.c
index 69757c1fc7dc..7220dde42b92 100644
--- a/src/ptgen.c
+++ b/src/ptgen.c
@@ -70,6 +70,10 @@ typedef struct {
GUID_INIT( 0x21686148, 0x6449, 0x6E6F, \
0x74, 0x4E, 0x65, 0x65, 0x64, 0x45, 0x46, 0x49)
 
+#define GUID_PARTITION_CHROME_OS_KERNEL \
+   GUID_INIT( 0xFE3A2A5D, 0x4F32, 0x41A7, \
+   0xB7, 0x25, 0xAC, 0xCC, 0x32, 0x85, 0xA3, 0x09)
+
 #define GUID_PARTITION_LINUX_FIT_GUID \
GUID_INIT( 0xcae9be83, 0xb15f, 0x49cc, \
0x86, 0x3f, 0x08, 0x1b, 0x74, 0x4a, 0x2d, 0x93)
@@ -116,7 +120,9 @@ struct partinfo {
int hybrid;
char *name;
short int required;
+   bool has_guid;
guid_t guid;
+   uint64_t gattr;  /* GPT partition attributes */
 };
 
 /* GPT Partition table header */
@@ -256,6 +262,23 @@ static inline int guid_parse(char *buf, guid_t *guid)
return 0;
 }
 
+/*
+ * Map GPT partition types to partition GUIDs.
+ * NB: not all GPT partition types have an equivalent MBR type.
+ */
+static inline bool parse_gpt_parttype(const char *type, struct partinfo *part)
+{
+   if (!strcmp(type, "cros_kernel")) {
+   part->has_guid = true;
+   part->guid = GUID_PARTITION_CHROME_OS_KERNEL;
+   /* Default attributes: bootable kernel. */
+   part->gattr = (1ULL << 48) |  /* priority=1 */
+ (1ULL << 56);  /* success=1 */
+   return true;
+   }
+   return false;
+}
+
 /* init an utf-16 string from utf-8 string */
 static inline void init_utf16(char *str, uint16_t *buf, unsigned bufsize)
 {
@@ -416,6 +439,7 @@ static int gen_gptable(uint32_t signature, guid_t guid, 
unsigned nr)
to_chs(sect - 1, pte[1].chs_end);
pmbr++;
}
+   gpte[i].attr = parts[i].gattr;
 
if (parts[i].name)
init_utf16(parts[i].name, (uint16_t *)gpte[i].name, 
GPT_ENTRY_NAME_SIZE / sizeof(uint16_t));
@@ -523,7 +547,9 @@ fail:
 
 static void usage(char *prog)
 {
-   fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h  -s  -o 
 [-a 0..4] [-l ] [-G ] [[-t ] [-r] [-N 
] -p [@]...] \n", prog);
+   fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h  -s  -o 
\n"
+   "  [-a 0..4] [-l ] [-G ]\n"
+   "  [[-t  | -T ] [-r] [-N 
] -p [@]...] \n", prog);
exit(EXIT_FAILURE);
 }
 
@@ -559,9 +585,8 @@ int main (int argc, char **argv)
uint32_t signature = 0x5452574F; /* 'OWRT' */
guid_t guid = GUID_INIT( signature, 0x2211, 0x4433, \
0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0x00);
-   guid_t part_guid = GUID_PARTITION_BASIC_DATA;
 
-   while ((ch = getopt(argc, argv, "h:s:p:a:t:o:vnHN:gl:rS:G:")) != -1) {
+   while ((ch = getopt(argc, argv, "h:s:p:a:t:T:o:vnHN:gl:rS:G:")) != -1) {
switch (ch) {
case 'o':
filename = optarg;
@@ -594,12 +619,12 @@ int main (int argc, char **argv)
*(p++) = 0;
parts[part].start = to_kbytes(p);
}
-   part_guid = type_to_g

[PATCH firmware-utils 2/2] cros-vbutil: add Chrome OS vboot kernel-signing utility

[Brian Norris]

Chrom{ium,e} OS based devices use a Coreboot+Depthcharge-based firmware,
which verifies and loads a kernel packed in a verified-boot payload. The
verification tooling (both for creating and verifying payloads) is
implemented here:

https://chromium.googlesource.com/chromiumos/platform/vboot_reference

Devices running such bootloaders also tend to support a "developer
mode," where a device can be unlocked to run arbitrary kernel payloads,
using the same verified-boot format plus well-known developer keys. More
information can be found here:

https://chromium.googlesource.com/chromiumos/docs/+/master/developer_mode.md

Rather than build and package the vboot_reference utilities as part of
the base OpenWRT tools, I chose to reimplement just the portion that's
required for signing payloads. I also embed the developer key directly
in the source for convenience, though it's certainly possible to
provide other keys too, if one were to build their own firmware that
accepts it.

This tool is essentially the same as running something like this, using
the Chromium OS tooling:

  vbutil_kernel --pack kernel_partition.bin \
   --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
   --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
   --version 1 \
   --vmlinuz kernel.bin \
   --bootloader zero.txt \
   --config commnad_line.txt \
   --arch ${ARCH}

I have also packaged the Chromium OS vboot_reference tooling for the
packages feed, as it can be useful beyond simply creating a bootable
image (e.g., manipulating Chromium OS specific GPT attributes, handling
other NVRAM attributes, vboot packing/unpacking/verifying):
https://github.com/openwrt/packages/pull/12829

The vboot_reference tools are released by Google under a BSD 3-clause
license. I've provided the original license text as well as a GPL-2
notice for my modifications (essentially just borrowing the data
structures and rewriting everything else).

Signed-off-by: Brian Norris 
---
 CMakeLists.txt|   1 +
 src/cros-vbutil.c | 608 ++
 2 files changed, 609 insertions(+)
 create mode 100644 src/cros-vbutil.c

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f406520aa87e..9ac64ff51033 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -34,6 +34,7 @@ FW_UTIL(bcm4908kernel "" "" "")
 FW_UTIL(buffalo-enc src/buffalo-lib.c "" "")
 FW_UTIL(buffalo-tag src/buffalo-lib.c "" "")
 FW_UTIL(buffalo-tftp src/buffalo-lib.c "" "")
+FW_UTIL(cros-vbutil "" "" "${OPENSSL_CRYPTO_LIBRARIES}")
 FW_UTIL(dgfirmware "" "" "")
 FW_UTIL(dgn3500sum "" "" "")
 FW_UTIL(dns313-header "" "" "")
diff --git a/src/cros-vbutil.c b/src/cros-vbutil.c
new file mode 100644
index ..a29ee700f1d4
--- /dev/null
+++ b/src/cros-vbutil.c
@@ -0,0 +1,608 @@
+/*
+ * cros-vbutil - Tool for signing kernels using the Chromium OS verified boot
+ * format, using widely-shared "developer" keys. The output of this tool is
+ * intended to be written to a GPT partition of type "Chrome OS Kernel", such
+ * that a Chromium OS bootloader can find it.
+ *
+ * Much of this is adapted from Google's vboot_reference project found here:
+ *   https://chromium.googlesource.com/chromiumos/platform/vboot_reference
+ *
+ * Copyright (c) 2010 The Chromium OS Authors. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Google Inc. nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * 

Re: Support for Google Onhub devices

[Brian Norris]

On Wed, Jan 12, 2022 at 8:43 AM Thomas Deselaers  wrote:
>
> Hey folks,

Hi!

> I have an Onhub router and some Google Wifi repeaters. Google recently
> announced that they are going to shut down the support for Onhub
> (effectively bricking them) by end of 2022.
>
> I have done a bit of research and it seems like there was some
> preliminary support for OpenWRT on these devices at some point. I
> guess there will be a lot of Onhubs that would be pretty good OpenwRT
> routers in about a year - which otherwise, are probably going to the
> trash.
>
> While I am a developer, I have only very little openWRT experience and
> I have been wondering what it would take to bring up support for these
> devices.

It's not likely to be a great "first hacking on OpenWRT" experience,
but it should technically be possible...

FWIW, I've been hacking on Google WiFi, the successor of the OnHub. I
have it working, and documented pretty much everything here:

https://openwrt.org/inbox/toh/google/google_wifi

For the OnHub, you could leverage the same partition formatting (OnHub
is also running a similar Chrome OS bootloader), but you'd have to
bring up a different SoC (OnHub uses ipq8064, while Google WiFi is
ipq4019). OnHub also doesn't have as easy of serial-console access for
hacking. And I don't see documentation for Developer Mode on OnHub,
although I know it's possible.

But, I'm interested, and if you really have the stamina to hack on it,
I can be a sounding board!

Regard,
Brian

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

Re: Patchwork and DMARC emails.

[Brian Norris]

On Thu, Feb 18, 2021 at 2:50 AM Bjørn Mork  wrote:
> Brian Norris  writes:
> > I've necromanced that thread to bug the infradead admin -- maybe he
> > can be convinced to try that patch:
> > http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033849.html
>
> Would be great to have that fixed. The missing subject is extremely
> annyoing in any email client.  It's not just about patchwork.  I scan
> quickly over mailing lists and my eyes tend to ignore any email with
> subject "(none)", which is what Gnus uses in summary buffers.

Agreed.

To close this out: it seems like David applied said patch in the last
day or two, and the subject line is working again:
http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033858.html

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

Re: missing email header

[Brian Norris]

On Thu, Feb 18, 2021 at 1:57 AM David Woodhouse  wrote:
> On Wed, 2021-02-17 at 21:52 -0800, Brian Norris wrote:
> > It turns out a bug report was filed, and fixed:
> >
> > https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/
> > https://bugs.launchpad.net/mailman/+bug/1915655
> >
> > They've suggested the mailman admin apply a patch ;)
>
> I believe I did so yesterday.

Ah! I suspected that might be the case after I sent my previous email,
as I then searched my mailbox for those DMARC-wrapping headers and
finally found a single message from Etan that finally had a correct
Subject line. And there have been more since. So that part seems to
work now.

Awesome, thanks.

Brian

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

Re: Patchwork and DMARC emails.

[Brian Norris]

On Wed, Feb 17, 2021 at 8:11 PM Sam Kuper  wrote:
>
> On Wed, Feb 17, 2021 at 02:47:57PM +0100, Etan Kissling wrote:
> > On 08.02.21, 10:33, Rosen Penev wrote:
> >>> My patches don't end up in Patchwork for some reason.
> >> It's because of DMARC. [..]
...
> > For other mailing lists that do not modify email subject and body,
> > Patchwork has no problems with DMARC.  Example:
> > https://patchwork.ozlabs.org/project/netfilter-devel/patch/a355cb9d-9b07-4d62-a228-a37c2660c...@apple.com/
> > for mailing list: netfilter-de...@vger.kernel.org
>
> I don't know which headers Patchwork requires in order to be able to
> process an email correctly, but if it requires a non-empty "Subject:"
> header, then see:

I'm pretty sure Patchwork expects some kind of subject, so yes that's
most likely a problem.

> https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/

Oh, nice, thanks for filing the bug report! This came up before but
wasn't resolved:
http://lists.openwrt.org/pipermail/openwrt-devel/2020-August/030819.html

I've necromanced that thread to bug the infradead admin -- maybe he
can be convinced to try that patch:
http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033849.html

Brian

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

Re: missing email header

[Brian Norris]

(CC a few)

On Tue, Aug 11, 2020 at 6:59 AM David Woodhouse  wrote:
> On Mon, 2020-08-10 at 10:13 -0300, Henrique de Moraes Holschuh wrote:
> > Agreed.  HOWEVER, anything that is being relayed due to too-strict SPF
> > is being relayed with an *EMPTY* subject, and *THAT* is extremely annoying.
>
> Hm, didn't that get fixed?

It would seem not. Mailing list participants have been complaining
very recently:

http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033848.html

It turns out a bug report was filed, and fixed:

https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/
https://bugs.launchpad.net/mailman/+bug/1915655

They've suggested the mailman admin apply a patch ;)

Brian

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

Re: Installation error for libncursesw6

[Brian Norris]

On Sun, Feb 14, 2021 at 4:07 PM Ansuel Smith  wrote:
>
> > Collected errors:
> >  * pkg_hash_fetch_best_installation_candidate: Packages for
> > libreadline8 found, but incompatible with the architectures configured
> >  * opkg_install_cmd: Cannot install package libreadline8.
> >  * satisfy_dependencies_for: Cannot satisfy the following dependencies
> > for softethervpn5-libs:
> >  *  libncursesw6
> >  * opkg_install_cmd: Cannot install package softethervpn5-libs.
> > make[2]: *** [package/Makefile:69: package/install] Error 255
> >
> > Multiple packages complain about this... This is from a clean custom build.
> > Think this is caused by the abi changes to buildroot
>
> reverting c92165038217e49075098479704da58a2a3a89bd fix the problem

Thanks for tracking down the regression! This has been bugging me too.

FWIW, I found that the problem seems to be in badly-generated
libncurses ipk files. The 'control' file seems to have lines like
this:

Provides: libncursesw, libncurses, libncursesw

when it should have:

Provides: libncursesw, libncurses, libncursesw6

Brian

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

[PATCH] base-files: mount pstore if present

[Brian Norris]

Pstore (persistent store) can be used to stash debug information (kernel
console, panics, ftrace) across reboots or crashes. If the filesystem is
present, mount it.

Signed-off-by: Brian Norris 
---
 package/base-files/files/etc/init.d/boot | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/base-files/files/etc/init.d/boot 
b/package/base-files/files/etc/init.d/boot
index b36323a97e2a..a1e8e828dd2b 100755
--- a/package/base-files/files/etc/init.d/boot
+++ b/package/base-files/files/etc/init.d/boot
@@ -35,6 +35,7 @@ boot() {
ln -sf /tmp/resolv.conf.d/resolv.conf.auto /tmp/resolv.conf
grep -q debugfs /proc/filesystems && /bin/mount -o noatime -t debugfs 
debugfs /sys/kernel/debug
grep -q bpf /proc/filesystems && /bin/mount -o 
nosuid,nodev,noexec,noatime,mode=0700 -t bpf bpffs /sys/fs/bpf
+   grep -q pstore /proc/filesystems && /bin/mount -o noatime -t pstore 
pstore /sys/fs/pstore
[ "$FAILSAFE" = "true" ] && touch /tmp/.failsafe
 
/sbin/kmodloader
-- 
2.29.2


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

Re: [PATCH v2 3/4] image-commands: support Chromium OS image-type creation

[Brian Norris]

Hi Paul,

On Sun, Jan 17, 2021 at 2:43 AM Paul Spooren  wrote:
> On Sat Jan 16, 2021 at 5:07 PM HST, Brian Norris wrote:
> > See the previous patches, which implemented the cros-vbutil
> > verified-boot payload-packing tool, and extended ptgen for the CrOS
> > kernel partition type. With these, it's now possible to package kernel +
> > rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
> > Chromebooks, or even a few AP models).
> >
> > gen_image_vboot.sh borrows a bit of structure from gen_image_generic.sh,
> > but I didn't feel it fit well to try and add new flags to the latter,
> > given the difference in its FAT kernel packaging and our raw kernel
> > partition packing.
> >
> > Signed-off-by: Brian Norris 
> > ---
> > include/image-commands.mk | 18 ++
> > .../base-files/files/lib/upgrade/common.sh | 4 ++-
> > scripts/gen_image_vboot.sh | 36 +++
> > 3 files changed, 57 insertions(+), 1 deletion(-)
> > create mode 100755 scripts/gen_image_vboot.sh
> >
> > diff --git a/include/image-commands.mk b/include/image-commands.mk
> > index 979eafb15734..f02d8e79fce6 100644
> > --- a/include/image-commands.mk
> > +++ b/include/image-commands.mk
> > @@ -172,6 +172,24 @@ define Build/fit
> > @mv $@.new $@
> > endef
> >
> > +define Build/cros-image
> > + $(SCRIPT_DIR)/gen_image_vboot.sh \
> > + $@ \
> > + $(CONFIG_TARGET_KERNEL_PARTSIZE) \
>
> You're passing the kernel size twice here which the script expects
>  . Am I missing something?

>From the error/help text:

echo "SYNTAX: $0  "

It's a bit awkward, but for the first partition, it's only asking for
a . I haven't fully fleshed it out yet, but this first partition
is a spare FAT partition, for use in sysupgrade. I believe other
systems reuse the kernel partition (which tends to be either FAT or
ext4), but because Chrome OS systems use a signed blob (and not a
proper filesystem) for their kernel partitions, I needed to create an
extra partition, with no special data in it.

Also, I don't really have a separate Kconfig option for defining the
FAT partition size -- I just reused the kernel partition size.

I'm open to suggestions on this, but the current code is written as
intended. I'm not very familiar with OpenWRT image-construction best
practices (e.g., adding more Kconfig parameters?).

Thanks,
Brian

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

[PATCH] base-file: remove unused 'bootdisk' variable

[Brian Norris]

This was left obsolete in:
4a0688ed7153 base-files: remove block2mtd checks from sysupgrade

Signed-off-by: Brian Norris 
---
 package/base-files/files/lib/upgrade/common.sh | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index c28bae48a15c..0c78974d7c6b 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -149,7 +149,7 @@ part_magic_fat() {
 }
 
 export_bootdevice() {
-   local cmdline bootdisk rootpart uuid blockdev uevent line class
+   local cmdline rootpart uuid blockdev uevent line class
local MAJOR MINOR DEVNAME DEVTYPE
 
if read cmdline < /proc/cmdline; then
@@ -160,12 +160,6 @@ export_bootdevice() {
;;
esac
 
-   case "$bootdisk" in
-   /dev/*)
-   uevent="/sys/class/block/${bootdisk##*/}/uevent"
-   ;;
-   esac
-
case "$rootpart" in

PARTUUID=[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9]-[a-f0-9][a-f0-9])
uuid="${rootpart#PARTUUID=}"
-- 
2.29.2


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

[PATCH v2 4/4] ipq40xx: add target for Google WiFi (Gale)

[Brian Norris]

Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
In its stock configuration, it runs a Chromium OS-based system, but you
wouldn't know it, since you can only manage it via a "cloud" +
mobile-app system.

The "v2" label is coded into the bootloader, which prefers the
"google,gale-v2" compatible string. I believe "v1" must have been
pre-release hardware.

Note: this is *not* the Google Nest WiFi, released in 2019.

I include "factory.bin" support, where we generate a GPT-based disk
image with 3 partitions -- a spare FAT partition, a kernel partition
(using the custom "Chrome OS kernel" GUID type) and a root filesystem
partition. See below for flashing instructions.

Sysupgrade is only partially working.

"FEATURES=boot-part rootfs-part" is required to get kernel and rootfs
partition sizes established. This adds extra (unused) configuration
parameters for other ipq40xx targets, so I'm not sure if this is the
"right" thing to do either.

Flashing instructions
=

[ NB: you may still need to tweak which drivers are built-in, if you
want to boot from a USB disk. ]

Chrome OS systems allow booting custom images only when transitioned
into Developer Mode. Existing sources document how to enter Developer
Mode on a Google WiFi system:

https://github.com/marcosscriven/galeforce#how-to-apply-an-image

The OpenWRT-relevant summary:

1. Flash factory.bin to a USB storage device (e.g., with 'dd')
2. Pop off the case
3. Attach a USB-C hub with power delivery
4. Press the reset button on the back until light blinks orange (>16
   seconds)
5. Once blinking orange, hit the tiny bubble switch (SW7) found on the
   board
6. Device will start blinking purple and restart
7. Wait until device restarts and starts blinking purple again
7. Plug in USB stick
8. Hit bubble switch again

The device should boot to OpenWRT.

If you want to persist to the eMMC, flash factory.bin to /dev/mmcblk0.

Features


I've tested:

 * Ethernet, both WAN and LAN ports
 * eMMC
 * USB-C (hub, power-delivery, peripherals)
 * LED0 (R/G/B)
 * WiFi (limited testing)
 * SPI flash
 * Serial console: once in developer mode, console can be accessed via
   the USB-C port with SuzyQable, or other similar "Closed Case
   Debugging" tools:
 
https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/ccd.md#suzyq-suzyqable

Not tested:

 * TPM
 * LED1, LED2: I'm not even confident they are actually populated
   anywhere

Known not working:

 * Reboot: this requires some additional TrustZone / SCM
   configuration to disable Qualcomm's SDI. I have a proposal upstream,
   and based on IRC chats, this might be acceptable with additional DT
   logic:
 [RFC PATCH] firmware: qcom_scm: disable SDI at boot
 
https://lore.kernel.org/linux-arm-msm/20200721080054.2803881-1-computersforpe...@gmail.com/
 * SMP: enabling secondary CPUs doesn't currently work using the stock
   bootloader, as the qcom_scm driver assumes newer features than this
   TrustZone firmware has. I posted notes here:
 [RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
 https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
 * There's a single external button, and a few useful internal GPIO
   switches. I haven't hooked them up.

Additional notes


Much of the DTS is pulled from the Chrome OS kernel 3.18 branch, which
the manufacturer image uses.

Note: the manufacturer bootloader knows how to patch in calibration data
via the wifi{0,1} aliases in the DTB, so while these properties aren't
present in the DTS, they are available at runtime:

  # ls -l
/sys/firmware/devicetree/base/soc/wifi@a*/qcom,ath10k-pre-calibration-data
  -r--r--r--1 root root 12064 Jul 15 19:11 
/sys/firmware/devicetree/base/soc/wifi@a00/qcom,ath10k-pre-calibration-data
  -r--r--r--1 root root 12064 Jul 15 19:11 
/sys/firmware/devicetree/base/soc/wifi@a80/qcom,ath10k-pre-calibration-data

Ethernet MAC addresses are similarly patched in via the ethernet{0,1} aliases.

Signed-off-by: Brian Norris 
---
v2:
 * include more verbose flashing instructions
 * rename to "google_wifi" in most contexts, with "gale" only used as a
   secondary name, so the bootloader can find the DTB
 * other formalities (alphabetization, etc.)
---
 target/linux/ipq40xx/Makefile |   2 +-
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../base-files/lib/upgrade/platform.sh|  16 +
 .../arch/arm/boot/dts/qcom-ipq4019-wifi.dts   | 402 ++
 target/linux/ipq40xx/image/Makefile   |  13 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 6 files changed, 435 insertions(+), 2 deletions(-)
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qco

[PATCH v2 2/4] firmware-utils/cros-vbutil: add Chrome OS vboot kernel-signing utility

[Brian Norris]

Chrom{ium,e} OS based devices use a Coreboot+Depthcharge-based firmware,
which verifies and loads a kernel packed in a verified-boot payload. The
verification tooling (both for creating and verifying payloads) is
implemented here:

https://chromium.googlesource.com/chromiumos/platform/vboot_reference

Devices running such bootloaders also tend to support a "developer
mode," where a device can be unlocked to run arbitrary kernel payloads,
using the same verified-boot format plus well-known developer keys. More
information can be found here:

https://chromium.googlesource.com/chromiumos/docs/+/master/developer_mode.md

Rather than build and package the vboot_reference utilities as part of
the base OpenWRT tools, I chose to reimplement just the portion that's
required for signing payloads. I also embed the developer key directly
in the source for convenience, though it's certainly possible to
provide other keys too, if one were to build their own firmware that
accepts it.

This tool is essentially the same as running something like this, using
the Chromium OS tooling:

  vbutil_kernel --pack kernel_partition.bin \
   --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
   --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
   --version 1 \
   --vmlinuz kernel.bin \
   --bootloader zero.txt \
   --config commnad_line.txt \
   --arch ${ARCH}

I have also packaged the Chromium OS vboot_reference tooling for the
packages feed, as it can be useful beyond simply creating a bootable
image (e.g., manipulating Chromium OS specific GPT attributes, handling
other NVRAM attributes, vboot packing/unpacking/verifying):
https://github.com/openwrt/packages/pull/12829

The vboot_reference tools are released by Google under a BSD 3-clause
license. I've provided the original license text as well as a GPL-2
notice for my modifications (essentially just borrowing the data
structures and rewriting everything else).

Signed-off-by: Brian Norris 
---
 tools/firmware-utils/Makefile  |   1 +
 tools/firmware-utils/src/cros-vbutil.c | 609 +
 2 files changed, 610 insertions(+)
 create mode 100644 tools/firmware-utils/src/cros-vbutil.c

diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index 6074ecc608d0..f4f9f233cdc2 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -30,6 +30,7 @@ define Host/Compile
$(call cc,buffalo-enc buffalo-lib,-Wall)
$(call cc,buffalo-tag buffalo-lib,-Wall)
$(call cc,buffalo-tftp buffalo-lib,-Wall)
+   $(call cc,cros-vbutil,-lcrypto -lpthread)
$(call cc,dgfirmware)
$(call cc,dgn3500sum,-Wall)
$(call cc,dns313-header,-Wall)
diff --git a/tools/firmware-utils/src/cros-vbutil.c 
b/tools/firmware-utils/src/cros-vbutil.c
new file mode 100644
index ..13ba9a3245b3
--- /dev/null
+++ b/tools/firmware-utils/src/cros-vbutil.c
@@ -0,0 +1,609 @@
+/*
+ * cros-vbutil - Tool for signing kernels using the Chromium OS verified boot
+ * format, using widely-shared "developer" keys. The output of this tool is
+ * intended to be written to a GPT partition of type "Chrome OS Kernel", such
+ * that a Chromium OS bootloader can find it.
+ *
+ * Much of this is adapted from Google's vboot_reference project found here:
+ *   https://chromium.googlesource.com/chromiumos/platform/vboot_reference
+ *
+ * Copyright (c) 2010 The Chromium OS Authors. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Google Inc. nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF A

[PATCH v2 3/4] image-commands: support Chromium OS image-type creation

[Brian Norris]

See the previous patches, which implemented the cros-vbutil
verified-boot payload-packing tool, and extended ptgen for the CrOS
kernel partition type. With these, it's now possible to package kernel +
rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
Chromebooks, or even a few AP models).

gen_image_vboot.sh borrows a bit of structure from gen_image_generic.sh,
but I didn't feel it fit well to try and add new flags to the latter,
given the difference in its FAT kernel packaging and our raw kernel
partition packing.

Signed-off-by: Brian Norris 
---
 include/image-commands.mk | 18 ++
 .../base-files/files/lib/upgrade/common.sh|  4 ++-
 scripts/gen_image_vboot.sh| 36 +++
 3 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100755 scripts/gen_image_vboot.sh

diff --git a/include/image-commands.mk b/include/image-commands.mk
index 979eafb15734..f02d8e79fce6 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -172,6 +172,24 @@ define Build/fit
@mv $@.new $@
 endef
 
+define Build/cros-image
+   $(SCRIPT_DIR)/gen_image_vboot.sh \
+ $@ \
+ $(CONFIG_TARGET_KERNEL_PARTSIZE) \
+ $(CONFIG_TARGET_KERNEL_PARTSIZE) $(IMAGE_KERNEL) \
+ $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(IMAGE_ROOTFS)
+endef
+
+# NB: Chrome OS bootloaders replace the '%U' in command lines with the UUID of
+# the kernel partition it chooses to boot from. This gives a flexible way to
+# consistently build and sign kernels that always use the subsequent
+# (PARTNROFF=1) partition as their rootfs.
+define Build/cros-vboot
+   $(STAGING_DIR_HOST)/bin/cros-vbutil \
+   -k $@ -c "root=PARTUUID=%U/PARTNROFF=1" -o $@.new
+   @mv $@.new $@
+endef
+
 define Build/gzip
gzip -f -9n -c $@ $(1) > $@.new
@mv $@.new $@
diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index c28bae48a15c..a2ee8d1675a6 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -178,9 +178,11 @@ export_bootdevice() {
fi
done
;;
+   
PARTUUID=----??01/PARTNROFF=1 | \
PARTUUID=----??02)
uuid="${rootpart#PARTUUID=}"
-   uuid="${uuid%02}00"
+   uuid="${uuid%/PARTNROFF=1}"
+   uuid="${uuid%0?}00"
for disk in $(find /dev -type b); do
set -- $(dd if=$disk bs=1 skip=568 
count=16 2>/dev/null | hexdump -v -e '8/1 "%02x "" "2/1 "%02x""-"6/1 "%02x"')
if [ "$4$3$2$1-$6$5-$8$7-$9" = "$uuid" 
]; then
diff --git a/scripts/gen_image_vboot.sh b/scripts/gen_image_vboot.sh
new file mode 100755
index ..ae267ba3fbb9
--- /dev/null
+++ b/scripts/gen_image_vboot.sh
@@ -0,0 +1,36 @@
+#!/usr/bin/env bash
+# Copyright (C) 2021 OpenWrt.org
+set -e -x
+[ $# == 6 ] || {
+echo "SYNTAX: $0 
 "
+exit 1
+}
+
+OUTPUT="$1"
+BOOTPARTSIZE="$2"
+KERNELSIZE="$3"
+KERNELIMAGE="$4"
+ROOTFSSIZE="$5"
+ROOTFSIMAGE="$6"
+
+rm -f "${OUTPUT}"
+
+head=16
+sect=63
+
+# create partition table
+set $(ptgen -o "${OUTPUT}" -h $head -s $sect -g -p ${BOOTPARTSIZE}m -T 
cros_kernel -p ${KERNELSIZE}m -p ${ROOTFSSIZE}m)
+
+BOOTOFFSET="$(($1 / 512))"
+BOOTSIZE="$2"
+KERNELOFFSET="$(($3 / 512))"
+KERNELSIZE="$4"
+ROOTFSOFFSET="$(($5 / 512))"
+ROOTFSSIZE="$(($6 / 512))"
+
+mkfs.fat -n boot -C "${OUTPUT}.boot" -S 512 "$((BOOTSIZE / 1024))"
+
+dd if="${OUTPUT}.boot" of="${OUTPUT}" bs=512 seek="${BOOTOFFSET}" conv=notrunc
+rm -f "${OUTPUT}.boot"
+dd if="${KERNELIMAGE}" of="${OUTPUT}" bs=512 seek="${KERNELOFFSET}" 
conv=notrunc
+dd if="${ROOTFSIMAGE}" of="${OUTPUT}" bs=512 seek="${ROOTFSOFFSET}" 
conv=notrunc
-- 
2.29.2


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

[PATCH v2 0/4] Add support for Chromium OS and Google WiFi

[Brian Norris]

Hi,

This series adds support for both Chromium OS (or particularly, its
kernel-payload signing and disk layout) and for a device using it (the
first generation Google WiFi).

Google WiFi (code-named "Gale") is an IPQ4019-based AP. Its hardware is
decently supported by the existing ipq40xx target -- see patch 4 for
more notes. Notably missing: reboot does not work properly -- I have
some separate TrustZone/SCM-related patches I'd like to clean up to
enable this later.

I sent v1 as an "RFC" here:
http://patchwork.ozlabs.org/project/openwrt/patch/20200718205148.1743807-6-computersforpe...@gmail.com/
and since I got only mechanical feedback for the last patch, I'm now
sending a non-RFC. I leave some notes about my implementation choices
below, for reference.

Changes since v1:
 * 1 patch was already merged
 * patch 4 is rebased, improved (see patch 4 for notes)

Chromium OS (the open-source OS on which Google builds its Chrome OS) --
"CrOS" for short -- typically boots via Coreboot, plus Depthcharge as a
second stage. Such bootloaders utilize a verified boot toolkit [1] to
verify each subsequent stage. Of note:

 1. The kernel should be placed in a GPT partition with a custom "Chrome
OS kernel" GUID type and a few custom flags (to manage the A/B
OS updates employed by Chromium OS). CrOS vboot provides the `cgpt`
utility for creating and managing such partitions.
 2. That partition should hold a vboot payload, signed and packaged per
the format documented and implemented at [1]. Using the vboot
utilities, this involves the `vbutil_kernel --pack ...` command.

I chose:

 (a) To extend OpenWRT's ptgen to help customize partition types,
 instead of packaging vboot's `cgpt`.
 (b) To adapt and reimplement the `vbutil_kernel` command as a custom
 `cros-vbutil` utility, rather than packaging Google's utility.
 (c) To add kernel and rootfs partition-size parameters (for customizing
 my GPT), but it's not clear to me if this fits well into the
 existing ipq40xx target, or if it should be done differently.

For some alternatives (especially on (b)), I did package
futility/vbutil_kernel here:
https://github.com/openwrt/packages/pull/12829
I could adapt this into tools/ instead, so OpenWRT doesn't have to carry
my re-implementation. This would carry some extra build complexity,
as the vboot tools are >10,000 lines of code, compared to my
reimplementation of a few hundred lines. The library dependencies are
similar (mostly just crypto/ssl, and potentially libuuid (for GPT)), as
the vboot project tries to keep the code semi-portable / reusable.

Packaging the vboot utilities might give us some future flexibility, if
the formats grow and change for future systems. So far, I think the
format has been pretty stable. Also, there are potentially some quirks I
missed in my port related the ${ARCH} -- I ported the ARM support, but
there may be some small tweaks I missed that are applicable only to x86
systems.

For (c): adding this to the common ipq40xx target means that there will
be a new CONFIG_TARGET_KERNEL_PARTSIZE and
CONFIG_TARGET_ROOTFS_PARTSIZE, which are only applicable to a single
device but are present for all:
  FEATURES:=boot-part rootfs-part

Regards,
Brian

[1] https://chromium.googlesource.com/chromiumos/platform/vboot_reference

Brian Norris (4):
  firmware-utils/ptgen: add Chromium OS kernel partition support
  firmware-utils/cros-vbutil: add Chrome OS vboot kernel-signing utility
  image-commands: support Chromium OS image-type creation
  ipq40xx: add target for Google WiFi (Gale)

 include/image-commands.mk |  18 +
 .../base-files/files/lib/upgrade/common.sh|   4 +-
 scripts/gen_image_vboot.sh|  36 ++
 target/linux/ipq40xx/Makefile |   2 +-
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../base-files/lib/upgrade/platform.sh|  16 +
 .../arch/arm/boot/dts/qcom-ipq4019-wifi.dts   | 402 
 target/linux/ipq40xx/image/Makefile   |  13 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 tools/firmware-utils/Makefile |   1 +
 tools/firmware-utils/src/cros-vbutil.c| 609 ++
 tools/firmware-utils/src/ptgen.c  |  39 +-
 12 files changed, 1138 insertions(+), 6 deletions(-)
 create mode 100755 scripts/gen_image_vboot.sh
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
 create mode 100644 tools/firmware-utils/src/cros-vbutil.c

-- 
2.29.2


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

[PATCH v2 1/4] firmware-utils/ptgen: add Chromium OS kernel partition support

[Brian Norris]

Chrom{ium,e} OS (shortened as "CrOS") bootloaders use a custom GPT
partition type to locate their kernel(s), with custom attributes for
noting properties around which partition(s) should be active and how
many times they've been tried as part of their A/B in-place upgrade
system.

OpenWRT doesn't use A/B updates for upgrades (instead, just shutting
things down far enough to reprogram the necessary partitions), so all we
need to do is tell the bootloader which one is the kernel partition, and
how to use it (i.e., set the "successful" and "priority" attributes).

ptgen already supports some basic GPT partition creation, so just
add support for a '-T ' argument. Currently, this
only supports '-T cros_kernel', but it could be extended if there are
other GPT partition types needed.

For GPT attribute and GUID definitions, see the CrOS verified boot
sources:

https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/lib/cgptlib/include/cgptlib_internal.h
https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/include/gpt.h

The GUID is also recognized in fdisk, and likely other utilities, but
creation/manipulation is typically done via the 'cgpt' utility, provided
as part of the vboot_reference project.

Signed-off-by: Brian Norris 
---
 tools/firmware-utils/src/ptgen.c | 39 +---
 1 file changed, 36 insertions(+), 3 deletions(-)

diff --git a/tools/firmware-utils/src/ptgen.c b/tools/firmware-utils/src/ptgen.c
index 223ee295611f..bc1da6d64061 100644
--- a/tools/firmware-utils/src/ptgen.c
+++ b/tools/firmware-utils/src/ptgen.c
@@ -80,6 +80,10 @@ typedef struct {
GUID_INIT( 0x21686148, 0x6449, 0x6E6F, \
0x74, 0x4E, 0x65, 0x65, 0x64, 0x45, 0x46, 0x49)
 
+#define GUID_PARTITION_CHROME_OS_KERNEL \
+   GUID_INIT( 0xFE3A2A5D, 0x4F32, 0x41A7, \
+   0xB7, 0x25, 0xAC, 0xCC, 0x32, 0x85, 0xA3, 0x09)
+
 #define GPT_HEADER_SIZE 92
 #define GPT_ENTRY_SIZE  128
 #define GPT_ENTRY_MAX   128
@@ -109,6 +113,9 @@ struct partinfo {
unsigned long start;
unsigned long size;
int type;
+   bool has_gtype;
+   guid_t gtype;  /* GPT partition type */
+   uint64_t gattr;  /* GPT partition attributes */
 };
 
 /* GPT Partition table header */
@@ -248,6 +255,19 @@ static inline int guid_parse(char *buf, guid_t *guid)
return 0;
 }
 
+/* Map GPT partition types to partition GUIDs. */
+static inline bool parse_gpt_parttype(const char *type, struct partinfo *part)
+{
+   if (!strcmp(type, "cros_kernel")) {
+   part->has_gtype = true;
+   part->gtype = GUID_PARTITION_CHROME_OS_KERNEL;
+   part->gattr = (1ULL << 48) |  /* priority=1 */
+ (1ULL << 56);  /* success=1 */
+   return true;
+   }
+   return false;
+}
+
 /* init an utf-16 string from utf-8 string */
 static inline void init_utf16(char *str, uint16_t *buf, unsigned bufsize)
 {
@@ -396,12 +416,15 @@ static int gen_gptable(uint32_t signature, guid_t guid, 
unsigned nr)
gpte[i].end = cpu_to_le64(sect -1);
gpte[i].guid = guid;
gpte[i].guid.b[sizeof(guid_t) -1] += i + 1;
-   if (parts[i].type == 0xEF || (i + 1) == (unsigned)active) {
+   if (parts[i].has_gtype) {
+   gpte[i].type = parts[i].gtype;
+   } else if (parts[i].type == 0xEF || (i + 1) == 
(unsigned)active) {
gpte[i].type = GUID_PARTITION_SYSTEM;
init_utf16("EFI System Partition", (uint16_t 
*)gpte[i].name, GPT_ENTRY_NAME_SIZE / sizeof(uint16_t));
} else {
gpte[i].type = GUID_PARTITION_BASIC_DATA;
}
+   gpte[i].attr = parts[i].gattr;
 
if (verbose)
fprintf(stderr, "Partition %d: start=%" PRIu64 ", 
end=%" PRIu64 ", size=%"  PRIu64 "\n",
@@ -498,7 +521,9 @@ fail:
 
 static void usage(char *prog)
 {
-   fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h  -s  -o 
 [-a 0..4] [-l ] [-G ] [[-t ] -p 
[@]...] \n", prog);
+   fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h  -s  -o 
\n"
+   "  [-a 0..4] [-l ] [-G ]\n"
+   "  [[-t  | -T ] -p 
[@]...] \n", prog);
exit(EXIT_FAILURE);
 }
 
@@ -512,7 +537,7 @@ int main (int argc, char **argv)
guid_t guid = GUID_INIT( signature, 0x2211, 0x4433, \
0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0x00);
 
-   while ((ch = getopt(argc, argv, "h:s:p:a:t:o:vngl:S:G:")) != -1) {
+   while ((ch = getopt(argc, argv, "h:s:p:a:t:T:o:vngl:S:G:")) != -1) {
 

Re: missing email header

[Brian Norris]

Hi,

On Wed, Aug 5, 2020 at 2:21 AM Moritz Warning  wrote:
> somehow the titles of the emails from openwrt-devel@ do not contain a title 
> prefix anymore.
> They appear to address me personally at first glance, which is a bit 
> unsettling.

FWIW, I see very few other mailing lists mangle the Subject field the
way openwrt-devel used to do it. I have no say in these things, but I
personally prefer it this way.

> Is this a temporary thing?

I can't speak for any of that, but it does seem like the change
started around June 21, which happens to be the same weekend when the
machine that hosts the mailing list seems to have gone down with disk
failure:
http://lists.infradead.org/pipermail/linux-mtd/2020-June/081081.html

I expect the mailing list configuration must have been reset too.

So in other words, the change may simply be an accident?

Regards,
Brian

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

Re: [RFC PATCH 5/5] ipq40xx: add target for Google WiFi (Gale)

[Brian Norris]

Hi Adrian,

On Sat, Jul 18, 2020 at 2:13 PM  wrote:
> just some formal stuff below.

Thanks! It's useful, especially where I'm still learning the OpenWRT
Makefile structures.

I'll spin up a new revision sooner or later, but I'm hoping I'll get
some opinion on the RFC portion (cover letter / first ~3 patches)
before doing that.

> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Brian Norris
> > Sent: Samstag, 18. Juli 2020 22:52
> > To: openwrt-devel@lists.openwrt.org
> > Cc: Brian Norris 
> > Subject: [RFC PATCH 5/5] ipq40xx: add target for Google WiFi (Gale)
...
> > I include "factory.bin" support, where we generate a GPT-based disk image
> > with 2 partitions -- a kernel partition (using the custom "Chrome OS kernel"
> > GUID type) and a root filesystem partition. If the AP is in Developer Mode,
> > the stock bootloader can boot it via a USB disk or (after gaining access 
> > via USB
> > boot) flashed to the eMMC.
>
> I'd like a bit more detailed flashing instructions here. What you have right 
> now only works if the reader knows what to do anyway.

Well, it's not exactly trivial, but I guess not that difficult,
relative to the average device OpenWRT supports. As luck would have
it, somebody has already documented it:

https://github.com/marcosscriven/galeforce#how-to-apply-an-image

Would it be best to summarize, link, or both?

> > +++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gale-v2.
> > +++ dts
> > @@ -0,0 +1,402 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2016, 2018 The Linux Foundation. All rights reserved.
> > + * Copyright (c) 2016 Google, Inc
> > + */
> > +
> > +#include "qcom-ipq4019.dtsi"
> > +#include 
> > +#include 
> > +
> > + {
>
> I'd have expected the root node first.

I've learned muscle memory to put things like pinctrl first, because
they're often referenced by other nodes (possibly including in the
root node) via phandle, and at least in the past, DTC would not
support out-of-order references for phandles.

But that doesn't apply here (no phandles from the root section), so
that doesn't apply. Will change.

> > +/ {
> > + model = "Google IPQ4019/Gale";
>
> This should be generally consistent with what you choose for DEVICE_MODEL. 
> See my others comments there below.
>
> > + compatible = "google,gale-v2", "qcom,ipq4019";
...
> > --- a/target/linux/ipq40xx/image/Makefile
> > +++ b/target/linux/ipq40xx/image/Makefile
> > @@ -218,6 +218,20 @@ define Device/avm_fritzbox-4040  endef
> > TARGET_DEVICES += avm_fritzbox-4040
> >
> > +define Device/google_gale-v2
>
> Alphabetic sorting.
>
> > + DEVICE_VENDOR := Google
> > + DEVICE_MODEL := WiFi (Gale)
>
> This uses yet another name compared to device definition/compatible and model 
> in DTS.
> Please be more consistent. Despite, if the device node (and thus the image) 
> has a v2 in it, please also add
>
> DEVICE_VARIANT := v2
>
> here.

Thanks for the scrutiny! I do have some questions here: is the
VENDOR/MODEL supposed to match closer to a
marketing-friendly/user-friendly name, or a developer/low-level name?
Or just some balance of both? Because there's several constraints
here:
* The bootloader recognizes compatible="google,gale-v2" -- I don't
believe I can reliably drop the "v2" there, but I suppose that doesn't
require the file names, etc., to include it
* There really is no v1 publicly-available; as noted in the commit
message, I believe that was pre-release hardware, and the revisions
just stuck around through development
* the "v2" here does *not* mean second generation, as in
https://en.wikipedia.org/wiki/Google_Nest_Wifi#Second_generation
* "WiFi" doesn't really make for a good MODEL on its own, although
it's OK when paired with the VENDOR. But I still preferred sticking
the codename (Gale) around, since that's the unambiguous way hackers
can recognize the model.

What do you think? Should I try to keep the keywords "google", "wifi",
and "gale" in all of the config, image, and DTS name? And I'll avoid
the "v2" labeling (and DEVICE_VARIANT) outside of "compatible",
because I think that would be misleading.

Anyway, I'll try to figure out a better balance of the above on the
next version.

Thanks,
Brian

> > + SOC := qcom-ipq4019
> > + DEVICE_DTS := qcom-ipq4019-gale-v2
>
> This line can be dropped, it will be calculated from SOC and device node name 
> automatically.

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

Re: [RFC PATCH 3/5] image-commands: support Chromium OS image-type creation

[Brian Norris]

Hi Adrian,

On Sat, Jul 18, 2020 at 2:14 PM  wrote:
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Brian Norris
> > Sent: Samstag, 18. Juli 2020 22:52
> > To: openwrt-devel@lists.openwrt.org
> > Cc: Brian Norris 
> > Subject: [RFC PATCH 3/5] image-commands: support Chromium OS image-
> > type creation
> >
> > See the previous patches, which implemented the cros-vbutil verified-boot
> > payload-packing tool, and extended ptgen for the CrOS kernel partition type.
> > With these, it's now possible to package kernel + rootfs to make disk images
> > that can boot a Chrome OS-based system (e.g., Chromebooks, or even a few
> > AP models).
> >
> > gen_image_vboot.sh borrows a bit of structure from gen_image_generic.sh,
> > but I didn't feel it fit well to try and add new flags to the latter, given 
> > the
> > difference in its FAT kernel packaging and our raw kernel partition packing.
> >
> > Signed-off-by: Brian Norris 
> > ---
> >  include/image-commands.mk  | 17 +
> > scripts/gen_image_vboot.sh | 29 +
> >  2 files changed, 46 insertions(+)
> >  create mode 100755 scripts/gen_image_vboot.sh
> >
> > diff --git a/include/image-commands.mk b/include/image-commands.mk
> > index e7db7128b4ca..ca8e826ffb1e 100644
> > --- a/include/image-commands.mk
> > +++ b/include/image-commands.mk
>
> Why is this added globally and not just for ipq40xx (same for the script)?
>
> Do you plan to use it for other targets?

Great question! Perhaps I should have noted that in the cover letter a
little more explicitly -- I noted that these image-generation commands
are applicable to all Chrome OS based devices (Chromebooks, etc.), but
there's one device in particular that may be quite relevant: Google
OnHub. It's got an IPQ8064 SoC running a Chrome OS stack, and I hear
there are some others who may be interested in porting to it too. I
don't have immediate plans to do that myself though, and if it's
preferred to start ipq40xx-local and move later if needed, I can do
that too.

Brian

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

[RFC PATCH 2/5] firmware-utils/cros-vbutil: add Chrome OS vboot kernel-signing utility

[Brian Norris]

Chrom{ium,e} OS based devices use a Coreboot+Depthcharge-based firmware,
which verifies and loads a kernel packed in a verified-boot payload. The
verification tooling (both for creating and verifying payloads) is
implemented here:

https://chromium.googlesource.com/chromiumos/platform/vboot_reference

Devices running such bootloaders also tend to support a "developer
mode," where a device can be unlocked to run arbitrary kernel payloads,
using the same verified-boot format plus well-known developer keys. More
information can be found here:

https://chromium.googlesource.com/chromiumos/docs/+/master/developer_mode.md

Rather than build and package the vboot_reference utilities as part of
the base OpenWRT tools, I chose to reimplement just the portion that's
required for signing payloads. I also embed the developer key directly
in the source for convenience, though it's certainly possible to
provide other keys too, if one were to build their own firmware that
accepts it.

This tool is essentially the same as running something like this, using
the Chromium OS tooling:

  vbutil_kernel --pack kernel_partition.bin \
   --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
   --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
   --version 1 \
   --vmlinuz kernel.bin \
   --bootloader zero.txt \
   --config commnad_line.txt \
   --arch ${ARCH}

I have also packaged the Chromium OS vboot_reference tooling for the
packages feed, as it can be useful beyond simply creating a bootable
image (e.g., manipulating Chromium OS specific GPT attributes, handling
other NVRAM attributes, vboot packing/unpacking/verifying):
https://github.com/openwrt/packages/pull/12829

The vboot_reference tools are released by Google under a BSD 3-clause
license. I've provided the original license text as well as a GPL-2
notice for my modifications (essentially just borrowing the data
structures and rewriting everything else).

Signed-off-by: Brian Norris 
---
 tools/firmware-utils/Makefile  |   1 +
 tools/firmware-utils/src/cros-vbutil.c | 609 +
 2 files changed, 610 insertions(+)
 create mode 100644 tools/firmware-utils/src/cros-vbutil.c

diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index 3dd9ac5c2cc1..8216c97e9cfc 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -29,6 +29,7 @@ define Host/Compile
$(call cc,buffalo-enc buffalo-lib,-Wall)
$(call cc,buffalo-tag buffalo-lib,-Wall)
$(call cc,buffalo-tftp buffalo-lib,-Wall)
+   $(call cc,cros-vbutil,-lcrypto -lpthread)
$(call cc,dgfirmware)
$(call cc,dgn3500sum,-Wall)
$(call cc,dns313-header,-Wall)
diff --git a/tools/firmware-utils/src/cros-vbutil.c 
b/tools/firmware-utils/src/cros-vbutil.c
new file mode 100644
index ..2040c5901985
--- /dev/null
+++ b/tools/firmware-utils/src/cros-vbutil.c
@@ -0,0 +1,609 @@
+/*
+ * cros-vbutil - Tool for signing kernels using the Chromium OS verified boot
+ * format, using widely-shared "developer" keys. The output of this tool is
+ * intended to be written to a GPT partition of type "Chrome OS Kernel", such
+ * that a Chromium OS bootloader can find it.
+ *
+ * Much of this is adapted from Google's vboot_reference project found here:
+ *   https://chromium.googlesource.com/chromiumos/platform/vboot_reference
+ *
+ * Copyright (c) 2010 The Chromium OS Authors. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Google Inc. nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF A

[RFC PATCH 5/5] ipq40xx: add target for Google WiFi (Gale)

[Brian Norris]

Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
In its stock configuration, it runs a Chromium OS-based system, but you
wouldn't know it, since you can only manage it via a "cloud" +
mobile-app system.

The "v2" label is coded into the bootloader, which prefers the
"google,gale-v2" compatible string. I believe "v1" must have been
pre-release hardware.

Note: this is *not* the Google Nest WiFi, released in 2019.

I include "factory.bin" support, where we generate a GPT-based disk
image with 2 partitions -- a kernel partition (using the custom "Chrome
OS kernel" GUID type) and a root filesystem partition. If the AP is in
Developer Mode, the stock bootloader can boot it via a USB disk or
(after gaining access via USB boot) flashed to the eMMC.

Sysupgrade also seems to work OK, although I've omitted some of the
(re)partitioning handling. I also hard-code /dev/mmcblk0 -- while MMC
device numbering can technically change, there's no other MMC controller
present (e.g., no SD card slot).

"FEATURES=boot-part rootfs-part" is required to get kernel and rootfs
partition sizes established. This adds extra (unused) configuration
parameters for other ipq40xx targets, so I'm not sure if this is the
"right" thing to do either.

Features I have tested:

 * Ethernet, both WAN and LAN ports
 * eMMC
 * USB-C (hub, power-delivery, peripherals)
 * LED0 (R/G/B)
 * WiFi (limited testing)
 * SPI flash
 * Serial console: once in developer mode, console can be accessed via
   the USB-C port with SuzyQable, or other similar "Closed Case
   Debugging" tools:
 
https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/ccd.md#suzyq-suzyqable

Not tested:

 * TPM
 * LED1, LED2: I'm not even confident they are actually populated
   anywhere

Known not working:

 * Reboot: this seems to require some additional TrustZone / SCM
   configuration; with additional local patches, I have this working,
   but I'm still trying to figure out exactly the right way I should
   integrate this. Ideally, I could propose it upstream, instead of just
   adding a custom OpenWRT patch. Without this patch, reboot just hangs
   the system. (NB: I've found at least one other user report of this on
   an "IPQ4019" device, but I don't know yet if that's the same.)
 * There's a single external button, and a few useful internal GPIO
   switches. I haven't hooked them up.

Much of the DTS is pulled from the Chrome OS kernel 3.18 branch, which
the manufacturer image uses.

Note: the manufacturer bootloader knows how to patch in calibration data
via the wifi{0,1} aliases in the DTB, so while these properties aren't
present in the DTS, they are available at runtime:

  # ls -l
/sys/firmware/devicetree/base/soc/wifi@a*/qcom,ath10k-pre-calibration-data
  -r--r--r--1 root root 12064 Jul 15 19:11 
/sys/firmware/devicetree/base/soc/wifi@a00/qcom,ath10k-pre-calibration-data
  -r--r--r--1 root root 12064 Jul 15 19:11 
/sys/firmware/devicetree/base/soc/wifi@a80/qcom,ath10k-pre-calibration-data

Ethernet MAC addresses are similarly patched in via the ethernet{0,1} aliases.

Signed-off-by: Brian Norris 
---
 target/linux/ipq40xx/Makefile |   2 +-
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../base-files/lib/upgrade/platform.sh|  13 +
 .../arm/boot/dts/qcom-ipq4019-gale-v2.dts | 402 ++
 target/linux/ipq40xx/image/Makefile   |  14 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 6 files changed, 433 insertions(+), 2 deletions(-)
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gale-v2.dts

diff --git a/target/linux/ipq40xx/Makefile b/target/linux/ipq40xx/Makefile
index 94b47c4c96de..c114df620d5c 100644
--- a/target/linux/ipq40xx/Makefile
+++ b/target/linux/ipq40xx/Makefile
@@ -3,7 +3,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=ipq40xx
 BOARDNAME:=Qualcomm Atheros IPQ40XX
-FEATURES:=squashfs fpu ramdisk nand
+FEATURES:=squashfs fpu ramdisk nand boot-part rootfs-part
 CPU_TYPE:=cortex-a7
 CPU_SUBTYPE:=neon-vfpv4
 SUBTARGETS:=generic
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 61d02a17bcc9..f6b2f47e6ce6 100755
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -38,6 +38,7 @@ ipq40xx_setup_interfaces()
;;
asus,map-ac2200|\
cilab,meshpoint-one|\
+   google,gale-v2|\
openmesh,a42|\
openmesh,a62)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
diff --git a/target/linux/ipq40xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ipq40xx/base-files/lib/upgrade/platform.sh
index 5b

[RFC PATCH 1/5] firmware-utils/ptgen: add Chromium OS kernel partition support

[Brian Norris]

Chrom{ium,e} OS (shortened as "CrOS") bootloaders use a custom GPT
partition type to locate their kernel(s), with custom attributes for
noting properties around which partition(s) should be active and how
many times they've been tried as part of their A/B in-place upgrade
system.

OpenWRT doesn't use A/B updates for upgrades (instead, just shutting
things down far enough to reprogram the necessary partitions), so all we
need to do is tell the bootloader which one is the kernel partition, and
how to use it (i.e., set the "successful" and "priority" attributes).

ptgen already supports some basic GPT partition creation, so just
add support for a '-T ' argument. Currently, this
only supports '-T cros_kernel', but it could be extended if there are
other GPT partition types needed.

For GPT attribute and GUID definitions, see the CrOS verified boot
sources:

https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/lib/cgptlib/include/cgptlib_internal.h
https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/include/gpt.h

The GUID is also recognized in fdisk, and likely other utilities, but
creation/manipulation is typically done via the 'cgpt' utility, provided
as part of the vboot_reference project.

Signed-off-by: Brian Norris 
---
 tools/firmware-utils/src/ptgen.c | 39 +---
 1 file changed, 36 insertions(+), 3 deletions(-)

diff --git a/tools/firmware-utils/src/ptgen.c b/tools/firmware-utils/src/ptgen.c
index 223ee295611f..bc1da6d64061 100644
--- a/tools/firmware-utils/src/ptgen.c
+++ b/tools/firmware-utils/src/ptgen.c
@@ -80,6 +80,10 @@ typedef struct {
GUID_INIT( 0x21686148, 0x6449, 0x6E6F, \
0x74, 0x4E, 0x65, 0x65, 0x64, 0x45, 0x46, 0x49)
 
+#define GUID_PARTITION_CHROME_OS_KERNEL \
+   GUID_INIT( 0xFE3A2A5D, 0x4F32, 0x41A7, \
+   0xB7, 0x25, 0xAC, 0xCC, 0x32, 0x85, 0xA3, 0x09)
+
 #define GPT_HEADER_SIZE 92
 #define GPT_ENTRY_SIZE  128
 #define GPT_ENTRY_MAX   128
@@ -109,6 +113,9 @@ struct partinfo {
unsigned long start;
unsigned long size;
int type;
+   bool has_gtype;
+   guid_t gtype;  /* GPT partition type */
+   uint64_t gattr;  /* GPT partition attributes */
 };
 
 /* GPT Partition table header */
@@ -248,6 +255,19 @@ static inline int guid_parse(char *buf, guid_t *guid)
return 0;
 }
 
+/* Map GPT partition types to partition GUIDs. */
+static inline bool parse_gpt_parttype(const char *type, struct partinfo *part)
+{
+   if (!strcmp(type, "cros_kernel")) {
+   part->has_gtype = true;
+   part->gtype = GUID_PARTITION_CHROME_OS_KERNEL;
+   part->gattr = (1ULL << 48) |  /* priority=1 */
+ (1ULL << 56);  /* success=1 */
+   return true;
+   }
+   return false;
+}
+
 /* init an utf-16 string from utf-8 string */
 static inline void init_utf16(char *str, uint16_t *buf, unsigned bufsize)
 {
@@ -396,12 +416,15 @@ static int gen_gptable(uint32_t signature, guid_t guid, 
unsigned nr)
gpte[i].end = cpu_to_le64(sect -1);
gpte[i].guid = guid;
gpte[i].guid.b[sizeof(guid_t) -1] += i + 1;
-   if (parts[i].type == 0xEF || (i + 1) == (unsigned)active) {
+   if (parts[i].has_gtype) {
+   gpte[i].type = parts[i].gtype;
+   } else if (parts[i].type == 0xEF || (i + 1) == 
(unsigned)active) {
gpte[i].type = GUID_PARTITION_SYSTEM;
init_utf16("EFI System Partition", (uint16_t 
*)gpte[i].name, GPT_ENTRY_NAME_SIZE / sizeof(uint16_t));
} else {
gpte[i].type = GUID_PARTITION_BASIC_DATA;
}
+   gpte[i].attr = parts[i].gattr;
 
if (verbose)
fprintf(stderr, "Partition %d: start=%" PRIu64 ", 
end=%" PRIu64 ", size=%"  PRIu64 "\n",
@@ -498,7 +521,9 @@ fail:
 
 static void usage(char *prog)
 {
-   fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h  -s  -o 
 [-a 0..4] [-l ] [-G ] [[-t ] -p 
[@]...] \n", prog);
+   fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h  -s  -o 
\n"
+   "  [-a 0..4] [-l ] [-G ]\n"
+   "  [[-t  | -T ] -p 
[@]...] \n", prog);
exit(EXIT_FAILURE);
 }
 
@@ -512,7 +537,7 @@ int main (int argc, char **argv)
guid_t guid = GUID_INIT( signature, 0x2211, 0x4433, \
0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0x00);
 
-   while ((ch = getopt(argc, argv, "h:s:p:a:t:o:vngl:S:G:")) != -1) {
+   while ((ch = getopt(argc, argv, "h:s:p:a:t:T:o:vngl:S:G:")) != -1) {
 

[RFC PATCH 0/5] Add support for Chromium OS and Google WiFi

[Brian Norris]

Hi,

This series adds support for both Chromium OS (or particularly, its
kernel-payload signing and disk layout) and for a device using it (the
first generation Google WiFi).

Google WiFi (code-named "Gale") is an IPQ4019-based AP. Its hardware is
decently supported by the existing ipq40xx target -- see patch 5 for
more notes. Notably missing: reboot does not work properly -- I have
some separate TrustZone/SCM-related patches I'd like to clean up to
enable this later.

The "RFC" is mostly for the first part of the series: supporting the
verified boot payload utilities and disk layout needed for building
images that can be booted by Gale's bootloader (or by other Chromium OS
systems).

Chromium OS (the open-source OS on which Google builds its Chrome OS) --
"CrOS" for short -- typically boots via Coreboot, plus Depthcharge as a
second stage. Such bootloaders utilize a verified boot toolkit [1] to
verify each subsequent stage. Of note:

 1. The kernel should be placed in a GPT partition with a custom "Chrome
OS kernel" GUID type and a few custom flags (to manage the A/B
OS updates employed by Chromium OS). CrOS vboot provides the `cgpt`
utility for creating and managing such partitions.
 2. That partition should hold a vboot payload, signed and packaged per
the format documented and implemented at [1]. Using the vboot
utilities, this involves the `vbutil_kernel --pack ...` command.

My main questions are:

 (a) How should we establish this custom partition layout (i.e., #1)? In
 this series, I extend OpenWRT's ptgen to help customize partition
 types, instead of packaging vboot's `cgpt`.
 (b) How should we package and sign kernels (#2)? In this series, I
 adapt and reimplement the `vbutil_kernel` command as a custom
 `cros-vbutil` utility, rather than packaging Google's utility.
 (c) How should this integrate into the ipq40xx target? In this series,
 I add kernel and rootfs partition-size parameters, but it's not
 clear to me if this fits well into the existing ipq40xx target, or
 if it should be done differently.

For some alternatives (especially on (b)), I did package
futility/vbutil_kernel here:
https://github.com/openwrt/packages/pull/12829
I could adapt this into tools/ instead, so OpenWRT doesn't have to carry
my re-implementation. This would carry some extra build complexity,
as the vboot tools are >10,000 lines of code, compared to my
reimplementation of a few hundred lines. The library dependencies are
similar (mostly just crypto/ssl, and potentially libuuid (for GPT)), as
the vboot project tries to keep the code semi-portable / reusable.

Packaging the vboot utilities might give us some future flexibility, if
the formats grow and change for future systems. So far, I think the
format has been pretty stable. Also, there are potentially some quirks I
missed in my port related the ${ARCH} -- I ported the ARM support, but
there may be some small tweaks I missed that are applicable only to x86
systems.

For (c): adding this to the common ipq40xx target means that there will
be a new CONFIG_TARGET_KERNEL_PARTSIZE and
CONFIG_TARGET_ROOTFS_PARTSIZE, which are only applicable to a single
device but are present for all:
  FEATURES:=boot-part rootfs-part
Is this reason for a new subtarget?

Anyway, this is a working device port as-is, so feel free to take a look
even if you don't have opinions on any of my "RFC" questions!

Regards,
Brian

[1] https://chromium.googlesource.com/chromiumos/platform/vboot_reference

Brian Norris (5):
  firmware-utils/ptgen: add Chromium OS kernel partition support
  firmware-utils/cros-vbutil: add Chrome OS vboot kernel-signing utility
  image-commands: support Chromium OS image-type creation
  ipq40xx: add open-drain support to pinctrl-msm
  ipq40xx: add target for Google WiFi (Gale)

 include/image-commands.mk |  17 +
 scripts/gen_image_vboot.sh|  29 +
 target/linux/ipq40xx/Makefile |   2 +-
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../base-files/lib/upgrade/platform.sh|  13 +
 .../arm/boot/dts/qcom-ipq4019-gale-v2.dts | 402 
 target/linux/ipq40xx/image/Makefile   |  14 +
 .../090-pinctrl-msm-open-drain.patch  |  90 +++
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 tools/firmware-utils/Makefile |   1 +
 tools/firmware-utils/src/cros-vbutil.c| 609 ++
 tools/firmware-utils/src/ptgen.c  |  39 +-
 12 files changed, 1215 insertions(+), 5 deletions(-)
 create mode 100755 scripts/gen_image_vboot.sh
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gale-v2.dts
 create mode 100644 
target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch
 create mode 100644 tools/firmware-utils/src/cros-vbutil.c

-- 
2.27.0


___
openwrt-dev

[RFC PATCH 4/5] ipq40xx: add open-drain support to pinctrl-msm

[Brian Norris]

Submitted upstream. Shouldn't affect existing devices, but enables new
device support.

https://lore.kernel.org/linux-gpio/20200703080646.23233-1-computersforpe...@gmail.com/

Currently queued for-next:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=13355ca35cd16f5024655ac06e228b3c199e52a9

Signed-off-by: Brian Norris 
---
 .../090-pinctrl-msm-open-drain.patch  | 90 +++
 1 file changed, 90 insertions(+)
 create mode 100644 
target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch

diff --git a/target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch 
b/target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch
new file mode 100644
index ..9bb05f32844a
--- /dev/null
+++ b/target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch
@@ -0,0 +1,90 @@
+From 5b08c1d567ee8e6af94696b3e549997cbdb2bb80 Mon Sep 17 00:00:00 2001
+From: Jaiganesh Narayanan 
+Date: Thu, 1 Sep 2016 10:40:38 +0530
+Subject: [PATCH] pinctrl: qcom: ipq4019: add open drain support
+
+Signed-off-by: Jaiganesh Narayanan 
+[ Brian: adapted from from the Chromium OS kernel used on IPQ4019-based
+  WiFi APs. ]
+Signed-off-by: Brian Norris 
+---
+https://lore.kernel.org/linux-gpio/20200703080646.23233-1-computersforpe...@gmail.com/
+
+ drivers/pinctrl/qcom/pinctrl-ipq4019.c |  1 +
+ drivers/pinctrl/qcom/pinctrl-msm.c | 13 +
+ drivers/pinctrl/qcom/pinctrl-msm.h |  2 ++
+ 3 files changed, 16 insertions(+)
+
+diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c 
b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
+index 8bdb5bd393d2..63915cb210ff 100644
+--- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
 b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
+@@ -254,6 +254,7 @@ DECLARE_QCA_GPIO_PINS(99);
+   .mux_bit = 2,   \
+   .pull_bit = 0,  \
+   .drv_bit = 6,   \
++  .od_bit = 12,   \
+   .oe_bit = 9,\
+   .in_bit = 0,\
+   .out_bit = 1,   \
+diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
+index 83b7d64bc4c1..dac0404dadf4 100644
+--- a/drivers/pinctrl/qcom/pinctrl-msm.c
 b/drivers/pinctrl/qcom/pinctrl-msm.c
+@@ -233,6 +233,10 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
+   *bit = g->pull_bit;
+   *mask = 3;
+   break;
++  case PIN_CONFIG_DRIVE_OPEN_DRAIN:
++  *bit = g->od_bit;
++  *mask = 1;
++  break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   *bit = g->drv_bit;
+   *mask = 7;
+@@ -310,6 +314,12 @@ static int msm_config_group_get(struct pinctrl_dev 
*pctldev,
+   if (!arg)
+   return -EINVAL;
+   break;
++  case PIN_CONFIG_DRIVE_OPEN_DRAIN:
++  /* Pin is not open-drain */
++  if (!arg)
++  return -EINVAL;
++  arg = 1;
++  break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   arg = msm_regval_to_drive(arg);
+   break;
+@@ -382,6 +392,9 @@ static int msm_config_group_set(struct pinctrl_dev 
*pctldev,
+   else
+   arg = MSM_PULL_UP;
+   break;
++  case PIN_CONFIG_DRIVE_OPEN_DRAIN:
++  arg = 1;
++  break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   /* Check for invalid values */
+   if (arg > 16 || arg < 2 || (arg % 2) != 0)
+diff --git a/drivers/pinctrl/qcom/pinctrl-msm.h 
b/drivers/pinctrl/qcom/pinctrl-msm.h
+index 9452da18a78b..dc7f8c84744b 100644
+--- a/drivers/pinctrl/qcom/pinctrl-msm.h
 b/drivers/pinctrl/qcom/pinctrl-msm.h
+@@ -38,6 +38,7 @@ struct msm_function {
+  * @mux_bit:  Offset in @ctl_reg for the pinmux function 
selection.
+  * @pull_bit: Offset in @ctl_reg for the bias configuration.
+  * @drv_bit:  Offset in @ctl_reg for the drive strength 
configuration.
++ * @od_bit:   Offset in @ctl_reg for controlling open drain.
+  * @oe_bit:   Offset in @ctl_reg for controlling output enable.
+  * @in_bit:   Offset in @io_reg for the input bit value.
+  * @out_bit:  Offset in @io_reg for the output bit value.
+@@ -75,6 +76,7 @@ struct msm_pingroup {
+   unsigned pull_bit:5;
+   unsigned drv_bit:5;
+ 
++  unsigned od_bit:5;
+   unsigned oe_bit:5;
+   unsigned in_bit:5;
+   unsigned out_bit:5;
+-- 
+2.17.1
+
-- 
2.27.0


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

[RFC PATCH 3/5] image-commands: support Chromium OS image-type creation

[Brian Norris]

See the previous patches, which implemented the cros-vbutil
verified-boot payload-packing tool, and extended ptgen for the CrOS
kernel partition type. With these, it's now possible to package kernel +
rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
Chromebooks, or even a few AP models).

gen_image_vboot.sh borrows a bit of structure from gen_image_generic.sh,
but I didn't feel it fit well to try and add new flags to the latter,
given the difference in its FAT kernel packaging and our raw kernel
partition packing.

Signed-off-by: Brian Norris 
---
 include/image-commands.mk  | 17 +
 scripts/gen_image_vboot.sh | 29 +
 2 files changed, 46 insertions(+)
 create mode 100755 scripts/gen_image_vboot.sh

diff --git a/include/image-commands.mk b/include/image-commands.mk
index e7db7128b4ca..ca8e826ffb1e 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -164,6 +164,23 @@ define Build/fit
@mv $@.new $@
 endef
 
+define Build/cros-image
+   $(SCRIPT_DIR)/gen_image_vboot.sh \
+ $@ \
+ $(CONFIG_TARGET_KERNEL_PARTSIZE) $(IMAGE_KERNEL) \
+ $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(IMAGE_ROOTFS)
+endef
+
+# NB: Chrome OS bootloaders replace the '%U' in command lines with the UUID of
+# the kernel partition it chooses to boot from. This gives a flexible way to
+# consistently build and sign kernels that always use the subsequent
+# (PARTNROFF=1) partition as their rootfs.
+define Build/cros-vboot
+   $(STAGING_DIR_HOST)/bin/cros-vbutil \
+   -k $@ -c "root=PARTUUID=%U/PARTNROFF=1" -o $@.new
+   @mv $@.new $@
+endef
+
 define Build/lzma
$(call Build/lzma-no-dict,-lc1 -lp2 -pb2 $(1))
 endef
diff --git a/scripts/gen_image_vboot.sh b/scripts/gen_image_vboot.sh
new file mode 100755
index ..acded33de654
--- /dev/null
+++ b/scripts/gen_image_vboot.sh
@@ -0,0 +1,29 @@
+#!/usr/bin/env bash
+# Copyright (C) 2020 OpenWrt.org
+set -e -x
+[ $# == 5 ] || {
+echo "SYNTAX: $0 "
+exit 1
+}
+
+OUTPUT="$1"
+KERNELSIZE="$2"
+KERNELIMAGE="$3"
+ROOTFSSIZE="$4"
+ROOTFSIMAGE="$5"
+
+rm -f "${OUTPUT}"
+
+head=16
+sect=63
+
+# create partition table
+set $(ptgen -o "$OUTPUT" -h $head -s $sect -g -T cros_kernel -p ${KERNELSIZE}m 
-p ${ROOTFSSIZE}m)
+
+KERNELOFFSET="$(($1 / 512))"
+KERNELSIZE="$2"
+ROOTFSOFFSET="$(($3 / 512))"
+ROOTFSSIZE="$(($4 / 512))"
+
+dd if="${KERNELIMAGE}" of="${OUTPUT}" bs=512 seek="${KERNELOFFSET}" 
conv=notrunc
+dd if="${ROOTFSIMAGE}" of="${OUTPUT}" bs=512 seek="${ROOTFSOFFSET}" 
conv=notrunc
-- 
2.27.0


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

Re: [PATCH] ipq40xx: add open-drain support to pinctrl-msm

[Brian Norris]

On Fri, Jul 17, 2020 at 1:59 AM Petr Štetiar  wrote:
> Or is there any other valid reason I'm missing right now?

I put my main reason in the original email:
"Submitting this separately, partly because the device-support patches
are a bit bigger and likely will take a little work."

Particularly, the device in question uses some new disk layout and
kernel packaging that's not yet supported in OpenWRT, and there are
likely some questions to be resolved there. I figured the more obvious
stuff (like this) could go separately.

But I can just keep this in the device-support series, since that
appears to be your preference. Stay tuned.

Regards,
Brian

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

[PATCH] ipq40xx: add open-drain support to pinctrl-msm

[Brian Norris]

Submitted upstream. Shouldn't affect existing devices, but enables new
device support.

https://lore.kernel.org/linux-gpio/20200703080646.23233-1-computersforpe...@gmail.com/

Currently queued for-next:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=13355ca35cd16f5024655ac06e228b3c199e52a9

Signed-off-by: Brian Norris 
---
Submitting this separately, partly because the device-support patches
are a bit bigger and likely will take a little work.

 .../090-pinctrl-msm-open-drain.patch  | 90 +++
 1 file changed, 90 insertions(+)
 create mode 100644 
target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch

diff --git a/target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch 
b/target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch
new file mode 100644
index ..9bb05f32844a
--- /dev/null
+++ b/target/linux/ipq40xx/patches-5.4/090-pinctrl-msm-open-drain.patch
@@ -0,0 +1,90 @@
+From 5b08c1d567ee8e6af94696b3e549997cbdb2bb80 Mon Sep 17 00:00:00 2001
+From: Jaiganesh Narayanan 
+Date: Thu, 1 Sep 2016 10:40:38 +0530
+Subject: [PATCH] pinctrl: qcom: ipq4019: add open drain support
+
+Signed-off-by: Jaiganesh Narayanan 
+[ Brian: adapted from from the Chromium OS kernel used on IPQ4019-based
+  WiFi APs. ]
+Signed-off-by: Brian Norris 
+---
+https://lore.kernel.org/linux-gpio/20200703080646.23233-1-computersforpe...@gmail.com/
+
+ drivers/pinctrl/qcom/pinctrl-ipq4019.c |  1 +
+ drivers/pinctrl/qcom/pinctrl-msm.c | 13 +
+ drivers/pinctrl/qcom/pinctrl-msm.h |  2 ++
+ 3 files changed, 16 insertions(+)
+
+diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c 
b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
+index 8bdb5bd393d2..63915cb210ff 100644
+--- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
 b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
+@@ -254,6 +254,7 @@ DECLARE_QCA_GPIO_PINS(99);
+   .mux_bit = 2,   \
+   .pull_bit = 0,  \
+   .drv_bit = 6,   \
++  .od_bit = 12,   \
+   .oe_bit = 9,\
+   .in_bit = 0,\
+   .out_bit = 1,   \
+diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
+index 83b7d64bc4c1..dac0404dadf4 100644
+--- a/drivers/pinctrl/qcom/pinctrl-msm.c
 b/drivers/pinctrl/qcom/pinctrl-msm.c
+@@ -233,6 +233,10 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
+   *bit = g->pull_bit;
+   *mask = 3;
+   break;
++  case PIN_CONFIG_DRIVE_OPEN_DRAIN:
++  *bit = g->od_bit;
++  *mask = 1;
++  break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   *bit = g->drv_bit;
+   *mask = 7;
+@@ -310,6 +314,12 @@ static int msm_config_group_get(struct pinctrl_dev 
*pctldev,
+   if (!arg)
+   return -EINVAL;
+   break;
++  case PIN_CONFIG_DRIVE_OPEN_DRAIN:
++  /* Pin is not open-drain */
++  if (!arg)
++  return -EINVAL;
++  arg = 1;
++  break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   arg = msm_regval_to_drive(arg);
+   break;
+@@ -382,6 +392,9 @@ static int msm_config_group_set(struct pinctrl_dev 
*pctldev,
+   else
+   arg = MSM_PULL_UP;
+   break;
++  case PIN_CONFIG_DRIVE_OPEN_DRAIN:
++  arg = 1;
++  break;
+   case PIN_CONFIG_DRIVE_STRENGTH:
+   /* Check for invalid values */
+   if (arg > 16 || arg < 2 || (arg % 2) != 0)
+diff --git a/drivers/pinctrl/qcom/pinctrl-msm.h 
b/drivers/pinctrl/qcom/pinctrl-msm.h
+index 9452da18a78b..dc7f8c84744b 100644
+--- a/drivers/pinctrl/qcom/pinctrl-msm.h
 b/drivers/pinctrl/qcom/pinctrl-msm.h
+@@ -38,6 +38,7 @@ struct msm_function {
+  * @mux_bit:  Offset in @ctl_reg for the pinmux function 
selection.
+  * @pull_bit: Offset in @ctl_reg for the bias configuration.
+  * @drv_bit:  Offset in @ctl_reg for the drive strength 
configuration.
++ * @od_bit:   Offset in @ctl_reg for controlling open drain.
+  * @oe_bit:   Offset in @ctl_reg for controlling output enable.
+  * @in_bit:   Offset in @io_reg for the input bit value.
+  * @out_bit:  Offset in @io_reg for the output bit value.
+@@ -75,6 +76,7 @@ struct msm_pingroup {
+   unsigned pull_bit:5;
+   unsigned drv_bit:5;
+ 
++  unsigned od_bit:5;
+   unsigned oe_bit:5;
+   unsigned in_bit:5;
+   unsigned out_bit:5;
+-- 
+2.17.1
+
-- 
2.27.0


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

[PATCH] scripts/feeds: warn when skipping core package override

[Brian Norris]

Otherwise, a n00b like myself can get quite confused when moving a
package from core to feeds, for example.

(Hint: one *really* needs to clear out the tmp/info/.packageinfo...
entries for the stale package, but '-f' works as well.)

Signed-off-by: Brian Norris 
---
 scripts/feeds | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/feeds b/scripts/feeds
index 69ab60278a1a..dc2b91266dcd 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -536,7 +536,10 @@ sub install_src {
# If it's a core package and we don't want to override, just return
my $override = 0;
if (is_core_src($name)) {
-   return 0 unless $force;
+   if (!$force) {
+   warn "Not overriding core package $name; use -f to 
force\n";
+   return 0;
+   }
$override = 1;
}
 
-- 
2.17.1


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