do_zero_of_workspace

[Bill Butler]

Joel,

 

I have a small issue with Rtems Startup code that I would like to
discuss.

 

Rtems allows the programmer to determine if to 'zero out' RTEMS
workspace memory by a variable called "do_zero_of_workspace" that is
typically set in the "bspstart.c" in your bsp.

 

By modifying "Cpu_table.do_zero_of_workspace = TRUE" you can cause the
RTEMS workspace memory to be zeroed once pasted to the memory manager.
The side effect to this is it will later zero out all the remaining
memory that RTEMS passes to the Heap manager for you application. In
most cases this is a good and expected thing.

 

I have 64Meg of memory on my application and it takes around 11secs to
zero out this space and it seems that, in my case, RTEMS expects the
RTEMS workspace to be zero'ed out on startup up. I get frequent lockups
if I don't zero this space.

 

I have found that getting RTEMS to zero out the workspace, without
zeroing the 64 Meg of Ram is a bit of a trick.

 

I have patched my bsp  by declaring "bsp_pretasking_hook()" local in my
bsp directories and turning off the flag which by now is called
"_Cpu_Table.do_zero_of_workspace", but I feel that this is a bit unclear
why I am setting a variable to TRUE in one function then turning it off
later (yes I commented it heavily) :-)

 

I believe reusing "do_zero_of_workspace" to signal the zeroing of RTEMS
workspace memory and the HEAP space is unclear.  Would it be clearer for
these separate functions to check their own flag so that we might be
able to zero out RTEMS workspace but not require us to zero out the
entire memory?

 

 

Humbly your,

 

 

(ps Mark po is coming :-) )

Bill Butler

Project Lead

Sr Software Engineer

AIPCOM Inc

(972) 644-2328 (x16)

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20020712/60e3122d/attachment.html>