Support for Orange Pi R1 Plus LTS, Drivers for YT8531 and other Motorcomm chips. Linux-5.10y and Linux-5.15y.
Description
I’m submitting a pull request providing support for Orange Pi R1 Plus LTS, (Rockchip RK3328, 1GB LPDDR3 RAM,2 x 1GB Ethernet ports YT8531C and USB3 RTL8513B).
Patches are for uBoot, Linux-5.10y and Linux-5.15y Includes drivers for YT8531 and other Motorcomm chips YT8010, YT8510, YT8511, YT8512, YT8521.
The driver patch set for Linux-5.10y renames the existing "net-phy-Add-driver-for-Motorcomm-YT85xx-PHYs.patch" to "net-phy-Add-driver-for-Motorcomm-1-YT85xx-PHYs" to ensure correct patching order. The existing patch incorporates YT8010, YT8510, YT8511, YT8512 and YT8521
Patch "net-phy-Add-driver-for-Motorcomm-2-YT8531-PHYs.patch" incorporates YT8531(C) and is sourced from Lean's OpenWrt rockchip/patches-5.10/601-net-phy-Add-driver-for-Motorcomm-YT8531-PHYs.patch. It is intended to extend a patch identical to Armbian's "net-phy-Add-driver-for-Motorcomm-YT85xx-PHYs.patch" and is used without alteration. I've renamed it to "net-phy-Add-driver-for-Motorcomm-2-YT8531-PHYs.patch" to match Armbian's existing Motorcomm patch and ensure correct patching order.
The driver patch set for Linux-5.15y is sourced from Xunlong-OrangePi OpenWRT and is used as is, with only a name and makefile change. The single patch combines the two patches and uses the same underlying source code as the Linux-5.10y set of two patches, but uses inbuilt logic to apply tweaks that depend on the Linux kernel version. The patch is renamed to net-phy-Add-driver-for-Motorcomm-T85xx+PHYs to indicate code base continuity with the previous Armbian patch sets.
defconfig comes from the OEM 5.10 build.
I got the OEM uBoot DTS to build after I added in two missing family DTS's (that seems acceptable to me).
I'm happy with the 5.15 kernel DTS, it comes from the OEM and works without change.
I couldn't get the 5.10 Kernel DTS to build via a the usual scripts and DTSI. The OEM build must be quite different. I don't know much about device trees, so after struggling for days, I reverse engineered the OEM 5.10 build dts.tmp file and created a monolithic dts that compiles without errors or warnings and works well.
The only other uBoot change in /drivers/net/phy/phy.c is reverse engineered from the OEM build and seems trivial to me and I don't think that it will cause issues for other cards, but I have no way to test.
I’m submitting a pull request providing support for Orange Pi R1 Plus LTS, (Rockchip RK3328, 1GB LPDDR3 RAM,2 x 1GB Ethernet ports YT8531C and USB3 RTL8513B).
Patches are for uBoot, Linux-5.10y and Linux-5.15y
Includes drivers for YT8531 and other Motorcomm chips YT8010, YT8510, YT8511, YT8512, YT8521.
The driver patch set for Linux-5.10y renames the existing "net-phy-Add-driver-for-Motorcomm-YT85xx-PHYs.patch" to "net-phy-Add-driver-for-Motorcomm-1-YT85xx-PHYs" to ensure correct patching order.
The existing patch incorporates YT8010, YT8510, YT8511, YT8512 and YT8521
Patch "net-phy-Add-driver-for-Motorcomm-2-YT8531-PHYs.patch" incorporates YT8531(C) and is sourced
from Lean's OpenWrt rockchip/patches-5.10/601-net-phy-Add-driver-for-Motorcomm-YT8531-PHYs.patch. It is intended to extend a patch identical to Armbian's "net-phy-Add-driver-for-Motorcomm-YT85xx-PHYs.patch" and is used without alteration. I've renamed it to "net-phy-Add-driver-for-Motorcomm-2-YT8531-PHYs.patch" to match Armbian's existing Motorcomm patch and ensure correct patching order.
The driver patch set for Linux-5.15y is sourced from Xunlong-OrangePi OpenWRT and is used as is, with only a name and makefile change. The single patch combines the two patches and uses the same underlying source code as the Linux-5.10y set of two patches, but uses inbuilt logic to apply tweaks that depend on the Linux kernel version. The patch is renamed to net-phy-Add-driver-for-Motorcomm-T85xx+PHYs to indicate code base continuity with the previous Armbian patch sets.
defconfig comes from the OEM 5.10 build.
I got the OEM uBoot DTS to build after I added in two missing family DTS's (that seems acceptable to me).
I'm happy with the 5.15 kernel DTS, it comes from the OEM and works without change.
I couldn't get the 5.10 Kernel DTS to build via a the usual scripts and DTSI. The OEM build must be quite different. I don't know much about device trees, so after struggling for days, I reverse engineered the OEM 5.10 build dts.tmp file and created a monolithic dts that compiles without errors or warnings and works well.
The only other uBoot change in /drivers/net/phy/phy.c is reverse engineered from the OEM build and seems trivial to me and I don't think that it will cause issues for other cards, but I have no way to test.