2018-05-06 21:58:06 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2014-11-24 09:11:56 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2014 Freescale Semiconductor, Inc.
|
|
|
|
*
|
2015-03-27 07:48:34 +00:00
|
|
|
* Shengzhou Liu <Shengzhou.Liu@freescale.com>
|
2014-11-24 09:11:56 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <common.h>
|
|
|
|
#include <command.h>
|
2020-05-10 17:40:01 +00:00
|
|
|
#include <fdt_support.h>
|
2020-05-10 17:39:56 +00:00
|
|
|
#include <net.h>
|
2014-11-24 09:11:56 +00:00
|
|
|
#include <netdev.h>
|
|
|
|
#include <asm/mmu.h>
|
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/immap_85xx.h>
|
|
|
|
#include <asm/fsl_law.h>
|
|
|
|
#include <asm/fsl_serdes.h>
|
|
|
|
#include <asm/fsl_portals.h>
|
|
|
|
#include <asm/fsl_liodn.h>
|
|
|
|
#include <malloc.h>
|
|
|
|
#include <fm_eth.h>
|
|
|
|
#include <fsl_mdio.h>
|
|
|
|
#include <miiphy.h>
|
|
|
|
#include <phy.h>
|
2015-10-26 11:47:47 +00:00
|
|
|
#include <fsl_dtsec.h>
|
2014-11-24 09:11:56 +00:00
|
|
|
#include <asm/fsl_serdes.h>
|
2014-12-17 08:51:08 +00:00
|
|
|
#include "../common/fman.h"
|
2014-11-24 09:11:56 +00:00
|
|
|
|
2020-06-26 06:13:33 +00:00
|
|
|
int board_eth_init(struct bd_info *bis)
|
2014-11-24 09:11:56 +00:00
|
|
|
{
|
|
|
|
#if defined(CONFIG_FMAN_ENET)
|
|
|
|
int i, interface;
|
|
|
|
struct memac_mdio_info dtsec_mdio_info;
|
|
|
|
struct memac_mdio_info tgec_mdio_info;
|
|
|
|
struct mii_dev *dev;
|
|
|
|
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
|
|
|
|
u32 srds_s1;
|
|
|
|
|
|
|
|
srds_s1 = in_be32(&gur->rcwsr[4]) &
|
|
|
|
FSL_CORENET2_RCWSR4_SRDS1_PRTCL;
|
|
|
|
srds_s1 >>= FSL_CORENET2_RCWSR4_SRDS1_PRTCL_SHIFT;
|
|
|
|
|
|
|
|
dtsec_mdio_info.regs =
|
|
|
|
(struct memac_mdio_controller *)CONFIG_SYS_FM1_DTSEC_MDIO_ADDR;
|
|
|
|
|
|
|
|
dtsec_mdio_info.name = DEFAULT_FM_MDIO_NAME;
|
|
|
|
|
|
|
|
/* Register the 1G MDIO bus */
|
|
|
|
fm_memac_mdio_init(bis, &dtsec_mdio_info);
|
|
|
|
|
|
|
|
tgec_mdio_info.regs =
|
|
|
|
(struct memac_mdio_controller *)CONFIG_SYS_FM1_TGEC_MDIO_ADDR;
|
|
|
|
tgec_mdio_info.name = DEFAULT_FM_TGEC_MDIO_NAME;
|
|
|
|
|
|
|
|
/* Register the 10G MDIO bus */
|
|
|
|
fm_memac_mdio_init(bis, &tgec_mdio_info);
|
|
|
|
|
2014-12-17 08:51:08 +00:00
|
|
|
/* Set the on-board RGMII PHY address */
|
2014-11-24 09:11:56 +00:00
|
|
|
fm_info_set_phy_address(FM1_DTSEC4, RGMII_PHY1_ADDR);
|
|
|
|
|
|
|
|
switch (srds_s1) {
|
2016-12-28 16:43:34 +00:00
|
|
|
#ifdef CONFIG_TARGET_T1024RDB
|
2014-11-24 09:11:56 +00:00
|
|
|
case 0x95:
|
2014-12-17 08:51:08 +00:00
|
|
|
/* set the on-board RGMII2 PHY */
|
|
|
|
fm_info_set_phy_address(FM1_DTSEC3, RGMII_PHY2_ADDR);
|
|
|
|
|
2021-09-18 12:32:34 +00:00
|
|
|
/* set 10GBase-R with Aquantia AQR105 PHY */
|
2014-11-24 09:11:56 +00:00
|
|
|
fm_info_set_phy_address(FM1_10GEC1, FM1_10GEC1_PHY_ADDR);
|
|
|
|
break;
|
2015-03-27 07:48:34 +00:00
|
|
|
#endif
|
|
|
|
case 0x6a:
|
|
|
|
case 0x6b:
|
2014-12-17 08:51:08 +00:00
|
|
|
case 0x77:
|
|
|
|
case 0x135:
|
|
|
|
/* set the on-board 2.5G SGMII AQR105 PHY */
|
2015-03-27 07:48:34 +00:00
|
|
|
fm_info_set_phy_address(FM1_DTSEC3, SGMII_AQR_PHY_ADDR);
|
2016-12-28 16:43:33 +00:00
|
|
|
#ifdef CONFIG_TARGET_T1023RDB
|
2015-03-27 07:48:34 +00:00
|
|
|
/* set the on-board 1G SGMII RTL8211F PHY */
|
|
|
|
fm_info_set_phy_address(FM1_DTSEC1, SGMII_RTK_PHY_ADDR);
|
|
|
|
#endif
|
2014-12-17 08:51:08 +00:00
|
|
|
break;
|
2014-11-24 09:11:56 +00:00
|
|
|
default:
|
|
|
|
printf("SerDes protocol 0x%x is not supported on T102xRDB\n",
|
|
|
|
srds_s1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = FM1_DTSEC1; i < FM1_DTSEC1 + CONFIG_SYS_NUM_FM1_DTSEC; i++) {
|
|
|
|
interface = fm_info_get_enet_if(i);
|
|
|
|
switch (interface) {
|
|
|
|
case PHY_INTERFACE_MODE_RGMII:
|
2020-11-04 13:09:17 +00:00
|
|
|
case PHY_INTERFACE_MODE_RGMII_TXID:
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_RXID:
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_ID:
|
2014-11-24 09:11:56 +00:00
|
|
|
dev = miiphy_get_dev_by_name(DEFAULT_FM_MDIO_NAME);
|
|
|
|
fm_info_set_mdio(i, dev);
|
|
|
|
break;
|
2015-03-27 07:48:34 +00:00
|
|
|
case PHY_INTERFACE_MODE_SGMII:
|
2016-12-28 16:43:33 +00:00
|
|
|
#if defined(CONFIG_TARGET_T1023RDB)
|
2015-03-27 07:48:34 +00:00
|
|
|
dev = miiphy_get_dev_by_name(DEFAULT_FM_MDIO_NAME);
|
2016-12-28 16:43:34 +00:00
|
|
|
#elif defined(CONFIG_TARGET_T1024RDB)
|
2015-03-27 07:48:34 +00:00
|
|
|
dev = miiphy_get_dev_by_name(DEFAULT_FM_TGEC_MDIO_NAME);
|
|
|
|
#endif
|
|
|
|
fm_info_set_mdio(i, dev);
|
|
|
|
break;
|
net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x"
After the discussion here:
https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/
which resulted in this patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-pali@kernel.org/
and many other discussions before it, notably:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512016235-15909-1-git-send-email-Bhaskar.Upadhaya@nxp.com/
it became apparent that nobody really knows what "SGMII 2500" is.
Certainly, Freescale/NXP hardware engineers name this protocol
"SGMII 2500" in the reference manuals, but the PCS devices do not
support any "SGMII" specific features when operating at the speed of
2500 Mbps, no in-band autoneg and no speed change via symbol replication
. So that leaves a fixed speed of 2500 Mbps using a coding of 8b/10b
with a SERDES lane frequency of 3.125 GHz. In fact, "SGMII 2500 without
in-band autoneg and at a fixed speed" is indistinguishable from
"2500base-x without in-band autoneg", which is precisely what these NXP
devices support.
So it just appears that "SGMII 2500" is an unclear name with no clear
definition that stuck.
As such, in the Linux kernel, the drivers which use this SERDES protocol
use the 2500base-x phy-mode.
This patch converts U-Boot to use 2500base-x too, or at least, as much
as it can.
Note that I would have really liked to delete PHY_INTERFACE_MODE_SGMII_2500
completely, but the mvpp2 driver seems to even distinguish between SGMII
2500 and 2500base-X. Namely, it enables in-band autoneg for one but not
the other, and forces flow control for one but not the other. This goes
back to the idea that maybe 2500base-X is a fiber protocol and SGMII-2500
is an MII protocol (connects a MAC to a PHY such as Aquantia), but the
two are practically indistinguishable through everything except use case.
NXP devices can support both use cases through an identical configuration,
for example RX flow control can be unconditionally enabled in order to
support rate adaptation performed by an Aquantia PHY. At least I can
find no indication in online documents published by Cisco which would
point towards "SGMII-2500" being an actual standard with an actual
definition, so I cannot say "yes, NXP devices support it".
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-18 12:32:35 +00:00
|
|
|
case PHY_INTERFACE_MODE_2500BASEX:
|
2014-12-17 08:51:08 +00:00
|
|
|
dev = miiphy_get_dev_by_name(DEFAULT_FM_TGEC_MDIO_NAME);
|
|
|
|
fm_info_set_mdio(i, dev);
|
|
|
|
break;
|
2014-11-24 09:11:56 +00:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = FM1_10GEC1; i < FM1_10GEC1 + CONFIG_SYS_NUM_FM1_10GEC; i++) {
|
|
|
|
switch (fm_info_get_enet_if(i)) {
|
|
|
|
case PHY_INTERFACE_MODE_XGMII:
|
|
|
|
dev = miiphy_get_dev_by_name(DEFAULT_FM_TGEC_MDIO_NAME);
|
|
|
|
fm_info_set_mdio(i, dev);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
cpu_eth_init(bis);
|
|
|
|
#endif /* CONFIG_FMAN_ENET */
|
|
|
|
|
|
|
|
return pci_eth_init(bis);
|
|
|
|
}
|
|
|
|
|
2014-12-17 08:51:08 +00:00
|
|
|
void board_ft_fman_fixup_port(void *fdt, char *compat, phys_addr_t addr,
|
|
|
|
enum fm_port port, int offset)
|
|
|
|
{
|
2016-12-28 16:43:34 +00:00
|
|
|
#if defined(CONFIG_TARGET_T1024RDB)
|
net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x"
After the discussion here:
https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/
which resulted in this patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-pali@kernel.org/
and many other discussions before it, notably:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512016235-15909-1-git-send-email-Bhaskar.Upadhaya@nxp.com/
it became apparent that nobody really knows what "SGMII 2500" is.
Certainly, Freescale/NXP hardware engineers name this protocol
"SGMII 2500" in the reference manuals, but the PCS devices do not
support any "SGMII" specific features when operating at the speed of
2500 Mbps, no in-band autoneg and no speed change via symbol replication
. So that leaves a fixed speed of 2500 Mbps using a coding of 8b/10b
with a SERDES lane frequency of 3.125 GHz. In fact, "SGMII 2500 without
in-band autoneg and at a fixed speed" is indistinguishable from
"2500base-x without in-band autoneg", which is precisely what these NXP
devices support.
So it just appears that "SGMII 2500" is an unclear name with no clear
definition that stuck.
As such, in the Linux kernel, the drivers which use this SERDES protocol
use the 2500base-x phy-mode.
This patch converts U-Boot to use 2500base-x too, or at least, as much
as it can.
Note that I would have really liked to delete PHY_INTERFACE_MODE_SGMII_2500
completely, but the mvpp2 driver seems to even distinguish between SGMII
2500 and 2500base-X. Namely, it enables in-band autoneg for one but not
the other, and forces flow control for one but not the other. This goes
back to the idea that maybe 2500base-X is a fiber protocol and SGMII-2500
is an MII protocol (connects a MAC to a PHY such as Aquantia), but the
two are practically indistinguishable through everything except use case.
NXP devices can support both use cases through an identical configuration,
for example RX flow control can be unconditionally enabled in order to
support rate adaptation performed by an Aquantia PHY. At least I can
find no indication in online documents published by Cisco which would
point towards "SGMII-2500" being an actual standard with an actual
definition, so I cannot say "yes, NXP devices support it".
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-18 12:32:35 +00:00
|
|
|
if (((fm_info_get_enet_if(port) == PHY_INTERFACE_MODE_2500BASEX) ||
|
2015-03-27 07:48:34 +00:00
|
|
|
(fm_info_get_enet_if(port) == PHY_INTERFACE_MODE_SGMII)) &&
|
|
|
|
(port == FM1_DTSEC3)) {
|
2014-12-17 08:51:08 +00:00
|
|
|
fdt_set_phy_handle(fdt, compat, addr, "sg_2500_aqr105_phy4");
|
2015-04-14 09:56:50 +00:00
|
|
|
fdt_setprop_string(fdt, offset, "phy-connection-type",
|
net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x"
After the discussion here:
https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/
which resulted in this patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-pali@kernel.org/
and many other discussions before it, notably:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512016235-15909-1-git-send-email-Bhaskar.Upadhaya@nxp.com/
it became apparent that nobody really knows what "SGMII 2500" is.
Certainly, Freescale/NXP hardware engineers name this protocol
"SGMII 2500" in the reference manuals, but the PCS devices do not
support any "SGMII" specific features when operating at the speed of
2500 Mbps, no in-band autoneg and no speed change via symbol replication
. So that leaves a fixed speed of 2500 Mbps using a coding of 8b/10b
with a SERDES lane frequency of 3.125 GHz. In fact, "SGMII 2500 without
in-band autoneg and at a fixed speed" is indistinguishable from
"2500base-x without in-band autoneg", which is precisely what these NXP
devices support.
So it just appears that "SGMII 2500" is an unclear name with no clear
definition that stuck.
As such, in the Linux kernel, the drivers which use this SERDES protocol
use the 2500base-x phy-mode.
This patch converts U-Boot to use 2500base-x too, or at least, as much
as it can.
Note that I would have really liked to delete PHY_INTERFACE_MODE_SGMII_2500
completely, but the mvpp2 driver seems to even distinguish between SGMII
2500 and 2500base-X. Namely, it enables in-band autoneg for one but not
the other, and forces flow control for one but not the other. This goes
back to the idea that maybe 2500base-X is a fiber protocol and SGMII-2500
is an MII protocol (connects a MAC to a PHY such as Aquantia), but the
two are practically indistinguishable through everything except use case.
NXP devices can support both use cases through an identical configuration,
for example RX flow control can be unconditionally enabled in order to
support rate adaptation performed by an Aquantia PHY. At least I can
find no indication in online documents published by Cisco which would
point towards "SGMII-2500" being an actual standard with an actual
definition, so I cannot say "yes, NXP devices support it".
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-18 12:32:35 +00:00
|
|
|
"2500base-x");
|
2014-12-17 08:51:08 +00:00
|
|
|
fdt_status_disabled_by_alias(fdt, "xg_aqr105_phy3");
|
|
|
|
}
|
2015-03-27 07:48:34 +00:00
|
|
|
#endif
|
2014-12-17 08:51:08 +00:00
|
|
|
}
|
|
|
|
|
2014-11-24 09:11:56 +00:00
|
|
|
void fdt_fixup_board_enet(void *fdt)
|
|
|
|
{
|
|
|
|
}
|