Limiting program RAM addresses

[Mohammed Khoory]

I think I figured out why RTEMS on LEON3 keeps ignoring the linker script
when it comes to RAM initialization. Basically, in the start-up code
(start.S), the variable rdb_start is initialized from the register value of
%sp (aka register g6). rdb_start is then treated by the BSP code as the end
of the RAM and uses it to initialize the RAM which includes the heap and
stack.

When running an application from GRMON this register gets set automatically
during initialization. I would imagine that the mkprom packager also does
this when decompressing the image. The value is 32 bytes minus the last RAM
address.

I'm mostly wondering why this is done and not simply by using the linker
script and having the user specify how much RAM is avaliable? My
understanding is that some debugging stub is stored in the last 32 bytes of
RAM and there shouldn't be any overlap as a result of this. Is this right?
The comments in start.S also mention that there's a "bug in linker", but
this comment is from 2006 from what I can see, so I'm not sure if it still
applies. I would appreciate any insight into this.

Thanks!

>-----Original Message-----
>From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org]
>On Behalf Of Mohammed Khoory
>Sent: Tuesday, December 10, 2013 9:24 AM
>To: 'Sebastian Huber'; rtems-users at rtems.org
>Subject: RE: Limiting program RAM addresses
>
>>On 2013-12-09 07:05, Mohammed Khoory wrote:
>>> It's probably very GCC specific, but that's ok as long as it does the
>job.
>>> While it would seem that the buffer is indeed allocated at 0x40200000,
>>> the heap still allocates memory blocks on top of it which means that
>>> corruption still occurs.
>>
>>Yes, this is due to the SPARC low-level initialization.  Why do you need
>the
>>ramdisk at a fixed location?
>>
>
>After a board reset, the OS might need to mount the filesystem again as it
>was before the reset (the memory is not cleared). It is easier to work with
>a fixed and well-known address for this scenario
>
>Additionally, being able to take a memory dump of the filesystem from a
>fixed and unchanging memory location rather than a variable one would
>probably assist debugging a lot.
>
>>>
>>> I'm starting to suspect that this is because RTEMS, newlib, and the
>>> other libraries were compiled with the old linker script. Is this the
>>> case, or am I missing something?
>>
>>For the compiler the linker command file is irrelevant.
>>
>
>Yeah that was a wrong thing to suspect... I was running out of ideas I
>guess.
>
>>--
>>Sebastian Huber, embedded brains GmbH
>>
>>Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>Phone   : +49 89 189 47 41-16
>>Fax     : +49 89 189 47 41-09
>>E-Mail  : sebastian.huber at embedded-brains.de
>>PGP     : Public key available on request.
>>
>>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>_______________________________________________
>>rtems-users mailing list
>>rtems-users at rtems.org
>>http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>_______________________________________________
>rtems-users mailing list
>rtems-users at rtems.org
>http://www.rtems.org/mailman/listinfo/rtems-users