Upper limit for BSS on SPARC BSP ?

Jiri Gaisler jiri at gaisler.se
Sat Sep 8 08:21:31 UTC 2018



On 09/07/2018 07:47 AM, Hugues Jérôme wrote:
> Thanks Sebastian and Joel, we will try your suggestions
>
> I’ll see with partners what is feasible. I also suspect a difference
> of behaviour between dmon and grmon monitors when loading the program
> in memory
>
> Note I may have been misleading somehow: 
> our test program with a BSS of 1MB works perfectly fine, 
> the exact same program, with a different set of size for our data has
> a BSS of 4MB, and crashes due to an alignment error at RTEMS start up.
>
> The second seems to point to an unexpected behavior in the code
> setting the BSS

Check that the external memory is working correctly, and that grmon has
set the stack pointer to top of external SDRAM. With 1 MByte BSS, you
might be executing completely from L2 cache, so you will never access
external RAM. With 4 MByte, you will hit the external RAM and this might
lead to failures if it is not working or initialized correctly. You
might need to 'wash' the external memory before first use if it uses
external EDAC, otherwise you will get spurious EDAC errors on byte
writes. Use the wash command in grmon or similar.

Also check that the program is linked to start address that is withing
the RAM boundaries. Note that GR740 has start of SDRAM at address 0x0
while most leon2/3 systems has this at 0x40000000. A general leon3
binary will then not run properly on GR740 except when it fits in the L2
cache.

Jiri.

>
> Regards
>
>> Le 7 sept. 2018 à 07:39, Sebastian Huber
>> <sebastian.huber at embedded-brains.de
>> <mailto:sebastian.huber at embedded-brains.de>> a écrit :
>>
>> On 05/09/18 15:45, Hugues Jérôme wrote:
>>> Hi Sebastian,
>>>
>>>> Le 5 sept. 2018 à 14:20, Sebastian Huber
>>>> <sebastian.huber at embedded-brains.de
>>>> <mailto:sebastian.huber at embedded-brains.de>> a écrit :
>>>>
>>>> Hello Hugues,
>>>>
>>>> On 05/09/18 14:02, Hugues Jérôme wrote:
>>>>> Hi,
>>>>>
>>>>> I’m investigating a memory alignement issue using the GR740 BSP.
>>>>> It appears we have a memory corruption when the BSS is bigger than
>>>>> 4MB.
>>>> does the ELF file look all right? Is the stack pointer at the end
>>>> of RAM right at the entry point (start)? Is the BSS section
>>>> properly zeroed in the startup sequence?
>>> I’m not sure I can provide any positive answer to these questions.
>>> We used the default GR740 BSP, compiled by Thanassis Tsiodras. We
>>> did not change anything
>>>
>>> As far as i can see, the BSS is zeroed by start.S
>>> do you have any recommendation to perform the diagnosis you prescribe ?
>>
>> I would check this with the debugger.
>>
>>>
>>> As far as I can provide details
>>> size (from binutils) can parse the ELF file, but that does not mean
>>> a lot
>>> stack pointer is set by the linker script (if I understood correctly
>>> this part), and we did not change it
>>
>> The boot loader sets the stack pointer to the end of the usable RAM.
>>
>> I would try to test this BSS size with a simple example program from
>> the RTEMS testsuite using the RTEMS BSP build tree (configure the BSP
>> build with --enable-tests=samples), e.g. modify the
>> testsuites/samples/ticker program.
>>
>> -- 
>> 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
>> <mailto:sebastian.huber at embedded-brains.de>
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180908/b7c377e7/attachment-0002.html>


More information about the users mailing list