test app

test app

[Vanalme Filip]

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

Re: test app

[Baruch Siach]

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

RE: test app

[Vanalme Filip]

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

RE: test app

[Vanalme Filip]

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

Re: test app

[Baruch Siach]

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

Re: test app

[Sascha Hauer]

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

Re: test app

[Sascha Hauer]

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

RE: test app

[Vanalme Filip]

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

RE: test app

[Vanalme Filip]

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

Re: test app

[Baruch Siach]

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

RE: test app

[Vanalme Filip]

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

RE: test app

[Vanalme Filip]

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

Re: test app

[Jean-Christophe PLAGNIOL-VILLARD]

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

Re: test app

[Baruch Siach]

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

RE: test app

[Vanalme Filip]

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

Re: test app

[Zoltán Kócsi]

> 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