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