[OpenWrt-Devel] [PATCH] ramips: add support for Ubiquiti UniFi nanoHD

David Bauer mail at david-bauer.net
Mon Mar 9 09:05:01 EDT 2020


Hello Adrian,

On 3/9/20 1:18 PM, Adrian Schmutzler wrote:
> Hi David,
> 
>> -----Original Message-----
>> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On
>> Behalf Of David Bauer
>> Sent: Montag, 9. März 2020 02:07
>> To: openwrt-devel at lists.openwrt.org
>> Subject: [OpenWrt-Devel] [PATCH] ramips: add support for Ubiquiti UniFi
>> nanoHD
>>
>> Hardware
>> --------
>> SoC:   MediaTek MT7621AT
>> WiFi:  MediaTek MT7603 bgn 2T2R
>>        MediaTek MT7615 ac  4T4R
>> Flash: 32M SPI (Macronix MX25L25635F)
>> RAM:   128M DDR3 (Winbond W631GG6KB)
>> LED:   Dome (Blue / White)
>> BTN:   Reset
>>
>> Installation
>> ------------
>>
>> These instructions were written for firmware version v3.9.27.
>> Downgrade if necessary.
>>
>> 1. Copy the OpenWrt sysupgrade image to the devices /tmp folder
>>    via scp. On factory defaults, user and password is "ubnt" at
>>    192.168.1.20/24.
>>
>> 2. Write the bootselect flag. Otherwise, the device might boot from the
>>    wrong partition. Verify the mtd partition used in the command below
>>    is the one labled "bs" in /proc/mtd (as this might change in the
>>    future).
>>
>>    > dd if=/dev/zero bs=1 count=1 of=/dev/mtd4
>>
>> 3. Write the OpenWrt sysupgrade to the mtd partitions labled
>>    "kernel0" and "kernel1".
>>
>>    > dd if=/tmp/openwrt-sysupgrade.bin of=/dev/mtdblock6
>>    > dd if=/tmp/openwrt-sysupgrade.bin of=/dev/mtdblock7
>>
>> 4. Reboot or powercycle the device.
>>
>> Signed-off-by: David Bauer <mail at david-bauer.net>
>> ---
>>  .../dts/mt7621_ubiquiti_unifi-nanohd.dts      | 141 ++++++++++++++++++
>>  target/linux/ramips/image/mt7621.mk           |   8 +
>>  .../mt7621/base-files/etc/board.d/02_network  |   3 +-
>>  3 files changed, 151 insertions(+), 1 deletion(-)
>>  create mode 100644 target/linux/ramips/dts/mt7621_ubiquiti_unifi-nanohd.dts
>>
>> diff --git a/target/linux/ramips/dts/mt7621_ubiquiti_unifi-nanohd.dts
>> b/target/linux/ramips/dts/mt7621_ubiquiti_unifi-nanohd.dts
>> new file mode 100644
>> index 0000000000..7d39242efa
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/mt7621_ubiquiti_unifi-nanohd.dts
>> @@ -0,0 +1,141 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> +/dts-v1/;
>> +
>> +#include "mt7621.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +
>> +/ {
>> +	compatible = "ubiquiti,unifi-nanohd", "mediatek,mt7621-soc";
> 
> The two Edgerouter X devices in ramips are the only two cases in trunk that use
> "ubiquiti" for the vendor string instead of the recommended "ubnt".
> 
> IMO we should use the latter also for this new device (and consider changing the
> edgerouter devices at some point as well).
> 
>> +	model = "Ubiquiti UniFi nanoHD";
>> +
>> +	aliases {
>> +		led-boot = &led_white;
>> +		led-failsafe = &led_white;
>> +		led-running = &led_blue;
>> +		led-upgrade = &led_blue;
>> +
>> +		label-mac-device = ðernet;
>> +	};
>> +
>> +	chosen {
>> +		bootargs = "console=ttyS0,115200";
>> +	};
>> +
>> +	leds {
>> +		compatible = "gpio-leds";
>> +
>> +		led_blue: power_amber {
> 
> power_amber?
> 
>> +			label = "nanohd:blue:dome";
>> +			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
>> +		};
>> +
>> +		led_white: power_green {
> 
> power_green?

Will fix these.

> 
>> +			label = "nanohd:white:dome";
>> +			gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
>> +		};
>> +	};
>> +
>> +	keys {
>> +		compatible = "gpio-keys";
>> +
>> +		reset {
>> +			label = "reset";
>> +			gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
>> +			linux,code = <KEY_RESTART>;
>> +		};
>> +	};
>> +};
>> +
>> +&spi0 {
>> +	status = "okay";
>> +
>> +	flash at 0 {
>> +		compatible = "mx25l25635f", "jedec,spi-nor";
>> +		reg = <0>;
>> +		spi-max-frequency = <10000000>;
> 
> No higher speed possible?

Last time I've checked, the SPI speed was still calculated based on an incorrect
reference clock for MT7621, thus the frequency defined will not match the one
configured to the hardware.
Are you aware if this has already been fixed in Kernel 4.14?

> 
>> +
>> +		partitions {
>> +			compatible = "fixed-partitions";
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +
>> +			partition at 0 {
>> +				label = "u-boot";
>> +				reg = <0x0 0x60000>;
>> +				read-only;
>> +			};
>> +
>> +			partition at 60000 {
>> +				label = "u-boot-env";
>> +				reg = <0x60000 0x10000>;
>> +				read-only;
>> +			};
>> +
>> +			factory: partition at 70000 {
>> +				label = "factory";
>> +				reg = <0x70000 0x10000>;
>> +				read-only;
>> +			};
>> +
>> +			eeprom: partition at 80000 {
>> +				label = "eeprom";
>> +				reg = <0x80000 0x10000>;
>> +				read-only;
>> +			};
>> +
>> +			partition at 90000 {
>> +				label = "bs";
>> +				reg = <0x90000 0x10000>;
>> +			};
>> +
>> +			partition at a0000 {
>> +				label = "cfg";
>> +				reg = <0xa0000 0x100000>;
>> +				read-only;
>> +			};
>> +
>> +			partition at 1a0000 {
>> +				compatible = "denx,uimage";
>> +				label = "firmware";
>> +				reg = <0x1a0000 0xf30000>;
>> +			};
>> +
>> +			partition at 10d0000 {
>> +				label = "kernel1";
>> +				reg = <0x10d0000 0xf30000>;
>> +				read-only;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&pcie {
>> +	status = "okay";
>> +};
>> +
>> +&pcie0 {
>> +	wifi at 0,0 {
>> +		reg = <0x0 0 0 0 0>;
>> +		mediatek,mtd-eeprom = <&factory 0x0000>;
>> +	};
>> +};
>> +
>> +&pcie1 {
>> +	wifi at 0,0 {
>> +		reg = <0x0 0 0 0 0>;
>> +		mediatek,mtd-eeprom = <&factory 0x8000>;
>> +	};
>> +};
>> +
>> +&ethernet {
>> +	mtd-mac-address = <&eeprom 0x0>;
>> +};
>> +
>> +&state_default {
>> +	gpio {
>> +		ralink,group = "i2c", "uart2";
> 
> uart2 would match <&gpio0 12 ...>, but you have <&gpio1 12 ...> for the key?

Has already been fixed, the button is attached to the wrong controller.

Best wishes
David

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list