I don't know if I have enough skills to make a translation layer for ubus commands to what ever the device requires, and I don't know if it is totally possible in reality.
It runs a highly modified version of Openwrt from donkeys ago a lot has changed since then it also centers around features implemented by the oem not in openwrt or not in the same format or way.
In reality one could create a small stm32 Linux distribution for the lcd and build their own control, but it is a lot of work.
I added the link to the Wiki you created to the GitHub page 
I wasn’t home for the last few days so I’ll try to continue where we left of today/tomorow night.
Our first priority is to get the actual device to fully work properly I can really imagine it’s gonna be near impossible to make the LCD work…
BROWN is Ground
BLACK is RX
WHITE is TX
4TH pin probably VCC
Logic: 8N1 3V 115200
@professor_jonny let’s continue on this thread next time
To anyone following I have updated the wiki with flashing info and created new images.
You should be able to flash from the initramfs image now.
The stock layout of the Nand is a little odd the kernel root fs is split and only 4Mib and 20 Mib there is another partition called stats that we may be able to format and extend rootfs into this area.
once it is confirmed working, we can look at extending rootfs, or possibly format the whole nand as rootfs depending on what the bootloader will allow.
Awesome, thanks for the update!
I’ll give the new initramfs image a try once my setup is working again.
Will see
NEW:
Project paused for 4 weeks.
Project halted for undefined time*
for this device is does not seem to have any tel tale sign in the env the dual boot mechanism.
the ubi partition layout is odd for a modern device:
Current Layout Analysis
Dual-boot partitions (A/B scheme):
kernel (4.4 MiB) + rootfs (19.1 MiB) = 23.5 MiB - Partition set 1
kernel2 (4.4 MiB) + rootfs2 (19.1 MiB) = 23.5 MiB - Partition set 2
Recovery:
kernel_recovery (3.9 MiB) + rootfs_recovery (11.5 MiB) = 15.4 MiB
Other:
cfg + cfg2 (dual config) = 2 MiB
stats = 116 MiB (This is suspiciously large)
lcm = 11.1 MiB
Available = 50.6 MiB
We are going to hit the kernel limit even with a conservative OpenWrt image.
I'm guessing stats is the user partition and OEM telemetry
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:127
Present UBI devices: ubi0
ubi0
Volumes count: 10
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 2048 (260046848 bytes, 248.0 MiB)
Amount of available logical eraseblocks: 418 (53075968 bytes, 50.6 MiB)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 40
Current maximum erase counter value: 42
Minimum input/output unit size: 2048 bytes
Character device major/minor: 247:0
Present volumes: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 37 LEBs (4698112 bytes, 4.4 MiB)
State: OK
Name: kernel2
Character device major/minor: 247:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 158 LEBs (20062208 bytes, 19.1 MiB)
State: OK
Name: rootfs2
Character device major/minor: 247:2
-----------------------------------
Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 9 LEBs (1142784 bytes, 1.0 MiB)
State: OK
Name: cfg2
Character device major/minor: 247:3
-----------------------------------
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 9 LEBs (1142784 bytes, 1.0 MiB)
State: OK
Name: cfg
Character device major/minor: 247:4
-----------------------------------
Volume ID: 4 (on ubi0)
Type: dynamic
Alignment: 1
Size: 37 LEBs (4698112 bytes, 4.4 MiB)
State: OK
Name: kernel
Character device major/minor: 247:5
-----------------------------------
Volume ID: 5 (on ubi0)
Type: dynamic
Alignment: 1
Size: 158 LEBs (20062208 bytes, 19.1 MiB)
State: OK
Name: rootfs
Character device major/minor: 247:6
-----------------------------------
Volume ID: 6 (on ubi0)
Type: dynamic
Alignment: 1
Size: 958 LEBs (121643008 bytes, 116.0 MiB)
State: OK
Name: stats
Character device major/minor: 247:7
-----------------------------------
Volume ID: 7 (on ubi0)
Type: dynamic
Alignment: 1
Size: 33 LEBs (4190208 bytes, 3.9 MiB)
State: OK
Name: kernel_recovery
Character device major/minor: 247:8
-----------------------------------
Volume ID: 8 (on ubi0)
Type: dynamic
Alignment: 1
Size: 95 LEBs (12062720 bytes, 11.5 MiB)
State: OK
Name: rootfs_recovery
Character device major/minor: 247:9
-----------------------------------
Volume ID: 9 (on ubi0)
Type: dynamic
Alignment: 1
Size: 92 LEBs (11681792 bytes, 11.1 MiB)
State: OK
Name: lcm
Character device major/minor: 247:10
The idea might be to delete the stats partition and expand into that area:
# Example layout for 256 MiB with dual-boot:
# kernel (8 MiB) + rootfs (80 MiB) = 88 MiB per slot
# kernel2 (8 MiB) + rootfs2 (80 MiB) = 88 MiB
# Total: 176 MiB for OS, rest for overlay/config
I've got a AFi-ALN-R and a AFi-ALN-P MeshPoint wired up via serial if I can help in anyway.
I'm very interested in repurposing these devices as I mainly use Ubiquiti U6 AP's now.
Forgive me if I'm not posting to the correct area, I'm new to OpenWrt Project and this forum.
OpenWrt support for this device is a draft on the main repo, you can clone it and build it.
The things that have not been tested is flashing it to a device and see if NV ram updates the interfaces mac addresses on init.
The other thing that won't work and likely never will is the LCM/ LCD support it would require reverse engineering.
Bluetooth is supported but there is no mechanism to load the config for coexistence in OpenWrt, it needs something like what ath10k driver has where board files are loaded on boot to support this feature but i don't think it really matters, not many will use Bluetooth any way.
The partition layout on the device if really restrictive and ideally it needs to be repartitioned to increase the partition sizes but again I don't have a device to try this, to see if the bootloader will like this.
If you could build and flash it to a device and it works we can likely change it out of draft state.
Could you post the boot log for the meshpoint?
Ultimately a dump of the meshpoints Nand would be great as I could add support for it too, but if it is like the main device the smem partition layout is broken and I will need to create a DTS and a ram image so you can dump it properly.
Just setting up a TFTP server to dig a bit deeper.
I'll step through the instructions and post the boot log in a bit.
Like I said, I'm a little new to this so bear with me 
OEM Boot Log for the AFi-ALN-P MeshPoint - Emperor Emerald 4.0.6
This may be of interest. It's not released yet but looks very similar to the AmpliFi Alien 
Hey 
just to give a bit of context I’m the one who originally opened the thread and started testing on the ALN-R some time ago.
I took a bit (long) of a break due to work, but I’m back now and will continue testing.
Great to see someone else with both the ALN-R and MeshPoint jumping in — the more hardware the better.
I’ll resume where I left off (env capture / factory comparison etc.) and we’ll see how it develops.
and no worries at all we’re all learning as we go.
This thread has been a bit experimental from the start anyway.
The more people with hardware testing things, the better.
Yep, I’m aware of it 
Jonny and I discussed it earlier. It looks like it could be in the same platform family, but we’re focusing on Alien first.