Dumb Question - Linkcmds and Heap initialization

[Robert S. Grimes]

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.

3. Is the first _Heap_Initialize call for the RTEMS
workspace?

4. Is the second call for the libc heap (for malloc,
new, etc.)?

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);

    _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
  >
  >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100310/3fe05bd6/attachment-0001.html>