Re: [U-Boot] TFTP timeouts, i.mx fec problem?
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:w...@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 > <15ae5a936f5e3a42a9144e66875a0a89309...@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: w...@denx.de > Like winter snow on summer lawn, time past is time gone. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Ruud, In message <15ae5a936f5e3a42a9144e66875a0a89309...@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: w...@denx.de Like winter snow on summer lawn, time past is time gone. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
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:e...@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 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Ruud, Le Fri, 7 Jun 2013 11:28:54 +0200, Ruud Commandeur 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
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:feste...@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 > 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Fabio Estevam, > Hi Marek, > > On Thu, Jun 6, 2013 at 10:25 PM, Marek Vasut 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Marek, On Thu, Jun 6, 2013 at 10:25 PM, Marek Vasut 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Fabio Estevam, > Hi Ruud, > > On Fri, May 31, 2013 at 3:56 AM, Ruud Commandeur 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Ruud, On Fri, May 31, 2013 at 3:56 AM, Ruud Commandeur 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
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@800f {
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
phy-supply = <®_fec_3v3>;
phy-reset-gpios = <&gpio4 13 0>;
phy-reset-duration = <100>;
status = "okay";
};
Regards,
Ruud
-Oorspronkelijk bericht-
Van: Troy Kisky [mailto:troy.ki...@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.3090...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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.3090...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Stefano Babic, In message <51a8c5da.3090...@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: w...@denx.de The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Stefano, [Joe added to Cc: list] In message <51a8c479.6010...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Stefano, On Fri, May 31, 2013 at 12:46 PM, Stefano Babic 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
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: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
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: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
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:w...@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.3040...@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: w...@denx.de > I can't say I've ever been lost, but I was bewildered once for three > days. - Daniel Boone (Attributed) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Stefano Babic, In message <51a86445.3040...@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: w...@denx.de I can't say I've ever been lost, but I was bewildered once for three days. - Daniel Boone (Attributed) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
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_TIMEOUT200UL > > 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:sba...@denx.de] > > Verzonden: vrijdag 31 mei 2013 10:50 > > Aan: Ruud Commandeur > > CC: U-Boot list; sba...@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: > sba...@denx.de > > > = > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 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_TIMEOUT200UL 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:sba...@denx.de] > Verzonden: vrijdag 31 mei 2013 10:50 > Aan: Ruud Commandeur > CC: U-Boot list; sba...@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: sba...@denx.de > = > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 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: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Ruud, In message <15ae5a936f5e3a42a9144e66875a0a89309...@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_TIMEOUT200UL > 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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
