* tx51 ethernet regression @ 2012-07-16 11:28 Christian Kapeller 2012-07-16 11:44 ` Eric Bénard 0 siblings, 1 reply; 5+ messages in thread From: Christian Kapeller @ 2012-07-16 11:28 UTC (permalink / raw) To: barebox 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 -- Christian Kapeller cmotion GmbH Kriehubergasse 16 1050 Wien / Austria http://www.cmotion.eu christian.kapeller@cmotion.eu Phone: +43 1 789 1096 38 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tx51 ethernet regression 2012-07-16 11:28 tx51 ethernet regression Christian Kapeller @ 2012-07-16 11:44 ` Eric Bénard 2012-07-16 12:52 ` Christian Kapeller 0 siblings, 1 reply; 5+ messages in thread From: Eric Bénard @ 2012-07-16 11:44 UTC (permalink / raw) To: barebox Hi Christian, Le Mon, 16 Jul 2012 13:28:13 +0200, Christian Kapeller <christian.kapeller@cmotion.eu> a écrit : > 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? > 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 : diff --git a/arch/arm/mach-imx/iomux-v3.c b/arch/arm/mach-imx/iomux-v3.c index 680d260..c21d8a2 100644 --- a/arch/arm/mach-imx/iomux-v3.c +++ b/arch/arm/mach-imx/iomux-v3.c @@ -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 barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tx51 ethernet regression 2012-07-16 11:44 ` Eric Bénard @ 2012-07-16 12:52 ` Christian Kapeller 2012-07-16 14:21 ` Sascha Hauer 0 siblings, 1 reply; 5+ messages in thread From: Christian Kapeller @ 2012-07-16 12:52 UTC (permalink / raw) To: Eric Bénard; +Cc: barebox Hi Eric, thanks for the prompt reply. > Le Mon, 16 Jul 2012 13:28:13 +0200, > Christian Kapeller <christian.kapeller@cmotion.eu> a écrit : >> 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? >> > 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 : > diff --git a/arch/arm/mach-imx/iomux-v3.c b/arch/arm/mach-imx/iomux-v3.c > index 680d260..c21d8a2 100644 > --- a/arch/arm/mach-imx/iomux-v3.c > +++ b/arch/arm/mach-imx/iomux-v3.c > @@ -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 barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tx51 ethernet regression 2012-07-16 12:52 ` Christian Kapeller @ 2012-07-16 14:21 ` Sascha Hauer 2012-07-17 9:49 ` [PATCH] imx51: fix pad definition used for fec communication Christian Kapeller 0 siblings, 1 reply; 5+ messages in thread From: Sascha Hauer @ 2012-07-16 14:21 UTC (permalink / raw) To: Christian Kapeller; +Cc: barebox On Mon, Jul 16, 2012 at 02:52:22PM +0200, Christian Kapeller wrote: > Hi Eric, > > > 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 : > > diff --git a/arch/arm/mach-imx/iomux-v3.c b/arch/arm/mach-imx/iomux-v3.c > > index 680d260..c21d8a2 100644 > > --- a/arch/arm/mach-imx/iomux-v3.c > > +++ b/arch/arm/mach-imx/iomux-v3.c > > @@ -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. 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 -- 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 barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] imx51: fix pad definition used for fec communication. 2012-07-16 14:21 ` Sascha Hauer @ 2012-07-17 9:49 ` Christian Kapeller 0 siblings, 0 replies; 5+ messages in thread From: Christian Kapeller @ 2012-07-17 9:49 UTC (permalink / raw) To: barebox 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 <christian.kapeller@cmotion.eu> --- arch/arm/mach-imx/include/mach/iomux-mx51.h | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-imx/include/mach/iomux-mx51.h b/arch/arm/mach-imx/include/mach/iomux-mx51.h index 36c8989..f94c5a5 100644 --- a/arch/arm/mach-imx/include/mach/iomux-mx51.h +++ b/arch/arm/mach-imx/include/mach/iomux-mx51.h @@ -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) -- 1.7.5.4 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-07-17 9:50 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-16 11:28 tx51 ethernet regression Christian Kapeller 2012-07-16 11:44 ` Eric Bénard 2012-07-16 12:52 ` Christian Kapeller 2012-07-16 14:21 ` Sascha Hauer 2012-07-17 9:49 ` [PATCH] imx51: fix pad definition used for fec communication Christian Kapeller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox