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.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 -- 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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
