mirror of
https://github.com/openwrt/openwrt.git
synced 2024-12-26 00:41:17 +00:00
6f31941d38
Some MT7915 devices need to load the second part of the eeprom to
work properly. The mt76 driver is not yet ready to read the pre-cal
data via the NVMEM cell. Therefore, partially revert commit to fix
the device probe issue on some devices.
P.S.
Except for D-Link and Ubnt devices, It is still uncertain whether
pre-cal data is required for other devices in the patch.
This partially reverts commit 9ac891f8c4.
Fixes: https://github.com/openwrt/openwrt/issues/13700
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
130 lines
2.4 KiB
Plaintext
130 lines
2.4 KiB
Plaintext
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
|
|
|
|
#include "mt7621_ubnt_unifi.dtsi"
|
|
|
|
/ {
|
|
compatible = "ubnt,unifi-6-lite", "mediatek,mt7621-soc";
|
|
model = "Ubiquiti UniFi 6 Lite";
|
|
|
|
chosen {
|
|
bootargs-override = "console=ttyS0,115200";
|
|
};
|
|
};
|
|
|
|
&spi0 {
|
|
status = "okay";
|
|
|
|
flash@0 {
|
|
compatible = "jedec,spi-nor";
|
|
reg = <0>;
|
|
spi-max-frequency = <50000000>;
|
|
|
|
partitions {
|
|
compatible = "fixed-partitions";
|
|
#address-cells = <1>;
|
|
#size-cells = <1>;
|
|
|
|
partition@0 {
|
|
label = "u-boot";
|
|
reg = <0x0 0x60000>;
|
|
read-only;
|
|
};
|
|
|
|
partition@60000 {
|
|
label = "u-boot-env";
|
|
reg = <0x60000 0x10000>;
|
|
read-only;
|
|
};
|
|
|
|
factory: partition@70000 {
|
|
compatible = "nvmem-cells";
|
|
label = "factory";
|
|
reg = <0x70000 0x40000>;
|
|
#address-cells = <1>;
|
|
#size-cells = <1>;
|
|
read-only;
|
|
|
|
eeprom_factory_0: eeprom@0 {
|
|
reg = <0x0 0x400>;
|
|
};
|
|
};
|
|
|
|
eeprom: partition@b0000 {
|
|
compatible = "nvmem-cells";
|
|
label = "eeprom";
|
|
reg = <0xb0000 0x10000>;
|
|
#address-cells = <1>;
|
|
#size-cells = <1>;
|
|
read-only;
|
|
|
|
macaddr_eeprom_0: macaddr@0 {
|
|
reg = <0x0 0x6>;
|
|
};
|
|
|
|
macaddr_eeprom_6: macaddr@6 {
|
|
reg = <0x6 0x6>;
|
|
};
|
|
};
|
|
|
|
partition@c0000 {
|
|
label = "bs";
|
|
reg = <0xc0000 0x10000>;
|
|
};
|
|
|
|
partition@d0000 {
|
|
label = "cfg";
|
|
reg = <0xd0000 0x100000>;
|
|
read-only;
|
|
};
|
|
|
|
partition@1d0000 {
|
|
compatible = "denx,fit";
|
|
label = "firmware";
|
|
reg = <0x1d0000 0xf10000>;
|
|
};
|
|
|
|
partition@10e0000 {
|
|
label = "kernel1";
|
|
reg = <0x10e0000 0xf10000>;
|
|
};
|
|
};
|
|
};
|
|
};
|
|
|
|
&gmac0 {
|
|
nvmem-cells = <&macaddr_eeprom_0>;
|
|
nvmem-cell-names = "mac-address";
|
|
};
|
|
|
|
&wlan_2g {
|
|
nvmem-cells = <&eeprom_factory_0>, <&macaddr_eeprom_0>;
|
|
nvmem-cell-names = "eeprom", "mac-address";
|
|
};
|
|
|
|
&wlan_5g {
|
|
compatible = "mediatek,mt76";
|
|
|
|
mediatek,mtd-eeprom = <&factory 0x20000>;
|
|
|
|
nvmem-cells = <&macaddr_eeprom_6>;
|
|
nvmem-cell-names = "mac-address";
|
|
|
|
/* This is a workaround.
|
|
*
|
|
* Ubiquiti uses a +2 offset in the first octet relative
|
|
* to the 2.4 GHz WMAC. Other octets are identical.
|
|
*
|
|
* The vendor firmware increases the last octet by 2 for each
|
|
* VAP.
|
|
*
|
|
* This is in conflict on how mac80211 addresses subsequent VAPs.
|
|
* mac80211 increases the first octet by two for each VAP, leading
|
|
* to conflicting MAC addresses for subsequent interfaces.
|
|
*/
|
|
mac-address-increment = <1>;
|
|
|
|
ieee80211-freq-limit = <5000000 6000000>;
|
|
|
|
mediatek,disable-radar-background;
|
|
};
|