Re: Flagship AX routers
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 --- On 5/18/21 11:52 PM, Philip Prindeville wrote: Hi all, I noticed that there are several AX routers from TP-Link, Netgear, D-Link, etc. and some of them have even had OpenWRT ported to them. Which of these various platforms has the most CPU/RAM/FLASH? A few are discussed, but I'm not seeing consensus on "the best one currently is this..." And not to forget, which ones are affordable given the current shortages and are (still) available globally. https://forum.openwrt.org/t/802-11ax-routers/10484/281 Also saw this: https://10-0-0-0-1.org/reviews/routers/openwrt/ But it only lists AC routers. Was looking at this: https://www.amazon.com/TP-Link-WiFi-AX3000-Smart-Router/dp/B07YMFZ28Q/ But it doesn't call out CPU, memory, or storage. Got there from this page: https://www.amazon.com/OpenWrt-Routers-Networking-Products/s?k=OpenWrt=n%3A300189 Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Flagship AX routers
On 21.05.21 20:18, Stijn Segers wrote: Oh you'd provably get the board up and running in a jiffy. I suppose the multi-gigabit PHYs might already be supported as well - not in the loop in those. The wireless? Just look at Broadcom's FOSS track record with 802.11g/n/ac. And vote with your wallet. lol ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Flagship AX routers
Hi, Mike Bernardo schreef op 21 mei 2021 13:46:25 CEST: >Would be great if we could get openwrt running on these, with 2.5gigE and AX. > >https://www.fs.com/products/115390.html > >It is a BCM47622, I wonder how difficult this would be? Oh you'd provably get the board up and running in a jiffy. I suppose the multi-gigabit PHYs might already be supported as well - not in the loop in those. The wireless? Just look at Broadcom's FOSS track record with 802.11g/n/ac. And vote with your wallet. Stijn > I'd be tempted to buy one to give it a try. > >Mike > >> On 2021/05/21, at 04:58:46 CDT (-05:00), Daniel Golle >> wrote: >> >> On Thu, May 20, 2021 at 11:26:58PM -0600, Philip Prindeville wrote: >>> >>> On May 18, 2021, at 10:57 PM, John Crispin wrote: On 19.05.21 00:09, Paul Spooren wrote: > Hi, > > On 5/18/21 11:52 PM, Philip Prindeville wrote: >> Hi all, >> >> I noticed that there are several AX routers from TP-Link, Netgear, >> D-Link, etc. and some of them have even had OpenWRT ported to them. >> >> Which of these various platforms has the most CPU/RAM/FLASH? A few are >> discussed, but I'm not seeing consensus on "the best one currently is >> this..." > > I'm using both a Belkin RT3200 and a Linksys AX3200 (aka E8450), which > are conveniently pretty much the same thing and I'm having a pretty good > time. Would flash again. > > Best, > Paul > this is the goto unit for AX right now ... https://openwrt.org/toh/linksys/linksys_e8450 consider using this to flash the unit https://github.com/dangowrt/linksys-e8450-openwrt-installer John >>> >>> >>> Thanks, both of you. >>> >>> Is that the one that only has USB 2.0, so if you wanted to add a hard drive >>> for NAS or DLNA, you're bandwidth limited? >> >> Yes, it got only USB 2.0, I guess because for USB 3.x you got to decide >> to either live with 2.4~2.5GHz interference (like most IPQ devices I've >> seen having USB 3.0 so far) or spend more for filters and evaluating a >> board design. >> It's definitely not meant to be a NAS, it's just an AP/Router, not even >> too useful as a modem-router (USB 2.0 port supplies only 500mAh afair). >> When using as dual-band AP, also the Gigabit Ethernet of the E8450 can >> become a bottle-kneck, UniFi 6 LR got that Aquantina 2.5GBase-T PHY >> (and also combines MT7622x with MT7915E, like the E8450). >> >> ___ >> 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 -- Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SquashFS mixed errors (decompression failed and others)
On 5/21/21 3:58 PM, Koen Vandeputte wrote: On 21.05.21 13:19, Ibrahim Tachijian wrote: Hello, We use approximately 10k IPQ40XX devices and we have noticed that every time we run "sysupgrade -n" we lose approximately 1% of the routers in the process. After further investigation I'm almost confident that it is not the sysupgrade process that is the culprit - so what I did was that I put one test router into a reboot loop. This is what I do; Boot the router in a fresh state after a newly installed image. The image contains a reboot loop that consists of a shell script that runs every minute. The shell script tries to run a php-script which simply echoes "Hello World". If the php-script exists normally then we reboot the router. However the php-script exists abnormally then the router stops and does nothing other than informing me that there was a bus-error making php not able to process the hello world script. When this process runs the router reboots approximately 50 times before it boots into a state which is faulty where I see bus-errors when I try to run php scripts for example. Looking into dmesg you can see some errors such as, [10985.209438] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11045.218685] SQUASHFS error: xz decompression failed, data probably corrupt [11045.218731] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11105.228157] SQUASHFS error: xz decompression failed, data probably corrupt [11105.228203] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e or [26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a] [26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 10234 or [62745.801178] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62773.347234] SQUASHFS error: xz decompression failed, data probably corrupt [62773.347281] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.132661] SQUASHFS error: xz decompression failed, data probably corrupt [62790.132706] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.216746] SQUASHFS error: xz decompression failed, data probably corrupt [62790.216792] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62800.810525] SQUASHFS error: xz decompression failed, data probably corrupt [62800.810570] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62828.336267] SQUASHFS error: xz decompression failed, data probably corrupt Now, you would assume that the squashfs-partition is broken - but if this was the case then a reboot should not help. It does. Rebooting the router after it boots in this faulty state fixes the issue. So approximately 1-2% of my reboots make the router go into this faulty state. I am clueless on how to further investigate this issue. For now my work around is restarting the router via a bash script should it notice there are bus-errors or i/o errors. Thanks In the next kernel bump, following patch is also present: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.38=2ed1d90162a0c0683ecbe0c4802187fa22d641c3 I think it's worth a shot to retry the tests once it's bumped. Koen My guess is that the error already happens when reading the flash. Is your firmware (sysupgrade) bigger than 16MB? So maybe it has to do with switching to 4-address-mode... Best, Vincent ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SquashFS mixed errors (decompression failed and others)
On 21.05.21 13:19, Ibrahim Tachijian wrote: Hello, We use approximately 10k IPQ40XX devices and we have noticed that every time we run "sysupgrade -n" we lose approximately 1% of the routers in the process. After further investigation I'm almost confident that it is not the sysupgrade process that is the culprit - so what I did was that I put one test router into a reboot loop. This is what I do; Boot the router in a fresh state after a newly installed image. The image contains a reboot loop that consists of a shell script that runs every minute. The shell script tries to run a php-script which simply echoes "Hello World". If the php-script exists normally then we reboot the router. However the php-script exists abnormally then the router stops and does nothing other than informing me that there was a bus-error making php not able to process the hello world script. When this process runs the router reboots approximately 50 times before it boots into a state which is faulty where I see bus-errors when I try to run php scripts for example. Looking into dmesg you can see some errors such as, [10985.209438] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11045.218685] SQUASHFS error: xz decompression failed, data probably corrupt [11045.218731] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11105.228157] SQUASHFS error: xz decompression failed, data probably corrupt [11105.228203] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e or [26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a] [26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 10234 or [62745.801178] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62773.347234] SQUASHFS error: xz decompression failed, data probably corrupt [62773.347281] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.132661] SQUASHFS error: xz decompression failed, data probably corrupt [62790.132706] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.216746] SQUASHFS error: xz decompression failed, data probably corrupt [62790.216792] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62800.810525] SQUASHFS error: xz decompression failed, data probably corrupt [62800.810570] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62828.336267] SQUASHFS error: xz decompression failed, data probably corrupt Now, you would assume that the squashfs-partition is broken - but if this was the case then a reboot should not help. It does. Rebooting the router after it boots in this faulty state fixes the issue. So approximately 1-2% of my reboots make the router go into this faulty state. I am clueless on how to further investigate this issue. For now my work around is restarting the router via a bash script should it notice there are bus-errors or i/o errors. Thanks In the next kernel bump, following patch is also present: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.38=2ed1d90162a0c0683ecbe0c4802187fa22d641c3 I think it's worth a shot to retry the tests once it's bumped. Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SquashFS mixed errors (decompression failed and others)
Hello Vincent, The board is the GL.iNet GL-B1300. You can read about it here: https://openwrt.org/toh/gl.inet/gl.inet_gl-b1300 On Fri, May 21, 2021 at 2:18 PM Vincent Wiemann wrote: > > Hi Ibrahim, > > please post the affected model name. It could e.g. be a bad board design > which requires the flash to be clocked slower or something. > Without knowing the affected board, it is guessing... > > Best, > > Vincent > > On 5/21/21 1:19 PM, Ibrahim Tachijian wrote: > > Hello, > > > > We use approximately 10k IPQ40XX devices and we have noticed that > > every time we run "sysupgrade -n" we lose approximately 1% of the > > routers in the process. > > After further investigation I'm almost confident that it is not the > > sysupgrade process that is the culprit - so what I did was that I put > > one test router into a reboot loop. > > > > This is what I do; > > > > Boot the router in a fresh state after a newly installed image. > > The image contains a reboot loop that consists of a shell script that > > runs every minute. > > > > The shell script tries to run a php-script which simply echoes "Hello > > World". If the php-script exists normally then we reboot the router. > > > > However the php-script exists abnormally then the router stops and > > does nothing other than informing me that there was a bus-error making > > php not able to process the hello world script. > > > > When this process runs the router reboots approximately 50 times > > before it boots into a state which is faulty where I see bus-errors > > when I try to run php scripts for example. > > > > > > Looking into dmesg you can see some errors such as, > > > > [10985.209438] SQUASHFS error: squashfs_read_data failed to read block > > 0x3a803e > > [11045.218685] SQUASHFS error: xz decompression failed, data probably > > corrupt > > [11045.218731] SQUASHFS error: squashfs_read_data failed to read block > > 0x3a803e > > [11105.228157] SQUASHFS error: xz decompression failed, data probably > > corrupt > > [11105.228203] SQUASHFS error: squashfs_read_data failed to read block > > 0x3a803e > > > > or > > > > [26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 10234 > > [26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a] > > [26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 10234 > > [26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a] > > [26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 10234 > > [26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a] > > [26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 10234 > > > > or > > > > [62745.801178] SQUASHFS error: squashfs_read_data failed to read block > > 0x732ae2 > > [62773.347234] SQUASHFS error: xz decompression failed, data probably > > corrupt > > [62773.347281] SQUASHFS error: squashfs_read_data failed to read block > > 0x732ae2 > > [62790.132661] SQUASHFS error: xz decompression failed, data probably > > corrupt > > [62790.132706] SQUASHFS error: squashfs_read_data failed to read block > > 0x732ae2 > > [62790.216746] SQUASHFS error: xz decompression failed, data probably > > corrupt > > [62790.216792] SQUASHFS error: squashfs_read_data failed to read block > > 0x732ae2 > > [62800.810525] SQUASHFS error: xz decompression failed, data probably > > corrupt > > [62800.810570] SQUASHFS error: squashfs_read_data failed to read block > > 0x732ae2 > > [62828.336267] SQUASHFS error: xz decompression failed, data probably > > corrupt > > > > > > > > Now, you would assume that the squashfs-partition is broken - but if > > this was the case then a reboot should not help. It does. > > Rebooting the router after it boots in this faulty state fixes the issue. > > > > So approximately 1-2% of my reboots make the router go into this faulty > > state. > > > > I am clueless on how to further investigate this issue. For now my > > work around is restarting the router via a bash script should it > > notice there are bus-errors or i/o errors. > > > > Thanks > > > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ibrahim Tachijian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SquashFS mixed errors (decompression failed and others)
Hi Ibrahim, please post the affected model name. It could e.g. be a bad board design which requires the flash to be clocked slower or something. Without knowing the affected board, it is guessing... Best, Vincent On 5/21/21 1:19 PM, Ibrahim Tachijian wrote: Hello, We use approximately 10k IPQ40XX devices and we have noticed that every time we run "sysupgrade -n" we lose approximately 1% of the routers in the process. After further investigation I'm almost confident that it is not the sysupgrade process that is the culprit - so what I did was that I put one test router into a reboot loop. This is what I do; Boot the router in a fresh state after a newly installed image. The image contains a reboot loop that consists of a shell script that runs every minute. The shell script tries to run a php-script which simply echoes "Hello World". If the php-script exists normally then we reboot the router. However the php-script exists abnormally then the router stops and does nothing other than informing me that there was a bus-error making php not able to process the hello world script. When this process runs the router reboots approximately 50 times before it boots into a state which is faulty where I see bus-errors when I try to run php scripts for example. Looking into dmesg you can see some errors such as, [10985.209438] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11045.218685] SQUASHFS error: xz decompression failed, data probably corrupt [11045.218731] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11105.228157] SQUASHFS error: xz decompression failed, data probably corrupt [11105.228203] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e or [26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a] [26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 10234 or [62745.801178] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62773.347234] SQUASHFS error: xz decompression failed, data probably corrupt [62773.347281] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.132661] SQUASHFS error: xz decompression failed, data probably corrupt [62790.132706] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.216746] SQUASHFS error: xz decompression failed, data probably corrupt [62790.216792] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62800.810525] SQUASHFS error: xz decompression failed, data probably corrupt [62800.810570] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62828.336267] SQUASHFS error: xz decompression failed, data probably corrupt Now, you would assume that the squashfs-partition is broken - but if this was the case then a reboot should not help. It does. Rebooting the router after it boots in this faulty state fixes the issue. So approximately 1-2% of my reboots make the router go into this faulty state. I am clueless on how to further investigate this issue. For now my work around is restarting the router via a bash script should it notice there are bus-errors or i/o errors. Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Flagship AX routers
Would be great if we could get openwrt running on these, with 2.5gigE and AX. https://www.fs.com/products/115390.html It is a BCM47622, I wonder how difficult this would be? I'd be tempted to buy one to give it a try. Mike > On 2021/05/21, at 04:58:46 CDT (-05:00), Daniel Golle > wrote: > > On Thu, May 20, 2021 at 11:26:58PM -0600, Philip Prindeville wrote: >> >> >>> On May 18, 2021, at 10:57 PM, John Crispin wrote: >>> >>> On 19.05.21 00:09, Paul Spooren wrote: Hi, On 5/18/21 11:52 PM, Philip Prindeville wrote: > Hi all, > > I noticed that there are several AX routers from TP-Link, Netgear, > D-Link, etc. and some of them have even had OpenWRT ported to them. > > Which of these various platforms has the most CPU/RAM/FLASH? A few are > discussed, but I'm not seeing consensus on "the best one currently is > this..." I'm using both a Belkin RT3200 and a Linksys AX3200 (aka E8450), which are conveniently pretty much the same thing and I'm having a pretty good time. Would flash again. Best, Paul >>> >>> this is the goto unit for AX right now ... >>> >>> https://openwrt.org/toh/linksys/linksys_e8450 >>> >>> consider using this to flash the unit >>> >>> https://github.com/dangowrt/linksys-e8450-openwrt-installer >>> >>>John >>> >> >> >> Thanks, both of you. >> >> Is that the one that only has USB 2.0, so if you wanted to add a hard drive >> for NAS or DLNA, you're bandwidth limited? > > Yes, it got only USB 2.0, I guess because for USB 3.x you got to decide > to either live with 2.4~2.5GHz interference (like most IPQ devices I've > seen having USB 3.0 so far) or spend more for filters and evaluating a > board design. > It's definitely not meant to be a NAS, it's just an AP/Router, not even > too useful as a modem-router (USB 2.0 port supplies only 500mAh afair). > When using as dual-band AP, also the Gigabit Ethernet of the E8450 can > become a bottle-kneck, UniFi 6 LR got that Aquantina 2.5GBase-T PHY > (and also combines MT7622x with MT7915E, like the E8450). > > ___ > 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
SquashFS mixed errors (decompression failed and others)
Hello, We use approximately 10k IPQ40XX devices and we have noticed that every time we run "sysupgrade -n" we lose approximately 1% of the routers in the process. After further investigation I'm almost confident that it is not the sysupgrade process that is the culprit - so what I did was that I put one test router into a reboot loop. This is what I do; Boot the router in a fresh state after a newly installed image. The image contains a reboot loop that consists of a shell script that runs every minute. The shell script tries to run a php-script which simply echoes "Hello World". If the php-script exists normally then we reboot the router. However the php-script exists abnormally then the router stops and does nothing other than informing me that there was a bus-error making php not able to process the hello world script. When this process runs the router reboots approximately 50 times before it boots into a state which is faulty where I see bus-errors when I try to run php scripts for example. Looking into dmesg you can see some errors such as, [10985.209438] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11045.218685] SQUASHFS error: xz decompression failed, data probably corrupt [11045.218731] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11105.228157] SQUASHFS error: xz decompression failed, data probably corrupt [11105.228203] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e or [26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a] [26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 10234 or [62745.801178] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62773.347234] SQUASHFS error: xz decompression failed, data probably corrupt [62773.347281] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.132661] SQUASHFS error: xz decompression failed, data probably corrupt [62790.132706] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.216746] SQUASHFS error: xz decompression failed, data probably corrupt [62790.216792] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62800.810525] SQUASHFS error: xz decompression failed, data probably corrupt [62800.810570] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62828.336267] SQUASHFS error: xz decompression failed, data probably corrupt Now, you would assume that the squashfs-partition is broken - but if this was the case then a reboot should not help. It does. Rebooting the router after it boots in this faulty state fixes the issue. So approximately 1-2% of my reboots make the router go into this faulty state. I am clueless on how to further investigate this issue. For now my work around is restarting the router via a bash script should it notice there are bus-errors or i/o errors. Thanks -- Ibrahim Tachijian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC v2 2/3] ath79: add NAND driver for Mikrotik RB91xG series
Main part is copied from ar71xx original driver rb91x_nand
written by Gabor Juhos .
What is done:
* Support of kernel 5.4 and 5.10,
* DTS support,
* New gpio API (gpiod_*) support.
Signed-off-by: Denis Kalashnikov
---
Changelog:
v1-->v2:
- Do not use MFD driver API anymore.
---
.../files/drivers/mtd/nand/raw/rb91x_nand.c | 414 ++
target/linux/ath79/mikrotik/config-default| 1 +
.../patches-5.10/939-mikrotik-rb91x.patch | 24 +
.../patches-5.4/939-mikrotik-rb91x.patch | 21 +
4 files changed, 460 insertions(+)
create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
diff --git a/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
new file mode 100644
index 00..069c2978f7
--- /dev/null
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
@@ -0,0 +1,414 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * NAND flash driver for the MikroTik RouterBOARD 91x series
+ *
+ * Main part is copied from original driver written by Gabor Juhos.
+ *
+ * Copyright (C) 2013-2014 Gabor Juhos
+ */
+
+/*
+ * WARNING: to speed up NAND reading/writing we are working with SoC GPIO
+ * controller registers directly -- not through standard GPIO API.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* TODO: ar71xx regs (SoC GPIO controller ones) should be get from DTS? */
+#include
+
+#define RB91X_NAND_DRIVER_NAME "rb91x-nand"
+
+static void __iomem *ath79_gpio_base;
+
+#define RB91X_NAND_DRIVER_DESC "MikrotTik RB91x NAND flash driver"
+
+/* Bit masks for NAND data lines in ath79 gpio 32-bit register */
+#define RB91X_NAND_NRW_BIT BIT(12)
+#define RB91X_NAND_DATA_BITS (BIT(0) | BIT(1) | BIT(2) | BIT(3) | BIT(4) \
+ | BIT(13) | BIT(14) | BIT(15))
+#define RB91X_NAND_LOW_DATA_MASK 0x1f
+#define RB91X_NAND_HIGH_DATA_MASK 0xe0
+#define RB91X_NAND_HIGH_DATA_SHIFT 8
+
+enum rb91x_nand_gpios {
+ RB91X_NAND_ALE, /* Address Latch Enable */
+ RB91X_NAND_CLE, /* Command Latch Enable */
+ RB91X_NAND_NCE, /* Chip Enable. Active low */
+ RB91X_NAND_NRW, /* Read/Write. Active low */
+ RB91X_NAND_READ,/* Read */
+ RB91X_NAND_RDY, /* NAND Ready */
+ RB91X_NAND_NLE, /* Latch Enable. Active low */
+
+ RB91X_NAND_GPIOS,
+};
+
+struct rb91x_nand_drvdata {
+ struct nand_chip chip;
+ struct device *dev;
+ struct gpio_desc *gpio[RB91X_NAND_GPIOS];
+};
+
+static void rb91x_nand_latch_lock(struct rb91x_nand_drvdata *drvdata, int lock)
+{
+ gpiod_set_value_cansleep(drvdata->gpio[RB91X_NAND_NLE], lock);
+}
+
+static struct mtd_info *rb91x_nand_drvdata_to_mtd(struct rb91x_nand_drvdata
*drvdata)
+{
+ return nand_to_mtd(>chip);
+}
+
+static int rb91x_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ switch (section) {
+ case 0:
+ oobregion->offset = 8;
+ oobregion->length = 3;
+ return 0;
+ case 1:
+ oobregion->offset = 13;
+ oobregion->length = 3;
+ return 0;
+ default:
+ return -ERANGE;
+ }
+}
+
+static int rb91x_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ switch (section) {
+ case 0:
+ oobregion->offset = 0;
+ oobregion->length = 4;
+ return 0;
+ case 1:
+ oobregion->offset = 4;
+ oobregion->length = 1;
+ return 0;
+ case 2:
+ oobregion->offset = 6;
+ oobregion->length = 2;
+ return 0;
+ case 3:
+ oobregion->offset = 11;
+ oobregion->length = 2;
+ return 0;
+ default:
+ return -ERANGE;
+ }
+}
+
+static const struct mtd_ooblayout_ops rb91x_nand_ecclayout_ops = {
+ .ecc = rb91x_ooblayout_ecc,
+ .free = rb91x_ooblayout_free,
+};
+
+/* TODO: Should be in DTS */
+static struct mtd_partition rb91x_nand_partitions[] = {
+ {
+ .name = "booter",
+ .offset = 0,
+ .size = (256 * 1024),
+ .mask_flags = MTD_WRITEABLE,
+ }, {
+ .name = "kernel",
+ .offset = (256 * 1024),
+ .size = (4 * 1024 * 1024) - (256 * 1024),
+ }, {
+ .name = "ubi",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static void rb91x_nand_write(struct rb91x_nand_drvdata *drvdata,
+const u8 *buf,
+unsigned len)
+{
+ void __iomem *base = ath79_gpio_base;
+ u32 oe_reg;
+ u32 out_reg;
+ u32 out;
+
[RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
This board has been supported in the ar71xx.
Links:
* https://mikrotik.com/product/RB912UAG-2HPnD
* https://mikrotik.com/product/RB912UAG-5HPnD
* https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd
* https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-5hpnd
Hardware:
* SoC: Atheros AR9342,
* RAM: DDR 64MB,
* SPI NOR: 64KB,
* NAND: 128MB,
* Ethernet: x1 10/100/1000 port with passive POE in,
* Wi-Fi: 802.11bgn,
* PCIe,
* USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A
port -- both can be used for LTE modem. But only one can be used.
* LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED,
Ethernet phy LED,
* Button,
* Beeper.
Not working:
* Button: it shares gpio line 15 with NAND ALE and NAND IO7,
and current drivers doesn't easily support this configuration,
* Beeper: it is connected to bit 5 of a serial shift register
(tested with sysfs led trigger timer). But kmod-gpio-beeper
doesn't work -- we left this as is for now.
You can flash image by sysupgrade utility or load it by net
(by DHCP/TFTP, hold the button while booting).
Co-Developed-by: Koen Vandeputte
Signed-off-by: Denis Kalashnikov
---
Changelog:
v1->v2:
- Delete uneeded comments from DTS,
- Delete ascii-art of board scheme near NAND latch from DTS,
- Rewrite gpio_latch and nand_gpio nodes to be consistent with the
new versions of drivers,
- Fix SPI NOR flash and SPI serial shift register maximum speeds
(thanks to Koen Vandeputte),
- Add UART, PCIe, USB support and gpio exports (thanks to Koen Vandeputte),
- Fix Ethernet node (thanks to Koen Vandeputte),
- Add key and beeper nodes in disabled state just to be documented.
---
.../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++
target/linux/ath79/image/mikrotik.mk | 9 +
.../base-files/etc/board.d/02_network | 2 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
.../base-files/lib/upgrade/platform.sh| 1 +
5 files changed, 246 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
diff --git a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
new file mode 100644
index 00..a23fc04a99
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "ar9344.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "mikrotik,routerboard-912g", "qca,ar9342";
+ model = "Mikrotik RouterBoard 912G";
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power {
+ label = "green:power";
+ gpios = <_latch 1 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ led_user {
+ label = "green:user";
+ gpios = <_latch 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ led1 {
+ label = "green:led1";
+ gpios = < 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ led2 {
+ label = "green:led2";
+ gpios = < 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ led3 {
+ label = "green:led3";
+ gpios = < 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ led4 {
+ label = "green:led4";
+ gpios = < 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ led5 {
+ label = "green:led5";
+ gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ beeper {
+ status = "disabled";
+ compatible = "gpio-beeper";
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ keys {
+ status = "disabled";
+ compatible = "gpio-keys";
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 15 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+
+ gpio_export {
+ compatible = "gpio-export";
+
+ usb_select {
+ label = "select:usb";
+ gpio-export,name = "mikrotik:select:usb";
+ gpio-export,output = <0>; /* 0: mini-pcie, 1: Type-A
port */
+ gpios = < 6 GPIO_ACTIVE_LOW>;
+ };
+
+ pcie_power {
+ label = "power:pcie";
+ gpio-export,name = "mikrotik:power:pcie";
+ gpio-export,output = <1>;
+ gpios = < 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+ {
+ gpio_latch: gpio_latch {
+ compatible = "gpio-latch";
+ gpio-controller;
+
[RFC v2 1/3] ath79: add gpio-latch driver for Mikrotik RouterBoards
This is a slighty modified version of ar71xx gpio-latch driver
written by Gabor Juhos .
Changes:
* DTS support,
* New gpio API (gpiod_*).
Signed-off-by: Denis Kalashnikov
---
Changelog:
v1-->v2:
- Don't use MFD driver API anymore.
---
.../ath79/files/drivers/gpio/gpio-latch.c | 225 ++
.../patches-5.10/939-mikrotik-rb91x.patch | 25 ++
.../patches-5.4/939-mikrotik-rb91x.patch | 23 ++
3 files changed, 273 insertions(+)
create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c
create mode 100644 target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch
create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch
diff --git a/target/linux/ath79/files/drivers/gpio/gpio-latch.c
b/target/linux/ath79/files/drivers/gpio/gpio-latch.c
new file mode 100644
index 00..cb80b29052
--- /dev/null
+++ b/target/linux/ath79/files/drivers/gpio/gpio-latch.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * GPIO latch driver
+ *
+ * Copyright (C) 2014 Gabor Juhos
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GPIO_LATCH_DRIVER_NAME "gpio-latch"
+#define GPIO_LATCH_LINES 9
+
+struct gpio_latch_chip {
+ struct gpio_chip gc;
+ struct mutex mutex;
+ struct mutex latch_mutex;
+ bool latch_enabled;
+ int le_gpio;
+ bool le_active_low;
+ struct gpio_desc **gpios;
+};
+
+static inline struct gpio_latch_chip *to_gpio_latch_chip(struct gpio_chip *gc)
+{
+ return container_of(gc, struct gpio_latch_chip, gc);
+}
+
+static void gpio_latch_lock(struct gpio_latch_chip *glc, bool enable)
+{
+ mutex_lock(>mutex);
+
+ if (enable)
+ glc->latch_enabled = true;
+
+ if (glc->latch_enabled)
+ mutex_lock(>latch_mutex);
+}
+
+static void gpio_latch_unlock(struct gpio_latch_chip *glc, bool disable)
+{
+ if (glc->latch_enabled)
+ mutex_unlock(>latch_mutex);
+
+ if (disable)
+ glc->latch_enabled = true;
+
+ mutex_unlock(>mutex);
+}
+
+static int
+gpio_latch_get(struct gpio_chip *gc, unsigned offset)
+{
+ struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
+ int ret;
+
+ gpio_latch_lock(glc, false);
+ ret = gpiod_get_value(glc->gpios[offset]);
+ gpio_latch_unlock(glc, false);
+
+ return ret;
+}
+
+static void
+gpio_latch_set(struct gpio_chip *gc, unsigned offset, int value)
+{
+ struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
+ bool enable_latch = false;
+ bool disable_latch = false;
+
+ if (offset == glc->le_gpio) {
+ enable_latch = value ^ glc->le_active_low;
+ disable_latch = !enable_latch;
+ }
+
+ gpio_latch_lock(glc, enable_latch);
+ gpiod_set_value(glc->gpios[offset], value);
+ gpio_latch_unlock(glc, disable_latch);
+}
+
+static int
+gpio_latch_direction_input(struct gpio_chip *gc, unsigned offset)
+{
+ struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
+ int ret;
+
+ gpio_latch_lock(glc, false);
+ ret = gpiod_direction_input(glc->gpios[offset]);
+ gpio_latch_unlock(glc, false);
+
+ return ret;
+}
+
+static int
+gpio_latch_direction_output(struct gpio_chip *gc, unsigned offset, int value)
+{
+ struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
+ bool enable_latch = false;
+ bool disable_latch = false;
+ int ret;
+
+ if (offset == glc->le_gpio) {
+ enable_latch = value ^ glc->le_active_low;
+ disable_latch = !enable_latch;
+ }
+
+ gpio_latch_lock(glc, enable_latch);
+ ret = gpiod_direction_output(glc->gpios[offset], value);
+ gpio_latch_unlock(glc, disable_latch);
+
+ return ret;
+}
+
+static int gpio_latch_probe(struct platform_device *pdev)
+{
+ struct gpio_latch_chip *glc;
+ struct gpio_chip *gc;
+ struct device *dev = >dev;
+ struct device_node *of_node = dev->of_node;
+ struct gpio_descs *gpios;
+ int i;
+ enum of_gpio_flags flags;
+
+ glc = devm_kzalloc(dev, sizeof(*glc), GFP_KERNEL);
+ if (!glc)
+ return -ENOMEM;
+
+ mutex_init(>mutex);
+ mutex_init(>latch_mutex);
+
+ gpios = devm_gpiod_get_array(dev, NULL, 0);
+ if (IS_ERR(gpios)) {
+ dev_err(dev, "failed to get gpios: %d\n", (int)gpios);
+ return -EINVAL;
+ }
+ glc->gpios = gpios->desc;
+
+ if (gpios->ndescs != GPIO_LATCH_LINES) {
+ dev_err(dev, "gpios count must be %d\n", GPIO_LATCH_LINES);
+ return -EINVAL;
+ }
+
+ glc->le_gpio = of_get_named_gpio_flags(of_node, "latch-enable-gpios", 0,
+ );
+ if (glc->le_gpio < 0) {
+ dev_err(dev,
+ "could not read required 'latch-enable-gpios' property: %d\n",
+
[RFC 0/3] ath79: add support for Mikrotik RouterBoard 912G
In the first vertion of these patches I've added a MFD driver that provides API for manipulating shared gpio lines to gpio-latch and nand drivers. Now I just port gpio-latch and rb91x_nand drivers from ar71xx to ath79 by adding DTS support and new gpio API (gpiod_*). This way turned to be more clear and compact. All is working on my RB912UAG-2HPnD. Except a button and a beeper. The beeper seems is not important thing, but the button is. The button shares gpio 15 with NAND ALE and NAND IO7, but this is not easily supported by the current drivers. May be we need ad hoc driver for button. Or may be there is a more general solution for this problem. Nevertheless all other seems to be working. Denis Kalashnikov (3): ath79: add gpio-latch driver for Mikrotik RouterBoards ath79: add NAND driver for Mikrotik RB91xG series ath79: add support for Mikrotik RouterBoard 912G .../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++ .../ath79/files/drivers/gpio/gpio-latch.c | 225 ++ .../files/drivers/mtd/nand/raw/rb91x_nand.c | 414 ++ target/linux/ath79/image/mikrotik.mk | 9 + .../base-files/etc/board.d/02_network | 2 + .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 + .../base-files/lib/upgrade/platform.sh| 1 + target/linux/ath79/mikrotik/config-default| 1 + .../patches-5.10/939-mikrotik-rb91x.patch | 49 +++ .../patches-5.4/939-mikrotik-rb91x.patch | 44 ++ 10 files changed, 979 insertions(+) create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c create mode 100644 target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch -- 2.26.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Flagship AX routers
On Thu, May 20, 2021 at 11:26:58PM -0600, Philip Prindeville wrote: > > > > On May 18, 2021, at 10:57 PM, John Crispin wrote: > > > > On 19.05.21 00:09, Paul Spooren wrote: > >> Hi, > >> > >> On 5/18/21 11:52 PM, Philip Prindeville wrote: > >>> Hi all, > >>> > >>> I noticed that there are several AX routers from TP-Link, Netgear, > >>> D-Link, etc. and some of them have even had OpenWRT ported to them. > >>> > >>> Which of these various platforms has the most CPU/RAM/FLASH? A few are > >>> discussed, but I'm not seeing consensus on "the best one currently is > >>> this..." > >> > >> I'm using both a Belkin RT3200 and a Linksys AX3200 (aka E8450), which are > >> conveniently pretty much the same thing and I'm having a pretty good time. > >> Would flash again. > >> > >> Best, > >> Paul > >> > > > > this is the goto unit for AX right now ... > > > > https://openwrt.org/toh/linksys/linksys_e8450 > > > > consider using this to flash the unit > > > > https://github.com/dangowrt/linksys-e8450-openwrt-installer > > > > John > > > > > Thanks, both of you. > > Is that the one that only has USB 2.0, so if you wanted to add a hard drive > for NAS or DLNA, you're bandwidth limited? Yes, it got only USB 2.0, I guess because for USB 3.x you got to decide to either live with 2.4~2.5GHz interference (like most IPQ devices I've seen having USB 3.0 so far) or spend more for filters and evaluating a board design. It's definitely not meant to be a NAS, it's just an AP/Router, not even too useful as a modem-router (USB 2.0 port supplies only 500mAh afair). When using as dual-band AP, also the Gigabit Ethernet of the E8450 can become a bottle-kneck, UniFi 6 LR got that Aquantina 2.5GBase-T PHY (and also combines MT7622x with MT7915E, like the E8450). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: backport MediaTek jumbo frame support to 5.10
Allow MTU up to 2026 on mediatek, ramips/mt7621 targets
Signed-off-by: DENG Qingfang
---
...thernet-mediatek-support-setting-MTU.patch | 138 ++
...1-net-dsa-mt7530-support-setting-MTU.patch | 112 ++
...-dsa-mt7530-enable-MTU-normalization.patch | 36 +
3 files changed, 286 insertions(+)
create mode 100644
target/linux/generic/backport-5.10/604-v5.12-net-ethernet-mediatek-support-setting-MTU.patch
create mode 100644
target/linux/generic/backport-5.10/760-v5.11-net-dsa-mt7530-support-setting-MTU.patch
create mode 100644
target/linux/generic/backport-5.10/761-v5.11-net-dsa-mt7530-enable-MTU-normalization.patch
diff --git
a/target/linux/generic/backport-5.10/604-v5.12-net-ethernet-mediatek-support-setting-MTU.patch
b/target/linux/generic/backport-5.10/604-v5.12-net-ethernet-mediatek-support-setting-MTU.patch
new file mode 100644
index 00..8b995f817d
--- /dev/null
+++
b/target/linux/generic/backport-5.10/604-v5.12-net-ethernet-mediatek-support-setting-MTU.patch
@@ -0,0 +1,138 @@
+From 4fd59792097a6b2fb949d41264386a7ecade469e Mon Sep 17 00:00:00 2001
+From: DENG Qingfang
+Date: Mon, 25 Jan 2021 12:20:46 +0800
+Subject: [PATCH] net: ethernet: mediatek: support setting MTU
+
+MT762x HW, except for MT7628, supports frame length up to 2048
+(maximum length on GDM), so allow setting MTU up to 2030.
+
+Also set the default frame length to the hardware default 1518.
+
+Signed-off-by: DENG Qingfang
+Reviewed-by: Andrew Lunn
+Link: https://lore.kernel.org/r/20210125042046.5599-1-dqf...@gmail.com
+Signed-off-by: Jakub Kicinski
+---
+ drivers/net/ethernet/mediatek/mtk_eth_soc.c | 43 ++---
+ drivers/net/ethernet/mediatek/mtk_eth_soc.h | 12 --
+ 2 files changed, 47 insertions(+), 8 deletions(-)
+
+--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+@@ -353,7 +353,7 @@ static void mtk_mac_config(struct phylin
+ /* Setup gmac */
+ mcr_cur = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
+ mcr_new = mcr_cur;
+- mcr_new |= MAC_MCR_MAX_RX_1536 | MAC_MCR_IPG_CFG | MAC_MCR_FORCE_MODE |
++ mcr_new |= MAC_MCR_IPG_CFG | MAC_MCR_FORCE_MODE |
+ MAC_MCR_BACKOFF_EN | MAC_MCR_BACKPR_EN | MAC_MCR_FORCE_LINK;
+
+ /* Only update control register when needed! */
+@@ -759,8 +759,8 @@ static void mtk_get_stats64(struct net_d
+ static inline int mtk_max_frag_size(int mtu)
+ {
+ /* make sure buf_size will be at least MTK_MAX_RX_LENGTH */
+- if (mtu + MTK_RX_ETH_HLEN < MTK_MAX_RX_LENGTH)
+- mtu = MTK_MAX_RX_LENGTH - MTK_RX_ETH_HLEN;
++ if (mtu + MTK_RX_ETH_HLEN < MTK_MAX_RX_LENGTH_2K)
++ mtu = MTK_MAX_RX_LENGTH_2K - MTK_RX_ETH_HLEN;
+
+ return SKB_DATA_ALIGN(MTK_RX_HLEN + mtu) +
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+@@ -771,7 +771,7 @@ static inline int mtk_max_buf_size(int f
+ int buf_size = frag_size - NET_SKB_PAD - NET_IP_ALIGN -
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+
+- WARN_ON(buf_size < MTK_MAX_RX_LENGTH);
++ WARN_ON(buf_size < MTK_MAX_RX_LENGTH_2K);
+
+ return buf_size;
+ }
+@@ -2499,6 +2499,35 @@ static void mtk_uninit(struct net_device
+ mtk_rx_irq_disable(eth, ~0);
+ }
+
++static int mtk_change_mtu(struct net_device *dev, int new_mtu)
++{
++ int length = new_mtu + MTK_RX_ETH_HLEN;
++ struct mtk_mac *mac = netdev_priv(dev);
++ struct mtk_eth *eth = mac->hw;
++ u32 mcr_cur, mcr_new;
++
++ if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628)) {
++ mcr_cur = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
++ mcr_new = mcr_cur & ~MAC_MCR_MAX_RX_MASK;
++
++ if (length <= 1518)
++ mcr_new |= MAC_MCR_MAX_RX(MAC_MCR_MAX_RX_1518);
++ else if (length <= 1536)
++ mcr_new |= MAC_MCR_MAX_RX(MAC_MCR_MAX_RX_1536);
++ else if (length <= 1552)
++ mcr_new |= MAC_MCR_MAX_RX(MAC_MCR_MAX_RX_1552);
++ else
++ mcr_new |= MAC_MCR_MAX_RX(MAC_MCR_MAX_RX_2048);
++
++ if (mcr_new != mcr_cur)
++ mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
++ }
++
++ dev->mtu = new_mtu;
++
++ return 0;
++}
++
+ static int mtk_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
+ {
+ struct mtk_mac *mac = netdev_priv(dev);
+@@ -2795,6 +2824,7 @@ static const struct net_device_ops mtk_n
+ .ndo_set_mac_address= mtk_set_mac_address,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_do_ioctl = mtk_do_ioctl,
++ .ndo_change_mtu = mtk_change_mtu,
+ .ndo_tx_timeout = mtk_tx_timeout,
+ .ndo_get_stats64= mtk_get_stats64,
+ .ndo_fix_features = mtk_fix_features,
+@@ -2896,7 +2926,10 @@ static int mtk_add_mac(struct mtk_eth *e
+ eth->netdev[id]->irq =
