On 26/2/19 9:07 am, Joel Sherrill wrote: > On Mon, Feb 25, 2019 at 3:31 PM Chris Johns <chr...@rtems.org > <mailto: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. >
Ah ok, it is nice to see the error on these targets at link time. > 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. What about a way to set this value in the `.tcfg` files and then provide it on the command line as a compile option? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
