[PATCH v2 1/2] ipq40xx: add support for Luma Home WRTQ-329ACN

Tue Sep 15 10:50:26 EDT 2020

Hi Christian, thanks for looking at this.

W dniu 13.09.2020 o 00:04, Christian Lamparter pisze:
> On 2020-08-30 13:28, Tomasz Maciej Nowak wrote:
>> Luma Home WRTQ-329ACN, also known as Luma WiFi System, is a dual-band
>> wireless access point.
>>
>> Specification
>> SoC: Qualcomm Atheros IPQ4018
>> RAM: 256 MB DDR3
>> Flash: 2 MB SPI NOR
>>         128 MB SPI NAND
>> WIFI: 2.4 GHz 2T2R integrated
>>        5 GHz 2T2R integrated
>> Ethernet: 2x 10/100/1000 Mbps QCA8075
>> USB: 1x 2.0
>> Bluetooth: 1x 4.0 CSR8510 A10, connected to USB bus
>> LEDS: 16x multicolor LEDs ring, controlled by MSP430G2403 MCU
>> Buttons: 1x GPIO controlled
>> EEPROM: 16 Kbit, compatible with AT24C16
>> UART: row of 4 holes marked on PCB as J19, starting count from the side
>>        of J19 marking on PCB
>>        1. GND, 2. RX, 3. TX, 4. 3.3V
>>        baud: 115200, parity: none, flow control: none
>>
>> The device supports OTA or USB flash drive updates, unfotunately they
>> are signed. Until the signing key is known, the UART access is mandatory
>> for installation. The difficult part is disassembling the casing, there
>> are a lot of latches holding it together.
>>
>> Teardown
>> Prepare three thin, but sturdy, prying tools. Place the device with back
>> of it facing upwards. Start with the wall having a small notch. Insert
>> first tool, until You'll feel resistance and keep it there. Repeat the
>> procedure for neighbouring walls. With applying a pressure, one edge of
>> the back cover should pop up. Now carefully slide one of the tools to
>> free the rest of the latches.
>> There's no need to solder pins to the UART holes, You can use hook clips,
>> but wiring them outside the casing, will ease debuging and recovery if
>> problems occur.
>>
>> Installation
>> 1. Prepare TFTP server with OpenWrt initramfs image.
>> 2. Connect to UART port (don't connect the voltage pin).
>> 3. Connect to LAN port.
>> 4. Power on the device, carefully observe the console output and when
>>     asked quickly enter the failsafe mode.
>> 5. Invoke 'mount_root'.
>> 6. After the overlayfs is mounted run:
>>       fw_setenv bootdelay 3
>>     This will allow to access U-Boot shell.
>> 7. Reboot the device and when prompted to stop autoboot, hit any key.
>> 8. Adjust "ipaddr" and "serverip" addresses in U-Boot environment, use
>>     'setenv' to do that, then run following commands:
>>       tftpboot 0x84000000 <openwrt_initramfs_image_name>
>>       bootm 0x84000000
>>     and wait till OpenWrt boots.
>> 9. In OpenWrt command line run following commands:
>>       fw_setenv openwrt "setenv mtdids nand1=spi_nand; setenv mtdparts mtdparts=spi_nand:-(ubi); ubi part ubi; ubi read 0x84000000 kernel1; bootm 0x84000000"
>>       fw_setenv bootcmd "run openwrt"
> So, because you install from the initramfs and introduced a custom run
> command with a custom "kernel1" ubi volume... It might be possible to
> cut the extra parts in the sysupgrade and bootargs and unify it with
> the generic nand_do_upgrade() crowed.
> 
> I've incorperated what maybe could be done in this patch on my
> staging tree: [0]
> 
> (Note the changes in step 9 (kernel1->kernel), step 10 (ubirmvol ubi_rootfs1 & kernel1) and the "step 2 in
> back to OEM".
> 
> The idea is that we use OpenWrt's existing automount for ubi
> and "rootfs" volumes.
> 
> (In theory this could make the "back to OEM" even easier.
> Because if it works the way I think it does, we could drop
> the ubirmvol of ubi_rootfs1 and kernel1 in step 10 of my version.
> Next, it should be possible to drop the ubimkvol of
> kernel1 and ubi_rootfs1 step 2 in the "Reverting to OEM" section.
> This is because the original rootfs1 and kernel1 still exist and
> are left untouched - no idea if this works out or not.)

Personally I would like to use whole NAND for OpenWrt, that would simplify everything a lot.
Unfortunately some users might be dissatisfied with how things are done in OpenWrt and wish
to revert to stock firmware. I'll explain in points what are the current issues with this
device. My knowledge is based on what I could dig out from firmware (QSDK) without access to
source modifications.

1. The devices have different flash layouts, some come with
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"

and some

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"

this reflects the bootargs in dts.

2. As illustrated above, the device comes with two sets of kernel+ubi_rootfs and shared
overlay "rootfs_data". The U-Boot with 'bootipq' command boots the first kernel+ubi_rootfs
pair. There is some kind of fallback mechanism to issue boot from the second pair, but I was
unable to trigger it (didn't try hammer approach by deleting first kernel+ubi_rootfs set).

3. On each reboot the 'bootipq' command rewrites some of U-Boot environments variables to
default state. I don't know every one of them and that makes this not a stable environment,
which could overwrite our changes. Also this increases flash wear (it's NOR, I know, but still).
That's why I decided to introduce custom 'bootcmd'.

4. The stock firmware likes to fiddle with U-Boot environment from userspace. I could miss
some case of it and users who reverted to stock firmware (which would need custom 'bootcmd'
if we went with Your changes) could end up with OpenWrt booted after reboot (in best case)
or in U-Boot shell. Explaining what to do, would include non-trivial tasks for average user.
This is why I decided to write OpenWrt firmware to kernel1+ubi_rootfs1 set.

5. What we have stored in flash is all we've got in terms of OEM firmware. There is no
downloadable image (I know of) we could use to flash the device with, in case no backup is
made and all partitions are wiped.
Given that, I decided to go for reverting to OEM setup, as close as possible, so self-heal
implemented in stock firmware won't be confused.

> 
> Note: I've squashed both of your patches into one.

ACK

> 
> Note2: You don't mention it in your commit. But I'm seeing that you are
> using GPIO OPEN_DRAIN for the bitbanged i2c. So, don't you also need
> Brain's pinctrl patch that wires up OPEN_DRAIN for this? [1]

I went with suggestion in [3], but even setting to GPIO_ACTIVE_HIGH is enough. I tested
this with and without Brian's patch. Should I send v3 without GPIO_OPEN_DRAIN?

> 
> Currently, I've added it to the staging tree too (see the parent patch [2]).
> If you haven't heard of this patch before, please also give it a quick
> spin and see if it changes anything or not. Thanks.
> 
> Cheers,
> Christian
> 
> [0] <https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=f0aead0152574ed8ea24fec1ef6ee54ff3627c3e>
> [1] <https://patchwork.ozlabs.org/project/openwrt/patch/20200718205148.1743807-5-computersforpeace@gmail.com/>
> [2] <https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=68d0dc5802a8b670a06c02b9797ab7ca237da502>

[3] <https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-gpio.txt>

-- 
TMN