powerpc/mpc5643l_dpu: psxconfig01 too large

[Chris Johns]

On 4/3/19 5:36 pm, Sebastian Huber wrote:
> 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.

Sure and thanks.

> I added tickets for these two problems:
> 
> https://devel.rtems.org/ticket/3713
> https://devel.rtems.org/ticket/3714
>

Thanks. I will work around the problems until they can be properly fixed.

> They are not as important to fix as a broken build.

Yes I agree.

> These tests didn't work on
> the low end targets before and nobody complained about this.

I think the workspace change to expose this is really good to have.

> 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.

I understand and this make sense.

>> 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.
> 

No problem, I have this almost resolved. I will post a patch soon. I hope the
changes to the .tcfg files will help us manage these situations easier. It is
slow going because of the time it takes to build all the powerpc bsps at once.

Chris