Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[Rich Brown]

Thank you Felix for the careful review.

> On Feb 5, 2024, at 3:28 PM, Felix Baumann via openwrt-devel 
>  wrote:
> 
> I would do an estimate if I could. I don't think it's possible to do one 
> without building images. Especially since OpenWrt will grow a bit as well 
> till any release is done.
> But I also wouldn't worry too much about this if I were you :)

I raised these (admittedly imprecise) points to see whether we are approaching 
any thresholds that would eliminate support for a large number of devices (like 
the transition away from 4/32 devices). If no threshold is looming, that's 
great.

If there were, I am voicing my support for moving to 6.6 now so that dev's 
don't have to do much the same work twice in the next 1-2 years.

Thanks again.

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

Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[Hauke Mehrtens]

On 2/5/24 11:35, Zoltan HERPAI wrote:

On Sat, 3 Feb 2024, Enrico Mioso wrote:

On Sat, Feb 03, 2024 at 07:02:44PM +0100, Christian Marangi (Ansuel) 
wrote:

Il giorno sab 3 feb 2024 alle ore 18:55 Janusz Dziedzic
 ha scritto:


sob., 3 lut 2024 o 13:08 Hauke Mehrtens  napisał(a):


Hi,

I track the status of the Linux kernel 6.1 migration in this github
issue: https://github.com/openwrt/openwrt/issues/14546

There are still many targets on kernel 5.15 without testing support 
for
kernel 6.1 in OpenWrt master. I assume that we need at least 4 
months to

get everything to 6.1 and more or less stable. Kernel 6.1 support is
also missing for some important targets like lantiq, realtek and 
ramips.



Which kernel should we use for the next major OpenWrt release?
We have two options and I would like to get some feedback on these:

1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or
most of the targets are on kernel 6.1 by default.
2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or
most of the targets are on kernel 6.6 by default. Do not do any stable
OpenWrt release which supports kernel 6.1.

Doing a OpenWrt release with multiple kernels cases too much 
maintenance

effort from my point of view based on previews experience.


I think with kernel 6.1 we can branch off at around May 2024. With
kernel 6.6 we could probably branch off around September 2024. The 
final

release will be out about 2 to 4 months later.

Currently OpenWrt releases are about 1.5 years behind the Linux LTS
releases. When we use kernel 6.1 for the next release we will continue
to stay 1.5 years behind. When we switch to kernel 6.6 and do not 
do any

release with kernel 6.1 we will probably only stay 10 months behind
Linux LTS kernels.

There is already a PR requiring kernel 6.6:
https://github.com/openwrt/openwrt/pull/14357


Currently I would prefer to use kernel 6.6 to get closer to the recent
Linux LTS releases.



6.6 for sure if possible.

Just curious - any reason to not support both or even 5.15? And target
could decide about it in mk?
Eg. newest ATH/QCA that base a lot on newest kernel and backports just
could choose it?
For older one we already have work done - so just change generic
patches directory into generic-kernel_ver?
Or this is more work and problems?



We usually try to stick to a common kernel across all target for 
stable release
for consistency and to prevent and handle regression in the generic 
target.


Also it's really a way to force target on getting updated... If it
wasn't for this
reason we would probably have stuff stuck at 4.19.


Hello all,

I would choose 6.1: to get more time for some things to stabilize out 
and because I am under the impression the kernel size is growing too 
fast and so we are accelerating hw obsolescence.
The 6.1 kernel has also been choosen by the Civil Infrastructure 
Platform, so it would get some attention and maintenance still.


However, my preference / decision is for 6.6 in the end: especially 
after having felt the pain of developers who need to backport lots of 
stuff and for which the challenge becomes harder over time.
If we need more developers, making development less annoying is 
preferrable.
That said, it would be nice to enable only the needed kernel features 
for a subtarget, just to incrase efficiency in general.


Hi,

I'm kind of biased here too. 6.1 due to CIP and vendors starting to pick 
6.1 as their kernel of choice in SDKs, but 6.6 for moving with the 
targets and new stuff we're working on forward.


I do not care much what vendors choose for their SDKs. If you want to 
consider this you probably have to look what vendors will choose next 
year when they look for an OpenWrt version and a kernel version. For 
example prplOS selected OpenWrt 22.03 and kernel 5.15, but OpenWrt 22.03 
shipped with kernel 5.10. OpenWrt 23.05 was not stable when they made 
the decision, but they already selected kernel 5.15.


I do not know how good the CIP people are at maintaining a LTS kernel. I 
do not see them working together with the upstream community. I 
personally only trust Greg Kroah-Hartman with the help of the full 
kernel community and RedHat with all their kernel developers on their 
payroll to be able to maintain a stable LTS kernel. I do not trust any 
hardware manufacturer to be able to maintain a stable LTS kernel.


One thing I fully agree with Hauke is that we should pick one (and only 
one) kernel for the next release, whenever that is. If we need to drop 
targets to achieve it (no maintainer stepping up or lack of storage on 
the devices), so be it.


Also:
  - riscv targets I'm working on are usually better off with 6.6,
  - we are unable to keep up with a standard release cycle anyway, so no 
one will tell us off if we delay a release by a few months.


I think the biggest efforts in a kernel migration are the generic 
support and the MIPS targets with many deceives (ath79, ramips, ...). 
The modern ARM targets 

Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[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 5. Februar 2024 15:28:08 MEZ schrieb Rich Brown :
>
>To aid in the analysis, I copy/pasted the Table of Hardware into a spreadsheet 
>to see what we would be losing. I started with 
>https://openwrt.org/toh/views/toh_extended_all
>
>The resulting spreadsheet is at: 
>https://docs.google.com/spreadsheets/d/1j_Yv62tdYzvA4iU216W3B0XHswXv2U2LrxQ0QOB5-vE/edit?usp=sharing
>
>The tabs are:
>
>- Original Data - as copy/pasted from the Table of Hardware. Cells are 
>protected to prevent inadvertent changes.
>   The rest of the spreadsheet is unprotected and you should feel free to 
> modify it/make new tabs
>- Sorted by Curr Release - same data, but sorted by Current Release column 
>(Column I)
>- 23.0x-only devices - removes the rows for 22.0x and earlier, and current 
>release = blank
>- Changelog - changes from original data to produce current state
>
>Observations:
>
>- There are ~2200 devices listed in the ToH

There's a comparatively "huge" list of devices/images not present in the ToH. 
Not everyone adding device support bothered with adding it to the ToH.

>- There are ~880 devices that are only supported in 22.0x and earlier

Lots of those probably have a working 23.05.2 image. The list in the ToH wasn't 
checked manually. They just ran the usual script. We have no Wiki maintainer 
atm.


There are 154 devices whose support was dropped with release 23 but(!) this was 
just due to the same earlier decision made to drop 4/32 devices. There were 154 
devices we still built OpenWrt 22.03.x for that officially shouldn't have been 
supported anyways, dropping them was overdue. Noone bothered to do the work to 
drop them earlier.
 

My advise:
Don't use the ToH as an estimate it is highly inaccurate.
Look at the download server and which images are present in the available 
releases.
Also: mvebu devices were dropped from OpenWrt 22 temporarily in releases after 
22.03.3, I think. This was due to a bug in Kernel 5.10 regarding their switch 
that was reported after release. They returned with OpenWrt 23. The ToH might 
not reflect this correctly because tmomas script only touches devices who 
received the latest release. And mvebu didn't receive the latest 22 release 
before release of 23.

>- There are ~330 devices that have the empty string as the Supported Current 
>Release
>- Virtually all the devices in the last two items (22.0x and earlier, and 
>empty string) have been discontinued/unavailable from before 2020
>
>Can someone who knows more about our devices make a judgement whether we would 
>lose an appreciable fraction of devices by switching to a kernel that might 
>not fit/work? Thanks.
>
>Rich

I would do an estimate if I could. I don't think it's possible to do one 
without building images. Especially since OpenWrt will grow a bit as well till 
any release is done.
But I also wouldn't worry too much about this if I were you :)

Regards
Felix Baumann

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

Re: [PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware

[Christian Marangi]

On Mon, Feb 05, 2024 at 08:21:43PM +0100, Rafał Miłecki wrote:
> On 5.02.2024 15:21, Daniel Golle wrote:
> > On Mon, Feb 05, 2024 at 02:23:08PM +0100, Rafał Miłecki wrote:
> > > From: Rafał Miłecki 
> > > 
> > > Aquantia AQR113C is PHY that needs loading a firmware. Some devices may
> > > have it stored on flash and some need filesystem to provide it.
> > 
> > Are you aware of any MediaTek boards which do come with AQR113C but
> > don't bring their own dedicated firmware flash/EEPROM IC connected
> > directly to first PHY?
> > UniFi 6 LR v1/v2 (Aquantia AQR112C) and MT7988RFB (Aquantia AQR113C)
> > both come with a dedidated flash/EEPROM IC for the PHY firmware.
> > However, that firmware (esp. on the UniFi 6 LR) may of course be
> > outdated by now and we may want to load newer firmware from within
> > Linux anyway.
> 
> I'm not sure if I can verify using Linux if there is EEPROM attached to
> any of two PHYs on my board. I don't believe Linux's PHY driver exposes
> possibly-attached EEPROM as any Linux device.
> 
> I think however that with EEPROM present I wouldn't need Linux driver
> to load PHY firmware. In my board case I need to do that which makes me
> believe there is no EEPROM chip with firmware present.
>

Just to be clear, the EEPROM (actually it's a spi) is attached directly
to the PHY internally, you don't have a way to expose it in linux...

Also in that configuration, the FW is loaded automatically and with the
current driver, fw loading is skipped as a correct FW version is read
from the PHY. (FW loading from attached EEPROM is setup by hw strapping)

There is no need to verify if an EEPROM is attached, the check we do
is either a FW is present and loaded or a FW is not loaded and the PHY
FW version reg answer with 0.0.0 (or 0xff if held in reset state)

-- 
Ansuel

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

Re: [PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware

[Rafał Miłecki]

On 5.02.2024 15:21, Daniel Golle wrote:

On Mon, Feb 05, 2024 at 02:23:08PM +0100, Rafał Miłecki wrote:

From: Rafał Miłecki 

Aquantia AQR113C is PHY that needs loading a firmware. Some devices may
have it stored on flash and some need filesystem to provide it.


Are you aware of any MediaTek boards which do come with AQR113C but
don't bring their own dedicated firmware flash/EEPROM IC connected
directly to first PHY?
UniFi 6 LR v1/v2 (Aquantia AQR112C) and MT7988RFB (Aquantia AQR113C)
both come with a dedidated flash/EEPROM IC for the PHY firmware.
However, that firmware (esp. on the UniFi 6 LR) may of course be
outdated by now and we may want to load newer firmware from within
Linux anyway.


I'm not sure if I can verify using Linux if there is EEPROM attached to
any of two PHYs on my board. I don't believe Linux's PHY driver exposes
possibly-attached EEPROM as any Linux device.

I think however that with EEPROM present I wouldn't need Linux driver
to load PHY firmware. In my board case I need to do that which makes me
believe there is no EEPROM chip with firmware present.

--
Rafał Miłecki

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

Re: [PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware

[Rafał Miłecki]

On 5.02.2024 15:15, Robert Marko wrote:

On Mon, 5 Feb 2024 at 14:23, Rafał Miłecki  wrote:


From: Rafał Miłecki 

Aquantia AQR113C is PHY that needs loading a firmware. Some devices may
have it stored on flash and some need filesystem to provide it.

MediaTek holds its own AQR113C firmware file for its boards. Package it.


Hi Rafal, not going into details of this patch, but what is the
license situation with
redistributing the AQR firmware?


Good question. I don't know.

Cc linux-mediatek@
Can we get some licensing help, please?



Initial firmware file
Rhe-05.06-Candidate7-AQR_Mediatek_23B_StartOff_ID45623_VER36657.cld was
added in the commit:

commit 24ba51c5be18613127b2d8407b0223174624b130
Author: developer 
Date:   Tue Nov 15 11:22:46 2022 +0800

[][kernel][mt7988][eth][Change AQR113C firmware download method to MDIO 
gangload]

[Description]
Change AQR113C firmware download method to MDIO gangload.

If without this patch, AQR113C cannot boot from MDIO gangload.

[Release-log]
N/A


Change-Id: Iddc29f5e1c73c772bcea9313938b6daccc10025a
Reviewed-on: 
https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/6781059

with not licensing details.



Later there was a firmware update update handled by adding file:
Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld in the commit:

commit 405b1e31f924b97d379719fb39f0d28c0fac43a9
Author: developer 
Date:   Tue Mar 28 17:00:41 2023 +0800

[][kernel][mt7988][eth][Fix AQR113C 5GBASE-T compliance test mode4 tone1 
fail issue]

[Description]
Fix AQR113C 5GBASE-T compliance test mode4 tone1 fail issue by
updating firmware version to
Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld.

If without this patch, AQR113C might not pass the 5GBASE-T mode4 tone1
items for the compliance test.

[Release-log]
N/A


Change-Id: I3b2c6e6cf1a6ba8183daa7e30110ff2c839c5989
Reviewed-on: 
https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/7305781

but again with not licensing info.



I also can't find any readme file specifying licensing of those files.


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

Re: [VOTE] New member proposal: Robimarko (Robert Marko)

[Álvaro Fernández Rojas]

El mar, 30 ene 2024 a las 19:16, Christian Marangi (Ansuel)
() escribió:
>
> Robert is active in OpenWrt since 2017 and with some recent stats, he
> has more than 310 commits merged in OpenWrt.
> He also have uncounted Reviewed-by tag on various PR and merged commits
> and generally helps in everything related to IPQ (ipq806x, ipq40xx and
> ipq807x) and some mvebu targets.
>
> He did the conversion of ipq40xx target to DSA and made possible the
> introduction of the ipq807x target by sorting all the QSDK downstream
> patch and pushing them upstream.
>
> With his help, also the ipq60xx is very close on getting merged and
> actually used permitting support of even more device for OpenWrt.
>
> Also he is almost always reachable on IRC openwrt-devel and never had
> a problem in coordinating and collaborating with him.
>
> I think Robert is a good addition to our team and would massively help
> me (Ansuel) in maintaining each IPQ target and review all the related
> PR on github and patchwork.
> I would like to add Robert to the OpenWrt committers team.

+1

>
> The vote shall be concluded within 14 days. (13/02/2024)

Thanks,
Álvaro.

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

Re: Librerouter v1 booting from second partition broken

[Gio]

Have tested a few changes based on your suggestion, all of them sadly 
failed:


1) Reset kernel settings to default + Remove the whole partitions block 
from librerouter dts, the image fails to be compile with an error of 
missing art label (probably because uno of the partitions have that label)



2) Reset kernel settings to default + Remove firmware and fw2 partitions 
from librerouter dts, the image build fine but at boot the commandline 
passed by the bootloader is completely ignored (because the default 
kernel config includes CONFIG_MIPS_CMDLINE_FROM_DTB)


3) Unset CONFIG_MIPS_CMDLINE_FROM_DTB and set 
CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER, at this point the commandline is 
onored but fails later because the partitions encapsulated inside 
firmare partitions are not "unpacked" same as I reported in the first email



Does the "automatic unpacking" have something to do with the `compatible 
= "denx,uimage";` line present on the DTS  which refer to the firmware 
partition?



Cheers

Gio


On 2/3/24 01:18, Isaev Ruslan wrote:

Try to remove your patch and just remove mtdparts from dts.

On Sat, Feb 3, 2024, 00:19 Gio  wrote:

Hi!

librerouterOS used to be based on OpenWrt 19

librerouterOS is basically plain OpenWrt plus safe-upgrade,

safe-upgrade is a mechanism to flash an updated firmware to a second
partition and mark it as testing, so if something goes wrong and user
doesn't confirm everything is ok, after a while it reboot from the
first
partition, support for flashing a second partition and booting from
there, to do this safe-upgrade basically does a bit of U-Boot
trickery and

pass to kernel command line


mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),7936k(firmware),7936k(fw2),128k(res),64k(ART)

to boot from first partition, while


mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),7936k(fw1),7936k(firmware),128k(res),64k(ART)

when booting from second partition

OpenWrt 19 used to works perfectly with this trick, while with
current
development branch it boot perfectly from first partition but
fails to
boot from second :-/

AFAIU now mtdparts are passed via DTS so I have been fiddling with
kernel options to avoid the kernel reading from there as of today
I do this


 # Avoid MTD partition table being read from Device Tree
safe-upgrade need
     # to change it depending if we need to boot fw1 or fw2 so it
uses
kernel
     # command line to pass partition table
     kconfig_unset CONFIG_MTD_OF_PARTS

     # Disable kernel command line being read from device tree
which is
mutually
     # exclusive with reading it from boot loader
     # CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER
     kconfig_unset CONFIG_MIPS_CMDLINE_FROM_DTB

     # safe-upgrade need kernel command line to be generated
dinamically
by the
     # boot loader (U-Boot) depending on which partition (either
fw1 or
fw2) it
     # need to boot
     kconfig_set CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER

and then pass the mtdparts to kernel command line via U-Boot, the
result
is that it keeps booting fine from first partition but it cannot find
root partition when booting from second partition, apparently at some
point sub-MTD-partitions get detected when booting from fw1 while
they
are not when booting from fw2


booting form first partition


[    0.334007] spi-nor spi0.0: w25q128 (16384 Kbytes)
[    0.338951] mtd: Found partition defined in DT for u-boot.
Assigning
OF node to support nvmem.
[    0.338964] mtd: Found partition defined in DT for u-boot-env.
Assigning OF node to support nvmem.
[    0.347748] mtd: Found partition defined in DT for firmware.
Assigning OF node to support nvmem.
[    0.356859] mtd: Found partition defined in DT for res.
Assigning OF
node to support nvmem.
[    0.365783] mtd: Found partition defined in DT for ART.
Assigning OF
node to support nvmem.
[    0.374263] 6 cmdlinepart partitions found on MTD device spi0.0
[    0.388733] Creating 6 MTD partitions on "spi0.0":
[    0.393595] 0x-0x0004 : "u-boot"
[    0.402035] 0x0004-0x0005 : "u-boot-env"
[    0.408366] 0x0005-0x0081 : "firmware"
[    0.416207] 2 uimage-fw partitions found on MTD device firmware
[    0.48] Creating 2 MTD partitions on "firmware":
[    0.427307] 0x-0x0024 : "kernel"
[    0.433243] 0x0024-0x007c : "rootfs"
[    0.440527] mtd: setting mtd4 (rootfs) as root device
[    0.445792] 1 squashfs-split partitions found on MTD device rootfs
[    0.452072] 0x0069-0x007c : "rootfs_data"
[    0.458570] 0x0081-0x00fd : "fw2"
[    0.465664] 0x00fd-0x00ff : "res"
[    0.471330] 0x00ff-0x0100 : 

Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[Rich Brown]

> On Feb 5, 2024, at 5:35 AM, Zoltan HERPAI  wrote:
> 
> 
> One thing I fully agree with Hauke is that we should pick one (and only one) 
> kernel for the next release, whenever that is. If we need to drop targets to 
> achieve it (no maintainer stepping up or lack of storage on the devices), so 
> be it.

+1. 

To aid in the analysis, I copy/pasted the Table of Hardware into a spreadsheet 
to see what we would be losing. I started with 
https://openwrt.org/toh/views/toh_extended_all

The resulting spreadsheet is at: 
https://docs.google.com/spreadsheets/d/1j_Yv62tdYzvA4iU216W3B0XHswXv2U2LrxQ0QOB5-vE/edit?usp=sharing

The tabs are:

- Original Data - as copy/pasted from the Table of Hardware. Cells are 
protected to prevent inadvertent changes.
The rest of the spreadsheet is unprotected and you should feel free to 
modify it/make new tabs
- Sorted by Curr Release - same data, but sorted by Current Release column 
(Column I)
- 23.0x-only devices - removes the rows for 22.0x and earlier, and current 
release = blank
- Changelog - changes from original data to produce current state

Observations:

- There are ~2200 devices listed in the ToH
- There are ~880 devices that are only supported in 22.0x and earlier
- There are ~330 devices that have the empty string as the Supported Current 
Release
- Virtually all the devices in the last two items (22.0x and earlier, and empty 
string) have been discontinued/unavailable from before 2020

Can someone who knows more about our devices make a judgement whether we would 
lose an appreciable fraction of devices by switching to a kernel that might not 
fit/work? Thanks.

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

Re: [PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware

[Daniel Golle]

On Mon, Feb 05, 2024 at 02:23:08PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Aquantia AQR113C is PHY that needs loading a firmware. Some devices may
> have it stored on flash and some need filesystem to provide it.

Are you aware of any MediaTek boards which do come with AQR113C but
don't bring their own dedicated firmware flash/EEPROM IC connected
directly to first PHY?
UniFi 6 LR v1/v2 (Aquantia AQR112C) and MT7988RFB (Aquantia AQR113C)
both come with a dedidated flash/EEPROM IC for the PHY firmware.
However, that firmware (esp. on the UniFi 6 LR) may of course be
outdated by now and we may want to load newer firmware from within
Linux anyway.

> 
> MediaTek holds its own AQR113C firmware file for its boards. Package it.
> 
> The problem is obtaining that firmware:
> 1. Cloning whole repo seems like an overkill for copying a single file
> 2. Public git server doesn't support git protocol (and so git archive)
> 3. Gitiles UI doesn't allow downloading raw files (nor binaries as text)
> 
> The only option seems to be downloading tar archive of "firmware"
> directory. The problem is such archives generated by Gitiles differ on
> every download so a checksum can't be specified.
> 
> Due to all above a custom download is implemented in "Build/Prepare".
> Then firmware gets simply extracted and packaged.
> 
> Cc: Robert Marko 
> Cc: Christian Marangi 
> Cc: Daniel Golle 
> Signed-off-by: Rafał Miłecki 
> ---
>  package/firmware/aquantia-firmware/Makefile | 36 +
>  1 file changed, 36 insertions(+)
>  create mode 100644 package/firmware/aquantia-firmware/Makefile
> 
> diff --git a/package/firmware/aquantia-firmware/Makefile 
> b/package/firmware/aquantia-firmware/Makefile
> new file mode 100644
> index 00..9cf67f41bb
> --- /dev/null
> +++ b/package/firmware/aquantia-firmware/Makefile
> @@ -0,0 +1,36 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=aquantia-firmware
> +PKG_RELEASE:=1

PKG_VERSION ?

PKG_LICENSE ?

> +
> +include $(INCLUDE_DIR)/package.mk
> +
> +define Package/aquantia-mediatek-aqr113c-firmware
> +  SECTION:=firmware
> +  CATEGORY:=Firmware
> +  TITLE:=MediaTek's firmware for Aquantia AQR113C
> +endef
> +
> +define Build/Prepare
> + mkdir -p $(PKG_BUILD_DIR)
> +
> + # Download for "aquantia-mediatek-aqr113c-firmware" package
> + wget \
> + -O 
> $(DL_DIR)/mtk-openwrt-feeds-refs_heads_master-21.02-files-target-linux-mediatek-mt7988-base-files-lib-firmware.tar.gz
>  \
> + 
> "https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+archive/refs/heads/master/21.02/files/target/linux/mediatek/mt7988/base-files/lib/firmware.tar.gz;
> + tar xf 
> $(DL_DIR)/mtk-openwrt-feeds-refs_heads_master-21.02-files-target-linux-mediatek-mt7988-base-files-lib-firmware.tar.gz
>  -C $(PKG_BUILD_DIR)
> + # TODO: Verify extracted firmware checksum
> +endef
> +
> +define Build/Compile
> +
> +endef
> +
> +define Package/aquantia-mediatek-aqr113c-firmware/install
> + $(INSTALL_DIR) $(1)/lib/firmware
> + $(INSTALL_DATA) 
> $(PKG_BUILD_DIR)/Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld 
> $(1)/lib/firmware/
> +endef
> +
> +$(eval $(call BuildPackage,aquantia-mediatek-aqr113c-firmware))
> -- 
> 2.35.3
> 

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

Re: [PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware

[Robert Marko]

On Mon, 5 Feb 2024 at 14:23, Rafał Miłecki  wrote:
>
> From: Rafał Miłecki 
>
> Aquantia AQR113C is PHY that needs loading a firmware. Some devices may
> have it stored on flash and some need filesystem to provide it.
>
> MediaTek holds its own AQR113C firmware file for its boards. Package it.

Hi Rafal, not going into details of this patch, but what is the
license situation with
redistributing the AQR firmware?

Regards,
Robert
>
> The problem is obtaining that firmware:
> 1. Cloning whole repo seems like an overkill for copying a single file
> 2. Public git server doesn't support git protocol (and so git archive)
> 3. Gitiles UI doesn't allow downloading raw files (nor binaries as text)
>
> The only option seems to be downloading tar archive of "firmware"
> directory. The problem is such archives generated by Gitiles differ on
> every download so a checksum can't be specified.
>
> Due to all above a custom download is implemented in "Build/Prepare".
> Then firmware gets simply extracted and packaged.
>
> Cc: Robert Marko 
> Cc: Christian Marangi 
> Cc: Daniel Golle 
> Signed-off-by: Rafał Miłecki 
> ---
>  package/firmware/aquantia-firmware/Makefile | 36 +
>  1 file changed, 36 insertions(+)
>  create mode 100644 package/firmware/aquantia-firmware/Makefile
>
> diff --git a/package/firmware/aquantia-firmware/Makefile 
> b/package/firmware/aquantia-firmware/Makefile
> new file mode 100644
> index 00..9cf67f41bb
> --- /dev/null
> +++ b/package/firmware/aquantia-firmware/Makefile
> @@ -0,0 +1,36 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=aquantia-firmware
> +PKG_RELEASE:=1
> +
> +include $(INCLUDE_DIR)/package.mk
> +
> +define Package/aquantia-mediatek-aqr113c-firmware
> +  SECTION:=firmware
> +  CATEGORY:=Firmware
> +  TITLE:=MediaTek's firmware for Aquantia AQR113C
> +endef
> +
> +define Build/Prepare
> +   mkdir -p $(PKG_BUILD_DIR)
> +
> +   # Download for "aquantia-mediatek-aqr113c-firmware" package
> +   wget \
> +   -O 
> $(DL_DIR)/mtk-openwrt-feeds-refs_heads_master-21.02-files-target-linux-mediatek-mt7988-base-files-lib-firmware.tar.gz
>  \
> +   
> "https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+archive/refs/heads/master/21.02/files/target/linux/mediatek/mt7988/base-files/lib/firmware.tar.gz;
> +   tar xf 
> $(DL_DIR)/mtk-openwrt-feeds-refs_heads_master-21.02-files-target-linux-mediatek-mt7988-base-files-lib-firmware.tar.gz
>  -C $(PKG_BUILD_DIR)
> +   # TODO: Verify extracted firmware checksum
> +endef
> +
> +define Build/Compile
> +
> +endef
> +
> +define Package/aquantia-mediatek-aqr113c-firmware/install
> +   $(INSTALL_DIR) $(1)/lib/firmware
> +   $(INSTALL_DATA) 
> $(PKG_BUILD_DIR)/Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld 
> $(1)/lib/firmware/
> +endef
> +
> +$(eval $(call BuildPackage,aquantia-mediatek-aqr113c-firmware))
> --
> 2.35.3
>

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

[PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware

[Rafał Miłecki]

From: Rafał Miłecki 

Aquantia AQR113C is PHY that needs loading a firmware. Some devices may
have it stored on flash and some need filesystem to provide it.

MediaTek holds its own AQR113C firmware file for its boards. Package it.

The problem is obtaining that firmware:
1. Cloning whole repo seems like an overkill for copying a single file
2. Public git server doesn't support git protocol (and so git archive)
3. Gitiles UI doesn't allow downloading raw files (nor binaries as text)

The only option seems to be downloading tar archive of "firmware"
directory. The problem is such archives generated by Gitiles differ on
every download so a checksum can't be specified.

Due to all above a custom download is implemented in "Build/Prepare".
Then firmware gets simply extracted and packaged.

Cc: Robert Marko 
Cc: Christian Marangi 
Cc: Daniel Golle 
Signed-off-by: Rafał Miłecki 
---
 package/firmware/aquantia-firmware/Makefile | 36 +
 1 file changed, 36 insertions(+)
 create mode 100644 package/firmware/aquantia-firmware/Makefile

diff --git a/package/firmware/aquantia-firmware/Makefile 
b/package/firmware/aquantia-firmware/Makefile
new file mode 100644
index 00..9cf67f41bb
--- /dev/null
+++ b/package/firmware/aquantia-firmware/Makefile
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=aquantia-firmware
+PKG_RELEASE:=1
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/aquantia-mediatek-aqr113c-firmware
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  TITLE:=MediaTek's firmware for Aquantia AQR113C
+endef
+
+define Build/Prepare
+   mkdir -p $(PKG_BUILD_DIR)
+
+   # Download for "aquantia-mediatek-aqr113c-firmware" package
+   wget \
+   -O 
$(DL_DIR)/mtk-openwrt-feeds-refs_heads_master-21.02-files-target-linux-mediatek-mt7988-base-files-lib-firmware.tar.gz
 \
+   
"https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+archive/refs/heads/master/21.02/files/target/linux/mediatek/mt7988/base-files/lib/firmware.tar.gz;
+   tar xf 
$(DL_DIR)/mtk-openwrt-feeds-refs_heads_master-21.02-files-target-linux-mediatek-mt7988-base-files-lib-firmware.tar.gz
 -C $(PKG_BUILD_DIR)
+   # TODO: Verify extracted firmware checksum
+endef
+
+define Build/Compile
+
+endef
+
+define Package/aquantia-mediatek-aqr113c-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DATA) 
$(PKG_BUILD_DIR)/Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld 
$(1)/lib/firmware/
+endef
+
+$(eval $(call BuildPackage,aquantia-mediatek-aqr113c-firmware))
-- 
2.35.3


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

Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[Dave Taht]

I do not care one whit about CIP. It will lead to redhat-style
ossification and even further delusional consideration that Linux is
"done". The Linux foundation keeps losing its way. I would prefer
OpenWrt (and arm development in particular) continue to track the
newest kernels possible and indeed, somehow, push back into the
mainline kernel processes for older, embedded gear more than it has,
continuing to shrink needed bits as they come up.

As an example, 6.7 had had extensive profiling in it, which made the
tcp stack on AMD in particular more highly performant. But no work was
done that I know of to verify that ARM was not hurt, particularly arm
on older gear - but due to those patches being so beneficial, it looks
like ubuntu plans to ship 6.8 in april. Improvements to the tcp stack
are not openwrt´s primary use case, but being able to stay on top of
linux developments on arm gear is.

Perhaps rather than chasing LF unnecessarily, following a mainstream
distro more closely aligned with ARM might help.

As for 6.1 vs 6.6, having tooling, processing, people, and attitude in
place towards being always being able to go in 4 months to a new
kernel - of any sort - would be a win.

On Mon, Feb 5, 2024 at 5:38 AM Zoltan HERPAI  wrote:
>
> On Sat, 3 Feb 2024, Enrico Mioso wrote:
>
> > On Sat, Feb 03, 2024 at 07:02:44PM +0100, Christian Marangi (Ansuel) wrote:
> >> Il giorno sab 3 feb 2024 alle ore 18:55 Janusz Dziedzic
> >>  ha scritto:
> >>>
> >>> sob., 3 lut 2024 o 13:08 Hauke Mehrtens  napisał(a):
> 
>  Hi,
> 
>  I track the status of the Linux kernel 6.1 migration in this github
>  issue: https://github.com/openwrt/openwrt/issues/14546
> 
>  There are still many targets on kernel 5.15 without testing support for
>  kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to
>  get everything to 6.1 and more or less stable. Kernel 6.1 support is
>  also missing for some important targets like lantiq, realtek and ramips.
> 
> 
>  Which kernel should we use for the next major OpenWrt release?
>  We have two options and I would like to get some feedback on these:
> 
>  1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or
>  most of the targets are on kernel 6.1 by default.
>  2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or
>  most of the targets are on kernel 6.6 by default. Do not do any stable
>  OpenWrt release which supports kernel 6.1.
> 
>  Doing a OpenWrt release with multiple kernels cases too much maintenance
>  effort from my point of view based on previews experience.
> 
> 
>  I think with kernel 6.1 we can branch off at around May 2024. With
>  kernel 6.6 we could probably branch off around September 2024. The final
>  release will be out about 2 to 4 months later.
> 
>  Currently OpenWrt releases are about 1.5 years behind the Linux LTS
>  releases. When we use kernel 6.1 for the next release we will continue
>  to stay 1.5 years behind. When we switch to kernel 6.6 and do not do any
>  release with kernel 6.1 we will probably only stay 10 months behind
>  Linux LTS kernels.
> 
>  There is already a PR requiring kernel 6.6:
>  https://github.com/openwrt/openwrt/pull/14357
> 
> 
>  Currently I would prefer to use kernel 6.6 to get closer to the recent
>  Linux LTS releases.
> 
> >>>
> >>> 6.6 for sure if possible.
> >>>
> >>> Just curious - any reason to not support both or even 5.15? And target
> >>> could decide about it in mk?
> >>> Eg. newest ATH/QCA that base a lot on newest kernel and backports just
> >>> could choose it?
> >>> For older one we already have work done - so just change generic
> >>> patches directory into generic-kernel_ver?
> >>> Or this is more work and problems?
> >>>
> >>
> >> We usually try to stick to a common kernel across all target for stable 
> >> release
> >> for consistency and to prevent and handle regression in the generic target.
> >>
> >> Also it's really a way to force target on getting updated... If it
> >> wasn't for this
> >> reason we would probably have stuff stuck at 4.19.
> >>
> > Hello all,
> >
> > I would choose 6.1: to get more time for some things to stabilize out and 
> > because I am under the impression the kernel size is growing too fast and 
> > so we are accelerating hw obsolescence.
> > The 6.1 kernel has also been choosen by the Civil Infrastructure Platform, 
> > so it would get some attention and maintenance still.
> >
> > However, my preference / decision is for 6.6 in the end: especially after 
> > having felt the pain of developers who need to backport lots of stuff and 
> > for which the challenge becomes harder over time.
> > If we need more developers, making development less annoying is preferrable.
> > That said, it would be nice to enable only the needed kernel features for a 
> > subtarget, just to incrase 

Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[Zoltan HERPAI]

On Sat, 3 Feb 2024, Enrico Mioso wrote:


On Sat, Feb 03, 2024 at 07:02:44PM +0100, Christian Marangi (Ansuel) wrote:

Il giorno sab 3 feb 2024 alle ore 18:55 Janusz Dziedzic
 ha scritto:


sob., 3 lut 2024 o 13:08 Hauke Mehrtens  napisał(a):


Hi,

I track the status of the Linux kernel 6.1 migration in this github
issue: https://github.com/openwrt/openwrt/issues/14546

There are still many targets on kernel 5.15 without testing support for
kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to
get everything to 6.1 and more or less stable. Kernel 6.1 support is
also missing for some important targets like lantiq, realtek and ramips.


Which kernel should we use for the next major OpenWrt release?
We have two options and I would like to get some feedback on these:

1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or
most of the targets are on kernel 6.1 by default.
2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or
most of the targets are on kernel 6.6 by default. Do not do any stable
OpenWrt release which supports kernel 6.1.

Doing a OpenWrt release with multiple kernels cases too much maintenance
effort from my point of view based on previews experience.


I think with kernel 6.1 we can branch off at around May 2024. With
kernel 6.6 we could probably branch off around September 2024. The final
release will be out about 2 to 4 months later.

Currently OpenWrt releases are about 1.5 years behind the Linux LTS
releases. When we use kernel 6.1 for the next release we will continue
to stay 1.5 years behind. When we switch to kernel 6.6 and do not do any
release with kernel 6.1 we will probably only stay 10 months behind
Linux LTS kernels.

There is already a PR requiring kernel 6.6:
https://github.com/openwrt/openwrt/pull/14357


Currently I would prefer to use kernel 6.6 to get closer to the recent
Linux LTS releases.



6.6 for sure if possible.

Just curious - any reason to not support both or even 5.15? And target
could decide about it in mk?
Eg. newest ATH/QCA that base a lot on newest kernel and backports just
could choose it?
For older one we already have work done - so just change generic
patches directory into generic-kernel_ver?
Or this is more work and problems?



We usually try to stick to a common kernel across all target for stable release
for consistency and to prevent and handle regression in the generic target.

Also it's really a way to force target on getting updated... If it
wasn't for this
reason we would probably have stuff stuck at 4.19.


Hello all,

I would choose 6.1: to get more time for some things to stabilize out and 
because I am under the impression the kernel size is growing too fast and so we 
are accelerating hw obsolescence.
The 6.1 kernel has also been choosen by the Civil Infrastructure Platform, so 
it would get some attention and maintenance still.

However, my preference / decision is for 6.6 in the end: especially after 
having felt the pain of developers who need to backport lots of stuff and for 
which the challenge becomes harder over time.
If we need more developers, making development less annoying is preferrable.
That said, it would be nice to enable only the needed kernel features for a 
subtarget, just to incrase efficiency in general.


Hi,

I'm kind of biased here too. 6.1 due to CIP and vendors starting to pick 
6.1 as their kernel of choice in SDKs, but 6.6 for moving with the 
targets and new stuff we're working on forward.


One thing I fully agree with Hauke is that we should pick one (and only 
one) kernel for the next release, whenever that is. If we need to drop 
targets to achieve it (no maintainer stepping up or lack of storage on 
the devices), so be it.


Also:
 - riscv targets I'm working on are usually better off with 6.6,
 - we are unable to keep up with a standard release cycle anyway, so no 
one will tell us off if we delay a release by a few months.


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

Re: [VOTE] New member proposal: Robimarko (Robert Marko)

[David Bauer]

Yes please.

 - David

On 1/30/24 19:15, Christian Marangi (Ansuel) wrote:

Robert is active in OpenWrt since 2017 and with some recent stats, he
has more than 310 commits merged in OpenWrt.
He also have uncounted Reviewed-by tag on various PR and merged commits
and generally helps in everything related to IPQ (ipq806x, ipq40xx and
ipq807x) and some mvebu targets.

He did the conversion of ipq40xx target to DSA and made possible the
introduction of the ipq807x target by sorting all the QSDK downstream
patch and pushing them upstream.

With his help, also the ipq60xx is very close on getting merged and
actually used permitting support of even more device for OpenWrt.

Also he is almost always reachable on IRC openwrt-devel and never had
a problem in coordinating and collaborating with him.

I think Robert is a good addition to our team and would massively help
me (Ansuel) in maintaining each IPQ target and review all the related
PR on github and patchwork.
I would like to add Robert to the OpenWrt committers team.

The vote shall be concluded within 14 days. (13/02/2024)

___
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