powerpc/mpc5643l_dpu: psxconfig01 too large

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Mar 4 06:36:10 UTC 2019

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_TASKS 11
>>>      #define CONFIGURE_MAXIMUM_TIMERS 59
>>>      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
>> 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:


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.

More information about the devel mailing list