openwrt/package/boot/uboot-mvebu/patches/101-net-mvpp2-fix-10GBase-R-support.patch
Robert Marko 14bf60deb8 uboot-mvebu: add support for MikroTik RB5009
MikroTik RB5009 uses RouterBoot as its bootloader like all MikroTik devices
running RouterOS, meaning that its not FIT compatible and can only boot
ELF images.

Now this is not so much of an issue on ARM or MIPS since kernel supports
appending DTB-s to it (Or we patch the kernel to embed it), but on ARM64
there is intentionally no such support.

RouterBoot will pass a DTB, but its the broken MikroTik one which is a
modified reference DTB and incorrect in more places than its valid so we
cannot use it to boot our kernel.

Thus, the solution is to use an intermediary loader and luckily for us
Armada 7040 is well supported in U-Boot which makes it a great option since
it supports anything that we will ever need to boot.

Upstream U-Boot currently requires the Armada boards to be converted to
OF_UPSTREAM before adding anything new and this requires updating all of
the drivers to accomodate the Linux DTS, while I plan to do this eventually
we will need to keep this board downstream for now.

Most stuff is supported in U-Boot, including networking since the switch
is preconfigured by RouterBoot.

A custom environment is used to try and boot from the following devices:
1. NAND (UBI)
2. USB
3. Networking

If NAND boot fails then U-Boot will attempt to boot OpenWrt initramfs from
USB or via networking.

There is a manual recovery mechanism implemented where if the reset button
is held when U-Boot is booting it will try to boot OpenWrt initramfs from:
1. USB
2. Networking

When U-Boot is in recovery mode it will light all of the LED-s except the
switch ones.

Link: https://github.com/openwrt/openwrt/pull/15765
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-06-24 09:46:19 +02:00

109 lines
3.3 KiB
Diff

From 0de5d031f36bca4f7c2686287eff1ef0f5412367 Mon Sep 17 00:00:00 2001
From: Sergey Sergeev <adron@yapic.net>
Date: Sun, 16 Jan 2022 17:19:35 +0100
Subject: [PATCH 2/3] net: mvpp2: fix 10GBase-R support
Due to the lack of XPCS register initialization code and partially incorrect
initialization of the MPCS network controler registers (tested on Mikrotik RB5009
in conjunction with MV88E6393X) the network does not work correctly.
The problem manifests itself as an arbitrary delay (0.4-4 sec) for the actual
data transmission to the network! Accordingly, an almost completely non-working
network for U-Boot is obtained. The code is backported from a similar Linux driver.
Signed-off-by: Sergey Sergeev <adron@yapic.net>
Signed-off-by: Robert Marko <robimarko@gmail.com>
---
drivers/net/mvpp2.c | 73 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
--- a/drivers/net/mvpp2.c
+++ b/drivers/net/mvpp2.c
@@ -3255,6 +3255,76 @@ static int gop_gpcs_reset(struct mvpp2_p
return 0;
}
+static void gop_pcs_reset_assert(struct mvpp2_port *port)
+{
+ u32 val;
+
+ if (port->priv->hw_version == MVPP21 || port->gop_id != 0)
+ return;
+
+ val = readl(port->priv->mpcs_base + port->gop_id * MVPP22_PORT_OFFSET +
+ PCS_CLOCK_RESET);
+ val &= ~(MAC_CLK_RESET_MASK | RX_SD_CLK_RESET_MASK | TX_SD_CLK_RESET_MASK);
+ val |= CLK_DIV_PHASE_SET_MASK;
+ writel(val, port->priv->mpcs_base + port->gop_id * MVPP22_PORT_OFFSET +
+ PCS_CLOCK_RESET);
+
+ val = readl(port->priv->xpcs_base + port->gop_id * MVPP22_PORT_OFFSET +
+ MVPP22_XPCS_GLOBAL_CFG_0_REG);
+ val &= ~MVPP22_XPCS_PCSRESET;
+ writel(val, port->priv->xpcs_base + port->gop_id * MVPP22_PORT_OFFSET +
+ MVPP22_XPCS_GLOBAL_CFG_0_REG);
+}
+
+static void gps_pcs_reset_deassert(struct mvpp2_port *port)
+{
+ u32 val;
+
+ if (port->priv->hw_version == MVPP21 || port->gop_id != 0)
+ return;
+
+ /* this code is only for case of PHY_INTERFACE_MODE_10GBASER! */
+ val = readl(port->priv->mpcs_base + port->gop_id * MVPP22_PORT_OFFSET +
+ PCS_CLOCK_RESET);
+ val |= MAC_CLK_RESET_MASK | RX_SD_CLK_RESET_MASK |
+ TX_SD_CLK_RESET_MASK;
+ val &= ~CLK_DIV_PHASE_SET_MASK;
+ writel(val, port->priv->mpcs_base + port->gop_id * MVPP22_PORT_OFFSET +
+ PCS_CLOCK_RESET);
+}
+
+/* Set the internal mux's to the required PCS in the PI */
+static int gop_xpcs_mode(struct mvpp2_port *port, int num_of_lanes)
+{
+ u32 val;
+ int lane;
+
+ switch (num_of_lanes) {
+ case 1:
+ lane = 0;
+ break;
+ case 2:
+ lane = 1;
+ break;
+ case 4:
+ lane = 2;
+ break;
+ default:
+ return -1;
+ }
+
+ /* configure XG MAC mode */
+ val = readl(port->priv->xpcs_base + port->gop_id * MVPP22_PORT_OFFSET +
+ MVPP22_XPCS_GLOBAL_CFG_0_REG);
+ val &= ~MVPP22_XPCS_PCSMODE_MASK;
+ val &= ~MVPP22_XPCS_LANEACTIVE_MASK;
+ val |= (2 * lane) << MVPP22_XPCS_LANEACTIVE_OFFS;
+ writel(val, port->priv->xpcs_base + port->gop_id * MVPP22_PORT_OFFSET +
+ MVPP22_XPCS_GLOBAL_CFG_0_REG);
+
+ return 0;
+}
+
static int gop_mpcs_mode(struct mvpp2_port *port)
{
u32 val;
@@ -3397,7 +3467,10 @@ static int gop_port_init(struct mvpp2_po
num_of_act_lanes = 2;
mac_num = 0;
/* configure PCS */
+ gop_pcs_reset_assert(port);
+ gop_xpcs_mode(port, num_of_act_lanes);
gop_mpcs_mode(port);
+ gps_pcs_reset_deassert(port);
/* configure MAC */
gop_xlg_mac_mode_cfg(port, num_of_act_lanes);