Wolfgang Denk wrote:

Dear Justin,

in message 4155D0DA4B6B044891B3F19311C7E7B89C45E4@EXCHANGE1.886llc.local you wrote:

...

I recently upgraded the firmware on some of my old Linksys WRT54G routers (version 5) from firmware version 1.0.6 to firmware version 1.02.2, both of which are released by Linksys and U-Boot was no longer able to get an IP address using DHCP. However, with the older firmware (version 1.0.6), U-Boot was still able to get an IP through DHCP.

Using a hub and a packet sniffer, I was able to locate the problem. The U-Boot code will bind to an IP address offered by the DHCP server prematurely and the DHCP server will not respond with an ACK, rendering

I have to admit that I'm not sure if this is a bug in U-Boot or in the Linksys router (which I have under special observation as they explicitely and intentionally violate the U-Boot GPL).

...

the system without an IP address. This is no longer valid when using a Linksys router as DHCP server. I modified the code to operate the way the Linux DHCP client does by not binding to the offered IP until the DHCP client receives the ACK sent by the server, ending the conversation. After making the appropriate changes, DCHP service was restored for all flavors of the Linksys firmware that I have available (v 1.02.2 and v1.0.6 for the version 5 router, v8.00.2 for the version 8 router). It has also been tested on an AirPort Extreme router running DHCP.

Attached is the patch with the code changes that were made. Any feed back would be appreciated.

I'm waiting for feedback (or a pull request?) from the network custodian.

Ben???

This looks promising. I'll provide feedback after doing some testing tomorrow.

regards, Ben

Sorry, I forgot to mention that I'm using at91rm9200 CPU (ARM9 from Atmel) and u-boot version is 1.2.0 official release. May be there are some known issues with standalone application for ARM? Stack getting corrupted?

My code is but small variation of standard hello_world (attached) and here is output:

U-Boot$ tftp 21000000 $image_path/hello_world.bin; go 21000000; TFTP from server 192.168.0.108; our IP address is 192.168.0.205 Filename 'leonid/ref/images/hello_world.bin'. Load address: 0x21000000 Loading: # done Bytes transferred = 620 (26c hex) ## Starting application at 0x21000000 ... Example expects ABI version 3 Actual U-Boot ABI version 3 Hello World argc = 1 argv[0] = "21000000" argv[1] = "<NULL>" main:48 line=help len=553648684 Hit any key to exit ...

## Application terminated, rc = 0x0 U-Boot$

Application is compiled to run from the address 0x21000000 which is the middle of RAM.

Thanks,

Leonid.

-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Leonid Sent: Sunday, October 28, 2007 11:01 PM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] Return values from u-boot to standalone application.

Hi:

I have created u-boot standalone application and exported some string functions (like strlen()). The application is working (doesn't fail) but values which exported functions are returning don't look right. For example, this printf() in standalone application

printf ("cmdparse:%u line=%s len=%d\n", __LINE__, line, strlen(line));

prints the following line:

cmdparse:407 line=help len=553684153

meaning strlen() return code is wrong. Same thing happens with strchr() and other functions I have exported.

Am I doing something wrong? How can I get correct return values from u-boot to standalone application?

Thanks,

Leonid.

------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

Hi, Laurent:

You are right regarding value. The interesting thing though is that functions which have been exported by u-boot traditionally (say, getenv() or getc()) return correct value in standalone application.

However all string related functions I have tried to export (strlen(), strchr(), etc...) are not so. I think I did everything the same way it's done for other functions...

Thanks,

Leonid.

-----Original Message----- From: Laurent Pinchart [mailto:laurentp@cse-semaphore.com] Sent: Monday, October 29, 2007 6:47 AM To: u-boot-users@lists.sourceforge.net Cc: Leonid Subject: Re: [U-Boot-Users] Return values from u-boot to standalone application.

Hi Leonid, On Monday 29 October 2007 14:34, Leonid wrote:

Sorry, I forgot to mention that I'm using at91rm9200 CPU (ARM9 from Atmel) and u-boot version is 1.2.0 official release. May be there are some known issues with standalone application for ARM? Stack getting corrupted?

My code is but small variation of standard hello_world (attached) and here is output:

U-Boot$ tftp 21000000 $image_path/hello_world.bin; go 21000000; TFTP from server 192.168.0.108; our IP address is 192.168.0.205 Filename 'leonid/ref/images/hello_world.bin'. Load address: 0x21000000 Loading: # done Bytes transferred = 620 (26c hex) ## Starting application at 0x21000000 ... Example expects ABI version 3 Actual U-Boot ABI version 3 Hello World argc = 1 argv[0] = "21000000" argv[1] = "<NULL>" main:48 line=help len=553648684 Hit any key to exit ...

## Application terminated, rc = 0x0 U-Boot$

Application is compiled to run from the address 0x21000000 which is the middle of RAM.

For what it's worth, 553648684 is 0x2100022c in hex, which is in the middle of your application's memory. This either means you end up feeding the function address to printf instead of calling the function, or you got a stack/calling convention issue.

Best regards,