Limiting program RAM addresses

[Mohammed Khoory]

>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