[U-Boot] dlmalloc: sbrk_base error after cpu reset.

Hi all,
I have a problem about malloc() fail after the cpu has been reset. This problem I have not encountered when porting with older version of u-boot. Unfortunately I've forget which version (commit) is still work with my port (NDS32)
The problem is that, after the command "reset" under u-boot console. The cpu will do flush I/D cache , disable interrupt , redo mem_malloc_init(). Then redo the init process.
Reset was successful, however, when the code is executed to himport default env, will encounter malloc fail in the himport_r function. It won't occur before reset.
The malloc() called in himport_r was the first time u-boot called malloc() after reset.
After I have traced into the dlmalloc, I've found that The 1st success u-boot startup, sbrk_base seems a correct value in malloc_extend_top().
(The following is gdb output) 2017 if (sbrk_base != (char*)(-1)) malloc_extend_top: sbrk_base: 0xffffffff, (char*)(-1): 0xffffffff Destroy Hash Table: 0321ea58 table = (null)
When the u-boot has been reset, sbrk_base seems not cleared/reset. (sbrk_base is a static global variable) (The following is gdb output after system has been reset) 2017 if (sbrk_base != (char*)(-1)) malloc_extend_top: sbrk_base: 0x03180000, (char*)(-1): 0xffffffff 2018 sbrk_size = (sbrk_size + (pagesz - 1)) & ~(pagesz - 1); malloc_extend_top: sbrk_size: 0x00000050
Is this correct? Should I clear sbrk_base after u-boot has been reset? Or it looks like where was the misconfiguration about the memory layout? Could anyone give some suggestion? Thanks a lot.

Dear Macpaul Lin,
In message AANLkTik5jU9nS=8Bx4Lf8hUZp5wyCKppuCLKGJvHJrq9@mail.gmail.com you wrote:
I have a problem about malloc() fail after the cpu has been reset. This problem I have not encountered when porting with older version of u-boot. Unfortunately I've forget which version (commit) is still work with my port (NDS32)
The problem is that, after the command "reset" under u-boot console. The cpu will do flush I/D cache , disable interrupt , redo mem_malloc_init(). Then redo the init process.
I'm not sure I understand what you mean. This shouds as if the "reset" command in U-Boot woul perform just apartial re-initialization of the software, but not a real hardware reset of the board?
Note that "reset" means a hard reset of the whole board, includine the CPU and all peripherals (similar to pressing a reset button, if there is one).
Best regards,
Wolfgang Denk

Dear Wolfgang,
2010/12/23 Wolfgang Denk wd@denx.de:
Dear Macpaul Lin,
In message macpaul@gmail.com you wrote:
The problem is that, after the command "reset" under u-boot console. The cpu will do flush I/D cache , disable interrupt , redo mem_malloc_init(). Then redo the init process.
I'm not sure I understand what you mean. This shouds as if the "reset" command in U-Boot woul perform just apartial re-initialization of the software, but not a real hardware reset of the board?
Yes, the "reset" in this problem is meant to the software reset "command" which could be manually executed from console.
If the "reset" command in u-boot just do apartial re-initialization, then I think the problem could not to allocate memory might be some static variable wasn't cleared after the reset process.
I think the "reset" command will called do_reset() here. void do_reset (cmd_tbl_t *cmdtp, bd_t *bd, int flag, int argc, char *argv[]) { ...... /*currently no ROM loader at addr 0. do not use reset_cpu(0) */ reset_cpu(CONFIG_SYS_TEXT_BASE); }
The CONFIG_SYS_TEXT_BASE is 0x3200000
I found that the problem cannot do malloc() after software reset might related to malloc_extend_top() is also failed.
The following debug output is the first cold boot of the u-boot. /* gdb load binary log */ Loading section .text, size 0x16ba4 lma 0x3200000 Loading section .rodata, size 0x12c4 lma 0x3216ba4 Loading section .rodata.str1.4, size 0x5d04 lma 0x3217e68 Loading section .rodata.cst4, size 0x8 lma 0x321db6c Loading section .data, size 0xb54 lma 0x321db74 Loading section .u_boot_cmd, size 0x450 lma 0x321e6c8 Start address 0x3200000, load size 125720
/* debug log of mem_malloc_init() */ mem_malloc_init: start: 0x03180000, size: 0x00080000
/* the first malloc has been called in himport_r() */ malloc: mem_malloc_start: 0x03180000, mem_malloc_end: 0x03200000 bytes: 0x0000001d is small request: nb: 40, idx: 5 malloc: remainder_size: -40, chunksize(top): 0, nb: 40 malloc_extend_top: old_end: 0x0321e040, old_top: 0x0321e040, old_top_size: 0x00000000 malloc_extend_top: &sbrk_base: 0x0321e448, sbrk_base: 0xffffffff, (char*)(-1): 0xffffffff Destroy Hash Table: 0321eb18 table = (null) Create Hash Table: N=67
/* the following is the debug output after the "reset" command" */ NDS32 # reset mem_malloc_init: start: 0x03180000, size: 0x00080000
malloc: mem_malloc_start: 0x03180000, mem_malloc_end: 0x03200000 bytes: 0x0000001d is small request: nb: 40, idx: 5 malloc: remainder_size: -40, chunksize(top): 0, nb: 40 malloc_extend_top: old_end: 0x03180570, old_top: 0x03180570, old_top_size: 0x00000000 malloc_extend_top: &sbrk_base: 0x0321e448, sbrk_base: 0x03180000, (char*)(-1): 0xffffffff malloc_extend_top: sbrk_size: 0x00000038 malloc: remainder_size: -40 himport_r: can't malloc 29 bytes ERROR: Environment import failed: errno = 12
Note that "reset" means a hard reset of the whole board, includine the CPU and all peripherals (similar to pressing a reset button, if there is one).
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Insults are effective only where emotion is present. -- Spock, "Who Mourns for Adonais?" stardate 3468.1

HI all,
2010/12/24 Macpaul Lin macpaul@gmail.com:
Dear Wolfgang,
2010/12/23 Wolfgang Denk wd@denx.de:
Dear Macpaul Lin,
In message macpaul@gmail.com you wrote:
The problem is that, after the command "reset" under u-boot console. The cpu will do flush I/D cache , disable interrupt , redo mem_malloc_init(). Then redo the init process.
I'm not sure I understand what you mean. This shouds as if the "reset" command in U-Boot woul perform just apartial re-initialization of the software, but not a real hardware reset of the board?
Yes, the "reset" in this problem is meant to the software reset "command" which could be manually executed from console.
If the "reset" command in u-boot just do apartial re-initialization, then I think the problem could not to allocate memory might be some static variable wasn't cleared after the reset process.
This problem (couldn't do malloc after reset) has been solved with patch "[PATCH] common/dlmalloc: support reinit bin for fast reset" for platforms enabled "CONFIG_SKIP_LOWLEVEL_INIT" and do reset_cpu(CONFIG_SYS_TEXT_BASE).
participants (2)
-
Macpaul Lin
-
Wolfgang Denk