Please post. The point of the stack trace is that it shows where stuff blew up. The dev_uevent reference is a bit too generic. That could be any device.
Full log is postedhere: https://pastebin.com/embed_js/45DxVSTK
I am not sure its because dev_uevent.
Thanks!
I started poking around looking for short and I did find something suspicious, I do have a dead short on the resistor I pointed in the below photos, I don't believe it's a 0 Ohm resistor because of the topology is part of.
Can anyone measure the value of that resistor ?
I also removed the resistor but nothing changed in the bootlog.
Later EDIT:
I wasn't paying attention.. that's a inductor 
On 6.0.21 with v3, the boot process gets stuck trying to query the RGB LED driver, but it eventually continues. I found that leaving it there for a few minutes continues the boot process.
Are you sure that the ethernet works, even after cold boot? I just checked and I see that I used the same changes the last time I tried and it didn't work unless I initialized the network in stock U-Boot.
Ah yeah, I did the same thing I think - got what seems to be a v3 that came with 6.0.24 which like you said isn't even available on their website, had issues with openwrt, recovered to 6.0.21, and then was stuck with what you describe as the "white-ring-of-death"
At least in my case I flashed 6.0.21 to the v3, which seemed to boot, I then flashed openwrt, and now the device seems to be pretty bricked. The white LED comes on immediately and just stays on, and I can't seem to interact in any way (I've waited over an hour to see if it was just taking a while or something), even trying to get into the recovery mode doesn't work. Going to open it up when I get a chance to, to see if I can glean anything / fix it somehow with access to the serial pins.
(more details of exactly what happened I had written about here Unifi 6 LR Issues)
On this... there could be a few causes for this that may be resolvable within the Unifi context if you want to go back (I'm not suggesting it, just mentioning this). Three things I've seen with Unifi stuff in general:
- Make sure the UNA is up to date (>= 6.0.34 is required for the U6-LR).
- Manually update the firmware on the AP (sometimes the firmware preloaded in the AP has an issue or is actually too old to adopt). You'd do this by resetting the device and ssh'ing into it for a manual upgrade.
- Reset the device and try adopting again.
The UI community forums can also be helpful (you won't get much, if any support from UI staff, but the volunteer community is quite knowledgable and often can help solve the issue)
All that said, hopfully you can resolve the OpenWrt issue you're having now with the ethernet. I'd try to help, but I don't have any U6 devices... but you're in capable hands here.
@danijeltudek Thanks for the hint! You were right, after about 10 minutes they really booted to stock unify .21 and i were able to reflash openwrt!
I tried all variants and all of my 25 Accesspoints are working properly now (ethernet/wifi on cold boot/reboot).
Can you please guide me on how to write the uboot ? I am more into hardware things than software when it comes to those stuff.
I did compile OpenWrt with the patches that I see above, and I got the initramfs, sysupgrade and in:
openwrt/build_dir/target-aarch64_cortex-a53_musl/u-boot-mt7622_ubnt_unifi-6-lr/u-boot-2022.01
I got: u-boot-dtb.bin, u-boot-nodtb.bin, u-boot.bin
And my mtd:
root@OpenWrt:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "preloader"
mtd1: 00020000 00010000 "atf"
mtd2: 00060000 00010000 "u-boot"
mtd3: 00010000 00010000 "u-boot-env"
mtd4: 00040000 00010000 "factory"
mtd5: 00010000 00010000 "eeprom"
mtd6: 00010000 00010000 "bs"
mtd7: 00100000 00010000 "cfg"
mtd8: 01ee0000 00010000 "firmware"
mtd9: 003b0000 00010000 "kernel"
mtd10: 01b20000 00010000 "rootfs"
mtd11: 016a0000 00010000 "rootfs_data"
mtd12: 01ee0000 00010000 "kernel1"
I am not sure how to write the file and most specially what file where to write it.
The U6-LR is now booting OpenWrt, but without updating the u-boot if I don't issue tftpboot first the network will not work.
Thanks, I really appreciate any help received!
I wonder if it's worth gathering manufacture dates so these can be documented? Mine appears to have the new phy and on the rear panel it says "2234K". I assume this is 34rd week of 2022 (22 Aug 2022 to 28 Aug 2022), since this matches the date on the packaging ("Test Date 08/25/22" i.e. 25 Aug 2022).
It shipped with the U6-LR-BZ.6.0.24 firmware.
I recovered to OEM firmware BZ.MT7622_6.2.37+14065.220826.2348.bin (which contains the uboot build date string "Aug 14 2022 - 09:48:05") from the bootloader tftp. This works with the new phy and doesn't pause/timeout at boot time.
I've added a note about the "V3" hardware to the device's wiki page.
It would presumably be possible to ask for the source code to the V3 firmware kernel and uboot to check what they've done to detect the different firmware versions, and initialise the PHY? Has anyone tried doing that?
While hacks to detect different board version in run-time after Linux has started are possible in theory it is not straight forward and will require lots of ugly hacks. In an ideal world we would have a single firmware image with multiple device tree blobs, and the U-Boot bootloader would select the device tree blob matching the hardware and then start Linux. However, this is probably not how ubnt's loader is doing it...
Hence the clean solution is to introduce a new image for the new hardware, though that will inconvenience users as they will have to find out which hardware version they are dealing with...
2 Likes
Till now I tried multiple options, none of them worked. I am really curious to find out how @AndyX90 managed to get it to work.
What I tried:
- All stock firmware from UBNT and then flashed OpenWRT with the patch posted above ( keeping UBNT original u-boot )
- Patched the latest snapshot of OpenWRT and replaced UBNT u-boot with ubootmod: Ethernet didn't work neither in u-bootmod neither after the linux is loaded.
The only way to get ethernet to work is to first issue a tftpsrv from UBNT original u-boot. BUT we aware that is the link flaps then the ethernet will likely stop working. There are times when it recovers after a link down/up event and times when it doesn't.
Searching for a solution I tried to look at other people code and found this:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/stabilize-13421.80.B-chromeos-4.19-lakitu^2..refs/heads/stabilize-13421.80.B-chromeos-4.19-lakitu/
I am no expert in FW design but it might help:
+ /*
+ * Reset for the RTL8211 PHY which requires a 10-ms reset pulse (low)
+ * with a 30ms settling time.
+ */
+ snps,reset-gpio = <&gpio4 RK_PB0 0>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 30000>;
+ wakeup-source;
Don't know if this makes any sense.
I have collected the following information from all Unify 6 LRs i got in my hands:
The revision seems to be the number next to the QR-Code. (22xxK)
Default v2 Target:
Rev: 2224K
MAC: 70:A7:41:XX:XX:XX --> Aquantia 2,5G NIC
Rev: 2227K
MAC: 70:A7:41:XX:XX:XX --> Aquantia 2,5G NIC
Rev: 2228K
MAC: 70:A7:41:XX:XX:XX --> Aquantia 2,5G NIC
New "v3" Target:
Rev: 2234K
MAC: 60:22:32:XX:XX:XX --> Realtek 1G Nic
All these Revs are tested and working fine. (v3 with above patches)
@darkm4n This is strange, for me it seems that you maybe have a faulty device. Can you post your Rev?
Hi Andy,
My U6-LR is 2236V, that may explain why it's not working on my side.
Also my device is refusing to work with the UBNT original firmware, it crashes at boot ( https://pastebin.com/embed_js/45DxVSTK ), so we can assume something is wrong with the hardware. But it's very strange, if I boot the device using OpenWRT and I activate the ethernet from the original u-boot by issuing a "tftpsrv" command before "boot" it works without any issues except that if the ethernet port flaps then most of the times it will not work again after the link is established.
The ethernet chip I have on my board is: RTL8211FS
EDIT:
I just ordered a replacement RTL8211F chip, it will take a month to arrive from China, I will replace the chip just to rule out it's faulty. Next step if it still doesn't work ( even with UBNT official FW ) will be to replace the MT7622, still looking where I can find a donner board or a supplier that can provide me this part.
My two seemingly v3's are 2246V and 2247V
@AndyX90 Does Ethernet work on your devices regardless of which stock U-Boot do you use (either 6.0.xx or 6.2.xx)? Looking at your patch, it's the same as the last one that I used before giving up and I couldn't get it to work.
Yes, ethernet is working in all cases regardless of which stock version i came.
It looks like mtd layout is also different on v-variants?
All my versions are k-variants and are working well.
I have two 2233K that I assume are v3. I will try the custom build @AndyX90 suggested once I get the build environment set up and report my experiences.
So will there be a branch available for the V3 hardware on the product page given that the patches you have been testing seem to work?
Cheers
Spart
1 Like
I built OpenWRT 22.03.3 with the patch from @AndyX90. Since I am anything but an expert on this, here's my git diff output:
diff --git a/include/bpf.mk b/include/bpf.mk
index 7d0cfbd76d..9d21a67824 100644
--- a/include/bpf.mk
+++ b/include/bpf.mk
@@ -67,6 +67,7 @@ ifeq ($(DUMP),)
CLANG_VER:=$(shell $(CLANG) -dM -E - < /dev/null | grep __clang_major__ | cut -d' ' -f3)
CLANG_VER_VALID:=$(shell [ "$(CLANG_VER)" -ge "$(CLANG_MIN_VER)" ] && echo 1 )
ifeq ($(CLANG_VER_VALID),)
+ $(error CLANG=$(CLANG))
$(error ERROR: LLVM/clang version too old. Minimum required: $(CLANG_MIN_VER), found: $(CLANG_VER))
endif
endif
diff --git a/package/boot/uboot-mediatek/patches/412-add-ubnt-unifi-6-lr.patch b/package/boot/uboot-mediatek/patches/412-add-ubnt-unifi-6-lr.patch
index c475a7c597..96ba2385dc 100644
--- a/package/boot/uboot-mediatek/patches/412-add-ubnt-unifi-6-lr.patch
+++ b/package/boot/uboot-mediatek/patches/412-add-ubnt-unifi-6-lr.patch
@@ -109,7 +109,8 @@
+CONFIG_PHYLIB_10G=y
+CONFIG_PHY_AQUANTIA=y
+CONFIG_PHY_ADDR_ENABLE=y
-+CONFIG_PHY_ADDR=8
++CONFIG_PHY_ADDR=0
++CONFIG_PHY_REALTEK=y
+CONFIG_MEDIATEK_ETH=y
+CONFIG_MTD=y
+# CONFIG_MMC is not set
@@ -326,10 +327,10 @@
+ #address-cells = <1>;
+ #size-cells = <0>;
+
-+ gphy: ethernet-phy@8 {
++ gphy: ethernet-phy@0 {
+ /* Marvell AQRate AQR112W - no driver */
-+ compatible = "ethernet-phy-ieee802.3-c45";
-+ reg = <0x8>;
++ compatible = "ethernet-phy-ieee802.3-c22";
++ reg = <0x0>;
+ };
+ };
+};
diff --git a/target/linux/mediatek/dts/mt7622-ubnt-unifi-6-lr.dtsi b/target/linux/mediatek/dts/mt7622-ubnt-unifi-6-lr.dtsi
index 4231cc1f79..8883ccf2b9 100644
--- a/target/linux/mediatek/dts/mt7622-ubnt-unifi-6-lr.dtsi
+++ b/target/linux/mediatek/dts/mt7622-ubnt-unifi-6-lr.dtsi
@@ -160,18 +160,18 @@
compatible = "mediatek,eth-mac";
reg = <0>;
- phy-mode = "2500base-x";
+ phy-mode = "sgmii";
phy-handle = <&phy0>;
- phy-connection-type = "2500base-x";
+ phy-connection-type = "sgmii";
};
mdio: mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
- phy0: ethernet-phy@8 {
- compatible = "ethernet-phy-ieee802.3-c45";
- reg = <0x8>;
+ phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x0>;
};
};
};
[The CLANG-modification was required because even though I have clang v13 installed, the makefile refuses to accept that it is >= v12 for some reason.]
Starting with stock firmware 6.2.44, I uploaded the image from bin/targets/mediatek/mt7622 to the AP as documented in the wiki.
When booting, the LED goes white on, single white strobe, off, white strobe, white quick flash. The AP does not react to the network in any way.
Since I had to restore the stock firmware anyways, I upgraded to 6.2.49 and tried the whole procedure again. Unfortunately with the same results.
So, after much mucking about, I will concede a draw. I am open to suggestions. 