Re: [PATCH] kernel: force atomic renames in ubifs
Hi Richard, On 1.03.2022 20:37, Richard Weinberger wrote: - Ursprüngliche Mail - Von: "Rafał Miłecki" An: "OpenWrt Development List" CC: "Koen Vandeputte" , "richard" , "Rafał Miłecki" Gesendet: Dienstag, 1. März 2022 20:13:29 Betreff: [PATCH] kernel: force atomic renames in ubifs From: Rafał Miłecki This deals with user-spaces apps that don't handle all syncing correctly. It prevents user ending up with an empty file. Signed-off-by: Rafał Miłecki --- .../510-ubifs-force-atomic-renames.patch | 46 +++ .../510-ubifs-force-atomic-renames.patch | 46 +++ 2 files changed, 92 insertions(+) create mode 100644 target/linux/generic/pending-5.10/510-ubifs-force-atomic-renames.patch create mode 100644 target/linux/generic/pending-5.4/510-ubifs-force-atomic-renames.patch diff --git a/target/linux/generic/pending-5.10/510-ubifs-force-atomic-renames.patch b/target/linux/generic/pending-5.10/510-ubifs-force-atomic-renames.patch new file mode 100644 index 00..80f5f1b910 --- /dev/null +++ b/target/linux/generic/pending-5.10/510-ubifs-force-atomic-renames.patch @@ -0,0 +1,46 @@ +From: Richard Weinberger +Date: Mon, 28 Feb 2022 16:07:41 +0100 +Subject: [PATCH] ubifs: force atomic renames +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Before actual rename make sure that the old inode data has been flash +written. This is similar to what other filesystems do and workarounds +bugs in some user-space apps. + +With this change updating file using tmpfile & rename() will never +result in losing all content e.g. on power cut. Please slow down a bit. :-) The commit message is not written by me and also not entirely correct. The patch is not about making rename atomic. rename is already atomic on UBIFS. It is about syncing in flight pages when a file is overwritten by rename. While I plan to upstream this change it still needs more testing. I'm also not sure about the overhead it causes. Flushing the write buffers can cause more garbage collection and may trigger write amplification. I didn't end up pushing this change to OpenWrt since your e-mail. I use it however in my project in production in thousands of devices. I'd very much like to see a proper change upstream. Could you take a look at it, please? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Battlemesh x OpenWrt meeting in Cyprus?
Hi Everyone, On Sat, Nov 25, 2023 at 05:14:30PM +0100, Hauke Mehrtens wrote: > Hi Arınç and Paul, > > Thank you Arınç for organizing the Battlemesh in Cyprus. > > I will probably join the Battlemesh again, but I wont have much time to > organize stuff. > > The following dates are currently proposed: > May 15 - 19 > May 22 - 26 > Wednesday - Sunday, 5 days. > > Everyone who wants to join, please take part in the poll: > https://framadate.org/M4I9AYvKYypQTmGB > > It is hard to get people together. I would suggest to plan an OpenWrt track > on the last 2 days of Battlemesh in parallel. > > Who would like to join? I think that a dedicated OpenWrt meeting like in 2019 would be very good, like a mini-summit for OpenWrt devs to present ongoing work and recent achievements, but also just meet and talk in person and possibly even ending up hacking on stuff together. An official invitation to the OpenWrt meeting/mini-summit and endorsement of Battlemesh should happen early via all OpenWrt channels (*-adm mailing list, IRC, Web, Forums). Also, as it's going to be OpenWrt's 20th anniversary in 2024, we should use that opportunity to also reach out to a wider audience, ie. prepare some more layer 8/9 talks about the OpenWrt project or the role of free software in the context of both, protocol research and grassroots networks. I'm ready to be involved in organizational aspects and also take care of reaching out to the wider community once we decided on the date. Cheers Daniel > > Hauke > > On 11/25/23 12:59, Arınç ÜNAL wrote: > > Hello! > > > > I am the head organiser of the next Battlemesh. I will also be involved > > the most on organising the OpenWrt summit. Let me know if you've got any > > questions. My website from my email address includes the channels other > > than email to reach me more easily. > > > > Arınç > > > > On 23 November 2023 23:54:16 EET, Paul Spooren wrote: > > > Hi all, > > > > > > While attending this years Battlemesh in Spain some fellow mesh people > > > asked why there weren’t more OpenWrt people around. I’m guessing it was > > > mostly due to the lack of communication in advance, so I’d like to raise > > > the topic here: Are people from the OpenWrt community, specially members > > > and maintainers interested in collaborating with and attending the > > > Battlemesh next year? > > > > > > They’d do most of the heavy lifting and would offer us to take some > > > slots/space to do our own little OpenWrt meeting (remember the good and > > > productive days in Hamburg anno 2019). Ideally at least one OpenWrt > > > member would join their organizing team, I could do it but would also be > > > happy if someone else jumps in. > > > > > > The general idea is to have a week long Battlemesh event in Cyprus, the > > > OpenWrt part could happen both within the week, before or after, the full > > > length or only a weekend etc. To my knowledge Cyprus offers an easier > > > VISA process so more folks could join, I remember last time people > > > wouldn’t get a VISA in time. > > > > > > If we participate we should raise some donations to offer travel stipends > > > and come up with some (lighting) talks and presentations. > > > > > > I think the timeframe is “somewhen in May 2024”, this will be further > > > discussed on the Battlemesh mailing list. > > > > > > Looking forward to meet you all again! > > > > > > 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
[sdwalker/sdwalker.github.io] 12bc2b: This week's update
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 --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 12bc2b6ba9ce70d746b2b452a149a9ccab153e39 https://github.com/sdwalker/sdwalker.github.io/commit/12bc2b6ba9ce70d746b2b452a149a9ccab153e39 Author: Stephen Walker Date: 2023-11-26 (Sun, 26 Nov 2023) Changed paths: M uscan/index-22.03.html M uscan/index-23.05.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] uhttpd: uhttpd-mod-ubus: reload uhttpd only if it's runtime install
From: Rafał Miłecki
Reloading service from uci-defaults script is a hack to workaround
postinst limitation. It should not be executed during boot as other
uci-defaults scripts may want to adjust uhttpd's config too.
Cc: Hauke Mehrtens
Fixes: d25d281fd668 ("uhttpd: Reload config after uhttpd-mod-ubus was added")
Signed-off-by: Rafał Miłecki
---
package/network/services/uhttpd/Makefile | 2 +-
package/network/services/uhttpd/files/ubus.default | 13 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/package/network/services/uhttpd/Makefile
b/package/network/services/uhttpd/Makefile
index 02a02405fd..9405070626 100644
--- a/package/network/services/uhttpd/Makefile
+++ b/package/network/services/uhttpd/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=uhttpd
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/uhttpd.git
diff --git a/package/network/services/uhttpd/files/ubus.default
b/package/network/services/uhttpd/files/ubus.default
index 474016c1c5..e2240a1018 100644
--- a/package/network/services/uhttpd/files/ubus.default
+++ b/package/network/services/uhttpd/files/ubus.default
@@ -12,6 +12,17 @@ fi
commit=1
}
-[ "$commit" = 1 ] && uci commit uhttpd && /etc/init.d/uhttpd reload
+# Normally (when executing this script during boot) we want to adjust config
+# only. Actual uhttpd start will happen later.
+#
+# If this is package installation in a running system however then we need to
+# reload uhttpd to make ubus access work right after. Ideally this should be
+# handled by a "postinst" script but those get executed *before* uci-defaults
+# scripts. For that reason we abuse uci-defaults to call init.d script.
+#
+# Check for $PKG_ROOT to detect "opkg install" case in a running system.
+if [ -n "$PKG_ROOT" ]; then
+ [ "$commit" = 1 ] && uci commit uhttpd && /etc/init.d/uhttpd reload
+fi
exit 0
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RFC] base-files: execute package's "postinst" after executing uci-defaults
From: Rafał Miłecki
With this change "postinst" scripts can perform extra actions after
applying all kind of fixups implemented using uci-defaults.
This is needed e.g. by uhttpd-mod-ubus which after installation in a
running systems needs to:
1. Update uhttpd config using its uci-defaults script
2. Reload uhttpd
Cc: Hauke Mehrtens
Signed-off-by: Rafał Miłecki
---
I noticed that kind of hacky code was added in the commit d25d281fd668
("uhttpd: Reload config after uhttpd-mod-ubus was added") to reload
uhttpd after "opkg install". It abuses uci-defaults script to call
init.d script. It's a wrong idea as uci-defaults should run before
running services during first boot. It doesn't allow further config
adjustments by other uci-defaults as uhttpd gets started early.
This change would allow moving uhttpd-mod-ubus's reload to postinst.
The question is: can this change break anything?
package/base-files/files/lib/functions.sh | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/package/base-files/files/lib/functions.sh
b/package/base-files/files/lib/functions.sh
index d9628dbb7a..851d2f1791 100644
--- a/package/base-files/files/lib/functions.sh
+++ b/package/base-files/files/lib/functions.sh
@@ -270,11 +270,6 @@ default_postinst() {
add_group_and_user "${pkgname}"
- if [ -f "$root/usr/lib/opkg/info/${pkgname}.postinst-pkg" ]; then
- ( . "$root/usr/lib/opkg/info/${pkgname}.postinst-pkg" )
- ret=$?
- fi
-
if [ -d "$root/rootfs-overlay" ]; then
cp -R $root/rootfs-overlay/. $root/
rm -fR $root/rootfs-overlay/
@@ -300,6 +295,11 @@ default_postinst() {
rm -f /tmp/luci-indexcache
fi
+ if [ -f "$root/usr/lib/opkg/info/${pkgname}.postinst-pkg" ]; then
+ ( . "$root/usr/lib/opkg/info/${pkgname}.postinst-pkg" )
+ ret=$?
+ fi
+
local shell="$(command -v bash)"
for i in $(grep -s "^/etc/init.d/" "$root$filelist"); do
if [ -n "$root" ]; then
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH V2] mediatek: filogic: add support for GL.iNet GL-MT2500
The GL-MT2500 is a Security Gateway based on MediaTek MT7981. It comes in
two variants: one with a plastic case, the other with an alluminium one. Both
variants run the same firmware.
Hardware specifications:
- SoC: MediaTek MT7981B
- CPU: 2x 1.3 GHz Cortex-A53
- Flash: 8GB EMMC
- RAM: 1 GB
- Ethernet:
- 1x 10/100/1000 Mbps built-in PHY (LAN)
- 1x 10/100/1000/2500 Mbps MaxLinear GPY211 PHY (WAN)
- USB 3.0 port
- Buttons: RESET button
- LEDs: 1x light-blue, 1x warm-white, 1x VPN
- Serial console: internal 4-pin header, 115200 8n1
- Power: 5 VDC, 3 A (USB Type-C)
MAC addresses assignment:
The label on the back of the device reports WAN (eth0) interface MAC address.
LAN interface (eth1) has WAN MAC address incremented by 1.
Installation:
-
Method 1 - via GL.iNet bootloader web failsafe UI
1. Connect to the LAN interface of the device (the one that's farther from
USB-C power supply connector).
2. Assign static IP 192.168.1.2/24 to the host.
3. Hold the reset button for at least 5 seconds while powering on the device.
If all went well, the bootloader should be responding to ICMP ping packets
and listening for web connections at 192.168.1.1. Upload the
*sysupgrade-squashfs image, then press the Update button. The device should
restart to OpenWrt.
Method 2 - via UART connection
1. Connect to device serial port.
2. Interrupt the boot process typing "gl".
3. Connect your host to the LAN port of the device and assign it static IP
192.168.1.2/24.
4. Start a TFTP server in your artifacts folder (e.g.:
openwrt/bin/targets/mediatek/filogic).
5. In the bootloader, issue these commands:
tftpboot openwrt-mediatek-filogic-glinet_gl-mt2500-initramfs-kernel.bin && bootm
this should bring you to the OpenWrt prompt where you can transfer a
sysupgrade image and proceed with the usual sysupgrade process.
Notes
-
1. This port might not work on all hardware samples: in some cases, the unit
might just hang when probing EMMC.
2. The U-Boot environment might not be populated (empty EMMC partition) until
a "saveenv" command is issued. Do not initialize the environment from within
OpenWrt as this might cause problems due to the fact fw_printenv's default env
will not match the vendor's U-Boot one.
Untested features
-
Flashing from stock web UI wasn't tested, but is expected to work, being stock
firmware shipped as a sysupgrade tar image as well.
Furthermore, going back to stock firmware wasn't tested, but should be possible
via U-Boot failsafe web UI.
CREDITS
--
Daniel Golle did the hard part of this port, so thank you!
Signed-off-by: Daniel Golle
Signed-off-by: Enrico Mioso
---
.../uboot-envtools/files/mediatek_filogic | 1 +
.../mediatek/dts/mt7981b-glinet-gl-mt2500.dts | 149 ++
.../filogic/base-files/etc/board.d/02_network | 6 +
.../base-files/lib/upgrade/platform.sh| 2 +
target/linux/mediatek/image/filogic.mk| 11 ++
5 files changed, 169 insertions(+)
create mode 100644 target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
diff --git a/package/boot/uboot-envtools/files/mediatek_filogic
b/package/boot/uboot-envtools/files/mediatek_filogic
index ae8e1589a0..d678e1fcbd 100644
--- a/package/boot/uboot-envtools/files/mediatek_filogic
+++ b/package/boot/uboot-envtools/files/mediatek_filogic
@@ -77,6 +77,7 @@ xiaomi,redmi-router-ax6000-ubootmod)
glinet,gl-mt3000)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x8" "0x2"
;;
+glinet,gl-mt2500|\
glinet,gl-mt6000)
local envdev=$(find_mmc_part "u-boot-env")
ubootenv_add_uci_config "$envdev" "0x0" "0x8"
diff --git a/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
new file mode 100644
index 00..0287fb7bc0
--- /dev/null
+++ b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
@@ -0,0 +1,149 @@
+/dts-v1/;
+#include "mt7981.dtsi"
+/ {
+ model = "GL.iNet GL-MT2500";
+ compatible = "glinet,gl-mt2500", "mediatek,mt7981";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs-append = " root=PARTLABEL=rootfs rootwait";
+ };
+
+ aliases {
+ led-boot = _blue;
+ led-failsafe = _blue;
+ led-running = _white;
+ led-upgrade = _blue;
+ serial0 =
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 1 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ gpio-export {
+
Re: Battlemesh x OpenWrt meeting in Cyprus?
I've just created a poll to decide the OpenWrt summit dates, see below. I also aim to see how many people are interested in the summit with this poll so please vote to decide the dates for the OpenWrt summit. https://framadate.org/oGXhCQkygdpXGiTh The "with Battlemesh" option represents the suggestion Hauke has made, the last 2 days of Battlemesh in parallel. Beware if you're on mobile, there are 6 choices. On 11/25/23 18:14, Hauke Mehrtens wrote: Hi Arınç and Paul, Thank you Arınç for organizing the Battlemesh in Cyprus. I will probably join the Battlemesh again, but I wont have much time to organize stuff. The following dates are currently proposed: May 15 - 19 May 22 - 26 Wednesday - Sunday, 5 days. Everyone who wants to join, please take part in the poll: https://framadate.org/M4I9AYvKYypQTmGB It is hard to get people together. I would suggest to plan an OpenWrt track on the last 2 days of Battlemesh in parallel. Who would like to join? Hauke On 11/25/23 12:59, Arınç ÜNAL wrote: Hello! I am the head organiser of the next Battlemesh. I will also be involved the most on organising the OpenWrt summit. Let me know if you've got any questions. My website from my email address includes the channels other than email to reach me more easily. Arınç On 23 November 2023 23:54:16 EET, Paul Spooren wrote: Hi all, While attending this years Battlemesh in Spain some fellow mesh people asked why there weren’t more OpenWrt people around. I’m guessing it was mostly due to the lack of communication in advance, so I’d like to raise the topic here: Are people from the OpenWrt community, specially members and maintainers interested in collaborating with and attending the Battlemesh next year? They’d do most of the heavy lifting and would offer us to take some slots/space to do our own little OpenWrt meeting (remember the good and productive days in Hamburg anno 2019). Ideally at least one OpenWrt member would join their organizing team, I could do it but would also be happy if someone else jumps in. The general idea is to have a week long Battlemesh event in Cyprus, the OpenWrt part could happen both within the week, before or after, the full length or only a weekend etc. To my knowledge Cyprus offers an easier VISA process so more folks could join, I remember last time people wouldn’t get a VISA in time. If we participate we should raise some donations to offer travel stipends and come up with some (lighting) talks and presentations. I think the timeframe is “somewhen in May 2024”, this will be further discussed on the Battlemesh mailing list. Looking forward to meet you all again! Sunshine, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mediatek: filogic: add support for GL.iNet GL-MT2500
On Sun, Nov 26, 2023 at 03:35:09PM +, Daniel Golle wrote:
> Hi Enrico,
>
> thank you for advancing with support for this device!
>
> See comments inline, mostly about left-overs from earlier draft
> implementations of nvmem-on-MMC.
>
> On Sun, Nov 26, 2023 at 04:11:13PM +0100, Enrico Mioso wrote:
> > The GL-MT2500 is a Security Gateway based on MediaTek MT7981. It comes in
> > two variants: one with a plastic case, the other with an alluminium one.
> > Both
> > variants run the same firmware.
> >
> > Hardware specifications:
> > - SoC: MediaTek MT7981B
> > - CPU: 2x 1.3 GHz Cortex-A53
> > - Flash: 8GB EMMC
> > - RAM: 1 GB
> > - Ethernet:
> > - 1x 10/100/1000 Mbps built-in PHY (LAN)
> > - 1x 10/100/1000/2500 Mbps MaxLinear GPY211 PHY (WAN)
> > - USB 3.0 port
> > - Buttons: RESET button
> > - LEDs: 1x light-blue, 1x warm-white, 1x VPN
> > - Serial console: internal 4-pin header, 115200 8n1
> > - Power: 5 VDC, 3 A (USB Type-C)
> >
> > MAC addresses assignment:
> > The label on the back of the device reports WAN (eth0) interface MAC
> > address.
> > LAN interface (eth1) has WAN MAC address incremented by 1.
> >
> > Installation:
> > -
> > Method 1 - via GL.iNet bootloader web failsafe UI
> > 1. Connect to the LAN interface of the device (the one that's farther from
> > USB-C power supply connector).
> > 2. Assign static IP 192.168.1.2/24 to the host.
> > 3. Hold the reset button for at least 5 seconds while powering on the
> > device.
> > If all went well, the bootloader should be responding to ICMP ping packets
> > and listening for web connections at 192.168.1.1. Upload the
> > *sysupgrade-squashfs image, then press the Update button. The device should
> > restart to OpenWrt.
> >
> > Method 2 - via UART connection
> > 1. Connect to device serial port.
> > 2. Interrupt the boot process typing "gl".
> > 3. Connect your host to the LAN port of the device and assign it static IP
> > 192.168.1.2/24.
> > 4. Start a TFTP server in your artifacts folder (e.g.:
> > openwrt/bin/targets/mediatek/filogic).
> > 5. In the bootloader, issue these commands:
> > tftpboot openwrt-mediatek-filogic-glinet_gl-mt2500-initramfs-kernel.bin &&
> > bootm
> > this should bring you to the OpenWrt prompt where you can transfer a
> > sysupgrade image and proceed with the usual sysupgrade process.
> >
> > Notes
> > -
> > 1. This port might not work on all hardware samples: in some cases, the unit
> > might just hang when probing EMMC.
> > 2. The U-Boot environment might not be populated (empty EMMC partition)
> > until
> > a "saveenv" command is issued. Do not initialize the environment from within
> > OpenWrt as this might cause problems due to the fact fw_printenv's default
> > env
> > will not match the vendor's U-Boot one.
> >
> > Untested features
> > -
> > Flashing from stock web UI wasn't tested, but is expected to work, being
> > stock
> > firmware shipped as a sysupgrade tar image as well.
> > Furthermore, going back to stock firmware wasn't tested, but should be
> > possible
> > via U-Boot failsafe web UI.
> >
> > CREDITS
> > --
> > Daniel Golle did the hard part of this port, so thank you!
> >
> > Signed-off-by: Daniel Golle
> > Signed-off-by: Enrico Mioso
> > ---
> > .../uboot-envtools/files/mediatek_filogic | 1 +
> > .../mediatek/dts/mt7981b-glinet-gl-mt2500.dts | 209 ++
> > .../filogic/base-files/etc/board.d/02_network | 6 +
> > .../base-files/lib/upgrade/platform.sh| 2 +
> > target/linux/mediatek/image/filogic.mk| 11 +
> > 5 files changed, 229 insertions(+)
> > create mode 100644 target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> >
> > diff --git a/package/boot/uboot-envtools/files/mediatek_filogic
> > b/package/boot/uboot-envtools/files/mediatek_filogic
> > index ae8e1589a0..d678e1fcbd 100644
> > --- a/package/boot/uboot-envtools/files/mediatek_filogic
> > +++ b/package/boot/uboot-envtools/files/mediatek_filogic
> > @@ -77,6 +77,7 @@ xiaomi,redmi-router-ax6000-ubootmod)
> > glinet,gl-mt3000)
> > ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x8" "0x2"
> > ;;
> > +glinet,gl-mt2500|\
> > glinet,gl-mt6000)
> > local envdev=$(find_mmc_part "u-boot-env")
> > ubootenv_add_uci_config "$envdev" "0x0" "0x8"
> > diff --git a/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> > b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> > new file mode 100644
> > index 00..58d4200d6c
> > --- /dev/null
> > +++ b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> > @@ -0,0 +1,209 @@
> > +/dts-v1/;
> > +#include "mt7981.dtsi"
> > +/ {
> > + model = "GL.iNet GL-MT2500";
> > + compatible = "glinet,gl-mt2500", "mediatek,mt7981";
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + bootargs-append = " root=PARTLABEL=rootfs rootwait";
> > + };
> > +
> > + aliases {
> > + led-boot = _blue;
> > + led-failsafe
Re: [PATCH] mediatek: filogic: add support for GL.iNet GL-MT2500
Hi Enrico,
thank you for advancing with support for this device!
See comments inline, mostly about left-overs from earlier draft
implementations of nvmem-on-MMC.
On Sun, Nov 26, 2023 at 04:11:13PM +0100, Enrico Mioso wrote:
> The GL-MT2500 is a Security Gateway based on MediaTek MT7981. It comes in
> two variants: one with a plastic case, the other with an alluminium one. Both
> variants run the same firmware.
>
> Hardware specifications:
> - SoC: MediaTek MT7981B
> - CPU: 2x 1.3 GHz Cortex-A53
> - Flash: 8GB EMMC
> - RAM: 1 GB
> - Ethernet:
> - 1x 10/100/1000 Mbps built-in PHY (LAN)
> - 1x 10/100/1000/2500 Mbps MaxLinear GPY211 PHY (WAN)
> - USB 3.0 port
> - Buttons: RESET button
> - LEDs: 1x light-blue, 1x warm-white, 1x VPN
> - Serial console: internal 4-pin header, 115200 8n1
> - Power: 5 VDC, 3 A (USB Type-C)
>
> MAC addresses assignment:
> The label on the back of the device reports WAN (eth0) interface MAC address.
> LAN interface (eth1) has WAN MAC address incremented by 1.
>
> Installation:
> -
> Method 1 - via GL.iNet bootloader web failsafe UI
> 1. Connect to the LAN interface of the device (the one that's farther from
> USB-C power supply connector).
> 2. Assign static IP 192.168.1.2/24 to the host.
> 3. Hold the reset button for at least 5 seconds while powering on the device.
> If all went well, the bootloader should be responding to ICMP ping packets
> and listening for web connections at 192.168.1.1. Upload the
> *sysupgrade-squashfs image, then press the Update button. The device should
> restart to OpenWrt.
>
> Method 2 - via UART connection
> 1. Connect to device serial port.
> 2. Interrupt the boot process typing "gl".
> 3. Connect your host to the LAN port of the device and assign it static IP
> 192.168.1.2/24.
> 4. Start a TFTP server in your artifacts folder (e.g.:
> openwrt/bin/targets/mediatek/filogic).
> 5. In the bootloader, issue these commands:
> tftpboot openwrt-mediatek-filogic-glinet_gl-mt2500-initramfs-kernel.bin &&
> bootm
> this should bring you to the OpenWrt prompt where you can transfer a
> sysupgrade image and proceed with the usual sysupgrade process.
>
> Notes
> -
> 1. This port might not work on all hardware samples: in some cases, the unit
> might just hang when probing EMMC.
> 2. The U-Boot environment might not be populated (empty EMMC partition) until
> a "saveenv" command is issued. Do not initialize the environment from within
> OpenWrt as this might cause problems due to the fact fw_printenv's default env
> will not match the vendor's U-Boot one.
>
> Untested features
> -
> Flashing from stock web UI wasn't tested, but is expected to work, being stock
> firmware shipped as a sysupgrade tar image as well.
> Furthermore, going back to stock firmware wasn't tested, but should be
> possible
> via U-Boot failsafe web UI.
>
> CREDITS
> --
> Daniel Golle did the hard part of this port, so thank you!
>
> Signed-off-by: Daniel Golle
> Signed-off-by: Enrico Mioso
> ---
> .../uboot-envtools/files/mediatek_filogic | 1 +
> .../mediatek/dts/mt7981b-glinet-gl-mt2500.dts | 209 ++
> .../filogic/base-files/etc/board.d/02_network | 6 +
> .../base-files/lib/upgrade/platform.sh| 2 +
> target/linux/mediatek/image/filogic.mk| 11 +
> 5 files changed, 229 insertions(+)
> create mode 100644 target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
>
> diff --git a/package/boot/uboot-envtools/files/mediatek_filogic
> b/package/boot/uboot-envtools/files/mediatek_filogic
> index ae8e1589a0..d678e1fcbd 100644
> --- a/package/boot/uboot-envtools/files/mediatek_filogic
> +++ b/package/boot/uboot-envtools/files/mediatek_filogic
> @@ -77,6 +77,7 @@ xiaomi,redmi-router-ax6000-ubootmod)
> glinet,gl-mt3000)
> ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x8" "0x2"
> ;;
> +glinet,gl-mt2500|\
> glinet,gl-mt6000)
> local envdev=$(find_mmc_part "u-boot-env")
> ubootenv_add_uci_config "$envdev" "0x0" "0x8"
> diff --git a/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> new file mode 100644
> index 00..58d4200d6c
> --- /dev/null
> +++ b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> @@ -0,0 +1,209 @@
> +/dts-v1/;
> +#include "mt7981.dtsi"
> +/ {
> + model = "GL.iNet GL-MT2500";
> + compatible = "glinet,gl-mt2500", "mediatek,mt7981";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + bootargs-append = " root=PARTLABEL=rootfs rootwait";
> + };
> +
> + aliases {
> + led-boot = _blue;
> + led-failsafe = _blue;
> + led-running = _white;
> + led-upgrade = _blue;
> + serial0 =
> + };
> +
> + reg_3p3v: regulator-3p3v {
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-3.3V";
> + regulator-min-microvolt =
[PATCH] mediatek: filogic: add support for GL.iNet GL-MT2500
The GL-MT2500 is a Security Gateway based on MediaTek MT7981. It comes in
two variants: one with a plastic case, the other with an alluminium one. Both
variants run the same firmware.
Hardware specifications:
- SoC: MediaTek MT7981B
- CPU: 2x 1.3 GHz Cortex-A53
- Flash: 8GB EMMC
- RAM: 1 GB
- Ethernet:
- 1x 10/100/1000 Mbps built-in PHY (LAN)
- 1x 10/100/1000/2500 Mbps MaxLinear GPY211 PHY (WAN)
- USB 3.0 port
- Buttons: RESET button
- LEDs: 1x light-blue, 1x warm-white, 1x VPN
- Serial console: internal 4-pin header, 115200 8n1
- Power: 5 VDC, 3 A (USB Type-C)
MAC addresses assignment:
The label on the back of the device reports WAN (eth0) interface MAC address.
LAN interface (eth1) has WAN MAC address incremented by 1.
Installation:
-
Method 1 - via GL.iNet bootloader web failsafe UI
1. Connect to the LAN interface of the device (the one that's farther from
USB-C power supply connector).
2. Assign static IP 192.168.1.2/24 to the host.
3. Hold the reset button for at least 5 seconds while powering on the device.
If all went well, the bootloader should be responding to ICMP ping packets
and listening for web connections at 192.168.1.1. Upload the
*sysupgrade-squashfs image, then press the Update button. The device should
restart to OpenWrt.
Method 2 - via UART connection
1. Connect to device serial port.
2. Interrupt the boot process typing "gl".
3. Connect your host to the LAN port of the device and assign it static IP
192.168.1.2/24.
4. Start a TFTP server in your artifacts folder (e.g.:
openwrt/bin/targets/mediatek/filogic).
5. In the bootloader, issue these commands:
tftpboot openwrt-mediatek-filogic-glinet_gl-mt2500-initramfs-kernel.bin && bootm
this should bring you to the OpenWrt prompt where you can transfer a
sysupgrade image and proceed with the usual sysupgrade process.
Notes
-
1. This port might not work on all hardware samples: in some cases, the unit
might just hang when probing EMMC.
2. The U-Boot environment might not be populated (empty EMMC partition) until
a "saveenv" command is issued. Do not initialize the environment from within
OpenWrt as this might cause problems due to the fact fw_printenv's default env
will not match the vendor's U-Boot one.
Untested features
-
Flashing from stock web UI wasn't tested, but is expected to work, being stock
firmware shipped as a sysupgrade tar image as well.
Furthermore, going back to stock firmware wasn't tested, but should be possible
via U-Boot failsafe web UI.
CREDITS
--
Daniel Golle did the hard part of this port, so thank you!
Signed-off-by: Daniel Golle
Signed-off-by: Enrico Mioso
---
.../uboot-envtools/files/mediatek_filogic | 1 +
.../mediatek/dts/mt7981b-glinet-gl-mt2500.dts | 209 ++
.../filogic/base-files/etc/board.d/02_network | 6 +
.../base-files/lib/upgrade/platform.sh| 2 +
target/linux/mediatek/image/filogic.mk| 11 +
5 files changed, 229 insertions(+)
create mode 100644 target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
diff --git a/package/boot/uboot-envtools/files/mediatek_filogic
b/package/boot/uboot-envtools/files/mediatek_filogic
index ae8e1589a0..d678e1fcbd 100644
--- a/package/boot/uboot-envtools/files/mediatek_filogic
+++ b/package/boot/uboot-envtools/files/mediatek_filogic
@@ -77,6 +77,7 @@ xiaomi,redmi-router-ax6000-ubootmod)
glinet,gl-mt3000)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x8" "0x2"
;;
+glinet,gl-mt2500|\
glinet,gl-mt6000)
local envdev=$(find_mmc_part "u-boot-env")
ubootenv_add_uci_config "$envdev" "0x0" "0x8"
diff --git a/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
new file mode 100644
index 00..58d4200d6c
--- /dev/null
+++ b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
@@ -0,0 +1,209 @@
+/dts-v1/;
+#include "mt7981.dtsi"
+/ {
+ model = "GL.iNet GL-MT2500";
+ compatible = "glinet,gl-mt2500", "mediatek,mt7981";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs-append = " root=PARTLABEL=rootfs rootwait";
+ };
+
+ aliases {
+ led-boot = _blue;
+ led-failsafe = _blue;
+ led-running = _white;
+ led-upgrade = _blue;
+ serial0 =
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 1 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ gpio-export {
+
