[En-Nut-Discussion] Can anyone check httpd example on AT91SAM7X-EK?

[Ulrich Prinz]

I investigated the problem a bit deeper:

First of all I have one board that boots in my small private network 
and it boots in the large company network too.
I have two other boards that do not boot in the company network. Both 
fail at regisstering the at91emac device.

First bug in the at91_emac.c driver at all is, that the PHY needs a 
second reset where the GPIO pins of the AT91 are set up as GPIO and 
preset the pins of the PHY to a certain configuration.
That is highly board specific as this is only valid for the combination 
of PHY and CPU. So the #ifdef must not be
#if defined(MCU_AT91_SAM7X) && (NIC_PHY_UID == DM9161A_ID)
it must be
#if defined(AT91SAM7X_EK)

The big problem is that this pin-configuration of the PHY is specific 
for each PHY. So I admit not to use this, what brings me to the next 
problem:
The PHYs can be set up by using MDIO interface. Therefore you need 
phy_inw() and phy_outw(). Looks like someone thougth that with using 
RMII any phy_outw is not available. I cannot find anything in the 
datasheets of SAMs or PHYs so I assume that with RMII reading and 
writing of PHY registers is possible too.
If we put that together to me it looks far more easy to reconfigure 
PHYs through the MDIO interface than to reboot them to read in the GPIO 
lines.
This may also reduce the boot up time for the Auto-Negotiation. The 
Switch will partition us out if we abort the initial handshake to a 
random configuration, then reset and start again negotiation.

I tested some switches and the time needed until link is up differs 
from 1..10s with high diversity per switch.

So the true solution might be to reprogram the PHY using MDIO interface 
or trying to use the hardware configuration by setting up the GPIOs 
fast enough at the system startup in a board specific init routine.

Ok, by patching the #if thing I got the EMAC booting up. But it still 
doesn't work with the httpserv.
The PHY is loosing the link with every Packet that is received. 
Conditions to follow:
- The DHCP sends aout the first request
- A response packet is coming in
- PHY looses link.

The interrupt routine continuously gets a status of RX packet pending, 
TX packet pending and after a while TX-Overflow. So it looks like the 
EMAC cannot send its packets, but the cause must be the received 
packet. There is no jabber or Remote Fault bit set in the PHY status at 
this time.

Nut/OS 4.9.9.0 HTTP Daemon...
[EMAC Init][EmacReset  BMCR=3100 EmacReset]
[probePhy set 0xffffffff  PHYID=0x0181b8a0  LIST 0x0181b8a0  BMCR=3100
 BMSR=7849
 BMSR=786d
 ANLPAR=45e1
 DSCSR=8208
OK]
Configure eth0...
->[1.DHCP-INIT]
->[1.DHCP-REBOOTING 10.201.49.232][DHCP-Send to 255.255.255.255] TX 
I:00000080 T:00000021 R:00000000 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100
I:00000002 T:00000021 R:00000002 BS:786d BM:3100

Now here might be again a bug in the driver:
 ANLPAR=45e1
The AT91EMAC is programmed according this registers content about the 
links speed and options. But the ANLPAR contains _all_ possible options 
that the link partner (the switch) supports. Assuming that the fastest 
option is the one that is actually selected is wrong. One has to find 
the right registers for the _actually_used_ link capabilities and 
program the EMAC registers exactly to that active features.
The right values are BMCR bit 13 for the speed and BMCR Bit 8 for 
duplex. Read specs carefully:
If AutoMDI(X) is selected, these bits _reflect_ the actual status of 
the link.

This directly leads to a future bug. Someone suggested to make 
AutoMDI(X) configureable by nutconf. Good idea, but you then have to 
set up the PHY BMCR register for the right values. And you have to 
configure the EMAC to the same setup. Instead of writing two separate 
functions, just reuse the readout of the BMCR values in probePhy() and 
don't make it dependent on the Auto feature.

I will check the AutoMDIX behavior if I find my old managable Switches 
in that any port can be configured for its features.

With all this things patched, the board that worked before still works 
fine. But the other boards that do not work, still do not work.
This remembers me that I have sometimes problems with my EIR board not 
connecting correctly to the network too. The LEDs then show unusal 
flashing too. It is different from the DA9161A PHY but the EMAC on the 
EIR is a different one from DACOM and it includes a PHY. That leads to 
the conclusion that the real root cause for this network behavior is 
still somwhere else. And it must be a problem that is either a timing 
or a supply problem. If I use different power supplies for the EIR the 
problem occures less or more.
With the AT91SAM7X-EK I didn't check for the power supply as it is USB 
powered. It doesn't make a difference if I use a PC or a Wallplug USB 
supply.

Best Regards
Ulrich