<HTML><BODY>Hi Joel,<br>
<br>
Yup, you got it (but I still have "one" more question - see below). So, I added a new printk into the routine, as follows:<br>
<br>
void bsp_pretasking_hook(void)<br>
{<br>
printk("bsp_pretasking_hook called...\n"); /* RSG */<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>
printk("Heap: start:$%08x, end:$%08x, size:$%08x, _heap_start:$%08x, _HeapSize:$%08x\n",<br>
heap_start, heap_end, heap_size, _heap_start, _HeapSize);<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>
Here is the output:<br>
<br>
Heap: start:$00AA0000, end:$00800000, size:$FFD60000, _heap_start:$00000000, _HeapSize:$AAAA5555<br>
<br>
Three things:<br>
<br>
1. The calculation of heap_end is wrong, first because it should (I think) use heap_start, not _heap_start; and second, because it doesn't handle the "if _HeapSize is 0, use all of RAM" semantics. Correct?<br>
<br>
2. _HeapSize appears to be a variable in RAM whose value is not initialized (hence the $AAAA5555 value). Why is that? Where should it get its initial value?<br>
<br>
3. Near the top of linkcmds is this line:<br>
<br>
_HeapSize = DEFINED(_HeapSize) ? _HeapSize : 8M;<br>
<br>
Does this make any sense?<br>
<br>
At this point, I think I could hack something that would work for me, if this is all too much trouble. After all, even if I do fix it "correctly", this has all changed in 4.10! <br>
<br>
Thanks Joel (and Gedare),<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 10:24:21 -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 10:07 AM, Robert S. Grimes wrote:<br>
>> Hi Joel,<br>
>><br>
>> 1. Yeah, there was an overlap between .text and .textrom. FWIW, for <br>
>> my system, the executable file is loaded (i.e. sections placed, etc.) <br>
>> by MicroMonitor, and there isn't really any need to place .textrom at <br>
>> a specific location (i.e. into a physical EPROM), so I just removed <br>
>> the address and let it get placed after the rest of the sections. Is <br>
>> my interpretation correct on the meaning of .textrom?<br>
>><br>
>> 2. I removed the overlap, and now I get two calls to _Heap_Initialize <br>
>> (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 <br>
>> bogus. Indeed, immediately (in human terms) after the second call, <br>
>> the Heap Walker goes nuts as before while walking through the second heap.<br>
>><br>
>Looks like it has to do with the end of ram not being sized right.<br>
>> 3. Is the first _Heap_Initialize call for the RTEMS workspace?<br>
>><br>
>Yes.<br>
>> 4. Is the second call for the libc heap (for malloc, new, etc.)?<br>
>><br>
>Yes. And it should be all available memory from the end of<br>
>workspace to the end of RAM.<br>
>> 5. I'm guessing the problem is the calculation of the size for the <br>
>> second heap. That's in bspstart.c, right? Specifically, it seems to <br>
>> 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) & <br>
>> 0xffff0000;<br>
>><br>
>> heap_end = _heap_start + (uint32_t)&_HeapSize;<br>
>><br>
>> heap_size = (heap_end - heap_start);<br>
>><br>
>_HeapSize is in the linkcmds and may be 0. If it is 0,<br>
>then you are supposed to give all available memory to<br>
>the heap (ram_end - heap_start).<br>
><br>
>This is probably it.<br>
><br>
>And a shining example of exactly why this code should not<br>
>be distributed out in multiple copies across all the BSPs.<br>
>It is fragile and leads to inconsistent behaviour even when<br>
>it is implemented correctly. :)<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>
>><br>
>><br>
>> *Date:* Wed, 10 Mar 2010 09:31:34 -0600<br>
>> *From:* Joel Sherrill <joel.sherrill@oarcorp.com><br>
>> *Subject:* Re: Dumb Question - Linkcmds and Heap initialization<br>
>> *To:* "rsg@alum.mit.edu" <rsg@alum.mit.edu><br>
>> *Cc:* 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<br>
>> messages I<br>
>> >> had added.<br>
>> >><br>
>> >> 2. I've added some more debugging calls that indicate the heap<br>
>> walker<br>
>> >> is being called from malloc, but there is no evidence that the<br>
>> heap<br>
>> >> was ever initialized to begin with. This certainly would<br>
>> explain the<br>
>> >> following messages!<br>
>> >><br>
>> >> It seems the problem lies within the BSP startup, or maybe what<br>
>> the<br>
>> >> RTEMS startup sequence expects from the BSP (and how linkcmds<br>
>> 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<br>
>> issues?<br>
>> ><br>
>> >Check that the workspace, heap, interrupt stack , .bss, etc do<br>
>> 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<br>
>> 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>
>><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>
<DIV class=mirapoint-signature>
<PRE>
Robert S. Grimes
RSG Associates
Embedded Systems and Software Development
for Military, Aerospace, Industry - and beyond!
617.697.8579
www.rsgassoc.com
</PRE>
</DIV>
</BODY></HTML>