Priority aggregation question

[Malte Münch]

Hello,

i am currently playing around with resource sharing protocols and have a
question regarding the priority aggregation behaviour of RTEMS. I have
to tasks both with a "base" priority of 10. I set that priority via:

rtems_task_set_scheduler(task1, sched0, 10);

Later i am raising the priority via this code (mainly copied from
_MRSP_Raise):

  ISR_lock_Context lock_context;
  Priority_Node*priority_node;
  Priority_Control new_prio;
  new_prio = 5;

  priority_node = &(fmlpl->Ceiling_priority);
  thread = _FMLPL_Get_owner(fmlpl);
  _Thread_queue_Context_clear_priority_updates( queue_context );
  _Thread_Wait_acquire_default_critical( thread, &lock_context );
  _Priority_Node_initialize(priority_node, new_prio);
  _Thread_Priority_add(thread, priority_node, queue_context);
  _Thread_Wait_release_default_critical( thread, &lock_context );


I am printing the current aggregated priority to the terminal via:

rtems_task_get_priority(id, sched, &rtp);

Before the execution of the priority raising it prints a 10 (which is
what i expected) and after the execution it prints a 2. I expected a 5
to be printed because the documentation says:

The overall priority of the aggregation is the minimum priority of the
priority nodes in the contributors tree.
(https://docs.rtems.org/doxygen/branches/master/structPriority__Aggregation.html#a98e1d7eb856737a9fafb3d0302b5db9e)

I dont know if it is important but the task that triggers the priority
raise is on a different scheduler (and cpu) than the task which gets the
updated priority.

thanks for any answer/explanation in advance.

Best regards
Malte
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[ERROR] sparc-rtems5-gcc: error: bsp_specs: No such file or directory

[Ravindra Kumar Meena]

Hi,

I was trying the following tracing example
https://docs.rtems.org/branches/master/user/tracing/examples.html

but getting an error on the second command

sparc-rtems5-gcc
-B/home/ravindra/quick-start/build/b-erc32/sparc-rtems5/erc32/lib -specs
bsp_specs -qrtems -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections
-Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=cypress -o
/home/ravindra/quick-start/build/b-erc32/sparc-rtems5/c/erc32/testsuites/samples/fileio.exe
/home/ravindra/quick-start/build/b-erc32/sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio-init.o

*Error Output:* sparc-rtems5-gcc: error: bsp_specs: No such file or
directory

Can anyone please help me resolve this issue?

Thanks

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Priority aggregation question

[Sebastian Huber]

Hello Malte,

for an example code to set the priority see 
_Scheduler_EDF_Release_job(). Please note that you have to map the 
priority values between API and internal formats, see 
SCHEDULER_PRIORITY_MAP().


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

Re: Priority aggregation question

[Malte Münch]

Thanks, that has been a helpful pointer.

Best
Malte

On 28.02.19 12:05, Sebastian Huber wrote:
> Hello Malte,
> 
> for an example code to set the priority see
> _Scheduler_EDF_Release_job(). Please note that you have to map the
> priority values between API and internal formats, see
> SCHEDULER_PRIORITY_MAP().
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Doxygen @param and [in], [out] or [in,out]?

[Sebastian Huber]

Hello,

we agreed to use @param for function parameter documentation:

https://docs.rtems.org/branches/master/eng/coding-doxygen.html#doxygen-best-practices

Do we want to use [in], [out] or [in,out] as well?

If yes, how are [in], [out] or [in,out] used exactly? For example 
consider values passed by reference. Is in


void f(int *a)
{
  if (*a == 0) {
    *a = 1;
  }
}

the parameter a an [in,out] parameter? What about

void g(int *a)
{
  *a = 1;
}

?

How can we ensure that this extra information is consistent throughout 
the documentation?


I think we should remove all the [in], [out] or [in,out] stuff. From the 
parameter type it is quite obvious how they are used, e.g. "type *param" 
vs. "const type *param". For passed by value it is clear that they are 
input parameters. Output only use is normally indicated by the function 
name, e.g. "initialize", "set", "create", etc.


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

Doxygen @return vs. @retval

[Sebastian Huber]

Hello,

we agreed to use @retval instead of @return:

https://docs.rtems.org/branches/master/eng/coding-doxygen.html#doxygen-best-practices

How should we indicate that not a particular value is returned, but 
instead an element of a set. For example:


/**
 * @brief Performs something and returns the operation status.
 *
 * @retval 0 Successful operation.
 * @retval EIO Input/output error.
 * @retval  Any other value will not be returned.
 */
int f(void);

/**
 * @brief Creates an object.
 *
 * @retval NULL Not enough resources to create an object.
 * @retval  Pointer to created object.
 */
T *create(void);

We may also use "[object]" or "{object}" or "object" or whatever.

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

Re: Doxygen @return vs. @retval

[Joel Sherrill]

On Thu, Feb 28, 2019 at 9:03 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> we agreed to use @retval instead of @return:
>
>
> https://docs.rtems.org/branches/master/eng/coding-doxygen.html#doxygen-best-practices
>
>
Is there going to be a global replacement or have they been purged?


> How should we indicate that not a particular value is returned, but
> instead an element of a set. For example:
>
> /**
>   * @brief Performs something and returns the operation status.
>   *
>   * @retval 0 Successful operation.
>   * @retval EIO Input/output error.
>   * @retval  Any other value will not be returned.
>   */
> int f(void);
>

That last @retval doesn't match what I thought your statement above
indicated.
The English on the last @retval say there are no more. Why even include
that?

If you mean other errno's may be returned, that's different.

What about the -1 and errno cases?


> /**
>   * @brief Creates an object.
>   *
>   * @retval NULL Not enough resources to create an object.
>   * @retval  Pointer to created object.
>   */
> T *create(void);
>
> We may also use "[object]" or "{object}" or "object" or whatever.
>

Can we use "instance of T"?

I assume you used object generically. Wouldn't it be the specific noun for
the created object?

>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [ERROR] sparc-rtems5-gcc: error: bsp_specs: No such file or directory

[Joel Sherrill]

On Thu, Feb 28, 2019 at 3:36 AM Ravindra Kumar Meena 
wrote:

> Hi,
>
> I was trying the following tracing example
> https://docs.rtems.org/branches/master/user/tracing/examples.html
>
> but getting an error on the second command
>
> sparc-rtems5-gcc
> -B/home/ravindra/quick-start/build/b-erc32/sparc-rtems5/erc32/lib -specs
> bsp_specs -qrtems -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections
> -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=cypress -o
> /home/ravindra/quick-start/build/b-erc32/sparc-rtems5/c/erc32/testsuites/samples/fileio.exe
> /home/ravindra/quick-start/build/b-erc32/sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio-init.o
>
> *Error Output:* sparc-rtems5-gcc: error: bsp_specs: No such file or
> directory
>
> Can anyone please help me resolve this issue?
>

Did you forget to do a "make install" on RTEMS?

>
> Thanks
>
> --
> *Ravindra Kumar Meena*,
> B. Tech. Computer Science and Engineering,
> Indian Institute of Technology (Indian School of Mines)
> , Dhanbad
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Mentors Wanted - RTEMS Accepted in Google Summer of Code 2019

[Joel Sherrill]

Hi

RTEMS was accepted as an organization into the 2019 edition of
the Google Summer of Code. It is an honor for us all to be included
each year and the project has greatly benefited.

We need as many mentors as possible for this to work. You don't have
to be a BSP and driver wizard to mentor. Last year we had two students
work on host-side utilities. If you have a pet RTEMS project you think would
make a good GSoC project, speak up.

Please email myself or Gedare (former GSoC student) if you have any
questions.

Thanks.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issue with sis and Leon3

[Jiri Gaisler]

I have found the problem, stdout is not flushed when the simulator stops
and it has been invoked by gdb. The run command uses the gdb interface
to call sis, so this is why it happens there too. I will make a new sis
patch (2.13) with some additional (speed) improvements...

Jiri.


On 2/27/19 9:34 AM, Jiri Gaisler wrote:
>
>
> On 2/26/19 11:04 PM, Joel Sherrill wrote:
>>
>>
>> On Tue, Feb 26, 2019 at 2:06 PM Jiri Gaisler > > wrote:
>>
>>
>> On 2/26/19 8:49 PM, Joel Sherrill wrote:
>>>
>>>
>>> On Tue, Feb 26, 2019 at 1:28 PM Jiri Gaisler >> > wrote:
>>>
>>>
>>> On 2/26/19 8:08 PM, Joel Sherrill wrote:
>>> > Hi
>>> >
>>> > I think something is wrong with sis on the leon3 which is
>>> impacting rtems-tester.
>>> > ticker ends like this:
>>> >
>>> > TA1  - rtems_clock_get_tod - 09:00:34   12/31/1988
>>> >
>>> > *** END OF TEST CLOCK TICK ***[joel@
>>> >
>>> > Notice that there is no carriage return at the end. Hello
>>> ends with a CR and an
>>> > blank line and it passes. Similar issue on the tests I
>>> picked which passed or failed.
>>> >
>>> > Any idea what's up? I assume something isn't quite right
>>> after all the sis work
>>> > since it is reproducible.
>>>
>>>
>>> Works OK here on Ubuntu 18.04.2 x64. Which host O/S are you on?
>>>
>>>
>>> Interesting. OS is:
>>>
>>> CentOS Linux release 7.5.1804 (Core) 
>>>
>>> Here is the output of my last run by hand with a subsequent
>>> comment. Notice that
>>>
>>> ===
>>> [joel@rtbf64c b-leon3]$ sparc-rtems5-run -a -leon3
>>> ./sparc-rtems5/c/leon3/testsuites/sptests/sp05.exe
>>
>> The run program has some issues, I think we should sis with -r
>> instead:
>>
>> $ sparc-rtems5-sis -r -leon3
>> ./sparc-rtems5/c/leon3/testsuites/sptests/sp05.exe
>>
>> .
>>
>> .
>>
>>
>> *** END OF TEST SP 5 ***
>>
>>
>> Thanks. Then do you agree that this patch is needed for rtems-tools
>> to invoke sis correctly:
>>
>> diff --git a/tester/rtems/testing/bsps/leon3-sis.ini
>> b/tester/rtems/testing/bsps
>> index 2f933a7..9e8111f 100644
>> --- a/tester/rtems/testing/bsps/leon3-sis.ini
>> +++ b/tester/rtems/testing/bsps/leon3-sis.ini
>> @@ -36,4 +36,4 @@ bsp          = leon3
>>  arch         = sparc
>>  tester       = %{_rtscripts}/run.cfg
>>  bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
>> -bsp_run_opts = -leon3 -nouartrx -r -tlim 200 s -m 4
>> +bsp_run_opts = -r -leon3 -nouartrx -r -tlim 200 s -m 4
>>
> Hmm, bsp_run_opts already has -r, I don't think you need a second copy
> ...?
>
>
>> And the cut-off output also occurs when running it from inside gdb so
>> using leon3
>> (leon3.ini) configuration with rtems-test is broken. Not sure how to
>> fix that.
>
> I will look into this.
>
> Jiri.
>
>>
>> The tests pass with leon3-sis with my above patch but fail with
>> simple leon3
>> passed to tester.
>>
>> --joel
>>
>>
>> Jiri.
>>
>>
>>
>>
>>>
>>>
>>> *** BEGIN OF TEST SP 5 ***
>>> *** TEST VERSION: 5.0.0.7abc497b6c763ccdc090014f310951b17c742ae9
>>> *** TEST STATE: EXPECTED-PASS
>>> *** TEST BUILD: RTEMS_NETWORKING
>>> *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB
>>> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
>>> TA1 - rtems_task_wake_after - sleep 5 seconds
>>> TA2 - rtems_task_suspend - suspend self
>>> TA3 - rtems_task_suspend - suspend self
>>> ..
>>> TA1 - rtems_task_resume - resume TA3
>>>
>>> *** END OF TEST [joel@rtbf64c b-leon3]$ cat /etc/redhat-release 
>>> CentOS Linux release 7.5.1804 (Core) 
>>> === 
>>>
>>> And this is the end of the erc32 output from the same test and
>>> same sis on the same computer: 
>>>
>>> ===
>>>  TA1 - rtems_task_resume - resume TA3
>>>
>>> *** END OF TEST SP 5 ***
>>>
>>>
>>> *** FATAL ***
>>> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
>>> fatal code: 0 (0x)
>>> RTEMS version: 5.0.0.7abc497b6c763ccdc090014f310951b17c742ae9
>>> RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB
>>> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
>>>
>>> === 
>>>
>>> Looks like a lot of output got chopped or not flushed or something.
>>>
>>> If the final output makes it out on your system, then rtems-test
>>> will be happy and pass them. 
>>> In my case, it ends most of the time just a little too early to
>>> make that happen.
>>>  
>>>
>>>
>>> jiri@office:~/src/rtems/sparc$ rtems-test
>>> --rtems-bsp=leon3-sis sparc-rtems5/c/leon3/testsuites/samples
>>> RTEMS Testing - Tester, 5.0.not_released
>>>  Command Line: /opt/rtems/5/bin/rtems-test
>>> --rt

Re: Conversion of BSP config files to pkg-config files

[Vijay Kumar Banerjee]

On Thu, 28 Feb 2019 at 03:37, Chris Johns  wrote:

> On 25/2/19 6:57 am, Vijay Kumar Banerjee wrote:
> > In an attempt to read all the files, I wrote a parser to try to put them
> > all in one place.
>
> Great.
>
> > I'm attaching the parser, the generated data and the list of files that
> > could not be parsed because they use `defines`.
>
> Yes this is where things get difficult.
>
> > Is this data any helpful?
>
> It is interesting. If a complete set can be captured we can move all the
> common
> options into a single place.
>
> > Is this the right way forward?
>
> I suspect it is or we run the risk of not seeing something if this is done
> by
> manually.
>
> On the issue of the defines:
>
> 1. Are the defines needed or could be these changed into something else and
> removed? I think this requires inspecting each one and deciding.
>
> it's defining bsp-post-link something like this ...

define bsp-post-link
$(default-bsp-post-link)
$(OBJCOPY) -O binary $@ $(basename $@)$(DOWNEXT)
endef

can this be moved to some common cfg file somehow?

I have observed that the arm bsps are using .inc files and importing them
from the .cfg files.  Is there any reason that they're organized like that,
instead
of directly writing it in the .cfg files ?

2 Does running `gmake -p` after a successful build of the BSP provide you
> with
> the missing details?
>
> Chris
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Interest/Intent to port OpenSSH?

[Gedare Bloom]

Hello all,

Does anyone plan/want to use OpenSSH with RTEMS? Would there be interest or
already an intent to port it?

I suspect it would not be so hard to add it with libbsd, but I'm not that
experienced to be certain. Would it make for a good potential GSoC Project?

Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Interest/Intent to port OpenSSH?

[Victor Kukshiev]

hello, Gedare!
I interested to particiate.

чт, 28 февр. 2019 г. в 23:44, Gedare Bloom :

> Hello all,
>
> Does anyone plan/want to use OpenSSH with RTEMS? Would there be interest
> or already an intent to port it?
>
> I suspect it would not be so hard to add it with libbsd, but I'm not that
> experienced to be certain. Would it make for a good potential GSoC Project?
>
> Gedare
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

powerpc/mpc5643l_dpu: psxconfig01 too large

[Chris Johns]

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.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: powerpc/mpc5643l_dpu: psxconfig01 too large

[Joel Sherrill]

On Thu, Feb 28, 2019, 4:50 PM Chris Johns  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.

>
> Thanks
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: powerpc/mpc5643l_dpu: psxconfig01 too large

[Chris Johns]

On 1/3/19 10:00 am, Joel Sherrill wrote:
> On Thu, Feb 28, 2019, 4:50 PM Chris Johns  > 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 ...

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

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: powerpc/mpc5643l_dpu: psxconfig01 too large

[Joel Sherrill]

On Thu, Feb 28, 2019, 5:03 PM Chris Johns  wrote:

> On 1/3/19 10:00 am, Joel Sherrill wrote:
> > On Thu, Feb 28, 2019, 4:50 PM Chris Johns  > > 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.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel