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