BSP submitting requirements
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Jun 4 21:05:48 UTC 2014
FWIW I wrote the confdefs.h part and Marcos wrote the documentation.
He spotted a typo and missed that also.
I am ok with this patch.
On 6/4/2014 3:58 PM, Marcos Díaz wrote:
> 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
--
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
More information about the devel
mailing list