I was looking into the Hello_World with the debugger and went in single step through the assembly code of the example application.

Somehow to me it looks like that Hello_World is not at all linked against U-BOOT, as there is no jump intothe U-BOOT image, i.e. for calling the printf function. Instead it is just constantly moving any data into the R12 registeruntil finally the application crashes and the WandBoard reboots.

I was just building the u-boot as you have stated in you document

# make -j4 wandboard

The example applications are also build by this, but is the linking process being done properly?

I wanted to use the Hello_World as a starting project for my own application development, but so far it looks like there are still some toolchain topics to be solved before.

does anybody know how the LDFLAGS environment variable should be set in order to build u-boot correctly?In my system this variable is not set at all, and kind of I assume that this might be the reason for the no properlylinked Hello_World app.

If I disassemble hello_world.bin, I still do not see any jump into the u-boot memory region which is 0x17800000.So even though I hope the API is now compiled into u-boot, it seems the standalone application doesn't knowanything about it.

Is there still something missing for the compiling of the standalone app?

hm, I never tried to load and execute a .bin file. I used the mkimage utility, which is also used to generate the linux kernelimage for the wandboard as described in section "5.12.3. Processor cache considerations" ofhttp://www.denx.de/wiki/DULG/UBootStandalone. I used thisapproach to generate the loader for FreeBSD (ubldr) image, whichsuccessfully used the u-boot API for console and disk IO.

The standalone application searches memory above it's stack,which is setup by u-boot, for some magic values to find theentry point for calls into u-boot (see examples/api/glue.cin u-boot source).

sorry, seems I don't get it. I tried your advice and added these few lines to the makefile for the standalone apps, but I do not get an image file, but I also do not get any error message during compilation.Looks like my added command inside the makefile are not even taken into account.

## Some versions of make do not handle trailing white spaces properly;# leading to build failures. The problem was found with GNU Make 3.80.# Using 'strip' as a workaround for the problem.#ELF := $(strip $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)))

# For PowerPC there's no need to compile standalone applications as a# relocatable executable. The relocation data is not needed, and# also causes the entry point of the standalone application to be# inconsistent.ifeq ($(ARCH),powerpc)AFLAGS := $(filter-out $(RELFLAGS),$(AFLAGS))CFLAGS := $(filter-out $(RELFLAGS),$(CFLAGS))CPPFLAGS := $(filter-out $(RELFLAGS),$(CPPFLAGS))endif

# We don't want gcc reordering functions if possible. This ensures that an# application's entry point will be the first function in the application's# source file.CFLAGS_NTR := $(call cc-option,-fno-toplevel-reorder)CFLAGS += $(CFLAGS_NTR)