Dumb Question - Linkcmds and Heap initialization

[Joel Sherrill]

On 03/10/2010 10:07 AM, Robert S. Grimes wrote:
> Hi Joel,
>
> 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?
>
> 2. I removed the overlap, and now I get two calls to _Heap_Initialize 
> (as evidenced by my printk traces):
>
>    _Heap_Initialize: heap:96CDC8, start:990000, size:1048576, page:8
>    _Heap_Initialize: heap:96C598, start:AA0000, size:4292214784, page:8
>
> 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.
>
Looks like it has to do with the end of ram not being sized right.
> 3. Is the first _Heap_Initialize call for the RTEMS workspace?
>
Yes.
> 4. Is the second call for the libc heap (for malloc, new, etc.)?
>
Yes.  And it should be all available memory from the end of
workspace to the end of RAM.
> 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?
>
> void bsp_pretasking_hook(void)
> {
>     uint32_t        heap_start;
>     uint32_t          heap_size;
>     uint32_t          heap_end;
>
>     /* round up from the top of workspace to next 64k boundary, get
>      * default heapsize from linker script  */
>     heap_start = (((uint32_t)Configuration.work_space_start +
>            rtems_configuration_get_work_space_size()) + 0x18000) & 
> 0xffff0000;
>
>     heap_end = _heap_start + (uint32_t)&_HeapSize;
>
>     heap_size = (heap_end - heap_start);
>
_HeapSize is in the linkcmds and may be 0.  If it is 0,
then you are supposed to give all available memory to
the heap (ram_end - heap_start).

This is probably it.

And a shining example of exactly why this code should not
be distributed out in multiple copies across all the BSPs.
It is fragile and leads to inconsistent behaviour even when
it is implemented correctly. :)
>     _heap_start = heap_start;
>     _heap_end = heap_end;
>
>     _top_of_ram = heap_end;
>
>     bsp_libc_init((void *) heap_start, heap_size, 0); /* 64 * 1024 */
>
> }
>
> Thanks,
> -Bob
>
> ---- Original message ----
>
>
>     *Date:* Wed, 10 Mar 2010 09:31:34 -0600
>     *From:* Joel Sherrill <joel.sherrill at oarcorp.com>
>     *Subject:* Re: Dumb Question - Linkcmds and Heap initialization
>     *To:* "rsg at alum.mit.edu" <rsg at alum.mit.edu>
>     *Cc:* RTEMS Mailing List <rtems-users at rtems.org>
>     >On 03/10/2010 09:07 AM, Robert S. Grimes wrote:
>     >> Okay, some clarification and news...
>     >>
>     >> 1. Some of the output, such as the "calling ..." and
>     >> "bsp_pretasking_hook called..." are simple printk debugging
>     messages I
>     >> had added.
>     >>
>     >> 2. I've added some more debugging calls that indicate the heap
>     walker
>     >> is being called from malloc, but there is no evidence that the
>     heap
>     >> was ever initialized to begin with. This certainly would
>     explain the
>     >> following messages!
>     >>
>     >> It seems the problem lies within the BSP startup, or maybe what
>     the
>     >> RTEMS startup sequence expects from the BSP (and how linkcmds
>     affects
>     >> that, I suppose). So, my questions become thus:
>     >>
>     >> 1. When (and where) is the heap set up?
>     >>
>     >In 4.10, this is much neater and easier to answer since it
>     >is done in the same way across the BSPs. But in 4.9, the
>     >code was in each BSP.
>     >
>     >virtex/startup/bspstart.c has the code which does the heap in
>     >bsp_pretasking_hook. Workspace is carved out in bsp_start().
>     >
>     >It is possible that moving the base address up somehow caused
>     >an overlap. Is the section .textrom in the linker script causing
>     issues?
>     >
>     >Check that the workspace, heap, interrupt stack , .bss, etc do
>     not overlap.
>     >Make a good memory map.
>     >
>     >Check for overlaps. :)
>     >> 2. Is it possible that an uninitialized heap could actually work?
>     >>
>     >No. :)
>     >> 3. How could the start location of .text cause an (presumably
>     >> uninitialized) heap to either work or not?
>     >>
>     >It could mess up the math in the BSP.
>     >> 4. Again, I'm using powerpc/virtex BSP, under 4.9.0; has the
>     startup
>     >> been changed such that this problem has already been addressed?
>     >>
>     >If there was one of the common overlaps, it would be caught
>     >and reported now. If there was a math error, it would have been
>     >eliminated as that code is now shared across more BSPs.
>     >
>     >The old way had per BSP duplication of this and led to unique
>     >ways of doing it and unique bugs. :)
>     >
>     >--joel
>     >> Thanks again,
>     >> -Bob
>     >> Robert S. Grimes
>     >>
>     >> RSG Associates
>     >> Embedded Systems and Software Development
>     >> for Military, Aerospace, Industry - and beyond!
>     >> 617.697.8579
>     >> www.rsgassoc.com
>     >>
>     >>
>     >
>     >
>     >--
>     >Joel Sherrill, Ph.D. Director of Research& Development
>     >joel.sherrill at OARcorp.com On-Line Applications Research
>     >Ask me about RTEMS: a free RTOS Huntsville AL 35805
>     > Support Available (256) 722-9985
>     >
>     >
>
>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985