Add Hardware support: Unifi AC Mesh

[tuennes]

I think this could be a cool, small device. Hopefully with a nice performance. Please give me hints how I can support you.

Picture of PCB Front: Back without antenna:

Link to OEM-FW Some info out of ssh console: console.txt

Serial console: serial_console.txt

[tuennes]

Serial console of booted LEDE ramdisk (generic, all drivers): serial_console_LEDE_ramdisk.txt

Serial console of booted LEDE board=UBNT-UF-AC-LITE: serial_console_LEDE_UBNT-UF-AC-LITE.txt

Flash memory dump (cat /dev/mtd0 > /tmp/mtd0): mtd0.zip

[rotanid]

hey @tuennes , primarily this is an upstream issue. gluon won't include hardware that isn't supported by LEDE-upstream. maybe you can gather in information on how to add support from a recent lede hardware PR ( https://github.com/lede-project/source/pull/613 ) or @Brother-Lal can help you out with his notes on the topic.

[Brother-Lal]

That looks good. If you can, join the #gluon irc channel at hackint an i can try to help a little bit along.

I tried to write the whole thing down: https://gist.github.com/Brother-Lal/3ad312a8aa1c38ac5b9d8ebd47bb3a2a

Its targeted for Atheros devices, and just from my amateurish viewpoint .

Next question then would be, check what works with the ac-lite board: wifi,lan,macadresses,LEDS

[ArwedSchmidt]

I would like to participate.

@tuennes Which pin mapping is required to connect to the UART? RX/TX/GND/3.3 or 5V?

[tuennes]

Hey @ArwedSchmidt same like unifi ac lite, have a look at his picture It is the left pinheader which is labled with UART 3.3V level, 115200 Baud, 8N1 But only use (from left, towards the LAN connector) ground, rx, tx

[tuennes]

Currenly only the generic LEDE ramdisk with boardparameter UBNT-UF-AC-LITE is running fine (Wifi, LAN, LED, reset works). What I do not understand is that the specific ramdisk for the AC-LITE is not booting out of uboot...

[Brother-Lal]

Can you explain what you mean with booting out of uboot?

[tuennes]

The U-Boot envirionment comes up, after any key hit on the message "Hit any key to stop autoboot:" I'm booting via tftp a LEDE initramfs (renamed) tftpboot 0x80060000 ifs.bin go 0x80060000 console=ttyS0,115200 board=UBNT-UF-AC-LITE

[Brother-Lal]

That did work, in your second post? What did you change to "break" it? Any more logs or error messages? With specific ramdisk, which file do you refer too?

Sry for the barrage of questions :)

[tuennes]

yes Only the use of the generic ramdisk, not the specific...It is booting as well without any boardparameter Will follow lede-ar71xx-generic-vmlinux-initramfs.bin

[tuennes]

Thanks to @Brother-Lal: I have flashed a LEDE image onto it (kernel0 partition) via mtd and have booted via bootm this image. Only 5Ghz missing... Next step is to build an image with ath10k-ct firmware and driver in... We'll see...

[tuennes]

New image build is running fine: LEDE with build in athk10-ct firmware and driver (only as modules they are not functional) 2 radios, LUCi... Gluon 2016.2.4 is running as well, image ubiquiti-unifi-ac-lite

Next step is to build separate target ubiquiti-unifi-ac-mesh

[tuennes]

Gluon 2016.2.4, every 2-3 minutes in logread: Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k_pci 0000:00:00.0: ath10k_pci ATH10K_DBG_BUFFER: Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k: [0000]: 7E851000 244CFC17 14594300 06000000 00000000 40000000 01000000 Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k_pci 0000:00:00.0: ATH10K_END

[rotanid]

these messages are there with the Unifi AP AC Pro devices, too. i think there is some kind of debug switch that wasn't turned off...

[tuennes]

@Brother-Lal has build within his own repo a dedicated branch and changed all needed files (hopefully)... When I build with this repo the 5Ghz is not working (f.e. luci is not showing this device). corresponding logmessages: [ 8.863015] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed [ 8.872438] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 8.944828] ath10k_pci 0000:00:00.0: otp calibration failed: 2 [ 8.950858] ath10k_pci 0000:00:00.0: failed to run otp: -22 [ 8.956629] ath10k_pci 0000:00:00.0: could not init core (-22) [ 8.962745] ath10k_pci 0000:00:00.0: could not probe fw (-22)

If I just clone the LEDE Master tree and choose the AC-LITE device then LEDE is running on the AC-mesh, LOG: [ 8.841067] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed [ 8.850514] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 9.769806] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 9.787894] ath10k_pci 0000:00:00.0: wmi print 'P 128 V 8 T 410' [ 9.794165] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0' [ 9.801536] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 25908 iram: 25808' [ 9.859459] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1

What do I wrong during build, menuconfig etc.?

[ArwedSchmidt]

We confirmed that the Mesh Pro (codename "dragonfly") is actually using:

QCA 9563-AL3A QCA 9880-BR4A QCA 8334-AL3C

Hardware seems to be identical to what's been used with the UAP-AC PRO! Due to all the interesting talks and some debricking, we haven't tried to flash the existing image yet.

The case is a bit trickier but can be opened by first cutting the silicate seal all around the case (it's just two parts, later). The cover is hold in place by maybe 20 plastic hooks.

One can start to disconnect these hooks most easily by carefully levering the knobs up that hold the cable door in place (lever against the fixed part of the cable outlet). Once the first hook is loose, it's easier to continue with four hands and two screwdrivers.

Here are some pictures of the opened device:

We also found out that one of our AC Meshs was using a bootloader from 2016-06-12 which was not compatible with the latest gluon build. The device was bricked until we recovered with the special recovery process offered by UBNT, effectively upgrading the bootloader. One should update to latest stock firmware before trying to flash anything!

Note: it seems that you cannot be sure whether your device will actually boot from kernel0 or kernel1 partition (haven't searched for an output yet, that hints which one to flash to). This seems to be a safety feature where every upgrade would use the partition that’s not in use.

Testing mesh on 5 GHz has not yielded positive results yet. However, we couldn't confirm that the builds we were using can actually mesh on 5 GHz. Once we disabled 2.4 GHz mesh, no connection was possible to a second "mesh only" UAP-AC-M.

I'm gonna install my UAP-AC-M in a test setup for now and see if it's stable. One thing you can note is that these devices get a little bit hot when used indoors. It uses around 6.9 Watts when idling with gluon-v2016.2.3-8 - more than e.g. NanoStations would draw.

[Brother-Lal]

If somebody has access to an ubiquity ac lite, ac pro and also for the ac mesh pro, i would like to have a look at the flash. So, if you could do a Flash memory dump (cat /dev/mtd0 > /tmp/mtd0) for those three, i would appreciate it if you could drop me a link :)

Update: AC Lite and AC pro are good, the ac mesh lite is already in the ticket, so the one last i need would be Mesh PRO!

[tuennes]

DMESG log original FW: dmesg_AC_mesh_pro_original_FW.txt

First binwalk info: binwalk mtd0 -v

Scan Time: 2017-05-11 07:09:40 Target File: /home/frank/mtd0 MD5 Checksum: f29d4c975d56420e97b487e20b89f075 Signatures: 344

DECIMAL HEXADECIMAL DESCRIPTION

150944 0x24DA0 Certificate in DER format (x509 v3), header length: 4, sequence length: 64 175312 0x2ACD0 CRC32 polynomial table, big endian 199639 0x30BD7 Copyright string: "Copyright Ubiquiti Networks Inc. 2014" 203020 0x3190C Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0x454E442E 310152 0x4BB88 CRC32 polynomial table, big endian 312448 0x4C480 Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0x454E442E 316619 0x4D4CB Unix path: /pk/asn1/der/sequence/der_decode_sequence_ex.c 316947 0x4D613 Unix path: /pk/asn1/der/sequence/der_decode_sequence_multi.c 318775 0x4DD37 Unix path: /pk/asn1/der/integer/der_decode_integer.c 319059 0x4DE53 Unix path: /pk/asn1/der/integer/der_length_integer.c 323790 0x4F0CE Ubiquiti partition header, header size: 56 bytes, name: "PARTkernel0", base address: 0x00000001, data size: -2147475456 bytes 323854 0x4F10E uImage header, header size: 64 bytes, header CRC: 0x5CEF3CED, created: 2016-08-30 03:21:13, image size: 7223979 bytes, Data Address: 0x80060000, Entry Point: 0x80060000, data CRC: 0xAB112EF2, OS: Linux, CPU: MIPS, image type: Multi-File Image, compression type: lzma, image name: "MIPS OpenWrt Linux-3.3.8"

Serial: J1: 3v3 (do not use), tx, rx, ground

log: serial_log_AC_mesh_pro.txt

Partitions: BZ.v3.7.12# cat /proc/mtd dev: size erasesize name mtd0: 00060000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00790000 00010000 "kernel0" mtd3: 00790000 00010000 "kernel1" mtd4: 00020000 00010000 "bs" mtd5: 00040000 00010000 "cfg" mtd6: 00010000 00010000 "EEPROM"

After FW upgrade (UniFi firmware 3.7.55 for UAP-AC-Lite/LR/Pro/EDU/M/M-PRO/IW):

Serial log serial_log_AC_mesh_pro_FW_3755.txt

DMESG dmesg_AC_mesh_pro_original_FW_3755.txt

Flash memory dump Unify AC mesh pro (FW 3755): mtd_mesh_pro_3755.zip

[janhanekom]

I have a UAP-AC-M-Pro (Mesh Pro); I have tried, but have been unsuccessful at getting non-stock firmware to run, presumably because of UBoot. I tried downgrading firmware to 3.4.7, but anything lower than 3.4.16 doesn't appear to boot on the device (TFTP upgrades succeed, but the device does not boot. fwupdate.real returns an error, stating it doesn't like the 3.4.7 firmware file.)

Arwed: I'm preplexed by your statement that one should update to the latest stock firmware before flashing custom firmware - were you able to get your unit to flash custom firmware, even with the UBoot installed by recent versions of firmware?

[ArwedSchmidt]

@janhanekom I have only flashed normal mesh APs yet. Therefore my comment was primarily meant for that device. My mesh AP came with "latest stock" back in March/April and we had no issues to flash it. Another mesh ap had a fairly outdated u-boot and bricked (details in my previous comment). I assumed that early mesh ap and ap pro's shipped together and would suffer both from ancient u-boot version (first orders).

Which Gluon version have you tried to flash on the device? If you have trouble with latest u-boot/stock I can add a warning to my comment that there might have been changes that cause compatibility issues.

[janhanekom]

Nevermind, I’ve figured it out! The unit has two Ethernet ports, and it turns out LAN and WAN are the other way around than I expected. When installing UAP-AC-PRO LEDE images onto a UAP-AC-M-PRO, LAN is on the “Secondary” port, and WAN is on the “Main” port (where PoE is connected to.)

(Haven't tried a Gluon image yet - right now I've just been trying to keep it basic and just testing "plain" LEDE. Prior to this I’ve tried both 17.01.1 and an image compiled from trunk.)

So as to my reason for asking about UAP 3.4.7 firmware: There is lots of talk on the LEDE pages and elsewhere about U-Boot in versions subsequent to 3.4.7 (3.4.16+) checking for digital signatures in firmware to block 3rd party firmware. Based on what I just did, I suspect that might no longer be the case, at least with recent firmware? (I had 3.7.55 on my device.)

For what it’s worth: Unifi 3.4.7 indeed does not boot properly on the UAP-AC-M-PRO. It gets partway through, as the AP responds to pings and you can SSH to it, but if you log in using ubnt/ubnt, the session closes immediately. (Logging in with a different password results in “access denied”, so pretty sure the credentials are correct.)

After I’d flashed my UAP-AC-M-PRO with LEDE and it didn’t come up (I flashed both firmware partitions – kernel0 and kernel1 – with the same image just to be sure), I assumed that the U-Boot problem was the cause. However, I eventually spotted odd behaviour which caused to me question that: • I got a single ping response to 192.168.1.1 during boot-up (one and one only, after which the MAC entry timed out of my computer’s ARP table.) • I started seeing DHCPv4 requests; when issued an IP, the device did not allow connections, but the entry showed up in my ARP table • I also saw DHCPv6 requests, which had the FQDN field set to “LEDE”  this was the clincher…

Status right now is that I’m up & running on the “Secondary” port. Similar to tuennes’ initial results, 802.11an/802.11ac does not seem to work yet even though I’ve added the qca988x-ct driver and firmware to my image. Subsequent posts infer he got it working, will try to reproduce.

That’s a challenge for another day… right now, I’m just chuffed I got the basics working without having to crack it open for access to a serial console.

[janhanekom]

Just an update: LAN and WAN being inverted (at least in my opinion) should be correctable in the device profile in LEDE; if I have time in the next few days' I'll try to catch up on how to do (and contribute) that, but it will probably be quicker and less error prone if someone else does it.

5Ghz wireless; not sure if this is related to the AC-M-PRO specifically, but: (tried both ath10k and ath10k-ct)

• I can see and connect to the QCA9880 (?) from 802.11an clients, but 802.11ac clients don't even "see" the SSID. This is true for any channel and bandwidth combination I tested. I also tested setting the "Operation mode" to either AC or N, the behaviour is the same.
• I can only "see" the AP if I choose a channel in the UNII-1 and UNII-2 Mid bands (36-64.) The subset of channels I tried in the UNII-2 Extended band (100-140) do not seem to work, even though they're permitted in the regdomain I configured (and are listed as such when I run "iw phy0 info".) I could not test UNII-3 Upper due to my regdomain. For what it's worth, channels in the UNII-1/2 Mid band requiring DFS and TPC do come up after a little while, so don't think it's related to that.

I find the above behaviour to be rather "weird." Will keep looking.

[rotanid]

afaik it's the default for every similar device, having WAN on the main port, where PoE also is active...

[rotanid]

regarding unifi ac mesh (NOT mesh pro) upstream now has support for this device: https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/lede-ar71xx-generic-ubnt-unifiac-mesh-squashfs-sysupgrade.bin next step probably would be to do a PR for lede-17.01 backport and after that, gluon master

the mesh pro is not yet supported upstream.

[tuennes]

@janhanekom : Which qca988x firmware do have in use? Following this maybe it solves the client problems?

[janhanekom]

Thanks for the heads-up Tuennes - will try to take a look and report back.

[ghost]

https://github.com/lede-project/source/pull/1169

[rotanid]

as two upstream lede devs now rejected the backport, we need to create a patch for gluon itself for this

[neocturne]

I went for the easy solution and simply added an image alias instead of patching LEDE.

[rotanid]

do we have to change something again as soon as we are based on a newer LEDE branch?

[neocturne]

@rotanid We'll need to support the changed model string in the manifest in addition to the old one, using manifest_alias.

[s13884]

Anyone has Datasheet for QCA9563? Or else anyone suggest where can I get the same?

[mobythevan]

Do we know the pinout for connector J3 and if the interface is enabled?

[yunhai20082008]

I think this could be a cool, small device. Hopefully with a nice performance. Please give me hints how I can support you.

Picture of PCB Front: Back without antenna:

Link to OEM-FW Some info out of ssh console: console.txt

Serial console: serial_console.txt

could you do me a favor about this?https://forum.openwrt.org/t/need-a-copy-content-of-full-flash-about-uap-ac-m/140438