Failed to install OpenWRT on a Ubiquiti Unifi-6-Plus

clifcox · January 25, 2025, 1:27am

Greetings,

A while back I tried installing openwrt-23.05.3-mediatek-filogic-ubnt_unifi-6-plus-squashfs-sysupgrade.bin on a U6+, but it bricked, and I couldn't even access TFTP. About a year later, I tried again with a new U6+ using openwrt-23.05.5-mediatek-filogic-ubnt_unifi-6-plus-squashfs-sysupgrade.bin, (the latest version) I was very careful, but it bricked again. Maybe someone can tell me what I'm doing wrong.

I found the instructions here:
https://openwrt.org/toh/ubiquiti/unifi_6_plus

First thing I noticed is there were no minor hardware versions listed, cool. Next I checked the firmware in my device. The prompt showed:
U6-Plus-BZ.6.5.28 Which is less than the mentioned version of: 6.6.55, so that looks good.

I didn't find a handy link to the proper sysupgrade file in the instructions so I had to go looking, and I found it in under filogic not ramips like the other U6s.

The full link to the firmware I used is:

https://downloads.openwrt.org/releases/23.05.5/targets/mediatek/filogic/openwrt-23.05.5-mediatek-filogic-ubnt_unifi-6-plus-squashfs-sysupgrade.bin

I checked the SHA256 hash, and it looked correct:

sha256sum openwrt-23.05.5-mediatek-filogic-ubnt_unifi-6-plus-squashfs-sysupgrade.bin
44f51ca7317aa08c261b1002c86fc85e8388a12f2894ce3b33cdd98f9c60a378 openwrt-23.05.5-mediatek-filogic-ubnt_unifi-6-plus-squashfs-sysupgrade.bin

Here is a log of my command line session on the U6-Plus:

type U6-Plus-BZ.6.5.28# sha256sum /tmp/openwrt.bin 
44f51ca7317aa08c261b1002c86fc85e8388a12f2894ce3b33cdd98f9c60a378  /tmp/openwrt.bin

U6-Plus-BZ.6.5.28# echo 5edfacbf > /proc/ubnthal/.uf
U6-Plus-BZ.6.5.28# 

U6-Plus-BZ.6.5.28# grep PARTNAME /sys/block/mmcblk0/mmcblk0p6/uevent
PARTNAME=kernel0
U6-Plus-BZ.6.5.28# grep PARTNAME /sys/block/mmcblk0/mmcblk0p7/uevent
PARTNAME=kernel1
U6-Plus-BZ.6.5.28# grep PARTNAME /sys/block/mmcblk0/mmcblk0p8/uevent
PARTNAME=bs

U6-Plus-BZ.6.5.28# fw_printenv
baudrate=115200
bootargs=ubootver= ramoops.mem_address=0x42fe0000 ramoops.mem_size=1048576 ramoops.ecc=1 ramoops.record_size=262144 console=ttyS0,115200n1 mem=262112K ubntbootid=0
bootcmd=bootubnt
bootdelay=2
ethaddr=d8:b3:70:dd:58:78
fdtaddr=46b60674
fdtcontroladdr=4ffc0460
ipaddr=192.168.1.20
is_default=true
loadaddr=0x46000000
netmask=255.255.255.0
serverip=192.168.1.2
stderr=serial@11002000
stdin=serial@11002000
stdout=serial@11002000
ubntaddr=440000b0
U6-Plus-BZ.6.5.28# 

U6-Plus-BZ.6.5.28# fw_setenv boot_openwrt "fdt addr \$(fdtcontroladdr); fdt rm /signature; bootubnt"
U6-Plus-BZ.6.5.28# fw_setenv bootcmd_real "run boot_openwrt"

U6-Plus-BZ.6.5.28# fw_printenv
baudrate=115200
bootargs=ubootver= ramoops.mem_address=0x42fe0000 ramoops.mem_size=1048576 ramoops.ecc=1 ramoops.record_size=262144 console=ttyS0,115200n1 mem=262112K ubntbootid=0
bootcmd=bootubnt
bootdelay=2
ethaddr=d8:b3:70:dd:58:78
fdtaddr=46b60674
fdtcontroladdr=4ffc0460
ipaddr=192.168.1.20
is_default=true
loadaddr=0x46000000
netmask=255.255.255.0
serverip=192.168.1.2
stderr=serial@11002000
stdin=serial@11002000
stdout=serial@11002000
ubntaddr=440000b0
boot_openwrt=fdt addr $(fdtcontroladdr); fdt rm /signature; bootubnt
bootcmd_real=run boot_openwrt
U6-Plus-BZ.6.5.28# 

cd /tmp/
U6-Plus-BZ.6.5.28# sha256sum openwrt.bin 
44f51ca7317aa08c261b1002c86fc85e8388a12f2894ce3b33cdd98f9c60a378  openwrt.bin
tar xf openwrt.bin
cd /tmp/sysupgrade-ubnt_unifi-6-plus/

U6-Plus-BZ.6.5.28# df -h .
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   112.3M     17.7M     94.6M  16% /tmp

U6-Plus-BZ.6.5.28# ls -l
-rw-r--r--    1 ui       root            24 Sep 23  2024 CONTROL
-rw-r--r--    1 ui       root       3804732 Sep 23  2024 kernel
-rw-r--r--    1 ui       root       5349376 Sep 23  2024 root

U6-Plus-BZ.6.5.28# dd if=kernel of=/dev/mmcblk0p6
U6-Plus-BZ.6.5.28# dd if=root of=/dev/mmcblk0p7
U6-Plus-BZ.6.5.28# echo -ne "\x00\x00\x00\x00\x2b\xe8\x4d\xa3" > /dev/mmcblk0p8

U6-Plus-BZ.6.5.28# fw_setenv boot_openwrt "fdt addr 4ffc0460 ; fdt rm /signature; bootubnt"
U6-Plus-BZ.6.5.28# reboot

The LEDs blinked a few times then it lit up solid Blue. I let it sit for about 10 or 15 minutes (Still solid blue) and power cycled it. I tried entering TFTP by holding down the reset button before applying power. Though it never enters the expected light pattern, and seems to be caught in a boot loop.

If I let it boot normally, it also seems to also be in a boot loop, during which most of the time I can ping it at 192.168.1.20 but can never ssh into it.

What am I doing wrong?

Thanks,
Clif

bmork · January 25, 2025, 6:10pm

What's this? That's not in the instructions, and it will softbrick the device.

clifcox · January 25, 2025, 6:50pm

Yes it's not in the instructions. I was a bit cautious since the first time I did follow them literally and it bricked. I thought I would hand copy the value of that variable into that field. If you look at the fw_printenv output for fdtcontroladdr, you will see it's value is: 4ffc0460. Which is what I pasted in.

I did wonder if it should be 0x4ffc0460 instead, but just left it as it was.

Clif

bmork · January 25, 2025, 7:29pm

It should be exactly as in the instructions. The value is expanded at runtime when the device boots.

clifcox · January 26, 2025, 10:49pm

Yes in a perfect world it should.

I was determined to get to the bottom of this so I bought a heat gun from harbor freight and took the darn U6+ apart. After soldering on a 4 pin header I captured the boot sequence on the serial port, included below.

I noticed a couple of errors. First: "*** Warning - bad CRC, using default environment"

I'm not an expert but it seems like the shell commands typed over ssh, did not update the environment variables correctly. In any case the changes were not listed with printenv. I tried using the saveenv command to correctly update the environment, and this error went away.

The 2nd error that caught my eye was. "WARNING:Boot selection logic magic mismatch!"

3rd error: "Verifying Hash Integrity ... Failed to verify required signature 'key-uap6_mt7981' error!"

So for some reason, even though we tried to disable signature checking with "fdt rm /signature; bootubnt" it didn't seem to get executed.

BOOT SEQUENCE:

F0: 102B 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 103F 0000
F3: 0000 0000 [0200]
V0: 0000 0000 [0001]
00: 0000 0000
BP: 2400 0041 [0000]
G0: 1190 0000
EC: 0000 0000 [2000]
T0: 0000 01A0 [010F]
Jump to BL

NOTICE:  BL2: v2.7(release):50aa1a6-dirty.........
NOTICE:  BL2: Built : 18:27:01, Aug 23 2022.........
NOTICE:  WDT: disabled
NOTICE:  EMI: Using DDR3 settings

dump toprgu registers data: 
1001c000 | 00000000 0000ffe0 00000000 00000000
1001c010 | 00000fff 00000000 00f00000 00000000
1001c020 | 00000000 00000000 00000000 00000000
1001c030 | 003c0003 003c0003 00000000 00000000
1001c040 | 00000000 00000000 00000000 00000000
1001c050 | 00000000 00000000 00000000 00000000
1001c060 | 00000000 00000000 00000000 00000000
1001c070 | 00000000 00000000 00000000 00000000
1001c080 | 00000000 00000000 00000000 00000000

dump drm registers data: 
1001d000 | 00000000 00000000 00000000 00000000
1001d010 | 00000000 00000000 00000000 00000000
1001d020 | 00000000 00000000 00000000 00000000
1001d030 | 00a083f1 000003ff 00100000 00000000
1001d040 | 00000000 00000000 00020303 000000ff
1001d050 | 00000000 00000000 00000000 00000000
1001d060 | 00000002 00000000 00000000 00000000
drm: 500 = 0x8 
[DDR Reserve] ddr reserve mode not be enabled yet
DDR RESERVE Success 0
[EMI] ComboMCP not ready, using default setting
BYTE_swap:0 
BYTE_swap:0 
Window Sum 568, worse bit 0, min window 68
Window Sum 576, worse bit 15, min window 68
Window Sum 442, worse bit 1, min window 54
Window Sum 440, worse bit 11, min window 52
Window Sum 448, worse bit 1, min window 54
Window Sum 458, worse bit 11, min window 54
Window Sum 456, worse bit 1, min window 54
Window Sum 460, worse bit 11, min window 56
Window Sum 466, worse bit 4, min window 56
Window Sum 476, worse bit 15, min window 56
Window Sum 476, worse bit 6, min window 56
Window Sum 486, worse bit 11, min window 58
Window Sum 486, worse bit 1, min window 60
Window Sum 490, worse bit 11, min window 58
Window Sum 496, worse bit 1, min window 60
Window Sum 504, worse bit 11, min window 60
Window Sum 498, worse bit 3, min window 60
Window Sum 510, worse bit 9, min window 62
NOTICE:  EMI: Detected DRAM size: 256MB
NOTICE:  EMI: complex R/W mem test passed
NOTICE:  CPU: MT7981 (1300MHz)
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.7(release):50aa1a6
NOTICE:  BL31: Built : 11:15:19, Dec  6 2022
NOTICE:  Hello BL31!!!


U-Boot 2022.04-00011-g9f2bed5188 (Dec 06 2022 - 11:15:03 +0800)

CPU:   MediaTek MT7981
Model: mt7981-rfb
DRAM:  256 MiB
Core:  38 devices, 17 uclasses, devicetree: embed
MMC:   mmc@11230000: 0
Loading Environment from SPIFlash... SF: Detected mx25l12805d with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

SF: Detected mx25l12805d with page size 256 Bytes, erase size 4 KiB, total 16 MiB
device 0 offset 0x0, size 0x14
SF: 20 bytes @ 0x0 Read: OK
In:    serial@11002000
Out:   serial@11002000
Err:   serial@11002000
Net:   eth0: ethernet@15100000
Autobooting in 2 seconds, press "<Esc><Esc>" to stop
ubnt boot ...

MMC read: dev # 0, block # 541824, count 1 ... 1 blocks read: OK
## Starting application at 0x440000B0 ...
Board: Ubiquiti Networks mt7981 board (a642-16.0000)
WARNING:Boot selection logic magic mismatch!
UBNT application initialized 
## Application terminated, rc = 0x0
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0

MMC read: dev # 0, block # 17536, count 1 ... 1 blocks read: OK

MMC read: dev # 0, block # 17536, count 7432 ... 7432 blocks read: OK
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
Config #config-a642 not found, using default
## Loading kernel from FIT Image at 46000000 ...
   Using 'config-1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel-1' kernel subimage
     Description:  ARM64 OpenWrt Linux-5.15.167
     Type:         Kernel Image
     Compression:  lzma compressed
     Data Start:   0x460000ec
     Data Size:    3781454 Bytes = 3.6 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x48000000
     Entry Point:  0x48000000
     Hash algo:    crc32
     Hash value:   ed237e3a
     Hash algo:    sha1
     Hash value:   62362639aecdfc48a48ab20b70286ac97e1ca56f
   Verifying Hash Integrity ... Failed to verify required signature 'key-uap6_mt7981'
 error!
Unable to verify required signature for '' hash node in 'kernel-1' image node
Bad Data Hash
ERROR: can't get kernel image!
ERROR validate: bootm start 0x0000000046000000
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0

MMC read: dev # 0, block # 279680, count 1 ... 1 blocks read: OK

MMC read: dev # 0, block # 279680, count 262144 ... 262144 blocks read: OK
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
Config #config-a642 not found, using default
Wrong Image Format for bootm command
ERROR: can't get kernel image!
ERROR validate: bootm start 0x0000000046000000
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
ethernet@15100000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
ethernet@15100000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
ethernet@15100000 Waiting for PHY auto negotiation to complete......... TIMEOUT !

I tried updating the boot_openwrt ENV variable once again to 4ffc0460, and this time it worked, and I was able to boot openwrt.

setenv boot_openwrt 'fdt addr 4ffc0460; fdt rm /signature; bootubnt'

Notice how I had to replace the double quotes with single quotes. Then, I tried variations on the intended command and found that if replaced the quotes and removed the backslashes it would work.

setenv boot_openwrt 'fdt addr $(fdtcontroladdr); fdt rm /signature; bootubnt'

Of course to pass through the ssh shell command line processing you might have to tweak this a bit. I'm happy to try that and report back, but I couldn't find an older version of the U6+ firmware at the listed site:

https://community.ui.com/releases

If someone has a version that is not later than version 6.6.55 as mentioned in the instructions, that would get me started.

Thanks,
Clif

bmork · January 27, 2025, 7:29am

This is unexpected, I believe. Wonder how that happened? Could it be caused by running fw_setenv immediately before rebooting?

Anyway, I still don't understand why you did that. That fw_setenv call is not in the instructions. I don't think it makes sense adjusting the current instructons as long as you have not tried to follow them. The problems you had are most likely caused by the additional command you issued. The solution is

Don't do that.

This is usually part of any instructions since the set of "don't do" commands is infinite.

Your log shows that you successfully ran

U6-Plus-BZ.6.5.28# fw_setenv boot_openwrt "fdt addr \$(fdtcontroladdr); fdt rm /signature; bootubnt"

as instructed, and fw_printenv printed the expected escaped value:

boot_openwrt=fdt addr $(fdtcontroladdr); fdt rm /signature; bootubnt

So the environment was correct at this point. The backslash escaping worked as it should. There was no reason to run any more fw_setenv commands.

The environment error was added later, and the bogus fw_setenv you added is the prime suspect. None of the other commands will touch the u-boot enviroment. Or the NOR flash at all, in fact. They all operate on the emmc

clifcox · January 29, 2025, 2:04am

Howdy,

I doubt it, there seems to be nothing else in the instructions that would update the environment variables. For example there was no saveenv command equivalent.

Why did I do that? because the first time I followed the instructions exactly, and it bricked. Then I RMAed the device and got a new one. Something that you can probably only get away with once. I thought trying exactly the same thing again and expecting different results would be silly. So I simplified the command to see if I could get it to work. Anyway, as I mentioned above, the simplified ftd command with the literal address worked fine, the problem is somewhere else. Both forms of this command work fine:

setenv boot_openwrt 'fdt addr 4ffc0460;          fdt rm /signature; bootubnt'
setenv boot_openwrt 'fdt addr $(fdtcontroladdr); fdt rm /signature; bootubnt

It might be that there is some version skew between the fw_setenv command and the version of U-Boot running on the device. This would be odd, but if the fw_setenv command caused the environment flash not to be updated correctly, perhaps an invalid CRC for example, then that might explain it.

Thankfully this doesn't happen very often, maybe if someone else encounters this problem they could chime in here and let us know.

Just for Completeness sake here is a U-Boot log of it correctly booting. The only error remaining seems to be:

WARNING:Boot selection logic magic mismatch!
I guess it's not important.

Working Boot Log:

F0: 102B 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 103F 0000
F3: 0000 0000 [0200]
V0: 0000 0000 [0001]
00: 0000 0000
BP: 2400 0041 [0000]
G0: 1190 0000
EC: 0000 0000 [2000]
T0: 0000 01A0 [010F]
Jump to BL

NOTICE:  BL2: v2.7(release):50aa1a6-dirty.........
NOTICE:  BL2: Built : 18:27:01, Aug 23 2022.........
NOTICE:  WDT: disabled
NOTICE:  EMI: Using DDR3 settings

dump toprgu registers data: 
1001c000 | 00000000 0000ffe0 00000000 00000000
1001c010 | 00000fff 00000000 00f00000 00000000
1001c020 | 00000000 00000000 00000000 00000000
1001c030 | 003c0003 003c0003 00000000 00000000
1001c040 | 00000000 00000000 00000000 00000000
1001c050 | 00000000 00000000 00000000 00000000
1001c060 | 00000000 00000000 00000000 00000000
1001c070 | 00000000 00000000 00000000 00000000
1001c080 | 00000000 00000000 00000000 00000000

dump drm registers data: 
1001d000 | 00000000 00000000 00000000 00000000
1001d010 | 00000000 00000000 00000000 00000000
1001d020 | 00000000 00000000 00000000 00000000
1001d030 | 00a083f1 000003ff 00100000 00000000
1001d040 | 00000000 00000000 00020303 000000ff
1001d050 | 00000000 00000000 00000000 00000000
1001d060 | 00000002 00000000 00000000 00000000
drm: 500 = 0x8 
[DDR Reserve] ddr reserve mode not be enabled yet
DDR RESERVE Success 0
[EMI] ComboMCP not ready, using default setting
BYTE_swap:0 
BYTE_swap:0 
Window Sum 568, worse bit 0, min window 68
Window Sum 580, worse bit 8, min window 72
Window Sum 442, worse bit 1, min window 54
Window Sum 440, worse bit 15, min window 52
Window Sum 448, worse bit 1, min window 54
Window Sum 456, worse bit 11, min window 54
Window Sum 460, worse bit 1, min window 56
Window Sum 458, worse bit 11, min window 54
Window Sum 468, worse bit 1, min window 56
Window Sum 472, worse bit 15, min window 56
Window Sum 474, worse bit 6, min window 56
Window Sum 482, worse bit 11, min window 58
Window Sum 488, worse bit 1, min window 60
Window Sum 490, worse bit 11, min window 58
Window Sum 504, worse bit 11, min window 60
Window Sum 492, worse bit 6, min window 60
Window Sum 506, worse bit 9, min window 62
Window Sum 496, worse bit 3, min window 60
Window Sum 508, worse bit 8, min window 62
NOTICE:  EMI: Detected DRAM size: 256MB
NOTICE:  EMI: complex R/W mem test passed
NOTICE:  CPU: MT7981 (1300MHz)
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.7(release):50aa1a6
NOTICE:  BL31: Built : 11:15:19, Dec  6 2022
NOTICE:  Hello BL31!!!


U-Boot 2022.04-00011-g9f2bed5188 (Dec 06 2022 - 11:15:03 +0800)

CPU:   MediaTek MT7981
Model: mt7981-rfb
DRAM:  256 MiB
Core:  38 devices, 17 uclasses, devicetree: embed
MMC:   mmc@11230000: 0
Loading Environment from SPIFlash... SF: Detected mx25l12805d with page size 256 Bytes, erase size 4 KiB, total 16 MiB
SF: Detected mx25l12805d with page size 256 Bytes, erase size 4 KiB, total 16 MiB
device 0 offset 0x0, size 0x14
SF: 20 bytes @ 0x0 Read: OK
OK
In:    serial@11002000
Out:   serial@11002000
Err:   serial@11002000
Net:   eth0: ethernet@15100000
Autobooting in 2 seconds, press "<Esc><Esc>" to stop
ubnt boot ...

MMC read: dev # 0, block # 541824, count 1 ... 1 blocks read: OK
## Starting application at 0x440000B0 ...
Board: Ubiquiti Networks mt7981 board (a642-16.0000)
WARNING:Boot selection logic magic mismatch!
UBNT application initialized 
## Application terminated, rc = 0x0
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0

MMC read: dev # 0, block # 17536, count 1 ... 1 blocks read: OK

MMC read: dev # 0, block # 17536, count 7432 ... 7432 blocks read: OK
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
Config #config-a642 not found, using default
## Loading kernel from FIT Image at 46000000 ...
   Using 'config-1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel-1' kernel subimage
     Description:  ARM64 OpenWrt Linux-5.15.167
     Type:         Kernel Image
     Compression:  lzma compressed
     Data Start:   0x460000ec
     Data Size:    3781454 Bytes = 3.6 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x48000000
     Entry Point:  0x48000000
     Hash algo:    crc32
     Hash value:   ed237e3a
     Hash algo:    sha1
     Hash value:   62362639aecdfc48a48ab20b70286ac97e1ca56f
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 46000000 ...
   Using 'config-1' configuration
   Verifying Hash Integrity ... OK
   Trying 'fdt-1' fdt subimage
     Description:  ARM64 OpenWrt ubnt_unifi-6-plus device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x4639b580
     Data Size:    21362 Bytes = 20.9 KiB
     Architecture: AArch64
     Hash algo:    crc32
     Hash value:   2802edfd
     Hash algo:    sha1
     Hash value:   ef3066986032e287de11d85a13d8687e7f1355f8
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x4639b580
   Uncompressing Kernel Image
## Starting application at 0x440000B0 ...
## Application terminated, rc = 0x0
device 0 offset 0x10000, size 0x4
SF: 4 bytes @ 0x10000 Read: OK
   Loading Device Tree to 000000004f7f1000, end 000000004f7f9371 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.15.167 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r24106-10cc5fcd00) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Mon Sep 23 12:34:46 2024
[    0.000000] Machine model: Ubiquiti UniFi 6 Plus
[...]

Best,
Clif

bmork · January 29, 2025, 7:28am

Yes, and even broke the tftp recovery AFAIR. That one is still unexplainable. There is no way to break that without overwriting one of the bootloader stages.

FWIW, your last breakage would have been rescuable without console, using the builtin tftp failsafe. But having console is essential if we're going to figure out what's going on here.

You are of course free to add whatever experimental commands you want to. But when you do so, then it is impossible to know which part caused a breakage - the instructions or your additions. What we do know is that the instructions have worked for me and others, and that instructuons with extra commands broke your device. This does of course not prove anything.

I will still claim that NOT following instructions is far more risky than following instructions. AFAICS you have presented no reason for adding that command, which at best will be redundant. As I said: What you had before that command looked good. There was no reason to change anything. Yet you did. And then the device didn't boot.

Please don't advice anyone else to do stuff like that.

clifcox:

MMC read: dev # 0, block # 541824, count 1 ... 1 blocks read: OK
## Starting application at 0x440000B0 ...
Board: Ubiquiti Networks mt7981 board (a642-16.0000)
WARNING:Boot selection logic magic mismatch!

This means that the "bs" partition is invalid/empty. That's not a big problem since boot selection will default to 0 in that case, which is what we want. And it's also a normal event right after (some?) OEM image upgrades. Should not happen more than once since the bs code will update the partiion, I believe.

Can't explain how that happened. The "bs" partition should look like this after following instrctions:

root@u6plus:~# hexdump -C /dev/mmcblk0p8
00000000  00 00 00 00 2b e8 4d a3  00 00 00 00 00 00 00 00  |....+.M.........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800

You could also verify this by reading it by block number like the boot loader bs code does:

root@u6plus:~# dd if=/dev/mmcblk0 skip=541824 bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
00000000  00 00 00 00 2b e8 4d a3  00 00 00 00 00 00 00 00  |....+.M.........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

bmork · January 29, 2025, 7:50am

Not sure what you meant here. This makes no sense. There are fw_setenv commands in the instructions. Your log shows that you ran those too. And the log of the fw_printenv shows that they were successful.

Unless you have other information, we must assume that the Ubnt biaries are based on some version of the U-Boot mainline code. This will flush the environment to flash on every call to fw_setenv. See
https://sour.ce.denx.de/u-boot/u-boot/-/blob/master/tools/env/fw_env.c?ref_type=heads#L722

That's why there is no savenv equivalent. This is different from the U-Boot shell where setenv and printenv operates on the environment currently loaded in memory. That wouldn't make any sense in the OS.

bmork · January 29, 2025, 8:42am

This was wrong. I went back and checked my boot log history, and see that the U-Boot code does not update "bs". So this warning is persistent until you either run the Ubnt fw upgrade app (which will toggle between kernel0 and kernel1) or run the commands in the OpenWrt instructions (which will force kernel0).

The warning can still be safely ignored.

clifcox · February 2, 2025, 7:24pm

Greetings,

Let me clarify as best I can.

For the first device I Followed the instructions to the letter. it got bricked IIRC I could not even ping it when attempting tftp mode, I RMA'd it and the distributor could not recover it either, so both of us tried. Yes I think you are correct in suspecting that the boot code got overwritten, That's hard to explain.

For the second device, I couldn't get away with another RMA so soon, and here is where Bjørn and I may have different opinions. I would advocate for trying something different, with the faint hope of learning something.

I tried a simplified version of a setenv command, and it worked fine, but I didn't learn anything new, because the problem was somewhere else.

setenv boot_openwrt 'fdt addr 4ffc0460;          fdt rm /signature; bootubnt'
setenv boot_openwrt 'fdt addr $(fdtcontroladdr); fdt rm /signature; bootubnt

This time I could ping while attempting tftp mode. I never tried tftp though. I can say both times the LEDs did not blink in the expected pattern. The takeaway here would be to try uploading an image even if tftp doesn't seem to be working. You might have to try several times because from the console output, it seemed to be timing out after only a couple of seconds, and looping, so it might be hard to catch it while it's listening.

bmork:

Can't explain how that happened. The "bs" partition should look like this after following instrctions:
root@u6plus:~# hexdump -C /dev/mmcblk0p8
00000000  00 00 00 00 2b e8 4d a3  00 00 00 00 00 00 00 00  |....+.M.........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800

Maybe the bytes written to the bs block with the echo command failed to update some check code correctly. Above I mentioned this might explain the error for the environment update from the OS side (ssh shell) of things.

I meant to say there was nothing else in the instructions that would update the environment variables after my last update.

They should be, if this happens to anyone else, the first thing I would check is if the error checks on the flash partitions get updated correctly by the Ubnt factory firmware.

I have since deployed this device, but it would be nice to try again, if I only had an earlier (confirmed working) firmware version I might do that.

Best,
Clif