[U-Boot] TFTP timeouts, i.mx fec problem?

[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

Hi everyone,

I have been testing for a while now on the i.mx28 evk, and I noticed
that almost all tftp transfers take some time before they actually
start. It will show a 'T' as first character, then followed by '#'
chars. After enabling some debug info, it appeared that it would always
start by sending an ARP request, but this ARP message does not get sent
actually (monitored with Wireshark). After 5 seconds the 2nd ARP request
is sent (this does get traced by Wireshark) and also responded and from
that point all goes well.

When tracing the code, it could see that fec_send is called for the 1st
ARP request and also the return value indicates that sending should have
been succeeded (fec_send: status 0xc00 index 0 ret 0). But no package is
actually sent. My first guess would be that it has something to do with
the TBD / DMA part. The fec_tbd_init also shows some note about a rare
hardware condition regarding the WRAP bit (all in
drivers/net/fec_mxc.c). Could it be that there is still another issue
regarding the chip that causes this? If I do a tftp transfer from linux
on the same board and in the same network, it does start immediately.

=======================DEBUG LOG===========================
U-Boot > tftp versions.ini
eth_halt: wait for stop regs
eth_halt: done
Trying FEC0
fec_init
fec_tbd_init
fec_mii_setspeed: mii_speed 0000003c
fec_open: fec_open(dev)
fec_open:Speed=100
TFTP blocksize = 1468, timeout = 5000 ms
TFTP from server 192.168.0.100; our IP address is 192.168.0.109
Filename 'versions.ini'.
Loading: send option "timeout 5"
sending ARP for 192.168.0.100
ARP broadcast 1
fec_send: status 0xc00 index 0 ret 0
T send option "timeout 5"
sending ARP for 192.168.0.100
ARP broadcast 1
fec_send: status 0x2c00 index 1 ret 0
Got ARP REPLY, set eth addr (00:0c:29:65:b4:8a)
fec_send: status 0xc00 index 0 ret 0
received UDP (to=192.168.0.109, from=192.168.0.100, len=53)
Got OACK: timeout 5
Blocksize ack: 1468, 1468
sending UDP to 192.168.0.100/00:0c:29:65:b4:8a
fec_send: status 0x2c00 index 1 ret 0
received UDP (to=192.168.0.109, from=192.168.0.100, len=100)
#sending UDP to 192.168.0.100/00:0c:29:65:b4:8a
fec_send: status 0xc00 index 0 ret 0

         0 Bytes/s
done
Bytes transferred = 68 (44 hex)
eth_halt: wait for stop regs
eth_halt: done
U-Boot >
==========================================================

Thanks in advance for any comments. Regards,

Ruud

[U-Boot] TFTP timeouts, i.mx fec problem?

[Wolfgang Denk]

Dear Ruud,

In message <15AE5A936F5E3A42A9144E66875A0A893090E4@server1-derijp.CLB-Benelux.lokaal> you wrote:
> 
> I have been testing for a while now on the i.mx28 evk, and I noticed
> that almost all tftp transfers take some time before they actually
> start. It will show a 'T' as first character, then followed by '#'
> chars. After enabling some debug info, it appeared that it would always
> start by sending an ARP request, but this ARP message does not get sent
> actually (monitored with Wireshark). After 5 seconds the 2nd ARP request
> is sent (this does get traced by Wireshark) and also responded and from
> that point all goes well.

This is a known problem on some hardware.  We usually work around this
by defining CONFIG_ARP_TIMEOUT in the board config file.  Try setting
something like

	#define CONFIG_ARP_TIMEOUT    200UL

> When tracing the code, it could see that fec_send is called for the 1st
> ARP request and also the return value indicates that sending should have
> been succeeded (fec_send: status 0xc00 index 0 ret 0). But no package is
> actually sent. My first guess would be that it has something to do with
> the TBD / DMA part. The fec_tbd_init also shows some note about a rare

I'm not sure about that.  It appears to depend on the PHY used on the
hardware, in combination on which switch you connect the system to,
and eventually a few more parameters including the phase of moon.  My
speculation is that in some cases the PHY may enter a low-power or
idle state if not used, and drops the first packet while still waking
up.

> drivers/net/fec_mxc.c). Could it be that there is still another issue
> regarding the chip that causes this? If I do a tftp transfer from linux
> on the same board and in the same network, it does start immediately.

All I can say is that (1) this depends on the hardware and (2) if you
have a combinatiuon of hardware where it happens, then it happens
reliably.  It would be great if you have time to investigate and find
the real cause of the problem.  The CONFIG_ARP_TIMEOUT workaround is a
bit ugly, but works pretty well.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The whole problem with the world is  that  fools  and  fanatics  are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell

[U-Boot] TFTP timeouts, i.mx fec problem?

[Stefano Babic]

On 31/05/2013 08:56, Ruud Commandeur wrote:
> Hi everyone,
> 

Hi Ruud,

> When tracing the code, it could see that fec_send is called for the 1st
> ARP request and also the return value indicates that sending should have
> been succeeded (fec_send: status 0xc00 index 0 ret 0). But no package is
> actually sent. My first guess would be that it has something to do with
> the TBD / DMA part. The fec_tbd_init also shows some note about a rare
> hardware condition regarding the WRAP bit (all in
> drivers/net/fec_mxc.c). Could it be that there is still another issue
> regarding the chip that causes this? If I do a tftp transfer from linux
> on the same board and in the same network, it does start immediately.

At first glance the problem should be with the set up of the phy. It
could take longer as expected, or there are some issues with the
specific PHY of the board. An issue in general code of FEC driver is not
probable, because the same code runs on most of i.MXes without problems.

[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

Stefano, Wolfgang,

Thanks for your comments. The CONFIG_ARP_TIMEOUT was not set, so it will
take the default of 5 seconds. This is also the time it takes for the
first timeout. If I add a

	#define CONFIG_ARP_TIMEOUT    200UL

to my board config, I see the ARP request succeed after 2 to 4 attempts.
I always see only one ARP request in Wireshark. Apparently it takes 200
- 600 msecs for the phy to wake up and respond (as Wolfgang assumes as
possible and very plausible cause).

Increasing the ARP_TIMEOUT to some high value like 15000UL has no use,
the 5 seonds tftp timeout comes in earier and a new ARP request is sent
(which is answered as before).

So adding this timeout define will speed things up, and I guess I should
either also increase the CONFIG_NET_RETRY_COUNT or set the ARP_TIMEOUT
to 400 to prevent exceeding the retry count.

But of course it would be nicer to fix the actual cause. I could try and
find a way to keep the phy alive or at least try to proof that it is the
phy (the LAN8720A) that causes this. To be continued...

Regards,

Ruud


 

> -----Oorspronkelijk bericht-----
> Van: Stefano Babic [mailto:sbabic at denx.de] 
> Verzonden: vrijdag 31 mei 2013 10:50
> Aan: Ruud Commandeur
> CC: U-Boot list; sbabic at denx.de
> Onderwerp: Re: TFTP timeouts, i.mx fec problem?
> 
> On 31/05/2013 08:56, Ruud Commandeur wrote:
> > Hi everyone,
> > 
> 
> Hi Ruud,
> 
> > When tracing the code, it could see that fec_send is called 
> for the 1st
> > ARP request and also the return value indicates that 
> sending should have
> > been succeeded (fec_send: status 0xc00 index 0 ret 0). But 
> no package is
> > actually sent. My first guess would be that it has 
> something to do with
> > the TBD / DMA part. The fec_tbd_init also shows some note 
> about a rare
> > hardware condition regarding the WRAP bit (all in
> > drivers/net/fec_mxc.c). Could it be that there is still 
> another issue
> > regarding the chip that causes this? If I do a tftp 
> transfer from linux
> > on the same board and in the same network, it does start 
> immediately.
> 
> At first glance the problem should be with the set up of the phy. It
> could take longer as expected, or there are some issues with the
> specific PHY of the board. An issue in general code of FEC 
> driver is not
> probable, because the same code runs on most of i.MXes 
> without problems.
> From your report, it looks like that the link of the phy is not yet
> active when the fec_send is called, and then no ARP message is sent.
> Could you try setting #define CONFIG_ARP_TIMEOUT to some high value
> (when it is set, the value is often 200mS) to check if the issue
> disappears ?
> 
> Best regards,
> Stefano Babic
> 
> -- 
> =====================================================================
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================
> 

[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

No real success here yet. By using a scope I did see that at least the
MAC is trying to send the 1st packet (activity on RMII TXD part). On the
Phy, the clock is running, LED's are blinking, but the 1st packet
doesn't come out. Although: occasionally it does. Also no clues found in
the datasheet of the phy.

For now, I have set the ARP Timeout to 200 msecs and the retries to 15.
Maybe next week I give it another try with some fresh thoughts.

Regards,

Ruud

> -----Oorspronkelijk bericht-----
> Van: Ruud Commandeur 
> Verzonden: vrijdag 31 mei 2013 12:17
> Aan: 'Stefano Babic'
> CC: U-Boot list; 'Wolfgang Denk'
> Onderwerp: RE: TFTP timeouts, i.mx fec problem?
> 
> Stefano, Wolfgang,
> 
> Thanks for your comments. The CONFIG_ARP_TIMEOUT was not set, 
> so it will take the default of 5 seconds. This is also the 
> time it takes for the first timeout. If I add a
> 
> 	#define CONFIG_ARP_TIMEOUT    200UL
> 
> to my board config, I see the ARP request succeed after 2 to 
> 4 attempts. I always see only one ARP request in Wireshark. 
> Apparently it takes 200 - 600 msecs for the phy to wake up 
> and respond (as Wolfgang assumes as possible and very 
> plausible cause).
> 
> Increasing the ARP_TIMEOUT to some high value like 15000UL 
> has no use, the 5 seonds tftp timeout comes in earier and a 
> new ARP request is sent (which is answered as before).
> 
> So adding this timeout define will speed things up, and I 
> guess I should either also increase the 
> CONFIG_NET_RETRY_COUNT or set the ARP_TIMEOUT to 400 to 
> prevent exceeding the retry count.
> 
> But of course it would be nicer to fix the actual cause. I 
> could try and find a way to keep the phy alive or at least 
> try to proof that it is the phy (the LAN8720A) that causes 
> this. To be continued...
> 
> Regards,
> 
> Ruud
> 
> 
>  
> 
> > -----Oorspronkelijk bericht-----
> > Van: Stefano Babic [mailto:sbabic at denx.de] 
> > Verzonden: vrijdag 31 mei 2013 10:50
> > Aan: Ruud Commandeur
> > CC: U-Boot list; sbabic at denx.de
> > Onderwerp: Re: TFTP timeouts, i.mx fec problem?
> > 
> > On 31/05/2013 08:56, Ruud Commandeur wrote:
> > > Hi everyone,
> > > 
> > 
> > Hi Ruud,
> > 
> > > When tracing the code, it could see that fec_send is called 
> > for the 1st
> > > ARP request and also the return value indicates that 
> > sending should have
> > > been succeeded (fec_send: status 0xc00 index 0 ret 0). But 
> > no package is
> > > actually sent. My first guess would be that it has 
> > something to do with
> > > the TBD / DMA part. The fec_tbd_init also shows some note 
> > about a rare
> > > hardware condition regarding the WRAP bit (all in
> > > drivers/net/fec_mxc.c). Could it be that there is still 
> > another issue
> > > regarding the chip that causes this? If I do a tftp 
> > transfer from linux
> > > on the same board and in the same network, it does start 
> > immediately.
> > 
> > At first glance the problem should be with the set up of the phy. It
> > could take longer as expected, or there are some issues with the
> > specific PHY of the board. An issue in general code of FEC 
> > driver is not
> > probable, because the same code runs on most of i.MXes 
> > without problems.
> > From your report, it looks like that the link of the phy is not yet
> > active when the fec_send is called, and then no ARP message is sent.
> > Could you try setting #define CONFIG_ARP_TIMEOUT to some high value
> > (when it is set, the value is often 200mS) to check if the issue
> > disappears ?
> > 
> > Best regards,
> > Stefano Babic
> > 
> > -- 
> > 
> =====================================================================
> > DENX Software Engineering GmbH,     MD: Wolfgang Denk & 
> Detlev Zundel
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 
> Groebenzell, Germany
> > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: 
> sbabic at denx.de
> > 
> =====================================================================
> > 

[U-Boot] TFTP timeouts, i.mx fec problem?

[Wolfgang Denk]

Dear Stefano Babic,

In message <51A86445.3040703@denx.de> you wrote:
>
> At first glance the problem should be with the set up of the phy. It
> could take longer as expected, or there are some issues with the
> specific PHY of the board. An issue in general code of FEC driver is not
> probable, because the same code runs on most of i.MXes without problems.

Well, we do have this first-ARP-failing problem on a number of boards,
and especially the i.MX based boards appear to be affected - just
check which boards set CONFIG_ARP_TIMEOUT in their board configs:

	mx31ads
	mx35pdk
	mx51evk
	mx53ard
	mx53evk
	mx53loco
	mx53smd
	mx6qarm2
	mx6qsabre
	qong
	woodburn

Actually these are only_ i.MX based boards!

> From your report, it looks like that the link of the phy is not yet
> active when the fec_send is called, and then no ARP message is sent.

The question is if there is no better way to wait for the PHY to
become (really) ready?

> Could you try setting #define CONFIG_ARP_TIMEOUT to some high value
> (when it is set, the value is often 200mS) to check if the issue
> disappears ?

Indeed, this should help.  But it remains just a workaround, it ain't
a real fix.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I can't say I've ever been lost, but I was bewildered once for  three
days.                                     - Daniel Boone (Attributed)

[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

Dear Wolfgang, Stefano,

I'm pretty sure I found the cause:

For each tftp transfer the ethernet part is re-initialised. This means
that also fec_init is called. And in fec_init this piece of code
resides:

#ifndef CONFIG_PHYLIB
	if (fec->xcv_type != SEVENWIRE)
		miiphy_restart_aneg(dev);
#endif

This means (in this case) that miiphy_restart_aneg() is called. And here
the phy gets a software reset and autonegotiation restart command, wich
can take up to 500 msces according to the datasheet. So when we would
like to send out the 1st ARP request, the phy is busy with restart and
negotiation. If I skip these commands, any tftp transfer is fast as
lightning! About 150 msecs between pressing enter and the completion of
a small file (68 bytes).

Of course, re-initialisation of all parts for each transfer sounds like
the safest solution. But perhaps the phy could only be reset /
initialised once after start-up. Would this be an option?

Regards,

Ruud

> -----Oorspronkelijk bericht-----
> Van: Wolfgang Denk [mailto:wd at denx.de] 
> Verzonden: vrijdag 31 mei 2013 16:19
> Aan: Stefano Babic
> CC: Ruud Commandeur; U-Boot list
> Onderwerp: Re: [U-Boot] TFTP timeouts, i.mx fec problem?
> 
> Dear Stefano Babic,
> 
> In message <51A86445.3040703@denx.de> you wrote:
> >
> > At first glance the problem should be with the set up of the phy. It
> > could take longer as expected, or there are some issues with the
> > specific PHY of the board. An issue in general code of FEC 
> driver is not
> > probable, because the same code runs on most of i.MXes 
> without problems.
> 
> Well, we do have this first-ARP-failing problem on a number of boards,
> and especially the i.MX based boards appear to be affected - just
> check which boards set CONFIG_ARP_TIMEOUT in their board configs:
> 
> 	mx31ads
> 	mx35pdk
> 	mx51evk
> 	mx53ard
> 	mx53evk
> 	mx53loco
> 	mx53smd
> 	mx6qarm2
> 	mx6qsabre
> 	qong
> 	woodburn
> 
> Actually these are only_ i.MX based boards!
> 
> > From your report, it looks like that the link of the phy is not yet
> > active when the fec_send is called, and then no ARP message is sent.
> 
> The question is if there is no better way to wait for the PHY to
> become (really) ready?
> 
> > Could you try setting #define CONFIG_ARP_TIMEOUT to some high value
> > (when it is set, the value is often 200mS) to check if the issue
> > disappears ?
> 
> Indeed, this should help.  But it remains just a workaround, it ain't
> a real fix.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> I can't say I've ever been lost, but I was bewildered once for  three
> days.                                     - Daniel Boone (Attributed)
> 

[U-Boot] TFTP timeouts, i.mx fec problem?

[Stefano Babic]

Hi Ruud,

On 31/05/2013 16:36, Ruud Commandeur wrote:
> Dear Wolfgang, Stefano,
> 
> I'm pretty sure I found the cause:
> 
> For each tftp transfer the ethernet part is re-initialised. This means
> that also fec_init is called. And in fec_init this piece of code
> resides:
> 
> #ifndef CONFIG_PHYLIB
> 	if (fec->xcv_type != SEVENWIRE)
> 		miiphy_restart_aneg(dev);
> #endif
> 

Indeed, this is wanted. As design, U-Boot should not touch any interface
that is not needed and must close/reset the interface after usage. The
main reason is that the kernel is expecting a fresh powered on system,
and we get a lot of cases (USB, for instance) when the kernel cannot go
on because the bootloader let the controller in an unknown status.

> This means (in this case) that miiphy_restart_aneg() is called. And here
> the phy gets a software reset and autonegotiation restart command, wich
> can take up to 500 msces according to the datasheet. So when we would
> like to send out the 1st ARP request, the phy is busy with restart and
> negotiation. If I skip these commands, any tftp transfer is fast as
> lightning! About 150 msecs between pressing enter and the completion of
> a small file (68 bytes).
> 
> Of course, re-initialisation of all parts for each transfer sounds like
> the safest solution.

We discussed this issue many times, yes.

> But perhaps the phy could only be reset /
> initialised once after start-up. Would this be an option?

I know that there is an exception using netconsole - if the FEC driver
stops after each packet, it could not work. But again, letting the
controller in a well known status should be a must before booting the
kernel. In current code, eth_halt() is called before booting linux only
if NETCONSOLE is activated (common/cmd_bootm.c).

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] TFTP timeouts, i.mx fec problem?

[Stefano Babic]

Hi Wolfgang,
>
>> From your report, it looks like that the link of the phy is not yet
>> active when the fec_send is called, and then no ARP message is sent.
> 
> The question is if there is no better way to wait for the PHY to
> become (really) ready?

The phy is reinitialized after each transaction - the safiest condition
to boot afterwards the kernel. Or we need a way to stop the phy only
before booting, letting it on for the whole time. But again, this opens
other issues, because we cannot get as in linux if the lan cable is
removed (or worse, if it is connected to another switch with a different
speed).

> 
>> Could you try setting #define CONFIG_ARP_TIMEOUT to some high value
>> (when it is set, the value is often 200mS) to check if the issue
>> disappears ?
> 
> Indeed, this should help.  But it remains just a workaround, it ain't
> a real fix.

Right ;-(

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] TFTP timeouts, i.mx fec problem?

[Fabio Estevam]

Hi Stefano,

On Fri, May 31, 2013 at 12:46 PM, Stefano Babic <sbabic@denx.de> wrote:

> The phy is reinitialized after each transaction - the safiest condition
> to boot afterwards the kernel. Or we need a way to stop the phy only
> before booting, letting it on for the whole time. But again, this opens
> other issues, because we cannot get as in linux if the lan cable is
> removed (or worse, if it is connected to another switch with a different
> speed).

In the kernel we can reset the fec phy, so that we can always
guarantee it is on a known-state.

Regards,

Fabio Estevam

[U-Boot] TFTP timeouts, i.mx fec problem?

[Wolfgang Denk]

Dear Stefano,

[Joe added to Cc: list]

In message <51A8C479.6010309@denx.de> you wrote:
> 
> > This means (in this case) that miiphy_restart_aneg() is called. And here
> > the phy gets a software reset and autonegotiation restart command, wich
> > can take up to 500 msces according to the datasheet. So when we would
> > like to send out the 1st ARP request, the phy is busy with restart and
> > negotiation. If I skip these commands, any tftp transfer is fast as
> > lightning! About 150 msecs between pressing enter and the completion of
> > a small file (68 bytes).
> > 
> > Of course, re-initialisation of all parts for each transfer sounds like
> > the safest solution.
> 
> We discussed this issue many times, yes.

I still wonder if we should not be able to wait until the PHY has
complete auto-negotiation, before we send the first packet.  There
should be some status bit available we could poll for, rathr than
relying on a delay (which will always have to be tuned for the worst
case)?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quote from a recent meeting:   "We are going to continue having these
meetings everyday until I find out why no work is getting done."

[U-Boot] TFTP timeouts, i.mx fec problem?

[Wolfgang Denk]

Dear Stefano Babic,

In message <51A8C5DA.3090605@denx.de> you wrote:
>
> > The question is if there is no better way to wait for the PHY to
> > become (really) ready?
> 
> The phy is reinitialized after each transaction - the safiest condition
> to boot afterwards the kernel. Or we need a way to stop the phy only

Yes, that is clear, we fully agree on that.

But can we not test for "autoneogitation completed, link up and
running" before we send the first packet?

Or rather - why do we have this issue appearently only on i.MX?  We
don't see this on other ARM or on PowerPC?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of anthropomorphic terminology when  dealing  with  computing
systems is a symptom of professional immaturity.   -- Edsger Dijkstra

[U-Boot] TFTP timeouts, i.mx fec problem?

[Troy Kisky]

On 5/31/2013 11:58 AM, Wolfgang Denk wrote:
> Dear Stefano Babic,
>
> In message <51A8C5DA.3090605@denx.de> you wrote:
>>> The question is if there is no better way to wait for the PHY to
>>> become (really) ready?
>> The phy is reinitialized after each transaction - the safiest condition
>> to boot afterwards the kernel. Or we need a way to stop the phy only
> Yes, that is clear, we fully agree on that.
>
> But can we not test for "autoneogitation completed, link up and
> running" before we send the first packet?
>
> Or rather - why do we have this issue appearently only on i.MX?  We
> don't see this on other ARM or on PowerPC?
>
> Best regards,
>
> Wolfgang Denk
>
Think of this as incentive to convert to the board to  PHYLIB.

Troy

[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

In fact, it does wait for the link-up bit in miiphy_wait_aneg( ), which is called from fec_open. So after the init and before starting to send the first packet, you notice a delay for about half as second (enabled some debug printing) waiting for this bit to get set and then the phy should be up and running. I tried adding to wait for the the auto-neg complete bit as well, but this doesn't solve it. For some reason, the phy needs like 200 - 600 msecs extra in most cases before the 1st packet can be sent.

Some other remark: I get the idea of starting the kernel with a "virgin-like" phy and mac, which I will not argue about. But in fact the phy is reset and initialised bef?re each transfer. After the transfer, the mac is halted, but the phy is not reset again. Also, I am pretty sure (sorry, I'm not at the office right now), that the phy is reset if the kernel starts. I know this because I did some tweaking to the evk dts, where the phy reset pulse can be configured:

		mac0: ethernet at 800f0000 {
			phy-mode = "rmii";
			pinctrl-names = "default";
			pinctrl-0 = <&mac0_pins_a>;
			phy-supply = <&reg_fec_3v3>;
			phy-reset-gpios = <&gpio4 13 0>;
			phy-reset-duration = <100>;
			status = "okay";
		};

Regards,

Ruud


-----Oorspronkelijk bericht-----
Van: Troy Kisky [mailto:troy.kisky at boundarydevices.com]
Verzonden: vr 31-5-2013 21:09
Aan: Wolfgang Denk
CC: Stefano Babic; Ruud Commandeur; U-Boot list
Onderwerp: Re: [U-Boot] TFTP timeouts, i.mx fec problem?
 
On 5/31/2013 11:58 AM, Wolfgang Denk wrote:
> Dear Stefano Babic,
>
> In message <51A8C5DA.3090605@denx.de> you wrote:
>>> The question is if there is no better way to wait for the PHY to
>>> become (really) ready?
>> The phy is reinitialized after each transaction - the safiest condition
>> to boot afterwards the kernel. Or we need a way to stop the phy only
> Yes, that is clear, we fully agree on that.
>
> But can we not test for "autoneogitation completed, link up and
> running" before we send the first packet?
>
> Or rather - why do we have this issue appearently only on i.MX?  We
> don't see this on other ARM or on PowerPC?
>
> Best regards,
>
> Wolfgang Denk
>
Think of this as incentive to convert to the board to  PHYLIB.

Troy

[U-Boot] TFTP timeouts, i.mx fec problem?

[Fabio Estevam]

Hi Ruud,

On Fri, May 31, 2013 at 3:56 AM, Ruud Commandeur <RCommandeur@clb.nl> wrote:
> Hi everyone,
>
> I have been testing for a while now on the i.mx28 evk, and I noticed
> that almost all tftp transfers take some time before they actually
> start. It will show a 'T' as first character, then followed by '#'

Besides the initial timeout you mentioned, I also see some timeouts
during the kernel transfer.

I have just sent two patches converting mx28evk to use phylib, but I
still see the timeouts there.

I see that in the kernel there is a workaround for LAN8270 low por
mode and I will try it when I have a chance.

Please let me know if you make any progress on this.

Regards,

Fabio Estevam

[U-Boot] TFTP timeouts, i.mx fec problem?

[Marek Vasut]

Dear Fabio Estevam,

> Hi Ruud,
> 
> On Fri, May 31, 2013 at 3:56 AM, Ruud Commandeur <RCommandeur@clb.nl> wrote:
> > Hi everyone,
> > 
> > I have been testing for a while now on the i.mx28 evk, and I noticed
> > that almost all tftp transfers take some time before they actually
> > start. It will show a 'T' as first character, then followed by '#'
> 
> Besides the initial timeout you mentioned, I also see some timeouts
> during the kernel transfer.
> 
> I have just sent two patches converting mx28evk to use phylib, but I
> still see the timeouts there.
> 
> I see that in the kernel there is a workaround for LAN8270 low por
> mode and I will try it when I have a chance.
> 
> Please let me know if you make any progress on this.

I'm also having issues when pulling stuff from my main system via TFTP 
sometimes. This is manifesting by _lots_ of timeouts. The problem in this case 
is some weirdness in e1000e in my system, after I force-switch the main system 
to 100baseT (using ethtool -s eth0 speed 100 duplex full), I no longer get 
timeouts (even after I force-switch it back to 1000baseT later). But I suspect 
this is some network issue on my end.

Best regards,
Marek Vasut

[U-Boot] TFTP timeouts, i.mx fec problem?

[Fabio Estevam]

Hi Marek,

On Thu, Jun 6, 2013 at 10:25 PM, Marek Vasut <marex@denx.de> wrote:

> I'm also having issues when pulling stuff from my main system via TFTP
> sometimes. This is manifesting by _lots_ of timeouts. The problem in this case
> is some weirdness in e1000e in my system, after I force-switch the main system
> to 100baseT (using ethtool -s eth0 speed 100 duplex full), I no longer get
> timeouts (even after I force-switch it back to 1000baseT later). But I suspect
> this is some network issue on my end.

Does this only happen when you use  mx28 board or with any board?

In my case I get the timeouts only on mx28.

Regards,

Fabio Estevam

[U-Boot] TFTP timeouts, i.mx fec problem?

[Marek Vasut]

Dear Fabio Estevam,

> Hi Marek,
> 
> On Thu, Jun 6, 2013 at 10:25 PM, Marek Vasut <marex@denx.de> wrote:
> > I'm also having issues when pulling stuff from my main system via TFTP
> > sometimes. This is manifesting by _lots_ of timeouts. The problem in this
> > case is some weirdness in e1000e in my system, after I force-switch the
> > main system to 100baseT (using ethtool -s eth0 speed 100 duplex full), I
> > no longer get timeouts (even after I force-switch it back to 1000baseT
> > later). But I suspect this is some network issue on my end.
> 
> Does this only happen when you use  mx28 board or with any board?
> 
> In my case I get the timeouts only on mx28.

Most of the boards have this issue ... at least all of those that use 100baseT 
ethernet. Those 10baseT (I have such boards!) don't have this problem I think, 
but that might be because they're usually catching dust ;-D

Best regards,
Marek Vasut

[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

Hi Fabio,

I have not come any further yet in finding the real cause. For now, I just tested with workarounds like lowering the ARP timeout and skipping the phy reset (or only reset for the 1st transfer). Note that also the phy reset and waiting for "link-up" takes about 2 seconds every time. I did not realise earlier that it would take this long, but this is the part before the "TFTP from server..." line is displayed and he transfer even starts.

To my opinion, resetting the phy and restarting auto-negotiation before each transfer seems a bit overdone, especially if a number of transfers are started in a row. But since the MAC is also halted and restarted, perhaps a freshly started phy is recommended?

Up till now, I have not seen too many timeouts during a transfer. But for the last weeks I've been testing mostly with smaller files and focused on the start of the transfer.

Regards,

Ruud

> -----Oorspronkelijk bericht-----
> Van: Fabio Estevam [mailto:festevam at gmail.com] 
> Verzonden: vrijdag 7 juni 2013 2:16
> Aan: Ruud Commandeur
> CC: U-Boot list; Marek Va?ut; Stefano Babic
> Onderwerp: Re: [U-Boot] TFTP timeouts, i.mx fec problem?
> 
> Hi Ruud,
> 
> On Fri, May 31, 2013 at 3:56 AM, Ruud Commandeur 
> <RCommandeur@clb.nl> wrote:
> > Hi everyone,
> >
> > I have been testing for a while now on the i.mx28 evk, and I noticed
> > that almost all tftp transfers take some time before they actually
> > start. It will show a 'T' as first character, then followed by '#'
> 
> Besides the initial timeout you mentioned, I also see some timeouts
> during the kernel transfer.
> 
> I have just sent two patches converting mx28evk to use phylib, but I
> still see the timeouts there.
> 
> I see that in the kernel there is a workaround for LAN8270 low por
> mode and I will try it when I have a chance.
> 
> Please let me know if you make any progress on this.
> 
> Regards,
> 
> Fabio Estevam
> 

[U-Boot] TFTP timeouts, i.mx fec problem?

[Eric Bénard]

Hi Ruud,

Le Fri, 7 Jun 2013 11:28:54 +0200,
Ruud Commandeur <RCommandeur@clb.nl> a ?crit :
> I have not come any further yet in finding the real cause. For now, I just tested with workarounds like lowering the ARP timeout and skipping the phy reset (or only reset for the 1st transfer). Note that also the phy reset and waiting for "link-up" takes about 2 seconds every time. I did not realise earlier that it would take this long, but this is the part before the "TFTP from server..." line is displayed and he transfer even starts.
> 
isn't your problem related to the fact that when you reset the PHY it
samples some pins to get some settings and that after the first reset it
could gets wrong settings because the i.MX pins are in a wrong state
(because handled by the FEC) leading to the errors you meet ?

Eric

[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

Hi Eric,

Thanks for your comments and sorry for my delayed response. Busy with some other projects last week...

I noticed these pins on the board. They have optional pull-down resistors, which are not placed by default. This would result in mode[2:0] being 111: "All capable. Auto-negotiation enabled". And as I look at the code, the cofiguration bits are set quite identical to this mode (10 + 100, Both FULL + HALF, aneg enabled). And on the other hand: after this sw-config + reset, the autonegotiation itself succeeds, indicated by the status bits and LED's. But for some reason it is not ready to transmit yet...

Regards,

Ruud

> -----Oorspronkelijk bericht-----
> Van: Eric B?nard [mailto:eric at eukrea.com] 
> Verzonden: vrijdag 7 juni 2013 11:40
> Aan: Ruud Commandeur
> CC: Fabio Estevam; Marek Va?ut; U-Boot list
> Onderwerp: Re: [U-Boot] TFTP timeouts, i.mx fec problem?
> 
> Hi Ruud,
> 
> Le Fri, 7 Jun 2013 11:28:54 +0200,
> Ruud Commandeur <RCommandeur@clb.nl> a ?crit :
> > I have not come any further yet in finding the real cause. 
> For now, I just tested with workarounds like lowering the ARP 
> timeout and skipping the phy reset (or only reset for the 1st 
> transfer). Note that also the phy reset and waiting for 
> "link-up" takes about 2 seconds every time. I did not realise 
> earlier that it would take this long, but this is the part 
> before the "TFTP from server..." line is displayed and he 
> transfer even starts.
> > 
> isn't your problem related to the fact that when you reset the PHY it
> samples some pins to get some settings and that after the 
> first reset it
> could gets wrong settings because the i.MX pins are in a wrong state
> (because handled by the FEC) leading to the errors you meet ?
> 
> Eric
> 

[U-Boot] TFTP timeouts, i.mx fec problem?

[Wolfgang Denk]

Dear Ruud,

In message <15AE5A936F5E3A42A9144E66875A0A89309217@server1-derijp.CLB-Benelux.lokaal> you wrote:
> 
> I noticed these pins on the board. They have optional pull-down
> resistors, which are not placed by default. This would result in
> mode[2:0] being 111: "All capable. Auto-negotiation enabled". And as
> I look at the code, the cofiguration bits are set quite identical to
> this mode (10 + 100, Both FULL + HALF, aneg enabled). And on the
> other hand: after this sw-config + reset, the autonegotiation itself
> succeeds, indicated by the status bits and LED's. But for some reason
> it is not ready to transmit yet...

Hm... autonegotiation does not happen on the board only, it is
something between the board an the switch.  Would it be possible that
the switch takes longer to become ready to receive than the target
board takes to become ready to send?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Like winter snow on summer lawn, time past is time gone.

[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

Hi Wolfgang,

Interesting thought. Never looked at it from this site, but this can be true of course. Although somewhat harder to proof, I'm afraid. I will keep this in mind for any further testing I will do.

Regards,

Ruud

> -----Oorspronkelijk bericht-----
> Van: Wolfgang Denk [mailto:wd at denx.de] 
> Verzonden: vrijdag 14 juni 2013 17:31
> Aan: Ruud Commandeur
> CC: Eric B?nard; Marek Va?ut; U-Boot list
> Onderwerp: Re: [U-Boot] TFTP timeouts, i.mx fec problem?
> 
> Dear Ruud,
> 
> In message 
> <15AE5A936F5E3A42A9144E66875A0A89309217@server1-derijp.CLB-Ben
elux.lokaal> you wrote:
> > 
> > I noticed these pins on the board. They have optional pull-down
> > resistors, which are not placed by default. This would result in
> > mode[2:0] being 111: "All capable. Auto-negotiation enabled". And as
> > I look at the code, the cofiguration bits are set quite identical to
> > this mode (10 + 100, Both FULL + HALF, aneg enabled). And on the
> > other hand: after this sw-config + reset, the autonegotiation itself
> > succeeds, indicated by the status bits and LED's. But for 
> some reason
> > it is not ready to transmit yet...
> 
> Hm... autonegotiation does not happen on the board only, it is
> something between the board an the switch.  Would it be possible that
> the switch takes longer to become ready to receive than the target
> board takes to become ready to send?
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Like winter snow on summer lawn, time past is time gone.
>