<HTML><BODY>Hi Joel,<br>
<br>
1. Yeah, there was an overlap between .text and .textrom. FWIW, for my system, the executable file is loaded (i.e. sections placed, etc.) by MicroMonitor, and there isn't really any need to place .textrom at a specific location (i.e. into a physical EPROM), so I just removed the address and let it get placed after the rest of the sections. Is my interpretation correct on the meaning of .textrom?<br>
<br>
2. I removed the overlap, and now I get two calls to _Heap_Initialize (as evidenced by my printk traces):<br>
<br>
_Heap_Initialize: heap:96CDC8, start:990000, size:1048576, page:8<br>
_Heap_Initialize: heap:96C598, start:AA0000, size:4292214784, page:8<br>
<br>
Looks better, except that the size of the second call is clearly bogus. Indeed, immediately (in human terms) after the second call, the Heap Walker goes nuts as before while walking through the second heap.<br>
<br>
3. Is the first _Heap_Initialize call for the RTEMS workspace?<br>
<br>
4. Is the second call for the libc heap (for malloc, new, etc.)?<br>
<br>
5. I'm guessing the problem is the calculation of the size for the second heap. That's in bspstart.c, right? Specifically, it seems to be here, in bsp_pretasking_hook() - is that right?<br>
<br>
void bsp_pretasking_hook(void)<br>
{<br>
uint32_t heap_start;<br>
uint32_t heap_size;<br>
uint32_t heap_end;<br>
<br>
/* round up from the top of workspace to next 64k boundary, get<br>
* default heapsize from linker script */<br>
heap_start = (((uint32_t)Configuration.work_space_start +<br>
rtems_configuration_get_work_space_size()) + 0x18000) & 0xffff0000;<br>
<br>
heap_end = _heap_start + (uint32_t)&_HeapSize;<br>
<br>
heap_size = (heap_end - heap_start);<br>
<br>
_heap_start = heap_start;<br>
_heap_end = heap_end;<br>
<br>
_top_of_ram = heap_end;<br>
<br>
bsp_libc_init((void *) heap_start, heap_size, 0); /* 64 * 1024 */<br>
<br>
}<br>
<br>
Thanks,<br>
-Bob<br>
<br>
---- Original message ----<br>
<blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;"><br>
<b>Date:</b> Wed, 10 Mar 2010 09:31:34 -0600<br>
<b>From:</b> Joel Sherrill <joel.sherrill@oarcorp.com><br>
<b>Subject:</b> Re: Dumb Question - Linkcmds and Heap initialization<br>
<b>To:</b> "rsg@alum.mit.edu" <rsg@alum.mit.edu><br>
<b>Cc:</b> RTEMS Mailing List <rtems-users@rtems.org><br>
>On 03/10/2010 09:07 AM, Robert S. Grimes wrote:<br>
>> Okay, some clarification and news...<br>
>><br>
>> 1. Some of the output, such as the "calling ..." and <br>
>> "bsp_pretasking_hook called..." are simple printk debugging messages I <br>
>> had added.<br>
>><br>
>> 2. I've added some more debugging calls that indicate the heap walker <br>
>> is being called from malloc, but there is no evidence that the heap <br>
>> was ever initialized to begin with. This certainly would explain the <br>
>> following messages!<br>
>><br>
>> It seems the problem lies within the BSP startup, or maybe what the <br>
>> RTEMS startup sequence expects from the BSP (and how linkcmds affects <br>
>> that, I suppose). So, my questions become thus:<br>
>><br>
>> 1. When (and where) is the heap set up?<br>
>><br>
>In 4.10, this is much neater and easier to answer since it<br>
>is done in the same way across the BSPs. But in 4.9, the<br>
>code was in each BSP.<br>
><br>
>virtex/startup/bspstart.c has the code which does the heap in<br>
>bsp_pretasking_hook. Workspace is carved out in bsp_start().<br>
><br>
>It is possible that moving the base address up somehow caused<br>
>an overlap. Is the section .textrom in the linker script causing issues?<br>
><br>
>Check that the workspace, heap, interrupt stack , .bss, etc do not overlap.<br>
>Make a good memory map.<br>
><br>
>Check for overlaps. :)<br>
>> 2. Is it possible that an uninitialized heap could actually work?<br>
>><br>
>No. :)<br>
>> 3. How could the start location of .text cause an (presumably <br>
>> uninitialized) heap to either work or not?<br>
>><br>
>It could mess up the math in the BSP.<br>
>> 4. Again, I'm using powerpc/virtex BSP, under 4.9.0; has the startup <br>
>> been changed such that this problem has already been addressed?<br>
>><br>
>If there was one of the common overlaps, it would be caught<br>
>and reported now. If there was a math error, it would have been<br>
>eliminated as that code is now shared across more BSPs.<br>
><br>
>The old way had per BSP duplication of this and led to unique<br>
>ways of doing it and unique bugs. :)<br>
><br>
>--joel<br>
>> Thanks again,<br>
>> -Bob<br>
>> Robert S. Grimes<br>
>><br>
>> RSG Associates<br>
>> Embedded Systems and Software Development<br>
>> for Military, Aerospace, Industry - and beyond!<br>
>> 617.697.8579<br>
>> www.rsgassoc.com<br>
>><br>
>> <br>
><br>
><br>
>-- <br>
>Joel Sherrill, Ph.D. Director of Research& Development<br>
>joel.sherrill@OARcorp.com On-Line Applications Research<br>
>Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
> Support Available (256) 722-9985<br>
><br>
><br>
</blockquote><br>
</BODY></HTML>