TFTP boot problem. help!

setenv serverip is the correct procedure.  However, my guess is that the dhcp in the bootcmd is causing the problem.  Try using setenv ipaddr and give yourself a fixed ip.

John A

Hi,

Can you try using the following (with the quotes)

setenv serverip '200.17.96.155'

Also, please print the environment variables before calling "bootm"

Also, as John suggested, might want to put the static ip addr too.

Regards,

Anshuman

i tried setenv ipaddr and didn't work. I tried with quotes too, and same.

=(

anything more to help?

thx anyway.

One thing you could try on your development PC to make sure your tftp server is correctly exporting your file is the following:

bash$ tftp

tftp> open localhost

tftp> get uImage

If it fails, then you most likely have an issue in your TFTP server configuration.

Let us know.

Rafael Fernandes said:

my TFTP server is not 200.17.96.80, it is 200.17.96.155.

DHCP replies can also contain the ip of the TFTP server. In the DHCP configuration files this is referred to as the next-server.

http://www.daemon-systems.org/man/dhcpd.conf.5.html    search for next-server

You can try two things:

1. Configure the DHCP server to provide the correct serverip by modifying the next-server field appropriately.

2. Use something like this:

# setenv serverip_old <required TFTP server address>

# dhcp

# setenv serverip ${serverip_old}

# <rest of the commands>

Regards,

Vaibhav

hey look this..

utfpr@dhcp155:~> tftp localhost
tftp> get uImage               
tftp> quit                     
utfpr@dhcp155:~> ls -l uImage  
-rw-r--r-- 1 utfpr users 2017356 Fev 10 09:31 uImage

appear to be ok.

I tried this serverip_old, but i think i don't understand how to use it in the right way.

look this too...

dhcp155:/home/utfpr/Download/cutecom-0.22.0 # route -n
Tabela de Roteamento IP do Kernel
Destino         Roteador        MáscaraGen.    Opções Métrica Ref   Uso Iface
200.17.96.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         200.17.96.80    0.0.0.0         UG    0      0        0 eth1

the ip ,200.17.96.80 , that apear like tftp in boot,  is my gateway right?

thx=)

If you do a printenv after doing a dhcp you should see the serverip being overwritten to 200.17.96.80.

Try modifying the bootcmd to set the serverip after doing a dhcp but before the tftp command.

Eg: setenv bootcmd 'dhcp; setenv serverip 200.17.96.155; tftp 0x82000000 initrd.image; tftp 80700000 uImage' etc.

Regards,

Vaibhav

Luiz,

Maybe could be a misudestood between your ethernet cards, if you have more than one card. It than could share the tftp server in the wrong port and card. This result in troubles finding the EVM and the tftp server. Maybe if you disable one of the ethernet cards. Or even get the right specification of the tftp server, e. g., know the exactally card, IP and port that the tftp is shared, you than could have this connecting fixed

Regards,

Kartunov

I ran across this issue when setting up my environment for dev work on a AM437X Starter Kit. There are a number of posts that relate to this issue and I suspect that a few more people will run across this problem. I have a solution which feels less workaround-ish.

As has been mentioned previously the problem arises because either the dhcp server is sending bootp/dhcp-boot parameters for tftp server settings or u-boot is interpreting something incorrectly about these settings.

I performed a quick packet capture and I'm not sure I found anything specifically that showed my dhcp server sending tftp settings. I'm not an expert though so be that as it may. I suspect that u-boot is filling in some blanks here - possibly incorrectly or with incorrect assumptions.

Anyway - on to the fix:

in the SDK under bin/setup-uboot-env.sh on line 144 and 154 (or near there in case this file changes in new versions of the SDK) change the following:

LINE 144:

do_expect "\"U-Boot#\"" "send setenv bootcmd 'run findfdt; run getuenv; setenv autoload no;dhcp ; tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run netargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom

AND LINE 154:

do_expect "\"U-Boot#\"" "send setenv bootcmd 'run findfdt; run getuenv; setenv autoload no; dhcp ; tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run mmcargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom

to:

LINE 144:

do_expect "\"U-Boot#\"" "send setenv bootcmd 'run findfdt; run getuenv; setenv autoload no;dhcp ;setenv serverip ${ipdefault}; tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run netargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom

AND LINE 154:

do_expect "\"U-Boot#\"" "send setenv bootcmd 'run findfdt; run getuenv; setenv autoload no; dhcp ; setenv serverip ${ipdefault}; tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run mmcargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom

This will at least make sure that serverip gets set correctly after being changed from the dhcp command. It'd be great to see this incorporated into the SDK (or a better fix?) since it appears so many people have this problem and it doesn't appear to be caused by incorrect dhcp server settings.