BSP submitting requirements
Marcos Díaz
marcos.diaz at tallertechnologies.com
Wed Jun 4 20:58:07 UTC 2014
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.Sherrill at 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.diaz at 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.diaz at tallertechnologies.com> wrote:
>> Ok thanks!
>>
>> On Wed, Jun 4, 2014 at 11:57 AM, Joel Sherrill
>> <joel.sherrill at 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.sherrill at 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.sherrill at 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.diaz at 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.sherrill at 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.sherrill at 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.diaz at 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 at rtems.org
>>>>>>>>>>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> rtems-devel mailing list
>>>>>>>>>>>>> rtems-devel at rtems.org
>>>>>>>>>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>>>>>>>>>> --
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ______________________________
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.sherrill at 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.sherrill at 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.sherrill at 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
-------------- next part --------------
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
+ at c === BSP_MINIMUM_TASK_STACK_SIZE ===
+ at c
+ at subsection Specify BSP Suggested Value for Minimum Task Stack Size
+
+ at findex BSP_MINIMUM_TASK_STACK_SIZE
+
+ at table @b
+ at item CONSTANT:
+ at code{BSP_MINIMUM_TASK_STACK_SIZE}
+
+ at item DATA TYPE:
+Unsigned integer (@code{size_t}).
+
+ at item RANGE:
+Undefined or positive.
+
+ at item DEFAULT VALUE:
+This option is BSP specific.
+
+ at end table
+
+ at subheading DESCRIPTION:
+If @code{BSP_MINIMUM_TASK_STACK_SIZE} is defined by the BSP and
+ at code{CONFIGURE_MINIMUM_TASK_STACK_SIZE} is not defined by the application,
+then this BSP suggested minimum task stack size will be used.
+
+
+ at subheading NOTES:
+The order of precedence for configuring the minimum task stack size is:
+
+ at itemize @bullet
+ at item RTEMS default minimum stack size.
+ at item If defined, then the BSP specific @code{BSP_MINIMUM_TASK_STACK_SIZE}.
+ at item If defined, then the application specified
+ at code{CONFIGURE_MINIMUM_TASK_STACK_SIZE}.
+ at end itemize
+
+ at c XXX - add cross references to other related values.
+
+ at 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}.
- at item If defined, then the BSP specific @code{BSP_IDLE_TASK_SIZE}.
+ at item If defined, then the BSP specific @code{BSP_IDLE_TASK_STACK_SIZE}.
@item If defined, then the application specified
- at code{CONFIGURE_IDLE_TASK_SIZE}.
+ at code{CONFIGURE_IDLE_TASK_STACK_SIZE}.
@end itemize
@c XXX - add cross references to other related values.
More information about the devel
mailing list