Luma Home WiFi support

For Developers
21

No image for flashing is ready yet. The nand flash seems to be storing two sets of kernel and rootfs, one of the set seems to be a backup, but I can't trigger the backup set. Don't know if that was ever implemented and that is main decision which will affect creation of image to flash. Keep the flash layout and replace one set of kernel+rootfs or mark the whole flash for OpenWrt to use it.

The target in use is ipq40xx. You can use this image to boot the board from U-Boot using TFTP server: https://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/openwrt-ipq40xx-generic-qcom_ap-dk01.1-c1-initramfs-fit-uImage.itb
This image will leave no permanent changes.

Remember DO NOT flash any image yet. There's no OEM image for download in case You want to revert to factory.

1 Like
22

Wow. That works!

For reference, what I did was:
hit a key during boot to get to uboot menu
type "help" to see commands
type "tftpboot"
read what was there and then setup my computer/tftpserver to be on the right ip address and the file in the right place with the right name:
sudo cp openwrt-ipq40xx-generic-qcom_ap-dk01.1-c1-initramfs-fit-uImage.itb /srv/tftp/C0A80B0E.img
type "bootm"

23

I see this in dmesg...
[ 43.990259] i2c-gpio i2c-gpio.0: using pins 1 (SDA) and 0 (SCL)
There does seem to be i2c traffic (verified with a scope) on two of the black wires leading to the led board. The other wires are all at GND, 3.3V, or 5V.

Actually, the SDA and SCL go to Test Points (TP3 and TP4) near the microprocessor on the LED board, respectively. I soldered wires to them, and fed them into A4 and A5 on an arduino, and ran this slave i2c code to spy on the data as I sent led_ctl commands from the luma: https://www.arduino.cc/en/Tutorial/MasterWriter

I could tell that the luma was addressing 0x48 by doing:
i2cdetect -y 0 (on the luma)
There also seems to be some devices at 0x50-0x57, but only 0x57 has any data, which you can see with e.g.:
i2cdump -y 0 0x57
It seems to be the default wifi ssid of the device, something I can't recognize, and the serial number. It's likely a flash nvram.
You can read/write from/to it with e.g.:
i2cset -y 0 0x56 0x40 0xef
i2cget -y 0 0x56 0x40
But I digress!

The LEDs can be controlled with i2cset commands just like they can from led_ctl. See the led_ctl commands below. Each command has up to four numbers. The first is the mode, the second is the color, and the third and forth depends on the command. For instance,
i2cset -y 0 0x48 3 1 9 0 i
would set it to solid red brightness=9 (and the fourth value is not used for that command).
The modes go from 3 to 8, for solid to pulsing.
The colors go from 1 to 7, for red to white (except blue and yellow are switched, so it really goes red, green, yellow, blue, purple, cyan, white).

root@luma:~# led_ctl
Usage: led_ctl [status | upgrade | force_upgrade | version]
led_ctl solid COLOR
led_ctl single COLOR INDEX <brightness 0 - 15>
led_ctl spinning COLOR <period 1 - 16 (lower = faster)>
led_ctl fill COLOR <period 1 - 16 (lower = faster)>
( default is 5 )
led_ctl flashing COLOR <on dur 1 - 128> <off dur 1 - 128>
(default is 34) ( default is 34 )
led_ctl pulsing COLOR
COLOR: red, green, blue, yellow, purple, cyan, white

24

At first i dismissed that, but those are indeed the needed gpios. Here: https://github.com/tmn505/openwrt/tree/luma is preliminary support. Still only boot through TFTP is supported.
You can read the contents of eeprom with cat /sys/devices/platform/i2c-gpio/i2c-2/2-0050/eeprom.

The first "LUMA" is simply a sanity check for OEM firmware commands. The second is an UUID, I would assume it is used for communication with the "cloud". The third is indeed product serial.
You can check /opt/luma/bin, there are a lot of interesting scripts which led to those conclusions.

Unfortunately someone would need to write driver or application for interfacing with the leds ring, I don't have the needed skills atm. This led ring is driven by MSP430 micro controller.

1 Like
25

Just tried out your luma branch. Works great!
To turn off the led ring, you can do:
i2cset -y 2 0x48 3 1 0 0 i
Or if you want a nice red light:
i2cset -y 2 0x48 3 1 10 0 i

I'd really like to try flashing one of them with this, to make it permanent. I have 8 or 9 lumas, and I could care less if one gets bricked. :slight_smile: How would I do this? From the uboot prompt?

Thanks!
PS - I've got these configured with 802.11s+BATMAN and they are working WAY better than the original luma firmware (which seemed to be based on some AP+STA architecture, from looking at their /etc/config/wireless file... am I wrong?). I am getting a consistent ~75 Mb/s now after going from luma <-> lumas <-> router <-> modem, whereas I was lucky to get 20-30Mb/s before.

1 Like
26

The image for flashing is on the menu for upcoming days, I'll start to work on it tomorrow.
I didn't test yet the wireless throughput. You can test the OpenWrt image with the board-2.bin extracted from the factory flash, just remove double slashes in two lines at the end of dts, and add ipq-wifi-luma_wrtq-329acn to DEVICE_PACKAGES array in device definition for Luma intarget/linux/ipq40xx/image/Makefile.

27

Please post an cat /proc/mtd output from factory image.

28 
root@luma:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00040000 00010000 "0:SBL1"
mtd1: 00020000 00010000 "0:MIBIB"
mtd2: 00060000 00010000 "0:QSEE"
mtd3: 00010000 00010000 "0:CDT"
mtd4: 00010000 00010000 "0:DDRPARAMS"
mtd5: 00010000 00010000 "0:APPSBLENV"
mtd6: 00080000 00010000 "0:APPSBL"
mtd7: 00010000 00010000 "0:ART"
mtd8: 08000000 00020000 "rootfs"
mtd9: 0041e000 0001f000 "kernel"
mtd10: 026c0000 0001f000 "ubi_rootfs"
mtd11: 01ff8000 0001f000 "rootfs_data"
mtd12: 0041e000 0001f000 "kernel1"
mtd13: 026c0000 0001f000 "ubi_rootfs1"
'''
29

Mine differs from Yours, please post outputs of:
cat /etc/firmware_version
and
cat /opt/luma/bin/create_dualbank.sh

Thanks

30 
root@luma:~# cat /etc/firmware_version 
1.1-18

root@luma:~# cat /opt/luma/bin/create_dualbank.sh 
# This script is used for create/re-partition the firmware bank
# on the luma devices in the field.
#
#!/bin/sh

set -e
set -o

#MTD part of NAND FLASH
MTD_PART_NAND=/dev/mtd8
UBI_DEV_FILE=/dev/ubi0

#flash map
#Actual Physical block size of NAND is 128KB
#UBI will consider only 124KB as logical block
#remaining 4KB will be used for storing the metadata of each block.
DEF_BANK0_PART_SIZE=366   #45 MB   (kernel+ubi_rootfs)
DEF_ORLAY_PART_SIZE=264   #32 MB  (rootfs_data)
DEF_BANK1_PART_SIZE=366   #45 MB   (kernel1+ubi_rootfs1)
DEF_RESVD_PART_SIZE=28    # 3 MB   resreved for bad block


#mtd part size defination
DEF_DUMMYD_MTD_PART_SIZE=51  #6 MB
DEF_KERNEL_MTD_PART_SIZE=34  #4 MB
DEF_ROOTFS_MTD_PART_SIZE=320 #39 MB
DEF_OVRLAY_MTD_PART_SIZE=264 #32 MB  (rootfs_data)


switch_to_ramfs()
{
#    echo "Switch to Ramfs to re-part the NAND flash"
    /opt/luma/bin/run_ramfs.sh
    RAMFS_MODE=1
}

create_bank0_part()
{
    DUMMY_PART=`grep 'dummy' /proc/mtd  | wc -l`
    if [ $DUMMY_PART -eq 1 ]; then
     echo "Create the Bank 0 Partition" > /dev/kmsg

     #At this stage we never bricked the units, we have active bank 1 image.
     #also we dont need to switch to ramfs during this process

     ubirmvol $UBI_DEV_FILE -N dummy
     ubirmvol $UBI_DEV_FILE -N kernel
     ubirmvol $UBI_DEV_FILE -N ubi_rootfs
     ubimkvol $UBI_DEV_FILE -S $DEF_KERNEL_MTD_PART_SIZE -N kernel --type=dynamic
     ubimkvol $UBI_DEV_FILE -S $DEF_ROOTFS_MTD_PART_SIZE -N ubi_rootfs --type=dynamic

     echo "Bank0 Re-Partition Created successfully" > /dev/kmsg
     exit 0
    else
     echo "Bank0 Re-Partition fail to create" >&2 > /dev/kmsg
     exit 1
    fi;
}

create_bank1_part()
{
    BANK1_PART=`grep 'ubi_rootfs1' /proc/mtd | wc -l`
    if [ $BANK1_PART -eq '0' ] ; then
     echo "Create the Bank 1 Partition" > /dev/kmsg
     echo "Copy the overlay to /tmp" > /dev/kmsg
     cp -rf /overlay /tmp/.

     switch_to_ramfs

     ubidetach -f -p $MTD_PART_NAND
     ubiattach -p $MTD_PART_NAND
     ubirmvol $UBI_DEV_FILE -N rootfs_data
     ubimkvol $UBI_DEV_FILE -S $DEF_DUMMYD_MTD_PART_SIZE -N dummy --type=dynamic
     ubimkvol $UBI_DEV_FILE -S $DEF_OVRLAY_MTD_PART_SIZE -N rootfs_data --type=dynamic
     mkfs.ubifs --max-leb-cnt=264 --reserved=4329881 -r /tmp/overlay ${UBI_DEV_FILE}_3
     ubimkvol $UBI_DEV_FILE -S $DEF_KERNEL_MTD_PART_SIZE -N kernel1 --type=dynamic
     ubimkvol $UBI_DEV_FILE -S $DEF_ROOTFS_MTD_PART_SIZE -N ubi_rootfs1 --type=dynamic

     echo "Bank1 Partition Created successfully" > /dev/kmsg

     if [ $RAMFS_MODE -eq '1' ]; then
       exit 0
     fi
    else
     echo "Bank1 Partition fail to create" >&2 > /dev/kmsg
     exit 1
    fi;
}

if [ $# -ne 1 ]; then
    echo "Usage: $0: primary/alternate "
    exit 1
fi;

if [ "$1" = "primary" ] ; then
    create_bank0_part
elif [ "$1" = "alternate" ] ; then
    create_bank1_part
else
echo "invalid bank partiton name" >&2
exit 2
fi;
'''
31

Here's another data point:

root@luma:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "0:SBL1"
mtd1: 00020000 00010000 "0:MIBIB"
mtd2: 00060000 00010000 "0:QSEE"
mtd3: 00010000 00010000 "0:CDT"
mtd4: 00010000 00010000 "0:DDRPARAMS"
mtd5: 00010000 00010000 "0:APPSBLENV"
mtd6: 00080000 00010000 "0:APPSBL"
mtd7: 00010000 00010000 "0:ART"
mtd8: 08000000 00020000 "rootfs"
mtd9: 003a2000 0001f000 "kernel"
mtd10: 02283000 0001f000 "ubi_rootfs"
mtd11: 0062d000 0001f000 "dummy"
mtd12: 01ff8000 0001f000 "rootfs_data"
mtd13: 0041e000 0001f000 "kernel1"
mtd14: 026c0000 0001f000 "ubi_rootfs1"
root@luma:~# cat /etc/firmware_version 
1.1-18
32

This is really great and exciting news. Looking forward to giving it a go here too, I have 6 lumas in my net.

Will we need to solder pins for every luma we want to u/g or will there be a way to u/g without?

33

I'm guessing you're gonna have to crack each one open and attach the serial header, type those few commands to get into the root or uboot prompt, and then run the upgrade.
But fear not, soldering is not required. You can hold the header pins into the holes for the 30 seconds it takes to type those commands.

34

It would be really great if we figured out how the luma checked for a new release and then downloaded and installed it - then fake it out to install the real deal.

On the other hand, if we have to open them up, with 6 more to go I should be pretty good at it by the time I am all done.

35

The UART connection is mandatory. The updates through OTA or USB flash stick are signed. Unless You somehow get access to signing key.

The images are ready. These are with additional packages set:
luci-ssl
i2c-tools
nand-utils
usbutils
kmod-fs-exfat
kmod-fs-ext4
kmod-fs-vfat
kmod-usb-storage

https://tmn505.github.io/openwrt/openwrt-ipq40xx-generic-luma_wrtq-329acn-initramfs-fit-uImage.itb
https://tmn505.github.io/openwrt/openwrt-ipq40xx-generic-luma_wrtq-329acn-squashfs-sysupgrade.bin

They are compiled from this tree:


the installation instructions are in message from commit titled:
ipq40xx: add support for Luma WRTQ-329ACN

Enjoy.

2 Likes
36

Thank you, thank you.
Unfortunately I cannot get good communication with my lumas, I have tried 2. Something is wrong with my setup. I have a usb to serial converter. I connect the ground and receive and get a screen full of gibberish. I have tried everything I can think of and at a standstill. Any thoughts?

37

Try switching the TX and RX lines. I can never keep them straight. Also make sure you set your terminal program to talk at 115200 baud. And be sure your usb adapter is set to talk to 3.3V, not 5V.

38

That is probably the issue. It is just a regular USB to serial adapter and regular RS232 is at 5VDC if I recall correctly. Do you have a recommendation on a USB to RS232 adapter that will work?

39
1 Like
40

I ordered one, thanks!