Basic Application from scratch

This is the place for software discussions not having a dedicated subforum

Basic Application from scratch

Postby mysli » Sat Jan 04, 2014 9:46 pm

Hi All,

I would like to write an application from scratch to get the hardware known much better.
I.e. letting a GPIO toggle for the first would be fine.

But I would like to do this without any underlying linux kernel.
The U-Boot sound great to me, but instead of loading the linux kernel, I would like to have my own application being loaded.

I have already quite some experience with ARM Cortex-Mx micros, there I'm writing my software totally from scratch.
Kind of the same I would like to do with the Wandboard.

How does such a simple basic application should look like, especially regarding how does the entry from u-boot looks like?

Does anybody of you have such a little example for me to start from?

@Tapani, maybe you have something for me?

That would be great.

Bye
Daniel
mysli
 
Posts: 12
Joined: Sun Dec 29, 2013 8:16 pm

Re: Basic Application from scratch

Postby Tapani » Mon Jan 06, 2014 3:42 am

mysli,

Some pointers:

not sure if this is what you are looking for: http://www.denx.de/wiki/DULG/UBootStandalone

Also, if you really want to be really barebone, look and modify the whoosh bootloader: https://github.com/alexandrebelloni/whoosh

Otherwise, maybe add your code into u-boot?
Tapani
 
Posts: 712
Joined: Tue Aug 27, 2013 8:32 am

Re: Basic Application from scratch

Postby mysli » Thu Jan 09, 2014 10:17 pm

Hello,

I was looking into the u-boot now, and it looks quite promising already.

I wanted to start with the example/standablone/hello_world.c but I do not really know how to execute it.

I can load it from the SD card into RAM from the U-Boot shell, but when I try to execute it, it does not do anything.

Does anyone successfully executed the Hello_World example?

Thx
Daniel
mysli
 
Posts: 12
Joined: Sun Dec 29, 2013 8:16 pm

Re: Basic Application from scratch

Postby mysli » Fri Jan 10, 2014 11:24 pm

Hi All,

Hi Tapani,

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 into
the U-BOOT image, i.e. for calling the printf function. Instead it is just constantly moving any data into the R12 register
until 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.

Any help would be highly appreciated.

Bye
Daniel
mysli
 
Posts: 12
Joined: Sun Dec 29, 2013 8:16 pm

Re: Basic Application from scratch

Postby mysli » Mon Jan 13, 2014 8:21 pm

Hi All,

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 properly
linked Hello_World app.

Thanks for any help.

Bye
Daniel
mysli
 
Posts: 12
Joined: Sun Dec 29, 2013 8:16 pm

Re: Basic Application from scratch

Postby juergen » Thu Jan 16, 2014 8:24 pm

The default wandboard u-boot loader does NOT support the u-boot API, because
it's compiled without it. So the examples will certainly not work.

You must define CONFIG_API in include/configs/wandboard.h in the u-boot
sources, recompile and reinstall u-boot.

Regards

Juergen
juergen
 
Posts: 3
Joined: Thu Jan 16, 2014 8:17 pm

Re: Basic Application from scratch

Postby mysli » Fri Jan 17, 2014 9:16 pm

Hi Juergen,

thanks for your help.
I did put the following defines in addition into the include/configs/wandboard.h

Code: Select all
#define CONFIG_API
#define CONFIG_SYS_MMC_MAX_DEVICE 2
#define CONFIG_NET_MULTI

#define CONFIG_STANDALONE_LOAD_ADDR     0x11000000


U-Boot compiles without failures, I did update my SD card with the compiled SPL, u-boot image and the hello_world.bin.

But still, the hello_world.bin is still not working, inside the u-boot shell I did it the following:

Code: Select all
=> ext2load mmc 0:1 0x11000000 hello_world.bin
590 bytes read in 26 ms (21.5 KiB/s)
=>


executing hello_world by:

Code: Select all
go 0x11000000


reboot, that's what I get.

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 know
anything about it.

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

Thanks for any help
Daniel
mysli
 
Posts: 12
Joined: Sun Dec 29, 2013 8:16 pm

Re: Basic Application from scratch

Postby juergen » Fri Jan 17, 2014 9:54 pm

hm, I never tried to load and execute a .bin file. I used the
mkimage utility, which is also used to generate the linux kernel
image for the wandboard as described in section
"5.12.3. Processor cache considerations" of
http://www.denx.de/wiki/DULG/UBootStandalone. I used this
approach to generate the loader for FreeBSD (ubldr) image, which
successfully 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 the
entry point for calls into u-boot (see examples/api/glue.c
in u-boot source).

Juergen
juergen
 
Posts: 3
Joined: Thu Jan 16, 2014 8:17 pm

Re: Basic Application from scratch

Postby mysli » Fri Jan 17, 2014 10:50 pm

Hi Juergen,

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.

Would you mind to check if my makefile entries are making sense?

Code: Select all
#
# (C) Copyright 2000-2006
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
#
# SPDX-License-Identifier:   GPL-2.0+
#

include $(TOPDIR)/config.mk

ELF-$(ARCH)  :=
ELF-$(BOARD) :=
ELF-$(CPU)   :=
ELF-y        := hello_world

ELF-$(CONFIG_SMC91111)           += smc91111_eeprom
ELF-$(CONFIG_SMC911X)            += smc911x_eeprom
ELF-$(CONFIG_SPI_FLASH_ATMEL)    += atmel_df_pow2
ELF-i386                         += 82559_eeprom
ELF-mpc5xxx                      += interrupt
ELF-mpc8xx                       += test_burst timer
ELF-mpc8260                      += mem_to_mem_idma2intr
ELF-ppc                          += sched
ELF-oxc                          += eepro100_eeprom

#
# 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)))

SREC := $(addsuffix .srec,$(ELF))
BIN  := $(addsuffix .bin,$(ELF))
IMG  := $(addsuffix).img,$(ELF))

COBJS   := $(ELF:=.o)

LIB   = $(obj)libstubs.o

LIBAOBJS-$(ARCH)     :=
LIBAOBJS-$(CPU)      :=
LIBAOBJS-ppc         += $(ARCH)_longjmp.o $(ARCH)_setjmp.o
LIBAOBJS-mpc8xx      += test_burst_lib.o
LIBAOBJS := $(LIBAOBJS-$(ARCH)) $(LIBAOBJS-$(CPU))

LIBCOBJS = stubs.o

LIBOBJS   = $(addprefix $(obj),$(LIBAOBJS) $(LIBCOBJS))

SRCS   := $(COBJS:.o=.c) $(LIBCOBJS:.o=.c) $(LIBAOBJS:.o=.S)
OBJS   := $(addprefix $(obj),$(COBJS))
ELF   := $(addprefix $(obj),$(ELF))
BIN   := $(addprefix $(obj),$(BIN))
SREC   := $(addprefix $(obj),$(SREC))
IMG   := $(addprefix $(obj),$(IMG))

gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)

CPPFLAGS += -I..

# 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)

MKIMAGE := $(obj)tools/mkimage

all:   $(obj).depend $(OBJS) $(LIB) $(BIN) $(SREC) $(ELF) $(IMG)

#########################################################################
$(LIB):   $(obj).depend $(LIBOBJS)
   $(call cmd_link_o_target, $(LIBOBJS))

$(ELF):
$(obj)%:   $(obj)%.o $(LIB)
      $(LD) $(LDFLAGS) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \
         -o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \
         -L$(gcclibdir) -lgcc

$(SREC):
$(obj)%.srec:   $(obj)%
      $(OBJCOPY) -O srec $< $@ 2>/dev/null

$(BIN):
$(obj)%.bin:   $(obj)%
      $(OBJCOPY) -O binary $< $@ 2>/dev/null

$(IMG):
$(obj)%.img:   $(BIN)%
      $(SRCTREE)/tools/mkimage -n "Hello stand alone" -A $(ARCH) -O u-boot -T standalone -C none -a $(CONFIG_STANDALONE_LOAD_ADDR) -d $(BIN) -v $@

#########################################################################

# defines $(obj).depend target
include $(SRCTREE)/rules.mk

sinclude $(obj).depend

#########################################################################


Thank you.
Daniel
mysli
 
Posts: 12
Joined: Sun Dec 29, 2013 8:16 pm

Re: Basic Application from scratch

Postby mysli » Fri Jan 17, 2014 10:58 pm

Hi Juergen

I did manage to make an image manually (makefile problem from post above still present).

I did executed the image on the u-boot, but still seems not to work:

Code: Select all
=> ext2load mmc 0:1 0x11000000 hello_world.img
654 bytes read in 43 ms (14.6 KiB/s)
=> bootm 0x11000000 hello bla
## Booting kernel from Legacy Image at 11000000 ...
   Image Name:   hello stand alone
   Image Type:   ARM U-Boot Standalone Program (uncompressed)
   Data Size:    590 Bytes = 590 Bytes
   Load Address: 11000000
   Entry Point:  11000000
   Verifying Checksum ... OK
   XIP Standalone Program ... OK
ERROR: booting os 'U-Boot' (17) is not supported
=>


I get the error message "U-Boot" is not supported, do you have any idea what this means, or what might gone wrong?

Thanks
Daniel
mysli
 
Posts: 12
Joined: Sun Dec 29, 2013 8:16 pm

Next

Return to Software - General

Who is online

Users browsing this forum: No registered users and 14 guests

cron