Re: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

2020-03-18 Thread Chris Johns 
On 19/3/20 7:06 am, Christian Mauderer wrote:
> Hello Amar,
> 
> On 18/03/2020 19:24, Amar Takhar wrote:
>> The only one I would like to propose is the 80 character limit.  This should 
>> be 
>> moved to something more reasonable such as 120.
>>
>> Code comments should remain below 80 however.
>>
> 
> I'm not a big fan of long lines (reason further below) but I won't block
> it either. But what I think is really a bad idea is to have different
> rules for different parts of the code.

And different parts of the project.

> I think we will have a really hard time to set up tools like formatters
> or pylint to check and use these rules. I think setting a line length to
> 120 should be easy to possible for nearly any tool. But I expect that
> setting it to 120 for code and 80 for comments can be _very_ difficult
> depending on the tool.
> 
> 
> PS: Reason for me being not a fan of long lines: While programming I
> often use a split window. In that configuration my editor can show 112
> columns in each window on my current screen. That fits well for nearly
> all code that follows the 80 character convention. But for example your
> proposed length of 120 the code will lead to either a smaller font, a
> lot of random line breaks done by the editor or to loosing one window.
> Again: It's not a strong opinion and I'll accept 120 too. But expect
> that some others have stronger opinions about 80 characters.

I run everything in text mode under tmux and in Emacs I split vertically and
variable length is painful and prefer we settle on 80.

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

Re: Improve the Raspberry Pi BSP

2020-03-18 Thread Denil Verghese 
I will create a new thread soon.
Thank you
Denil.

On Wed, 18 Mar, 2020, 11:56 PM Gedare Bloom,  wrote:

> On Wed, Mar 18, 2020 at 11:12 AM Denil Verghese 
> wrote:
> >
> >
> >
> > On Wed, 18 Mar, 2020, 9:03 PM Gedare Bloom,  wrote:
> >>
> >> On Wed, Mar 18, 2020 at 8:41 AM Denil Verghese 
> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, 18 Mar, 2020, 7:43 PM Alan Cudmore, 
> wrote:
> >> >>
> >> >> This is probably not a comprehensive list, but currently all models
> except the Pi 4 are working thanks to Niteesh’s work on the uart for the Pi
> 3 and Zero W.
> >> >>
> >> >>
> >> >>
> >> >> I believe there is some support for GPIO, and I2C.
> >> >>
> >> >> I’m not sure about the state of SPI.
> >> >>
> >> >> There is also support for the graphics console, but I don’t know
> that state of that with the various Pi models as well.
> >> >>
> >> >>
> >> >>
> >> >> Finally, there was an effort to port libbsd to the Pi, but I don’t
> think it was completed.
> >> >>
> >> >>
> >> >>
> >> >> From what I know the Pi 4 is not supported at all yet.
> >> >>
> >> >>
> >> >>
> >> >> So there is still a lot of work to do, maybe too much for a single
> GSoC project.
> >> >>
> >> >> Maybe try to narrow the focus on something like:
> >> >>
> >> >> Libbsd and SMP support for the Raspberry Pi 3?
> >> >
> >> > That is a great idea. Thanks for the suggestion.
> >> >
> >> > Will this will be more useful than my current proposal?( Which is
> based on Release note generator and code formatter.).
> >> >
> >>
> >> They are two very different projects. You can continue to flesh out
> >> both of them if you like, although we prefer a student to focus on one
> >> proposal if you are not certain then it will be fine
> >
> >
> > I can't focus on two proposals at the same time. My intention was to
> change my proposal if this makes a great contribution and will be
> interesting for mentors.
> >>
> >>
> >> As before, to do the RPi projects you must have and demonstrate that
> >> you can run RPi at least with baremetal if not with RTEMS.
> >>
> >> I don't know if we'll have the bandwidth for multiple projects
> >> involving libbsd, while the release note generator/formatter may be
> >> somewhat easier to mentor. I haven't heard too much enthusiasm yet,
> >> but if you write a strong proposal you may convince a mentor :)
> >
> >
> > If that's the case, I will focus on my current proposal and will make it
> strong as I can:). I need some clarification on how can I do formatting
> part. Maybe start a new thread??
>
> Yes, start a new thread.
>
> In general, projects that improve "infrastructure" are better than
> individual BSPs, but we do value both. We like to have a mix really.
> In your case, I think it will be better to focus on your current
> trajectory and try to make it the best you can.
>
> >>
> >>
> >> >> I have been learning how to use RTEMS and rtems-libbsd on the
> beaglebone black lately. Having that capability along with SMP on the Pi 3
> would be great.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Alan
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> From: Joel Sherrill
> >> >> Sent: Tuesday, March 17, 2020 11:19 PM
> >> >> To: Denil Verghese
> >> >> Cc: rtems-de...@rtems.org
> >> >> Subject: Re: Improve the Raspberry Pi BSP
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sun, Mar 15, 2020, 10:20 PM Denil Verghese 
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >>I would like to know whether the projects shown in this
> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the
> ideas are yet to implement I could work on it.
> >> >>
> >> >>
> >> >>
> >> >> I think there is plenty left. I am not authoritative on this though.
> >> >>
> >> >>
> >> >>
> >> >> I think getting Pi3/4 support still has work.
> >> >>
> >> >>
> >> >>
> >> >> I think USB plus Ethernet.
> >> >>
> >> >>
> >> >>
> >> >> I recall the graphics work was done on the Beagle.
> >> >>
> >> >>
> >> >>
> >> >> I am not even sure that Pi2 qemu support has been worked through
> completely.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> It will more interesting to work those projects rather than my
> currently selected project which is Release Note Generator.
> >> >>
> >> >> Meanwhile I have uploaded my draft proposal which is ongoing self
> revision.
> >> >>
> >> >>
> >> >>
> >> >> Thank you
> >> >>
> >> >> Denil C Verghese
> >> >>
> >> >>
> >> >>
> >> >> ___
> >> >> 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: Improve the Raspberry Pi BSP

2020-03-18 Thread Denil Verghese 
On Wed, 18 Mar, 2020, 10:55 PM Alan Cudmore,  wrote:

> While, I would like to see additional improvement to the Raspberry Pi
> BSPs, I don't think I have the time to serve as a mentor this year. I
> am sure I could not keep up with the daily communication that is
> required for a successful GSoC project.
> Alan
>
I understand. :)
Denil

>
>
> On Wed, Mar 18, 2020 at 1:12 PM Denil Verghese  wrote:
> >
> >
> >
> > On Wed, 18 Mar, 2020, 9:03 PM Gedare Bloom,  wrote:
> >>
> >> On Wed, Mar 18, 2020 at 8:41 AM Denil Verghese 
> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, 18 Mar, 2020, 7:43 PM Alan Cudmore, 
> wrote:
> >> >>
> >> >> This is probably not a comprehensive list, but currently all models
> except the Pi 4 are working thanks to Niteesh’s work on the uart for the Pi
> 3 and Zero W.
> >> >>
> >> >>
> >> >>
> >> >> I believe there is some support for GPIO, and I2C.
> >> >>
> >> >> I’m not sure about the state of SPI.
> >> >>
> >> >> There is also support for the graphics console, but I don’t know
> that state of that with the various Pi models as well.
> >> >>
> >> >>
> >> >>
> >> >> Finally, there was an effort to port libbsd to the Pi, but I don’t
> think it was completed.
> >> >>
> >> >>
> >> >>
> >> >> From what I know the Pi 4 is not supported at all yet.
> >> >>
> >> >>
> >> >>
> >> >> So there is still a lot of work to do, maybe too much for a single
> GSoC project.
> >> >>
> >> >> Maybe try to narrow the focus on something like:
> >> >>
> >> >> Libbsd and SMP support for the Raspberry Pi 3?
> >> >
> >> > That is a great idea. Thanks for the suggestion.
> >> >
> >> > Will this will be more useful than my current proposal?( Which is
> based on Release note generator and code formatter.).
> >> >
> >>
> >> They are two very different projects. You can continue to flesh out
> >> both of them if you like, although we prefer a student to focus on one
> >> proposal if you are not certain then it will be fine
> >
> >
> > I can't focus on two proposals at the same time. My intention was to
> change my proposal if this makes a great contribution and will be
> interesting for mentors.
> >>
> >>
> >> As before, to do the RPi projects you must have and demonstrate that
> >> you can run RPi at least with baremetal if not with RTEMS.
> >>
> >> I don't know if we'll have the bandwidth for multiple projects
> >> involving libbsd, while the release note generator/formatter may be
> >> somewhat easier to mentor. I haven't heard too much enthusiasm yet,
> >> but if you write a strong proposal you may convince a mentor :)
> >
> >
> > If that's the case, I will focus on my current proposal and will make it
> strong as I can:). I need some clarification on how can I do formatting
> part. Maybe start a new thread??
> >>
> >>
> >> >> I have been learning how to use RTEMS and rtems-libbsd on the
> beaglebone black lately. Having that capability along with SMP on the Pi 3
> would be great.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Alan
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> From: Joel Sherrill
> >> >> Sent: Tuesday, March 17, 2020 11:19 PM
> >> >> To: Denil Verghese
> >> >> Cc: rtems-de...@rtems.org
> >> >> Subject: Re: Improve the Raspberry Pi BSP
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sun, Mar 15, 2020, 10:20 PM Denil Verghese 
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >>I would like to know whether the projects shown in this
> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the
> ideas are yet to implement I could work on it.
> >> >>
> >> >>
> >> >>
> >> >> I think there is plenty left. I am not authoritative on this though.
> >> >>
> >> >>
> >> >>
> >> >> I think getting Pi3/4 support still has work.
> >> >>
> >> >>
> >> >>
> >> >> I think USB plus Ethernet.
> >> >>
> >> >>
> >> >>
> >> >> I recall the graphics work was done on the Beagle.
> >> >>
> >> >>
> >> >>
> >> >> I am not even sure that Pi2 qemu support has been worked through
> completely.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> It will more interesting to work those projects rather than my
> currently selected project which is Release Note Generator.
> >> >>
> >> >> Meanwhile I have uploaded my draft proposal which is ongoing self
> revision.
> >> >>
> >> >>
> >> >>
> >> >> Thank you
> >> >>
> >> >> Denil C Verghese
> >> >>
> >> >>
> >> >>
> >> >> ___
> >> >> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-examples PATCH v2 1/2] Update rtems_waf

2020-03-18 Thread Chris Johns 
Both these patches are fine to push. Vijay, please push once your access has
been sorted out.

I should highlight I am OK with the approach taken in the examples repo, that is
not building something if the dependent tool is not found rather than raising an
error.

Thanks
Chris

On 18/3/20 8:43 pm, Vijay Kumar Banerjee wrote:
> ---
>  rtems_waf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rtems_waf b/rtems_waf
> index e7a75df..ad08908 16
> --- a/rtems_waf
> +++ b/rtems_waf
> @@ -1 +1 @@
> -Subproject commit e7a75df6531beec1c1b0d18fcaf2cfce7693920c
> +Subproject commit ad08908c452c6a9bbb3bf7bbbcc9fc03fe46cc7f
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020 memory protection project initial draft.

2020-03-18 Thread Utkarsh Rai 
Oh sorry, I have rectified that now.

On Wed, Mar 18, 2020 at 11:34 PM Gedare Bloom  wrote:

> Provide edit access so I can add comments / suggestions.
>
> On Tue, Mar 17, 2020 at 11:41 PM Utkarsh Rai 
> wrote:
>
>> Hi, I have prepared my initial draft for the project and look forward to
>> your feedback on the same.
>> I have also added this to the GSoC tracking page.
>>  GSOC2020_ Rai_Memory_Protection
>> 
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Successfully built EPICS 7 with RTEMS 5 for mvme6100

2020-03-18 Thread Joel Sherrill 
On Wed, Mar 18, 2020 at 2:38 PM Heinz Junkes 
wrote:

> Hello, Mritunjay,
>
> I will contact you tomorrow during the day (European time).  We have here
> institute closings because of Corona Virus etc..
>
> It's great that you've come this far. I can also provide you with an
> MVME6100 remotely so you can get a feeling for target development.
> Yes, I have also started development of libbsd and the MVME2500. More on
> this tomorrow.
>
> But the first, important step in this proposal would be to get EPICS7
> running with RTEMS5 on e.g. qemu, ideally on i386?
> I think I had some problems with the psim in the past. Unfortunately I
> don't know exactly what it is anymore.
> More tomorrow.
>

We have had good experiences with RTEMS+libbsd with the Qemu ARM Zynq.
We have been able to telnet to the RTEMS target from Linux and use the RTEMS
NFS client to mount Linux files plus dynamic loading works. Personally I
would
start with that since the goal is EPICS not fixing a BSP. :)

My second would be Qemu i386 pc386 but I don't know the status of libbsd on
pc386 at the moment. This should work the same as the Zynq qemu but I
personally don't know. Heinz.. do you have recent experience on it?

Gedare is correct though. Work on the proposal next. You are far enough
along
with what you have done to been into debugging and integrating on a real
embedded target.


> Many greetings and stay healthy,
>

Everything here is closed with teleworking. Two confirmed cases here
in town so far but one was at NASA Marshall and the other was a
pharmacist at the Army clinic. I expect we will have more in the near
future.

--joel


> Heinz
>
> --
> Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
> Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
> Faradayweg 4-6| VC: 102220181...@bjn.vc
> D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
>
> --
>
> > On 18. Mar 2020, at 19:56, Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
> >
> > Thank you so much for the feedback. I will research more on the targets
> that can run with the simulator and would like to tell you that looking at
> https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0, I feel that
> @Heinz Junkes is already working on libbsd for RTEMS-MVME2500 and I would
> like to hear more from him to get some clarity on what can be done. Being a
> beginner, it's really a great welcome to the world of cross-compiler
> development and testing. :) Thank you for always helping me out!
> >
> > On Wed, Mar 18, 2020 at 11:51 PM Gedare Bloom  wrote:
> > On Wed, Mar 18, 2020 at 11:40 AM Mritunjay Sharma
> >  wrote:
> > >
> > > Hi everyone,
> > >
> > > As a part of working on ticket #3835 (BSP Buildset for EPICS), this is
> to inform the community that after a lot of research, help from RTEMS and
> EPICS community and
> https://epics.mpg.de/index.php?n=Software.EPICSRTEMS?userlang=en, I was
> able to build EPICS 7 for RTEMS 5 for mvme6100 (powerpc-rtems5).
> > > After this, my development environment is almost completely set up
> with RTEMS, rtems-source-builder and epics7 (taken from
> https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0 ). While going
> through the entire process, I learnt about the changes to be made in
> epics7/configure/os/CONFIG_STATUS.Common.RTEMS and also encountered few
> errors while the 'make' process, however, it got fixed by commenting line
> 325 to 329 in
> '/home/mritunjay/development/rtems/5/powerpc-rtems5/beatnik/lib/include/rtems/confdefs/libio.h':
> > > //  #ifdef CONFIGURE_FILESYSTEM_ENTRY_DEVFS
> > > //CONFIGURE_FILESYSTEM_ENTRY_DEVFS,
> > > //  #endif
> > > I would like to know more on why this behaviour occurred. Is it a bug?
> Or something else?
> > >
> > Include some of this detail in your proposal. I don't have time at the
> > moment to delve into details.
> >
> > Next step would be to identify a target you can build EPICS7+RTEMS5
> > with simulator support. This one is challenging since AFAIK there
> > haven't been any successes in that regards. Find out what are the
> > blockers and maybe you can work on those.
> >
> > > I wanted to test it but I am facing issues in connecting with tftp
> server when I run 'scp bin/RTEMS-beatnik/libComTestHarness.boot root@epics
> :/var/lib/tftp'
> > > The following error was encountered:
> > > /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
> information available (required by /usr/bin/ssh)
> > > /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
> information available (required by /usr/bin/ssh)
> > > ssh: Could not resolve hostname epics: Name or service not known
> > > lost connection
> > > I was wondering what can be the reason behind this, please help me fix
> this.
> > >
> > Test it how -- do you have a powerpc MVME6100 board?
> >
> > I'm guessing

Maintainers of rtems-littlevgl package

2020-03-18 Thread Gedare Bloom 
Hi everyone,

I'm pleased to announce that the rtems-littlevgl package will be
maintained (officially) by Christian Mauderer and Vijay Kumar
Bannerjee. Christian/Vijay, please add a README file to the
rtems-littlevgl package and include some details about the role of
that repo in RTEMS, and with your information as the package
maintainers. Eventually there should also be some instructions on how
to use it in the README :)

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

ANN: New Maintainer Vijay Kumar Bannerjee

2020-03-18 Thread Gedare Bloom 
Hello all,

I'm pleased to announce Vijay Kumar Bannerjee is being added as a
maintainer for the "beagle" BSPs and as write-after-approval
elsewhere. Vijay was a GSoC Student in 2018 and 2019, and he has been
an energetic and enthusiastic member of the community since his first
student experience.

Welcome aboard, Vijay!
Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

2020-03-18 Thread Christian Mauderer 
Hello Amar,

On 18/03/2020 19:24, Amar Takhar wrote:
> The only one I would like to propose is the 80 character limit.  This should 
> be 
> moved to something more reasonable such as 120.
> 
> Code comments should remain below 80 however.
> 

I'm not a big fan of long lines (reason further below) but I won't block
it either. But what I think is really a bad idea is to have different
rules for different parts of the code.

I think we will have a really hard time to set up tools like formatters
or pylint to check and use these rules. I think setting a line length to
120 should be easy to possible for nearly any tool. But I expect that
setting it to 120 for code and 80 for comments can be _very_ difficult
depending on the tool.


PS: Reason for me being not a fan of long lines: While programming I
often use a split window. In that configuration my editor can show 112
columns in each window on my current screen. That fits well for nearly
all code that follows the 80 character convention. But for example your
proposed length of 120 the code will lead to either a smaller font, a
lot of random line breaks done by the editor or to loosing one window.
Again: It's not a strong opinion and I'll accept 120 too. But expect
that some others have stronger opinions about 80 characters. At least it
have been 80 chars since at least punch hole cards:

https://softwareengineering.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width#148678


PPS: Also note one of the first rules in PEP-008: "A Foolish Consistency
is the Hobgoblin of Little Minds":
https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

It explicitly tells you to not follow the standard if your code gets
less readable by doing it. So if we only have few cases with long lines,
we can use exceptions and it is conform to PEP-008. Of course it might
could be tricky to tell our tools that this line is an exception.


Best regards

Christian

> Python itself has not followed this rule for a long time you can see many 
> lines 
> over 80 in the Python source itself.
> 
> Also, due to the nature of the language most lines end up below 80 characters 
> anyway.  Python is not an easy language to read when you have to break long 
> lines into 2 especially when you start breaking up strings.
> 
> I'm with most of the developers here -- 80 characters as been the norm for a 
> very long time however this is no longer true for new developers.  There are 
> already examples in our own rtems-tool codebase that make no sense being 
> split:
> 
>   
> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/execute.py?id=274981f77d648ceb87f84cdeaec33a58dfd37385#n579
> 
> I've ran into this more than once where a Python developer ends up in 
> confusion 
> when reading source that has line breaks to keep under line lengths.
> 
> I'd like to go the direction the wind is blowing on this and relax this rule 
> to 
> 120 for source, 80 for documentation where possible.
> 
> This is of course applied to cases where leaving the line long makes sense.  
> A 
> function with 20 parameters shouldn't be in a long line that is a disaster in 
> any language.
> 
> 
> Amar.
> ___
> 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: Successfully built EPICS 7 with RTEMS 5 for mvme6100

2020-03-18 Thread Heinz Junkes 
Hello, Mritunjay,

I will contact you tomorrow during the day (European time).  We have here 
institute closings because of Corona Virus etc..  

It's great that you've come this far. I can also provide you with an MVME6100 
remotely so you can get a feeling for target development. 
Yes, I have also started development of libbsd and the MVME2500. More on this 
tomorrow.

But the first, important step in this proposal would be to get EPICS7 running 
with RTEMS5 on e.g. qemu, ideally on i386?
I think I had some problems with the psim in the past. Unfortunately I don't 
know exactly what it is anymore. 
More tomorrow.

Many greetings and stay healthy,
Heinz
--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
Faradayweg 4-6| VC: 102220181...@bjn.vc
D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
--

> On 18. Mar 2020, at 19:56, Mritunjay Sharma  
> wrote:
> 
> Thank you so much for the feedback. I will research more on the targets that 
> can run with the simulator and would like to tell you that looking at 
> https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0, I feel that 
> @Heinz Junkes is already working on libbsd for RTEMS-MVME2500 and I would 
> like to hear more from him to get some clarity on what can be done. Being a 
> beginner, it's really a great welcome to the world of cross-compiler 
> development and testing. :) Thank you for always helping me out! 
> 
> On Wed, Mar 18, 2020 at 11:51 PM Gedare Bloom  wrote:
> On Wed, Mar 18, 2020 at 11:40 AM Mritunjay Sharma
>  wrote:
> >
> > Hi everyone,
> >
> > As a part of working on ticket #3835 (BSP Buildset for EPICS), this is to 
> > inform the community that after a lot of research, help from RTEMS and 
> > EPICS community and 
> > https://epics.mpg.de/index.php?n=Software.EPICSRTEMS?userlang=en, I was 
> > able to build EPICS 7 for RTEMS 5 for mvme6100 (powerpc-rtems5).
> > After this, my development environment is almost completely set up with 
> > RTEMS, rtems-source-builder and epics7 (taken from 
> > https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0 ). While going 
> > through the entire process, I learnt about the changes to be made in 
> > epics7/configure/os/CONFIG_STATUS.Common.RTEMS and also encountered few 
> > errors while the 'make' process, however, it got fixed by commenting line 
> > 325 to 329 in 
> > '/home/mritunjay/development/rtems/5/powerpc-rtems5/beatnik/lib/include/rtems/confdefs/libio.h':
> > //  #ifdef CONFIGURE_FILESYSTEM_ENTRY_DEVFS
> > //CONFIGURE_FILESYSTEM_ENTRY_DEVFS,
> > //  #endif
> > I would like to know more on why this behaviour occurred. Is it a bug? Or 
> > something else?
> >
> Include some of this detail in your proposal. I don't have time at the
> moment to delve into details.
> 
> Next step would be to identify a target you can build EPICS7+RTEMS5
> with simulator support. This one is challenging since AFAIK there
> haven't been any successes in that regards. Find out what are the
> blockers and maybe you can work on those.
> 
> > I wanted to test it but I am facing issues in connecting with tftp server 
> > when I run 'scp bin/RTEMS-beatnik/libComTestHarness.boot 
> > root@epics:/var/lib/tftp'
> > The following error was encountered:
> > /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> > information available (required by /usr/bin/ssh)
> > /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> > information available (required by /usr/bin/ssh)
> > ssh: Could not resolve hostname epics: Name or service not known
> > lost connection
> > I was wondering what can be the reason behind this, please help me fix this.
> >
> Test it how -- do you have a powerpc MVME6100 board?
> 
> I'm guessing whoever gave you that scp command line has a board with a
> local /etc/hosts entry for 'epics' pointing to some local IP address
> they connect to their board over.
> 
> Welcome to the world of cross-compiler development and testing. :)
> https://docs.rtems.org/branches/master/user/hosts/index.html#development-host
> 
> > Also, what are the next steps? I am working on the GSoC proposal currently 
> > and since the current ticket #3835 is a shorter project, I have to add 
> > certain similar sub-tasks within the GSoC timeline as suggested by @Gedare 
> > Bloom :
> > "* compile CFS by hand, create an RSB "recipe" to build it, then
> > integrate it with vertical buildset configuration.
> > * create vertical buildsets for PC, Raspberry Pi, and other boards.
> > ** EPICS community uses many powerpc boards so adding something there
> > would be good."
> 
> Identify what might be potential simulator targets for you to use, and
> look at how easy they are to build with RSB. If any are missing
> support, work on adding them. If any are

Re: Successfully built EPICS 7 with RTEMS 5 for mvme6100

2020-03-18 Thread Mritunjay Sharma 
Thank you so much for the feedback. I will research more on the targets
that can run with the simulator and would like to tell you that looking at
https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0, I feel that @Heinz
Junkes  is already working on libbsd for
RTEMS-MVME2500 and I would like to hear more from him to get some clarity
on what can be done. Being a beginner, it's really a great welcome to the
world of cross-compiler development and testing. :) Thank you for always
helping me out!

On Wed, Mar 18, 2020 at 11:51 PM Gedare Bloom  wrote:

> On Wed, Mar 18, 2020 at 11:40 AM Mritunjay Sharma
>  wrote:
> >
> > Hi everyone,
> >
> > As a part of working on ticket #3835 (BSP Buildset for EPICS), this is
> to inform the community that after a lot of research, help from RTEMS and
> EPICS community and
> https://epics.mpg.de/index.php?n=Software.EPICSRTEMS?userlang=en, I was
> able to build EPICS 7 for RTEMS 5 for mvme6100 (powerpc-rtems5).
> > After this, my development environment is almost completely set up with
> RTEMS, rtems-source-builder and epics7 (taken from
> https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0 ). While going
> through the entire process, I learnt about the changes to be made in
> epics7/configure/os/CONFIG_STATUS.Common.RTEMS and also encountered few
> errors while the 'make' process, however, it got fixed by commenting line
> 325 to 329 in
> '/home/mritunjay/development/rtems/5/powerpc-rtems5/beatnik/lib/include/rtems/confdefs/libio.h':
> > //  #ifdef CONFIGURE_FILESYSTEM_ENTRY_DEVFS
> > //CONFIGURE_FILESYSTEM_ENTRY_DEVFS,
> > //  #endif
> > I would like to know more on why this behaviour occurred. Is it a bug?
> Or something else?
> >
> Include some of this detail in your proposal. I don't have time at the
> moment to delve into details.
>
> Next step would be to identify a target you can build EPICS7+RTEMS5
> with simulator support. This one is challenging since AFAIK there
> haven't been any successes in that regards. Find out what are the
> blockers and maybe you can work on those.
>
> > I wanted to test it but I am facing issues in connecting with tftp
> server when I run 'scp bin/RTEMS-beatnik/libComTestHarness.boot root@epics
> :/var/lib/tftp'
> > The following error was encountered:
> > /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
> information available (required by /usr/bin/ssh)
> > /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
> information available (required by /usr/bin/ssh)
> > ssh: Could not resolve hostname epics: Name or service not known
> > lost connection
> > I was wondering what can be the reason behind this, please help me fix
> this.
> >
> Test it how -- do you have a powerpc MVME6100 board?
>
> I'm guessing whoever gave you that scp command line has a board with a
> local /etc/hosts entry for 'epics' pointing to some local IP address
> they connect to their board over.
>
> Welcome to the world of cross-compiler development and testing. :)
>
> https://docs.rtems.org/branches/master/user/hosts/index.html#development-host
>
> > Also, what are the next steps? I am working on the GSoC proposal
> currently and since the current ticket #3835 is a shorter project, I have
> to add certain similar sub-tasks within the GSoC timeline as suggested by
> @Gedare Bloom :
> > "* compile CFS by hand, create an RSB "recipe" to build it, then
> > integrate it with vertical buildset configuration.
> > * create vertical buildsets for PC, Raspberry Pi, and other boards.
> > ** EPICS community uses many powerpc boards so adding something there
> > would be good."
>
> Identify what might be potential simulator targets for you to use, and
> look at how easy they are to build with RSB. If any are missing
> support, work on adding them. If any are broken, poke into why.
>
> psim is a good powerpc simulator, although it may not have enough
> support for running epics--I haven't looked.
>
> For EPICS it is best to get something working in qemu so that you can
> run some  networking. So I'd look at some qemu simulator targets and
> check what is their status and whether you can build and run anything
> for RTEMS on them. After that, can you build/run any RTEMS networking
> applications?
>
> Does the EPICS7+RTEMS5 stack still using cpukit/libnetworking, or is
> it able to use libbsd? That is an interesting question to find out.
>
> > I would like to have suggestions on resetting the timeline as I work on
> refining the proposal for GSoC based on Dr. @Gedare Bloom's suggestions.
> >
> For timeline the first step is to break down all the tasks to figure
> out what you need to do to accomplish each of your goals. Then you
> should try to estimate how long you (or mentors) think each task will
> take, and use that create your plan. (Estimating time is notoriously
> difficult, but do your best. If it comes in too heavy or light, that
> is fine, you should put some activities in "Future Improvements" that
> can be moved into your

Re: Improve the Raspberry Pi BSP

2020-03-18 Thread Gedare Bloom 
On Wed, Mar 18, 2020 at 11:12 AM Denil Verghese  wrote:
>
>
>
> On Wed, 18 Mar, 2020, 9:03 PM Gedare Bloom,  wrote:
>>
>> On Wed, Mar 18, 2020 at 8:41 AM Denil Verghese  wrote:
>> >
>> >
>> >
>> > On Wed, 18 Mar, 2020, 7:43 PM Alan Cudmore,  wrote:
>> >>
>> >> This is probably not a comprehensive list, but currently all models 
>> >> except the Pi 4 are working thanks to Niteesh’s work on the uart for the 
>> >> Pi 3 and Zero W.
>> >>
>> >>
>> >>
>> >> I believe there is some support for GPIO, and I2C.
>> >>
>> >> I’m not sure about the state of SPI.
>> >>
>> >> There is also support for the graphics console, but I don’t know that 
>> >> state of that with the various Pi models as well.
>> >>
>> >>
>> >>
>> >> Finally, there was an effort to port libbsd to the Pi, but I don’t think 
>> >> it was completed.
>> >>
>> >>
>> >>
>> >> From what I know the Pi 4 is not supported at all yet.
>> >>
>> >>
>> >>
>> >> So there is still a lot of work to do, maybe too much for a single GSoC 
>> >> project.
>> >>
>> >> Maybe try to narrow the focus on something like:
>> >>
>> >> Libbsd and SMP support for the Raspberry Pi 3?
>> >
>> > That is a great idea. Thanks for the suggestion.
>> >
>> > Will this will be more useful than my current proposal?( Which is based on 
>> > Release note generator and code formatter.).
>> >
>>
>> They are two very different projects. You can continue to flesh out
>> both of them if you like, although we prefer a student to focus on one
>> proposal if you are not certain then it will be fine
>
>
> I can't focus on two proposals at the same time. My intention was to change 
> my proposal if this makes a great contribution and will be interesting for 
> mentors.
>>
>>
>> As before, to do the RPi projects you must have and demonstrate that
>> you can run RPi at least with baremetal if not with RTEMS.
>>
>> I don't know if we'll have the bandwidth for multiple projects
>> involving libbsd, while the release note generator/formatter may be
>> somewhat easier to mentor. I haven't heard too much enthusiasm yet,
>> but if you write a strong proposal you may convince a mentor :)
>
>
> If that's the case, I will focus on my current proposal and will make it 
> strong as I can:). I need some clarification on how can I do formatting part. 
> Maybe start a new thread??

Yes, start a new thread.

In general, projects that improve "infrastructure" are better than
individual BSPs, but we do value both. We like to have a mix really.
In your case, I think it will be better to focus on your current
trajectory and try to make it the best you can.

>>
>>
>> >> I have been learning how to use RTEMS and rtems-libbsd on the beaglebone 
>> >> black lately. Having that capability along with SMP on the Pi 3 would be 
>> >> great.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Alan
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Joel Sherrill
>> >> Sent: Tuesday, March 17, 2020 11:19 PM
>> >> To: Denil Verghese
>> >> Cc: rtems-de...@rtems.org
>> >> Subject: Re: Improve the Raspberry Pi BSP
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Sun, Mar 15, 2020, 10:20 PM Denil Verghese  wrote:
>> >>
>> >> Hi,
>> >>
>> >>I would like to know whether the projects shown in this 
>> >> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the 
>> >> ideas are yet to implement I could work on it.
>> >>
>> >>
>> >>
>> >> I think there is plenty left. I am not authoritative on this though.
>> >>
>> >>
>> >>
>> >> I think getting Pi3/4 support still has work.
>> >>
>> >>
>> >>
>> >> I think USB plus Ethernet.
>> >>
>> >>
>> >>
>> >> I recall the graphics work was done on the Beagle.
>> >>
>> >>
>> >>
>> >> I am not even sure that Pi2 qemu support has been worked through 
>> >> completely.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> It will more interesting to work those projects rather than my currently 
>> >> selected project which is Release Note Generator.
>> >>
>> >> Meanwhile I have uploaded my draft proposal which is ongoing self 
>> >> revision.
>> >>
>> >>
>> >>
>> >> Thank you
>> >>
>> >> Denil C Verghese
>> >>
>> >>
>> >>
>> >> ___
>> >> 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: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

2020-03-18 Thread Amar Takhar 
The only one I would like to propose is the 80 character limit.  This should be 
moved to something more reasonable such as 120.

Code comments should remain below 80 however.

Python itself has not followed this rule for a long time you can see many lines 
over 80 in the Python source itself.

Also, due to the nature of the language most lines end up below 80 characters 
anyway.  Python is not an easy language to read when you have to break long 
lines into 2 especially when you start breaking up strings.

I'm with most of the developers here -- 80 characters as been the norm for a 
very long time however this is no longer true for new developers.  There are 
already examples in our own rtems-tool codebase that make no sense being split:

  
https://git.rtems.org/rtems-tools/tree/rtemstoolkit/execute.py?id=274981f77d648ceb87f84cdeaec33a58dfd37385#n579

I've ran into this more than once where a Python developer ends up in confusion 
when reading source that has line breaks to keep under line lengths.

I'd like to go the direction the wind is blowing on this and relax this rule to 
120 for source, 80 for documentation where possible.

This is of course applied to cases where leaving the line long makes sense.  A 
function with 20 parameters shouldn't be in a long line that is a disaster in 
any language.


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

Re: Successfully built EPICS 7 with RTEMS 5 for mvme6100

2020-03-18 Thread Gedare Bloom 
On Wed, Mar 18, 2020 at 11:40 AM Mritunjay Sharma
 wrote:
>
> Hi everyone,
>
> As a part of working on ticket #3835 (BSP Buildset for EPICS), this is to 
> inform the community that after a lot of research, help from RTEMS and EPICS 
> community and 
> https://epics.mpg.de/index.php?n=Software.EPICSRTEMS?userlang=en, I was able 
> to build EPICS 7 for RTEMS 5 for mvme6100 (powerpc-rtems5).
> After this, my development environment is almost completely set up with 
> RTEMS, rtems-source-builder and epics7 (taken from 
> https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0 ). While going 
> through the entire process, I learnt about the changes to be made in 
> epics7/configure/os/CONFIG_STATUS.Common.RTEMS and also encountered few 
> errors while the 'make' process, however, it got fixed by commenting line 325 
> to 329 in 
> '/home/mritunjay/development/rtems/5/powerpc-rtems5/beatnik/lib/include/rtems/confdefs/libio.h':
> //  #ifdef CONFIGURE_FILESYSTEM_ENTRY_DEVFS
> //CONFIGURE_FILESYSTEM_ENTRY_DEVFS,
> //  #endif
> I would like to know more on why this behaviour occurred. Is it a bug? Or 
> something else?
>
Include some of this detail in your proposal. I don't have time at the
moment to delve into details.

Next step would be to identify a target you can build EPICS7+RTEMS5
with simulator support. This one is challenging since AFAIK there
haven't been any successes in that regards. Find out what are the
blockers and maybe you can work on those.

> I wanted to test it but I am facing issues in connecting with tftp server 
> when I run 'scp bin/RTEMS-beatnik/libComTestHarness.boot 
> root@epics:/var/lib/tftp'
> The following error was encountered:
> /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> information available (required by /usr/bin/ssh)
> /usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version 
> information available (required by /usr/bin/ssh)
> ssh: Could not resolve hostname epics: Name or service not known
> lost connection
> I was wondering what can be the reason behind this, please help me fix this.
>
Test it how -- do you have a powerpc MVME6100 board?

I'm guessing whoever gave you that scp command line has a board with a
local /etc/hosts entry for 'epics' pointing to some local IP address
they connect to their board over.

Welcome to the world of cross-compiler development and testing. :)
https://docs.rtems.org/branches/master/user/hosts/index.html#development-host

> Also, what are the next steps? I am working on the GSoC proposal currently 
> and since the current ticket #3835 is a shorter project, I have to add 
> certain similar sub-tasks within the GSoC timeline as suggested by @Gedare 
> Bloom :
> "* compile CFS by hand, create an RSB "recipe" to build it, then
> integrate it with vertical buildset configuration.
> * create vertical buildsets for PC, Raspberry Pi, and other boards.
> ** EPICS community uses many powerpc boards so adding something there
> would be good."

Identify what might be potential simulator targets for you to use, and
look at how easy they are to build with RSB. If any are missing
support, work on adding them. If any are broken, poke into why.

psim is a good powerpc simulator, although it may not have enough
support for running epics--I haven't looked.

For EPICS it is best to get something working in qemu so that you can
run some  networking. So I'd look at some qemu simulator targets and
check what is their status and whether you can build and run anything
for RTEMS on them. After that, can you build/run any RTEMS networking
applications?

Does the EPICS7+RTEMS5 stack still using cpukit/libnetworking, or is
it able to use libbsd? That is an interesting question to find out.

> I would like to have suggestions on resetting the timeline as I work on 
> refining the proposal for GSoC based on Dr. @Gedare Bloom's suggestions.
>
For timeline the first step is to break down all the tasks to figure
out what you need to do to accomplish each of your goals. Then you
should try to estimate how long you (or mentors) think each task will
take, and use that create your plan. (Estimating time is notoriously
difficult, but do your best. If it comes in too heavy or light, that
is fine, you should put some activities in "Future Improvements" that
can be moved into your summer work in case you get through your
planned work faster than you expect; if you don't complete all your
planned work, we understand and will take everything into
consideration during evaluation. Do NOT think of your plan as a
contract: it is not, it is a guideline for your summer.)

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

Re: GSoC 2020 memory protection project initial draft.

2020-03-18 Thread Gedare Bloom 
Provide edit access so I can add comments / suggestions.

On Tue, Mar 17, 2020 at 11:41 PM Utkarsh Rai 
wrote:

> Hi, I have prepared my initial draft for the project and look forward to
> your feedback on the same.
> I have also added this to the GSoC tracking page.
>  GSOC2020_ Rai_Memory_Protection
> 
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Successfully built EPICS 7 with RTEMS 5 for mvme6100

2020-03-18 Thread Mritunjay Sharma 
Hi everyone,

As a part of working on ticket #3835 (BSP Buildset for EPICS), this is to
inform the community that after a lot of research, help from RTEMS and
EPICS community and
https://epics.mpg.de/index.php?n=Software.EPICSRTEMS?userlang=en, I was
able to build EPICS 7 for RTEMS 5 for mvme6100 (powerpc-rtems5).
After this, my development environment is almost completely set up with
RTEMS, rtems-source-builder and epics7 (taken from
https://github.com/hjunkes/epicsBaseOwnPlayground/tree/7.0 ). While going
through the entire process, I learnt about the changes to be made in
epics7/configure/os/CONFIG_STATUS.Common.RTEMS and also encountered few
errors while the 'make' process, however, it got fixed by commenting line
325 to 329 in
'/home/mritunjay/development/rtems/5/powerpc-rtems5/beatnik/lib/include/rtems/confdefs/libio.h':
//  #ifdef CONFIGURE_FILESYSTEM_ENTRY_DEVFS
//CONFIGURE_FILESYSTEM_ENTRY_DEVFS,
//  #endif
I would like to know more on why this behaviour occurred. Is it a bug? Or
something else?

I wanted to test it but I am facing issues in connecting with tftp server
when I run 'scp bin/RTEMS-beatnik/libComTestHarness.boot root@epics
:/var/lib/tftp'
The following error was encountered:
/usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/ssh)
/usr/bin/ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/ssh)
ssh: Could not resolve hostname epics: Name or service not known
lost connection
I was wondering what can be the reason behind this, please help me fix this.

Also, what are the next steps? I am working on the GSoC proposal currently
and since the current ticket #3835 is a shorter project, I have to add
certain similar sub-tasks within the GSoC timeline as suggested by @Gedare
Bloom  :
"* compile CFS by hand, create an RSB "recipe" to build it, then
integrate it with vertical buildset configuration.
* create vertical buildsets for PC, Raspberry Pi, and other boards.
** EPICS community uses many powerpc boards so adding something there
would be good."
I would like to have suggestions on resetting the timeline as I work on
refining the proposal for GSoC based on Dr. @Gedare Bloom 's
suggestions.

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

RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

2020-03-18 Thread Gedare Bloom 
Hello all,

Sebastian has proposed some Python development guidelines for the
SWEng book, which is great and I'm even going to steal some of his
words here. I want to open the discussion for comments and requests
for changes to one specific point: Python Coding Style. I'm
specifically interested to hear from stakeholders including Chris
Johns as the de facto Tools maintainer, Amar Takhar, Sebastian Huber,
and anyone involved in the development of pre-qual tools intended for
RTEMS community adoption. Anyone else in the community that wants to
chime in is always certainly welcome.

Python is the main programming language for the RTEMS Tools. The rules
we choose will apply to new tools and should be possible to adapt
backward to existing tools. Python has good automatic code formatters
available. We will benefit by using them to the maximum extent
possible. This means we should aim to adopt a Python Coding Style as
close to existing well-used styles as possible. The current proposal
is essentially to adopt PEP-8
(https://www.python.org/dev/peps/pep-0008/) directly.

I would like to open the discussion for any requests for exceptions to
PEP-8. Please make your comments with justification for the exception
and let's maintain a civil tone :) as usual. (If anyone wants to
reject PEP-8 in favor of something else, please provide justification
and show that the "something else" is widely supported by
formatters/checkers. We don't want to define any exotic formats that
require us to maintain our own formatter/checker infrastructure.)

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

Re: Improve the Raspberry Pi BSP

2020-03-18 Thread Alan Cudmore 
While, I would like to see additional improvement to the Raspberry Pi
BSPs, I don't think I have the time to serve as a mentor this year. I
am sure I could not keep up with the daily communication that is
required for a successful GSoC project.
Alan

On Wed, Mar 18, 2020 at 1:12 PM Denil Verghese  wrote:
>
>
>
> On Wed, 18 Mar, 2020, 9:03 PM Gedare Bloom,  wrote:
>>
>> On Wed, Mar 18, 2020 at 8:41 AM Denil Verghese  wrote:
>> >
>> >
>> >
>> > On Wed, 18 Mar, 2020, 7:43 PM Alan Cudmore,  wrote:
>> >>
>> >> This is probably not a comprehensive list, but currently all models 
>> >> except the Pi 4 are working thanks to Niteesh’s work on the uart for the 
>> >> Pi 3 and Zero W.
>> >>
>> >>
>> >>
>> >> I believe there is some support for GPIO, and I2C.
>> >>
>> >> I’m not sure about the state of SPI.
>> >>
>> >> There is also support for the graphics console, but I don’t know that 
>> >> state of that with the various Pi models as well.
>> >>
>> >>
>> >>
>> >> Finally, there was an effort to port libbsd to the Pi, but I don’t think 
>> >> it was completed.
>> >>
>> >>
>> >>
>> >> From what I know the Pi 4 is not supported at all yet.
>> >>
>> >>
>> >>
>> >> So there is still a lot of work to do, maybe too much for a single GSoC 
>> >> project.
>> >>
>> >> Maybe try to narrow the focus on something like:
>> >>
>> >> Libbsd and SMP support for the Raspberry Pi 3?
>> >
>> > That is a great idea. Thanks for the suggestion.
>> >
>> > Will this will be more useful than my current proposal?( Which is based on 
>> > Release note generator and code formatter.).
>> >
>>
>> They are two very different projects. You can continue to flesh out
>> both of them if you like, although we prefer a student to focus on one
>> proposal if you are not certain then it will be fine
>
>
> I can't focus on two proposals at the same time. My intention was to change 
> my proposal if this makes a great contribution and will be interesting for 
> mentors.
>>
>>
>> As before, to do the RPi projects you must have and demonstrate that
>> you can run RPi at least with baremetal if not with RTEMS.
>>
>> I don't know if we'll have the bandwidth for multiple projects
>> involving libbsd, while the release note generator/formatter may be
>> somewhat easier to mentor. I haven't heard too much enthusiasm yet,
>> but if you write a strong proposal you may convince a mentor :)
>
>
> If that's the case, I will focus on my current proposal and will make it 
> strong as I can:). I need some clarification on how can I do formatting part. 
> Maybe start a new thread??
>>
>>
>> >> I have been learning how to use RTEMS and rtems-libbsd on the beaglebone 
>> >> black lately. Having that capability along with SMP on the Pi 3 would be 
>> >> great.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Alan
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Joel Sherrill
>> >> Sent: Tuesday, March 17, 2020 11:19 PM
>> >> To: Denil Verghese
>> >> Cc: rtems-de...@rtems.org
>> >> Subject: Re: Improve the Raspberry Pi BSP
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Sun, Mar 15, 2020, 10:20 PM Denil Verghese  wrote:
>> >>
>> >> Hi,
>> >>
>> >>I would like to know whether the projects shown in this 
>> >> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the 
>> >> ideas are yet to implement I could work on it.
>> >>
>> >>
>> >>
>> >> I think there is plenty left. I am not authoritative on this though.
>> >>
>> >>
>> >>
>> >> I think getting Pi3/4 support still has work.
>> >>
>> >>
>> >>
>> >> I think USB plus Ethernet.
>> >>
>> >>
>> >>
>> >> I recall the graphics work was done on the Beagle.
>> >>
>> >>
>> >>
>> >> I am not even sure that Pi2 qemu support has been worked through 
>> >> completely.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> It will more interesting to work those projects rather than my currently 
>> >> selected project which is Release Note Generator.
>> >>
>> >> Meanwhile I have uploaded my draft proposal which is ongoing self 
>> >> revision.
>> >>
>> >>
>> >>
>> >> Thank you
>> >>
>> >> Denil C Verghese
>> >>
>> >>
>> >>
>> >> ___
>> >> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

2020-03-18 Thread Gedare Bloom 
On Wed, Mar 18, 2020 at 9:20 AM Amar Takhar  wrote:
>
> On 2020-03-18 16:16 +1100, Chris Johns wrote:
> >
> > Are these plugins extra dependencies or are they part of our test code?
>
> Dependencies on pytest but we can include them in the test suite just fine.
> This is what I usually do.  Most of them are a single Python file.
>
Will they be shared among all the tests then?

My two concerns are updating and ensuring consistency. I have no
problems with capturing files but whenever we deal with 3rd party code
these are the two main hurdles to address.

>
> Amar.
> ___
> 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: Improve the Raspberry Pi BSP

2020-03-18 Thread Denil Verghese 
On Wed, 18 Mar, 2020, 9:03 PM Gedare Bloom,  wrote:

> On Wed, Mar 18, 2020 at 8:41 AM Denil Verghese  wrote:
> >
> >
> >
> > On Wed, 18 Mar, 2020, 7:43 PM Alan Cudmore, 
> wrote:
> >>
> >> This is probably not a comprehensive list, but currently all models
> except the Pi 4 are working thanks to Niteesh’s work on the uart for the Pi
> 3 and Zero W.
> >>
> >>
> >>
> >> I believe there is some support for GPIO, and I2C.
> >>
> >> I’m not sure about the state of SPI.
> >>
> >> There is also support for the graphics console, but I don’t know that
> state of that with the various Pi models as well.
> >>
> >>
> >>
> >> Finally, there was an effort to port libbsd to the Pi, but I don’t
> think it was completed.
> >>
> >>
> >>
> >> From what I know the Pi 4 is not supported at all yet.
> >>
> >>
> >>
> >> So there is still a lot of work to do, maybe too much for a single GSoC
> project.
> >>
> >> Maybe try to narrow the focus on something like:
> >>
> >> Libbsd and SMP support for the Raspberry Pi 3?
> >
> > That is a great idea. Thanks for the suggestion.
> >
> > Will this will be more useful than my current proposal?( Which is based
> on Release note generator and code formatter.).
> >
>
> They are two very different projects. You can continue to flesh out
> both of them if you like, although we prefer a student to focus on one
> proposal if you are not certain then it will be fine


I can't focus on two proposals at the same time. My intention was to change
my proposal if this makes a great contribution and will be interesting for
mentors.

>
> As before, to do the RPi projects you must have and demonstrate that
> you can run RPi at least with baremetal if not with RTEMS.
>
> I don't know if we'll have the bandwidth for multiple projects
> involving libbsd, while the release note generator/formatter may be
> somewhat easier to mentor. I haven't heard too much enthusiasm yet,
> but if you write a strong proposal you may convince a mentor :)
>

If that's the case, I will focus on my current proposal and will make it
strong as I can:). I need some clarification on how can I do formatting
part. Maybe start a new thread??

>
> >> I have been learning how to use RTEMS and rtems-libbsd on the
> beaglebone black lately. Having that capability along with SMP on the Pi 3
> would be great.
> >>
> >>
> >>
> >>
> >>
> >> Alan
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: Joel Sherrill
> >> Sent: Tuesday, March 17, 2020 11:19 PM
> >> To: Denil Verghese
> >> Cc: rtems-de...@rtems.org
> >> Subject: Re: Improve the Raspberry Pi BSP
> >>
> >>
> >>
> >>
> >>
> >> On Sun, Mar 15, 2020, 10:20 PM Denil Verghese 
> wrote:
> >>
> >> Hi,
> >>
> >>I would like to know whether the projects shown in this
> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the
> ideas are yet to implement I could work on it.
> >>
> >>
> >>
> >> I think there is plenty left. I am not authoritative on this though.
> >>
> >>
> >>
> >> I think getting Pi3/4 support still has work.
> >>
> >>
> >>
> >> I think USB plus Ethernet.
> >>
> >>
> >>
> >> I recall the graphics work was done on the Beagle.
> >>
> >>
> >>
> >> I am not even sure that Pi2 qemu support has been worked through
> completely.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> It will more interesting to work those projects rather than my
> currently selected project which is Release Note Generator.
> >>
> >> Meanwhile I have uploaded my draft proposal which is ongoing self
> revision.
> >>
> >>
> >>
> >> Thank you
> >>
> >> Denil C Verghese
> >>
> >>
> >>
> >> ___
> >> 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: [rtems-libbsd commit] nfsclient: Use a system event for RPC

2020-03-18 Thread Sebastian Huber 

On 18/03/2020 16:47, Joel Sherrill wrote:


Is this the same as the NFS client for the legacy stack?
Probably yes. In the libbsd I had to rewrite some parts to use kqueue() 
instead of events in some parts.

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

[PATCH] c-user: Use new template for feature config opts

2020-03-18 Thread Sebastian Huber 
Try to bring all descriptions up to date.  Add cross-references to
several options.

Update #3900.
---
 c-user/config/bdbuf.rst |  21 ++-
 c-user/config/classic-init-task.rst |  35 ++--
 c-user/config/device-driver.rst | 278 +++--
 c-user/config/event-record.rst  |  22 ++-
 c-user/config/filesystem.rst| 336 ++--
 c-user/config/general.rst   | 141 +++
 c-user/config/idle-task.rst |  43 +++--
 c-user/config/mpci.rst  |  19 +-
 c-user/config/posix-init-thread.rst |  36 ++--
 c-user/config/scheduler-general.rst | 173 +--
 10 files changed, 539 insertions(+), 565 deletions(-)

diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
index 2aaa310..24261b9 100644
--- a/c-user/config/bdbuf.rst
+++ b/c-user/config/bdbuf.rst
@@ -18,22 +18,21 @@ CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 CONSTANT:
 ``CONFIGURE_APPLICATION_NEEDS_LIBBLOCK``
 
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
+OPTION TYPE:
+This configuration option is a boolean feature define.
 
-DEFAULT VALUE:
-This is not defined by default.
+DEFAULT CONFIGURATION:
+If this configuration option is undefined, then the Block Device Cache is 
not
+initialized during system initialization.
 
 DESCRIPTION:
-Provides a Block Device Cache configuration.
+In case this configuration option is defined, then the Block Device Cache 
is
+initialized during system initialization.
 
 NOTES:
-Each option of the Block Device Cache configuration can be explicitly set
-by the user with the configuration options below.  The Block Device Cache
-is used for example by the RFS and DOSFS file systems.
+Each option of the Block Device Cache (bdbuf) configuration can be 
explicitly
+set by the user with the configuration options below.  The Block Device 
Cache
+is used for example by the RFS and DOSFS filesystems.
 
 .. index:: CONFIGURE_BDBUF_BUFFER_MAX_SIZE
 
diff --git a/c-user/config/classic-init-task.rst 
b/c-user/config/classic-init-task.rst
index 8eaafca..f56fd6e 100644
--- a/c-user/config/classic-init-task.rst
+++ b/c-user/config/classic-init-task.rst
@@ -206,28 +206,25 @@ CONFIGURE_RTEMS_INIT_TASKS_TABLE
 CONSTANT:
 ``CONFIGURE_RTEMS_INIT_TASKS_TABLE``
 
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
+OPTION TYPE:
+This configuration option is a boolean feature define.
 
-DEFAULT VALUE:
-This is not defined by default.
+DEFAULT CONFIGURATION:
+If this configuration option is undefined, then no Classic API 
initialization
+task is configured.
 
 DESCRIPTION:
-``CONFIGURE_RTEMS_INIT_TASKS_TABLE`` is defined if the user wishes to use a
-Classic RTEMS API Initialization Task Table. The table built by
- specifies the parameters for a single task. This is
-sufficient for applications which initialization the system from a single
-task.
-
-By default, this field is not defined as the user MUST select their own API
-for initialization tasks.
+In case this configuration option is defined, then a Classic API
+initialization task is configured.
 
 NOTES:
-The application may choose to use the initialization tasks or threads table
-from another API.
+The application must define exactly one of the following configuration
+options
+
+* :ref:`CONFIGURE_RTEMS_INIT_TASKS_TABLE`,
+
+* :ref:`CONFIGURE_POSIX_INIT_THREAD_TABLE`, or
+
+* :ref:`CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`
 
-A compile time error will be generated if the user does not configure any
-initialization tasks or threads.
+otherwise a compile time error will occur.
diff --git a/c-user/config/device-driver.rst b/c-user/config/device-driver.rst
index 7a1196d..9710dba 100644
--- a/c-user/config/device-driver.rst
+++ b/c-user/config/device-driver.rst
@@ -18,26 +18,32 @@ CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
 CONSTANT:
 ``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER``
 
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
+OPTION TYPE:
+This configuration option is a boolean feature define.
 
-DEFAULT VALUE:
-This is not defined by default.
+DEFAULT CONFIGURATION:
+If this configuration option is undefined, then a clock driver may be
+initialized during system initialization.
 
 DESCRIPTION:
-``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is defined when the
-application does *NOT* want the Clock Device Driver and is *NOT* using the
-Timer Driver.  The inclusion or exclusion of the Clock Driver must be
-explicit in user applications.
+In case this configuration option is defined, then **no** clock driver is
+initialized during system initialization.
 
 NOTES:
 This configuration parameter is intended to prevent the common user error
 of using the Hello World example as the

Re: [rtems-libbsd commit] nfsclient: Use a system event for RPC

2020-03-18 Thread Joel Sherrill 
Is this the same as the NFS client for the legacy stack?

On Wed, Mar 18, 2020, 2:27 AM Sebastian Huber  wrote:

> Module:rtems-libbsd
> Branch:5-freebsd-12
> Commit:039afd9816122fc52f77966dc78430e009aa220c
> Changeset:
> http://git.rtems.org/rtems-libbsd/commit/?id=039afd9816122fc52f77966dc78430e009aa220c
>
> Author:Sebastian Huber 
> Date:  Wed Mar 11 11:05:59 2020 +0100
>
> nfsclient: Use a system event for RPC
>
> Aviod conflicts with application events.
>
> ---
>
>  rtemsbsd/nfsclient/rpcio.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/rtemsbsd/nfsclient/rpcio.c b/rtemsbsd/nfsclient/rpcio.c
> index cd04de3..40f8f08 100644
> --- a/rtemsbsd/nfsclient/rpcio.c
> +++ b/rtemsbsd/nfsclient/rpcio.c
> @@ -145,7 +145,7 @@ static struct timeval _rpc_default_timeout = { 10 /*
> secs */, 0 /* usecs */ };
>   * MUST NOT be used by any application
>   * thread doing RPC IO (e.g. NFS)
>   */
> -#define RTEMS_RPC_EVENTRTEMS_EVENT_30  /* THE event used
> by RPCIO. Every task doing
> +#define RTEMS_RPC_EVENTRTEMS_EVENT_SYSTEM_SERVER   /*
> THE event used by RPCIO. Every task doing
>
>* RPC IO will receive this - hence it is
>
>* RESERVED
>
>*/
> @@ -867,7 +867,7 @@ rtems_event_set gotEvents;
> do {
>
> /* block for the reply */
> -   status = rtems_event_receive(
> +   status = rtems_event_system_receive(
> RTEMS_RPC_EVENT,
> RTEMS_WAIT | RTEMS_EVENT_ANY,
> RTEMS_NO_TIMEOUT,
> @@ -1316,7 +1316,7 @@ rtems_status_code status;
> }
>
> /* wakeup requestor */
> -   rtems_event_send(xact->requestor,
> RTEMS_RPC_EVENT);
> +   rtems_event_system_send(xact->requestor,
> RTEMS_RPC_EVENT);
> }
> }
>
> @@ -1371,7 +1371,7 @@ rtems_status_code status;
>  #if (DEBUG) & DEBUG_TIMEOUT
> fprintf(stderr,"RPCIO XACT timed
> out; waking up requestor\n");
>  #endif
> -   if (
> rtems_event_send(xact->requestor, RTEMS_RPC_EVENT) ) {
> +   if (
> rtems_event_system_send(xact->requestor, RTEMS_RPC_EVENT) ) {
> rtems_panic("RPCIO PANIC:
> requestor id was 0x%08x",
>
> xact->requestor);
> }
> @@ -1403,7 +1403,7 @@ rtems_status_code status;
>
> /* wakeup requestor */
> fprintf(stderr,"RPCIO:
> SEND failure\n");
> -   status =
> rtems_event_send(xact->requestor, RTEMS_RPC_EVENT);
> +   status =
> rtems_event_system_send(xact->requestor, RTEMS_RPC_EVENT);
> assert( status ==
> RTEMS_SUCCESSFUL );
>
> } else {
> @@ -1541,7 +1541,7 @@ rtems_status_code status;
>
> for (xact=((RpcUdpXact)listHead.next); xact;
> xact=((RpcUdpXact)xact->node.next)) {
> xact->status.re_status = RPC_TIMEDOUT;
> -   rtems_event_send(xact->requestor, RTEMS_RPC_EVENT);
> +   rtems_event_system_send(xact->requestor,
> RTEMS_RPC_EVENT);
> }
>  #endif
>
>
> ___
> 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

Re: Re: Improve the Raspberry Pi BSP

2020-03-18 Thread Gedare Bloom 
On Wed, Mar 18, 2020 at 8:41 AM Denil Verghese  wrote:
>
>
>
> On Wed, 18 Mar, 2020, 7:43 PM Alan Cudmore,  wrote:
>>
>> This is probably not a comprehensive list, but currently all models except 
>> the Pi 4 are working thanks to Niteesh’s work on the uart for the Pi 3 and 
>> Zero W.
>>
>>
>>
>> I believe there is some support for GPIO, and I2C.
>>
>> I’m not sure about the state of SPI.
>>
>> There is also support for the graphics console, but I don’t know that state 
>> of that with the various Pi models as well.
>>
>>
>>
>> Finally, there was an effort to port libbsd to the Pi, but I don’t think it 
>> was completed.
>>
>>
>>
>> From what I know the Pi 4 is not supported at all yet.
>>
>>
>>
>> So there is still a lot of work to do, maybe too much for a single GSoC 
>> project.
>>
>> Maybe try to narrow the focus on something like:
>>
>> Libbsd and SMP support for the Raspberry Pi 3?
>
> That is a great idea. Thanks for the suggestion.
>
> Will this will be more useful than my current proposal?( Which is based on 
> Release note generator and code formatter.).
>

They are two very different projects. You can continue to flesh out
both of them if you like, although we prefer a student to focus on one
proposal if you are not certain then it will be fine.

As before, to do the RPi projects you must have and demonstrate that
you can run RPi at least with baremetal if not with RTEMS.

I don't know if we'll have the bandwidth for multiple projects
involving libbsd, while the release note generator/formatter may be
somewhat easier to mentor. I haven't heard too much enthusiasm yet,
but if you write a strong proposal you may convince a mentor :)

>> I have been learning how to use RTEMS and rtems-libbsd on the beaglebone 
>> black lately. Having that capability along with SMP on the Pi 3 would be 
>> great.
>>
>>
>>
>>
>>
>> Alan
>>
>>
>>
>>
>>
>>
>>
>> From: Joel Sherrill
>> Sent: Tuesday, March 17, 2020 11:19 PM
>> To: Denil Verghese
>> Cc: rtems-de...@rtems.org
>> Subject: Re: Improve the Raspberry Pi BSP
>>
>>
>>
>>
>>
>> On Sun, Mar 15, 2020, 10:20 PM Denil Verghese  wrote:
>>
>> Hi,
>>
>>I would like to know whether the projects shown in this 
>> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the ideas 
>> are yet to implement I could work on it.
>>
>>
>>
>> I think there is plenty left. I am not authoritative on this though.
>>
>>
>>
>> I think getting Pi3/4 support still has work.
>>
>>
>>
>> I think USB plus Ethernet.
>>
>>
>>
>> I recall the graphics work was done on the Beagle.
>>
>>
>>
>> I am not even sure that Pi2 qemu support has been worked through completely.
>>
>>
>>
>>
>>
>>
>>
>> It will more interesting to work those projects rather than my currently 
>> selected project which is Release Note Generator.
>>
>> Meanwhile I have uploaded my draft proposal which is ongoing self revision.
>>
>>
>>
>> Thank you
>>
>> Denil C Verghese
>>
>>
>>
>> ___
>> 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 2/2] Add a message to run 'pytest' to run rest of test suite.

2020-03-18 Thread Amar Takhar 
On 2020-03-18 16:16 +1100, Chris Johns wrote:
> 
> Are these plugins extra dependencies or are they part of our test code?

Dependencies on pytest but we can include them in the test suite just fine.  
This is what I usually do.  Most of them are a single Python file.


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

Re: Re: Improve the Raspberry Pi BSP

2020-03-18 Thread Denil Verghese 
On Wed, 18 Mar, 2020, 7:43 PM Alan Cudmore,  wrote:

> This is probably not a comprehensive list, but currently all models except
> the Pi 4 are working thanks to Niteesh’s work on the uart for the Pi 3 and
> Zero W.
>
>
>
> I believe there is some support for GPIO, and I2C.
>
> I’m not sure about the state of SPI.
>
> There is also support for the graphics console, but I don’t know that
> state of that with the various Pi models as well.
>
>
>
> Finally, there was an effort to port libbsd to the Pi, but I don’t think
> it was completed.
>
>
>
> From what I know the Pi 4 is not supported at all yet.
>
>
>
> So there is still a lot of work to do, maybe too much for a single GSoC
> project.
>
> Maybe try to narrow the focus on something like:
>
>- Libbsd and SMP support for the Raspberry Pi 3?
>
> That is a great idea. Thanks for the suggestion.

Will this will be more useful than my current proposal?( Which is based on
Release note generator and code formatter.).

I have been learning how to use RTEMS and rtems-libbsd on the beaglebone
> black lately. Having that capability along with SMP on the Pi 3 would be
> great.
>
>
>
>
>
> Alan
>
>
>
>
>
>
>
> *From: *Joel Sherrill 
> *Sent: *Tuesday, March 17, 2020 11:19 PM
> *To: *Denil Verghese 
> *Cc: *rtems-de...@rtems.org 
> *Subject: *Re: Improve the Raspberry Pi BSP
>
>
>
>
>
> On Sun, Mar 15, 2020, 10:20 PM Denil Verghese  wrote:
>
> Hi,
>
>I would like to know whether the projects shown in this
> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the
> ideas are yet to implement I could work on it.
>
>
>
> I think there is plenty left. I am not authoritative on this though.
>
>
>
> I think getting Pi3/4 support still has work.
>
>
>
> I think USB plus Ethernet.
>
>
>
> I recall the graphics work was done on the Beagle.
>
>
>
> I am not even sure that Pi2 qemu support has been worked through
> completely.
>
>
>
>
>
>
>
> It will more interesting to work those projects rather than my currently
> selected project which is Release Note Generator.
>
> Meanwhile I have uploaded my draft proposal which is ongoing self revision.
>
>
>
> Thank you
>
> Denil C Verghese
>
>
>
> ___
> 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: Re: Improve the Raspberry Pi BSP

2020-03-18 Thread Alan Cudmore 
This is probably not a comprehensive list, but currently all models except the Pi 4 are working thanks to Niteesh’s work on the uart for the Pi 3 and Zero W. I believe there is some support for GPIO, and I2C.I’m not sure about the state of SPI.There is also support for the graphics console, but I don’t know that state of that with the various Pi models as well. Finally, there was an effort to port libbsd to the Pi, but I don’t think it was completed. From what I know the Pi 4 is not supported at all yet. So there is still a lot of work to do, maybe too much for a single GSoC project.Maybe try to narrow the focus on something like:Libbsd and SMP support for the Raspberry Pi 3?I have been learning how to use RTEMS and rtems-libbsd on the beaglebone black lately. Having that capability along with SMP on the Pi 3 would be great.  Alan   From: Joel SherrillSent: Tuesday, March 17, 2020 11:19 PMTo: Denil VergheseCc: rtems-de...@rtems.orgSubject: Re: Improve the Raspberry Pi BSP  On Sun, Mar 15, 2020, 10:20 PM Denil Verghese  wrote:Hi,    I would like to know whether the projects shown in this https://devel.rtems.org/ticket/2899 ticket is completed or not. If the ideas are yet to implement I could work on it. I think there is plenty left. I am not authoritative on this though. I think getting Pi3/4 support still has work. I think USB plus Ethernet. I recall the graphics work was done on the Beagle. I am not even sure that Pi2 qemu support has been worked through completely.   It will more interesting to work those projects rather than my currently selected project which is Release Note Generator. Meanwhile I have uploaded my draft proposal which is ongoing self revision. Thank youDenil C Verghese ___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v1 06/16] Py2/3 compliant tools/gdb/python/percpu.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/percpu.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/gdb/python/percpu.py b/tools/gdb/python/percpu.py
index 991bdf8..fb2d6d8 100644
--- a/tools/gdb/python/percpu.py
+++ b/tools/gdb/python/percpu.py
@@ -31,9 +31,11 @@
 # RTEMS Per CPU Table
 #
 
+from __future__ import absolute_import
+
 import gdb
 
-import configuration
+from . import configuration
 
 def _table(cpu):
 max_cpus = configuration.maximum_processors()
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 04/16] Py2/3 compliant tools/gdb/python/rtems.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/rtems.py | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/gdb/python/rtems.py b/tools/gdb/python/rtems.py
index a097797..43232a6 100644
--- a/tools/gdb/python/rtems.py
+++ b/tools/gdb/python/rtems.py
@@ -31,15 +31,18 @@
 # RTEMS Pretty Printers
 #
 
+from __future__ import print_function
+from __future__ import absolute_import
+
 import gdb
 import re
 
-import objects
-import threads
-import chains
-import watchdog
-import supercore
-import classic
+from . import objects
+from . import threads
+from . import chains
+from . import watchdog
+from . import supercore
+from . import classic
 
 
 class rtems(gdb.Command):
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 02/16] Py2/3 compliant tools/gdb/python/pretty.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/pretty.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/gdb/python/pretty.py b/tools/gdb/python/pretty.py
index 3cbe052..302dc2f 100644
--- a/tools/gdb/python/pretty.py
+++ b/tools/gdb/python/pretty.py
@@ -30,12 +30,14 @@
 # RTEMS pretty printers
 #
 
+from __future__ import absolute_import
+
 import re
-import helper
-import objects
+from . import helper
+from . import objects
 
-import supercore_printer
-import classic_printer
+from . import supercore_printer
+from . import classic_printer
 
 pretty_printer = {
 
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 09/16] Py2/3 compliant tools/gdb/python/supercore.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/supercore.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/gdb/python/supercore.py b/tools/gdb/python/supercore.py
index 318ebb7..dd1420e 100644
--- a/tools/gdb/python/supercore.py
+++ b/tools/gdb/python/supercore.py
@@ -31,8 +31,11 @@
 # RTEMS Supercore Objects
 #
 
-import threads
-import helper
+from __future__ import print_function
+from __future__ import absolute_import
+
+from . import threads
+from . import helper
 
 class time_of_day:
 '''Manage time of day object'''
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 11/16] Py2/3 compliant tools/gdb/python/classic.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/classic.py | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/gdb/python/classic.py b/tools/gdb/python/classic.py
index b5aacf8..494eaea 100644
--- a/tools/gdb/python/classic.py
+++ b/tools/gdb/python/classic.py
@@ -31,18 +31,22 @@
 # RTEMS Classic API Support
 #
 
+from __future__ import print_function
+from __future__ import absolute_import
+
 import gdb
 import itertools
 import re
 #ToDo This shouldn't be here
-import helper
-
-import heaps
-import mutex
-import objects
-import supercore
-import threads
-import watchdog
+
+from . import helper
+
+from . import heaps
+from . import mutex
+from . import objects
+from . import supercore
+from . import threads
+from . import watchdog
 
 class attribute:
 """The Classic API attribute."""
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 03/16] Py2/3 compliant tools/gdb/python/mutex.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/mutex.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/gdb/python/mutex.py b/tools/gdb/python/mutex.py
index 17f1900..eaae1ac 100644
--- a/tools/gdb/python/mutex.py
+++ b/tools/gdb/python/mutex.py
@@ -31,11 +31,13 @@
 # RTEMS Mutex Support
 #
 
+from __future__ import absolute_import
+
 import gdb
 
-import objects
-import percpu
-import threads
+from . import objects
+from . import percpu
+from . import threads
 
 class attributes:
 CORE_MUTEX_NESTING_ACQUIRES = 0
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 05/16] Py2/3 compliant tools/gdb/python/main.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/main.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/gdb/python/main.py b/tools/gdb/python/main.py
index 6fb7c54..945fb69 100644
--- a/tools/gdb/python/main.py
+++ b/tools/gdb/python/main.py
@@ -3,9 +3,11 @@
 #
 # main
 
+from __future__ import absolute_import
+
 import gdb
-import pretty
-import rtems
+from . import pretty
+from . import rtems
 
 gdb.pretty_printers = []
 gdb.pretty_printers.append(pretty.lookup_function)
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 01/16] Py2/3 compliant tools/gdb/python

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/__init__.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/gdb/python/__init__.py b/tools/gdb/python/__init__.py
index 0ea5fb2..dfbe6ba 100644
--- a/tools/gdb/python/__init__.py
+++ b/tools/gdb/python/__init__.py
@@ -27,8 +27,11 @@
 # POSSIBILITY OF SUCH DAMAGE.
 #
 
+from __future__ import print_function
+from __future__ import absolute_import
+
 import gdb
-import rtems
+from . import rtems
 
 def get_architure():
 frame = gdb.selected_frame()
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 07/16] Py2/3 compliant tools/gdb/python/sparc.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/sparc.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/gdb/python/sparc.py b/tools/gdb/python/sparc.py
index 38f19b7..4879266 100644
--- a/tools/gdb/python/sparc.py
+++ b/tools/gdb/python/sparc.py
@@ -2,7 +2,10 @@
 # RTEMS gdb extensions
 # sparc archetecture specific abstractions
 
-from helper import test_bit
+from __future__ import print_function
+from __future__ import absolute_import
+
+from .helper import test_bit
 
 
 
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 12/16] Py2/3 compliant tools/gdb/python/heaps.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/heaps.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/gdb/python/heaps.py b/tools/gdb/python/heaps.py
index 14238e3..274942e 100644
--- a/tools/gdb/python/heaps.py
+++ b/tools/gdb/python/heaps.py
@@ -31,6 +31,8 @@
 # RTEMS heap
 #
 
+from __future__ import print_function
+
 class block:
 '''Abstract a heap block structure'''
 
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 15/16] Py2/3 compliant tools/gdb/python/classic_printer.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/classic_printer.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/gdb/python/classic_printer.py 
b/tools/gdb/python/classic_printer.py
index 86e0eeb..121edc8 100644
--- a/tools/gdb/python/classic_printer.py
+++ b/tools/gdb/python/classic_printer.py
@@ -1,7 +1,10 @@
 #
 # RTEMS Classic pretty printers for GDB
 #
-import classic
+
+from __future__ import absolute_import
+
+from . import classic
 import gdb
 
 class attribute:
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 08/16] Py2/3 compliant tools/gdb/python/threads.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/threads.py | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/gdb/python/threads.py b/tools/gdb/python/threads.py
index 690f77f..d050acc 100644
--- a/tools/gdb/python/threads.py
+++ b/tools/gdb/python/threads.py
@@ -31,13 +31,15 @@
 # RTEMS Threads Support
 #
 
+from __future__ import absolute_import
+
 import gdb
 
-import chains
-import objects
-import percpu
-import rbtrees
-import time
+from . import chains
+from . import objects
+from . import percpu
+from . import rbtrees
+from . import time
 
 def task_chain(chain):
 tasks = []
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 14/16] Py2/3 compliant tools/gdb/python/helper.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/helper.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/gdb/python/helper.py b/tools/gdb/python/helper.py
index e9fe2f8..ac7c944 100644
--- a/tools/gdb/python/helper.py
+++ b/tools/gdb/python/helper.py
@@ -30,6 +30,8 @@
 # RTEMS GDB support helper routins.
 #
 
+from __future__ import print_function
+
 import gdb
 
 def tasks_printer_routine(wait_queue):
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 16/16] Py2/3 compliant tools/gdb/python/supercore_printer.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/supercore_printer.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/gdb/python/supercore_printer.py 
b/tools/gdb/python/supercore_printer.py
index 61241e3..d144b40 100644
--- a/tools/gdb/python/supercore_printer.py
+++ b/tools/gdb/python/supercore_printer.py
@@ -30,9 +30,11 @@
 # RTEMS Supercore pretty printers for GDB
 #
 
-import objects
+from __future__ import absolute_import
+
+from . import objects
 import itertools
-import threads
+from . import threads
 
 class id:
 """Print an object given the ID. Print using the struct display hint and an
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 13/16] Py2/3 compliant tools/gdb/python/rbtrees.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/rbtrees.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/gdb/python/rbtrees.py b/tools/gdb/python/rbtrees.py
index 2e4c9e7..ace598c 100644
--- a/tools/gdb/python/rbtrees.py
+++ b/tools/gdb/python/rbtrees.py
@@ -31,6 +31,8 @@
 # RTEMS Red/Black Tree Support
 #
 
+from __future__ import print_function
+
 import gdb
 
 rbt_left = 0
@@ -49,7 +51,7 @@ class node:
 self.node_ptr = node_ptr
 self.node_val = None
 if node_ptr != 0:
-print ''
+print('')
 self.node_val = node_ptr.dereference()
 
 def __str__(self):
@@ -138,7 +140,7 @@ class node:
 def to_string(self):
 if self.null():
 return 'NULL'
-print ']]] here'
+print('')
 return 'Parent:%s Child:%s Color:%s' % (self.node_val['parent'],
 self.node_val['child'],
 self.node_val['color'])
-- 
2.21.0 (Apple Git-122.2)

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

[PATCH v1 10/16] Py2/3 compliant tools/gdb/python/watchdog.py

2020-03-18 Thread Anmol mishra 
From: Anmol Mishra 

---
 tools/gdb/python/watchdog.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/gdb/python/watchdog.py b/tools/gdb/python/watchdog.py
index 6a80421..b758e11 100644
--- a/tools/gdb/python/watchdog.py
+++ b/tools/gdb/python/watchdog.py
@@ -31,10 +31,13 @@
 # RTEMS Watchdog Support
 #
 
+from __future__ import print_function
+from __future__ import absolute_import
+
 import gdb
 
-import chains
-import objects
+from . import chains
+from . import objects
 
 class state:
 
-- 
2.21.0 (Apple Git-122.2)

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

[rtems-examples PATCH v2 2/2] filesystem: Add checks for rtems-bin2c

2020-03-18 Thread Vijay Kumar Banerjee 
---
 file_io/crc/wscript| 23 ---
 filesystem/fat_ramdisk/wscript | 18 +-
 2 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/file_io/crc/wscript b/file_io/crc/wscript
index 531da20..45384a9 100644
--- a/file_io/crc/wscript
+++ b/file_io/crc/wscript
@@ -26,14 +26,15 @@ def build(bld):
 #
 # Package the root file system as a C file.
 #
-rootfs.build_from_src_root(bld,
-   name = 'fs-root',
-   root = 'rootfs')
-
-bld(features = 'c cprogram',
-target = 'crc.exe',
-includes = bld.includes,
-defines = bld.defines,
-source = ['init.c',
-  'fs-root-tar.c',
-  'crc_32.c'])
+if rtems.check_env(bld, 'RTEMS_BIN2C'):
+rootfs.build_from_src_root(bld,
+   name = 'fs-root',
+   root = 'rootfs')
+
+bld(features = 'c cprogram',
+target = 'crc.exe',
+includes = bld.includes,
+defines = bld.defines,
+source = ['init.c',
+  'fs-root-tar.c',
+  'crc_32.c'])
diff --git a/filesystem/fat_ramdisk/wscript b/filesystem/fat_ramdisk/wscript
index a980187..ecf216f 100644
--- a/filesystem/fat_ramdisk/wscript
+++ b/filesystem/fat_ramdisk/wscript
@@ -26,17 +26,17 @@ def build(bld):
 #
 # Package the root file system as a C file.
 #
-rootfs.build_from_src_root(bld,
-   name = 'fs-root',
-   root = 'rootfs')
+if rtems.check_env(bld, 'RTEMS_BIN2C', 'RTEMS_TLD'):
+rootfs.build_from_src_root(bld,
+   name = 'fs-root',
+   root = 'rootfs')
 
-bld(features = 'c cprogram',
-target = 'fat_ramdisk.exe',
-includes = bld.includes,
-defines = bld.defines,
-source = ['init.c', 'fs-root-tar.c'])
+bld(features = 'c cprogram',
+target = 'fat_ramdisk.exe',
+includes = bld.includes,
+defines = bld.defines,
+source = ['init.c', 'fs-root-tar.c'])
 
-if rtems.check_env(bld, 'RTEMS_TLD'):
 bld(features = 'c rtrace',
 target = 'fat_ramdisk.texe',
 includes = bld.includes,
-- 
2.21.1

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

[rtems-examples PATCH v2 1/2] Update rtems_waf

2020-03-18 Thread Vijay Kumar Banerjee 
---
 rtems_waf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems_waf b/rtems_waf
index e7a75df..ad08908 16
--- a/rtems_waf
+++ b/rtems_waf
@@ -1 +1 @@
-Subproject commit e7a75df6531beec1c1b0d18fcaf2cfce7693920c
+Subproject commit ad08908c452c6a9bbb3bf7bbbcc9fc03fe46cc7f
-- 
2.21.1

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

RTEMS python standardisation

2020-03-18 Thread Anmol Mishra 
Hello,
I know you must be consumed into other work and repositories, but I have
been waiting for your response on the proposal and patch. I just need a
starting point and Is there any guide for python repositories testing, I
can see a lot of discussion in the past 2 days. I really look forward to
hearing from you.

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

Re: Build FreeBSD: FAILED 5/rtems-mips on x86_64-freebsd12.1 (mipstx39-rtems5-gdb-8.0.1-x86_64-freebsd12.1-1)

2020-03-18 Thread Chris Johns 
On 18/3/20 5:29 pm, Sebastian Huber wrote:
> On 18/03/2020 07:24, Chris Johns wrote:
>> On 18/3/20 5:12 pm, Sebastian Huber wrote:
>>> I don't have this fail on my FreeBSD 12.1 VM:
>>>
>>> https://lists.rtems.org/pipermail/build/2020-March/011712.html
>>>
>>> I use the GNU sed to build the tools.
>>>
>> Hmmm, I am undecided if it is too late in the release cycle to check for GNU 
>> sed
>> and build it if it is not present? I know we do not strictly meet GCC build
>> prereqs using a BSD sed.
> The GCC maintainer told me that a GNU sed is a build requirement and the 
> FreeBSD
> maintainer told me that they don't want to add GNU sed features to the BSD 
> sed.
> I use the GNU sed for more than one year to build the tools.

The issue is breaking the building adding the logic to the RSB at this point in
time.

I am happy to do this for RTEMS 6 and then we can look at a back port for 5.2.

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

Re: Build FreeBSD: FAILED 5/rtems-mips on x86_64-freebsd12.1 (mipstx39-rtems5-gdb-8.0.1-x86_64-freebsd12.1-1)

2020-03-18 Thread Sebastian Huber 

On 18/03/2020 07:24, Chris Johns wrote:


On 18/3/20 5:12 pm, Sebastian Huber wrote:

I don't have this fail on my FreeBSD 12.1 VM:

https://lists.rtems.org/pipermail/build/2020-March/011712.html

I use the GNU sed to build the tools.


Hmmm, I am undecided if it is too late in the release cycle to check for GNU sed
and build it if it is not present? I know we do not strictly meet GCC build
prereqs using a BSD sed.
The GCC maintainer told me that a GNU sed is a build requirement and the 
FreeBSD maintainer told me that they don't want to add GNU sed features 
to the BSD sed. I use the GNU sed for more than one year to build the tools.

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

Re: Build FreeBSD: FAILED 5/rtems-mips on x86_64-freebsd12.1 (mipstx39-rtems5-gdb-8.0.1-x86_64-freebsd12.1-1)

2020-03-18 Thread Chris Johns 
On 18/3/20 5:12 pm, Sebastian Huber wrote:
> I don't have this fail on my FreeBSD 12.1 VM:
> 
> https://lists.rtems.org/pipermail/build/2020-March/011712.html
> 
> I use the GNU sed to build the tools.
> 

Hmmm, I am undecided if it is too late in the release cycle to check for GNU sed
and build it if it is not present? I know we do not strictly meet GCC build
prereqs using a BSD sed.

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

Re: Build FreeBSD: FAILED 5/rtems-mips on x86_64-freebsd12.1 (mipstx39-rtems5-gdb-8.0.1-x86_64-freebsd12.1-1)

2020-03-18 Thread Sebastian Huber 

I don't have this fail on my FreeBSD 12.1 VM:

https://lists.rtems.org/pipermail/build/2020-March/011712.html

I use the GNU sed to build the tools.

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

Re: Build Linux: FAILED 6/rtems-riscv on x86_64-linux-gnu (riscv-rtems6-gdb-771dd3a-x86_64-linux-gnu-1)

2020-03-18 Thread Sebastian Huber 

On 18/03/2020 05:53, j...@rtems.org wrote:

libtool: compile:  gcc -O2 -g -pipe -I/home/joel/rtems-cron-6/rtems-source-builder/rtems/build/tmp/sb-1001/6/rtems-riscv/home/joel/rtems-cron-6/tools/6/include -DHAVE_CONFIG_H -I. -I../../sourceware-mirror-binutils-gdb-771dd3a/bfd 
-DBINDIR=\"/home/joel/rtems-cron-6/tools/6/bin\" 
-DLIBDIR=\"/home/joel/rtems-cron-6/tools/6/lib\" -I. 
-I../../sourceware-mirror-binutils-gdb-771dd3a/bfd 
-I../../sourceware-mirror-binutils-gdb-771dd3a/bfd/../include 
-DHAVE_riscv_elf32_vec -DHAVE_riscv_elf64_vec -DHAVE_elf64_le_vec 
-DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -W -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wshadow 
-I../../sourceware-mirror-binutils-gdb-771dd3a/bfd/../zlib -g -O2 -MT elflink.lo -MD -MP -MF .deps/elflink.Tpo -c ../../sourceware-mirror-binutils-gdb-771dd3a/bfd/elflink.c -o elflink.o

no
configure: WARNING: libipt is missing or unusable; some features may be 
unavailable.
../../sourceware-mirror-binutils-gdb-771dd3a/bfd/elfxx-riscv.c: In function 
'riscv_parse_subset':
../../sourceware-mirror-binutils-gdb-771dd3a/bfd/elfxx-riscv.c:1493:3: error: 
'for' loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < ARRAY_SIZE (parse_config); ++i) {
^
../../sourceware-mirror-binutils-gdb-771dd3a/bfd/elfxx-riscv.c:1493:3: note: 
use option -std=c99 or -std=gnu99 to compile your code


I sent a patch for this one:

https://sourceware.org/pipermail/binutils/2020-March/110265.html

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

Re: [PATCH v2] eng: Add Python development guidelines

2020-03-18 Thread Chris Johns 
On 18/3/20 4:52 pm, Sebastian Huber wrote:
> On 18/03/2020 06:28, Chris Johns wrote:
> 
>> Build System
>> 
>>
>> Any need to have something about the build system to be used to wrap a 
>> project?
>> There is waf as used in rtems-tools and then are are Python packaging 
>> systems.
>>
>> Should this be covered?
> Yes, this should be covered, but I would like to do this in a follow up 
> patch. I
> guess this topic needs a bit more consideration. Python seems to have a lot of
> specialized tools for the module packaging, testing, and deployment. I am not
> really a Python expert. So I don't know what works best for us.

We are a bit different because we are not attempting to be part of the python
ecosystem as we provide tools as stand along command line interfaces. There is
nothing stopping us moving a python tool to another language or the other way
around without a user needing to change anything.

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