Luma Home WiFi support

Is it possible to get support for Luma Home WiFi?? Since the company abandoned the product and I haven't seen any firmware updates for nearly two years..... I have three of these units. Descent hardware specs

http://en.techinfodepot.shoutwiki.com/wiki/Luma_WRTQ-329ACN

Am willing to open one up and be a guinnie pig

IPQ4018 and QCA8075 should be well supported as chips, so it should be "just a matter of time" to be able to support the board. How much time is always the operative question!

Getting the GPL sources would be first on my list, in parallel with getting serial access.

https://openwrt.org/faq/how_can_i_add_support_for_a_new_device


I just saw " Flash2 Size 2 MB" -- If that is just the boot loader and perhaps some "cal" or "factory" data, that should be OK. If the kernel is in there as well (as opposed to on NAND), you may need a shim loader (boot loader loads shim loader as "kernel" which then loads "real" kernel) as the kernel size for IPQ40xx is well over 2 MB at this time.

1 Like

Nice hardware (for the intended purpose, they should have gone with ipq4019 and tri-radio though), sadly not really available in Europe (otherwise I might have been tempted to get a set, as I've been looking for cheap/ used ipq40xx/ ipq806x devices to experiment with for quite a while). The 2 MB flash is most likely used only for bootloader{,-env}, TZ, RPM and ART, pushing the real firmware (kernel+rootfs) to the 128 MB NAND.

Unless you're lucky that someone else stumbles over this device, you probably have to port OpenWrt to it yourself (how feasible that is depends to a large extent on getting serial access, as these mesh clients often omit an accessible header for this (e.g. Linksys velop or eero), at least judging from the FCC images I haven't really found a likely candidate yet).

1 Like

I'll open up the unit and probably have to solder in a header for serial access. As for GPL sources I am not sure about, I'll search around and see what I can find.

Found this. Seems to have a spot for a header, will have to confirm once I open one up.

that thing on the right is definitely a serial header... sometimes oem just disable it in production by removing resistory before the serial header... Doesn't look in this case so... Serial should be plug-n-play ahhaha

J19 is indeed quite likely, especially as it was populated with a header (which fooled me into thinking that it was part of the connection to the light board) in the FCC pictures.

I thought so as well :slight_smile:

Now time to open one up, will be a little while as I am away for a bit.

Thought this info might be of use. Luma is running a customized version of OpenWRT

Browsed to IP: 192.168.55.1, got the below info

deos v2018.01.22-0

process

dconf::uptime 1d 0h 31m 26s
libc::allocated 1346720b (1.28mb)
cc::version 4.8.3
cc::builddate Jan 23 2018 09:29:10
fw::buildver jenkins-luma-firmware-office-build-server-872
libc::version µClibc 0.9.33
ssl::version OpenSSL 1.0.2f 28 Jan 2016

environment

uname::machine armv7l
uname::sys Linux 3.14.43 #1 SMP PREEMPT Fri Feb 24 17:17:23 EST 2017
sys::uptime 1d 0h 32m 36s
sys::processes 140
sys::load1m 0.16
sys::load15m 0.25
sys::totalram 241mb
sys::freeram 56mb
net::w0_channel 1
net::w1_channel 149

Port scan revealed the following:

luma.lan

Status: Alive
Operating system: Linux
IP: 192.168.55.1
MAC:
Manufacturer:
NetBIOS:
User:
Type: Wireless access point
Date:
Comments:
Service Details
HTTP
Port 53 (TCP) domain
Port 80 (TCP)
Port 4369 (TCP) Erlang Port Mapper Daemon
Port 5000 (TCP) MiniUPnP 1.8 OpenWrt Barrier Breaker r48529; UPnP 1.1
Port 5001 (TCP)

Seems that a few devices with the same CPU and SWITCH combo have been ported to OpenWRT. Still waiting to get back home so I can hook up my TTL cable :slight_smile:

https://openwrt.org/toh/views/toh_extended_all?dataflt[CPU*~]=IPQ4018&dataflt[Switch*~]=QCA8075

Anything going on here? I would like to help. I need to be able to set the wan address on the luma and this is probably going to be the only way for me to do that.

Haven't had a chance to go any further with this for now. Got the JTAG pins soldered in and connected to the terminal, but it won't accept any keyboard inputs. Will try again later, just busy with work.

Has any of this research lead to ideas (beyond factory reset) for how to recover a bricked / swirling blue Luma that doesn't respond to resets?

How the heck did you get it open?

The plastic clips holding it together are very visible in the pictures above.

I asked "how" not "what" but thanks anyway.

So, I opened it up by tracing the little gap at the bottom around the first corner going clockwise with a putty knife, sliding inside most of the way, then leveraging the top open by pulling away. Took a lot of force, so be careful!

Yes, that J19 is a serial header, at 115200 baud. The pin nearest the power connector is GND, and the next two are RX/TX.
Here's the boot log:


You can get to a root terminal by getting into "failsafe mode" by typing "f" then enter during bootup!
I'm not sure what to do next... (time to read some openwrt page about porting to a new device!).
1 Like

After getting to failsafe, invoke mount_root, it mounts ubi rootfs. Next type fw_printenv and store values somewhere safe. Next sed -e 's/root:x:/root::/' -i /etc/passwd to reset asking for password and also fw_setenv bootdelay 3 to have possibility to acces U-Boot shell. After rebooting login as root, now You can play fo example with led ring with led_ctl command, enjoy.

I have been poking this device since Friday, basic things work already on OpenWrt. What's missing is:

  • finding gpios activating i2c,
  • ready to flash image,
  • a way to disable leds ring.
1 Like

That works!
So what target are you using for an openwrt build for this? And how would we flash the resulting image to the device now?