* test app
@ 2011-03-07 13:05 Vanalme Filip
2011-03-08 5:40 ` Baruch Siach
2011-03-08 11:50 ` Sascha Hauer
0 siblings, 2 replies; 16+ messages in thread
From: Vanalme Filip @ 2011-03-07 13:05 UTC (permalink / raw)
To: barebox
We would like to have a kind of small test application, that can be started from the barebox prompt, to do some basic tests on some hardware components. What's the best way to do that ? E.g. can I add that test application to the environment and would this be good practice ? Or do I better extend the barebox commands with my own command to start the tests ? Maybe there's an example on how to do it ?
Filip Vanalme
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: test app
2011-03-07 13:05 test app Vanalme Filip
@ 2011-03-08 5:40 ` Baruch Siach
2011-03-08 8:13 ` Vanalme Filip
2011-03-08 11:50 ` Sascha Hauer
1 sibling, 1 reply; 16+ messages in thread
From: Baruch Siach @ 2011-03-08 5:40 UTC (permalink / raw)
To: Vanalme Filip; +Cc: barebox
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
Hi Vanalme,
On Mon, Mar 07, 2011 at 02:05:32PM +0100, Vanalme Filip wrote:
> We would like to have a kind of small test application, that can be started
> from the barebox prompt, to do some basic tests on some hardware components.
> What's the best way to do that ? E.g. can I add that test application to the
> environment and would this be good practice ? Or do I better extend the
> barebox commands with my own command to start the tests ? Maybe there's an
> example on how to do it ?
I'm using the attached program to do a simple RAM read/write test on i.MX25.
This program runs on bare hardware from the internal chip SRAM, and doesn't
rely on the Barebox run-time code. I only use Barebox to start this program.
The program is built with the following Makefile rules:
all: ramtest.bin
%.bin: %.elf
${OBJCOPY} -O binary $^ $@
ramtest.elf: ramtest.c
${CC} -Wall -Os -nostdlib $^ -o $@ -Wl,-Ttext=0x78000000
Running this program from the Barebox prompt:
cp ramtest.bin /dev/sram0
go /dev/sram0
I hope this helps.
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
[-- Attachment #2: ramtest.c --]
[-- Type: text/x-csrc, Size: 5204 bytes --]
/*
* Test RAM on an i.MX25 machine
*
* Author: Baruch Siach <baruch@tkos.co.il>
*
* This is a standalone program which does not use any external library.
* The RAM test algorithm that is implemented here is based on idea from the
* "Testing RAM in Embedded Systems" article at
* http://www.ganssle.com/testingram.htm
*/
#define MX25_UART1_BASE 0x43F90000
#define MX25_GPIO2_BASE 0x53FD0000
#define IOMUXC_BASE_ADDR 0x43FAC000
#define IOMUX_MUX_SD1_DATA2_PAD 0x1a0
#define IOMUX_PAD_SD1_DATA2_PAD 0x398
#define MX25_WDOG_BASE 0x53FDC000
#define MX25_WDOG_SEQ1 0x5555
#define MX25_WDOG_SEQ2 0xAAAA
#define RAM_BASE 0x80000000
#define RAM_SIZE 0x04000000
#define TEST_START_VALUE 0x55
#define writeb(v, a) (*(volatile unsigned char *)(a)) = (v)
#define readb(a) *(volatile unsigned char *)(a)
#define writew(v, a) (*(volatile unsigned short *)(a)) = (v)
#define readw(a) *(volatile unsigned short *)(a)
#define writel(v, a) (*(volatile unsigned int *)(a)) = (v)
#define readl(a) *(volatile unsigned int *)(a)
static char hex_tab[] = "0123456789abcdef";
__asm__ (".text\n"
".globl _start\n"
"_start:\n"
"ldr sp, =0x78020000\n"
"bl main\n"
"stop:\n"
"b stop\n"
);
static void uart_putc (char c)
{
while (readl (MX25_UART1_BASE + 0xb4) & 0x10)
;
writel (c, MX25_UART1_BASE + 0x40);
}
static void uart_puthex (unsigned int val, int width)
{
unsigned char digit;
while (width-- > 0) {
digit = (val >> (width*4)) & 0xf;
uart_putc (hex_tab[digit]);
}
}
static void uart_puts (char *str)
{
for (; *str; str++) {
if (*str == '\n')
uart_putc ('\r');
uart_putc (*str);
}
}
static void watchdog_ping ()
{
writew (MX25_WDOG_SEQ1, MX25_WDOG_BASE + 0x02);
writew (MX25_WDOG_SEQ2, MX25_WDOG_BASE + 0x02);
}
static void reset_cpu ()
{
unsigned short wcr = readw (MX25_WDOG_BASE);
writew (wcr & 0xff, MX25_WDOG_BASE);
watchdog_ping ();
}
static void __attribute__ ((unused)) led_on (void)
{
/* set pad */
writel (5, IOMUXC_BASE_ADDR + IOMUX_MUX_SD1_DATA2_PAD);
writel (1, IOMUXC_BASE_ADDR + IOMUX_PAD_SD1_DATA2_PAD);
/* set direction */
writel (0x08000000, MX25_GPIO2_BASE + 4);
/* set value */
writel (0, MX25_GPIO2_BASE);
}
static void filler (unsigned char val, int cycle)
{
unsigned int i;
for (i = 0; i < RAM_SIZE; i++) {
if ((i & 0xfffff) == 0) {
uart_putc ('#');
watchdog_ping ();
}
if (val == TEST_START_VALUE) {
writeb(val, RAM_BASE + i);
i++;
}
writeb(val, RAM_BASE + i);
if (cycle)
val++;
else if (i & 1) /* negate bits on every 16bit write */
val = ~val;
}
uart_puts ("\n");
}
static void check_err (unsigned long addr, unsigned char expect,
unsigned char val)
{
uart_puts ("Error at 0x");
uart_puthex (addr, 8);
uart_puts (" expected 0x");
uart_puthex (expect, 2);
uart_puts (", got 0x");
uart_puthex (val, 2);
uart_puts ("\n");
}
static int checker (int cycle)
{
unsigned int i;
unsigned char expected_val = TEST_START_VALUE;
unsigned char ram_val;
int err = 0;
for (i = 0; i < RAM_SIZE; i++) {
if ((i & 0xfffff) == 0) {
uart_putc ('#');
watchdog_ping ();
}
if (expected_val == TEST_START_VALUE) {
ram_val = readb(RAM_BASE + i);
if (ram_val != expected_val) {
check_err (RAM_BASE + i, expected_val, ram_val);
err++;
}
i++;
}
ram_val = readb(RAM_BASE + i);
if (ram_val != expected_val) {
check_err (RAM_BASE + i, expected_val, ram_val);
err++;
}
if (err >= 10)
return err;
if (cycle)
expected_val++;
else if (i & 1) /* negate bits on every 16bit check */
expected_val = ~expected_val;
}
uart_puts ("\n");
return err;
}
int main (int argc, char *argv[])
{
watchdog_ping ();
#ifdef TERMINATION_TEST
if (argc > 1) {
uart_puts ("Doing termination testing ");
if (argv[1][0] == 'w') {
unsigned char val;
uart_puts ("(write)\n");
if (argc == 3 && argv[2][0] == 'a')
val = 0xAA;
else
val = TEST_START_VALUE;
while (1)
filler (val, 0);
} else {
uart_puts ("(read)\n");
uart_puts ("Filling RAM...\n");
filler (TEST_START_VALUE, 0);
uart_puts ("Reading RAM...\n");
while (1)
checker (0);
}
}
#endif
uart_puts ("Starting RAM write\n");
filler (TEST_START_VALUE, 1);
uart_puts ("Starting RAM read\n");
if (checker (1) == 0)
uart_puts ("RAM test finished successfully\n");
else
uart_puts ("RAM test failed\n");
reset_cpu ();
return 0;
}
[-- Attachment #3: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: test app
2011-03-08 5:40 ` Baruch Siach
@ 2011-03-08 8:13 ` Vanalme Filip
2011-03-08 10:09 ` Vanalme Filip
0 siblings, 1 reply; 16+ messages in thread
From: Vanalme Filip @ 2011-03-08 8:13 UTC (permalink / raw)
To: Baruch Siach; +Cc: barebox
Thank you Baruch ! Good starting point for my test app.
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: dinsdag 8 maart 2011 6:40
> To: Vanalme Filip
> Cc: barebox@lists.infradead.org
> Subject: Re: test app
>
> Hi Vanalme,
>
> On Mon, Mar 07, 2011 at 02:05:32PM +0100, Vanalme Filip wrote:
> > We would like to have a kind of small test application, that can be
> > started from the barebox prompt, to do some basic tests on some hardware
> components.
> > What's the best way to do that ? E.g. can I add that test application
> > to the environment and would this be good practice ? Or do I better
> > extend the barebox commands with my own command to start the tests ?
> > Maybe there's an example on how to do it ?
>
> I'm using the attached program to do a simple RAM read/write test on i.MX25.
> This program runs on bare hardware from the internal chip SRAM, and doesn't rely
> on the Barebox run-time code. I only use Barebox to start this program.
>
> The program is built with the following Makefile rules:
>
> all: ramtest.bin
>
> %.bin: %.elf
> ${OBJCOPY} -O binary $^ $@
>
> ramtest.elf: ramtest.c
> ${CC} -Wall -Os -nostdlib $^ -o $@ -Wl,-Ttext=0x78000000
>
> Running this program from the Barebox prompt:
>
> cp ramtest.bin /dev/sram0
> go /dev/sram0
>
> I hope this helps.
>
> baruch
>
> --
> ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: test app
2011-03-08 8:13 ` Vanalme Filip
@ 2011-03-08 10:09 ` Vanalme Filip
2011-03-08 11:22 ` Baruch Siach
2011-03-08 11:43 ` Sascha Hauer
0 siblings, 2 replies; 16+ messages in thread
From: Vanalme Filip @ 2011-03-08 10:09 UTC (permalink / raw)
To: Baruch Siach; +Cc: barebox
> -----Original Message-----
> From: barebox-bounces@lists.infradead.org [mailto:barebox-
> bounces@lists.infradead.org] On Behalf Of Vanalme Filip
> Sent: dinsdag 8 maart 2011 9:13
> To: Baruch Siach
> Cc: barebox@lists.infradead.org
> Subject: RE: test app
>
> Thank you Baruch ! Good starting point for my test app.
>
> > -----Original Message-----
> > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > Sent: dinsdag 8 maart 2011 6:40
> > To: Vanalme Filip
> > Cc: barebox@lists.infradead.org
> > Subject: Re: test app
> >
> > Hi Vanalme,
> >
> > On Mon, Mar 07, 2011 at 02:05:32PM +0100, Vanalme Filip wrote:
> > > We would like to have a kind of small test application, that can be
> > > started from the barebox prompt, to do some basic tests on some hardware
> > components.
> > > What's the best way to do that ? E.g. can I add that test application
> > > to the environment and would this be good practice ? Or do I better
> > > extend the barebox commands with my own command to start the tests ?
> > > Maybe there's an example on how to do it ?
> >
> > I'm using the attached program to do a simple RAM read/write test on i.MX25.
> > This program runs on bare hardware from the internal chip SRAM, and doesn't
> rely
> > on the Barebox run-time code. I only use Barebox to start this program.
> >
> > The program is built with the following Makefile rules:
> >
> > all: ramtest.bin
> >
> > %.bin: %.elf
> > ${OBJCOPY} -O binary $^ $@
> >
> > ramtest.elf: ramtest.c
> > ${CC} -Wall -Os -nostdlib $^ -o $@ -Wl,-Ttext=0x78000000
> >
> > Running this program from the Barebox prompt:
> >
> > cp ramtest.bin /dev/sram0
> > go /dev/sram0
> >
> > I hope this helps.
> >
> > baruch
> >
[Filip]
As a start, I just took over your Makefile and a minimal source file :
__asm__ (".text\n"
".globl _start\n"
"_start:\n"
"ldr sp, =0xA7E00000\n"
"bl main\n"
"stop:\n"
"b stop\n"
);
int main (int argc, char *argv[])
{
return 0;
}
I think I might still miss something because the assembler part gives me errors e.g.
" Error: no such instruction: 'ldr sp,=0xA7E00000' "
" Error: no such instruction: 'bl main' "
" Error: no such instruction: 'b stop' "
Maybe a tab/space related issue ?
> > --
> > ~. .~ Tk Open Systems
> > =}------------------------------------------------ooO--U--Ooo------------{=
> > - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: test app
2011-03-08 10:09 ` Vanalme Filip
@ 2011-03-08 11:22 ` Baruch Siach
2011-03-08 15:52 ` Vanalme Filip
2011-03-08 11:43 ` Sascha Hauer
1 sibling, 1 reply; 16+ messages in thread
From: Baruch Siach @ 2011-03-08 11:22 UTC (permalink / raw)
To: Vanalme Filip; +Cc: barebox
Hi Vanalme,
On Tue, Mar 08, 2011 at 11:09:57AM +0100, Vanalme Filip wrote:
> As a start, I just took over your Makefile and a minimal source file :
>
> __asm__ (".text\n"
> ".globl _start\n"
> "_start:\n"
> "ldr sp, =0xA7E00000\n"
> "bl main\n"
> "stop:\n"
> "b stop\n"
> );
>
> int main (int argc, char *argv[])
> {
> return 0;
> }
>
> I think I might still miss something because the assembler part gives me errors e.g.
> " Error: no such instruction: 'ldr sp,=0xA7E00000' "
> " Error: no such instruction: 'bl main' "
> " Error: no such instruction: 'b stop' "
>
> Maybe a tab/space related issue ?
Works for me (using the CodeSourcery toolchain):
$ cat baretest.c
__asm__ (".text\n"
".globl _start\n"
"_start:\n"
"ldr sp, =0xA7E00000\n"
"bl main\n"
"stop:\n"
"b stop\n"
);
int main (int argc, char *argv[])
{
return 0;
}
$ arm-none-linux-gnueabi-gcc -Wall -Os -nostdlib baretest.c -o baretest.elf -Wl,-Ttext=0x78000000
$ arm-none-linux-gnueabi-objdump -S baretest.elf
baretest.elf: file format elf32-littlearm
Disassembly of section .text:
78000000 <_start>:
78000000: e59fd00c ldr sp, [pc, #12] ; 78000014 <main+0x8>
78000004: eb000000 bl 7800000c <main>
78000008 <stop>:
78000008: eafffffe b 78000008 <stop>
7800000c <main>:
7800000c: e3a00000 mov r0, #0
78000010: e12fff1e bx lr
78000014: a7e00000 .word 0xa7e00000
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: test app
2011-03-08 10:09 ` Vanalme Filip
2011-03-08 11:22 ` Baruch Siach
@ 2011-03-08 11:43 ` Sascha Hauer
2011-03-08 12:43 ` Vanalme Filip
1 sibling, 1 reply; 16+ messages in thread
From: Sascha Hauer @ 2011-03-08 11:43 UTC (permalink / raw)
To: Vanalme Filip; +Cc: barebox
On Tue, Mar 08, 2011 at 11:09:57AM +0100, Vanalme Filip wrote:
> > -----Original Message-----
> > From: barebox-bounces@lists.infradead.org [mailto:barebox-
> > bounces@lists.infradead.org] On Behalf Of Vanalme Filip
> > Sent: dinsdag 8 maart 2011 9:13
> > To: Baruch Siach
> > Cc: barebox@lists.infradead.org
> > Subject: RE: test app
> >
> > Thank you Baruch ! Good starting point for my test app.
> >
> > > -----Original Message-----
> > > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > > Sent: dinsdag 8 maart 2011 6:40
> > > To: Vanalme Filip
> > > Cc: barebox@lists.infradead.org
> > > Subject: Re: test app
> > >
> > > Hi Vanalme,
> > >
> > > On Mon, Mar 07, 2011 at 02:05:32PM +0100, Vanalme Filip wrote:
> > > > We would like to have a kind of small test application, that can be
> > > > started from the barebox prompt, to do some basic tests on some hardware
> > > components.
> > > > What's the best way to do that ? E.g. can I add that test application
> > > > to the environment and would this be good practice ? Or do I better
> > > > extend the barebox commands with my own command to start the tests ?
> > > > Maybe there's an example on how to do it ?
> > >
> > > I'm using the attached program to do a simple RAM read/write test on i.MX25.
> > > This program runs on bare hardware from the internal chip SRAM, and doesn't
> > rely
> > > on the Barebox run-time code. I only use Barebox to start this program.
> > >
> > > The program is built with the following Makefile rules:
> > >
> > > all: ramtest.bin
> > >
> > > %.bin: %.elf
> > > ${OBJCOPY} -O binary $^ $@
> > >
> > > ramtest.elf: ramtest.c
> > > ${CC} -Wall -Os -nostdlib $^ -o $@ -Wl,-Ttext=0x78000000
> > >
> > > Running this program from the Barebox prompt:
> > >
> > > cp ramtest.bin /dev/sram0
> > > go /dev/sram0
> > >
> > > I hope this helps.
> > >
> > > baruch
> > >
>
> [Filip]
>
> As a start, I just took over your Makefile and a minimal source file :
>
> __asm__ (".text\n"
> ".globl _start\n"
> "_start:\n"
> "ldr sp, =0xA7E00000\n"
> "bl main\n"
> "stop:\n"
> "b stop\n"
> );
>
> int main (int argc, char *argv[])
> {
> return 0;
> }
>
> I think I might still miss something because the assembler part gives me errors e.g.
> " Error: no such instruction: 'ldr sp,=0xA7E00000' "
> " Error: no such instruction: 'bl main' "
> " Error: no such instruction: 'b stop' "
Just a guess, did you set $CC to your cross compiler?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: test app
2011-03-07 13:05 test app Vanalme Filip
2011-03-08 5:40 ` Baruch Siach
@ 2011-03-08 11:50 ` Sascha Hauer
1 sibling, 0 replies; 16+ messages in thread
From: Sascha Hauer @ 2011-03-08 11:50 UTC (permalink / raw)
To: Vanalme Filip; +Cc: barebox
On Mon, Mar 07, 2011 at 02:05:32PM +0100, Vanalme Filip wrote:
> We would like to have a kind of small test application, that can be
> started from the barebox prompt, to do some basic tests on some
> hardware components. What's the best way to do that ? E.g. can I add
> that test application to the environment and would this be good
> practice ? Or do I better extend the barebox commands with my own
> command to start the tests ? Maybe there's an example on how to do it
> ?
Besides what Baruch already pointed out you can of course create your
own command. Maybe you don't want to have this command in your
production bootloader, then you could also build a barebox for
development only and start this as a second stage loader (tftp
barebox.bin /dev/ram0; go /dev/ram0).
Another possibility would be to use modules. barebox supports modules
similar to the kernel. When you build your own command as a module
you can do a 'tftp mycommand.ko; insmod mycommand.ko' and can use
your command then. Anyway, this feature is a bit experimental and
I can't really recommend this unless you know exactly what you
are doing.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: test app
2011-03-08 11:43 ` Sascha Hauer
@ 2011-03-08 12:43 ` Vanalme Filip
0 siblings, 0 replies; 16+ messages in thread
From: Vanalme Filip @ 2011-03-08 12:43 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer@pengutronix.de]
> Sent: dinsdag 8 maart 2011 12:43
> To: Vanalme Filip
> Cc: Baruch Siach; barebox@lists.infradead.org
> Subject: Re: test app
>
> On Tue, Mar 08, 2011 at 11:09:57AM +0100, Vanalme Filip wrote:
> > > -----Original Message-----
> > > From: barebox-bounces@lists.infradead.org [mailto:barebox-
> > > bounces@lists.infradead.org] On Behalf Of Vanalme Filip
> > > Sent: dinsdag 8 maart 2011 9:13
> > > To: Baruch Siach
> > > Cc: barebox@lists.infradead.org
> > > Subject: RE: test app
> > >
> > > Thank you Baruch ! Good starting point for my test app.
> > >
> > > > -----Original Message-----
> > > > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > > > Sent: dinsdag 8 maart 2011 6:40
> > > > To: Vanalme Filip
> > > > Cc: barebox@lists.infradead.org
> > > > Subject: Re: test app
> > > >
> > > > Hi Vanalme,
> > > >
> > > > On Mon, Mar 07, 2011 at 02:05:32PM +0100, Vanalme Filip wrote:
> > > > > We would like to have a kind of small test application, that can be
> > > > > started from the barebox prompt, to do some basic tests on some hardware
> > > > components.
> > > > > What's the best way to do that ? E.g. can I add that test application
> > > > > to the environment and would this be good practice ? Or do I better
> > > > > extend the barebox commands with my own command to start the tests ?
> > > > > Maybe there's an example on how to do it ?
> > > >
> > > > I'm using the attached program to do a simple RAM read/write test on i.MX25.
> > > > This program runs on bare hardware from the internal chip SRAM, and
> doesn't
> > > rely
> > > > on the Barebox run-time code. I only use Barebox to start this program.
> > > >
> > > > The program is built with the following Makefile rules:
> > > >
> > > > all: ramtest.bin
> > > >
> > > > %.bin: %.elf
> > > > ${OBJCOPY} -O binary $^ $@
> > > >
> > > > ramtest.elf: ramtest.c
> > > > ${CC} -Wall -Os -nostdlib $^ -o $@ -Wl,-Ttext=0x78000000
> > > >
> > > > Running this program from the Barebox prompt:
> > > >
> > > > cp ramtest.bin /dev/sram0
> > > > go /dev/sram0
> > > >
> > > > I hope this helps.
> > > >
> > > > baruch
> > > >
> >
> > [Filip]
> >
> > As a start, I just took over your Makefile and a minimal source file :
> >
> > __asm__ (".text\n"
> > ".globl _start\n"
> > "_start:\n"
> > "ldr sp, =0xA7E00000\n"
> > "bl main\n"
> > "stop:\n"
> > "b stop\n"
> > );
> >
> > int main (int argc, char *argv[])
> > {
> > return 0;
> > }
> >
> > I think I might still miss something because the assembler part gives me errors
> e.g.
> > " Error: no such instruction: 'ldr sp,=0xA7E00000' "
> > " Error: no such instruction: 'bl main' "
> > " Error: no such instruction: 'b stop' "
>
> Just a guess, did you set $CC to your cross compiler?
[Filip]
Of course.....How could I have missed that... shame...Think I badly need a holiday one of these days... ;-)
Thanks anyway
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: test app
2011-03-08 11:22 ` Baruch Siach
@ 2011-03-08 15:52 ` Vanalme Filip
2011-03-08 18:08 ` Baruch Siach
0 siblings, 1 reply; 16+ messages in thread
From: Vanalme Filip @ 2011-03-08 15:52 UTC (permalink / raw)
To: Baruch Siach; +Cc: barebox
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: dinsdag 8 maart 2011 12:22
> To: Vanalme Filip
> Cc: barebox@lists.infradead.org
> Subject: Re: test app
>
> Hi Vanalme,
>
> On Tue, Mar 08, 2011 at 11:09:57AM +0100, Vanalme Filip wrote:
> > As a start, I just took over your Makefile and a minimal source file :
> >
> > __asm__ (".text\n"
> > ".globl _start\n"
> > "_start:\n"
> > "ldr sp, =0xA7E00000\n"
> > "bl main\n"
> > "stop:\n"
> > "b stop\n"
> > );
> >
> > int main (int argc, char *argv[])
> > {
> > return 0;
> > }
> >
> > I think I might still miss something because the assembler part gives me errors
> e.g.
> > " Error: no such instruction: 'ldr sp,=0xA7E00000' "
> > " Error: no such instruction: 'bl main' "
> > " Error: no such instruction: 'b stop' "
> >
> > Maybe a tab/space related issue ?
>
> Works for me (using the CodeSourcery toolchain):
>
> $ cat baretest.c
> __asm__ (".text\n"
> ".globl _start\n"
> "_start:\n"
> "ldr sp, =0xA7E00000\n"
> "bl main\n"
> "stop:\n"
> "b stop\n"
> );
>
> int main (int argc, char *argv[])
> {
> return 0;
> }
> $ arm-none-linux-gnueabi-gcc -Wall -Os -nostdlib baretest.c -o baretest.elf -Wl,-
> Ttext=0x78000000
> $ arm-none-linux-gnueabi-objdump -S baretest.elf
>
> baretest.elf: file format elf32-littlearm
>
>
> Disassembly of section .text:
>
> 78000000 <_start>:
> 78000000: e59fd00c ldr sp, [pc, #12] ; 78000014 <main+0x8>
> 78000004: eb000000 bl 7800000c <main>
>
> 78000008 <stop>:
> 78000008: eafffffe b 78000008 <stop>
>
> 7800000c <main>:
> 7800000c: e3a00000 mov r0, #0
> 78000010: e12fff1e bx lr
> 78000014: a7e00000 .word 0xa7e00000
>
> baruch
>
[Filip]
Baruch,
Compiling and linking seems to work well now. When I dump the .elf, I see that the start address is 0xA7E00000. That's what I wanted.
However, when loading the app in ram and executing it, I see that it tries to start from 0xA0000000 (this is the base address of the RAM section) :
barebox:/test tftp testapp.bin
TFTP from server 10.0.48.80 ('testapp.bin' -> 'testapp.bin')
barebox:/test cp testapp.bin /dev/ram0
barebox:/test go /dev/ram0
## Starting application at 0xA0000000 ...
?¶/ÿ'.e¢Óøñ_
_øýàõÒÿ ïO
ÿOÿðzþðöàþ A'}®ÿ
ùý"õÿ?O¿PP¼@Y
}¸m
×´ï@ïðx`G-/
Should I specify an address when executing 'go' or 'cp' ? Isn't it loading the app always at the beginning of the RAM space, i.e. 0xA0000000 ?
Filip
> --
> ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: test app
2011-03-08 15:52 ` Vanalme Filip
@ 2011-03-08 18:08 ` Baruch Siach
2011-03-09 8:28 ` Vanalme Filip
0 siblings, 1 reply; 16+ messages in thread
From: Baruch Siach @ 2011-03-08 18:08 UTC (permalink / raw)
To: Vanalme Filip; +Cc: barebox
Hi Vanalme,
On Tue, Mar 08, 2011 at 04:52:49PM +0100, Vanalme Filip wrote:
> Compiling and linking seems to work well now. When I dump the .elf, I see
> that the start address is 0xA7E00000. That's what I wanted.
> However, when loading the app in ram and executing it, I see that it tries to start from 0xA0000000 (this is the base address of the RAM section) :
>
> barebox:/test tftp testapp.bin
> TFTP from server 10.0.48.80 ('testapp.bin' -> 'testapp.bin')
>
> barebox:/test cp testapp.bin /dev/ram0
> barebox:/test go /dev/ram0
> ## Starting application at 0xA0000000 ...
> ?¶/ÿ'.e¢Óøñ_
>
> _øýàõÒÿ ïO
> ÿOÿðzþðöàþ A'}®ÿ
> ùý"õÿ?O¿PP¼@Y
> }¸m
> ×´ï@ïðx`G-/
>
>
> Should I specify an address when executing 'go' or 'cp' ? Isn't it loading the app always at the beginning of the RAM space, i.e. 0xA0000000 ?
Is 0xA0000000 the beginning of you external RAM?
Note that in my example I used /dev/sram0 (on-chip 128K SRAM), not /dev/ram0
(external DDR2 RAM).
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: test app
2011-03-08 18:08 ` Baruch Siach
@ 2011-03-09 8:28 ` Vanalme Filip
2011-03-14 14:55 ` Vanalme Filip
0 siblings, 1 reply; 16+ messages in thread
From: Vanalme Filip @ 2011-03-09 8:28 UTC (permalink / raw)
To: Baruch Siach; +Cc: barebox
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: dinsdag 8 maart 2011 19:09
> To: Vanalme Filip
> Cc: barebox@lists.infradead.org
> Subject: Re: test app
>
> Hi Vanalme,
>
> On Tue, Mar 08, 2011 at 04:52:49PM +0100, Vanalme Filip wrote:
> > Compiling and linking seems to work well now. When I dump the .elf, I see
> > that the start address is 0xA7E00000. That's what I wanted.
> > However, when loading the app in ram and executing it, I see that it tries to start
> from 0xA0000000 (this is the base address of the RAM section) :
> >
> > barebox:/test tftp testapp.bin
> > TFTP from server 10.0.48.80 ('testapp.bin' -> 'testapp.bin')
> >
> > barebox:/test cp testapp.bin /dev/ram0
> > barebox:/test go /dev/ram0
> > ## Starting application at 0xA0000000 ...
> > ?¶/ÿ'.e¢Óøñ_
> >
> > _øýàõÒÿ ïO
> > ÿOÿðzþðöàþ A'}®ÿ
> > ùý"õÿ?O¿PP¼@Y
> > }¸m
> > ×´ï@ïðx`G-/
> >
> >
> > Should I specify an address when executing 'go' or 'cp' ? Isn't it loading the app
> always at the beginning of the RAM space, i.e. 0xA0000000 ?
>
> Is 0xA0000000 the beginning of you external RAM?
[Filip] yes.
I meanwhile adjusted Makefile and test app source code to start from address 0xA0000000. This seem to work well. My test app is running now.
Because it's just a test app, I think it's OK to put it at the beginning of the external RAM (so at address 0xA0000000). No use in trying to move it to another region in the external RAM, is it ?
>
> Note that in my example I used /dev/sram0 (on-chip 128K SRAM), not /dev/ram0
> (external DDR2 RAM).
>
> baruch
>
[Filip] If I'm right (have to verify though), i.MX27 does not have any SRAM on board. So, I guess external RAM will be the only option. Because the test app resides in the external RAM, it won't be possible to test the whole RAM. But I think we can live with that limitation.
Thanks !
Filip
> --
> ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: test app
2011-03-09 8:28 ` Vanalme Filip
@ 2011-03-14 14:55 ` Vanalme Filip
2011-03-14 17:31 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-14 18:03 ` Baruch Siach
0 siblings, 2 replies; 16+ messages in thread
From: Vanalme Filip @ 2011-03-14 14:55 UTC (permalink / raw)
To: Baruch Siach; +Cc: barebox
Hi,
Would I have to change a lot if I would like to use standard libraries (e.g. stdio for printf and sprint) in my test app ?
Filip
> -----Original Message-----
> From: barebox-bounces@lists.infradead.org [mailto:barebox-
> bounces@lists.infradead.org] On Behalf Of Vanalme Filip
> Sent: woensdag 9 maart 2011 9:29
> To: Baruch Siach
> Cc: barebox@lists.infradead.org
> Subject: RE: test app
>
> > -----Original Message-----
> > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > Sent: dinsdag 8 maart 2011 19:09
> > To: Vanalme Filip
> > Cc: barebox@lists.infradead.org
> > Subject: Re: test app
> >
> > Hi Vanalme,
> >
> > On Tue, Mar 08, 2011 at 04:52:49PM +0100, Vanalme Filip wrote:
> > > Compiling and linking seems to work well now. When I dump the .elf, I see
> > > that the start address is 0xA7E00000. That's what I wanted.
> > > However, when loading the app in ram and executing it, I see that it tries to
> start
> > from 0xA0000000 (this is the base address of the RAM section) :
> > >
> > > barebox:/test tftp testapp.bin
> > > TFTP from server 10.0.48.80 ('testapp.bin' -> 'testapp.bin')
> > >
> > > barebox:/test cp testapp.bin /dev/ram0
> > > barebox:/test go /dev/ram0
> > > ## Starting application at 0xA0000000 ...
> > > ?¶/ÿ'.e¢Óøñ_
> > >
> > > _øýàõÒÿ ïO
> > > ÿOÿðzþðöàþ A'}®ÿ
> > > ùý"õÿ?O¿PP¼@Y
> > > }¸m
> > > ×´ï@ïðx`G-/
> > >
> > >
> > > Should I specify an address when executing 'go' or 'cp' ? Isn't it loading the
> app
> > always at the beginning of the RAM space, i.e. 0xA0000000 ?
> >
> > Is 0xA0000000 the beginning of you external RAM?
>
>
> [Filip] yes.
> I meanwhile adjusted Makefile and test app source code to start from address
> 0xA0000000. This seem to work well. My test app is running now.
> Because it's just a test app, I think it's OK to put it at the beginning of the external
> RAM (so at address 0xA0000000). No use in trying to move it to another region in
> the external RAM, is it ?
>
> >
> > Note that in my example I used /dev/sram0 (on-chip 128K SRAM), not /dev/ram0
> > (external DDR2 RAM).
> >
> > baruch
> >
>
> [Filip] If I'm right (have to verify though), i.MX27 does not have any SRAM on
> board. So, I guess external RAM will be the only option. Because the test app
> resides in the external RAM, it won't be possible to test the whole RAM. But I think
> we can live with that limitation.
>
> Thanks !
>
> Filip
> > --
> > ~. .~ Tk Open Systems
> > =}------------------------------------------------ooO--U--Ooo------------{=
> > - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: test app
2011-03-14 14:55 ` Vanalme Filip
@ 2011-03-14 17:31 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-14 18:03 ` Baruch Siach
1 sibling, 0 replies; 16+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-14 17:31 UTC (permalink / raw)
To: Vanalme Filip; +Cc: barebox
On 15:55 Mon 14 Mar , Vanalme Filip wrote:
> Hi,
>
> Would I have to change a lot if I would like to use standard libraries (e.g. stdio for printf and sprint) in my test app ?
I think of two ways
1) you could integrate in barebox the app implentation of u-boot
in dir api and examples / api /
this will allow to run application in barebox and be able to use
the std lib probide by barebox
2) re-implement them
Best Regards,
J.
>
>
> Filip
>
>
> > -----Original Message-----
> > From: barebox-bounces@lists.infradead.org [mailto:barebox-
> > bounces@lists.infradead.org] On Behalf Of Vanalme Filip
> > Sent: woensdag 9 maart 2011 9:29
> > To: Baruch Siach
> > Cc: barebox@lists.infradead.org
> > Subject: RE: test app
> >
> > > -----Original Message-----
> > > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > > Sent: dinsdag 8 maart 2011 19:09
> > > To: Vanalme Filip
> > > Cc: barebox@lists.infradead.org
> > > Subject: Re: test app
> > >
> > > Hi Vanalme,
> > >
> > > On Tue, Mar 08, 2011 at 04:52:49PM +0100, Vanalme Filip wrote:
> > > > Compiling and linking seems to work well now. When I dump the .elf, I see
> > > > that the start address is 0xA7E00000. That's what I wanted.
> > > > However, when loading the app in ram and executing it, I see that it tries to
> > start
> > > from 0xA0000000 (this is the base address of the RAM section) :
> > > >
> > > > barebox:/test tftp testapp.bin
> > > > TFTP from server 10.0.48.80 ('testapp.bin' -> 'testapp.bin')
> > > >
> > > > barebox:/test cp testapp.bin /dev/ram0
> > > > barebox:/test go /dev/ram0
> > > > ## Starting application at 0xA0000000 ...
> > > > ?¶/ÿ'.e¢Óøñ_
> > > >
> > > > _øýàõÒÿ ïO
> > > > ÿOÿðzþðöàþ A'}®ÿ
> > > > ùý"õÿ?O¿PP¼@Y
> > > > }¸m
> > > > ×´ï@ïðx`G-/
> > > >
> > > >
> > > > Should I specify an address when executing 'go' or 'cp' ? Isn't it loading the
> > app
> > > always at the beginning of the RAM space, i.e. 0xA0000000 ?
> > >
> > > Is 0xA0000000 the beginning of you external RAM?
> >
> >
> > [Filip] yes.
> > I meanwhile adjusted Makefile and test app source code to start from address
> > 0xA0000000. This seem to work well. My test app is running now.
> > Because it's just a test app, I think it's OK to put it at the beginning of the external
> > RAM (so at address 0xA0000000). No use in trying to move it to another region in
> > the external RAM, is it ?
> >
> > >
> > > Note that in my example I used /dev/sram0 (on-chip 128K SRAM), not /dev/ram0
> > > (external DDR2 RAM).
> > >
> > > baruch
> > >
> >
> > [Filip] If I'm right (have to verify though), i.MX27 does not have any SRAM on
> > board. So, I guess external RAM will be the only option. Because the test app
> > resides in the external RAM, it won't be possible to test the whole RAM. But I think
> > we can live with that limitation.
> >
> > Thanks !
> >
> > Filip
> > > --
> > > ~. .~ Tk Open Systems
> > > =}------------------------------------------------ooO--U--Ooo------------{=
> > > - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
> >
> > _______________________________________________
> > barebox mailing list
> > barebox@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/barebox
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: test app
2011-03-14 14:55 ` Vanalme Filip
2011-03-14 17:31 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2011-03-14 18:03 ` Baruch Siach
2011-03-15 11:03 ` Vanalme Filip
1 sibling, 1 reply; 16+ messages in thread
From: Baruch Siach @ 2011-03-14 18:03 UTC (permalink / raw)
To: Vanalme Filip; +Cc: barebox
Hi Vanalme,
On Mon, Mar 14, 2011 at 03:55:29PM +0100, Vanalme Filip wrote:
> Hi,
>
> Would I have to change a lot if I would like to use standard libraries (e.g.
> stdio for printf and sprint) in my test app ?
For printf you may use a standalone implementation, and just provide a putc()
routine. See the following implementations:
http://www.sparetimelabs.com/tinyprintf/index.html
http://www.menie.org/georges/embedded/
baruch
> > -----Original Message-----
> > From: barebox-bounces@lists.infradead.org [mailto:barebox-
> > bounces@lists.infradead.org] On Behalf Of Vanalme Filip
> > Sent: woensdag 9 maart 2011 9:29
> > To: Baruch Siach
> > Cc: barebox@lists.infradead.org
> > Subject: RE: test app
> >
> > > -----Original Message-----
> > > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > > Sent: dinsdag 8 maart 2011 19:09
> > > To: Vanalme Filip
> > > Cc: barebox@lists.infradead.org
> > > Subject: Re: test app
> > >
> > > Hi Vanalme,
> > >
> > > On Tue, Mar 08, 2011 at 04:52:49PM +0100, Vanalme Filip wrote:
> > > > Compiling and linking seems to work well now. When I dump the .elf, I see
> > > > that the start address is 0xA7E00000. That's what I wanted.
> > > > However, when loading the app in ram and executing it, I see that it tries to
> > start
> > > from 0xA0000000 (this is the base address of the RAM section) :
> > > >
> > > > barebox:/test tftp testapp.bin
> > > > TFTP from server 10.0.48.80 ('testapp.bin' -> 'testapp.bin')
> > > >
> > > > barebox:/test cp testapp.bin /dev/ram0
> > > > barebox:/test go /dev/ram0
> > > > ## Starting application at 0xA0000000 ...
> > > > ?¶/ÿ'.e¢Óøñ_
> > > >
> > > > _øýàõÒÿ ïO
> > > > ÿOÿðzþðöàþ A'}®ÿ
> > > > ùý"õÿ?O¿PP¼@Y
> > > > }¸m
> > > > ×´ï@ïðx`G-/
> > > >
> > > >
> > > > Should I specify an address when executing 'go' or 'cp' ? Isn't it loading the
> > app
> > > always at the beginning of the RAM space, i.e. 0xA0000000 ?
> > >
> > > Is 0xA0000000 the beginning of you external RAM?
> >
> >
> > [Filip] yes.
> > I meanwhile adjusted Makefile and test app source code to start from address
> > 0xA0000000. This seem to work well. My test app is running now.
> > Because it's just a test app, I think it's OK to put it at the beginning of the external
> > RAM (so at address 0xA0000000). No use in trying to move it to another region in
> > the external RAM, is it ?
> >
> > >
> > > Note that in my example I used /dev/sram0 (on-chip 128K SRAM), not /dev/ram0
> > > (external DDR2 RAM).
> > >
> > > baruch
> > >
> >
> > [Filip] If I'm right (have to verify though), i.MX27 does not have any SRAM on
> > board. So, I guess external RAM will be the only option. Because the test app
> > resides in the external RAM, it won't be possible to test the whole RAM. But I think
> > we can live with that limitation.
> >
> > Thanks !
> >
> > Filip
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: test app
2011-03-14 18:03 ` Baruch Siach
@ 2011-03-15 11:03 ` Vanalme Filip
2011-03-15 11:47 ` Zoltán Kócsi
0 siblings, 1 reply; 16+ messages in thread
From: Vanalme Filip @ 2011-03-15 11:03 UTC (permalink / raw)
To: Baruch Siach; +Cc: barebox
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: maandag 14 maart 2011 19:04
> To: Vanalme Filip
> Cc: barebox@lists.infradead.org
> Subject: Re: test app
>
> Hi Vanalme,
>
> On Mon, Mar 14, 2011 at 03:55:29PM +0100, Vanalme Filip wrote:
> > Hi,
> >
> > Would I have to change a lot if I would like to use standard libraries (e.g.
> > stdio for printf and sprint) in my test app ?
>
> For printf you may use a standalone implementation, and just provide a putc()
> routine. See the following implementations:
>
> http://www.sparetimelabs.com/tinyprintf/index.html
> http://www.menie.org/georges/embedded/
>
> baruch
[Filip]
Thanks for the information.
I guess this one is because I'm not an experienced programmer.... :
If I use a division operator or a modulo division operator in a static function, all compiles well. If I change the static function into a global function, I get following errors :
Undefined reference to '__aeabi_idiv'
Undefined reference to '__aeabi_idivmod'
The function looks basicly like this (just took the 'problem' part) :
static void testfunc (int row)
{
char c[2];
c[0] = row / 10 + '0';
row %= 10;
c[1] = row + '0';
}
This is how my Makefile looks like :
CC = $(CROSS_COMPILE)gcc
OBJCOPY = $(CROSS_COMPILE)objcopy
OBJDUMP = $(CROSS_COMPILE)objdump
AR = $(CROSS_COMPILE)ar
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
CFLAGS = -Wall -Os -nostdlib -Wl,-Ttext=0xA0000000
OBJECTS = testapp.o gpio.o uart.o time.o
SRCS = $(OBJECTS:.o=.c)
all: testapp.bin
%.bin : %.elf
$(OBJCOPY) -O binary $^ $@
%.elf : $(SRCS)
$(CC) $(CFLAGS) $^ -o $@
$(OBJDUMP) -S $@ > dump
.PHONY: clean
clean:
rm -f *bin *elf $(OBJECTS)
I never encountered this problem before in other projects and I don't see why this is working in static functions and not in global functions....
Filip
>
> > > -----Original Message-----
> > > From: barebox-bounces@lists.infradead.org [mailto:barebox-
> > > bounces@lists.infradead.org] On Behalf Of Vanalme Filip
> > > Sent: woensdag 9 maart 2011 9:29
> > > To: Baruch Siach
> > > Cc: barebox@lists.infradead.org
> > > Subject: RE: test app
> > >
> > > > -----Original Message-----
> > > > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > > > Sent: dinsdag 8 maart 2011 19:09
> > > > To: Vanalme Filip
> > > > Cc: barebox@lists.infradead.org
> > > > Subject: Re: test app
> > > >
> > > > Hi Vanalme,
> > > >
> > > > On Tue, Mar 08, 2011 at 04:52:49PM +0100, Vanalme Filip wrote:
> > > > > Compiling and linking seems to work well now. When I dump the .elf, I see
> > > > > that the start address is 0xA7E00000. That's what I wanted.
> > > > > However, when loading the app in ram and executing it, I see that it tries to
> > > start
> > > > from 0xA0000000 (this is the base address of the RAM section) :
> > > > >
> > > > > barebox:/test tftp testapp.bin
> > > > > TFTP from server 10.0.48.80 ('testapp.bin' -> 'testapp.bin')
> > > > >
> > > > > barebox:/test cp testapp.bin /dev/ram0
> > > > > barebox:/test go /dev/ram0
> > > > > ## Starting application at 0xA0000000 ...
> > > > > ?¶/ÿ'.e¢Óøñ_
> > > > >
> > > > > _øýàõÒÿ ïO
> > > > > ÿOÿðzþðöàþ A'}®ÿ
> > > > > ùý"õÿ?O¿PP¼@Y
> > > > > }¸m
> > > > > ×´ï@ïðx`G-/
> > > > >
> > > > >
> > > > > Should I specify an address when executing 'go' or 'cp' ? Isn't it loading the
> > > app
> > > > always at the beginning of the RAM space, i.e. 0xA0000000 ?
> > > >
> > > > Is 0xA0000000 the beginning of you external RAM?
> > >
> > >
> > > [Filip] yes.
> > > I meanwhile adjusted Makefile and test app source code to start from address
> > > 0xA0000000. This seem to work well. My test app is running now.
> > > Because it's just a test app, I think it's OK to put it at the beginning of the
> external
> > > RAM (so at address 0xA0000000). No use in trying to move it to another region
> in
> > > the external RAM, is it ?
> > >
> > > >
> > > > Note that in my example I used /dev/sram0 (on-chip 128K SRAM), not
> /dev/ram0
> > > > (external DDR2 RAM).
> > > >
> > > > baruch
> > > >
> > >
> > > [Filip] If I'm right (have to verify though), i.MX27 does not have any SRAM on
> > > board. So, I guess external RAM will be the only option. Because the test app
> > > resides in the external RAM, it won't be possible to test the whole RAM. But I
> think
> > > we can live with that limitation.
> > >
> > > Thanks !
> > >
> > > Filip
>
> --
> ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: test app
2011-03-15 11:03 ` Vanalme Filip
@ 2011-03-15 11:47 ` Zoltán Kócsi
0 siblings, 0 replies; 16+ messages in thread
From: Zoltán Kócsi @ 2011-03-15 11:47 UTC (permalink / raw)
To: barebox
> If I use a division operator or a modulo division operator in a
> static function, all compiles well. If I change the static function
> into a global function, I get following errors : Undefined reference
> to '__aeabi_idiv' Undefined reference to '__aeabi_idivmod'
Those are the division routines in gcc's libgcc.a library. Your problem
is this:
> CFLAGS = -Wall -Os -nostdlib -Wl,-Ttext=0xA0000000
-nostdlib tells the compiler not to link against the standard
libraries, which include libgcc.a.
> %.elf : $(SRCS)
> $(CC) $(CFLAGS) $^ -o $@
If you add a -lgcc to the line above, it should compile.
> I never encountered this problem before in other projects and I don't
> see why this is working in static functions and not in global
> functions....
Possibly because if you have static functions, then the compiler can
inline them. If after the inlining it can work out that you are
dividing with a constant, then it won't pull in the division routines,
but substitute division with a multiplication, two shifts and an
addition (the cost of calculating the constant to multiply with and
the shift amounts involves, among other things, a 64-bit division, but
that all happens in compile time - at runtime it's just the mul, shift,
add, which is orders of magnitue faster as well as smaller than a real
division). If you have a global function, gcc must assume that it can
be called with arbitrary arguments from other C files, therefore it must
do real (i.e. runtime) division.
Regards,
Zoltan
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-03-15 11:47 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-07 13:05 test app Vanalme Filip
2011-03-08 5:40 ` Baruch Siach
2011-03-08 8:13 ` Vanalme Filip
2011-03-08 10:09 ` Vanalme Filip
2011-03-08 11:22 ` Baruch Siach
2011-03-08 15:52 ` Vanalme Filip
2011-03-08 18:08 ` Baruch Siach
2011-03-09 8:28 ` Vanalme Filip
2011-03-14 14:55 ` Vanalme Filip
2011-03-14 17:31 ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-14 18:03 ` Baruch Siach
2011-03-15 11:03 ` Vanalme Filip
2011-03-15 11:47 ` Zoltán Kócsi
2011-03-08 11:43 ` Sascha Hauer
2011-03-08 12:43 ` Vanalme Filip
2011-03-08 11:50 ` Sascha Hauer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox