Re: Commit "mt76: update to Git HEAD (2024-09-29)" causing warning on missing dependency on kmod-mt7996

[Felix Fietkau]

On 29.09.24 19:43, Bas Mevissen wrote:

Hi,

The commit "mt76: update to Git HEAD (2024-09-29)"
(2f7d22dc6fbb9532b82522c4a78434a07f9d8fb1) causes the following warning
to be introduced:



WARNING: Makefile 'package/kernel/mt76/Makefile' has a dependency on 
'kmod-mt7996', which does not exist


This is due to the following snippet:


diff --git a/package/kernel/mt76/Makefile b/package/kernel/mt76/Makefile
index 4d808c96b3..872dec0e76 100644
--- a/package/kernel/mt76/Makefile
+++ b/package/kernel/mt76/Makefile
@@ -8,9 +8,9 @@ PKG_LICENSE_FILES:=

   PKG_SOURCE_URL:=https://github.com/openwrt/mt76
   PKG_SOURCE_PROTO:=git
-PKG_SOURCE_DATE:=2024-09-05
-PKG_SOURCE_VERSION:=65cc3daf2a332cc658e9f7438cdadde4392e672e
-PKG_MIRROR_HASH:=c29c4f883051a6360119156a03e010ac11573011b23d9e873f83c720600970e7
+PKG_SOURCE_DATE:=2024-09-29
+PKG_SOURCE_VERSION:=680bc70f161fde0f167e2ae50c771be4775eb50a
+PKG_MIRROR_HASH:=bcdb95e40cfceba56a565ad6b6d9f92a122e7230d0f7f950b3d39e4280723cca

   PKG_MAINTAINER:=Felix Fietkau 
   PKG_USE_NINJA:=0
@@ -323,10 +323,34 @@ define KernelPackage/mt7996e
 AUTOLOAD:=$(call AutoProbe,mt7996e)
   endef

+define KernelPackage/mt7992-firmware
+  $(KernelPackage/mt76-default)
+  TITLE:=MediaTek MT7992 firmware
+  DEPENDS+=+kmod-mt7996
+endef

Shouldn't the second last line read "+  DEPENDS+=+kmod-mt7996e" instead?


You're right, I wonder why my build test didn't catch it.
Fixed now, thanks.

- Felix

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

Re: Re: [PATCH 2/2] treewide: remove INITRAMFS check for preinit_main hook

[Elliott Mitchell]

On Thu, Sep 26, 2024 at 08:14:45AM +0200, Florian Eckert wrote:
> 
> Any progress on this Subject?
> Maybe you missed it, but I have sent a reworked patch [1].

> [1] 
> https://patchwork.ozlabs.org/project/openwrt/patch/20240910141839.3433214-1...@dev.tdt.de/

Sorry, missed this; alas I do tend to drop things.  Note, I am a
community reviewer and so cannot bring anything into OpenWRT's tree
myself.

I like this approach far better.  Problem is you've missed a number of
scripts which are effected by the change.  Of note:

package/base-files/files/lib/preinit/99_10_failsafe_login
package/system/urandom-seed/files/lib/preinit/81_urandom_seed

You can place a note under the "---" after the "Signed-off-by" line.
This can be used for statements such as those two were examined and
aren't effected by the change.  There are also a bunch of other files
which may interact:

find target/linux -name preinit -print | while read d
do  find "$d" -mindepth 1 -name \[7-~\]\* -print
done


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



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

Re: [PATCH] mpc85xx: Add support for HP MSM466 (J9622A)

[Evan Jobling via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> Reviewed-by: Rosen Penev 
Thanks Rosen!
>
> Any chance to test https://github.com/openwrt/openwrt/pull/16248 ?

What output do you need?

Can confirm that mac addresses are the same as before.

WiFi LED's appear to break.

Cheers,
Evan.

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

Re: [PATCH] mpc85xx: Add support for HP MSM466 (J9622A)

[Rosen Penev]

On Wed, Sep 25, 2024 at 11:05 PM Evan Jobling via openwrt-devel
 wrote:
>
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> -- Forwarded message --
> From: Evan Jobling 
> To: openwrt-devel 
> Cc:
> Bcc:
> Date: Thu, 26 Sep 2024 16:04:15 +1000
> Subject: [PATCH] mpc85xx: Add support for HP MSM466 (J9622A)
> Hardware details:
> Identical in radios and mainboard to MSM460.
> This model features 6x RP-SMA rather
> than internal antennas.
>
> Approved antennas have varied gains ranging
> from 1.5dBi to 13.5dBi.
>
> Installation instructions:
> Identical to MSM460.
> To differentiate between board numbers
> after flashing check in Colubris BID
> partition at 0x0001f997.
> For example: J9622-60001.
>
> Known issues:
> J9621A and J9620A should be identical but
> are untested.
>
> After flashing, transmit power limits are
> 23dBm in 2.4GHz, 18dBm in 5GHz.
> Factory is 20dBm in both bands for both
> radios.
>
> Factory left it to the user to consider
> transmit power, antenna gain and channel
> selection, given the approval for indoor
> and outdoor antennas of various gains.
>
> Signed-off-by: Evan Jobling 
Reviewed-by: Rosen Penev 

Any chance to test https://github.com/openwrt/openwrt/pull/16248 ?
> ---
>  target/linux/mpc85xx/image/p1020.mk | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/target/linux/mpc85xx/image/p1020.mk 
> b/target/linux/mpc85xx/image/p1020.mk
> index c310b26c87..c0e7885ad4 100644
> --- a/target/linux/mpc85xx/image/p1020.mk
> +++ b/target/linux/mpc85xx/image/p1020.mk
> @@ -94,6 +94,8 @@ TARGET_DEVICES += extreme-networks_ws-ap3825i
>  define Device/hpe_msm460
>DEVICE_VENDOR := Hewlett-Packard
>DEVICE_MODEL := MSM460
> +  DEVICE_ALT0_VENDOR := Hewlett-Packard
> +  DEVICE_ALT0_MODEL := MSM466
>KERNEL = kernel-bin | fit none $(KDIR)/image-$$(DEVICE_DTS).dtb
>KERNEL_NAME := zImage.la300
>KERNEL_ENTRY := 0x300
> --
> 2.39.5
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: Wireless config file design proposal for multi-radio wiphy

[Felix Fietkau]

Hi Harshitha,

On 26.09.24 07:14, Harshitha Prem wrote:

Hi Team,

The MLO interface requires support for multi-radio wiphy and we would
like to propose the following design for the wireless configuration file
to accommodate multi-radio wiphy. For the multi-radio wireless
configuration, we could use Wi-Fi devices named as radio0_band0,
radio0_band1, etc. This naming convention would be helpful for hardware
that includes a combination of one multi-radio capable wiphy
(radio0_band0, radio0_band1) and one non-multi-radio wiphy (radio1).

Sample multi-radio wireless configuration file:

config wifi-device  radio0
  option type mac80211
  option channel  11
  option hwmode   11g
  option htmode   HT20
  # REMOVE THIS LINE TO ENABLE WIFI:
  option disabled 1
config wifi-iface
  option device   radio0
  option network  lan
  option mode ap
  option ssid OpenWrt
  option encryption  none
config wifi-device  radio1_band0
  option type mac80211
  option channel  36
  option hwmode   11a
  option htmode   VHT80
  # REMOVE THIS LINE TO ENABLE WIFI:
  option disabled 1
  option country US
config wifi-iface
  option device   radio1_band0
  option network  lan
  option mode ap
  option ssid OpenWrt
  option encryption  none
config wifi-device  radio1_band1
  option type mac80211
  option channel  49
  option hwmode   11a
  option band 3
  option htmode   HE80
  # REMOVE THIS LINE TO ENABLE WIFI:
  option disabled 1
config wifi-iface
  option device   radio1_band1
  option network  lan
  option mode ap
  option ssid OpenWrt
  option encryption  sae
  option sae_pwe  1
  option key  0123456789

To configure a IEEE802.11be Multi-link Interface (MLD VAP), we could use
options such as mld in each wifi-iface section which are part of MLD and
introduce a new wireless configuration section, wifi-mld. This allows us
to couple multiple links together under a single interface and any ML
specific configurations could be updated under this section.

Please find the sample ML interface configuration below:


I have a different plan for supporting MLD already. In my staging tree, 
I've been working on user space code for using the multi-radio wiphy 
support that I added to cfg80211/mac80211.
The idea is to still have multiple wifi-device sections (like on your 
proposal), but with an option radio  matching the wiphy radio index.
The code will use my work-in-progress code for setting allowed radios 
for each vif.


The next step (which I have not implemented yet) is to turn the device 
option for a wifi-iface into a list, so that the same SSID can be 
brought up on multiple radios without duplicating the section.
That should be supported for both MLD and non-MLD configurations, adding 
an extra option to enable MLD for the SSID.


I want to retain the ability to bring individual wifi devices up and 
down via the wifi command and make the hostapd ucode script responsible 
for adding/removing MLD links accordingly.


I can go into more detail once I've made more progress with the code.
The next step for me is to rework the vif-allowed-radios code based on 
feedback from Johannes and to complete the single-wiphy support for 
legacy mode. After that I will move on to MLD.


- Felix

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

Re: [PATCH 04/11] base-files: uci-defaults: allow setting the number of MACs a radio can use

[John Crispin]

On 24.09.24 12:53, Andreas Gnau wrote:


Not a WiFi-expert, but: How will this band parameter work for WiFi 7 
MLO where a single-phy device can represent multiple bands?


How would we deal with devices having more than one radio per band? 
For example, some repeaters have a separate radio for backhaul and 
fronthaul.



+    local mac_count="$2"


Out of interest: How is mac_count to be used in practice? What 
component is enforcing / allocating the MAC addresses? 


there is an UCI option "num_global_macaddr" that can be set for a 
wifi-device. the script code will then know how many consecutive MACs 
can be used for a PHY without using the private bit


MLO will ignore that setting just like multiple_bssid does right now



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

Re: [PATCH 11/11] base-files: set root password if present inside board.json

[John Crispin]

On 24.09.24 11:58, Jo-Philipp Wich wrote:
You should probably just separate the variables into 
`root_password_plain` and `root_password_hash`, then make the latter 
take precedence over the former in case both are defined. 

makes sense

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

Re: [PATCH 09/11] dropbear: add a uci-defaults script for loading authorized keys

[John Crispin]

On 24.09.24 10:47, Bjørn Mork wrote:

John Crispin  writes:


+   echo -n "$ssh_authorized_key" > /etc/dropbear/authorized_keys

This will unnecessarily break an image built with one or more
pre-defined keys.


Bjørn

yeash, I'll check if the file exists and if so do nothing.

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

Re: [PATCH 02/11] base-files: uci-defaults: allow setting default credentials and ssh keys

[John Crispin]

On 24.09.24 09:57, Bjørn Mork wrote:

John Crispin  writes:


+ucidef_set_ssh_authorized_key() {

This should be ucidef_add_ssh_authorized_key() and it should support
being called more than once.

(no, I don't have a use case - just one of my many hangups after having
seen similar things too many times)


good idea, I'll add that


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

Re: [PATCH 04/11] base-files: uci-defaults: allow setting the number of MACs a radio can use

[Andreas Gnau via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2024-09-23 19:18, John Crispin wrote:

Introduce new uci-default functions:
- ucidef_set_wireless_mac_count [count]

Signed-off-by: John Crispin 
---
  .../files/lib/functions/uci-defaults.sh   | 21 +++
  1 file changed, 21 insertions(+)

diff --git a/package/base-files/files/lib/functions/uci-defaults.sh 
b/package/base-files/files/lib/functions/uci-defaults.sh
index 67862497c0..30ae36949e 100644
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -684,6 +684,27 @@ ucidef_set_country() {
json_select ..
  }
  
+ucidef_set_wireless_mac_count() {

+   local band="$1"


Not a WiFi-expert, but: How will this band parameter work for WiFi 7 MLO 
where a single-phy device can represent multiple bands?


How would we deal with devices having more than one radio per band? For 
example, some repeaters have a separate radio for backhaul and fronthaul.



+   local mac_count="$2"


Out of interest: How is mac_count to be used in practice? What component 
is enforcing / allocating the MAC addresses?



+
+   case "$band" in
+   2g|5g|6g) ;;
+   *) return;;
+   esac

> 




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

Re: [PATCH 11/11] base-files: set root password if present inside board.json

[Jo-Philipp Wich]

Hi,


The code checks if the first character is "$". In that case it is assumed
that the string contains a solted hash. Alternatively we assume that it is
a cleartext password.


IMHO that kind of heuristic is undesirable. Imagine a scenario where something 
autogenerates passwords and those happen to start with `$`, the resulting 
configuration would not allow authentication with the expected password.


You should probably just separate the variables into `root_password_plain` and 
`root_password_hash`, then make the latter take precedence over the former in 
case both are defined.


~ Jo



Signed-off-by: John Crispin 
---
  .../files/etc/uci-defaults/50-root-passwd | 15 +++
  1 file changed, 15 insertions(+)
  create mode 100644 package/base-files/files/etc/uci-defaults/50-root-passwd

diff --git a/package/base-files/files/etc/uci-defaults/50-root-passwd 
b/package/base-files/files/etc/uci-defaults/50-root-passwd
new file mode 100644
index 00..a7e5ace913
--- /dev/null
+++ b/package/base-files/files/etc/uci-defaults/50-root-passwd
@@ -0,0 +1,15 @@
+. /usr/share/libubox/jshn.sh
+
+json_init
+json_load "$(cat /etc/board.json)"
+
+json_select credentials
+json_get_vars root_password root_password
+   [ -z "$root_password" ] || {
+   if [ "${root_password:0:1}" == "$" ]; then
+   sed -i "s|^root:[^:]*|root:$root_password|g" /etc/shadow
+   else
+   (echo "$root_password"; sleep 1; echo "$root_password") 
| passwd root
+   fi
+   }
+json_select ..


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

Re: [PATCH 11/11] base-files: set root password if present inside board.json

[Jo-Philipp Wich]

Hi,


The code checks if the first character is "$". In that case it is assumed
that the string contains a solted hash. Alternatively we assume that it is
a cleartext password.


IMHO that kind of heuristic is undesirable. Imagine a scenario where something 
autogenerates passwords and those happen to start with `$`, the resulting 
configuration would not allow authentication with the expected password.


You should probably just separate the variables into `root_password_plain` and 
`root_password_hash`, then make the latter take precedence over the former in 
case both are defined.


~ Jo



Signed-off-by: John Crispin 
---
  .../files/etc/uci-defaults/50-root-passwd | 15 +++
  1 file changed, 15 insertions(+)
  create mode 100644 package/base-files/files/etc/uci-defaults/50-root-passwd

diff --git a/package/base-files/files/etc/uci-defaults/50-root-passwd 
b/package/base-files/files/etc/uci-defaults/50-root-passwd
new file mode 100644
index 00..a7e5ace913
--- /dev/null
+++ b/package/base-files/files/etc/uci-defaults/50-root-passwd
@@ -0,0 +1,15 @@
+. /usr/share/libubox/jshn.sh
+
+json_init
+json_load "$(cat /etc/board.json)"
+
+json_select credentials
+json_get_vars root_password root_password
+   [ -z "$root_password" ] || {
+   if [ "${root_password:0:1}" == "$" ]; then
+   sed -i "s|^root:[^:]*|root:$root_password|g" /etc/shadow
+   else
+   (echo "$root_password"; sleep 1; echo "$root_password") 
| passwd root
+   fi
+   }
+json_select ..


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

Re: [PATCH 09/11] dropbear: add a uci-defaults script for loading authorized keys

[Bjørn Mork via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
John Crispin  writes:

> + echo -n "$ssh_authorized_key" > /etc/dropbear/authorized_keys

This will unnecessarily break an image built with one or more
pre-defined keys.


Bjørn

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

Re: [PATCH 02/11] base-files: uci-defaults: allow setting default credentials and ssh keys

[Bjørn Mork via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
John Crispin  writes:

> +ucidef_set_ssh_authorized_key() {

This should be ucidef_add_ssh_authorized_key() and it should support
being called more than once.

(no, I don't have a use case - just one of my many hangups after having
seen similar things too many times)


Bjørn

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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Evan Jobling via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On 22/9/24 19:50, Bjørn Mork wrote:
 
> I believe that's pretty much it.  If you already have a "cooling-device"
> implementation using the gpio-fan driver, then you just have to extend
> the thermal-zone with cooling-maps and trips.  See
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> 
> The RPi PoE hat device tree overlay is another example of adding a
> cooling-device (fan) into an existing thermal-zone with a sensor:
> 
> https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/overlays/rpi-poe-overlay.dts
> 
> We obviously don't want overlays - just think of it as a device tree
> diff.  And the trip point params are also irrelevant.  AFAICS,
> thermal_of will set THERMAL_TRIP_FLAG_RW_TEMP. So the trip points should
> be configurable from userspace using sysfs.  Unless I'm missing
> something.
> 
> In any case, a fixed high/low setting like OEM is probably good enough
> for most users.

OK thanks. I did some reading on thermal zones trying to find a way to set
default fans. Need to do more reading. Thanks for the heads up.

> 
> I've never written thermal drver either.  There's only one way out of
> that :-)
> 
Okay cool. More reading in my future to do things kernel safe I guess.

> 
> Bjørn


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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Evan Jobling via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Tim!> 
> My thoughts were that the kernel's gpio-init code for that SoC shouldn't 
> reset the gpio state - rather it should leave it in the state that the 
> firmware configured it.  gpio-fan would then do the right thing.

I've read the RTL8231 device driver and  code sets everything to input
to ensure output drivers are always in a valid state.

Commit is 3810e897295cb66bc45a62bc2c0b70a01004fe3b

"realtek: ensure output drivers are enabled in RTL8231"

I guess this is going to require per device patching to restore the
fan (and other?) GPIO state set by the bootloader when initialising RTL8231's?

Still working on it.

> 
> I think the only really "correct" ways to proceed are either to allow user 
> control (defaulting to high speed i.e. delegating the decision), or to 
> re-implement the same fan control algorithm as the OEM firmware does.
> 
> That algorithm could probably be discovered by treating it as a black box 
> (e.g. giving it different PoE power loads, and/or operating temperatures, 
> simulating fan failures etc. and observing behaviour)
> 
> Unfortunately I think that without access to the hardware specs and/or 
> carrying out a lot of hardware characterisation work there is too much 
> guesswork involved in implementing any other algorithm.
I think my laziness will prevail and I'll end up cooking up my own script 
rather than doing the reverse engineering work haha.

Hotbox and loading up with PoE to near max on JG926A isn't out of the realm of 
possibility.
Don't really want to try to run equipment at 40C ambient but I guess that's 
summer here anyway.
Won't be able to get higher than 80W PoE draw on the JG922A with my current 
equipment.

Cheers,
Evan.


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

Re: State of APK package manger integration

[Petr Štetiar]

Paul Spooren  [2024-08-11 20:34:09]:

Hi,

> Some time has passed and there are further news for the APK migration:

awesome progress, thanks a lot to all of you pushing this forward! :-)

> If you run one of those images, please give APK a spin and see how it’s 
> doing. A simple example would b to run the following:

FYI seems like ImageBuilder still needs some love, I've tested both:

 
https://buildbot.aparcar.org/targets/x86/64/openwrt-imagebuilder-x86-64.Linux-x86_64.tar.zst
 
https://downloads.staging.openwrt.org/snapshots/targets/x86/64/openwrt-imagebuilder-x86-64.Linux-x86_64.tar.zst

and they both seems to fail the basic `make image` smoke test:

  $ make image
  Building images for x86 - Generic x86/64
  Packages: apk-mbedtls base-files busybox ca-bundle dnsmasq dropbear e2fsprogs 
firewall4 fstools grub2-bios-setup kernel kmod-amazon-ena kmod-amd-xgbe 
kmod-bnx2 kmod-button-hotplug kmod-dwmac-intel kmod-e1000 kmod-e1000e 
kmod-forcedeth kmod-fs-vfat kmod-igb kmod-igc kmod-ixgbe kmod-nft-offload 
kmod-r8169 kmod-tg3 libc libgcc libustream-mbedtls logd mkf2fs mtd netifd 
nftables odhcp6c odhcpd-ipv6only partx-utils ppp ppp-mod-pppoe procd 
procd-seccomp procd-ujail uci uclient-fetch urandom-seed urngd

  Package list missing or not up-to-date, generating it.

  Building package index...
  ERROR: *.apk: No such file or directory
  ERROR: 1 errors, not creating index
  make[3]: *** [Makefile:172: package_index] Error 99
  make[2]: *** [Makefile:196: package_reload] Error 2
  make[1]: *** [Makefile:150: _call_image] Error 2
  make: *** [Makefile:310: image] Error 2

Cheers,

Petr

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

Re: [PATCH] realtek: add missing PHY handles for GS1900-10HP

[Bjørn Mork via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Stijn Segers  writes:

> So what do you suggest? Leave it as-is?

Either that or remove the bogus error message from the driver.  This is
not an error.

If any cleanup should be done in the GS1900-10HP dts, then removing
those two bogus internal phys would be the correct thing to do.

> I can't recall seeing this
> error with 5.15.

It was there for me:


[0.00] Linux version 5.15.158 (bjorn@canardo) 
(mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.2.0 r26302-4f87a4d84f3d) 13.2.0, 
GNU ld (GNU Binutils) 2.42) #0 Mon May 13 08:15:17 2024
[0.00] RTL838X model is 83806800
[0.00] SoC Type: RTL8380
[0.00] printk: bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019070 (MIPS 4KEc)
[0.00] MIPS: machine is ZyXEL GS1900-10HP Switch
[0.00] earlycon: ns16550a0 at MMIO 0x18002000 (options '115200n8')
[0.00] printk: bootconsole [ns16550a0] enabled
...

[3.885337] Realtek RTL8218B (internal) rtl838x slave mii-0:08: Detected 
internal RTL8218B
[3.894752] Firmware loaded. Size 1184, magic: 83808380
[4.199898] sfp sfp-p9: module OEM  GLC-Trev Bsn 
M0312A804dc 130823  
[4.310319] sfp sfp-p10: module Tsuhan   THMPRS-3511-10A  rev A
sn F19021506991 dc 190409  
[6.713738] Realtek RTL8380 SERDES rtl838x slave mii-0:18: Detected internal 
RTL8380 SERDES
[6.723249] Firmware loaded. Size 1184, magic: 83808380
[6.729162] SDS power down value: 3
[6.757270] PLL control register: f
[6.761319] SDS power down value now: 3f
[6.765729] Configuration of SERDES done
[6.797530] rtl83xx-switch switch@1b00: Port node 24 misses phy-handle
[6.805417] rtl83xx-switch switch@1b00: Port node 26 misses phy-handle
[6.817852] In rtl83xx_vlan_setup



Bjørn

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

Re: [PATCH] realtek: add missing PHY handles for GS1900-10HP

[Stijn Segers]

Hi Bjorn,


Op zondag 22 september 2024 om 18:29:50 +02:00:00 schreef Bjørn Mork 
:

Stijn Segers  writes:


 Fixes the following error in dmesg:

   [7.703678] rtl83xx-switch switch@1b00: Port node 24 
misses phy-handle
   [7.711556] rtl83xx-switch switch@1b00: Port node 26 
misses phy-handle


rtl83xx_mdio_probe() is weird.  I guess the SoC phy polling makes that
necessary. But it should accept sfp ports without phys, because that's
what these are.  There are pnly 8 internal phys in this switch.


 @@ -59,6 +59,7 @@
port@24 {
reg = <24>;
label = "lan9";
 +  phy-handle = "<&phy24>";
phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <&sfp0>;


This does not describe any hardware.  It just works around a driver 
bug.


So what do you suggest? Leave it as-is? I can't recall seeing this 
error with 5.15.


Stijn




Bjørn




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

Re: [PATCH] realtek: add missing PHY handles for GS1900-10HP

[Bjørn Mork via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Stijn Segers  writes:

> Fixes the following error in dmesg:
>
>   [7.703678] rtl83xx-switch switch@1b00: Port node 24 misses 
> phy-handle
>   [7.711556] rtl83xx-switch switch@1b00: Port node 26 misses 
> phy-handle

rtl83xx_mdio_probe() is weird.  I guess the SoC phy polling makes that
necessary. But it should accept sfp ports without phys, because that's
what these are.  There are pnly 8 internal phys in this switch.

> @@ -59,6 +59,7 @@
>   port@24 {
>   reg = <24>;
>   label = "lan9";
> + phy-handle = "<&phy24>";
>   phy-mode = "1000base-x";
>   managed = "in-band-status";
>   sfp = <&sfp0>;

This does not describe any hardware.  It just works around a driver bug.


Bjørn

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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Tim Small via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

Hi Evan,

Thanks for your email...

On 21/09/2024 15:06, Evan Jobling wrote:


I had a look into this on JG922A today.
I can set the fans to max on initialisation of RTL8231 using gpio-hog.
But it not only is setting initalisation, it also 'hogs' it per description.

So that basically locks out gpio-fan or userspace setting it.


My thoughts were that the kernel's gpio-init code for that SoC shouldn't 
reset the gpio state - rather it should leave it in the state that the 
firmware configured it.  gpio-fan would then do the right thing.



JG922A and JG928A got accepted without max fans by default?
So I hope moving to hwmon and gpio-fan is sufficient?


I think that was probably a mistake - since there is definitely scope 
for hardware damage (conceivably even fire) with what is now the default 
OpenWRT behaviour for these devices.


This problem is gnarly unfortunately.

I think the only really "correct" ways to proceed are either to allow 
user control (defaulting to high speed i.e. delegating the decision), or 
to re-implement the same fan control algorithm as the OEM firmware does.


That algorithm could probably be discovered by treating it as a black 
box (e.g. giving it different PoE power loads, and/or operating 
temperatures, simulating fan failures etc. and observing behaviour).


Unfortunately I think that without access to the hardware specs and/or 
carrying out a lot of hardware characterisation work there is too much 
guesswork involved in implementing any other algorithm.


Tim.

--
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309

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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Bjørn Mork via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Evan Jobling  writes:

>> I wrote this as a proof-of-concept many years ago:
>> https://github.com/bmork/openwrt/commit/8043178a6bf439ebd7665c0ad1e36aa89847fc38
>> 
>> Maybe usable as a start for someone?
>
> First, this is excellent thanks.
>
> Are you able to elaborate on any further work you think is required?
> I don't know where to start, other than "make it build",
> "port to Kernel 6.6" and then "configure the device tree correctly."

I believe that's pretty much it.  If you already have a "cooling-device"
implementation using the gpio-fan driver, then you just have to extend
the thermal-zone with cooling-maps and trips.  See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/thermal/thermal-zones.yaml

The RPi PoE hat device tree overlay is another example of adding a
cooling-device (fan) into an existing thermal-zone with a sensor:

https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/overlays/rpi-poe-overlay.dts

We obviously don't want overlays - just think of it as a device tree
diff.  And the trip point params are also irrelevant.  AFAICS,
thermal_of will set THERMAL_TRIP_FLAG_RW_TEMP. So the trip points should
be configurable from userspace using sysfs.  Unless I'm missing
something.

In any case, a fixed high/low setting like OEM is probably good enough
for most users.

> Whilst I've done C. My kernel device driver experience approximates zero.

I've never written thermal drver either.  There's only one way out of
that :-)


Bjørn

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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Evan Jobling via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> I wrote this as a proof-of-concept many years ago:
> https://github.com/bmork/openwrt/commit/8043178a6bf439ebd7665c0ad1e36aa89847fc38
> 
> Maybe usable as a start for someone?

First, this is excellent thanks.

Are you able to elaborate on any further work you think is required?
I don't know where to start, other than "make it build",
"port to Kernel 6.6" and then "configure the device tree correctly."

Whilst I've done C. My kernel device driver experience approximates zero.

Cheers,
Evan.

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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Evan Jobling via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Thanks for your response Tim!

>> I don't have a JG925A to test so I wasn't game to submit for that.
>> Everything else looks similar which is nice.

Thanks for providing the context.
If we ever get to the stage where the patch set is looking good I guess i can 
reach out.

> 
> So far as I know everything is the same except the power supply module. There 
> were a couple of users willing to test here:
> 
> https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2670
> 
>> So your feedback here is to get this merged, I should change the fan control 
>> into the DTS as you have done?
> 
> I think that seems best to me - the kernel has a thermal management subsystem 
> and future enhancements could use this for fan control by implementing the 
> same algorithm as the OEM firmware.

I've put my patches in patchwork as "changes requested" and will be working on 
another set.
Similarly I've started work on updating JG922A and getting that with gpio-fan 
driver.


> 
>> I was also unaware that there was another GPIO for fan failure so that's 
>> great news.
> 
> It looked like the OEM firmware could be made aware of this, so I just found 
> this by trial and error.  Safest way to provoke this during test is to poke 
> something soft and non-conductive (e.g. plastic foam) in through the fan 
> grille to temporarily stop one fan.

Confirmed and checked that JG922A also has the same functionality.
I used a paperclip but foam is a good idea.
Fan datasheet for JG922A says 8200rpm max. Haven't estimated the low speed RPM.
> 
> 
>>> The best policy is unfortunately probably to run the fans at full speed by 
>>> default.

I've also looked and the 48G model also just got merged, but I didn't see any 
fan control stuff there?

the 48G-PoE model (jg928a) appears to have two fan levels per HPE documentation.
The non poe one (jg927a) says it has one fan loudness (i.e. speed).

> 
> Initially fan speed is set to high (by uboot and/or OEM kernel - can't 
> remember exactly)

uboot does it from what I understand.

 
> The behaviour of the in-kernel gpio fan speed controller is to leave the fan 
> speed as it was when the driver loaded (e.g. to inherit hardware default 
> speed, or the speed which was set by the bootloader etc.). IIRC, the OpenWRT 
> kernel resets the GPIO state at init time, so the fan speed is set to low - 
> which is "wrong".  One approach would be some sort of addition to the patch 
> set to change that (either to force it back high again, or to retain the 
> pre-boot settings), but I didn't have time to look at that, and then life got 
> in the way as usual...

I had a look into this on JG922A today.
I can set the fans to max on initialisation of RTL8231 using gpio-hog.
But it not only is setting initalisation, it also 'hogs' it per description.

So that basically locks out gpio-fan or userspace setting it.

I don't think there's currently a method in openwrt to set fan speed without 
writing
your own fan_ctrl script like on one of the d-link switches, or doing the 
control
in the device tree thermal section?

I don't know the best way to set /sys/class/hwmon/hwmon0/pwm1_enable and then
/sys/class/hwmon/hwmon0/pwm1 to 1 at boot.
I'm thinking duplicate something like /etc/init.d/gpio_switch but for
various hwmon devices? That sounds like lots of work =(

I had a look at what fancontrol and pwmconfig did ( lm-sensors ?)
They require a temperature sensor and aren't in openwrt yet anyway.

> 
> The SoC does have a temperature sensor built-in, but the driver is incomplete 
> and not upstreamed.

So we can set the fan speeds by thermal, if we can get that upstreamed?
Or per Bjørn's patch and keep it in OpenWrt?
I don't understand how much "Further work" is required there.

Whilst I can code in C.
My kernel device driver experience approximates zero.
I can try to build it and get closed loop fan control working.

I haven't figured out whether a fan alarm can be part of the
thermal control scheme in device tree to set the fan state.

The scope creep here is getting a little much for me if I need to get closed or 
open loop
fan control working in a short time frame.

JG922A and JG928A got accepted without max fans by default?
So I hope moving to hwmon and gpio-fan is sufficient?

Then of course update the wiki on how to control/slow down fans, leave it up to 
user?

As I'm going to be operating in hot environments with large PoE loads.
I am also eager to have some sort of algorithm implemented.
But I'd like to put that as "future work"?

I've had thoughts regarding what fan control algorithm to use.
(Without attempting to
reverse engineer what factory did, or do my own thermal characterisation of the
power supply and PSE controller FET

Re: OpenWrt 24.XX release plan

[John Crispin]

On 21.09.24 11:51, Hauke Mehrtens wrote:
@John: You told me you want to add some bigger improvements for 
board.d, what is the timeline for that? 


next few days, I am also testing 
https://github.com/openwrt/openwrt/pull/16342/commits right now. 24.xx 
should include that patch


    John


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

Re: OpenWrt 24.XX release plan

[Christian Marangi]

On Sat, Sep 21, 2024 at 11:51:19AM +0200, Hauke Mehrtens wrote:
> Hi,
> 
> We finally migrated all targets in OpenWrt main branch to kernel 6.6. The
> biggest release blocker is done now.
> 
> It will probably be 24.10.
> 
> When we branch 24.10 we should be able to release a 24.10.0-rc1 release soon
> after, so the wider community is starting to test it.
> 
> We should already start building up the build infrastructure for a 24.10
> branch now.
> @ynezz: What is needed for that?
> 
> The 22.03 branch is EoL since some months, we can decommission the resources
> used for that one if that helps.
> 
> 
> @Ansuel: You said that you want to finish up APK support, what is still
> missing for that?

Mainly the luci app. I hope to have it ready about this and the next
week.

> 
> @John: You told me you want to add some bigger improvements for board.d,
> what is the timeline for that?
> 
> Are there any other bigger changes missing?
> 
> 
> Hauke

-- 
Ansuel

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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Bjørn Mork via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Tim Small via openwrt-devel  writes:

>> So your feedback here is to get this merged, I should change the fan control 
>> into the DTS as you have done?
>
> I think that seems best to me - the kernel has a thermal management
> subsystem and future enhancements could use this for fan control by
> implementing the same algorithm as the OEM firmware.

I wrote this as a proof-of-concept many years ago:
https://github.com/bmork/openwrt/commit/8043178a6bf439ebd7665c0ad1e36aa89847fc38

Maybe usable as a start for someone?

I don't have any switches with fans, so for me it was mostly about
reading the temp sensor for fun.



Bjørn

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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Tim Small via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

Hi Evan,

On 19/09/2024 01:36, Evan Jobling wrote:


I don't have a JG925A to test so I wasn't game to submit for that.
Everything else looks similar which is nice.


So far as I know everything is the same except the power supply module. 
There were a couple of users willing to test here:


https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2670


So your feedback here is to get this merged, I should change the fan control 
into the DTS as you have done?


I think that seems best to me - the kernel has a thermal management 
subsystem and future enhancements could use this for fan control by 
implementing the same algorithm as the OEM firmware.



I was also unaware that there was another GPIO for fan failure so that's great 
news.


It looked like the OEM firmware could be made aware of this, so I just 
found this by trial and error.  Safest way to provoke this during test 
is to poke something soft and non-conductive (e.g. plastic foam) in 
through the fan grille to temporarily stop one fan.




The best policy is unfortunately probably to run the fans at full speed by 
default.


I guess then we should also submit a patch so the default for the JG922A is 
also max?
Then the user can elect to turn down the fans?


Yes, I think that's the case.  The OEM firmware setup is that during boot:

Initially fan speed is set to high (by uboot and/or OEM kernel - can't 
remember exactly)


. OEM user space manages fan speed based on some unknown algorithm 
(presumably by the "FanT" user space process, which isn't present on the 
very similar fanless JG924A).


https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2668

The behaviour of the in-kernel gpio fan speed controller is to leave the 
fan speed as it was when the driver loaded (e.g. to inherit hardware 
default speed, or the speed which was set by the bootloader etc.). 
IIRC, the OpenWRT kernel resets the GPIO state at init time, so the fan 
speed is set to low - which is "wrong".  One approach would be some sort 
of addition to the patch set to change that (either to force it back 
high again, or to retain the pre-boot settings), but I didn't have time 
to look at that, and then life got in the way as usual...


The SoC does have a temperature sensor built-in, but the driver is 
incomplete and not upstreamed.


Also relevant:

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2676

and:

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2679

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2680

... and a few other posts around that time in that thread.

Cheers,

Tim.

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

Re: [PATCH 2/2] scripts/feeds: force kernel package scan after a target installation

[Andrey Jr. Melnikov]

Thomas Richard via openwrt-devel  wrote:

[...]

> diff --git a/scripts/feeds b/scripts/feeds
> index 7cbe07f58e..a48be670f0 100755
> --- a/scripts/feeds
> +++ b/scripts/feeds
> @@ -461,6 +461,11 @@ sub do_install_target($) {
> return 1;
> }
>  
> +   # Clean packageinfo of linux kernel to force the scan.
> +   # Otherwise kernel modules defined at target level are not scanned, 
> as the
> +   # linux kernel package was scanned before the installation of the 
> target.
> +   system("rm tmp/info/.packageinfo-kernel_linux");
Why spawn shell with rm? Use 'unlink "tmp/info/.packageinfo-kernel_linux";' 
here.


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

Re: [PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Tim Small via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

Hi,

I prepared a patch for this switch about 6 months ago, but never got 
around to submitting it.


The OEM firmware seems to do fan speed control in firmware - although 
the algorithm used is not obvious - it's probably temperature sensor or 
total power draw feedback, or some combination of the two.  Additionally 
when one fan fails the others go full-speed (and log faults).


The best policy is unfortunately probably to run the fans at full speed 
by default.


If you want to take a look it's here, and should be pretty much complete.

https://github.com/openwrt/openwrt/compare/main...tim-seoss:openwrt:hpe-1920-24g-poe-370w-jg926a

Cheers,

Tim.

On 18/09/2024 03:09, Evan Jobling via openwrt-devel wrote:

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.


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


--
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309

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

Re: realtek: HPE 1920-24G-PoE+ 370W (JG926A) support

[Evan Jobling via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi All.

Thanks for the feedback.

I've rebased the patches and tested on kernel 6.6.

I will be sending through the patches now.

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

Re: realtek: HPE 1920-24G-PoE+ 370W (JG926A) support

[Bjørn Mork via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Felix Baumann via openwrt-devel 
writes:

> The Realtek target needs help. It needs to be upgraded to Kernel 6.6
> like all the other targets.  Else there is a chance it will be dropped
> so OpenWrt Release 24 can proceed to be branched and later
> released. The Realtek could still be reintroduced later on, if people
> owning the device can help put in the work or help with testing.

Things are not looking that bad any longer, IMHO.  There's a 6.6 PR
ready(?) for merging: https://github.com/openwrt/openwrt/pull/16204

AFACS, the latest revision addresses all comments so far.  Better test
coverage on different hardware and actual use cases would probably be
good though.

So please, everybody: Go test that code now!

That's the best help you currenly can give the target. Remember to
enable v6.6 by setting CONFIG_TESTING_KERNEL=y in .config.  It's so easy
to forget.  Done that several times myself...


Bjørn

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

Re: realtek: HPE 1920-24G-PoE+ 370W (JG926A) support

[Felix Baumann via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Am 14. September 2024 06:07:27 MESZ schrieb Evan Jobling via openwrt-devel 
:
>The sender domain has a DMARC Reject/Quarantine policy which disallows
>sending mailing list messages using the original "From" header.
>
>To mitigate this problem, the original message has been wrapped
>automatically by the mailing list software.
Hi,

just a heads up in-case you missed the mail:
The Realtek target needs help. It needs to be upgraded to Kernel 6.6 like all 
the other targets.
Else there is a chance it will be dropped so OpenWrt Release 24 can proceed to 
be branched and later released. The Realtek could still be reintroduced later 
on, if people owning the device can help put in the work or help with testing.



If you have further questions feel free to ask via mail or on Github
 

Regards
Felix Baumann

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

Re: [PATCH] mvneta: fix "napi poll" infinite loop for openwrt

[Kabuli Chana]

Why is this kernel 5.15 based?


On 2024-09-11 06:18, webmas...@jbsky.fr wrote:

From: Julien Blais 

This patch is submitted to the kernel.

For your information, this fixes the problem identified during a test with
  iperf, the packet sending stall and above all the use of a 100% CPU
  because of the softIRQ.

Before:
root@wrt1900acv1:~# cat /proc/interrupts
CPU0   CPU1
  24:   18652404   15171396  MPIC   5 Level armada_370_xp_per_cpu_tick
  26: 292136 78  MPIC  31 Level mv64xxx_i2c
  27: 26  0  MPIC  41 Level ttyS0
  33:1024678  0  MPIC  45 Level ehci_hcd:usb1
  34:   23007175  0  MPIC   8 Level eth0

After:
root@OpenWrt:/# cat /proc/interrupts
CPU0   CPU1
  24: 194183 161947  MPIC   5 Level armada_370_xp_per_cpu_tick
  25:  0  0  MPIC   3 Level arm-pmu
  26:246  0  MPIC  31 Level mv64xxx_i2c
  27:   5488  0  MPIC  41 Level ttyS0
  33:  0  0  MPIC  45 Level ehci_hcd:usb1
  34:20151306330694  MPIC   8 Level eth0

Signed-off-by: Julien Blais 
---
  .../700-mvneta-tx-queue-workaround.patch  | 38 ---
  ...1-mvneta-fix-napi-poll-infinite-loop.patch | 38 +++
  2 files changed, 38 insertions(+), 38 deletions(-)
  delete mode 100644 
target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch
  create mode 100644 
target/linux/mvebu/patches-5.15/701-mvneta-fix-napi-poll-infinite-loop.patch

diff --git 
a/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch 
b/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch
deleted file mode 100644
index 32e8ef4b7d..00
--- a/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-The hardware queue scheduling is apparently configured with fixed
-priorities, which creates a nasty fairness issue where traffic from one
-CPU can starve traffic from all other CPUs.
-
-Work around this issue by forcing all tx packets to go through one CPU,
-until this issue is fixed properly.
-
-Signed-off-by: Felix Fietkau 

 a/drivers/net/ethernet/marvell/mvneta.c
-+++ b/drivers/net/ethernet/marvell/mvneta.c
-@@ -5006,6 +5006,16 @@ static int mvneta_setup_tc(struct net_de
-   }
- }
-
-+#ifndef CONFIG_ARM64
-+static u16 mvneta_select_queue(struct net_device *dev, struct sk_buff *skb,
-+ struct net_device *sb_dev)
-+{
-+  /* XXX: hardware queue scheduling is broken,
-+   * use only one queue until it is fixed */
-+  return 0;
-+}
-+#endif
-+
- static const struct net_device_ops mvneta_netdev_ops = {
-   .ndo_open= mvneta_open,
-   .ndo_stop= mvneta_stop,
-@@ -5016,6 +5026,9 @@ static const struct net_device_ops mvnet
-   .ndo_fix_features= mvneta_fix_features,
-   .ndo_get_stats64 = mvneta_get_stats64,
-   .ndo_eth_ioctl= mvneta_ioctl,
-+#ifndef CONFIG_ARM64
-+  .ndo_select_queue= mvneta_select_queue,
-+#endif
-   .ndo_bpf = mvneta_xdp,
-   .ndo_xdp_xmit= mvneta_xdp_xmit,
-   .ndo_setup_tc= mvneta_setup_tc,
diff --git 
a/target/linux/mvebu/patches-5.15/701-mvneta-fix-napi-poll-infinite-loop.patch 
b/target/linux/mvebu/patches-5.15/701-mvneta-fix-napi-poll-infinite-loop.patch
new file mode 100644
index 00..0fa191ea14
--- /dev/null
+++ 
b/target/linux/mvebu/patches-5.15/701-mvneta-fix-napi-poll-infinite-loop.patch
@@ -0,0 +1,38 @@
+From bbeea07de50e925df3877f63a24aee1d35828a02 Mon Sep 17 00:00:00 2001
+From: Julien Blais 
+Date: Wed, 11 Sep 2024 13:27:09 +0200
+Subject: [PATCH v2] mvneta: fix "napi poll" infinite loop
+
+In percpu mode, when there's a network load, one of the cpus can be
+solicited without having anything to process.
+If 0 is returned to napi poll, napi will ignore the next requests,
+causing an infinite loop with ISR handling.
+
+Without this change, patches hang around fixing the queue at 0 and
+the interrupt remains stuck on the 1st CPU.
+The percpu conf is useless in this case, so we might as well remove it.
+
+Signed-off-by: Julien Blais 
+---
+ drivers/net/ethernet/marvell/mvneta.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
+index 3f124268b..b6e89b888 100644
+--- a/drivers/net/ethernet/marvell/mvneta.c
 b/drivers/net/ethernet/marvell/mvneta.c
+@@ -3186,7 +3186,10 @@ static int mvneta_poll(struct napi_struct *napi, int 
budget)
+
+   if (rx_done < budget) {
+   cause_rx_tx = 0;
+-  napi_complete_done(napi, rx_done);
++  if (rx_done)
++  napi_complete_done(napi, rx_done);
++  else
++  napi_complete(napi);
+
+   if (pp->neta_armada

Re: [PATCH 2/2] treewide: remove INITRAMFS check for preinit_main hook

[Elliott Mitchell]

On Fri, Sep 06, 2024 at 02:15:22PM +0200, Florian Eckert wrote:
> 
> On 2024-09-06 04:40, Elliott Mitchell wrote:
> > 
> > Examining this situation, I wonder whether this is really the right way
> > to go.
> > 
> > There are 29 files which match [789]* (excluding `70_initramfs_test`).
> > So you found this redundant check in >10% of files.  This seems a rather
> > high percentage.  Perhaps it might be better to remove the `break` from
> > `70_initramfs_test` and instead require explicitly checking $INITRAMFS ?
> 
> I thought about that too, but decided against it, as I would then have to
> adapt a lot more, as you mentioned. I have to admit that at the beginning
> I didn't understand why my script wasn't called in 'preinit_main' until
> I saw that there was a 'break' in 'boot_run_hook'.
> 
> I would not have expected that!
> 
> I would therefore also prefer as you notice the same to delete 'break' and
> check the INITRAMFS flag. That makes the whole thing more transparent and
> clear.

These haven't been through the copy/update cycle of the kernel
configuration files, so `git blame` works on them:

f43b7934d285 package/base-files/files/lib/preinit/80_mount_root
John Crispin   2013-03-13 11:11:19

a0b7fef0ffe4 package/utils/zyxel-bootconfig/files/95_apply_bootconfig
David Bauer   2022-07-20 12:52:06

fe0081eecf43 target/linux/bcm27xx/base-files/lib/preinit/81_set_root_part
Álvaro Fernández Rojas   2024-03-04 07:28:57

The authors are all members of the project and should therefore be pretty
knowledgeable about OpenWRT.  If even members of the project are getting
it wrong, that seems strong evidence the existing approach doesn't work
well.

Add us and I think we've got a consensus the `break` really should be
removed and checking in every script should be used.  Though there are
the other alternative approaches below.


> > Perhaps the files should have a tag inside them and during build scripts
> > which require initramfs should be conditionally enabled?
> 
> What exactly do you mean by that? Should the scripts always be installed,
> but if an initramfs is built, then the hook line is deleted?

I was thinking something along the lines of having a in-comment tag for
scripts which should be omitted from initramfs.  Perhaps
"# INITRAMFS_OMIT" and "# INITRAMFS_INCLUDE"?

When building the initramfs use `grep -l` or `grep -L` to identify files
which should (not) be included.


> > Perhaps base-files should be split into base-files, base-files-initramfs
> > and base-files-noinitramfs?
> 
> This would be a big change from my point of view, because in base-files
> are not only the preinit scripts but also many other things. We would
> have to maintain this redundantly, if I understand your intention correctly

This might be too big of a change for now.  This may well be a bad idea
right now and in the future.

> > In other news 18 of the 29 [789]* files are named "79_move_config"
> > inside
> > target/linux.  This makes me wonder how similar the job they're doing
> > is.
> > Perhaps these should all merge into a single file in package/base-files.
> 
> This would make sense if the scripts were all the same, but on closer
> look they are all different and are target/subtarget specific. Therefore,
> from my point of view, it makes no sense to move them to the base-files.

Indeed.  A quick glance suggested many are pretty similar and I wonder if
it would be possible to write a single script which could replace all of
them.  I suspect most of them started as copies and they've simply been
slowly drifting apart.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



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

Re: OpenWrt One / status update

[Rosen Penev]

On Fri, Sep 6, 2024 at 6:58 AM John Crispin  wrote:
>
> Hi,
>
> Since it's been a while I'd like to share a brief update on the OpenWrt
> One project.
>
> * 50 DVT (Design Validation Test) samples arrived with the final PCB,
> metal case and packaging. They look really good.
> * The samples feature a 256MB NAND flash instead of the initially
> anticipated 128MB.
> * Hardware and software testing is progressing well. I'm working on a
> couple of small OpenWrt integration patches revolving around MAC address
> handling and supporting the larger NAND flash size which I am going to
> submit soon.
> * I'm planning to send out 30 units to selected contributors beginning
> of next week.
> * The FCC/CE/RoHS certification process has started. Samples are on
> their way to the labs for testing.
>
> The biggest news are that we have a final price:
>
> * $65 for the raw PCB
> * $85 for the fully assembled device inside a metal case

>
> These prices include a $10 donation to the OpenWrt Project
>
>  John
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 2/2] treewide: remove INITRAMFS check for preinit_main hook

[Florian Eckert]

Hello Elliott,

On 2024-09-06 04:40, Elliott Mitchell wrote:

Small item, these two patches appear largely independent.  Numbering is
primarily needed if there are dependencies between patches.  As such
there seem any need to number these.


You're right sorry, I summarized it because it makes changes in the same 
corner.



On Thu, Sep 05, 2024 at 02:42:18PM +0200, Florian Eckert wrote:
The 'preinit' script '/lib/preinit/70_initramfs_test' [1] checks 
whether
the system is running in an 'initramfs'. If this is the case, the loop 
[2]
in which the function is called is exited via a 'break' call. All 
further
'preinit_main' hooks are no longer processed. Therefore, the check 
whether
we are running in an initramfs is not necessary and are therefore 
removed.


I dislike this wording.  Perhaps replace the 3rd sentence with "Further
'preinit_main' hooks are ignored."?  The final sentence seemed a
caltrop.

A better subject line might be "remove duplicate INITRAMFS checks in
preinit_main hooks".  The main issue is these replicate the test in
70_initramfs_test.


I'm not a native speaker. Thanks for the hint. I will definitely adjust
the wording if we agree on how to proceed now.


Examining this situation, I wonder whether this is really the right way
to go.

There are 29 files which match [789]* (excluding `70_initramfs_test`).
So you found this redundant check in >10% of files.  This seems a 
rather

high percentage.  Perhaps it might be better to remove the `break` from
`70_initramfs_test` and instead require explicitly checking $INITRAMFS 
?


I thought about that too, but decided against it, as I would then have 
to
adapt a lot more, as you mentioned. I have to admit that at the 
beginning

I didn't understand why my script wasn't called in 'preinit_main' until
I saw that there was a 'break' in 'boot_run_hook'.

I would not have expected that!

I would therefore also prefer as you notice the same to delete 'break' 
and
check the INITRAMFS flag. That makes the whole thing more transparent 
and clear.



I'm also concerned about the test being done during *every* boot.  This
doesn't make sense unless there were many devices which can use both
overlay and initramfs as root.


I have update the wiki page [1] with currently used preinit script
that I have found to get an overview what is going on.
I hope it is complete!

If I have seen it correctly there are some scripts that need an
additional `[ "$INITRAMFS" = "1" ] ||` check if we remove the 'break' in
'70_initramfs_test'. This means that all scripts that have a
number greater than '70' and hook into the 'preinit_main' need
this check. See my change in the wiki `INITRAMFS check 'NO'`


Perhaps the after initramfs scripts should be split from preinit hooks?


If I got the whole picture, we already have a hook 'preinit_mount_root'
for scripts that are executed if we are not run in an initramfs.
Therefore we can move all other scripts to 'preinit_mount_root' and thus
drop the INITRAMFS check? So we only need this check for 
'80_mount_root'.


Perhaps the files should have a tag inside them and during build 
scripts

which require initramfs should be conditionally enabled?


What exactly do you mean by that? Should the scripts always be 
installed,

but if an initramfs is built, then the hook line is deleted?

Perhaps base-files should be split into base-files, 
base-files-initramfs

and base-files-noinitramfs?


This would be a big change from my point of view, because in base-files
are not only the preinit scripts but also many other things. We would
have to maintain this redundantly, if I understand your intention 
correctly


In other news 18 of the 29 [789]* files are named "79_move_config" 
inside
target/linux.  This makes me wonder how similar the job they're doing 
is.
Perhaps these should all merge into a single file in 
package/base-files.


This would make sense if the scripts were all the same, but on closer
look they are all different and are target/subtarget specific. 
Therefore,

from my point of view, it makes no sense to move them to the base-files.

Best regards

Florian

[1] https://openwrt.org/docs/techref/preinit_mount#overview

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

Re: [PATCH 2/2] treewide: remove INITRAMFS check for preinit_main hook

[Elliott Mitchell]

Small item, these two patches appear largely independent.  Numbering is
primarily needed if there are dependencies between patches.  As such
there seem any need to number these.


On Thu, Sep 05, 2024 at 02:42:18PM +0200, Florian Eckert wrote:
> The 'preinit' script '/lib/preinit/70_initramfs_test' [1] checks whether
> the system is running in an 'initramfs'. If this is the case, the loop [2]
> in which the function is called is exited via a 'break' call. All further
> 'preinit_main' hooks are no longer processed. Therefore, the check whether
> we are running in an initramfs is not necessary and are therefore removed.

I dislike this wording.  Perhaps replace the 3rd sentence with "Further
'preinit_main' hooks are ignored."?  The final sentence seemed a
caltrop.

A better subject line might be "remove duplicate INITRAMFS checks in
preinit_main hooks".  The main issue is these replicate the test in
70_initramfs_test.


Examining this situation, I wonder whether this is really the right way
to go.

There are 29 files which match [789]* (excluding `70_initramfs_test`).
So you found this redundant check in >10% of files.  This seems a rather
high percentage.  Perhaps it might be better to remove the `break` from
`70_initramfs_test` and instead require explicitly checking $INITRAMFS ?

I'm also concerned about the test being done during *every* boot.  This
doesn't make sense unless there were many devices which can use both
overlay and initramfs as root.

Perhaps the after initramfs scripts should be split from preinit hooks?

Perhaps the files should have a tag inside them and during build scripts
which require initramfs should be conditionally enabled?

Perhaps base-files should be split into base-files, base-files-initramfs
and base-files-noinitramfs?


In other news 18 of the 29 [789]* files are named "79_move_config" inside
target/linux.  This makes me wonder how similar the job they're doing is.
Perhaps these should all merge into a single file in package/base-files.


The patch basically looks reasonable, just there are these concerning
bits lurking slightly deeper.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



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

Re: [PATCH] gpio-button-hotplug: skip disabled buttons

[Rosen Penev]

On Thu, Sep 5, 2024 at 7:33 AM Thomas Richard via openwrt-devel
 wrote:
>
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> -- Forwarded message --
> From: Thomas Richard 
> To: openwrt-devel@lists.openwrt.org
> Cc: thomas.petazz...@bootlin.com, thomas.rich...@bootlin.com
> Bcc:
> Date: Thu,  5 Sep 2024 16:26:42 +0200
> Subject: [PATCH] gpio-button-hotplug: skip disabled buttons
> Ignore buttons which are disabled in the devicetree.
>
> Signed-off-by: Thomas Richard 
Reviewed-by: Rosen Penev 
> ---
>  package/kernel/gpio-button-hotplug/Makefile  | 2 +-
>  package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/package/kernel/gpio-button-hotplug/Makefile 
> b/package/kernel/gpio-button-hotplug/Makefile
> index 04cbb69ada..5b4085887d 100644
> --- a/package/kernel/gpio-button-hotplug/Makefile
> +++ b/package/kernel/gpio-button-hotplug/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>  include $(INCLUDE_DIR)/kernel.mk
>
>  PKG_NAME:=gpio-button-hotplug
> -PKG_RELEASE:=3
> +PKG_RELEASE:=4
>  PKG_LICENSE:=GPL-2.0
>
>  include $(INCLUDE_DIR)/package.mk
> diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
> b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
> index 17748219e8..a73e5c4e5a 100644
> --- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
> +++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
> @@ -373,7 +373,7 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> if (!node)
> return NULL;
>
> -   nbuttons = of_get_child_count(node);
> +   nbuttons = of_get_available_child_count(node);
> if (nbuttons == 0)
> return ERR_PTR(-EINVAL);
>
> @@ -388,7 +388,7 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> pdata->rep = !!of_get_property(node, "autorepeat", NULL);
> of_property_read_u32(node, "poll-interval", &pdata->poll_interval);
>
> -   for_each_child_of_node(node, pp) {
> +   for_each_available_child_of_node(node, pp) {
> button = (struct gpio_keys_button *)(&pdata->buttons[i++]);
>
> if (of_property_read_u32(pp, "linux,code", &button->code)) {
> --
> 2.39.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

Any news, link, where could we order it?

BR
Janusz


Hi Janusz,

the first 50 DVT samples arrived at my place yesterday, we will post an 
update next few days with further details


John


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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Felix Baumann via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
It's not available. News will be sent here once it does become available, I 
assume. And there'll probably be other news on the project before that.

I don't know the status but they are working on it, give the project time :)

Regards
Felix Baumann

Am 3. September 2024 13:37:52 MESZ schrieb Janusz Dziedzic 
:
>wt., 30 lip 2024 o 12:47 Paul Spooren  napisał(a):
>>
>> Sure, https://github.com/cyyself/wg-bench/pull/37
>>
>> > On 29. Jul 2024, at 19:37, Paul D  wrote:
>> >
>> >
>> > Hi, could one of the early ONE owners/users post numbers for the ONE 
>> > regarding WireGuard performance?
>> >
>> > https://forum.openwrt.org/t/a-wireguard-comparison-db/187586/1
>> >
>> > It's an important use-case and a factor affecting the decision for next 
>> > hardware purchase (for me, anyway).
>> >
>> >
>> >
>
>Any news, link, where could we order it?
>
>BR
>Janusz
>
>___
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Janusz Dziedzic]

wt., 30 lip 2024 o 12:47 Paul Spooren  napisał(a):
>
> Sure, https://github.com/cyyself/wg-bench/pull/37
>
> > On 29. Jul 2024, at 19:37, Paul D  wrote:
> >
> >
> > Hi, could one of the early ONE owners/users post numbers for the ONE 
> > regarding WireGuard performance?
> >
> > https://forum.openwrt.org/t/a-wireguard-comparison-db/187586/1
> >
> > It's an important use-case and a factor affecting the decision for next 
> > hardware purchase (for me, anyway).
> >
> >
> >

Any news, link, where could we order it?

BR
Janusz

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

Re: BPI-R4-NIC-BE14

[Janusz Dziedzic]

śr., 21 sie 2024 o 10:21 Janusz Dziedzic  napisał(a):
>
> wt., 20 sie 2024 o 15:50 Janusz Dziedzic  
> napisał(a):
> >
> > wt., 20 sie 2024 o 15:23 Janusz Dziedzic  
> > napisał(a):
> > >
> > > Hello,
> > >
> > > Any hints about BE14 NIC - what should I enable in config. Does it work?
> > > Have latest main and seems no pci output with BE14 inside BPI-R4.
> > >
> > Sorry for the noise.
> > SW4 - on - after that module power on:
> >
> > root@OpenWrt:~# lspci
> > :00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
> > :01:00.0 Network controller: MEDIATEK Corp. Device 7990
> > 0001:00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
> > 0001:01:00.0 Network controller: MEDIATEK Corp. Device 7991
> > root@OpenWrt:~#
> > root@OpenWrt:~# ls /sys/class/ieee80211/
> > phy0  phy1
> > root@OpenWrt:~#
>
> Any hint why I don't see 5GHz?
> phy0 - report 2GHz
> phy1 - report 6GHz
>
> should one of them support both? Or should be another phyX? Or have
> wrong firmware?
>
Just in case someone read this :)

- patch [PATCH] wifi: mt76: mt7996: support mt7996 2+3+3 variant - required
- firmware 2-3-3

After that see 3 phys (all bands)

root@bpi-r4-9611025bdb3d:~# ls /lib/firmware/mediatek/mt7996/
mt7996_dsp.binmt7996_eeprom_233.bin
mt7996_rom_patch_233.bin  mt7996_wa_233.bin mt7996_wm_233.bin
mt7996_eeprom.bin mt7996_rom_patch.bin  mt7996_wa.bin
   mt7996_wm.bin
root@bpi-r4-9611025bdb3d:~#
root@bpi-r4-9611025bdb3d:~# ls /sys/class/ieee80211/
phy0  phy1  phy2
root@bpi-r4-9611025bdb3d:~#
root@bpi-r4-9611025bdb3d:~#
root@bpi-r4-9611025bdb3d:~#

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

Re: Can't build 6.6 kernel for x86_64

[Elliott Mitchell]

On Tue, Aug 27, 2024 at 09:08:48PM +0200, Felix Fietkau wrote:
> On 27.08.24 19:31, Elliott Mitchell wrote:
> > On Thu, Jul 11, 2024 at 08:51:24PM -0600, Philip Prindeville via 
> > openwrt-devel wrote:
> > 
> > > Date: Thu, 11 Jul 2024 20:51:24 -0600
> > > From: Philip Prindeville 
> > > 
> > > Was able to get a build with:
> > > 
> > > --- a/kernel-config
> > > +++ b/kernel-config
> > > @@ -35,6 +35,8 @@ CONFIG_CHR_DEV_SG=m
> > >  CONFIG_CLZ_TAB=y
> > >  CONFIG_COREDUMP=y
> > >  CONFIG_CRASH_DUMP=y
> > > +CONFIG_CRASH_HOTPLUG=y
> > > +CONFIG_CRASH_MAX_MEMORY_RANGES=8192
> > >  CONFIG_CRYPTO_ABLK_HELPER=y
> > >  CONFIG_CRYPTO_AKCIPHER=y
> > >  CONFIG_CRYPTO_AKCIPHER2=y
> > > @@ -67,6 +69,8 @@ CONFIG_CRYPTO_HW=y
> > >  CONFIG_CRYPTO_JITTERENTROPY=y
> > >  CONFIG_CRYPTO_KPP=y
> > >  CONFIG_CRYPTO_KPP2=y
> > > +# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> > > +# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
> > >  CONFIG_CRYPTO_MD5=m
> > >  CONFIG_CRYPTO_NULL=y
> > >  CONFIG_CRYPTO_POLY1305=y
> > 
> > What is/are the justification(s) for the current approach to kernel
> > configuration handling?
> > 
> > Every time I take a look I cannot help noticing it requires a *lot* of
> > manual intervention.  Worse, since most configuration options need to be
> > set, it is hard to distinguish options which are set due to features
> > being desired versus those needed to simply get the kernel to build.
> > 
> > This means many extra options may have leaked in which are no longer
> > desireable.  This means kernel updates have to change many options and
> > it can be quite non-obvious when unwanted options sneak in.
> > 
> > 
> > I think it might be better to instead do something along the lines of:
> > 
> > cp target/linux/generic/config-${version} 
> > linux-${version}/arch/${ARCH}/configs/generic.config
> > cp target/linux/${BOARD}/config-${version} 
> > linux-${version}/arch/${ARCH}/configs/${BOARD}.config
> > cp target/linux/${BOARD}/${TARGET}/config-${version} 
> > linux-${version}/arch/${ARCH}/configs/${BOARD}_${TARGET}.config
> > #
> > make ARCH=${ARCH} defconfig
> > make ARCH=${ARCH} generic.config
> > make ARCH=${ARCH} ${BOARD}.config
> > make ARCH=${ARCH} ${BOARD}_${TARGET}.config
> > 
> > Mainly since the time when OpenWRT's kernel configuration system was
> > created, the Linux kernel configuration system has grown comparable
> > functionality.  This would make OpenWRT's build rather more robust, plus
> > emphasize options which were deliberately chosen.
> 
> I designed the current kernel configuration handling based on the following
> requirement list (likely incomplete):
> 
> - making it as easy as possible to handle dynamic kernel config changes for
> packaging kmod packages
> - not enabling kernel modules which are not packaged
> - keeping most common kernel config symbols in a generic file which is
> shared across targets and can be used to change options for all targets
> - being able to edit the target/subtarget kernel config with
> menuconfig/oldconfig while storing only deltas relative to the generic
> config
> 
> What you're proposing seems simple on the surface, but in my opinion ignores
> important parts of the kernel config maintenance, especially:
> - package based kernel module selection

How?  The approach I'm suggesting appears almost completely orthogonal to
this issue.  I could see the above process making verifying package
builds harder, but doesn't seem to actually break this.

In fact the difference between in-tree module builds versus out-of-tree
module builds is *very* small.  I was very close to being able to build
every package outside the kernel build.  I ran into some difficulty of
the two build types weren't *quite* identical, but hopefully that will be
addressed in the future.

The kernel maintainer I interacted with favored a distinct approach from
what I had, but did seem to acknowledge the processes *should* be
identical.  If that works, then I may have a rather superior approach for
module building for 6.11.

> - make kernel_menuconfig/oldconfig

Why is this so valuable?  Certainly the kernel configuration program is
handy for doing fully-manual kernel configuration.  Yet for OpenWRT I
would expect it to be rather more valuable to keep kernel options one
cares about (CONFIG_NETFILTER=y) from ones which are merely needed to
generate valid kernel configurations (CONFIG_NF_LOG_IPV6=n).

I've run across a number of kernel configuration options which were set
inappropriately (CONFIG_SCx200=y on *all* x86 platforms, not just geode),
so this certainly hasn't kept everything clean.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



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

Re: Can't build 6.6 kernel for x86_64

[Felix Fietkau]

On 27.08.24 19:31, Elliott Mitchell wrote:

On Thu, Jul 11, 2024 at 08:51:24PM -0600, Philip Prindeville via openwrt-devel 
wrote:


Date: Thu, 11 Jul 2024 20:51:24 -0600
From: Philip Prindeville 

Was able to get a build with:

--- a/kernel-config
+++ b/kernel-config
@@ -35,6 +35,8 @@ CONFIG_CHR_DEV_SG=m
 CONFIG_CLZ_TAB=y
 CONFIG_COREDUMP=y
 CONFIG_CRASH_DUMP=y
+CONFIG_CRASH_HOTPLUG=y
+CONFIG_CRASH_MAX_MEMORY_RANGES=8192
 CONFIG_CRYPTO_ABLK_HELPER=y
 CONFIG_CRYPTO_AKCIPHER=y
 CONFIG_CRYPTO_AKCIPHER2=y
@@ -67,6 +69,8 @@ CONFIG_CRYPTO_HW=y
 CONFIG_CRYPTO_JITTERENTROPY=y
 CONFIG_CRYPTO_KPP=y
 CONFIG_CRYPTO_KPP2=y
+# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
+# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
 CONFIG_CRYPTO_MD5=m
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_POLY1305=y


What is/are the justification(s) for the current approach to kernel
configuration handling?

Every time I take a look I cannot help noticing it requires a *lot* of
manual intervention.  Worse, since most configuration options need to be
set, it is hard to distinguish options which are set due to features
being desired versus those needed to simply get the kernel to build.

This means many extra options may have leaked in which are no longer
desireable.  This means kernel updates have to change many options and
it can be quite non-obvious when unwanted options sneak in.


I think it might be better to instead do something along the lines of:

cp target/linux/generic/config-${version} 
linux-${version}/arch/${ARCH}/configs/generic.config
cp target/linux/${BOARD}/config-${version} 
linux-${version}/arch/${ARCH}/configs/${BOARD}.config
cp target/linux/${BOARD}/${TARGET}/config-${version} 
linux-${version}/arch/${ARCH}/configs/${BOARD}_${TARGET}.config
#
make ARCH=${ARCH} defconfig
make ARCH=${ARCH} generic.config
make ARCH=${ARCH} ${BOARD}.config
make ARCH=${ARCH} ${BOARD}_${TARGET}.config

Mainly since the time when OpenWRT's kernel configuration system was
created, the Linux kernel configuration system has grown comparable
functionality.  This would make OpenWRT's build rather more robust, plus
emphasize options which were deliberately chosen.


I designed the current kernel configuration handling based on the 
following requirement list (likely incomplete):


- making it as easy as possible to handle dynamic kernel config changes 
for packaging kmod packages

- not enabling kernel modules which are not packaged
- keeping most common kernel config symbols in a generic file which is 
shared across targets and can be used to change options for all targets
- being able to edit the target/subtarget kernel config with 
menuconfig/oldconfig while storing only deltas relative to the generic 
config


What you're proposing seems simple on the surface, but in my opinion 
ignores important parts of the kernel config maintenance, especially:

- package based kernel module selection
- make kernel_menuconfig/oldconfig

- Felix

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

Re: Can't build 6.6 kernel for x86_64

[Elliott Mitchell]

On Thu, Jul 11, 2024 at 08:51:24PM -0600, Philip Prindeville via openwrt-devel 
wrote:

> Date: Thu, 11 Jul 2024 20:51:24 -0600
> From: Philip Prindeville 
> 
> Was able to get a build with:
> 
> --- a/kernel-config
> +++ b/kernel-config
> @@ -35,6 +35,8 @@ CONFIG_CHR_DEV_SG=m
>  CONFIG_CLZ_TAB=y
>  CONFIG_COREDUMP=y
>  CONFIG_CRASH_DUMP=y
> +CONFIG_CRASH_HOTPLUG=y
> +CONFIG_CRASH_MAX_MEMORY_RANGES=8192
>  CONFIG_CRYPTO_ABLK_HELPER=y
>  CONFIG_CRYPTO_AKCIPHER=y
>  CONFIG_CRYPTO_AKCIPHER2=y
> @@ -67,6 +69,8 @@ CONFIG_CRYPTO_HW=y
>  CONFIG_CRYPTO_JITTERENTROPY=y
>  CONFIG_CRYPTO_KPP=y
>  CONFIG_CRYPTO_KPP2=y
> +# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> +# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
>  CONFIG_CRYPTO_MD5=m
>  CONFIG_CRYPTO_NULL=y
>  CONFIG_CRYPTO_POLY1305=y

What is/are the justification(s) for the current approach to kernel
configuration handling?

Every time I take a look I cannot help noticing it requires a *lot* of
manual intervention.  Worse, since most configuration options need to be
set, it is hard to distinguish options which are set due to features
being desired versus those needed to simply get the kernel to build.

This means many extra options may have leaked in which are no longer
desireable.  This means kernel updates have to change many options and
it can be quite non-obvious when unwanted options sneak in.


I think it might be better to instead do something along the lines of:

cp target/linux/generic/config-${version} 
linux-${version}/arch/${ARCH}/configs/generic.config
cp target/linux/${BOARD}/config-${version} 
linux-${version}/arch/${ARCH}/configs/${BOARD}.config
cp target/linux/${BOARD}/${TARGET}/config-${version} 
linux-${version}/arch/${ARCH}/configs/${BOARD}_${TARGET}.config
#
make ARCH=${ARCH} defconfig
make ARCH=${ARCH} generic.config
make ARCH=${ARCH} ${BOARD}.config
make ARCH=${ARCH} ${BOARD}_${TARGET}.config

Mainly since the time when OpenWRT's kernel configuration system was
created, the Linux kernel configuration system has grown comparable
functionality.  This would make OpenWRT's build rather more robust, plus
emphasize options which were deliberately chosen.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



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

Re: State of APK package manger integration

[Rosen Penev]

On Sun, Aug 11, 2024 at 11:36 AM Paul Spooren  wrote:
>
> Hi all,
>
> Some time has passed and there are further news for the APK migration:
>
> Timo and Ansuel worked out a way to allow index trust[1]. If a package index 
> is signed by a trusted key, all containing packages are automatically 
> trusted. It is still possible distribute and sign single packages.
>
> With this in place, the last missing bit was to teach our Buildbot 
> infrastructure to sign indexes with the Buildmaster key[2]. For context, the 
> OpenWrt project does not store private signing keys on Buildworkers but only 
> on the Buildmaster. Indexes are transferred to the Buildmaster and signed 
> there, later uploaded to the download server.
>
> This, too, works now and can be tested for a limited number of targets/archs 
> (if your favorite is missing, please ping me)[3].
>
> The firmware contains a APK public key (in /etc/apk/keys) for testing[4] and 
> the download server is modified[5]. The key is not official and will be 
> replaced once things go further upstream.
>
> If you run one of those images, please give APK a spin and see how it’s 
> doing. A simple example would b to run the following:
>
> apk add luci # install LuCI
> apk audit # see what file changed since rootfs creation
>
> Looking at the failing packages[6], some maintainers have not yet switches to 
> an APK conform version schema. I’ll try to ping those or create PRs myself.
>
> I’m optimistic’ish that things will work out just great. Please give it a 
> test and let me know how it goes.
ca-bundle and ca-certificates can't coexist it seems.
>
> Best,
> Paul
>
> [1]: 
> https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/54caa31be633efc5f655700b77af290124f71689
> [2]: 
> https://github.com/openwrt/buildbot/commit/a94d4e15fdc1e9715d7d0cfdcc62227186d0fc45
> [3]: https://buildbot.aparcar.org/targets/
> [4]: 
> https://github.com/aparcar/openwrt/commit/de9b171c5a98c9e23e3da8b787ddc5ba7dd0ac53
> [5]: 
> https://github.com/aparcar/openwrt/commit/2c98eb52e365be6e59b470b4c0001cf29e8a6fb3
> [6]: https://buildbot.aparcar.org/faillogs/x86_64/
>
>
> > On 13. Jun 2024, at 13:29, Paul Spooren  wrote:
> >
> > Dear all,
> >
> > With great contributions from Timo, Ansuel, Jonas, Daniel, Petr, John, and 
> > many others, APK is evolving smoothly, and the integration is progressing 
> > well!
> >
> > We have established a staging buildbot environment[1] that compiles 
> > firmware images and certain packages. To replicate this setup locally, 
> > simply enable “Use APK instead of OPKG to build distribution” (`USE_APK`) 
> > in the “Global build settings”.
> >
> > Once the firmware is compiled, it is uploaded to the staging downloads 
> > page[2]. Currently, we have limited the targets created to a subset that we 
> > have found useful for testing purposes.The firmware images boot up 
> > successfully and allow for the installation of external feeds[3]!
> >
> > Be aware, there is still some work required on the package feeds to 
> > accommodate the new version requirements. If you are maintaining something, 
> > please take a look (e.g. [4]).
> >
> > We are facing an architectural challenge that needs to be addressed. In the 
> > past, both OPKG and APKv2 would only sign the package indexes and 
> > automatically trust the included packages. With APKv3 (the version we are 
> > using), each individual package is signed. We are exploring ways to 
> > securely integrate this into the existing setup, where build workers do not 
> > have a private key but upload the package index to a dedicated server for 
> > signing. We will keep you updated on our progress.
> >
> > I will provide more updates as we make further advancements. Please stay 
> > tuned for more information.
> >
> > Sunshine,
> > Paul
> >
> > PS: since we do parallel experiments with the Buildbot itself some packages 
> > are missing, please be aware that your milage may vary when testing package 
> > installation
> >
> > [1]: https://buildbot.staging.openwrt.org 
> > 
> > [2]: https://downloads.staging.openwrt.org/snapshots/targets/
> > [2]: apk add --allow-untrusted kmod-usb-serial-cp210x
> > [4]: https://github.com/openwrt/packages/issues/23706
> >
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: mpc85xx/p1010 buildboot issue

[Petr Štetiar]

Paweł Dembicki  [2024-08-23 12:15:03]:

 [ adding Christian and Luiz to the CC: loop ]

Hi,

> Buildbot had some issue with mpc85xx/p1010 subtarget:
> https://buildbot.openwrt.org/images/#/builders/231
> 
> It looks like only `osuosl-vm5-dock-02` can build this subtarget.
> Could someone look at this issue?

seems to be some race condition in the build system being exposed on a boxes 
with a specific I/O performance?

  [ ! -d 
"/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da"
 ] || rm -rf 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  /builder/shared-workdir/build/staging_dir/host/bin/mksquashfs4 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/target-dir-68b329da
 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/root.squashfs+pkg=68b329da
 -nopad -noappend -root-owned -comp xz -Xpreset 9 -Xe -Xlc 0 -Xlp 2 -Xpb 2 
-Xbcj powerpc -b 256k -p '/dev d 755 0 0' -p '/dev/console c 600 0 0 5 1' 
-no-xattrs
  mkdir 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  [ ! -d 
"/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da"
 ] || rm -rf 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  Parallel mksquashfs: Using 6 processors
  Creating 4.0 filesystem on 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/root.squashfs+pkg=68b329da,
 block size 262144.
  
  Pseudo file "dev" exists in source filesystem 
"/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/target-dir-68b329da/dev".
  Ignoring, exclude it (-e/-ef) to override.
  [|   ]   0/818   
0%cp -fpR 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47/.config
 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  mkdir 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  rm -f 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.prev
  mkdir: cannot create directory 
'/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da':
 File exists
  make[4]: *** [Makefile:24: 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/simpleImage.ws-ap3715i-initramfs.68b329da]
 Error 1
  make[4]: *** Waiting for unfinished jobs
  mv 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config
 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.old
  mv: failed to access 
'/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.old':
 Not a directory
  make[4]: *** [Makefile:27: 
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/simpleImage.br200-wp-initramfs.68b329da]
 Error 1


which leads me to the commit 97fd059e7e6a ("image: respect 
TARGET_PER_DEVICE_ROOTFS for initramfs") and I would be tempted to fix it via:

  --- a/include/kernel-defaults.mk
  +++ b/include/kernel-defaults.mk
  @@ -158,7 +158,7 @@ endef
 
  define Kernel/PrepareConfigPerRootfs
[ ! -d "$(1)" ] || rm -rf $(1)
 -  mkdir $(1)
 +  mkdir -p $(1)
  
$(CP) $(LINUX_DIR)/.config $(1)
  endef

but reading the reasoning in the commit:

  "To handle this, we prepare a config for each rootfs and we generate the
   images under lock to prevent problem with parallel execution."

it might not be actually desired, that devices are racing between each other
and doing that "rm -rf $(1)" ? So maybe some additional locking or even better
per device/rootfs directory would make more sense?


Cheers,

Petr

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

Re: BPI-R4-NIC-BE14

[Janusz Dziedzic]

wt., 20 sie 2024 o 15:50 Janusz Dziedzic  napisał(a):
>
> wt., 20 sie 2024 o 15:23 Janusz Dziedzic  
> napisał(a):
> >
> > Hello,
> >
> > Any hints about BE14 NIC - what should I enable in config. Does it work?
> > Have latest main and seems no pci output with BE14 inside BPI-R4.
> >
> Sorry for the noise.
> SW4 - on - after that module power on:
>
> root@OpenWrt:~# lspci
> :00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
> :01:00.0 Network controller: MEDIATEK Corp. Device 7990
> 0001:00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
> 0001:01:00.0 Network controller: MEDIATEK Corp. Device 7991
> root@OpenWrt:~#
> root@OpenWrt:~# ls /sys/class/ieee80211/
> phy0  phy1
> root@OpenWrt:~#

Any hint why I don't see 5GHz?
phy0 - report 2GHz
phy1 - report 6GHz

should one of them support both? Or should be another phyX? Or have
wrong firmware?

BR
Janusz

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

Re: BPI-R4-NIC-BE14

[Janusz Dziedzic]

wt., 20 sie 2024 o 15:23 Janusz Dziedzic  napisał(a):
>
> Hello,
>
> Any hints about BE14 NIC - what should I enable in config. Does it work?
> Have latest main and seems no pci output with BE14 inside BPI-R4.
>
Sorry for the noise.
SW4 - on - after that module power on:

root@OpenWrt:~# lspci
:00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
:01:00.0 Network controller: MEDIATEK Corp. Device 7990
0001:00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
0001:01:00.0 Network controller: MEDIATEK Corp. Device 7991
root@OpenWrt:~#
root@OpenWrt:~# ls /sys/class/ieee80211/
phy0  phy1
root@OpenWrt:~#

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

Re: realtek target needs help

[Bjørn Mork]

Bas Mevissen  writes:

>> The complete boot log from my initial attempt with @howels branch is
>> found here:
>> https://github.com/bmork/openwrt/commit/f858f8e78963693097256ca7498f46d35217db6a
>> The problem was the irq-realtek-rtl driver, and simply disabling our
>> VPE/SMP hack made it work again.  This should be fine on RTL838X.
>> But we do need someone with an RTL839X to test this, and maybe port
>> the
>> hack? Or preferable find some solution which can be pushed upstream...
>> 
>
> I'm willing to test. So please tell me how I can help.

I'm an amateur at this.  What I did was grep for the output before and
after lockup (based on successful v5.15 booting), and then sprinkle
debugging printk's all over the place.  Makes it possible to pinpoint
the exact location at least.



Bjørn


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

Re: realtek target needs help

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 14/08/2024 12:26, Bjørn Mork wrote:

Bas Mevissen via openwrt-devel  writes:


I acquired an HP 1920-24G and gave this branch a spin. Unfortunately,
it does not boot with this branch. Booting 23.05.4 and current main
branch are fine.


System application is starting...[0.00] Linux version 6.6.41 
(bas@lenovo) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 4
[0.00] RTL838X model is 83826800
[0.00] SoC Type: RTL8382
[0.00] printk: bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019070 (MIPS 4KEc)
[0.00] MIPS: machine is HPE 1920-24G (JG924A)
[0.00] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
[0.00] printk: bootconsole [ns16550a0] enabled
[0.00] Initrd not found or empty - disabling initrd
[0.00] Using appended Device Tree.
[0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[0.00] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 
bytes
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x07ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x07ff]
[0.00] Initmem setup node 0 [mem 0x-0x07ff]


So there is work to do. Not sure where to start as this is very early
in the kernel boot...


This is even earlier than expected so I'm unsure if there's another
problem here,. But I noticed that your normal boot log looks like the
console server is eating a few chars here and there:



Yes, I only use a lazy 3-wire serial line and a somewhat flaky RS232 to 
USB converter. Will be fine for console output and manual input.



[0.00] Initmem setup node 0 [mem 0x-0x07ff]
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists,
mobility grouping on.  Total pages: 32480
[0.00] Kernel command line: earlycon
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, 
linear)


So I'm crossing my fingers that this is what's happening to the
remaining part of the hanging boot too :-)

Please test https://github.com/bmork/openwrt/commits/realtek-6.6-test/
if you can.  It is mostly @howels test branch with a couple of
additional workarounds which made my GS108Tv3 work.



Same result:


Done!
System application is starting...[0.00] Linux version 6.6.41 
(bas@lenovo) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 r
27000-48454ae4da) 13.3.0, GNU ld (GNU Binutils) 2.42) #0 Thu Aug  8 06:54:39 
2024
[0.00] RTL838X model is 83826800
[0.00] SoC Type: RTL8382
[0.00] printk: bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019070 (MIPS 4KEc)
[0.00] MIPS: machine is HPE 1920-24G (JG924A)
[0.00] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
[0.00] printk: bootconsole [ns16550a0] enabled
[0.00] Initrd not found or empty - disabling initrd
[0.00] Using appended Device Tree.
[0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[0.00] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 
bytes
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x07ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x07ff]
[0.00] Initmem setup node 0 [mem 0x-0x07ff]


(pasted as quotation to avoid line breakage)



The complete boot log from my initial attempt with @howels branch is
found here:
https://github.com/bmork/openwrt/commit/f858f8e78963693097256ca7498f46d35217db6a

The problem was the irq-realtek-rtl driver, and simply disabling our
VPE/SMP hack made it work again.  This should be fine on RTL838X.

But we do need someone with an RTL839X to test this, and maybe port the
hack? Or preferable find some solution which can be pushed upstream...



I'm willing to test. So please tell me how I can help.

Bas.



Bjørn


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


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

Re: realtek target needs help

[Bjørn Mork]

Bas Mevissen via openwrt-devel  writes:

> I acquired an HP 1920-24G and gave this branch a spin. Unfortunately,
> it does not boot with this branch. Booting 23.05.4 and current main
> branch are fine.
>
>> System application is starting...[0.00] Linux version 6.6.41 
>> (bas@lenovo) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 4
>> [0.00] RTL838X model is 83826800
>> [0.00] SoC Type: RTL8382
>> [0.00] printk: bootconsole [early0] enabled
>> [0.00] CPU0 revision is: 00019070 (MIPS 4KEc)
>> [0.00] MIPS: machine is HPE 1920-24G (JG924A)
>> [0.00] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
>> [0.00] printk: bootconsole [ns16550a0] enabled
>> [0.00] Initrd not found or empty - disabling initrd
>> [0.00] Using appended Device Tree.
>> [0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 
>> bytes.
>> [0.00] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 
>> 16 bytes
>> [0.00] Zone ranges:
>> [0.00]   Normal   [mem 0x-0x07ff]
>> [0.00] Movable zone start for each node
>> [0.00] Early memory node ranges
>> [0.00]   node   0: [mem 0x-0x07ff]
>> [0.00] Initmem setup node 0 [mem 
>> 0x-0x07ff]
>
> So there is work to do. Not sure where to start as this is very early
> in the kernel boot...

This is even earlier than expected so I'm unsure if there's another
problem here,. But I noticed that your normal boot log looks like the
console server is eating a few chars here and there:

> [0.00] Initmem setup node 0 [mem 
> 0x-0x07ff]
> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists,
> mobility grouping on.  Total pages: 32480
> [0.00] Kernel command line: earlycon
> [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, 
> linear)

So I'm crossing my fingers that this is what's happening to the
remaining part of the hanging boot too :-)

Please test https://github.com/bmork/openwrt/commits/realtek-6.6-test/
if you can.  It is mostly @howels test branch with a couple of
additional workarounds which made my GS108Tv3 work.

The complete boot log from my initial attempt with @howels branch is
found here:
https://github.com/bmork/openwrt/commit/f858f8e78963693097256ca7498f46d35217db6a

The problem was the irq-realtek-rtl driver, and simply disabling our
VPE/SMP hack made it work again.  This should be fine on RTL838X.

But we do need someone with an RTL839X to test this, and maybe port the
hack? Or preferable find some solution which can be pushed upstream...


Bjørn


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

Re: realtek target needs help

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 12/08/2024 16:00, Paul D wrote:

On 2024-08-12 12:21, Bas Mevissen wrote:




All things being equal, is it worth a try with a different GCC version? Where 
GCC 13.3.4 boots, and 13.3.0... doesn't?




I checked that image from the firmware-selector again. That GCC version 
was just a screen artifact somehow. All use GCC 13.3.0. There isn't even 
an GCC 13.3.4 release.



BR,

Bas.

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

Re: realtek target needs help

[Paul D]

On 2024-08-12 12:21, Bas Mevissen wrote:
> 

All things being equal, is it worth a try with a different GCC version? Where 
GCC 13.3.4 boots, and 13.3.0... doesn't?



> 
> I acquired an HP 1920-24G and gave this branch a spin. Unfortunately, it does 
> not boot with this branch. Booting 23.05.4 and current main branch are fine.
> 
>> System application is starting...[    0.00] Linux version 6.6.41 
>> (bas@lenovo) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 4
>> [    0.00] RTL838X model is 83826800
>> [    0.00] SoC Type: RTL8382
>> [    0.00] printk: bootconsole [early0] enabled
>> [    0.00] CPU0 revision is: 00019070 (MIPS 4KEc)
>> [    0.00] MIPS: machine is HPE 1920-24G (JG924A)
>> [    0.00] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
>> [    0.00] printk: bootconsole [ns16550a0] enabled
>> [    0.00] Initrd not found or empty - disabling initrd
>> [    0.00] Using appended Device Tree.
>> [    0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 
>> bytes.
>> [    0.00] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 
>> 16 bytes
>> [    0.00] Zone ranges:
>> [    0.00]   Normal   [mem 0x-0x07ff]
>> [    0.00] Movable zone start for each node
>> [    0.00] Early memory node ranges
>> [    0.00]   node   0: [mem 0x-0x07ff]
>> [    0.00] Initmem setup node 0 [mem 
>> 0x-0x07ff]
> 
> So there is work to do. Not sure where to start as this is very early in the 
> kernel boot...
> 
> For reference, this is part of the boot from 
> https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=realtek%2Frtl838x&id=hpe_1920-24g
> 
>> System application is starting...[    0.00] Linux version 5.15.161 
>> (builder@buildhost) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.4
>> [    0.00] RTL838X model is 83826800
>> [    0.00] SoC Type: RTL8382
>> [    0.00] printk: bootconsole [early0] enabled
>> [    0.00] CPU0 revision is: 00019070 (MIPS 4KEc)
>> [    0.00] MIPS: machine is HPE 1920-24G (JG924A)
>> [    0.00] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
>> [    0.00] printk: bootconsole [ns16550a0] enabled
>> [    0.00] Initrd not found or empty - disabling initrd
>> [    0.00] Using appended Device Tree.
>> [    0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 
>> bytes.
>> [    0.00] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 
>> 16 bytes
>> [    0.00] Zone ranges:
>> [    0.00]   Normal   [mem 0x-0x07ff]
>> [    0.00] Movable zone start for each node
>> [    0.00] Early memory node ranges
>> [    0.00]   node   0: [mem 0x-0x07ff]
>> [    0.00] Initmem setup node 0 [mem 
>> 0x-0x07ff]

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

Re: realtek target needs help

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 08/08/2024 06:39, Luiz Angelo Daros de Luca wrote:

The realtek target supporting the Realtek switches is the only target in
OpenWrt main still on Linux kernel 5.15, all other targets are at least
on kernel 6.1, most of them are on Linux kernel 6.6.

The next OpenWrt major release will use kernel 6.6 only, all targets not
migrated to kernel 6.6 will get removed from OpenWrt before branching.
Looking at the status of OpenWrt main branch we will probably branch in
the next 2 months.

Here is the overview of the Linux kernel 6.6 migration status:
https://github.com/openwrt/openwrt/issues/15192

There is a pull request to drop the realtek target from OpenWrt main:
https://github.com/openwrt/openwrt/pull/16052

A migration of the realtek target to Linux kernel 6.1 was started here:
https://github.com/openwrt/openwrt/pull/12726


I noticed that #15192 metions
https://github.com/howels/openwrt/commits/realtek-6.6-test/ as the
development branch. Is anyone coordinating that front? Is there a TODO
list? I have some devices to play with (dgs-1210-28p and dgs-1210-52p)
and I can give a hand on specific topics but I do not have too much
time to lead it. There are some commits in that dev branch that are
actually disabling things. I might be able to work on fixing those
things or check what is useful from the 6.1 PR. However, I don't want
to step over someone's WIP and waste time in useless rework.



I acquired an HP 1920-24G and gave this branch a spin. Unfortunately, it 
does not boot with this branch. Booting 23.05.4 and current main branch 
are fine.



System application is starting...[0.00] Linux version 6.6.41 
(bas@lenovo) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 4
[0.00] RTL838X model is 83826800
[0.00] SoC Type: RTL8382
[0.00] printk: bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019070 (MIPS 4KEc)
[0.00] MIPS: machine is HPE 1920-24G (JG924A)
[0.00] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
[0.00] printk: bootconsole [ns16550a0] enabled
[0.00] Initrd not found or empty - disabling initrd
[0.00] Using appended Device Tree.
[0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[0.00] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 
bytes
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x07ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x07ff]
[0.00] Initmem setup node 0 [mem 0x-0x07ff]


So there is work to do. Not sure where to start as this is very early in 
the kernel boot...


For reference, this is part of the boot from 
https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=realtek%2Frtl838x&id=hpe_1920-24g



System application is starting...[0.00] Linux version 5.15.161 
(builder@buildhost) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.4
[0.00] RTL838X model is 83826800
[0.00] SoC Type: RTL8382
[0.00] printk: bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019070 (MIPS 4KEc)
[0.00] MIPS: machine is HPE 1920-24G (JG924A)
[0.00] earlycon: ns16550a0 at MMIO 0x18002000 (options '38400n8')
[0.00] printk: bootconsole [ns16550a0] enabled
[0.00] Initrd not found or empty - disabling initrd
[0.00] Using appended Device Tree.
[0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[0.00] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 
bytes
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x07ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x07ff]
[0.00] Initmem setup node 0 [mem 0x-0x07ff]
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 32480

[0.00] Kernel command line: earlycon
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, 
linear)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] Memory: 110240K/131072K available (6243K kernel code, 615K 
rwdata, 1380K rodata, 11016K init, 219K bss, 20832K reserved, 0K)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS: 2

Re: State of APK package manger integration

[Paul Spooren]

Hi all,

Some time has passed and there are further news for the APK migration:

Timo and Ansuel worked out a way to allow index trust[1]. If a package index is 
signed by a trusted key, all containing packages are automatically trusted. It 
is still possible distribute and sign single packages.

With this in place, the last missing bit was to teach our Buildbot 
infrastructure to sign indexes with the Buildmaster key[2]. For context, the 
OpenWrt project does not store private signing keys on Buildworkers but only on 
the Buildmaster. Indexes are transferred to the Buildmaster and signed there, 
later uploaded to the download server.

This, too, works now and can be tested for a limited number of targets/archs 
(if your favorite is missing, please ping me)[3].

The firmware contains a APK public key (in /etc/apk/keys) for testing[4] and 
the download server is modified[5]. The key is not official and will be 
replaced once things go further upstream.

If you run one of those images, please give APK a spin and see how it’s doing. 
A simple example would b to run the following:

apk add luci # install LuCI
apk audit # see what file changed since rootfs creation

Looking at the failing packages[6], some maintainers have not yet switches to 
an APK conform version schema. I’ll try to ping those or create PRs myself.

I’m optimistic’ish that things will work out just great. Please give it a test 
and let me know how it goes.

Best,
Paul

[1]: 
https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/54caa31be633efc5f655700b77af290124f71689
[2]: 
https://github.com/openwrt/buildbot/commit/a94d4e15fdc1e9715d7d0cfdcc62227186d0fc45
[3]: https://buildbot.aparcar.org/targets/
[4]: 
https://github.com/aparcar/openwrt/commit/de9b171c5a98c9e23e3da8b787ddc5ba7dd0ac53
[5]: 
https://github.com/aparcar/openwrt/commit/2c98eb52e365be6e59b470b4c0001cf29e8a6fb3
[6]: https://buildbot.aparcar.org/faillogs/x86_64/


> On 13. Jun 2024, at 13:29, Paul Spooren  wrote:
> 
> Dear all,
> 
> With great contributions from Timo, Ansuel, Jonas, Daniel, Petr, John, and 
> many others, APK is evolving smoothly, and the integration is progressing 
> well!
> 
> We have established a staging buildbot environment[1] that compiles firmware 
> images and certain packages. To replicate this setup locally, simply enable 
> “Use APK instead of OPKG to build distribution” (`USE_APK`) in the “Global 
> build settings”.
> 
> Once the firmware is compiled, it is uploaded to the staging downloads 
> page[2]. Currently, we have limited the targets created to a subset that we 
> have found useful for testing purposes.The firmware images boot up 
> successfully and allow for the installation of external feeds[3]!
> 
> Be aware, there is still some work required on the package feeds to 
> accommodate the new version requirements. If you are maintaining something, 
> please take a look (e.g. [4]).
> 
> We are facing an architectural challenge that needs to be addressed. In the 
> past, both OPKG and APKv2 would only sign the package indexes and 
> automatically trust the included packages. With APKv3 (the version we are 
> using), each individual package is signed. We are exploring ways to securely 
> integrate this into the existing setup, where build workers do not have a 
> private key but upload the package index to a dedicated server for signing. 
> We will keep you updated on our progress.
> 
> I will provide more updates as we make further advancements. Please stay 
> tuned for more information.
> 
> Sunshine,
> Paul
> 
> PS: since we do parallel experiments with the Buildbot itself some packages 
> are missing, please be aware that your milage may vary when testing package 
> installation
> 
> [1]: https://buildbot.staging.openwrt.org 
> 
> [2]: https://downloads.staging.openwrt.org/snapshots/targets/
> [2]: apk add --allow-untrusted kmod-usb-serial-cp210x
> [4]: https://github.com/openwrt/packages/issues/23706
> 



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Buildbots missing for ipq60xx?

[Daniel Nilsson via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Ah that makes sense, thanks for the insights and a fast reply!

/ Daniel

On Saturday, August 10th, 2024 at 21:22, Stefan Lippers-Hollmann  
wrote:
>
>
> Hi
>
> On 2024-08-10, Daniel Nilsson via openwrt-devel wrote:
>
> > I was taking a look at the ipq60xx target, and noticed that none of
> > it's devices are available on the firmware selector. I saw on
> > https://buildbot.openwrt.org/images/#/builders that the target doesn't
> > have a builder, is this the reason why the devices are missing?
>
>
> qualcommax/ipq60xx is explicitly marked as source-only and intentionally
> not built on the buildbots, yet:
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/qualcommax/ipq60xx/target.mk
>
> AFAIK the major reason for that is the current state of the wireless
> firmware for ath11k not playing nice with the (typically older) BDF
> definitions for its devices.
>
> > With the upcoming branching of 24.x, it would be good to have that
> > configured so it at least gets built as part of the next release.
>
>
> It won't be part of the next release, until this is resolved and the
> source-only flag gets removed - pending a new (and official, not via
> third parties) wireless firmware release from QCA.
>
> Regards
> Stefan Lippers-Hollmann

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

Re: Buildbots missing for ipq60xx?

[Stefan Lippers-Hollmann via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi

On 2024-08-10, Daniel Nilsson via openwrt-devel wrote:
> I was taking a look at the ipq60xx target, and noticed that none of 
> it's devices are available on the firmware selector. I saw on 
> https://buildbot.openwrt.org/images/#/builders that the target doesn't 
> have a builder, is this the reason why the devices are missing? 

qualcommax/ipq60xx is explicitly marked as source-only and intentionally
not built on the buildbots, yet:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/qualcommax/ipq60xx/target.mk

AFAIK the major reason for that is the current state of the wireless
firmware for ath11k not playing nice with the (typically older) BDF
definitions for its devices.

> With the upcoming branching of 24.x, it would be good to have that 
> configured so it at least gets built as part of the next release.

It won't be part of the next release, until this is resolved and the 
source-only flag gets removed - pending a new (and official, not via 
third parties) wireless firmware release from QCA.

Regards
Stefan Lippers-Hollmann


pgpoUDeNUHhFd.pgp
Description: Digitale Signatur von OpenPGP
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek target needs help

[Luiz Angelo Daros de Luca]

> The realtek target supporting the Realtek switches is the only target in
> OpenWrt main still on Linux kernel 5.15, all other targets are at least
> on kernel 6.1, most of them are on Linux kernel 6.6.
>
> The next OpenWrt major release will use kernel 6.6 only, all targets not
> migrated to kernel 6.6 will get removed from OpenWrt before branching.
> Looking at the status of OpenWrt main branch we will probably branch in
> the next 2 months.
>
> Here is the overview of the Linux kernel 6.6 migration status:
> https://github.com/openwrt/openwrt/issues/15192
>
> There is a pull request to drop the realtek target from OpenWrt main:
> https://github.com/openwrt/openwrt/pull/16052
>
> A migration of the realtek target to Linux kernel 6.1 was started here:
> https://github.com/openwrt/openwrt/pull/12726

I noticed that #15192 metions
https://github.com/howels/openwrt/commits/realtek-6.6-test/ as the
development branch. Is anyone coordinating that front? Is there a TODO
list? I have some devices to play with (dgs-1210-28p and dgs-1210-52p)
and I can give a hand on specific topics but I do not have too much
time to lead it. There are some commits in that dev branch that are
actually disabling things. I might be able to work on fixing those
things or check what is useful from the 6.1 PR. However, I don't want
to step over someone's WIP and waste time in useless rework.

Regards,

Luiz

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

Re: [PATCH V2 0/3] Enhance GL-MV1000 support

[Robert Marko]

Merged, thanks.

Regards,
Robert

On Mon, 29 Jul 2024 at 09:56, Enrico Mioso  wrote:
>
> Hello all,
>
> as you might already have guessed, this is just a friendly ping.
>
> Thanks,
> Enrico
>
> On Tue, Jul 02, 2024 at 06:09:06PM +0200, Enrico Mioso wrote:
> > This series contains some already submitted patches to enhance GL.iNet
> > GL-MV1000 support, enabling easier boot media selection (SD card vs internal
> > MMC) without forcing boot to stock firmware or connecting to UART.
> >
> > Changes since V1:
> > - better approach (different kernel config option) to enable 4K writes
> >
> > Signed-off-by: Enrico Mioso 
> >
> > Enrico Mioso (3):
> >   mvebu: GL-MV1000: add custom boot script
> >   mvebu: enable CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE=y config option
> >   mvebu: GL-MV1000: let u-boot-env be writable again
> >
> >  target/linux/mvebu/config-6.6 |  1 +
> >  .../dts/marvell/armada-3720-gl-mv1000.dts |  1 -
> >  target/linux/mvebu/image/cortexa53.mk |  1 +
> >  target/linux/mvebu/image/gl-mv1000.bootscript | 28 +++
> >  4 files changed, 30 insertions(+), 1 deletion(-)
> >  create mode 100644 target/linux/mvebu/image/gl-mv1000.bootscript
> >
> > --
> > 2.45.2
> >
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: realtek target needs help

[Tim Small via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
In the past, I've done some very minor work to add support for some 
Realtek switch variants (not merged as-yet).


If anyone would like to get involved with this, it might be worth 
looking for a used HP 1920-24G switch.  This has good support in OpenWrt 
23.05, reasonable storage, lowish power usage (for a 24 port gigabit 
switch with an additional 4 SFP ports), is fanless, includes an external 
serial console port (RS232 with "Cisco" type pinout on an 8P8C 
connector), and the hardware also includes a lifetime warranty.  When 
looking for online auctions etc. the following are useful search terms 
(the switch was sold under both the HP and HPE brands):


HP 1920-24G
HPE 1920-24G
JG924A

... check for "JG924A" printed on the front panel to ensure it's the 
correct model.


Used prices in the UK are under GBP 30 including shipping (that's circa 
Euro 35 or USD 38).


Third party Cisco pinout RS232 to USB serial console adapters are under 
GBP 10 if you don't already have suitable hardware.


I'm away from the location where I have my hardware for the next 3 weeks 
or so, so won't be able to help out with anything for a while unfortunately.


Cheers,

Tim.

On 03/08/2024 13:15, Hauke Mehrtens wrote:
The realtek target supporting the Realtek switches is the only target in 
OpenWrt main still on Linux kernel 5.15, all other targets are at least 
on kernel 6.1, most of them are on Linux kernel 6.6.


The next OpenWrt major release will use kernel 6.6 only, all targets not 
migrated to kernel 6.6 will get removed from OpenWrt before branching. 
Looking at the status of OpenWrt main branch we will probably branch in 
the next 2 months.


Here is the overview of the Linux kernel 6.6 migration status:
https://github.com/openwrt/openwrt/issues/15192

There is a pull request to drop the realtek target from OpenWrt main:
https://github.com/openwrt/openwrt/pull/16052

A migration of the realtek target to Linux kernel 6.1 was started here:
https://github.com/openwrt/openwrt/pull/12726

Hauke

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


--
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309

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

Re: [PATCH] mediatek: fix u-boot env layout NVMEM definitions

[Robert Marko]

On Tue, 30 Jul 2024 at 10:46, Enrico Mioso  wrote:
>
> s/u-boot,env-layout/u-boot,env/g
>
> Signed-off-by: Enrico Mioso 

Thanks,
Merged via: 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=6bb334c5cf1c96a208c8dab93123476248b78254

Regards,
Robert

> ---
>  .../mediatek/dts/mt7981a-glinet-gl-x3000-xe3000-common.dtsi   | 2 +-
>  target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts| 2 +-
>  target/linux/mediatek/dts/mt7981b-unielec-u7981-01-emmc.dts   | 2 +-
>  target/linux/mediatek/dts/mt7986a-glinet-gl-mt6000.dts| 2 +-
>  .../arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso | 2 +-
>  .../arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-sd.dtso   | 2 +-
>  .../patches-6.6/911-dts-mt7622-bpi-r64-add-rootdisk.patch | 4 ++--
>  7 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git 
> a/target/linux/mediatek/dts/mt7981a-glinet-gl-x3000-xe3000-common.dtsi 
> b/target/linux/mediatek/dts/mt7981a-glinet-gl-x3000-xe3000-common.dtsi
> index e9050e02e5..919fb23c53 100644
> --- a/target/linux/mediatek/dts/mt7981a-glinet-gl-x3000-xe3000-common.dtsi
> +++ b/target/linux/mediatek/dts/mt7981a-glinet-gl-x3000-xe3000-common.dtsi
> @@ -148,7 +148,7 @@
> partname = "u-boot-env";
>
> nvmem-layout {
> -   compatible = 
> "u-boot,env-layout";
> +   compatible = "u-boot,env";
> };
> };
>
> diff --git a/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts 
> b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> index 15818a90fc..0bd3ac0a29 100644
> --- a/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> +++ b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> @@ -164,7 +164,7 @@
> block-partition-u-boot-env {
> partname = "u-boot-env";
> nvmem-layout {
> -   compatible = 
> "u-boot,env-layout";
> +   compatible = "u-boot,env";
> };
> };
> };
> diff --git a/target/linux/mediatek/dts/mt7981b-unielec-u7981-01-emmc.dts 
> b/target/linux/mediatek/dts/mt7981b-unielec-u7981-01-emmc.dts
> index abd4d4e59d..264c985612 100644
> --- a/target/linux/mediatek/dts/mt7981b-unielec-u7981-01-emmc.dts
> +++ b/target/linux/mediatek/dts/mt7981b-unielec-u7981-01-emmc.dts
> @@ -32,7 +32,7 @@
> partname = "u-boot-env";
>
> nvmem-layout {
> -   compatible = 
> "u-boot,env-layout";
> +   compatible = "u-boot,env";
> };
> };
>
> diff --git a/target/linux/mediatek/dts/mt7986a-glinet-gl-mt6000.dts 
> b/target/linux/mediatek/dts/mt7986a-glinet-gl-mt6000.dts
> index fd0e1a6915..fe55f2ea3a 100644
> --- a/target/linux/mediatek/dts/mt7986a-glinet-gl-mt6000.dts
> +++ b/target/linux/mediatek/dts/mt7986a-glinet-gl-mt6000.dts
> @@ -325,7 +325,7 @@
> partname = "u-boot-env";
>
> nvmem-layout {
> -   compatible = 
> "u-boot,env-layout";
> +   compatible = "u-boot,env";
> };
> };
>
> diff --git 
> a/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso
>  
> b/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso
> index 4945185d69..cd266d6b0f 100644
> --- 
> a/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso
> +++ 
> b/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso
> @@ -41,7 +41,7 @@
> block-partition-env {
> partname = "ubootenv";
> nvmem-layout {
> -   compatible = 
> "u-boot,env-layout";
> +   compatible = 
> "u-boot,env";
> };
> };
> emmc_rootfs: 
> block-partition-production {
> diff --git 
> a/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-sd.dtso
>  
> b/target/li

Re: BPI-R4: Copper SFP issues

[Martin Schiller]

On 2024-08-01 10:22, Daniel Golle wrote:

On 1 August 2024 07:26:35 UTC, Martin Schiller  wrote:

Hi!

I've got some issues bringing up copper SFPs in a BananaPi BPI-R4 
runnig
the latest OpenWrt master. Using the original Firmware pre-installed 
on

the BPI-R4 makes the modules work as expected:

I've tested with a HPE J8177C 1GBASE-T module as well as with a FS
SFP-10G-T module.

Any ideas what could be wrong here?

Here are the debug log outputs:


[   81.554779] mtk_soc_eth 1510.ethernet eth2: validation with 
support 00,,, failed: -EINVAL

[   81.565458] sfp sfp1: sfp_add_phy failed: -EINVAL
[   81.570155] sfp sfp1: SM: exit present:up:fail


Looks like you are simply missing kmod-phy-marvell as well as
kmod-phy-marvell-10g. Do you have those driver module packages
installed?


Thank you very much for this hint. Adding the kmod-phy-marvell makes the
1G-BASE-T module working.

The FS SFP-10G-T is still not working, but I've found some fixes for
this module in linux v6.9 and v6.10.

I'll try to backport this changes.

Thanks,
Martin

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

Re: BPI-R4: Copper SFP issues

[Daniel Golle]

On 1 August 2024 07:26:35 UTC, Martin Schiller  wrote:
>Hi!
>
>I've got some issues bringing up copper SFPs in a BananaPi BPI-R4 runnig
>the latest OpenWrt master. Using the original Firmware pre-installed on
>the BPI-R4 makes the modules work as expected:
>
>I've tested with a HPE J8177C 1GBASE-T module as well as with a FS
>SFP-10G-T module.
>
>Any ideas what could be wrong here?
>
>Here are the debug log outputs:

>[   81.554779] mtk_soc_eth 1510.ethernet eth2: validation with support 
>00,,, failed: -EINVAL
>[   81.565458] sfp sfp1: sfp_add_phy failed: -EINVAL
>[   81.570155] sfp sfp1: SM: exit present:up:fail

Looks like you are simply missing kmod-phy-marvell as well as 
kmod-phy-marvell-10g. Do you have those driver module packages installed?

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

Re: Applying arch specific patch to package from feeds

[Andre Heider]

Hi,

On 29/07/2024 4:31 pm, Nishant Sharma wrote:

Hello,

How can I apply a patch to a package from the feed, only when the 
architecture is say, ramips but not when it is x86_64 or mips.


This should work:
PATCH_DIR:=./patches-$(ARCH)
and then throw it in ./patches-ramips

But generally speaking you should avoid that, as e.g. refreshing patches 
becomes fragile. Use ifdefery to make the code arch depended instead.




If I put the patch in package's patch directory, it gets applied 
unconditionally.


Thanks in advance for the pointers.

Regards,
Nishant

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



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

Re: [PATCH] kernel: module: usb: remove deprecated Kconfig option CONFIG_XHCI_HCD_DEBUGGING

[Florian Eckert]

Hello Hauke


--- /dev/null
+++ 
b/patches/openwrt/30066-kernel-modules-usb-remove-deprecated-Kconfig-option-CONFIG_USB_XHCI_HCD_DEBUGGING.patch

@@ -0,0 +1,36 @@
+From: Florian Eckert 
+Date: Wed, 17 Jul 2024 11:42:58 +0200
+Subject: [PATCH] kernel: modules: usb: remove deprecated Kconfig 
option

+ CONFIG_USB_XHCI_HCD_DEBUGGING
+
+Redmine-patch-id: 8668
+The Kconfig option 'CONFIG_USB_XHCI_HCD_DEBUGGING' has been removed 
with the

+following commit upstream in the Linux kernel.
+
+https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b2497509df002e9a09c8550cd0ecd2f77c9640d8
+
+This Kconfig option is therefore no longer valid for the kernel 
version

+6.6 and should musst be removed.
+
+Signed-off-by: Florian Eckert 
+---
+ package/kernel/linux/modules/usb.mk | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/package/kernel/linux/modules/usb.mk 
b/package/kernel/linux/modules/usb.mk
+index 
12725f10ee25d9ba83e67763f0c41a338aac5542..b0037378342149275571d3e836c44a439a145bc5 
100644

+--- a/package/kernel/linux/modules/usb.mk
 b/package/kernel/linux/modules/usb.mk
+@@ -1846,9 +1846,7 @@ $(eval $(call KernelPackage,usb-roles))
+
+ define KernelPackage/usb-xhci-hcd
+   TITLE:=xHCI HCD (USB 3.0) support
+-  KCONFIG:= \
+-CONFIG_USB_XHCI_HCD \
+-CONFIG_USB_XHCI_HCD_DEBUGGING=n
++  KCONFIG:= CONFIG_USB_XHCI_HCD
+   HIDDEN:=1
+   FILES:=$(LINUX_DIR)/drivers/usb/host/xhci-hcd.ko
+   AUTOLOAD:=$(call AutoLoad,54,xhci-hcd,1)
+--
+

Hi Florian,

This patch looks strange. This looks like a patch for your internal
build system. ;-)


You're absolutely right! It must be the heat!
I've already sent a new one.

Thanks

Florian

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

Re: [PATCH] kernel: module: usb: remove deprecated Kconfig option CONFIG_XHCI_HCD_DEBUGGING

[Hauke Mehrtens]

On 7/26/24 10:07, Florian Eckert wrote:

The kconfig option 'CONFIG_XHCI_HCD_DEBUGGING' was removed with commit:

https://github.com/torvalds/linux/commit/b2497509df002e9a09c8550cd0ecd2f77c9640d8

Signed-off-by: Florian Eckert 
---
  ...option-CONFIG_USB_XHCI_HCD_DEBUGGING.patch | 36 +++
  1 file changed, 36 insertions(+)
  create mode 100644 
patches/openwrt/30066-kernel-modules-usb-remove-deprecated-Kconfig-option-CONFIG_USB_XHCI_HCD_DEBUGGING.patch

diff --git 
a/patches/openwrt/30066-kernel-modules-usb-remove-deprecated-Kconfig-option-CONFIG_USB_XHCI_HCD_DEBUGGING.patch
 
b/patches/openwrt/30066-kernel-modules-usb-remove-deprecated-Kconfig-option-CONFIG_USB_XHCI_HCD_DEBUGGING.patch
new file mode 100644
index 00..0f54807fec
--- /dev/null
+++ 
b/patches/openwrt/30066-kernel-modules-usb-remove-deprecated-Kconfig-option-CONFIG_USB_XHCI_HCD_DEBUGGING.patch
@@ -0,0 +1,36 @@
+From: Florian Eckert 
+Date: Wed, 17 Jul 2024 11:42:58 +0200
+Subject: [PATCH] kernel: modules: usb: remove deprecated Kconfig option
+ CONFIG_USB_XHCI_HCD_DEBUGGING
+
+Redmine-patch-id: 8668
+The Kconfig option 'CONFIG_USB_XHCI_HCD_DEBUGGING' has been removed with the
+following commit upstream in the Linux kernel.
+
+https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b2497509df002e9a09c8550cd0ecd2f77c9640d8
+
+This Kconfig option is therefore no longer valid for the kernel version
+6.6 and should musst be removed.
+
+Signed-off-by: Florian Eckert 
+---
+ package/kernel/linux/modules/usb.mk | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/package/kernel/linux/modules/usb.mk 
b/package/kernel/linux/modules/usb.mk
+index 
12725f10ee25d9ba83e67763f0c41a338aac5542..b0037378342149275571d3e836c44a439a145bc5
 100644
+--- a/package/kernel/linux/modules/usb.mk
 b/package/kernel/linux/modules/usb.mk
+@@ -1846,9 +1846,7 @@ $(eval $(call KernelPackage,usb-roles))
+
+ define KernelPackage/usb-xhci-hcd
+   TITLE:=xHCI HCD (USB 3.0) support
+-  KCONFIG:= \
+-CONFIG_USB_XHCI_HCD \
+-CONFIG_USB_XHCI_HCD_DEBUGGING=n
++  KCONFIG:= CONFIG_USB_XHCI_HCD
+   HIDDEN:=1
+   FILES:=$(LINUX_DIR)/drivers/usb/host/xhci-hcd.ko
+   AUTOLOAD:=$(call AutoLoad,54,xhci-hcd,1)
+--
+

Hi Florian,

This patch looks strange. This looks like a patch for your internal 
build system. ;-)


Hauke

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

Re: files for jailed process's

[e9hack]

Am 30.07.2024 um 17:29 schrieb Daniel Golle:

On Tue, Jul 30, 2024 at 03:40:25PM +0200, e9hack wrote:

Hi,

if a process is started via procd in a jail and uses some files, changes to 
those files outside the jail are not reflected inside the jail. For  E.g. 
dnsmasq runs in a jail. The configuration is changed, that only the host file 
does change. Sending SIGHUP to dnsmasq results in reloading of the unmodified 
host file.

Is it possible to change this behaviour?


What you are observing is typically caused by the file being replaced
rather than edited. In that case, the mount-bind on the old file will
remain, and you will not be able to access the new (replacement) file
inside the jail. This is due to the nature of mount --bind which
attaches itself to a specific inode on the filesystem rather than to
a filename.

There are two ways to work around this problem:
1. Actually edit instead of replace the file.

2. procd_add_jail_mount_ro a folder instead of a file. In that way, the
replaced file will also show up.


dnsmasq.init replaces the host file but mounts usually the folder of the
host file. I've two instances of dnsmasq running, which needs different
host files. I set the option 'ignore_hosts_dir=1' for both instances.



As in most cases only strategy 2 is truely a good option we have already
moved resolv.conf.auto into a folder of its own. If the same problem
also occurs for other dnsmasq config files, we shall introduce a folder
for all of them and add that using procd_add_jail_mount_ro to make it
accessible inside the jail instead of calling procd_add_jail_mount_ro for
individual files.


I think for the host file is this necessary and maybe for all files, which
dnsmasq can reload at SIGHUP.


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

Re: files for jailed process's

[Daniel Golle]

On Tue, Jul 30, 2024 at 03:40:25PM +0200, e9hack wrote:
> Hi,
> 
> if a process is started via procd in a jail and uses some files, changes to 
> those files outside the jail are not reflected inside the jail. For  E.g. 
> dnsmasq runs in a jail. The configuration is changed, that only the host file 
> does change. Sending SIGHUP to dnsmasq results in reloading of the unmodified 
> host file.
> 
> Is it possible to change this behaviour?

What you are observing is typically caused by the file being replaced
rather than edited. In that case, the mount-bind on the old file will
remain, and you will not be able to access the new (replacement) file
inside the jail. This is due to the nature of mount --bind which
attaches itself to a specific inode on the filesystem rather than to
a filename.

There are two ways to work around this problem:
1. Actually edit instead of replace the file.

2. procd_add_jail_mount_ro a folder instead of a file. In that way, the
replaced file will also show up.

As in most cases only strategy 2 is truely a good option we have already
moved resolv.conf.auto into a folder of its own. If the same problem
also occurs for other dnsmasq config files, we shall introduce a folder
for all of them and add that using procd_add_jail_mount_ro to make it
accessible inside the jail instead of calling procd_add_jail_mount_ro for
individual files.

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Paul Spooren]

Sure, https://github.com/cyyself/wg-bench/pull/37

> On 29. Jul 2024, at 19:37, Paul D  wrote:
> 
> 
> Hi, could one of the early ONE owners/users post numbers for the ONE 
> regarding WireGuard performance?
> 
> https://forum.openwrt.org/t/a-wireguard-comparison-db/187586/1
> 
> It's an important use-case and a factor affecting the decision for next 
> hardware purchase (for me, anyway).
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Jonathan lancett via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 29/07/2024 18:37, Paul D wrote:

Hi, could one of the early ONE owners/users post numbers for the ONE regarding 
WireGuard performance?

https://forum.openwrt.org/t/a-wireguard-comparison-db/187586/1

It's an important use-case and a factor affecting the decision for next 
hardware purchase (for me, anyway).


No one has one yet mate. I have bin asking, but
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel




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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Paul D]

Hi, could one of the early ONE owners/users post numbers for the ONE regarding 
WireGuard performance?

https://forum.openwrt.org/t/a-wireguard-comparison-db/187586/1

It's an important use-case and a factor affecting the decision for next 
hardware purchase (for me, anyway).



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

Re: [PATCH V2 0/3] Enhance GL-MV1000 support

[Enrico Mioso]

Hello all,

as you might already have guessed, this is just a friendly ping.

Thanks,
Enrico

On Tue, Jul 02, 2024 at 06:09:06PM +0200, Enrico Mioso wrote:
> This series contains some already submitted patches to enhance GL.iNet
> GL-MV1000 support, enabling easier boot media selection (SD card vs internal
> MMC) without forcing boot to stock firmware or connecting to UART.
> 
> Changes since V1:
> - better approach (different kernel config option) to enable 4K writes
> 
> Signed-off-by: Enrico Mioso 
> 
> Enrico Mioso (3):
>   mvebu: GL-MV1000: add custom boot script
>   mvebu: enable CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE=y config option
>   mvebu: GL-MV1000: let u-boot-env be writable again
> 
>  target/linux/mvebu/config-6.6 |  1 +
>  .../dts/marvell/armada-3720-gl-mv1000.dts |  1 -
>  target/linux/mvebu/image/cortexa53.mk |  1 +
>  target/linux/mvebu/image/gl-mv1000.bootscript | 28 +++
>  4 files changed, 30 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/mvebu/image/gl-mv1000.bootscript
> 
> -- 
> 2.45.2
> 

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

Re: [PATCH] netifd: add support for dhcp fallback to static ip

[Roman Yeryomin]

On 2024-07-14 22:39, Roman Yeryomin wrote:

It is pretty common use case for a network device to be configured
as DHCP client but having some fallback static IP address where it
would be reachable for, e.g., configuration.

This adds 'fallbackip' network config option, which will be used
on an interface until device receives an IP from DHCP server.



Hi Felix, I hope I got your points on this implementation in the right 
way.

Would be nice to hear what is your word on this!

Regards,
Roman

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

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Paul D]

On 2024-07-18 18:31, Henrique de Moraes Holschuh via openwrt-devel wrote:
> 
> OpenWRT has its hotplug via procd, which is different, but it should still be 
> usable for that kind of *required* functionality.  What the wiki describes 
> for "usbmisc" hotplug does *not* look good, hopefully the wiki is incomplete. 
>  Otherwise, procd should be improved and meanwhile, you need to deploy a 
> script to handle that event that does the follow-the-symlinks game in sysfs 
> to go from usblp to usb endpoint, and get the necessary device data from 
> there.

usbmisc is complete from last I dived into it - I updated the wiki with my 
findings when working with printers (usbmisc class devices).

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

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Henrique de Moraes Holschuh via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 18/07/2024 11:47, Sam Kuper wrote:

After all, the commit message suggests the developer didn't anticipate this 
commit causing breakage.


More like they don't expect it to cause breakage when a suitable 
userspace solution to the issue of non-deterministic probing order is 
deployed for hotplug handling (and that includes coldplug on hotplug 
buses).  Almost everything else that is a hotplug bus already does this 
(PCIe, SATA, SAS...).


I suppose it would be a regression if it happened to land through a 
stable update, especially if it landed in a LTS kernel.  But if it 
landed on 6.6, I very much doubt it will be reverted.


On typical desktops, you'd use udev to rename the node to something 
static, or add a symlink, etc.


OpenWRT has its hotplug via procd, which is different, but it should 
still be usable for that kind of *required* functionality.  What the 
wiki describes for "usbmisc" hotplug does *not* look good, hopefully the 
wiki is incomplete.  Otherwise, procd should be improved and meanwhile, 
you need to deploy a script to handle that event that does the 
follow-the-symlinks game in sysfs to go from usblp to usb endpoint, and 
get the necessary device data from there.


--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações 
(Ceptro.br)

+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br


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

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Sam Kuper]

On 18 July 2024 09:53:14 UTC, Florian Eckert  wrote:
> 
> I found a commit [1] in the Linux kernel that makes the USB
> controller probing asynchronous and therefore not deterministic as
> before. I have reverted the commit on my build and now nothing
> changes in the controller numbering. This is not a solution, but
> I now know what the problem is. With a new kernel, the numbering
> can be completely different again.
> 
> From my point of view, that's a general problem, that USB controller
> does not have a fix sysfs path. In my case, I explicitly refer to
> a USB device sysfs path in the network configuration that the
> modemmanager should use. I can't work with serial number, pid, vid.
> I think also the udev service will also not help there.
> 
> The question is how to get a unambiguous that is the same after every
> boot even if the kernel changes the probing behavior. On the PCI bus
> there is always unambiguous number.
> 
> [...]
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=69a1c9a9b273271f2a2674bcc117336a9bb0a4b4


Might it be best to file a bug report against the Linux kernel?

After all, the commit message suggests the developer didn't anticipate this 
commit causing breakage.

Yet it seems the commit is causing serious breakage, likely to stop many 
people's routers, PCs or other devices to stop being able to use peripherals 
(network adapters, printers, cameras, who knows what else?) as expected, with 
no easy workaround.

Sorry if I've misunderstood. 

Sam

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

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Paul D]

I can see this affecting USB network devices.


In my experience of working with p910nd, I used sysfs also. Deterministic 
probing order is important if the order of discovered USB printers is to remain 
the same (so that port 9100 always talks to your HP at /dev/usb/lp0, port 9101 
always talks to your Brother at /dev/usb/lp1, mutatis mutandis). To prevent 
soft-bricking when sending a (driver) blob, the script would only send to 
devices identified using the below properties. While I could not (yet) affect 
the port ordering of /dev/usb/lpX character device assignments (first detected 
gets first assignment), I could ensure the right blob went to the right device.


The files below presented in sysfs help to build an unmistakable identity of 
device type, in this case:

bInterfaceClass
bInterfaceSubClass
idVendor
idProduct

( /sys/bus/usb/devices/*/idVendor )

and also the following if you have multiple identical device types:

iSerialNumber


These files might allow non-deterministic ordering or presentation such that a 
moved device can still be reconciled. Certain other files at this location 
might provide better anchoring. Be aware that some USB devices can have 
multiple connection modes, i.e. bNumConfigurations and bConfigurationValue ( 
e.g. press button, device mounts file-system with drivers, press button, device 
then changes config to connect printer etc )

For reconciliation, store contents of several of the files found in 
/sys/bus/usb/devices/*/ ) for matching, e.g. as a CSV in configuration:

{idVendor},{idProduct},{iSerialNumber},{bInterfaceClass},{bInterfaceSubClass}


Some info:
https://beyondlogic.org/usbnutshell/usb5.shtml
https://openwrt.org/docs/guide-user/base-system/hotplug


Open to suggestions if there's a 'better' way to do this, but this way I think 
one can disregard a sysfs path and be certain that one has found the same 
'device'.




On 2024-07-18 11:53, Florian Eckert wrote:
> Hello Felix
> 
>>> Boot 1:
>>> -> lrwxrwxrwx    1 root root 0 Jul 17 12:56 2-1.3:1.0 ->
>>> ../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.0
>>> -> lrwxrwxrwx    1 root root 0 Jul 17 12:56 2-1.3:1.1 ->
>>> ../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.1
>>> -> lrwxrwxrwx    1 root root 0 Jul 17 12:56 2-1.3:1.2 ->
>>> ../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.2
>>> -> lrwxrwxrwx    1 root root 0 Jul 17 12:56 2-1.3:1.3 ->
>>> ../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.3
> 
>>> Boot 2:
>>> -> lrwxrwxrwx    1 root root 0 Jul 17 12:43 1-1.3:1.0 ->
>>> ../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.0
>>> -> lrwxrwxrwx    1 root root 0 Jul 17 12:43 1-1.3:1.1 ->
>>> ../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.1
>>> -> lrwxrwxrwx    1 root root 0 Jul 17 12:43 1-1.3:1.2 ->
>>> ../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.2
>>> -> lrwxrwxrwx    1 root root 0 Jul 17 12:43 1-1.3:1.3 ->
>>> ../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.3
> 
>> Oh, right. The main issue here is the fact that the device ids in the
>> path contain the bus number as initial component.
> 
> That is correct. The bus number is incremented with each new USB controller.
> The number assigned to the controller is allocated in the order in which it
> is probed (first come first serve).
> 
>> I guess the syntax
>> could be something like: "pci:00/:00:12.0%"
>> To resolve it, it would look up the bus number from the controller
>> path and then use /sys/bus/usb/devices/- as the device path.
> 
> On my APU3 I have four USB busses.
> lrwxrwxrwx    1 root root 0 Jul 18 11:10 usb1 -> 
> ../../../devices/pci:00/:00:12.0/usb1
> lrwxrwxrwx    1 root root 0 Jul 18 11:10 usb2 -> 
> ../../../devices/pci:00/:00:13.0/usb2
> lrwxrwxrwx    1 root root 0 Jul 18 11:17 usb3 -> 
> ../../../devices/pci:00/:00:10.0/usb3
> lrwxrwxrwx    1 root root 0 Jul 18 11:17 usb4 -> 
> ../../../devices/pci:00/:00:10.0/usb4
> 
> usb1 an ehci on PCI :00:12.0
> usb2 an ehci on PCI :00:13.0
> usb3 an xhci on PCI :00:10.0
> usb4 an xhci on PCI :00:10.0
> 
> I have an USB modem on PCI :00:13.0 that can be reached under
> either bus number 1 or bus number 2 depending on when the controller
> was proped in the boot sequence. The xhci controllers on PCI
> :00:10.0 always get the bus number 3 and bus number 4.
> The ehci is probed before xhci.
> 
> I found a commit [1] in the Linux kernel that makes the USB
> controller probing asynchronous and therefore not deterministic as
> before. I have reverted the commit on my build and now nothing
> changes in the controller numbering. This is not a solution, but
> I now know what the problem is. With a new kernel, the numbering
> can be com

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Florian Eckert]

Hello Felix


Boot 1:
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.0 
->

../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.0
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.1 
->

../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.1
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.2 
->

../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.2
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.3 
->

../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.3



Boot 2:
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.0 
->

../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.0
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.1 
->

../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.1
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.2 
->

../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.2
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.3 
->

../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.3



Oh, right. The main issue here is the fact that the device ids in the
path contain the bus number as initial component.


That is correct. The bus number is incremented with each new USB 
controller.
The number assigned to the controller is allocated in the order in which 
it

is probed (first come first serve).


I guess the syntax
could be something like: "pci:00/:00:12.0%"
To resolve it, it would look up the bus number from the controller
path and then use /sys/bus/usb/devices/- as the device path.


On my APU3 I have four USB busses.
lrwxrwxrwx1 root root 0 Jul 18 11:10 usb1 -> 
../../../devices/pci:00/:00:12.0/usb1
lrwxrwxrwx1 root root 0 Jul 18 11:10 usb2 -> 
../../../devices/pci:00/:00:13.0/usb2
lrwxrwxrwx1 root root 0 Jul 18 11:17 usb3 -> 
../../../devices/pci:00/:00:10.0/usb3
lrwxrwxrwx1 root root 0 Jul 18 11:17 usb4 -> 
../../../devices/pci:00/:00:10.0/usb4


usb1 an ehci on PCI :00:12.0
usb2 an ehci on PCI :00:13.0
usb3 an xhci on PCI :00:10.0
usb4 an xhci on PCI :00:10.0

I have an USB modem on PCI :00:13.0 that can be reached under
either bus number 1 or bus number 2 depending on when the controller
was proped in the boot sequence. The xhci controllers on PCI
:00:10.0 always get the bus number 3 and bus number 4.
The ehci is probed before xhci.

I found a commit [1] in the Linux kernel that makes the USB
controller probing asynchronous and therefore not deterministic as
before. I have reverted the commit on my build and now nothing
changes in the controller numbering. This is not a solution, but
I now know what the problem is. With a new kernel, the numbering
can be completely different again.

From my point of view, that's a general problem, that USB controller
does not have a fix sysfs path. In my case, I explicitly refer to
a USB device sysfs path in the network configuration that the
modemmanager should use. I can't work with serial number, pid, vid.
I think also the udev service will also not help there.

The question is how to get a unambiguous that is the same after every
boot even if the kernel changes the probing behavior. On the PCI bus
there is always unambiguous number.

Best regards
Florian

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=69a1c9a9b273271f2a2674bcc117336a9bb0a4b4


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

Re: A PCIe E-Key interface would have great advantages

[Janusz Dziedzic]

śr., 17 lip 2024 o 17:50 Schmid, Florian
 napisał(a):
>
> Hi,
> i have only recently started working with OpenWrt. I think the project of an 
> own hardware platform is great. I don't know how far the development has 
> progressed. However, I am missing a very important interface in the hardware 
> specification!
> A PCIe M.2 E-Key interface would open the way for the use of the new WiFi-7 
> modules from various manufacturers (e.g. FG8276MPUX from FN-Link, WMX8202 
> from EmWicon, NONI56M2-4x4 or BE200.NGW.NV from Intel and others).  This 
> means that the entire frequency range (2.4GHz, 5GHz and 5GHz) specified in 
> IEEE802.11be can be used. WiFi-8 is still in the future, but will probably 
> also use PCIe E-Key as an interface.
>

Hi,
I am using M2 NVM + M2+AE converter + intel/qualcom m2 cards in my BPI-R4.
So, probably openwrt ONE will also work.

Today have in my BPI-R4:
root@bpi-r4-92bab365400b:~# lspci
:00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
:01:00.0 Unclassified device [0002]: MEDIATEK Corp. MT7915E
802.11ax PCI Express Wireless Network Adapter
0001:00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
0001:01:00.0 Network controller: Qualcomm Technologies, Inc WCN785x
Wi-Fi 7(802.11be) 320MHz 2x2 [FastConnect 7800] (rev 01)
0002:00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01)
0002:01:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)

https://pl.aliexpress.com/item/1005005872611013.html?spm=a2g0o.order_list.order_list_main.5.1bc01c24pkisos&gatewayAdapt=glo2pol

But, yes great if there could be another M2 slot.

BR
Janusz

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

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Felix Fietkau]

On 17.07.24 14:29, Florian Eckert wrote:

In my opinion, the best course of action is to just deal with it by
changing the code to no longer rely on usbX names. Better make it
depend on the sysfs path, similar to wifi-device path handling in the
wireless config.


I am already using the sysfs path, but if the usbX name changes then
also the
sysfs path changes as well! See the devices I have attached '->'. Or am
I
misunderstanding you?

Boot 1:
root@G3-10940 /sys/bus/usb/devices # ls -la | grep usb
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-0:1.0 ->
../../../devices/pci:00/:00:12.0/usb1/1-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-1 ->
../../../devices/pci:00/:00:12.0/usb1/1-1
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-1.2 ->
../../../devices/pci:00/:00:12.0/usb1/1-1/1-1.2
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-1.2:1.0 ->
../../../devices/pci:00/:00:12.0/usb1/1-1/1-1.2/1-1.2:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-1:1.0 ->
../../../devices/pci:00/:00:12.0/usb1/1-1/1-1:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-0:1.0 ->
../../../devices/pci:00/:00:13.0/usb2/2-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1 ->
../../../devices/pci:00/:00:13.0/usb2/2-1
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3 ->
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.0 ->
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.0
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.1 ->
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.1
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.2 ->
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.2
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.3 ->
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.3
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.4 ->
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.4
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1:1.0 ->
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 3-0:1.0 ->
../../../devices/pci:00/:00:10.0/usb3/3-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 4-0:1.0 ->
../../../devices/pci:00/:00:10.0/usb4/4-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 usb1 ->
../../../devices/pci:00/:00:12.0/usb1
lrwxrwxrwx1 root root 0 Jul 17 12:56 usb2 ->
../../../devices/pci:00/:00:13.0/usb2

Boot 2:
root@G3-10940 /sys/bus/usb/devices # ls -la | grep usb
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-0:1.0 ->
../../../devices/pci:00/:00:13.0/usb1/1-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1 ->
../../../devices/pci:00/:00:13.0/usb1/1-1
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3 ->
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.0 ->
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.0
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.1 ->
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.1
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.2 ->
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.2
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.3 ->
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.3
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.4 ->
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.4
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1:1.0 ->
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:43 2-0:1.0 ->
../../../devices/pci:00/:00:12.0/usb2/2-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:43 2-1 ->
../../../devices/pci:00/:00:12.0/usb2/2-1
lrwxrwxrwx1 root root 0 Jul 17 12:43 2-1.2 ->
../../../devices/pci:00/:00:12.0/usb2/2-1/2-1.2
lrwxrwxrwx1 root root 0 Jul 17 12:43 2-1.2:1.0 ->
../../../devices/pci:00/:00:12.0/usb2/2-1/2-1.2/2-1.2:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:43 2-1:1.0 ->
../../../devices/pci:00/:00:12.0/usb2/2-1/2-1:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:43 usb1 ->
../../../devices/pci:00/:00:13.0/usb1
lrwxrwxrwx1 root root 0 Jul 17 12:43 usb2 ->
../../../devices/pci:00/:00:12.0/usb2


Oh, right. The main issue here is the fact that the device ids in the 
path contain the bus number as initial component. I guess the syntax 
could be

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Enrico Mioso]

Hello,

if things work as expected, MM will auto-discover the modem.
You may get sysfs path from mmcli itself and dynamically set it viauci.

I didn't use very much this protocol handler, so I do not have better 
suggestions.
Genuine question: are we sure sysfs path is necessary in the config?

Enrico

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

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Florian Eckert]

Hello Felix,

thanks for your reply.


As you can see the usb1 and usb2 are swapped!

The problem now is that the ModemManager is using the syspath
to reference the modem in the uci configuration [2]. If the modem's
syspath is now random, the system can no longer find the modem and
cannot establish a connection.

1. Does anyone have the same problem?
2. Is the path of usb randomly intentional?
3. Can I somehow force the path across a restart?


I think the most likely cause is more parallelization in device probe
in order to speed up boot time. Not sure if there is a way to make it
deterministic, but even if there is, it might still change across
kernel upgrades.


I have already thought that this is probably due to when the device is
ready and then the driver is loaded to speed up the load time during 
boot.



In my opinion, the best course of action is to just deal with it by
changing the code to no longer rely on usbX names. Better make it
depend on the sysfs path, similar to wifi-device path handling in the
wireless config.


I am already using the sysfs path, but if the usbX name changes then 
also the
sysfs path changes as well! See the devices I have attached '->'. Or am 
I

misunderstanding you?

Boot 1:
root@G3-10940 /sys/bus/usb/devices # ls -la | grep usb
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-0:1.0 -> 
../../../devices/pci:00/:00:12.0/usb1/1-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-1 -> 
../../../devices/pci:00/:00:12.0/usb1/1-1
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-1.2 -> 
../../../devices/pci:00/:00:12.0/usb1/1-1/1-1.2
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-1.2:1.0 -> 
../../../devices/pci:00/:00:12.0/usb1/1-1/1-1.2/1-1.2:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 1-1:1.0 -> 
../../../devices/pci:00/:00:12.0/usb1/1-1/1-1:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-0:1.0 -> 
../../../devices/pci:00/:00:13.0/usb2/2-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1 -> 
../../../devices/pci:00/:00:13.0/usb2/2-1
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3 -> 
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.0 -> 
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.0
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.1 -> 
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.1
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.2 -> 
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.2
-> lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.3 -> 
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.3
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1.3:1.4 -> 
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.4
lrwxrwxrwx1 root root 0 Jul 17 12:56 2-1:1.0 -> 
../../../devices/pci:00/:00:13.0/usb2/2-1/2-1:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 3-0:1.0 -> 
../../../devices/pci:00/:00:10.0/usb3/3-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 4-0:1.0 -> 
../../../devices/pci:00/:00:10.0/usb4/4-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:56 usb1 -> 
../../../devices/pci:00/:00:12.0/usb1
lrwxrwxrwx1 root root 0 Jul 17 12:56 usb2 -> 
../../../devices/pci:00/:00:13.0/usb2


Boot 2:
root@G3-10940 /sys/bus/usb/devices # ls -la | grep usb
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-0:1.0 -> 
../../../devices/pci:00/:00:13.0/usb1/1-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1 -> 
../../../devices/pci:00/:00:13.0/usb1/1-1
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3 -> 
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.0 -> 
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.0
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.1 -> 
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.1
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.2 -> 
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.2
-> lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.3 -> 
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.3
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1.3:1.4 -> 
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.4
lrwxrwxrwx1 root root 0 Jul 17 12:43 1-1:1.0 -> 
../../../devices/pci:00/:00:13.0/usb1/1-1/1-1:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:43 2-0:1.0 -> 
../../../devices/pci:00/:00:12.0/usb2/2-0:1.0
lrwxrwxrwx1 root root 0 Jul 17 12:43 

Re: USB controller enumeration on APU3 is random since the update to kernel 6.6

[Felix Fietkau]

On 17.07.24 13:10, Florian Eckert wrote:

Hello Dev´s,

I hope someone can help me here. I have noticed since the
kernel update in the master branch of OpenWrt to 6.6 that
the enumeration of the USB host controllers is suddenly
randomly.

This has been encountered on the APU3 board from PCengine[1].

That wasn't the case with the 5.15 kernel before, or I didn't
notice it. I also don't know if it must have fixed paths
so that the USB host controllers always have the same path.

Boot1
lrwxrwxrwx1 root root 0 Jul 17 12:43 usb1 ->
../../../devices/pci:00/:00:13.0/usb1
lrwxrwxrwx1 root root 0 Jul 17 12:43 usb2 ->
../../../devices/pci:00/:00:12.0/usb2
lrwxrwxrwx1 root root 0 Jul 17 12:43 usb3 ->
../../../devices/pci:00/:00:10.0/usb3
lrwxrwxrwx1 root root 0 Jul 17 12:43 usb4 ->
../../../devices/pci:00/:00:10.0/usb4

Boot2
lrwxrwxrwx1 root root 0 Jul 17 12:56 usb1 ->
../../../devices/pci:00/:00:12.0/usb1
lrwxrwxrwx1 root root 0 Jul 17 12:56 usb2 ->
../../../devices/pci:00/:00:13.0/usb2
lrwxrwxrwx1 root root 0 Jul 17 12:56 usb3 ->
../../../devices/pci:00/:00:10.0/usb3
lrwxrwxrwx1 root root 0 Jul 17 12:56 usb4 ->
../../../devices/pci:00/:00:10.0/usb4

As you can see the usb1 and usb2 are swapped!

The problem now is that the ModemManager is using the syspath
to reference the modem in the uci configuration [2]. If the modem's
syspath is now random, the system can no longer find the modem and
cannot establish a connection.

1. Does anyone have the same problem?
2. Is the path of usb randomly intentional?
3. Can I somehow force the path across a restart?


I think the most likely cause is more parallelization in device probe in 
order to speed up boot time. Not sure if there is a way to make it 
deterministic, but even if there is, it might still change across kernel 
upgrades.


In my opinion, the best course of action is to just deal with it by 
changing the code to no longer rely on usbX names. Better make it depend 
on the sysfs path, similar to wifi-device path handling in the wireless 
config.


- Felix

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

Re: [RFC] netifd: add support for dhcp fallback to static ip

[Roman Yeryomin]

On 2024-07-14 14:11, Felix Fietkau wrote:

On 14.07.24 11:47, Roman Yeryomin wrote:

On 2024-07-14 10:42, Felix Fietkau wrote:

On 14.07.24 02:34, Roman Yeryomin wrote:

It is pretty common use case for a network device to be configured
as DHCP client but having some fallback static IP address where it
would be reachable for, e.g., configuration.

This reacts on udhcpc events and sets/removes ipaddr which is
configured on an iface from network config.
This means that for an interface with proto set to dhcp but with
fallback static IP disabled (ipaddr parameter is not set in config)
cost of this feature is one uci call.
If static fallback is enabled (ipaddr is present) then the cost is
3 uci calls and one ip call for each deconfig/renew/bound udhcpc
event.
It is not nothing but to me it seem like it's a very small overhead
for such a convenience and I think it should be OpenWrt default at
least for targets with one ethernet port.

Signed-off-by: Roman Yeryomin 
---
diff --git 
a/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh 
b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh

new file mode 100644
index 00..79984e9a2f
--- /dev/null
+++ 
b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh

@@ -0,0 +1,23 @@
+#!/bin/sh
+
+[ -z "$1" ] && echo "Error: should be run by udhcpc" && exit 1
+
+ipaddr=$(uci get network.$INTERFACE.ipaddr)
+[ -z "$ipaddr" ] && exit 0
+
+ifname=$(uci get network.$INTERFACE.ifname)
+[ -z "$ifname" ] && exit 0
+
+netmask=$(uci get network.$INTERFACE.netmask)
+[ -z "$netmask" ] && netmask=24
+
+case "$1" in
+   deconfig)
+   ip ad add $ipaddr/$netmask dev $ifname
+   ;;
+   renew|bound)
+   ip ad del $ipaddr dev $ifname
+   ;;
+esac
+
+exit 0


Here's my take on this patch:

1. The feature should be opt-in via an extra config option, since it
changes the behavior in a meaningful way that might be problematic 
for

some users.
2. IP addresses should be set from within netifd, e.g. via the same
mechanism that the dhcp script uses to bring up the interface.
3. IP settings should not be read directly from uci, but passed down
from the netifd proto handler, e.g. via env vars.



Agree on 2. and 3.
Can't say I agree on 1. -- could you please give an example in which
situation it could be problematic?


If you use the ipaddr to request a specific address from the DHCP
server, but don't want the link to be up when the server is not
reachable.


Ah, got it, let me send updated version then with 'fallbackip' option.

Regards,
Roman

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

Re: [RFC] netifd: add support for dhcp fallback to static ip

[Felix Fietkau]

On 14.07.24 11:47, Roman Yeryomin wrote:

On 2024-07-14 10:42, Felix Fietkau wrote:

On 14.07.24 02:34, Roman Yeryomin wrote:

It is pretty common use case for a network device to be configured
as DHCP client but having some fallback static IP address where it
would be reachable for, e.g., configuration.

This reacts on udhcpc events and sets/removes ipaddr which is
configured on an iface from network config.
This means that for an interface with proto set to dhcp but with
fallback static IP disabled (ipaddr parameter is not set in config)
cost of this feature is one uci call.
If static fallback is enabled (ipaddr is present) then the cost is
3 uci calls and one ip call for each deconfig/renew/bound udhcpc
event.
It is not nothing but to me it seem like it's a very small overhead
for such a convenience and I think it should be OpenWrt default at
least for targets with one ethernet port.

Signed-off-by: Roman Yeryomin 
---
diff --git 
a/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh 
b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh

new file mode 100644
index 00..79984e9a2f
--- /dev/null
+++ 
b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh

@@ -0,0 +1,23 @@
+#!/bin/sh
+
+[ -z "$1" ] && echo "Error: should be run by udhcpc" && exit 1
+
+ipaddr=$(uci get network.$INTERFACE.ipaddr)
+[ -z "$ipaddr" ] && exit 0
+
+ifname=$(uci get network.$INTERFACE.ifname)
+[ -z "$ifname" ] && exit 0
+
+netmask=$(uci get network.$INTERFACE.netmask)
+[ -z "$netmask" ] && netmask=24
+
+case "$1" in
+   deconfig)
+   ip ad add $ipaddr/$netmask dev $ifname
+   ;;
+   renew|bound)
+   ip ad del $ipaddr dev $ifname
+   ;;
+esac
+
+exit 0


Here's my take on this patch:

1. The feature should be opt-in via an extra config option, since it
changes the behavior in a meaningful way that might be problematic for
some users.
2. IP addresses should be set from within netifd, e.g. via the same
mechanism that the dhcp script uses to bring up the interface.
3. IP settings should not be read directly from uci, but passed down
from the netifd proto handler, e.g. via env vars.



Agree on 2. and 3.
Can't say I agree on 1. -- could you please give an example in which
situation it could be problematic?


If you use the ipaddr to request a specific address from the DHCP 
server, but don't want the link to be up when the server is not reachable.


- Felix

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

Re: [RFC] netifd: add support for dhcp fallback to static ip

[Roman Yeryomin]

On 2024-07-14 10:42, Felix Fietkau wrote:

On 14.07.24 02:34, Roman Yeryomin wrote:

It is pretty common use case for a network device to be configured
as DHCP client but having some fallback static IP address where it
would be reachable for, e.g., configuration.

This reacts on udhcpc events and sets/removes ipaddr which is
configured on an iface from network config.
This means that for an interface with proto set to dhcp but with
fallback static IP disabled (ipaddr parameter is not set in config)
cost of this feature is one uci call.
If static fallback is enabled (ipaddr is present) then the cost is
3 uci calls and one ip call for each deconfig/renew/bound udhcpc
event.
It is not nothing but to me it seem like it's a very small overhead
for such a convenience and I think it should be OpenWrt default at
least for targets with one ethernet port.

Signed-off-by: Roman Yeryomin 
---
diff --git 
a/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh 
b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh

new file mode 100644
index 00..79984e9a2f
--- /dev/null
+++ 
b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh

@@ -0,0 +1,23 @@
+#!/bin/sh
+
+[ -z "$1" ] && echo "Error: should be run by udhcpc" && exit 1
+
+ipaddr=$(uci get network.$INTERFACE.ipaddr)
+[ -z "$ipaddr" ] && exit 0
+
+ifname=$(uci get network.$INTERFACE.ifname)
+[ -z "$ifname" ] && exit 0
+
+netmask=$(uci get network.$INTERFACE.netmask)
+[ -z "$netmask" ] && netmask=24
+
+case "$1" in
+   deconfig)
+   ip ad add $ipaddr/$netmask dev $ifname
+   ;;
+   renew|bound)
+   ip ad del $ipaddr dev $ifname
+   ;;
+esac
+
+exit 0


Here's my take on this patch:

1. The feature should be opt-in via an extra config option, since it
changes the behavior in a meaningful way that might be problematic for
some users.
2. IP addresses should be set from within netifd, e.g. via the same
mechanism that the dhcp script uses to bring up the interface.
3. IP settings should not be read directly from uci, but passed down
from the netifd proto handler, e.g. via env vars.



Agree on 2. and 3.
Can't say I agree on 1. -- could you please give an example in which 
situation it could be problematic?


Thanks for feedback!

Regards,
Roman

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

Re: [RFC] netifd: add support for dhcp fallback to static ip

[Felix Fietkau]

On 14.07.24 02:34, Roman Yeryomin wrote:

It is pretty common use case for a network device to be configured
as DHCP client but having some fallback static IP address where it
would be reachable for, e.g., configuration.

This reacts on udhcpc events and sets/removes ipaddr which is
configured on an iface from network config.
This means that for an interface with proto set to dhcp but with
fallback static IP disabled (ipaddr parameter is not set in config)
cost of this feature is one uci call.
If static fallback is enabled (ipaddr is present) then the cost is
3 uci calls and one ip call for each deconfig/renew/bound udhcpc
event.
It is not nothing but to me it seem like it's a very small overhead
for such a convenience and I think it should be OpenWrt default at
least for targets with one ethernet port.

Signed-off-by: Roman Yeryomin 
---
diff --git 
a/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh 
b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh
new file mode 100644
index 00..79984e9a2f
--- /dev/null
+++ b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+[ -z "$1" ] && echo "Error: should be run by udhcpc" && exit 1
+
+ipaddr=$(uci get network.$INTERFACE.ipaddr)
+[ -z "$ipaddr" ] && exit 0
+
+ifname=$(uci get network.$INTERFACE.ifname)
+[ -z "$ifname" ] && exit 0
+
+netmask=$(uci get network.$INTERFACE.netmask)
+[ -z "$netmask" ] && netmask=24
+
+case "$1" in
+   deconfig)
+   ip ad add $ipaddr/$netmask dev $ifname
+   ;;
+   renew|bound)
+   ip ad del $ipaddr dev $ifname
+   ;;
+esac
+
+exit 0


Here's my take on this patch:

1. The feature should be opt-in via an extra config option, since it 
changes the behavior in a meaningful way that might be problematic for 
some users.
2. IP addresses should be set from within netifd, e.g. via the same 
mechanism that the dhcp script uses to bring up the interface.
3. IP settings should not be read directly from uci, but passed down 
from the netifd proto handler, e.g. via env vars.


- Felix

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

[PATCH 2/2] omap: re-enable target

[Jan Hoffmann]

The target was marked source-only due do the broken Ethernet port on
some devices. With that fixed, it can be enabled again.

Signed-off-by: Jan Hoffmann 
---
 target/linux/omap/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/omap/Makefile b/target/linux/omap/Makefile
index fc0842d056e4..a3c61efc9ab2 100644
--- a/target/linux/omap/Makefile
+++ b/target/linux/omap/Makefile
@@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=omap
 BOARDNAME:=TI OMAP3/4/AM33xx
-FEATURES:=usb usbgadget ext4 targz fpu audio display nand rootfs-part squashfs 
source-only
+FEATURES:=usb usbgadget ext4 targz fpu audio display nand rootfs-part squashfs
 CPU_TYPE:=cortex-a8
 CPU_SUBTYPE:=vfpv3
 SUBTARGETS:=generic
-- 
2.45.2


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

Re: Can't build 6.6 kernel for x86_64

[Philip Prindeville via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Was able to get a build with:

--- a/kernel-config
+++ b/kernel-config
@@ -35,6 +35,8 @@ CONFIG_CHR_DEV_SG=m
 CONFIG_CLZ_TAB=y
 CONFIG_COREDUMP=y
 CONFIG_CRASH_DUMP=y
+CONFIG_CRASH_HOTPLUG=y
+CONFIG_CRASH_MAX_MEMORY_RANGES=8192
 CONFIG_CRYPTO_ABLK_HELPER=y
 CONFIG_CRYPTO_AKCIPHER=y
 CONFIG_CRYPTO_AKCIPHER2=y
@@ -67,6 +69,8 @@ CONFIG_CRYPTO_HW=y
 CONFIG_CRYPTO_JITTERENTROPY=y
 CONFIG_CRYPTO_KPP=y
 CONFIG_CRYPTO_KPP2=y
+# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
+# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
 CONFIG_CRYPTO_MD5=m
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_POLY1305=y


> On Jul 10, 2024, at 9:55 PM, Philip Prindeville 
>  wrote:
> 
> Hi,
> 
> I rebased Sunday to HEAD on master because it had been over a year since I 
> updated my firmware, and I'm thinking either the config is broken or I missed 
> a step.
> 
> I have a env/kernel-config file but after I rebased, reindexed with 
> "scripts/feeds update -i && scripts/feeds install -a", and did "make 
> oldconfig defconfig", nothing in my kernel-config seemed to change.
> 
> And when I built, I got this:
> 
> ...
> + x86_64-openwrt-linux-musl-ld -m elf_x86_64 -z noexecstack 
> --no-warn-rwx-segments -z max-page-size=0x20 --build-id=sha1 -X 
> --orphan-handling=warn --script=./arch/x86/kernel/vmlinux.lds --strip-debug 
> -o .tmp_vmlinux.kallsyms1 --whole-archive vmlinux.a .vmlinux.export.o 
> init/version-timestamp.o --no-whole-archive --start-group --end-group
> x86_64-openwrt-linux-musl-ld: 
> drivers/crypto/intel/qat/qat_common/qat_comp_algs.o: in function 
> `qat_comp_algs_register':
> /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:478:(.text+0xbec):
>  undefined reference to `crypto_register_acomps'
> x86_64-openwrt-linux-musl-ld: 
> drivers/crypto/intel/qat/qat_common/qat_comp_algs.o: in function 
> `qat_comp_algs_unregister':
> /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/drivers/crypto/intel/qat/qat_common/qat_comp_algs.c:487:(.text+0xc48):
>  undefined reference to `crypto_unregister_acomps'
> make[7]: *** [scripts/Makefile.vmlinux:37: vmlinux] Error 1
> make[6]: *** 
> [/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/Makefile:1164:
>  vmlinux] Error 2
> make[5]: *** [Makefile:234: __sub-make] Error 2
> make[5]: Leaving directory 
> '/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36'
> make[4]: *** [Makefile:26: 
> /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.36/.modules]
>  Error 2
> make[4]: Leaving directory '/home/philipp/lede/target/linux/x86'
> make[3]: *** [Makefile:11: compile] Error 2
> make[3]: Leaving directory '/home/philipp/lede/target/linux'
> time: target/linux/compile#2821.60#261.82#3080.51
>ERROR: target/linux failed to build.
> make[2]: *** [target/Makefile:32: target/linux/compile] Error 1
> make[2]: Leaving directory '/home/philipp/lede'
> make[1]: *** [target/Makefile:25: 
> /home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.target_compile] 
> Error 2
> make[1]: Leaving directory '/home/philipp/lede'
> make: *** [/home/philipp/lede/include/toplevel.mk:248: world] Error 2
> 
> 
> I unset "CONFIG_PACKAGE_kmod-crypto-acompress" in my .config and set 
> "CONFIG_CRYPTO_ACOMP2=y" in my kernel-config, but no joy.
> 
> What am I missing?  And what are the steps to refresh your kernel config 
> after a rebase?
> 
> Thanks,
> 
> -Philip
> 


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

Re: Pass option from /etc/config/wireless to hostapd config

[Moritz Warning via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

haha, it does.

Thank you :-)

On 7/5/24 09:12, Gio wrote:

Hi!

The first file of this patchset

https://github.com/G10h4ck/openwrt/commit/555fd77fdeaaf2a893c5d41180b84e693b43b336

should answer your question ;-)

Cheers

On 2024-07-04 22:08, Moritz Warning via openwrt-devel wrote:

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.

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



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

Re: Pass option from /etc/config/wireless to hostapd config

[Gio]

Hi!

The first file of this patchset

https://github.com/G10h4ck/openwrt/commit/555fd77fdeaaf2a893c5d41180b84e693b43b336

should answer your question ;-)

Cheers

On 2024-07-04 22:08, Moritz Warning via openwrt-devel wrote:

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.

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


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

Re: legal question for VRX518

[Robert Marko]

On Tue, 2 Jul 2024 at 16:39, Paul D  wrote:
>
> https://forum.openwrt.org/t/vrx518-firmware-license-change-can-it-be-included-now/202141

There is a PR already open:
https://github.com/openwrt/openwrt/pull/15550#issuecomment-2148823067

Regards,
Robert
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [PATCH 2/2] mvebu: enable 4K sectors config option

[Enrico Mioso]

On Mon, Jul 01, 2024 at 11:52:05AM +0200, Thibaut wrote:
> Hi,
> 
> Disclaimer: I know nothing about this arch or this hw, however this CONFIG 
> will make the entire flash storage significantly slower. Have you considered 
> CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE ? It allows writing to partitions that 
> do not fit a 64K EB by selectively using 4K EB.
> 
> Cheers,
> T

Hi!

I didn't know about this option. I will try that out and come back with result.

Thanks a lot,

Enrico



> 
> > Le 1 juil. 2024 à 09:37, Enrico Mioso  a écrit :
> > 
> > Enable the CONFIG_MTD_SPI_NOR_USE_4K_SECTORS kernel option to allow for
> > U-Boot environment writing. This might be hiding a problem somewhere else,
> > since the w25q128fw chip supports 32K erases, still this change makes it
> > much easier to switch the GL-MV1000 boot media without an UART cable
> > connection.
> > 
> > Thanks to @robimarko for the precious hints.
> > 
> > Signed-off-by: Enrico Mioso 
> > ---
> > target/linux/mvebu/config-6.6 | 1 +
> > 1 file changed, 1 insertion(+)
> > 
> > diff --git a/target/linux/mvebu/config-6.6 b/target/linux/mvebu/config-6.6
> > index 88e5fff4d9..b8302eb798 100644
> > --- a/target/linux/mvebu/config-6.6
> > +++ b/target/linux/mvebu/config-6.6
> > @@ -270,6 +270,7 @@ CONFIG_MTD_NAND_ECC_SW_HAMMING=y
> > CONFIG_MTD_NAND_MARVELL=y
> > CONFIG_MTD_RAW_NAND=y
> > CONFIG_MTD_SPI_NOR=y
> > +CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
> > CONFIG_MTD_SPLIT_FIRMWARE=y
> > CONFIG_MTD_UBI=y
> > CONFIG_MTD_UBI_BEB_LIMIT=20
> > -- 
> > 2.45.2
> > 
> > 
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

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

Re: [PATCH 2/2] mvebu: enable 4K sectors config option

[Thibaut]

Hi,

Disclaimer: I know nothing about this arch or this hw, however this CONFIG will 
make the entire flash storage significantly slower. Have you considered 
CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE ? It allows writing to partitions that do 
not fit a 64K EB by selectively using 4K EB.

Cheers,
T

> Le 1 juil. 2024 à 09:37, Enrico Mioso  a écrit :
> 
> Enable the CONFIG_MTD_SPI_NOR_USE_4K_SECTORS kernel option to allow for
> U-Boot environment writing. This might be hiding a problem somewhere else,
> since the w25q128fw chip supports 32K erases, still this change makes it
> much easier to switch the GL-MV1000 boot media without an UART cable
> connection.
> 
> Thanks to @robimarko for the precious hints.
> 
> Signed-off-by: Enrico Mioso 
> ---
> target/linux/mvebu/config-6.6 | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/target/linux/mvebu/config-6.6 b/target/linux/mvebu/config-6.6
> index 88e5fff4d9..b8302eb798 100644
> --- a/target/linux/mvebu/config-6.6
> +++ b/target/linux/mvebu/config-6.6
> @@ -270,6 +270,7 @@ CONFIG_MTD_NAND_ECC_SW_HAMMING=y
> CONFIG_MTD_NAND_MARVELL=y
> CONFIG_MTD_RAW_NAND=y
> CONFIG_MTD_SPI_NOR=y
> +CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
> CONFIG_MTD_SPLIT_FIRMWARE=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_BEB_LIMIT=20
> -- 
> 2.45.2
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


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

Re: [RFC PATCH 00/14] odhcpd config value clamping

[Paul D]

Any comments?



On 2024-05-10 00:30, Paul Donald wrote:
> Clamp values read from config to RFC mandated sane values instead of just
> complaining. We also now implement valid_lifetime for ULA prefixes.
> This is useful if you need to sunset or remove one from circulation.
> ( Interestingly, if you spin up dev devices frequently which spam the
> network with new ULA each time, which have no expiry, interesting things
> start to happen. )
> Fixed also a bug in MTU handling.
> 
> Paul Donald (14):
>   config: refactor parse_leasetime() - branch amount remains same
>   router: Apply updated values from RFC8319 (updates RFC4861) to RA/ND
>   config: clamp ra_mininterval, ra_maxinterval, ra_lifetime at load time
>   router: refactor calc_ra_lifetime, and define ra_lifetime as uint32_t
>   router: redefine ra_mininterval and ra_maxinterval as uint32_t
>   config: implement RFC4861 AdvValidLifetime (make configurable)
>   config: lease times are all UINT32_MAX; drop double size handling
>   router: clamp prefix valid_lt to interface valid_lifetime
>   config: clamp ra_reachabletime to RFC maximum (instead of complaining)
>   config: clamp ra_hoplimit to maximum (instead of complaining)
>   config: clamp ra_retranstime
>   config: clamp ra_mtu into 1280-65535 range
>   config: clamp dhcpv6_hostid_len
>   config: clamp dhcpv6_pd_min_len
> 
>  README   |   2 +
>  src/config.c | 162 +--
>  src/odhcpd.h |   7 ++-
>  src/router.c |  34 +--
>  src/router.h |  25 +++-
>  5 files changed, 148 insertions(+), 82 deletions(-)
> 


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

Re: [RFC PATCH 0/1] odhcpd uses also interafce dns_search

[Paul D]

Any comments?


On 2024-04-10 03:16, Paul Donald wrote:
> From: Paul Donald 
> 
> Applies to master d8118f6e76e5519881f9a37137c3a06b3cb60fd2
> 
> Naïve implementation. Works well. 
> 
> Might have drawbacks: it parses interfaces, so if they happen to have the 
> same parameter names, ???
> 
> The idea seems worth implementing.
> 
> 
> Paul Donald (1):
>   config: use network interface 'dns_search' and dhcp 'domain'
> 
>  src/config.c | 26 --
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 


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

Re: Next OpenWrt 23.05 and 22.03 minor releases

[Hauke Mehrtens]

Hi Goetz,

I think Rosen can best comment on that.

We anyway build the packages continually and they are not tied to a 
release.


Hauke

On 6/29/24 13:18, Goetz Goerisch wrote:

Hi Hauke,

How about package backports?

There are a few pending in openwrt/packages for 23.05 and 22.03 incl.
a security fix as far as I can tell from the description?

https://github.com/openwrt/packages/pulls?q=is%3Apr+is%3Aopen+%5B23.05%5D

Goetz


Am Do., 27. Juni 2024 um 20:21 Uhr schrieb Hauke Mehrtens :


Hi,

I am planning a new minor release of the 23.05 series and the final
release of the 22.03 series in about 1 week.

If you want some commits backported please answer to this mail with the
upstream commit hash or create a PR on github for the stable branch.

PRs for OpenWrt 23.05:
https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F23.05+sort%3Aupdated-desc

PRs for OpenWrt 22.03:
https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F22.03+sort%3Aupdated-desc

Hauke

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



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

Re: Next OpenWrt 23.05 and 22.03 minor releases

[Goetz Goerisch]

Hi Hauke,

How about package backports?

There are a few pending in openwrt/packages for 23.05 and 22.03 incl.
a security fix as far as I can tell from the description?

https://github.com/openwrt/packages/pulls?q=is%3Apr+is%3Aopen+%5B23.05%5D

Goetz


Am Do., 27. Juni 2024 um 20:21 Uhr schrieb Hauke Mehrtens :
>
> Hi,
>
> I am planning a new minor release of the 23.05 series and the final
> release of the 22.03 series in about 1 week.
>
> If you want some commits backported please answer to this mail with the
> upstream commit hash or create a PR on github for the stable branch.
>
> PRs for OpenWrt 23.05:
> https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F23.05+sort%3Aupdated-desc
>
> PRs for OpenWrt 22.03:
> https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F22.03+sort%3Aupdated-desc
>
> Hauke
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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