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

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 s

Re: GSoC Project | Basic Support for Trace Compass

On 24/07/2019 07:47, Ravindra Kumar Meena wrote: This makes no sense: static void print_item( client_context *cctx, const client_item *item ) {    if( cctx->event_counter % 2 == 0 ){ 1. event_counter is not per CPU. 2. You don't care about the record event. You have

Re: BSP names

On 23/7/19 5:36 pm, Sebastian Huber wrote: > On 21/07/2019 04:08, Chris Johns wrote: >> On 19/7/19 11:41 pm, Joel Sherrill wrote: >>> On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber >>> >> > >>> wrote: >>> >>> Hello, >>> >>> I worked a bit with D

Re: GSoC Project | Basic Support for Trace Compass

> > This makes no sense: > > static void print_item( client_context *cctx, const client_item *item ) > { >if( cctx->event_counter % 2 == 0 ){ > > 1. event_counter is not per CPU. > > 2. You don't care about the record event. You have to do this for > specific events as I already wrote in the de

Re: Change Control Board (CCB) proposal for requirements

- Am 23. Jul 2019 um 19:26 schrieb Sebastian Huber sebastian.hu...@embedded-brains.de: > - Am 23. Jul 2019 um 17:30 schrieb joel j...@rtems.org: > >> One random thought is how to ensure that patches from people with >> hardware who submit patches to fix bugs get through the process. >> W

Re: Change Control Board (CCB) proposal for requirements

- Am 23. Jul 2019 um 17:30 schrieb joel j...@rtems.org: > One random thought is how to ensure that patches from people with > hardware who submit patches to fix bugs get through the process. > We have generally trusted people who have hardware. This is common > for boards none of us have. > >

Re: Requirement Identifiers

Hi I am not sure if I am derailing this or helping. I think we need to seriously consider that we want these to be easy to manage and the logical names should reflect the natural groups in RTEMS. I lean to something simple like this without the arbitrary sections. ARINC 653 doesn't have odd subse

Re: Change Control Board (CCB) proposal for requirements

One random thought is how to ensure that patches from people with hardware who submit patches to fix bugs get through the process. We have generally trusted people who have hardware. This is common for boards none of us have. Also we have relied on a timeout rule and a level of significance. Like

newlib ndbm documentation

Hi Just a note to remind you that we need to find a way to get the ndbm documentation into newlib. Since they put a marked up man page at the top of the .c file, I expect there are only two choices. (1) Put it at the top of ndbm.c as expected (2) Leave ndbm.c as found and add ndbm_doc.c As much

[PATCH v6] ndbm test suite

--- testsuites/psxtests/Makefile.am | 9 + testsuites/psxtests/configure.ac| 1 + testsuites/psxtests/psxndbm01/init.c| 299 testsuites/psxtests/psxndbm01/psxndbm01.doc | 36 +++ testsuites/psxtests/psxndbm01/psxndbm01.scn | 29 ++ 5 files

Re: Change Control Board (CCB) proposal for requirements

Hello Gedare, thanks for the review, here is a second version. The final review can later when I submit the patch for the RTEMS Software Engineering manual. Change Control Board Working with requirements usually involves a Change Control Board (:term:`CCB`). The CCB of t

GSoC PRU: AM35xx Clock driver

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/610349693dd31d8b0efd33776516b

[PATCH] devel/sis: Fix building the SIS on FreeBSD

From: Chris Johns - Update to SIS 2.17 which has internal readline support for the hosts which do not have readline. Closes #3763 --- bare/config/devel/sis-2-1.cfg | 5 ++--- rtems/config/5/rtems-riscv.bset | 2 +- rtems/config/5/rtems-sparc.bset | 3 +-- source-builder/config/sis-

Re: GSoC Project | Basic Support for Trace Compass

On 23/07/2019 12:34, Ravindra Kumar Meena wrote: All your state must be per-CPU otherwise you mix data from different CPUs. Have made changes. https://github.com/rmeena840/rtems-tools/commit/fac873672d5cd8fe3605ea7ac817ebaa4e8e4cdc This makes no sense: static void print_item( client_

Re: GSoC Project | Basic Support for Trace Compass

> > All your state must be per-CPU otherwise you mix data from different CPUs. > Have made changes. https://github.com/rmeena840/rtems-tools/commit/fac873672d5cd8fe3605ea7ac817ebaa4e8e4cdc Have a look. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Tec

Re: GSoC Project | Basic Support for Trace Compass

On 23/07/2019 10:23, Ravindra Kumar Meena wrote: I said this before, do not add global variables like this:   static void print_item( client_context *cctx, const client_item *item )   {     switch_event switch_event;     event_header_extended event_header_extended;

Re: GSoC Project | Basic Support for Trace Compass

> > I said this before, do not add global variables like this: > > static void print_item( client_context *cctx, const client_item *item ) > { > switch_event switch_event; > event_header_extended event_header_extended; > char item_data_str[256]; > FILE **f = cctx->event_streams;

Re: BSP names

On 21/07/2019 04:08, Chris Johns wrote: On 19/7/19 11:41 pm, Joel Sherrill wrote: On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber mailto:sebastian.hu...@embedded-brains.de>> wrote: Hello, I worked a bit with Doorstop and found the YAML file quite interesting. The file format i