tx51 ethernet regression

PATCH New Christian Kapeller 3 participants 5 messages Jul 16, 2012 – Jul 17, 2012

Subsystems (3)

Arm (32-bit) Arm sub-architectures Arm i.MX and Layerscape

lore

Share & tools

lore

Christian Kapeller

author

2012-07-16 11:28 UTC #0 lore raw

Hi,

I recently came to update my barebox port based on the karo tx51 imx module from v2012.03.0 to v2012.07.0.

I discovered, that, when trying to use the ethernet connection, I more often than not get frame errors reported by the FEC.

--snip--
barebox@Ka-Ro tx51:/ dhcp
phy0: Link is up - 1000/Full
error frame: 0x97b961c0 0x00000890
error frame: 0x97b96188 0x00000882
DHCP client bound to address 10.41.14.147
--snap--

The errors range from 'non octet aligned frame' over 'Fifo overrun' to timeouts. It renders the ethernet support unusable. Small images may work but, require the one and other retry.

One thing that catches my eye is that the auto negotioation resulted in a 1000MBit link. The imx fec does only support 100MBit. I forced the link to be set to 10MBit by declaring xcv_type=MII10 in the fec_platform_data structure. Interestingly the link is now reported as 100MBit, and shows the same behaviour.

Another thing I checked was the changed pad definitions in commit 2bdc9f57a86dff41cfc1f87b644a2e53fdcce2b6. Not only the type of the pad data structure changed, but also some of their configuration as well. For example, pads that were configured with FEC_PAD_CTL, now have other settings enabled.

I'reverted the pad changes, but still no luck. Auto negtiation starts, but I don't seem to get any packets.

So my question is: What change since v2012.03.0 could cause this kind of behaviour?

Regards
Christian

Signature · 14 lines

Christian Kapeller
cmotion GmbH
Kriehubergasse 16
1050 Wien / Austria
http://www.cmotion.eu

[email protected]
Phone: +43 1 789 1096 38


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox

Eric Bénard

2012-07-16 11:44 UTC #1 lore raw

Hi Christian,

Quoted 30 lines · Christian Kapeller

I recently came to update my barebox port based on the karo tx51 imx module from v2012.03.0 to v2012.07.0.
I discovered, that, when trying to use the ethernet connection, I more often than not get frame errors reported by the FEC.
--snip--
barebox@Ka-Ro tx51:/ dhcp
phy0: Link is up - 1000/Full
error frame: 0x97b961c0 0x00000890
error frame: 0x97b96188 0x00000882
DHCP client bound to address 10.41.14.147
--snap--
The errors range from 'non octet aligned frame' over 'Fifo overrun' to timeouts. It renders the ethernet support unusable. Small images may work but, require the one and other retry.
One thing that catches my eye is that the auto negotioation resulted in a 1000MBit link. The imx fec does only support 100MBit. I forced the link to be set to 10MBit by declaring xcv_type=MII10 in the fec_platform_data structure. Interestingly the link is now reported as 100MBit, and shows the same behaviour.
Another thing I checked was the changed pad definitions in commit 2bdc9f57a86dff41cfc1f87b644a2e53fdcce2b6. Not only the type of the pad data structure changed, but also some of their configuration as well. For example, pads that were configured with FEC_PAD_CTL, now have other settings enabled.

Quoted 6 lines

I'reverted the pad changes, but still no luck. Auto negtiation starts, but I don't seem to get any packets.
So my question is: What change since v2012.03.0 could cause this kind of behaviour?

same problem here. the problem comes from :
68b32be4926d3ab5b72036c0ceecef2f82aa0625 "i.MX51: Synchronize iomux header file from kernel"
as now most pins have NO_PAD_CTRL which means the pad doesn't get reconfigured and thus some pads to communicate with the FEC are no more working.

A dirty workaround to default PAD config is :

arch/arm/mach-imx/iomux-v3.c +2 -0

index 680d260..c21d8a2 100644
@@ -45,6 +45,8 @@ int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
 
        if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs)
                __raw_writel(pad_ctrl, base + pad_ctrl_ofs);
+       else if ((pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs)
+               __raw_writel(0, base + pad_ctrl_ofs);
 
        return 0;
 }

Eric

_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox

Christian Kapeller

author

2012-07-16 12:55 UTC #2 lore raw

Hi Eric,

thanks for the prompt reply.

Quoted 51 lines

Quoted 30 lines · Christian Kapeller
I recently came to update my barebox port based on the karo tx51 imx module from v2012.03.0 to v2012.07.0.
I discovered, that, when trying to use the ethernet connection, I more often than not get frame errors reported by the FEC.
--snip--
barebox@Ka-Ro tx51:/ dhcp
phy0: Link is up - 1000/Full
error frame: 0x97b961c0 0x00000890
error frame: 0x97b96188 0x00000882
DHCP client bound to address 10.41.14.147
--snap--
The errors range from 'non octet aligned frame' over 'Fifo overrun' to timeouts. It renders the ethernet support unusable. Small images may work but, require the one and other retry.
One thing that catches my eye is that the auto negotioation resulted in a 1000MBit link. The imx fec does only support 100MBit. I forced the link to be set to 10MBit by declaring xcv_type=MII10 in the fec_platform_data structure. Interestingly the link is now reported as 100MBit, and shows the same behaviour.
Another thing I checked was the changed pad definitions in commit 2bdc9f57a86dff41cfc1f87b644a2e53fdcce2b6. Not only the type of the pad data structure changed, but also some of their configuration as well. For example, pads that were configured with FEC_PAD_CTL, now have other settings enabled.
Quoted 6 lines
I'reverted the pad changes, but still no luck. Auto negtiation starts, but I don't seem to get any packets.
So my question is: What change since v2012.03.0 could cause this kind of behaviour?
same problem here. the problem comes from :
68b32be4926d3ab5b72036c0ceecef2f82aa0625 "i.MX51: Synchronize iomux header file from kernel"
as now most pins have NO_PAD_CTRL which means the pad doesn't get reconfigured and thus some pads to communicate with the FEC are no more working.
A dirty workaround to default PAD config is :
arch/arm/mach-imx/iomux-v3.c +0 -0
index 680d260..c21d8a2 100644

arch/arm/mach-imx/iomux-v3.c int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad) · line 52

Quoted 8 lines

arch/arm/mach-imx/iomux-v3.c +2 -0

@@ -45,6 +45,8 @@ int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
 
        if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs)
                __raw_writel(pad_ctrl, base + pad_ctrl_ofs);
+       else if ((pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs)
+               __raw_writel(0, base + pad_ctrl_ofs);
 
        return 0;
 }

I see your problem, and why this patch has solved it. My board also uses some pads, that are declared with NO_PAD_CTRL. I've applied your solution as well, but no luck. I see the same behaviour as before.

The fact, that I am, able to do dhcp (even without your change), and sometimes transfer files from some other host, makes me think, that my pad config isn't that broken. May be the problem is in the pad configs, some changed to PAD_CTRL_[2,4,5], some are NO_PAD_CTRL.

I don't know how the pad configuration influences pads, that are assigned to some imx peripheral, like the FEC. For example the PAD definition for the pads used for reception is inconsistent:

from iomux-mx51.h:

#define MX51_PAD_NANDF_D9__FEC_RDATA0 IOMUX_PAD(0x554, 0x16c, 0x12,
0x958, 0, MX51_PAD_CTRL_4)
#define MX51_PAD_EIM_EB3__FEC_RDATA1 IOMUX_PAD(0x46c, 0x0d8, 3, 0x95c,
0, NO_PAD_CTRL)
#define MX51_PAD_EIM_CS2__FEC_RDATA2 IOMUX_PAD(0x47c, 0x0e8, 3, 0x960,
0, NO_PAD_CTRL)
#define MX51_PAD_EIM_CS3__FEC_RDATA3 IOMUX_PAD(0x480, 0x0ec, 3, 0x964,
0, NO_PAD_CTRL)

I'd expect all RDATA signals all having the same pad control settings. They don't have, and I't doesn't make a difference, when I set them all to PAD_CTRL_4 as the first one.

Regards,
Christian

_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox

Sascha Hauer

maintainer

2012-07-16 14:22 UTC #3 lore raw

Quoted 48 lines · Christian Kapeller

Hi Eric,
Quoted 13 lines
same problem here. the problem comes from :
68b32be4926d3ab5b72036c0ceecef2f82aa0625 "i.MX51: Synchronize iomux header file from kernel"
as now most pins have NO_PAD_CTRL which means the pad doesn't get reconfigured and thus some pads to communicate with the FEC are no more working.
A dirty workaround to default PAD config is :
arch/arm/mach-imx/iomux-v3.c +0 -0
index 680d260..c21d8a2 100644
arch/arm/mach-imx/iomux-v3.c int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad) · line 52
Quoted 8 lines
arch/arm/mach-imx/iomux-v3.c +2 -0
@@ -45,6 +45,8 @@ int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
 
        if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs)
                __raw_writel(pad_ctrl, base + pad_ctrl_ofs);
+       else if ((pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs)
+               __raw_writel(0, base + pad_ctrl_ofs);
 
        return 0;
 }
I see your problem, and why this patch has solved it. My board also uses some pads, that are declared with NO_PAD_CTRL. I've applied your solution as well, but no luck. I see the same behaviour as before.
The fact, that I am, able to do dhcp (even without your change), and sometimes transfer files from some other host, makes me think, that my pad config isn't that broken. May be the problem is in the pad configs, some changed to PAD_CTRL_[2,4,5], some are NO_PAD_CTRL.
I don't know how the pad configuration influences pads, that are assigned to some imx peripheral, like the FEC. For example the PAD definition for the pads used for reception is inconsistent:
from iomux-mx51.h:
#define MX51_PAD_NANDF_D9__FEC_RDATA0 IOMUX_PAD(0x554, 0x16c, 0x12,
0x958, 0, MX51_PAD_CTRL_4)
#define MX51_PAD_EIM_EB3__FEC_RDATA1 IOMUX_PAD(0x46c, 0x0d8, 3, 0x95c,
0, NO_PAD_CTRL)
#define MX51_PAD_EIM_CS2__FEC_RDATA2 IOMUX_PAD(0x47c, 0x0e8, 3, 0x960,
0, NO_PAD_CTRL)
#define MX51_PAD_EIM_CS3__FEC_RDATA3 IOMUX_PAD(0x480, 0x0ec, 3, 0x964,
0, NO_PAD_CTRL)

Quoted 3 lines

I'd expect all RDATA signals all having the same pad control settings. They don't have, and I't doesn't make a difference, when I set them all to PAD_CTRL_4 as the first one.

The easiest way to get back to a working pin setup is probably to add a printk to the writel in iomux-v3.c in both the working and the nonworking barebox. It should be quite easy to figure out and bisect the differences then.
Note that you once you have figured it out you should send the same patch for the kernel aswell.

Sascha

Signature · 9 lines

Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox

Christian Kapeller

author

2012-07-17 09:50 UTC #4 lore raw

PATCH 1/1 imx51: fix pad definition used for fec communication.

Using the existing configuration, on the Ka-Ro i.MX51 board fec is reporting all kind of error conditions for ethernet reception.

Define FEC_RDATAn signals consistently.
Don't use hysteresis feature on any pins interfacing a mii phy chip. Don't use NO_PAD_CTRL value for used pads.

Signed-off-by Christian Kapeller <[email protected]>

---
 arch/arm/mach-imx/include/mach/iomux-mx51.h |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

arch/arm/mach-imx/include/mach/iomux-mx51.h +10 ~~-10~~

index 36c8989..f94c5a5 100644
@@ -187,7 +187,7 @@
 #define MX51_PAD_EIM_EB3__AUD5_RXC		IOMUX_PAD(0x46c, 0x0d8, 6, 0x8dc, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_EB3__CSI1_D3		IOMUX_PAD(0x46c, 0x0d8, 5, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_EB3__EIM_EB3		IOMUX_PAD(0x46c, 0x0d8, 0, __NA_, 0, NO_PAD_CTRL)
-#define MX51_PAD_EIM_EB3__FEC_RDATA1		IOMUX_PAD(0x46c, 0x0d8, 3, 0x95c, 0, NO_PAD_CTRL)
+#define MX51_PAD_EIM_EB3__FEC_RDATA1		IOMUX_PAD(0x46c, 0x0d8, 3, 0x95c, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_EIM_EB3__GPIO2_23		IOMUX_PAD(0x46c, 0x0d8, 1, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_EIM_EB3__GPT_CMPOUT2		IOMUX_PAD(0x46c, 0x0d8, 7, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_OE__EIM_OE			IOMUX_PAD(0x470, 0x0dc, 0, __NA_, 0, NO_PAD_CTRL)

@@ -199,26 +199,26 @@
 #define MX51_PAD_EIM_CS2__AUD5_TXD		IOMUX_PAD(0x47c, 0x0e8, 6, 0x8d8, 1, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS2__CSI1_D4		IOMUX_PAD(0x47c, 0x0e8, 5, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS2__EIM_CS2		IOMUX_PAD(0x47c, 0x0e8, 0, __NA_, 0, NO_PAD_CTRL)
-#define MX51_PAD_EIM_CS2__FEC_RDATA2		IOMUX_PAD(0x47c, 0x0e8, 3, 0x960, 0, NO_PAD_CTRL)
+#define MX51_PAD_EIM_CS2__FEC_RDATA2		IOMUX_PAD(0x47c, 0x0e8, 3, 0x960, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_EIM_CS2__GPIO2_27		IOMUX_PAD(0x47c, 0x0e8, 1, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_EIM_CS2__USBOTG_STP		IOMUX_PAD(0x47c, 0x0e8, 2, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS3__AUD5_RXD		IOMUX_PAD(0x480, 0x0ec, 6, 0x8d4, 1, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS3__CSI1_D5		IOMUX_PAD(0x480, 0x0ec, 5, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS3__EIM_CS3		IOMUX_PAD(0x480, 0x0ec, 0, __NA_, 0, NO_PAD_CTRL)
-#define MX51_PAD_EIM_CS3__FEC_RDATA3		IOMUX_PAD(0x480, 0x0ec, 3, 0x964, 0, NO_PAD_CTRL)
+#define MX51_PAD_EIM_CS3__FEC_RDATA3		IOMUX_PAD(0x480, 0x0ec, 3, 0x964, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_EIM_CS3__GPIO2_28		IOMUX_PAD(0x480, 0x0ec, 1, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_EIM_CS3__USBOTG_NXT		IOMUX_PAD(0x480, 0x0ec, 2, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS4__AUD5_TXC		IOMUX_PAD(0x484, 0x0f0, 6, 0x8e4, 1, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS4__CSI1_D6		IOMUX_PAD(0x484, 0x0f0, 5, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS4__EIM_CS4		IOMUX_PAD(0x484, 0x0f0, 0, __NA_, 0, NO_PAD_CTRL)
-#define MX51_PAD_EIM_CS4__FEC_RX_ER		IOMUX_PAD(0x484, 0x0f0, 3, 0x970, 0, MX51_PAD_CTRL_2)
+#define MX51_PAD_EIM_CS4__FEC_RX_ER		IOMUX_PAD(0x484, 0x0f0, 3, 0x970, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_EIM_CS4__GPIO2_29		IOMUX_PAD(0x484, 0x0f0, 1, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_EIM_CS4__USBOTG_CLK		IOMUX_PAD(0x484, 0x0f0, 2, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS5__AUD5_TXFS		IOMUX_PAD(0x488, 0x0f4, 6, 0x8e8, 1, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS5__CSI1_D7		IOMUX_PAD(0x488, 0x0f4, 5, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS5__DISP1_EXT_CLK		IOMUX_PAD(0x488, 0x0f4, 4, 0x904, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_CS5__EIM_CS5		IOMUX_PAD(0x488, 0x0f4, 0, __NA_, 0, NO_PAD_CTRL)
-#define MX51_PAD_EIM_CS5__FEC_CRS		IOMUX_PAD(0x488, 0x0f4, 3, 0x950, 0, MX51_PAD_CTRL_2)
+#define MX51_PAD_EIM_CS5__FEC_CRS		IOMUX_PAD(0x488, 0x0f4, 3, 0x950, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_EIM_CS5__GPIO2_30		IOMUX_PAD(0x488, 0x0f4, 1, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_EIM_CS5__USBOTG_DIR		IOMUX_PAD(0x488, 0x0f4, 2, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_EIM_DTACK__EIM_DTACK		IOMUX_PAD(0x48c, 0x0f8, 0, __NA_, 0, NO_PAD_CTRL)

@@ -259,14 +259,14 @@
 #define MX51_PAD_NANDF_RB1__SD4_CMD		IOMUX_PAD(0x4fc, 0x120, 0x15, __NA_, 0, MX51_SDHCI_PAD_CTRL)
 #define MX51_PAD_NANDF_RB2__DISP2_WAIT		IOMUX_PAD(0x500, 0x124, 5, 0x9a8, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_RB2__ECSPI2_SCLK		IOMUX_PAD(0x500, 0x124, 2, __NA_, 0, MX51_ECSPI_PAD_CTRL)
-#define MX51_PAD_NANDF_RB2__FEC_COL		IOMUX_PAD(0x500, 0x124, 1, 0x94c, 0, MX51_PAD_CTRL_2)
+#define MX51_PAD_NANDF_RB2__FEC_COL		IOMUX_PAD(0x500, 0x124, 1, 0x94c, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_NANDF_RB2__GPIO3_10		IOMUX_PAD(0x500, 0x124, 3, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_NANDF_RB2__NANDF_RB2		IOMUX_PAD(0x500, 0x124, 0, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_RB2__USBH3_H3_DP		IOMUX_PAD(0x500, 0x124, 0x17, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_RB2__USBH3_NXT		IOMUX_PAD(0x500, 0x124, 6, 0xa20, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_RB3__DISP1_WAIT		IOMUX_PAD(0x504, 0x128, 5, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_RB3__ECSPI2_MISO		IOMUX_PAD(0x504, 0x128, 2, __NA_, 0, MX51_ECSPI_PAD_CTRL)
-#define MX51_PAD_NANDF_RB3__FEC_RX_CLK		IOMUX_PAD(0x504, 0x128, 1, 0x968, 0, MX51_PAD_CTRL_2)
+#define MX51_PAD_NANDF_RB3__FEC_RX_CLK		IOMUX_PAD(0x504, 0x128, 1, 0x968, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_NANDF_RB3__GPIO3_11		IOMUX_PAD(0x504, 0x128, 3, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_NANDF_RB3__NANDF_RB3		IOMUX_PAD(0x504, 0x128, 0, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_RB3__USBH3_CLK		IOMUX_PAD(0x504, 0x128, 6, 0x9f8, 0, NO_PAD_CTRL)

@@ -313,7 +313,7 @@
 #define MX51_PAD_NANDF_CS7__NANDF_CS7		IOMUX_PAD(0x534, 0x14c, 0, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_CS7__SD3_CLK		IOMUX_PAD(0x534, 0x14c, 5, __NA_, 0, MX51_SDHCI_PAD_CTRL | PAD_CTL_HYS)
 #define MX51_PAD_NANDF_RDY_INT__ECSPI2_SS0	IOMUX_PAD(0x538, 0x150, 2, __NA_, 0, MX51_ECSPI_PAD_CTRL)
-#define MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK	IOMUX_PAD(0x538, 0x150, 1, 0x974, 0, MX51_PAD_CTRL_4)
+#define MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK	IOMUX_PAD(0x538, 0x150, 1, 0x974, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_NANDF_RDY_INT__GPIO3_24	IOMUX_PAD(0x538, 0x150, 3, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_NANDF_RDY_INT__NANDF_RDY_INT	IOMUX_PAD(0x538, 0x150, 0, 0x938, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_RDY_INT__SD3_CMD		IOMUX_PAD(0x538, 0x150, 0x15, __NA_, 0, MX51_SDHCI_PAD_CTRL)

@@ -337,7 +337,7 @@
 #define MX51_PAD_NANDF_D12__NANDF_D12		IOMUX_PAD(0x548, 0x160, 0, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_D12__PATA_DATA12		IOMUX_PAD(0x548, 0x160, 1, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_D12__SD3_DAT4		IOMUX_PAD(0x548, 0x160, 5, __NA_, 0, NO_PAD_CTRL)
-#define MX51_PAD_NANDF_D11__FEC_RX_DV		IOMUX_PAD(0x54c, 0x164, 2, 0x96c, 0, NO_PAD_CTRL)
+#define MX51_PAD_NANDF_D11__FEC_RX_DV		IOMUX_PAD(0x54c, 0x164, 2, 0x96c, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_NANDF_D11__GPIO3_29		IOMUX_PAD(0x54c, 0x164, 3, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_NANDF_D11__NANDF_D11		IOMUX_PAD(0x54c, 0x164, 0, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_D11__PATA_DATA11		IOMUX_PAD(0x54c, 0x164, 1, __NA_, 0, NO_PAD_CTRL)

@@ -346,7 +346,7 @@
 #define MX51_PAD_NANDF_D10__NANDF_D10		IOMUX_PAD(0x550, 0x168, 0, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_D10__PATA_DATA10		IOMUX_PAD(0x550, 0x168, 1, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_D10__SD3_DATA2		IOMUX_PAD(0x550, 0x168, 5, 0x944, 1, NO_PAD_CTRL)
-#define MX51_PAD_NANDF_D9__FEC_RDATA0		IOMUX_PAD(0x554, 0x16c, 0x12, 0x958, 0, MX51_PAD_CTRL_4)
+#define MX51_PAD_NANDF_D9__FEC_RDATA0		IOMUX_PAD(0x554, 0x16c, 0x2, 0x958, 0, MX51_PAD_CTRL_5)
 #define MX51_PAD_NANDF_D9__GPIO3_31		IOMUX_PAD(0x554, 0x16c, 3, __NA_, 0, MX51_GPIO_PAD_CTRL)
 #define MX51_PAD_NANDF_D9__NANDF_D9		IOMUX_PAD(0x554, 0x16c, 0, __NA_, 0, NO_PAD_CTRL)
 #define MX51_PAD_NANDF_D9__PATA_DATA9		IOMUX_PAD(0x554, 0x16c, 1, __NA_, 0, NO_PAD_CTRL)

Signature · 7 lines

1.7.5.4


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox