RTEMS Software Coding Standard

[Manuel Coutinho]

Hello all,

It has been some time since my last email. Hope you are doing well!

Some of you already know that Edisoft together with Embedded Brains (and some 
other institutions) are in a joint project to pre-qualify RTEMS according to 
the ESA (ECSS) standards.

One of the items required is the Software Coding Standard and one of the goals 
of the project is to minimize (hopefully eliminate) any deviation from a 
pre-qualified version of RTEMS and the community RTEMS.

To that end, we ask your ideas of how the RTEMS software coding standard should 
look like. We have looked at your current coding standard 
(https://docs.rtems.org/branches/master/eng/coding.html) and made a preliminary 
analysis to it (see table in attach). For an open-source project, these rules 
are very good. Unfortunately, from a pre-qualification point of view, there are 
not so many rules that are verifiable and even fewer that are automatically 
verifiable by a tool that we can use in the project.

We have some preferences:
 - have only automatically verified tools (to reduce the amount of manual 
verifications to a minimum)
 - use preferentially open-source tools
 - use at most 2 tools
 - the tool(s) should have a "well-defined" rule set and output (e.g. XML, 
YAML, whatever) so that the qualification toolchain (another tool that we are 
developing) can interpret the output and re-format the output to sphinx.

As a side note (please lets not focus on this now), after selecting the rules 
there could be some violations to the rule and still the pre-qualification be 
successful. For that, we just need to justify why the violation occurred (was 
not corrected) and why the code is correct.

We believe a good starting point would be the MISRA rules since they are well 
defined, lots of tools use them, they can eliminate a lot of errors. But we 
welcome any other suggestion. 
Please keep in mind that some tools, while they are good to use, don't give a 
well-defined ruleset. 
We have looked at cppcheck for some time and only now we found that there is a 
ruleset. You can get it by running "cppcheck --errorlist".

After we define this rule set, we suggest that the current standard (in 
https://docs.rtems.org/branches/master/eng/coding.html) be more or less renamed 
to a "Coding guidelines" instead of "Rules" because some of them are not 
verifiable and we believe the community should keep on following them. And 
create a new coding standard with the rules that are selected.

Kind regards,
Manuel Coutinho
Technical Manager
Aeronautics & Space Systems manuel.couti...@edisoft.pt 
Tel: +351 212 945 906
Fax: +351 212 945 999
Rua Calvet Magalhães, 245
2770-153 Paço de Arcos · Portugal
www.edisoft.pt


RTEMS community SCS.ods
Description: RTEMS community SCS.ods
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> This approach makes no sense to me.
>
> Per CPU you receive three record events in succession:
>
> [19:32:26.679099590] (+0.46608) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_OUT" : container =
> 216 ), data = 167837707 }
> [19:32:26.679099590] (+0.0) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_STACK_CURRENT" :
> container = 209 ), data = 32320 }
> [19:32:26.679099590] (+0.0) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_IN" : container =
> 215 ), data = 151060501 }
>
> They have all the same timestamp.
>
> When you receive an RTEMS_RECORD_THREAD_SWITCH_OUT event, you store the
> timestamp (per CPU) and the data (per-CPU, this is the thread ID).
>
> When you receive an RTEMS_RECORD_THREAD_SWITCH_IN event and the
> timestamp matches, you use the values of the current event and the
> values stored before to output an LTTNG sched_switch event.
>

I am trying this approach but I think there is one problem with it. When
RTEMS_RECORD_THREAD_SWITCH_IN event is received then there is no way to
receive it's next_* values.

e.g.

ab //RTEMS_RECORD_THREAD_SWITCH_OUT
bc //RTEMS_RECORD_THREAD_STACK_CURRENT
cd //RTEMS_RECORD_THREAD_SWITCH_IN

Think this example as output in babeltrace where first character is of
prev_comm value and second character is of next_comm value. Since we will
be writing just after receiving c(third row) we can't get d values.

For this, we should have d value so that we can write it in
RTEMS_RECORD_THREAD_SWITCH_IN event with next_comm value.




-- 
*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: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 24/07/2019 11:04, Ravindra Kumar Meena wrote:

This approach makes no sense to me.

Per CPU you receive three record events in succession:

[19:32:26.679099590] (+0.46608) Record_Item
RTEMS_RECORDING_EVENT: {
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_OUT" :
container =
216 ), data = 167837707 }
[19:32:26.679099590] (+0.0) Record_Item
RTEMS_RECORDING_EVENT: {
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_STACK_CURRENT" :
container = 209 ), data = 32320 }
[19:32:26.679099590] (+0.0) Record_Item
RTEMS_RECORDING_EVENT: {
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_IN" : container =
215 ), data = 151060501 }

They have all the same timestamp.

When you receive an RTEMS_RECORD_THREAD_SWITCH_OUT event, you store the
timestamp (per CPU) and the data (per-CPU, this is the thread ID).

When you receive an RTEMS_RECORD_THREAD_SWITCH_IN event and the
timestamp matches, you use the values of the current event and the
values stored before to output an LTTNG sched_switch event.

I am trying this approach but I think there is one problem with it. When 
RTEMS_RECORD_THREAD_SWITCH_IN event is received then there is no way to 
receive it's next_* values.


You received RTEMS_RECORD_THREAD_SWITCH_OUT two record events before the 
 RTEMS_RECORD_THREAD_SWITCH_IN with the same timestamp. See my comment 
above. In these two record events all you need for the sched_switch 
event is contained.


--
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: RTEMS Software Coding Standard

[Joel Sherrill]

On Wed, Jul 24, 2019, 3:59 AM Manuel Coutinho 
wrote:

> Hello all,
>
> It has been some time since my last email. Hope you are doing well!
>
> Some of you already know that Edisoft together with Embedded Brains (and
> some other institutions) are in a joint project to pre-qualify RTEMS
> according to the ESA (ECSS) standards.
>
> One of the items required is the Software Coding Standard and one of the
> goals of the project is to minimize (hopefully eliminate) any deviation
> from a pre-qualified version of RTEMS and the community RTEMS.
>
> To that end, we ask your ideas of how the RTEMS software coding standard
> should look like. We have looked at your current coding standard (
> https://docs.rtems.org/branches/master/eng/coding.html) and made a
> preliminary analysis to it (see table in attach). For an open-source
> project, these rules are very good. Unfortunately, from a pre-qualification
> point of view, there are not so many rules that are verifiable and even
> fewer that are automatically verifiable by a tool that we can use in the
> project.
>
> We have some preferences:
>  - have only automatically verified tools (to reduce the amount of manual
> verifications to a minimum)
>  - use preferentially open-source tools
>  - use at most 2 tools
>  - the tool(s) should have a "well-defined" rule set and output (e.g. XML,
> YAML, whatever) so that the qualification toolchain (another tool that we
> are developing) can interpret the output and re-format the output to sphinx.
>
> As a side note (please lets not focus on this now), after selecting the
> rules there could be some violations to the rule and still the
> pre-qualification be successful. For that, we just need to justify why the
> violation occurred (was not corrected) and why the code is correct.
>
> We believe a good starting point would be the MISRA rules since they are
> well defined, lots of tools use them, they can eliminate a lot of errors.
> But we welcome any other suggestion.
> Please keep in mind that some tools, while they are good to use, don't
> give a well-defined ruleset.
>

The MISRA C coding guide is not freely available. This is a barrier to open
discussion about the merit to adopting the rules.

I personally have not seen the entire rule set in a long time since I don't
own a copy. My recollection is that I am against some of the rules. For
example, I vaguely recall a rule about 32 character global symbol names and
I am strongly opposed to that rule. It reflects limits in long unused
object formats. And that's just one I remember as being odd.

Each rule or handful will have to be proposed for evaluation independent of
having a copy of MISRA. The way it is checked by a FLOSS tool and its value
will have to be established.

The use of any rules which are adopted will have to be restricted to
certain directories. We can't change the style or format of third party
code.

It is likely close to time to discuss if we will use an annotation like
spdx to denote files which have artifacts.


We have looked at cppcheck for some time and only now we found that there
> is a ruleset. You can get it by running "cppcheck --errorlist".
>

What's the other tool?

>
> After we define this rule set, we suggest that the current standard (in
> https://docs.rtems.org/branches/master/eng/coding.html) be more or less
> renamed to a "Coding guidelines" instead of "Rules" because some of them
> are not verifiable and we believe the community should keep on following
> them. And create a new coding standard with the rules that are selected.
>

And some of those are verifiable. Let's start with those

>
> Kind regards,
> Manuel Coutinho
> Technical Manager
> Aeronautics & Space Systems manuel.couti...@edisoft.pt
> Tel: +351 212 945 906
> Fax: +351 212 945 999
> Rua Calvet Magalhães, 245
> 2770-153 Paço de Arcos · Portugal
> www.edisoft.pt
> ___
> 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: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> You received RTEMS_RECORD_THREAD_SWITCH_OUT two record events before the
>   RTEMS_RECORD_THREAD_SWITCH_IN with the same timestamp. See my comment
> above. In these two record events all you need for the sched_switch
> event is contained.
>

Have made changes:

https://github.com/rmeena840/rtems-tools/commit/880eb38c41f66e5ca08429f9ed52a209feed123e

Have a look.

Babeltrace output:

babeltrace . | head

[19:16:31.180116542] (+?.?) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "16e0", next_tid = 5856, next_prio = 0 }
[19:16:31.180116542] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "16e0", prev_tid = 5856, prev_prio = 0, prev_state =
0, next_comm = "09010014", next_tid = 151060500, next_prio = 0 }
[19:16:31.180116542] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180154588] (+0.38046) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "1ce0", next_tid = 7392, next_prio = 0 }
[19:16:31.180154588] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "1ce0", prev_tid = 7392, prev_prio = 0, prev_state =
0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0 }
[19:16:31.180154588] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010014", next_tid = 151060500, next_prio = 0
}
[19:16:31.180174232] (+0.19644) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "16e0", next_tid = 5856, next_prio = 0 }
[19:16:31.180174232] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "16e0", prev_tid = 5856, prev_prio = 0, prev_state =
0, next_comm = "09010014", next_tid = 151060500, next_prio = 0 }
[19:16:31.180174232] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180223920] (+0.49688) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0,
prev_state = 0, next_comm = "1ce0", next_tid = 7392, next_prio = 0 }

Now the prev_* and next_* values are not equal.


-- 
*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: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 24/07/2019 14:07, Ravindra Kumar Meena wrote:

You received RTEMS_RECORD_THREAD_SWITCH_OUT two record events before
the
   RTEMS_RECORD_THREAD_SWITCH_IN with the same timestamp. See my
comment
above. In these two record events all you need for the sched_switch
event is contained.


Have made changes:

https://github.com/rmeena840/rtems-tools/commit/880eb38c41f66e5ca08429f9ed52a209feed123e

Have a look.

Babeltrace output:

babeltrace . | head


[...]
[19:16:31.180223920] (+0.49688) Record_Item sched_switch: { cpu_id = 
5 }, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0, 
prev_state = 0, next_comm = "1ce0", next_tid = 7392, next_prio = 0 }


Now the prev_* and next_* values are not equal.


Being not equal is necessary but not sufficient.

Your code is too complicated.  Please try to simplify it.  Avoid the 
magic numbers and use the enumerator constants instead.


Why do you use values from RTEMS_RECORD_THREAD_STACK_CURRENT for the 
sched_switch? Do you know what a software thread is?


You only need RTEMS_RECORD_THREAD_SWITCH_IN and 
RTEMS_RECORD_THREAD_SWITCH_OUT.


--
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: GSoC PRU: AM35xx Clock driver

[Nils Hölscher]

Hi,

I just found out that the prcm driver fails to probe on the simplebus and
therefore cannot apply itself.
Seems like I am back to checking dtb.

Best,
Nils

On Tue, 23 Jul 2019 at 14:26, Nils Hölscher  wrote:

> Hi,
>
> After debugging with printk, didn't get the module loading working as
> suggested by Sebastian.
> I just found out that my PRU driver can't be attached, cause the AM35xx
> clock driver isn't loaded.
> The driver can be found her:
>
> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c
>
> Can anyone tell me how to load this driver and obisouly before I
> initialize my BSD modules?
>
> FYI: The code line that fails is this one, cause the driver hasn't been
> initialized.
>
> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c#L854
>
> Thanks,
> Nils
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC PRU: AM35xx Clock driver

[Nils Hölscher]

Hi again,

I just decompiled my device tree and checked.
The probe code of the prcm driver is as follows:
"
static int
am335x_prcm_probe(device_t dev)
{
printk("am335x_prcm_probe\n");

if (!ofw_bus_status_okay(dev)){
printk("ofw_bus_status_not_okay\n");
return (ENXIO);
}

if (ofw_bus_is_compatible(dev, "ti,am3-prcm")) {
device_set_desc(dev, "AM335x Power and Clock Management");
printk("PROBE SUCESSFULL\n");
return(BUS_PROBE_DEFAULT);
}
printk("ofw_bus incompatible\n");
return (ENXIO);
}
"
So it seems the prcm part in the device tree has to be compatible to
"ti,am3-prcm".
The thing is the decompiled device tree states just that:
"
prcm@0 {
compatible = "ti,am3-prcm\0simple-bus";
reg = <0x00 0x2000>;
#address-cells = <0x01>;
#size-cells = <0x01>;
ranges = <0x00 0x00 0x2000>;
phandle = <0x5a>;
[...]
"
Any ideas would help, cause I am currently not able to understand this
behaviour.
Also without this driver even the dev_usb_bbb driver shouldn't work.
However it attaches because it doesn't check for the clocks error code.

Best,
Nils



On Wed, 24 Jul 2019 at 14:43, Nils Hölscher  wrote:

> Hi,
>
> I just found out that the prcm driver fails to probe on the simplebus and
> therefore cannot apply itself.
> Seems like I am back to checking dtb.
>
> Best,
> Nils
>
> On Tue, 23 Jul 2019 at 14:26, Nils Hölscher  wrote:
>
>> Hi,
>>
>> After debugging with printk, didn't get the module loading working as
>> suggested by Sebastian.
>> I just found out that my PRU driver can't be attached, cause the AM35xx
>> clock driver isn't loaded.
>> The driver can be found her:
>>
>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c
>>
>> Can anyone tell me how to load this driver and obisouly before I
>> initialize my BSD modules?
>>
>> FYI: The code line that fails is this one, cause the driver hasn't been
>> initialized.
>>
>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c#L854
>>
>> Thanks,
>> Nils
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC PRU: AM35xx Clock driver

[Vijay Kumar Banerjee]

On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher  wrote:

> Hi again,
>
> Hi Nils

> I just decompiled my device tree and checked.
> The probe code of the prcm driver is as follows:
> "
> static int
> am335x_prcm_probe(device_t dev)
> {
> printk("am335x_prcm_probe\n");
>
> if (!ofw_bus_status_okay(dev)){
> printk("ofw_bus_status_not_okay\n");
> return (ENXIO);
> }
>
> Do you get the "ofw_bus_status_not_okay" print ?

> if (ofw_bus_is_compatible(dev, "ti,am3-prcm")) {
> device_set_desc(dev, "AM335x Power and Clock Management");
> printk("PROBE SUCESSFULL\n");
> return(BUS_PROBE_DEFAULT);
> }
> printk("ofw_bus incompatible\n");
> return (ENXIO);
> }
> "
> So it seems the prcm part in the device tree has to be compatible to
> "ti,am3-prcm".
> The thing is the decompiled device tree states just that:
> "
> prcm@0 {
> compatible = "ti,am3-prcm\0simple-bus";
>
In my device tree, it runs successfully and the decompiled compatible looks
like  :
```
prcm@20 {
compatible = "ti,am3-prcm";
reg = < 0x20 0x4000 >;
linux,phandle = < 0x4a >;
phandle = < 0x4a >;
```

> reg = <0x00 0x2000>;
> #address-cells = <0x01>;
> #size-cells = <0x01>;
> ranges = <0x00 0x00 0x2000>;
> phandle = <0x5a>;
> [...]
> "
> Any ideas would help, cause I am currently not able to understand this
> behaviour.
> Also without this driver even the dev_usb_bbb driver shouldn't work.
> However it attaches because it doesn't check for the clocks error code.
>
I remember testing this a few days ago for my fb drivers and it was
attaching alright,
if I remember correctly. If changing the dtb doesn't work for you, I won't
mind checking
again, this will give me a hint for the display issue as well.

>
>
Best,
> Nils
>
>
>
> On Wed, 24 Jul 2019 at 14:43, Nils Hölscher  wrote:
>
>> Hi,
>>
>> I just found out that the prcm driver fails to probe on the simplebus and
>> therefore cannot apply itself.
>> Seems like I am back to checking dtb.
>>
>> Best,
>> Nils
>>
>> On Tue, 23 Jul 2019 at 14:26, Nils Hölscher  wrote:
>>
>>> Hi,
>>>
>>> After debugging with printk, didn't get the module loading working as
>>> suggested by Sebastian.
>>> I just found out that my PRU driver can't be attached, cause the AM35xx
>>> clock driver isn't loaded.
>>> The driver can be found her:
>>>
>>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c
>>>
>>> Can anyone tell me how to load this driver and obisouly before I
>>> initialize my BSD modules?
>>>
>>> FYI: The code line that fails is this one, cause the driver hasn't been
>>> initialized.
>>>
>>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c#L854
>>>
>>> Thanks,
>>> Nils
>>>
>> ___
> 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

Addition of Rule Checkers

[Joel Sherrill]

Hi

I just wanted to make sure we followed proper procedures and policies when
considering rule checkers.

1. The license must appropriate.

2. There should be some basic requirements that the tool is expected to
meet to be fit for purpose

3. The tool must support the range of development hosts used in the
Community.

As a detail, once selected the tool needs to have an RSB recipe.

For style checkers, I am concerned that they are not integrated into the
normal development and build process. There is already enough "garbage
collection" to do and making a special pass. If that's the case, it will
just be a burden.

Just some thoughts. I'm not opposed to this, I just don't want something
like Coverity where it is only run periodically and only a few people even
look at it much less fix problems.

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

Re: GSoC PRU: AM35xx Clock driver

[Nils Hölscher]

On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee 
wrote:

>
>
>
> On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher  wrote:
>
>> Hi again,
>>
>> Hi Nils
>
>> I just decompiled my device tree and checked.
>> The probe code of the prcm driver is as follows:
>> "
>> static int
>> am335x_prcm_probe(device_t dev)
>> {
>> printk("am335x_prcm_probe\n");
>>
>> if (!ofw_bus_status_okay(dev)){
>> printk("ofw_bus_status_not_okay\n");
>> return (ENXIO);
>> }
>>
>> Do you get the "ofw_bus_status_not_okay" print ?
>
Yes. But I also see the other print. except the success one.

> if (ofw_bus_is_compatible(dev, "ti,am3-prcm")) {
>> device_set_desc(dev, "AM335x Power and Clock Management");
>> printk("PROBE SUCESSFULL\n");
>> return(BUS_PROBE_DEFAULT);
>> }
>> printk("ofw_bus incompatible\n");
>> return (ENXIO);
>> }
>> "
>> So it seems the prcm part in the device tree has to be compatible to
>> "ti,am3-prcm".
>> The thing is the decompiled device tree states just that:
>> "
>> prcm@0 {
>> compatible = "ti,am3-prcm\0simple-bus";
>>
> In my device tree, it runs successfully and the decompiled compatible
> looks like  :
> ```
> prcm@20 {
> compatible = "ti,am3-prcm";
> reg = < 0x20 0x4000 >;
> linux,phandle = < 0x4a >;
> phandle = < 0x4a >;
> ```
>
OK, this is awkward, cause we both should have used the same sources.

> reg = <0x00 0x2000>;
>> #address-cells = <0x01>;
>> #size-cells = <0x01>;
>> ranges = <0x00 0x00 0x2000>;
>> phandle = <0x5a>;
>> [...]
>> "
>> Any ideas would help, cause I am currently not able to understand this
>> behaviour.
>> Also without this driver even the dev_usb_bbb driver shouldn't work.
>> However it attaches because it doesn't check for the clocks error code.
>>
> I remember testing this a few days ago for my fb drivers and it was
> attaching alright,
> if I remember correctly. If changing the dtb doesn't work for you, I won't
> mind checking
> again, this will give me a hint for the display issue as well.
>
I will keep you updated on this.
Would you be so kind and send me your compiled device tree?
>
>
>>
> Best,
>> Nils
>>
>>
>>
>> On Wed, 24 Jul 2019 at 14:43, Nils Hölscher  wrote:
>>
>>> Hi,
>>>
>>> I just found out that the prcm driver fails to probe on the simplebus
>>> and therefore cannot apply itself.
>>> Seems like I am back to checking dtb.
>>>
>>> Best,
>>> Nils
>>>
>>> On Tue, 23 Jul 2019 at 14:26, Nils Hölscher  wrote:
>>>
 Hi,

 After debugging with printk, didn't get the module loading working as
 suggested by Sebastian.
 I just found out that my PRU driver can't be attached, cause the AM35xx
 clock driver isn't loaded.
 The driver can be found her:

 https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c

 Can anyone tell me how to load this driver and obisouly before I
 initialize my BSD modules?

 FYI: The code line that fails is this one, cause the driver hasn't been
 initialized.

 https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c#L854

 Thanks,
 Nils

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

[PATCH] eng: Add Software Requirements Engineering chapter

[Sebastian Huber]

---
 eng/index.rst |   1 +
 eng/req-eng.rst   | 813 ++
 images/eng/req-add.pdf| Bin 0 -> 81320 bytes
 images/eng/req-add.png| Bin 0 -> 50516 bytes
 images/eng/req-add.uml|  40 +++
 images/eng/req-modify.pdf | Bin 0 -> 68500 bytes
 images/eng/req-modify.png | Bin 0 -> 37776 bytes
 images/eng/req-modify.uml |  34 ++
 8 files changed, 888 insertions(+)
 create mode 100644 eng/req-eng.rst
 create mode 100644 images/eng/req-add.pdf
 create mode 100644 images/eng/req-add.png
 create mode 100644 images/eng/req-add.uml
 create mode 100644 images/eng/req-modify.pdf
 create mode 100644 images/eng/req-modify.png
 create mode 100644 images/eng/req-modify.uml

diff --git a/eng/index.rst b/eng/index.rst
index cfc831b..802eec9 100644
--- a/eng/index.rst
+++ b/eng/index.rst
@@ -26,6 +26,7 @@ RTEMS Software Engineering (|version|)
 preface
 prequalification
 stakeholders
+req-eng
 management
 test-plan
 test-framework
diff --git a/eng/req-eng.rst b/eng/req-eng.rst
new file mode 100644
index 000..6b63c7b
--- /dev/null
+++ b/eng/req-eng.rst
@@ -0,0 +1,813 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 embedded brains GmbH
+
+.. |E40| replace:: ECSS-E-ST-40C
+
+.. |E10-06| replace:: ECSS-E-ST-10-06C
+
+Software Requirements Engineering
+*
+
+Software engineering standards for critical software such as |E40| demand that
+software requirements for a software product are collected in a software
+requirements specification (technical specification in |E40| terms).  They are
+usually derived from system requirements (requirements baseline in |E40|
+terms).  RTEMS is designed as a reusable software product which can be utilized
+by application designers to ease the development of their applications.  The
+requirements of the end system (system requirements) using RTEMS are only known
+to the application designer.  RTEMS itself is developed by the RTEMS
+maintainers and they do not know the requirements of a particular end system in
+general.  RTEMS is designed as a real-time operating system to meet typical
+system requirements for a wide range of applications.  Its suitability for a
+particular application must be determined by the application designer based on
+the technical specification provided by RTEMS accompanied with performance data
+for a particular target platform.
+
+Currently, no technical specification of RTEMS exists in the form of a
+dedicated document.  Since the beginning of the RTEMS evolution in the late
+1980s it was developed iteratively.  It was never developed in a waterfall
+model.  During initial development the RTEID :cite:`Motorola:1988:RTEID` and
+later the ORKID :cite:`VITA:1990:ORKID` draft specifications were used as
+requirements.  These were evolving during the development and an iterative
+approach was followed often using simple algorithms and coming back to
+optimise.  In 1993 and 1994 a subset of pthreads sufficient to support
+:term:`GNAT` was added as requirements.  At this time the Ada tasking was
+defined, however, not implemented in GNAT, so this involved guessing during the
+development. Later some adjustments were made when Ada tasking was actually
+implemented.  So, it was consciously iterative with the specifications evolving
+and feedback from performance analysis.  Benchmarks published from other real
+time operating systems were used for comparison.  Optimizations were carried
+out until the results were comparable.  Development was done with distinct
+contractual phases and tasks for development, optimization, and the addition of
+priority inheritance and rate monotonic scheduling.  The pthreads requirement
+has grown to be as much POSIX as possible.  Portability to FreeBSD to use the
+network stack, USB stack, SD/MMC card stack and device drivers resulted in
+another set of requirements.  The support for symmetric multiprocessing (SMP)
+was a huge driver for change.  It was developed step by step and sponsored by
+several independent users with completely different applications and target
+platforms in mind.  The high performance OpenMP support introduced the Futex as
+a new synchronization primitive.  A key success element of RTEMS is the ability
+to accept changes driven by user needs and still keep the operating system
+stable enough for production systems.  Procedures that place a high burden on
+changes are doomed to be discarded by the RTEMS project.  We have to keep this
+in mind when we introduce a requirements management work flow which should be
+followed by RTEMS community members and new contributors.
+
+We have to put in some effort first into the reconstruction of software
+requirements through reverse engineering using the RTEMS documentation, test
+cases, sources, standard references, mailing list archives, etc. as input.
+Writing a technical specification for the complete RTEMS code base is probably
+a j

Re: [PATCH] eng: Add Software Requirements Engineering chapter

[Sebastian Huber]

Hello,

this is my first attempt to add a "Software Requirements Engineering" 
chapter to the RTEMS Software Engineering manual.  You can find a PDF 
with this patch here:


https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf

I removed the binary files from the patch.

--
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: GSoC PRU: AM35xx Clock driver

[Nils Hölscher]

Hi,

@Vijay Kumar Banerjee   thanks for the dtb file.
I build my file from FreeBSD master.

Prcm attaches now but still after the pruss driver...:
"
nexus0: 
ofwbus0:  on nexus0
simplebus0:  on ofwbus0


*ti_pruss0:  mem
0x4a30-0x4a37 irq 20,21,22,23,24,25,26,27 on simplebus0ti_pruss0:
could not enable PRUSS clockdevice_attach: ti_pruss0 attach returned 6*
simplebus1:  on simplebus0
*am335x_prcm0:  mem 0x20-0x203fff on
simplebus1*
*am335x_prcm_attach*
"

Is there anything else I can do besides using MODULE_DEPENDENCY, which I
already use.
The prcm module is also a EARLY_DRIVER_MODULE.

Best,
Nils

On Wed, 24 Jul 2019 at 16:04, Vijay Kumar Banerjee 
wrote:

>
>
> On Wed, Jul 24, 2019 at 7:03 PM Nils Hölscher  wrote:
>
>>
>>
>> On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher 
>>> wrote:
>>>
 Hi again,

 Hi Nils
>>>
 I just decompiled my device tree and checked.
 The probe code of the prcm driver is as follows:
 "
 static int
 am335x_prcm_probe(device_t dev)
 {
 printk("am335x_prcm_probe\n");

 if (!ofw_bus_status_okay(dev)){
 printk("ofw_bus_status_not_okay\n");
 return (ENXIO);
 }

 Do you get the "ofw_bus_status_not_okay" print ?
>>>
>> Yes. But I also see the other print. except the success one.
>>
>>> if (ofw_bus_is_compatible(dev, "ti,am3-prcm")) {
 device_set_desc(dev, "AM335x Power and Clock Management");
 printk("PROBE SUCESSFULL\n");
 return(BUS_PROBE_DEFAULT);
 }
 printk("ofw_bus incompatible\n");
 return (ENXIO);
 }
 "
 So it seems the prcm part in the device tree has to be compatible to
 "ti,am3-prcm".
 The thing is the decompiled device tree states just that:
 "
 prcm@0 {
 compatible = "ti,am3-prcm\0simple-bus";

>>> In my device tree, it runs successfully and the decompiled compatible
>>> looks like  :
>>> ```
>>> prcm@20 {
>>> compatible = "ti,am3-prcm";
>>> reg = < 0x20 0x4000 >;
>>> linux,phandle = < 0x4a >;
>>> phandle = < 0x4a >;
>>> ```
>>>
>> OK, this is awkward, cause we both should have used the same sources.
>>
> Have you checked that your source is from the tree matching the libBSD HEAD
> commit?
>
>> reg = <0x00 0x2000>;
 #address-cells = <0x01>;
 #size-cells = <0x01>;
 ranges = <0x00 0x00 0x2000>;
 phandle = <0x5a>;
 [...]
 "
 Any ideas would help, cause I am currently not able to understand this
 behaviour.
 Also without this driver even the dev_usb_bbb driver shouldn't work.
 However it attaches because it doesn't check for the clocks error code.

>>> I remember testing this a few days ago for my fb drivers and it was
>>> attaching alright,
>>> if I remember correctly. If changing the dtb doesn't work for you, I
>>> won't mind checking
>>> again, this will give me a hint for the display issue as well.
>>>
>> I will keep you updated on this.
>> Would you be so kind and send me your compiled device tree?
>>
> Please find it attached in this mail.
>
> Note: I have removed the devel from the cc because the attachment might be
> big for the list. Please continue the discussion in the mailing list and
> maybe note
> it somewhere that you already received the dtb from me in private mail.
>
> Regards,
> Vijay
>
>>

>>> Best,
 Nils



 On Wed, 24 Jul 2019 at 14:43, Nils Hölscher  wrote:

> Hi,
>
> I just found out that the prcm driver fails to probe on the simplebus
> and therefore cannot apply itself.
> Seems like I am back to checking dtb.
>
> Best,
> Nils
>
> On Tue, 23 Jul 2019 at 14:26, Nils Hölscher 
> wrote:
>
>> Hi,
>>
>> After debugging with printk, didn't get the module loading working as
>> suggested by Sebastian.
>> I just found out that my PRU driver can't be attached, cause the
>> AM35xx clock driver isn't loaded.
>> The driver can be found her:
>>
>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c
>>
>> Can anyone tell me how to load this driver and obisouly before I
>> initialize my BSD modules?
>>
>> FYI: The code line that fails is this one, cause the driver hasn't
>> been initialized.
>>
>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c#L854
>>
>> Thanks,
>> Nils
>>
> ___
 devel mailing list
 devel@rtems.org
 http://lists

Re: [rtems-docs commit] eng: Add bibliography

[Joel Sherrill]

Hi

Where possible, can we mirror the references to the ftp site?

--joel

On Wed, Jul 24, 2019 at 8:42 AM Sebastian Huber  wrote:

> Module:rtems-docs
> Branch:master
> Commit:735bcd765ab64aefa0fc9012d2143490fe090c8a
> Changeset:
> http://git.rtems.org/rtems-docs/commit/?id=735bcd765ab64aefa0fc9012d2143490fe090c8a
>
> Author:Sebastian Huber 
> Date:  Wed Jul 24 15:42:08 2019 +0200
>
> eng: Add bibliography
>
> ---
>
>  eng/index.rst   | 1 +
>  eng/zreferences.rst | 6 ++
>  2 files changed, 7 insertions(+)
>
> diff --git a/eng/index.rst b/eng/index.rst
> index f29d0f3..cfc831b 100644
> --- a/eng/index.rst
> +++ b/eng/index.rst
> @@ -35,3 +35,4 @@ RTEMS Software Engineering (|version|)
>  appendix-a
>  function_and_variable
>  concept
> +zreferences
> diff --git a/eng/zreferences.rst b/eng/zreferences.rst
> new file mode 100644
> index 000..26b0ed2
> --- /dev/null
> +++ b/eng/zreferences.rst
> @@ -0,0 +1,6 @@
> +.. only:: html
> +
> +References
> +**
> +
> +.. bibliography:: ../common/refs.bib
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC Weekly IRC Meeting PRU

[Nils Hölscher]

Hi,

Since this weeks IRC meeting has been canceled, we were asked to post on
devel.

*What I did this week:*
- I Ported the BSD pruss driver over to rtems-libbsd.
- Moved the driver from my application to the rtems-libbsd repository, it
makes more sense to develop it there I think.
https://github.com/nilhoel1/rtems-libbsd/tree/ti_pruss
The last commit is the whole driver stack.
I still need to figure out which files to alter so that ./waf install
copies the ti_pruss.c/h files to BSP.
-I have got the solution to the clock driver module not loading just today,
device tree again...
However prcm still loads after the ti_pruss module.

*Major Blocker:*
My main blocker is the prcm clock driver loading after the pruss driver,
rendering the pruss driver unattachable.
I posted about this on devel, the mail isn't in the Archive yet.
The title was "GSoC PRU: AM35xx Clock driver" <- Help wanted and needed!

Also resolving this Blocker is my work for *next week*, if everything runs
fine I will test the driver and start porting the shell commands to access
PRU.

Thanks for reading,
Nils
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2019 : POSIX Compliance- Low pace in last week

[Vaibhav Gupta]

Hello,
I want to apologise that I couldn't inform earlier, actually my time table
got hectic.
My college started last week and their initial time table is not much
useful in terms of productivity. Hence my pace got slow last week.

I am back on track and continuing with my fenv task.

Thank you
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019 : POSIX Compliance- Low pace in last week

[Joel Sherrill]

Hi

I have some progress to report on this. The ndbm patch is in newlib git now
but
the corresponding files were not regenerated. Once Corinna pushes those, I
will
test and bump the newlib version in the tools.

I see you have a test posted and once I have tools, I will be able to
review that
properly.

How is the fenv test going? And what's the list of targets missing fenv
support
in newlib that you have found code for?

--joel

On Wed, Jul 24, 2019 at 10:56 AM Vaibhav Gupta 
wrote:

> Hello,
> I want to apologise that I couldn't inform earlier, actually my time table
> got hectic.
> My college started last week and their initial time table is not much
> useful in terms of productivity. Hence my pace got slow last week.
>
> I am back on track and continuing with my fenv task.
>
> Thank you
> Vaibhav Gupta
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC Status update : BBB Framebuffer Project

[Vijay Kumar Banerjee]

Hello all,

This is a mail to update my weekly status since the meeting got
canceled this week.

Progress:
* Completed mmap patch :
https://lists.rtems.org/pipermail/devel/2019-July/026680.html
This patch is pending approval. I'm not sure if it was supposed
to be merged or will it be merged after some test runs in fb or
PRU?
* Added documentation for Beagle BSP
* Sent Patch for documenting Device Tree:
https://lists.rtems.org/pipermail/devel/2019-July/026775.html

Blocker:
The Initialization is still not fixed. Christian ordered a display cape
and will test without HDMI.

Next:
I'm a bit short of ideas and waiting for feedback from Christian about
the test using cape. Meanwhile, I'm trying to write a few docs. Also
wrote blog on how to write an application in libbsd for the wider audience.

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

Re: GSoC 2019 : POSIX Compliance- Low pace in last week

[Vaibhav Gupta]

On Wed, Jul 24, 2019 at 9:44 PM Joel Sherrill  wrote:

> Hi
>
> I have some progress to report on this. The ndbm patch is in newlib git
> now but
> the corresponding files were not regenerated. Once Corinna pushes those, I
> will
> test and bump the newlib version in the tools.
>
Thanks, Yah I saw the mail today. The path is pushed, I am also waiting for
regenerated file, Or else will have pull the current update and regenerae
the files using 'autoreconf -fvi'.

>
> I see you have a test posted and once I have tools, I will be able to
> review that
> properly.
>
Yes, and Gedare has verified the code for now, but its execution needs to be
verified once newlib has the update.

>
> How is the fenv test going? And what's the list of targets missing fenv
> support
> in newlib that you have found code for?
>
There are two approach I found:

   1. I saw in NetBSD, they have one general 'fenv.h' which is present in
   their include directory (This contains function prototypes). And one
   'fenv.h' is present in evry architecture specific folders(They contain
   architecture specific macros). We can implement it in similar way. When
   they are compiled, the 'include/fenv.h' and '/fenv.h' gets
   combined i guess.
   2. Or we can have only architecture specific headers which contain
   function prototypes and macros in one single file for every architecture.


> --joel
>
> On Wed, Jul 24, 2019 at 10:56 AM Vaibhav Gupta 
> wrote:
>
>> Hello,
>> I want to apologise that I couldn't inform earlier, actually my time
>> table got hectic.
>> My college started last week and their initial time table is not much
>> useful in terms of productivity. Hence my pace got slow last week.
>>
>> I am back on track and continuing with my fenv task.
>>
>> Thank you
>> Vaibhav Gupta
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: RTEMS Software Coding Standard

[Manuel Coutinho]

Regarding MISRA, we are not suggesting to have all the rules. Only the ones 
that are automatically verified by a tool that we can use and only those that 
make sense for the community.
MISRA is not open, that is understood. But there are some sources 
(https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/coverity-misra-standards-ds-ul.pdf)
 that give a good insight about the rules. I would say that for the rules that 
are doubtful of their meaning, just leave them out.
Anyway, I suggest to look at cppcheck rules. I send below. They are not exactly 
written with a "proper rule phrasing" but we can more or less understand their 
meaning.

The code standard should be applicable, at least in the context of the 
pre-qualification project, to a subset of the RTEMS which we called "space 
profile" (we don't have the effort to pre-qualify all the RTEMS code). I don't 
think third party code is inside the space profile.

We are thinking about Coverity or Coverity Scan. Coverity Scan, as I was told, 
is not a great tool because we don't know which are the rules that are covered 
and there are no guarantees that one month from now they will remain the same. 
Coverity might be an issue (or not).

We could start with the current RTEMS verifiable rules, but if you look at the 
excel file, most of the rules that can be automatically verified... I don't 
know of a tool that verifies them. There are 6 rules that I know that Coverity 
can check (since they are equivalent to MISRA rules, like the use of /* and */ 
for comments). I think it would be a very big effort to look at all the rules 
and cross-check with the tools to find if any tool can verify them. Normally we 
do the other way around (that is, first we select the tool(s) and derive the 
rules from it).

Anyway, we welcome suggestions or corrections.

Thanks,
Manuel
































































































































































































































































From: Joel Sherrill [mailto:j...@rtems.org]
Sent: quarta-feira, 24 de julho de 2019 12:10
To: Manuel Coutinho
Cc: rtems-de...@rtems.org
Subject: Re: RTEMS Software Coding Standard


On Wed, Jul 24, 2019, 3:59 AM Manuel Coutinho  
wrote:
Hello all,

It has been some time since my last email. Hope you are doing well!

Some of you already know that Edisoft together with Embedded Brains (and some 
other institutions) are in a joint project to pre-qualify RTEMS according to 
the ESA (ECSS) standards.

One of the items required is the Software Coding Standard and one of the goals 
of the project is to minimize (hopefully eliminate) any deviation from a 
pre-qualified version of RTEMS and the community RTEMS.

To that end, we ask your ideas of how the RTEMS software coding standard should 
look like. We have looked at your current coding standard 
(https://docs.rtems.org/branches/master/eng/coding.html) and made a preliminary 
analysis to it (see table in attach). For an open-source project, these rules 
are very good. Unfortunately, from a pre-qualification point of view, there are 
not so many rules that are verifiable and even fewer that are automatically 
verifiable by a tool that we can use in the project.

We have some preferences:
 - have only automatically verified tools (to reduce the amount of manual 
verifications to a minimum)
 - use preferentially open-source tools
 - use at most 2 tools
 - the tool(s) should have a "well-defined" rule set and output (e.g. XML, 
YAML, whatever) so that the qualification toolchain (another tool that we are 
developing) can interpret the output and re-format the output to sphinx.

As a side note (please lets not focus on this now), after selecting the rules 
there could be some violations to the rule and still the pre-qualification be 
successful. For that, we just need to justify why the violation occurred (was 
not corrected) and why the code is correct.

We believe a good starting point

GSoC 2019 : POSIX Compliance - Weekly Report

[Vaibhav Gupta]

Hello,
Progress so far:
- NDBM patch is pushed by newlib.
- NDBM Testsuite is sent to devel ([PATCH V6] ndbm test suite), its
execution will be verified once newlib has required files. Although I have
tested it by manually generating required file using 'autoreconf -fvi' on
my local system.

Blocker:
- My pace got slow last week as my college started, I informed about it on
devel.

Next:
- Implement fenv for SPARC first, then move on to ARM, PPC and others.


Thank You
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019 : POSIX Compliance- Low pace in last week

[Vaibhav Gupta]

On Wed, Jul 24, 2019, 9:44 PM Joel Sherrill  wrote:

> Hi
>
> I have some progress to report on this. The ndbm patch is in newlib git
> now but
> the corresponding files were not regenerated. Once Corinna pushes those, I
> will
> test and bump the newlib version in the tools.
>
Corinna just did it. :), Thanks for mentioning this thing on that thread.

>
> I see you have a test posted and once I have tools, I will be able to
> review that
> properly.
>
> How is the fenv test going? And what's the list of targets missing fenv
> support
> in newlib that you have found code for?
>
> --joel
>
> On Wed, Jul 24, 2019 at 10:56 AM Vaibhav Gupta 
> wrote:
>
>> Hello,
>> I want to apologise that I couldn't inform earlier, actually my time
>> table got hectic.
>> My college started last week and their initial time table is not much
>> useful in terms of productivity. Hence my pace got slow last week.
>>
>> I am back on track and continuing with my fenv task.
>>
>> Thank you
>> Vaibhav Gupta
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Software Coding Standard

[Joel Sherrill]

On Wed, Jul 24, 2019 at 11:39 AM Manuel Coutinho 
wrote:

> Regarding MISRA, we are not suggesting to have all the rules. Only the
> ones that are automatically verified by a tool that we can use and only
> those that make sense for the community.
> MISRA is not open, that is understood. But there are some sources (
> https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/coverity-misra-standards-ds-ul.pdf)
> that give a good insight about the rules. I would say that for the rules
> that are doubtful of their meaning, just leave them out.
> Anyway, I suggest to look at cppcheck rules. I send below. They are not
> exactly written with a "proper rule phrasing" but we can more or less
> understand their meaning.
>
>
The Excel file (proprietary file warning) was inlined and not attached. But
which MISRA rules do those correspond to?

Looking through what I can see of the inlined XML, some/many of these are
checked by GCC. Why isn't GCC the first order tool? We have been fairly
aggressive in enabling warnings and if gcc is already checking for
something, that should be the first order tool. If there is value in
enabling another warning, that's OK.

What about clang/llvm? Has Gaisler upstreamed their SPARC work? They are
usually considered to have good static checking. See
http://clang-analyzer.llvm.org/


The code standard should be applicable, at least in the context of the
> pre-qualification project, to a subset of the RTEMS which we called "space
> profile" (we don't have the effort to pre-qualify all the RTEMS code). I
> don't think third party code is inside the space profile.
>

But any checks need to be consistently integrated into the build mechanics.
Perhaps code error checks can be separately defined from more style
oriented things that we don't want to apply everywhere.


>
> We are thinking about Coverity or Coverity Scan. Coverity Scan, as I was
> told, is not a great tool because we don't know which are the rules that
> are covered and there are no guarantees that one month from now they will
> remain the same. Coverity might be an issue (or not).
>

If you have a Coverity license, they may answer questions about what Scan
does in comparison.

But ultimately, it is a proprietary tool and even Scan's reports are a pain
from an open project perspective.They really can't be depended on for a
random submitter to use or even look at. They can only be a back up -- not
the primary enforcer of any rule.


> We could start with the current RTEMS verifiable rules, but if you look at
> the excel file, most of the rules that can be automatically verified... I
> don't know of a tool that verifies them. There are 6 rules that I know that
> Coverity can check (since they are equivalent to MISRA rules, like the use
> of /* and */ for comments).


Then we need a table that says we have a rule and no way to automatically
verify it so is checked by hand. Or we can verify it with X.

Just checking whatever rules a random tool can check seems like box
checking for a contract. Lets try to do the right thing. Just because a
rule is checked by hand, doesn't mean the rule doesn't have value and
doesn't mean that the rule will never be automatically checked.


> I think it would be a very big effort to look at all the rules and
> cross-check with the tools to find if any tool can verify them. Normally we
> do the other way around (that is, first we select the tool(s) and derive
> the rules from it).
>

Doing this to an open source code base in an open way is not the usual way
either. This is new territory.

I think picking a tool and just using a subset of the rules it implements
is really backwards. You should know the rules you want to enforce and look
for a tool (or tool combination) that covers those rules. Why wouldn't we
want an objective set of rules we want to follow?


Random question: Does Frama-C offer anything here?


> Anyway, we welcome suggestions or corrections.
>

I'm not trying to be argumentative. We have rules just not all are enforced
by tools. Let's try to change that where possible and if we add rules, try
to ensure they are enforced by FLOSS tools.


>
> Thanks,
> Manuel
>
>
> 
> 
> 
> 
>  msg="Returning an integer in a function with pointer return type is not
> portable."/>
>  msg="Returning an address value in a function with integer return type is
> not portable."/>
> 
> 
> 
> 
> 
> 
> 
>  msg="Deallocation of an auto-variable results in undefined behaviour."/>
>  msg="Address of function parameter 'parameter' returned."/>
> 
> 
> 
> 
>  msg="Comparison of a function returning boolean value using relational
> (<, >, <= or >=) operator."/>
>  msg="Comparison of two functions returning boolean value using relational
> (<, >, <= or >=) operator."/>
>  msg="Comparison of a variable having boolean value using relational (<,
> >, <= or >=) operator."/>
> 
>
>  msg="Comparison of a boolean expressio

Re: GSoC Status update : BBB Framebuffer Project

[Christian Mauderer]

Hello Vijay,

On 24/07/2019 18:14, Vijay Kumar Banerjee wrote:
> Hello all,
> 
> This is a mail to update my weekly status since the meeting got
> canceled this week.

Sorry for that.

> 
> Progress:
> * Completed mmap patch
> : https://lists.rtems.org/pipermail/devel/2019-July/026680.html
> This patch is pending approval. I'm not sure if it was supposed 
> to be merged or will it be merged after some test runs in fb or 
> PRU?

I haven't tested the patch yet. I'll try to do that in the next few
days. Sebastian reviewed it quite well so I think as soon as I've seen
the test run on one or two platforms I can merge it. Same is true for
your documentation patch that fixes the typos.

> * Added documentation for Beagle BSP
> * Sent Patch for documenting Device
> Tree: https://lists.rtems.org/pipermail/devel/2019-July/026775.html
> 
> Blocker:
> The Initialization is still not fixed. Christian ordered a display cape
> and will test without HDMI.

The display arrived today. Although still a bit distorted, I get at
least an output on FreeBSD with an adapted device tree. Bad news is: No
output with your fb-sample. The backlight didn't light up (which is
expected) and I don't get any output if I search with a flashlight. I'll
try to hack in a backlight soon but normally if there is something on
the screen it should be at least slightly visible with enough light.

> 
> Next: 
> I'm a bit short of ideas and waiting for feedback from Christian about
> the test using cape. Meanwhile, I'm trying to write a few docs. Also
> wrote blog on how to write an application in libbsd for the wider audience.

That's a good gap filler and it's great and useful if you contribute to
the documentation. But at least the first tests with the display didn't
give much results. So most likely you should try some other methods of
analysis. I think you had thought about debugging the FreeBSD kernel to
find out the differences?

Best regards

Christian

> 
> Thanks,
> Vijay

PS: Sorry for sending it twice to all directly addressed. I used the
wrong "from" address the first time so it didn't reach the list.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Status update : BBB Framebuffer Project

[Vijay Kumar Banerjee]

On Thu, Jul 25, 2019 at 1:09 AM Christian Mauderer 
wrote:

> Hello Vijay,
>
> On 24/07/2019 18:14, Vijay Kumar Banerjee wrote:
> > Hello all,
> >
> > This is a mail to update my weekly status since the meeting got
> > canceled this week.
>
> Sorry for that.
>
> >
> > Progress:
> > * Completed mmap patch
> > : https://lists.rtems.org/pipermail/devel/2019-July/026680.html
> > This patch is pending approval. I'm not sure if it was supposed
> > to be merged or will it be merged after some test runs in fb or
> > PRU?
>
> I haven't tested the patch yet. I'll try to do that in the next few
> days. Sebastian reviewed it quite well so I think as soon as I've seen
> the test run on one or two platforms I can merge it. Same is true for
> your documentation patch that fixes the typos.
>
> > * Added documentation for Beagle BSP
> > * Sent Patch for documenting Device
> > Tree: https://lists.rtems.org/pipermail/devel/2019-July/026775.html
> >
> > Blocker:
> > The Initialization is still not fixed. Christian ordered a display cape
> > and will test without HDMI.
>
> The display arrived today. Although still a bit distorted, I get at
> least an output on FreeBSD with an adapted device tree. Bad news is: No
> output with your fb-sample. The backlight didn't light up (which is
> expected) and I don't get any output if I search with a flashlight. I'll
> try to hack in a backlight soon but normally if there is something on
> the screen it should be at least slightly visible with enough light.
>
> >
> > Next:
> > I'm a bit short of ideas and waiting for feedback from Christian about
> > the test using cape. Meanwhile, I'm trying to write a few docs. Also
> > wrote blog on how to write an application in libbsd for the wider
> audience.
>
> That's a good gap filler and it's great and useful if you contribute to
> the documentation. But at least the first tests with the display didn't
> give much results. So most likely you should try some other methods of
> analysis. I think you had thought about debugging the FreeBSD kernel to
> find out the differences?
>
> Best regards
>
> Christian
>
> >
> > Thanks,
> > Vijay
>
> PS: Sorry for sending it twice to all directly addressed. I used the
> wrong "from" address the first time so it didn't reach the list.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Status update : BBB Framebuffer Project

[Vijay Kumar Banerjee]

On Thu, Jul 25, 2019 at 1:17 AM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

>
>
>
>
> On Thu, Jul 25, 2019 at 1:09 AM Christian Mauderer 
> wrote:
>
>> Hello Vijay,
>>
>> On 24/07/2019 18:14, Vijay Kumar Banerjee wrote:
>> > Hello all,
>> >
>> > This is a mail to update my weekly status since the meeting got
>> > canceled this week.
>>
>> Sorry for that.
>>
>> >
>> > Progress:
>> > * Completed mmap patch
>> > : https://lists.rtems.org/pipermail/devel/2019-July/026680.html
>> > This patch is pending approval. I'm not sure if it was supposed
>> > to be merged or will it be merged after some test runs in fb or
>> > PRU?
>>
>> I haven't tested the patch yet. I'll try to do that in the next few
>> days. Sebastian reviewed it quite well so I think as soon as I've seen
>> the test run on one or two platforms I can merge it. Same is true for
>> your documentation patch that fixes the typos.
>>
>> > * Added documentation for Beagle BSP
>> > * Sent Patch for documenting Device
>> > Tree: https://lists.rtems.org/pipermail/devel/2019-July/026775.html
>> >
>> > Blocker:
>> > The Initialization is still not fixed. Christian ordered a display cape
>> > and will test without HDMI.
>>
>> The display arrived today. Although still a bit distorted, I get at
>> least an output on FreeBSD with an adapted device tree. Bad news is: No
>> output with your fb-sample. The backlight didn't light up (which is
>> expected) and I don't get any output if I search with a flashlight. I'll
>> try to hack in a backlight soon but normally if there is something on
>> the screen it should be at least slightly visible with enough light.
>>
>> >
>> > Next:
>> > I'm a bit short of ideas and waiting for feedback from Christian about
>> > the test using cape. Meanwhile, I'm trying to write a few docs. Also
>> > wrote blog on how to write an application in libbsd for the wider
>> audience.
>>
>> That's a good gap filler and it's great and useful if you contribute to
>> the documentation. But at least the first tests with the display didn't
>> give much results. So most likely you should try some other methods of
>> analysis. I think you had thought about debugging the FreeBSD kernel to
>> find out the differences?
>>
>> Thanks for the note. I will get started with the FreeBSD kernel tomorrow
and compile
it and run it through the debugger to see what it does.

Thanks

> Best regards
>>
>> Christian
>>
>> >
>> > Thanks,
>> > Vijay
>>
>> PS: Sorry for sending it twice to all directly addressed. I used the
>> wrong "from" address the first time so it didn't reach the list.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

assistance needed in bumping newlib version

[Joel Sherrill]

Hi

I got this error from github. I was bumping the newlib hash to get ndbm.

download: (full)
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8
-> sources/newlib-6b843b8.tar.gz
download:
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8
-> sources/newlib-6b843b8.tar.gz
download: no ssl context
download:
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8:
error: HTTP Error 404: Not Found

Even by hand in a browser, codeland is gone.

Any suggestions or advice?

Thanks.

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

Re: GSoC Status update : BBB Framebuffer Project

[Christian Mauderer]

Am Mittwoch, 24. Juli 2019 schrieb Vijay Kumar Banerjee:
> 
> 
> 
> 
> On Thu, Jul 25, 2019 at 1:17 AM Vijay Kumar Banerjee 
>  wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Jul 25, 2019 at 1:09 AM Christian Mauderer  wrote:
> 
> Hello Vijay,
> 
> On 24/07/2019 18:14, Vijay Kumar Banerjee wrote:
> > Hello all,
> > 
> > This is a mail to update my weekly status since the meeting got
> > canceled this week.
> 
> Sorry for that.
> 
> > 
> > Progress:
> > * Completed mmap patch
> > : https://lists.rtems.org/pipermail/devel/2019-July/026680.html
> > This patch is pending approval. I'm not sure if it was supposed 
> > to be merged or will it be merged after some test runs in fb or 
> > PRU?
> 
> I haven't tested the patch yet. I'll try to do that in the next few
> days. Sebastian reviewed it quite well so I think as soon as I've seen
> the test run on one or two platforms I can merge it. Same is true for
> your documentation patch that fixes the typos.
> 
> > * Added documentation for Beagle BSP
> > * Sent Patch for documenting Device
> > Tree: https://lists.rtems.org/pipermail/devel/2019-July/026775.html
> > 
> > Blocker:
> > The Initialization is still not fixed. Christian ordered a display cape
> > and will test without HDMI.
> 
> The display arrived today. Although still a bit distorted, I get at
> least an output on FreeBSD with an adapted device tree. Bad news is: No
> output with your fb-sample. The backlight didn't light up (which is
> expected) and I don't get any output if I search with a flashlight. I'll
> try to hack in a backlight soon but normally if there is something on
> the screen it should be at least slightly visible with enough light.
> 
> > 
> > Next: 
> > I'm a bit short of ideas and waiting for feedback from Christian about
> > the test using cape. Meanwhile, I'm trying to write a few docs. Also
> > wrote blog on how to write an application in libbsd for the wider audience.
> 
> That's a good gap filler and it's great and useful if you contribute to
> the documentation. But at least the first tests with the display didn't
> give much results. So most likely you should try some other methods of
> analysis. I think you had thought about debugging the FreeBSD kernel to
> find out the differences?
> 
> 
> Thanks for the note. I will get started with the FreeBSD kernel tomorrow and 
> compile
> it and run it through the debugger to see what it does.

It might could be possible to debug modules via some kind of kernel debugger 
instead of the whole kernel via a hardware debugger. I never tried that with 
FreeBSD but maybe it's worth to have a look at that first.
 
> 
> 
> Thanks
> Best regards
> 
> Christian
> 
> > 
> > Thanks,
> > Vijay
> 
> PS: Sorry for sending it twice to all directly addressed. I used the
> wrong "from" address the first time so it didn't reach the list.
>

-- 
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: assistance needed in bumping newlib version

[Chris Johns]

On 25/7/19 6:11 am, Joel Sherrill wrote:
> Hi
> 
> I got this error from github. I was bumping the newlib hash to get ndbm.
> 
> download: (full)
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8
> -> sources/newlib-6b843b8.tar.gz
> download:
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8
> -> sources/newlib-6b843b8.tar.gz
> download: no ssl context
> download:
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8:
>  error:
> HTTP Error 404: Not Found
> 
> Even by hand in a browser, codeland is gone.
> 
> Any suggestions or advice?
> 

Has the repo been updated with the upstream? It might be a manual operation. I
am not sure if there are any instructions available on doing this. I am also not
aware of any jobs on our servers to handle this.

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

Re: assistance needed in bumping newlib version

[Chris Johns]

On 25/7/19 8:23 am, Chris Johns wrote:
> Has the repo been updated with the upstream? It might be a manual operation. I
> am not sure if there are any instructions available on doing this. I am also 
> not
> aware of any jobs on our servers to handle this.

The repo looks updated.

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

Re: Change Control Board (CCB) proposal for requirements (v2)

[Joel Sherrill]

On Wed, Jul 24, 2019 at 1:39 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I work currently on a requirements engineering section for RTEMS in the
> RTEMS Software Engineering manual:
>
> https://docs.rtems.org/branches/master/eng/index.html
>
> One topic is the Change Control Board (CCB). The Doorstop maintainer was
> not so fond of my idea to add support for digital signatures:
>
> https://github.com/jacebrowning/doorstop/issues/375
>
> So, here is a new proposal without signatures. I think this makes the
> process a bit easier.
>
> Change Control Board
> 
>
> Working with requirements usually involves a Change Control Board
> (:term:`CCB`).  The CCB of the RTEMS project is the
> `RTEMS developer mailing list
> `_.
>
> There are the following actors involved:
>
> * *RTEMS users*: Everyone using the RTEMS real-time operating system to
> design,
>develop and build an application on top of it.
>
> * *RTEMS developers*: The persons developing and maintaining RTEMS.
> They write
>patches to add or modify code, requirements, tests and documentation.
>
> * *RTEMS maintainers*: They are listed in the
>`MAINTAINERS `_ file
> and have
>write access to the project repositories.
>
> .. TODO: Make a reference to the "normal patch review process".
>
> Adding and changing requirements follows the normal patch review process.
>

The normal process should be defined and referenced.


> Reviews and comments may be submitted by anyone, but a maintainer review is
> required to approve *significant* changes.  In addition for significant
> changes, there should be at least one reviewer with a sufficient
> independence
> from the author which proposes a new requirement or a change of an existing
> requirement.  Working in another company on different projects is
> sufficiently
> independent.


Different companies and same funding source isn't independent.


> RTEMS maintainers do not know all the details, so they
> trust in
> general people with experience on a certain platform.  Sometimes no review
> comments may appear in a reasonable time frame, then an implicit
> agreement to
> the proposed changes is assumed.  Patches can be sent at anytime, so
> controlling changes in RTEMS requires a permanent involvement on the RTEMS
> developer mailing list.
>

There is a problem with independence and reasonable time frame. You are
relying on volunteers to review requirements (or anything else) and at
their time
availability mercy. I don't know how you ensure you have proper second
reviewers
from the volunteer community in a reasonable time frame. Lack of commentary
could just mean personal issues or travel. For example, I spent 3 weeks of
June
traveling and/or teaching and was sick enough for two rounds of
antibiotics. I
care about reviewing but I didn't review much last month. And even when I do
review, there is a practical limit.

Some of this going to have to be spoon fed to the community to have a chance
to get it reviewed by volunteer. Better would be paid time from alternative
core
developers to speed this up.But ultimately some core reviewers will be
volunteer
and slow.

A normal timeout isn't appropriate for requirements. They really deserve
positive
acknowledge. A true CCB waits for a majority from a quorum.

A technical part of the solution is be something like Phabricator which
tracks
getting multiple approvals and lets you do online reviews. A tool like this
also
helps with the records for code reviews and approval beyond the final git
log.


>
> For a qualification of RTEMS according to certain standards, the
> requirements
> may be approved by an RTEMS user.


I think you mean tailoring the requirements and code.


> The approval by RTEMS users is not the
> concern of the RTEMS project, however, the RTEMS project should enable
> RTEMS
> users to manage the approval of requirements easily.  This information
> may be
> also used by a independent authority which comes into play with an
> Independent
> Software Verification and Validation (:term:`ISVV`).  It could be used to
> select a subset of requirements, e.g. look only at the ones approved by a
> certain user.


Careful with approved. Do you mean tailoring again?


> RTEMS users should be able to reference the determinative
> content of requirements, test procedures, test cases and justification
> reports
> in their own documentation.  Changes in the determinative content should
> invalidate all references to previous versions.
>

Determinative doesn't appear to be a word.

>
> .. topic:: Doorstop
>
>  In Doorstop some values of an item (generalization of a requirement)
>  contribute to a
>  `fingerprint of the item
> <
> https://github.com/jacebrowning/doorstop/blob/develop/docs/reference/items.md#reviewed
> >`_.
>  Changing a value, e.g. the text of a requirement, changes the
> fingerprint.
>

GSoC 2019 : Basic support for Trace Compass

[Ravindra Kumar Meena]

Hello all,

This is a mail to update my weekly status since the meeting got
canceled this week.

Progress so far:
* Added compact header in both client-side and metadata.
* Imported trace in Trace Compass with the updated event.header in the
metadata. Trace Compass can still read the values.
* Added sched_switch in the metadata.

Next:
* Currently working on adding sched_switch in client-side.

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: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> Being not equal is necessary but not sufficient.
>
> Your code is too complicated.  Please try to simplify it.  Avoid the
> magic numbers and use the enumerator constants instead.
>
Okay

>
> Why do you use values from RTEMS_RECORD_THREAD_STACK_CURRENT for the
> sched_switch? Do you know what a software thread is?
>
I learned software thread in Java. I tried to implement thread in C. We
need '-lpthread' flag in gcc compiler to use the thread in C. Does this
flag needed to be included in wscript?



-- 
*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: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 25/07/2019 06:34, Ravindra Kumar Meena wrote:

Being not equal is necessary but not sufficient.

Your code is too complicated.  Please try to simplify it.  Avoid the
magic numbers and use the enumerator constants instead.

Okay


Why do you use values from RTEMS_RECORD_THREAD_STACK_CURRENT for the
sched_switch? Do you know what a software thread is?

I learned software thread in Java. I tried to implement thread in C. We 
need '-lpthread' flag in gcc compiler to use the thread in C. Does this 
flag needed to be included in wscript?


We don't need threads for this program. I meant if you know the concept 
of software threads in general and what a stack is.


--
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: assistance needed in bumping newlib version

[Sebastian Huber]

On 24/07/2019 22:11, Joel Sherrill wrote:

I got this error from github. I was bumping the newlib hash to get ndbm.

download: (full) 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8 
-> sources/newlib-6b843b8.tar.gz
download: 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8 
-> sources/newlib-6b843b8.tar.gz

download: no ssl context
download: 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/6b843b8: 
error: HTTP Error 404: Not Found


Even by hand in a browser, codeland is gone.

Any suggestions or advice?


The mirrors are only updated daily or manually from my desktop machine.

--
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: Change Control Board (CCB) proposal for requirements (v2)

[Sebastian Huber]

On 25/07/2019 01:17, Joel Sherrill wrote:



On Wed, Jul 24, 2019 at 1:39 AM Sebastian Huber 
> wrote:


Hello,

I work currently on a requirements engineering section for RTEMS in the
RTEMS Software Engineering manual:

https://docs.rtems.org/branches/master/eng/index.html

One topic is the Change Control Board (CCB). The Doorstop maintainer
was
not so fond of my idea to add support for digital signatures:

https://github.com/jacebrowning/doorstop/issues/375

So, here is a new proposal without signatures. I think this makes the
process a bit easier.

Change Control Board


Working with requirements usually involves a Change Control Board
(:term:`CCB`).  The CCB of the RTEMS project is the
`RTEMS developer mailing list
`_.

There are the following actors involved:

* *RTEMS users*: Everyone using the RTEMS real-time operating system to
design,
    develop and build an application on top of it.

* *RTEMS developers*: The persons developing and maintaining RTEMS.
They write
    patches to add or modify code, requirements, tests and
documentation.

* *RTEMS maintainers*: They are listed in the
    `MAINTAINERS `_ file
and have
    write access to the project repositories.

.. TODO: Make a reference to the "normal patch review process".

Adding and changing requirements follows the normal patch review
process.


The normal process should be defined and referenced.


Yes, I propose to add it to a "Contributing" section in the user manual. 
Is this all right for you, or do you prefer the RTEMS Software 
Engineering manual?




Reviews and comments may be submitted by anyone, but a maintainer
review is
required to approve *significant* changes.  In addition for significant
changes, there should be at least one reviewer with a sufficient
independence
from the author which proposes a new requirement or a change of an
existing
requirement.  Working in another company on different projects is
sufficiently
independent. 



Different companies and same funding source isn't independent.


The "another company on different projects" was my attempt to rule out 
people fed by the same money pot. Do yo have a suggestion to formulate 
this more clearly?




RTEMS maintainers do not know all the details, so they
trust in
general people with experience on a certain platform.  Sometimes no
review
comments may appear in a reasonable time frame, then an implicit
agreement to
the proposed changes is assumed.  Patches can be sent at anytime, so
controlling changes in RTEMS requires a permanent involvement on the
RTEMS
developer mailing list.


There is a problem with independence and reasonable time frame. You are
relying on volunteers to review requirements (or anything else) and at 
their time
availability mercy. I don't know how you ensure you have proper second 
reviewers

from the volunteer community in a reasonable time frame. Lack of commentary
could just mean personal issues or travel. For example, I spent 3 weeks 
of June
traveling and/or teaching and was sick enough for two rounds of 
antibiotics. I

care about reviewing but I didn't review much last month. And even when I do
review, there is a practical limit.

Some of this going to have to be spoon fed to the community to have a chance
to get it reviewed by volunteer. Better would be paid time from 
alternative core
developers to speed this up.But ultimately some core reviewers will be 
volunteer

and slow.

A normal timeout isn't appropriate for requirements. They really deserve 
positive

acknowledge. A true CCB waits for a majority from a quorum.


When you get no response from maintainers and you know they are on 
holidays or otherwise not available, then a reasonable timeout is not 
within this time frame.


I think we should not put all "requirements" into one bucket. There are 
high level ones and low level ones, e.g. "If the id parameter is NULL, 
then the X directive shall return the RTEMS_Y status.". Initially, we do 
a reverse engineering of the RTEMS code base to get the requirements. 
So, the code base will probably stay as is. The work I produce in the 
next year is also reviewed by ESA staff. We have a bit of funding to 
spend on review work by community members (for example Gedare if he is 
interested).


A technical part of the solution is be something like Phabricator which 
tracks
getting multiple approvals and lets you do online reviews. A tool like 
this also
helps with the records for code reviews and approval beyond the final 
git log.
Thinking about alternatives to mailing list based patch review process 
is a good idea. I would use the same approach for code and requirements. 
I am not sure

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> We don't need threads for this program. I meant if you know the concept
> of software threads in general and what a stack is.
>

I have removed the RTEMS_RECORD_THREAD_STACK_CURRENT.

https://github.com/rmeena840/rtems-tools/commit/f7838f156006064ffc53b1b1d3fb01f80ef15ae4



-- 
*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: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 25/07/2019 07:53, Ravindra Kumar Meena wrote:

We don't need threads for this program. I meant if you know the concept
of software threads in general and what a stack is.


I have removed the RTEMS_RECORD_THREAD_STACK_CURRENT.

https://github.com/rmeena840/rtems-tools/commit/f7838f156006064ffc53b1b1d3fb01f80ef15ae4 


No, sorry, this is not what we need. Maybe you should delete this code 
part and start from scratch.


We process record events and produce LTTNG events. Is this clear?

Your task is:

1. Gather the information from two record events 
(RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN) with 
the same timestamp on the same CPU.


2. Once you gathered the information of two events that meet this 
criteria, you produce exactly one LTTNG sched_switch event.


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