The problem was in the order of gd->jt[] array initialization. I did it too early and in common/exports.c it was filled by dummy function address.
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: Monday, October 29, 2007 7:45 AM To: Laurent Pinchart; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Return values from u-boot to standaloneapplication.
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,
-- Laurent Pinchart CSE Semaphore Belgium
Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium
T +32 (2) 387 42 59 F +32 (2) 387 42 75
------------------------------------------------------------------------- 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