Release goals for 22.XX
Hi, The OpenWrt 21.02 release is done and we should plan the next release. We already talked about this in the last meeting, see https://openwrt.org/meetings/20210920 To monitor the current state I created this wiki page based on the wiki page from the previous release: https://openwrt.org/docs/guide-developer/releases/goals/22.xx I would like to get an overview about the "big" changes, if an additional board is added or something is improved we do not need to plan it. I would like to get the following: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel version for all targets: Kernel 5.10 (only): bmips Kernel 5.10 (5.4 still present): bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86 Testing 5.10: apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra Kernel 5.4 only: arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap pistachio uml zynq toolchain: We already updated the toolchain in master to GCC 11.2, binutils 2.37 and musl 1.2.2. This looks good to me. Minor version updates of musl libc later should be ok. gdb and glibc could also be update later if someone wants to do it. mac80211: I would like to update the mac80211 version we use to match the code from kernel 5.15 or whatever will be the next LTS kernel. I haven't started yet. DSA: We will migrate some more boards to DSA, the lantiq/xrx200 target is using DSA in master now. It looks like some boards with qca8k would switch. These changes should be local to one target or even board anyway. The infrastructure is already provided. This can continue without much coordination and we can see what is finished when we branch. firewall4: OpenWrt master contains firewall4 optionally which uses nftables instead of iptables. It uses the same configuration as firewall3, the old configuration should still work. Custom iptables extensions should also still work when we use iptables-nft which supports the iptables user interface and generates nftables rules, even Debian stable uses iptables-nft by default. Flow offloading (software and hardware) is supported by upstream kernel when nftables is used, we are currently using a patch to make it "work" with iptables too. We have to activate it by default and deactivate firewall3. We probably need some minor modifications to LuCi to show the current nftables firewall status. This is not device depended like DSA, we can easily test this on one device and it should work the same way on all others. LuCi: What is still needed in LuCi? Is there anything else which is blocking, should be added or needs a discussion? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: switch to kernel 5.10
Hi Ilya, Op maandag 27 september 2021 om 19u11 schreef Ilya Lipnitskiy : Hi Stijn, >> >all mt7620 JBOOT devices will be broken. ... $ grep \ KERNEL_SIZE image/mt7620.mk|wc -l 1 That one is under "define Device/amit_jboot", searching for that yields: $ git grep "\$(Device/amit_jboot)" | wc -l 8 So all JBOOT devices look covered. Which mt76x8 device(s) is missing a KERNEL_SIZE or fails to boot with 5.10? The single mt76x8 device I have works, my reasoning was that maybe those needed further checks because most (all?) of them are small flash devices. That worry was triggered by the odd report of people bricking their device by flashing images with too big a kernel. That being said, that even seems to happen to beefy modern hardware like the mvebu platform, so... I may have been overly cautious (and worried). By now it's clear I am not wholly familiar with the finer points, so I'm happy with the answers I got (and what I learned) and I'll leave it at that. Thank you! Stijn Ilya ___ 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: Release goals for 22.XX
Hi Hauke, Op woensdag 29 september 2021 om 22u28 schreef Hauke Mehrtens : Hi, The OpenWrt 21.02 release is done and we should plan the next release. We already talked about this in the last meeting, see https://openwrt.org/meetings/20210920 To monitor the current state I created this wiki page based on the wiki page from the previous release: https://openwrt.org/docs/guide-developer/releases/goals/22.xx I would like to get an overview about the "big" changes, if an additional board is added or something is improved we do not need to plan it. I would like to get the following: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel version for all targets: Kernel 5.10 (only): bmips Kernel 5.10 (5.4 still present): bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86 Testing 5.10: apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra Kernel 5.4 only: arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap pistachio uml zynq Not sure if you missed this, but there's a 5.10 for OMAP: https://github.com/openwrt/openwrt/pull/4539. There's a 5.10 PR for lantiq as well, and lantiq is in your 'Testing 5.10' list, so mentioning just it in case. Cheers Stijn toolchain: We already updated the toolchain in master to GCC 11.2, binutils 2.37 and musl 1.2.2. This looks good to me. Minor version updates of musl libc later should be ok. gdb and glibc could also be update later if someone wants to do it. mac80211: I would like to update the mac80211 version we use to match the code from kernel 5.15 or whatever will be the next LTS kernel. I haven't started yet. DSA: We will migrate some more boards to DSA, the lantiq/xrx200 target is using DSA in master now. It looks like some boards with qca8k would switch. These changes should be local to one target or even board anyway. The infrastructure is already provided. This can continue without much coordination and we can see what is finished when we branch. firewall4: OpenWrt master contains firewall4 optionally which uses nftables instead of iptables. It uses the same configuration as firewall3, the old configuration should still work. Custom iptables extensions should also still work when we use iptables-nft which supports the iptables user interface and generates nftables rules, even Debian stable uses iptables-nft by default. Flow offloading (software and hardware) is supported by upstream kernel when nftables is used, we are currently using a patch to make it "work" with iptables too. We have to activate it by default and deactivate firewall3. We probably need some minor modifications to LuCi to show the current nftables firewall status. This is not device depended like DSA, we can easily test this on one device and it should work the same way on all others. LuCi: What is still needed in LuCi? Is there anything else which is blocking, should be added or needs a discussion? 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
[PATCH] realtek: ensure output drivers are enabled in RTL8231
The bootloader can leave the GPIO expander in a state which doesn't have output drivers enabled so GPIOs will properly work for input but output operations will have no effect. To avoid disrupting the boot in case the bootloader left direction and data registers in an inconsistent state (e.g. pulling SoC's reset to 0) reconfigure everything as input. Thanks to Sander Vanheule for telling about LED_Start. Signed-off-by: Paul Fertser --- My previous patch to this part of the code is marked Accepted in the Patchwork so this one is on top of it. Feel free to squash them together. .../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c index a8ffcdc31368..405c2c151368 100644 --- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c +++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c @@ -254,11 +254,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios) sw_w32_mask(3, 1, RTL838X_DMY_REG5); } - /* Select GPIO functionality for pins 0-34 */ + /* Select GPIO functionality and force input direction for pins 0-34 */ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x); + rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x); rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x); - v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32)); - rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7); + rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x); + rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff); + + /* Set LED_Start to enable drivers for output mode */ + rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1); return 0; } -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 9/29/21 10:43 PM, Stijn Segers wrote: Hi Hauke, Op woensdag 29 september 2021 om 22u28 schreef Hauke Mehrtens : Hi, The OpenWrt 21.02 release is done and we should plan the next release. We already talked about this in the last meeting, see https://openwrt.org/meetings/20210920 To monitor the current state I created this wiki page based on the wiki page from the previous release: https://openwrt.org/docs/guide-developer/releases/goals/22.xx I would like to get an overview about the "big" changes, if an additional board is added or something is improved we do not need to plan it. I would like to get the following: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel version for all targets: Kernel 5.10 (only): bmips Kernel 5.10 (5.4 still present): bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86 Testing 5.10: apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra Kernel 5.4 only: arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap pistachio uml zynq Not sure if you missed this, but there's a 5.10 for OMAP: https://github.com/openwrt/openwrt/pull/4539. There's a 5.10 PR for lantiq as well, and lantiq is in your 'Testing 5.10' list, so mentioning just it in case. Cheers Stijn Hi Stijn, I only listed the status which is already committed to master. When there is already a testing 5.10 kernel in master it will probably be switched soon. I am aware of the lantiq pull request, but there are still some problems. There are also patches on the mailing list for at91: https://patchwork.ozlabs.org/project/openwrt/list/?series=263092 I think the kernel 5.10 status in OpenWrt looks good as all major targets at least have a testing kernel 5.10. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 9/29/21 22:28, Hauke Mehrtens wrote: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel 5.15 could be also a LTS Kernel that should be released in the end of October? Why not aiming for it if we plan to release in 2022? Bests Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Hauke: My thanks also for writing up those note. My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in September. And so on - every six months (or whatever interval we believe we can sustain for the long term.) For each release, we need to work backwards, and make the feature freeze for the March release in, say, early January so the first RC can come out in January, we can have a few RCs leading up to a final release sometime within 60-75 days. The reasons to do this: - Some people can only use stable releases because of their business needs or their personality. (Or because we tell them "Only Use Stable!") Regular releases let them use the newest features. - Contrarily, a long release cycle "traps" new stuff behind something that "isn't quite done." - We don't waste time producing and testing patched versions of the previous release. There were seven patch releases in the 19.07 series (running from January 2020 through August 2021). A regular release schedule could have avoided many of these. - Having a firm feature freeze date decreases stress. If a particular feature is done/substantially working, it goes in. If it's not quite ready, it can skip this release, and get into the next release. (The alternative is what I think happened with DSA. It was a big change: there were a large number of problems that took a long time to iron out. That kept pushing out the date...) - Customers (our users, our industry partners) gain confidence in projects that can meet their deadlines. Imre noted that "industry is using the snapshots..." but I suspect the extended schedule just worries other vendors. Does this need a vote? Thanks. Rich > On Sep 29, 2021, at 4:28 PM, Hauke Mehrtens wrote: > > Hi, > > The OpenWrt 21.02 release is done and we should plan the next release. > We already talked about this in the last meeting, see > https://openwrt.org/meetings/20210920 > > To monitor the current state I created this wiki page based on the wiki page > from the previous release: > https://openwrt.org/docs/guide-developer/releases/goals/22.xx > > I would like to get an overview about the "big" changes, if an additional > board is added or something is improved we do not need to plan it. > > I would like to get the following: > > kernel 5.10: > We should get all targets to kernel 5.10. All targets which are not on kernel > 5.10 when we branch off should get removed. > > Kernel version for all targets: > Kernel 5.10 (only): > bmips > Kernel 5.10 (5.4 still present): > bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86 > Testing 5.10: > apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta > mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra > Kernel 5.4 only: > arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap pistachio > uml zynq > > toolchain: > We already updated the toolchain in master to GCC 11.2, binutils 2.37 and > musl 1.2.2. This looks good to me. Minor version updates of musl libc later > should be ok. gdb and glibc could also be update later if someone wants to do > it. > > mac80211: > I would like to update the mac80211 version we use to match the code from > kernel 5.15 or whatever will be the next LTS kernel. I haven't started yet. > > DSA: > We will migrate some more boards to DSA, the lantiq/xrx200 target is using > DSA in master now. It looks like some boards with qca8k would switch. These > changes should be local to one target or even board anyway. The > infrastructure is already provided. This can continue without much > coordination and we can see what is finished when we branch. > > firewall4: > OpenWrt master contains firewall4 optionally which uses nftables instead of > iptables. It uses the same configuration as firewall3, the old configuration > should still work. Custom iptables extensions should also still work when we > use iptables-nft which supports the iptables user interface and generates > nftables rules, even Debian stable uses iptables-nft by default. Flow > offloading (software and hardware) is supported by upstream kernel when > nftables is used, we are currently using a patch to make it "work" with > iptables too. > > We have to activate it by default and deactivate firewall3. > We probably need some minor modifications to LuCi to show the current > nftables firewall status. This is not device depended like DSA, we can easily > test this on one device and it should work the same way on all others. > > LuCi: > What is still needed in LuCi? > > > Is there anything else which is blocking, should be added or needs a > discussion? > > Hauke > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwr
