A patch was added in kernel 5.4 to support the fiber operation of
AR8033 with ramips devices. In kernel 5.18 similar enhancements
were added to the kernel. Those patches are required for other
fiber based devices but when added, build fails for ramips targets.
This commit removes the ramips patch and adds the kernel 5.18 ones.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
[ split commit,refresh patch and improve commit message ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
A patch was added in kernel 5.4 to support the fiber operation of
AR8033 with ramips devices. In kernel 5.18 similar enhancements
were added to the kernel. Those patches are required for other
fiber based devices but when added, build fails for ramips targets.
This commit removes the ramips patch and adds the kernel 5.18 ones.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
[ split commit, refresh patch and improve commit title ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Replace pending 730-net-phy-at803x-fix-feature-detection.patch with
upstream version and move it to backport.
Refresh other related patch while moving it.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The patch needs to be refreshed to apply cleanly.
Fixes: 998b973157 ("kernel: net: phy: realtek: improve RealTek 2.5G PHY driver")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Hardware specification:
SoC: MediaTek MT7986A 4x A53
Flash: ESMT F50L1G41LB 128MB
RAM: ESMT M15T4G16256A 512MB
Ethernet (Max Speed):
XDR4288: 1x 2.5G Wan, 1x 2.5G Lan, 4x 1G Lan
XDR6086: 1x 2.5G Wan, 1x 2.5G Lan, 1x 1G Lan
XDR6088: 1x 2.5G Wan, 1x 2.5G Lan, 4x 1G Lan
WiFi:
XDR4288: MT7976DAN (2.4G 2T2R, 5G 3T3R)
XDR6086/XDR6088:
WiFi1: MT7976GN 2.4GHz 4T4R
WiFi2: MT7976AN 5GHz 4T4R
Button: Reset, WPS, Turbo
USB: 1 x USB 3.0
Power: DC 12V 4A
Flash instructions:
1. Execute the following operation to open nc shell:
https://openwrt.org/inbox/toh/tp-link/xdr-6086#rooting
2. Replace the stock bootloader to OpenWrt's:
dd bs=131072 conv=sync of=/dev/mtdblock9 if=/tmp/xxx-preloader.bin
dd bs=131072 conv=sync of=/dev/mtdblock9 seek=28 if=/tmp/xxx-bl31-uboot.fip
3. Connect to your PC via the Gigabit port of the router,
set a static ip on the ethernet interface of your PC.
(ip 192.168.1.254, gateway 192.168.1.1)
4. Download the initramfs image, and restart the router,
waiting for tftp recovery to complete.
5. After openwrt boots up, perform sysupgrade.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
[Add uboot build, fit and sysupgrade support, fix RealTek PHYs]
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* use interface mode switching only when operating in C45 mode
Linux prevents switching the interface mode when using C22 MDIO,
hence use rate-adapter mode in case the PHY controlled via C22.
* use phy_read_paged where appropriate
* use existing generic inline functions to handle 10GbE advertisements
instead of redundantly defining register macros in realtek.c which
are not actually vendor-specific.
* make sure 10GbE advertisement is valid, preventing false-positive
warning "Downshift occurred from negotiated speed 2.5Gbps to actual
speed 1Gbps, check cabling!" with some link-partners using 1G mode.
* Support Link Down Power Saving Mode (ALDPS)
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Instead of use mac-address-ascii in nvmem_get_mac_address
function, move it into of_get_mac_addr_nvmem function to
support more devices.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
The Config partition of some machines is special, and the openwrt script
cannot read the protest_lan_mac correctly. This problem can be solved by
reading the mac address (ascii) in dts.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Fix the network configuration according to the device tree.
Fixes: 5faff99 ("mediatek: filogic: fix mt7986a ethernet devicetree entries")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
According to SinoVoip up to 3A @ 3.3V are available for both
SFP modules together. Raise energy limit from 1W (default) to 3W,
however, be aware that using modules consuming more than 1W will
require active cooling!
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Instead of erasing the entire NAND partition holding the kernel during
every system upgrade and then flashing a Yaffs file system image
prepared using kernel2minor (not accounting for bad blocks in the
process), use the Yafut utility to replace the kernel executable on
MikroTik NAND devices, preserving the existing Yaffs file system
(including bad block information) on the partition holding the kernel.
Add Yafut to DEFAULT_PACKAGES for the ath79/mikrotik target, so that the
tool is included in the initramfs images created when building for
multiple profiles. However, exclude Yafut from the images built for
MikroTik devices with NOR flash as the tool is currently only meant to
be used on devices with NAND flash.
As this addresses the concerns for MikroTik NAND devices discussed in
commit 9d96b6fb72 ("ath79/mikrotik: disable building NAND images"),
re-enable building images for these devices.
Signed-off-by: Michał Kępień <openwrt@kempniu.pl>
MEMREAD is a new ioctl for MTD character devices that was first included
in Linux 6.1. It allows userspace applications to use the Linux
kernel's OOB autoplacement mechanism while reading data from NAND
devices. The Yafut tool needs this ioctl to do its job.
Signed-off-by: Michał Kępień <openwrt@kempniu.pl>
The ramdisk used by sysupgrade on MikroTik devices currently includes
U-Boot fw_* files that are not necessary for performing a system upgrade
on that platform. The relevant lines were added to
target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh by commit
a66eee6336 ("ath79: add mikrotik subtarget"), likely because they also
existed in target/linux/ath79/nand/base-files/lib/upgrade/platform.sh,
where the platform_do_upgrade_mikrotik_nand() function moved by commit
a66eee6336 originally lived. However, these lines were added to
target/linux/ath79/nand/base-files/lib/upgrade/platform.sh by commit
55e6c903ae ("ath79: GL-AR300M: provide NAND support; increase to 4 MB
kernel"), which is not related to MikroTik devices in any way.
Remove the code adding unused U-Boot fw_* files to the ramdisk used by
sysupgrade on MikroTik devices.
Signed-off-by: Michał Kępień <openwrt@kempniu.pl>
Alter the Aruba AP-105 image generation process so OpenWrt can be loaded
with the vendor Aruba APBoot.
This works by prepending the OpenWrt LZMA loader to the uImage and
jumping directly to the loader. Aruba does not offer bootm on these
boards.
This approach keeps compatibility to devices which had their U-Boot
replaced. Both bootloaders can boot the same image.
The same modification is most likely also possible for the Aruba AP-175.
With this patch, new installations do not require replacing the
bootloader and can be performed from the serial console without opening
the case.
Installation
------------
1. Attach to the serial console of the AP-105.
Interrupt autoboot and change the U-Boot env.
$ setenv apb_rb_openwrt "setenv ipaddr 192.168.1.1;
setenv serverip 192.168.1.66;
netget 0x84000000 ap105.bin; go 0x84000040"
$ setenv apb_fb_openwrt "cp.b 0xbf040000 0x84000000 0x10000;
go 0x84000040"
$ setenv bootcmd "run apb_fb_openwrt"
$ saveenv
2. Load the OpenWrt initramfs image on the device using TFTP.
Place the initramfs image as "ap105.bin" in the TFTP server
root directory, connect it to the AP and make the server reachable
at 192.168.1.66/24.
$ run apb_rb_openwrt
3. Once OpenWrt booted, transfer the sysupgrade image to the device
using scp and use sysupgrade to install the firmware.
Signed-off-by: David Bauer <mail@david-bauer.net>
In addition to standardizing LED names to match the rest of the systems, this
commit fixes a possibly erroneous pinout for LEDs in Comfast CF-E314N v2.
In particular, rssimediumhigh and rssihigh are moved from pins 13 and 14 to
14 and 16 respectively. In addition to working on a test device, this pinout
better matches the one set out in the prototype support patch for the device
in Github PR #1873.
Signed-off-by: Mark Onstid <turretkeeper@mail.com>
RA75 has 5 physical LEDs under 2 indicators, mixed with light pipes:
Indicator "System":
GPIO0: blue
GPIO2: amber
Indicator "Signal":
GPIO44: blue
GPIO37: amber
GPIO46: red
All except GPIO46 were already added by Jo Deisenhofer. GPIO46 is used for UART1 by
default, so it needs additional pin control change in devicetree to be operational.
Verified on my RA75.
Signed-off-by: Oleksandr Zharov <alex.zeed@gmail.com>
Re-enable the Aruba AP-365 with DSA support. Changes are trvivial, as
the board design is pretty much the already updated AP-303.
Run-tested on the device.
Signed-off-by: David Bauer <mail@david-bauer.net>
Import commit "ubi: Fix failure attaching when vid_hdr offset equals to
(sub)page size" which did not yet make it to stable upstream Linux trees.
Fixes: #12232Fixes: #12339
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Now that new pinconf features have been backported sync pinctrl-mt7981
and pinctrl-m7986 with bleeding-edge upstream versions.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Backport new features for MediaTek pinctrl/pinconf drivers from upstream.
This will serve as the base to improve pinconf bias/pull-up/pull-down on
MT7981 and MT7986, and also prepare for upcoming support for MT7988.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Avoid MCU getting "command reply receive timed out" message when LED
configuration setting trigger function is enabled in heartbeat mode.
Signed-off-by: Ian Chang <ianchang@ieiworld.com>
It appears that the refactor of the upgrade process for NAND devices resulted in the nand_do_upgrade_success step not being called for
devices using the linksys.sh script. As a result, configuration was
not preserved over sysupgrade steps.
This corrects a typo in the call of nand_do_upgrade_failed for ipq40xx
and ipq806x devices using the linksys.sh script.
Fixes: 8634c1080d ("ipq40xx: Fix Linksys upgrade, restore config step")
Fixes: 2715aff5df ("ipq806x: Fix Linksys upgrade, restore config step")
Signed-off-by: Michael Trinidad <trinidude4@hotmail.com>
It appears that the refactor of the upgrade process for NAND devices resulted in the nand_do_upgrade_success step not being called for
devices using the linksys.sh script. As a result, configuration was
not preserved over sysupgrade steps.
This restores the preservation of configs for mvebu/cortexa9 devices using the
linksys.sh script.
Fixes: e25e6d8e54 ("base-files: fix and clean up nand sysupgrade code")
Signed-off-by: Michael Trinidad <trinidude4@hotmail.com>
It appears that the refactor of the upgrade process for NAND devices
resulted in the nand_do_upgrade_success step not being called for
devices using the linksys.sh script. As a result, configuration was
not preserved over sysupgrade steps.
This restores the preservation of configs for kirkwood devices using the
linksys.sh script.
Fixes: e25e6d8e54 ("base-files: fix and clean up nand sysupgrade code")
Fixes: #12298
Signed-off-by: Michael Trinidad <trinidude4@hotmail.com>
Getting ready for the next release.
Signed-off-by: Paul Spooren <mail@aparcar.org>
[rmilecki: tested on GT-AC5300: boot, sysupgrade & 940 Mbps NAT]
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
bmips target is now more stable and it's time to start generating buildbot
images in order to receive a wider testing, which will be essential to replace
bcm63xx target in the future.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
BMIPS is a generic arch that can be used for multiple Broadcom SoCs, each one
with its own specific drivers, so instead of having a huge kernel supporting
all of them, let's switch to a subtarget per SoC like other OpenWrt targets.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Add BCM6328 and BCM6358 LED kernel modules.
This allows selecting the LED controllers only for those devices using them.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Sercomm SHG2500 is a BCM63168 with 128M of RAM, 256M of NAND, an external
BCM53124S switch for the LAN ports and internal/external Broadcom wifi.
LEDs are connected to an external MSP430G2513 MCU controlled via SPI.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Make use of sercomm-pid script for generating the Sercomm PID, which avoids
having to add an array of hex bytes for every new Sercomm device.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
SERCOMM_VERSION is ambiguous and it should be more clear that it refers to the
version used for the filesystem.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Instead of passing an array of hex bytes for the Sercomm PID we can now use
the --pid-file parameter.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
