powerpc/mpc5643l_dpu: psxconfig01 too large
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_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:
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