|
Wilson, Nic, I’ve seen this as well �C as you mention
below - looks like some routers are setting the ‘next-server’ address in the dhcp
options they hand out, which uboot picks up and configures serverip. This
can be very useful if some scenarios for automating the boot procedure �C but will
make it incorrect for your app in this case. If you want DHCP to work as well, you
could also do : - setenv autoload no This will stop dhcp from autoloading the bootfile
and allow you to reset the serverip to your desired tftpserver before loading
the kernel. Your bootcmd would then become :- setenv bootcmd ‘dhcp;setenv serverip
xxx.yyy.xxx.yyy;tftpboot 0x80700000 uImage; ....’ ~rog From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Judging from your ip addresses used it looks like
you have a local router. I have noticed that u-boot first tries to download the
uImage from the gateway = router first before it tries the TFTP server you
actually specified in the u-boot environment variable (serverip variable). Some
routers (like my linksys wrt54g) use tftp for updating the flash which is why
they have tftp server, but their server of course doesn't have your uImage. This could be your problem as I can see the client
tries to download the uImage from 192.168.3.1 (which likely is your router). I
haven't found a way around this issue other than to specify the ip adress
manually (ipaddr variable) followed by the tftpboot command to download the
image (and not use the dhcp command at all). This works for me. Regards, Niclas From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Hello: ___________________________________________________
|
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
