Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[Ketul Shah]

Hello Punit and all,

According to me, Punit you must have completed some gpio test through gpio
API that was merged last year. So till the final result of accepted student
you can start working with PWM driver that plays an important role for any
embedded project. This would be a good kick-start for you as well as a
strong reason to showcase in your proposal. Try to give hardware test and
post the video if possible.

Coming to further I2C and SPI can be next milestones. To me these should be
at the highest priorities. I had done I2C driver but was not able to make
the hardware test. So you can also refer that and come up with the output
along with best modifications.

Next target you can set for SPI after both drivers are tested and committed.

For the references you can always have a loot at code of GPIO
API,MINIX,FreeBSD for BBB drivers.

Any suggestions ?

In case of any queries you can always ping.

Cheers,
Ketul

On 5 March 2016 at 01:02, Marcos Díaz 
wrote:

> We use I2c but using drivers from TI's baremetal drivers they provide in
> their StarterWare software suite.
> So, currently we cannot commit that into RTEMS.
> But those drivers should be very useful to port to RTEMS.
>
> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz <
>> marcos.d...@tallertechnologies.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill  wrote:
>>>


 On Wed, Mar 2, 2016 at 1:41 PM, punit vara  wrote:

> Yes I have checked previous year work of ketul . He has done ADC and
> GPIO BSP . It seems SPI,USB BSP need to be developed as I have checked
> rtems.git and I am not sure about I2C .I asked last year student Ketul
> .According to him , I2c is also need to be modified. I tried to contact 
> Ben
> but he is unreachable on mailing list :-(
>
>
 Let me reach out to Ketul and see if a private ping helps.

 Start with the assumption that USB needs work. That involves the
 rtems-libbsd tree and
 there is likely code to import from FreeBSD that will help a lot.

 SPI and i2c are close to one another in my understanding. Likely Ketul
 is referring to changes
 in the RTEMS i2c interfaces.

 My recollection is that the NIC had performance issues based on the
 version of U-Boot
 used. There was some traffic at the end of GSoC about this. I don't
 know if it was
 ever resolved.  But the NIC should work. Maybe worth benchmarking.

>>> We had more of these problems when trying to use I2C. It was fixed in
>>>
>>> https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764.
>>> I think we dont need tos ee these problems any more
>>>


>> Marcos.. does this mean that the BBB i2c is complete now?
>>
>> And is my understanding that this covers SPI correct?
>>
>> What else on the BBB is left?
>>
>> --joel
>>
>>
>>> --joel


 On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Mar 2, 2016 at 1:24 PM, Hesham Almatary <
>> heshamelmat...@gmail.com> wrote:
>>
>>> Hi Punit,
>>>
>>> You can have a look at the open projects here [1] and find one or
>>> more
>>> that match your experience/interests.
>>>
>>> [1] https://devel.rtems.org/wiki/Developer/OpenProjects
>>>
>>>
>> I have added Ben Gras. He knows more about the BBB than anyone. I am
>> unsure what is left
>> to do. Have you compared the status of last year's projects versus
>> the git repository?
>>
>> --joel
>>
>>
>>> Regards,
>>>
>>> On Wed, Mar 2, 2016 at 7:14 PM, punit vara 
>>> wrote:
>>> >  I have asked for BBB BSP proposal before but I haven't found any
>>> good
>>> > response from someone. What are the projects you are going to
>>> mentor @joel ?
>>> > Would anyone please suggest me to pick any other project ?
>>> >
>>> > ___
>>> > devel mailing list
>>> > devel@rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> --
>>> Hesham
>>> ___
>>> 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

>>>
>>>
>>>
>>> --
>>>
>>> __
>>>
>>> 
>>>
>>>
>>> Marcos Díaz
>>>
>>> Software Engineer
>>>
>>>
>>> San Lorenzo 47, 3rd Floor, Office 5
>>>
>>> Córdoba, Argentina
>>>
>>>
>>> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>>
>>> Skype: markdiaz22
>>>
>>>
>>
>
>
> --
>
> __
>
> 
>
>
> Marcos Díaz
>
> S

[PATCH] generic_or1k: Fix include guard conflict at bsp.h

[Hesham Almatary]

---
 c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h 
b/c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h
index 72bb107..0a82058 100644
--- a/c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h
+++ b/c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h
@@ -7,15 +7,15 @@
  */
 
 /*
- * COPYRIGHT (c) 2014-2015 Hesham ALMatary 
+ * COPYRIGHT (c) 2014-2016 Hesham ALMatary 
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
  *  http://www.rtems.org/license/LICENSE
  */
 
-#ifndef LIBBSP_GENERIC_OR1K_H
-#define LIBBSP_GENERIC_OR1K_H
+#ifndef LIBBSP_OR1K_H
+#define LIBBSP_OR1K_H
 
 #include 
 #include 
@@ -35,7 +35,7 @@ extern "C" {
 }
 #endif /* __cplusplus */
 
-#endif /* LIBBSP_GENERIC_OR1K_H */
+#endif /* LIBBSP_OR1K_H */
 
 /**
  * @defgroup generic_or1k support
-- 
1.9.1

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

Re: [PATCH 5/8] generic_or1k BSP clock driver correction

[Hesham Almatary]

Hi Jakob,

I submitted a patch that fixes the include guard bug so you don't have
to do anything with it. We can work together to get your work sorted
out and merged, kindly let us know if you need any help.

Best,
Hesham

On Wed, Mar 2, 2016 at 5:01 PM, Hesham Almatary
 wrote:
> Hi Jakob,
>
> I reapplied your patches after the include guard issue and it compiles
> fine. However, helloworld and ticker samples don't work on either
> or1ksim or qemu. Both run fine without your patches applied. Since not
> all the users have a hardware platform, RTEMS prefers that each port
> runs at least hello and ticker on one or more simulators. So it would
> be great if you can test your patches on or1ksim and/or qemu as the
> main targets for testing.
>
> There's a readme file at the generic_or1k directory that contains some
> instructions how to run the test cases. Also, RTEMS has two other
> systems for testing purposes like sim-scripts [1] which has scripts to
> run test cases, and RTEMS Tester [2] that automates running the whole
> 500+ tests. or1k port within RTEMS Tester depends on qemu-system-or32
> and not or1ksim.
>
> I'd be happy to provide any help if required.
>
> [1] https://devel.rtems.org/browser/rtems-testing/sim-scripts
> [2] https://devel.rtems.org/wiki/Testing/Tester
>
> Best,
> Hesham
>
> On Wed, Mar 2, 2016 at 11:44 AM, Hesham Almatary
>  wrote:
>> On Tue, Mar 1, 2016 at 2:03 PM, Jakob Viketoft
>>  wrote:
>>> 
>>> From: devel [devel-boun...@rtems.org] on behalf of Hesham Almatary 
>>> [heshamelmat...@gmail.com]
>>> Sent: Saturday, February 27, 2016 19:57
>>> To: Jakob Viketoft
>>> Cc: rtems-de...@rtems.org
>>> Subject: Re: [PATCH 5/8] generic_or1k BSP clock driver correction
>>>
On Sat, Feb 20, 2016 at 11:01 PM,   wrote:
> From: Jakob Viketoft 
>
>  - Improve the clock driver to use RTEMS default tick period
>or the on the one supplied by the application
>  - Avoid rewriting the timer settings, since all we need is to clear the 
> interrupt
>  - Remove any mention of or1ksim in favour of generic_or1k
>
> Close #2600
> ---
>  .../lib/libbsp/or1k/generic_or1k/clock/clockdrv.c  | 109 
> ++---
>  1 file changed, 51 insertions(+), 58 deletions(-)
>
> diff --git a/c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c 
> b/c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c
> index e01d2e5..60eec98 100644
> --- a/c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c
> +++ b/c/src/lib/libbsp/or1k/generic_or1k/clock/clockdrv.c
> @@ -3,13 +3,15 @@
>   *
>   * @ingroup bsp_clock
>   *
> - * @brief or1k clock support.
> + * @brief generic_or1k clock support.
>   */
>
>  /*
>   * generic_or1k Clock driver
>   *
>   * COPYRIGHT (c) 2014-2015 Hesham ALMatary 
> + * Copyright (c) 2014-2016 ÅAC Microtec AB 
> + * Jakob Viketoft 
> 
>   *
>   * The license and distribution terms for this file may be
>   * found in the file LICENSE in this distribution or at
> @@ -25,35 +27,30 @@
>  #include 
>
>  /* The number of clock cycles before generating a tick timer interrupt. 
> */
> -#define TTMR_NUM_OF_CLOCK_TICKS_INTERRUPT 0x09ED9
> -#define OR1K_CLOCK_CYCLE_TIME_NANOSECONDS 10
> +#define OR1K_CLOCK_CYCLE_TIME_NANOSECONDS (10 / 
> OR1K_BSP_CLOCK_FREQ)
clockdrv.c:30:61: error: 'OR1K_BSP_CLOCK_FREQ' undeclared (first use
in this function)
>>>
>>> Sorry for the delay in responding, it took me a while to figure this one 
>>> out since I had to build a new toolchain and stuff to make sure I was using 
>>> same as you. I had rather quickly transfered the change from what we were 
>>> doing in our own BSP.
>>>
>> Thanks for doing this.
>>
>>> Basically, there is a copy-paste error between the 
>>> generic_or1k/include/bsp.h and generic_or1k/include/generic_or1k.h include 
>>> guards which both define the same thing. Change the one in bsp.h and 
>>> everything compiles as it should. This is somewhat outside this patch's 
>>> intentions, but should this patch address this as well?
>>>
>> Great catch. I already have a local fix, if you prefer not to submit a
>> patch for this bug separately, I am happy to submit it.
>>
>>> Jakob Viketoft
>>> Senior Engineer in RTL and embedded software
>>>
>>> ÅAC Microtec AB
>>> Dag Hammarskjölds väg 48
>>> SE-751 83 Uppsala, Sweden
>>>
>>> T: +46 702 80 95 97
>>> http://www.aacmicrotec.com
>>
>>
>>
>> --
>> Hesham
>
>
>
> --
> Hesham



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

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah  wrote:

> Hello Punit and all,
>
> According to me, Punit you must have completed some gpio test through gpio
> API that was merged last year. So till the final result of accepted student
> you can start working with PWM driver that plays an important role for any
> embedded project. This would be a good kick-start for you as well as a
> strong reason to showcase in your proposal. Try to give hardware test and
> post the video if possible.
>
> Coming to further I2C and SPI can be next milestones. To me these should
> be at the highest priorities. I had done I2C driver but was not able to
> make the hardware test. So you can also refer that and come up with the
> output along with best modifications.
>
> Next target you can set for SPI after both drivers are tested and
> committed.
>
> For the references you can always have a loot at code of GPIO
> API,MINIX,FreeBSD for BBB drivers.
>
> Any suggestions ?
>
> In case of any queries you can always ping.
>
> Cheers,
> Ketul
>
> On 5 March 2016 at 01:02, Marcos Díaz 
> wrote:
>
>> We use I2c but using drivers from TI's baremetal drivers they provide in
>> their StarterWare software suite.
>> So, currently we cannot commit that into RTEMS.
>> But those drivers should be very useful to port to RTEMS.
>>
>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz <
>>> marcos.d...@tallertechnologies.com> wrote:
>>>


 On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill  wrote:

>
>
> On Wed, Mar 2, 2016 at 1:41 PM, punit vara 
> wrote:
>
>> Yes I have checked previous year work of ketul . He has done ADC and
>> GPIO BSP . It seems SPI,USB BSP need to be developed as I have checked
>> rtems.git and I am not sure about I2C .I asked last year student Ketul
>> .According to him , I2c is also need to be modified. I tried to contact 
>> Ben
>> but he is unreachable on mailing list :-(
>>
>>
> Let me reach out to Ketul and see if a private ping helps.
>
> Start with the assumption that USB needs work. That involves the
> rtems-libbsd tree and
> there is likely code to import from FreeBSD that will help a lot.
>
> SPI and i2c are close to one another in my understanding. Likely Ketul
> is referring to changes
> in the RTEMS i2c interfaces.
>
> My recollection is that the NIC had performance issues based on the
> version of U-Boot
> used. There was some traffic at the end of GSoC about this. I don't
> know if it was
> ever resolved.  But the NIC should work. Maybe worth benchmarking.
>
 We had more of these problems when trying to use I2C. It was fixed in

 https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764.
 I think we dont need tos ee these problems any more

>
>
>>> Marcos.. does this mean that the BBB i2c is complete now?
>>>
>>> And is my understanding that this covers SPI correct?
>>>
>>> What else on the BBB is left?
>>>
>>> --joel
>>>
>>>
 --joel
>
>
> On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Mar 2, 2016 at 1:24 PM, Hesham Almatary <
>>> heshamelmat...@gmail.com> wrote:
>>>
 Hi Punit,

 You can have a look at the open projects here [1] and find one or
 more
 that match your experience/interests.

 [1] https://devel.rtems.org/wiki/Developer/OpenProjects


>>> I have added Ben Gras. He knows more about the BBB than anyone. I am
>>> unsure what is left
>>> to do. Have you compared the status of last year's projects versus
>>> the git repository?
>>>
>>> --joel
>>>
>>>
 Regards,

 On Wed, Mar 2, 2016 at 7:14 PM, punit vara 
 wrote:
 >  I have asked for BBB BSP proposal before but I haven't found any
 good
 > response from someone. What are the projects you are going to
 mentor @joel ?
 > Would anyone please suggest me to pick any other project ?
 >
 > ___
 > devel mailing list
 > devel@rtems.org
 > http://lists.rtems.org/mailman/listinfo/devel



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



 --

 __

 


 Marcos Díaz

 Software Engineer


 San Lorenzo 47, 3rd Floor, Offic

Re: GSoC2016 : Providing SMP support for RTEMS

[Joel Sherrill]

On Fri, Mar 4, 2016 at 11:59 PM, Rahul Goradia 
wrote:

> Hello everyone.
> I am Rahul Goradia from India.
> I am interested to provide SMP support for RTEMS.
>
> I have read Getting Started Document and configured RTEMS for SPARC.
> I successfully run helloworld example and now trying to run modified code.
>
> I believe I have good understanding of operating system fundamentals.
> Currently I am working on issues related to running RTOS multiprocessor.
> Working on SMP support for RTMES will be a good opportunity for me to learn
> RTOS issues on multiprocessor support.
>
> Please tell me what literature I need to study and in which direction
> should I go.
>
>
The SMP support is fairly mature so you won't find a general project like
"add SMP". Projects will be more focused like adding SMP support to a
specific Board Support Package, addressing a specific deficiency that
impacts all architectures, or addressing issues that impact a single
architecture.

The Project focused on improving the pc BSP has multiple components needed
for SMP to work on that BSP again.  This has an open projects page.

Similarly, the Pi2 SMP support is missing. This should be on the Pi page.

Also Thread Local Support is an important construct and not implemented on
all architectures. This likely doesn't have a project page but if
interested, we could do a quick survey on which architectures have TLS
support and which do not.

Sebastian may have more general SMP ideas but the initial push for SMP gave
us great support on a subset of BSPs and architectures and left gaps on
others.

--joel


> --
> Thanks and Regards,
>
> Rahul Goradia
>
> ___
> 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: GSoC2016 : Providing SMP support for RTEMS

[Hesham Almatary]

On Sun, Mar 6, 2016 at 6:17 PM, Joel Sherrill  wrote:
>
>
> On Fri, Mar 4, 2016 at 11:59 PM, Rahul Goradia 
> wrote:
>>
>> Hello everyone.
>> I am Rahul Goradia from India.
>> I am interested to provide SMP support for RTEMS.
>>
>> I have read Getting Started Document and configured RTEMS for SPARC.
>> I successfully run helloworld example and now trying to run modified code.
>>
>> I believe I have good understanding of operating system fundamentals.
>> Currently I am working on issues related to running RTOS multiprocessor.
>> Working on SMP support for RTMES will be a good opportunity for me to learn
>> RTOS issues on multiprocessor support.
>>
>> Please tell me what literature I need to study and in which direction
>> should I go.
>>
>
> The SMP support is fairly mature so you won't find a general project like
> "add SMP". Projects will be more focused like adding SMP support to a
> specific Board Support Package, addressing a specific deficiency that
> impacts all architectures, or addressing issues that impact a single
> architecture.
>
> The Project focused on improving the pc BSP has multiple components needed
> for SMP to work on that BSP again.  This has an open projects page.
>
> Similarly, the Pi2 SMP support is missing. This should be on the Pi page.
>
Epiphany too. I've the initial SMP support for it in my local repo,
but didn't have time to clean it up and submit patches yet.

> Also Thread Local Support is an important construct and not implemented on
> all architectures. This likely doesn't have a project page but if
> interested, we could do a quick survey on which architectures have TLS
> support and which do not.
>
> Sebastian may have more general SMP ideas but the initial push for SMP gave
> us great support on a subset of BSPs and architectures and left gaps on
> others.
>
> --joel
>
>>
>> --
>> Thanks and Regards,
>>
>> Rahul Goradia
>>
>> ___
>> 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



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

Re: Policy for RSB branches for 4.9, 4.10 and 4.11

[Chris Johns]

On 04/03/2016 23:46, Sebastian Huber wrote:

On 28/02/16 00:07, Chris Johns wrote:

Hi,

Should we create branches for 4.9 and 4.10 in the RSB repo?

Should the 4.9, 4.10 and 4.11 build set files and config scripts be
removed from master?

I do not see the point of maintaining the branches for releases and the
master and I can see a situation where the 4.11 build on master, ie
currently 4.12, is wrong but noticeable so.


In case branches are used, then we should remove the corresponding
versions from the master. Giving users the option to build the tools for
4.10 from the master */4.10 directory or the 4.10 branch makes no sense.



Great. I will clean this up once I have python3 and python2 support 
finished.


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

Re: GSoC 2016 Interested in Tracing was Re:

[Chris Johns]

Hi,

Please excuse the delay in responding.

Trace doco has been placed in the wiki here 
https://devel.rtems.org/wiki/Developer/Tracing. It outlines the overall 
structure of the tracing support we have. The key component is the trace 
linker. The purpose of the trace linker is to capture in a single user 
interface the complexities of tracing on an embedded real-time target. 
The focus of the work to date is to provide a frame work to do this. The 
trace buffering is a simplified but useful example of how to use the 
trace linker to actually trace code. The printk generator is an even 
simpler example.


I will update the Open Projects TraceTool page today.

For GSoC there are a few areas that can be worked on. They are:

 1) RTEMS Trace linker (rtems-tld) Symbol Signatures.
 2) Target Integration of the Capture Engine with rtems-tld
 3) CTF integration.
 4) Tracing tools improvements.

1) RTEMS Trace linker (rtems-tld) Symbol Signatures.

Update the elftools component and add libdwarf support to rtems-tools. 
Provide a C++ framework in a similar manner to the ELF framework to wrap 
libdwarf. The current use case for libdwarf is to get a function 
signature of a library symbol from the debug info and with this create a 
suitable function signature for the trace linker. Currently this is 
manually done by adding the signatures to the generator INI files. The 
manual approach is a stop gap measure and is not maintainable. This task 
requires good C++ skills.


2) Target Integration of the Capture Engine with rtems-tld

The Capture Engine is a module in RTEMS for the target that provides low 
level services for buffers, triggers and captures for the target. This 
task integrates the Capture Engine to the RTEMS Trace Linker to allow 
rtems-tld linked application to use the Capture Engine for the capture, 
buffering and transport of the trace data. The task also includes 
looking at adding other transports to the Capture Engine other than a 
command line and console output. A role of the Capture Engine is to 
provide an API users can access to allow custom transports. This is 
important with custom hardware with restricted external interfaces.


3) CTF integration

Isaac has been looking at this and I hope he considers joining GSoC 2016 
to help mentor the Trace project with me (Isaac, hint hint :)).


CTF is really neat and brings to RTEMS a range of features we really 
need. The format is good and applicable to RTEMS and the post processing 
and real-time monitoring tools are valuable.


The CTF has a range of tools and parts and this task is to bring those 
together and into the RTEMS Trace Linker. The goal is to encapsulate 
what is needed to use CTF and what it provides with the functionality of 
the RTEMS Trace Linker to build an application for a user that uses CTF. 
The rtems-tld tool knows about RTEMS and function signatures (see task 
1) and it can be taught to internally invoke the CTF tools to create a 
required meta-data files and target code to integrate with the CTF post 
processing tools. Being able to use the Capture Engine is considered an 
advantage.


This task is not as defined as the other ones and requires some research 
and analysis following on from what Isaac has already done. Isaac has 
discussed the remote protocol and this is an important part and worth 
plenty of attention.


Isaac, please feel free to update and correctly anything I have said 
here. As I said I will update the wiki page under Open Projects so 
please add anything more you have related to CTF.


4) Tracing tools improvements

This is an opened ended task and not one to be initially focused on but 
is here for completeness. The rtems-tld uses the binutils symbol mapping 
feature in GNU ld and I have observed some interesting behaviour with 
it. It would be good to characterise this behaviour and if possible 
improve the support in GNU ld. I however feel there are limitations, eg 
tracing static C functions internally optimised by the compiler, C++ and 
templates, and more. Long term there maybe the need to add passes to gcc 
to allow even better trace control. I can see us using the gcc Python 
plug in tool [1]. For this to happen I would like to see a separate GCC 
Plug-In project started and trace support being just one part of it. 
This would allow other interesting but yet to be defined things 
requiring GCC plug-in passes to be collected in one place. A separate 
project for special gcc passes would allow auditing and controls to be 
added so those users in our community who need to know everything about 
the code running in their target can control what happens.


Chris

[1] https://fedorahosted.org/gcc-python-plugin/


On 04/03/2016 04:00, Isaac Gutekunst wrote:

Hi Vivek,

Chris is definitely the person most knowledgeable in this area.





On 03/03/2016 11:45 AM, Joel Sherrill wrote:



On Thu, Mar 3, 2016 at 10:25 AM, Vivek Kukreja mailto:vivekkukr...@outlook.com>> wrote:

Hi everyone


I am Viv

Re: GSoC 2016 Interested in Tracing was Re:

[Chris Johns]

On 07/03/2016 10:25, Chris Johns wrote:

For this to happen I would like to see a separate GCC
Plug-In project started and trace support being just one part of it.


To clarify I mean a project within RTEMS for RTEMS.

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

Re: [PATCH] generic_or1k: Fix include guard conflict at bsp.h

[Gedare Bloom]

On Sun, Mar 6, 2016 at 8:30 AM, Hesham Almatary
 wrote:
> ---
>  c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h 
> b/c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h
> index 72bb107..0a82058 100644
> --- a/c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h
> +++ b/c/src/lib/libbsp/or1k/generic_or1k/include/bsp.h
> @@ -7,15 +7,15 @@
>   */
>
>  /*
> - * COPYRIGHT (c) 2014-2015 Hesham ALMatary 
> + * COPYRIGHT (c) 2014-2016 Hesham ALMatary 
>   *
>   * The license and distribution terms for this file may be
>   * found in the file LICENSE in this distribution or at
>   *  http://www.rtems.org/license/LICENSE
>   */
>
> -#ifndef LIBBSP_GENERIC_OR1K_H
> -#define LIBBSP_GENERIC_OR1K_H
> +#ifndef LIBBSP_OR1K_H
> +#define LIBBSP_OR1K_H
>
I'd use LIBBSP_OR1K_GENERIC_OR1K_BSP_H

embedding most of the path in the guard helps to prevent these kinds
of conflicts.

>  #include 
>  #include 
> @@ -35,7 +35,7 @@ extern "C" {
>  }
>  #endif /* __cplusplus */
>
> -#endif /* LIBBSP_GENERIC_OR1K_H */
> +#endif /* LIBBSP_OR1K_H */
>
>  /**
>   * @defgroup generic_or1k support
> --
> 1.9.1
>
> ___
> 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: GSoC2016 : Providing SMP support for RTEMS

[Sebastian Huber]

Hello,

On 06/03/16 19:17, Joel Sherrill wrote:
Sebastian may have more general SMP ideas but the initial push for SMP 
gave us great support on a subset of BSPs and architectures and left 
gaps on others.


working on SMP improvements is a bit difficult currently since I will 
work in this area nearly full time in the next half a year or so. I hope 
that Darshit Shah will work on the SMP scheduler optimizations for the 
arbitrary processor affinities in GSoC 2016.


Adding SMP support to a specific BSP for an architecture that already 
supports SMP (ARM, PowerPC, SPARC) is not enough for a GSoC project. 
Even adding SMP support to new architectures shouldn't be a big deal.


--
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: [PATCH 8/8] score: Replace watchdog handler implementation

[Sebastian Huber]

On 04/03/16 20:12, Joel Sherrill wrote:



On Fri, Mar 4, 2016 at 12:25 AM, Sebastian Huber 
> wrote:




On 03/03/16 23:44, Joel Sherrill wrote:


>
> "be placed on Red-Black Trees for set management."
copy-pasted
comment
> should be Chains?

Thanks, for spotting this.

>
> "watchdog is scheduled and a black node". ditto, black
should be red
> for the second one.

Oh, yes.

>
> _Watchdog_Ticks_from_seconds(): why is ticks =
seconds<<30 the right
> thing to do? Same for _Watchdog_Ticks_from_timespec(). I
am missing
> some assumption here, I guess. It might improve
readability to
provide
> a helper function for this.

Ok, sorry for the magic numbers.  2**30 == 1073741824
enough to
cope with 1e9 nanoseconds.  So, we have 2**34 seconds
available,
leading to a year 2514 problem.


That's pretty close to the 2^64 nanosecond limit as I recall.
So reasonable but
I suppose that should be very explicit somewhere in a comment.

Funny, before there was a wiki, we had a FAQ document which
had a section on
date/time overflow issues. We probably need a section in the
users manual with
the current truth on this:


https://docs.rtems.org/releases/rtemsdocs-4.6.4/share/rtems/html/FAQ/FAQ00100.html

We have multiple date/time and interval representations in the
score, classic and
POSIX APIs. It would be good to capture them again.


Yes, this is on my TODO list along with the year 2038 problem.


I thought we had discussed on newlib just changing time_t to 64 bits 
for RTEMS.

But clearly the code still has it as a long.

That seems to be the most straightforward solution.


I added a ticket for this:

https://devel.rtems.org/ticket/2624

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

Next step: Elimination of the Giant lock

[Sebastian Huber]

Hello,

my next task is the elimination of the Giant lock for proper SMP support.

https://devel.rtems.org/ticket/2555

I added some subtasks:

Use one lookup tree per-thread for the POSIX keys
https://devel.rtems.org/ticket/2625

Unify thread cancel/join and delete
https://devel.rtems.org/ticket/2626

Fix CPU time used for threads on SMP
https://devel.rtems.org/ticket/2627

Avoid home-grown condition variable implementation in the Classic Regions
https://devel.rtems.org/ticket/2628

Remove internal mutex objects
https://devel.rtems.org/ticket/2629

Protect time of day changes by a mutex
https://devel.rtems.org/ticket/2630

Use an ISR lock to protect the state of Classic Rate Monotonic objects
https://devel.rtems.org/ticket/2631

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