Réf : Re: Réf : Réf : Re: Réf : Re: Réf : Re: Réf : Re: Init of the memory by RTEMS

Leonard Bise leonard.bise at syderal.ch
Thu Dec 10 14:36:55 UTC 2009


Well, I can't use this method because I have a requirement that the 
application shall be linked at 0x4000'0000 ... It'd  have quite an impact 
to change this.

I think a solution would be to set the stack pointer below my famous 
address before starting the execution of the appli and since RTEMS takes 
the value of the sp to clear the workspace that could work.

Léonard.




Aleix Conchillo Flaqué <aconchillo at ice.csic.es> 
Envoyé par : aconchillo at gmail.com
10.12.2009 15:16

A
Leonard Bise <leonard.bise at syderal.ch>
cc
"rtems-users at rtems.org" <rtems-users at rtems.org>
Objet
Re: Réf : Réf : Re: Réf : Re: Réf : Re: Réf : Re: Init of the memory by 
RTEMS






Did you try to use the area on top of your application (modifying the 
ORIGIN) as I mentioned in a previous mail?

It works for me, and this way you are safe if you increase the RAM size or 
your application needs more space.

On Thu, Dec 10, 2009 at 14:53, Leonard Bise <leonard.bise at syderal.ch> 
wrote:

Actually using CONFIGURE_EXECUTIVE_RAM_WORK_AREA does not change anything. 


That's because in bsp_start function the following overwrites this value: 

  work_space_start = (unsigned char *)rdb_start; 
  work_space_start -= BSP_Configuration.work_space_size; 
  BSP_Configuration.work_space_start = work_space_start; 

rdb_start has the value 0x401F FFF0 which is the end of my RAM. rdb_start 
is set in start.S like so : set        (SYM(rdb_start)), %g6        ! End 
of work-space area  but I can't seem to find when is the g6 register 
loaded... 

Basically I don't see how to solve my problem because if in the linker 
script I specify a RAM size smaller, the BSP ignores it and use rdb_start 
instead which has the last address of my RAM but I don't know how it gets 
it. Specifying a start addr using the  CONFIGURE_EXECUTIVE_RAM_WORK_AREA 
define does not do anything either. 

Is there any other possibility I'm missing there? 

Léonard. 



Leonard Bise <leonard.bise at syderal.ch> 
Envoyé par : rtems-users-bounces at rtems.org 
10.12.2009 14:18 


A
Joel Sherrill <joel.sherrill at oarcorp.com> 
cc
"rtems-users at rtems.org" <rtems-users at rtems.org> 
Objet
Réf : Re: Réf : Re: Réf : Re: Réf : Re: Init of the memory by RTEMS









After looking around I found exactly where the data is being cleared. 

In function _Workspace_Handler_initialization, RTEMS clears the whole 
workspace. 
This operation is controlled by a flag but it is always set to true so 
there is no easy way around it. 

The start address for this operation is 0x401df7f0 and the size is 133120. 


I guess I can use CONFIGURE_EXECUTIVE_RAM_WORK_AREA to specify a start 
address for the workspace that is not so close from the end of the RAM and 
thus it won't clear all of it. Am I correct? 

Léonard. 


Joel Sherrill <joel.sherrill at oarcorp.com> 
10.12.2009 13:15 


A
Leonard Bise <leonard.bise at syderal.ch> 
cc
Aleix Conchillo Flaqué <aconchillo at ice.csic.es>, "rtems-users at rtems.org" <
rtems-users at rtems.org> 
Objet
Re: Réf : Re: Réf : Re: Réf : Re: Init of the memory by RTEMS










On 12/10/2009 01:37 AM, Leonard Bise wrote:
>
> I tried this methode but surprinsingly the memory in this area STILL 
> gets erased. I don't know by what  and it does not make any sense 
either.
>
> 401e0000 g       *ABS*        00000000 _RAM_END
>
> That seems correct but something is STILL clearing that damn memory !
>
Are you doing a CPU reset?

Do you have GRMON?  I think it clears memory also.
> I'm seriously lost now..
>
> Léonard.
>
>
>
>
> *Joel Sherrill <joel.sherrill at oarcorp.com>*
>
> 09.12.2009 20:28
>
>                  
> A
>                  Aleix Conchillo Flaqué <aconchillo at ice.csic.es>
> cc
>                  Leonard Bise <leonard.bise at syderal.ch>, "
rtems-users at rtems.org" 
> <rtems-users at rtems.org>
> Objet
>                  Re: Réf : Re: Réf : Re: Init of the memory by RTEMS
>
>
>
>                  
>
>
>
>
>
> On 12/09/2009 10:24 AM, Aleix Conchillo Flaqué wrote:
> > Why don't you just change the start of your Application? For example:
> >
> >
> > MEMORY
> > {
> >   ram     : ORIGIN = 0x40020000, LENGTH = 2M - 128 K
> > }
> >
> > RTEMS will not modify anything from 0x40000000 to 0x4001FFFF.
> >
> Or simply leave ORIGIN alone and subtract 128K from the LENGTH.
> Either way works.  But you can't tell RTEMS about it. :)
>
> --joel
> >
> > On Wed, Dec 9, 2009 at 14:26, Leonard Bise <leonard.bise at syderal.ch
> > <mailto:leonard.bise at syderal.ch>> wrote:
> >
> >
> >     Thanks for your answer Joel.
> >
> >     We are using the 4.6 version of RTEMS so I guess the memory must
> >     be cleared.
> >
> >     I already use a customized linkcmds file in this application, to
> >     specify various sections and other stuff.
> >
> >     Thats what I modified for my RAM size :
> >
> >     RAM_SIZE   = 2M ;
> >
> >     EEPROM_SIZe = 512K ;
> >
> >     PROM_SIZE        = 64K ;
> >
> >     RAM_END = RAM_START + RAM_SIZE;
> >
> >     MEMORY
> >     {
> >       rom     : ORIGIN = 0x00000000, LENGTH = 64K
> >       ram     : ORIGIN = 0x40000000, LENGTH = 2M
> >       eeprom  : ORIGIN = 0x60000000, LENGTH = 512K
> >     }
> >
> > >If you do not reserve the memory area out of the linkcmds, then
> > >it is likely to be used for some other purpose and overwritten.
> >
> >     How can I reserve memory ? I tried creating a section like this :
> >
> >       sCCA_Main 0x401E7000: {
> >         *(sCCA_Main)
> >        } > ram
> >
> >     then my var in the code looks like this :
> >
> >     uint32 PkgHW_CCA_main __attribute__ (( section ( "sCCA_Main" ) ) ) 
;
> >
> >     But this does not work, the data I place in 0x401E7000 before
> >     starting execution of my RTEMS apps is overwritten by 0.
> >     Hope you can help.
> >
> >     Léonard.
> >
> >
> >
> >
> >     *Joel Sherrill <joel.sherrill at oarcorp.com
> > <mailto:joel.sherrill at oarcorp.com>>*
> >
> >     09.12.2009 14:16
> >
> >
> >     A
> >                      Leonard Bise <leonard.bise at syderal.ch
> > <mailto:leonard.bise at syderal.ch>>
> >     cc
> >                      Sebastian Huber 
<sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at embedded-brains.de>>,
> >     "rtems-users at rtems.org <mailto:rtems-users at rtems.org>"
> > <rtems-users at rtems.org <mailto:rtems-users at rtems.org>>
> >     Objet
> >                      Re: Réf : Re: Init of the memory by RTEMS
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >     On 12/09/2009 06:41 AM, Leonard Bise wrote:
> > >
> > > I forgot to mention it.
> > >
> > > I'm using RTEMS for the LEON2 platform.
> > >
> >     Version?
> > > Also I'm not too sure how to know the address of the workspace
> >     or heap?
> > >
> >     They are next to each other and the linkcmds and symbol
> >     table from your application should give the information.
> >
> >     Where did  you override the RAM size?  The linkcmds
> >     has this:
> >
> >     MEMORY
> >     {
> >       rom     : ORIGIN = 0x00000000, LENGTH = 256M
> >       ram     : ORIGIN = 0x40000000, LENGTH = 1024M
> >     }
> >
> >     And the start.S zeroes out the BSS from "_edata"
> >     to "_end".
> >
> >     The addresses you mentioned will be part of the
> >     unused memory from after the bss until the end of ram
> >     and since you didn't tell the linkcmds or RTEMS about them,
> >     they will be put in either the Workspace or C Program Heap
> >     and used by something.
> >
> >
> >
> >     --joel
> >
> > > Léonard.
> > >
> > >
> > >
> > > *Sebastian Huber <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at embedded-brains.de>>*
> > >
> > > 09.12.2009 11:31
> > >
> > >
> > > A
> > >                  Leonard Bise <leonard.bise at syderal.ch
> > <mailto:leonard.bise at syderal.ch>>
> > > cc
> > > rtems-users at rtems.org <mailto:rtems-users at rtems.org>
> > > Objet
> > >                  Re: Init of the memory by RTEMS
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > > which BSP do you use? Is the memory address 0x401E7000 part of the
> > > workspace or
> > > heap?
> > >
> > > CU
> > >
> > > --
> > > Sebastian Huber, embedded brains GmbH
> > >
> > > Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
> > > Phone   : +49 89 18 90 80 79-6
> > > Fax     : +49 89 18 90 80 79-9
> > > 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.
> > >
> >
> >
> >
> >     _______________________________________________
> >     rtems-users mailing list
> >     rtems-users at rtems.org <mailto:rtems-users at rtems.org>
> > http://www.rtems.org/mailman/listinfo/rtems-users
> >
> >
>
>
> -- 
> 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
>
>
>

_______________________________________________
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20091210/7fc62f2b/attachment-0001.html>


More information about the users mailing list