U-Boot atheros PHY support and cubox ethernet
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
-- Tom
Reverting 4346df3392c0 makes your interface work? What is the DTS path that your hummingboard uses?
Thanks, -Vladimir
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
-- Tom
Reverting 4346df3392c0 makes your interface work?
Yup.
What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /* * This is not a perfect match. Avoid dependency on the DM GPIO driver * needed * for accurate board detection. Hummingboard2 DT is good enough for * U-Boot on * all Hummingboard/Cubox-i platforms. */ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But the board really is the original hummingboard platform. Thanks!
On Tue, 16 Jun 2020 at 23:10, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
-- Tom
Reverting 4346df3392c0 makes your interface work?
Yup.
What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /*
- This is not a perfect match. Avoid dependency on the DM GPIO driver
- needed
- for accurate board detection. Hummingboard2 DT is good enough for
- U-Boot on
- all Hummingboard/Cubox-i platforms.
*/ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But the board really is the original hummingboard platform. Thanks!
-- Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L12...
-Vladimir
On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:10, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
-- Tom
Reverting 4346df3392c0 makes your interface work?
Yup.
What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /*
- This is not a perfect match. Avoid dependency on the DM GPIO driver
- needed
- for accurate board detection. Hummingboard2 DT is good enough for
- U-Boot on
- all Hummingboard/Cubox-i platforms.
*/ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But the board really is the original hummingboard platform. Thanks!
-- Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L12...
No change. And to be clear, I bisect'd the issue down and at that commit, reverting it fixes ethernet. It doesn't revert cleanly (nor obviously to me) on master.
On Tue, 16 Jun 2020 at 23:31, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:10, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
-- Tom
Reverting 4346df3392c0 makes your interface work?
Yup.
What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /*
- This is not a perfect match. Avoid dependency on the DM GPIO driver
- needed
- for accurate board detection. Hummingboard2 DT is good enough for
- U-Boot on
- all Hummingboard/Cubox-i platforms.
*/ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But the board really is the original hummingboard platform. Thanks!
-- Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L12...
No change. And to be clear, I bisect'd the issue down and at that commit, reverting it fixes ethernet. It doesn't revert cleanly (nor obviously to me) on master.
-- Tom
On master, the revert would look like this:
diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c index 13f7275d1706..5ba639e8119f 100644 --- a/drivers/net/phy/atheros.c +++ b/drivers/net/phy/atheros.c @@ -124,6 +124,7 @@ static int ar8021_config(struct phy_device *phydev)
static int ar803x_delay_config(struct phy_device *phydev) { + int regval; int ret;
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID || @@ -138,6 +139,10 @@ static int ar803x_delay_config(struct phy_device *phydev) else ret = ar803x_enable_rx_delay(phydev, false);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05); + regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e); + phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100)); + return ret; }
The next thing to check is to print the value of phydev->interface there. 7 is PHY_INTERFACE_MODE_RGMII, 8 is PHY_INTERFACE_MODE_RGMII_ID, 9 is PHY_INTERFACE_MODE_RGMII_RXID, 10 is PHY_INTERFACE_MODE_RGMII_TXID,
You want it to be 8.
Thanks, -Vladimir
On Tue, Jun 16, 2020 at 11:37:17PM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:31, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:10, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
-- Tom
Reverting 4346df3392c0 makes your interface work?
Yup.
What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /*
- This is not a perfect match. Avoid dependency on the DM GPIO driver
- needed
- for accurate board detection. Hummingboard2 DT is good enough for
- U-Boot on
- all Hummingboard/Cubox-i platforms.
*/ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But the board really is the original hummingboard platform. Thanks!
-- Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L12...
No change. And to be clear, I bisect'd the issue down and at that commit, reverting it fixes ethernet. It doesn't revert cleanly (nor obviously to me) on master.
-- Tom
On master, the revert would look like this:
diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c index 13f7275d1706..5ba639e8119f 100644 --- a/drivers/net/phy/atheros.c +++ b/drivers/net/phy/atheros.c @@ -124,6 +124,7 @@ static int ar8021_config(struct phy_device *phydev)
static int ar803x_delay_config(struct phy_device *phydev) {
int regval; int ret; if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||@@ -138,6 +139,10 @@ static int ar803x_delay_config(struct phy_device *phydev) else ret = ar803x_enable_rx_delay(phydev, false);
phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));return ret;}
This alone is not enough.
The next thing to check is to print the value of phydev->interface there. 7 is PHY_INTERFACE_MODE_RGMII, 8 is PHY_INTERFACE_MODE_RGMII_ID, 9 is PHY_INTERFACE_MODE_RGMII_RXID, 10 is PHY_INTERFACE_MODE_RGMII_TXID,
With only this patch, it's 7. With this added to mx6cuboxi.c: - phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII); + phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII_ID); it's 8, and doesn't work either. Moving on to the next emails now.
On Wed, 17 Jun 2020 at 00:35, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 11:37:17PM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:31, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:10, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote: > > Hey all, > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually > configurable for AR8035") we brought in changes to get in to line with > upstream linux kernel support for this PHY and in turn deal with more > "driver was wrong, DT was wrong too" changes. Now the problem I have is > that ethernet on my Hummingboard doesn't work AND as far as I can tell, > the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It > also looks to match what's in v5.7 for the kernel. What do I need to do > here next? Thanks! > > -- > Tom
Reverting 4346df3392c0 makes your interface work?
Yup.
What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /*
- This is not a perfect match. Avoid dependency on the DM GPIO driver
- needed
- for accurate board detection. Hummingboard2 DT is good enough for
- U-Boot on
- all Hummingboard/Cubox-i platforms.
*/ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But the board really is the original hummingboard platform. Thanks!
-- Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L12...
No change. And to be clear, I bisect'd the issue down and at that commit, reverting it fixes ethernet. It doesn't revert cleanly (nor obviously to me) on master.
-- Tom
On master, the revert would look like this:
diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c index 13f7275d1706..5ba639e8119f 100644 --- a/drivers/net/phy/atheros.c +++ b/drivers/net/phy/atheros.c @@ -124,6 +124,7 @@ static int ar8021_config(struct phy_device *phydev)
static int ar803x_delay_config(struct phy_device *phydev) {
int regval; int ret; if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||@@ -138,6 +139,10 @@ static int ar803x_delay_config(struct phy_device *phydev) else ret = ar803x_enable_rx_delay(phydev, false);
phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));return ret;}
This alone is not enough.
So if this is not enough, then I'd go back to bisecting. I'd rebase right after 8737c65fe4e3 ("phy: atheros: consolidate {ar8031|ar8035}_config()"), create a new patch on board/solidrun/mx6cuboxi/mx6cuboxi.c which changes RGMII to RGMII_ID, confirm it works (according to what you've said so far, it should), then bless it as "git bisect good", and let the fun start :)
Am 2020-06-16 23:57, schrieb Vladimir Oltean:
On Wed, 17 Jun 2020 at 00:35, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 11:37:17PM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:31, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:10, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote: > Hi Tom, > > On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote: > > > > Hey all, > > > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually > > configurable for AR8035") we brought in changes to get in to line with > > upstream linux kernel support for this PHY and in turn deal with more > > "driver was wrong, DT was wrong too" changes. Now the problem I have is > > that ethernet on my Hummingboard doesn't work AND as far as I can tell, > > the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It > > also looks to match what's in v5.7 for the kernel. What do I need to do > > here next? Thanks! > > > > -- > > Tom > > Reverting 4346df3392c0 makes your interface work?
Yup.
> What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /*
- This is not a perfect match. Avoid dependency on the DM GPIO driver
- needed
- for accurate board detection. Hummingboard2 DT is good enough for
- U-Boot on
- all Hummingboard/Cubox-i platforms.
*/ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But the board really is the original hummingboard platform. Thanks!
-- Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L12...
No change. And to be clear, I bisect'd the issue down and at that commit, reverting it fixes ethernet. It doesn't revert cleanly (nor obviously to me) on master.
-- Tom
On master, the revert would look like this:
diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c index 13f7275d1706..5ba639e8119f 100644 --- a/drivers/net/phy/atheros.c +++ b/drivers/net/phy/atheros.c @@ -124,6 +124,7 @@ static int ar8021_config(struct phy_device *phydev)
static int ar803x_delay_config(struct phy_device *phydev) {
int regval; int ret; if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||@@ -138,6 +139,10 @@ static int ar803x_delay_config(struct phy_device *phydev) else ret = ar803x_enable_rx_delay(phydev, false);
phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));return ret;}
This alone is not enough.
So if this is not enough, then I'd go back to bisecting. I'd rebase right after 8737c65fe4e3 ("phy: atheros: consolidate {ar8031|ar8035}_config()"), create a new patch on board/solidrun/mx6cuboxi/mx6cuboxi.c which changes RGMII to RGMII_ID, confirm it works (according to what you've said so far, it should), then bless it as "git bisect good", and let the fun start :)
If these are the correct schematics, it looks like you also need the rgmii clock: https://developer.solid-run.com/download/i-mx6-som-simplified-schematics-rev...
https://gitlab.denx.de/u-boot/u-boot/-/commit/6333cbb3817ed551cd7d4e92f7359c...
So I guess you'd need both, the clock output and the correct RGMII pad delay.
-michael
Am 16. Juni 2020 22:21:08 MESZ schrieb Vladimir Oltean olteanv@gmail.com:
On Tue, 16 Jun 2020 at 23:10, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays
actually
configurable for AR8035") we brought in changes to get in to line
with
upstream linux kernel support for this PHY and in turn deal with
more
"driver was wrong, DT was wrong too" changes. Now the problem I
have is
that ethernet on my Hummingboard doesn't work AND as far as I can
tell,
the DTB is correct and saying phy-mode = "rgmii-id" now not
"rgmii". It
also looks to match what's in v5.7 for the kernel. What do I
need to do
here next? Thanks!
-- Tom
Reverting 4346df3392c0 makes your interface work?
Yup.
What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /*
- This is not a perfect match. Avoid dependency on the DM GPIO
driver
- needed
- for accurate board detection. Hummingboard2 DT is good enough for
- U-Boot on
- all Hummingboard/Cubox-i platforms.
*/ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base.
But
the board really is the original hummingboard platform. Thanks!
-- Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L12...
it should be PHY_INTERFACE_MODE_RGMII_TXID to get the original behavior, shouldn't it? The commit in question only removes the hardcoded TX delay.
-michael
On Tue, Jun 16, 2020 at 11:30:00PM +0200, Michael Walle wrote:
Am 16. Juni 2020 22:21:08 MESZ schrieb Vladimir Oltean olteanv@gmail.com:
On Tue, 16 Jun 2020 at 23:10, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays
actually
configurable for AR8035") we brought in changes to get in to line
with
upstream linux kernel support for this PHY and in turn deal with
more
"driver was wrong, DT was wrong too" changes. Now the problem I
have is
that ethernet on my Hummingboard doesn't work AND as far as I can
tell,
the DTB is correct and saying phy-mode = "rgmii-id" now not
"rgmii". It
also looks to match what's in v5.7 for the kernel. What do I
need to do
here next? Thanks!
-- Tom
Reverting 4346df3392c0 makes your interface work?
Yup.
What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c: /*
- This is not a perfect match. Avoid dependency on the DM GPIO
driver
- needed
- for accurate board detection. Hummingboard2 DT is good enough for
- U-Boot on
- all Hummingboard/Cubox-i platforms.
*/ so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base.
But
the board really is the original hummingboard platform. Thanks!
-- Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here? https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L12...
it should be PHY_INTERFACE_MODE_RGMII_TXID to get the original behavior, shouldn't it? The commit in question only removes the hardcoded TX delay.
This change alone also still fails on master for me.
Hi Tom,
On Tue, Jun 16, 2020 at 4:55 PM Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
mx6cuboxi_defconfig still needs to be converted to DM_ETH.
Unfortunately, I don't have access to my mx6cuboxi board to work on this.
On Tue, 16 Jun 2020 at 23:43, Fabio Estevam festevam@gmail.com wrote:
Hi Tom,
On Tue, Jun 16, 2020 at 4:55 PM Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
mx6cuboxi_defconfig still needs to be converted to DM_ETH.
Unfortunately, I don't have access to my mx6cuboxi board to work on this.
Oh, cool, thanks for the tip. Tom, I'll spare you the suffering. It's this one: https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/solidrun/mx6cuboxi/...
-Vladimir
On Tue, Jun 16, 2020 at 05:42:34PM -0300, Fabio Estevam wrote:
Hi Tom,
On Tue, Jun 16, 2020 at 4:55 PM Tom Rini trini@konsulko.com wrote:
Hey all,
In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") we brought in changes to get in to line with upstream linux kernel support for this PHY and in turn deal with more "driver was wrong, DT was wrong too" changes. Now the problem I have is that ethernet on my Hummingboard doesn't work AND as far as I can tell, the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It also looks to match what's in v5.7 for the kernel. What do I need to do here next? Thanks!
mx6cuboxi_defconfig still needs to be converted to DM_ETH.
Unfortunately, I don't have access to my mx6cuboxi board to work on this.
Ah. So this is probably why the DT being right isn't helping then. If you want to blind-convert I'm happy to test, otherwise do you have a similar board conversion for me to look at? Thanks!
On Tue, Jun 16, 2020 at 5:51 PM Tom Rini trini@konsulko.com wrote:
Ah. So this is probably why the DT being right isn't helping then. If you want to blind-convert I'm happy to test, otherwise do you have a similar board conversion for me to look at? Thanks!
Please try Vladimir's suggestion as it seems to be the less intrusive approach:
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis) if (!bus) return -EINVAL;
- phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII); + phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII_ID); if (!phydev) { ret = -EINVAL; goto free_bus;
Here is a similar DM_ETH board conversion:
commit 02ee7a4aa57b37d6003263b69b1852c4cda5975e Author: Alifer Moraes alifer.wsdm@gmail.com Date: Mon Feb 10 11:28:01 2020 -0300
mx6sabresd: Convert ethernet to driver model
Convert imx6sabresd ethernet to driver model to fix the following warning:
===================== WARNING ====================== This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ====================================================
Signed-off-by: Alifer Moraes alifer.wsdm@gmail.com Reviewed-by: Fabio Estevam festevam@gmail.com
Let us know if this helps.
On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
On Tue, Jun 16, 2020 at 5:51 PM Tom Rini trini@konsulko.com wrote:
Ah. So this is probably why the DT being right isn't helping then. If you want to blind-convert I'm happy to test, otherwise do you have a similar board conversion for me to look at? Thanks!
Please try Vladimir's suggestion as it seems to be the less intrusive approach:
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis) if (!bus) return -EINVAL;
phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
phydev = phy_find_by_mask(bus, ETH_PHY_MASK,PHY_INTERFACE_MODE_RGMII_ID); if (!phydev) { ret = -EINVAL; goto free_bus;
OK, tried that and not enough. Console says PHY autoneg completes, but DHCP still doesn't reply.
Here is a similar DM_ETH board conversion:
commit 02ee7a4aa57b37d6003263b69b1852c4cda5975e Author: Alifer Moraes alifer.wsdm@gmail.com Date: Mon Feb 10 11:28:01 2020 -0300
mx6sabresd: Convert ethernet to driver model Convert imx6sabresd ethernet to driver model to fix the following warning: ===================== WARNING ====================== This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== Signed-off-by: Alifer Moraes <alifer.wsdm@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com>Let us know if this helps.
I'm looking at the conversion now, thanks.
On Tue, Jun 16, 2020 at 5:58 PM Tom Rini trini@konsulko.com wrote:
I'm looking at the conversion now, thanks.
When doing the DM_ETH conversion, this kernel commit may also help as 'qca,clk-out-frequency' is also supported in U-Boot:
commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09 Author: Russell King rmk+kernel@armlinux.org.uk Date: Wed Apr 15 16:44:17 2020 +0100
ARM: dts: imx6-sr-som: add ethernet PHY configuration
Add ethernet PHY configuration ahead of removing the quirk that configures the clocking mode for the PHY. The RGMII delay is already set correctly.
Signed-off-by: Russell King rmk+kernel@armlinux.org.uk Reviewed-by: Fabio Estevam festevam@gmail.com Signed-off-by: Shawn Guo shawnguo@kernel.org
On Tue, Jun 16, 2020 at 06:01:24PM -0300, Fabio Estevam wrote:
On Tue, Jun 16, 2020 at 5:58 PM Tom Rini trini@konsulko.com wrote:
I'm looking at the conversion now, thanks.
When doing the DM_ETH conversion, this kernel commit may also help as 'qca,clk-out-frequency' is also supported in U-Boot:
commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09 Author: Russell King rmk+kernel@armlinux.org.uk Date: Wed Apr 15 16:44:17 2020 +0100
ARM: dts: imx6-sr-som: add ethernet PHY configuration Add ethernet PHY configuration ahead of removing the quirk that configures the clocking mode for the PHY. The RGMII delay is already set correctly. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Yeah, OK, I got far enough on trying to convert this that I see I don't quite have time to pick it up and run with it. It looks like there's going to be some extra fun around resetting the PHY perhaps? My quick pass got things seeing a generic PHY and not the atheros one. If you have time to make something you'd like me to test for conversion let me know. But I'm going to pick up debugging the problem I see on the platform right now in case there's a wider problem it's showing.
Hi Tom,
On Tue, Jun 16, 2020 at 7:30 PM Tom Rini trini@konsulko.com wrote:
Yeah, OK, I got far enough on trying to convert this that I see I don't quite have time to pick it up and run with it. It looks like there's going to be some extra fun around resetting the PHY perhaps? My quick pass got things seeing a generic PHY and not the atheros one. If you have time to make something you'd like me to test for conversion let me know. But I'm going to pick up debugging the problem I see on the platform right now in case there's a wider problem it's showing.
Here are two untested patches you could try.
On Wed, Jun 17, 2020 at 9:04 AM Fabio Estevam festevam@gmail.com wrote:
Hi Tom,
On Tue, Jun 16, 2020 at 7:30 PM Tom Rini trini@konsulko.com wrote:
Yeah, OK, I got far enough on trying to convert this that I see I don't quite have time to pick it up and run with it. It looks like there's going to be some extra fun around resetting the PHY perhaps? My quick pass got things seeing a generic PHY and not the atheros one. If you have time to make something you'd like me to test for conversion let me know. But I'm going to pick up debugging the problem I see on the platform right now in case there's a wider problem it's showing.
Here are two untested patches you could try.
Just tested Ethernet on a mx6qsabresd board and I see Ethernet is broken in master. It works fine in 2020.04.
Reverting 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") did not help.
git bisect is running into problems:
Error: Cannot open output file scripts/Makefile.spl:465: recipe for target 'spl/dts/imx6dl-sabresd.dtb' failed make[1]: *** [spl/dts/imx6dl-sabresd.dtb] Error 1 make[1]: *** Waiting for unfinished jobs.... UPD spl/./include/generated/asm-offsets.h UPD spl/./include/generated/generic-asm-offsets.h Makefile:1940: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2
So not able to run a bit bisect.
On Wed, Jun 17, 2020 at 10:06:25AM -0300, Fabio Estevam wrote:
On Wed, Jun 17, 2020 at 9:04 AM Fabio Estevam festevam@gmail.com wrote:
Hi Tom,
On Tue, Jun 16, 2020 at 7:30 PM Tom Rini trini@konsulko.com wrote:
Yeah, OK, I got far enough on trying to convert this that I see I don't quite have time to pick it up and run with it. It looks like there's going to be some extra fun around resetting the PHY perhaps? My quick pass got things seeing a generic PHY and not the atheros one. If you have time to make something you'd like me to test for conversion let me know. But I'm going to pick up debugging the problem I see on the platform right now in case there's a wider problem it's showing.
Here are two untested patches you could try.
Just tested Ethernet on a mx6qsabresd board and I see Ethernet is broken in master. It works fine in 2020.04.
Reverting 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually configurable for AR8035") did not help.
git bisect is running into problems:
Error: Cannot open output file scripts/Makefile.spl:465: recipe for target 'spl/dts/imx6dl-sabresd.dtb' failed make[1]: *** [spl/dts/imx6dl-sabresd.dtb] Error 1 make[1]: *** Waiting for unfinished jobs.... UPD spl/./include/generated/asm-offsets.h UPD spl/./include/generated/generic-asm-offsets.h Makefile:1940: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2
So not able to run a bit bisect.
You probably need 5f09f9af3cc335fe6a74c031cfa0b1d8bdf4b9db applied when you see that failure, or a smaller make -j number.
On Wed, Jun 17, 2020 at 10:23 AM Tom Rini trini@konsulko.com wrote:
You probably need 5f09f9af3cc335fe6a74c031cfa0b1d8bdf4b9db applied when you see that failure, or a smaller make -j number.
Ok, I fixed the issue for mx6sabresd. It was dts problem. I will send the patch.
On Wed, Jun 17, 2020 at 09:04:44AM -0300, Fabio Estevam wrote:
Hi Tom,
On Tue, Jun 16, 2020 at 7:30 PM Tom Rini trini@konsulko.com wrote:
Yeah, OK, I got far enough on trying to convert this that I see I don't quite have time to pick it up and run with it. It looks like there's going to be some extra fun around resetting the PHY perhaps? My quick pass got things seeing a generic PHY and not the atheros one. If you have time to make something you'd like me to test for conversion let me know. But I'm going to pick up debugging the problem I see on the platform right now in case there's a wider problem it's showing.
Here are two untested patches you could try.
Based on your follow-up patches, I think you'll be unsurprised it doesn't work. I get: Net: Could not get PHY for FEC0: addr 0
Now, question:
- ret = dm_gpio_lookup_name("GPIO4_15", &desc);
- if (ret) {
printf("%s: phy reset lookup failed\n", __func__);return;- }
- ret = dm_gpio_request(&desc, "phy-reset");
- if (ret) {
printf("%s: phy reset request failed\n", __func__);return;- }
- gpio_direction_output(ETH_PHY_RESET, 0);
- mdelay(10);
- gpio_set_value(ETH_PHY_RESET, 1);
- udelay(100);
- gpio_free_list_nodev(&desc, 1);
Don't we need that still, but in a setup_fec() call? I have a quick test with:
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c index a2c2bb9e354e..89b0d8680658 100644 --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -17,6 +17,7 @@ #include <image.h> #include <init.h> #include <log.h> +#include <net.h> #include <asm/arch/clock.h> #include <asm/arch/imx-regs.h> #include <asm/arch/iomux.h> @@ -33,6 +34,7 @@ #include <fsl_esdhc_imx.h> #include <malloc.h> #include <miiphy.h> +#include <netdev.h> #include <asm/arch/crm_regs.h> #include <asm/io.h> #include <asm/arch/sys_proto.h> @@ -50,15 +52,6 @@ DECLARE_GLOBAL_DATA_PTR; PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \ PAD_CTL_SRE_FAST | PAD_CTL_HYS)
-#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ - PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS) - -#define ENET_PAD_CTRL_PD (PAD_CTL_PUS_100K_DOWN | \ - PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS) - -#define ENET_PAD_CTRL_CLK ((PAD_CTL_PUS_100K_UP & ~PAD_CTL_PKE) | \ - PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) - #define ETH_PHY_RESET IMX_GPIO_NR(4, 15) #define USB_H1_VBUS IMX_GPIO_NR(1, 0)
@@ -235,6 +228,51 @@ int board_mmc_init(bd_t *bis) return 0; }
+#ifdef CONFIG_FEC_MXC +static int setup_fec(void) +{ + struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR; + struct gpio_desc desc; + + int ret = enable_fec_anatop_clock(0, ENET_25MHZ); + if (ret) + return ret; + + /* set gpr1[ENET_CLK_SEL] */ + setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK); + + /* Reset PHY */ + ret = dm_gpio_lookup_name("GPIO4_15", &desc); + if (ret) { + printf("%s: phy reset lookup failed\n", __func__); + return ret; + } + + ret = dm_gpio_request(&desc, "phy-reset"); + if (ret) { + printf("%s: phy reset request failed\n", __func__); + return ret; + } + + gpio_direction_output(ETH_PHY_RESET, 0); + mdelay(10); + gpio_set_value(ETH_PHY_RESET, 1); + udelay(100); + + gpio_free_list_nodev(&desc, 1); + + return 0; +} +#endif + +int board_phy_config(struct phy_device *phydev) +{ + if (phydev->drv->config) + phydev->drv->config(phydev); + + return 0; +} + #ifdef CONFIG_VIDEO_IPUV3 static void do_enable_hdmi(struct display_info_t const *dev) { @@ -344,6 +382,12 @@ int board_init(void) /* address of boot parameters */ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
+#ifdef CONFIG_FEC_MXC + ret = setup_fec(); + if (ret) + return ret; +#endif + #ifdef CONFIG_VIDEO_IPUV3 ret = setup_display(); #endif
And at run-time I get: Warning: ethernet@2188000 using MAC address from ROM eth0: ethernet@2188000 ... => mdio list FEC0: 0 - AR8035 <--> ethernet@2188000
And I did the mdio write/read's from the previous part of the thread and get the same values.
On Wed, Jun 17, 2020 at 4:00 PM Tom Rini trini@konsulko.com wrote:
+#ifdef CONFIG_FEC_MXC +static int setup_fec(void) +{
struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;struct gpio_desc desc;int ret = enable_fec_anatop_clock(0, ENET_25MHZ);if (ret)return ret;/* set gpr1[ENET_CLK_SEL] */setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);/* Reset PHY */ret = dm_gpio_lookup_name("GPIO4_15", &desc);if (ret) {printf("%s: phy reset lookup failed\n", __func__);return ret;}ret = dm_gpio_request(&desc, "phy-reset");if (ret) {printf("%s: phy reset request failed\n", __func__);return ret;}gpio_direction_output(ETH_PHY_RESET, 0);mdelay(10);gpio_set_value(ETH_PHY_RESET, 1);udelay(100);
The Ethernet PHY reset can be done via device tree.
It seems we need to change it like this:
--- a/arch/arm/dts/imx6qdl-sr-som.dtsi +++ b/arch/arm/dts/imx6qdl-sr-som.dtsi @@ -54,7 +54,8 @@ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_microsom_enet_ar8035>; phy-mode = "rgmii-id"; - phy-reset-duration = <2>; + phy-reset-duration = <10>; + phy-reset-post-delay = <1>; phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; status = "okay"; };
Does it still probe if you remove the PHY reset from the board code?
On Wed, Jun 17, 2020 at 4:09 PM Fabio Estevam festevam@gmail.com wrote:
Does it still probe if you remove the PHY reset from the board code?
Another suggestion: please use the ar8031_phy_fixup() and board_phy_config() from mx6sabresd into cubox board file to see if Ethernet works.
On Wed, Jun 17, 2020 at 04:18:27PM -0300, Fabio Estevam wrote:
On Wed, Jun 17, 2020 at 4:09 PM Fabio Estevam festevam@gmail.com wrote:
Does it still probe if you remove the PHY reset from the board code?
Another suggestion: please use the ar8031_phy_fixup() and board_phy_config() from mx6sabresd into cubox board file to see if Ethernet works.
Literal copy and paste and same failure.
On Wed, Jun 17, 2020 at 04:09:19PM -0300, Fabio Estevam wrote:
On Wed, Jun 17, 2020 at 4:00 PM Tom Rini trini@konsulko.com wrote:
+#ifdef CONFIG_FEC_MXC +static int setup_fec(void) +{
struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;struct gpio_desc desc;int ret = enable_fec_anatop_clock(0, ENET_25MHZ);if (ret)return ret;/* set gpr1[ENET_CLK_SEL] */setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);/* Reset PHY */ret = dm_gpio_lookup_name("GPIO4_15", &desc);if (ret) {printf("%s: phy reset lookup failed\n", __func__);return ret;}ret = dm_gpio_request(&desc, "phy-reset");if (ret) {printf("%s: phy reset request failed\n", __func__);return ret;}gpio_direction_output(ETH_PHY_RESET, 0);mdelay(10);gpio_set_value(ETH_PHY_RESET, 1);udelay(100);The Ethernet PHY reset can be done via device tree.
It seems we need to change it like this:
--- a/arch/arm/dts/imx6qdl-sr-som.dtsi +++ b/arch/arm/dts/imx6qdl-sr-som.dtsi @@ -54,7 +54,8 @@ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_microsom_enet_ar8035>; phy-mode = "rgmii-id";
phy-reset-duration = <2>;
phy-reset-duration = <10>;phy-reset-post-delay = <1>; phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; status = "okay";};
Does it still probe if you remove the PHY reset from the board code?
Nope, same "Could not get PHY for FEC0: addr 0". I gather from another part of this thread there's some further breakage / unexpected changes, so I'll chime in there next.
Hi Tom,
On Wed, Jun 17, 2020 at 4:00 PM Tom Rini trini@konsulko.com wrote:
Based on your follow-up patches, I think you'll be unsurprised it doesn't work. I get: Net: Could not get PHY for FEC0: addr 0
Now I understand why the PHY could not be found with the patches I sent.
On mx6cubox the AR8035 is clocked from a 25MHz clock coming from the i.MX6 GPIO16 pin.
My patch incorrectly removed this setting.
int ret = enable_fec_anatop_clock(0, ENET_25MHZ);if (ret)return ret;/* set gpr1[ENET_CLK_SEL] */setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
enable_fec_anatop_clock() and GPR1 settings above must remain.
In order to get patch 1 to work (the one that adds the qca,clk-out-frequency property ) you also need this FEC change: https://pastebin.com/raw/mcKdwwTs
I hope this helps.
On Wed, Jun 17, 2020 at 06:28:37PM -0300, Fabio Estevam wrote:
Hi Tom,
On Wed, Jun 17, 2020 at 4:00 PM Tom Rini trini@konsulko.com wrote:
Based on your follow-up patches, I think you'll be unsurprised it doesn't work. I get: Net: Could not get PHY for FEC0: addr 0
Now I understand why the PHY could not be found with the patches I sent.
On mx6cubox the AR8035 is clocked from a 25MHz clock coming from the i.MX6 GPIO16 pin.
My patch incorrectly removed this setting.
int ret = enable_fec_anatop_clock(0, ENET_25MHZ);if (ret)return ret;/* set gpr1[ENET_CLK_SEL] */setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);enable_fec_anatop_clock() and GPR1 settings above must remain.
In order to get patch 1 to work (the one that adds the qca,clk-out-frequency property ) you also need this FEC change: https://pastebin.com/raw/mcKdwwTs
I hope this helps.
I'll test that out tomorrow. But my question now is, what do you want to do about the various platforms where ethernet isn't working?
On Wed, Jun 17, 2020 at 6:30 PM Tom Rini trini@konsulko.com wrote:
I'll test that out tomorrow. But my question now is, what do you want to do about the various platforms where ethernet isn't working?
I fixed the mx6sabresd Ethernet regression today and I can also try to convert other imx platforms from rgmii to rgmi-id.
We still don't have the root cause for the mx6cuboxi regression.
What are the other platforms where ethernet isn't working?
On Wed, Jun 17, 2020 at 09:41:17PM -0300, Fabio Estevam wrote:
On Wed, Jun 17, 2020 at 6:30 PM Tom Rini trini@konsulko.com wrote:
I'll test that out tomorrow. But my question now is, what do you want to do about the various platforms where ethernet isn't working?
I fixed the mx6sabresd Ethernet regression today and I can also try to convert other imx platforms from rgmii to rgmi-id.
We still don't have the root cause for the mx6cuboxi regression.
What are the other platforms where ethernet isn't working?
It's a good question what else doesn't work. What has been actively verified at this point?
Hi Tom,
On Thu, Jun 18, 2020 at 10:39 AM Tom Rini trini@konsulko.com wrote:
It's a good question what else doesn't work. What has been actively verified at this point?
After the fixes I sent yesterday, the few imx boards I have access at the moment have Ethernet working well.
On 20.06.20 04:14, Fabio Estevam wrote:
Hi Tom,
On Thu, Jun 18, 2020 at 10:39 AM Tom Rini trini@konsulko.com wrote:
It's a good question what else doesn't work. What has been actively verified at this point?
After the fixes I sent yesterday, the few imx boards I have access at the moment have Ethernet working well.
I tested current master (v2020.07-rc5 + imx fixes) on tbs2910 (imx6q + atheros PHY). Unfortunately ethernet is broken now, while it used to work well on u-boot version v2020.04. Ethernet support was copied from imx6q-sabresd, the recently for sabresd fixed phy-mode already is rgmii-id for tbs2910.
Any ideas what could be wrong?
Thanks, Soeren
Hi Soeren,
On Wed, Jun 24, 2020 at 4:20 PM Soeren Moch smoch@web.de wrote:
I tested current master (v2020.07-rc5 + imx fixes) on tbs2910 (imx6q + atheros PHY). Unfortunately ethernet is broken now, while it used to work well on u-boot version v2020.04. Ethernet support was copied from imx6q-sabresd, the recently for sabresd fixed phy-mode already is rgmii-id for tbs2910.
Any ideas what could be wrong?
I just tested mainline U-Boot and Ethernet works fine on a imx6qp sabresd board:
U-Boot SPL 2020.07-rc5-00052-g922c6d5d00 (Jun 24 2020 - 16:21:27 -0300) Trying to boot from MMC1
U-Boot 2020.07-rc5-00052-g922c6d5d00 (Jun 24 2020 - 16:21:27 -0300)
CPU: Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 30C Reset cause: POR Model: Freescale i.MX6 Quad Plus SABRE Smart Device Board Board: MX6-SabreSD I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 3 Loading Environment from MMC... OK No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial Net: eth0: ethernet@2188000 Hit any key to stop autoboot: 0 => dhcp zImage BOOTP broadcast 1 DHCP client bound to address 192.168.0.24 (50 ms) Using ethernet@2188000 device TFTP from server 192.168.0.12; our IP address is 192.168.0.24 Filename 'zImage'. Load address: 0x12000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################################# 1.3 MiB/s done Bytes transferred = 9468928 (907c00 hex) => mdio list FEC0: 1 - AR8031/AR8033 <--> ethernet@2188000 =>
What is the exact failure you see? Is the Ethernet PHY found at the correct address and probed?
On tbs2910 does the AR8031 generate a 125MHz clock to the i.MX6Q Ethernet?
If so, does the change below help (I am assuming the PHY is located at address 1, if not, please adjust the @ and reg accordingly)?
--- a/arch/arm/dts/imx6q-tbs2910.dts +++ b/arch/arm/dts/imx6q-tbs2910.dts @@ -108,6 +108,16 @@ phy-mode = "rgmii-id"; phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; status = "okay"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy: ethernet-phy@1 { + reg = <1>; + qca,clk-out-frequency = <125000000>; + }; + }; };
In case you still have issues, please share the tbs2910 schematics with me offline so I can try to understand the failure.
Hi Fabio
On 24.06.20 21:39, Fabio Estevam wrote:
Hi Soeren,
On Wed, Jun 24, 2020 at 4:20 PM Soeren Moch smoch@web.de wrote:
I tested current master (v2020.07-rc5 + imx fixes) on tbs2910 (imx6q + atheros PHY). Unfortunately ethernet is broken now, while it used to work well on u-boot version v2020.04. Ethernet support was copied from imx6q-sabresd, the recently for sabresd fixed phy-mode already is rgmii-id for tbs2910.
Any ideas what could be wrong?
I just tested mainline U-Boot and Ethernet works fine on a imx6qp sabresd board:
U-Boot SPL 2020.07-rc5-00052-g922c6d5d00 (Jun 24 2020 - 16:21:27 -0300) Trying to boot from MMC1
U-Boot 2020.07-rc5-00052-g922c6d5d00 (Jun 24 2020 - 16:21:27 -0300)
CPU: Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 30C Reset cause: POR Model: Freescale i.MX6 Quad Plus SABRE Smart Device Board Board: MX6-SabreSD I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 3 Loading Environment from MMC... OK No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial Net: eth0: ethernet@2188000 Hit any key to stop autoboot: 0 => dhcp zImage BOOTP broadcast 1 DHCP client bound to address 192.168.0.24 (50 ms) Using ethernet@2188000 device TFTP from server 192.168.0.12; our IP address is 192.168.0.24 Filename 'zImage'. Load address: 0x12000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################################# 1.3 MiB/s done Bytes transferred = 9468928 (907c00 hex) => mdio list FEC0: 1 - AR8031/AR8033 <--> ethernet@2188000 =>
What is the exact failure you see? Is the Ethernet PHY found at the correct address and probed?
From what I see nothing is obviously wrong, just no ethernet connection:
U-Boot 2020.07-rc5-00039-g4ff63383e3-dirty (Jun 24 2020 - 21:48:31 +0200)
CPU: Freescale i.MX6Q rev1.2 at 792MHz CPU: Commercial temperature grade (0C to 95C) at 42C Reset cause: POR Model: TBS2910 Matrix ARM mini PC DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: vga Err: vga Net: eth0: ethernet@2188000 PCI:
PCI: pcie phy link never came up No such bus starting USB... Bus usb@2184000: usb dr_mode not found Bus usb@2184200: USB EHCI 1.00 scanning bus usb@2184000 for devices... 1 USB Device(s) found scanning bus usb@2184200 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Matrix U-Boot> dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17
Retry time exceeded; starting again Matrix U-Boot> mdio list FEC0:
4 - AR8035 <--> ethernet@2188000 Matrix U-Boot>
On tbs2910 does the AR8031 generate a 125MHz clock to the i.MX6Q Ethernet?
If so, does the change below help (I am assuming the PHY is located at address 1, if not, please adjust the @ and reg accordingly)?
--- a/arch/arm/dts/imx6q-tbs2910.dts +++ b/arch/arm/dts/imx6q-tbs2910.dts @@ -108,6 +108,16 @@ phy-mode = "rgmii-id"; phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; status = "okay";
mdio {#address-cells = <1>;#size-cells = <0>;phy: ethernet-phy@1 {reg = <1>;qca,clk-out-frequency = <125000000>;};};};
I used this patch with address 4 (that's why the -dirty in the u-boot version), no luck. It seems I have a AR8035 PHY.
In case you still have issues, please share the tbs2910 schematics with me offline so I can try to understand the failure.
Schematics are at https://www.tbsdtv.com/download/document/tbs2910/TBS2910-Matrix-ARM-mini-PC-...
Thanks for your help, Soeren
Hi Soeren,
On Wed, Jun 24, 2020 at 5:13 PM Soeren Moch smoch@web.de wrote:
Schematics are at https://www.tbsdtv.com/download/document/tbs2910/TBS2910-Matrix-ARM-mini-PC-...
Here is another patch for you to try: https://pastebin.com/raw/Dkipgq1n
Hi Fabio,
On 24.06.20 22:29, Fabio Estevam wrote:
Hi Soeren,
On Wed, Jun 24, 2020 at 5:13 PM Soeren Moch smoch@web.de wrote:
Schematics are at https://www.tbsdtv.com/download/document/tbs2910/TBS2910-Matrix-ARM-mini-PC-...
Here is another patch for you to try: https://pastebin.com/raw/Dkipgq1n
Still no luck:
U-Boot 2020.07-rc5-00039-g4ff63383e3-dirty (Jun 24 2020 - 22:36:43 +0200)
CPU: Freescale i.MX6Q rev1.2 at 792MHz CPU: Commercial temperature grade (0C to 95C) at 47C Reset cause: POR Model: TBS2910 Matrix ARM mini PC DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: vga Err: vga Net: eth0: ethernet@2188000 PCI: PCI: pcie phy link never came up No such bus starting USB... Bus usb@2184000: usb dr_mode not found Bus usb@2184200: USB EHCI 1.00 scanning bus usb@2184000 for devices... 1 USB Device(s) found scanning bus usb@2184200 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Matrix U-Boot> dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17
Retry time exceeded; starting again Matrix U-Boot> mdio list FEC0: 4 - AR8035 <--> ethernet@2188000 Matrix U-Boot>
Hi Soeren,
On Wed, Jun 24, 2020 at 5:45 PM Sören Moch smoch@web.de wrote:
Still no luck:
mx6cuboxi has an AR8035 too and it is working fine in U-Boot mainline.
I am not sure why tbs2910 is failing. Could you try to bisect?
Hi Fabio,
On 24.06.20 23:35, Fabio Estevam wrote:
Hi Soeren,
On Wed, Jun 24, 2020 at 5:45 PM Sören Moch smoch@web.de wrote:
Still no luck:
mx6cuboxi has an AR8035 too and it is working fine in U-Boot mainline.
I am not sure why tbs2910 is failing. Could you try to bisect?
Unfortunately I have no access to my usual development board (and will not have until the v2020.07 release). I only can use an old board without working USB-OTG, limited to eMMC boot. So I tried to avoid bisecting, because a bad commit could completely brick this board.
Is there a reliable way to start a new u-boot directly from a running u-boot?
Soeren
Hi Soeren,
On Wed, Jun 24, 2020 at 7:29 PM Soeren Moch smoch@web.de wrote:
Unfortunately I have no access to my usual development board (and will not have until the v2020.07 release). I only can use an old board without working USB-OTG, limited to eMMC boot. So I tried to avoid bisecting, because a bad commit could completely brick this board.
Ok, understood.
We could check if the issue on your board is due to:
commit 6333cbb3817ed551cd7d4e92f7359c73ccc567fc Author: Michael Walle michael@walle.cc Date: Thu May 7 00:11:58 2020 +0200
phy: atheros: ar8035: remove static clock config
We can configure the clock output in the device tree. Disable the hardcoded one in here. This is highly board-specific and should have never been enabled in the PHY driver.
If bisecting shows that this commit breaks your board it probably depends on the clock output of your Atheros AR8035 PHY. Please have a look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set "clk-out-frequency = <125000000>" because that value was the hardcoded value until this commit.
Signed-off-by: Michael Walle michael@walle.cc Acked-by: Joe Hershberger joe.hershberger@ni.com
On your board, are you able to measure with a scope the AR8035 CLK_25M pin?
Prior to this commit the CLK_25M was hardcoded to output a 125MHz clock.
Now that this setting from the ar8035 phy driver is gone we should pass this information in some form:
- We tried via devicetree with the "qca,clk-out-frequency" property, but it did not work. This is an area where you could add some debug prints inside drivers/net/phy/atheros.c and see if if qca,clk-out-frequency is being parsed correctly to configure a 125MHz clock output. This is the method I used on mx6cuboxi last week and it works.
- Other way to configure the AR803x is via board code. Please try to copy the ar8031_phy_fixup() and board_phy_config() from board/freescale/mx6sabresd/mx6sabresd.c into your board file.
(I plan to remove this board PHY code in mx6sabresd after 2020.07 and use "qca,clk-out-frequency" to do the job).
On Wed, Jun 24, 2020 at 8:19 PM Fabio Estevam festevam@gmail.com wrote:
- We tried via devicetree with the "qca,clk-out-frequency" property,
but it did not work. This is an area where you could add some debug prints inside drivers/net/phy/atheros.c and see if if qca,clk-out-frequency is being parsed correctly to configure a 125MHz clock output. This is the method I used on mx6cuboxi last week and it works.
To help debugging why "qca,clk-out-frequency" is not taking effect you could try this debug patch: https://pastebin.com/raw/RKG63JGJ
This is the result on a imx6 hummingboard: .... Net: ar803x_of_init: found PHY node: ethernet-phy@0 ********** clk out frequency is 125000000 ar803x_of_init: flags=0 clk_25m_reg=0018 clk_25m_mask=0018 ******** PHY mode is 8 Warning: ethernet@2188000 using MAC address from ROM eth0: ethernet@2188000 Hit any key to stop autoboot: 0 =>
Hi Fabio,
On 25.06.20 01:19, Fabio Estevam wrote:
Hi Soeren,
On Wed, Jun 24, 2020 at 7:29 PM Soeren Moch smoch@web.de wrote:
Unfortunately I have no access to my usual development board (and will not have until the v2020.07 release). I only can use an old board without working USB-OTG, limited to eMMC boot. So I tried to avoid bisecting, because a bad commit could completely brick this board.
Ok, understood.
We could check if the issue on your board is due to:
commit 6333cbb3817ed551cd7d4e92f7359c73ccc567fc Author: Michael Walle michael@walle.cc Date: Thu May 7 00:11:58 2020 +0200
phy: atheros: ar8035: remove static clock config We can configure the clock output in the device tree. Disable the hardcoded one in here. This is highly board-specific and should have never been enabled in the PHY driver. If bisecting shows that this commit breaks your board it probably depends on the clock output of your Atheros AR8035 PHY. Please have a look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set "clk-out-frequency = <125000000>" because that value was the hardcoded value until this commit. Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Joe Hershberger <joe.hershberger@ni.com>On your board, are you able to measure with a scope the AR8035 CLK_25M pin?
Prior to this commit the CLK_25M was hardcoded to output a 125MHz clock.
Now that this setting from the ar8035 phy driver is gone we should pass this information in some form:
- We tried via devicetree with the "qca,clk-out-frequency" property,
but it did not work. This is an area where you could add some debug prints inside drivers/net/phy/atheros.c and see if if qca,clk-out-frequency is being parsed correctly to configure a 125MHz clock output. This is the method I used on mx6cuboxi last week and it works.
The phy-handle was missing in the fec node. With this added everything works fine:
---8<--- diff --git a/arch/arm/dts/imx6q-tbs2910.dts b/arch/arm/dts/imx6q-tbs2910.dts index cc5df37b46..5b9b025bb6 100644 --- a/arch/arm/dts/imx6q-tbs2910.dts +++ b/arch/arm/dts/imx6q-tbs2910.dts @@ -105,9 +105,20 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; + phy-handle = <&phy>; phy-mode = "rgmii-id"; phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; status = "okay"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy: ethernet-phy@4 { + reg = <4>; + qca,clk-out-frequency = <125000000>; + }; + }; }; &hdmi { ---8<---
- Other way to configure the AR803x is via board code. Please try to
copy the ar8031_phy_fixup() and board_phy_config() from board/freescale/mx6sabresd/mx6sabresd.c into your board file.
(I plan to remove this board PHY code in mx6sabresd after 2020.07 and use "qca,clk-out-frequency" to do the job).
OK, so I think we should use the dts patch as fix for u-boot now and sync that to linux afterwards. Do you want to send a proper patch for that? Otherwise I can do so.
Thanks for your help and suggestions, Soeren
Hi Soeren,
On Thu, Jun 25, 2020 at 6:56 AM Soeren Moch smoch@web.de wrote:
The phy-handle was missing in the fec node. With this added everything works fine:
Ops :-)
Yes, I will submit this patch for U-Boot.
Thanks
Hi Tom,
On Wed, Jun 17, 2020 at 6:28 PM Fabio Estevam festevam@gmail.com wrote:
Hi Tom,
On Wed, Jun 17, 2020 at 4:00 PM Tom Rini trini@konsulko.com wrote:
Based on your follow-up patches, I think you'll be unsurprised it doesn't work. I get: Net: Could not get PHY for FEC0: addr 0
Now I understand why the PHY could not be found with the patches I sent.
On mx6cubox the AR8035 is clocked from a 25MHz clock coming from the i.MX6 GPIO16 pin.
My patch incorrectly removed this setting.
int ret = enable_fec_anatop_clock(0, ENET_25MHZ);if (ret)return ret;/* set gpr1[ENET_CLK_SEL] */setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);enable_fec_anatop_clock() and GPR1 settings above must remain.
In order to get patch 1 to work (the one that adds the qca,clk-out-frequency property ) you also need this FEC change: https://pastebin.com/raw/mcKdwwTs
I hope this helps.
Good news! I managed to get access to an imx6 humming board and managed to fix the Eternet issue.
I will submit the AR8035 fix.
On Tue, 16 Jun 2020 at 23:58, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
On Tue, Jun 16, 2020 at 5:51 PM Tom Rini trini@konsulko.com wrote:
Ah. So this is probably why the DT being right isn't helping then. If you want to blind-convert I'm happy to test, otherwise do you have a similar board conversion for me to look at? Thanks!
Please try Vladimir's suggestion as it seems to be the less intrusive approach:
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis) if (!bus) return -EINVAL;
phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
phydev = phy_find_by_mask(bus, ETH_PHY_MASK,PHY_INTERFACE_MODE_RGMII_ID); if (!phydev) { ret = -EINVAL; goto free_bus;
OK, tried that and not enough. Console says PHY autoneg completes, but DHCP still doesn't reply.
What about with the manual revert in place? What does phydev->interface print? Not only in atheros.c, but also in mx6cuboxi.c, right below this phy_find_by_mask call. Trying to understand if this is your only problem or if there are more.
On Wed, 17 Jun 2020 at 00:01, Vladimir Oltean olteanv@gmail.com wrote:
On Tue, 16 Jun 2020 at 23:58, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
On Tue, Jun 16, 2020 at 5:51 PM Tom Rini trini@konsulko.com wrote:
Ah. So this is probably why the DT being right isn't helping then. If you want to blind-convert I'm happy to test, otherwise do you have a similar board conversion for me to look at? Thanks!
Please try Vladimir's suggestion as it seems to be the less intrusive approach:
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis) if (!bus) return -EINVAL;
phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
phydev = phy_find_by_mask(bus, ETH_PHY_MASK,PHY_INTERFACE_MODE_RGMII_ID); if (!phydev) { ret = -EINVAL; goto free_bus;
OK, tried that and not enough. Console says PHY autoneg completes, but DHCP still doesn't reply.
What about with the manual revert in place? What does phydev->interface print? Not only in atheros.c, but also in mx6cuboxi.c, right below this phy_find_by_mask call. Trying to understand if this is your only problem or if there are more.
In fact there's one more 'manual' thing you can do.
Check if RX delay is enabled (bit 15 of debug register 0): => mdio write eTSEC1 0x1D 0 => mdio read eTSEC1 0x1E => mdio write eTSEC1 0x1E <new value>
Check if TX delay is enabled (bit 8 of debug register 5): => mdio write eTSEC1 0x1D 5 => mdio read eTSEC1 0x1E => mdio write eTSEC1 0x1E <new value>
(replace eTSEC1 with your mdio bus name from "mdio list")
On Wed, Jun 17, 2020 at 12:04:16AM +0300, Vladimir Oltean wrote:
On Wed, 17 Jun 2020 at 00:01, Vladimir Oltean olteanv@gmail.com wrote:
On Tue, 16 Jun 2020 at 23:58, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
On Tue, Jun 16, 2020 at 5:51 PM Tom Rini trini@konsulko.com wrote:
Ah. So this is probably why the DT being right isn't helping then. If you want to blind-convert I'm happy to test, otherwise do you have a similar board conversion for me to look at? Thanks!
Please try Vladimir's suggestion as it seems to be the less intrusive approach:
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis) if (!bus) return -EINVAL;
phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
phydev = phy_find_by_mask(bus, ETH_PHY_MASK,PHY_INTERFACE_MODE_RGMII_ID); if (!phydev) { ret = -EINVAL; goto free_bus;
OK, tried that and not enough. Console says PHY autoneg completes, but DHCP still doesn't reply.
What about with the manual revert in place? What does phydev->interface print? Not only in atheros.c, but also in mx6cuboxi.c, right below this phy_find_by_mask call. Trying to understand if this is your only problem or if there are more.
In fact there's one more 'manual' thing you can do.
For this test, based on your previous email and the kernel dts files, I made the change to mx6cuboxi.c to pass PHY_INTERFACE_MODE_RGMII_ID to phy_find_by_mask(...).
Check if RX delay is enabled (bit 15 of debug register 0): => mdio write eTSEC1 0x1D 0 => mdio read eTSEC1 0x1E => mdio write eTSEC1 0x1E <new value>
=> mdio list FEC: 0 - AR8035 <--> FEC => mdio write FEC 0x1D 0 => mdio read FEC 0x1E Reading from bus FEC PHY at address 0: 30 - 0x82ee ... so it's enabled already.
Check if TX delay is enabled (bit 8 of debug register 5): => mdio write eTSEC1 0x1D 5 => mdio read eTSEC1 0x1E => mdio write eTSEC1 0x1E <new value>
=> mdio write FEC 0x1D 5 => mdio read FEC 0x1E Reading from bus FEC PHY at address 0: 30 - 0x2d47 ... so it's enabled already.
Or did I make a mistake? Thanks!
On Wed, 17 Jun 2020 at 00:57, Tom Rini trini@konsulko.com wrote:
On Wed, Jun 17, 2020 at 12:04:16AM +0300, Vladimir Oltean wrote:
On Wed, 17 Jun 2020 at 00:01, Vladimir Oltean olteanv@gmail.com wrote:
On Tue, 16 Jun 2020 at 23:58, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
On Tue, Jun 16, 2020 at 5:51 PM Tom Rini trini@konsulko.com wrote:
Ah. So this is probably why the DT being right isn't helping then. If you want to blind-convert I'm happy to test, otherwise do you have a similar board conversion for me to look at? Thanks!
Please try Vladimir's suggestion as it seems to be the less intrusive approach:
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis) if (!bus) return -EINVAL;
phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
phydev = phy_find_by_mask(bus, ETH_PHY_MASK,PHY_INTERFACE_MODE_RGMII_ID); if (!phydev) { ret = -EINVAL; goto free_bus;
OK, tried that and not enough. Console says PHY autoneg completes, but DHCP still doesn't reply.
What about with the manual revert in place? What does phydev->interface print? Not only in atheros.c, but also in mx6cuboxi.c, right below this phy_find_by_mask call. Trying to understand if this is your only problem or if there are more.
In fact there's one more 'manual' thing you can do.
For this test, based on your previous email and the kernel dts files, I made the change to mx6cuboxi.c to pass PHY_INTERFACE_MODE_RGMII_ID to phy_find_by_mask(...).
Check if RX delay is enabled (bit 15 of debug register 0): => mdio write eTSEC1 0x1D 0 => mdio read eTSEC1 0x1E => mdio write eTSEC1 0x1E <new value>
=> mdio list FEC: 0 - AR8035 <--> FEC => mdio write FEC 0x1D 0 => mdio read FEC 0x1E Reading from bus FEC PHY at address 0: 30 - 0x82ee ... so it's enabled already.
Check if TX delay is enabled (bit 8 of debug register 5): => mdio write eTSEC1 0x1D 5 => mdio read eTSEC1 0x1E => mdio write eTSEC1 0x1E <new value>
=> mdio write FEC 0x1D 5 => mdio read FEC 0x1E Reading from bus FEC PHY at address 0: 30 - 0x2d47 ... so it's enabled already.
Or did I make a mistake? Thanks!
-- Tom
Yes, the PHY has RGMII delays enabled in both directions.
On Wed, Jun 17, 2020 at 12:01:39AM +0300, Vladimir Oltean wrote:
On Tue, 16 Jun 2020 at 23:58, Tom Rini trini@konsulko.com wrote:
On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
On Tue, Jun 16, 2020 at 5:51 PM Tom Rini trini@konsulko.com wrote:
Ah. So this is probably why the DT being right isn't helping then. If you want to blind-convert I'm happy to test, otherwise do you have a similar board conversion for me to look at? Thanks!
Please try Vladimir's suggestion as it seems to be the less intrusive approach:
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis) if (!bus) return -EINVAL;
phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
phydev = phy_find_by_mask(bus, ETH_PHY_MASK,PHY_INTERFACE_MODE_RGMII_ID); if (!phydev) { ret = -EINVAL; goto free_bus;
OK, tried that and not enough. Console says PHY autoneg completes, but DHCP still doesn't reply.
What about with the manual revert in place? What does phydev->interface print? Not only in atheros.c, but also in mx6cuboxi.c, right below this phy_find_by_mask call. Trying to understand if this is your only problem or if there are more.
In both functions the value printed out for phydev->interface is the value passed to phy_find_by_mask(...).
participants (6)
-
Fabio Estevam -
Michael Walle -
Soeren Moch -
Sören Moch
-
Tom Rini -
Vladimir Oltean