Ethernet RMII1 Interface not working in Linux on Vybrid Board

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Ethernet RMII1 Interface not working in Linux on Vybrid Board

ソリューションへジャンプ
2,272件の閲覧回数
almagest
Contributor III

Hello.

We are using Yocto and Timesys BSP to build our custom Linux BSP. (Kernel 3.0.15)

The Kernel and ethernet works fine on the development kit VF65GS10 (with original iomuxes), but once we change from RMII0 to RMII1 interface for ethernet for the custom hardware, it does not work any more.

I've been over the definitions multiple times, but cannot see what's wrong.

We use the same setup/definitions in U-boot on the custom board, and there it works fine.

We have also verified that the external input clock is 50MHz.

Any tips or help would be very much appreciated!

Thanks for your time.

Regards

Andreas Eknes Lie

// declarations (excerpt from arch/arm/plat-mxc/include/mach/iomux-mvf.h)

#define MVF600_PAD0_PTA6__RMII_CLKOUT                           \

                 IOMUX_PAD(0x0000, 0x0000, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_OBE_ENABLE)

/*FEC1*/

#define MVF600_PAD54_PTC9__RMII1_MDC                            \

                 IOMUX_PAD(0x00D8, 0x00D8, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_OBE_ENABLE)

#define MVF600_PAD55_PTC10__RMII1_MDIO                          \

                 IOMUX_PAD(0x00DC, 0x00DC, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_OBE_IBE_ENABLE)

#define MVF600_PAD56_PTC11__RMII1_CRS_DV                        \

                 IOMUX_PAD(0x00E0, 0x00E0, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_IBE_ENABLE)

#define MVF600_PAD57_PTC12__RMII1_RXD1                          \

                 IOMUX_PAD(0x00E4, 0x00E4, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_IBE_ENABLE)

#define MVF600_PAD58_PTC13__RMII1_RXD0                          \

                 IOMUX_PAD(0x00E8, 0x00E8, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_IBE_ENABLE)

#define MVF600_PAD59_PTC14__RMII1_RXER                          \

                 IOMUX_PAD(0x00EC, 0x00EC, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_IBE_ENABLE)

#define MVF600_PAD60_PTC15__RMII1_TXD1                          \

                 IOMUX_PAD(0x00F0, 0x00F0, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_OBE_ENABLE)

#define MVF600_PAD61_PTC16__RMII1_TXD0                          \

                 IOMUX_PAD(0x00F4, 0x00F4, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_OBE_ENABLE)

#define MVF600_PAD62_PTC17__RMII1_TXEN                          \

                 IOMUX_PAD(0x00F8, 0x00F8, 1, 0x0000, 0, \

                                 MVF600_ENET_PAD_CTRL | PAD_CTL_OBE_ENABLE)

// definitions (excerpt from arch/arm/mach-mvf/board-twr-vf700.c)

// add the PTA6 RMII0_CLKOUT

MVF600_PAD0_PTA6__RMII_CLKOUT,

MVF600_PAD54_PTC9__RMII1_MDC,

MVF600_PAD55_PTC10__RMII1_MDIO,

MVF600_PAD56_PTC11__RMII1_CRS_DV,

MVF600_PAD57_PTC12__RMII1_RXD1,

MVF600_PAD58_PTC13__RMII1_RXD0,

MVF600_PAD59_PTC14__RMII1_RXER,

MVF600_PAD60_PTC15__RMII1_TXD1,

MVF600_PAD61_PTC16__RMII1_TXD0,

MVF600_PAD62_PTC17__RMII1_TXEN,

We have configured/designed the board the following way: (erratum e8052, page 75, alternative A)

http://cache.freescale.com/files/microcontrollers/doc/user_guide/VYBRIDHDUG.pdf

Similar issue as, but no PHY detected at all in our case

https://community.freescale.com/thread/318899#394874

We enabled both devices in the kernel configuration, just to be on the safe-side of things.

Kernel output:

..

eth0: no PHY, assuming direct connection to switch

PHY 0:00 not found

eth0: could not attach to PHY

IP-Config: Failed to open eth0

eth1: no PHY, assuming direct connection to switch

PHY 0:00 not found

eth1: could not attach to PHY

IP-Config: Failed to open eth1

IP-Config: No network devices available.

..

ラベル(3)
1 解決策
1,293件の閲覧回数
falstaff
Senior Contributor I

Hi Andreas,

On our Colibri VF50/VF61 we used to use the 3.0.15 kernel on our initial BSP too, along with FEC1 as Ethernet. I just checked our commit, not sure if this is the issue but it might be: It seems that our definition of MVF600_PAD0_PTA6__RMII_CLKOUT is slightly different from yours, the fourth parameter is 0x02F0, see also this commit:

linux-toradex.git - Linux kernel for Apalis and Colibri modules

--

Stefan

元の投稿で解決策を見る

0 件の賞賛
返信
6 返答(返信)
1,293件の閲覧回数
timesyssupport
Senior Contributor II

Hello Andreas,


What U-boot version are you working with?

What PHY are you working with?

What is the value of MVF600_ENET_PAD_CTRL?

Thank you,

Timesys Support

0 件の賞賛
返信
1,293件の閲覧回数
almagest
Contributor III

#define MVF600_ENET_PAD_CTRL    (PAD_CTL_DSE_47K_UP | PAD_CTL_SPEED_HIGH | \

        PAD_CTL_DSE_50ohm)

out of curiosity i checked the definition in the u-boot source;

#define VF610_ENET_PAD_CTRL    (PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_50ohm | \

                                PAD_CTL_OBE_IBE_ENABLE)

It seems they liberally define all pins with in and output buffers.

The PHY we use, is the same as on the devkit; KSZ8041NLI from Micrel

U-Boot: U-Boot 2015.04-dirty

(dirty since we added the external clock and pll there)

linux-timesys and build where cloned from

git://git.yoctoproject.org/meta-fsl-arm

rev: b4b950b

0 件の賞賛
返信
1,294件の閲覧回数
falstaff
Senior Contributor I

Hi Andreas,

On our Colibri VF50/VF61 we used to use the 3.0.15 kernel on our initial BSP too, along with FEC1 as Ethernet. I just checked our commit, not sure if this is the issue but it might be: It seems that our definition of MVF600_PAD0_PTA6__RMII_CLKOUT is slightly different from yours, the fourth parameter is 0x02F0, see also this commit:

linux-toradex.git - Linux kernel for Apalis and Colibri modules

--

Stefan

0 件の賞賛
返信
1,293件の閲覧回数
karina_valencia
NXP Apps Support
NXP Apps Support

almagest​ can you share the status of this case?

0 件の賞賛
返信
1,293件の閲覧回数
almagest
Contributor III

We have got the RMII with external clock to work by on the development kit (rev. G). To achieve this we have soldered a 33uF Capacitor on top of C3 on the TWR-SER (to adjust reset of ethernet PHY during powerup).

In addition to this, we also have to connected pins 2 on J2 and 4 on J3 on the TWR-SER with a cable to route the PLL5 to the PHY.

We are using the iomux adjustment noted by falstaff​, although the original iomux i had works just as fine.

The main difference now between our custom board and the devkit comes down to the fact that the devkit use FEC0, and the custom board use FEC1.

So both yes and no, its working as it should on the devkit, but i need to figure out how to get the Linux Kernel to use FEC1 pins and such instead of FEC0 on our custom board.

Any tips would be greatly appreciated.

Edited: FEC instead of eth

0 件の賞賛
返信
1,293件の閲覧回数
almagest
Contributor III

And now its finally working.

I really got to hand it to falstaff​, the git commit supplied made all the difference. We didn't realize that the the FEC1 shared mdio with FEC0, and needs to be configured through the FEC0. By looking at the fixes in the git commit, this was overcome.

Thank you all and have a splendid day.