Hardware specs:
SoC: Qualcomm IPQ8065 (dual core Cortex-A15)
RAM: 512 MB DDR3
Flash: 256 MB NAND, 32 MB NOR
WiFi: QCA9983 2.4 GHz, QCA9984 5 GHz
Switch: QCA8337
Ethernet: 5x 10/100/1000 Mbit/s
USB: 1x USB 3.0 Type-A
Buttons: WPS, Reset
Power: 12 VDC, 2.5 A
Ethernet ports:
1x WAN: connected to eth2
4x LAN: connected via the switch to eth0 and eth1
(eth0 is disabled in OEM firmware)
MAC addresses (OEM and OpenWrt):
fw_env @ 0x00 d4🆎82:??:??:?a LAN (eth1)
fw_env @ 0x06 d4🆎82:??:??:?b WAN (eth2)
fw_env @ 0x0c d4🆎82:??:??:?c WLAN 2.4 GHz (ath1)
fw_env @ 0x12 d4🆎82:??:??:?d WLAN 5 GHz (ath0)
fw_env @ 0x18 d4🆎82:??:??:?e OEM usage unknown (eth0 in OpenWrt)
OID d4🆎82 is registered to:
ARRIS Group, Inc., 6450 Sequence Drive, San Diego CA 92121, US
More info:
https://openwrt.org/inbox/toh/arris/tr4400_v2
IMPORTANT:
This port requires moving the 'fw_env' partition prior to first boot to
consolidate 70% of the usable space in flash into a contiguous partition.
'fw_env' contains factory-programmed MAC addresses, SSIDs, and passwords.
Its contents must be copied to 'rootfs_1' prior to booting via initramfs.
Note that the stock 'fw_env' partition will be wiped during sysupgrade.
A writable 'stock_fw_env' partition pointing to the old, stock location
is included in the port to help rolling back this change if desired.
Installation:
- Requires serial access and a TFTP server.
- Fully boot stock, press ENTER, type in:
mtd erase /dev/mtd21
dd if=/dev/mtd22 bs=128K count=1 | mtd write - /dev/mtd21
umount /config && ubidetach -m 23 && mtd erase /dev/mtd23
- Reboot and interrupt U-Boot by pressing a key, type in:
set mtdids 'nand0=nand0'
set mtdparts 'mtdparts=nand0:155M@0x6500000(mtd_ubi)'
set bootcmd 'ubi part mtd_ubi && ubi read 0x44000000 kernel && bootm'
env save
- Setup TFTP server serving initramfs image as 'recovery.bin', type in:
set ipaddr 192.168.1.1
set serverip 192.168.1.2
tftpboot recovery.bin && bootm
- Use sysupgrade to install squashfs image.
This port is based on work done by AmadeusGhost <amadeus@jmu.edu.cn>.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
[add 5.15 changes for 0069-arm-boot-add-dts-files.patch]
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
(cherry picked from commit f8b0010dfb)
Fix wrong CPU OPP for ipq8062. Revision of the SoC added an
extra 25mV for every pvs. Also fix the voltage min/max value
that were wrong.
Reviewed-by: Robert Marko robimarko@gmail.com
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
(cherry picked from commit 3f0d87fd69)
These workarrounds are incomplete and non-functional, and thus not needed.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
(cherry picked from commit 3a4d972d43)
Timo Schroeder reported:
"The TP-Link Archer VR2600v is stuck in a boot loop on written
snapshot image. It's able to boot using the snapshot uimage
though, but there ath10k firmware can't be found.
21.02.2 release version doesn't have either problem."
The VR2600v has a 512 byte header at the beginning of the
firmware that needs to be accounted for.
Fixes: f6a01d7f5c ("ipq806x: convert TP-Link Archer VR2600v to denx,uimage")
Reported-by: Timo Schroeder <der.timosch@gmail.com>
References: <https://github.com/openwrt/openwrt/issues/9467>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Increase the kernel size from 3 MB to 4 MB for EA8500 and EA7500v1.
* modify the common .dtsi
* modify the kernel size in the image recipes
Define compat-version 2.0 to force factory image usage for sysupgrade.
Add explanation message. Reenable both devices.
As for 4MiB (and not more): Hannu Nyman noted that:
"We have lots of ipq806x devices with 4 MB kernel, so will
need action at that point in future in any case.
(Assuming that the bootloader did not have a 4 MB limit that
has been tested...)"
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
(squashed, added 4MiB notice of support in ipq806x)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Define the kernel crash log storage ramoops/pstore feature
for R7800 and its sister XR500.
Reference to the ramoops admin guide in upstream Linux:
https://www.kernel.org/doc/html/v5.10/admin-guide/ramoops.html
Tested with R7800.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
This device still had the legacy flash partitioning.
This is a problem, because neither the nvmem-cells
for mac-address and calibration. Nor the denx,uimage
mtd-splitter compatible would be picked up.
The patch also changes the node-names of the flash
and partition nodes to hopefully meet all the
current FDT trends.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Increase the available flash memory size in Netgear R7800
by repurposing the unused "netgear" partition that is
located after the firmware partition.
Available flash space for kernel+rootfs+overlay increases
by 68 MB from 32 MB to 100 MB.
In a typical build, overlay space increases from 15 to 85,
increasing the package installation possibilities greatly.
Reverting to the OEM firmware is still possible, as the OEM
firmware contains logic to initialise the "netgear" partition
if its contents do not match expectations. In OEM firmware,
"netgear" contains 6 UBI sub-partitions that are defined in
/etc/netgear.cfg and initialisation is done by /etc/preinit
This is based on fb8a578aa7
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
The recent device-tree modification that added pre-cal
nvmem-cells pushed the device's kernel+dtb over the
allotted 3072k KERNEL_SIZE.
> WARNING: Image file tplink_vr2600v-uImage is too big: 3147214 > 3145728
There was a previous kernel partition size upgrade:
commit 0c967d92b3 ("ipq806x: increase kernel partition size for the TP-Link Archer VR2600v")
It has been seemingly upgraded from a 2048k KERNEL_SIZE in the past.
The commit talks about using the MTD_SPLIT_TPLINK_FW. But looking at
the image make recipe, there is no code that adds a TPLINK header.
So instead the board will use "denx,umimage". This requires
MTD_SPLIT_UIMAGE_FW, but this is present thanks to some NEC devices.
(Maybe the MTD_CONFIG_ARGS can be removed as well? But it could be
there because of the padding at the beginning. This needs testing.)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
brings back the ath10k QCA9980 wifi nodes to which
it adds ASROCK's wifi calibration data. These are
now provided by the ath10k_firmware.git's board-2.bin.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
converts extraction entries from 11-ath10k-caldata into
nvmem-cells in the individual board's device-tree file.
The patch also moves previously existing referenced
nvmem-cells data nodes which were placed at the end
back into the partitions node. As well as removing
some duplicated properties from qcom-ipq8065-xr500.dts's
art (the included nighthawk.dtsi defines those already).
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Commit d284e6ef0f ("treewide: convert mtd-mac-address-increment* to
generic implementation") renamed "mtd-mac-address-increment" property
to "mac-address-increment". Convert remaining usages that have been
added after that.
Fixes: f44e933458 ("ipq806x: provide WiFI mac-addresses from dts")
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
This board has 512MiB of RAM like the R7800, and the VDSL modem is
attached to the second PCIe port.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Properly declare that the g10 is booting from NAND and define its
correct (larger than on other devices-) boot_pages_size, to prevent
the kernel from constantly falling over missing OOB error correction
for the bootloader.
This patch prevents a constant slew of (bogus) read errors reported
by the kernel and keeping the CPU busy and fixes:
blk_update_request: I/O error, dev mtdblock0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
blk_update_request: I/O error, dev mtdblock0, sector 8 op 0x0:(READ) flags 0x80700 phys_seg 3 prio class 0
blk_update_request: I/O error, dev mtdblock0, sector 16 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0
blk_update_request: I/O error, dev mtdblock0, sector 24 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
blk_update_request: I/O error, dev mtdblock0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Buffer I/O error on dev mtdblock0, logical block 0, async page read
blk_update_request: I/O error, dev mtdblock0, sector 32 op 0x0:(READ) flags 0x80700 phys_seg 8 prio class 0
blk_update_request: I/O error, dev mtdblock0, sector 40 op 0x0:(READ) flags 0x80700 phys_seg 7 prio class 0
blk_update_request: I/O error, dev mtdblock0, sector 48 op 0x0:(READ) flags 0x80700 phys_seg 6 prio class 0
blk_update_request: I/O error, dev mtdblock0, sector 56 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
blk_update_request: I/O error, dev mtdblock0, sector 64 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
Buffer I/O error on dev mtdblock0, logical block 1, async page read
Buffer I/O error on dev mtdblock1, logical block 0, async page read
Buffer I/O error on dev mtdblock1, logical block 1, async page read
Buffer I/O error on dev mtdblock2, logical block 0, async page read
Buffer I/O error on dev mtdblock2, logical block 1, async page read
Buffer I/O error on dev mtdblock3, logical block 0, async page read
Buffer I/O error on dev mtdblock3, logical block 0, async page read
Buffer I/O error on dev mtdblock4, logical block 0, async page read
Buffer I/O error on dev mtdblock4, logical block 1, async page read
Suggested-by: Ansuel Smith <ansuelsmth@gmail.com>
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
The MR42 and MR52 are two similar IPQ806x based devices from the Cisco
Meraki "Cryptid" series.
MR42 main features:
- IPQ8068 1.4GHz
- 512MB RAM
- 128MB NAND
- 2x QCA9992 (2.4 & 5GHz)
- 1x QCA9889 (2.4 & 5GHz)
- 1x AR8033 PHY
- PoE/AC power
MR52 main features:
- IPQ8068 1.4GHz
- 512MB RAM
- 128MB NAND
- 2x QCA9994 (2.4 & 5GHz)
- 1x QCA9889 (2.4 & 5GHz)
- 2x AR8033 PHYs
- PoE/AC power
(MR42 Only) Installation via diagnostic mode:
If you can successfully complete step 1 then you can continue to install
via this method without having to open the device. Otherwise please use
the standard UART method. Please note that when booting via TFTP, some
Ethernet devices, in particular those on laptops, will not connect in
time, resulting in TFTP boot not succeeding. In this instance it is
advised to connect via a switch.
1. Hold down reset at power on and keep holding, after around 10 seconds
if the orange LED changes behaviour to begin flashing, proceed to
release reset, then press reset two times. Ensure that the LED has
turned blue. Note that flashing will occur on some devices, but it
will not be possible to change the LED colour using the reset button.
In this case it will still be possible to continue with this install
method.
2. Set your IP to 192.168.1.250. Set up a TFTP server serving
mr42_u-boot.mbn and
openwrt-ipq806x-generic-meraki_mr42-initramfs-fit-uImage.itb, obtained
from [1].
3. Use telnet and connect to 192.168.1.1. Run the following commands to
install u-boot. Note that all these commands are critical, an error
will likely render the device unusable.
Option 3.1:
If you are sure you have set up the TFTP server correctly you can
run this script on the device. This will download and flash the
u-boot image immediately:
`/etc/update_uboot.sh 192.168.1.250 mr42_u-boot.mbn`
Once completed successfully, power off the device.
Option 3.2:
If you are unsure the TFTP server is correctly set up you can
obtain the image and flash manually:
3.2.1. `cd /tmp`
3.2.2. `tftp-hpa 192.168.1.250 -m binary -c get mr42_u-boot.mbn`
3.2.3. Confirm file has downloaded correctly by comparing the
md5sum:
`md5sum mr42_u-boot.mbn`
3.2.4. The following are the required commands to write the image.
`echo 1 > /sys/devices/platform/msm_nand/boot_layout
mtd erase /dev/mtd1
nandwrite -pam /dev/mtd1 mr42_u-boot.mbn
echo 0 > /sys/devices/platform/msm_nand/boot_layout`
Important: You must observe the output of the `nandwrite`
command. Look for the following to verify writing is occurring:
`Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000`
If you do not see this then do not power off the device. Check
your previous commands and that mr42_u-boot.mbn was downloaded
correctly. Once you are sure the image has been written you
can proceed to power off the device.
4. Hold the reset button and power on the device. This will immediately
begin downloading the appropriate initramfs image and boot into it.
Note: If the device does not download the initramfs, this is likely
due to the interface not being brought up in time. Changing Ethernet
source to a router or switch will likely resolve this. You can also
try manually setting the link speed to 10Mb/s Half-Duplex.
5. Once a solid white LED is displayed on the device, continue to the
UART installation method, step 6.
Standard installation via UART - MR42 & MR52
1. Disassemble the device and connect a UART header. The header pinout
is as follows:
1 - 3.3v
2 - TXD
3 - RXD
4 - GND
Important: You should only connect TXD, RXD and GND. Connecting
3.3v may damage the device.
2. Set your IP to 192.168.1.250. Set up a TFTP server serving
openwrt-ipq806x-generic-meraki_(mr42|mr52)-initramfs-fit-uImage.itb.
Separately obtain the respective sysupgrade image.
3. Run the following commands, preferably from a Linux host. The
mentioned files, including ubootwrite.py and u-boot images, can be
obtained from [1].
`python ubootwrite.py --write=(mr42|mr52)_u-boot.bin`
The default for "--serial" option is /dev/ttyUSB0.
4. Power on the device. The ubootwrite script will upload the image to
the device and launch it. The second stage u-boot will in turn load
the initramfs image by TFTP, provided the TFTP server is running
correctly. This process will take about 13 minutes. Once a solid
white LED is displayed, the image has successfully finished
loading. Note: If the image does not load via TFTP, try again with
the Ethernet link to 10Mb/s Half-Duplex.
5. (MR42 only) Do not connect over the network. Instead connect over
the UART using minicom or similar tool. To replace u-boot with
the network enabled version, please run the following commands.
Note that in the provided initramfs images, the u-boot.mbn file
is located in /root:
If you have not used the provided initramfs, you must ensure you
are using an image with "boot_layout" ECC configuration enabled in
the Kernel. This will be version 5.10 or higher. If you do not do
this correctly the device will be bricked.
`insmod mtd-rw i_want_a_brick=1
mtd erase /dev/mtd8
nandwrite -pam /dev/mtd8 /root/mr42_u-boot.mbn`
After running nandwrite, ensure you observe the following output:
`Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000`
6. (Optional) If you have no further use for the Meraki OS, you can
remove all other UBI volumes on ubi0 (mtd11), including diagnostic1,
part.old, storage and part.safe. You must not remove the ubi1 ART
partition (mtd12).
`for i in diagnostic1 part.old storage part.safe ; do
ubirmvol /dev/ubi0 -N $i
done`
7. Proceed to flash the sysupgrade image via luci, or else download or
scp the image to /tmp and use the sysupgrade command.
[1] The mentioned images and ubootwrite.py script can be found in this repo:
https://github.com/clayface/openwrt-cryptid
[2] The modified u-boot sources for the MR42 and MR52 are available:
https://github.com/clayface/U-boot-MR52-20200629
Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
Currently, we are overriding the bootloader provided MAC-s as the ethernet
aliases are reversed so MAC-s were fixed up in userspace.
There is no need to do that as we can just fix the aliases instead and get
rid of MAC setting via userspace helper.
Fixes: 59f0a0f ("ipq806x: add Edgecore ECW5410 support")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
It looks like this is a leftover before there was a proper MDIO driver.
Since both PHY-s are connected to the HW MDIO bus there is no reason for
this to exist anymore, especially since it uses the same pins as the HW
controller and has the pinmux for the set to "MDIO" so this worked by
pure luck as GPIO MDIO would probe first and override the HW driver.
Move the GMAC3 to simply use the same MDIO bus phandle.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Use nvmem framework for supported mac-address stored
in nvmem cells and drop mac patch function for hotplug
script for supported devices.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
[rebase, move to correct node for d7800, include xr500]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This adds support for the Netgear Nighthawk Pro Gaming XR500.
It is the successor to the Netgear Nighthawk R7800 and shares almost
identical hardware to that device.
The stock firmware is a heavily modified version of OpenWRT.
Specifications:
SoC: Qualcomm Atheros IPQ8065
RAM: 512 MB
Storage: 256 MiB NAND Flash
Wireless: 2x Qualcomm Atheros QCA9984
Ethernet: 2x 1000/100/10 dedicated interfaces
Switch: 5x 1000/100/10 external ports
USB: 2x 3.0 ports
More information:
Manufacturer page: https://www.netgear.com/gaming/xr500/
Almost identical to Netgear R7800
Differences (r7800 > xr500):
Flash: 128MiB > 256MiB
Removed esata
swapped leds:
usb1 (gpio 7 > 8)
usb2 (gpio 8 > 26)
guest/esata (gpio 26 > 7)
MAC addresses:
On the OEM firmware, the mac addresses are:
WAN: *:50 art 0x6
LAN: *:4f art 0x0 (label)
2G: *:4f art 0x0
5G: *:51 art 0xc
Installation:
Install via Web Interface (preferred):
Utilize openwrt-ipq806x-netgear_xr500-squashfs-factory.img
Install via TFTP recovery:
1.Turn off the power, push and hold the reset button (in a hole on
backside) with a pin
2.Turn on the power and wait till power led starts flashing white
(after it first flashes orange for a while)
3.Release the reset button and tftp the factory img in binary mode.
The power led will stop flashing if you succeeded in transferring
the image, and the router reboots rather quickly with the new
firmware.
4.Try to ping the router (ping 192.168.1.1). If does not respond,
then tftp will not work either.
Uploading the firmware image with a TFTP client
$ tftp 192.168.1.1
bin
put openwrt-ipq806x-netgear_xr500-squashfs-factory.img
Note:
The end of the last partition is at 0xee00000. This was chosen
by the initial author, but nobody was able to tell why this
particular arbitrary size was chosen. Since it's not leaving
too much empty space and it's the only issue left, let's just
keep it for now.
Based on work by Adam Hnat <adamhnat@gmail.com>
ref: https://github.com/openwrt/openwrt/pull/3215
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
[squash commits, move common LEDs to DTSI, remove SPDX on old
files, minor whitespace cleanup, commit message facelift,
add MAC address overview, add Notes, fix MAC addresses,
use generic name for partition nodes in DTS]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The partitions that have compatible property set are skipped by mtd if
they are not contained inside a partitions node and this breaks
fetching MAC address from "default-mac" partition.
Fix this by defining all the partitions inside partitions node with
compatible = "fixed-partitions" as nvmem requires the standard
partitions scheme to work correctly.
Fixes: FS#3945
Fixes: cd36d71655 ("ipq806x/dts: Add Archer C2600 DTS")
Fixes: 0458a8993c ("ipq806x: convert mtd-mac-address to nvmem
implementation")
Signed-off-by: Filip Matijević <filip.matijevic.pz@gmail.com>
Reviewed-by: Ansuel Smith <ansuelsmth@gmail.com>
[adjust commit title/message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The problem has been fixed in f47cb405ca ("ipq806x: fix pci broken
on bootm command"), now the pcie part can be written in the usual way.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Ansuel Smith <ansuelsmth@gmail.com>
Rearrange all voltage triplets for "opp_table0" to match the
specifications. "opp-microvolt" and "opp-microvolt-<name>" triplets
are in order of <target min max>, and NOT <min target max>.
Previously, the CPU would *always* spend its time at the "minimum"
voltage, ignoring the actual intended target. This is a regression
from previous behavior.
On an NBG6817 with a Qualcomm CPU of PVS bin #2...
(see &opp_table0 -> opp-1725000000 -> opp-microvolt-speed0-pvs2-v0)
* Before:
/usr/bin/tail -n +1 /sys/kernel/debug/opp/cpu0/opp\:1725000000/supply-0/u_volt_*
==> /sys/kernel/debug/opp/cpu0/opp:1725000000/supply-0/u_volt_max <==
1260000
==> /sys/kernel/debug/opp/cpu0/opp:1725000000/supply-0/u_volt_min <==
1200000
==> /sys/kernel/debug/opp/cpu0/opp:1725000000/supply-0/u_volt_target <==
1140000
* After:
/usr/bin/tail -n +1 /sys/kernel/debug/opp/cpu0/opp\:1725000000/supply-0/u_volt_*
==> /sys/kernel/debug/opp/cpu0/opp:1725000000/supply-0/u_volt_max <==
1260000
==> /sys/kernel/debug/opp/cpu0/opp:1725000000/supply-0/u_volt_min <==
1140000
==> /sys/kernel/debug/opp/cpu0/opp:1725000000/supply-0/u_volt_target <==
1200000
To check voltages and frequencies at run time, use...
/bin/cat /sys/kernel/debug/regulator/regulator_summary &&
/bin/cat /sys/kernel/debug/clk/clk_summary | grep "hfpll"
See
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/devicetree/bindings/opp/opp.txt?h=v5.4.142#n91
Fixes: 1e25423be8 ("ipq806x: refresh dtsi patches")
Signed-off-by: Shane Synan <digitalcircuit36939@gmail.com>
Reviewed-by: Ansuel Smith <ansuelsmth@gmail.com>
[commit message style cleanup, another kernel refresh]
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>
Rework patch 681-NET-add-mtd-mac-address-support to implement
only the function to read the mac-address from mtd.
Generalize mtd-mac-address-increment function so it can be applied
to any source of of_get_mac_address.
Rename any mtd-mac-address-increment to mac-address-increment.
Rename any mtd-mac-address-increment-byte to mac-address-increment-byte.
This should make simplify the conversion of target to nvmem implementation.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
With the new implementation of the dedicated cpufreq driver,
the 1.4 Ghz was only dropped and not added to the ipq8065 SoC.
Fix this to improve performance.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
This adds support for the Askey RT4230W REV6
(Branded by Spectrum/Charter as RAC2V1K)
At this time, there's no way to reinstall the stock firmware so don't install
this on a router that's being rented.
Specifications:
Qualcomm IPQ8065
1 GB of RAM (DDR3)
512 MB Flash (NAND)
2x Wave 2 WiFi cards (QCA9984)
5x 10/100/1000 Mbps Ethernet (Switch: QCA8337)
1x LED (Controlled by a microcontroller that switches it between red and
blue with different patterns)
1x USB 3.0 Type-A
12V DC Power Input
UART header on PCB - pinout from top to bottom is RX, TX, GND, 5V
Port settings are 115200n8
More information: https://forum.openwrt.org/t/askey-rac2v1k-support/15830https://deviwiki.com/wiki/Askey_RAC2V1K
To check what revision your router is, restore one of these config backups
through the stock firmware to get ssh access then run
"cat /proc/device-tree/model".
https://forum.openwrt.org/t/askey-rac2v1k-support/15830/17
The revision number on the board doesn't seem to be very consistent so that's
why this is needed. You can also run printenv in the uboot console and if
machid is set to 177d, that means your router is rev6.
Note: Don't install this if the router is being rented from an ISP. The defined
partition layout is different from the OEM one and even if you changed the
layout to match, backing up and restoring the OEM firmware breaks /overlay so
nothing will save and the router will likely enter a bootloop.
How to install:
Method 1: Install without opening the case using SSH and tftp
You'll need:
RAC2V1K-SSH.zip:
https://github.com/lmore377/openwrt-rt4230w/blob/master/RAC2V1K-SSH.zip
initramfs and sysupgrade images
Connect to one of the router's LAN ports
Download the RAC2V1K-SSH.zip file and restore the config file that
corresponds to your router's firmware (If you're firmware is newer than what's
in the zip file, just restore the 1.1.16 file)
After a reboot, you should be able to ssh into the router with username:
"4230w" and password: "linuxbox" or "admin". Run the following commannds
fw_setenv ipaddr 10.42.0.10 #IP of router, can be anything as long as
it's in the same subnet as the server
fw_setenv serverip 10.42.0.1# #IP of tftp server that's set up in next
steps
fw_setenv bootdelay 8
fw_setenv bootcmd "tftpboot initramfs.bin; bootm; bootipq"
Don't reboot the router yet.
Install and set up a tftp server on your computer
Set a static ip on the ethernet interface of your computer (use this for
serverip in the above commands)
Rename the initramfs image to initramfs.bin, and host it with the tftp
server
Reboot the router. If you set up everything right, the router led should
switch over to a slow blue glow which means openwrt is booted. If for some
reason the file doesn't get loaded into ram properly, it should still boot to
the OEM firmware.
After openwrt boots, ssh into it and run these commands:
fw_setenv bootcmd "setenv mtdids nand0=nand0 && setenv mtdparts
mtdparts=nand0:0x1A000000@0x2400000(firmware) && ubi part firmware && ubi
read 0x44000000 kernel 0x6e0000 && bootm"
fw_setenv bootdelay 2
After openwrt boots up, figure out a way to get the sysupgrade file onto it
(scp, custom build with usb kernel module included, wget, etc.) then flash it
with sysupgrade. After it finishes flashing, it should reboot, the light should
start flashing blue, then when the light starts "breathing" blue that means
openwrt is booted.
Method 2: Install with serial access (Do this if something fails and you can't
boot after using method 1)
You'll need:
initramfs and sysupgrade images
Serial access:
https://openwrt.org/inbox/toh/askey/askey_rt4230w_rev6#opening_the_case
Install and set up a tftp server
Set a static ip on the ethernet interface of your computer
Download the initramfs image, rename it to initramfs.bin, and host it with
the tftp server
Connect the wan port of the router to your computer
Interrupt U-Boot and run these commands:
setenv serverip 10.42.0.1 (You can use whatever ip you set for the computer)
setenv ipaddr 10.42.0.10 (Can be any ip as long as it's in the same subnet)
setenv bootcmd "setenv mtdids nand0=nand0 &&
set mtdparts mtdparts=nand0:0x1A000000@0x2400000(firmware) && ubi part firmware
&& ubi read 0x44000000 kernel 0x6e0000 && bootm"
saveenv
tftpboot initramfs.bin
bootm
After openwrt boots up, figure out a way to get the sysupgrade file onto it
(scp, custom build with usb kernel module included, wget, etc.) then flash it
with sysupgrade. After it finishes flashing, it should reboot, the light should
start flashing blue, then when the light starts "breathing" blue that means
openwrt is booted.
Signed-off-by: Lauro Moreno <lmore377@gmail.com>
[add entry in 5.10 patch, fix whitespace issues]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
wakeup-source is required for gpio keys to fix error
genirq: irq_chip msmgpio did not update eff. affinity mask
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
- Add new tsens node
- Add new cpufreq required nodes
- Drop arm cpuidle compatible
- Fix duplicate node set upstream
- Add voltage tolerance value for cpu opp
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
The Ubiquiti UniFi AC HD (UAP-AC-HD, UAP301) has two Ethernet ports,
labeled MAIN and SECONDARY, connected to gmac2 and gmac1, respectively.
The standard probe order results in gmac1/SECONDARY being eth0 and
gmac2/MAIN being eth1. This does not match the stock firmware, is
contrary to user expectation, causes the wrong (high) MAC address to be
used in a bridged configuration (the default for this device), and makes
the gmac2/MAIN port unusable in the preinit environment (such as for
failsafe). Until a recent patch, gmac1/SECONDARY (eth0) was not even
usable.
This reorders the ports so that gmac2/MAIN is eth0, and the now-working
gmac1/SECONDARY is eth1. eth0 has the low MAC address and eth1 has the
high; when bridged, the bridge takes on the correct low MAC address.
This matches the stock firmware. The MAIN port is usable for failsafe
during preinit.
This device does not have a switch on board, so there's no possibility
to remap ports via switch configuration. "ip link set $interface name"
is used instead, during preinit before networking is configured.
Signed-off-by: Mark Mentovai <mark@moxienet.com>
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
Unlike many ipq806x devices, Ubiquiti UniFi AC HD (UAP-AC-HD, UAP301)
has no switch on board. Its two Ethernet ports are connected to Atheros
AR8033 PHYs. It is not appropriate to use fixed-link in this
configuration. Instead, configure the correct PHYs in the device tree
configuration to allow the at803x driver to load.
Signed-off-by: Mark Mentovai <mark@moxienet.com>
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
ZyXEL NBG6817 comes with an eMMC which contains a GPT partition named
'rootfs_data'. This currently confuses fstools and makes it pick that
(not suitable) partition.
Use the newly introduced fstools_ignore_partname=1 kernel cmdline
parameter to have fstools ignore that partition.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This replaces a full-text BSD clause by the corresponding SPDX
identifier.
This should make it easier to identify the license both by humans
and machines.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This fixes a typo in the previously committed partition map that led to
the extension of the read-only mtd partition "SSD" into the following
partitions.
Fixes: 4e46beb313 ("ipq806x: add support for Ubiquiti UniFi AC HD")
Signed-off-by: Jan Alexander <jan@nalx.net>
Hardware
--------
SoC: Qualcomm IPQ8064
RAM: 512MB DDR3
Flash: 256MB NAND (Micron MT29F2G08ABBEAH4)
32MB SPI-NOR (Macronix MX25U25635F)
WLAN: Qualcomm Atheros QCA9994 4T4R b/g/n
Qualcomm Atheros QCA9994 4T4R a/n/ac
ETH: eth0 - SECONDARY (Atheros AR8033)
eth1 - MAIN (Atheros AR8033)
USB: USB-C
LED: Dome (white / blue)
BTN: Reset
Installation
------------
Copy the OpenWrt sysupgrade image to the /tmp directory of the device
using scp. Default IP address is 192.168.1.20 and default username and
password are "ubnt".
SSH to the device and write the bootselect flag to ensure it is booting
from the mtd partition the OpenWrt image will be written to. Verify the
output device below matches mtd partition "bootselect" using /proc/mtd.
> dd if=/dev/zero bs=1 count=1 seek=7 conv=notrunc of=/dev/mtd11
Write the OpenWrt sysupgrade image to the mtd partition labeled
"kernel0". Also verify the used partition device using /proc/mtd.
> dd if=/tmp/sysupgrade.bin of=/dev/mtdblock12
Reboot the device.
Back to stock
-------------
Use the TFTP recovery procedure with the Ubiquiti firmware image to
restore the vendor firmware.
Signed-off-by: Jan Alexander <jan@nalx.net>
Strictly, an SPDX identifier requires a space between the comment
marker and the identifier itself. This has been addressed in
b69c21738e ("treewide: add space before SPDX identifier"), but
some new malformatted identifiers were merged recently.
This could have been prevented by using checkpatch.pl earlier.
Fixes: 1a775a4fd0 ("ipq806x: add support for TP-Link Talon AD7200")
Fixes: 8ddaeaf642 ("ipq806x: create DTSI for TP-Link AD7200 and C2600")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Both devices share most of their setup except buttons and LEDs,
so having a common DTSI removes a lot of duplicate code.
In order to have a shared partitioning scheme, device-id and
product-info from AD7200 have been merged into a single
product-info partition like for C2600.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This does several cosmetic adjustments for AD7200's DTS:
- Make node name, DT label and label property consistent
- Drop wrong and unused spi4 label
- Use generic flash@0 node name
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Address most comments made by Adrian Schmutzler on the mailing list.
The device name is kept as 'TP-Link Talon AD7200' as that seems to be
the marketing name TP-Link chose for that device, it also matches the
naming scheme for other TP-Link devices (e.g. 'TP-Link Archer C7').
Fixes: 1a775a4fd0 ("ipq806x: add support for TP-Link Talon AD7200")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Device hardware: https://deviwiki.com/wiki/TP-LINK_AD7200_(Talon)
The Talon AD7200 is basically an Archer C2600 with a third PCIe lane
and an 802.11ad radio. It looks like the Archers C2600/5400 but the
housing is slightly larger.
Specifications
--------------
- IPQ8064 dual-core 1400MHz
- QCA9988 2.4GHz WiFi
- QCA9990 5GHz WiFi
- QCA9500 60GHz WiFi
- 32MB SPI Flash
- 512MiB RAM
- 5 GBit Ports (QCA8337)
Installation
------------
Installation is possible from the OEM web interface.
Sysupgrade is possible.
TFTP recovery is possible.
- Image: AD7200_1.0_tp_recovery.bin
Notes
- This will be the first 802.11ad device supported by mainline.
Signed-off-by: Gary Cooper <gaco@bitmessage.de>
Commit 29ca10e537 ("ipq806x: remove support for kernel 4.19") moved
DTS files to "files" directory, but after that a new DTS file was added
to the former "files-5.4" directory. Move it to the new directory.
Fixes: 98b86296e6 ("ipq806x: add support for ASRock G10")
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
This commit adds support for Qualcomm IPQ8062 SoC.
IPQ8062 is a lower clock variant of IPQ8064.
CPU and NSS clocks:
- CPU: 384 MHz - 1 GHz
- NSS: 110 MHz - 550 MHz
opp and l2 clock values are taken from WG2600HP3 GPL source code [1].
Due to a lack of devices, I didn't test the following features.
- SATA
- NAND flash memory controller
- SD
- USB
- GSBI2, GSBI7
- PCIE2
- GMAC0, GMAC3
Works properly:
- GSBI4 UART
- GSBI5 SPI
- GMAC1, GMAC2
- PCIE0, PCIE1
- MDIO0
Does not work properly:
- CPU SPC
- This can cause a system hang. Same as IPQ8065.
See 2336c2dbb1
[1] https://www.aterm.jp/function/wg2600hp3/appendix/opensource.html
Signed-off-by: Yanase Yuki <dev@zpc.sakura.ne.jp>
The WAN port on Netgear D7800 is unable to connect to an ISP when the
link to the modem is running at less than 1GB.
This patch fixes the issue by removing the phy-handle definition
and replacing it with a fixed-link definition
The WAN port is then able to connect to a modem via a link running at 100Mbs or 10Mbs
Fixes: FS#3086
Signed-off-by: Peter Cardoe <peter@cardoe.co.uk>
The target uses 5.4 as default kernel since 04/2020.
Kernel 4.19 support is not really maintained anymore, and there has
been a lot of changes between 4.19 and 5.4 on this target. Despite,
new devices are typically added for 5.4 only anyway.
Thus, make maintaining of old stuff and reviewing of new stuff
easier by removing support for kernel 4.19.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
