Note to GL-MT2500 OpenWrt-based U-Boot users and some questions

Tue Dec 30 09:28:05 PST 2025

Hello All,

this message is to inform you that the OpenWrt-based U-Boot port for the GL-MT2500 (Brume2) device works as expected on the new design with Airoha PHY as well, and to clarify some aspects (see questions below).
For now, some environment tweaks may be appropriate, in particular regarding variables referencing file names, even tough a -factory file is currently not provided.
In my case, I just tweaked the bootfile env variable to be able to easily recover my device and booting it via TFTP by default.
The same installation instructions as outlined in commit 4ff02b46b9379bb19747636cdb6984b026ac62a9 should apply, but for a more streamlined experience I suggest waiting for a different U-Boot build to be available.
The same restrictions apply here as well, so you will be able to use the device's LAN port only for recovery, line in the Maxlinear version.


Now, some questions to help me provide such a build :)

Curiosity 1: addresses
So I compared a dmesg with stock gl.iNet bootloader and new one, noticing the following differences:

--- owrt.old.nonumbers	2025-12-30 17:18:35.073385967 +0100
+++ owrt.new.nonumbers	2025-12-30 17:27:01.669341497 +0100
@@ -22,7 +22,7 @@
  psci: PSCIv1.1 detected in firmware.
  psci: Using standard PSCI v0.2 function IDs
  psci: MIGRATE_INFO_TYPE not supported.
- psci: SMC Calling Convention v1.2
+ psci: SMC Calling Convention v1.5
  percpu: Embedded 20 pages/cpu s42520 r8192 d31208 u81920
  pcpu-alloc: s42520 r8192 d31208 u81920 alloc=20*4096
  pcpu-alloc: [0] 0 [0] 1 
@@ -37,7 +37,7 @@
  mem auto-init: stack:off, heap alloc:off, heap free:off
  software IO TLB: SWIOTLB bounce buffer size adjusted to 1MB
  software IO TLB: area num 2.
- software IO TLB: mapped [mem 0x000000007fb2b000-0x000000007fc2b000] (1MB)
+ software IO TLB: mapped [mem 0x000000007eb00000-0x000000007ec00000] (1MB)
  SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
  rcu: Hierarchical RCU implementation.
  rcu: 	RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
@@ -128,8 +128,8 @@
  NET: Registered PF_PACKET protocol family
  8021q: 802.1Q VLAN Support v1.8
  mtk-msdc 11230000.mmc: msdc_track_cmd_data: cmd=52 arg=00000C00; host->error=0x00000002
- mtk-msdc 11230000.mmc: msdc_track_cmd_data: cmd=52 arg=80000C08; host->error=0x00000002
  phy phy-soc:usb-phy at 11e10000.1: type_sw - reg 0x218, index 0
+ mtk-msdc 11230000.mmc: msdc_track_cmd_data: cmd=52 arg=80000C08; host->error=0x00000002
  mtk-msdc 11230000.mmc: msdc_track_cmd_data: cmd=8 arg=000001AA; host->error=0x00000002
  mtk-msdc 11230000.mmc: msdc_track_cmd_data: cmd=5 arg=00000000; host->error=0x00000002
  mtk-msdc 11230000.mmc: msdc_track_cmd_data: cmd=5 arg=00000000; host->error=0x00000002
@@ -181,19 +181,15 @@
  hub 2-0:1.0: 1 port detected
  kmodloader: done loading kernel modules from /etc/modules-boot.d/*
  init: - preinit -
- u-boot-env-layout 11230000.mmc:card at 0:block:partitions:block-partition-u-boot-env:nvmem-layout: Invalid calculated CRC32: 0xc09e9b4c (expected: 0x00000000)
- u-boot-env-layout 11230000.mmc:card at 0:block:partitions:block-partition-u-boot-env:nvmem-layout: probe with driver u-boot-env-layout failed with error -22
  Airoha EN8811H mdio-bus:0d: MD32 firmware version: 25062302
- mtk_soc_eth 15100000.ethernet eth0: mediatek frame engine at 0xffffffc081380000, irq 74
- mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc081380000, irq 74
+ mtk_soc_eth 15100000.ethernet eth0: mediatek frame engine at 0xffffffc081f80000, irq 74
+ mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc081f80000, irq 74
  loop0: detected capacity change from 0 to 15186944
  loop0: detected capacity change from 15186944 to 15176960
- F2FS-fs (loop0): Found nat_bits in checkpoint
- F2FS-fs (loop0): Mounted with checkpoint version = 1cfc5d7f
- mount_root: overlay filesystem has not been fully initialized yet
+ F2FS-fs (loop0): Mounted with checkpoint version = 1cfc5d8a
  mount_root: switching to f2fs overlay
  overlayfs: null uuid detected in lower fs '/', falling back to xino=off,index=off,nfs_export=off.
- urandom-seed: Seed file not found (/etc/urandom.seed)
+ urandom-seed: Seeding with /etc/urandom.seed
  procd: - early -
  procd: - watchdog -
  procd: - watchdog -

Some differences are obvious here, but some are not, to me at least, and in particular those related to mtk-msdc errors and mtk_eth_soc different addresses for the frame engine.
Why is this happening?

Curiosity 2: load address
I remember I had to choose a different load address for this device. I was wondering how I may determine the correct load address for a device; I did so empirically, but was wondering why two different mt7981 evices may require a different load address.
Any help would be apreciated.

And now a more "practical" question: what is the best way to proceed for creating two distinct builds of U-Boot for the two versions of this device?
No DTS changes are needed to distinguish the two builds, since neither Maxlinear or Airoha PHYs are supported. Still, two distinct environment configs are appropriate.
Also, the build system recipes needs to be tweaked for producing the U-Boot images for both devices.
Any recommendations on what (not) to do?
I foresee at least three possible ways of proceeding:
1 - Refactor U-Boot DTS to have a common file and two DTS files for the two variants; the two DTS files would in practice only include the common file and define some properties like the model name and so on. Update build system recipes.
2 - Leave things as they are: leaving who decides to use OpenWrt-based U-Boot bootloader to customize things as needed when running on the Airoha version.
I don't like this solution and think it's really suboptimal.
3 - Use some Makefile magic to have two different builds of U-Boot including two different environment configs but with the same DTS.

Let me know all your toughts and opinions.

Also, this may be a good occasion for the OpenWrt project to express on how to proceed with the firmware images for the two versions of the device to acomodate ASU needs. For reference, see GitHub Issues #21297 #20566 .
Takins a decision here would be important also to proceed with this work. I do not use ASU and so have no experience with the tool.

And BTW - have a very very good new year.

Enrico

