On Mon, Feb 25, 2019 at 3:31 PM Chris Johns <chr...@rtems.org> wrote:
> On 26/2/19 4:52 am, Joel Sherrill wrote: > > To follow up, I built lm4f120 with OPERATION_COUNT=10 and the failure set > > dropped to these: > > > > gmake[5]: *** [capture.exe] Error 1 > > gmake[5]: *** [loopback.exe] Error 1 > > gmake[5]: *** [block08.exe] Error 1 > > gmake[5]: *** [top.exe] Error 1 > > gmake[5]: *** [sp47.exe] Error 1 > > gmake[5]: *** [sp71.exe] Error 1 > > gmake[5]: *** [sptimecounter02.exe] Error 1 > > gmake[5]: *** [sptimecounter03.exe] Error 1 > > gmake[5]: *** [psxconfig01.exe] Error 1 > > gmake[5]: *** [tm21.exe] Error 1 > > gmake[5]: *** [tmcontext01.exe] Error 1 > > > > This looks better. What does the `OPERATION_COUNT` do to effect the link > size? > It used to do nothing to impact the link size. :) > > I am wondering how a change to a statically initialised workspace Sebastian > raised and the OPERATION_COUNT interact. > OPERATION_COUNT is usually the number of objects (e.g. tasks, semaphores, etc) created so it is the maximum object count. For example, tm03 has this: https://git.rtems.org/rtems/tree/testsuites/tmtests/tm03/system.h#n29 #define CONFIGURE_MAXIMUM_TASKS (3 + OPERATION_COUNT) So when Sebastian changed this, it went from a run-time to a link time failure. The intent of OPERATION_COUNT was to be able to scale the timing tests down to the hardware platform. Dropping OPERATION_COUNT to 10 for these BSPs will resolve almost all of the tm and psxtm linking issues from what I can tell. --joel > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
