[U-Boot-Users] PATCH : Allow dhcp to get IP address from and keep other env data .

[Woodruff, Richard]

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 at denx.de] 
Sent: Wednesday, July 30, 2003 2:13 AM
To: Woodruff, Richard
Cc: u-boot-users at 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 at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
To program is to be.