Re: [U-Boot] [PATCH v3 3/4] net: phy: Force master mode A20-OLinuXino-Lime2
On 03/26/2016 12:46 AM, Iain Paton wrote: > On 24/03/16 06:46, Michael Haas wrote: >> Force master mode on the A20-OLinuXino-Lime2. This change is required >> to get a reliable link at gigabit speeds. >> >> Signed-off-by: Michael Haas > Acked-by: Iain Paton > > Glad to see someone finally got to the bottom of this. On the boards I have > I only see the problem intermittantly, perhaps 2% of boots so virtually > impossible to know if anything fixed it. > > Is something needed in the kernel as well, or is it sufficient to do it in > u-boot? > > Iain I have not verified this extensively. In my experience, fixing u-boot is enough to get a stable link in the kernel. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/3] net: phy: Optionally force master mode for RTL PHY
This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this define is set, RTL8211x PHYs (except for the RTL8211F) will have their 1000BASE-T master/slave autonegotiation disabled and forced to master mode. This is helpful for PHYs like the RTL8211C which produce unstable links in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB and A20-OLinuXino-Lime2. There is no proper way to identify affected PHYs in software as the RTL8211C shares its UID with the RTL8211B. Thus, this fix requires the introduction of an #ifdef. CC: fra...@gmail.com CC: mer...@debian.org CC: hdego...@redhat.com CC: i...@hellion.org.uk CC: joe.hershber...@ni.com Signed-off-by: Michael Haas Tested-by: Karsten Merker --- Changes in v5: - Improve formatting of Kconfig help text. No content change. Change suggested by Karsten Merker. Changes in v4: - Squashed previously separate commit introducing KCONFIG variable into commit containing main code change (Hans de Goede's suggestion) - Changed KCONFIG description according to Karsten Merker's suggestions plus some clarification of my own - Changed commit message according to Karsten Merker's suggestions Changes in v3: - Remove incorrect detection of RTL8211CL and use #ifdef instead (thanks to Karsten Merker) - Introduced constants for register bits Changes in v2: - Removed accidental inclusion of Karsten's patch in my first submission of this series. - Fix a typo in the code: 6 -> & drivers/net/Kconfig | 21 + drivers/net/phy/realtek.c | 13 - 2 files changed, 33 insertions(+), 1 deletion(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 2a229b8..e0008fd 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -13,6 +13,27 @@ config PHYLIB help Enable Ethernet PHY (physical media interface) support. +config RTL8211X_PHY_FORCE_MASTER + bool "Ethernet PHY RTL8211x: force 1000BASE-T master mode" + depends on PHYLIB + help + Force master mode for 1000BASE-T on RTl8211x PHYs (except for RTL8211F). + This can work around link stability and data corruption issues on gigabit + links which can occur in slave mode on certain PHYs, e.g. on the + RTL8211C(L). + + Please note that two directly connected devices (i.e. via crossover cable) + will not be able to establish a link between each other if they both force + master mode. Multiple devices forcing master mode when connected by a + network switch do not pose a problem as the switch configures its affected + ports into slave mode. + + This option only affects gigabit links. If you must establish a direct + connection between two devices which both force master mode, try forcing + the link speed to 100MBit/s. + + If unsure, say N. + menuconfig NETDEVICES bool "Network device support" depends on NET diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c index 259a87f..359ec50 100644 --- a/drivers/net/phy/realtek.c +++ b/drivers/net/phy/realtek.c @@ -12,6 +12,10 @@ #define PHY_AUTONEGOTIATE_TIMEOUT 5000 +/* RTL8211x 1000BASE-T Control Register */ +#define MIIM_RTL8211x_CTRL1000T_MSCE (1 << 12); +#define MIIM_RTL8211X_CTRL1000T_MASTER (1 << 11); + /* RTL8211x PHY Status Register */ #define MIIM_RTL8211x_PHY_STATUS 0x11 #define MIIM_RTL8211x_PHYSTAT_SPEED0xc000 @@ -53,7 +57,14 @@ static int rtl8211x_config(struct phy_device *phydev) */ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER, MIIM_RTL8211x_PHY_INTR_DIS); - +#ifdef CONFIG_RTL8211X_PHY_FORCE_MASTER + unsigned int reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_CTRL1000); + /* force manual master/slave configuration */ + reg |= MIIM_RTL8211x_CTRL1000T_MSCE; + /* force master mode */ + reg |= MIIM_RTL8211X_CTRL1000T_MASTER; + phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg); +#endif /* read interrupt status just to clear it */ phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER); -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/3] sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master
Force master mode for 1000BASE-T operation on the A20-Olimex-SOM-EVB. Karsten Merker reports that this change is necessary to get a reliable link at gigabit speeds. Signed-off-by: Michael Haas --- Changes in v5: - Fix order of defconfig entry (suggested by Karsten Marker) Series-changes: 4 - Changed commit summary according to Chen-Yu Tsai's suggestion, modified to fit the 70 character limit Changes in v4: None Changes in v3: None Changes in v2: None configs/A20-Olimex-SOM-EVB_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/A20-Olimex-SOM-EVB_defconfig b/configs/A20-Olimex-SOM-EVB_defconfig index 66d8f98..bcfbf9c 100644 --- a/configs/A20-Olimex-SOM-EVB_defconfig +++ b/configs/A20-Olimex-SOM-EVB_defconfig @@ -17,5 +17,6 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)" # CONFIG_CMD_FLASH is not set # CONFIG_CMD_FPGA is not set CONFIG_CMD_GPIO=y +CONFIG_RTL8211X_PHY_FORCE_MASTER=y CONFIG_ETH_DESIGNWARE=y CONFIG_USB_EHCI_HCD=y -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/3] sunxi: A20-OLinuXino-Lime2: Force 8211CL to master
Force master mode on the A20-OLinuXino-Lime2. This change is required to get a reliable link at gigabit speeds. Signed-off-by: Michael Haas --- Changes in v5: - Fix order of defconfig entry (suggested by Karsten Marker) Changes in v4: - Changed commit summary according to Chen-Yu Tsai's suggestion, modified to fit the 70 character limit Changes in v3: None Changes in v2: None configs/A20-OLinuXino-Lime2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig index 95c67d6..1de503a 100644 --- a/configs/A20-OLinuXino-Lime2_defconfig +++ b/configs/A20-OLinuXino-Lime2_defconfig @@ -14,5 +14,6 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)" # CONFIG_CMD_FLASH is not set # CONFIG_CMD_FPGA is not set CONFIG_CMD_GPIO=y +CONFIG_RTL8211X_PHY_FORCE_MASTER=y CONFIG_ETH_DESIGNWARE=y CONFIG_USB_EHCI_HCD=y -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/3] net: phy: Force master mode for RTL8211C on some boards
This patch is required to get reliable 1000BASE-T operation on some boards using the RTL8211C(L) PHY. Following discussions on v2 of this patch, I have removed the incorrect check for the RTL8211C(L). Affected boards now have to define CONFIG_RTL8211X_PHY_FORCE_MASTER to benefit from the fix. Note that this patch requires Karsten Merkers '[PATCH] net: phy: Realtek RTL8211B/C PHY ID fix' as well as Hans de Goede's recent u-boot-sunxi pull request, specifically 1eae8f66ff749409eb96e2f3f3387c56232d0b8a and fc8991c61c393ce6a9d3dfc97cb56dbbd9e8cbba. Michael Changes in v5: - Improve formatting of Kconfig help text. No content change. Change suggested by Karsten Merker. - Fix order of defconfig entry (suggested by Karsten Marker) Series-changes: 4 - Changed commit summary according to Chen-Yu Tsai's suggestion, modified to fit the 70 character limit - Fix order of defconfig entry (suggested by Karsten Marker) Changes in v4: - Squashed previously separate commit introducing KCONFIG variable into commit containing main code change (Hans de Goede's suggestion) - Changed KCONFIG description according to Karsten Merker's suggestions plus some clarification of my own - Changed commit message according to Karsten Merker's suggestions - Changed commit summary according to Chen-Yu Tsai's suggestion, modified to fit the 70 character limit Changes in v3: - Remove incorrect detection of RTL8211CL and use #ifdef instead (thanks to Karsten Merker) - Introduced constants for register bits Changes in v2: - Removed accidental inclusion of Karsten's patch in my first submission of this series. - Fix a typo in the code: 6 -> & Michael Haas (3): net: phy: Optionally force master mode for RTL PHY sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master sunxi: A20-OLinuXino-Lime2: Force 8211CL to master configs/A20-OLinuXino-Lime2_defconfig | 1 + configs/A20-Olimex-SOM-EVB_defconfig | 1 + drivers/net/Kconfig | 21 + drivers/net/phy/realtek.c | 13 - 4 files changed, 35 insertions(+), 1 deletion(-) -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Linux hangs due to commit v2015.10-15-g02cc27c on loading i2c-mv64xx
On 03/20/2016 08:15 PM, Hans de Goede wrote:
> > I'm running Debian Jessie with Linux 4.3.0-0.bpo.1-armmp-lpae on my
> > a20-olinuxino-lime2.
> > I have noticed that my board hangs with my recent u-boot versions
> when I
> > load the i2c module.
> >
> > git-bisect narrowed the problem down to the following commit:
> >
> > 02cc27c74f9b884b538bcd1b93342a4c05b5d608 is the first bad commit
> > commit 02cc27c74f9b884b538bcd1b93342a4c05b5d608
> > Author: Hans de Goede
> > Date: Sat Oct 3 15:29:24 2015 +0200
> >
> >sunxi: power: Change axp209 LDO3 and LDO4 default to disabled
>
>
>
> > The axp209 is attached to the i2c bus, so that is likely the real
> > culprit. In my setup, the axp209 drivers are loaded before I insert
> > i2c-mv64xxx.
> >
> > What would be the best course of action here?
> >
> > * Revert the commit
> > * Enable LDO3 and LDO4 for the a20-olinuxino-lime2 only?
> > * Fix linux
>
> I would go for option 3: "Fix linux", looking at the lime2 dts I see:
>
> vcc_csi0: ldo3 {
> regulator-min-microvolt = <70>;
> regulator-max-microvolt = <350>;
> regulator-always-on;
> };
>
> vcc_csi1: ldo4 {
> regulator-min-microvolt = <125>;
> regulator-max-microvolt = <330>;
> regulator-always-on;
> };
>
> The regulator-always-on will cause both regulators to get turned on,
> but the min / max constraints match the datasheet constrains / the
> absolute min / max values these ldo-s can deliver, not the constraints
> which the board design puts on these.
>
> So now these ldo-s end up getting turned on at whatever voltage
> is the default (which according to the datasheet is unknown),
> where as the schematic says that if these get turned on (which
> is not necessary) they should be run at 2.8V.
>
> This dts file is the only axp209 using dts file which:
>
> 1) Does not have proper constraints for LDO3 / LDO4
> 2) Uses regulator-always-on; for these
>
> I would suggest fixing both, first you can try making min = max =
> 280. And if that fixes things, which I expect it will, I would
> also drop the regulator-always-on from the dts, since we really
> only need to turn these on when using the csi interface in which
> case it would be up to the csi driver to explicitly turn them on.
>
Setting the voltage to 2.8V does not seem to fix things. Dropping the
'regulator-always-on' stance does allow me to
load and use i2c-mv64xx and axp20x-i2c.
Is that something I should submit upstream or is there further
investigation needed why simply setting a proper voltage
does not work?
Thanks!
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/3] net: phy: Optionally force master mode for RTL PHY
This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this define is set, RTL8211x PHYs (except for the RTL8211F) will have their 1000BASE-T master/slave autonegotiation disabled and forced to master mode. This is helpful for PHYs like the RTL8211C which produce unstable links in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB and A20-OLinuXino-Lime2. There is no proper way to identify affected PHYs in software as the RTL8211C shares its UID with the RTL8211B. Thus, this fix requires the introduction of an #ifdef. CC: fra...@gmail.com CC: mer...@debian.org CC: hdego...@redhat.com CC: i...@hellion.org.uk CC: joe.hershber...@ni.com Signed-off-by: Michael Haas Tested-by: Karsten Merker --- Changes in v4: - Squashed previously separate commit introducing KCONFIG variable into commit containing main code change (Hans de Goede's suggestion) - Changed KCONFIG description according to Karsten Merker's suggestions plus some clarification of my own - Changed commit message according to Karsten Merker's suggestions Changes in v3: - Remove incorrect detection of RTL8211CL and use #ifdef instead (thanks to Karsten Merker) - Introduced constants for register bits Changes in v2: - Removed accidental inclusion of Karsten's patch in my first submission of this series. - Fix a typo in the code: 6 -> & drivers/net/Kconfig | 21 + drivers/net/phy/realtek.c | 13 - 2 files changed, 33 insertions(+), 1 deletion(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 2a229b8..8a95fbd 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -13,6 +13,27 @@ config PHYLIB help Enable Ethernet PHY (physical media interface) support. +config RTL8211X_PHY_FORCE_MASTER + bool "Ethernet PHY RTL8211x: force 1000BASE-T master mode" + depends on PHYLIB + help + Force master mode for 1000BASE-T on RTl8211x PHYs (except for RTL8211F). + This can work around link stability and data + corruption issues on gigabit links which can occur in slave mode on + certain PHYs, e.g. on the RTL8211C(L). + + Please note that two directly connected devices (i.e. via + crossover cable) will not be able to establish a link between each other + if they both force master mode. Multiple devices forcing + master mode when connected by a network switch do not pose a + problem as the switch configures its affected ports into slave + mode. + This option only affects gigabit links. If you must establish a direct + connection between two devices which both force master mode, try forcing + the link speed to 100MBit/s. + + If unsure, say N. + menuconfig NETDEVICES bool "Network device support" depends on NET diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c index 259a87f..359ec50 100644 --- a/drivers/net/phy/realtek.c +++ b/drivers/net/phy/realtek.c @@ -12,6 +12,10 @@ #define PHY_AUTONEGOTIATE_TIMEOUT 5000 +/* RTL8211x 1000BASE-T Control Register */ +#define MIIM_RTL8211x_CTRL1000T_MSCE (1 << 12); +#define MIIM_RTL8211X_CTRL1000T_MASTER (1 << 11); + /* RTL8211x PHY Status Register */ #define MIIM_RTL8211x_PHY_STATUS 0x11 #define MIIM_RTL8211x_PHYSTAT_SPEED0xc000 @@ -53,7 +57,14 @@ static int rtl8211x_config(struct phy_device *phydev) */ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER, MIIM_RTL8211x_PHY_INTR_DIS); - +#ifdef CONFIG_RTL8211X_PHY_FORCE_MASTER + unsigned int reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_CTRL1000); + /* force manual master/slave configuration */ + reg |= MIIM_RTL8211x_CTRL1000T_MSCE; + /* force master mode */ + reg |= MIIM_RTL8211X_CTRL1000T_MASTER; + phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg); +#endif /* read interrupt status just to clear it */ phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER); -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/3] sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master
Force master mode for 1000BASE-T operation on the A20-Olimex-SOM-EVB. Karsten Merker reports that this change is necessary to get a reliable link at gigabit speeds. Signed-off-by: Michael Haas --- Changes in v4: - Changed commit summary according to Chen-Yu Tsai's suggestion, modified to fit the 70 character limit Changes in v3: None Changes in v2: None configs/A20-Olimex-SOM-EVB_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/A20-Olimex-SOM-EVB_defconfig b/configs/A20-Olimex-SOM-EVB_defconfig index 66d8f98..68de5f2 100644 --- a/configs/A20-Olimex-SOM-EVB_defconfig +++ b/configs/A20-Olimex-SOM-EVB_defconfig @@ -19,3 +19,4 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)" CONFIG_CMD_GPIO=y CONFIG_ETH_DESIGNWARE=y CONFIG_USB_EHCI_HCD=y +CONFIG_RTL8211X_PHY_FORCE_MASTER=y -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/3] net: phy: Force master mode for RTL8211C on some boards
This patch is required to get reliable 1000BASE-T operation on some boards using the RTL8211C(L) PHY. Following discussions on v2 of this patch, I have removed the incorrect check for the RTL8211C(L). Affected boards now have to define CONFIG_RTL8211X_PHY_FORCE_MASTER to benefit from the fix. Note that this patch requires Karsten Merkers '[PATCH] net: phy: Realtek RTL8211B/C PHY ID fix' as well as Hans de Goede's recent u-boot-sunxi pull request, specifically 1eae8f66ff749409eb96e2f3f3387c56232d0b8a and fc8991c61c393ce6a9d3dfc97cb56dbbd9e8cbba. Michael Changes in v4: - Squashed previously separate commit introducing KCONFIG variable into commit containing main code change (Hans de Goede's suggestion) - Changed KCONFIG description according to Karsten Merker's suggestions plus some clarification of my own - Changed commit message according to Karsten Merker's suggestions - Changed commit summary according to Chen-Yu Tsai's suggestion, modified to fit the 70 character limit - Changed commit summary according to Chen-Yu Tsai's suggestion, modified to fit the 70 character limit Changes in v3: - Remove incorrect detection of RTL8211CL and use #ifdef instead (thanks to Karsten Merker) - Introduced constants for register bits Changes in v2: - Removed accidental inclusion of Karsten's patch in my first submission of this series. - Fix a typo in the code: 6 -> & Michael Haas (3): net: phy: Optionally force master mode for RTL PHY sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master sunxi: A20-OLinuXino-Lime2: Force 8211CL to master configs/A20-OLinuXino-Lime2_defconfig | 1 + configs/A20-Olimex-SOM-EVB_defconfig | 1 + drivers/net/Kconfig | 21 + drivers/net/phy/realtek.c | 13 - 4 files changed, 35 insertions(+), 1 deletion(-) -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/3] sunxi: A20-OLinuXino-Lime2: Force 8211CL to master
Force master mode on the A20-OLinuXino-Lime2. This change is required to get a reliable link at gigabit speeds. Signed-off-by: Michael Haas --- Changes in v4: - Changed commit summary according to Chen-Yu Tsai's suggestion, modified to fit the 70 character limit Changes in v3: None Changes in v2: None configs/A20-OLinuXino-Lime2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig index 95c67d6..3bd4fa7 100644 --- a/configs/A20-OLinuXino-Lime2_defconfig +++ b/configs/A20-OLinuXino-Lime2_defconfig @@ -16,3 +16,4 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)" CONFIG_CMD_GPIO=y CONFIG_ETH_DESIGNWARE=y CONFIG_USB_EHCI_HCD=y +CONFIG_RTL8211X_PHY_FORCE_MASTER=y -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] net: phy: Optionally force master mode for RTL PHY
This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this define is set, RTL8211x PHYs will have their 1000BASE-T master/slave autonegotiation disabled and forced to master mode. This is helpful for PHYs like the RTL8211C which produce unstable links in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB and A20-OLinuXino-Lime2. There is no proper way to identify affected PHYs as the RTL8211C shares its UID with the RTL8211B. Thus, this fixes requires the introduction of an #ifdef. CC: fra...@gmail.com CC: mer...@debian.org CC: hdego...@redhat.com CC: i...@hellion.org.uk CC: joe.hershber...@ni.com Signed-off-by: Michael Haas --- Changes in v3: - Remove incorrect detection of RTL8211CL and use #ifdef instead (thanks to Karsten Merker) - Introduced constants for register bits Changes in v2: - Removed accidental inclusion of Karsten's patch in my first submission of this series. - Fix a typo in the code: 6 -> & drivers/net/phy/realtek.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c index 259a87f..359ec50 100644 --- a/drivers/net/phy/realtek.c +++ b/drivers/net/phy/realtek.c @@ -12,6 +12,10 @@ #define PHY_AUTONEGOTIATE_TIMEOUT 5000 +/* RTL8211x 1000BASE-T Control Register */ +#define MIIM_RTL8211x_CTRL1000T_MSCE (1 << 12); +#define MIIM_RTL8211X_CTRL1000T_MASTER (1 << 11); + /* RTL8211x PHY Status Register */ #define MIIM_RTL8211x_PHY_STATUS 0x11 #define MIIM_RTL8211x_PHYSTAT_SPEED0xc000 @@ -53,7 +57,14 @@ static int rtl8211x_config(struct phy_device *phydev) */ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER, MIIM_RTL8211x_PHY_INTR_DIS); - +#ifdef CONFIG_RTL8211X_PHY_FORCE_MASTER + unsigned int reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_CTRL1000); + /* force manual master/slave configuration */ + reg |= MIIM_RTL8211x_CTRL1000T_MSCE; + /* force master mode */ + reg |= MIIM_RTL8211X_CTRL1000T_MASTER; + phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg); +#endif /* read interrupt status just to clear it */ phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER); -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] net: phy: Add RTL8211X_PHY_FORCE_MASTER to Kconfig
This change mainly serves as a way to document the define. Signed-off-by: Michael Haas --- Changes in v3: None Changes in v2: None drivers/net/Kconfig | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 2a229b8..b102bc6 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -13,6 +13,23 @@ config PHYLIB help Enable Ethernet PHY (physical media interface) support. +config RTL8211X_PHY_FORCE_MASTER + bool "Ethernet PHY RTL8211x: force 1000BASE-T master mode" + depends on PHYLIB + help + Force master mode for 1000BASE-T on RTl8211x PHYs. + This is helpful for unstable gigabit links, e.g. on the + RTL8211C(L). + + If two devices force master mode, they will not be able to establish + a direct link between themselves. In this case, either: + - live with an unstable link and disable this option + - reduce link speed to 100MBit/s + - use a switch + + Does not apply to RTL8211F. + If unsure, say N. + menuconfig NETDEVICES bool "Network device support" depends on NET -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] net: phy: Force master mode for A20-Olimex-SOM-EVB
Force master mode for 1000BASE-T operation on the A20-Olimex-SOM-EVB. Karsten Merker reports that this change is necessary to get a reliable link at gigabit speeds. Signed-off-by: Michael Haas --- Changes in v3: None Changes in v2: None configs/A20-Olimex-SOM-EVB_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/A20-Olimex-SOM-EVB_defconfig b/configs/A20-Olimex-SOM-EVB_defconfig index 66d8f98..68de5f2 100644 --- a/configs/A20-Olimex-SOM-EVB_defconfig +++ b/configs/A20-Olimex-SOM-EVB_defconfig @@ -19,3 +19,4 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)" CONFIG_CMD_GPIO=y CONFIG_ETH_DESIGNWARE=y CONFIG_USB_EHCI_HCD=y +CONFIG_RTL8211X_PHY_FORCE_MASTER=y -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] net: phy: Force master mode A20-OLinuXino-Lime2
Force master mode on the A20-OLinuXino-Lime2. This change is required to get a reliable link at gigabit speeds. Signed-off-by: Michael Haas --- Changes in v3: None Changes in v2: None configs/A20-OLinuXino-Lime2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig index 95c67d6..3bd4fa7 100644 --- a/configs/A20-OLinuXino-Lime2_defconfig +++ b/configs/A20-OLinuXino-Lime2_defconfig @@ -16,3 +16,4 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)" CONFIG_CMD_GPIO=y CONFIG_ETH_DESIGNWARE=y CONFIG_USB_EHCI_HCD=y +CONFIG_RTL8211X_PHY_FORCE_MASTER=y -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] net: phy: Force master mode for RTL8211C on some boards
This patch is required to get reliable 1000BASE-T operation on some boards using the RTL8211C(L) PHY. Following discussions on v2 of this patch, I have removed the incorrect check for the RTL8211C(L). Affected boards now have to define CONFIG_RTL8211X_PHY_FORCE_MASTER to benefit from the fix. Note that this patch requires Karsten Merkers '[PATCH] net: phy: Realtek RTL8211B/C PHY ID fix' as well as Hans de Goede's recent u-boot-sunxi pull request, specifically 1eae8f66ff749409eb96e2f3f3387c56232d0b8a and fc8991c61c393ce6a9d3dfc97cb56dbbd9e8cbba. Michael Changes in v3: - Remove incorrect detection of RTL8211CL and use #ifdef instead (thanks to Karsten Merker) - Introduced constants for register bits Changes in v2: - Removed accidental inclusion of Karsten's patch in my first submission of this series. - Fix a typo in the code: 6 -> & Michael Haas (4): net: phy: Optionally force master mode for RTL PHY net: phy: Force master mode for A20-Olimex-SOM-EVB net: phy: Force master mode A20-OLinuXino-Lime2 net: phy: Add RTL8211X_PHY_FORCE_MASTER to Kconfig configs/A20-OLinuXino-Lime2_defconfig | 1 + configs/A20-Olimex-SOM-EVB_defconfig | 1 + drivers/net/Kconfig | 17 + drivers/net/phy/realtek.c | 13 - 4 files changed, 31 insertions(+), 1 deletion(-) -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: Fix gmac not working due to cpu_eth_init no longer being called
On 03/22/2016 08:24 PM, Hans de Goede wrote:
> cpu_eth_init is no longer called for dm enabled eth drivers, this
> was causing the sunxi gmac eth controller to no longer work in u-boot.
>
> This commit fixes this by calling the clock, reset and pinmux setup
> function from s_init() and enabling the phy power pin (if any) from
> board_init().
>
> The enabling of phy power cannot be done from s_init because it uses dm
> and dm is not ready yet at this point.
>
> Note that the mdelay is dropped as the phy gets enabled much earlier
> now, so it is no longer needed.
>
> Signed-off-by: Hans de Goede
> Acked-by: Ian Campbell
> Tested-by: Karsten Merker
> ---
> Changes in v2:
> -Move enabling of phy power to board_init()
> ---
> arch/arm/cpu/armv7/sunxi/board.c| 28 +---
> arch/arm/include/asm/arch-sunxi/sys_proto.h | 6 +-
> board/sunxi/board.c | 5 +
> board/sunxi/gmac.c | 14 +-
> 4 files changed, 12 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/sunxi/board.c
> b/arch/arm/cpu/armv7/sunxi/board.c
> index e80785b..7653148 100644
> --- a/arch/arm/cpu/armv7/sunxi/board.c
> +++ b/arch/arm/cpu/armv7/sunxi/board.c
> @@ -152,6 +152,7 @@ void s_init(void)
> timer_init();
> gpio_init();
> i2c_init_board();
> + eth_init_board();
> }
>
> #ifdef CONFIG_SPL_BUILD
> @@ -259,30 +260,3 @@ void enable_caches(void)
> dcache_enable();
> }
> #endif
> -
> -#ifdef CONFIG_CMD_NET
> -/*
> - * Initializes on-chip ethernet controllers.
> - * to override, implement board_eth_init()
> - */
> -int cpu_eth_init(bd_t *bis)
> -{
> - __maybe_unused int rc;
> -
> -#ifdef CONFIG_MACPWR
> - gpio_request(CONFIG_MACPWR, "macpwr");
> - gpio_direction_output(CONFIG_MACPWR, 1);
> - mdelay(200);
> -#endif
> -
> -#ifdef CONFIG_SUNXI_GMAC
> - rc = sunxi_gmac_initialize(bis);
> - if (rc < 0) {
> - printf("sunxi: failed to initialize gmac\n");
> - return rc;
> - }
> -#endif
> -
> - return 0;
> -}
> -#endif
> diff --git a/arch/arm/include/asm/arch-sunxi/sys_proto.h
> b/arch/arm/include/asm/arch-sunxi/sys_proto.h
> index 9df3744..a373319 100644
> --- a/arch/arm/include/asm/arch-sunxi/sys_proto.h
> +++ b/arch/arm/include/asm/arch-sunxi/sys_proto.h
> @@ -24,6 +24,10 @@ void sdelay(unsigned long);
> void return_to_fel(uint32_t lr, uint32_t sp);
>
> /* Board / SoC level designware gmac init */
> -int sunxi_gmac_initialize(bd_t *bis);
> +#if !defined CONFIG_SPL_BUILD && defined CONFIG_SUNXI_GMAC
> +void eth_init_board(void);
> +#else
> +static inline void eth_init_board(void) {}
> +#endif
>
> #endif
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 80eae9c..e16718f 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -90,6 +90,11 @@ int board_init(void)
> if (ret)
> return ret;
>
> +#ifdef CONFIG_MACPWR
> + gpio_request(CONFIG_MACPWR, "macpwr");
> + gpio_direction_output(CONFIG_MACPWR, 1);
> +#endif
> +
> /* Uses dm gpio code so do this here and not in i2c_init_board() */
> return soft_i2c_board_init();
> }
> diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
> index 4e222d8..69eb8ff 100644
> --- a/board/sunxi/gmac.c
> +++ b/board/sunxi/gmac.c
> @@ -6,7 +6,7 @@
> #include
> #include
>
> -int sunxi_gmac_initialize(bd_t *bis)
> +void eth_init_board(void)
> {
> int pin;
> struct sunxi_ccm_reg *const ccm =
> @@ -79,16 +79,4 @@ int sunxi_gmac_initialize(bd_t *bis)
> for (pin = SUNXI_GPA(26); pin <= SUNXI_GPA(27); pin++)
> sunxi_gpio_set_cfgpin(pin, SUN6I_GPA_GMAC);
> #endif
> -
> -#ifdef CONFIG_DM_ETH
> - return 0;
> -#else
> -# ifdef CONFIG_RGMII
> - return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_RGMII);
> -# elif defined CONFIG_GMII
> - return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_GMII);
> -# else
> - return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_MII);
> -# endif
> -#endif
> }
Tested-by: Michael Haas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
Am 22. März 2016 09:57:16 MEZ, schrieb Hans de Goede : >Hi, > >On 22-03-16 09:46, Peter Korsgaard wrote: >>> "Hans" == Hans de Goede writes: >> >> Hi, >> >> > Oh good catch, so I believe that we should submit a patch to the >u-boot >> > realtek phy driver which: >> >> > 1) Adds a seperate init function for the RTL8211C >> > 2) In that function set the force master mode bit and then >> >call the init function currently used for RTL8211C and others, >> >this assumes that the more generic init function will not >reset >> >the force master mode bit. >> >> So what happens if you connect two of these boards together without a >> switch in between? Will they be able to autonegotiate? > >Likely not, but without this fix, they would and they would have an >unreliable connection. Arguably no connection is better then an >unreliable one. > >Regards, > >Hans I assume that forcing the link to 100mbps would work for this case. After all, the fix should only apply for GBit mode. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] net: phy: Force master mode for RTL8211C
The RTL8211C found on the A20-OlinuXino-Lime2 does not word in slave
mode. This patch disables master/slave mode autonegotiation and forces
master mode.
The RTL8211C identifies itself as RTL8211B via its UID. This patch uses
the revision number taken from the PHYID2 register to distinguish the
two. The NetBSD driver uses the same approach.
CC: fra...@gmail.com
CC: mer...@debian.org
CC: hdego...@redhat.com
CC: i...@hellion.org.uk
CC: joe.hershber...@ni.com
Signed-off-by: Michael Haas
---
drivers/net/phy/realtek.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 259a87f..97d5712 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -54,6 +54,19 @@ static int rtl8211x_config(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER,
MIIM_RTL8211x_PHY_INTR_DIS);
+ int reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_PHYSID1);
+ int rev = reg & 0xf;
+ if (rev == 3 && phydev->phy_id == 0x1cc912) {
+ /* RTL8211C and RTL8211C are distinguished only by
+ their revision number */
+ reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_CTRL1000);
+ /* force manual master/slave configuration */
+ reg |= (1 << 12);
+ /* force master mode */
+ reg | = (1 << 11);
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg);
+ }
+
/* read interrupt status just to clear it */
phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER);
--
2.7.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/1] net: phy: Force master mode for RTL8211C
This patch is an RFC based on recent discussions. It's only lightly tested. I have yet to verify that the registers are being set correctly. I'm sending it out now because I have to leave for today. Note that this patch requires Karsten Merkers '[PATCH] net: phy: Realtek RTL8211B/C PHY ID fix'. Series-Version: 2 Series-changes: 2 - Removed accidental inclusion of Karsten's patch in my first submission of this series. - Fix a typo in the code: 6 -> & Michael Michael Haas (1): net: phy: Force master mode for RTL8211C drivers/net/phy/realtek.c | 13 + 1 file changed, 13 insertions(+) -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] net: phy: Force master mode for RTL8211C
On 03/22/2016 08:19 AM, Michael Haas wrote:
> The RTL8211C found on the A20-OlinuXino-Lime2 does not word in slave
> mode. This patch disables master/slave mode autonegotiation and forces
> master mode.
>
> The RTL8211C identifies itself as RTL8211B via its UID. This patch uses
> the revision number taken from the PHYID2 register to distinguish the
> two. The NetBSD driver uses the same approach.
>
> CC: fra...@gmail.com
> CC: mer...@debian.org
> CC: hdego...@redhat.com
> CC: i...@hellion.org.uk
> CC: joe.hershber...@ni.com
> Signed-off-by: Michael Haas
> ---
>
> drivers/net/phy/realtek.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index 259a87f..cdb3376 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -5,6 +5,7 @@
> *
> * Copyright 2010-2011, 2015 Freescale Semiconductor, Inc.
> * author Andy Fleming
> + * Copyright 2016 Karsten Merker
> */
> #include
> #include
> @@ -54,6 +55,19 @@ static int rtl8211x_config(struct phy_device *phydev)
> phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER,
> MIIM_RTL8211x_PHY_INTR_DIS);
>
> + int reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_PHYSID1);
> + int rev = reg & 0xf;
> + if (rev == 3 & 6 phydev->phy_id == 0x1cc912) {
> + /* RTL8211C and RTL8211C are distinguished only by
> +their revision number */
> + reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_CTRL1000);
> + /* force manual master/slave configuration */
> + reg |= (1 << 12);
> + /* force master mode */
> + reg | = (1 << 11);
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg);
> + }
> +
> /* read interrupt status just to clear it */
> phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER);
>
> @@ -223,7 +237,7 @@ static int rtl8211f_startup(struct phy_device *phydev)
> /* Support for RTL8211B PHY */
> static struct phy_driver RTL8211B_driver = {
> .name = "RealTek RTL8211B",
> - .uid = 0x1cc910,
> + .uid = 0x1cc912,
> .mask = 0xff,
> .features = PHY_GBIT_FEATURES,
> .config = &rtl8211x_config,
I have accidentally included Karsten Merkers '[PATCH] net: phy: Realtek
RTL8211B/C PHY ID fix' due to a botched call to git am earlier. I'll be
re-sending a clean version, but note that Karsten's patch is required.
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/1] net: phy: Force master mode for RTL8211C
This patch is an RFC based on recent discussions. It's only lightly tested. I have yet to verify that the registers are being set correctly. I'm sending it out now because I have to leave for today. Michael Michael Haas (1): net: phy: Force master mode for RTL8211C drivers/net/phy/realtek.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] net: phy: Force master mode for RTL8211C
The RTL8211C found on the A20-OlinuXino-Lime2 does not word in slave
mode. This patch disables master/slave mode autonegotiation and forces
master mode.
The RTL8211C identifies itself as RTL8211B via its UID. This patch uses
the revision number taken from the PHYID2 register to distinguish the
two. The NetBSD driver uses the same approach.
CC: fra...@gmail.com
CC: mer...@debian.org
CC: hdego...@redhat.com
CC: i...@hellion.org.uk
CC: joe.hershber...@ni.com
Signed-off-by: Michael Haas
---
drivers/net/phy/realtek.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 259a87f..cdb3376 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -5,6 +5,7 @@
*
* Copyright 2010-2011, 2015 Freescale Semiconductor, Inc.
* author Andy Fleming
+ * Copyright 2016 Karsten Merker
*/
#include
#include
@@ -54,6 +55,19 @@ static int rtl8211x_config(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER,
MIIM_RTL8211x_PHY_INTR_DIS);
+ int reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_PHYSID1);
+ int rev = reg & 0xf;
+ if (rev == 3 & 6 phydev->phy_id == 0x1cc912) {
+ /* RTL8211C and RTL8211C are distinguished only by
+ their revision number */
+ reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_CTRL1000);
+ /* force manual master/slave configuration */
+ reg |= (1 << 12);
+ /* force master mode */
+ reg | = (1 << 11);
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg);
+ }
+
/* read interrupt status just to clear it */
phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER);
@@ -223,7 +237,7 @@ static int rtl8211f_startup(struct phy_device *phydev)
/* Support for RTL8211B PHY */
static struct phy_driver RTL8211B_driver = {
.name = "RealTek RTL8211B",
- .uid = 0x1cc910,
+ .uid = 0x1cc912,
.mask = 0xff,
.features = PHY_GBIT_FEATURES,
.config = &rtl8211x_config,
--
2.7.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/21/2016 11:00 PM, Hans de Goede wrote: > Hi, > > On 21-03-16 22:47, Michael Haas wrote: >>> Hmm, I just realized / read that RTL8211B and RTL8211C have the same >> phyid, maybe there is some other reg which we can use to >> differentiate between them ? >> >>> Otherwise we are back to having a #ifdef for the fix ... >> >>> Regards, >> >> Hans >> >> >> The BSD people seem to key off a revision field, which has value 3 >> for the rtl8211c: >> >> https://lists.freebsd.org/pipermail/svn-src-stable-9/2015-March/007669.html >> > > And another good catch, yes that looks like it should work. > > Now all we need to do is turn all this info into a proper patch. > > Regards, > > Hans I'm going to work on that. I'd like to have the bragging rights for having a patch in Das U-Boot :) Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
>Hmm, I just realized / read that RTL8211B and RTL8211C have the same phyid, maybe there is some other reg which we can use to differentiate between them ? >Otherwise we are back to having a #ifdef for the fix ... >Regards, Hans The BSD people seem to key off a revision field, which has value 3 for the rtl8211c: https://lists.freebsd.org/pipermail/svn-src-stable-9/2015-March/007669.html Excuse the bad quoting, I am on mobile and the client is broken. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/21/2016 04:47 PM, Karsten Merker wrote:
Are any other sunxi boards impacted by the same problem that you know ?
>>> No, I don't know of any other boards, but I have not looked very hard :)
> At least the Olimex A20-SOM-EVB (which uses the same RTL8211CL
> PHY) has the same issue and forcing master mode helps there as
> well. With the above change added on top of v2016.01, I can
> successfully boot via tftp on a gigabit link on both the Lime2
> and the A20-SOM-EVB, which was impossible before.
Great news!
>
> Some quick iperf measurements on the A20-SOM-EVB with the patch
> applied show network throughput comparable to what I get with
> other A20-based systems.
>
> All my other A20-based boards - which don't have problems on
> gigabit links - use an RTL8211E instead of the RTL8211CL. I had
> been looking into the source of the gigabit problems on the
> A20-SOM-EVB for a while already and talked with Olimex about
> them. Olimex has also been trying to debug the issue and told me
> that the problem doesn't seem to occur on all boards, and that
> during their tests different RTL8211CL chips (i.e. same chip
> model, but with different production date codes) behaved
> differently. This would fit into the hypothesis that there might
> be some kind of erratum in at least some series of the RTL8211CL.
>
>
So, Olimex knows about these issues? :/ Perhaps you can CC your contact
there once we have a final patch.
By the way, I just searched the web for "rtl8211c master mode" and found
this [0]:
---%--
// The EVK board with RTL8211C requires this sequence per information
// Realtek.
// 1. Register 0x1F, write 0005 -> Page 5
// 2. Register 0x0C, write
// 3. Register 0x01, change bit [7] to 1
// 4. Register 0x1F, write -> Page 0
// However, please note that it is not recommended to use the RTL8211CL
125MHz clock output because
// it is not stable when link at Slave mode. If you need the clock
output,
// please consider using RTL8211E instead.
// 5. Force manual "master" mode in auto-negotiation.
#if defined(CONFIG_DIGICOLOR_MAINBOARD_THUNDERBOLT_REV1)
if (!RTL8211C_hack) {
// Enable 125 Mhz clock output
gmac_mdio_write(ei, phy_id, 0x1f, 5);
gmac_mdio_write(ei, phy_id, 0x0c, 0);
gmac_mdio_read (ei, phy_id, 0x01, &data);
data |= 0x80;
gmac_mdio_write(ei, phy_id, 0x01, data);
gmac_mdio_write(ei, phy_id, 0x1f, 0);
// Set Manual MASTER Mode
gmac_mdio_read (ei, phy_id, 0x09, &data);
data |= 0x1800;
gmac_mdio_write(ei, phy_id, 0x09, data);
// Restart Autonegotiation
gmac_mdio_read (ei, phy_id, 0x00, &data);
data |= 0x0200;
gmac_mdio_write(ei, phy_id, 0x00, data);
// All done now.
RTL8211C_hack = 1;
}
#endif
%---
I guess we are not the first to find this out the hard way. If the issue
is related to an internal clock of the RTL8211C, is there perhaps an
external clock we can use?
[0]
http://mydc-proj.googlecode.com/svn/trunk/linux/target/u-boot/2010.09-cnxt/board/cnxt/common/gmac_hal.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Linux hangs due to commit v2015.10-15-g02cc27c on loading i2c-mv64xx
Hello all, I'm running Debian Jessie with Linux 4.3.0-0.bpo.1-armmp-lpae on my a20-olinuxino-lime2. I have noticed that my board hangs with my recent u-boot versions when I load the i2c module. git-bisect narrowed the problem down to the following commit: 02cc27c74f9b884b538bcd1b93342a4c05b5d608 is the first bad commit commit 02cc27c74f9b884b538bcd1b93342a4c05b5d608 Author: Hans de Goede Date: Sat Oct 3 15:29:24 2015 +0200 sunxi: power: Change axp209 LDO3 and LDO4 default to disabled LDO3 and LDO4 are normally either unused, or used to power csi attached camera sensors, and as such do not need to be enabled at boot time. Signed-off-by: Hans de Goede Acked-by: Ian Campbell :04 04 9ff2e54e613a4386473cdf66c3bc5dc830a31bc7 d5330c13ef2c86643499f476b7042748969fd523 MT>drivers The axp209 is attached to the i2c bus, so that is likely the real culprit. In my setup, the axp209 drivers are loaded before I insert i2c-mv64xxx. What would be the best course of action here? * Revert the commit * Enable LDO3 and LDO4 for the a20-olinuxino-lime2 only? * Fix linux Best, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/20/2016 02:45 PM, Hans de Goede wrote:
> Hi,
>
> On 19-03-16 14:40, Michael Haas wrote:
>> On 03/19/2016 10:32 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 19-03-16 09:39, François-David Collin wrote:
>>>> Hi,
>>>>
>>>> As I’m banging my head on this too, please allow me to provide some
>>>> details
>>>> I got two stable situations :
>>>> The Lime2 is connected directly to the Gbit interface of my laptop,
>>>> speed are OK:
>>>
>>> Michael Haas' work to debug this by looking at the phy registers
>>> seems to be the most promising so-far, the clk reg and axp209
>>> registers all seem to be identical between good and bad setups.
>>>
>>> Can you try to:
>>>
>>> 1) Stop the boot in u-boot (press a key on the serial console)
>>> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
>>> to tftp
>>> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>>>
>>> Regards,
>>>
>>> Hans
>>
>> Hi all,
>>
>> i have diffed and cross-compared logs of several working and broken tftp
>> downloads. The most significant
>> difference between working and broken was registers 0xa, 0x1c and 0x2a
>> in the first MII page.
>>
>> These registers started making sense when I looked at the datasheet for
>> the RTL8211CL. Previously, I was looking at the RTL8211E.
>>
>> 0xA was set to 7800 for working runs and 3800 for broken runs. The
>> difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
>> Resolution'. In the broken runs, the autonegotation configured the
>> OlinuXino to 'slave'. I have whipped up a quick patch which disable the
>> master/slave part of the autonegotiation and force master mode.
>>
>> The patch itself is quite terrible as it's forcing the master mode bits
>> for every phy, not just for the RTL8211CL. It's good enough for testing,
>> however, and I seem to be getting consistent download speeds. There are
>> occasional hangs when booting the downloaded kernel, but that is
>> probably a different issue.
>>
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index 51b5746..484b2be 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
>> int genphy_config_aneg(struct phy_device *phydev)
>> {
>> int result;
>> + phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
>>
>> if (AUTONEG_ENABLE != phydev->autoneg)
>> return genphy_setup_forced(phydev);
>>
>> Please test this change and let me know. If it's successful, I will
>> submit a proper version.
>
> Good catch, I wonder why we need this. I believe that the proper version
> should probably be wrapped in a #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER
> and then add a Kconfig option for this (and enable it in the lime2
> defconfig), forcing this on all rtl8211cl phy-s seems wrong, unless
> someone can dig up an errata from realtek which said we should.
I was going to add that in realtek.c, not in phy.c - as soon as I figure
out which section there is applicable. I have started a new thread
asking about that.
>
> Are any other sunxi boards impacted by the same problem that you know ?
>
No, I don't know of any other boards, but I have not looked very hard :)
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/18/2016 08:06 PM, Michael Haas wrote: > On 03/18/2016 08:02 PM, Karsten Merker wrote: >> The installer supports a number of systems that can only load images >> of limited size, therefore the installer includes only an >> installation-related subset of all the kernel modules and i2c-mv64xxx >> currently isn't among those. This hasn't been a practical problem up >> to now, but being able to talk to the pmic is indeed something that >> should be possible even in the installer. I'll try to address that in >> the next days. Regards, Karsten > Just an anecdote: I loaded i2c-mv64xx.ko which I had extracted from the > deb and the olinuxino locked up. Just for the record: loading i2c-mv64xx.ko reproducibly hangs my Debian Jessie install with the 4.3.0-0.bpo.1-armmp-lpae kernel. This happens only on u-boot 2016.01; both Debian stable 2014.10 and my own build of 2016.03 + patches work fine! So no problem since it's fixed on newer builds. Just a note for those playing along at home and wondering why their olinuxino does not come up anymore with 2016.01. > > So now I'm trying to reproduce broken GBit, which is harder than > expected. I managed to do it once right after the lockup in u-boot: tftp > was slow and ran into timeouts. Then I typed 'reset' in the u-boot > shell. u-boot started again and GBit was working again. > > Weird. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/17/2016 11:52 AM, Hans de Goede wrote: > > 3) The phy settings, unfortunately I do not know of > a way to dump these, so lets just forget about these > and focus on the other 2. > You can dump these with 'mii read' in u-boot. I sat down with the rtl8211eg data sheet and decided to look at 'PHYCR (PHY Specific Control Register, Address 0x10)' and 'PHYSR (PHY Specific Status Register, Address 0x11)'. There is no difference at 0x10 between working and broken. There are some changed bits in reserved areas in 0x11: Bad: => mii read 1 0x10 01EE => mii read 1 0x11 AD5C # 1010 1101 0101 1100 Good: => mii read 1 0x10 01EE => mii read 1 0x11 BDDC # 1011 1101 1101 1100 Good #2: => mii read 1 0x11 BD5C # 1011 1101 0101 1100 I haven't yet looked at other registers. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Which entry in drivers/net/phy/realtek.c matches my device?
Hello all, I'd like to add some device-specific hacks to realtek.c. I'm using the Olimex A20-OlinuXino-Lime2 which uses the RTL8211CL PHY. Which of the various phy_driver structs is responsible for that device? I presume it's keyed off the .uid, but I'm not sure how to find the ID of the specific PHY used on my device. Thanks! Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
Hello all, After the board locked up, I am now working exclusively from within u-boot. Occasionally, gbit will work well. At other times, it will appear to work well but the kernel won't boot. And sometimes, downloading a kernel will just time-out. A reset is often enough to get a behavior change. In my earlier post, I noted that it's hard for me now to get broken gbit: I've since then also had spurs where five resets in a row did not work. On 03/17/2016 11:52 AM, Hans de Goede wrote: > There are 3 things which would be interesting to save and compare > with a boot which does have the problem: > > ./mmio-dump 0x1c20164 > > I have used the u-boot 'md' command here. Between a completely broken (timeouts) and working (at least a finished download), there is no change: Working: => md 0x1c20164 01c20164: 0c06 Broken: md 0x1c20164 01c20164: 0c06 > > 2) The pmic settings for various ldo-s, etc. as root run: > > i2cdump -f -y 0 0x34 > > I used the i2c md command here to get several dumps: Working 1: => i2c md 0x34 0 0xff : c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00...A 0010: 01 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 1c 00 00 00 16 cf 54 00 00 00 00 00 00.T.. 0030: 60 03 42 c9 45 22 9d 08 a5 1f 68 5f fc 16 00 00`.B.E"h_ 0040: 00 00 00 00 00 00 00 00 40 40 00 00 00 00 00 00@@.. 0050: 09 0a 00 00 00 00 00 00 00 00 00 00 00 00 6d 0f..m. 0060: db 07 3e 08 00 00 00 00 00 00 00 00 00 00 00 00..>. 0070: 00 00 00 00 00 00 00 00 1a 03 00 00 00 00 db 08 0080: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 212..! 0090: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00 00a0: 00 00 00 00 00 00 00 00 08 00 00 00 00 00 db 06 00b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00 00c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63$.5=IT\c 00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00A.. Working 2: => i2c md 0x34 0 0xff : c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00...A 0010: 01 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 1c 00 00 00 16 cf 54 00 00 00 00 00 00.T.. 0030: 60 03 42 c9 45 22 9d 08 a5 1f 68 5f fc 16 00 00`.B.E"h_ 0040: 00 00 00 00 00 00 00 00 40 40 00 00 00 00 00 00@@.. 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 0f..m. 0060: db 0c 3e 08 00 00 00 00 00 00 00 00 00 00 00 00..>. 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 db 08 0080: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 212..! 0090: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dc 00 00b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00 00c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63$.5=IT\c 00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00A.. Broken 1: => i2c md 0x34 0 0xff : c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00...A 0010: 01 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 1c 00 00 00 16 cf 54 00 00 00 00 00 00.T.. 0030: 60 03 42 c9 45 22 9d 08 a5 1f 68 5f fc 16 00 00`.B.E"h_ 0040: 00 00 00 00 00 00 00 00 40 40 00 00 00 00 00 00@@.. 0050: 22 06 00 00 00 00 00 00 00 00 00 00 00 00 6e 04".n. 0060: db 0a 3e 08 00 00 00 00 00 00 00 00 00 00 00 00..>. 0070: 00 00 00 00 00 00 00 00 03 08 00 00 00 00 db 08 0080: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 212..! 0090: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00 00a0: 00 00 00 00 00 00 00 00 20 08 00 00 00 00 db 09 ... 00b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00 00c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63$.5=IT\c 00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00A.. Broken 2: => i2c md 0x34 0 0xff : c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00...A 0010: 01 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 1c 00 00 00 16 cf 54 00 00 00 00 00 00.
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/19/2016 10:32 AM, Hans de Goede wrote:
> Hi,
>
> On 19-03-16 09:39, François-David Collin wrote:
>> Hi,
>>
>> As I’m banging my head on this too, please allow me to provide some
>> details
>> I got two stable situations :
>> The Lime2 is connected directly to the Gbit interface of my laptop,
>> speed are OK:
>
> Michael Haas' work to debug this by looking at the phy registers
> seems to be the most promising so-far, the clk reg and axp209
> registers all seem to be identical between good and bad setups.
>
> Can you try to:
>
> 1) Stop the boot in u-boot (press a key on the serial console)
> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
> to tftp
> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>
> Regards,
>
> Hans
Hi all,
i have diffed and cross-compared logs of several working and broken tftp
downloads. The most significant
difference between working and broken was registers 0xa, 0x1c and 0x2a
in the first MII page.
These registers started making sense when I looked at the datasheet for
the RTL8211CL. Previously, I was looking at the RTL8211E.
0xA was set to 7800 for working runs and 3800 for broken runs. The
difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
Resolution'. In the broken runs, the autonegotation configured the
OlinuXino to 'slave'. I have whipped up a quick patch which disable the
master/slave part of the autonegotiation and force master mode.
The patch itself is quite terrible as it's forcing the master mode bits
for every phy, not just for the RTL8211CL. It's good enough for testing,
however, and I seem to be getting consistent download speeds. There are
occasional hangs when booting the downloaded kernel, but that is
probably a different issue.
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 51b5746..484b2be 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
int genphy_config_aneg(struct phy_device *phydev)
{
int result;
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
if (AUTONEG_ENABLE != phydev->autoneg)
return genphy_setup_forced(phydev);
Please test this change and let me know. If it's successful, I will
submit a proper version.
Best
Michael
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
Hello all, On 03/16/2016 09:36 PM, Karsten Merker wrote: > Michael, if you would like to try testing higher RX delay chain values > on the Lime2, I have attached a small patch that adds an appropriate > Kconfig option. Regards, Karsten I will be testing your patch along with Hans' patch. In fact, I have already compiled it - I'm just waiting for a new SD card reader to arrive tomorrow. Sorry for the delay. In the mean time, as I was trying to get the device to boot at all (not related to u-boot, just my broken sdcard setup), I did try my old SD card again to load the debian netinstaller. This should be the version with the TX_DELAY set to 4. Now I'm sitting in an ash shell and I can wget files from my desktop at around 100MB/s. ~ # wget http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O - | md5sum Connecting to 192.168.1.170:8000 (192.168.1.170:8000) -100% |***| 315M 0:00:00 ETA 37f329724a1c072cbe0ebda211fdeb88 - ~ # wget http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O - | md5sum Connecting to 192.168.1.170:8000 (192.168.1.170:8000) -100% |***| 315M 0:00:00 ETA 37f329724a1c072cbe0ebda211fdeb88 - ~ # date +%s; wget http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O /d ev/null; date +%s 1258 Connecting to 192.168.1.170:8000 (192.168.1.170:8000) null 100% |***| 315M 0:00:00 ETA 1261 ~ # dmesg | grep -i link [1.504918] audit: initializing netlink subsys (disabled) [ 88.561822] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 90.547368] sun7i-dwmac 1c5.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 90.547424] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready ~ # cat /etc/lsb-release DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="9 (stretch) - installer build 20160316-00:13" X_INSTALLATION_MEDIUM=netboot ~ # uname -a Linux debian 4.4.0-1-armmp #1 SMP Debian 4.4.4-2 (2016-03-09) armv7l GNU/Linux It takes around three seconds (date +%s; time not set) to transfer the 315MB. The md5sum matches. Now, with the device sitting on my desk in a debian installer session and working gbit.. how do I proceed from here? I don't dare rebooting.. Best Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/19/2016 10:32 AM, Hans de Goede wrote: > Hi, > > On 19-03-16 09:39, François-David Collin wrote: >> Hi, >> >> As I’m banging my head on this too, please allow me to provide some >> details >> I got two stable situations : >> The Lime2 is connected directly to the Gbit interface of my laptop, >> speed are OK: > > Michael Haas' work to debug this by looking at the phy registers > seems to be the most promising so-far, the clk reg and axp209 > registers all seem to be identical between good and bad setups. > > Can you try to: > > 1) Stop the boot in u-boot (press a key on the serial console) > 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries > to tftp > 3) Do: "mii read 1 0x11" in u-boot and record the output ? > > Regards, > > Hans I'm attaching four files, two with tftp timeouts and two with a successful boot. The -miipages files include mii pages 0 to 7, but not extpages. broken.dump Description: Binary data broken-miipages.dump Description: Binary data working.dump Description: Binary data working-miipages.dump Description: Binary data signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/19/2016 10:32 AM, Hans de Goede wrote:
> Hi,
>
> On 19-03-16 09:39, François-David Collin wrote:
>> Hi,
>>
>> As I’m banging my head on this too, please allow me to provide some
>> details
>> I got two stable situations :
>> The Lime2 is connected directly to the Gbit interface of my laptop,
>> speed are OK:
>
> Michael Haas' work to debug this by looking at the phy registers
> seems to be the most promising so-far, the clk reg and axp209
> registers all seem to be identical between good and bad setups.
>
> Can you try to:
>
> 1) Stop the boot in u-boot (press a key on the serial console)
> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
> to tftp
> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>
> Regards,
>
> Hans
I am currently (as I write this email) looking at the full set of
registers for the PHY, including the additional
pages:
setenv miipagedump 'for page in 0x0 0x01 0x02 0x03 0x04 0x05 0x06 0x07;
do echo "page $page"; mii write 1 0x1f $page; run miidump; done; mii
write 1 0x1f 0x00'
setenv miireadable 'setenv x 0x0; while test $x -le 5; do echo $x; mii
dump 1 $x; setexpr x $x + 1; done'
setenv miidump 'setenv x 0x0; while test $x -le 31; do echo $x; mii read
1 $x; setexpr x $x + 1; done'
setenv pmicdump 'i2c md 0x34 0xff'
setenv clkdump 'md 0x1c20164'
setenv doboot 'run pmicdump; run clkdump; setenv bootargs
console=ttyS0,115200 rootwait panic=10; setenv autoload no;dhcp; run
miireadable; run miipagedump; setenv serverip 192.168.1.170;tftpboot
${scriptaddr} /debian-installer/armhf/tftpboot.scr;source ${scriptaddr}'
No results as of yet, but I have yet to do a run where I successfully
dump all extpages.. the script was off before hand. Some registers were
different between working and non-working runs, but these were mostly
reserved. I will be posting a full log later on.
Interesting: 01c20224 is 14888022 for broken runs and 14888021 on
working runs - but I have not verified this extensively.
I'm hanging out as 'laga' in #u-boot.
Michael
Another
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/17/2016 11:52 AM, Hans de Goede wrote: > Hi, > > There are 3 things which would be interesting to save and compare > with a boot which does have the problem: > > 1) The gmc clk register, to do this download mmio_dump from: > > Working GBit: 01c20164: 0c06 Broken GBit: tomorrow :) > > 2) The pmic settings for various ldo-s, etc. as root run: > > i2cdump -f -y 0 0x34 > And record the output. You may need to > install i2c-tools (or the deb. alternative) and > do "modprobe i2c_dev" > I had to download the Debian kernel package on another box, extract the .ko, transfer and insmod it. Now I'm getting: ~ # /mnt/usr/sbin/i2cdump -f -y 0 0x34 No size specified (using byte-data access) Error: Could not open file `/dev/i2c-0': No such device I did mknod the devices, but I'm getting the same error msg: ~ # ls -al /dev/i2c-* crw-r--r--1 root root 89, 0 Mar 17 21:31 /dev/i2c-0 crw-r--r--1 root root 89, 1 Mar 17 21:31 /dev/i2c-1 ~ # Module Size Used by i2c_dev 7087 0 i2c_sun6i_p2wi 3664 0 dm_mod 98419 0 md_mod121938 0 jfs 175313 0 crc32c_generic 1862 1 btrfs1068047 0 xor 4846 1 btrfs zlib_deflate 20354 1 btrfs raid6_pq 87885 1 btrfs vfat 10249 0 fat55086 1 vfat ext4 552524 2 crc16 1274 1 ext4 mbcache 9623 1 ext4 jbd2 96157 1 ext4 usb_storage45523 0 ahci_sunxi 2851 0 libahci_platform6430 1 ahci_sunxi libahci23066 2 libahci_platform,ahci_sunxi libata182871 3 libahci,libahci_platform,ahci_sunxi scsi_mod 188073 2 usb_storage,libata realtek 2711 0 dwmac_sunxi 2431 0 stmmac_platform 3302 1 dwmac_sunxi stmmac 74687 3 stmmac_platform,dwmac_sunxi ohci_platform 4658 0 ohci_hcd 38045 1 ohci_platform ehci_platform 5398 0 ehci_hcd 63999 1 ehci_platform usbcore 190581 5 usb_storage,ohci_platform,ohci_hcd,ehci_hcd,ehci_platform usb_common 3195 1 usbcore phy_sun4i_usb 7858 8 extcon 10436 1 phy_sun4i_usb sunxi_mmc 11288 0 leds_gpio 3606 0 I also loaded i2c_sun6i_p2wi for good measure. Any idea what's missing here? > 3) The phy settings, unfortunately I do not know of > a way to dump these, so lets just forget about these > and focus on the other 2. > I might even look at the data sheet tomorrow if time permits. Michael signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/18/2016 08:02 PM, Karsten Merker wrote: > The installer supports a number of systems that can only load images > of limited size, therefore the installer includes only an > installation-related subset of all the kernel modules and i2c-mv64xxx > currently isn't among those. This hasn't been a practical problem up > to now, but being able to talk to the pmic is indeed something that > should be possible even in the installer. I'll try to address that in > the next days. Regards, Karsten Just an anecdote: I loaded i2c-mv64xx.ko which I had extracted from the deb and the olinuxino locked up. So now I'm trying to reproduce broken GBit, which is harder than expected. I managed to do it once right after the lockup in u-boot: tftp was slow and ran into timeouts. Then I typed 'reset' in the u-boot shell. u-boot started again and GBit was working again. Weird. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
On 03/15/2016 07:09 PM, Karsten Merker wrote:
> On Tue, Mar 15, 2016 at 06:41:39AM +0100, Michael Haas wrote:
>
>> This change is required to get GBIT Ethernet to work
>> reliably on my board. Without CONFIG_GMAC_TX_DELAY=4, the connection
>> suffers severe packet loss and SSH becomes unusable.
>>
>> --- 192.168.1.1 ping statistics ---
>> 100 packets transmitted, 100 received, 0% packet loss, time 19842ms
>> rtt min/avg/max/mdev = 0.260/0.334/0.527/0.038 ms
>>
>> I have also tried CONFIG_GMAC_TX_DELAY=3, which still
>> yielded 11-13% packet loss.
> Hello,
>
> unfortunately this change doesn't solve the gigabit issues
> on my LIME2 - it even seems to make them worse on my board.
>
>
> Could you perhaps try netbooting a kernel with your LIME2?
> I would be interested in knowing whether that works on your
> board (with CONFIG_GMAC_TX_DELAY=0/4).
>
>
Hello Karsten,
I just tried netbooting the debian installer: it didn't work, just as
you said.
Even worse: I noticed I had not installed my patched u-boot at all when
I ran the ping test above! With my patch, the kernel would not download
at all.
So the patch is wrong and I'm sorry for having wasted everyone's time here.
I won't give up yet, however. The fact still stands that at some point,
I was able to use GBit Ethernet
without any issues in Linux, possibly after a warm reboot.
For (my) future reference, I used these commands:
--
setenv bootargs console=ttyS0,115200 rootwait panic=10
setenv autoload no
dhcp
setenv serverip 192.168.1.170
tftpboot ${scriptaddr} /debian-installer/armhf/tftpboot.scr
source ${scriptaddr}
--
I'll be playing around with the value a bit more to find the "best"
value for netbooting from a cold state, then try to get it
to work within Linux itself. Perhaps there are also some clock adjusts
to be done from within the DTS.
Sorry again!
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
This change is required to get GBIT Ethernet to work reliably on my board. Without CONFIG_GMAC_TX_DELAY=4, the connection suffers severe packet loss and SSH becomes unusable. --- 192.168.1.1 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19842ms rtt min/avg/max/mdev = 0.260/0.334/0.527/0.038 ms I have also tried CONFIG_GMAC_TX_DELAY=3, which still yielded 11-13% packet loss. It's quite possible that A20-OLinuXino-Lime_defconfig also requires this change, but I do not have a board for testing. I have tested this change on u-boot 2016.01. Signed-off-by: Michael Haas Tested-by: Michael Haas Cc: i...@hellion.org.uk Cc: hdego...@redhat.com --- configs/A20-OLinuXino-Lime2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig index b5181c6..f75b191 100644 --- a/configs/A20-OLinuXino-Lime2_defconfig +++ b/configs/A20-OLinuXino-Lime2_defconfig @@ -15,3 +15,4 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)" CONFIG_CMD_GPIO=y CONFIG_ETH_DESIGNWARE=y CONFIG_USB_EHCI_HCD=y +CONFIG_GMAC_TX_DELAY=4 -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
