[PATCH] bsp/lpc1768_mbed: Disable unsupported tests

[Chris Johns]

On 26/2/19 9:07 am, Joel Sherrill wrote:
> On Mon, Feb 25, 2019 at 3:31 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at 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