[PATCH] bsp/lpc1768_mbed: Disable unsupported tests

[Joel Sherrill]

On Mon, Feb 25, 2019 at 3:31 PM Chris Johns <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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190225/9fd56125/attachment-0002.html>