Networking Bug in SDK v07.00

Hi Matthew,

Issue D-01525 is still marked as "Under Investigation" as noted here: http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Kernel_Release_Notes#Known_Issues

I have asked the factory team to provide some information about the status of the issue and I will let you know as soon as I have an answer.

Best regards,
Miroslav

So issue D-01525 seems to suggest that the problem is only with some routers and in in only a specific mode. I'm seeing that networking is not working at all with SDK 7.0, with or without DHCP, and I'm not intentionally putting in it in Dual EMAC mode, unless that's the default mode which I don't believe that it is.  I'm simply trying to the follow the TI instructions and setup scripts for NFS boot and it doesn't work! I'm really struggling to understand how a such a fundamental problem remains in the SDK with no solution. 

If all of this is related to issue D-01525 then please do let me know the status and at least tell us how to proceed in the absents of a fix. Do we roll back to 6.0, or move forward to a newer kernel, if we move forward how do we do that? 

Matt S. 

Any word on this problem from the factory guys?

It seems like a rather glaring problem for an SDK to fail right out of the box with a fundamental feature like this.

Has anybody used the SDK 7.0 and gotten NFS boot to work? 

Matt S. 

bump!

hi Matthew Schuckmann1,

I am also facing the same problem. stuck here for almost two weeks.

Jawahar Krishnamoorthi

Hi all,

I have forwarded this to the factory team once again and hope to have an answer soon. Sorry for the delay.

Best regards,
Miroslav

Matthew and others,

I'm sorry you are having trouble with the SDK due to this. While we try to test as exhaustively as we can, I'm sure you'll understand that we can't test with every router out there. Our test bed of routers did not reveal this problem until very late in our test cycle and we were not able to ascertain how severe the limitation was until after release (and further testing). We have tried to expand our test bed so that a problem like this does not slip by us again.

The fix for the issue is discussed here. It is a very simple change that should allow DHCP to work properly and thus allow NFS to work. And, yes, we've had NFS work on a regular basis.

The SK DeviceTree file enables dual EMAC by default, so a SK will have this turned on and see this problem depending on the behavior of the attached DHCP server.

This will be fixed in the next SDK release. Again, we apologize that it has cost you valuable time and energy. If you have further questions, please let us know.

Thanks for the response Ron but your link does not work, I just get the message "Group Not Found". 

I think it should be noted that it's more than just a DHCP problem, if I boot from and SD Card and manually assign an IP address I can not successfully ping any devices on the network. 

Matt S. 

Ok I've verified that this works. 

Might I suggest that you update the release notes to be a bit more clear that it not just a problem with DHCP and perhaps provided a link to the fix or at least post an official fix page or something. 

By the way the setup.sh script that is included as part of SDK 7.0 doesn't work if the DHCP server is not your tftp server. You're script sets serverip to the address specified by the user prior to running dhcp and if the dhcp advertises itself as a tftp server the dhcp command will overwrite serverip. 

Here is my uEnv.txt with the evmsk:

tftp_nfs_boot=setenv autoload no; setenv rootpath /export/rootfs; setenv ip_method dhcp; dhcp; setenv serverip 192.168.12.100; run findfdt; tftp ${loadaddr} zImage; run findfdt; tftp ${fdtaddr} ${fdtfile}; run netargs; bootz ${loadaddr} - ${fdtaddr}

uenvcmd=run tftp_nfs_boot