powerpc/mpc5643l_dpu: psxconfig01 too large

[Sebastian Huber]

On 02/03/2019 02:07, Chris Johns wrote:
>
> On 1/3/19 7:34 pm, Sebastian Huber wrote:
>> On 01/03/2019 00:10, Joel Sherrill wrote:
>>>
>>> On Thu, Feb 28, 2019, 5:03 PM Chris Johns <chrisj at rtems.org
>>> <mailto:chrisj at rtems.org>> wrote:
>>>
>>>      On 1/3/19 10:00 am, Joel Sherrill wrote:
>>>      > On Thu, Feb 28, 2019, 4:50 PM Chris Johns <chrisj at rtems.org
>>>      <mailto:chrisj at rtems.org>
>>>      > <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>> wrote:
>>>      >
>>>      >     Hi,
>>>      >
>>>      >     This test has a number of config values that overflow the
>>>      memory on the
>>>      >     powerpc/mpc5643l_dpu BSP. Can these value be reduced so they
>>>      can fit?
>>>      >
>>>      >     I can provide support in .tcfg files now to provide specific
>>>      per BSP settings
>>>      >     but I am not sure what the values should be for this BSP?
>>>      Some guidance is most
>>>      >     welcome.
>>>      > Unfortunately I think this is a test like the old sp09 which
>>>      crammed too much
>>>      > into one executable. I think it needs to be split into multiple
>>>      tests. Ideally
>>>      > one per object class.
>>>
>>>      That would work. I am wondering about values like 37, 41, 43, etc ...
>>>
>>>
>>>  From my reading of the test 3 would be effective.
>>>
>>>
>>>      #define CONFIGURE_MAXIMUM_BARRIERS 2
>>>      #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 7
>>>      #define CONFIGURE_MAXIMUM_PARTITIONS 37
>>>      #define CONFIGURE_MAXIMUM_PERIODS 41
>>>      #define CONFIGURE_MAXIMUM_REGIONS 43
>>>      #define CONFIGURE_MAXIMUM_SEMAPHORES 47
>>>      #define CONFIGURE_MAXIMUM_TASKS 11
>>>      #define CONFIGURE_MAXIMUM_TIMERS 59
>>>      #define CONFIGURE_MAXIMUM_USER_EXTENSIONS 17
>>>
>>>      They look unusual enough to mean something or they are random, I
>>>      cannot tell.
>>>
>> The numbers in the test are all unique. If you use the same values
>>
>> #define CONFIGURE_MAXIMUM_PERIODS 3
>> #define CONFIGURE_MAXIMUM_REGIONS 3
>>
>> how can to ensure that for example the configurations for periods and regions
>> are not switched?
> Can the values be smaller? Do they need to be so large?
>
>> If you don't want to use unique numbers, then the test should be split up to
>> test each configuration option individually. Who has time to do this just to
>> enable this test on a very low end BSP?
> Hmmm. I have been attempting to test some changes for the PowerPC to work around
> the mess of linker command files in the PowerPC arch. The diversion created by
> the workspace static patch is costing me time so it costs someone at some point
> in time. I support the static workspace patch and appreciate these things can
> break things without knowing but I hope these breakages are not known about and
> are being left.

I worked immediately on a patch to fix the build issues and set a patch 
last Monday. It was not my idea to extend this to a general discussion 
of the OPERATION_COUNT in the timing tests and an improvements in 
specific tests like psxconfig01. I added tickets for these two problems:

https://devel.rtems.org/ticket/3713
https://devel.rtems.org/ticket/3714

They are not as important to fix as a broken build. These tests didn't 
work on the low end targets before and nobody complained about this. In 
particular, I would not run the full test suite on the MPC5643L chips. 
These are automotive chips with an on-chip flash which could wear down 
if you burn several hundred tests into it.

> If you think the BSP is of no value please say so and it can be
> flagged to be removed.

This BSP is fine, the chips have a long delivery guarantee.

> I hope when we find these things we all work to get them
> fixed. The project cannot afford to leave these corners.

Yes, sorry I was a bit distracted after the patch feedback.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.