Here is a patch in order to configure the minimum stack size for a task for a bsp. We tested it with our bsp to be submitted.
On Wed, Jun 4, 2014 at 12:50 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > The patch I sent you needs be reflected I user docs. Conf.t in doc/user. But > it is a prerequisite and independent. > > I am at an Open Group meeting and can't code much. > > On Jun 4, 2014 10:43 AM, =?ISO-8859-1?Q?Marcos_D=EDaz?= > <marcos.d...@tallertechnologies.com> wrote: > Our tests passed report was made with that configuration (1k stack > size for tasks), shall we first submit this patch and then our bsp, or > is the same. > > On Wed, Jun 4, 2014 at 12:11 PM, Marcos Díaz > <marcos.d...@tallertechnologies.com> wrote: >> Ok thanks! >> >> On Wed, Jun 4, 2014 at 11:57 AM, Joel Sherrill >> <joel.sherr...@oarcorp.com> wrote: >>> >>> On 6/4/2014 9:48 AM, Marcos Díaz wrote: >>>> Ok, but with that modification, just our bsp will be changed, my >>>> suggestion is to put a macro defined in our bsp: >>>> # ifdef ARM_LPC1768_MBED >>>> #define ARM_CPU_STACK_MINIMUM_SIZE 1024 >>>> # else >>>> #define ARM_CPU_STACK_MINIMUM_SIZE 4096 >>>> # endif >>>> >>>> And if I change it in confdefs should I put it with the same macro? >>> That is not a good way to do it. This is an uncompiled shot at it: >>> >>> $ git diff cpukit/sapi/ >>> diff --git a/cpukit/sapi/include/confdefs.h >>> b/cpukit/sapi/include/confdefs.h >>> index 9a4149e..e5037d9 100644 >>> --- a/cpukit/sapi/include/confdefs.h >>> +++ b/cpukit/sapi/include/confdefs.h >>> @@ -52,6 +52,7 @@ >>> #undef BSP_IDLE_TASK_BODY >>> #undef BSP_IDLE_TASK_STACK_SIZE >>> #undef BSP_INITIAL_EXTENSION >>> + #undef BSP_MINIMUM_TASK_STACK_SIZE >>> #undef BSP_INTERRUPT_STACK_SIZE >>> #undef BSP_MAXIMUM_DEVICES >>> #undef BSP_ZERO_WORKSPACE_AUTOMATICALLY >>> @@ -1013,7 +1014,11 @@ const rtems_libio_helper rtems_fs_init_helper = >>> * By default, use the minimum stack size requested by this port. >>> */ >>> #ifndef CONFIGURE_MINIMUM_TASK_STACK_SIZE >>> - #define CONFIGURE_MINIMUM_TASK_STACK_SIZE CPU_STACK_MINIMUM_SIZE >>> + #ifdef BSP_MINIMUM_TASK_STACK_SIZE >>> + #define CONFIGURE_MINIMUM_TASK_STACK_SIZE CPU_STACK_MINIMUM_SIZE >>> + #else >>> + #define CONFIGURE_MINIMUM_TASK_STACK_SIZE >>> BSP_MINIMUM_TASK_STACK_SIZE >>> + #endif >>> #endif >>> >>> #define CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE \ >>> >>>> I don't know what is that test configuration file, where can i learn >>>> more about it? >>>> >>> There isn't much to it except a list of tests by name that the BSP >>> cannot link >>> or has a known execution failure with that can't be fixed. Then they get >>> skipped during the build process. Look in this directory for *.tcfg >>> >>> c/src/lib/libbsp/sh/gensh1/make/custom/ >>> >>>> On Wed, Jun 4, 2014 at 11:38 AM, Joel Sherrill >>>> <joel.sherr...@oarcorp.com> wrote: >>>>> On 6/4/2014 9:22 AM, Marcos Díaz wrote: >>>>>> Thanks! >>>>>> I have another question: >>>>>> We are developing a bsp for a board with very little memory (32k) when >>>>>> we tried to run tmtest (and others) we encounter that couldnt allocate >>>>>> more RAM, and one of the things that we saw we could improve is the >>>>>> stack size passed for each task. >>>>>> For this there exists the CPU_STACK_MINIMUM_SIZE macro, but >>>>>> unfortunately it is defined to 4k for ARM, which is too much for us >>>>>> >>>>>> (http://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/rtems/score/cpu.h#n176) >>>>>> The question is: >>>>>> Can we change this macro like for the m68k boards: >>>>>> >>>>>> http://git.rtems.org/rtems/tree/cpukit/score/cpu/m68k/rtems/score/cpu.h#n384 >>>>>> and >>>>>> >>>>>> http://git.rtems.org/rtems/tree/cpukit/score/cpu/m68k/rtems/score/m68k.h#n160 >>>>>> Is this the correct way to do this? >>>>> The answer comes down to whether this multilib variant always has low >>>>> memory >>>>> or not. If some boards with this CPU core have plenty of RAM, then you >>>>> shouldn't >>>>> do it this way. >>>>> >>>>> One simple solution that comes to mind is a simple modification to >>>>> confdefs.h >>>>> (and the documentation) to allow for a BSP specific override of minimum >>>>> stack >>>>> size. We have a similar pattern in place for the idle thread body so >>>>> there is >>>>> precedence. See cpukit/sapi/include/confdefs.h. It is a large file but >>>>> largely >>>>> mechanical. This would be a very clean way to do it. >>>>> >>>>> Also you have the option of a test configuration file. Did you use >>>>> that? It >>>>> is a new thing Chris Johns and I worked through recently. >>>>>> Thanks! >>>>>> >>>>>> On Wed, Jun 4, 2014 at 11:10 AM, Joel Sherrill >>>>>> <joel.sherr...@oarcorp.com> wrote: >>>>>>> On 6/4/2014 8:52 AM, Marcos Díaz wrote: >>>>>>>> Hi, we were running the check_submission script and we were fixing >>>>>>>> some issues. but now we are having two problems: >>>>>>> The script is far from perfect and the structure of a BSP is a moving >>>>>>> target. >>>>>>>> One is that a missing file, for example bsp_interrupt_vector_enable, >>>>>>>> which is defined in the shared folder outside our bsp's folder, >>>>>>>> gives >>>>>>>> a warning (only with verbose set), but also sets faults to 1, so, we >>>>>>>> think it should be just a warning. >>>>>>> Can you provide the output and a candidate patch? >>>>>>>> Other is the missing sbrk. Thanks! >>>>>>> A BSP provides its own sbrk(). Most use the default one in >>>>>>> libbsp/shared. >>>>>>> Should just be a matter of including in in Makefile.am. >>>>>>> >>>>>>> --joel >>>>>>> >>>>>>>> On Fri, May 30, 2014 at 12:38 PM, Marcos Díaz >>>>>>>> <marcos.d...@tallertechnologies.com> wrote: >>>>>>>>> It doesn't run in any simulator.. >>>>>>>>> >>>>>>>>> I have another question: >>>>>>>>> We are developing a bsp for a board with very little memory (32k) >>>>>>>>> when >>>>>>>>> we tried to run tmtest (and others) we encounter that couldnt >>>>>>>>> allocate >>>>>>>>> more RAM, and one of the things that we saw we could improve is the >>>>>>>>> stack size passed for each task. >>>>>>>>> For this there exists the CPU_STACK_MINIMUM_SIZE macro, but >>>>>>>>> unfortunately it is defined to 4k for ARM, which is too much for us >>>>>>>>> >>>>>>>>> (http://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/rtems/score/cpu.h#n176) >>>>>>>>> The question is: >>>>>>>>> Can we change this macro like for the m68k boards: >>>>>>>>> >>>>>>>>> http://git.rtems.org/rtems/tree/cpukit/score/cpu/m68k/rtems/score/cpu.h#n384 >>>>>>>>> and >>>>>>>>> >>>>>>>>> http://git.rtems.org/rtems/tree/cpukit/score/cpu/m68k/rtems/score/m68k.h#n160 >>>>>>>>> Is this the correct way to do this? >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> On Fri, May 30, 2014 at 12:33 PM, Joel Sherrill >>>>>>>>> <joel.sherr...@oarcorp.com> wrote: >>>>>>>>>> On 5/30/2014 9:51 AM, Marcos Díaz wrote: >>>>>>>>>>> thanks to all! We will try to submit it soon! >>>>>>>>>> Does the BSP run on any simulator? If so, there are a >>>>>>>>>> couple of other things we like to have to aid automated >>>>>>>>>> testing. >>>>>>>>>> >>>>>>>>>> Also there is a new file .tcfg which can list the files >>>>>>>>>> which do not link or run with a known/expected >>>>>>>>>> failure on your BSP. See >>>>>>>>>> >>>>>>>>>> libbsp/arm/gdbarmsim/make/custom/arm1136jfs-testsuite.tcfg >>>>>>>>>> >>>>>>>>>> for an example. This is a great way to ignore tests >>>>>>>>>> which do not fit on the target. >>>>>>>>>>> On Thu, May 29, 2014 at 5:16 PM, Joel Sherrill >>>>>>>>>>> <joel.sherr...@oarcorp.com> wrote: >>>>>>>>>>>> On 5/29/2014 2:34 PM, Gedare Bloom wrote: >>>>>>>>>>>>> On Thu, May 29, 2014 at 3:02 PM, Marcos Díaz >>>>>>>>>>>>> <marcos.d...@tallertechnologies.com> wrote: >>>>>>>>>>>>>> Hi! We are about to submit a BSP but we have some doubts: >>>>>>>>>>>>>> In http://www.rtems.org/wiki/index.php/Submitting_a_BSP >>>>>>>>>>>>>> there is a point that refers to: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do all files have a CVS $Id$ in them? >>>>>>>>>>>>>> >>>>>>>>>>>>>> What does this mean? >>>>>>>>>>>>>> >>>>>>>>>>>>> That is outdated and shouldn't be there. There is a script in >>>>>>>>>>>>> the >>>>>>>>>>>>> rtems-testing.git repository located at >>>>>>>>>>>>> merge-helpers/check_submission >>>>>>>>>>>>> that may be useful to run. I don't know there is much >>>>>>>>>>>>> documentation >>>>>>>>>>>>> for it, but you just run it from your bsp directory and it does >>>>>>>>>>>>> some >>>>>>>>>>>>> checks about what is expected to exist in a bsp. >>>>>>>>>>>>> >>>>>>>>>>>>>> There is other: >>>>>>>>>>>>>> Did you provide a TIMES files with the results of the tmtests? >>>>>>>>>>>>>> is there any example of a file like this in order to see how >>>>>>>>>>>>>> it should be >>>>>>>>>>>>> I think this is old too and can be ignored for now, I only see >>>>>>>>>>>>> one >>>>>>>>>>>>> example in the tree under libbsp/m68k/uC5282/TIMES >>>>>>>>>>>> There are more times* files in the tree. >>>>>>>>>>>> >>>>>>>>>>>> These are certainly optional but give the next person a good >>>>>>>>>>>> handle on >>>>>>>>>>>> what the expected performance is. >>>>>>>>>>>>> -Gedare >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> ______________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Marcos Díaz >>>>>>>>>>>>>> >>>>>>>>>>>>>> Software Engineer >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> San Lorenzo 47, 3rd Floor, Office 5 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Córdoba, Argentina >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Skype: markdiaz22 >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> rtems-devel mailing list >>>>>>>>>>>>>> rtems-devel@rtems.org >>>>>>>>>>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> rtems-devel mailing list >>>>>>>>>>>>> rtems-devel@rtems.org >>>>>>>>>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel >>>>>>>>>>>> -- >>>>>>>>>>>> Joel Sherrill, Ph.D. Director of Research & >>>>>>>>>>>> Development >>>>>>>>>>>> joel.sherr...@oarcorp.com On-Line Applications Research >>>>>>>>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>>>>>>>>>>> Support Available (256) 722-9985 >>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Joel Sherrill, Ph.D. Director of Research & >>>>>>>>>> Development >>>>>>>>>> joel.sherr...@oarcorp.com On-Line Applications Research >>>>>>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>>>>>>>>> Support Available (256) 722-9985 >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> ______________________________ >>>>>>>>> >>>>>>>>> >>>>>>>>> Marcos Díaz >>>>>>>>> >>>>>>>>> Software Engineer >>>>>>>>> >>>>>>>>> >>>>>>>>> San Lorenzo 47, 3rd Floor, Office 5 >>>>>>>>> >>>>>>>>> Córdoba, Argentina >>>>>>>>> >>>>>>>>> >>>>>>>>> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452 >>>>>>>>> >>>>>>>>> Skype: markdiaz22 >>>>>>> -- >>>>>>> Joel Sherrill, Ph.D. Director of Research & Development >>>>>>> joel.sherr...@oarcorp.com On-Line Applications Research >>>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>>>>>> Support Available (256) 722-9985 >>>>>>> >>>>>> >>>>> -- >>>>> Joel Sherrill, Ph.D. Director of Research & Development >>>>> joel.sherr...@oarcorp.com On-Line Applications Research >>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>>>> Support Available (256) 722-9985 >>>>> >>>> >>>> >>> >>> -- >>> Joel Sherrill, Ph.D. Director of Research & Development >>> joel.sherr...@oarcorp.com On-Line Applications Research >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>> Support Available (256) 722-9985 >>> >> >> >> >> -- >> ______________________________ >> >> >> Marcos Díaz >> >> Software Engineer >> >> >> San Lorenzo 47, 3rd Floor, Office 5 >> >> Córdoba, Argentina >> >> >> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452 >> >> Skype: markdiaz22 > > > > -- > ______________________________ > > > Marcos Díaz > > Software Engineer > > > San Lorenzo 47, 3rd Floor, Office 5 > > Córdoba, Argentina > > > Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452 > > Skype: markdiaz22 -- ______________________________ Marcos Díaz Software Engineer San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452 Skype: markdiaz22
diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h index 9a4149e..24bccbf 100644 --- a/cpukit/sapi/include/confdefs.h +++ b/cpukit/sapi/include/confdefs.h @@ -50,6 +50,7 @@ #ifdef CONFIGURE_DISABLE_BSP_SETTINGS #undef BSP_DEFAULT_UNIFIED_WORK_AREAS #undef BSP_IDLE_TASK_BODY + #undef BSP_MINIMUM_TASK_STACK_SIZE #undef BSP_IDLE_TASK_STACK_SIZE #undef BSP_INITIAL_EXTENSION #undef BSP_INTERRUPT_STACK_SIZE @@ -1013,7 +1014,11 @@ const rtems_libio_helper rtems_fs_init_helper = * By default, use the minimum stack size requested by this port. */ #ifndef CONFIGURE_MINIMUM_TASK_STACK_SIZE - #define CONFIGURE_MINIMUM_TASK_STACK_SIZE CPU_STACK_MINIMUM_SIZE + #ifndef BSP_MINIMUM_TASK_STACK_SIZE + #define CONFIGURE_MINIMUM_TASK_STACK_SIZE CPU_STACK_MINIMUM_SIZE + #else + #define CONFIGURE_MINIMUM_TASK_STACK_SIZE BSP_MINIMUM_TASK_STACK_SIZE + #endif #endif #define CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE \ diff --git a/doc/user/conf.t b/doc/user/conf.t index d72ff06..c5e7681 100644 --- a/doc/user/conf.t +++ b/doc/user/conf.t @@ -3222,6 +3222,46 @@ and peripheral buses, a BSP specific IDLE task may be capable of turning components off to save power during extended periods of no task activity @c +@c === BSP_MINIMUM_TASK_STACK_SIZE === +@c +@subsection Specify BSP Suggested Value for Minimum Task Stack Size + +@findex BSP_MINIMUM_TASK_STACK_SIZE + +@table @b +@item CONSTANT: +@code{BSP_MINIMUM_TASK_STACK_SIZE} + +@item DATA TYPE: +Unsigned integer (@code{size_t}). + +@item RANGE: +Undefined or positive. + +@item DEFAULT VALUE: +This option is BSP specific. + +@end table + +@subheading DESCRIPTION: +If @code{BSP_MINIMUM_TASK_STACK_SIZE} is defined by the BSP and +@code{CONFIGURE_MINIMUM_TASK_STACK_SIZE} is not defined by the application, +then this BSP suggested minimum task stack size will be used. + + +@subheading NOTES: +The order of precedence for configuring the minimum task stack size is: + +@itemize @bullet +@item RTEMS default minimum stack size. +@item If defined, then the BSP specific @code{BSP_MINIMUM_TASK_STACK_SIZE}. +@item If defined, then the application specified +@code{CONFIGURE_MINIMUM_TASK_STACK_SIZE}. +@end itemize + +@c XXX - add cross references to other related values. + +@c @c === BSP_IDLE_TASK_STACK_SIZE === @c @subsection Specify BSP Suggested Value for IDLE Task Stack Size @@ -3255,9 +3295,9 @@ The order of precedence for configuring the IDLE task stack size is: @itemize @bullet @item RTEMS default minimum stack size. @item If defined, then @code{CONFIGURE_MINIMUM_TASK_STACK_SIZE}. -@item If defined, then the BSP specific @code{BSP_IDLE_TASK_SIZE}. +@item If defined, then the BSP specific @code{BSP_IDLE_TASK_STACK_SIZE}. @item If defined, then the application specified -@code{CONFIGURE_IDLE_TASK_SIZE}. +@code{CONFIGURE_IDLE_TASK_STACK_SIZE}. @end itemize @c XXX - add cross references to other related values.
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel