Generated a custom image of 22.03.0 with imagebuilder, to upgrade from 22.03rc6 on my wrt3200acm. The actual SHA256 checksum of the sysupgrade .bin file does not match the generated .sha256sum file. There were no errors during the imagebuild process. I keep getting the same result each time I download, extract, and try to build a new file from the imagebuilder kit. Is the sysupgrade.bin file corrupted?
Images are build, however, packaging sysupgrade and factory images fails due to size limitations (most likely caused by fw4 and grown kernel images). You can build your own images using the imagebuilder. Your best bet is to remove luci and fw4 from those RE devices in order to make the image fit.
If I force the upgrade I end up with broken system and at the serial console I get the following output.
U-Boot 2009.08-00048-ga5d8f06 Meraki MX60 (Oct 14 2011 - 21:30:08)
CPU: AMCC PowerPC UNKNOWN (PVR=12c41c83) at 800 MHz (PLB=200, OPB=100, EBC=100 MHz)
Bootstrap Option D - Boot ROM Location NAND wo/ECC 2k page (8 bits), booting from NAND
32 kB I-Cache 32 kB D-Cache
Board: Buckminster - Meraki Buckminster Cloud Managed Router
============================
BoardID: 1 0
Reset Button Status: 1
============================
SDR0_PERCLK=0x40000300
I2C: ready
DRAM: 512 MB
NAND: 1024 MiB
I2c read: failed 4
I2c read: failed 4
I2c read: failed 4
Net: ppc_4xx_eth0
Initializing Bluestone Ethernet Port ...
Disabling port 0
Disabling port 1
Disabling port 2
Disabling port 3
ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
*** ERROR: ping address not given
RESET is un-pushed
Set serverpath and run meraki_netboot to netboot
Hit any key to stop autoboot: 0
Creating 1 MTD partitions on "nand0":
0x000000240000-0x000040000000 : "mtd=2"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=2"
UBI: MTD device size: 1021 MiB
UBI: number of good PEBs: 8170
UBI: number of bad PEBs: 4
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 4
UBI: available PEBs: 75
UBI: total number of reserved PEBs: 8095
UBI: number of PEBs reserved for bad PEB handling: 81
UBI: max/mean erase counter: 3/1
Volume kernel found at volume id 0
read 0 bytes from volume 0 to 800000(buf address)
Read [3999744] bytes
Unexpected magic number 27051956
recovery volume not found
=>
Leaving me having to reinstall 21.02 again manually.
I do not have recovery partition option set on this as I get not enough free logical space to create partition error when I follow the instructions verbatim from the device page.
It does say to do it before you perform the upgrade but if you do then reboot it to load up luci to do the sysupgrade it will fail to boot so do the first line then reboot and do the upgrade in luci and then go to the serial console and do the second line then reboot and it will boot into 22.03
Hi
Successfully installed on Linksys EA7300v2 (mt7621). I rebooted to Linksys firmware and than flashed a factory and restored the config from backup.
The EA7300 needs a tweak (see its doc) for keeping the install safe. This tweak is also necessary for 22.03. A patch has been put in PR in master snapshots, and is wiating for validation.
I upgraded to 22.03.0 from 19.07.07 on a Zyxel NBG6716 (full upgrade using tftp).
Did anyone get the QCA988x to work? (ath10k) I tried both ct and regular drivers but no success with either.
thanks.
ps: I asked the same question in a seperate thread 5Ghz on NBG6716 with 22.03 but no responses. I'm trying this thread as a last resort before reverting back to 19.07
There are no bug fixes to the mwlwifi driver, the project has been dead for years. So if you have WRT1200 or WRT1900 series you will likely still need to disable amsdu. WRT3200ACM and WRT32X are not affected.
FYI wifi for these targets have been discussed heavily over the years and best practices have been outlined here, I overhauled it recently from my github account so the info should still be good:
[https://openwrt.org/toh/linksys/wrt_ac_series#marvell_wifi]
Yes, very happy, but might also be depending on type of configuration, some people setup... I did a complete new installation, from Zero.. flashing the factory image to both partitions, and then, made a "Master" installation with all I need (Wireguard <-> Mullvad, Unbound, Exroot, AdBlock, local Wireguardserver, DDNS, omcproxy, Transmission, SQM, ksmbd... all wonderfull. For those, that have problems, I hope they can be fixed soon Peace
Yes, I did on my TP-Link Archer C7 v2. Works fine with the mainline (non-ct) firmware and driver (I haven't tested the ct-variant).
My Archer C7 v2 setup is somewhat unique though, because I replaced the original Mini-PCIe wireless module (it broke at some point) with a Compex WLE900VX module which is also QCA988x-based.
the archer C7 v2 is indeed very similar to the NBG6716 - but (sadly) my wireless module is still working fine (with 19.07 that is).
I do have some (intel) wifi modules lying around, scavenged from laptops. Would it be a matter of just swapping out the cards and loading the drivers - or I'm I then down the rabbit hole of extracting cal-data, editing board files and really just building a custom firmware.
i.e. just stick with 19.07 - I'm not looking for a new hobby project, just a stable openwrt release.
(grasping at straws here but) the root cause of this could be similar as to what i'm seeing on my NBG6716. Could you check whether the driver is loaded correctly?
either rmmod/insmod or reboot and: dmesg | grep ath10k
(not sure if that's the best way to check this, but it's what I do )
Technically, it should work if you swap the modules install the required kernel modules and firmware. Intel modules don't come with calibration data that would need to be extracted from the original device (and calibration data for the QCA module would simply not be used by the Intel driver). But I wonder what the benefit of that would be other than verifying that the Mini-PCIe slot is working. Intel restricts the access point use on its wireless modules to the 2.4GHz band. So you wouldn't have a proper replacement for the 5GHz band that the QCA module offers.
Hi, and thanks to everyone for adding bits of information.
TL:DR: I'll be reverting to 19.07 - 5Ghz is broken.
What I've found so far:
AFAICT the QCA988x is fine, at least at the PCI level - but both CT and regular drivers fail to load properly.
the problem is NBG6716 specific, not with QCA988x in general - other devices with the QCA988x are working fine with 22.03
the problem is older than 22.03 - I've not verified this myself but I found a similar report of 21.02 failing similarly (and reverting to 19.07 to get it working again).
My best guess would be the bug was introduced transitioning from ar71xx to ath79... but that's way out of my league to figure out, let alone fix.
SInce the bug was introduced so long ago, and wasn't picked up, I don't expect a fix to magically appear anytime soon.
Back to 19.07 it is.
anyway, thanks for the support, openwrt has a great community!
and my other devices are happily chugging along on 22.03.
Peace
)