am3517 tftpboot problems

Can you "ping" the server from u-boot?

# ping 192.168.1.141

If not, try to do a "dhcp" from u-boot and then re-try the ping and tftpboot.  The "dhcp" may change your ipaddr value.

If you still have trouble, please share the full set of u-boot env vars.

Greg.

You're right, I can't ping my host linux from uboot.

I added all the network configuration environment variables I could find mentioned, and that didn't help.

But maybe I have to saveenv and reboot so that uboot has them as it starts, in order to get the network interface up?

My full printenv follows.  The last 5, starting with ethaddr, I added manually.

==  dj

AM3517_EVM # printenv
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboi
bootdelay=10
baudrate=115200
bootfile=uImage
loadaddr=0x82000000
console=ttyO2,115200n8
mmcargs=setenv bootargs console=${console} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
nandargs=setenv bootargs console=${console} root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}
stdin=serial
stdout=serial
stderr=serial
dieid#=19d2000100000000015da3960f00e01f
ethact=DaVinci EMAC
ethaddr=08:00:28:0F:49:DC
gatewayip=192.168.1.1
ipaddr=192.168.1.138
serverip=192.168.1.141
dnsip=192.168.1.206

I should have mentioned that "dhcp" will fill in all of the network config variables for you.  And it will initiate the tftp of the kernel if the variable autoload is set to "yes" (the default for autoload is yes).  I would recommend that you do NOT saveenv the network config for this reason.  It is better to let "dhcp" do it for you.  This will let things be dynamic if you were to move to a different network.

Here is the way that I set up to tftp my kernel and boot into an NFS folder.

nfsargs=setenv bootargs console=${console} noinitrd rw ip=dhcp root=/dev/nfs nfsroot=${serverip}:${nfspath}
bootcmd=dhcp;run nfsargs;bootm

This assumes that my console, serverip, and nfspath are all set to appropriate values.  The dhcp command should configure the network and initiate the tftp of the kernel.

Anyway, erase ipaddr, gatewayip, and dnsip and then do the dhcp.  Print the environment afterwards and observe how the network config may or may not have changed.  Then re-try the ping.

That last post didn't format very well on the forum.  On my recommended settings it looks like I made three different entries.  But actually there were only two.  There is one line for nfsargs and another line for bootcmd.  The line for nfsargs wrapped around and makes it look like nfsroot is a separate env var.  It is not.  nfsroot is part of the nfsargs variable.

Another thing to look at is the Ubuntu VM.  Assuming that it is running in a windows host, can you ping the VM from Windows?  Run -> cmd, then ping the VM host address.

If this fails then the VM may need to have its firewall disabled.  In the VM, try sudo ufw disable.  You may then have to re-start your tftp server.

Hi Greg,

I understand about the 2 settings, for nfsargs and bootcmd.

And windows can ping the Ubuntu VM OK>  I had thought about  the Ubuntu firewall and have stopped it with "stop ufw".

It's looking pretty certainly like what's fouled up is my uboot network config.  I am not sure how that is established other than via DHCP so I think using DHCP is a good idea.

The engineer I inherited this board from had been trying to use it with a static IP, but I am pretty sure that was all at the Arago linux level.  But maybe uboot is somehow using some of that configuration and that is fouling up my DHCP.  Anyway, here is what DHCP looks like.  I observed that the address, host and filename args are all optional, so I thought that maybe plain "dhcp" would just do network config.  But it looks like it's sending out BOOTP packets and getting nothing back.  This is all on our corporate network, mostly windows, and via whatever switches and routers are between me and the servers, not at all sure about how that works and why it would not cooperate with uboot's dhcp command.

Uboot command line as I try to "dhcp" - Note that I tried autoload = no, in case that was somehow interfering with just getting IP assigned.  Also, I had no ethaddr, I had to manually set that before dhcp would run.

ethaddr=08:00:28:0F:49:DC

Environment size: 885/131068 bytes
AM3517_EVM # dhcp 192.168.1.1
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3

Abort
AM3517_EVM # help dhcp
dhcp - boot image via network using DHCP/TFTP protocol

Usage:
dhcp [loadAddress] [[hostIPaddr:]bootfilename]
AM3517_EVM # setenv autoload no
AM3517_EVM # dhcp
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4

Abort

Thanks for looking at this, I'm pretty far over my head at this level.

==  dj

Keep the ethaddr set, you do need that saved.  Since you can't ping the VM from u-boot, I would expect that dhcp would fail to tftp the kernel, but it should be able to get an IP address from the DHCP server.  And just plain "dhcp" should do it.  But this could depend on your corporate network.  I have a VMware Ubuntu VM running on a Windows XP host.  The VM network is set to "Bridged".  This means that it just replicates the settings of my host connection and both Windows host and VM each DHCP on the corporate network to get an IP.  So to the network they look like two different machines.  I use a dumb switch to connect my EVM to the same network and doing "dhcp" in u-boot doesn't have a problem getting an ip address and then tftp'ing from the VM server.

Would it be possible to get a local router (with a DHCP server) and place everything behind this?  I sometimes do this at my desk when I need to isolate from the corporate network.  This may tell you if the problem is the corporate network.

Backing up some, there is another thing to try.  You mentioned that you were able to telnet to the board after booting kernel and fs from the SD card.  This implies that DHCP did work during the Linux boot up.  So it could be that for some reason DHCP in u-boot is broken.  If your real goal is to get NFS working, you could probably get the kernel from SD card and then use NFS for the filesystem.

bootcmd=mmc init;fatload mmc 0 ${loadaddr} uImage;run nfsargs;bootm

Hi Greg,

Actually, the standalone router was the next thing I tried.  Just plugged the am3517 into an old SMC7004ABR to see if that DHCP would work, and got the same result.  Maybe I will just move on to NFS mounted file system.  I was thinking that I might well be  rebuilding the kernel along the way here, and it would be handy to get the new one via TFTP.

Hopefully my squirrely network config won't foul up NFS as well.  I'm calling it a day for this issue, I'll try some more things tomorrow and let you know what I find.

==  dj

Sounds like the problem is with u-boot.  I am more confident that you will get NFS to work since the Linux DHCP seemed to work.

Notes on NFS server (assuming that you don't already have this).

Install NFS server: # sudo apt-get install nfs-kernel-server

Config NFS server (I keep multiple NFS points) by editing /etc/exports:

user@UbuntuVbox1004:~/NFS$ more /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
#  to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#
/home/user/AM35x-OMAP35x-PSP-SDK-03.00.01.06/images/fs/nfsbase *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
/home/user/AM35x-OMAP35x-PSP-SDK-03.00.01.06/images/fs/matrixfs *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
/home/user/ti-sdk-am37x-evm-4.0.1.0/filesystem/SDK_NFS *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
/home/user/ti-sdk-am37x-evm-4.0.1.0/filesystem/SDK_NFS2 *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
/home/user/ti-ezsdk_dm814x-evm_5_00_00_26/filesystem/baseNFS *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
/home/user/ti-ezsdk_dm814x-evm_5_00_00_26/CentFS *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
/home/user/ti-sdk-am37x-evm-4.0.1.0/targetNFS *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
/home/user/NFS/am37x-evm-sdk-bin-05.02.00.00/fs *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)

user@UbuntuVbox1004:~/NFS$

Start NFS server (use start ot restart after editing exports) : # sudo /etc/init.d/nfs-kernel-server start

Define nfspath in u-boot env vars: # nfspath=/home/user/NFS/am37x-evm-sdk-bin-05.02.00.00/fs,nolock

Put an empty file with a meaningful name in the home/root sub-folder of the NFS point.  That file will list with ls after the board boots up.  It is a good sanity check to see that you are in the right NFS.

OK, got that to work on the second try.

For the next victim of this tangled maze, here is the uboot env that worked.

I added nfshost, rootpath, nfsargs, and bootcmd per Greg's instructions.

(I might have changed some env names, my first attempt failed and it looked like the kernel might be looking for "rootpath").

Greg, thanks for all the help, and if I get back into tftp boot and figure out anything, I'll follow up with another post here.

==  dj

AM3517_EVM # printenv
bootdelay=10
baudrate=115200
bootfile=uImage
loadaddr=0x82000000
console=ttyO2,115200n8
mmcargs=setenv bootargs console=${console} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
nandargs=setenv bootargs console=${console} root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}
stdin=serial
stdout=serial
stderr=serial
dieid#=19d2000100000000015da3960f00e01f
ethact=DaVinci EMAC
nfshost=192.168.1.141
rootpath=/home/user/ti-sdk-am3517-evm-05.02.00.00/targetNFS
nfsargs=setenv bootargs console=${console} noinitrd rw ip=dhcp root=/dev/nfs nfsroot=${nfshost}:${rootpath}
bootcmd=mmc init;fatload mmc 0 ${loadaddr} uImage;run nfsargs;bootm

Environment size: 956/131068 bytes

I did get tftpboot to work.

Not sure exactly what got fixed but here is what I did.

Followed the SDK instructions to rebuild u-boot and kernel.

I found a reference to using the toolchain in the linux-devkit directory of the SDK, and set PATH to include /home/user/ti-sdk-am3517-evm-05.02.00.00/linux-devkit/bin,

and used CROSS_COMPILE=arm-arago-linux-gnueabi-

Built u-boot first to get mkimage built and added the u-boot tools directory to PATH before building kernel.

Copied uImage and u-boot.bin to the MMC card, renaming the old u-boot and kernel in case I needed to get back to them.

Rebooted from the MMC card, and booted with NFS file system as discussed above.

Then I rebooted and stopped at u-boot, and set autoload=no and tried dhcp which seemed to work.

Then I tried tftpboot and it worked this time.

My best guess is that there was some problem with the u-boot on the MMC, and the fresh build of u-boot fixed the problem.

Thanks again for the assistance.

==  dj

One last thing you can check is to set autoload=yes.  Make sure your serverip, bootfile, and loadaddr variables are set the way you want.  Then, dhcp will set the network and perform the tftp.  Then you just set bootargs and boot.  Your bootcmd could look like the following:

bootcmd=dhcp;run nfsargs;bootm

Glad it is working now.  Please click the verify answer button for me.  Thanks.

Don't forget to verify answers to your forum questions by using the green "Verify Answer" button.