Some MT7915 calibration data consists of two parts. The first part
"eeprom" size is 0xe00. The second part "precal" size is 0x19c10.
Though some devices may not have precal data, it's better to assume
that precal data exists as no users/developers confirm it. On the
other hand, some devices definitely do not contain precal data
because the EEPROM partition size is smaller than the precal NVMEM
cell size.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
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>
The UniFi 6 Lite as well as the Tenbay T-MB5EU do not have the third
background-radar chain. For the Tenbay, the connector is present,
however no antenna is connected to it.
Signed-off-by: David Bauer <mail@david-bauer.net>
The UniFi 6 Lite has two MAC addresses for the 2.4 and 5GHz radio in
it's EEPROM partition.
On my unit these are
F4 92 BF A0 BB 6F
F6 92 BF A0 BB 6F
The problem with these is that mac80211 increases the first octet by
2, which leads to conflicting MAC addresses between radios.
Work around this problem for now by increasing the last octet by 1 on
the 5 GHz radio.
Ubiquiti increases the last octet by 2 for each subsequent VAP created
per radio. Ideally we should do the same, however this functionality is
currently lacking from mac80211.
Signed-off-by: David Bauer <mail@david-bauer.net>
Convert most of the cases from mtd-mac-address to nvmem where
MAC addresses are set in the DTSI, but the partitions are only
located in the device DTS. This posed some problems earlier, since
in these cases we are using partitions before they are defined,
and the nvmem system did not seem to like that.
There have been a few different resolution approaches, based on
the different tradeoffs of deduplication vs. maintainability:
1. In many cases, the partition tables were identical except for
the firmware partition size, and the firmware partition was
the last in the table.
In these cases, the partition table has been moved to the
DTSI, and only the firmware partition's "reg" property has
been kept in the DTS files. So, the updated nvmem definition
could stay in the DTSI files as well.
2. For all other cases, splitting up the partition table would
have introduced additional complexity. Thus, the nodes to be
converted to nvmem have been moved to the DTS files where the
partitioning was defined.
3. For Netgear EX2700 and WN3000RP v3, the remaining DTSI file
was completely dissolved, as it was quite small and the name
was not really nice either.
4. The D-Link DIR-853 A3 was converted to nvmem as well, though
it is just a plain DTS file not taken care of in the first
wave.
In addition, some minor rearrangements have been made for tidyness.
Not covered (yet) by this patch are:
* Various unielec devices
* The D-Link DIR-8xx family
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Define nvmem-cells and convert mtd-mac-address to nvmem implementation.
The conversion is done with an automated script.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
The kernel bump to 5.4 has removed the mx25l25635f hack, and the
mx25l25635f compatible is no longer required.
Signed-off-by: DENG Qingfang <dqfext@gmail.com>
The MT7915 radio currently advertises 2.4GHz channels while the antenna
path only supports 5 GHz. Limit the radio to 5GHz channels to prevent
users from configuring non-supported channels.
Signed-off-by: David Bauer <mail@david-bauer.net>
Hardware
--------
MediaTek MT7621AT
256M DDR3
32M SPI-NOR
MediaTek MT7603 2T2R 802.11n 2.4GHz
MediaTek MT7915 2T2R 802.11ax 5GHz
Not Working
-----------
- Bluetooth (connected to UART3)
UART
----
UART is located in the lower left corner of the board. Pinout is
0 - 3V3 (don't connect)
1 - RX
2 - TX
3 - GND
Console is 115200 8N1.
Boot
----
1. Connect to the serial console and connect power.
2. Double-press ESC when prompted
3. Set the fdt address
$ fdt addr $(fdtcontroladdr)
4. Remove the signature node from the control FDT
$ fdt rm /signature
5. Transfer and boot the OpenWrt initramfs image to the device.
Make sure to name the file C0A80114.img and have it reachable at
192.168.1.1/24
$ tftpboot; bootm
Installation
------------
1. Connect to the booted device at 192.168.1.20 using username/password
"ubnt".
2. Update the bootloader environment.
$ fw_setenv devmode TRUE
$ fw_setenv boot_openwrt "fdt addr \$(fdtcontroladdr);
fdt rm /signature; bootubnt"
$ fw_setenv bootcmd "run boot_openwrt"
3. Transfer the OpenWrt sysupgrade image to the device using SCP.
4. Check the mtd partition number for bs / kernel0 / kernel1
$ cat /proc/mtd
5. Set the bootselect flag to boot from kernel0
$ dd if=/dev/zero bs=1 count=1 of=/dev/mtdblock4
6. Write the OpenWrt sysupgrade image to both kernel0 as well as kernel1
$ dd if=openwrt.bin of=/dev/mtdblock6
$ dd if=openwrt.bin of=/dev/mtdblock7
7. Reboot the device. It should boot into OpenWrt.
Below are the original installation instructions prior to the discovery
of "devmode=TRUE". They are not required for installation and are
documentation only.
The bootloader employs signature verification on the FIT image
configurations. This way, booting unauthorized image without patching
the bootloader is not possible. Manually configuring the bootcmd in the
U-Boot envronment won't work, as this is restored to the default value
if modified.
The bootloader is made up of three different parts.
1. The SPL performing early board initialization and providing a XModem
recovery in case the PBL is missing
2. The PBL being the primary U-Boot application and containing the
control FDT. It is LZMA packed with a uImage header.
3. A Ubiquiti standalone U-Boot application providing the main boot
routine as well as their recovery mechanism.
In a perfect world, we would only replace the PBL, as the SPL does not
perform checks on the PBLs integrity. However, as the PBL is in the same
eraseblock as the SPL, we need to at least rewrite both.
The bootloader will only verify integrity in case it has a "signature"
node in it's control device-tree. Renaming the signature node to
something else will prevent this from happening.
Warning: These instructions are based on the firmware intially
shipped with the device and potentially brick your device in a way it
can only be recovered using a SPI flasher.
Only (!) proceed if you understand this!
1. Extract the bootloader from the U-Boot partition using the OpenWrt
initramfs image.
2. Split the bootloader into it's 3 components:
$ dd if=bootloader.bin of=spl.bin bs=1 skip=0 count=45056
$ dd if=bootloader.bin of=pbl.uimage bs=1 skip=45056 count=143360
$ dd if=bootloader.bin of=ubnt.uimage bs=1 skip=188416
3. Strip the uImage header from the PBL
$ dd if=pbl.uimage of=pbl.lzma bs=64 skip=1
4. Decompress the PBL
$ lzma -d pbl.lzma --single-stream
The decompressed PBL sha256sum should be
d8b406c65240d260cf15be5f97f40c1d6d1b6e61ec3abed37bb841c90fcc1235
5. Open the decompressed PBL using your favorite hexeditor. Locate the
control FDT at offset 0x4CED0 (0xD00DFEED). At offset 0x4D5BC, the
label for the signature node is located. Rename the "signature"
string at this offset to "signaturr".
The patched PBL sha256sum should be
d028e374cdb40ba44b6e3cef2e4e8a8c16a3b85eb15d9544d24fdd10eed64c97
6. Compress the patched PBL
$ lzma -z pbl --lzma1=dict=67108864
The resulting pbl.lzma file should have the sha256sum
7ae6118928fa0d0b3fe4ff81abd80ecfd9ba2944cb0f0a462b6ae65913088b42
7. Create the PBL uimage
$ SOURCE_DATE_EPOCH=1607909492 mkimage -A mips -O u-boot -C lzma
-n "U-Boot 2018.03 [UniFi,v1.1.40.71]" -a 84000000 -e 84000000
-T firmware -d pbl.lzma patched_pbl.uimage
The resulting patched_pbl.uimage should have the sha256sum
b90d7fa2dcc6814180d3943530d8d6b0d6a03636113c94e99af34f196d3cf2ce
8. Reassemble the complete bootloader
$ dd if=patched_pbl.uimage of=aligned_pbl.uimage bs=143360 count=1
conv=sync
$ cat spl.bin > patched_uboot.bin
$ cat aligned_pbl.uimage >> patched_uboot.bin
$ cat ubnt.uimage >> patched_uboot.bin
The resulting patched_uboot.bin should have the sha256sum
3e1186f33b88a525687285c2a8b22e8786787b31d4648b8eee66c672222aa76b
9. Transfer your patched bootloader to the device. Also install the
kmod-mtd-rw package using opkg and load it.
$ insmod mtd-rw.ko i_want_a_brick=1
Write the patched bootloader to mtd0
$ mtd write patched_uboot.bin u-boot
10. Erase the kernel1 partition, as the bootloader might otherwise
decide to boot from there.
$ mtd erase kernel1
11. Transfer the OpenWrt sysupgrade image to the device and install
using sysupgrade.
FIT configurations
------------------
In the future, the MT7621 UniFi6 family can be supported by a single
OpenWrt image.
config@1: U6 Lite
config@2: U6 IW
config@3: U6 Mesh
config@4: U6 Extender
config@5: U6 LR-EA (Early Access - GA is MT7622)
Signed-off-by: David Bauer <mail@david-bauer.net>
