Dumb Question - Linkcmds and Heap initialization

Robert S. Grimes rsg at alum.mit.edu
Wed Mar 10 16:54:12 UTC 2010


  Hi Joel,

  Yup, you got it (but I still have "one" more
  question - see below).  So, I added a new printk
  into the routine, as follows:

  void bsp_pretasking_hook(void)
  {
    printk("bsp_pretasking_hook called...\n");  /* RSG
  */

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

      printk("Heap: start:$%08x, end:$%08x,
  size:$%08x, _heap_start:$%08x, _HeapSize:$%08x\n",
             heap_start, heap_end, heap_size,
  _heap_start, _HeapSize);

      _heap_start = heap_start;
      _heap_end = heap_end;

      _top_of_ram = heap_end;

      bsp_libc_init((void *) heap_start, heap_size,
  0); /* 64 * 1024 */

  }

  Here is the output:

  Heap: start:$00AA0000, end:$00800000,
  size:$FFD60000, _heap_start:$00000000,
  _HeapSize:$AAAA5555

  Three things:

  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?

  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?

  3. Near the top of linkcmds is this line:

    _HeapSize = DEFINED(_HeapSize) ? _HeapSize : 8M;

  Does this make any sense?

  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! 

  Thanks Joel (and Gedare),
  -Bob

  ---- Original message ----

    Date: Wed, 10 Mar 2010 10:24:21 -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 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
    >
    >

Robert S. Grimes

RSG Associates
Embedded Systems and Software Development
for Military, Aerospace, Industry - and beyond!
617.697.8579
www.rsgassoc.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100310/eb363dc2/attachment-0001.html>


More information about the users mailing list