[U-Boot] On simple standalone applications

[Wolfgang Denk]

Dear Alessio Sangalli,

In message <48B89A07.7010806 at manoweb.com> you wrote:
> Hi, I have problems in writing an application for U-boot. I do not need
> U-boot functions (for now), I just have to write some registers and then
> fill some memory with a value. The HW will read that memory region for
> its usage.
> 
> I work on a ARM9 board whose RAM is mapped from 0x000000 to 0x04000000
> (64MB). I have been privided U-boot 1.2.0 for this board.

Are you sure about this? Normally ARM systems have flash memory (or
some other ROM) mapped at 0, because this is where execution starts
out of reset.

> First problem: I can compile U-boot with ELDK 4.1 but if I enter the
> "examples" directory and issue a make:

Who says you should do that? The examples are automatically built when
running "make all" (or just "make") in the top level directory.

> uboot-1.2.0/examples# make
> Makefile:64: /config.mk: No such file or directory
> Makefile:174: /rules.mk: No such file or directory
> make: *** No rule to make target `/rules.mk'.  Stop.

That's a user error. Please see above.

> 4. The default load and start addresses of the applications are as
>    follows:
> [...]
>         ARM     0x0c100000      0x0c100000
> 
> I do not have RAM at that location! Shall I modify the Makefile for this?

Yes, you have to adjust the link address to your actual memory map.

> Anyway, I wrote a small program that does what I described above:
> 
> int test02()
> {
>         volatile int* r;
>         int i;
> 
>         *(volatile int*)(0xc0001200) = 0x00000000;
>         *(volatile int*)(0xc0001220) = 0x0257031f;
>         *(volatile int*)(0xc0001224) = 0x00162028;
> 
>         r = (int*)0x00800000;
>         for(i=0; i<0x100; i++)
>                 *r = 0x00000000;
> 
>         return 0;
> }
> 
> I know, it's ugly and I could do everything with a bunch of u-boot's
> 'mw' commands, but this is only supposed to be a quick test. I have
> compiled it with:

It's not only gly, but also error-prone. You should not use plain
pointer accesses to read or write to registers, but the correct
accessor functions/macros ({in,out}[bwl]).

> arm-gcc -c test02.c && arm-objcopy -O binary test02.o test02.bin && cp
> test02.bin /tftpboot/

And object file is not an executable. You have to run it through the
linker.

> The first part of the program, the register writing, works, I get my
> hardware enabled. But the 'for' loop is not well 'relocated' and points
> to undefined code in random memory areas, and the CPU gets stuck.

Yes, that's because you did not correctly link your code.

I recommend to have a closer lok at  the  examples  in  the  examples
directory, and how these get compiled and linked.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The majority of the stupid is  invincible  and  guaranteed  for  all
time.  The  terror  of their tyranny, however, is alleviated by their
lack of consistency."                               - Albert Einstein