On Monday 26 October 2009 07:35:14 Raffaele Recalcati wrote:
I've customized the commit f67066b6b0740b826ed862615c5ab022aaf4779a for my pxa255/smx911x (lan9118) board. tftp works nice, also through a switch, but only if I'm not connected to the LAN.
you really need to be careful when throwing around general terms like "LAN" but you're really referring to specific things like "your company's internal intranet/LAN". as soon as you connect computers together, you have a "LAN".
If I'm connected to the LAN of my company I have many timeout problems.
which means the board is going to probably see a lot more packets which are not destined for it, so some slow down is to be expected
=> tftp a2000000 uImage smc911x: detected LAN9118 controller smc911x: phy initialized .. BSR=0x782D smc911x: phy initialized .. PHY special control status=0x1058 smc911x: MAC 00:03:50:00:a7:c5 Using smc911x-0 device TFTP from server 10.39.10.114; our IP address is 10.39.10.183 Filename 'uImage'. Load address: 0xa2000000 Loading: #####################################T ############################ ##############################T #T ################################## ###invalid RARP header T ##T ###T ############################################T
#############
##################################
the TFTP implementation/protocol isnt perfect -- if one packet is missed because the hardware is processing unrelated ones, you're going to get a "T". that just means it was retransmitted.
as for how much noise there actually is and whether there's anything the driver can do to negate it, that's something you'll have to investigate with wireshark (or similar network util).
no idea about the RARP header. -mike