There are many ways to remove all traces of OpenWrt if that's the point. E.g a regular firmware upgrade (or downgrade) after restoring the OEM firmware.
Just to clarify, the preogative is usually not to 'remove OpenWrt', but to install something else instead of OpenWrt (removing OpenWrt is then just an indirect consequence of the former).
Yes, technically you could also remove OpenWrt without installing a replacement, but doing that would typically brick your device (potentially even for good).
<Insert bad car analogy here>: if you have troubles with your car engine, the solution is not to remove the old engine and leave it at that (empty engine bay, troublesome engine removed - all fine for the motorway?!), but to swap in a new one.
Sure, I know that the main aim is to swap one firmware with another one; as per your example there is no point in leaving a car without an engine 
. My question was related to the fact that the documentation states that even by replacing OpenWRT with the stock firmware via TFTP, part of OpenWRT is still present on the kernel1 partition. So, I wondered if there is a way to remove what is present in that partition after reverting back to the stock firmware.
I had a very similar experience after a failed install of snapshot:
could not enter failsafe mode (fast blinking continues until power cycle)
- TFTP flashing works and was able to restore stock firmware v6.6.55
- installing 23.05.5 seemingly works at first but after rebooting it directly enters TFTP mode again
- installing v6.6.55 again via TFTP
- using the UniFi upgrade command i installed a newer version of the stock firmware to see if that worked
- works
- retry install of 23.05.5
- fails and back to TFTP mode
- flash v6.6.55
- upgrade to v6.6.75 with UniFi upgrade tool
- downgrade to v6.6.55 with UniFi upgrade tool
- install 23.05.5
- works!
My guess is that the UniFi upgrade process â but not the TFTP process! â overwrites some part of the flash that needs to be in a certain state before attempting to install OpenWRT but i could not identify which one so far. I checked the mmcblk0p8 partition.
First of all ... amazing job devs!
Transitioned to U6+ OpenWrt 24.10.2 with ease following the instructions (was on unifi firmware 6.5.28); partition reports were correct during the pre-flashing phase.
I noticed this in the logs:
[ 15.558003] mt798x-wmac 18000000.wifi: eeprom load fail, use default bin
[ 15.565086] mt798x-wmac 18000000.wifi: missing precal data, size=200720
any concerns with this?
No, my U6+ has those same lines in the kernel log and it's working as expected. Kernel logs are rather chatty to assist developers, but understandably confusing to users. If the AP is working, don't worry about it.
As a general question, if I've lost the contents of the eMMC, then nothing is to be done, right?
Asking as a last-resort since after subsequent power-cuts my AP (with Unifi firmware) lost its mmcblk0 partitions. My best guess to how this happened is that the device started a self-upgrade which got interrrupted by a power-cut, seemingly bricking the device.
The device responds to TFTP upgrades but as already mentioned in this thread, that does not touch the eMMC partitions. Any update method via SSH resolves in:
syswrapper[7560]: Upgrade Firmware Downloading:
syswrapper[7560]: Download ...OK
syswrapper[7560]: Upgrade Firmware Check:
syswrapper[7560]: open(/dev/mmcblk0p1) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p2) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p3) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p4) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p5) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p6) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p7) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p8) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p9) failed: No such file or directory
syswrapper[7560]: open(/dev/mmcblk0p10) failed: No such file or directory
syswrapper[7560]: Invalid Image Layout!
Couldn't open image file: /tmp/fwupdate.bin!
Invalid firmware. Exit status for firmware check = 65024.
And surely enough:
U6-LR-PLUS-BZ.6.7.12# ls /dev
bus kmsg loop6 mtd0ro random ubnt_sta_ht
conninfra_dev log loop7 mtd1 sflash urandom
console loop-control mapper mtd1ro shm vhci
cpu_dma_latency loop0 mem mtdblock0 tty watchdog
full loop1 mmcblk0 mtdblock1 ttyS0 watchdog0
gpiochip0 loop2 mmcblk0boot0 null ttyS1 zero
hwrng loop3 mmcblk0boot1 port ttyS2
iio:device0 loop4 mmcblk0rpmb ptmx ubi_ctrl
input loop5 mtd0 pts ubnt_neighbor
This problem seems to affect the U6+ and U6-LR+ products: https://community.ui.com/questions/U6-Firmware-Upgrade-Failed/ec079d99-24dc-403a-88e2-cc123d2f67e7
I'm waiting for final confirmation, but Ubiquiti already once declined RMA. So, I would be rather open to try any fixes possible. I'm also open to sending it to someone within EU for hacking.
TFTP certainly does touch eMMC, where else does it write the firmware to? 
I think you meant to say that it doesnât touch mmcblk0p7 (kernel1), at least the last time I looked at the UniFi 6+ bootloader. In OpenWrt, mmcblk0p7 is used to store the root filesystem. In UniFi, itâs used for A/B system boot.
Just to be clear, this is with the UniFi stock firmware, correct? If so, thatâs a really major failure of Ubiquitiâs part. This is one of the reasons why OpenWrt keeps the partitions intact.
If all the data partitions are wiped, the device is basically bricked since some of them include radio calibration data. If itâs only the partition table, you might be able to save it. But honestly I would push for RMA with Ubiquiti, especially since it looks like OpenWrt had nothing to do with the initial bricking.
I think you meant to say that it doesnât touch mmcblk0p7 (kernel1), at least the last time I looked at the UniFi 6+ bootloader.
Yes!
Just to be clear, this is with the UniFi stock firmware, correct?
Yes.
If all the data partitions are wiped, the device is basically bricked since some of them include radio calibration data. If itâs only the partition table, you might be able to save it.
I contacted Ubiquiti describing my problem to push for RMA. They sent me a version of the firmware (v6.7.12 with md5sum of 017539dac9bd66daa73eff9637ab04b2). This version fixed my problem, so it must have been something about the partition table!
Although, binwalk suggests there is nothing special (that would address my problem in particular) about this image:
BZ.MT7981_6.7.12+15511.250311.0958.bin
----------------------------------------------------------------------------------------------------------
DECIMAL HEXADECIMAL DESCRIPTION
----------------------------------------------------------------------------------------------------------
324 0x144 EFI Global Partition Table, total
size: 13231225
I still have no idea what caused the initial issues.
Thanks for the pointers though!
I haven't seen this page referenced here and thought it might be generally helpful, not related to any comment.
I'm trying to recover a U6+ OpenWrt flash attempt that apparently went wrong. I followed the instructions closely, the partition names matched, it all looked fine. But after a reboot the device did not come back on.
It now flashes off/white/blue repeatedly. I've tried TFTP but the device does not respond. I can ping it via 192.168.1.20 and I'm seeing UDP broadcasts in tcpdump:
17:28:39.036592 IP 192.168.1.20.10000 > 255.255.255.255.10001: UDP, length 21
0x0000: ffff ffff ffff 9c05 d620 90fc 0800 4500 ..............E.
0x0010: 0031 0118 4000 ff11 b8e7 c0a8 0114 ffff .1..@...........
0x0020: ffff 2710 2711 001d 0000 0307 1103 0e55 ..'.'..........U
0x0030: 2d42 6f6f 7420 3230 3232 2e30 34a6 42 -Boot.2022.04.B
It appears to be broadcasting the U-Boot version every second or so, so it's not entirely dead.
I've tried connecting to the UART, but I'm not getting anything (wouldn't rule out bad soldering from my side, but I've tried resoldering multiple times).
Anyone got an idea what I could do still? Or is it dead?
Please describe in detail your TFTP attempt. In particular, did you follow the Recovery Mode procedure as described by Ubiquiti?
Please double check that the pinout is correct. Does it correspond to how @bmork connected to the serial console in his previous post? Starting from the square pin, it's VCC, RXD input[1], TXD output[2], and GND. Do not connect VCC, you only need RXD, TXD, and GND. If in doubt, please post a picture of your setup and we can take a look at it.
It doesn't appear dead or bricked, but we can't help without serial console logs or a vastly more thorough description of your TFTP attempt.
Please describe in detail your TFTP attempt. In particular, did you follow the Recovery Mode procedure as described by Ubiquiti?
Yes exactly. I've used the exact same procedure. The device seems to be booting into the same mode (off/white/blue) regardless of whether I hold the reset button or not. The only difference is that it takes longer to go into this mode if I hold the reset button before plugging in the PoE.
The TFTP client stops with a transfer timeout. My IP is set to 192.168.1.25 and the AP responds to pings at 192.168.1.20.
[nix-shell:~/u6p]$ tftp
(to) 192.168.1.20
tftp> binary
tftp> rexmt 1
tftp> timeout 60
tftp> trace
Packet tracing on.
tftp> put fwupdate.bin
sent WRQ <file=fwupdate.bin, mode=octet>
[..]
sent WRQ <file=fwupdate.bin, mode=octet>
Transfer timed out.
Please double check that the pinout is correct. Does it correspond to how @bmork connected to the serial console in his previous post? Starting from the square pin, it's VCC, RXD input , TXD output , and GND. Do not connect VCC, you only need RXD, TXD, and GND.
These are the pins I have used. I have also tried swapping RX and TX to rule out they were wrong.
On my USB/Serial adapter:
- 2 = RX
- 3 = TX
- 6 = GND
The pinout looks right, although I'm always suspicious of the cheap "DuPont-style" jumpers that are sold alongside the DIY electronics stuff[1]. Can you check that the terminal viewer you're using is configured properly? It should be set to 115200 baud, 8 bits/byte, no parity, 1 stop bit (sometimes called 115200-8N1).
IME they seem to often not work quite right at the worst possible times. âŠď¸
I checked with an ESP32 and the serial readout was fine, but something was definitely wrong with the soldering. Never got the output to work. Maybe I fried a chip involved in it?
I did manage to do the TFTP recovery, though. No idea why, but it worked on Windows with tftp64. I tried several Linux clients (tftp-hpa, busybox, etc.) but all of them would time out, even though the AP responded to pings.
Anyway, after recovery I flashed OpenWrt again. Same problem as before: TFTP mode. Tried another time with an older version, no luck.
In the end I managed to flash it. This time I did not connect the recovered UniFi firmware with the LAN and did a factory reset before that, so management config was pushed to the device. I also recovered with an even older version that was mentioned in this thread, 6.5.xx I think.
Not sure if it was one of these or a combination, but now it runs OpenWrt like a charm. It still boggles my mind why TFTP would not work on my Linux machine. I didn't even have to crack open the case, but oh well. Thanks so much for jumping in to help!
"Firewall" settings maybe?
If you want to debug your serial connection further, you could for example test the soldering with a multimeter. Verify near 0 ohm between ground pin and some other grounded part, like a connector shield. Then look at the voltage between the tx pin and the ground pin when booting. You should observe a varying potential difference.
And if the problem really is the soldering, then maybe try simply holding the wires against the pads while looking at the outout. Only ground and tx needed for that test, so it's not hard to do.
FWIW, I gave up soldering and used tape to connect an uart module to one of my U6 Lites a few years a ago. That's still working. There are also other ways to temporarily attach wires to the holes if you don't require a permanent solution, like inserting a toothpick along with the wire etc.
So was the AP connected to your network instead of directly to your PC? That could explain a lot of your installation issues. The device's wiki page specifically calls out this particular step, although to be fair to you the wiki's search function is completely borked and doesn't bring up the wiki page for U6+.