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 <chr...@rtems.org
<mailto:chr...@rtems.org>> wrote:
On 1/3/19 10:00 am, Joel Sherrill wrote:
> On Thu, Feb 28, 2019, 4:50 PM Chris Johns <chr...@rtems.org
<mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
