Kernel 6.12 has been ported as the default kernel to 44 of 44 targets (100%) in OpenWrt’s main branch. Qoriq is the only target left. If you have any qoriq devices, please help test 6.12 on it so the kernel migration can be completed. Thanks!
Resources:
Note: I’m not a developer, just a user who’s been monitoring the 6.12 porting progress since its ticket was created a little over a year ago. I don’t have any of this hardware.
I am confused. Are you posting to raise awareness? The ticket is self explanatory.
Yes, I’m posting to raise awareness. Not everyone who’s a potential run tester closely monitors the GitHub, but maybe they’ll see it here. I’m also thinking about making a post on the OpenWrt subreddit.
Several of these test kernels were developed months ago, but have since been languishing with little or no response from run testers. Look at at91, for example. Together, these targets are holding up the migration to kernel 6.12 and, by extension, the creation of the next release branch.
At this point, we’re near the end of the year and progress has been slow enough that there probably won’t be a 25.xx series and instead it will branch next year. Normally, OpenWrt gets one major release per year, with 2020 (Covid-19) being the exception. I hoping more awareness will help speed up the porting process, so that maybe branching could become possible in like January or February.
Hi.
I too am monitoring progress for the 6.12 kernel over various targets. Rather than counting targets, it would be more interesting to count supported devices. Targets that you enumerated have only few devices, while targets already ported to 6.12 represent the vast majority of devices. At some point work and progress for the 6.12 bump should not be hinder by these few devices. So I'm talking about dropping support. It happened before.
True, there’s the number of devices under a given target, and there’s also the popularity of each device. I don’t have any hard data, but I’m guessing these may also be less popular targets. Anecdotally, I don’t tend to see them get mentioned much by users. Targets supported by 24.10 aren’t guaranteed to still be supported in the next release, even if the hardware would be technically capable of running it in theory.
That being said, my understanding is that if a target at least has an approved testing kernel for the appropriate kernel version, OpenWrt developers can choose to keep supporting it in a release but mark it as source-only. So if some of those eight targets can get enough basic run testing done on real hardware in a timely manner, they might be able to avoid getting entirely dropped.
Agreed.
The essence of OpenWrt is to provided the OS for a maximum of devices/targets. Let's give those belated targets a chance. The "approved testing kernel" stage is encouraging. Honestly I don't care if the next version is 25.xx or 26.xx as long as the software is efficient. I praise and trust the devs team for their work.
That's not good. There are millions of ac68u's globally that can be still used as a wired router or smart switch.
Kernel migrations would go way quicker if there were prebuilt snapshots to get more testers.
snapshot
build your own
vs
snapshot
snapshot-6.12
If enough testers give the okay, snapshot-6.12 gets pushed to snapshot.
Not enough testers, snapshot-6.12 stays until the first point release of next stable.
Under this system, a 25.x.0 (6.12) release could happen. "These targets will be dropped with 25.x.1 release if no testers." snapshot-6.12 is deleted for 25.x.2.
Is there a list of good candidate devices somewhere? Maybe people have them sitting in drawers but don't necessarily know the codenames/chipset name. This could be especially important for your companion post on Reddit
List of units:
(https://downloads.openwrt.org/snapshots/targets/)
e.g. bcm53xx
(https://downloads.openwrt.org/snapshots/targets/bcm53xx/generic/)
Links to the documentation are more clear to read.
I think that bcm47xx should be dropped anyway. A lot of those boards did not have working wi-fi anyway like the e1000, e2000 and e3000. Some of thoes had verry week CPUs.
True I have and administer a lot of Broadcom Northstar router NetGear R7000, R6400v2, Linksys EA6900, Asus AC68U which are still running great and are in daily use, but as support for these routers because of the Broadcom proprietary wireless drivers is not so great with OpenWRT, I think that not much are actually running OpenWRT as there are very good alternatives with full support e.g. DDWRT and FT.
Mine all run DDWRT, with the hardware CTF off loading they are doing 1 Gb LAN<>WAN throughput and are using Kernel 4.4. which is still supported as SLTS release.
So yes much used but perhaps not much used for running OpenWRT?
Agreed wireless sucks or is non-existent but that has always been the case and yet it became a target.
Still works as a wired router. If you don't need it as a router, run it as a fully managed switch thanks to DSA. That is how I use them. For whatever reason, openwrt does not promote this use case.
6.12 boots fine. Didn't bother with wireless. DSA works. USB looks like it is getting patched upstream? I don't know how to submit this as a "tester."
Here.
"Unable to verify your captcha response. Please visit https://docs.github.com/articles/troubleshooting-connectivity-problems/#troubleshooting-the-captcha for troubleshooting information."
Did the captcha, created account, and still appear to have been flagged as a bot. Does @stkl read these forums?
[Nov 9, 2025, 12:31:39 PM UTC] kern.info: [ 0.000000] Booting Linux on physical CPU 0x0
[Nov 9, 2025, 12:31:39 PM UTC] kern.notice: [ 0.000000] Linux version 6.12.57 (op@op) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 14.3.0 r31739-557b1801df) 14.3.0, GNU ld (GNU Binutils) 2.44) #0 SMP Sun Nov 9 12:31:34 2025
[Nov 9, 2025, 12:31:39 PM UTC] kern.info: [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[Nov 9, 2025, 12:31:39 PM UTC] kern.info: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[Nov 9, 2025, 12:31:39 PM UTC] kern.info: [ 0.000000] OF: fdt: Machine model: Asus RT-AC68U (BCM4708)
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 3.282334] bcma-host-soc 18000000.axi: bus0: Flash type not supported
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 3.312045] b53-srab-switch b53-srab-switch: error -EINVAL: invalid resource (null)
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 3.319763] b53-srab-switch b53-srab-switch: probe with driver b53-srab-switch failed with error -22
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 3.340952] bgmac_bcma bcma0:4: Invalid MAC addr: 00:00:00:00:00:00
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 3.366403] bgmac_bcma bcma0:5: Invalid MAC addr: 00:00:00:00:00:00
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 3.380554] bgmac_bcma bcma0:6: Unsupported core_unit 3
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 3.385785] bgmac_bcma bcma0:6: probe with driver bgmac_bcma failed with error -524
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 4.155874] pcie_iproc_bcma bcma0:9: PHY or data link is INACTIVE!
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 4.162044] pcie_iproc_bcma bcma0:9: no PCIe EP device detected
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 4.589446] b53-srab-switch 18007000.ethernet-switch: OF node /ethernet-switch@18007000/ports/port@5 of CPU port 5 lacks the required "phy-mode" property
[Nov 9, 2025, 12:31:39 PM UTC] kern.err: [ 4.603210] b53-srab-switch 18007000.ethernet-switch: OF node /ethernet-switch@18007000/ports/port@5 of CPU port 5 lacks the required "phy-handle", "fixed-link" or "managed" properties
[Nov 9, 2025, 12:31:52 PM UTC] daemon.err: procd: Got unexpected signal 1
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 0.000000] Hit pending asynchronous external abort (FSR=0x00001c06) during first unmask, this is most likely caused by a firmware/bootloader bug.
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 0.000000] L2C: DT/platform modifies aux control register: 0x0a130000 -> 0x3a530000
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 0.017487] CPU: WARNING: CPU(s) started in wrong/inconsistent modes (primary CPU mode 0x13)
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 0.017492] CPU: This may indicate a broken bootloader or firmware.
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 1.112111] Bad eraseblock 395 at 0x000003160000
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.011833] mtd: partition "linux" doesn't start on an erase/write block boundary -- force read-only
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.304439] bgmac_bcma bcma0:3: Support for Roboswitch not implemented
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.334403] bgmac_bcma bcma0:4: Support for Roboswitch not implemented
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.347221] bgmac_bcma bcma0:4: Using random MAC: f6:c1:68:87:cb:19
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.359869] bgmac_bcma bcma0:5: Support for Roboswitch not implemented
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.372656] bgmac_bcma bcma0:5: Using random MAC: 3e:d4:a4:8f:93:6f
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.410782] OF: /axi@18000000/pcie@12000: Missing device_type
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.416525] pcie_iproc_bcma bcma0:7: non-prefetchable memory resource required
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.559148] pci_bus 0000:00: 2-byte config write to 0000:00:00.0 offset 0xc8 may corrupt adjacent RW1C bits
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.623756] pci_bus 0000:01: 2-byte config write to 0000:01:00.0 offset 0x4 may corrupt adjacent RW1C bits
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.721139] pcie_iproc_bcma bcma0:8: non-prefetchable memory resource required
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.868985] pci_bus 0001:00: 2-byte config write to 0001:00:00.0 offset 0xc8 may corrupt adjacent RW1C bits
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 3.933630] pci_bus 0001:01: 2-byte config write to 0001:01:00.0 offset 0x4 may corrupt adjacent RW1C bits
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 4.031064] pcie_iproc_bcma bcma0:9: non-prefetchable memory resource required
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 4.168461] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation.
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 4.299654] bcma-pci-bridge 0000:01:00.0: bus1: Invalid SPROM read from the PCIe card, trying to use fallback SPROM
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 4.427344] bcma-pci-bridge 0001:01:00.0: bus2: Invalid SPROM read from the PCIe card, trying to use fallback SPROM
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 4.619640] b53-srab-switch 18007000.ethernet-switch: Skipping phylink registration for CPU port 5
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 6.141335] gpio_button_hotplug: loading out-of-tree module taints kernel.
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 7.188815] mtdblock: MTD device 'nvram' is NAND, please consider using UBI block devices instead.
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 7.537984] mtdblock: MTD device 'nvram' is NAND, please consider using UBI block devices instead.
[Nov 9, 2025, 12:31:39 PM UTC] user.warn: [ 12.662306] urandom-seed: Seed file not found (/etc/urandom.seed)
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 15.408860] mtdblock: MTD device 'nvram' is NAND, please consider using UBI block devices instead.
[Nov 9, 2025, 12:31:39 PM UTC] kern.warn: [ 15.758293] mtdblock: MTD device 'nvram' is NAND, please consider using UBI block devices instead.
I have commented on the GitHub with a link to your forum posts.
Thanks for your feedback @cookiemonster
Log indicates there’s room for improvement on the device tree, but apparently no blocker on this device.
There’s a pending fix for a partitioning issue on some other devices like EA9200, but looks like we are close to merging 6.12 support for bcm53xx.
Agree. If it was possible for users to sysupgrade and easily run tests (and automatically upload results?), I think it would be possible to get more volunteers.
The 6.12 testing kernel for bcm53xx has now been merged into OpenWrt’s main branch.
When I posted this thread just over a week ago, there were 8 targets without approved testing kernels. Now there are only 2. Progress is happening! Nice work, devs! 