ipq40xx: add support for OpenMesh A62

[ecsv]

• QCA IPQ4019
• 256 MB of RAM
• 32 MB of SPI NOR flash (s25fl256s1)
  • 2x 15 MB available; but one of the 15 MB regions is the recovery image
• 2T2R 2.4 GHz
  • QCA4019 hw1.0 (SoC)
  • requires special BDF in QCA4019/hw1.0/board-2.bin with
    bus=ahb,bmi-chip-id=0,bmi-board-id=20,variant=OM-A62
• 2T2R 5 GHz (channel 36-64)
  • QCA9888 hw2.0 (PCI)
  • requires special BDF in QCA9888/hw2.0/board-2.bin
    bus=pci,bmi-chip-id=0,bmi-board-id=16,variant=OM-A62
• 2T2R 5 GHz (channel 100-165)
  • QCA4019 hw1.0 (SoC)
  • requires special BDF in QCA4019/hw1.0/board-2.bin with
    bus=ahb,bmi-chip-id=0,bmi-board-id=21,variant=OM-A62
• multi-color LED (controlled via red/green/blue GPIOs)
• 1x button (reset; kmod-input-gpio-keys compatible)
• external watchdog
  • triggered GPIO
• 1x USB 2.0
• TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
• 2x gigabit ethernet
  • phy@mdio3:
    • Label: Ethernet 1
    • gmac0 (ethaddr) in original firmware
    • 802.3at POE+
  • phy@mdio4:
    • Label: Ethernet 2
    • gmac1 (eth1addr) in original firmware
    • 18-24V passive POE (mode B)
• powered only via POE

The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the factory image to the u-boot when the device boots up.

The initramfs image can be started using

setenv bootargs 'loglevel=8 earlycon=msm_serial_dm,0x78af000 console=ttyMSM0,115200 mtdparts=spi0.0:256k(0:SBL1),128k(0:MIBIB),384k(0:QSEE),64k(0:CDT),64k(0:DDRPARAMS),64k(0:APPSBLENV),512k(0:APPSBL),64k(0:ART),64k(0:custom),64k(0:KEYS),15552k(inactive),15552k(inactive2)'
tftpboot 0x84000000 openwrt-ipq40xx-openmesh_a62-initramfs-fit-uImage.itb
set fdt_high 0x85000000
bootm 0x84000000

As you can see, this PR currently contains some changes from #881 and #879. It doesn't seem to be a good idea to build the support without the other PRs in mind. So you can basically ignore following changes when the other PRs are accepted:

• firmware: ath10k-firmware: update to 2018-04-19
• ipq40xx: Remove unused reserved-memory nodes
• ipq40xx: Move reserved-memory DT to qcom-ipq4019.dtsi

I would like to thank @chunkeey here because he investigated the gpio-hog problem with the pinctrl-msm and prepared several patches for upstream.

---

There are not many informations about this device but OpenMesh just added it to their shop https://store.openmesh.com/products/a62-universal-tri-band-802-11ac-wave-2-cloud-managed-wifi-access-point.html

The u-boot source code can currently only be downloaded from https://drive.google.com/drive/folders/1bBOQH5RCpwi0acJlLd0xs2OComopO5tn?usp=sharing

[mkresin]

I haven't had a look at the driver nor do I have access to a board at the moment, but can't we use the phy-supply from the phy framework as we are doing with lantiq/xrx200 on kernel 4.14 a vbus-supply similar to the lantiq commits in my staging tree?

I mean, the hogged GPIO is a similar workaround as gpio-export and the phyvbus-supply seem to me the "correct" solution for the problem.

One benefit of using phyvbus-supply is that the usb power is disabled if the usb driver is unloaded/not enabled. Furthermroe, this way the usb power can be disabled if the usb port should be used in peripheral mode.

It might that the following works out of the box (update: no it doesn't, neither the dwc3 core nor dwc3-of-simple.c have vbus supply support yet):

soc {
	usb_vbus: regulator-usb-vbus {
		compatible = "regulator-fixed";

		regulator-name = "USB_VBUS";

		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;

		gpio = <&tlmm 58 GPIO_ACTIVE_HIGH>;
		enable-active-high;
	};

	usb2: usb2@60f8800 {
		vbus-supply = <&usb_vbus>;
		status = "okay";
	};
};

Options are already enabled target/linux/ipq40xx/config-4.14 needs the following additional config options:

CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y

I remember that we had a similar issue with ipq806x back in the days and we went with setting the pin output-high/output-low in the pinmux. It is neither a proper solution and just another workaround instead of using the phyvbus-supply.

[ecsv]

As you mentioned in your mail (and also updated your ticket), external vbus-supply is currently not supported by dcw3.

And yes, in theory this might be a good idea to switch to - but it is a rather bad timing the dcw3-qcom is currently upstreamed https://lkml.org/lkml/2018/4/13/508. Not sure what must be done to this driver to correctly enable/disable vbus-supply for peripheral/host mode. At least dwc3-omap.c integrated it very tight to their mailbox system.

[mkresin]

Merged, thanks!

I cherry picked the related commits and removed the patching of the unrelated dtsi from the gpio hog patch.

[ecsv]

Here some additional information about the VBUS: An OC protection circuit was added between powerrail and VBUS pin of the USB connector. The gpio58 is used to control this circuit and allows to disable the power (set it to high - which it is by default). There is a capacitor and thus voltage will not drop directly when setting GPIO58 to high.

[ecsv]

I was just asked in private about following situation:

• device checked in cloudtrax from China (and downloaded new configuration)
• SSH is accessible (User: root + Password configured in cloudtrax, IP taken from cloudtrax AP overview page)
• u-boot is not accessible (just reboots when trying to open the u-boot shell)
• u-boot asks for fwupgrade.cfg.sig when trying to upload factory image using ap51-flash

This means that the device is unlocked but still has the signature check key for installed. I don't know whether this was intended by Datto/OpenMesh or not. But you just have to disable the key in this case to make u-boot accessible again:

if grep KEYS /proc/mtd > /dev/null; then
  dd if=/dev/zero of=/dev/mtdblock9 conv=notrunc bs=1 seek=0 count=8
else
  dd if=/dev/zero of=/dev/mtdblock7 conv=notrunc bs=1 seek=32768 count=8
fi

A new OpenWrt image should be installed immediately to avoid that firmware-ng reinstalls the key again. I don't actually know whether it would do that in this situation but the disabling of the key works (see Datto's u-boot GPL source code for more details).

[pepe2k]

@ecsv here is also related OpenWrt forum topic: https://forum.openwrt.org/t/openwrt-installation-on-openmesh-a62-router/23986

Cheers,
Piotr