Wolfgang,
Seems to be some misunderstanding here.
For the site I'm working at the global network is administrated by people in another location, and for some things in another city. All my "work" computers get their IP address via dhcp. If for convience sake I want to use my embedded target on the main network (its common for me to just NFS mount my development system for a built in root, or shared file system), all I can do easily is to use a static IP address which I either assign in a semi-unsafe way, or request one and wait. This works fine for just one person in small scale but when any number of people want to develop in a similar way things start to get messy.
A dhcp server on my own machine with a lot of careful settings could be set up on my work station, however the networking administrators are very paranoid about running dhcp servers on the live network....and with some reason....hundreds of machines have been brought down in the past by people trying and mis-configuring. A second and more correct alternative, is to set up private networks off of workstations, unfortunately not all workstations are created equal in the number of interfaces they are shipped with, and even if they were its more effort to set up routing and the like to get it working properly.
So, the shorter term and easier approach is to run a tftpserver on a workstation on the main network to deliver files, AND just use the main networks dhcp server for a valid IP address & netmask & gateway information.
Now here is where u-boot comes in ... If I issue the dhcp command, the global dhcp server will NOT fill in bootfile name and the server name fields in optional fields. HOWEVER, the u-boot code _DOES_ write the NULLs back to the defaults (beneath the env names) making them unusable. ... the variable BootFile in memory always gets the first path argument stomped, and the server is zero'ed and not set.
So, the patch I applied allows me to use the global dhcp server which I can ONLY ask address of, to give a valid address, and my environment variables allow resolution of my tftpserver and bootfile name. and all in one command.
Hopefully this is clear,
Regards,
Richard W.
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Wednesday, July 30, 2003 2:13 AM To: Woodruff, Richard Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] PATCH : Allow dhcp to get IP address from and keep other env data .
Dear Richard,
in message FD2AC9A020DDD51194710008C7089B200BEE2230@dlee17.itg.ti.com you wrote:
This small patch adds the conditional DHCP_IP_ADDR_ONLY . This allows someone to use the dhcp command to load a file on a network where you
DON'T
have access to the dhcp server, but would like to use it to have fast downloads of development kernels or other files.
I have to admit that I don't understand this sentence. How can you use "it" (the dhcp server?), when you don't have access to it?
Prior to this patch the the reply packet would trash your environment settings for bootfile and serverip will not be used when issuing the dhcp
Sorry, but I disagree. Those variables will be _set_, not trashed. And only if your DHCP server transmits this sort of ionformation. If you don't want it, don't send it, i. e. configure your DHCP server not to send it.
command. By adding the CFG_DHCP_CMD, along with DHCP_IP_ADDR_ONLY in your board config file you can use your company network server to get your
file.
The ip,gateway,netmask still are gotten from the dhcp reply.
I can see no need for this.
If I understand you correctly, you want to use DHCP to configure the network interface, yet download by TFTP from a different server. Did you thy something like this:
=> setenv my_bootfile "/tftpboot/foo" => setenv my_tftpserver XXX.XXX.XXX.XXX => saveenv
=> setenv autoload no => dhcp => setenv serverip $(my_tftpserver) => tftp 200000 $(my_bootfile)
Or what exactly is your problem?
Best regards,
Wolfgang Denk