Mi Matthias,
On Tue, Nov 1, 2011 at 2:50 AM, Matthias Weisser <weiss...@arcor.de> wrote:
> Dear Simon
>
> I just wanted to play around with the sandbox "arch" of u-boot maybe
> adding tun/tap support. Current head compiled successfully but crashed
> immediately after startup in board_init_f:
>
> gd = malloc(sizeof(gd_t));
> assert(gd);
>
> memset((void *)gd, 0, sizeof(gd_t));
>
> The simple reason was that malloc refers to u-boots internal malloc
> which is not initialized at this point. I added the following snippet
That is odd. This commit is supposed to switch over to the system malloc():
fe34107 sandbox: Disable built-in malloc
Can you please check that it is there?
>
> diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
> index 685793e..c98ca61 100644
> --- a/arch/sandbox/cpu/start.c
> +++ b/arch/sandbox/cpu/start.c
> @@ -21,8 +21,12 @@
>
> #include <common.h>
>
> +static uint8_t malloc_area[1024*1024*256];
> +
> int main(int argc, char *argv[])
> {
> + mem_malloc_init(malloc_area, sizeof(malloc_area));
> +
> /*
>
> and got the console working. Can you tell me what I am doing wrong when
> building u-boot from current head? Wouldn't it be a better approach to
> use the internal malloc of u-boot and acquire some memory from the
> system using mmap?
>
I would first check that dlmalloc.o is not being linked, and that
mem_malloc_init() is undefined.
The current setup works OK for me, but yes it would be nice use
U-Boot's internal malloc(). The initial effort was to get a baseline
implementation into U-Boot and there are a number of areas where it
can be expanded. We want to test as much as possible of the code, and
dlmalloc is no exception.
Regards,
Simon
> Regards
> Matthias
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
