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