Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

On 14/08/2015 7:44 am, Rohini Kulkarni wrote: > --- > > -BSP_START_DATA_SECTION static const arm_cp15_start_section_config > -zynq_mmu_config_table[] = { > +BSP_START_DATA_SECTION const arm_cp15_start_section_config > +arm_cp15_start_mmu_config_table[] = { >ARMV7_CP15_START_DEFAULT_SECTIONS,

Re: Identify control statements in source code

On August 13, 2015 7:15:08 PM CDT, Chris Johns wrote: >On 14/08/2015 6:34 am, Daniel Gutson wrote: >> I'd recommend a gcc plugin that generates your annotations; > >There is a Python framework for plugins to help make things easier ... > > http://gcc-python-plugin.readthedocs.org/en/latest/index

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Yeah. I am working now on developing a validate method to point out bad and good results. And documentation seems to be super important for now because I feel that logic is correct just some semantics based on above discussion will change. On Thursday, August 13, 2015, Gedare Bloom wrote: > I se

Re: Identify control statements in source code

On 14/08/2015 6:34 am, Daniel Gutson wrote: > I'd recommend a gcc plugin that generates your annotations; There is a Python framework for plugins to help make things easier ... http://gcc-python-plugin.readthedocs.org/en/latest/index.html Chris ___ de

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

I see, it is the "list" being passed, not the mutex_control. I misread something earlier. It may be acceptable to store a pointer to this list into the Thread_Control somewhere if that will simplify the interface and not complicate the implementation by too much. But I haven't given this too much

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

On Thu, Aug 13, 2015 at 7:31 PM, Cyrille Artho wrote: > Hi Gedard, > The CORE_mutex_order_list in the thread priority update functions is > needed to step down the priority in the right way upon unlocking. > Currently these functions are only used internally. > If you'd like a simpler interface, t

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

On Thu, Aug 13, 2015 at 6:55 PM, Saurabh Gadia wrote: > How can we get mutex->queue.priority_before data structure without having > the mutex structure. We need that to change the priority_before for every > acquired mutex by a thread to ensure that there is proper stepdown of > priority. We just

Re: Identify control statements in source code

On August 13, 2015 5:38:24 PM CDT, Daniel Gutson wrote: > >El 13/8/2015 19:35, "Joel Sherrill" >escribió: >> >> >> >> On August 13, 2015 3:34:12 PM CDT, Daniel Gutson > wrote: >> >I'd recommend a gcc plugin that generates your annotations; >otherwise, >> >dig into gcov in order to parse a .gcn

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

How can we get mutex->queue.priority_before data structure without having the mutex structure. We need that to change the priority_before for every acquired mutex by a thread to ensure that there is proper stepdown of priority. We just need to have mutex to get the start point of the chain_control

Re: Identify control statements in source code

El 13/8/2015 19:35, "Joel Sherrill" escribió: > > > > On August 13, 2015 3:34:12 PM CDT, Daniel Gutson < daniel.gut...@tallertechnologies.com> wrote: > >I'd recommend a gcc plugin that generates your annotations; otherwise, > >dig into gcov in order to parse a .gcno file. > > Covoar already produc

Re: Identify control statements in source code

On August 13, 2015 3:34:12 PM CDT, Daniel Gutson wrote: >I'd recommend a gcc plugin that generates your annotations; otherwise, >dig into gcov in order to parse a .gcno file. Covoar already produces gcov files. A previous gsoc student did that. This was a bonus task and we were never 100% con

Re: Nice surprise with C++11

I have been desperately busy to fix this, though we are indeed interested in the fix since we'll use C++14 soon. That's why I will address this a bit later. Sorry the delay. Daniel. On Wed, Aug 5, 2015 at 7:36 PM, Daniel Gutson wrote: > On Fri, Jul 31, 2015 at 9:56 AM, Sebastian Huber > wrot

[PATCH] Code refactor changes to mm.h and mminit.c

--- c/src/lib/libbsp/arm/shared/mminit.c | 17 +++-- c/src/lib/libbsp/shared/include/mm.h |5 - 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/c/src/lib/libbsp/arm/shared/mminit.c b/c/src/lib/libbsp/arm/shared/mminit.c index acfbfc0..f2617f8 100644 --- a/c/s

[PATCH 3/4] Code refactor realview-pbx-a9 BSP MMU initialization

--- c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am |4 +++ .../arm/realview-pbx-a9/startup/bspstarthooks.c| 27 ++-- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am b/c/src/lib/libbsp/arm/realview-pbx-

[PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

--- c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am |4 +++ .../libbsp/arm/xilinx-zynq/startup/bspstartmmu.c | 27 ++-- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am b/c/src/lib/libbsp/arm/xilinx-zynq/Makef

[PATCH 1/4] Code refactor altera-cyclone-V MMU initialization

--- c/src/lib/libbsp/arm/altera-cyclone-v/Makefile.am |4 .../arm/altera-cyclone-v/startup/bspstarthooks.c | 22 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/c/src/lib/libbsp/arm/altera-cyclone-v/Makefile.am b/c/src/lib/libbsp/arm/altera-cycl

[PATCH 2/4] Code refactor Beagle BSP MMU initialization

--- c/src/lib/libbsp/arm/beagle/Makefile.am |4 c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c | 25 ++--- 2 files changed, 16 insertions(+), 13 deletions(-) diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am b/c/src/lib/libbsp/arm/beagle/Makefile.am ind

Re: [PATCH 1/6] add mailbox support for rpi bsp

Hmmm... Gedare had a little better luck than I did but it still didn't work. He sees a non-ASCII character in #5. Not sure what's up. On 8/13/2015 3:31 PM, QIAO YANG wrote: I rebased on the latest commit on master: commit 61e7c698a44137afbc1447ed328b14a0d9e55016 Author: Andre Marques Date:

Re: Identify control statements in source code

I'd recommend a gcc plugin that generates your annotations; otherwise, dig into gcov in order to parse a .gcno file. On Thu, Aug 13, 2015 at 5:09 PM, Hermann Felbinger wrote: > I am looking for something that processes the source code at compile time. I > need this information to map branches fro

Re: [PATCH 1/6] add mailbox support for rpi bsp

I rebased on the latest commit on master: commit 61e7c698a44137afbc1447ed328b14a0d9e55016 Author: Andre Marques Date: Mon Jul 27 17:01:44 2015 +0100 Raspberry Pi implementation for the RTEMS GPIO API. I've just cloned it and the patches are all applied. Maybe I misunderstand which com

Re: [PATCH 1/6] add mailbox support for rpi bsp

This still doesn't apply for me. Did you pull the latest changes and rebase? --joel On 8/12/2015 5:08 PM, YANG QIAO wrote: From: YANG Qiao --- c/src/lib/libbsp/arm/raspberrypi/Makefile.am | 4 ++ c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h | 32 + .../libbsp/arm

Re: Identify control statements in source code

I am looking for something that processes the source code at compile time. I need this information to map branches from execution traces to conditions within the source code. With this information it will be possible to analyze source coverage metrics as decision coverage or MCDC. Daniel Gutson s

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Saurabh, Remove the commit "Updated the motivation for creating the new branch", don't add the .tags files, and don't add the .m4 changes that are not related to your project. Switch to using RTEMS_CONTAINER_OF macro and remove the typeaddr one. coremutexseize.c : remove the modification where y

Re: Identify control statements in source code

1) Are you looking for something statically processed (i.e. at compile time) or at runtime? (such as gcov) 2) Are you looking for a way to add _your_ annotations, or a way to _extract_ information? In any case, the best way I can think of is with a gcc plugin. Have you seen gcc's -ftest-coverage

Re: Identify control statements in source code

On 8/13/2015 2:06 PM, Hermann Felbinger wrote: Hi all! I am working on a tool to analyze source code coverage for RTEMS. Currently I am looking for a tool to annotate source code such that I can extract information about statements and conditions that affect the control flow of a program. A

Identify control statements in source code

Hi all! I am working on a tool to analyze source code coverage for RTEMS. Currently I am looking for a tool to annotate source code such that I can extract information about statements and conditions that affect the control flow of a program. A similar tool exists for Ada programs. They call this

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Hi, I have created a new branch for uniprocessor solution of priority inversion problem caused by nested mutex behavior. link: https://github.com/saurabhgadia4/rtems/tree/nested-mutex test case results: https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

That is how we were doing in JPF. The validate method was triggered after every release of mutex by any thread and we would check for all the waiting threads on mutex's held by the holder. And if it finds a thread with higher priority blocked then it would panic or give assertion failure. Thanks,

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Thanks. Would it be possible for you to turn the failure cases into real test failures? In other words, add some logic to detect the priority inversion and abort the test? Gedare On Thu, Aug 13, 2015 at 12:05 PM, Saurabh Gadia wrote: > Hi, > > Following is the result of spsem04 test without the

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Hi, Following is the result of spsem04 test without the patch: *** BEGIN OF TEST SPSEM 4 *** init: S0 created init: S1 created init: TA01 created with priority 36 init: TA02 created with priority 34 init: TA03 created with priority 32 TA01: started with priority 36 TA01: priority 36, holdi

Re: cppcheck errors

El 13/8/2015 12:49, "Gedare Bloom" escribió: > > Daniel, > > Unknown deadline right now. Probably whenever Joel can get around to > it! Realistically, we can create a bugfix "dot release" anytime after > the release subject to user demand. So, even if you miss the 4.11.0 > release with your patche

Re: cppcheck errors

Daniel, Unknown deadline right now. Probably whenever Joel can get around to it! Realistically, we can create a bugfix "dot release" anytime after the release subject to user demand. So, even if you miss the 4.11.0 release with your patches, we can cut a 4.11.1 after applying the patches if you ne

Re: cppcheck errors

Hi Gedare, What's the deadline for the official release, if any? El 13/8/2015 7:15, "Gedare Bloom" escribió: > Daniel, > > The release has (unofficially) happened on rtems.git/4.11 branch, from > which master is slowly diverging. Any patches you want applied before > the official release nee

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Ok. I will mail you back soon. On Thursday, August 13, 2015, Gedare Bloom wrote: > Saurabh, > > Please pull from rtems.git again, create a new branch from 'master', > and apply your changes to the branch. It's too hard to review code > that is not all by itself on a branch. > > Gedare > > On Thu

Re: [PATCH V2 1/2] RTEMS GPIO API definition and implementation.

Hello Andre, I created a ticket . Please make the necessary changes. Thanks. Cheers, Ketul On 13 August 2015 at 19:38, André Marques wrote: > On 13-08-2015 14:51, Ketul Shah wrote: > > Hi Andre, > > Thanks for the reply. > > On 13 August 2015 at 19:13, And

Re: [PATCH V2 1/2] RTEMS GPIO API definition and implementation.

On 13-08-2015 14:51, Ketul Shah wrote: Hi Andre, Thanks for the reply. On 13 August 2015 at 19:13, André Marques mailto:andre.lousa.marq...@gmail.com>> wrote: Hello Ketul, On 13-08-2015 13:04, Ketul Shah wrote: Hi Andre, Great API and happy to know that it is merg

Re: [PATCH V2 1/2] RTEMS GPIO API definition and implementation.

Hello Ketul, On 13-08-2015 13:04, Ketul Shah wrote: Hi Andre, Great API and happy to know that it is merged with main line. Eventually I implemented GPIO driver for BBB using this API. After debugging for rtems_gpio_get_value() on BBB I found the following bug. For BBB, GPIO pin nos. varies

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Saurabh, Please pull from rtems.git again, create a new branch from 'master', and apply your changes to the branch. It's too hard to review code that is not all by itself on a branch. Gedare On Thu, Aug 13, 2015 at 5:28 AM, Saurabh Gadia wrote: > Hi, > > I have implemented uniprocessor model of

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Can you please print the output from spsem04 without strict-order enabled? (Or, without your patches to fix it?) On Thu, Aug 13, 2015 at 6:31 AM, Saurabh Gadia wrote: > Hi, > > To validate spsem03 test case I created a new test case by modifying > spsem02. Below is the description of the new test

Re: [PATCH V2 1/2] RTEMS GPIO API definition and implementation.

On Thu, Aug 13, 2015 at 8:04 AM, Ketul Shah wrote: > Hi Andre, > > Great API and happy to know that it is merged with main line. > > Eventually I implemented GPIO driver for BBB using this API. After debugging > for rtems_gpio_get_value() on BBB I found the following bug. > > For BBB, GPIO pin nos

Re: How can we extract mutex_control

On Thu, Aug 13, 2015 at 4:57 AM, Saurabh Gadia wrote: > For time being I am calculating it this way: > > #define typeaddr(addr, type, member) \ > (type *)((char *)(addr) - offsetof(type, member)) > If you need this, use RTEMS_CONTAINER_OF macro > CORE_mutex_Control *the_mutex= typeaddr(holder->

Re: Uniprocessor implementation of nested mutex problem of priority inversion.

Hi, To validate spsem03 test case I created a new test case by modifying spsem02. Below is the description of the new test case: Task: TA01 having priority 36, TA02 having priority 34, TA03 having priority 32. Throughout the course following actions are performed: TA01 acquires S0 TA02 acquires

Re: cppcheck errors

Daniel, The release has (unofficially) happened on rtems.git/4.11 branch, from which master is slowly diverging. Any patches you want applied before the official release need to be (1) associated with a ticket on Trac, and (2) apply to both the 4.11 and master branches. Gedare On Wed, Aug 12, 20

Re: Fwd: SMP support for Raspberry Pi 2

On Wed, Aug 12, 2015 at 5:15 PM, Rohini Kulkarni wrote: > Hi, > > It would be great if somebody can help here. > [1] How are the mailbox registers available for each core of Pi2 to be used. > > [2] Another thing is that I don't know which registers of Pi 1 are available > for Pi2 as well. The ones

Uniprocessor implementation of nested mutex problem of priority inversion.

Hi, I have implemented uniprocessor model of nested mutex problem in rtems. its still in basic form. I tried to multiplex it with the existing solution but was finding hard time. To push ahead, I decided to have separate functions for uniprocessor and SMP(kept default behavior) and with your revie

Re: How can we extract mutex_control

For time being I am calculating it this way: #define typeaddr(addr, type, member) \ (type *)((char *)(addr) - offsetof(type, member)) CORE_mutex_Control *the_mutex= typeaddr(holder->Wait.queue, CORE_mutex_Control, Wait_queue); Is there any other easy way? Like I guess we maintain objects so is

How can we extract mutex_control

Hi, For a given thread waiting on a mutex, how can we extract the mutex_control on which this thread is waiting? For example in Thread_Change_priority(). So do the thread_control structure has any reference to mutex on which it is blocked? Thanks, Saurabh Gadia __