Re: Moving ipq-wifi to a dedicated repo

[Robert Marko]

On Wed, 29 Jun 2022 at 23:30, Christian Marangi  wrote:
>
> On Wed, Jun 29, 2022 at 11:08:43PM +0200, Christian Lamparter wrote:
> > On 28/06/2022 23:41, Ansuel Smith wrote:
> > > As the title said, it was suggested to move the ipq-wifi package
> > > board file to a separate repo.
> >
> > ipq-wifi Makefile is painfully self aware in that regard.
> >
> > |  20 # This is intended to be used on an interim basis until 
> > device-specific
> > |  21 # board data for new devices is available through the upstream 
> > compilation
> > |  22 #
> > |  23 # Please send a mail with your device-specific board files upstream.
> > |  24 # You can find instructions and examples on the linux-wireless wiki:
> > |  25 # 
> > 
> >
> > My "go-to" solution was to point people to this notice, provided them with
> > the example/template and wait for a mail to show up on ath10k-devel before
> > merging the "new device" PRs. If OpenWrt starts a repo for boardfiles, that
> > maintainer would be left holding the bag for upstreaming the files 
> > themselves.
> >
> > So in a way, that separate repo exists in Kalle's
> > https://github.com/kvalo/ath10k-firmware and the upstream linux-firmware.git

Well, that is the ideal place,
but let's remember that last time it took him a year to merge new BDF-s.

So, as a staging ground moving the BDF-s to a new GIT repo under the OpenWrt
umbrella looks good to me.
But we should really enforce requiring people to send BDF-s upstream before the
boards are merged, with the exception of MikroTik IPQ40xx devices that have
the BDF-s extracted from flash during runtime.

Regards,
Robert
> >
> > As for moving the eye-sores to a separate repository: If the (group) of
> > people which suggested the move wants to do it for the duration:
> > Sure, why not?
> >
> > If they welcome ideas and random thoughts:
> >
> > Kalle extended the public/open-source ath10k-bdencoder tool with an
> > "--add-mbox" (parses mbox/mails) and "--commit" (commit it to a git repo)
> > options. Maybe this could be of some use?
> >
> > Yes, this would essentially create one big board-2.bin for each QCA
> > variant. But this might not be that bad, because the file can simply be
> > shipped for all non-upstreamed devices instead of the individual
> > ipq-wifi-$device packages we have now.
> >
> > Regards,
> > Christian
>
> I see your point... Ideally we should all submit the board...
> I like the idea of creating a big board-2.bin
> Would also prepare things when the board is actually pushed upstream...
>
> Will see what I can do... Also curious of the delay in submitting a
> board file and have that merged in ath10k-firmware.
>
> --
> Ansuel
>
> ___
> 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: Moving ipq-wifi to a dedicated repo

[Christian Marangi]

On Wed, Jun 29, 2022 at 11:08:43PM +0200, Christian Lamparter wrote:
> On 28/06/2022 23:41, Ansuel Smith wrote:
> > As the title said, it was suggested to move the ipq-wifi package
> > board file to a separate repo.
> 
> ipq-wifi Makefile is painfully self aware in that regard.
> 
> |  20 # This is intended to be used on an interim basis until device-specific
> |  21 # board data for new devices is available through the upstream 
> compilation
> |  22 #
> |  23 # Please send a mail with your device-specific board files upstream.
> |  24 # You can find instructions and examples on the linux-wireless wiki:
> |  25 # 
> 
> My "go-to" solution was to point people to this notice, provided them with
> the example/template and wait for a mail to show up on ath10k-devel before
> merging the "new device" PRs. If OpenWrt starts a repo for boardfiles, that
> maintainer would be left holding the bag for upstreaming the files themselves.
> 
> So in a way, that separate repo exists in Kalle's
> https://github.com/kvalo/ath10k-firmware and the upstream linux-firmware.git
> 
> As for moving the eye-sores to a separate repository: If the (group) of
> people which suggested the move wants to do it for the duration:
> Sure, why not?
> 
> If they welcome ideas and random thoughts:
> 
> Kalle extended the public/open-source ath10k-bdencoder tool with an
> "--add-mbox" (parses mbox/mails) and "--commit" (commit it to a git repo)
> options. Maybe this could be of some use?
> 
> Yes, this would essentially create one big board-2.bin for each QCA
> variant. But this might not be that bad, because the file can simply be
> shipped for all non-upstreamed devices instead of the individual
> ipq-wifi-$device packages we have now.
> 
> Regards,
> Christian

I see your point... Ideally we should all submit the board...
I like the idea of creating a big board-2.bin
Would also prepare things when the board is actually pushed upstream...

Will see what I can do... Also curious of the delay in submitting a
board file and have that merged in ath10k-firmware.

-- 
Ansuel

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

Re: Moving ipq-wifi to a dedicated repo

[Christian Lamparter]

On 28/06/2022 23:41, Ansuel Smith wrote:

As the title said, it was suggested to move the ipq-wifi package
board file to a separate repo.


ipq-wifi Makefile is painfully self aware in that regard.

|  20 # This is intended to be used on an interim basis until device-specific
|  21 # board data for new devices is available through the upstream compilation
|  22 #
|  23 # Please send a mail with your device-specific board files upstream.
|  24 # You can find instructions and examples on the linux-wireless wiki:
|  25 # 

My "go-to" solution was to point people to this notice, provided them with
the example/template and wait for a mail to show up on ath10k-devel before
merging the "new device" PRs. If OpenWrt starts a repo for boardfiles, that
maintainer would be left holding the bag for upstreaming the files themselves.

So in a way, that separate repo exists in Kalle's
https://github.com/kvalo/ath10k-firmware and the upstream linux-firmware.git

As for moving the eye-sores to a separate repository: If the (group) of
people which suggested the move wants to do it for the duration:
Sure, why not?

If they welcome ideas and random thoughts:

Kalle extended the public/open-source ath10k-bdencoder tool with an
"--add-mbox" (parses mbox/mails) and "--commit" (commit it to a git repo)
options. Maybe this could be of some use?

Yes, this would essentially create one big board-2.bin for each QCA
variant. But this might not be that bad, because the file can simply be
shipped for all non-upstreamed devices instead of the individual
ipq-wifi-$device packages we have now.

Regards,
Christian

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

Re: [REQUEST] Review changes for new nvmem patch for dynamic partition

[Christian Marangi]

On Wed, Jun 29, 2022 at 09:57:53PM +0200, Sven Eckelmann wrote:
> On Wednesday, 29 June 2022 21:37:43 CEST Christian Marangi wrote:
> > On Wed, Jun 29, 2022 at 09:32:14PM +0200, Sven Eckelmann wrote:
> > > On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote:
> > > [...]
> > > > A node name change is required for the new patch to work. Since we are
> > > > not aware of device that use cmdline as partition parser, I converted
> > > > each device that use nvmem-cells to the new format.
> > > 
> > > I am not 100% if you reference here the mtdparts from cmdline or 
> > > something 
> > > else. If the former is the case then please perform a
> > > "git grep 'partitions are passed via bootloader'".
> > >
> > 
> > Problem is that it's not that easy... I notice that comment on some
> > ipq40xx dts but many ath79 device have fixed-partition defined and still
> > use cmdlinepart with no comments about it... guess how we discovered that
> > when the nvmem migration was done.
> 
> Ah, I think you meant "we are not always aware whether a device uses cmdline
> as partition parser" and not "we are not aware of device that use cmdline as 
> partition parser". At least this would make more sense here.
> 
> Other question regarding the changes in 11-ath10k-caldata: You've dropped the 
> caldata_extract in various places which would usually copy the pre-cal (or 
> cal) data from the ART partition to /lib/firmware/$FIRMWARE. But I see in 
> various places that there are things like ath10k_patch_mac still in there. 
> Take for example linksys,ea8500:
> 
> 
>   linksys,ea8500)
> - caldata_extract "art" 0x5000 0x2f20
>   ath10k_patch_mac $(macaddr_add $(mtd_get_mac_ascii devinfo 
> hw_mac_addr) 2) 
>   ;;
> 
> I thought that a "pre-calibration" nvmem-cell would then be used by ath10k to 
> get the (pre-)cal data [1]. So it doesn't make a lot of sense to me that 
> there 
> is now still a ath10k_patch_mac which tries to operate on 
> /lib/firmware/$FIRMWARE (which should not exist). The script section 
> shouldn't 
> be called in the first place because the "pre-calibration" nvmem-cell has a 
> higher priority in ath10k, right? I can also see the changes
> to qcom-ipq8064-eax500.dtsi but no mac address fix.
>

I see, you are right. The main problem is that get_mac_ascii can't be
provided with nvmem. Wonder if we have an alternative solution to split mac
patching with precal extraction.

> Kind regards,
>   Sven
> 
> [1] 
> https://patchwork.kernel.org/project/linux-wireless/patch/20211016234609.1568317-1-chunk...@gmail.com/#24559755



-- 
Ansuel

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

Re: [REQUEST] Review changes for new nvmem patch for dynamic partition

[Sven Eckelmann]

On Wednesday, 29 June 2022 21:37:43 CEST Christian Marangi wrote:
> On Wed, Jun 29, 2022 at 09:32:14PM +0200, Sven Eckelmann wrote:
> > On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote:
> > [...]
> > > A node name change is required for the new patch to work. Since we are
> > > not aware of device that use cmdline as partition parser, I converted
> > > each device that use nvmem-cells to the new format.
> > 
> > I am not 100% if you reference here the mtdparts from cmdline or something 
> > else. If the former is the case then please perform a
> > "git grep 'partitions are passed via bootloader'".
> >
> 
> Problem is that it's not that easy... I notice that comment on some
> ipq40xx dts but many ath79 device have fixed-partition defined and still
> use cmdlinepart with no comments about it... guess how we discovered that
> when the nvmem migration was done.

Ah, I think you meant "we are not always aware whether a device uses cmdline
as partition parser" and not "we are not aware of device that use cmdline as 
partition parser". At least this would make more sense here.

Other question regarding the changes in 11-ath10k-caldata: You've dropped the 
caldata_extract in various places which would usually copy the pre-cal (or 
cal) data from the ART partition to /lib/firmware/$FIRMWARE. But I see in 
various places that there are things like ath10k_patch_mac still in there. 
Take for example linksys,ea8500:


linksys,ea8500)
-   caldata_extract "art" 0x5000 0x2f20
ath10k_patch_mac $(macaddr_add $(mtd_get_mac_ascii devinfo 
hw_mac_addr) 2) 
;;

I thought that a "pre-calibration" nvmem-cell would then be used by ath10k to 
get the (pre-)cal data [1]. So it doesn't make a lot of sense to me that there 
is now still a ath10k_patch_mac which tries to operate on 
/lib/firmware/$FIRMWARE (which should not exist). The script section shouldn't 
be called in the first place because the "pre-calibration" nvmem-cell has a 
higher priority in ath10k, right? I can also see the changes
to qcom-ipq8064-eax500.dtsi but no mac address fix.

Kind regards,
Sven

[1] 
https://patchwork.kernel.org/project/linux-wireless/patch/20211016234609.1568317-1-chunk...@gmail.com/#24559755

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [REQUEST] Review changes for new nvmem patch for dynamic partition

[Christian Marangi]

On Wed, Jun 29, 2022 at 09:32:14PM +0200, Sven Eckelmann wrote:
> On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote:
> [...]
> > A node name change is required for the new patch to work. Since we are
> > not aware of device that use cmdline as partition parser, I converted
> > each device that use nvmem-cells to the new format.
> 
> I am not 100% if you reference here the mtdparts from cmdline or something 
> else. If the former is the case then please perform a
> "git grep 'partitions are passed via bootloader'".
>

Problem is that it's not that easy... I notice that comment on some
ipq40xx dts but many ath79 device have fixed-partition defined and still
use cmdlinepart with no comments about it... guess how we discovered that
when the nvmem migration was done.

> But I am currently not 100% sure why cmdline is so special here.

cmdline is so special because it does have priority against any parser.
We had a hack patch to support nvmem with device that used cmdlinepart
but this is now dropped as we have an upstream solution.

> 
> Kind regards,
>   Sven 


-- 
Ansuel

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

Re: [REQUEST] Review changes for new nvmem patch for dynamic partition

[Sven Eckelmann]

On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote:
[...]
> A node name change is required for the new patch to work. Since we are
> not aware of device that use cmdline as partition parser, I converted
> each device that use nvmem-cells to the new format.

I am not 100% if you reference here the mtdparts from cmdline or something 
else. If the former is the case then please perform a
"git grep 'partitions are passed via bootloader'".

But I am currently not 100% sure why cmdline is so special here.

Kind regards,
Sven 

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[REQUEST] Review changes for new nvmem patch for dynamic partition

[Christian Marangi]

Hi,
Finally a correct solution for providing nvmem cells with dynamic
partition (partition from cmdline, smem, other parser...) has been
merged in mtd-next.

A node name change is required for the new patch to work. Since we are
not aware of device that use cmdline as partition parser, I converted
each device that use nvmem-cells to the new format.

This way the new patch works just as the old cmdlinepart nvmem hack patch.

I would ask for some testing and if someone can check if I did some
mistake in some dts file that got converted to the new partition node
name format.

This is the PR https://github.com/openwrt/openwrt/pull/10153

-- 
Ansuel

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

Re: [PATCH RFT] ramips: use -fno-reorder-blocks for kernel compilation

[Arınç ÜNAL]

On 29.06.2022 12:18, Arınç ÜNAL wrote:

On 20.06.2022 23:24, Rafał Miłecki wrote:

From: Rafał Miłecki 

It seems to affect (improve) NAT masquarade performance on ramips. This
is SoC family specific (that flag worsens Broadcom Northstar NAT speeds)
so it can't be applied to all devices.


I have tested the NAT and routing performance on the current master 
snapshot for Unielec U7621-06 which is from the ramips target. I don’t 
see this issue to be related to NAT as it performs very similar to just 
routing.


https://github.com/openwrt/openwrt/issues/8778#issuecomment-1168772894

I will do another test with this patch to see if it performs better.

Arınç


Here're the test results with the -fno-reorder-blocks CFLAG.

https://github.com/openwrt/openwrt/issues/8778#issuecomment-1169833326

Arınç

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

Re: [PATCH RFT] ramips: use -fno-reorder-blocks for kernel compilation

[Arınç ÜNAL]

On 20.06.2022 23:24, Rafał Miłecki wrote:

From: Rafał Miłecki 

It seems to affect (improve) NAT masquarade performance on ramips. This
is SoC family specific (that flag worsens Broadcom Northstar NAT speeds)
so it can't be applied to all devices.


I have tested the NAT and routing performance on the current master 
snapshot for Unielec U7621-06 which is from the ramips target. I don’t 
see this issue to be related to NAT as it performs very similar to just 
routing.


https://github.com/openwrt/openwrt/issues/8778#issuecomment-1168772894

I will do another test with this patch to see if it performs better.

Arınç

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