Re: qca-wireless: ipq50xx: ipq5018: add bdf for ikuai sw8

[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

[this equally applies to all the posted bdf additions for this device]

On 2024-02-07, Isaev Ruslan wrote:
> This is second bdf for the device: ikuai sw8
>
> This one is for ipq5018 chip (stock fw: bdwlan.b24)

Given that ipq50xx support is not merged into OpenWrt yet, nor expected
to be merged within months (I'm not aware of anyone actively working on
qualcommax/ipq50xx for OpenWrt), wouldn't it make more sense
to approach kvalo to merge it upstream via QCA/ linux-firmware? Once
it is available there, adding it to the ipq-wifi packaging would be
straight forward as part of the subtarget/ device support patches.

In general, ipq-wifi is only understood as a stopgap measure, to
provide the board data files before they're available via
linux-fimware (which may take weeks or months), but in this case I'm
not seeing ipq50xx as a whole to become available in OpenWrt any time
soon (at least multiple months, if someone were to actively work on
getting the subtarget merged), so that will give it the time needed
to get available via linux-firmware. At least these files should be
submitted to kvalo first, if they haven't been merged to linux-firmware
by the time OpenWrt is about to get qualcommax/ipq50xx and sw8, this
could be revisited, of course.

Just at this point I don't see any reason to take these files into
ipq-wifi, as long as it is completely unclear if the whole subtarget
or the device in question will ever be supported by OpenWrt.

Disclaimer: Obviously I'm not an OpenWrt developer and can't for the
project in any way. so take this as my personal suggestion for an ideal
way forward.

Regards
Stefan Lippers-Hollmann

--- End Message ---
___
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)

[Matthias Schiffer]

On 30/01/2024 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-adm mailing list
openwrt-...@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-adm


+1

Thanks,
Matthias


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] scripts: create kernel configuration upgrade script

[Elliott Mitchell]

Create a script for automating kernel version changes.  This
generates a pair of commits which cause history to remain attached to
all versioned configuration files.

Crucially this makes `git blame` work without needing
--find-copies-harder, which is too slow for routine use.  This also
updates *everything*, which greatly simplifies rebasing patches
which effect multiple devices.

Signed-off-by: Elliott Mitchell 
---
v2:
Major tweaking.  No longer try to do `git merge --ff-only `,
but instead advise user to do so.

Add usage message.

Add statement about strategy.

Adjust commit messages.  Add advice to run `git bisect --skip` if
someone ends up on that commit.
---
 scripts/kernel_upgrade.pl | 261 ++
 1 file changed, 261 insertions(+)
 create mode 100755 scripts/kernel_upgrade.pl

diff --git a/scripts/kernel_upgrade.pl b/scripts/kernel_upgrade.pl
new file mode 100755
index 00..b9fe5882a3
--- /dev/null
+++ b/scripts/kernel_upgrade.pl
@@ -0,0 +1,261 @@
+#!/usr/bin/env perl
+#
+# Copyright (C) 2024 Elliott Mitchell#
+#  #
+# This is free software, licensed under the GNU General Public License #
+# v3.  See /LICENSE for more information.  #
+#
+
+use warnings;
+use strict;
+
+use feature 'state';
+
+use Digest::SHA qw(sha1_hex);
+
+#
+# Credit to the person who knew about this workable solution:
+# 
+#
+# Which originated from:
+# 
+#
+# Problem is copying a file in git causes the new file to be created
+# without any history.  Files can move around without losing their
+# history, but that only leaves the history on the new location.
+#
+# As such this can be solved with two commits.  The first commit moves
+# files from their old name to their new name.  The second merges the
+# original commit with the rename commit.  The merge commit then has
+# files in both locations with the full history.
+#
+#
+# Note, git handles discarded data by garbage collection.  When doing
+# development on this script, beware this script is an excellent
+# garbage generator.  Frequent use of `git gc` and `git prune` may be
+# needed.
+#
+
+
+sub gethead()
+{
+   open(my $fd, '-|', 'git', 'rev-parse', 'HEAD');
+   $_=<$fd>;
+   chop;
+   return $_;
+}
+
+sub getlist($$)
+{
+   my ($target, $from)=@_;
+   my $ret=[];
+
+   local $/="\0";
+   open(my $fd, '-| :raw :bytes', 'git', 'ls-tree', '-trz', '--full-name',
+'--name-only', 'HEAD', '--', $target)||die("failed to read git tree");
+
+   while(<$fd>) {
+   chop($_);
+   push(@$ret, substr($_, 0, -length($from)))
+if(substr($_, -length($from)) eq $from);
+   }
+
+   @$ret=sort({length($b)-length($a)} @$ret);
+
+   return $ret;
+}
+
+# start of interface to git fast-import
+my $gitpid;
+my $gitfds=[undef, undef];
+
+sub startgit()
+{
+   my $child=[];
+   (pipe($child->[0], $gitfds->[0])&($gitfds->[1], $child->[1])) ||
+die("pipe() failed");
+   binmode($gitfds->[0]);
+   binmode($gitfds->[1]);
+
+   $gitpid=fork();
+   if($gitpid==0) {
+   close($gitfds->[0]);
+   close($gitfds->[1]);
+
+   open(STDIN, '<&', $child->[0]);
+   close($child->[0]);
+
+   open(STDOUT, '>&', $child->[1]);
+   close($child->[1]);
+
+   exec('git', 'fast-import', '--done');
+   die('exec() of git failed');
+   } elsif(!$gitpid) {
+   die('fork() failed');
+   }
+   close($child->[0]);
+   close($child->[1]);
+   $gitfds->[0]->autoflush(1);
+
+}
+
+sub gitsend
+{
+   return print({$gitfds->[0]} @_);
+}
+
+sub gitrecv()
+{
+   return $_=readline(${$gitfds}[1]);
+}
+
+sub gitls($$)
+{
+   my ($commit, $name)=@_;
+   local $/="\n";
+
+   $commit.=' ' if($commit);
+   gitsend("ls $commit$name\n");
+   gitrecv();
+
+   die('git ls failed') unless(/^([0-8]+)\s+[a-z]+\s+([0-9a-z]+)\s+.+$/);
+
+   return [$1, $2];
+}
+
+sub gitcommit($$$)
+{
+   my ($dest, $message, $mark)=@_;
+   local $/="\n";
+   local $|=1;
+   state $author=undef;
+   unless($author) {
+   $author=['', ''];
+   open(my $user, '-|', 'git', 'config', '--get', 'user.name');
+   while(<$user>) {
+   chomp;
+   $author->[0].=$_;
+   }
+   $author->[0]=[split(/,/, [getpwuid($<)]->[6])]->[0]
+unless($author->[0]);
+
+   open(my $email, '-|', 'git', 'config', '--get', 'user.email');
+   while(<$email>) {
+

Re: Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken

[Bjørn Mork]

Don't change the name of fw1/firmware in DT.  If you change it to fw1
then it will match the cmdline definition and the of_node is copied.
And the uimage splitter will parse it based on compatible match.

What I suggest is keeping everything else as-is, but define

 CONFIG_MTD_SPLIT_FIRMWARE=y

I'm in no way sure it will work.  But it's worth trying


Bjørn


Gio  writes:

> Bjorn I have tested your suggestion too but same result happens, the
> DTS in my buildroot is manually edited so partitions are called fw1
> and fw2 and not firmware and fw2, but the behaviour is identical
>
> [    0.337578] spi-nor spi0.0: w25q128 (16384 Kbytes)
> [    0.342531] mtd: Found partition defined in DT for
> u-boot. Assigning OF node to support nvmem.
> [    0.342544] mtd: Found partition defined in DT for
> u-boot-env. Assigning OF node to support nvmem.
> [    0.351347] mtd: Found partition defined in DT for fw1. Assigning
> OF node to support nvmem.
> [    0.360463] mtd: Found partition defined in DT for res. Assigning
> OF node to support nvmem.
> [    0.368951] mtd: Found partition defined in DT for ART. Assigning
> OF node to support nvmem.
> [    0.377434] 6 cmdlinepart partitions found on MTD device spi0.0
> [    0.391918] Creating 6 MTD partitions on "spi0.0":
> [    0.396797] 0x-0x0004 : "u-boot"
> [    0.405696] 0x0004-0x0005 : "u-boot-env"
> [    0.412065] 0x0005-0x0081 : "fw1"
> [    0.419773] 2 uimage-fw partitions found on MTD device fw1
> [    0.425404] Creating 2 MTD partitions on "fw1":
> [    0.430002] 0x-0x0024 : "kernel"
> [    0.436159] 0x0024-0x007c : "rootfs"
> [    0.443588] mtd: setting mtd4 (rootfs) as root device
> [    0.448901] 1 squashfs-split partitions found on MTD device rootfs
> [    0.455224] 0x0069-0x007c : "rootfs_data"
> [    0.462541] 0x0081-0x00fd : "firmware"
> [    0.468874] 0x00fd-0x00ff : "res"
> [    0.476261] 0x00ff-0x0100 : "ART"
> [    0.880498] switch0: Atheros AR8337 rev. 2 switch registered on mdio.0
>
> On 2/7/24 20:16, Bjørn Mork wrote:
>> To me it looks like the uimage-fw parser isn't running at all in the
>> second case.  I assume that is because CONFIG_MTD_SPLIT_FIRMWARE is
>> unset.
>>
>> The reason splitting works in the first case is because of
>> 421-drivers-mtd-parsers-add-nvmem-support-to-cmdlinepart.patch
>> which copies the "firmware" of_node from the DT, making the splitter
>> match on the compatible.  We see the
>>
>>"mtd: Found partition defined in DT for firmware."
>>
>> message from that patch.  But this only works when there is an exact
>> match between the cmdline partition and the DT partition, which there
>> isn't when "fw2" is renamed to "firmware".
>>
>> If I am correct, you can make this work simply by setting
>>
>> CONFIG_MTD_SPLIT_FIRMWARE=y
>>
>> without any other changes. I believe this should make the second case
>> work by matching on the "firmware" name.
>>
>>
>> Bjørn
>>
>> Gio  writes:
>>
>>> Digging a bit more into the code I found the culprit
>>>
>>>
>>> The function mtd_partition_split added by the patch
>>> 400-mtd-mtdsplit-support.patch
>>>
>>> After finding first partition that is either named rootfs or have
>>> "linux,rootfs" property no matter if it is contained into a "super"
>>> partition named "firmware" or not, the function stops looking for
>>> partitions to split, so because second firmware partition is located
>>> after first it never get looked inside for split partitions. This code
>>> basically render impossible to have any form of "dual boot" in
>>> OpenWrt, because no matter what are the command line passed to the
>>> kernel from the bootloader, or what is inside de DTS the first and
>>> only partition with any of those two properties will be choosen as
>>> rootfs by the kernel.
>>>
>>> Along with the code there is no comment indicating that this behavior
>>> is intentional, AFAIU the rootfs is always inside the
>>> "super-partition" called "firmware", if you can confirm my
>>> understanding is correct I can change the code so "dual boot" is
>>> supported again and submit a patch.
>>>
>>>
>>> Cheers Gio
>>>
>>>
>>> P.S. rafal as direct recipient because from git log you seems to be
>>> the last one to have made substantial changes to that part of the code
>>> ;)
>>>
>>> On 2/5/24 17:26, Gio wrote:
 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 

Re: Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken

[Gio]

Bjorn I have tested your suggestion too but same result happens, the DTS 
in my buildroot is manually edited so partitions are called fw1 and fw2 
and not firmware and fw2, but the behaviour is identical


[    0.337578] spi-nor spi0.0: w25q128 (16384 Kbytes)
[    0.342531] mtd: Found partition defined in DT for u-boot. Assigning 
OF node to support nvmem.
[    0.342544] mtd: Found partition defined in DT for u-boot-env. 
Assigning OF node to support nvmem.
[    0.351347] mtd: Found partition defined in DT for fw1. Assigning OF 
node to support nvmem.
[    0.360463] mtd: Found partition defined in DT for res. Assigning OF 
node to support nvmem.
[    0.368951] mtd: Found partition defined in DT for ART. Assigning OF 
node to support nvmem.

[    0.377434] 6 cmdlinepart partitions found on MTD device spi0.0
[    0.391918] Creating 6 MTD partitions on "spi0.0":
[    0.396797] 0x-0x0004 : "u-boot"
[    0.405696] 0x0004-0x0005 : "u-boot-env"
[    0.412065] 0x0005-0x0081 : "fw1"
[    0.419773] 2 uimage-fw partitions found on MTD device fw1
[    0.425404] Creating 2 MTD partitions on "fw1":
[    0.430002] 0x-0x0024 : "kernel"
[    0.436159] 0x0024-0x007c : "rootfs"
[    0.443588] mtd: setting mtd4 (rootfs) as root device
[    0.448901] 1 squashfs-split partitions found on MTD device rootfs
[    0.455224] 0x0069-0x007c : "rootfs_data"
[    0.462541] 0x0081-0x00fd : "firmware"
[    0.468874] 0x00fd-0x00ff : "res"
[    0.476261] 0x00ff-0x0100 : "ART"
[    0.880498] switch0: Atheros AR8337 rev. 2 switch registered on mdio.0

On 2/7/24 20:16, Bjørn Mork wrote:

To me it looks like the uimage-fw parser isn't running at all in the
second case.  I assume that is because CONFIG_MTD_SPLIT_FIRMWARE is
unset.

The reason splitting works in the first case is because of
421-drivers-mtd-parsers-add-nvmem-support-to-cmdlinepart.patch
which copies the "firmware" of_node from the DT, making the splitter
match on the compatible.  We see the

   "mtd: Found partition defined in DT for firmware."

message from that patch.  But this only works when there is an exact
match between the cmdline partition and the DT partition, which there
isn't when "fw2" is renamed to "firmware".

If I am correct, you can make this work simply by setting

CONFIG_MTD_SPLIT_FIRMWARE=y

without any other changes. I believe this should make the second case
work by matching on the "firmware" name.


Bjørn

Gio  writes:


Digging a bit more into the code I found the culprit


The function mtd_partition_split added by the patch
400-mtd-mtdsplit-support.patch

After finding first partition that is either named rootfs or have
"linux,rootfs" property no matter if it is contained into a "super"
partition named "firmware" or not, the function stops looking for
partitions to split, so because second firmware partition is located
after first it never get looked inside for split partitions. This code
basically render impossible to have any form of "dual boot" in
OpenWrt, because no matter what are the command line passed to the
kernel from the bootloader, or what is inside de DTS the first and
only partition with any of those two properties will be choosen as
rootfs by the kernel.

Along with the code there is no comment indicating that this behavior
is intentional, AFAIU the rootfs is always inside the
"super-partition" called "firmware", if you can confirm my
understanding is correct I can change the code so "dual boot" is
supported again and submit a patch.


Cheers Gio


P.S. rafal as direct recipient because from git log you seems to be
the last one to have made substantial changes to that part of the code
;)

On 2/5/24 17:26, Gio wrote:

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

    

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

[Sander Vanheule]

Hi Christian,

On Tue, 2024-01-30 at 19:15 +0100, Christian Marangi (Ansuel) wrote:
> 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

Best,
Sander

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

Re: Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken

[Bjørn Mork]

To me it looks like the uimage-fw parser isn't running at all in the
second case.  I assume that is because CONFIG_MTD_SPLIT_FIRMWARE is
unset.

The reason splitting works in the first case is because of
421-drivers-mtd-parsers-add-nvmem-support-to-cmdlinepart.patch
which copies the "firmware" of_node from the DT, making the splitter
match on the compatible.  We see the

  "mtd: Found partition defined in DT for firmware."

message from that patch.  But this only works when there is an exact
match between the cmdline partition and the DT partition, which there
isn't when "fw2" is renamed to "firmware".

If I am correct, you can make this work simply by setting

CONFIG_MTD_SPLIT_FIRMWARE=y

without any other changes. I believe this should make the second case
work by matching on the "firmware" name.


Bjørn

Gio  writes:

> Digging a bit more into the code I found the culprit
>
>
> The function mtd_partition_split added by the patch
> 400-mtd-mtdsplit-support.patch
>
> After finding first partition that is either named rootfs or have
> "linux,rootfs" property no matter if it is contained into a "super"
> partition named "firmware" or not, the function stops looking for
> partitions to split, so because second firmware partition is located
> after first it never get looked inside for split partitions. This code
> basically render impossible to have any form of "dual boot" in
> OpenWrt, because no matter what are the command line passed to the
> kernel from the bootloader, or what is inside de DTS the first and
> only partition with any of those two properties will be choosen as
> rootfs by the kernel.
>
> Along with the code there is no comment indicating that this behavior
> is intentional, AFAIU the rootfs is always inside the
> "super-partition" called "firmware", if you can confirm my
> understanding is correct I can change the code so "dual boot" is
> supported again and submit a patch.
>
>
> Cheers Gio
>
>
> P.S. rafal as direct recipient because from git log you seems to be
> the last one to have made substantial changes to that part of the code
> ;)
>
> On 2/5/24 17:26, Gio wrote:
>> 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 

Booting from any non-first-containing-rootfs partition is broken Was: Librerouter v1 booting from second partition broken

[Gio]

Digging a bit more into the code I found the culprit


The function mtd_partition_split added by the patch 
400-mtd-mtdsplit-support.patch


After finding first partition that is either named rootfs or have 
"linux,rootfs" property no matter if it is contained into a "super" 
partition named "firmware" or not, the function stops looking for 
partitions to split, so because second firmware partition is located 
after first it never get looked inside for split partitions. This code 
basically render impossible to have any form of "dual boot" in OpenWrt, 
because no matter what are the command line passed to the kernel from 
the bootloader, or what is inside de DTS the first and only partition 
with any of those two properties will be choosen as rootfs by the kernel.


Along with the code there is no comment indicating that this behavior is 
intentional, AFAIU the rootfs is always inside the "super-partition" 
called "firmware", if you can confirm my understanding is correct I can 
change the code so "dual boot" is supported again and submit a patch.



Cheers Gio


P.S. rafal as direct recipient because from git log you seems to be the 
last one to have made substantial changes to that part of the code ;)


On 2/5/24 17:26, Gio wrote:
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.
   

Re: [PATCH 1/1] scripts: create kernel configuration upgrade script

[Elliott Mitchell]

On Wed, Feb 07, 2024 at 11:53:55AM +0100, Jonas Gorski wrote:
> On Wed, 7 Feb 2024 at 02:48, Elliott Mitchell  wrote:
> >
> > Create a script for automating kernel version changes.  This
> > generates a pair of commits which cause history to remain attached
> > to all versioned configuration files.
> 
> Why is this script needed? What exactly does it do? Does it preserve
> bisectability? How would you use it? I see neither a help message nor
> any usage examples.
> 
> Please provide more detailed explanation in the commit message,
> especially since perl isn't the most common or easy to read language.

Hmm, true.  This might be closer to PoC/WIP status since I was under
major time pressure.  I rather urgently wanted to get this out *before*
the 6.6 configs were added.

Use is supposed to be fairly simple:

```
scripts/kernel_upgrade.pl 6.1 6.6

git merge --ff-only 
```

The script is *meant* to take care of that second step, but git has so
far been refusing to do that in an automated fashion.  People wanting to
test could instead create a temporary branch at the specified commit and
examine whether they like the result.



On Wed, Feb 07, 2024 at 01:33:11PM +0100, Jonas Gorski wrote:
> On Wed, 7 Feb 2024 at 12:58, Felix Baumann via openwrt-devel
>  wrote:
> >
> > This might be of help
> > 
> > Elliott linked it in his previous mail.
> >
> > It explains the problem fairly well.
> >
> > Short version:
> > Right now every new kernel version creates a new kernel config file as a 
> > copy of the old one which doesn't preserve the git history which hinders 
> > the usage of git blame.
> 
> I'm aware of the discussion, my point is that the information /
> context should to be in the commit description, not in an external
> place with no reference to it. If someone not aware of the email
> thread looks at the commit I doubt they will be able to understand the
> issue this is trying to solve, or how it is solving it. And since
> neither the issue, the solution, nor the script itself are trivial all
> three need some sort of explanation in the commit message.

I'll see about some updating.

> FWIW, git blame also supports a find copies harder (-C) that can
> detect copies, not just delete/adds as renames (can be passed multiple
> times for even harder finding). Unfortunately it's rather slow and
> does not work as well as other git command's find copies harder. Not
> sure why. Might be worth investigating.

Rather slow is an understatement.  More than an order of magnitude
slower.  This is the difference between something where you can freely
run the command if you're curious about something you notice.  Versus
something you can occasionally start when you urgently need to examine
a major oddity, but then go off taking a coffee, tea, or other break
while waiting for the result.

Right now `git blame` is too slow to be useful in many places where it
should be used.

> > git bisect should still work fairly well even without the change.
> 
> What does "fairly well" mean? Either this produces commits that work,
> or it produces commits that break the build. There is no in between.

Due to the method, inherently a single non-buildable commit is created.
If `git bisect` lands on that, you will need to run `git bisect --skip`
to continue the bisect process.  The commit message could readily be
modified to state this.

I conservatively estimate OpenWRT is generating around 3000 commits per
year.  If the kernel version changes once per year, then there is a
0.03% chance of landing on the commit.  If your typical bisect session
touches 12 commits (this seems excessive) then 0.2% of your bisect
sessions will hit these.

While infinitely greater than zero, that is a worthy trade for making
`git blame` functional on configuration files.


-- 
(\___(\___(\__  --=> 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

qca-wireless: ipq50xx: qcn9000: add bdf for ikuai sw8

[Isaev Ruslan]

One of two bdf for the device: Ikuai sw8
This one for qcn9074 wifi5 chip (stock fw: qcn9000/bdwlan.ba0).


```
[
{
"board": [
{
"names": [
"bus=pci,qmi-chip-id=0,qmi-board-id=255,variant=Ikuai-SW8"
],
"data":
"bus=pci,qmi-chip-id=0,qmi-board-id=255,variant=Ikuai-SW8.bin"
}
],
"regdb": []
}
]
```

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

Re: [PATCH 1/1] scripts: create kernel configuration upgrade script

[Jonas Gorski]

On Wed, 7 Feb 2024 at 12:58, Felix Baumann via openwrt-devel
 wrote:
> Am 7. Februar 2024 11:53:55 MEZ schrieb Jonas Gorski :
> >On Wed, 7 Feb 2024 at 02:48, Elliott Mitchell  wrote:
> >>
> >> Create a script for automating kernel version changes.  This
> >> generates a pair of commits which cause history to remain attached
> >> to all versioned configuration files.
> >
> >Why is this script needed? What exactly does it do? Does it preserve
> >bisectability? How would you use it? I see neither a help message nor
> >any usage examples.
> >
> >Please provide more detailed explanation in the commit message,
> >especially since perl isn't the most common or easy to read language.
> >
> >Regards,
> >Jonas
>
> This might be of help
> 
> Elliott linked it in his previous mail.
>
> It explains the problem fairly well.
>
> Short version:
> Right now every new kernel version creates a new kernel config file as a copy 
> of the old one which doesn't preserve the git history which hinders the usage 
> of git blame.

I'm aware of the discussion, my point is that the information /
context should to be in the commit description, not in an external
place with no reference to it. If someone not aware of the email
thread looks at the commit I doubt they will be able to understand the
issue this is trying to solve, or how it is solving it. And since
neither the issue, the solution, nor the script itself are trivial all
three need some sort of explanation in the commit message.

FWIW, git blame also supports a find copies harder (-C) that can
detect copies, not just delete/adds as renames (can be passed multiple
times for even harder finding). Unfortunately it's rather slow and
does not work as well as other git command's find copies harder. Not
sure why. Might be worth investigating.

> git bisect should still work fairly well even without the change.

What does "fairly well" mean? Either this produces commits that work,
or it produces commits that break the build. There is no in between.

Regards,
Jonas

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

Re: [PATCH 1/1] scripts: create kernel configuration upgrade script

[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 7. Februar 2024 11:53:55 MEZ schrieb Jonas Gorski :
>On Wed, 7 Feb 2024 at 02:48, Elliott Mitchell  wrote:
>>
>> Create a script for automating kernel version changes.  This
>> generates a pair of commits which cause history to remain attached
>> to all versioned configuration files.
>
>Why is this script needed? What exactly does it do? Does it preserve
>bisectability? How would you use it? I see neither a help message nor
>any usage examples.
>
>Please provide more detailed explanation in the commit message,
>especially since perl isn't the most common or easy to read language.
>
>Regards,
>Jonas
>
>___
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

This might be of help

Elliott linked it in his previous mail.

It explains the problem fairly well.

Short version:
Right now every new kernel version creates a new kernel config file as a copy 
of the old one which doesn't preserve the git history which hinders the usage 
of git blame.

git bisect should still work fairly well even without the change.

Regards
Felix

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

Re: [PATCH 1/1] scripts: create kernel configuration upgrade script

[Jonas Gorski]

On Wed, 7 Feb 2024 at 02:48, Elliott Mitchell  wrote:
>
> Create a script for automating kernel version changes.  This
> generates a pair of commits which cause history to remain attached
> to all versioned configuration files.

Why is this script needed? What exactly does it do? Does it preserve
bisectability? How would you use it? I see neither a help message nor
any usage examples.

Please provide more detailed explanation in the commit message,
especially since perl isn't the most common or easy to read language.

Regards,
Jonas

___
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)

[Luka Perkov 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 Tue, Jan 30, 2024 at 7:17 PM 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)

+1

Luka

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