[U-Boot] On simple standalone applications

[U-Boot] On simple standalone applications

[Alessio Sangalli]

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.

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

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.

So I am unable to compile the examples. What should I do? By the way, I
noticed that:
uboot-1.2.0/doc/README.standalone

[...]
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?


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:

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

and then, on the target's u-boot prompt:
> tftp 1000000 test02.bin
TFTP from server 192.168.1.77; our IP address is 192.168.1.10
Filename 'test02.bin'.
Load address: 0x1000000
Loading: #
done
Bytes transferred = 252 (fc hex)
> go 1000000
## Starting application at 0x01000000 ...

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.

Any advice?
Thank you
Alessio

[U-Boot] On simple standalone applications

[Wolfgang Denk]

Dear Alessio Sangalli,

In message <48B89A07.7010806@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

[U-Boot] On simple standalone applications

[Alessio Sangalli]

Wolfgang Denk wrote:

> 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.

Yes I am. On this system (at least as it is now) U-boot is executed from
memory when DDR has already been initialized. So yes, I confirm DDR is
mapped from 0x00000000 to 0x3fffffff but I only have 64MB so the end of
physical RAM is 0x03ffffff.

>> 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.

Sorry my fault.


>> 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.

Well now it is somewhat clearer and I think I understand. I will do some
experiments on the target on Tuesday, after labor's day of course :)


> 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]).

Uh... are those defined for U-boot as well? Thanks.


bye!
as