Skip to contentSkip to conversation

sandbox: Crash on startup

U-Boot Matthias Weisser 3 participants 5 messages Nov 1, 2011 – Nov 2, 2011

lore
Share & tools
lore
#0 lore raw

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

arch/sandbox/cpu/start.c +4 -0
index 685793e..c98ca61 100644
@@ -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?

Regards
Matthias

#1 lore raw

Mi Matthias,

Quoted 6 lines · Matthias Weisser

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:

Quoted 7 lines

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

Quoted 17 lines
arch/sandbox/cpu/start.c +0 -0
index 685793e..c98ca61 100644
@@ -21,8 +21,12 @@
 

?#include <common.h>

arch/sandbox/cpu/start.c +2 -0
+static uint8_t malloc_area[1024*1024*256];
+

?int main(int argc, char *argv[])
?{
+ ? ?mem_malloc_init(malloc_area, sizeof(malloc_area)); +
? ? ? ?/*

Quoted 5 lines

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

Quoted 3 lines

Regards
Matthias

#2 lore raw

Am 01.11.2011 15:01, schrieb Simon Glass:

Quoted 14 lines

Mi Matthias,

Quoted 11 lines · Matthias Weisser

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));
Quoted 8 lines
Quoted 2 lines

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?

This commit is there. But it seems to be ignored. dlmalloc.c is build and linked on my machine here.

Quoted 8 lines

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.

Please see http://patchwork.ozlabs.org/patch/123074/ I just posted. This may be a solution for this issue and we can use dlmalloc in sandbox.

Regards
Matthias

#3 lore raw
In reply to Simon Glass
Quoted 10 lines · On Tuesday 01 November 2011 10:01:53 Simon Glass wrote:
Quoted 9 lines · Matthias Weisser

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));
Quoted 8 lines
Quoted 2 lines

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?

hmm, this was working for me, but now it's not. so something has changed ...

but probably best to cut over to the mmap/virtual mapping route proposed elsewhere so that we can test the internal u-boot malloc and not worry about people accidentally breaking sandbox like this in the future.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111101/bdfab73e/attachment.pgp

#4 lore raw
Quoted 18 lines · Mike Frysinger
Quoted 17 lines · On Tuesday 01 November 2011 10:01:53 Simon Glass wrote:
Quoted 11 lines · Matthias Weisser

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

Quoted 9 lines
Quoted 1 line

Can you please check that it is there?

hmm, this was working for me, but now it's not. ?so something has changed ...

but probably best to cut over to the mmap/virtual mapping route proposed elsewhere so that we can test the internal u-boot malloc and not worry about people accidentally breaking sandbox like this in the future. -mike

Yes definitely - disabling dlmalloc was only a stopgap to reduce the size of the initial patch set.

Regards,
Simon