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