GSoC requirements and suggested projects

[Federica Di Lauro]

Hello everyone,
I'm at my 2 year undergraduate in Computer Science and I recently got
interested in embedded systems.
My current experience includes:
- Operatives Systems course
- Computer Architecture course (specifically studied MIPS32 architecture)
- Basic knowledge of C++, python, Java programming languages
- Arduino's projects and basic knowledge of electronics

I'd really like to contribute to this project and get to know first hand
about real time SO, could my current experience and completing the "hello
world" project be enough?
If so, could you suggest what projects would be adequate to my experience?

Thanks in advance for your help,
Federica Di Lauro
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Beagleboard BSP Framebuffer

[Vijay Kumar Banerjee]

On Mon, 11 Mar 2019 at 19:21, Gedare Bloom  wrote:

>
>
> On Sun, Mar 10, 2019 at 7:31 PM Joel Sherrill  wrote:
>
>> The MINIX license is BSD with advertising clause as I read it. That is
>> less preferable to a 2-paragraph BSD license that you are likely to find in
>> Freebase. Try there.
>>
>> The license is fine if you find nothing else. I assume Joel meant FreeBSD.
>
> Study the framebuffers in i386 and raspberrypi code bases.
>

Hello,

Thanks for the reference, I found the tda19988 driver in freebsd source.
Following the raspberrypi framebuffer, I have made a header file with the
basic functions to implement. The implementation will be using the
driver code from the freebsd.

What needs to be figured out next is how to use the driver code with rtems,
since the file uses a lot of header files from the freebsd source, how do we
go about integrating it with rtems? Is there any guide on using codes from
different projects into RTEMS?


>
>
>> It is usable in RTEMS though. We just try to avoid pushing the
>> advertising requirement
>>
>>
>>
>> On Sun, Mar 10, 2019, 12:47 PM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Mar 8, 2019, 12:35 AM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Hi,

 I was reading up and trying to figure out the steps to achieve this
 project. Here's
 what I came up with :

 1. BBB uses TD19988 HDMI Framer, so the first step is to get an HDMI
 output,
 read EDID info and set the videomode according to the info. After some
 searching,
 I found a driver in minix that might be helpful. Is the minix license
 compatible?
 (
 https://github.com/Stichting-MINIX-Research-Foundation/minix/blob/03ac74ede908465cc64c671bbd209e761dc765dc/LICENSE
 )

 2. Set the values of structs from fb.h
 3. Write the fb.c using the functions from framebuffer.h ( I'm taking
 the fb.c in raspberrypi
 as example and the bsp-howto as a reference text)

 The above list is just an outline and I intend to explore/understand it
 better and make a
 proposal out of it.

 Does this list make sense to you?

 What am I missing?

 I would really appreciate any remarks/comments or details you'd like to
 add, it will help me understand it better.

 ping :)
>>>

 Thanks,
 --vijay

>>> ___
>> 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: Beagleboard BSP Framebuffer

[Christian Mauderer]

Am 12.03.19 um 10:52 schrieb Vijay Kumar Banerjee:
> 
> 
> On Mon, 11 Mar 2019 at 19:21, Gedare Bloom  > wrote:
> 
> 
> 
> On Sun, Mar 10, 2019 at 7:31 PM Joel Sherrill  > wrote:
> 
> The MINIX license is BSD with advertising clause as I read it.
> That is less preferable to a 2-paragraph BSD license that you
> are likely to find in Freebase. Try there.
> 
> The license is fine if you find nothing else. I assume Joel meant
> FreeBSD.
> 
> Study the framebuffers in i386 and raspberrypi code bases.
> 
> 
> Hello,
> 
> Thanks for the reference, I found the tda19988 driver in freebsd source.
> Following the raspberrypi framebuffer, I have made a header file with the 
> basic functions to implement. The implementation will be using the 
> driver code from the freebsd. 
> 
> What needs to be figured out next is how to use the driver code with rtems,
> since the file uses a lot of header files from the freebsd source, how do we
> go about integrating it with rtems? Is there any guide on using codes from 
> different projects into RTEMS? 
>  
> 

Hello Vijay,

for FreeBSD we have the libbsd as an easy way to integrate sources and
keep them up to date. Although I don't think that we have a framebuffer
driver there yet I would expect that it is a good method for that too.

Best regards

Christian

>  
> 
> It is usable in RTEMS though. We just try to avoid pushing the
> advertising requirement
> 
> 
> 
> On Sun, Mar 10, 2019, 12:47 PM Vijay Kumar Banerjee
> mailto:vijaykumar9...@gmail.com>> wrote:
> 
> 
> 
> On Fri, Mar 8, 2019, 12:35 AM Vijay Kumar Banerjee
> mailto:vijaykumar9...@gmail.com>>
> wrote:
> 
> Hi,
> 
> I was reading up and trying to figure out the steps to
> achieve this project. Here's
> what I came up with :
> 
> 1. BBB uses TD19988 HDMI Framer, so the first step is to
> get an HDMI output,
> read EDID info and set the videomode according to the
> info. After some searching,
> I found a driver in minix that might be helpful. Is the
> minix license compatible? 
> 
> (https://github.com/Stichting-MINIX-Research-Foundation/minix/blob/03ac74ede908465cc64c671bbd209e761dc765dc/LICENSE)
> 
> 2. Set the values of structs from fb.h 
> 3. Write the fb.c using the functions from framebuffer.h
> ( I'm taking the fb.c in raspberrypi 
> as example and the bsp-howto as a reference text)
> 
> The above list is just an outline and I intend to
> explore/understand it better and make a
> proposal out of it.
> 
> Does this list make sense to you? 
> 
> What am I missing?
> 
> I would really appreciate any remarks/comments or
> details you'd like to add, it will help me understand it
> better.
> 
> ping :)
> 
> 
> Thanks,
> --vijay
> 
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

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: Query Regarding Old Projects, for GSoC 2019

[Vaibhav Gupta]

On Mon, Mar 11, 2019 at 3:24 AM Joel Sherrill  wrote:

>
>
> On Sun, Mar 10, 2019, 3:57 PM Chris Johns  wrote:
>
>> On 11/3/19 9:06 am, Joel Sherrill wrote:
>> > On Sun, Mar 10, 2019, 2:29 PM Chris Johns > > > wrote:
>> >
>> > On 6/3/19 10:23 pm, Amaan Cheval wrote:
>> > > I'm not sure if the project is open, but if it is, I'd be willing
>> to
>> > co-mentor.
>> >
>> > Thanks.
>> >
>> > >
>> > > On Wed, Mar 6, 2019, 2:45 PM Vaibhav Gupta <
>> vaibhavgupt...@gmail.com
>> > 
>> > > >>
>> wrote:
>> > >
>> > > I was exploring for more open projects and found the
>> following one.
>> > >
>> > > - Port V8 Javascript Engine :
>> > > https://devel.rtems.org/wiki/Developer/Projects/Open/V8
>> > >
>> > > Not much information is given about it and even the above
>> link was
>> > modified
>> > > in 2015. I want to know if the project is open for GSOC 2019?
>> > > If it is open, then It would be great to know if someone
>> would like to
>> > > mentor it. I would like to discuss further on it.
>> >
>> > I suggest you create a ticket for this project like the other GSoC
>> tickets we
>> > have and add some additional details ..
>> >
>> > - Please list the archs supported, this is viewable in the src tree.
>> > - Add something about needing Chromium's depot_tools. I see FreeBSD
>> is not
>> >   listed but chromium is available on FreeBSD.
>> > - Investigate the build system and if it is possible to
>> cross-compile.
>> >
>> > I'm a bit concerned that it may require things RTEMS does not have.
>>
>> If it cannot be cross-compiled it would be hard to maintain long term.
>>
>> > Does it mmap in ways we don't support?
>>
>> I also wondered. There is an abstraction in the POSIX platform code for
>> mmap so
>> a grep would let us know.
>>
>> > I doubt it forks new processes but that has to be answered.
>>
>> Yeap.
>>
>> > Some basic research plus an attempt to compile it for RTEMS with
>> > problem sections disabled is a good first step of any porting
>> evaluation.
>>
>> Yes.
>>
>> > FWIW I looked at porting the PDF viewer from chromium to RTEMS. Their
>> build
>> > system seemed quite complex.
>>
>> Firefox uses a js project held in github (
>> https://github.com/mozilla/pdf.js/).
>>
>
> +1
>
> Just to be clear, I am not discouraging this as a project. I just think it
> needs some homework to.make sure it is feasible.
>
I will check the things.

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

Re: Beagleboard BSP Framebuffer

[Vijay Kumar Banerjee]

On Tue, 12 Mar 2019 at 15:27, Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Am 12.03.19 um 10:52 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Mon, 11 Mar 2019 at 19:21, Gedare Bloom  > > wrote:
> >
> >
> >
> > On Sun, Mar 10, 2019 at 7:31 PM Joel Sherrill  > > wrote:
> >
> > The MINIX license is BSD with advertising clause as I read it.
> > That is less preferable to a 2-paragraph BSD license that you
> > are likely to find in Freebase. Try there.
> >
> > The license is fine if you find nothing else. I assume Joel meant
> > FreeBSD.
> >
> > Study the framebuffers in i386 and raspberrypi code bases.
> >
> >
> > Hello,
> >
> > Thanks for the reference, I found the tda19988 driver in freebsd source.
> > Following the raspberrypi framebuffer, I have made a header file with
> the
> > basic functions to implement. The implementation will be using the
> > driver code from the freebsd.
> >
> > What needs to be figured out next is how to use the driver code with
> rtems,
> > since the file uses a lot of header files from the freebsd source, how
> do we
> > go about integrating it with rtems? Is there any guide on using codes
> from
> > different projects into RTEMS?
> >
> >
>
> Hello Vijay,
>
> for FreeBSD we have the libbsd as an easy way to integrate sources and
> keep them up to date. Although I don't think that we have a framebuffer
> driver there yet I would expect that it is a good method for that too.
>
> Best regards
>
> Christian
>
> Hi

I cloned the rtems-libbsd and the framer driver is not there. I wonder if
adding
this drivers to libbsd is itself a meaty task. Do we need a ticket for this
?

Also, the driver uses i2c bus driver from FreeBSD source, I see that the
i2c driver
is nicely supported in the rtems beagle bsp, how to use the i2c module in
the bsp,
with the hdmi framer driver in libbsd ? (I'm a bit confused here :) )

> >
> >
> > It is usable in RTEMS though. We just try to avoid pushing the
> > advertising requirement
> >
> >
> >
> > On Sun, Mar 10, 2019, 12:47 PM Vijay Kumar Banerjee
> > mailto:vijaykumar9...@gmail.com>>
> wrote:
> >
> >
> >
> > On Fri, Mar 8, 2019, 12:35 AM Vijay Kumar Banerjee
> > mailto:vijaykumar9...@gmail.com>>
> > wrote:
> >
> > Hi,
> >
> > I was reading up and trying to figure out the steps to
> > achieve this project. Here's
> > what I came up with :
> >
> > 1. BBB uses TD19988 HDMI Framer, so the first step is to
> > get an HDMI output,
> > read EDID info and set the videomode according to the
> > info. After some searching,
> > I found a driver in minix that might be helpful. Is the
> > minix license compatible?
> > (
> https://github.com/Stichting-MINIX-Research-Foundation/minix/blob/03ac74ede908465cc64c671bbd209e761dc765dc/LICENSE
> )
> >
> > 2. Set the values of structs from fb.h
> > 3. Write the fb.c using the functions from framebuffer.h
> > ( I'm taking the fb.c in raspberrypi
> > as example and the bsp-howto as a reference text)
> >
> > The above list is just an outline and I intend to
> > explore/understand it better and make a
> > proposal out of it.
> >
> > Does this list make sense to you?
> >
> > What am I missing?
> >
> > I would really appreciate any remarks/comments or
> > details you'd like to add, it will help me understand it
> > better.
> >
> > ping :)
> >
> >
> > Thanks,
> > --vijay
> >
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> 
> 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: Beagleboard BSP Framebuffer

[Christian Mauderer]

Am 12.03.19 um 11:35 schrieb Vijay Kumar Banerjee:
> 
> 
> 
> On Tue, 12 Mar 2019 at 15:27, Christian Mauderer
>  > wrote:
> 
> Am 12.03.19 um 10:52 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Mon, 11 Mar 2019 at 19:21, Gedare Bloom  
> > >> wrote:
> >
> >
> >
> >     On Sun, Mar 10, 2019 at 7:31 PM Joel Sherrill  
> >     >> wrote:
> >
> >         The MINIX license is BSD with advertising clause as I read it.
> >         That is less preferable to a 2-paragraph BSD license that you
> >         are likely to find in Freebase. Try there.
> >
> >     The license is fine if you find nothing else. I assume Joel meant
> >     FreeBSD.
> >
> >     Study the framebuffers in i386 and raspberrypi code bases.
> >
> >
> > Hello,
> >
> > Thanks for the reference, I found the tda19988 driver in
> freebsd source.
> > Following the raspberrypi framebuffer, I have made a header file
> with the 
> > basic functions to implement. The implementation will be using the 
> > driver code from the freebsd. 
> >
> > What needs to be figured out next is how to use the driver code
> with rtems,
> > since the file uses a lot of header files from the freebsd source,
> how do we
> > go about integrating it with rtems? Is there any guide on using
> codes from 
> > different projects into RTEMS? 
> >  
> >
> 
> Hello Vijay,
> 
> for FreeBSD we have the libbsd as an easy way to integrate sources and
> keep them up to date. Although I don't think that we have a framebuffer
> driver there yet I would expect that it is a good method for that too.
> 
> Best regards
> 
> Christian
> 
> Hi
> 
> I cloned the rtems-libbsd and the framer driver is not there. I wonder
> if adding
> this drivers to libbsd is itself a meaty task. Do we need a ticket for
> this ?

The files are copied between FreeBSD and libbsd using a script.
Basically you have to add the files you need to a (new) module in
libbsd.py. After that you can copy files with the freebsd-to-rtems.py.
Please take a look at CONTRIBUTING.md in the rtems-libbsd repo on how to
use the script.

> 
> Also, the driver uses i2c bus driver from FreeBSD source, I see that the
> i2c driver
> is nicely supported in the rtems beagle bsp, how to use the i2c module
> in the bsp,
> with the hdmi framer driver in libbsd ? (I'm a bit confused here :) )
> 

Most likely there will be adaptions necessary here. Either you have to
replace the BSPs driver with the one from FreeBSD or (the method that I
would suggest) you have to isolate the calls in the FreeBSD framebuffer
driver and replace them with RTEMS calls. With some luck, you can just
overwrite some functions for that. But that is one of the points that
would need a more thorough look.

Besides I2C you should have a look at which other subsystems are used.
Every subsystem that isn't ported yet can be more or less work depending
on the interface. Some might can be ported together with the driver
others might have to be replaced by RTEMS versions.

> >      
> >
> >         It is usable in RTEMS though. We just try to avoid pushing the
> >         advertising requirement
> >
> >
> >
> >         On Sun, Mar 10, 2019, 12:47 PM Vijay Kumar Banerjee
> >            >> wrote:
> >
> >
> >
> >             On Fri, Mar 8, 2019, 12:35 AM Vijay Kumar Banerjee
> >                >>
> >             wrote:
> >
> >                 Hi,
> >
> >                 I was reading up and trying to figure out the steps to
> >                 achieve this project. Here's
> >                 what I came up with :
> >
> >                 1. BBB uses TD19988 HDMI Framer, so the first step
> is to
> >                 get an HDMI output,
> >                 read EDID info and set the videomode according to the
> >                 info. After some searching,
> >                 I found a driver in minix that might be helpful.
> Is the
> >                 minix license compatible? 
> >               
>  
> (https://github.com/Stichting-MINIX-Research-Foundation/minix/blob/03ac74ede908465cc64c671bbd209e761dc765dc/LICENSE)
> >
> >                 2. Set the values of structs from fb.h 
> >                 3. Write the fb.c using the functions from
> framebuffer.h
> >                 ( I'm taking the fb.c in raspberrypi 
> >                 as example and the bsp

Re: GSoC requirements and suggested projects

[Gedare Bloom]

Hello Federica,

Welcome! We have a wide variety of projects that cover a range of
programming skills and languages but mostly involves either assembly, C, or
Python, and some other projects may use other languages. It seems you have
the basic skills needed to try to undertake most of the projects. Have a
look through https://devel.rtems.org/wiki/Developer/OpenProjects and see if
anything catches your particular interest. I think there are still a few
projects that may be added to the list, so keep checking back or ask
around. (I think Chris Johns has a project idea related to developing some
open-source complex application that he will describe in next few days as
"Application Suite" project.)

The first step for any student who wants to work with us is to complete the
"hello world" project. Email your proof to me and to j...@rtems.org. Then,
depending on your choice of project you will propose, we may also set some
other tasks for you to complete afterward.

Gedare

On Tue, Mar 12, 2019 at 5:39 AM Federica Di Lauro <
federicadilauro1...@gmail.com> wrote:

> Hello everyone,
> I'm at my 2 year undergraduate in Computer Science and I recently got
> interested in embedded systems.
> My current experience includes:
> - Operatives Systems course
> - Computer Architecture course (specifically studied MIPS32 architecture)
> - Basic knowledge of C++, python, Java programming languages
> - Arduino's projects and basic knowledge of electronics
>
> I'd really like to contribute to this project and get to know first hand
> about real time SO, could my current experience and completing the "hello
> world" project be enough?
> If so, could you suggest what projects would be adequate to my experience?
>
> Thanks in advance for your help,
> Federica Di Lauro
> ___
> 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: Beagleboard BSP Framebuffer

[Gedare Bloom]

On Tue, Mar 12, 2019 at 6:59 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Am 12.03.19 um 11:35 schrieb Vijay Kumar Banerjee:
> >
> >
> >
> > On Tue, 12 Mar 2019 at 15:27, Christian Mauderer
> >  > > wrote:
> >
> > Am 12.03.19 um 10:52 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > > On Mon, 11 Mar 2019 at 19:21, Gedare Bloom  > 
> > > >> wrote:
> > >
> > >
> > >
> > > On Sun, Mar 10, 2019 at 7:31 PM Joel Sherrill  > 
> > > >> wrote:
> > >
> > > The MINIX license is BSD with advertising clause as I read
> it.
> > > That is less preferable to a 2-paragraph BSD license that
> you
> > > are likely to find in Freebase. Try there.
> > >
> > > The license is fine if you find nothing else. I assume Joel
> meant
> > > FreeBSD.
> > >
> > > Study the framebuffers in i386 and raspberrypi code bases.
> > >
> > >
> > > Hello,
> > >
> > > Thanks for the reference, I found the tda19988 driver in
> > freebsd source.
> > > Following the raspberrypi framebuffer, I have made a header file
> > with the
> > > basic functions to implement. The implementation will be using the
> > > driver code from the freebsd.
> > >
> > > What needs to be figured out next is how to use the driver code
> > with rtems,
> > > since the file uses a lot of header files from the freebsd source,
> > how do we
> > > go about integrating it with rtems? Is there any guide on using
> > codes from
> > > different projects into RTEMS?
> > >
> > >
> >
> > Hello Vijay,
> >
> > for FreeBSD we have the libbsd as an easy way to integrate sources
> and
> > keep them up to date. Although I don't think that we have a
> framebuffer
> > driver there yet I would expect that it is a good method for that
> too.
> >
> > Best regards
> >
> > Christian
> >
> > Hi
> >
> > I cloned the rtems-libbsd and the framer driver is not there. I wonder
> > if adding
> > this drivers to libbsd is itself a meaty task. Do we need a ticket for
> > this ?
>
> The files are copied between FreeBSD and libbsd using a script.
> Basically you have to add the files you need to a (new) module in
> libbsd.py. After that you can copy files with the freebsd-to-rtems.py.
> Please take a look at CONTRIBUTING.md in the rtems-libbsd repo on how to
> use the script.
>
>
Bringing the framebuffer codebase into libbsd from FreeBSD, and then
demonstrating it on a target (e.g., BBB), would make a solid GSoC.

>
> > Also, the driver uses i2c bus driver from FreeBSD source, I see that the
> > i2c driver
> > is nicely supported in the rtems beagle bsp, how to use the i2c module
> > in the bsp,
> > with the hdmi framer driver in libbsd ? (I'm a bit confused here :) )
> >
>
> Most likely there will be adaptions necessary here. Either you have to
> replace the BSPs driver with the one from FreeBSD or (the method that I
> would suggest) you have to isolate the calls in the FreeBSD framebuffer
> driver and replace them with RTEMS calls. With some luck, you can just
> overwrite some functions for that. But that is one of the points that
> would need a more thorough look.
>
> Besides I2C you should have a look at which other subsystems are used.
> Every subsystem that isn't ported yet can be more or less work depending
> on the interface. Some might can be ported together with the driver
> others might have to be replaced by RTEMS versions.
>
>
+1

And reach out to others who have done some similar work in the past. We
have got at least a few students in recent history who added more mud to
libbsd. :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-test] sparc/erc32: RTEMS_NETWORKING, RTEMS_POSIX_API: Passed:583 Failed:1 Timeout:1 Invalid:0 Wrong:0

[Gedare Bloom]

Is it feasible to triage the failures for out-of-memory?

On Sat, Mar 9, 2019 at 12:22 PM Joel Sherrill  wrote:

>
>
> On Sat, Mar 9, 2019, 11:01 AM Chris Johns  wrote:
>
>> On 10/3/19 2:18 am, j...@rtems.org wrote:
>> > Testing time : 0:03:48.073542
>> > Average test time: 0:00:00.384610
>> >
>> > Host
>> > 
>> > Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core
>> (Linux rtbf64c.rtems.com 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14
>> 21:49:04 UTC 2018 x86_64 x86_64)
>> >
>> > Configuration
>> > =
>> > Version: 5.0.0.08ef50ff6a3b712cef5bcdeb78c531bc6a3e0f9e
>> > Build  : RTEMS_NETWORKING,RTEMS_POSIX_API
>> > Tools  : 7.4.0 20181206 (RTEMS 5, RSB
>> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
>> >
>> > Summary
>> > ===
>> >
>> > Passed:583
>> > Failed:  1
>> > User Input:  5
>> > Expected Fail:   0
>> > Indeterminate:   0
>> > Benchmark:   3
>> > Timeout: 1
>> > Invalid: 0
>> > Wrong Version:   0
>> > Wrong Build: 0
>> > Wrong Tools: 0
>> > --
>> > Total: 593
>> >
>> > Failures:
>> >  dl09.exe
>>
>> This test needs a lot of memory to run. It loads modules 64K apart to
>> test the
>> trampolines. I think there is an option to increase the memory of this
>> simulator
>>  but I am not sure.
>>
>> I am wondering if we need a file called 'disable
>> -large-memory-tests.tcfg' with
>> dl09.exe excluded.
>>
>
> Some of the tests are known to be deliberate memory pigs. This would be
> good. Commonly excluded tests would be obvious candidates.
>
> I need to investigate the impact of enabling debug and profiling on the
> failures. All built for me without those enabled.
>
>>
>> Chris
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] shell: Correct argument order of `mfill`

[Gedare Bloom]

Tickets opened for 4.11 and 4.10:
https://devel.rtems.org/ticket/3722
https://devel.rtems.org/ticket/3723

Please provide a backported patch with commit message to close these
tickets. (Any aspiring GSoC students are welcome to do the same!)

Gedare

On Fri, Mar 8, 2019 at 1:41 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 01/03/2019 19:21, Jonathan Brandmeyer wrote:
> > ---
> >   cpukit/libmisc/shell/main_mfill.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/libmisc/shell/main_mfill.c
> b/cpukit/libmisc/shell/main_mfill.c
> > index d8e2fcf74c..47a55d3a2f 100644
> > --- a/cpukit/libmisc/shell/main_mfill.c
> > +++ b/cpukit/libmisc/shell/main_mfill.c
> > @@ -60,7 +60,7 @@ static int rtems_shell_main_mfill(
> > /*
> >  *  Now fill the memory.
> >  */
> > -  memset(addr, size, value);
> > +  memset(addr, value, size);
> >
> > return 0;
> >   }
>
> Fixing this bug on the master is easy, but the bug is there in all RTEMS
> versions since 2007. If you fix this properly means you need tickets for
> a couple of RTEMS versions and an individual commit message
> corresponding to each ticket. The administration overhead is huge. I
> just fixed it for RTEMS 5.1:
>
> https://devel.rtems.org/ticket/3720
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-test] sparc/erc32: RTEMS_NETWORKING, RTEMS_POSIX_API: Passed:583 Failed:1 Timeout:1 Invalid:0 Wrong:0

[Joel Sherrill]

My plan once all the BSPs are building again with the tester is to see
which are disabled the most across the set of BSPs using xxx-testsuite.tcfg
files. That should be be the set of tests which are candidates for review
on how to shrink them.

Chris and I chatted about this and my hope is that every psx or sp test
(including tm's) can be reworked, split, resources lowered, etc so it can
work even on low memory targets.

File system tests may be candidates for a way to specify the size of the
RAM disk similar to how many tm tests have OPERATION_COUNT.

Some tests like fileio will never shrink enough.

Reviewing the .tcfg files for common tests disabled for memory use is the
first step.

--joel

On Tue, Mar 12, 2019 at 9:43 AM Gedare Bloom  wrote:

> Is it feasible to triage the failures for out-of-memory?
>
> On Sat, Mar 9, 2019 at 12:22 PM Joel Sherrill  wrote:
>
>>
>>
>> On Sat, Mar 9, 2019, 11:01 AM Chris Johns  wrote:
>>
>>> On 10/3/19 2:18 am, j...@rtems.org wrote:
>>> > Testing time : 0:03:48.073542
>>> > Average test time: 0:00:00.384610
>>> >
>>> > Host
>>> > 
>>> > Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core
>>> (Linux rtbf64c.rtems.com 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14
>>> 21:49:04 UTC 2018 x86_64 x86_64)
>>> >
>>> > Configuration
>>> > =
>>> > Version: 5.0.0.08ef50ff6a3b712cef5bcdeb78c531bc6a3e0f9e
>>> > Build  : RTEMS_NETWORKING,RTEMS_POSIX_API
>>> > Tools  : 7.4.0 20181206 (RTEMS 5, RSB
>>> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
>>> >
>>> > Summary
>>> > ===
>>> >
>>> > Passed:583
>>> > Failed:  1
>>> > User Input:  5
>>> > Expected Fail:   0
>>> > Indeterminate:   0
>>> > Benchmark:   3
>>> > Timeout: 1
>>> > Invalid: 0
>>> > Wrong Version:   0
>>> > Wrong Build: 0
>>> > Wrong Tools: 0
>>> > --
>>> > Total: 593
>>> >
>>> > Failures:
>>> >  dl09.exe
>>>
>>> This test needs a lot of memory to run. It loads modules 64K apart to
>>> test the
>>> trampolines. I think there is an option to increase the memory of this
>>> simulator
>>>  but I am not sure.
>>>
>>> I am wondering if we need a file called 'disable
>>> -large-memory-tests.tcfg' with
>>> dl09.exe excluded.
>>>
>>
>> Some of the tests are known to be deliberate memory pigs. This would be
>> good. Commonly excluded tests would be obvious candidates.
>>
>> I need to investigate the impact of enabling debug and profiling on the
>> failures. All built for me without those enabled.
>>
>>>
>>> Chris
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Help Needed with arm/lm4f120 tcfg Check

[Joel Sherrill]

Hi

I have a puzzling issue after updating the lm4f120 tcfg file. I added
cxx_iostream but it still tries to build it and fails.

Can anyone spot why this one exclude is not working?

Thanks.

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

Fwd: Coverity Scan: Analysis completed for RTEMS

[Joel Sherrill]

I don't think the build list has white listed the address these come from
so passing along there are new results.

-- Forwarded message -
From: 
Date: Tue, Mar 12, 2019 at 12:23 PM
Subject: Coverity Scan: Analysis completed for RTEMS
To: 



Your request for analysis of RTEMS has been completed successfully.
The results are available at
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRborMTckpAaQ-2BnaCxwyfyxV0FpOV5Q8wFmadmct-2BCFX1g-3D-3D_f7ckBxvUHj9w7T7pNhDOXvEGtshuaY3kMkYUMyu5N-2BD-2FC1093WT-2F8Ryve9Al0f-2BdNojAzL7i8tTwinaIJTpiviEmAgBfmswyKboadtHkCgXTYKW-2FqAHTspP09WehP6aS411Q0UEGtJiRHXI5tUawWXUq6W7Xaa8D8adcg7BSJc7GkTHgapr-2FC2KAuED50r-2Bb9fIgPOlUP-2FXj4BlW-2B1uLeVjGd3aBoZlwTVqAZ3wTyZk-3D

Build ID: 247308

Analysis Summary:
   New defects found: 0
   Defects eliminated: 0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help Needed with arm/lm4f120 tcfg Check

[Chris Johns]

On 13/3/19 3:24 am, Joel Sherrill wrote:
> 
> I have a puzzling issue after updating the lm4f120 tcfg file. I added
> cxx_iostream but it still tries to build it and fails.
> 
> Can anyone spot why this one exclude is not working?

What does configure show for this sample app?

Does the samples Makefile.am have the needed checks?

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

Re: Fwd: Coverity Scan: Analysis completed for RTEMS

[Chris Johns]

On 13/3/19 7:18 am, Joel Sherrill wrote:
> I don't think the build list has white listed the address these come from so
> passing along there are new results.

Fixed, and sorry about forgetting to sort this out.

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

Re: Beagleboard BSP Framebuffer

[Chris Johns]

On 13/3/19 1:41 am, Gedare Bloom wrote:
> Bringing the framebuffer codebase into libbsd from FreeBSD, and then
> demonstrating it on a target (e.g., BBB), would make a solid GSoC.

+1

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

Re: Fwd: Coverity Scan: Analysis completed for RTEMS

[Joel Sherrill]

No problem. When I run it next time perhaps it will get through. :)

--joel

On Tue, Mar 12, 2019 at 4:42 PM Chris Johns  wrote:

> On 13/3/19 7:18 am, Joel Sherrill wrote:
> > I don't think the build list has white listed the address these come
> from so
> > passing along there are new results.
>
> Fixed, and sorry about forgetting to sort this out.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] shell: Correct argument order of `mfill`

[Jonathan Brandmeyer]

Close #3723.

(cherry picked from commit 2e8a66d13f04015c0024a084578f720ceb15ea00)
---
 cpukit/libmisc/shell/main_mfill.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_mfill.c 
b/cpukit/libmisc/shell/main_mfill.c
index ecbaec4878..c86e2b6a25 100644
--- a/cpukit/libmisc/shell/main_mfill.c
+++ b/cpukit/libmisc/shell/main_mfill.c
@@ -62,7 +62,7 @@ int rtems_shell_main_mfill(
   /*
*  Now fill the memory.
*/
-  memset(addr, size, value);
+  memset(addr, value, size);
 
   return 0;
 }
-- 
2.11.0

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

[PATCH] shell: Correct argument order of `mfill`

[Jonathan Brandmeyer]

Close #3722.

(cherry picked from commit 2e8a66d13f04015c0024a084578f720ceb15ea00)
---
 cpukit/libmisc/shell/main_mfill.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_mfill.c 
b/cpukit/libmisc/shell/main_mfill.c
index d8e2fcf74c..47a55d3a2f 100644
--- a/cpukit/libmisc/shell/main_mfill.c
+++ b/cpukit/libmisc/shell/main_mfill.c
@@ -60,7 +60,7 @@ static int rtems_shell_main_mfill(
   /*
*  Now fill the memory.
*/
-  memset(addr, size, value);
+  memset(addr, value, size);
 
   return 0;
 }
-- 
2.11.0

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

Re: [PATCH] shell: Correct argument order of `mfill`

[Jonathan Brandmeyer]

I apologize for the vagueness - It isn't clear which one is supposed
to go against which branch.  The only distinguishing feature is the
affected ticket number.  ticket 3723 is against the 4.10 branch, while
3722 is against the 4.11 branch.

On Tue, Mar 12, 2019 at 9:04 PM Jonathan Brandmeyer
 wrote:
>
> Close #3722.
>
> (cherry picked from commit 2e8a66d13f04015c0024a084578f720ceb15ea00)
> ---
>  cpukit/libmisc/shell/main_mfill.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/libmisc/shell/main_mfill.c 
> b/cpukit/libmisc/shell/main_mfill.c
> index d8e2fcf74c..47a55d3a2f 100644
> --- a/cpukit/libmisc/shell/main_mfill.c
> +++ b/cpukit/libmisc/shell/main_mfill.c
> @@ -60,7 +60,7 @@ static int rtems_shell_main_mfill(
>/*
> *  Now fill the memory.
> */
> -  memset(addr, size, value);
> +  memset(addr, value, size);
>
>return 0;
>  }
> --
> 2.11.0
>


-- 
Jonathan Brandmeyer
Engineering Director
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requirement Management tools

[Sebastian Huber]

Hello,

I added a ticket and a wiki page for this topic:

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

https://devel.rtems.org/wiki/Developer/RequirementsEngineering

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

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

[Sebastian Huber]

On 28/02/2019 15:52, Sebastian Huber wrote:

Hello,

we agreed to use @param for function parameter documentation:

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



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

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


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

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

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

?

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


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




In ticket

http://devel.rtems.org/ticket/3721

Jens Schweikhardt proposed the following:

"1) only pointer parameters are annotated (since scalars are [in] by
 language definition)
2) [in] indicates that the pointer must point to an initialized object (it
 may be dereferenced by the directive)
3) [out] indicates that the object pointed to may be written by the
 directive
4) [inout] If both 2) and 3) apply."

I think these are good guidelines. What about annotation of const pointers? 
Should they get the [in] annotation which is somewhat redundant?

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