Re: BUG: as of 2967e24d0 "ramips: switch to Linux 6.6' ERX kernel is too big
On Mon, 20 May 2024 at 03:50, Russell Senior wrote: > > (try#2, damn you gmail) > > I mentioned this on IRC and as a github comment on the commit > (https://github.com/openwrt/openwrt/commit/2967e24d02775f63d9e363e6e0d351716dcc3f7c) > > My build started failing on the commit. The message I get from the > build system is: > > "WARNING: Image file > /home/openwrt/src/lede/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/ubnt_edgerouter-x-kernel.bin > is too big: 3165615 > 3145728" > > I tried a vanilla config: > > CONFIG_TARGET_ramips=y > CONFIG_TARGET_ramips_mt7621=y > CONFIG_TARGET_ramips_mt7621_DEVICE_ubnt_edgerouter-x=y > CONFIG_DEVEL=y > CONFIG_BUILD_LOG=y > > "WARNING: Image file > /home/openwrt/src/lede/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/ubnt_edgerouter-x-kernel.bin > is too big: 3165361 > 3145728" > > I notice that there are two kernel partitions on the NAND flash, each > of which is 3MB: > > [1.011604] 6 fixed-partitions partitions found on MTD device mt7621-nand > [1.025136] Creating 6 MTD partitions on "mt7621-nand": > [1.035552] 0x-0x0008 : "u-boot" > [1.054525] 0x0008-0x000e : "u-boot-env" > [1.072180] 0x000e-0x0014 : "factory" > [1.089606] 0x0014-0x0044 : "kernel1" > [1.147424] 0x0044-0x0074 : "kernel2" > [1.204979] 0x0074-0x0ff0 : "ubi" > > Which suggests two possible fixes: > > a) cannibalize the second kernel parition (might require a different > u-boot?); or > > b) use an intermediate u-boot that looks for the kernel in a ubi partition. > > or > > c) make the damn kernel smaller. > > Thoughts? Take a look at: https://github.com/openwrt/openwrt/pull/15194 Regards, Robert > > -- > Russell Senior > russ...@personaltelco.net > > ___ > 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: Install LuCI for snapshots builds
On Wed, 8 May 2024 at 03:32, Rich Brown wrote: > > Daniel, > > I find your comment persuasive. I was not aware of the cost of including LuCI > In the nightly builds. I withdraw my "+1" for including LuCI. > > On May 7, 2024, at 8:38 PM, Daniel Golle wrote: > > ...That means that a single build takes around 2~3 hours, > depending on the target and the machine carrying out the build. In this > way we manage to have every target build once approximately every 24 > hours. > > > I see the value of having a ~24 hour build cycle for snapshot builds. (And > the total lack of value of weekly snapshot builds.) > > I also like your suggestion of recommending the Firmware Selector for > snapshot+LuCI builds. Do we think it is a stable platform for this use case? > (I see a slow drip of messages on the Forum saying that "Firmware Selector > doesn't work" or "Attended Sysupgrade doesn't work" > > Thanks for weighing in. I have to agree with this as well, as it changes things completely so I also withdraw my +1 for LuCI by default if it would cause a massive slowdown. Regards, Robert > > Rich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Install LuCI for snapshots builds
On Tue, 7 May 2024 at 23:25, Paul Spooren wrote: > > Hi all, > > For some reason (resource usage?) our snapshot builds do not include the LuCI > web interface. I think it’s an advantage to have LuCI installed in snapshot > images since a) it installed for all releases anyway and b) often it’s just > nice to have the web interface directly available. > > Is anyone against having the interface installed by default? I remember from > multiple (in-person) discussion with fellow developers, that they’d prefer it > being installed. > > If it’s an oversight I’d like to see it added to the default packages (via > the builedbot config), if there’s a reason to keep it from snapshots, I’d > like to understand the details. +1 for LuCI by default in snapshots as well from me. Regards, Robert > > Thanks, > Paul > ___ > 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: Question to recent Qualcomm CVEs
On Tue, 30 Apr 2024 at 15:02, Kalle Valo wrote: > > Robert Marko writes: > > > On Tue, 30 Apr 2024 at 10:48, Kalle Valo wrote: > > > >> > >> Robert Marko writes: > >> > >> > On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote: > >> >> > >> >> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > >> >> > It's quite strange that they updated 2.5.0.1 branch first but my > >> >> > understanding that there should be updates for the newer 2.7.0.1 > >> >> > branch > >> >> > as well (2.7.0.1 branch is also in linux-firmware). > >> >> > >> >> Yes, I also told them in the support ticket that this is from an older > >> >> branch > >> >> than what is currently shipped in linux-firmware.git. But they told me > >> >> that they are working on newer versions (whatever that means) - but they > >> >> wanted to handle first the update to ATH.11.4 (2.5.0.x) and then > >> >> step-by-step release it for newer firmware branches. It seem like that > >> >> would be > >> >> up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the > >> >> AP > >> >> SoCs. > >> > > >> > I would like to point out that IPQ6018 doesn't even have anything > >> > newer than 2.5.0.1 available publicly. > >> > >> But I do see WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 for IPQ6018: > >> > >> https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ6018/hw1.0/2.7.0.1/WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1?ref_type=heads > >> > >> And that release seems to be also in linux-firmware: > >> > >> File: ath11k/IPQ6018/hw1.0/q6_fw.mdt > >> Version: WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 > >> > >> Am I missing something? Or did you mean IPQ5018 which only has a release > >> from 2.6.0.1 branch? > >> > >> https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ5018/hw1.0?ref_type=heads > > > > Ah yes, sorry for the confusion, I meant to say newer than 2.5.0.1 > > that actually works. > > All of the newer public FW than 2.5.0.1 that we tried in OpenWrt will > > just crash, we had the same issue with 2.6 and 2.7 FW on > > IPQ8074 and it was fixed in 2.9.0.1 but there is no 2.9.0.1 public for > > IPQ6018. > > Ah, is the issue you are talking about this bug: > > https://bugzilla.kernel.org/show_bug.cgi?id=216515 > > Or is this another issue? Yeah, that is the issue for IPQ8074, we just skipped the 2.6 and 2.7 FW and went for 2.9. For IPQ6018 it seems that we have BDF compatibility issues with most FW newer than 2.4 or 2.5 max. Its been some time since I last checked what boards work with what FW on IPQ6018. Regards, Robert > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
On Tue, 30 Apr 2024 at 10:48, Kalle Valo wrote: > > Robert Marko writes: > > > On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote: > >> > >> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > >> > It's quite strange that they updated 2.5.0.1 branch first but my > >> > understanding that there should be updates for the newer 2.7.0.1 branch > >> > as well (2.7.0.1 branch is also in linux-firmware). > >> > >> Yes, I also told them in the support ticket that this is from an older > >> branch > >> than what is currently shipped in linux-firmware.git. But they told me > >> that they are working on newer versions (whatever that means) - but they > >> wanted to handle first the update to ATH.11.4 (2.5.0.x) and then > >> step-by-step release it for newer firmware branches. It seem like that > >> would be > >> up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP > >> SoCs. > > > > I would like to point out that IPQ6018 doesn't even have anything > > newer than 2.5.0.1 available publicly. > > But I do see WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 for IPQ6018: > > https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ6018/hw1.0/2.7.0.1/WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1?ref_type=heads > > And that release seems to be also in linux-firmware: > > File: ath11k/IPQ6018/hw1.0/q6_fw.mdt > Version: WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 > > Am I missing something? Or did you mean IPQ5018 which only has a release > from 2.6.0.1 branch? > > https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ5018/hw1.0?ref_type=heads Ah yes, sorry for the confusion, I meant to say newer than 2.5.0.1 that actually works. All of the newer public FW than 2.5.0.1 that we tried in OpenWrt will just crash, we had the same issue with 2.6 and 2.7 FW on IPQ8074 and it was fixed in 2.9.0.1 but there is no 2.9.0.1 public for IPQ6018. Regards, Robert > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote: > > On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > > It's quite strange that they updated 2.5.0.1 branch first but my > > understanding that there should be updates for the newer 2.7.0.1 branch > > as well (2.7.0.1 branch is also in linux-firmware). > > Yes, I also told them in the support ticket that this is from an older branch > than what is currently shipped in linux-firmware.git. But they told me > that they are working on newer versions (whatever that means) - but they > wanted to handle first the update to ATH.11.4 (2.5.0.x) and then > step-by-step release it for newer firmware branches. It seem like that would > be > up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP > SoCs. I would like to point out that IPQ6018 doesn't even have anything newer than 2.5.0.1 available publicly. Regards, Robert > > Kind regards, > Sven___ > 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: Issue after changing from xz to zstd
On Sat, 6 Apr 2024 at 23:32, Robert Marko wrote: > > On Sat, 6 Apr 2024 at 22:35, e9hack wrote: > > > > Am 06.04.2024 um 21:50 schrieb Robert Marko: > > > On Sat, 6 Apr 2024 at 21:47, Hartmut Birr wrote: > > >> > > >> Hi, > > >> > > >> I did change the Makefile for dnsmasq in the way that I give: > > >> > > >> PKG_SOURCE_URL:=git://thekelleys.org.uk/dnsmasq.git > > >> PKG_SOURCE_PROTO:=git > > >> PKG_SOURCE_DATE:=2024-03-27 > > >> PKG_SOURCE_VERSION:=550c368adea12b312f83686c61f9015c122046c2# Treat > > >> cache insertion failure of DNSKEY and DS records as another resource > > >> problem and fail validation with suitable logging. > > >> PKG_MIRROR_HASH:=284a34bdb967ec8a9dff132df065ca64e9a1819d79bb8cecee1af001e22d626c > > >> > > >> Before changing to zstd, the generated source tar ball contains a file > > >> 'VERSION' with content '$Format:%d$'. This does match the dnsmasq git > > >> repository. After changing to zstd, VERSION contains ' (HEAD, > > >> origin/master, origin/HEAD, master)'. > > >> > > >> Any idea why VERSION is manipulated? > > >> > > >> I generate automatically a patch which modifies VERSION to see the > > >> commit hash via logread. Applying the patch doesn't work any more. > > >> > > >> dnsmasq/patches/999-dnsmasq-version.patch: > > >> diff --git a/VERSION b/VERSION > > >> index 998eb1f..9977908 100644 > > >> --- a/VERSION > > >> +++ b/VERSION > > >> @@ -1 +1 @@ > > >> -$Format:%d$ > > >> + (master, v2.90deb2-8-g550c368, head) > > >> > > > > > > Hi Hartmut, > > > We are now using git-archive to make a tarball of git repositories in > > > order to make them reproducible which fixes a long standing issue. > > > git-archive respects .gitattributes so that along with: > > > https://github.com/imp/dnsmasq/commit/2aaea18f432374fd062370f2d899e47849558b2f > > > > > > Is most likely the cause. > > > > I did add another static patch to solve the issue for me temporary: > > > > --- a/VERSION 2024-03-27 17:00:06.0 +0100 > > +++ b/VERSION 2024-03-27 17:00:06.0 +0100 > > @@ -1 +1 @@ > > - (HEAD, origin/master, origin/HEAD, master) > > +$Format:%d$ > > > > I generate 999-dnsmasq-version.patch via the following extension in the > > Makefile: > > > > define Build/Prepare > > mkdir -p $(TOPDIR)/tmp/dl && \ > > cd $(TOPDIR)/tmp/dl && \ > > rm -rf $(PKG_SOURCE_SUBDIR) && \ > > git clone -4 $(PKG_SOURCE_URL) $(PKG_SOURCE_SUBDIR) > > --recursive && \ > > cd $(PKG_SOURCE_SUBDIR) && \ > > git checkout $(PKG_SOURCE_VERSION) && \ > > version=`git describe` && \ > > echo " (master, version, head)" > VERSION && \ > > git diff VERSION > 999-dnsmasq-version.patch > > $(CP) > > $(TOPDIR)/tmp/dl/$(PKG_SOURCE_SUBDIR)/999-dnsmasq-version.patch ./patches > > touch -c -r ./Makefile ./patches/999-dnsmasq-version.patch > > cd $(TOPDIR)/tmp/dl && \ > > rm -rf $(PKG_SOURCE_SUBDIR) > > $(call Build/Prepare/Default) > > endef > > Hi, can I ask what is the point though? > That VERSION file contains a placeholder format specifier that is > supposed to be filled with a version > by git, it was most likely meant to be used with git-archive as > .gitattributes specifies that VERSION should > be updated. > > $Format:%d$ is just the format specifier placeholder to be replaced. Hm, I might have understood your previous statement wrong because when checking dnsmasq 2.90 tarball on OpenWrt sources VERSION is clearly properly populated so git-archive is most likely the culprit by not populating it with the commit, tag etc but by just the remote and branch names. Regards, Robert > > Regards, > Robert > > > > Regards, > > Hartmut > > > > > > > > Regards, > > > Robert > > > > > >> Regards, > > >> Hartmut > > >> > > >> ___ > > >> 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: Issue after changing from xz to zstd
On Sat, 6 Apr 2024 at 22:35, e9hack wrote: > > Am 06.04.2024 um 21:50 schrieb Robert Marko: > > On Sat, 6 Apr 2024 at 21:47, Hartmut Birr wrote: > >> > >> Hi, > >> > >> I did change the Makefile for dnsmasq in the way that I give: > >> > >> PKG_SOURCE_URL:=git://thekelleys.org.uk/dnsmasq.git > >> PKG_SOURCE_PROTO:=git > >> PKG_SOURCE_DATE:=2024-03-27 > >> PKG_SOURCE_VERSION:=550c368adea12b312f83686c61f9015c122046c2# Treat > >> cache insertion failure of DNSKEY and DS records as another resource > >> problem and fail validation with suitable logging. > >> PKG_MIRROR_HASH:=284a34bdb967ec8a9dff132df065ca64e9a1819d79bb8cecee1af001e22d626c > >> > >> Before changing to zstd, the generated source tar ball contains a file > >> 'VERSION' with content '$Format:%d$'. This does match the dnsmasq git > >> repository. After changing to zstd, VERSION contains ' (HEAD, > >> origin/master, origin/HEAD, master)'. > >> > >> Any idea why VERSION is manipulated? > >> > >> I generate automatically a patch which modifies VERSION to see the commit > >> hash via logread. Applying the patch doesn't work any more. > >> > >> dnsmasq/patches/999-dnsmasq-version.patch: > >> diff --git a/VERSION b/VERSION > >> index 998eb1f..9977908 100644 > >> --- a/VERSION > >> +++ b/VERSION > >> @@ -1 +1 @@ > >> -$Format:%d$ > >> + (master, v2.90deb2-8-g550c368, head) > >> > > > > Hi Hartmut, > > We are now using git-archive to make a tarball of git repositories in > > order to make them reproducible which fixes a long standing issue. > > git-archive respects .gitattributes so that along with: > > https://github.com/imp/dnsmasq/commit/2aaea18f432374fd062370f2d899e47849558b2f > > > > Is most likely the cause. > > I did add another static patch to solve the issue for me temporary: > > --- a/VERSION 2024-03-27 17:00:06.0 +0100 > +++ b/VERSION 2024-03-27 17:00:06.0 +0100 > @@ -1 +1 @@ > - (HEAD, origin/master, origin/HEAD, master) > +$Format:%d$ > > I generate 999-dnsmasq-version.patch via the following extension in the > Makefile: > > define Build/Prepare > mkdir -p $(TOPDIR)/tmp/dl && \ > cd $(TOPDIR)/tmp/dl && \ > rm -rf $(PKG_SOURCE_SUBDIR) && \ > git clone -4 $(PKG_SOURCE_URL) $(PKG_SOURCE_SUBDIR) > --recursive && \ > cd $(PKG_SOURCE_SUBDIR) && \ > git checkout $(PKG_SOURCE_VERSION) && \ > version=`git describe` && \ > echo " (master, version, head)" > VERSION && \ > git diff VERSION > 999-dnsmasq-version.patch > $(CP) $(TOPDIR)/tmp/dl/$(PKG_SOURCE_SUBDIR)/999-dnsmasq-version.patch > ./patches > touch -c -r ./Makefile ./patches/999-dnsmasq-version.patch > cd $(TOPDIR)/tmp/dl && \ > rm -rf $(PKG_SOURCE_SUBDIR) > $(call Build/Prepare/Default) > endef Hi, can I ask what is the point though? That VERSION file contains a placeholder format specifier that is supposed to be filled with a version by git, it was most likely meant to be used with git-archive as .gitattributes specifies that VERSION should be updated. $Format:%d$ is just the format specifier placeholder to be replaced. Regards, Robert > > Regards, > Hartmut > > > > > Regards, > > Robert > > > >> Regards, > >> Hartmut > >> > >> ___ > >> 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: Issue after changing from xz to zstd
On Sat, 6 Apr 2024 at 21:47, Hartmut Birr wrote: > > Hi, > > I did change the Makefile for dnsmasq in the way that I give: > > PKG_SOURCE_URL:=git://thekelleys.org.uk/dnsmasq.git > PKG_SOURCE_PROTO:=git > PKG_SOURCE_DATE:=2024-03-27 > PKG_SOURCE_VERSION:=550c368adea12b312f83686c61f9015c122046c2# Treat cache > insertion failure of DNSKEY and DS records as another resource problem and > fail validation with suitable logging. > PKG_MIRROR_HASH:=284a34bdb967ec8a9dff132df065ca64e9a1819d79bb8cecee1af001e22d626c > > Before changing to zstd, the generated source tar ball contains a file > 'VERSION' with content '$Format:%d$'. This does match the dnsmasq git > repository. After changing to zstd, VERSION contains ' (HEAD, origin/master, > origin/HEAD, master)'. > > Any idea why VERSION is manipulated? > > I generate automatically a patch which modifies VERSION to see the commit > hash via logread. Applying the patch doesn't work any more. > > dnsmasq/patches/999-dnsmasq-version.patch: > diff --git a/VERSION b/VERSION > index 998eb1f..9977908 100644 > --- a/VERSION > +++ b/VERSION > @@ -1 +1 @@ > -$Format:%d$ > + (master, v2.90deb2-8-g550c368, head) > Hi Hartmut, We are now using git-archive to make a tarball of git repositories in order to make them reproducible which fixes a long standing issue. git-archive respects .gitattributes so that along with: https://github.com/imp/dnsmasq/commit/2aaea18f432374fd062370f2d899e47849558b2f Is most likely the cause. Regards, Robert > Regards, > Hartmut > > ___ > 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: Definition for flash w25q128 is wrong
On Mon, 1 Apr 2024 at 15:00, e9hack wrote:
>
> Am 01.04.2024 um 11:54 schrieb Robert Marko:
> > On Mon, 1 Apr 2024 at 11:25, e9hack wrote:
> >>
> >> Am 01.04.2024 um 11:06 schrieb Robert Marko:
> >>> On Mon, 1 Apr 2024 at 10:32, e9hack wrote:
> >>>>
> >>>> Am 01.04.2024 um 10:14 schrieb Robert Marko:
> >>>>> On Mon, 1 Apr 2024 at 06:29, e9hack wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm using a TP-LINK WDR3600 with a bigger flash. Since some time the
> >>>>>> router hangs in an endless boot loop. I see the following message:
> >>>>>>
> >>>>>> ...
> >>>>>> [0.402716] spi-nor spi0.0: BFPT parsing failed. Please consider
> >>>>>> using SPI_NOR_SKIP_SFDP when declaring the flash
> >>>>>> [0.413217] spi-nor: probe of spi0.0 failed with error -22
> >>>>>> ...
> >>>>>> [0.926180] /dev/root: Can't open blockdev
> >>>>>> [0.930427] VFS: Cannot open root device "(null)" or
> >>>>>> unknown-block(0,0): error -6
> >>>>>> [0.938037] Please append a correct "root=" boot option; here are
> >>>>>> the available partitions:
> >>>>>> [0.946520] Kernel panic - not syncing: VFS: Unable to mount root
> >>>>>> fs on unknown-block(0,0)
> >>>>>> [0.954914] Rebooting in 1 seconds..
> >>>>>>
> >>>>>> It looks like the definition for the flash is wrong:
> >>>>>>
> >>>>>> --- a/drivers/mtd/spi-nor/winbond.c 2024-03-15 19:27:50.0
> >>>>>> +0100
> >>>>>> +++ b/drivers/mtd/spi-nor/winbond.c 2024-04-01 05:59:17.166780732
> >>>>>> +0200
> >>>>>> @@ -120,8 +120,8 @@ static const struct flash_info winbond_n
> >>>>>>NO_SFDP_FLAGS(SECT_4K) },
> >>>>>>{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16)
> >>>>>>NO_SFDP_FLAGS(SECT_4K) },
> >>>>>> - { "w25q128", INFO(0xef4018, 0, 0, 0)
> >>>>>> - PARSE_SFDP
> >>>>>> + { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256)
> >>>>>> + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
> >>>>>> SPI_NOR_QUAD_READ)
> >>>>>>FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> >>>>>>{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512)
> >>>>>>NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
> >>>>>> SPI_NOR_QUAD_READ)
> >>>>>>
> >>>>>> With these changes, the flash will be detected properly.
> >>>>>
> >>>>> Yeah, I am not so sure this is correct as all w25q128 versions have
> >>>>> SFDP table so skipping SFDP parsing
> >>>>> isn't really correct.
> >>>>> Can you check what is the exact model you have?
> >>>>
> >>>> The chip (SOIC8) is marked with:
> >>>>
> >>>> winbond
> >>>> 25Q128FVSG
> >>>> 1327
> >>>
> >>> If it is Genuine Winbond then it has an SFDP table according to the
> >>> datasheet:
> >>> https://www.winbond.com/hq/support/documentation/downloadV2022.jsp?__locale=en=/support/resources/.content/item/DA00-W25Q128FV.html=1
> >>>
> >>> AFAIK, all Winbond NOR with datecode 1124 and onwards have SFDP tables.
> >>>
> >>> Has this happened with kernel 6.1 or been going on for a while?
> >>
> >> My build from October is using kernel 5.15.133. I assume it is an issue of
> >> kernel 6.1.
> >>
> >> It looks like a driver issue. A SOIC8 housing doesn't support dual/quad
> >> SPI. The flash will be detect, if I change
> >>
> >> PARSE_SFDP to NO_SFDP_FLAGS(SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ).
> >
> > Hm, it really looks like your revision has broken SFDP but since
> > Winbond in their ultimate wisdom decided
> > that it was best to share the same JEDEC ID with other revisions SFDP
> > was enabled via:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mtd/spi-nor/winbond.c?h=v6.1.83=7c6ba20a0b9aeb82a6c097c74ccbecdda8e9fc25
> >
> > So you really need to report this to the linux-mtd crowd.
> > Can you check if SFDP table can be dumped on your NOR, cause there
> > should be one but most likely one of the tables is broken?
>
> The flash does not have a SFDP. I use another TP-LINK router. This is an
> Archer C7 v2. It has the same flash chip with date code 1528. This flash has
> a SFDP.
Then it would be best to send a revert upstream.
Regards,
Robert
>
> Regards,
> Hartmut
> >
> > Regards,
> > Robert
> >>
> >> Regards,
> >> Hartmut
> >>
> >>>
> >>> Regards,
> >>> Robert
> >>>
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>> Robert
> >>>>>>
> >>>>>> Regards,
> >>>>>> Hartmut
> >>>>>>
> >>>>>> ___
> >>>>>> 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: Definition for flash w25q128 is wrong
On Mon, 1 Apr 2024 at 11:25, e9hack wrote:
>
> Am 01.04.2024 um 11:06 schrieb Robert Marko:
> > On Mon, 1 Apr 2024 at 10:32, e9hack wrote:
> >>
> >> Am 01.04.2024 um 10:14 schrieb Robert Marko:
> >>> On Mon, 1 Apr 2024 at 06:29, e9hack wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I'm using a TP-LINK WDR3600 with a bigger flash. Since some time the
> >>>> router hangs in an endless boot loop. I see the following message:
> >>>>
> >>>> ...
> >>>> [0.402716] spi-nor spi0.0: BFPT parsing failed. Please consider
> >>>> using SPI_NOR_SKIP_SFDP when declaring the flash
> >>>> [0.413217] spi-nor: probe of spi0.0 failed with error -22
> >>>> ...
> >>>> [0.926180] /dev/root: Can't open blockdev
> >>>> [0.930427] VFS: Cannot open root device "(null)" or
> >>>> unknown-block(0,0): error -6
> >>>> [0.938037] Please append a correct "root=" boot option; here are the
> >>>> available partitions:
> >>>> [0.946520] Kernel panic - not syncing: VFS: Unable to mount root fs
> >>>> on unknown-block(0,0)
> >>>> [0.954914] Rebooting in 1 seconds..
> >>>>
> >>>> It looks like the definition for the flash is wrong:
> >>>>
> >>>> --- a/drivers/mtd/spi-nor/winbond.c 2024-03-15 19:27:50.0
> >>>> +0100
> >>>> +++ b/drivers/mtd/spi-nor/winbond.c 2024-04-01 05:59:17.166780732
> >>>> +0200
> >>>> @@ -120,8 +120,8 @@ static const struct flash_info winbond_n
> >>>> NO_SFDP_FLAGS(SECT_4K) },
> >>>> { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16)
> >>>> NO_SFDP_FLAGS(SECT_4K) },
> >>>> - { "w25q128", INFO(0xef4018, 0, 0, 0)
> >>>> - PARSE_SFDP
> >>>> + { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256)
> >>>> + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
> >>>> SPI_NOR_QUAD_READ)
> >>>> FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> >>>> { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512)
> >>>> NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
> >>>> SPI_NOR_QUAD_READ)
> >>>>
> >>>> With these changes, the flash will be detected properly.
> >>>
> >>> Yeah, I am not so sure this is correct as all w25q128 versions have
> >>> SFDP table so skipping SFDP parsing
> >>> isn't really correct.
> >>> Can you check what is the exact model you have?
> >>
> >> The chip (SOIC8) is marked with:
> >>
> >> winbond
> >> 25Q128FVSG
> >> 1327
> >
> > If it is Genuine Winbond then it has an SFDP table according to the
> > datasheet:
> > https://www.winbond.com/hq/support/documentation/downloadV2022.jsp?__locale=en=/support/resources/.content/item/DA00-W25Q128FV.html=1
> >
> > AFAIK, all Winbond NOR with datecode 1124 and onwards have SFDP tables.
> >
> > Has this happened with kernel 6.1 or been going on for a while?
>
> My build from October is using kernel 5.15.133. I assume it is an issue of
> kernel 6.1.
>
> It looks like a driver issue. A SOIC8 housing doesn't support dual/quad SPI.
> The flash will be detect, if I change
>
> PARSE_SFDP to NO_SFDP_FLAGS(SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ).
Hm, it really looks like your revision has broken SFDP but since
Winbond in their ultimate wisdom decided
that it was best to share the same JEDEC ID with other revisions SFDP
was enabled via:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mtd/spi-nor/winbond.c?h=v6.1.83=7c6ba20a0b9aeb82a6c097c74ccbecdda8e9fc25
So you really need to report this to the linux-mtd crowd.
Can you check if SFDP table can be dumped on your NOR, cause there
should be one but most likely one of the tables is broken?
Regards,
Robert
>
> Regards,
> Hartmut
>
> >
> > Regards,
> > Robert
> >
> >>
> >>>
> >>> Regards,
> >>> Robert
> >>>>
> >>>> Regards,
> >>>> Hartmut
> >>>>
> >>>> ___
> >>>> 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: Definition for flash w25q128 is wrong
On Mon, 1 Apr 2024 at 10:32, e9hack wrote:
>
> Am 01.04.2024 um 10:14 schrieb Robert Marko:
> > On Mon, 1 Apr 2024 at 06:29, e9hack wrote:
> >>
> >> Hi,
> >>
> >> I'm using a TP-LINK WDR3600 with a bigger flash. Since some time the
> >> router hangs in an endless boot loop. I see the following message:
> >>
> >> ...
> >> [0.402716] spi-nor spi0.0: BFPT parsing failed. Please consider using
> >> SPI_NOR_SKIP_SFDP when declaring the flash
> >> [0.413217] spi-nor: probe of spi0.0 failed with error -22
> >> ...
> >> [0.926180] /dev/root: Can't open blockdev
> >> [0.930427] VFS: Cannot open root device "(null)" or
> >> unknown-block(0,0): error -6
> >> [0.938037] Please append a correct "root=" boot option; here are the
> >> available partitions:
> >> [0.946520] Kernel panic - not syncing: VFS: Unable to mount root fs on
> >> unknown-block(0,0)
> >> [0.954914] Rebooting in 1 seconds..
> >>
> >> It looks like the definition for the flash is wrong:
> >>
> >> --- a/drivers/mtd/spi-nor/winbond.c 2024-03-15 19:27:50.0 +0100
> >> +++ b/drivers/mtd/spi-nor/winbond.c 2024-04-01 05:59:17.166780732 +0200
> >> @@ -120,8 +120,8 @@ static const struct flash_info winbond_n
> >> NO_SFDP_FLAGS(SECT_4K) },
> >> { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16)
> >> NO_SFDP_FLAGS(SECT_4K) },
> >> - { "w25q128", INFO(0xef4018, 0, 0, 0)
> >> - PARSE_SFDP
> >> + { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256)
> >> + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
> >> SPI_NOR_QUAD_READ)
> >> FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> >> { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512)
> >> NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
> >> SPI_NOR_QUAD_READ)
> >>
> >> With these changes, the flash will be detected properly.
> >
> > Yeah, I am not so sure this is correct as all w25q128 versions have
> > SFDP table so skipping SFDP parsing
> > isn't really correct.
> > Can you check what is the exact model you have?
>
> The chip (SOIC8) is marked with:
>
> winbond
> 25Q128FVSG
> 1327
If it is Genuine Winbond then it has an SFDP table according to the datasheet:
https://www.winbond.com/hq/support/documentation/downloadV2022.jsp?__locale=en=/support/resources/.content/item/DA00-W25Q128FV.html=1
AFAIK, all Winbond NOR with datecode 1124 and onwards have SFDP tables.
Has this happened with kernel 6.1 or been going on for a while?
Regards,
Robert
>
> >
> > Regards,
> > Robert
> >>
> >> Regards,
> >> Hartmut
> >>
> >> ___
> >> 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: Definition for flash w25q128 is wrong
On Mon, 1 Apr 2024 at 06:29, e9hack wrote:
>
> Hi,
>
> I'm using a TP-LINK WDR3600 with a bigger flash. Since some time the router
> hangs in an endless boot loop. I see the following message:
>
> ...
> [0.402716] spi-nor spi0.0: BFPT parsing failed. Please consider using
> SPI_NOR_SKIP_SFDP when declaring the flash
> [0.413217] spi-nor: probe of spi0.0 failed with error -22
> ...
> [0.926180] /dev/root: Can't open blockdev
> [0.930427] VFS: Cannot open root device "(null)" or unknown-block(0,0):
> error -6
> [0.938037] Please append a correct "root=" boot option; here are the
> available partitions:
> [0.946520] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
> [0.954914] Rebooting in 1 seconds..
>
> It looks like the definition for the flash is wrong:
>
> --- a/drivers/mtd/spi-nor/winbond.c 2024-03-15 19:27:50.0 +0100
> +++ b/drivers/mtd/spi-nor/winbond.c 2024-04-01 05:59:17.166780732 +0200
> @@ -120,8 +120,8 @@ static const struct flash_info winbond_n
> NO_SFDP_FLAGS(SECT_4K) },
> { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16)
> NO_SFDP_FLAGS(SECT_4K) },
> - { "w25q128", INFO(0xef4018, 0, 0, 0)
> - PARSE_SFDP
> + { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256)
> + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512)
> NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
>
> With these changes, the flash will be detected properly.
Yeah, I am not so sure this is correct as all w25q128 versions have
SFDP table so skipping SFDP parsing
isn't really correct.
Can you check what is the exact model you have?
Regards,
Robert
>
> Regards,
> Hartmut
>
> ___
> 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
Merged: kernel: kmod-phy-smsc: add dependency on crc16
Merged. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: kmod-phy-smsc: add dependency on crc16
On Thu, 28 Mar 2024 at 18:03, Tomasz Maciej Nowak wrote: > > From: Tomasz Maciej Nowak > > Introduced WoL feature needs CRC16 support. > > Signed-off-by: Tomasz Maciej Nowak > --- > package/kernel/linux/modules/netdevices.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/kernel/linux/modules/netdevices.mk > b/package/kernel/linux/modules/netdevices.mk > index af1d8b485e00..724f35df74a2 100644 > --- a/package/kernel/linux/modules/netdevices.mk > +++ b/package/kernel/linux/modules/netdevices.mk > @@ -363,7 +363,7 @@ define KernelPackage/phy-smsc > SUBMENU:=$(NETWORK_DEVICES_MENU) > TITLE:=SMSC PHY driver > KCONFIG:=CONFIG_SMSC_PHY > - DEPENDS:=+kmod-libphy > + DEPENDS:=+kmod-libphy +!LINUX_5_15||!LINUX_6_1:kmod-lib-crc16 I would prefer depending on 6.6 for the kmod, not the other way around. Regards, Robert > FILES:=$(LINUX_DIR)/drivers/net/phy/smsc.ko > AUTOLOAD:=$(call AutoProbe,smsc) > endef > -- > 2.44.0 > > > ___ > 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: GPIO numbering and ucidef_add_gpio_switch in kernel 6.6
On Mon, 18 Mar 2024 at 06:31, Mathew McBride wrote:
>
> Hi all,
>
> A change in kernel 6.2 ("gpio: Get rid of ARCH_NR_GPIOS (v2)") [1] resulted
> in the GPIO chip base numbers changing on some architectures (x86, arm and
> arm64 were directly modified in that series).
>
> This may cause issues with /etc/board.d/03_gpio_switches scripts as the GPIO
> numbers will change when moving to the 6.6 kernel.
Hi Matthew,
This has been an issue for a while as GPIO numbers are not stable and
have never been guaranteed so.
>
> For example, on our (Traverse Ten64) board, the I2C GPIO expander (PCA953x)
> used to be numbered from 368, now it is numbered from 640:
>
> # Old
> cat /sys/kernel/debug/gpio:
> gpiochip4: GPIOs 368-383, parent: i2c/0-0076, 0-0076, can sleep:
> gpiochip3: GPIOs 384-415, parent: platform/233.gpio, 233.gpio:
> gpiochip2: GPIOs 416-447, parent: platform/232.gpio, 232.gpio:
> gpiochip1: GPIOs 448-479, parent: platform/231.gpio, 231.gpio:
> gpiochip0: GPIOs 480-511, parent: platform/230.gpio, 230.gpio:
>
> # New
> gpiochip0: GPIOs 512-543, parent: platform/230.gpio, 230.gpio:
> gpiochip1: GPIOs 544-575, parent: platform/231.gpio, 231.gpio:
> gpiochip2: GPIOs 576-607, parent: platform/232.gpio, 232.gpio:
> gpiochip3: GPIOs 608-639, parent: platform/233.gpio, 233.gpio:
> gpiochip4: GPIOs 640-655, parent: i2c/0-0076, 0-0076, can sleep:
>
> I have tried to address this in my armsr/6.6 pull request, but I don't think
> the solution is very elegant:
> https://github.com/openwrt/openwrt/pull/14896/commits/b74da3cd82d69e99dda357e61cae9b32072bca80
>
> (I still need to figure out uci migration of these settings between 6.1 and
> 6.6 systems)
>
> sysfs GPIOs have also been deprecated for a while now, but from the mailing
> list and GitHub archives, my understanding is that everyone was waiting for
> libgpiod v2 to come out before migrating. (libgpiod v2 was released in August
> 2023).
>
> I think kernel 6.6 may force this issue to be addressed. Should we try to
> migrate to a new system (e.g libgpiod) or work out a more agnostic way to
> discover GPIOs (sysfs, DTB etc.)?
Some kind of libgpiod integration seems like the only option to me currently.
Regards,
Robert
>
> Best Regards,
> Matt
>
> [1]
> https://lore.kernel.org/lkml/cover.1662116601.git.christophe.le...@csgroup.eu/T/
>
> ___
> 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: Purpose of openwrt-devel?
On Wed, 13 Mar 2024 at 01:36, Elliott Mitchell wrote: > > Well, what purpose does the openwrt-devel mailing list serve? > > As near as I can tell it looks suspiciously like it is a method to divert > developers from where everything is done. There isn't too much review > activity. Anything which does get a positive review tends to simply > disappear unless it is later resubmitted via GitHub. > > According to https://openwrt.org/submitting-patches patch submission via > GitHub or the openwrt-devel mailing list can be done. The amount of text > seems to suggest the mailing list is preferred. Yet, can anyone cite a > single patch which was sent to the mailing list, reviewed positively and > brought into the main branch without resubmitting via GitHub? Hi Elliot, Both methods of submitting changes are accepted. However its is correct that most action happens via GH, that is the way that most users are more comfortable sending their changes and honestly for me its much easier to review and request changes and we have CI integrated as well. > > Then there is technical discussion. > > A rather serious problem with how kernel version changes are handled was > brought up. This eventually lead to: > https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html > Which seemed to gain a consensus of being the best solution to the > problem. > > Due to this not being the easiest process to implement, I went and > created a script for automating the process: > https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html > While some negotiation was expected, nothing has happened. I was > expecting to need some adjustment to match other's development > environments, yet no problems have been found. > > Yet now, 8a9273d51e simply throws the consensus in the garbage. Why was > something which there was consensus on ignored? Perhaps this mailing > list is now >99% ignored and people should no longer be directed here? It is not ignored, it was just a case where kernel 6.6 support was already done by the time we merged the kernel bump script that does the GIT magic to preserve the history and with multiple people working on 6.6 target support based of the same PR it was not practical to stall it any further. I expect further kernel bumps, both generic and target ones will use the script and preserve history but it will take some time to get everybody familiar with it. > > If action is taken quickly, the breakage in 8a9273d51e might be mostly > fixed. Check out 71360660e6, use the script to do an update and check > out the result. Then run `git merge --no-commit main` and then run > `git commit --amend`. I *think* this should generate the correct > result (squashing two merge commits together, creating a 3-way merge). > We cannot really change GIT history at this point I am afraid. Regards, Robert > Yet in the end, does this mailing list continue to serve any purpose > what-so-ever? Perhaps I should just give up and opt for Alpine instead. > > > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+sig...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
On Mon, 26 Feb 2024 at 17:28, Lorenzo Bianconi wrote: > > > On Mon, 26 Feb 2024 at 15:07, Lorenzo Bianconi wrote: > > > > > > > On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi > > > > wrote: > > > > > > > > > > Reduce and split pcie controller memory ranges for en7523 SoC > > > > > in order to properly load a pcie card on the second port. > > > > > > > > > > Signed-off-by: Lorenzo Bianconi > > > > > > > > Sorry for it taking so long, but merged. > > > > > > no worries :) > > > > > > > > > > > BTW, do you know is there anybody willing to maintain this target? > > > > > > since I am currently working on en7581 (even if I do not have too much > > > free > > > cycles) I can help maintaining it. > > > > That would be great as currently I have been doing kernel bumps > > without a board to test on as > > otherwise the target would be dropped. > > ack, fine. Am I supposed to do something in this case? It would be great if you can test the 6.1 kernel update for airoha, ideally in the future keep the target up to date with current kernels. Regards, Robert > > Regards, > Lorenzo > > > > > Regards, > > Robert > > > > > > Regards, > > > Lorenzo > > > > > > > > > > > Regards, > > > > Robert > > > > > --- > > > > > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/target/linux/airoha/dts/en7523.dtsi > > > > > b/target/linux/airoha/dts/en7523.dtsi > > > > > index 72478b225cbb..024a89752acb 100644 > > > > > --- a/target/linux/airoha/dts/en7523.dtsi > > > > > +++ b/target/linux/airoha/dts/en7523.dtsi > > > > > @@ -157,7 +157,7 @@ > > > > > clocks = < EN7523_CLK_PCIE>; > > > > > clock-names = "sys_ck0"; > > > > > bus-range = <0x00 0xff>; > > > > > - ranges = <0x8200 0 0x2000 0x2000 0 > > > > > 0x800>; > > > > > + ranges = <0x8200 0 0x2000 0x2000 0 > > > > > 0x200>; > > > > > status = "disabled"; > > > > > > > > > > #interrupt-cells = <1>; > > > > > @@ -186,7 +186,7 @@ > > > > > clocks = < EN7523_CLK_PCIE>; > > > > > clock-names = "sys_ck1"; > > > > > bus-range = <0x00 0xff>; > > > > > - ranges = <0x8200 0 0x2800 0x2800 0 > > > > > 0x800>; > > > > > + ranges = <0x8200 0 0x2200 0x2200 0 > > > > > 0x200>; > > > > > status = "disabled"; > > > > > > > > > > #interrupt-cells = <1>; > > > > > -- > > > > > 2.43.0 > > > > > > > > > > > > > > > ___ > > > > > openwrt-devel mailing list > > > > > openwrt-devel@lists.openwrt.org > > > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] mvebu: fill additional info for mvneta tx queue workaround patch
On Mon, 26 Feb 2024 at 17:27, Tomasz Maciej Nowak wrote: > > From: Tomasz Maciej Nowak > > Because some still unresolved bugs in this driver, which sprout > occasional questions what this patch works around, point to the issue > which started this. Being here, fill headers required by git am. > > Signed-off-by: Tomasz Maciej Nowak Thanks, Merged. Regards, Robert > --- > v1 -> v2 > - rebase > > .../mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch | 5 + > 1 file changed, 5 insertions(+) > > diff --git > a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > index 918132e2936c..14f93592fe3a 100644 > --- a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > +++ b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > @@ -1,3 +1,6 @@ > +From: Felix Fietkau > +Subject: mvneta: tx queue workaround > + > The hardware queue scheduling is apparently configured with fixed > priorities, which creates a nasty fairness issue where traffic from one > CPU can starve traffic from all other CPUs. > @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. > Work around this issue by forcing all tx packets to go through one CPU, > until this issue is fixed properly. > > +Ref: https://github.com/openwrt/openwrt/issues/5411 > + > Signed-off-by: Felix Fietkau > --- > --- a/drivers/net/ethernet/marvell/mvneta.c > -- > 2.44.0 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
On Mon, 26 Feb 2024 at 15:07, Lorenzo Bianconi wrote: > > > On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi wrote: > > > > > > Reduce and split pcie controller memory ranges for en7523 SoC > > > in order to properly load a pcie card on the second port. > > > > > > Signed-off-by: Lorenzo Bianconi > > > > Sorry for it taking so long, but merged. > > no worries :) > > > > > BTW, do you know is there anybody willing to maintain this target? > > since I am currently working on en7581 (even if I do not have too much free > cycles) I can help maintaining it. That would be great as currently I have been doing kernel bumps without a board to test on as otherwise the target would be dropped. Regards, Robert > > Regards, > Lorenzo > > > > > Regards, > > Robert > > > --- > > > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/target/linux/airoha/dts/en7523.dtsi > > > b/target/linux/airoha/dts/en7523.dtsi > > > index 72478b225cbb..024a89752acb 100644 > > > --- a/target/linux/airoha/dts/en7523.dtsi > > > +++ b/target/linux/airoha/dts/en7523.dtsi > > > @@ -157,7 +157,7 @@ > > > clocks = < EN7523_CLK_PCIE>; > > > clock-names = "sys_ck0"; > > > bus-range = <0x00 0xff>; > > > - ranges = <0x8200 0 0x2000 0x2000 0 > > > 0x800>; > > > + ranges = <0x8200 0 0x2000 0x2000 0 0x200>; > > > status = "disabled"; > > > > > > #interrupt-cells = <1>; > > > @@ -186,7 +186,7 @@ > > > clocks = < EN7523_CLK_PCIE>; > > > clock-names = "sys_ck1"; > > > bus-range = <0x00 0xff>; > > > - ranges = <0x8200 0 0x2800 0x2800 0 > > > 0x800>; > > > + ranges = <0x8200 0 0x2200 0x2200 0 0x200>; > > > status = "disabled"; > > > > > > #interrupt-cells = <1>; > > > -- > > > 2.43.0 > > > > > > > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mvebu: fill additional info for mvneta tx queue workaround patch
On Wed, 10 Jan 2024 at 17:45, Tomasz Maciej Nowak wrote: > > From: Tomasz Maciej Nowak > > Because some still unresolved bugs in this driver, which sprout > occasional questions what this patch works around, point to the issue > which started this. Being here, fill headers required by git am. > > Signed-off-by: Tomasz Maciej Nowak Hi, Thanks for doing this, but can you please rebase as 5.15 was dropped. Regards, Robert > --- > .../mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch | 5 + > .../mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch | 5 + > 2 files changed, 10 insertions(+) > > diff --git > a/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch > b/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch > index 32e8ef4b7d87..039dbc06dd04 100644 > --- a/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch > +++ b/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch > @@ -1,3 +1,6 @@ > +From: Felix Fietkau > +Subject: mvneta: tx queue workaround > + > The hardware queue scheduling is apparently configured with fixed > priorities, which creates a nasty fairness issue where traffic from one > CPU can starve traffic from all other CPUs. > @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. > Work around this issue by forcing all tx packets to go through one CPU, > until this issue is fixed properly. > > +Ref: https://github.com/openwrt/openwrt/issues/5411 > + > Signed-off-by: Felix Fietkau > --- > --- a/drivers/net/ethernet/marvell/mvneta.c > diff --git > a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > index 15762be81d40..f80d4e301ada 100644 > --- a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > +++ b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > @@ -1,3 +1,6 @@ > +From: Felix Fietkau > +Subject: mvneta: tx queue workaround > + > The hardware queue scheduling is apparently configured with fixed > priorities, which creates a nasty fairness issue where traffic from one > CPU can starve traffic from all other CPUs. > @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. > Work around this issue by forcing all tx packets to go through one CPU, > until this issue is fixed properly. > > +Ref: https://github.com/openwrt/openwrt/issues/5411 > + > Signed-off-by: Felix Fietkau > --- > --- a/drivers/net/ethernet/marvell/mvneta.c > -- > 2.43.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi wrote: > > Reduce and split pcie controller memory ranges for en7523 SoC > in order to properly load a pcie card on the second port. > > Signed-off-by: Lorenzo Bianconi Sorry for it taking so long, but merged. BTW, do you know is there anybody willing to maintain this target? Regards, Robert > --- > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/target/linux/airoha/dts/en7523.dtsi > b/target/linux/airoha/dts/en7523.dtsi > index 72478b225cbb..024a89752acb 100644 > --- a/target/linux/airoha/dts/en7523.dtsi > +++ b/target/linux/airoha/dts/en7523.dtsi > @@ -157,7 +157,7 @@ > clocks = < EN7523_CLK_PCIE>; > clock-names = "sys_ck0"; > bus-range = <0x00 0xff>; > - ranges = <0x8200 0 0x2000 0x2000 0 0x800>; > + ranges = <0x8200 0 0x2000 0x2000 0 0x200>; > status = "disabled"; > > #interrupt-cells = <1>; > @@ -186,7 +186,7 @@ > clocks = < EN7523_CLK_PCIE>; > clock-names = "sys_ck1"; > bus-range = <0x00 0xff>; > - ranges = <0x8200 0 0x2800 0x2800 0 0x800>; > + ranges = <0x8200 0 0x2200 0x2200 0 0x200>; > status = "disabled"; > > #interrupt-cells = <1>; > -- > 2.43.0 > > > ___ > 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: [VOTE] New member proposal: Robimarko (Robert Marko)
On Wed, 14 Feb 2024 at 22: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) > > Vote ended. > - 23/40 Participants. Quorum reached. > - 23 yes. > > https://openwrt.org/voting/2024-02-new-member-robimarko > > All welcomes Robert Marko as a new member of the OpenWrt Team. I would like to thank everybody who voted, glad to join the team. Regards, Robert > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: qca8327/qca8337 switch
On Mon, 12 Feb 2024 at 17:59, Christian Marangi (Ansuel) wrote: > > Il giorno lun 12 feb 2024 alle ore 17:58 e9hack ha scritto: > > > > Hi, > > > > it looks like that this commit > > > > 997acc7f86ca985cba52f7ea8b72f0661a1e3c52 > > generic: 6.1: backport at803x split patches > > > > breaks devices which using a qca8327/qca8337 switch, because the switch > > driver is not longer compiled in. I get the issue, now that QCA833X PHY driver has its own config symbol it means that all of the devices using QCA8X37 switches lack the drivers for the internal PHY, it should affect all targets basically. Regards, Robert > > > > Would be ideal to know what target are we talking about. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware
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
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
On Sat, 3 Feb 2024 at 13:06, Hauke Mehrtens wrote: > > 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. Hi Hauke, I would like to see 6.6 as soon as possible since 6.1 is getting quite old at this point and is requiring more and more backporting for any new work. We should also really push to move all of the targets onto 6.1. Regards, Robert > > Hauke > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
> > > > Along with a well designed minimalistic case with sufficient passive > > cooling and optional integrated antennas. Thinking something along the > > Flirc RPi4 cases, using the case itself as a cooler. With half the case > > radio transparent and a choice between antenna pigtails and integrated > > antennas. I realize that such a case will be relatively expensive. But > > without it all you have is yet another midrange dev board. This is your > > chance to make a device which shouts "OpenWrt!!!" whenever someone sees > > it. Just like the original WRT did. Not that that design was something > > to brag about beauty wise :-) > > I also think we should should have a pre-assembled-with-case-and-antennas > option in addition to just offering the plain board. I think this is crucial for any OpenWrt board, as that is where the biggest audience is. Regards, Robert > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Tue, 9 Jan 2024 at 17:53, Rafał Miłecki wrote: > > On 9.01.2024 13:29, John Crispin wrote: > > On 09.01.24 12:56, Robert Marko wrote: > >> ---SNIP--- > >> > >>> Why not 6GHz? > >> 6GHz requires an external card, and I doubt you can fit that in the > >> target price. > >> > >> Regards, > >> Robert > > > > correct. as mentioned in the email, we wanted to start out small. also > > upstream mac80211 is still missing a bunch of 11be related features. > > 6 GHz doesn't imply 802.11be, does it? I'm really not sure. > > Does MediaTek have any 802.11ax solutions that cover both: 5 GHz and > 6 GHz? Maybe it'd be worth checking if that's an option and then use > voting to see if people care? You can use 6GHz as part of 802.11ax as well, but you need an external card or you need to sacrifice the built-in 5GHz for 6GHz and that isn't really a good idea in my opinion. Regards, Robert > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: GPON project?
On Tue, 9 Jan 2024 at 14:59, Dave Taht wrote: > > Honestly, if progress is not made towards making GPON accessible in > FOSS, the next generation of fiber routers will be as locked down as > cablemodems are. While I do know of many ISPs using active ethernet > fiber instead, GPON is big in some places. Considering that GPON isn't a new thing and is rather widely deployed (At least in Europe) it would be awesome for FOSS products to exist but I have yet to see any progress made towards it despite the specification itself being public, but the drivers/blobs that actually interact with (mostly Realtek) GPON SoC-s are currently black boxes. I am unaware of any project working towards FOSS GPON or XGPON(Or any new 10G variants). Regards, Robert > > On Tue, Jan 9, 2024 at 7:39 AM Robert Marko wrote: > > > > On Tue, 9 Jan 2024 at 13:38, Dave Taht wrote: > > > > > > You should talk about this project at FOSSDEM! > > > > > > Two potential funders off the top of my head: > > > > > > https://nlnet.nl/funding.html > > > https://www.ardc.net/apply/ > > > Ardc funded the latest round of the librerouter project in argentina, > > > which is also openwrt based, but intended for outdoor. > > > > > > a 10 year design life would be nice. Gpon support instead of a 2.5Gbit > > > port? > > > > GPON support is non-existent in FOSS form basically. > > > > Regards, > > Robert > > > > > > The A53s are pretty weak. I would certainly like to see people squeeze > > > more performance out of these... > > > > > > I am more a software guy than hw, I would like to see "matter" begin > > > to matter. 802.14 anyone? Also: > > > https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554 > > > > > > Otherwise, I applaud. We could really use a reference router. I still > > > use (and love) my wndr3800s. Have not seen much reason to upgrade. > > > There´s still improvements to the ath9k feasible! > > > > > > On Tue, Jan 9, 2024 at 5:52 AM John Crispin wrote: > > > > > > > > tl;dr > > > > > > > > In 2024 the OpenWrt project turns 20 years! Let's celebrate this > > > > anniversary by launching our own first and fully upstream supported > > > > hardware design. > > > > > > > > If the community likes the idea outlined below in greater details, we > > > > would like to start a vote. > > > > > > > > --- > > > > > > > > The idea > > > > > > > > It is not new. We first spoke about this during the OpenWrt Summits in > > > > 2017 and also 2018. It became clear start of December 2023 while > > > > tinkering with Banana Pi style devices that they are already pretty > > > > close to what we wanted to achieve in ’17/‘18. Banana PIs have grown in > > > > popularity within the community. They boot using a self compiled Trusted > > > > Firmware-A (TF-A)and upstream U-Boot (thx MTK/Daniel) and some of the > > > > boards are already fully supported by the upstream Linux kernel. The > > > > only nonopen sourcecomponents are the 2.5 GbE PHYandWi-Fi firmware > > > > blobsrunning on separate cores that areindependent of the main SoC > > > > running Linuxand the DRAM calibration routines which are executed early > > > > during boot. > > > > > > > > I contacted three project members (pepe2k, dangole, nbd) on December 6th > > > > to outline the overall idea. We went over several design proposals, At > > > > the beginning we focused on the most powerful (and expensive) > > > > configurations possible but finally ended up with something rather > > > > simple and above all,feasible. We would like to propose the following as > > > > our "first" community driven HW platform called "OpenWrt One/AP-24.XY". > > > > > > > > Together with pepe2k (thx a lot) I discussed this for many hours and we > > > > worked out the following project proposal. Instead of going insane with > > > > specifications, we decided to include some nice features we believe all > > > > OpenWrt supported platforms should have (e.g. being almost > > > > unbrickablewith multiple recovery options, hassle-free system console > > > > access, on-board RTC with battery backup etc.). > > > > > > > > This is our first design, so let's KiSS! > > > > > > > > > > > > H
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Tue, 9 Jan 2024 at 13:38, Dave Taht wrote: > > You should talk about this project at FOSSDEM! > > Two potential funders off the top of my head: > > https://nlnet.nl/funding.html > https://www.ardc.net/apply/ > Ardc funded the latest round of the librerouter project in argentina, > which is also openwrt based, but intended for outdoor. > > a 10 year design life would be nice. Gpon support instead of a 2.5Gbit port? GPON support is non-existent in FOSS form basically. Regards, Robert > > The A53s are pretty weak. I would certainly like to see people squeeze > more performance out of these... > > I am more a software guy than hw, I would like to see "matter" begin > to matter. 802.14 anyone? Also: > https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554 > > Otherwise, I applaud. We could really use a reference router. I still > use (and love) my wndr3800s. Have not seen much reason to upgrade. > There´s still improvements to the ath9k feasible! > > On Tue, Jan 9, 2024 at 5:52 AM John Crispin wrote: > > > > tl;dr > > > > In 2024 the OpenWrt project turns 20 years! Let's celebrate this > > anniversary by launching our own first and fully upstream supported > > hardware design. > > > > If the community likes the idea outlined below in greater details, we > > would like to start a vote. > > > > --- > > > > The idea > > > > It is not new. We first spoke about this during the OpenWrt Summits in > > 2017 and also 2018. It became clear start of December 2023 while > > tinkering with Banana Pi style devices that they are already pretty > > close to what we wanted to achieve in ’17/‘18. Banana PIs have grown in > > popularity within the community. They boot using a self compiled Trusted > > Firmware-A (TF-A)and upstream U-Boot (thx MTK/Daniel) and some of the > > boards are already fully supported by the upstream Linux kernel. The > > only nonopen sourcecomponents are the 2.5 GbE PHYandWi-Fi firmware > > blobsrunning on separate cores that areindependent of the main SoC > > running Linuxand the DRAM calibration routines which are executed early > > during boot. > > > > I contacted three project members (pepe2k, dangole, nbd) on December 6th > > to outline the overall idea. We went over several design proposals, At > > the beginning we focused on the most powerful (and expensive) > > configurations possible but finally ended up with something rather > > simple and above all,feasible. We would like to propose the following as > > our "first" community driven HW platform called "OpenWrt One/AP-24.XY". > > > > Together with pepe2k (thx a lot) I discussed this for many hours and we > > worked out the following project proposal. Instead of going insane with > > specifications, we decided to include some nice features we believe all > > OpenWrt supported platforms should have (e.g. being almost > > unbrickablewith multiple recovery options, hassle-free system console > > access, on-board RTC with battery backup etc.). > > > > This is our first design, so let's KiSS! > > > > > > Hardwarespecifications: > > > > * SOC: MediaTek MT7981B > > * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz) > > * DRAM: 1 GiB DDR4 > > * Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR > > * Ethernet: 2x RJ45 (2.5 GbE + 1 GbE) > > * USB (host): USB 2.0 (Type-A port) > > * USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port) > > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) > > * Buttons: 2x (reset + user) > > * Mechanical switch: 1x for boot selection (recovery, regular) > > * LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven) > > * External hardware watchdog: EM Microelectronic EM6324 (GPIO driven) > > * RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220) > > * Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module) > > * Expansion slots: mikroBUS > > * Certification: FCC/EC/RoHS compliance > > * Case: PCB size is compatible to BPi-R4 and the case design can be re-used > > * JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD) > > * Antenna connectors: 3x MMCX for easy usage, assembly and durability > > * Schematics: these will be publicly available (license TBD) > > * GPL compliance: 3b. "Accompany it with a written offer ... to give any > > third party ... a complete machine-readable copy of the corresponding > > source code" > > * Price: aiming for below 100$ > > > > > > How will the device be distributed? > > > > OpenWrt itself cannot handle this for a ton of reasons. This is why we > > spoke with the SFC early. The idea is that BPi will distribute the > > device using the already established channels and for every device sold > > a donation will be made to ourSFC earmarked fund for OpenWrt. This money > > can then be used to cover hosting expenses or maybe an OpenWrt summit. > > > > SFC is committed to working with us in various ways on this project — > > including making sure OpenWrt'strademark is properly respected, that > > this router isabeautiful example of excellent
Re: OpenWrt One - celebrating 20 years of OpenWrt
---SNIP--- > Why not 6GHz? 6GHz requires an external card, and I doubt you can fit that in the target price. Regards, Robert > > BR > > > Janusz > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: enable thumb compile flag for 32bit architecture.
On Wed, 3 Jan 2024 at 10:20, Chuanhong Guo wrote: > > Hi! > > On Wed, Jan 3, 2024 at 10:14 AM wrote: > > > > From: shoudil > > > > Enable thumb flag to reduce package size, which help optimize the size > > of system image as well. > > > > Signed-off-by: shoudil > > --- > > include/hardening.mk | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/include/hardening.mk b/include/hardening.mk > > index 6acd862f5c..8c59643866 100644 > > --- a/include/hardening.mk > > +++ b/include/hardening.mk > > "hardening.mk", as the file name implies, is specifically for hardening > options. > > > @@ -9,6 +9,10 @@ PKG_SSP ?= 1 > > PKG_FORTIFY_SOURCE ?= 1 > > PKG_RELRO ?= 1 > > > > +ifeq ($(ARCH),arm) > > +TARGET_CFLAGS += -mthumb > > +endif > > + > > This isn't a hardening option, so it doesn't belong here. > This should probably be part of package.mk instead. Even then it should be a menuconfig option, not the default. Regards, Robert > -- > Regards, > Chuanhong Guo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Mon, 11 Dec 2023 at 06:55, Varadarajan Narayanan wrote: > > On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote: > > On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote: > > > > > > Hi Robert, > > > > > > Adding John's correct e-mail to the loop. > > > > > > On 8.12.2023 11:02, Robert Marko wrote: > > > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: > > > >> > > > >> Hi Robert, > > > >> > > > >> On 7.12.2023 12:52, Robert Marko wrote: > > > >> > > > > >> > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: > > > >> >> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: > > > >> >>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: > > > >> >>>>SoC : QCOM IPQ9574 > > > >> >>>>RAM : 2GB DDR4 > > > >> >>>>Flash : eMMC 8GB > > > >> >>>>WiFi: 1 x 2.4GHz > > > >> >>>> 1 x 5GHz > > > >> >>>> 1 x 6GHz > > > >> >>>> > > > >> >>>> Signed-off-by: Varadarajan Narayanan > > > >> >>> Without even looking at the code, please split this up as its > > > >> >>> not reviewable at all currently. > > > >> >>> > > > >> >>> Also, I would strongly encourage using Github PR for this. > > > >> >> This patch just has the base SoC/board support and not drivers for > > > >> >> WiFi/ethernet/USB etc. Can you kindly guide on what kind > > > >> >> of split is acceptable for the community. > > > >> >> > > > >> >> Thanks > > > >> >> Varada > > > >> > > > > >> > Hi, > > > >> > I would at least split the target itself, patches and then the board > > > >> > itself for the start. > > > >> > > > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx > > > >> just another subtarget of it (I'm aware of A53 vs. A73)? > > > > > > > > That depends on how much is shared between the AX SoC-s and the BE > > > > ones(IPQ95xx and IPQ53xx). > > > > > > I would say enough to keep them together. > > > > > > > But, I would prefer that or qualcommbe target where new BE SoC-s will > > > > be subtargets. > > > > > > I'm personally more a fan of limiting number of top targets and deal > > > with differences under subtargets. > > > > Same here, better than to add more targets especially since a lot is shared. > > Thanks for your inputs. > > Shall I rename target/linux/qualcommax/ -> target/linux/ipq/ (1st preference > since it is IPQ product family) or target/linux/qualcomm/ and have ipq95xx > as subtarget? I would prefer qualcomm and not ipq, and then ipq95xx as subtarget. Regards, Robert > > Kindly let me know. > > Thanks > Varada > > > > > Regards, > > Robert > > > > > > -- > > > Cheers, > > > Piotr > > > > > > > > > > > Regards, > > > > Robert > > > >> > > > >> -- > > > >> Cheers, > > > >> Piotr > > > >> > > > >> > > > > >> > Also, please sort the patches by prefix such as: > > > >> > 0xx are backports (Kernel version from which they are backported > > > >> > must be > > > >> > marked as well) > > > >> > 1xx are pending > > > >> > 9xx are usually hacks/stuff that currently cannot be upstreamed. > > > >> > > > > >> > Again, I would strongly encourage using Github PR for large changes > > > >> > such > > > >> > as these as its much > > > >> > easier to comment on certain changes and it has a lot larger reach > > > >> > than > > > >> > the OpenWrt mailing list > > > >> > as not all interested parties even follow this list. > > > >> > > > > >> > Regards, > > > >> > Robert > > > >> > > > > >> > > > > >> > ___ > > > >> > openwrt-devel mailing list > > > >> > openwrt-devel@lists.openwrt.org > > > >> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > >> > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Fri, 8 Dec 2023 at 16:39, Elliott Mitchell wrote: > > On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote: > > On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote: > > > > > > On 8.12.2023 11:02, Robert Marko wrote: > > > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: > > > >> > > > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx > > > >> just another subtarget of it (I'm aware of A53 vs. A73)? > > > > > > > > That depends on how much is shared between the AX SoC-s and the BE > > > > ones(IPQ95xx and IPQ53xx). > > > > > > I would say enough to keep them together. > > > > > > > But, I would prefer that or qualcommbe target where new BE SoC-s will > > > > be subtargets. > > > > > > I'm personally more a fan of limiting number of top targets and deal > > > with differences under subtargets. > > > > Same here, better than to add more targets especially since a lot is shared. > > This leads to needing more levels of organization. Instead of simply > TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET. If > this is going to be done, then the implementation should allow for an > arbitrary number of levels. Not really, there is no need for SUBSUBTARGET at all. When I say, they share stuff, I mean drivers are shared and thus target/subtarget model works just fine here. > > A makefile fragment I created for testing: > > foo := foo0 > SUBfoo := foo1 > SUBSUBfoo := foo2 > > define recur > $(info current is $(1), value is $($(1 > ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1))) > endef > > ignore := $(call recur,foo) > > all: test.make > @true > > So an arbitrary number of levels seems doable. Will mean rather > substantial changes to the build system though. I tend to favor this > as the 2 level limitation is already placing restrictions on the scaling > of the build count. > > > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+sig...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote: > > Hi Robert, > > Adding John's correct e-mail to the loop. > > On 8.12.2023 11:02, Robert Marko wrote: > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: > >> > >> Hi Robert, > >> > >> On 7.12.2023 12:52, Robert Marko wrote: > >> > > >> > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: > >> >> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: > >> >>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: > >> >>>>SoC : QCOM IPQ9574 > >> >>>>RAM : 2GB DDR4 > >> >>>>Flash : eMMC 8GB > >> >>>>WiFi: 1 x 2.4GHz > >> >>>> 1 x 5GHz > >> >>>> 1 x 6GHz > >> >>>> > >> >>>> Signed-off-by: Varadarajan Narayanan > >> >>> Without even looking at the code, please split this up as its > >> >>> not reviewable at all currently. > >> >>> > >> >>> Also, I would strongly encourage using Github PR for this. > >> >> This patch just has the base SoC/board support and not drivers for > >> >> WiFi/ethernet/USB etc. Can you kindly guide on what kind > >> >> of split is acceptable for the community. > >> >> > >> >> Thanks > >> >> Varada > >> > > >> > Hi, > >> > I would at least split the target itself, patches and then the board > >> > itself for the start. > >> > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx > >> just another subtarget of it (I'm aware of A53 vs. A73)? > > > > That depends on how much is shared between the AX SoC-s and the BE > > ones(IPQ95xx and IPQ53xx). > > I would say enough to keep them together. > > > But, I would prefer that or qualcommbe target where new BE SoC-s will > > be subtargets. > > I'm personally more a fan of limiting number of top targets and deal > with differences under subtargets. Same here, better than to add more targets especially since a lot is shared. Regards, Robert > > -- > Cheers, > Piotr > > > > > Regards, > > Robert > >> > >> -- > >> Cheers, > >> Piotr > >> > >> > > >> > Also, please sort the patches by prefix such as: > >> > 0xx are backports (Kernel version from which they are backported must be > >> > marked as well) > >> > 1xx are pending > >> > 9xx are usually hacks/stuff that currently cannot be upstreamed. > >> > > >> > Again, I would strongly encourage using Github PR for large changes such > >> > as these as its much > >> > easier to comment on certain changes and it has a lot larger reach than > >> > the OpenWrt mailing list > >> > as not all interested parties even follow this list. > >> > > >> > Regards, > >> > Robert > >> > > >> > > >> > ___ > >> > openwrt-devel mailing list > >> > openwrt-devel@lists.openwrt.org > >> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > >> > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: > > Hi Robert, > > On 7.12.2023 12:52, Robert Marko wrote: > > > > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: > >> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: > >>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: > >>>>SoC : QCOM IPQ9574 > >>>>RAM : 2GB DDR4 > >>>>Flash : eMMC 8GB > >>>>WiFi: 1 x 2.4GHz > >>>> 1 x 5GHz > >>>> 1 x 6GHz > >>>> > >>>> Signed-off-by: Varadarajan Narayanan > >>> Without even looking at the code, please split this up as its > >>> not reviewable at all currently. > >>> > >>> Also, I would strongly encourage using Github PR for this. > >> This patch just has the base SoC/board support and not drivers for > >> WiFi/ethernet/USB etc. Can you kindly guide on what kind > >> of split is acceptable for the community. > >> > >> Thanks > >> Varada > > > > Hi, > > I would at least split the target itself, patches and then the board > > itself for the start. > > Would it make sense to rename qualcommax to qualcomm and make ipq95xx > just another subtarget of it (I'm aware of A53 vs. A73)? That depends on how much is shared between the AX SoC-s and the BE ones(IPQ95xx and IPQ53xx). But, I would prefer that or qualcommbe target where new BE SoC-s will be subtargets. Regards, Robert > > -- > Cheers, > Piotr > > > > > Also, please sort the patches by prefix such as: > > 0xx are backports (Kernel version from which they are backported must be > > marked as well) > > 1xx are pending > > 9xx are usually hacks/stuff that currently cannot be upstreamed. > > > > Again, I would strongly encourage using Github PR for large changes such > > as these as its much > > easier to comment on certain changes and it has a lot larger reach than > > the OpenWrt mailing list > > as not all interested parties even follow this list. > > > > Regards, > > Robert > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: SoC : QCOM IPQ9574 RAM : 2GB DDR4 Flash : eMMC 8GB WiFi: 1 x 2.4GHz 1 x 5GHz 1 x 6GHz Signed-off-by: Varadarajan Narayanan Without even looking at the code, please split this up as its not reviewable at all currently. Also, I would strongly encourage using Github PR for this. This patch just has the base SoC/board support and not drivers for WiFi/ethernet/USB etc. Can you kindly guide on what kind of split is acceptable for the community. Thanks Varada Hi, I would at least split the target itself, patches and then the board itself for the start. Also, please sort the patches by prefix such as: 0xx are backports (Kernel version from which they are backported must be marked as well) 1xx are pending 9xx are usually hacks/stuff that currently cannot be upstreamed. Again, I would strongly encourage using Github PR for large changes such as these as its much easier to comment on certain changes and it has a lot larger reach than the OpenWrt mailing list as not all interested parties even follow this list. Regards, Robert ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for Aruba AP-303
On Thu, 16 Nov 2023 at 10:53, Luca Olivetti wrote: > > El 17/12/19 a les 12:52, David Bauer ha escrit: > > > 3. Configure the bootargs and bootcmd for OpenWrt. > > $ setenv bootargs_openwrt "setenv bootargs console=ttyMSM1,9600n8" > > $ setenv nandboot_openwrt "run bootargs_openwrt; ubi part aos1; > > ubi read 0x8500 kernel; bootm 0x8500" > > $ setenv ramboot_openwrt "run bootargs_openwrt; > > setenv ipaddr 192.168.1.105; setenv serverip 192.168.1.75; > > netget; set fdt_high 0x8700; bootm" > > $ setenv bootcmd "run nandboot_openwrt" > > $ saveenv > > > Hello, > > as explained here > > https://forum.openwrt.org/t/aruba-iap-11-apboot-downgrade-invalid-instant-small-business-image/120921 > > > it is no longer possible to install openwrt because they have removed > the bootm command from apboot. > > I asked here > https://forum.openwrt.org/t/apboot-dump-for-aruba-iap11-ap303-or-compatible-u-boot/177595/2 I have shared a dump from my AP11 that worked with OpenWrt. But please make sure they did not enable secure boot in the mean time. Regards, Robert > > for the old apboot image (it's possible to flash the spi from the new > apboot) but I'm wondering if it would be possible to compile a > compatible u-boot for this AP? > > > Bye > -- > Luca > > > ___ > 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: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)
On Mon, 13 Nov 2023 at 22:21, Thibaut wrote: > > > > > Le 13 nov. 2023 à 21:32, Petr Štetiar a écrit : > > > > Thibaut [2023-11-13 17:26:44]: > > > > Hi, > > > >> In any case, another way to tackle this problem would be to switch from > >> continuous builds that starve the build resources to periodic builds that > >> don’t (e.g. once a week), > > > > other options: > > > > * add more build workers :-) > > * use different GitPoller polling interval settings > > (master=5 minutes, 23.05=12 hours, 22.03=24 hours) > > GitPoller accepts a single poll interval. What you’re suggesting would > require separating each branch, i.e. returning to the previous situation. It > would also entirely defeat the purpose of prioritizing branches at the > Scheduler level. > > Also note that even with a 24h poll interval you could still starve the > master builds. > > Which is why I think either we accept the current situation as being « as > designed », or we switch to a periodic build schedule (which imho makes a lot > more sense considering that build resources aren’t infinitely expandable). > This would have the added benefit of ensuring *consistency* across targets, > i.e. ensuring that whichever commit is built is built on *all* targets. > Currently master will typically build and produce images for different > commits across targets when there is a lot of commit activity. Personally, time-based builds make more sense to me. Having all of targets built of the same commit would be nice. Regards, Robert > > Cheers > ___ > 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: Adding a new platform: renesas rz
On Tue, 31 Oct 2023 at 09:56, Michele Bisogno wrote: > > Hi Robert, > > thanks for the encouragement. > I'll go for plain "renesas" then. > > I am a bit hesitating on when / how to submit patches. > At the moment the image generated is for the sd card (similar to > Raspberry Pi) and for a single device (RZ/G2L) > However I am planning to support more boot memories (definitely QSPI > NOR) and more device from the same "family", i.e. very similar and > from OpenWRT point of view probably it's just a device tree change. > > Shall I focus on one device first and later on submit the rest? > I am still a newbie, I might discover that things should have been > done in a specific way only after the first review, that I know it > will be a disaster... :) To me, the most sense would be to provide one or 2 boards as part of the initial target but with multiple boot options supported so later boards can be easily added. Personally, GH PR-s are rather good for adding new stuff as it makes commenting on things much easier and cleaner, and we can let CI do its thing as well. Regards, Robert > > Regards, > Michele > > On Mon, 30 Oct 2023 at 21:40, Robert Marko wrote: > > > > On Mon, 30 Oct 2023 at 10:40, Michele Bisogno > > wrote: > > > > > > Hi, > > > > > > I've been a happy OpenWRT user for many years now, always buying > > > routers that could allow me to run it easily. > > > > Hi, nice to hear this. > > > > > > > > I've been working (actually only in my free time as a hobby) on > > > porting OpenWRT onto this Renesas board: > > > https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz-mpus/rzg2l-evkit-rzg2l-evaluation-board-kit > > > which features this Arm Cortex-A55 based device: > > > https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz-mpus/rzg2l-general-purpose-microprocessors-dual-core-arm-cortex-a55-12-ghz-cpus-and-single-core-arm-cortex-m33 > > > > > > I guess this is a new platform, since it does not really fit in any of > > > the already supported ones. > > > > > > I got it working and I am polishing the patch before submitting it. > > > The support of this device is already mainlined in the Linux kernel, > > > so I am using 6.1 as is with the appropriate config. > > > Arm Trusted Firmware and u-boot are instead taken from the respective > > > Renesas forks, available on github. > > > > Great, these Reneas SoC-s are rather well supported in respective > > upstream projects. > > > > > > > > However this is the first time I do that, and I am still reading and > > > learning, so I would like to get opinions, hints, why not constructive > > > criticism and hopefully encouragement. > > > > I definitively encourage people to contribute towards more HW support, > > especially HW which is mostly upstream. > > > > > > > > For example, naming (renesas? renesas-rz? rz?) and structure of the > > > subfolders. There are other variants I would like to add: RZ/G2LC, > > > RZ/G2UL and maybe others. > > > > To me, just "renesas" sounds good and then you can introduce the individual > > SoC families as subtargets. > > > > Regards, > > Robert > > > > > > System > > > > > > HostnameOpenWrt > > > ModelRenesas SMARC EVK based on r9a07g044l2 > > > ArchitectureARMv8 Processor rev 0 > > > Target Platformrz/g2l > > > Firmware VersionOpenWrt SNAPSHOT r24187-bb8fd41f9a / LuCI Master > > > git-23.294.26440-30a8a0d > > > Kernel Version6.1.59 > > > Local Time2023-10-29 07:44:17 > > > Uptime0h 9m 11s > > > Load Average0.13, 0.08, 0.05 > > > > > > ___ > > > 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: Adding a new platform: renesas rz
On Mon, 30 Oct 2023 at 10:40, Michele Bisogno wrote: > > Hi, > > I've been a happy OpenWRT user for many years now, always buying > routers that could allow me to run it easily. Hi, nice to hear this. > > I've been working (actually only in my free time as a hobby) on > porting OpenWRT onto this Renesas board: > https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz-mpus/rzg2l-evkit-rzg2l-evaluation-board-kit > which features this Arm Cortex-A55 based device: > https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz-mpus/rzg2l-general-purpose-microprocessors-dual-core-arm-cortex-a55-12-ghz-cpus-and-single-core-arm-cortex-m33 > > I guess this is a new platform, since it does not really fit in any of > the already supported ones. > > I got it working and I am polishing the patch before submitting it. > The support of this device is already mainlined in the Linux kernel, > so I am using 6.1 as is with the appropriate config. > Arm Trusted Firmware and u-boot are instead taken from the respective > Renesas forks, available on github. Great, these Reneas SoC-s are rather well supported in respective upstream projects. > > However this is the first time I do that, and I am still reading and > learning, so I would like to get opinions, hints, why not constructive > criticism and hopefully encouragement. I definitively encourage people to contribute towards more HW support, especially HW which is mostly upstream. > > For example, naming (renesas? renesas-rz? rz?) and structure of the > subfolders. There are other variants I would like to add: RZ/G2LC, > RZ/G2UL and maybe others. To me, just "renesas" sounds good and then you can introduce the individual SoC families as subtargets. Regards, Robert > > System > > HostnameOpenWrt > ModelRenesas SMARC EVK based on r9a07g044l2 > ArchitectureARMv8 Processor rev 0 > Target Platformrz/g2l > Firmware VersionOpenWrt SNAPSHOT r24187-bb8fd41f9a / LuCI Master > git-23.294.26440-30a8a0d > Kernel Version6.1.59 > Local Time2023-10-29 07:44:17 > Uptime0h 9m 11s > Load Average0.13, 0.08, 0.05 > > ___ > 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: CI/CD failures on non-x86 platforms
On Tue, 24 Oct 2023 at 17:46, Philip Prindeville wrote: > > Hi, > > I'm seeing the following: > > https://github.com/openwrt/packages/actions/runs/6621741418/job/17986176198?pr=22362 > > Specifically: > > mips-openwrt-linux-musl-gcc -shared -o libcligen.so.6.4 cligen_object.o > cligen_callback.o cligen_parsetree.o cligen_pt_head.o cligen_handle.o > cligen_cv.o cligen_match.o cligen_result.o cligen_read.o cligen_io.o > cligen_expand.o cligen_syntax.o cligen_print.o cligen_cvec.o cligen_buf.o > cligen_util.o cligen_history.o cligen_regex.o cligen_getline.o build.o > lex.cligen_parse.o cligen_parse.tab.o > -L/builder/staging_dir/toolchain-mips_24kc_gcc-12.3.0_musl/usr/lib > -L/builder/staging_dir/toolchain-mips_24kc_gcc-12.3.0_musl/lib -fuse-ld=bfd > -znow -zrelro -Wl,-soname=libcligen.so.6.4 -L. > /builder/staging_dir/host/bin/install -c -m 0755 -d > /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib > /builder/staging_dir/host/bin/install -c -m 0644 -s libcligen.so.6.4 > /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib > strip: Unable to recognise the format of the input file > `/builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib/libcligen.so.6.4' > /builder/staging_dir/host/bin/install: strip process terminated abnormally > make[3]: Leaving directory > '/builder/build_dir/target-mips_24kc_musl/cligen-6.4.0' > make[3]: *** [Makefile:157: install-lib] Error 1 > make[2]: *** [Makefile:60: > /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/.built] Error 2 > > > It looks like it's running on an x86_64 but the version of "install" doesn't > understand MIPS binaries. Is that what's happening? And why is it only > affecting me? It's the strip tool that is complaining. Can you try making it run file before on it to see what the library .so actually is? Regards, Robert > > There's nothing particular about my packaging: > > https://github.com/pprindeville/packages/blob/clixon-initial/utils/clixon/Makefile > > What am I missing? > > Thanks, > > -Philip > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 05/10] kernel: netdevices: Package AMD PHY
On Thu, 12 Oct 2023 at 10:43, Linus Walleij wrote: > > This adds a package for the AMD and Altima PHY, found in some > odd devices. > > Signed-off-by: Linus Walleij > --- LGTM, Reviewed-by: Robert Marko > package/kernel/linux/modules/netdevices.mk | 16 > 1 file changed, 16 insertions(+) > > diff --git a/package/kernel/linux/modules/netdevices.mk > b/package/kernel/linux/modules/netdevices.mk > index b0d69e022069..392bc176f491 100644 > --- a/package/kernel/linux/modules/netdevices.mk > +++ b/package/kernel/linux/modules/netdevices.mk > @@ -224,6 +224,22 @@ endef > $(eval $(call KernelPackage,phylib-broadcom)) > > > +define KernelPackage/phy-amd > + SUBMENU:=$(NETWORK_DEVICES_MENU) > + TITLE:=AMD PHY driver > + KCONFIG:=CONFIG_AMD_PHY > + DEPENDS:=+kmod-libphy > + FILES:=$(LINUX_DIR)/drivers/net/phy/amd.ko > + AUTOLOAD:=$(call AutoProbe,amd) > +endef > + > +define KernelPackage/phy-amd/description > + Currently supports the AMD and Altima PHYs. > +endef > + > +$(eval $(call KernelPackage,phy-amd)) > + > + > define KernelPackage/phy-ax88796b > SUBMENU:=$(NETWORK_DEVICES_MENU) > TITLE:=Asix PHY driver > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 03/10] kernel: Add kmod-rtc-x1205
On Thu, 12 Oct 2023 at 10:43, Linus Walleij wrote: > > To support the IXP42x platforms we need a kernel module > for the X1205 RTC so we can load it as an optional module. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v3: > - Use autoprobe, exclude from preinit. LGTM, Reviewed-by: Robert Marko > --- > package/kernel/linux/modules/other.mk | 16 > 1 file changed, 16 insertions(+) > > diff --git a/package/kernel/linux/modules/other.mk > b/package/kernel/linux/modules/other.mk > index ac26c2a15037..2cd01d84d516 100644 > --- a/package/kernel/linux/modules/other.mk > +++ b/package/kernel/linux/modules/other.mk > @@ -780,6 +780,22 @@ endef > > $(eval $(call KernelPackage,rtc-s35390a)) > > +define KernelPackage/rtc-x1205 > + SUBMENU:=$(OTHER_MENU) > + TITLE:=Xicor Intersil X1205 > + DEFAULT:=m if ALL_KMODS && RTC_SUPPORT > + DEPENDS:=+kmod-i2c-core > + KCONFIG:=CONFIG_RTC_DRV_X1205 \ > + CONFIG_RTC_CLASS=y > + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-x1205.ko > + AUTOLOAD:=$(call AutoProbe,rtc-x1205) > +endef > + > +define KernelPackage/rtc-x1205/description > + Kernel module for Xicor Intersil X1205 I2C RTC chip > +endef > + > +$(eval $(call KernelPackage,rtc-x1205)) > > define KernelPackage/mtdtests >SUBMENU:=$(OTHER_MENU) > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 04/10] kernel: Add kmod-rtc-r7301
On Thu, 12 Oct 2023 at 10:43, Linus Walleij wrote: > > To support the IXP42x platforms we need a kernel module > for the Epson R7301 RTC so we can load it as an optional > module. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v3: > - Use AutoProbe, drop preinit hook. LGTM, Reviewed-by: Robert Marko > --- > package/kernel/linux/modules/other.mk | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/package/kernel/linux/modules/other.mk > b/package/kernel/linux/modules/other.mk > index 2cd01d84d516..feee39602db9 100644 > --- a/package/kernel/linux/modules/other.mk > +++ b/package/kernel/linux/modules/other.mk > @@ -728,6 +728,21 @@ endef > > $(eval $(call KernelPackage,rtc-pcf2127)) > > +define KernelPackage/rtc-r7301 > + SUBMENU:=$(OTHER_MENU) > + TITLE:=Epson RTC7301 support > + DEFAULT:=m if ALL_KMODS && RTC_SUPPORT > + KCONFIG:=CONFIG_RTC_DRV_R7301 \ > + CONFIG_RTC_CLASS=y > + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-r7301.ko > + AUTOLOAD:=$(call AutoProbe,rtc-r7301) > +endef > + > +define KernelPackage/rtc-r7301/description > + Kernel module for Epson RTC7301 RTC chip > +endef > + > +$(eval $(call KernelPackage,rtc-r7301)) > > define KernelPackage/rtc-rs5c372a >SUBMENU:=$(OTHER_MENU) > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/9] ixp4xx: Add a ixp4xx hardware crypto kernel module
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > The IXP4xx crypto module must be loaded after the rootfs is > up as it depends on loading some NPE microcode from the file > system. > > Signed-off-by: Linus Walleij > --- > package/kernel/linux/modules/crypto.mk | 13 + > target/linux/ixp4xx/Makefile | 1 + > 2 files changed, 14 insertions(+) > > diff --git a/package/kernel/linux/modules/crypto.mk > b/package/kernel/linux/modules/crypto.mk > index 501be4b0a02c..bfb70f0344fb 100644 > --- a/package/kernel/linux/modules/crypto.mk > +++ b/package/kernel/linux/modules/crypto.mk > @@ -399,6 +399,19 @@ endef > > $(eval $(call KernelPackage,crypto-hw-hifn-795x)) > > +define KernelPackage/crypto-hw-ixp4xx > + TITLE:=Intel IXP4xx crypto accelerator > + DEPENDS:=@TARGET_ixp4xx +kmod-random-core +kmod-crypto-manager > +kmod-crypto-authenc +kmod-crypto-des > + KCONFIG:= \ > + CONFIG_CRYPTO_HW=y \ > + CONFIG_CRYPTO_DEV_IXP4XX > + FILES:=$(LINUX_DIR)/drivers/crypto/ixp4xx_crypto.ko > + AUTOLOAD:=$(call AutoLoad,09,ixp4xx_crypto) AutoProbe should work here since its now DT-based and can be probed against the compatible instead of manually loading it. Regards Robert > + $(call AddDepends/crypto) > +endef > + > +$(eval $(call KernelPackage,crypto-hw-ixp4xx)) > + > > define KernelPackage/crypto-hw-padlock >TITLE:=VIA PadLock ACE with AES/SHA hw crypto module > diff --git a/target/linux/ixp4xx/Makefile b/target/linux/ixp4xx/Makefile > index 89a1b2407bfe..6cd30877 100644 > --- a/target/linux/ixp4xx/Makefile > +++ b/target/linux/ixp4xx/Makefile > @@ -21,6 +21,7 @@ KERNELNAME:=zImage dtbs > include $(INCLUDE_DIR)/target.mk > > DEFAULT_PACKAGES += fconfig \ > + kmod-crypto-hw-ixp4xx \ > kmod-usb-ledtrig-usbport \ > kmod-leds-gpio > > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/9] boot/apex: Restore the APEX boot loader
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > This is a partial revert of the deletion of the IXP4xx > target: we restore the APEX boot loader so we can use it > for the NSLU2 and related targets. > > The APEX upstream is as dead as it gets so I have applied > OpenWrts old patches on top of the never released > v1.6.10 version and forked it into an OpenWrt variant > on GitHub. If the upstream comes back alive I will > happily switch over to it. > > The file refers to the external GitHub, I suppose when > integrating this patch the file should be copied to OpenWrts > file repository and the file link changed. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Do not default to "y", instead make the device target > select apex by default. > - Do not package the boot loader into the rootfs image. > Who wants that. > --- > package/boot/apex/Makefile | 55 > ++ > 1 file changed, 55 insertions(+) > > diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile > new file mode 100644 > index ..817e15d8e643 > --- /dev/null > +++ b/package/boot/apex/Makefile > @@ -0,0 +1,55 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# Copyright (C) 2006-2023 OpenWrt.org > + > +include $(TOPDIR)/rules.mk > +include $(INCLUDE_DIR)/kernel.mk > + > +PKG_NAME:=apex > +# This version was created from the stalled and unreleased v1.6.10 > +# with some patches on top. > +PKG_VERSION:=1.6.10-openwrt > +PKG_RELEASE:=1 > + > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz > +PKG_SOURCE_URL:=https://github.com/linusw/apex/releases/download/v1.6.10-openwrt/ > +PKG_HASH:=034baa99574014f4bcb8d36baf830fa942bef816b22e228eabd7c5663612c640 > +PKG_TARGETS:=bin > + > +include $(INCLUDE_DIR)/package.mk > + > +export GCC_HONOUR_COPTS=s > + > +define Package/apex > + SECTION:=boot > + CATEGORY:=Boot Loaders > + DEPENDS:=@TARGET_ixp4xx This will probably break the package if one tries to bisect as there is no ixp4xx target yet. Regards, Robert > + TITLE:=Boot loader for NSLU2, FSG3, NAS100D and others > +endef > + > +define build_apex > + $(MAKE) -C $(PKG_BUILD_DIR) \ > + ARCH=arm \ > + $(1)_config > + $(MAKE) -C $(PKG_BUILD_DIR) \ > + $(TARGET_CONFIGURE_OPTS) \ > + KBUILD_HAVE_NLS=no \ > + ARCH=arm \ > + clean all > + $(INSTALL_BIN) $(PKG_BUILD_DIR)/apex.bin > $(PKG_BUILD_DIR)/out/apex-$(2).bin > +endef > + > +define Build/Compile > + $(INSTALL_DIR) $(PKG_BUILD_DIR)/out > + $(call build_apex,openwrt-nslu2-armeb,nslu2-armeb) > + $(call build_apex,openwrt-nslu2-16mb-armeb,nslu2-16mb-armeb) > + $(call build_apex,openwrt-fsg3-armeb,fsg3-armeb) > + $(call build_apex,openwrt-nas100d-armeb,nas100d-armeb) > +endef > + > +define Package/apex/install > + $(INSTALL_DIR) $(STAGING_DIR)/apex > + $(CP) $(PKG_BUILD_DIR)/out/*.bin $(1)/ > +endef > + > +$(eval $(call BuildPackage,apex)) > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 3/9] kernel: Add kmod-rtc-r7301
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > To support the IXP42x platforms we need a kernel module > for the Epson R7301 RTC so we can load it as an optional > module. > > Signed-off-by: Linus Walleij > --- > package/kernel/linux/modules/other.mk | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/package/kernel/linux/modules/other.mk > b/package/kernel/linux/modules/other.mk > index 187c0c56f0bb..8e7da1ca2c6f 100644 > --- a/package/kernel/linux/modules/other.mk > +++ b/package/kernel/linux/modules/other.mk > @@ -728,6 +728,21 @@ endef > > $(eval $(call KernelPackage,rtc-pcf2127)) > > +define KernelPackage/rtc-r7301 > + SUBMENU:=$(OTHER_MENU) > + TITLE:=Epson RTC7301 support > + DEFAULT:=m if ALL_KMODS && RTC_SUPPORT > + KCONFIG:=CONFIG_RTC_DRV_R7301 \ > + CONFIG_RTC_CLASS=y > + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-r7301.ko > + AUTOLOAD:=$(call AutoLoad,50,rtc-r7301,1) Same question as for the other RTC kmod: Any reason why this cannot be probed instead, also why does it have to be included in preinit as well? Regards, Robert > +endef > + > +define KernelPackage/rtc-r7301/description > + Kernel module for Epson RTC7301 RTC chip > +endef > + > +$(eval $(call KernelPackage,rtc-r7301)) > > define KernelPackage/rtc-rs5c372a >SUBMENU:=$(OTHER_MENU) > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/9] kernel: Add kmod-rtc-x1205
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > To support the IXP42x platforms we need a kernel module > for the X1205 RTC so we can load it as an optional module. > > Signed-off-by: Linus Walleij > --- > package/kernel/linux/modules/other.mk | 16 > 1 file changed, 16 insertions(+) > > diff --git a/package/kernel/linux/modules/other.mk > b/package/kernel/linux/modules/other.mk > index ac26c2a15037..187c0c56f0bb 100644 > --- a/package/kernel/linux/modules/other.mk > +++ b/package/kernel/linux/modules/other.mk > @@ -780,6 +780,22 @@ endef > > $(eval $(call KernelPackage,rtc-s35390a)) > > +define KernelPackage/rtc-x1205 > + SUBMENU:=$(OTHER_MENU) > + TITLE:=Xicor Intersil X1205 > + DEFAULT:=m if ALL_KMODS && RTC_SUPPORT > + DEPENDS:=+kmod-i2c-core > + KCONFIG:=CONFIG_RTC_DRV_X1205 \ > + CONFIG_RTC_CLASS=y > + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-x1205.ko > + AUTOLOAD:=$(call AutoLoad,50,rtc-x1205,1) Any reason why this cannot be probed instead, also why does it have to be included in preinit as well? Regards, Robert > +endef > + > +define KernelPackage/rtc-x1205/description > + Kernel module for Xicor Intersil X1205 I2C RTC chip > +endef > + > +$(eval $(call KernelPackage,rtc-x1205)) > > define KernelPackage/mtdtests >SUBMENU:=$(OTHER_MENU) > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 4/9] kernel: netdevices: Package AMD PHY
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > This adds a package for the AMD and Altima PHY, found in some > odd devices. > > Signed-off-by: Linus Walleij > --- > package/kernel/linux/modules/netdevices.mk | 16 > 1 file changed, 16 insertions(+) > > diff --git a/package/kernel/linux/modules/netdevices.mk > b/package/kernel/linux/modules/netdevices.mk > index b0d69e022069..392bc176f491 100644 > --- a/package/kernel/linux/modules/netdevices.mk > +++ b/package/kernel/linux/modules/netdevices.mk > @@ -224,6 +224,22 @@ endef > $(eval $(call KernelPackage,phylib-broadcom)) > > > +define KernelPackage/phy-amd > + SUBMENU:=$(NETWORK_DEVICES_MENU) > + TITLE:=AMD PHY driver > + KCONFIG:=CONFIG_AMD_PHY > + DEPENDS:=+kmod-libphy > + FILES:=$(LINUX_DIR)/drivers/net/phy/amd.ko > + AUTOLOAD:=$(call AutoProbe,and) Is this PHY used on the only networking interface on any board? Cause if so, then it would make sense to include it in preinit so that failsafe will also work. Regards, Robert > +endef > + > +define KernelPackage/phy-amd/description > + Currently supports the AMD and Altima PHYs. > +endef > + > +$(eval $(call KernelPackage,phy-amd)) > + > + > define KernelPackage/phy-ax88796b > SUBMENU:=$(NETWORK_DEVICES_MENU) > TITLE:=Asix PHY driver > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] mvebu: cortexa72: enable USB PHY
On Thu, 7 Sept 2023 at 17:16, Tomasz Maciej Nowak wrote: > > From: Tomasz Maciej Nowak > > Since kernel 5.13 this is needed to enable USB ports on all devices in > subtarget. Previously TF-A and COMPHY driver might have set up this PHY, > but not anymore. > > Signed-off-by: Tomasz Maciej Nowak I tested this on MOchabin and it seems to be working after I actually enable the UTMI PHY-s, hence why USB was working fine on MOchabin without this driver. And yeah, this should be backported to anything using 5.15 or newer as Machiatobin has broken USB for sure. Tested-by: Robert Marko > --- > Please backport config-5.15 changes to 23.05 and 22.03 branches. > > target/linux/mvebu/cortexa72/config-5.15 | 1 + > target/linux/mvebu/cortexa72/config-6.1 | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/target/linux/mvebu/cortexa72/config-5.15 > b/target/linux/mvebu/cortexa72/config-5.15 > index cb27e0285faa..978208f1cb5a 100644 > --- a/target/linux/mvebu/cortexa72/config-5.15 > +++ b/target/linux/mvebu/cortexa72/config-5.15 > @@ -72,6 +72,7 @@ CONFIG_PCIE_DW_HOST=y > CONFIG_PGTABLE_LEVELS=3 > CONFIG_PHYS_ADDR_T_64BIT=y > CONFIG_PHY_MVEBU_CP110_COMPHY=y > +CONFIG_PHY_MVEBU_CP110_UTMI=y > CONFIG_PINCTRL_ARMADA_37XX=y > CONFIG_PINCTRL_ARMADA_AP806=y > CONFIG_PINCTRL_ARMADA_CP110=y > diff --git a/target/linux/mvebu/cortexa72/config-6.1 > b/target/linux/mvebu/cortexa72/config-6.1 > index 5a3dcc66f720..535b67225e70 100644 > --- a/target/linux/mvebu/cortexa72/config-6.1 > +++ b/target/linux/mvebu/cortexa72/config-6.1 > @@ -76,6 +76,7 @@ CONFIG_PCIE_DW_HOST=y > CONFIG_PGTABLE_LEVELS=3 > CONFIG_PHYS_ADDR_T_64BIT=y > CONFIG_PHY_MVEBU_CP110_COMPHY=y > +CONFIG_PHY_MVEBU_CP110_UTMI=y > CONFIG_PINCTRL_AC5=y > CONFIG_PINCTRL_ARMADA_37XX=y > CONFIG_PINCTRL_ARMADA_AP806=y > -- > 2.42.0 > > > ___ > 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: Meta packages for wireless
On Thu, 7 Sept 2023 at 23:27, Nicholas Smith wrote: > > Yeah the quectel hack job is not fun, have to load their driver too. I was > forced to because I couldn’t get good speeds on a RM500q nor do bridge mode > without it. Has that changed in recent versions of MM and qmi_wwan? Would > really love to retire that hack I just got the ModemManager and everything else backport to 19.07, all I did test so far was mmcli and some basic functions. I am using their driver for MHI as QCA-s 5.4 kernel MHI WWAN support is non-existent, but still need to test that path as I was just using qmi_wwan as I would really love to avoid their abomination with the qmi_wwan_q mess Quectel has. Regards, Robert > > > All the best, > Nicholas Smith > > > On Thu, 7 Sep 2023 at 23:55, Robert Marko wrote: >> >> On Wed, 6 Sept 2023 at 23:10, Nicholas Smith wrote: >> > >> > Hey, >> > >> > The idea of modemmanager is that it’s an abstract generic manager for any >> > modem that uses MBIM, QMI or sometimes AT commands. It’s like >> > networkmanager in that sense; you don’t care what brand your NIC is or >> > whether it’s wireless, networkmanager just works. >> > >> > Only issue up until recently has been notifying hotplug and netifd of >> > events that MM is aware of, as well as the size (about 2MB for a full >> > installation). But there has been some good work by Florian E recently >> > around that, and you get the lite option by default so size is kept to a >> > minimum. >> >> Hi, >> This is basically why I want to use modemmanager, size is not an issue >> so I spent some time backporting it as well as libqmi, libmbim and >> libqrtr-glib to 19.07. >> Fingers crossed it actually works so I dont have to use the Quectel hackjob. >> >> Regards, >> Robert >> > >> > All the best, >> > Nicholas Smith >> > >> > >> > On Thu, 7 Sep 2023 at 04:53, Robert Marko wrote: >> >> >> >> On Wed, 6 Sept 2023 at 20:22, Philip Prindeville >> >> wrote: >> >> > >> >> > Hi all, >> >> > >> >> > I was reading through some of the online documentations as I try to >> >> > bring up a 5G modem w/ Verizon and modemmanager, and bounced between >> >> > various settings (it's a Quectel EM120R-GL modem for the moment until >> >> > something better arrives), trying to decide if I wanted to use QMI or >> >> > MBIM, if I should use the "qui" protocol directly or "modemmanager" >> >> > instead... And thought it would be nice to have 2 or 3 groups of meta >> >> > packages that you select and the rest gets taken care of for you by >> >> > dependencies. >> >> > >> >> > In particular: >> >> > >> >> > https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle >> >> > >> >> > Talks about kmod's and user-space tools necessary for QMI, different >> >> > packages necessary for MBIM, and then what's needed for NCM (anyone >> >> > still using that or 3G)... >> >> > >> >> > General debugging tools like minicom so you don't need to use "echo" or >> >> > "socat"... >> >> > >> >> > Before I start on the effort (shouldn't take more than a couple of >> >> > hours), does anyone object to the project (or conversely, is anyone >> >> > willing to review and sign-off on it)? >> >> >> >> I would find this rather useful, to have meta-packages for modems >> >> instead of having to select everything manually. >> >> I am working on RM520N-GL support at work (For QSDK, dont ask why) and >> >> I am not sure whether I want to use the mess called Quectel CM(Vendor >> >> tool) or modemmanager. >> >> >> >> Regards, >> >> Robert >> >> > >> >> > Eckert: thanks for the quick turnaround on the MBIM-disabled issue when >> >> > building modemmanager... >> >> > >> >> > If anyone is wondering, no, I still don't have wireless up... not sure >> >> > if that hardware is in a weird persistent state (a lot of settings get >> >> > saved to NVRAM) or if modemmanager doesn't handle certain corner cases >> >> > (although Verizon on a Quectel EM120R-GL using QMI would seem to be >> >> > pretty mainstream). Please reach out to me if you have any >> >> > troubleshooting suggestions, and I'll update the docs appropriately >> >> > when I'm done. >> >> > >> >> > Thanks, >> >> > >> >> > -Philip >> >> > >> >> > >> >> > ___ >> >> > 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Meta packages for wireless
On Wed, 6 Sept 2023 at 23:10, Nicholas Smith wrote: > > Hey, > > The idea of modemmanager is that it’s an abstract generic manager for any > modem that uses MBIM, QMI or sometimes AT commands. It’s like networkmanager > in that sense; you don’t care what brand your NIC is or whether it’s > wireless, networkmanager just works. > > Only issue up until recently has been notifying hotplug and netifd of events > that MM is aware of, as well as the size (about 2MB for a full installation). > But there has been some good work by Florian E recently around that, and you > get the lite option by default so size is kept to a minimum. Hi, This is basically why I want to use modemmanager, size is not an issue so I spent some time backporting it as well as libqmi, libmbim and libqrtr-glib to 19.07. Fingers crossed it actually works so I dont have to use the Quectel hackjob. Regards, Robert > > All the best, > Nicholas Smith > > > On Thu, 7 Sep 2023 at 04:53, Robert Marko wrote: >> >> On Wed, 6 Sept 2023 at 20:22, Philip Prindeville >> wrote: >> > >> > Hi all, >> > >> > I was reading through some of the online documentations as I try to bring >> > up a 5G modem w/ Verizon and modemmanager, and bounced between various >> > settings (it's a Quectel EM120R-GL modem for the moment until something >> > better arrives), trying to decide if I wanted to use QMI or MBIM, if I >> > should use the "qui" protocol directly or "modemmanager" instead... And >> > thought it would be nice to have 2 or 3 groups of meta packages that you >> > select and the rest gets taken care of for you by dependencies. >> > >> > In particular: >> > >> > https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle >> > >> > Talks about kmod's and user-space tools necessary for QMI, different >> > packages necessary for MBIM, and then what's needed for NCM (anyone still >> > using that or 3G)... >> > >> > General debugging tools like minicom so you don't need to use "echo" or >> > "socat"... >> > >> > Before I start on the effort (shouldn't take more than a couple of hours), >> > does anyone object to the project (or conversely, is anyone willing to >> > review and sign-off on it)? >> >> I would find this rather useful, to have meta-packages for modems >> instead of having to select everything manually. >> I am working on RM520N-GL support at work (For QSDK, dont ask why) and >> I am not sure whether I want to use the mess called Quectel CM(Vendor >> tool) or modemmanager. >> >> Regards, >> Robert >> > >> > Eckert: thanks for the quick turnaround on the MBIM-disabled issue when >> > building modemmanager... >> > >> > If anyone is wondering, no, I still don't have wireless up... not sure if >> > that hardware is in a weird persistent state (a lot of settings get saved >> > to NVRAM) or if modemmanager doesn't handle certain corner cases (although >> > Verizon on a Quectel EM120R-GL using QMI would seem to be pretty >> > mainstream). Please reach out to me if you have any troubleshooting >> > suggestions, and I'll update the docs appropriately when I'm done. >> > >> > Thanks, >> > >> > -Philip >> > >> > >> > ___ >> > 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Meta packages for wireless
On Wed, 6 Sept 2023 at 20:22, Philip Prindeville wrote: > > Hi all, > > I was reading through some of the online documentations as I try to bring up > a 5G modem w/ Verizon and modemmanager, and bounced between various settings > (it's a Quectel EM120R-GL modem for the moment until something better > arrives), trying to decide if I wanted to use QMI or MBIM, if I should use > the "qui" protocol directly or "modemmanager" instead... And thought it would > be nice to have 2 or 3 groups of meta packages that you select and the rest > gets taken care of for you by dependencies. > > In particular: > > https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle > > Talks about kmod's and user-space tools necessary for QMI, different packages > necessary for MBIM, and then what's needed for NCM (anyone still using that > or 3G)... > > General debugging tools like minicom so you don't need to use "echo" or > "socat"... > > Before I start on the effort (shouldn't take more than a couple of hours), > does anyone object to the project (or conversely, is anyone willing to review > and sign-off on it)? I would find this rather useful, to have meta-packages for modems instead of having to select everything manually. I am working on RM520N-GL support at work (For QSDK, dont ask why) and I am not sure whether I want to use the mess called Quectel CM(Vendor tool) or modemmanager. Regards, Robert > > Eckert: thanks for the quick turnaround on the MBIM-disabled issue when > building modemmanager... > > If anyone is wondering, no, I still don't have wireless up... not sure if > that hardware is in a weird persistent state (a lot of settings get saved to > NVRAM) or if modemmanager doesn't handle certain corner cases (although > Verizon on a Quectel EM120R-GL using QMI would seem to be pretty mainstream). > Please reach out to me if you have any troubleshooting suggestions, and I'll > update the docs appropriately when I'm done. > > Thanks, > > -Philip > > > ___ > 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: Mofi still shipping Barrier Breaker (14.07)
On Sun, 3 Sept 2023 at 19:05, Dave Taht wrote: > > The qsdk is on openwrt 15. You won't believe it but they made it to 19.07 from the 12.0 release, and it seems they are preparing for 21.02. Regards, Robert > > On Sun, Sep 3, 2023 at 9:51 AM Philip Prindeville > wrote: > > > > Hi all, > > > > As we work on the 23.05 release, I was stunned to receive a Mofi > > MOFI4500-4GXeLTE-V3 router with 14.07 installed on it as part of my > > Unlimitedville enrollment. > > > > I thought, "wow, this must have been sitting in a warehouse a while! I'd > > better update it." So I went to the company's support site, grabbed the > > latest image, flashed it, rebooted and... still running 14.07. > > > > For those of you too young to remember, Barrier Breaker was released > > 10/2014 and included the 3.10.14 kernel (released 6/2013). > > > > How is this not cyber security malpractice? A firewall is your first line > > of defense against cyber attacks. If your firewall has long known, well > > documented vulnerabilities and exploits, you might as well not have a > > firewall at all. > > > > I wrote them asking why there wasn't a more recent, more secure release of > > the firewall firmware and this was their response: > > > > > > > Dear Philip, > > > You dint seem to know what you are talking about and should leave > > > software to Profesionals like us and relax > > > > > > I hope that most of the companies that use our software are more diligent, > > and don't incur repetitional damage to our efforts by continuing to ship > > EOL firmware. > > > > I get that not every company has kernel developers in-house, and frankly, > > providing an updated kernel release for their SoC is the manufacturer's > > responsibility, and MediaTek has not been responsive in this respect (for > > the longest time they were shipping a 2.6.36 SDK!). Some of the larger > > vendors (TPLink, ActionTec, Linksys, DLink, Netgear, et al) or their ODM > > partners have the option to hold their feet to the fire and make orders > > contingent on updated SDK's... I doubt that Mofi does the sort of volume > > that gives them any leverage. > > > > But I regress. > > > > Class Action suits are becoming more prevalent with computer and networking > > equipment manufacturers, as the public becomes aware of the increasing > > cyber security threats as well as manufacturers' implied responsibility to > > address vulnerabilities in a timely fashion as they become aware of them. > > > > I'm calling this out because I honestly hope it's the far outlier in our > > ecosystem, and not the rule. > > > > Sadly, > > > > -Philip > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > -- > Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html > Dave Täht CSO, LibreQos > > ___ > 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
[fstools] mount_root: support compression on F2FS rootfs
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 ---
Some devices dont utilize overlay but rather use F2FS backed RW rootfs
on eMMC and like.
F2FS does not provide space savings with compression but rather uses
compression to reduce writes and offer some small performance increases.
So, in order to prolong the eMMC life lets add a compile time option to
enable F2FS compression on rootfs mount.
Signed-off-by: Robert Marko
---
CMakeLists.txt | 16
mount_root.c | 14 +-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3421fec..eb605cb 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -66,6 +66,22 @@ IF(DEFINED CMAKE_OVL_MOUNT_FULL_ACCESS_TIME)
ADD_DEFINITIONS(-DOVL_MOUNT_FULL_ACCESS_TIME)
ENDIF(DEFINED CMAKE_OVL_MOUNT_FULL_ACCESS_TIME)
+IF(DEFINED CMAKE_F2FS_ROOTFS_MOUNT_COMPRESS_LZO)
+ ADD_DEFINITIONS(-DF2FS_ROOTFS_MOUNT_COMPRESS_LZO)
+ENDIF(DEFINED CMAKE_F2FS_ROOTFS_MOUNT_COMPRESS_LZO)
+
+IF(DEFINED CMAKE_F2FS_ROOTFS_MOUNT_COMPRESS_LZO_RLE)
+ ADD_DEFINITIONS(-DF2FS_ROOTFS_MOUNT_COMPRESS_LZO_RLE)
+ENDIF(DEFINED CMAKE_F2FS_ROOTFS_MOUNT_COMPRESS_LZO_RLE)
+
+IF(DEFINED CMAKE_F2FS_ROOTFS_MOUNT_COMPRESS_LZ4)
+ ADD_DEFINITIONS(-DF2FS_ROOTFS_MOUNT_COMPRESS_LZ4)
+ENDIF(DEFINED CMAKE_F2FS_ROOTFS_MOUNT_COMPRESS_LZ4)
+
+IF(DEFINED CMAKE_F2FS_ROOTFS_MOUNT_COMPRESS_ZSTD)
+ ADD_DEFINITIONS(-DF2FS_ROOTFS_MOUNT_COMPRESS_ZSTD)
+ENDIF(DEFINED CMAKE_F2FS_ROOTFS_MOUNT_COMPRESS_ZSTD)
+
ADD_EXECUTABLE(mount_root mount_root.c)
TARGET_LINK_LIBRARIES(mount_root fstools)
INSTALL(TARGETS mount_root RUNTIME DESTINATION sbin)
diff --git a/mount_root.c b/mount_root.c
index d343909..912ac1c 100644
--- a/mount_root.c
+++ b/mount_root.c
@@ -41,7 +41,19 @@ start(int argc, char *argv[1])
root = volume_find("rootfs");
volume_init(root);
ULOG_NOTE("mounting /dev/root\n");
- mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT, 0);
+ mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT,
+#ifdef F2FS_ROOTFS_MOUNT_COMPRESS_LZO
+ "compress_algorithm=lzo"
+#elif defined F2FS_ROOTFS_MOUNT_COMPRESS_LZO_RLE
+ "compress_algorithm=lzo-rle"
+#elif defined F2FS_ROOTFS_MOUNT_COMPRESS_LZ4
+ "compress_algorithm=lz4"
+#elif defined F2FS_ROOTFS_MOUNT_COMPRESS_ZSTD
+ "compress_algorithm=zstd"
+#else
+ 0
+#endif
+ );
}
/* Check for extroot config in rootfs before even trying rootfs_data */
--
2.41.0
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/3] ipq40xx: image: limit kernel size for NOR devices
On Mon, 24 Jul 2023 at 15:31, Tomasz Maciej Nowak wrote: > > From: Tomasz Maciej Nowak > > 'bootipq' command on some devices, with kernel on NOR flash chip, read > kernel partition size from Qualcomm proprietary partition table, which > seems to be stored in MIBIB partition. The partition table can be read > by 'smeminfo' command in U-Boot command line interface. Because this > partition table is never updated on sysupgrade (even when the kernel > size changes) kernel size is capped at initial value, usually 4MiB. > Sysupgrading such kernel will soft-brick the device, which will need > serial console for recovery. Some devices already suffer from this, > beacuse its U-Boot does not allow to boot LZMA compressed kernel image > and/or kernel zImage. Even some devices allowing to boot LZMA compressed > kernel will hit this limitation later. Therefore limit the kernel size > to 4MiB for devices not having it specified, so we won't create > soft-bricking images. > > Signed-off-by: Tomasz Maciej Nowak > --- > target/linux/ipq40xx/image/generic.mk | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/target/linux/ipq40xx/image/generic.mk > b/target/linux/ipq40xx/image/generic.mk > index f15463ae8ca5..d9d60a25ff0f 100644 > --- a/target/linux/ipq40xx/image/generic.mk > +++ b/target/linux/ipq40xx/image/generic.mk > @@ -130,6 +130,7 @@ define Device/8dev_habanero-dvk > DEVICE_VENDOR := 8devices > DEVICE_MODEL := Habanero DVK > IMAGE_SIZE := 30976k > + KERNEL_SIZE := 4096k Habanero does not have a kernel size limit as its not using bootipq for booting. Regards, Robert > SOC := qcom-ipq4019 > IMAGE/sysupgrade.bin := append-kernel | pad-to 64k | append-rootfs | > pad-rootfs | check-size | append-metadata > endef > @@ -400,6 +401,7 @@ define Device/dlink_dap-2610 > WRGG_DEVNAME := /dev/mtdblock/8 > WRGG_SIGNATURE := wapac30_dkbs_dap2610 > IMAGE_SIZE := 14080k > + KERNEL_SIZE := 4096k > IMAGES += factory.bin > # Bootloader expects a special 160 byte header which is added by > # wrgg-image. > @@ -478,6 +480,7 @@ define Device/engenius_emd1 > DEVICE_DTS_CONFIG := config@4 > SOC := qcom-ipq4018 > IMAGE_SIZE := 30720k > + KERNEL_SIZE := 4096k > IMAGES += factory.bin > IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | > append-metadata > IMAGE/factory.bin := qsdk-ipq-factory-nor | check-size > @@ -800,6 +803,7 @@ define Device/netgear_ex61x0v2 > NETGEAR_BOARD_ID := EX6150v2series > NETGEAR_HW_ID := 29765285+16+0+128+2x2 > IMAGE_SIZE := 14400k > + KERNEL_SIZE := 4096k > SOC := qcom-ipq4018 > endef > > @@ -954,6 +958,7 @@ define Device/pakedge_wr-1 > SOC := qcom-ipq4018 > BLOCKSIZE := 64k > IMAGE_SIZE := 31232k > + KERNEL_SIZE := 4096k > IMAGE/sysupgrade.bin := append-kernel | pad-to (BLOCKSIZE) | > append-rootfs | pad-rootfs | append-metadata > endef > TARGET_DEVICES += pakedge_wr-1 > @@ -1030,6 +1035,7 @@ define Device/qxwlan_e2600ac-c1 > BOARD_NAME := e2600ac-c1 > SOC := qcom-ipq4019 > IMAGE_SIZE := 31232k > + KERNEL_SIZE := 4096k > IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | > append-metadata > endef > TARGET_DEVICES += qxwlan_e2600ac-c1 > @@ -1202,6 +1208,7 @@ define Device/zyxel_wre6606 > DEVICE_DTS_CONFIG := config@4 > SOC := qcom-ipq4018 > IMAGE_SIZE := 13184k > + KERNEL_SIZE := 4096k > IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | > check-size | append-metadata > DEVICE_PACKAGES := -kmod-ath10k-ct kmod-ath10k-ct-smallbuffers > endef > -- > 2.41.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] ipq40xx: add support for eero Cento (J010001)
On 17. 05. 2023. 19:47, Connor Northway wrote:
development/internal name: Cento
public name: eero (2nd-gen)
model number: J010001
Hardware Info:
SoC : Qualcomm IPQ4019
RAM : 512 MB (Hynix NT5CC256M16ER-EK)
SPI Flash : 8 MB (Winbond W25Q64JVSS)
eMMC Flash : 4 GB (Kingston EMMC04G-M627)
Wi-Fi : 2.4 Ghz 2x2 802.11n (IPQ4019)
Wi-Fi : 5 Ghz 2x2 802.11ac (IPQ4019)
Ethernet: 2x 10/100/1000
Bluetooth : 5.0 / BLE (Cypress CYW20704)
RGBW LED Controller : Texas Instruments LP5562
Buttons : 1x Reset (bottom of device)
UART & SPI header : see below
Power & USB 2 : USB Type-C, requires 15W 5V/3A
Stock Firmware Layout:
The SPI flash stores U-Boot, U-Boot environment, hardware
calibration, and eero-specific information (keys, serial number,
MAC address, etc).
The eMMC is partitioned into an A/B layout with two sets of an ext2
kernel and ext4 rootfs partition, plus one cache partition.
MAC Address assignment:
One base MAC address is stored in SPI flash, with a space of 32
allocated. We follow stock layout, though stock FW also uses higher
addresses for routing / mesh applications.
Base / WAN : 48:dd:0c:**:**:xx
LAN: 48:dd:0c:**:**:xx + 1
Bluetooth : 48:dd:0c:**:**:xx + 2
Wi-Fi 1: 48:dd:0c:**:**:xx + 3
Wi-Fi 2: 48:dd:0c:**:**:xx + 4
Other OpenWrt details:
RGBW LED has been configured to the following:
Red: Failsafe
Green: Running
Blue: Upgrade
White: Boot
Ethernet ports are not labeled. Default config when viewed from
back: right port is WAN, left port is LAN.
UART/SPI Header:
2x5 1.27mm unpopulated SMT header labeled "J2".
Silkscreen dot marks pin 1; pins 2, 9, and 10 labeled with number.
Layout:
SPI cpu bypass --| 1 2 |-- SPI /CS
SPI CLK --| 3 4 |-- SPI DI
SPI DO --| 5 6 |-- GND
--| 7 8 |-- 3v3
UART RX --| 9 10 |-- UART TX
To access the SPI flash chip, pull pin 1 high (connect to 3v3)
before applying power through USB. This will disconnect the SPI
lines from the CPU and allow accessing the SPI bus without
contention. As always, do not connect external power to 3v3!
UART settings: 115200 8n1
Logic levels for UART and SPI are 3.3V.
OpenWrt Installation:
Unfortunately, eero has configured U-Boot to autoboot with no delay
and no way to abort boot. There does not appear to be any available
method to boot from an external source without modifications.
To change the bootdelay variable, editing the SPI flash contents
directly is required:
- Use an SPI programmer to make a backup of the flash
- Locate the APPSBLENV partition and modify the environment to have
a non-zero bootdelay value in both locations
- Update the leading CRC32 checksums
- Flash image back to the device and reboot
Details of environment layout:
APPSBLENV is at 0x21. It contains two redundant copies of
the following struct, each 0x1 bytes long.
struct env {
uint32_t crc; // calculated only over data[]
unsigned char flags;
unsigned char data[0x1-5];
};
Once access to the U-Boot shell is achieved:
Use TFTP to load the initramfs image to memory:
`tftpboot .itb`
with a TFTP server at 192.168.1.1
or use USB:
`fatload usb 0x8400 .itb`
with FAT32 USB drive connected through a powered hub
(use `usb part` to view partitions)
clear the bootargs variable:
`setenv bootargs`
then boot:
`bootm`
Make backups of SPI and eMMC flash!
Use SSH/SCP to transfer the sysupgrade file and run sysupgrade.
The upgrade script will determine which of the two dual-partition
slots the device is currently booting from. It will install to the
inactive slot if installing over stock FW, or the current slot if
upgrading OpenWrt. This leaves the most recent stock FW untouched
for easier restoration to stock. Don't rely on this as a backup!
Restore Stock Firmware:
If installed using sysupgrade and one stock partition set remains,
replace the U-Boot environment variables `bootargs` and `bootcmd`
with the contents of the `*_eero_backup` versions automatically
created during install. Stock firmware should overwrite OpenWrt the
next time it receives an update.
Signed-off-by: Connor Northway
---
package/boot/uboot-envtools/files/ipq40xx | 4 +
package/firmware/ipq-wifi/Makefile| 2 +
.../ipq40xx/base-files/etc/board.d/02_network | 5 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 8 +
.../etc/hotplug.d/usb/20-bluetooth-mac
Re: [PATCH] ath79: mikrotik: bump compat version for yafut images
On Fri, 5 May 2023 at 15:41, Thibaut VARÈNE wrote: > > Following 5264296, Mirotik NAND devices now use yafut to flash the > kernel on devices. This method is incompatible with the old-style > "kernel2minor" flash mechanism. > > Even though NAND images were disabled in default build since 21.02, a > user flashing a new-style image onto an old-style image would result in > in a soft-brick[1]. In order to prevent such accidental mishap, > especially as these device images will be reenabled in the upcoming > release, bump the compat version. > > After the new image is flashed, the compat version can be updated: > > uci set system.@system[0].compat_version='1.1' > uci commit > > [1] https://github.com/openwrt/openwrt/pull/12225#issuecomment-1517529262 > > Cc: Michał Kępień > Signed-off-by: Thibaut VARÈNE Reviewed-by: Robert Marko Regards, Robert > --- > target/linux/ath79/image/common-mikrotik.mk | 4 > 1 file changed, 4 insertions(+) > > diff --git a/target/linux/ath79/image/common-mikrotik.mk > b/target/linux/ath79/image/common-mikrotik.mk > index ce349b60b1..b37c8b7197 100644 > --- a/target/linux/ath79/image/common-mikrotik.mk > +++ b/target/linux/ath79/image/common-mikrotik.mk > @@ -18,4 +18,8 @@ endef > define Device/mikrotik_nand >$(Device/mikrotik) >IMAGE/sysupgrade.bin = append-kernel | sysupgrade-tar | append-metadata > + DEVICE_COMPAT_MESSAGE := \ > + NAND images switched to yafut. If running older image, reinstall from > initramfs. > + DEVICE_COMPAT_VERSION := 1.1 > + > endef > -- > 2.37.1 (Apple Git-137.1) > > > ___ > 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: Mark lantiq and omap as source only
On Wed, 3 May 2023 at 11:08, Nick wrote: > > I would also love to see a release. It is now already delayed more than > a month [0] (actual branching should be happening end of march). > However, I don't have a strong opinion on this. It's sad that lantiq > targets could be dropped. I will also try to fetch me some lantiq device > from somewhere to support fixing the fdb issues and re-adding it back to > 23.X or fixing it before the branch. I would also really like a new release to branch off sooner rather than later, there has been plenty of time for all targets to stabilize on 5.15. Regards, Robert > > If you branch soon, you could probably also give a talk about the new > OpenWrt release at Battlemesh v15. ;) > > Bests > Nick > > [0] - https://openwrt.org/meetings/20230124 > > On 5/1/23 18:01, Paul Spooren wrote: > > Hi all, > > > > I haven’t seen much progress happening regarding bringing the targets > > lantiq or omap to Kernel 5.15. That fact is currently the last blocker for > > branching another release. > > > > Instead of postponing another release I’d like to mark both targets as > > source-only and do the 23.05 branch, starting with a RC0. If either of the > > two targets are fixed within the RC phase, they should be re-added, as > > discussed during the last meeting. > > > > I’d value your feedback. > > > > Sunshine, > > Paul > > ___ > > 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ipq40xx: add support for Wallystech DR40x9
> > Signed-off-by: Robert Marko > > [Fixup dts for 2 missing crypto options] > > [Remove sfp from dts] > > [Add 'config' partition] > > [Update to latest wifi board bin files - received from Wallystech R] > > [Extensively tested on DR4029-V04] > > Signed-off-by: Koen Vandeputte > > If robert is OK with the change, I would drop the [] part. > > Also the BDF now are in a separate repo [1]. Please submit the separate > file there and then the ipq-wifi package needs to be bumped to the new > version and the the new board file added. > > [1] https://git.openwrt.org/?p=project/firmware/qca-wireless.git;a=summary > Cant say I have any opinion about the [] part. Regards, Robert ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add support for Wallystech DR40x9
On Wed, 15 Mar 2023 at 15:22, Koen Vandeputte
wrote:
>
> From: Robert Marko
>
> Adds support for the Wallys DR40x9 series boards.
> They come in IPQ4019 and IPQ4029 versions.
> IPQ4019/4029 only differ in that that IPQ4029 is the industrial version that
> is rated to higher temperatures.
>
> Specifications are:
> * CPU: Qualcomm IPQ40x9 (4x ARMv7A Cortex A7) at 716 MHz
> * RAM: 512 MB
> * Storage: 2MB of SPI-NOR, 128 MB of parallel NAND
> * USB 3.0 TypeA port for users
> * MiniPCI-E with PCI-E 2.0 link
> * MiniPCI-E for LTE modems with only USB2.0 link
> * 2 SIM card slots that are selected via GPIO11
> * MicroSD card slot
> * Ethernet: 2x GBe with 24~48V passive POE
> * SFP port (Does not work, I2C and GPIO's not connected on hardware)
> * DC Jack
> * UART header
> * WLAN: In-SoC 2x2 802.11b/g/n and 2x2 802.11a/n/ac
> * 4x MMCX connectors for WLAN
> * Reset button
> * 8x LED-s
>
> Installation instructions:
> Connect to UART, pins are like this:
> -> 3.3V | TX | RX | GND
>
> Settings are 115200 8n1
>
> Boot initramfs from TFTP:
> tftpboot 0x8400
> openwrt-ipq40xx-generic-wallys_dr40x9-initramfs-fit-uImage.itb
>
> bootm
>
> Then copy the sysupgrade image to the /tmp folder and execute sysupgrade -n
>
>
> Signed-off-by: Robert Marko
> [Fixup dts for 2 missing crypto options]
> [Remove sfp from dts]
> [Add 'config' partition]
> [Update to latest wifi board bin files - received from Wallystech R]
> [Extensively tested on DR4029-V04]
> Signed-off-by: Koen Vandeputte
> ---
> package/firmware/ipq-wifi/Makefile| 2 +
> .../ipq-wifi/board-wallys_dr40x9.qca4019 | Bin 0 -> 24316 bytes
> .../ipq40xx/base-files/etc/board.d/02_network | 1 +
> .../base-files/etc/board.d/03_gpio_switches | 3 +
> .../base-files/lib/upgrade/platform.sh| 3 +-
> .../arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts | 425 ++
> target/linux/ipq40xx/image/generic.mk | 13 +
> 7 files changed, 446 insertions(+), 1 deletion(-)
> create mode 100644 package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019
> create mode 100644
> target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts
>
> diff --git a/package/firmware/ipq-wifi/Makefile
> b/package/firmware/ipq-wifi/Makefile
> index 8e7fc4da39..6feac277b3 100644
> --- a/package/firmware/ipq-wifi/Makefile
> +++ b/package/firmware/ipq-wifi/Makefile
> @@ -47,6 +47,7 @@ ALLWIFIBOARDS:= \
> redmi_ax6 \
> sony_ncp-hg100-cellular \
> teltonika_rutx \
> + wallys_dr40x9 \
> xiaomi_ax3600 \
> xiaomi_ax9000 \
> zte_mf18a \
> @@ -147,6 +148,7 @@ $(eval $(call
> generate-ipq-wifi-package,qxwlan_e2600ac-c2,Qxwlan E2600AC C2))
> $(eval $(call generate-ipq-wifi-package,redmi_ax6,Redmi AX6))
> $(eval $(call generate-ipq-wifi-package,sony_ncp-hg100-cellular,Sony
> NCP-HG100/Cellular))
> $(eval $(call generate-ipq-wifi-package,teltonika_rutx,Teltonika RUTX))
> +$(eval $(call generate-ipq-wifi-package,wallys_dr40x9,Wallys DR40X9))
> $(eval $(call generate-ipq-wifi-package,xiaomi_ax3600,Xiaomi AX3600))
> $(eval $(call generate-ipq-wifi-package,xiaomi_ax9000,Xiaomi AX9000))
> $(eval $(call generate-ipq-wifi-package,zte_mf18a,ZTE MF18A))
> diff --git a/package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019
> b/package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019
> new file mode 100644
> index
> ..f23ecdfabbb90dc8d293676c4449a5fa9e90e721
> GIT binary patch
> literal 24316
> zcmeHPdr(tX8b1jj%4*?;fV{kf@JeV1A*2{2@{BY<3KkU!un1IR1@j)RX
> z0<|DS&^joOrihHi2gGV^?Tj+*=8pf3%%_bZ6FG+tKc{GrNm>?hSzi5={iA0qz
> zIp6v2`Of*yFDJ>p_x!kTCdP-x?-Ye|QbQBc<1>UnE|+C1F?~E+ii)iT#f7Xw
> zxis{xVrglpbnjLUUMoCUP`($dayhKZf^uoWfkRt&7nGFLRD=pMc$};#ISKmHU|+N_
> zk%}*aB_5k3IJ39UWvdp(;1UV$GQR_A|m3aCr?NM>KgFNUrxp9
> zlO62fCFS;9zZTs{;29KnY`Qkx>f+qi`nof%|#kfeL*k6 z4I8(Cta}+9h7~Hs&=N~^baZrZaIiBF0LHPIS}1O?ondl^b;D#~H#5zgq0Cg4xl-CZ
> zge{wCF`mrCP*+pUzU0U;wi zgNcv28fyx(li|VPu9g~U_V(nMiGHjZwDF-sQ)5-OI5`@3xE~w>Ca!dygd@C>95wMV
> zbdcc=eXx__>{LDjcGp@{nw`PtOgjV{$M=F-4U`u+NN<7~^5Owh~Y>J+tLyz1UPx
> z6}2xo(1g*lgps%q&5mgwpV^i|2mIJlh
> zq^umbn9uubK1e^ouGsX}jlrtUH=07Le2PX-7FWmYV`d^zH(@)WjGf~ebE!|-A!>ZJ
> z%DedbN0mKcb-typ`O6C>B3eBH4vy=7v%wj0b=%|_2vCk9O4?H2lGBTM=
> z!g4!1__MrbS{yIeXK_64zq6f-1_b!Szd*X5pFiD?PS3PoJLjB49}-b6Ap%)h8EJI7
> zFC5|LpP&3NHHDo4@tJ}CI@^DL_|x}>Hmu>M^^RnF`~Sgq^?&;G@grT^B@7qu
> zx^xJhk3g-ou6YPcm@zVv$I~UKa5-#NNF-KWu*QRZaPeLiN5dyDCqqyKiAUp+a5Nk#
> zRUEE6`d)Ke$9x3{rsbAZ3I(OGDGw-!7wX0K61$)-hzFX0Ca@D8Bp@kh3Ohv{hsGfy
> zl#6oN+y`7_3%Z59Ma)4t2p^pZLVdxsIunyXFcTG_=3>fy5Pcee8;Oquy+9aUz=d
Re: Intention on moving board-2 blob to a separate repo
On Tue, 28 Feb 2023 at 10:00, Petr Štetiar wrote: > > Ansuel Smith [2023-02-27 23:35:47]: > > Hi, > > > there is this idea of moving each board-2 blob to a separate repo > > the idea seems fine to me, I just don't understand this part, can you > elaborate more on why do we need separate repositaory for each board? It seems > to me, that a single repository should be good enough, is there anything I'm > missing? I think its just miscommunication, he probably meant to move all of the blobs under a separate repo to avoid increasing the size of the main repo with blobs. I agree with that approach as QCA doesn't seem overly interested in merging them upstream. Regards, Robert > > Cheers, > > Petr > > ___ > 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: Override MAC address for interface?
On Wed, 22 Feb 2023 at 21:39, Peter Naulls wrote: > > On 2/22/23 15:34, Robert Marko wrote: > > >> option 'lan1' > >> option macaddr 34:BA:9A:CC:DD:EE > > > > This should work as long as its in single quotes. > > I corrected the quotes, but no joy. Hm, that is weird as I have a device using this, albeit for WLAN interface and it works. > > > Also, cant you fixup the MAC in 02_networking or in preinit? > > Yes, I have a preinit script, but it seems that the MAC address > doesn't get retained. Probably cleared by netifd, which would be entirely > expected. > > The plan of course is to have the preinit script do the config setting. So, you have a script in /lib/preinit calling boot_hook_add preinit_main with a function setting the MAC? You can also use 02_network to set the MAC. Regards, Robert > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Override MAC address for interface?
On Wed, 22 Feb 2023 at 21:03, Peter Naulls wrote: > > > Due to some missing flash values, I need to do a later user space lookup for > possible missing values stored "elsewhere" to fix up the MAC address. > > According to: > > https://openwrt.org/docs/guide-user/base-system/basic-networking > > Something like this should work: > > > config device > option name 'br-lan' > option type 'bridge' > list ports 'lan1' > list ports 'lan2' > list ports 'lan3' > list ports 'lan4' > > config device > option 'lan1' > option macaddr 34:BA:9A:CC:DD:EE This should work as long as its in single quotes. Also, cant you fixup the MAC in 02_networking or in preinit? Regards, Robert > > But it doesn't get applied in my testing. > > As far as I know, there's no option to override the MAC in current luci. > > I am using ifconfig at boot to set the MAC, but that's transient and doesn't > remain set. > > Thanks. > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] hack-5.15: add Aquantia PHY hwmon temperature clamp patch
On Sat, 18 Feb 2023 at 21:47, Enrico Mioso wrote:
>
>
>
>
> On Sat, 18 Feb 2023, Robert Marko wrote:
>
> > Date: Sat, 18 Feb 2023 12:45:34
> > From: Robert Marko
> > To: Enrico Mioso
> > Cc: openwrt-devel@lists.openwrt.org, Andre Valentin ,
> > Karol Przybylski
> > Subject: Re: [PATCH 2/2] hack-5.15: add Aquantia PHY hwmon temperature clamp
> > patch
> >
> > On Sat, 18 Feb 2023 at 00:58, Enrico Mioso wrote:
> >>
> >> This is needed to avoid failures in the thermal subsystem while using this
> >> driver via hwmon subsystem.
> >
> > This should be submitted upstream, we have enough hacks already and
> > you will get proper feedback from Guenter rather fast whether this is a bug
> > in hwmon or the driver needs fixups.
>
> Thanks for your review and feedback!
>
> I am in the process of discussing this change upstream; the problem seems not
> to be related to hwmon core, but my approach of clamping the value is not
> going to be accepted either.
> I'm being asked to simply change the -ERANGE returned value to -EINVAL, so I
> will do it independently of this openwrt patch.
Perfect, I see that Andrew chimed in as well.
Realistically it should probably be clamped to -40 to 108 as that is
what the industrial models are rated at.
>
> But I am supposed to set max a min limits directly to reasonable values.
> I have no clear idea yet on where to set them in DTS, any help or hint would
> be very apreciated.
I am not sure if it's possible via DTS or only via sysfs.
Regards,
Robert
>
> Enrico
> >
> > Regards,
> > Robert
> >>
> >> CC: Andre Valentin
> >> CC: Karol Przybylski
> >> Signed-off-by: Enrico Mioso
> >> ---
> >> ...-clamp-temperature-value-in-aqr_hwmo.patch | 30 +++
> >> 1 file changed, 30 insertions(+)
> >> create mode 100644
> >> target/linux/generic/hack-5.15/726-net-phy-aquantia-clamp-temperature-value-in-aqr_hwmo.patch
> >>
> >> diff --git
> >> a/target/linux/generic/hack-5.15/726-net-phy-aquantia-clamp-temperature-value-in-aqr_hwmo.patch
> >>
> >> b/target/linux/generic/hack-5.15/726-net-phy-aquantia-clamp-temperature-value-in-aqr_hwmo.patch
> >> new file mode 100644
> >> index 00..36f0b37130
> >> --- /dev/null
> >> +++
> >> b/target/linux/generic/hack-5.15/726-net-phy-aquantia-clamp-temperature-value-in-aqr_hwmo.patch
> >> @@ -0,0 +1,30 @@
> >> +From 7bfceb1036d2ccda7b8e1e177e834c1cea9f0858 Mon Sep 17 00:00:00 2001
> >> +From: Enrico Mioso
> >> +Date: Sat, 18 Feb 2023 00:27:55 +0100
> >> +Subject: [PATCH] net: phy: aquantia: clamp temperature value in
> >> aqr_hwmon_set
> >> +
> >> +This patch is still under evaluation and is not guaranteed to be correct,
> >> +therefore it is submitted here in hack form. :)
> >> +
> >> +Signed-off-by: Enrico Mioso
> >> +---
> >> + drivers/net/phy/aquantia_hwmon.c | 3 +--
> >> + 1 file changed, 1 insertion(+), 2 deletions(-)
> >> +
> >> +diff --git a/drivers/net/phy/aquantia_hwmon.c
> >> b/drivers/net/phy/aquantia_hwmon.c
> >> +index 19c4c280a6cd..6444055e720c 100644
> >> +--- a/drivers/net/phy/aquantia_hwmon.c
> >> b/drivers/net/phy/aquantia_hwmon.c
> >> +@@ -70,8 +70,7 @@ static int aqr_hwmon_set(struct phy_device *phydev, int
> >> reg, long value)
> >> + {
> >> + int temp;
> >> +
> >> +- if (value >= 128000 || value < -128000)
> >> +- return -ERANGE;
> >> ++ clamp_val(value, -128000, 128000);
> >> +
> >> + temp = value * 256 / 1000;
> >> +
> >> +--
> >> +2.39.2
> >> +
> >> --
> >> 2.39.2
> >>
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] ipq807x: ZyXEL NBG7815: add fan support
On Sat, 18 Feb 2023 at 00:58, Enrico Mioso wrote:
>
> Add on/off fan support for the ZyXEL NBG7815. Single CPU cores, cluster
> CPU temperatures and the Aquantia PHY temperature sensor are monitored. The
> tmp103 sensor is missing from this patch, and can be added later, when kernel
> is bumped to 6.x, as it seems to require non-trivial hwmon backporting.
> Add kmod-phy-aquantia as default package while at it.
>
> Note: this patch has been marked RFT, since temperature values tuning is
> needed from someone actively using this device in high load conditions.
> Thanks to robimarko for helping me out.
>
> CC: Andre Valentin
> CC: Karol Przybylski
> Signed-off-by: Enrico Mioso
> ---
> .../arm64/boot/dts/qcom/ipq8074-nbg7815.dts | 119 ++
> target/linux/ipq807x/image/generic.mk | 2 +-
> 2 files changed, 120 insertions(+), 1 deletion(-)
>
> diff --git
> a/target/linux/ipq807x/files/arch/arm64/boot/dts/qcom/ipq8074-nbg7815.dts
> b/target/linux/ipq807x/files/arch/arm64/boot/dts/qcom/ipq8074-nbg7815.dts
> index 537dd52032..0ec602cf31 100644
> --- a/target/linux/ipq807x/files/arch/arm64/boot/dts/qcom/ipq8074-nbg7815.dts
> +++ b/target/linux/ipq807x/files/arch/arm64/boot/dts/qcom/ipq8074-nbg7815.dts
> @@ -39,6 +39,22 @@
> gpios = < 54 GPIO_ACTIVE_LOW>;
> };
> };
> +
> + fan: gpio_fan {
> + compatible = "gpio-fan";
> + gpios = < 21 GPIO_ACTIVE_HIGH>;
> + gpio-fan,speed-map = <00
> + 4500 1>;
> + #cooling-cells = <2>;
> + };
> +
> + thermal-zones {
> + aqr_thermal: aqr-thermal {
This is weird, why are you adding only the thermal zone here, then
using the label to add the trips and cooling device
down in the DTS?
> + polling-delay-passive = <1000>;
> + polling-delay = <1000>;
> + thermal-sensors = <>;
> + };
> + };
> };
>
> {
> @@ -291,6 +307,7 @@
> compatible = "ethernet-phy-ieee802.3-c45";
> reg = <8>;
> reset-gpios = < 63 GPIO_ACTIVE_LOW>;
> + #thermal-sensor-cells = <0>;
> };
> };
>
> @@ -443,3 +460,105 @@
>
> qcom,ath11k-calibration-variant = "Zyxel-NBG7815";
> };
> +
> +_thermal {
> + trips {
> + cpu0_active: cpu0-active {
> + temperature = <7>;
> + hysteresis = <5000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <_active>;
> + cooling-device = < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +_thermal {
> + trips {
> + cpu1_active: cpu1-active {
> + temperature = <7>;
> + hysteresis = <5000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <_active>;
> + cooling-device = < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +_thermal {
> + trips {
> + cpu2_active: cpu2-active {
> + temperature = <7>;
> + hysteresis = <5000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <_active>;
> + cooling-device = < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +_thermal {
> + trips {
> + cpu3_active: cpu3-active {
> + temperature = <7>;
> + hysteresis = <5000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <_active>;
> + cooling-device = < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +_thermal {
> + trips {
> + cluster_active: cluster-active {
> + temperature = <7>;
> + hysteresis = <5000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <_active>;
> + cooling-device = < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +_thermal {
This ties into my question for the zone, why not just add it directly
in the node?
> + trips {
> + aqr_thermal_active: aqr-thermal-active {
> + temperature =
Re: [PATCH 2/2] hack-5.15: add Aquantia PHY hwmon temperature clamp patch
On Sat, 18 Feb 2023 at 00:58, Enrico Mioso wrote:
>
> This is needed to avoid failures in the thermal subsystem while using this
> driver via hwmon subsystem.
This should be submitted upstream, we have enough hacks already and
you will get proper feedback from Guenter rather fast whether this is a bug
in hwmon or the driver needs fixups.
Regards,
Robert
>
> CC: Andre Valentin
> CC: Karol Przybylski
> Signed-off-by: Enrico Mioso
> ---
> ...-clamp-temperature-value-in-aqr_hwmo.patch | 30 +++
> 1 file changed, 30 insertions(+)
> create mode 100644
> target/linux/generic/hack-5.15/726-net-phy-aquantia-clamp-temperature-value-in-aqr_hwmo.patch
>
> diff --git
> a/target/linux/generic/hack-5.15/726-net-phy-aquantia-clamp-temperature-value-in-aqr_hwmo.patch
>
> b/target/linux/generic/hack-5.15/726-net-phy-aquantia-clamp-temperature-value-in-aqr_hwmo.patch
> new file mode 100644
> index 00..36f0b37130
> --- /dev/null
> +++
> b/target/linux/generic/hack-5.15/726-net-phy-aquantia-clamp-temperature-value-in-aqr_hwmo.patch
> @@ -0,0 +1,30 @@
> +From 7bfceb1036d2ccda7b8e1e177e834c1cea9f0858 Mon Sep 17 00:00:00 2001
> +From: Enrico Mioso
> +Date: Sat, 18 Feb 2023 00:27:55 +0100
> +Subject: [PATCH] net: phy: aquantia: clamp temperature value in aqr_hwmon_set
> +
> +This patch is still under evaluation and is not guaranteed to be correct,
> +therefore it is submitted here in hack form. :)
> +
> +Signed-off-by: Enrico Mioso
> +---
> + drivers/net/phy/aquantia_hwmon.c | 3 +--
> + 1 file changed, 1 insertion(+), 2 deletions(-)
> +
> +diff --git a/drivers/net/phy/aquantia_hwmon.c
> b/drivers/net/phy/aquantia_hwmon.c
> +index 19c4c280a6cd..6444055e720c 100644
> +--- a/drivers/net/phy/aquantia_hwmon.c
> b/drivers/net/phy/aquantia_hwmon.c
> +@@ -70,8 +70,7 @@ static int aqr_hwmon_set(struct phy_device *phydev, int
> reg, long value)
> + {
> + int temp;
> +
> +- if (value >= 128000 || value < -128000)
> +- return -ERANGE;
> ++ clamp_val(value, -128000, 128000);
> +
> + temp = value * 256 / 1000;
> +
> +--
> +2.39.2
> +
> --
> 2.39.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
On Sun, 5 Feb 2023 at 01:10, Jan Hoffmann wrote: > > > Am 02.02.23 um 11:54 schrieb Robert Marko: > > On Tue, 31 Jan 2023 at 23:52, Jan Hoffmann wrote: > >> > >> Hi Robert, > >> > >> > >> On 2023-01-30 at 00:08, Robert Marko wrote: > >>> Shouldn't it be possible for the modem driver itself to be fixed > >>> instead of faking > >>> the PCI details? > >> > >> This hack is definitely far from ideal, but I'm not sure if there is a > >> better way to fix this. > >> > >> Here are a few more details about the issue: > >> > >> On the affected devices (so far, three users reported it on the VRX518 > >> thread in the forum [0]), the function call to turn on the "EMA" > >> hardware unit in the vrx518_tc driver [1] fails with the error mentioned > >> in the commit message. > >> > >> I don't have any details about it, but this EMA unit is part of the data > >> path (it is also referenced in the ltq-atm and ltq-ptm data path drivers > >> for older Lantiq modems). If the EMA unit is not running, then at least > >> the transmit data path doesn't work, and any packets the driver writes > >> to the TX ring are not actually sent out by the device. > >> > >> This is also reproducible on non-affected devices by calling tc_clkoff > >> instead of tc_clkon in the vrx518_tc driver (i.e. disabling the hardware > >> unit). The same issue also occurs on affected devices running vendor > >> firmware, if the "magic" in the PCIe driver is disabled in the device > >> tree. So this is not just a bug in the data path driver. > > > > I get the issue, however, I am failing to see how faking the PCI ID for the > > root adaptor is magically solving that? > > If that works, why can't you just patch the driver to stop looking for > > the ancient > > Lantiq ID? > > As far as I can see, the magic values don't appear anywhere in the DSL > drivers. So it doesn't seem like there is an easy fix like that. > > To me this looks like whatever access to these values is being done, > seems to happen in hardware (or firmware). Maybe there are some > revisions or variants of the modem that don't like to cooperate with > non-Lantiq SoCs. > > But in the end, I don't know with certainty what exactly is happening > here, as about the only public information on these modems are the > open-source drivers (including the magic hack in the PCIe driver which > in its original form contains comments like "do some magic" without > really explaining what it actually does). Ok, I am now getting the issue, it's probably in the damn firmware. I still really dont like the hack that we are gonna need to carry forever. I would like for somebody else to chime in as well. Regards, Robert > > Regards, > Jan > > > > > > Regards, > > Robert > >> > >> > >> Regards, > >> Jan > >> > >> > >>> > >>> Especially considering that now modem support is not self-contained > >>> and will require > >>> patching the DWC Qualcomm PCI driver forever. > >>> > >>> Regards, > >>> Robert > >> > >> > >> [0] > >> https://forum.openwrt.org/t/adding-support-for-vrx518-and-maybe-vrx320/55160 > >> [1] > >> https://gitlab.com/prpl-foundation/intel/vrx518_tc_drv/-/blob/ugw-8.5.2/dcdp/tc_main.c#L112 > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
On Tue, 31 Jan 2023 at 23:52, Jan Hoffmann wrote: > > Hi Robert, > > > On 2023-01-30 at 00:08, Robert Marko wrote: > > Shouldn't it be possible for the modem driver itself to be fixed > > instead of faking > > the PCI details? > > This hack is definitely far from ideal, but I'm not sure if there is a > better way to fix this. > > Here are a few more details about the issue: > > On the affected devices (so far, three users reported it on the VRX518 > thread in the forum [0]), the function call to turn on the "EMA" > hardware unit in the vrx518_tc driver [1] fails with the error mentioned > in the commit message. > > I don't have any details about it, but this EMA unit is part of the data > path (it is also referenced in the ltq-atm and ltq-ptm data path drivers > for older Lantiq modems). If the EMA unit is not running, then at least > the transmit data path doesn't work, and any packets the driver writes > to the TX ring are not actually sent out by the device. > > This is also reproducible on non-affected devices by calling tc_clkoff > instead of tc_clkon in the vrx518_tc driver (i.e. disabling the hardware > unit). The same issue also occurs on affected devices running vendor > firmware, if the "magic" in the PCIe driver is disabled in the device > tree. So this is not just a bug in the data path driver. I get the issue, however, I am failing to see how faking the PCI ID for the root adaptor is magically solving that? If that works, why can't you just patch the driver to stop looking for the ancient Lantiq ID? Regards, Robert > > > Regards, > Jan > > > > > > Especially considering that now modem support is not self-contained > > and will require > > patching the DWC Qualcomm PCI driver forever. > > > > Regards, > > Robert > > > [0] > https://forum.openwrt.org/t/adding-support-for-vrx518-and-maybe-vrx320/55160 > [1] > https://gitlab.com/prpl-foundation/intel/vrx518_tc_drv/-/blob/ugw-8.5.2/dcdp/tc_main.c#L112 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
On Mon, 30 Jan 2023 at 23:41, Jan Hoffmann wrote:
>
> Some VRX518 modems fail to initialize properly with the error message
> "dc_ep_clk_on failed". As a result, the DSL data path doesn't work.
>
> This hack, which is based on code from the FRITZ!Box 7530 GPL archive,
> fixes the issue. It changes the PCIe vendor/device ID to values matching
> a Lantiq SoC. It also appears to emulate a Lantiq CPU ID register for
> connected PCIe devices, by remapping the matching address area to a
> specially crafted buffer using the address translation unit.
>
> The hack is only active if the "avm,host_magic" property is specified in
> the device tree, so this shouldn't affect any devices other than
> FRITZ!Box 7530/7520.
Shouldn't it be possible for the modem driver itself to be fixed
instead of faking
the PCI details?
Especially considering that now modem support is not self-contained
and will require
patching the DWC Qualcomm PCI driver forever.
Regards,
Robert
>
> Signed-off-by: Jan Hoffmann
> ---
> .../boot/dts/qcom-ipq4019-fritzbox-7530.dts | 2 +
> .../997-pcie-qcom-host-magic.patch| 215 ++
> 2 files changed, 217 insertions(+)
> create mode 100644
> target/linux/ipq40xx/patches-5.15/997-pcie-qcom-host-magic.patch
>
> diff --git
> a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> index 336da52f2724..bc167616d3dc 100644
> ---
> a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> +++
> b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> @@ -306,6 +306,8 @@
> perst-gpio = < 38 GPIO_ACTIVE_LOW>;
> wake-gpio = < 50 GPIO_ACTIVE_LOW>;
>
> + avm,host_magic;
> +
> bridge@0,0 {
> reg = <0x 0 0 0 0>;
> #address-cells = <3>;
> diff --git a/target/linux/ipq40xx/patches-5.15/997-pcie-qcom-host-magic.patch
> b/target/linux/ipq40xx/patches-5.15/997-pcie-qcom-host-magic.patch
> new file mode 100644
> index ..f427bccd2f4a
> --- /dev/null
> +++ b/target/linux/ipq40xx/patches-5.15/997-pcie-qcom-host-magic.patch
> @@ -0,0 +1,215 @@
> +This hack is based on code from the FRITZ!Box 7530 GPL archive for
> +firmware version 07.50.
> +
> +If the device tree contains the "avm,host_magic" property, it changes
> +the PCIe vendor/device ID to the values from Lantiq GRX500 SoCs. It also
> +programs the ATU to present a buffer containing a magic value to PCIe
> +devices. This appears to emulate a Lantiq CPU ID register.
> +
> +Without this hack, some VRX518 modems fail to initialize properly (error
> +"dc_ep_clk_on failed"), and the DSL data path doesn't work.
> +--- a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> +@@ -27,6 +27,7 @@
> + #include
> + #include
> + #include
> ++#include
> +
> + #include "../../pci.h"
> + #include "pcie-designware.h"
> +@@ -102,6 +103,8 @@
> +
> + #define QCOM_PCIE_CRC8_POLYNOMIAL (BIT(2) | BIT(1) | BIT(0))
> +
> ++#define PCIE_MAGIC_SIZE 0x1
> ++
> + struct qcom_pcie_resources_2_1_0 {
> + struct clk_bulk_data clks[QCOM_PCIE_2_1_0_MAX_CLOCKS];
> + struct reset_control *pci_reset;
> +@@ -197,6 +200,8 @@ struct qcom_pcie {
> + struct phy *phy;
> + struct gpio_desc *reset;
> + const struct qcom_pcie_ops *ops;
> ++ void *magic_cpu_addr;
> ++ dma_addr_t magic_dma_handle;
> + };
> +
> + #define to_qcom_pcie(x) dev_get_drvdata((x)->dev)
> +@@ -1388,8 +1393,141 @@ err_deinit:
> + return ret;
> + }
> +
> ++static int qcom_pcie_magic_prog_atu(struct qcom_pcie *pcie,
> ++ u32 addr, u32 limit, u32 phys)
> ++{
> ++ struct dw_pcie *pci = pcie->pci;
> ++ struct device *dev = pci->dev;
> ++ u32 retries, val;
> ++ int index;
> ++
> ++ if (!pci->num_ib_windows) {
> ++ dev_err(dev, "No inbound ATU window available for magic\n");
> ++ return -1;
> ++ }
> ++
> ++ /*
> ++ * Use highest window index and reduce window count so the driver
> ++ * won't overwrite the entry later.
> ++ */
> ++ index = --pci->num_ib_windows;
> ++
> ++#if LINUX_VERSION_CODE < KERNEL_VERSION(6,0,0)
> ++ if (pci->iatu_unroll_enabled) {
> ++ dev_err(dev, "Programming ATU for magic not implemented for
> this hardware\n");
> ++ return -1;
> ++ }
> ++
> ++ dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
> ++ PCIE_ATU_REGION_INBOUND | index);
> ++
> ++ dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE, addr);
> ++ dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE, 0);
> ++ dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT, limit);
> ++ dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET, phys);
> ++ dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET, 0);
> ++
> ++ dw_pcie_writel_dbi(pci,
Re: [PATCH] mt7621: Initial Atel platform support
On Thu, 26 Jan 2023 at 16:18, Peter Naulls wrote: > > > I'm expecting this to need to be tidied up based upon feedback, but here's the > first try of support for the two mt7621 atel platforms I've been working on. > > I have a number of smaller changes to go with this, but these are the top > level > pieces to get started that I want to get right first. This needs to be sent by using git send email, but first you must use git format-patch to properly export the commit, just plain diff as attachment is not enough. Regards, Robert > > Signed-off-by: Peter Naulls > ___ > 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: [opkg 0/3] Rework criteria for dependent package selection
On Mon, 17 Oct 2022 at 19:07, Eneas U de Queiroz wrote: > > This fixes a problem when generating an image using the firmware > building, to include libwolfsslcpu-crypto. Before they are sent to the > asu server, the firmware builder strips ABI version from the packages > and sort they alphabetically. That means libustream-wolfssl will be > installed before libwolfsslcpu-crypto. > > Opkg will see that libustream-wolfssl depends on > libwolfssl5.5.1.b24d5f87. Since it matches the name of the regular > libwolfssl package, it is chosen and installed. When it comes > libwolfsslcpu-crypto's turn, it will fail because of a clash with the > regular package. > > If you were to run it in the cmdline with the full name of > libwolfsslcpu-crypto5.5.1.b24d5f87, or list it before any dpeendents, > then it would work as expected. However, because the firmware selector > sripts ABI version and changes the order of the packages, there's no way > to build an image with both libustrem-wolfssl and libwolfsslcpu-crypto. > > The first two commits attempt to add some order to the way they are > currently chosen, by prioritizing packages chosen "by hand" and by > preferring packages listed in the command line arguments over new > packages chosen automatically. > > The third commit adds matching the package without ABI suffix, and > establishes a hierarchy among the criteria, prioritizing user choices > (i.e. package names given in as command line arguments), then developer > choices (chosen package names), and resort to alphabetical order as a > last resort. > > When resolving dependencies, packages listed in the cli may not have the > ABI version, and they should have a higher priority over anything picked > automatically. > > Use powers of two when computing the score to avoid ties due to > different criteria, and so that it reflects what was matched. The > resulting priorities after this change are: > > 1. base score is 0 > > ---USER CHOICES (cmdline)--- > 2. packages "picked by hand" (local file given in the cli) have absolute >priority, ending the search regardless of score > 3. package whose full name is in the cli: score += 4 > 4. package whose name stripped of ABI matches one in the cli: score += 2 > > ---DEVELOPER CHOICE (pkg data)--- > 5. package whose full name matches the dependency name: score += 1 >Note: the ABI is recorded in the dependency, so I'm not using the >stripped name here. > > 6. in case of a tie, the last package that was looked at is chosen >(equivalent to being first in alphabetical order) > > I tried not to change things so much--aside from restoring the "picked > by hand" case, I just created tie-breakers. However, I still have some > questions about the necessity of some of this. For example: if more > than one dependency is listed in the cli, does it matter which package > is chosen? I imagine it would be equivalent of the picked-by-hand case, > so it would be simpler and faster to end the search. It could make a > difference if one were to install clashing packages with > --force-overwrite in the same invocation, but I can't see a scenario > where this would be useful. > > This was tested with the Image Builder, and by running opkg from command > line on Linksys E8450 (mediatek/mt7622, aarch64_cortex-a53). Hi, I have just rediscovered this issue since ipq807x uses the libwolfsslcpu-crypto as a target package by default, however, this is breaking image builder. So, I wanted to bring some attention to this patchset that is fixing this issue as I am sure we are gonna hit more of these in the future are well. Tested-by: Robert Marko # ipq807x Regards, Robert > > Signed-off-by: Eneas U de Queiroz > > Eneas U de Queiroz (3): > libopkg: pkg_hash: restore picked by hand priority > libopkg: pkg_hash: bump score of packages in cli > libopkg: pkg_hash: consider names stripped of ABI > > libopkg/pkg_hash.c | 35 +-- > 1 file changed, 29 insertions(+), 6 deletions(-) > > > ___ > 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
[PATCH] ath25: mark as source-only
ath25 seems to be a target with low number of users according to download statistics, most of which are for older releases anyway. Users that we managed to find are currently building images downstream as due to low amount of RAM (32MB) default config will not work. Target also suffers from inability for the 5.15 kernel bump to be tested which is a requirment for the next release. So, for those reasons, lets mark it as source-only so that Buildbots dont use the resources for building the images for this target anymore. Signed-off-by: Robert Marko --- target/linux/ath25/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile index 4675962e6f..debb0a324b 100644 --- a/target/linux/ath25/Makefile +++ b/target/linux/ath25/Makefile @@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk ARCH:=mips BOARD:=ath25 BOARDNAME:=Atheros AR231x/AR5312 -FEATURES:=squashfs low_mem small_flash +FEATURES:=squashfs low_mem small_flash source-only SUBTARGETS:=generic KERNEL_PATCHVER:=5.10 -- 2.39.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On Mon, 9 Jan 2023 at 18:29, Christian Marangi wrote:
>
> From: Jo-Philipp Wich
>
> Some device have embedded wifi card that are not connected with usb or
> internall with pci. Such device have fake device_id and only the
> vendor_id actually reflect something real but internally they don't have
> any id and are just matched by the node compatible binding in DT.
>
> We currently match this with a big if-else to match the single devices
> but this can be improved and be matched directly in devices.txt
>
> Rework this so that we can drop the big if-else and move the matching
> from devices.txt
>
> When a device is matched using compatible in iwinfo the hardware will be
> flagged as embedded and won't print empty ids.
>
> Tested-by: Christian Marangi
> Co-developed-by: Christian Marangi
> Signed-off-by: Jo-Philipp Wich
> Signed-off-by: Christian Marangi
Tested-by: Robert Marko
Regards,
Robert
> ---
> devices.txt | 13 +
> include/iwinfo.h | 2 ++
> iwinfo_cli.c | 9 --
> iwinfo_nl80211.c | 71 ++--
> iwinfo_utils.c | 8 +-
> 5 files changed, 36 insertions(+), 67 deletions(-)
>
> diff --git a/devices.txt b/devices.txt
> index d76bbca..93938b5 100644
> --- a/devices.txt
> +++ b/devices.txt
> @@ -206,3 +206,16 @@
> # USB devices
> # 0x | 0x | vendor id | product id | ...
> 0x 0x 0x0e8d 0x79610 0 "MediaTek" "MT7921AU"
> +
> +# FDT compatible strings
> +# "compatible" | txpower offset | frequency offset | ...
> +"qca,ar9130-wmac" 0 0 "Atheros" "AR9130"
> +"qca,ar9330-wmac" 0 0 "Atheros" "AR9330"
> +"qca,ar9340-wmac" 0 0 "Atheros" "AR9340"
> +"qca,qca9530-wmac" 0 0 "Qualcomm Atheros" "QCA9530"
> +"qca,qca9550-wmac" 0 0 "Qualcomm Atheros" "QCA9550"
> +"qca,qca9560-wmac" 0 0 "Qualcomm Atheros" "QCA9560"
> +"qcom,ipq4019-wifi" 0 0 "Qualcomm Atheros" "IPQ4019"
> +"qcom,ipq8074-wifi" 0 0 "Qualcomm Atheros" "IPQ8074"
> +"mediatek,mt7622-wmac" 0 0 "MediaTek" "MT7622"
> +"mediatek,mt7986-wmac" 0 0 "MediaTek" "MT7986"
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index e87ad18..4b63f1e 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -243,6 +243,7 @@ struct iwinfo_hardware_id {
> uint16_t device_id;
> uint16_t subsystem_vendor_id;
> uint16_t subsystem_device_id;
> + char compatible[128];
> };
>
> struct iwinfo_hardware_entry {
> @@ -254,6 +255,7 @@ struct iwinfo_hardware_entry {
> uint16_t subsystem_device_id;
> int16_t txpower_offset;
> int16_t frequency_offset;
> + char compatible[128];
> };
>
> extern const struct iwinfo_iso3166_label IWINFO_ISO3166_NAMES[];
> diff --git a/iwinfo_cli.c b/iwinfo_cli.c
> index d70f7fb..9b3e8e3 100644
> --- a/iwinfo_cli.c
> +++ b/iwinfo_cli.c
> @@ -335,9 +335,12 @@ static char * print_hardware_id(const struct iwinfo_ops
> *iw, const char *ifname)
>
> if (!iw->hardware_id(ifname, (char *)))
> {
> - snprintf(buf, sizeof(buf), "%04X:%04X %04X:%04X",
> - ids.vendor_id, ids.device_id,
> - ids.subsystem_vendor_id, ids.subsystem_device_id);
> + if (strlen(ids.compatible) > 0)
> + snprintf(buf, sizeof(buf), "embedded");
> + else
> + snprintf(buf, sizeof(buf), "%04X:%04X %04X:%04X",
> + ids.vendor_id, ids.device_id,
> + ids.subsystem_vendor_id,
> ids.subsystem_device_id);
> }
> else
> {
> diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> index 916192f..a9e2adf 100644
> --- a/iwinfo_nl80211.c
> +++ b/iwinfo_nl80211.c
> @@ -3445,7 +3445,7 @@ static int nl80211_get_mbssid_support(const char
> *ifname, int *buf)
>
> static int nl80211_hardware_id_from_fdt(struct iwinfo_hardware_id *id, const
> char *ifname)
> {
> - char *phy, compat[64], path[PATH_MAX];
> + char *phy, path[PATH_MAX];
>
> /* Try to determine the phy name from the given interface */
> phy = nl80211_ifname2phy(ifname);
> @@ -3453,62 +3453,10 @@ static int nl80211_hardware_id_from_fdt(struct
>
Re: [PATCH] archs38: mark as source-only
On Thu, 29 Dec 2022 at 19:23, Robert Marko wrote: > > archs38 seems to be pretty much unused, usually only treewide changes or > kernel bumps in order to branch off new stable are done to it. > > Considering that target only support some Synopsis HS38 ARC reference > boards and no consumer hardware so mark the target as source-only to stop > using Buildbot resources on building the target and packages for it. Just a friendly ping, to see if there are any objections against this. Regards, Robert > > Signed-off-by: Robert Marko > --- > target/linux/archs38/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/linux/archs38/Makefile b/target/linux/archs38/Makefile > index e08f779170..756de43561 100644 > --- a/target/linux/archs38/Makefile > +++ b/target/linux/archs38/Makefile > @@ -8,6 +8,7 @@ ARCH:=arc > CPU_TYPE:=archs > BOARD:=archs38 > BOARDNAME:=Synopsys DesignWare ARC HS38 > +FEATURES:=source-only > SUBTARGETS:=generic > > KERNEL_PATCHVER:=5.10 > -- > 2.38.1 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] iwinfo: devices: add Qualcomm Atheros IPQ8074 WiSoC
On Fri, 6 Jan 2023 at 23:43, Jo-Philipp Wich wrote: > > Hi Robert, > > I know that you're just expanding existing code (which I recently noticed for > the first time) but I think that adding more and more if/else clauses with > further hardware matches for purely cosmetic reasons* is a good way forward. > > At the very least a mechanism should be added to configure this > FDT-to-PCI-ID-to-name mapping in the devices.txt file directly. > > > *) Many hardware entries are simply added to show a fancy radio name instead >of "Generic MAC80211" radio but don't add non-defaults values such as power >offsets or antenna gains. Jo, I agree that adding more if/else isn't ideal but this is pretty much what has been done so far and I dont have time or ideas on how to improve this. And yeah, devices are added just to display the SoC name instead of the generic name and that's pretty much it. Regards, Robert > > > Regards, > Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE wrote: > > > > > Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : > > > > On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: > >> I need to express a per-target dependency on the 'base64' utility, and > >> that's seemingly impossible to do for busybox. Pull in coreutils to make > >> that easier. > >> > >> Signed-off-by: Brian Norris > > > > We still need to think of a correct solution for this... coreutils is an > > option but wonder if a better one is openssl... Actually we have a small > > tool to handle specific decryption of some stuff... Wonder if that can > > be expanded for this task and just use wolfssl or openssl api to decode > > base64 stuff? > > Using one or the other would impose (i.e. (en)force) that SSL library on this > particular target. Do we want this, especially considering the ongoing > conversation about mbedTLS? > > Also pulling an entire SSL implementation just to decode base64 seems a tad > overkill too. I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils is a better option for sure. Regards, Robert > > HTH > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] iwinfo: devices: add Qualcomm Atheros QCN6024/9024/9074 cards
On Fri, 6 Jan 2023 at 17:42, Christian Marangi wrote: > > On Fri, Jan 06, 2023 at 05:32:48PM +0100, Robert Marko wrote: > > On Fri, 6 Jan 2023 at 17:31, Christian Marangi wrote: > > > > > > On Fri, Jan 06, 2023 at 05:14:37PM +0100, Robert Marko wrote: > > > > Add Qualcomm Atheros QCN6024/9024/9074 PCI ID, they all are compatible > > > > and > > > > use the same ID. > > > > > > > > Signed-off-by: Robert Marko > > > > > > Hi, > > > can you send a v2 with the iwinfo from the title dropped? > > > > > > Something like [iwinfo PATCH] devices: ... > > > > > > Just notice the different naming convention. > > > > Sure, but its a bit weird to send iwinfo patches to OpenWrt mailing > > list without a prefix > > of subproject? > > > > AFAIK for patch that should be merged in other repo than openwrt the > rule should be putting the related repo in the [] > > So to propose something to the ubus repo someone should use something > like > > [ubus PATCH] libubus: do some change > > The ubus present in the [] explain that it's for the ubus repo. Similar > to patch sent to net-next or net repo. Yeah, I got reminded about git subject prefix exactly for this usecase. Regards, Robert > > > > > > > > --- > > > > devices.txt | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/devices.txt b/devices.txt > > > > index bc0257c..d76bbca 100644 > > > > --- a/devices.txt > > > > +++ b/devices.txt > > > > @@ -173,6 +173,7 @@ > > > > 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984" > > > > 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887" > > > > 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886" > > > > +0x17cb 0x1104 0x17cb 0x11040 0 "Qualcomm Atheros" > > > > "QCN6024/9024/9074" > > > > 0x1814 0x3050 0x1814 0x00050 0 "Ralink" "Rt3050" > > > > 0x1814 0x3051 0x1814 0x00070 0 "Ralink" "Rt3051" > > > > 0x1814 0x3052 0x1814 0x00080 0 "Ralink" "Rt3052" > > > > -- > > > > 2.39.0 > > > > > > > > > > > > ___ > > > > openwrt-devel mailing list > > > > openwrt-devel@lists.openwrt.org > > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > > > -- > > > Ansuel > > -- > Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] devices: add Qualcomm Atheros QCN6024/9024/9074 cards
Add Qualcomm Atheros QCN6024/9024/9074 PCI ID, they all are compatible and use the same ID. Signed-off-by: Robert Marko --- Changes in v2: * Remove iwinfo prefix --- devices.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/devices.txt b/devices.txt index bc0257c..d76bbca 100644 --- a/devices.txt +++ b/devices.txt @@ -173,6 +173,7 @@ 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984" 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887" 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886" +0x17cb 0x1104 0x17cb 0x11040 0 "Qualcomm Atheros" "QCN6024/9024/9074" 0x1814 0x3050 0x1814 0x00050 0 "Ralink" "Rt3050" 0x1814 0x3051 0x1814 0x00070 0 "Ralink" "Rt3051" 0x1814 0x3052 0x1814 0x00080 0 "Ralink" "Rt3052" -- 2.39.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] iwinfo: devices: add Qualcomm Atheros QCN6024/9024/9074 cards
On Fri, 6 Jan 2023 at 17:31, Christian Marangi wrote: > > On Fri, Jan 06, 2023 at 05:14:37PM +0100, Robert Marko wrote: > > Add Qualcomm Atheros QCN6024/9024/9074 PCI ID, they all are compatible and > > use the same ID. > > > > Signed-off-by: Robert Marko > > Hi, > can you send a v2 with the iwinfo from the title dropped? > > Something like [iwinfo PATCH] devices: ... > > Just notice the different naming convention. Sure, but its a bit weird to send iwinfo patches to OpenWrt mailing list without a prefix of subproject? Regards, Robert > > > --- > > devices.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/devices.txt b/devices.txt > > index bc0257c..d76bbca 100644 > > --- a/devices.txt > > +++ b/devices.txt > > @@ -173,6 +173,7 @@ > > 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984" > > 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887" > > 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886" > > +0x17cb 0x1104 0x17cb 0x11040 0 "Qualcomm Atheros" > > "QCN6024/9024/9074" > > 0x1814 0x3050 0x1814 0x00050 0 "Ralink" "Rt3050" > > 0x1814 0x3051 0x1814 0x00070 0 "Ralink" "Rt3051" > > 0x1814 0x3052 0x1814 0x00080 0 "Ralink" "Rt3052" > > -- > > 2.39.0 > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > -- > Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] iwinfo: devices: add Qualcomm Atheros QCN6024/9024/9074 cards
Add Qualcomm Atheros QCN6024/9024/9074 PCI ID, they all are compatible and use the same ID. Signed-off-by: Robert Marko --- devices.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/devices.txt b/devices.txt index bc0257c..d76bbca 100644 --- a/devices.txt +++ b/devices.txt @@ -173,6 +173,7 @@ 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984" 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887" 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886" +0x17cb 0x1104 0x17cb 0x11040 0 "Qualcomm Atheros" "QCN6024/9024/9074" 0x1814 0x3050 0x1814 0x00050 0 "Ralink" "Rt3050" 0x1814 0x3051 0x1814 0x00070 0 "Ralink" "Rt3051" 0x1814 0x3052 0x1814 0x00080 0 "Ralink" "Rt3052" -- 2.39.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] iwinfo: devices: add Qualcomm Atheros IPQ8074 WiSoC
Add detection of the Qualcomm Atheros IPQ8074 WiSoC using the compatible
string from device tree.
Signed-off-by: Robert Marko
---
devices.txt | 1 +
iwinfo_nl80211.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/devices.txt b/devices.txt
index e0663b8..bc0257c 100644
--- a/devices.txt
+++ b/devices.txt
@@ -167,6 +167,7 @@
0x168c 0x003c 0x1a56 0x14200 0 "Qualcomm Atheros" "QCA9862"
0x168c 0x003c 0x19b6 0xd03c0 0 "Mikrotik" "R11e-5HacT"
0x168c 0x003c 0x168c 0x40190 0 "Qualcomm Atheros" "IPQ4019"
+0x168c 0x8074 0x168c 0x80740 0 "Qualcomm Atheros" "IPQ8074"
0x168c 0x003c 0x19b6 0xd0750 0 "Mikrotik" "R11e-5HacD"
0x168c 0x0040 0x168c 0x00020 0 "Qualcomm Atheros" "QCA9990"
0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984"
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index a78343f..916192f 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -3491,6 +3491,11 @@ static int nl80211_hardware_id_from_fdt(struct
iwinfo_hardware_id *id, const cha
id->device_id = 0x003c;
id->subsystem_vendor_id = 0x168c;
id->subsystem_device_id = 0x4019;
+ } else if (!strcmp(compat, "qcom,ipq8074-wifi")) {
+ id->vendor_id = 0x168c;
+ id->device_id = 0x8074;
+ id->subsystem_vendor_id = 0x168c;
+ id->subsystem_device_id = 0x8074;
} else if (!strcmp(compat, "mediatek,mt7622-wmac")) {
id->vendor_id = 0x14c3;
id->device_id = 0x7622;
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
On Thu, 5 Jan 2023 at 19:47, Brian Norris wrote: > > Hi Christian, > > On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote: > > On Mon, Jan 02, 2023 at 03:25:33PM -0800, Brian Norris wrote: > > > See the patch notes about the stock firmware for TP-Link Onhub and > > > https://chromium-review.googlesource.com/243115. > > > > > > As noted there, the production firmware for Google OnHub devices only > > > provide the *-base64 Device Tree property, and so either the kernel or > > > some user space mechanism needs to know how to parse/convert this > > > property. > ... > > > > Aside from this, I notice this is actually NOT used in the 2 device you > > are proposing. I'm totally missing something or this is not needed at > > all? > > It's provided by the production firmware, which patches it into the > device tree on its own. So you're not going to find it in the kernel or > DTS sources. > > If you want to look at its source though, it's here: > https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/firmware-storm-6315.B/src/board/storm/wifi_calibration.c > > And unfortunately, systems I'm looking at were only programmed with the > base64 VPD: > > # ls -1 /sys/firmware/vpd/ro/wifi* > /sys/firmware/vpd/ro/wifi_base64_calibration0 > /sys/firmware/vpd/ro/wifi_base64_calibration1 > /sys/firmware/vpd/ro/wifi_base64_calibration2 > > > Also on top of that the besto solution for these special case is to > > parse the base64 data in userspace a produce a calibration bin to pass > > with sysfs. A patch and some code to decode base64 seems overkill to me. > > I'd love something that's more pleasant than in-kernel base64. Is there > some sysfs method for this that I'm not aware of? The closest I find is: > > /sys/kernel/debug/ieee80211/*/ath10k/cal_data > > But that's read-only, not read-write. And it's not completely obvious to > me that this data can be (re)written to the target radio arbitrarily, so > I suppose the API would be a bit fiddly -- that one has to know to write > this file before ever bringing up the interface (but after loading the > driver/module). > > Without a user space API, this is the best I came up with. You can extract and provide the caldata from userspace by acting on the hotplug event that kernel files after request_firmware() fails, look at what Fritzbox devices are doing in: https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata Basically, you trigger on the requested file and device and then you can just use a userspace script or binary to actually provide that file. That would probably work best here as I dont know if upstream will accept adding a base64 method just for one or 2 devices. Regards, Robert > > Brian > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 5/8] ipq8064: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
On Thu, 5 Jan 2023 at 04:02, Brian Norris wrote: > > Hi Christian, Robert, > > On Wed, Jan 04, 2023 at 02:30:23PM +0100, Robert Marko wrote: > > On Wed, 4 Jan 2023 at 14:04, Christian Marangi wrote: > > > > > > On Mon, Jan 02, 2023 at 03:25:31PM -0800, Brian Norris wrote: > > > > This fixes device tree registration for 'qcom,lpass-cpu' as used by > > > > qcom-ipq8064 SoCs, and allows speaker audio to function. > > > > > > > > This patch has been submitted (and merged, for -next) upstream. > > > > > > Considering it's tagged for stable and assuming it will be part of 6.2 > > > wonder if it's a good idea to add the kernel tag to better track this? > > I first wrote this when I had just posted the patch; didn't expect it to > land so quickly! > > But what do you mean: just tweak the commit title to 'kernel: ...'? Or > move this to the generic kernel patches > (target/linux/generic/backport-5.15/)? No need for generic as its cleary QCA related, he means to add the kernel version it will be available in after number, so lets say 024-v6.2-whatever.patch > > > Also, the 900 prefix isn't really meant for backports. > > Ack. I only just noticed target/linux/generic/PATCHES. So I guess that's > one of these? > > 0xx - upstream backports > 1xx - code awaiting upstream merge > > Thanks, > Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/8] ipq806x: config-5.15: Normalize
On Wed, 4 Jan 2023 at 14:21, Christian Marangi wrote: > > On Mon, Jan 02, 2023 at 03:25:29PM -0800, Brian Norris wrote: > > Normalize = `make kernel_menuconfig`, save. > > Better be less cryptic and use something like "Refresh target config > with make kernel_menuconfig, save" > > > > > Signed-off-by: Brian Norris > > --- > > > > target/linux/ipq806x/config-5.15 | 20 +++- > > 1 file changed, 11 insertions(+), 9 deletions(-) > > > > diff --git a/target/linux/ipq806x/config-5.15 > > b/target/linux/ipq806x/config-5.15 > > index 7ea97ff89ec3..5082bc840be3 100644 > > --- a/target/linux/ipq806x/config-5.15 > > +++ b/target/linux/ipq806x/config-5.15 > > @@ -34,13 +34,14 @@ CONFIG_ARM_CPU_SUSPEND=y > > # CONFIG_ARM_CPU_TOPOLOGY is not set > > CONFIG_ARM_GIC=y > > CONFIG_ARM_HAS_SG_CHAIN=y > > +# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set > > +# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set > > CONFIG_ARM_L1_CACHE_SHIFT=6 > > CONFIG_ARM_L1_CACHE_SHIFT_6=y > > CONFIG_ARM_MODULE_PLTS=y > > CONFIG_ARM_PATCH_IDIV=y > > CONFIG_ARM_PATCH_PHYS_VIRT=y > > # CONFIG_ARM_QCOM_CPUFREQ_HW is not set > > -CONFIG_ARM_QCOM_CPUFREQ_KRAIT=y Ansuel, is Krait CPUFreq not used anymore? Regards, Robert > > CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y > > CONFIG_ARM_QCOM_SPM_CPUIDLE=y > > # CONFIG_ARM_SMMU is not set > > @@ -98,13 +99,11 @@ CONFIG_CRC16=y > > # CONFIG_CRC32_SARWATE is not set > > CONFIG_CRC32_SLICEBY8=y > > CONFIG_CRC8=y > > -CONFIG_CRYPTO_BLAKE2S=y > > CONFIG_CRYPTO_DEFLATE=y > > CONFIG_CRYPTO_DEV_QCOM_RNG=y > > CONFIG_CRYPTO_DRBG=y > > CONFIG_CRYPTO_DRBG_HMAC=y > > CONFIG_CRYPTO_DRBG_MENU=y > > -CONFIG_CRYPTO_GF128MUL=y > > CONFIG_CRYPTO_HASH_INFO=y > > CONFIG_CRYPTO_HMAC=y > > CONFIG_CRYPTO_HW=y > > @@ -112,7 +111,6 @@ CONFIG_CRYPTO_JITTERENTROPY=y > > CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y > > CONFIG_CRYPTO_LIB_SHA256=y > > CONFIG_CRYPTO_LZO=y > > -CONFIG_CRYPTO_NULL2=y > > CONFIG_CRYPTO_RNG=y > > CONFIG_CRYPTO_RNG2=y > > CONFIG_CRYPTO_SHA256=y > > @@ -127,8 +125,6 @@ CONFIG_DEVFREQ_GOV_PASSIVE=y > > # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set > > # CONFIG_DEVFREQ_GOV_USERSPACE is not set > > # CONFIG_DEVFREQ_THERMAL is not set > > -# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set > > -# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set > > CONFIG_DMADEVICES=y > > CONFIG_DMA_ENGINE=y > > CONFIG_DMA_OF=y > > @@ -143,6 +139,7 @@ CONFIG_DWMAC_IPQ806X=y > > CONFIG_DYNAMIC_DEBUG=y > > CONFIG_EDAC_ATOMIC_SCRUB=y > > CONFIG_EDAC_SUPPORT=y > > +CONFIG_ETHERNET_PACKET_MANGLE=y > > CONFIG_FIXED_PHY=y > > CONFIG_FIX_EARLYCON_MEM=y > > CONFIG_FWNODE_MDIO=y > > @@ -152,10 +149,12 @@ CONFIG_GENERIC_BUG=y > > CONFIG_GENERIC_CLOCKEVENTS=y > > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > > CONFIG_GENERIC_CPU_AUTOPROBE=y > > +CONFIG_GENERIC_CPU_VULNERABILITIES=y > > CONFIG_GENERIC_EARLY_IOREMAP=y > > CONFIG_GENERIC_GETTIMEOFDAY=y > > CONFIG_GENERIC_IDLE_POLL_SETUP=y > > CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y > > +CONFIG_GENERIC_IRQ_MIGRATION=y > > CONFIG_GENERIC_IRQ_MULTI_HANDLER=y > > CONFIG_GENERIC_IRQ_SHOW=y > > CONFIG_GENERIC_IRQ_SHOW_LEVEL=y > > @@ -173,6 +172,7 @@ CONFIG_GENERIC_STRNCPY_FROM_USER=y > > CONFIG_GENERIC_STRNLEN_USER=y > > CONFIG_GENERIC_TIME_VSYSCALL=y > > CONFIG_GENERIC_VDSO_32=y > > +CONFIG_GLOB=y > > CONFIG_GPIOLIB_IRQCHIP=y > > CONFIG_GPIO_CDEV=y > > CONFIG_GRO_CELLS=y > > @@ -185,6 +185,7 @@ CONFIG_HAS_IOPORT_MAP=y > > CONFIG_HAVE_SMP=y > > CONFIG_HIGHMEM=y > > # CONFIG_HIGHPTE is not set > > +CONFIG_HOTPLUG_CPU=y > > CONFIG_HWMON=y > > CONFIG_HWSPINLOCK=y > > CONFIG_HWSPINLOCK_QCOM=y > > @@ -214,12 +215,12 @@ CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y > > CONFIG_IRQ_FORCED_THREADING=y > > CONFIG_IRQ_WORK=y > > CONFIG_KMAP_LOCAL=y > > +CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY=y > > CONFIG_KPSS_XCC=y > > CONFIG_KRAITCC=y > > CONFIG_KRAIT_CLOCKS=y > > CONFIG_KRAIT_L2_ACCESSORS=y > > CONFIG_LIBFDT=y > > -CONFIG_LLD_VERSION=0 > > CONFIG_LOCK_DEBUGGING_SUPPORT=y > > CONFIG_LOCK_SPIN_ON_OWNER=y > > CONFIG_LZO_COMPRESS=y > > @@ -299,6 +300,7 @@ CONFIG_NO_HZ_IDLE=y > > CONFIG_NR_CPUS=2 > > CONFIG_NVMEM=y > > # CONFIG_NVMEM_SPMI_SDAM is not set > > +CONFIG_NVMEM_SYSFS=y > > CONFIG_OF=y > > CONFIG_OF_ADDRESS=y > > CONFIG_OF_EARLY_FLATTREE=y > > @@ -307,7 +309,6 @@ CONFIG_OF_GPIO=y > > CONFIG_OF_IRQ=y > > CONFIG_OF_KOBJ=y > > CONFIG_OF_MDIO=y > > -CONFIG_OF_NET=y > > CONFIG_OLD_SIGACTION=y > > CONFIG_OLD_SIGSUSPEND3=y > > CONFIG_PADATA=y > > @@ -397,7 +398,7 @@ CONFIG_QCOM_SCM=y > > # CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is not set > > CONFIG_QCOM_SMEM=y > > # CONFIG_QCOM_SMSM is not set > > -# CONFIG_QCOM_SOCINFO is not set > > +CONFIG_QCOM_SOCINFO=y > > CONFIG_QCOM_TCSR=y > > CONFIG_QCOM_TSENS=y > > CONFIG_QCOM_WDT=y > > @@ -452,6 +453,7 @@ CONFIG_SMP_ON_UP=y > > # CONFIG_SM_VIDEOCC_8150 is not set > > # CONFIG_SM_VIDEOCC_8250 is not set > > CONFIG_SOCK_RX_QUEUE_MAPPING=y > > +CONFIG_SOC_BUS=y > > CONFIG_SPARSE_IRQ=y > > CONFIG_SPI=y >
Re: [PATCH 4/8] ipq806x: Enable CONFIG_IPQ_LCC_806X
On Wed, 4 Jan 2023 at 14:03, Christian Marangi wrote: > > On Mon, Jan 02, 2023 at 03:25:30PM -0800, Brian Norris wrote: > > Clock controller used by some IP blocks (e.g., LPASS / audio) on > > IPQ8064. > > Since this will be only for 2 target, should we consider introducing ko > for LPASS? They are not mandatory for boot so I think they should be > able to get loaded correctly as kmods. Yeah, just package it along the user kmod and include for devices that use it. Regards, Robert > > > > > Signed-off-by: Brian Norris > > --- > > > > target/linux/ipq806x/config-5.15 | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/target/linux/ipq806x/config-5.15 > > b/target/linux/ipq806x/config-5.15 > > index 5082bc840be3..31bb729c85e9 100644 > > --- a/target/linux/ipq806x/config-5.15 > > +++ b/target/linux/ipq806x/config-5.15 > > @@ -207,7 +207,7 @@ CONFIG_IOMMU_SUPPORT=y > > # CONFIG_IPQ_GCC_6018 is not set > > CONFIG_IPQ_GCC_806X=y > > # CONFIG_IPQ_GCC_8074 is not set > > -# CONFIG_IPQ_LCC_806X is not set > > +CONFIG_IPQ_LCC_806X=y > > CONFIG_IRQCHIP=y > > CONFIG_IRQ_DOMAIN=y > > CONFIG_IRQ_DOMAIN_HIERARCHY=y > > -- > > 2.39.0 > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > -- > 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: [PATCH 6/8] kernel: Add kmod-sound-soc-ipq8064-storm
On Wed, 4 Jan 2023 at 14:24, Christian Marangi wrote: > > On Mon, Jan 02, 2023 at 03:25:32PM -0800, Brian Norris wrote: > > For IPQ8064 systems based off the "Google Storm" reference platform, > > such as the TP-Link OnHub. > > As this is really ipq806x specific, instead of bloating the kernel/linux > mk a better approach is to create some .mk specific for the target... We > should have some example with other target with mvebu I think. > > With this approach we should be able to also add the LPASS module in > this target specific mk bcm27xx uses in-target module definitions extensively. It makes sense to package the LCC clock and this inside of the target itself as its not reusable for other targets. Regards, Robert > > > > > Signed-off-by: Brian Norris > > --- > > > > package/kernel/linux/modules/sound.mk | 24 > > target/linux/generic/config-5.10 | 3 +++ > > target/linux/generic/config-5.15 | 3 +++ > > 3 files changed, 30 insertions(+) > > > > diff --git a/package/kernel/linux/modules/sound.mk > > b/package/kernel/linux/modules/sound.mk > > index 2bfa146207aa..92ad8bceed9b 100644 > > --- a/package/kernel/linux/modules/sound.mk > > +++ b/package/kernel/linux/modules/sound.mk > > @@ -254,6 +254,30 @@ endef > > $(eval $(call KernelPackage,sound-soc-imx-sgtl5000)) > > > > > > +define KernelPackage/sound-soc-ipq8064-storm > > + TITLE:=Qualcomm IPQ8064 SoC support for Google Storm > > + KCONFIG:=\ > > + CONFIG_SND_SOC_QCOM \ > > + CONFIG_SND_SOC_STORM > > + FILES:=\ > > + $(LINUX_DIR)/sound/soc/codecs/snd-soc-max98357a.ko \ > > + $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-cpu.ko \ > > + $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-ipq806x.ko \ > > + $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-platform.ko \ > > + $(LINUX_DIR)/sound/soc/qcom/snd-soc-storm.ko > > + AUTOLOAD:=$(call AutoLoad,57,snd-soc-max98357a snd-soc-lpass-cpu \ > > + snd-soc-lpass-ipq806x snd-soc-lpass-platform snd-soc-storm) > > + DEPENDS:=@TARGET_ipq806x +kmod-sound-soc-core > > + $(call AddDepends/sound) > > +endef > > + > > +define KernelPackage/sound-soc-ipq8064-storm/description > > + Support for Qualcomm IPQ8064 / Google Storm Platform sound > > +endef > > + > > +$(eval $(call KernelPackage,sound-soc-ipq8064-storm)) > > + > > + > > define KernelPackage/sound-soc-spdif > >TITLE:=SoC S/PDIF codec support > >KCONFIG:=CONFIG_SND_SOC_SPDIF > > diff --git a/target/linux/generic/config-5.10 > > b/target/linux/generic/config-5.10 > > index a2dc9b90b1fc..324401244155 100644 > > --- a/target/linux/generic/config-5.10 > > +++ b/target/linux/generic/config-5.10 > > @@ -5649,6 +5649,7 @@ CONFIG_SND_PROC_FS=y > > # CONFIG_SND_SOC_AMD_ACP is not set > > # CONFIG_SND_SOC_AMD_ACP3x is not set > > # CONFIG_SND_SOC_AMD_RENOIR is not set > > +# CONFIG_SND_SOC_APQ8016_SBC is not set > > # CONFIG_SND_SOC_AU1XAUDIO is not set > > # CONFIG_SND_SOC_AU1XPSC is not set > > # CONFIG_SND_SOC_BD28623 is not set > > @@ -5786,6 +5787,7 @@ CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y > > # CONFIG_SND_SOC_RT5616 is not set > > # CONFIG_SND_SOC_RT5631 is not set > > # CONFIG_SND_SOC_RT5677_SPI is not set > > +# CONFIG_SND_SOC_SC7180 is not set > > # CONFIG_SND_SOC_SGTL5000 is not set > > # CONFIG_SND_SOC_SIMPLE_AMPLIFIER is not set > > # CONFIG_SND_SOC_SIRF_AUDIO_CODEC is not set > > @@ -5795,6 +5797,7 @@ CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y > > # CONFIG_SND_SOC_SSM2602_I2C is not set > > # CONFIG_SND_SOC_SSM2602_SPI is not set > > # CONFIG_SND_SOC_SSM4567 is not set > > +# CONFIG_SND_SOC_STORM is not set > > # CONFIG_SND_SOC_STA32X is not set > > # CONFIG_SND_SOC_STA350 is not set > > # CONFIG_SND_SOC_STI_SAS is not set > > diff --git a/target/linux/generic/config-5.15 > > b/target/linux/generic/config-5.15 > > index df9755b19e68..5ccc1dc41594 100644 > > --- a/target/linux/generic/config-5.15 > > +++ b/target/linux/generic/config-5.15 > > @@ -5940,6 +5940,7 @@ CONFIG_SND_PROC_FS=y > > # CONFIG_SND_SOC_AMD_ACP3x is not set > > # CONFIG_SND_SOC_AMD_ACP5x is not set > > # CONFIG_SND_SOC_AMD_RENOIR is not set > > +# CONFIG_SND_SOC_APQ8016_SBC is not set > > # CONFIG_SND_SOC_AU1XAUDIO is not set > > # CONFIG_SND_SOC_AU1XPSC is not set > > # CONFIG_SND_SOC_BD28623 is not set > > @@ -6097,6 +6098,7 @@ CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y > > # CONFIG_SND_SOC_RT5640 is not set > > # CONFIG_SND_SOC_RT5659 is not set > > # CONFIG_SND_SOC_RT5677_SPI is not set > > +# CONFIG_SND_SOC_SC7180 is not set > > # CONFIG_SND_SOC_SGTL5000 is not set > > # CONFIG_SND_SOC_SIMPLE_AMPLIFIER is not set > > # CONFIG_SND_SOC_SIMPLE_MUX is not set > > @@ -6111,6 +6113,7 @@ CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y > > # CONFIG_SND_SOC_STA32X is not set > > # CONFIG_SND_SOC_STA350 is not set > > # CONFIG_SND_SOC_STI_SAS is not set > > +# CONFIG_SND_SOC_STORM is not set > > # CONFIG_SND_SOC_TAS2552 is not set > > # CONFIG_SND_SOC_TAS2562 is not set > > # CONFIG_SND_SOC_TAS2764 is not set > >
Re: [PATCH 3/8] ipq806x: config-5.15: Normalize
On Wed, 4 Jan 2023 at 14:30, Christian Marangi wrote: > > On Wed, Jan 04, 2023 at 02:28:19PM +0100, Robert Marko wrote: > > On Wed, 4 Jan 2023 at 14:21, Christian Marangi wrote: > > > > > > On Mon, Jan 02, 2023 at 03:25:29PM -0800, Brian Norris wrote: > > > > Normalize = `make kernel_menuconfig`, save. > > > > > > Better be less cryptic and use something like "Refresh target config > > > with make kernel_menuconfig, save" > > > > > > > > > > > Signed-off-by: Brian Norris > > > > --- > > > > > > > > target/linux/ipq806x/config-5.15 | 20 +++- > > > > 1 file changed, 11 insertions(+), 9 deletions(-) > > > > > > > > diff --git a/target/linux/ipq806x/config-5.15 > > > > b/target/linux/ipq806x/config-5.15 > > > > index 7ea97ff89ec3..5082bc840be3 100644 > > > > --- a/target/linux/ipq806x/config-5.15 > > > > +++ b/target/linux/ipq806x/config-5.15 > > > > @@ -34,13 +34,14 @@ CONFIG_ARM_CPU_SUSPEND=y > > > > # CONFIG_ARM_CPU_TOPOLOGY is not set > > > > CONFIG_ARM_GIC=y > > > > CONFIG_ARM_HAS_SG_CHAIN=y > > > > +# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set > > > > +# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set > > > > CONFIG_ARM_L1_CACHE_SHIFT=6 > > > > CONFIG_ARM_L1_CACHE_SHIFT_6=y > > > > CONFIG_ARM_MODULE_PLTS=y > > > > CONFIG_ARM_PATCH_IDIV=y > > > > CONFIG_ARM_PATCH_PHYS_VIRT=y > > > > # CONFIG_ARM_QCOM_CPUFREQ_HW is not set > > > > -CONFIG_ARM_QCOM_CPUFREQ_KRAIT=y > > > > Ansuel, is Krait CPUFreq not used anymore? > > > > We switched to cpufreq-dt + devfreq driver to scale cache. Currently > this is disabled as it does cause instability as I still have to > understand what is wrong in the cache freq. Ideally this should be what > will be pushed upstream. Thanks for clarifiying. Regards, Robert > > > > > > > CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y > > > > CONFIG_ARM_QCOM_SPM_CPUIDLE=y > > > > # CONFIG_ARM_SMMU is not set > > > > @@ -98,13 +99,11 @@ CONFIG_CRC16=y > > > > # CONFIG_CRC32_SARWATE is not set > > > > CONFIG_CRC32_SLICEBY8=y > > > > CONFIG_CRC8=y > > > > -CONFIG_CRYPTO_BLAKE2S=y > > > > CONFIG_CRYPTO_DEFLATE=y > > > > CONFIG_CRYPTO_DEV_QCOM_RNG=y > > > > CONFIG_CRYPTO_DRBG=y > > > > CONFIG_CRYPTO_DRBG_HMAC=y > > > > CONFIG_CRYPTO_DRBG_MENU=y > > > > -CONFIG_CRYPTO_GF128MUL=y > > > > CONFIG_CRYPTO_HASH_INFO=y > > > > CONFIG_CRYPTO_HMAC=y > > > > CONFIG_CRYPTO_HW=y > > > > @@ -112,7 +111,6 @@ CONFIG_CRYPTO_JITTERENTROPY=y > > > > CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y > > > > CONFIG_CRYPTO_LIB_SHA256=y > > > > CONFIG_CRYPTO_LZO=y > > > > -CONFIG_CRYPTO_NULL2=y > > > > CONFIG_CRYPTO_RNG=y > > > > CONFIG_CRYPTO_RNG2=y > > > > CONFIG_CRYPTO_SHA256=y > > > > @@ -127,8 +125,6 @@ CONFIG_DEVFREQ_GOV_PASSIVE=y > > > > # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set > > > > # CONFIG_DEVFREQ_GOV_USERSPACE is not set > > > > # CONFIG_DEVFREQ_THERMAL is not set > > > > -# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set > > > > -# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set > > > > CONFIG_DMADEVICES=y > > > > CONFIG_DMA_ENGINE=y > > > > CONFIG_DMA_OF=y > > > > @@ -143,6 +139,7 @@ CONFIG_DWMAC_IPQ806X=y > > > > CONFIG_DYNAMIC_DEBUG=y > > > > CONFIG_EDAC_ATOMIC_SCRUB=y > > > > CONFIG_EDAC_SUPPORT=y > > > > +CONFIG_ETHERNET_PACKET_MANGLE=y > > > > CONFIG_FIXED_PHY=y > > > > CONFIG_FIX_EARLYCON_MEM=y > > > > CONFIG_FWNODE_MDIO=y > > > > @@ -152,10 +149,12 @@ CONFIG_GENERIC_BUG=y > > > > CONFIG_GENERIC_CLOCKEVENTS=y > > > > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > > > > CONFIG_GENERIC_CPU_AUTOPROBE=y > > > > +CONFIG_GENERIC_CPU_VULNERABILITIES=y > > > > CONFIG_GENERIC_EARLY_IOREMAP=y > > > > CONFIG_GENERIC_GETTIMEOFDAY=y > > > > CONFIG_GENERIC_IDLE_POLL_SETUP=y > > > > CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y > > > > +CONFIG_GENERIC_IRQ_MIGRATION=y > > > > CONFIG_GENERIC_IRQ_MULTI_HANDLER=y > > > > CONFIG_GENERIC_IRQ_SHOW=y > > > > CONFIG_GENERIC_IRQ_SHOW_LEVEL=y > > > > @@ -173,6 +
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
On Tue, 3 Jan 2023 at 00:30, Brian Norris wrote:
>
> See the patch notes about the stock firmware for TP-Link Onhub and
> https://chromium-review.googlesource.com/243115.
>
> As noted there, the production firmware for Google OnHub devices only
> provide the *-base64 Device Tree property, and so either the kernel or
> some user space mechanism needs to know how to parse/convert this
> property.
>
> I haven't submitted this patch upstream. However, it applies relatively
> cleanly to the tree even after almost 8 years, so it doesn't seem too
> hard to maintain.
This should be sent upstream, otherwise its gonna be left downstream forever.
Regards,
Robert
>
> Signed-off-by: Brian Norris
> ---
>
> .../970-ath10k-calibration-base64.patch | 249 ++
> 1 file changed, 249 insertions(+)
> create mode 100644
> package/kernel/ath10k-ct/patches/970-ath10k-calibration-base64.patch
>
> diff --git
> a/package/kernel/ath10k-ct/patches/970-ath10k-calibration-base64.patch
> b/package/kernel/ath10k-ct/patches/970-ath10k-calibration-base64.patch
> new file mode 100644
> index ..739bdee9ccf4
> --- /dev/null
> +++ b/package/kernel/ath10k-ct/patches/970-ath10k-calibration-base64.patch
> @@ -0,0 +1,249 @@
> +Adapted from:
> +https://chromium-review.googlesource.com/307062
> +
> +This "hack" remained in the production kernel, and so the production firmware
> +for Google OnHub still only knows how to patch the *-base64 Device Tree
> +property.
> +
> +CHROMIUM: HACK: ath10k: read calibration data in base64 format from DT
> +
> + Chrome OS firmware doesn't support binary format in VPD currently.
> + As a workaround, the firmware stores the calibration data in base64
> + format in the same node with the different name:
> +
> + qcom,ath10k-calibration-data-base64 = [ 01 02 03 ... ];
> +
> + Since the original property "qcom,ath10k-calibration-data" is always
> + looked for first, it should have an invalid size (e.g. 1).
> +
> + BUG=chrome-os-partner:35262
> + TEST=build/boot on storm suceeded. Setup Storm board as AP using
> + hostapd and
> + connected to the board using another device. Device was able to
> + connect to
> + the internet and load multiple websites.
> +
> + Change-Id: I95675a803fad3b94977ecd0977bd9980779ad7e9
> + Signed-off-by: Toshi Kikuchi
> + Reviewed-on: https://chromium-review.googlesource.com/243115
> + Reviewed-by: Grant Grundler
> +
> +Change-Id: I17874f0ed03e28d279b08fe70aca70af57c90bda
> +Signed-off-by: Anilkumar Kolli
> +Reviewed-on: https://chromium-review.googlesource.com/307062
> +Commit-Ready: Grant Grundler
> +Tested-by: Grant Grundler
> +Reviewed-by: Srinivasa duvvuri
> +Reviewed-by: Grant Grundler
> +--- a/ath10k-5.15/Makefile
> b/ath10k-5.15/Makefile
> +@@ -4,6 +4,7 @@ ath10k_core-y += mac.o \
> +debug.o \
> +core.o \
> +coredump.o \
> ++ decode64.o \
> +htc.o \
> +htt.o \
> +htt_rx.o \
> +--- a/ath10k-5.15/core.c
> b/ath10k-5.15/core.c
> +@@ -18,6 +18,7 @@
> + #include
> +
> + #include "core.h"
> ++#include "decode64.h"
> + #include "mac.h"
> + #include "htc.h"
> + #include "hif.h"
> +@@ -2167,6 +2168,73 @@ static int ath10k_download_cal_file(stru
> + return 0;
> + }
> +
> ++static int ath10k_download_cal_dt_base64(struct ath10k *ar)
> ++{
> ++ struct device_node *node;
> ++ int data_len;
> ++ void *data;
> ++ int ret;
> ++
> ++ node = ar->dev->of_node;
> ++ if (!node)
> ++ /* Device Tree is optional, don't print any warnings if
> ++ * there's no node for ath10k.
> ++ */
> ++ return -ENOENT;
> ++
> ++ if (!of_get_property(node, "qcom,ath10k-calibration-data-base64",
> ++ _len)) {
> ++ /* The calibration data node is optional */
> ++ return -ENOENT;
> ++ }
> ++
> ++ data = kmalloc(data_len, GFP_KERNEL);
> ++ if (!data) {
> ++ ret = -ENOMEM;
> ++ goto out;
> ++ }
> ++
> ++ ret = of_property_read_u8_array(node,
> ++ "qcom,ath10k-calibration-data-base64",
> ++ data, data_len);
> ++ if (ret) {
> ++ ath10k_warn(ar,
> ++ "failed to read calibration data (base64) from DT: %d\n",
> ++ ret);
> ++ goto out_free;
> ++ }
> ++
> ++ data_len = strip_nl(data, data + data_len, data);
> ++ data_len = decode64(data, data + data_len, data);
> ++ if (data_len < 0) {
> ++ ath10k_warn(ar,
> ++ "base64 decoder found invalid input\n");
> ++ ret = -EINVAL;
> ++ goto out_free;
> ++ }
> ++
> ++ if (data_len != ar->hw_params.cal_data_len) {
> ++ ath10k_warn(ar, "invalid calibration data length
Re: [PATCH 5/8] ipq8064: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
On Wed, 4 Jan 2023 at 14:04, Christian Marangi wrote:
>
> On Mon, Jan 02, 2023 at 03:25:31PM -0800, Brian Norris wrote:
> > This fixes device tree registration for 'qcom,lpass-cpu' as used by
> > qcom-ipq8064 SoCs, and allows speaker audio to function.
> >
> > This patch has been submitted (and merged, for -next) upstream.
>
> Considering it's tagged for stable and assuming it will be part of 6.2
> wonder if it's a good idea to add the kernel tag to better track this?
Also, the 900 prefix isn't really meant for backports.
Regards,
Robert
>
> >
> > Signed-off-by: Brian Norris
> > ---
> >
> > ...cpu-Fix-fallback-SD-line-index-handl.patch | 39 +++
> > 1 file changed, 39 insertions(+)
> > create mode 100644
> > target/linux/ipq806x/patches-5.15/902-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
> >
> > diff --git
> > a/target/linux/ipq806x/patches-5.15/902-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
> >
> > b/target/linux/ipq806x/patches-5.15/902-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
> > new file mode 100644
> > index ..0bdab5dc62a5
> > --- /dev/null
> > +++
> > b/target/linux/ipq806x/patches-5.15/902-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
> > @@ -0,0 +1,39 @@
> > +From: Brian Norris
> > +Date: Thu, 15 Dec 2022 01:33:45 -0800
> > +Subject: [PATCH] ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
> > +
> > +[[ Submitted upstream as:
> > +
> > https://lore.kernel.org/all/20221231061545.2110253-1-computersforpe...@gmail.com/
> > ]]
> > +
> > +These indices should reference the ID placed within the dai_driver
> > +array, not the indices of the array itself.
> > +
> > +This fixes commit 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD
> > +lines configurable"), which among others, broke IPQ8064 audio
> > +(sound/soc/qcom/lpass-ipq806x.c) because it uses ID 4 but we'd stop
> > +initializing the mi2s_playback_sd_mode and mi2s_capture_sd_mode arrays
> > +at ID 0.
> > +
> > +Fixes: 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD lines
> > configurable")
> > +Cc:
> > +Signed-off-by: Brian Norris
> > +---
> > + sound/soc/qcom/lpass-cpu.c | 5 +++--
> > + 1 file changed, 3 insertions(+), 2 deletions(-)
> > +
> > +--- a/sound/soc/qcom/lpass-cpu.c
> > b/sound/soc/qcom/lpass-cpu.c
> > +@@ -851,10 +851,11 @@ static void of_lpass_cpu_parse_dai_data(
> > + struct lpass_data *data)
> > + {
> > + struct device_node *node;
> > +-int ret, id;
> > ++int ret, i, id;
> > +
> > + /* Allow all channels by default for backwards compatibility */
> > +-for (id = 0; id < data->variant->num_dai; id++) {
> > ++for (i = 0; i < data->variant->num_dai; i++) {
> > ++id = data->variant->dai_driver[i].id;
> > + data->mi2s_playback_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
> > + data->mi2s_capture_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
> > + }
> > --
> > 2.39.0
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> --
> 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: Updating env/kernel-config after rebasing/kernel version bump
On Wed, 28 Dec 2022 at 21:21, Philip Prindeville
wrote:
>
>
>
> > On Dec 28, 2022, at 1:14 PM, Robert Marko wrote:
> >
> > On Wed, 28 Dec 2022 at 01:01, Philip Prindeville
> > wrote:
> >>
> >>
> >>
> >>> On Dec 27, 2022, at 4:50 PM, Robert Marko wrote:
> >>>
> >>> On Wed, 28 Dec 2022 at 00:48, Philip Prindeville
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I originally set up my env/kernel-config a long time ago (like 2018) by
> >>>> hand, and since then the kernel has gone through several bumps. How do
> >>>> I easily refresh it to pick up new stuff from
> >>>> target/linux/x86/64/config-${KVER} (where KVER=5.15 currently)? Is
> >>>> there a handy script or make target to do this?
> >>>
> >>> There is make kernel_menuconfig that will essentially give you the
> >>> kernel menuconfig and refresh the config after saving.
> >>
> >>
> >> Right, but what does that involve? Will it pick up new symbols from the
> >> new kernel target? If there's a new default in 5.15 that wasn't in 5.10,
> >> how does it find its way into my config?
> >>
> >> I tried diffing target/linux/x86/64/config-5.15 and env/kernel-config and
> >> there's a whole lot of changes.
> >>
> >> Or is env/kernel-config the delta from the defaults for any given kernel
> >> version in config-${KVER}?
> >
> > I have to admit that I have not used the env script so far, so I dont
> > know how it works.
> >
> > Regards,
> > Robert
>
>
> I'd like to see something like scripts/diffconfig.sh done for the
> kernel-config ...
>
> How are the files in target/linux/ combined to generate default state in the
> absence of kernel-config, anyway?
Unfortunately, I am not familiar with this, have you try asking on the
IRC, somebody ought to know.
Regards,
Robert
>
> Thanks
>
>
> >>
> >>
> >>>
> >>> Regards,
> >>> Robert
> >>>>
> >>>> Thanks,
> >>>>
> >>>> -Philip
> >>>>
> >>>>
> >>>> ___
> >>>> openwrt-devel mailing list
> >>>> openwrt-devel@lists.openwrt.org
> >>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] sunxi: enable CONFIG_NVMEM_SYSFS
On Fri, 30 Dec 2022 at 03:41, Jan-Niklas Burfeind wrote: > > in both the stable and the testing kernel > > h2+/h3/h5 devices have a Secure ID that can be read from > `/sys/bus/nvmem/devices/sunxi-sid0/nvmem`. > Enabling CONFIG_NVMEM_SYSFS grants sysfs access from userspace. > > Signed-off-by: Jan-Niklas Burfeind > --- > Hauke suggested enabling it for the whole sunxi target, as all devices > either have enough onboard or external memory to cope with the > additional 5KB. > > @robimarko > I split off the the changes into two commits which can be found here: > https://github.com/openwrt/openwrt/compare/master...AiyionPrime:openwrt:sunxi-nvmem_sysfs > > I've left the first commit including all unrelated kernel settings aside, > due to build failures. Something is rather broken in your build environment to get that diff, I just tried refreshing sunxi generic config and A7 config and the diff is minimal and it builds fine: diff --git a/target/linux/sunxi/config-5.10 b/target/linux/sunxi/config-5.10 index caac9e1436..4ce089b53c 100644 --- a/target/linux/sunxi/config-5.10 +++ b/target/linux/sunxi/config-5.10 @@ -113,6 +113,7 @@ CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG=y # CONFIG_CRYPTO_DEV_SUN8I_CE is not set # CONFIG_CRYPTO_DEV_SUN8I_SS is not set CONFIG_CRYPTO_HW=y +CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y CONFIG_CRYPTO_LIB_DES=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_RNG=y @@ -177,6 +178,7 @@ CONFIG_GENERIC_BUG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CPU_AUTOPROBE=y +CONFIG_GENERIC_CPU_VULNERABILITIES=y CONFIG_GENERIC_EARLY_IOREMAP=y CONFIG_GENERIC_GETTIMEOFDAY=y CONFIG_GENERIC_IDLE_POLL_SETUP=y @@ -385,8 +387,6 @@ CONFIG_RESET_SUNXI=y CONFIG_RFS_ACCEL=y CONFIG_RPS=y CONFIG_RWSEM_SPIN_ON_OWNER=y -CONFIG_SATA_HOST=y -CONFIG_SATA_PMP=y CONFIG_SCSI=y CONFIG_SDIO_UART=y CONFIG_SECURITYFS=y @@ -495,8 +495,6 @@ CONFIG_VFPv3=y CONFIG_VHOST=y CONFIG_VHOST_IOTLB=y CONFIG_VHOST_NET=y -# CONFIG_VIDEO_SUN4I_CSI is not set -# CONFIG_VIDEO_SUN6I_CSI is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_VT=y CONFIG_VT_CONSOLE=y diff --git a/target/linux/sunxi/cortexa7/config-5.10 b/target/linux/sunxi/cortexa7/config-5.10 index 90e977b566..553770d6ba 100644 --- a/target/linux/sunxi/cortexa7/config-5.10 +++ b/target/linux/sunxi/cortexa7/config-5.10 @@ -1,7 +1,6 @@ CONFIG_B53=y CONFIG_B53_MDIO_DRIVER=y CONFIG_CRYPTO_BLAKE2S=y -CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y CONFIG_DWMAC_SUN8I=y CONFIG_GRO_CELLS=y # CONFIG_MACH_SUN4I is not set @@ -17,7 +16,6 @@ CONFIG_NET_DSA_TAG_BRCM_LEGACY=y CONFIG_NET_DSA_TAG_BRCM_PREPEND=y CONFIG_NET_SWITCHDEV=y CONFIG_NOP_USB_XCEIV=y -CONFIG_RTC_DRV_SUN6I=y CONFIG_USB_MUSB_DUAL_ROLE=y # CONFIG_USB_MUSB_GADGET is not set CONFIG_USB_MUSB_HDRC=y Regards, Robert > > It works as expected, tested on a NanoPi R1. > Path exists and is readable. > Thanks again for all the help, I hope this is done correctly. > > Jan-Niklas > > target/linux/sunxi/config-5.10 | 1 + > target/linux/sunxi/config-5.15 | 1 + > target/linux/sunxi/cortexa53/config-5.15 | 1 - > 3 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/target/linux/sunxi/config-5.10 b/target/linux/sunxi/config-5.10 > index caac9e1436..84645141fb 100644 > --- a/target/linux/sunxi/config-5.10 > +++ b/target/linux/sunxi/config-5.10 > @@ -301,6 +301,7 @@ CONFIG_NO_HZ_IDLE=y > CONFIG_NR_CPUS=8 > CONFIG_NVMEM=y > CONFIG_NVMEM_SUNXI_SID=y > +CONFIG_NVMEM_SYSFS=y > CONFIG_OF=y > CONFIG_OF_ADDRESS=y > CONFIG_OF_EARLY_FLATTREE=y > diff --git a/target/linux/sunxi/config-5.15 b/target/linux/sunxi/config-5.15 > index c7dbc5a9f1..17c4d910c8 100644 > --- a/target/linux/sunxi/config-5.15 > +++ b/target/linux/sunxi/config-5.15 > @@ -307,6 +307,7 @@ CONFIG_NO_HZ_IDLE=y > CONFIG_NR_CPUS=8 > CONFIG_NVMEM=y > CONFIG_NVMEM_SUNXI_SID=y > +CONFIG_NVMEM_SYSFS=y > CONFIG_OF=y > CONFIG_OF_ADDRESS=y > CONFIG_OF_EARLY_FLATTREE=y > diff --git a/target/linux/sunxi/cortexa53/config-5.15 > b/target/linux/sunxi/cortexa53/config-5.15 > index b93abf0765..85ace5d928 100644 > --- a/target/linux/sunxi/cortexa53/config-5.15 > +++ b/target/linux/sunxi/cortexa53/config-5.15 > @@ -52,7 +52,6 @@ CONFIG_MUSB_PIO_ONLY=y > CONFIG_NEED_SG_DMA_LENGTH=y > CONFIG_NOP_USB_XCEIV=y > CONFIG_NO_IOPORT_MAP=y > -CONFIG_NVMEM_SYSFS=y > CONFIG_PARTITION_PERCPU=y > CONFIG_PHY_SUN50I_USB3=y > CONFIG_PINCTRL_SUN50I_A100=y > -- > 2.39.0 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] archs38: mark as source-only
On Thu, 29 Dec 2022 at 23:28, Rosen Penev wrote: > > On Thu, Dec 29, 2022 at 10:52 AM Robert Marko wrote: > > > > archs38 seems to be pretty much unused, usually only treewide changes or > > kernel bumps in order to branch off new stable are done to it. > > > > Considering that target only support some Synopsis HS38 ARC reference > > boards and no consumer hardware so mark the target as source-only to stop > > using Buildbot resources on building the target and packages for it. > One benefit of building archs38 is that it's glibc, which is somewhat > supported with OpenWrt. We discussed this on the IRC with Hauke and others, and it would be more beneficial to have an x86 glibc target. That unlike archs38 would probably have an active user-base, cause currently other than making sure it compiles archs38 doesnt really provide any feedback on whether glibc actually works as expected. Regards, Robert > > > > Signed-off-by: Robert Marko > > --- > > target/linux/archs38/Makefile | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/target/linux/archs38/Makefile b/target/linux/archs38/Makefile > > index e08f779170..756de43561 100644 > > --- a/target/linux/archs38/Makefile > > +++ b/target/linux/archs38/Makefile > > @@ -8,6 +8,7 @@ ARCH:=arc > > CPU_TYPE:=archs > > BOARD:=archs38 > > BOARDNAME:=Synopsys DesignWare ARC HS38 > > +FEATURES:=source-only > > SUBTARGETS:=generic > > > > KERNEL_PATCHVER:=5.10 > > -- > > 2.38.1 > > > > > > ___ > > 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
[PATCH] archs38: mark as source-only
archs38 seems to be pretty much unused, usually only treewide changes or kernel bumps in order to branch off new stable are done to it. Considering that target only support some Synopsis HS38 ARC reference boards and no consumer hardware so mark the target as source-only to stop using Buildbot resources on building the target and packages for it. Signed-off-by: Robert Marko --- target/linux/archs38/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/archs38/Makefile b/target/linux/archs38/Makefile index e08f779170..756de43561 100644 --- a/target/linux/archs38/Makefile +++ b/target/linux/archs38/Makefile @@ -8,6 +8,7 @@ ARCH:=arc CPU_TYPE:=archs BOARD:=archs38 BOARDNAME:=Synopsys DesignWare ARC HS38 +FEATURES:=source-only SUBTARGETS:=generic KERNEL_PATCHVER:=5.10 -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Updating env/kernel-config after rebasing/kernel version bump
On Wed, 28 Dec 2022 at 01:01, Philip Prindeville
wrote:
>
>
>
> > On Dec 27, 2022, at 4:50 PM, Robert Marko wrote:
> >
> > On Wed, 28 Dec 2022 at 00:48, Philip Prindeville
> > wrote:
> >>
> >> Hi,
> >>
> >> I originally set up my env/kernel-config a long time ago (like 2018) by
> >> hand, and since then the kernel has gone through several bumps. How do I
> >> easily refresh it to pick up new stuff from
> >> target/linux/x86/64/config-${KVER} (where KVER=5.15 currently)? Is there
> >> a handy script or make target to do this?
> >
> > There is make kernel_menuconfig that will essentially give you the
> > kernel menuconfig and refresh the config after saving.
>
>
> Right, but what does that involve? Will it pick up new symbols from the new
> kernel target? If there's a new default in 5.15 that wasn't in 5.10, how
> does it find its way into my config?
>
> I tried diffing target/linux/x86/64/config-5.15 and env/kernel-config and
> there's a whole lot of changes.
>
> Or is env/kernel-config the delta from the defaults for any given kernel
> version in config-${KVER}?
I have to admit that I have not used the env script so far, so I dont
know how it works.
Regards,
Robert
>
>
> >
> > Regards,
> > Robert
> >>
> >> Thanks,
> >>
> >> -Philip
> >>
> >>
> >> ___
> >> 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: Updating env/kernel-config after rebasing/kernel version bump
On Wed, 28 Dec 2022 at 00:48, Philip Prindeville
wrote:
>
> Hi,
>
> I originally set up my env/kernel-config a long time ago (like 2018) by hand,
> and since then the kernel has gone through several bumps. How do I easily
> refresh it to pick up new stuff from target/linux/x86/64/config-${KVER}
> (where KVER=5.15 currently)? Is there a handy script or make target to do
> this?
There is make kernel_menuconfig that will essentially give you the
kernel menuconfig and refresh the config after saving.
Regards,
Robert
>
> Thanks,
>
> -Philip
>
>
> ___
> 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: Ethernet switch with linux/openwrt and DSA
On Wed, 14 Dec 2022 at 18:16, Janusz Dziedzic wrote: > > śr., 14 gru 2022 o 12:59 Janusz Dziedzic > napisał(a): > > > > wt., 13 gru 2022 o 14:20 Daniel Golle napisał(a): > > > > > > On Tue, Dec 13, 2022 at 11:17:49AM +0100, Janusz Dziedzic wrote: > > > > Hello, > > > > > > > > Do you know any/some ethernet switch project (best 18+ gbps ports) > > > > that using linux/openwrt and DSA architecture? > > > > > > Some switches with high port density currently supported by OpenWrt: > > > * TP-Link SG2452P > > > * ZyXEL GS1900-48 > > > * Panasonic Switch-M48eG PN28480K > > > > > > All of the above are using RealTek RTL839x platform. > > > > > > > Could I just buy (any experience): > > > > HP switch 1920-24G JG924A > > Do I need to check any HW ver? Or any JG924A should work? > > > Or > > D-Link DGS-1210-48 HW Ver. G1 - will be fine? I need some confirmation. > Anyone could confirm? F1 and F2 revisions are RTL, but not idea about Gx. Regards, Robert > > BR > Janusz > > ___ > 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: Ethernet switch with linux/openwrt and DSA
On Tue, 13 Dec 2022 at 11:18, Janusz Dziedzic wrote: > > Hello, > > Do you know any/some ethernet switch project (best 18+ gbps ports) > that using linux/openwrt and DSA architecture? Check out the Realtek target in OpenWrt. Regards, Robert > > BR > Janusz > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 22.03] mvebu: cortexa9: disable devices using broken mv88e6176 switch
On Thu, 1 Dec 2022 at 14:43, Christian Marangi wrote: > > On Thu, Dec 01, 2022 at 02:39:56PM +0100, Robert Marko wrote: > > On Thu, 1 Dec 2022 at 14:34, Christian Marangi wrote: > > > > > > On Thu, Dec 01, 2022 at 02:23:08PM +0100, Josef Schlehofer wrote: > > > > On 01. 12. 22 14:19, Bjørn Mork wrote: > > > > > > > > > I assume KERNEL_PATCHVER in target/linux/mvebu/Makefile will be fixed > > > > > in > > > > > master as well, given that 5.10 is unsupportable on this target? > > > > > > > > > AFAIK What should be done is to put the kernel 5.15 as the default > > > > kernel > > > > for mvebu. Currently, it is only as the testing kernel. > > > > > > > > > > My 2 cent on this... A kernel upgrade is not viable for a stable > > > release. The problem here is simple... > > > > > > Things related to VLAN are broken in 5.10 and got fixed in 5.15. DSA is > > > ""easy enough"" to check all the changes related to VLAN and mvebu > > > switch and backport them to 5.10. (even warning some kernel guy once the > > > affected patch are found and sent to stable mailing list to ask greg to > > > be backported) > > > > > > Problem is that we currently lack manpower to bisect this and ideally by > > > disabling these target we will push the community on finding the > > > problem. > > > > > > Require some time but the fact that things are broken on 5.10 and are > > > fixed in 5.15 makes everything less hard to bisect... Someone can > > > totally have some fun building intermediate kernel 5.11, 5.12, 5.13 once > > > things starts to work so he can reduce the patch to check... > > > > > > AFAIK there were many changes to VLAN part and were totally related to > > > mvebu so it just require some user with the device and time to actually > > > bisect this. Once we have the affected commit we can totally backport > > > them and put the patch for the mvebu target and we will reenable the > > > affected devices. > > > > My bet is on one of the patches that are not backports but rather > > hacks/hotfixes > > carried only in OpenWrt. > > Even if it was just an upstream change that fixed it, its probably one > > of the hundreds > > that dont look even remotely related. > > > > Personally I dont have any of these devices and the switch is a rather > > rare model. > > > > That can also be a reason... But again it's just having fun with > starting from a clear start and see what it's broken... > > mvebu platform is full supported upstream so in theory someone can just > use a buildroot and compile a kernel... everything should work right > away Yeah, it shouldn't be "that" hard, its just gonna take the time if you have the HW. Regards, Robert > > -- > Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
