Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

What PHY address does your custom baseboard use?

-Mike

My custom board uses either PHY address 1 or 0 - both addresses cause the same problem.
I played around a little with the industrial base board and found that it does not suffer the same issue,
so there is most likely something in my hardware that causes a conflict.

To troubleshoot a little bit more, I downloaded MDK_2011-12-05
(which seems to be what the kernel on the MityDsp-L138 was built with).
I was able to buld it and load on my board with no issues (and ethernet works fine after I boot using tftp).

Unfortunately I need USB gadgets, and it seems like they are broken in that release. I get massive compile errors when attempting to build the modules. An other post indicated that the usb gadgets do work in version 3.2.x so it looks like I am back to trying to figure out what causes the original problem.

Any thoughts would be really appreciated.

Thanks,
Lars

So the industrial IO board uses PHY address 3 and the EMAC driver is configured to look for that MDIO interface prior to initiating EMAC transfers. You will need to modify your kernel (make your own baseboard file or modify the industrial I/O one) and alter the configuration to use the string "0:01" for PHY address configuration. You might also double check that the PHY is getting it's address correctly if it is bootstrapping it's address on power up via pins that are connected to the OMAP-L138. The OMAP-L138 pulls up most of it's interface pins following reset, and we've run into several situations where the pull up pins are contending with base board strapping resistors for PHYs that strap their address.

The U-Boot routine actually probes the PHY on power up (if you've configured it to use MII or RMII in the "config" command). It should print out the address of the PHYs it can locate. Can you see the network while in the u-Boot prompt?

For USB gadgets, you might look at our git repository and take the latest on the mitydsp-linux-3.2. We are about to commit additional patches to enable DMA support for the OTG CPPI 4.1 DMA controller (originally from TI) to this branch. I would be interested to see your compile errors. We've been using gadgets (RNDIS, gadgetfs, host, etc.) for the USB 2.0 port for several projects and haven't had any issues with the build.

-Mike

Mike,
Thanks for pointing that out - really helpful!
I can most definitely see the network (and boot from it) from U-Boot.
However, there is clearly some funny business going on with the PHY address;
U-Boot claims it finds the PHY at address 3, regardless of whether I
have it strapped at 0 or 1.
During the boot sequence, Linux claims it is talking to a PHY at address 3 as well.

Last night, I did a clean build of the 3.2.0 kernel. Using that build, I can now boot 3.2.0 with ethernet working
as expected. Since there is flaky hardware involved - I can't really say that the clean build made a difference.
(Until I figure this out, I will add a pullup to the base board to define set the PHY address to 3 - hopefully that
will take care of the flakiness...)

I will get the latest version of 3.2x from the git respository and forge on from there - hopefully there is a
shiny new usb ACM gadget in there that will help me out.

Thanks for your help!
Lars

Mike,

My reply is out of date but it is about that topic: PHY address configuration.

You said that PHY address is set to 0x03 on Industrial board.

When I look at 0-000268RI schematic, only PHYAD1 pin is pulled up. There is no pull-up on PHYAD0 pin of TLK100 chip (MII device).
So, I would expect PHY address to be 0x02 instead of 0x03 for the Industrial board.

Is there a pull-up on MityDSP board on MII_COL pin?

When OMAPL138 reset, the MII_COL pin should be 3 stated (See SPRUH77 TI manual). So, the weak pull-down within TLK100 should be enough to drive PHYAD0 to ground.

See page 15 of http://www.ti.com/lit/ds/slls931b/slls931b.pdf

We have our custom board based on Industrial board and the kernel reports that PHY address is 0x03 but I don't understand why.

Do I miss something?

Thanks

-François

François,

I too was confused about this but was unable to determine why the phy id becomes 0x03.

I checked the SoM schematic and the MII_COL pin is directly connected to the SoC with no pull ups.

U-boot specifically disables pull-ups and then does a reset on the phy inorder to allow the pull ups to work. Check the misc_init_r function in board/davinci/mityomapl138/mityomapl138.c. Its possible there is a bug in that code were we aren't disabling the MII_COL pull-up.

Thanks Jonathan to told me that I am not alone with that questioning.

The first revision of our custom board had a mistake and PHYAD4 what pulled-up instead of PHYAD1.
The PHYAD0 is not pulled is any direction (as on Industrial board).

The PHY address returned by the kernel is 0x11 in that case.

So, the "logic" is respected.

It did not yet look at U-Boot code that you indicate. It may explain what we are seeing.

Regards,

-François

I look at U-boot code and it doesn't explain what we are seeing.

When resetting the PHY device, only GPIO5¹⁵ is activated with pin mux. Other pins are left 3-stated.
Look at line 113 of board/davinci/mityomapl138/mityomapl138.c. Also, except for GPIO5¹⁵, changing the PUPD_ENA
values is useless in the part of misc_init_r function that handles MII reset.

We should have 0x20 as PHY address. But, it is not the case...

-François

Hi François,

In the datasheet for the TLK100PHP, Section 2.2 shows that the PHYAD0 pin has an internal pull-up, which is why it is reading a '1' (there are no pullups on the DevKit card, and we are tri-stating the MII_COL and RXD0-RXD4 pins while driving reset).

The schematic shows a note suggesting that the PHYAD[3:0] is 0001. That is an error, and it really should be PHYAD[4:1]. There are no provisions to alter PHYAD[ 0 ], which is a '1'. I am sorry for the confusion. The note should read PHYAD[4:0] = 00011, which is 3.

-Mike

Thanks Mike for answer.

I did not look at section 2.2 of TLK100PHP datasheet. It is my fault.

I read section "3.3 PHY address" where it said

"Because all the PHYAD[4:0] pins have weak internal pull-down resistors,
the default setting for the PHY address is 00000 (0x00h)."

TI is very misleading here...

However, the example shown in figure 3-1 is correct. It seems that I did not
catch that PHYAD0=1 in this example. My fault again.

So, the behaviour we see is now explained. And I am happy when the theory matches the reality!

Last details: Why PHY address is hardcoded for Industrial IO board within the kernel?

If I remove line 420 of MDK_2014-01-13/sw/ARM/linux/linux-davinci/arch/arm/mach-davinci/baseboard-industrialio.c,
the line that hardcodes the PHY address to 0x03, the kernel uses the detected PHY address no matter what it is.

It seems to be a more reliable approach because no body needs to handle PHY addressing.

Is there a conflict in some situation and it the the way that it was fixed?

Thanks again

-François

I believe the phy address was set in an earlier version of the kernel and it was carried forward. There is also the case where the baseboard has a switch which identifies itself as multiple phy addresses and thus you would need to specify the exact one.

There also may be a small time penalty in having the kernel search for the phy. But this would need to be quantified to really claim it as a problem.