AW: [PATCH 1/3] Remove duplicate GRETH driver

2020-10-26 Thread Gabriel.Moyano 
Hi Jiri,

My understanding was that one driver version was meant to be used with drvmgr 
(greth.c) and the other without it (greth2.c). May I ask why do you've chosen 
to remove greth.c and not greth2.c?

Thanks,
Gabriel

-Ursprüngliche Nachricht-
Von: devel  Im Auftrag von Jiri Gaisler
Gesendet: Sonntag, 25. Oktober 2020 23:26
An: devel@rtems.org
Betreff: [PATCH 1/3] Remove duplicate GRETH driver

* bsps/shared/net/greth2.c is being used instead
---
 bsps/shared/grlib-sources.am  |4 -
 bsps/shared/grlib/net/README  |7 -
 bsps/shared/grlib/net/greth.c | 1655 -
 bsps/shared/grlib/net/network_interface_add.c |   62 -
 4 files changed, 1728 deletions(-)
 delete mode 100644 bsps/shared/grlib/net/README
 delete mode 100644 bsps/shared/grlib/net/greth.c
 delete mode 100644 bsps/shared/grlib/net/network_interface_add.c

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

Re: LibBSD PowerPC motorola_shared BSP PCI Support

2020-10-26 Thread Heinz Junkes 
Good morning Chris,
i will now try out libbsd on a MVME6100 (beatnik).
Is the mentioned patch in git? Or do I have to prepare something special?
Thanks Heinz

> On 21. Oct 2020, at 02:44, Chris Johns  wrote:
> 
> On 21/10/20 2:52 am, Sebastian Huber wrote:
>> On 20/10/2020 03:52, chr...@rtems.org wrote:
>> 
>>> Tested on a MVME2700 (mvme2307) BSP:
>>> 
>>> nexus0: 
>>> pcib0 pcibus 0 on motherboard
>>> pci0:  on pcib0
>>> pci0:  at device 0.0 (no driver attached)
>>> pci0:  at device 11.0 (no driver attached)
>>> pci0:  at device 11.1 (no driver attached)
>>> pci0:  at device 12.0 (no driver attached)
>>> pci0:  at device 13.0 (no driver attached)
>>> pci0:  at device 14.0 (no driver attached)
>> Does this mean that the legacy x86 PCI bus driver works on this PowerPC 
>> board?
>> Are there no big-endian vs. little-endian issues?
> 
> It seems there are no issues with the limited testing I have performed. I have
> not done extensive testing but the if_dc.c (tulip driver) does probe the bus 
> and
> the correct device/vendor id is returned. The fact there currently is no 
> support
> for the 21140 on the MVMEW2700 in the driver is different issue and not 
> related
> to this patch.
> 
> I had a detailed look at the few calls that are being made and everything 
> seems
> to work as expected. There is a lot of hardware in the PCI bridges on these
> boards to handle endian mapping. The same hardware set up is being used as 
> 4.10
> and legacy stack combination and that works.
> 
> I suspect there may be changes needed in relation to resource allocations but 
> I
> thought those can be in follow up patches.
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH 1/3] Remove duplicate GRETH driver

2020-10-26 Thread Jiri Gaisler 

On 10/26/20 3:37 AM, gabriel.moy...@dlr.de wrote:
> Hi Jiri,
>
> My understanding was that one driver version was meant to be used with drvmgr 
> (greth.c) and the other without it (greth2.c). May I ask why do you've chosen 
> to remove greth.c and not greth2.c?


The problem I had was that greth.c contains SPARC assembly code and
cannot be built on any other architecture. I will change my patch to
disable greth.c on non-SPARC targets or try to replace the asssembly
code with macros as in greth2.c. Thanks for the feedback!

An other issue is that the two files are 99% identical, but only greth,c
seems to be maintained. PHY handling and multi-cast support are areas
where the files have diverged. But this is an other discussion ...


>
> Thanks,
> Gabriel
>
> -Ursprüngliche Nachricht-
> Von: devel  Im Auftrag von Jiri Gaisler
> Gesendet: Sonntag, 25. Oktober 2020 23:26
> An: devel@rtems.org
> Betreff: [PATCH 1/3] Remove duplicate GRETH driver
>
>   * bsps/shared/net/greth2.c is being used instead
> ---
>  bsps/shared/grlib-sources.am  |4 -
>  bsps/shared/grlib/net/README  |7 -
>  bsps/shared/grlib/net/greth.c | 1655 -
>  bsps/shared/grlib/net/network_interface_add.c |   62 -
>  4 files changed, 1728 deletions(-)
>  delete mode 100644 bsps/shared/grlib/net/README
>  delete mode 100644 bsps/shared/grlib/net/greth.c
>  delete mode 100644 bsps/shared/grlib/net/network_interface_add.c
>

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

Re: BSP for STM32H7

2020-10-26 Thread Sebastian Huber 

On 20/10/2020 18:11, Sebastian Huber wrote:


Hello,

I rebased the BSP for the STM32H7 which was developed March/April this 
year to the current master. It is available for review here (patch set 
is too big for the mailing list):


https://git.rtems.org/sebh/rtems.git/log/?h=stm32h7

If nobody objects, then I will check in the BSP on this Friday.

--
Sebastian Huber, embedded brains GmbH

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

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

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

Re: BSP for STM32H7

2020-10-26 Thread Joel Sherrill 
On Mon, Oct 26, 2020, 8:29 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 20/10/2020 18:11, Sebastian Huber wrote:
>
> > Hello,
> >
> > I rebased the BSP for the STM32H7 which was developed March/April this
> > year to the current master. It is available for review here (patch set
> > is too big for the mailing list):
> >
> > https://git.rtems.org/sebh/rtems.git/log/?h=stm32h7
> If nobody objects, then I will check in the BSP on this Friday.
>

I don't see any need to wait until then.

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Way to use Older GDB on Cygwin rtems6

2020-10-26 Thread Sebastian Huber 

Hello Joel,

I updated the tools today to the latest upstream versions. Maybe the bug 
is already fixed. If not, please add a bug report for GDB.


--
Sebastian Huber, embedded brains GmbH

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

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

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

Re: Way to use Older GDB on Cygwin rtems6

2020-10-26 Thread Joel Sherrill 
On Mon, Oct 26, 2020 at 9:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> I updated the tools today to the latest upstream versions. Maybe the bug
> is already fixed. If not, please add a bug report for GDB.
>

https://sourceware.org/bugzilla/show_bug.cgi?id=26757 was filed last week.

I don't expect this to get fixed quickly and it is preventing further
testing on
Cygwin. And maybe mingw based on what others report. I just haven't tried
that yet.

--joel

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems-bsp-builder and rtems6 vs rtems7

2020-10-26 Thread Joel Sherrill 
Hi

I tried one of my build sweeps on rtems7 and there were some issues. First
the arm gcc didn't build but that is likely transient.  The
rtems-bsp-builder had a complete set of failures -- all 1696 because the
target used was rtems6.

https://lists.rtems.org/pipermail/build/2020-October/020269.html

/home/joel/rtems-cron-7/rtems/configure --target=arm-\
  rtems6 --enable-rtemsbsp=beagleboardxm --prefix=/home/joel/rtems-\
  cron-7/tools/7/bsps --enable-rtems-debug --enable-networking\
  --disable-smp

rtems-bsp-builder does not take target or version as an argument so it must
be generated internally. Is there a way to make it build for 7 instead of
defaulting to 6?

Also there is no way from the subject line in the build list archives to
tell 5 v 6 v 7.

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

Re: BSP for STM32H7

2020-10-26 Thread Gedare Bloom 
I had taken a quick look at it. Lot of HAL files from vendor but
licenses look good to me so I have no complaints.

On Mon, Oct 26, 2020 at 7:53 AM Joel Sherrill  wrote:
>
>
>
> On Mon, Oct 26, 2020, 8:29 AM Sebastian Huber 
>  wrote:
>>
>> On 20/10/2020 18:11, Sebastian Huber wrote:
>>
>> > Hello,
>> >
>> > I rebased the BSP for the STM32H7 which was developed March/April this
>> > year to the current master. It is available for review here (patch set
>> > is too big for the mailing list):
>> >
>> > https://git.rtems.org/sebh/rtems.git/log/?h=stm32h7
>> If nobody objects, then I will check in the BSP on this Friday.
>
>
> I don't see any need to wait until then.
>>
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: [GSoC Mentors] Announcing GSoC 2021 with a few changes

2020-10-26 Thread Joel Sherrill 
FYI GSoC 2021 and a summary of the changes.

Biggest one from our perspective is that the projects are supposed to be
geared to 1/2 as many student hours of work.

--joel

-- Forwarded message -
From: 'sttaylor' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: Mon, Oct 26, 2020 at 1:04 PM
Subject: [GSoC Mentors] Announcing GSoC 2021 with a few changes
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>


Hello GSoC Mentors and Org Admins,

We are pleased to announce Google Summer of Code 2021 ,
the 17th consecutive year of the program!

As many of you might have heard if you attended the Mentor Summit a couple
of weeks ago (or chatted with someone who did) we are making a few changes
for the 2021 program. We’ve spent a lot of time evaluating the GSoC program
and have been looking at where we can make some changes to help meet the #1
goal of GSoC - bring new, diverse contributors into your communities that
stay in your communities after their GSoC program ends. And with the
challenges of the pandemic and the strains it has put on everyone’s time
(students, mentors and org admins alike) we are looking to provide more
flexibility in 2021.

What are the changes for 2021 from 2020?

   1. *Smaller project size** - *all students participating in the 2021
   program will be working on a 175 hour project (instead of a 350 hr
   project). This change will also result in a few other changes including the
   student stipend being cut in half.


   - Currently we are missing out on many wonderful students who could
   never commit to such a huge project and time commitment but would be great
   contributors to your community. This is a significant change as we now are
   no longer strongly encouraging students to focus only on GSoC over their
   summer. Students have many other responsibilities especially during the
   pandemic that make it hard for them to spend 30 hours a week on a project.
   - We realize this is going to require all of you to think about smaller
   projects and update your project ideas which is why we wanted to give you
   3+ months to start talking it through with your communities.
   - The mentor stipends will be adjusted to $400 per student mentored. In
   feedback from the mentor summit it was pointed out that the effort from
   mentors will not be half as much even though the project size is cut in
   half so we adjusted from $250 to $400.


   1. *Shortened coding period* - the *coding period will be 10 weeks* with
   a lot more flexibility for the mentor and student to decide together how
   they want to spread the work out over the summer. Some folks may choose to
   stick to a 17-18 hour a week schedule with their students, others may
   factor in a couple of breaks during the program (for student and mentor)
   and some may have students focus 30 hours a week on their project so they
   wrap up in 6 weeks. This also makes it a lot easier for students with
   finals or other commitments (weddings, etc.) to adjust their schedules.
   2.

   *2 evaluations  (instead of 3)* - There will be an evaluation after 5
   weeks and the final evaluation will take place after the 10th week. We are
   also no longer requiring students complete their first evaluation (though
   we encourage them to do so), so if a student doesn’t complete the first
   evaluation they will not automatically be removed from the program. They
   are still required to complete the final evaluation.
   3.

   *Eligibility requirements* - In 2020 there are many ways students are
   learning and we want to acknowledge that so we will be allowing students
   who are 18 years old AND currently enrolled (or accepted into) a
   post-secondary academic program as of May 17, 2021 or have graduated from a
   post-secondary academic program between December 1, 2020 and May 17, 2021
   to apply to the GSoC program.


   - What this means is that now the program will be open to folks
   participating in a variety of different academic programs, not just
   accredited university programs. This includes licensed coding camps,
   community colleges, and many other programs that may not be accredited yet
   but are post-secondary academic programs.

These changes were made to help find more diverse students who we hope will
stay involved in your communities after their GSoC ends. We look forward to
these changes and will definitely be getting feedback from all of you as
the 2021 program goes on to see what is working and what we should consider
adjusting for any possible future program.

The program announcement

, timeline ,
marketing materials
 (slide
deck, flyers), FAQs

Re: BSP for STM32H7

2020-10-26 Thread Chris Johns 
On 27/10/20 12:29 am, Sebastian Huber wrote:
> On 20/10/2020 18:11, Sebastian Huber wrote:
> 
>> Hello,
>>
>> I rebased the BSP for the STM32H7 which was developed March/April this year 
>> to
>> the current master. It is available for review here (patch set is too big for
>> the mailing list):
>>
>> https://git.rtems.org/sebh/rtems.git/log/?h=stm32h7
> If nobody objects, then I will check in the BSP on this Friday.
> 

Is this different to master ...

https://git.rtems.org/sebh/rtems.git/commit/?h=stm32h7&id=79e364c24510f794be3490e0048b61a112eeed0a

... ?

Otherwise it looks good.

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

Re: rtems-bsp-builder and rtems6 vs rtems7

2020-10-26 Thread Chris Johns 
On 27/10/20 2:49 am, Joel Sherrill wrote:
> Hi
> 
> I tried one of my build sweeps on rtems7 and there were some issues. First the
> arm gcc didn't build but that is likely transient.  The rtems-bsp-builder had 
> a
> complete set of failures -- all 1696 because the target used was rtems6.
> 
> https://lists.rtems.org/pipermail/build/2020-October/020269.html
> 
> /home/joel/rtems-cron-7/rtems/configure --target=arm-\
>       rtems6 --enable-rtemsbsp=beagleboardxm --prefix=/home/joel/rtems-\
>       cron-7/tools/7/bsps --enable-rtems-debug --enable-networking\
>       --disable-smp
> 
> rtems-bsp-builder does not take target or version as an argument so it must be
> generated internally. Is there a way to make it build for 7 instead of
> defaulting to 6?
> 
> Also there is no way from the subject line in the build list archives to tell 
> 5
> v 6 v 7.

There is no option to set an RTEMS version. I could be added but I am not sure
how much work it would be.

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

Re: rtems-bsp-builder and rtems6 vs rtems7

2020-10-26 Thread Joel Sherrill 
On Mon, Oct 26, 2020, 6:14 PM Chris Johns  wrote:

> On 27/10/20 2:49 am, Joel Sherrill wrote:
> > Hi
> >
> > I tried one of my build sweeps on rtems7 and there were some issues.
> First the
> > arm gcc didn't build but that is likely transient.  The
> rtems-bsp-builder had a
> > complete set of failures -- all 1696 because the target used was rtems6.
> >
> > https://lists.rtems.org/pipermail/build/2020-October/020269.html
> >
> > /home/joel/rtems-cron-7/rtems/configure --target=arm-\
> >   rtems6 --enable-rtemsbsp=beagleboardxm --prefix=/home/joel/rtems-\
> >   cron-7/tools/7/bsps --enable-rtems-debug --enable-networking\
> >   --disable-smp
> >
> > rtems-bsp-builder does not take target or version as an argument so it
> must be
> > generated internally. Is there a way to make it build for 7 instead of
> > defaulting to 6?
> >
> > Also there is no way from the subject line in the build list archives to
> tell 5
> > v 6 v 7.
>
> There is no option to set an RTEMS version. I could be added but I am not
> sure
> how much work it would be.
>

I'll try to remember to file a ticket some don't forget about it. I assume
7 is just leading edge tools and until we get closer to a 6 release branch
we will bump 6 tools periodically. So testing 7 by building all bsps is
desirable but not pressing at the moment.

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

Re: rtems-bsp-builder and rtems6 vs rtems7

2020-10-26 Thread Chris Johns 
On 27/10/20 10:55 am, Joel Sherrill wrote:
> On Mon, Oct 26, 2020, 6:14 PM Chris Johns  > wrote:
> On 27/10/20 2:49 am, Joel Sherrill wrote:
> > Hi
> >
> > I tried one of my build sweeps on rtems7 and there were some issues. 
> First the
> > arm gcc didn't build but that is likely transient.  The 
> rtems-bsp-builder
> had a
> > complete set of failures -- all 1696 because the target used was rtems6.
> >
> > https://lists.rtems.org/pipermail/build/2020-October/020269.html
> >
> > /home/joel/rtems-cron-7/rtems/configure --target=arm-\
> >       rtems6 --enable-rtemsbsp=beagleboardxm --prefix=/home/joel/rtems-\
> >       cron-7/tools/7/bsps --enable-rtems-debug --enable-networking\
> >       --disable-smp
> >
> > rtems-bsp-builder does not take target or version as an argument so it 
> must be
> > generated internally. Is there a way to make it build for 7 instead of
> > defaulting to 6?
> >
> > Also there is no way from the subject line in the build list archives to
> tell 5
> > v 6 v 7.
> 
> There is no option to set an RTEMS version. I could be added but I am not 
> sure
> how much work it would be.
> 
> I'll try to remember to file a ticket some don't forget about it. I assume 7 
> is
> just leading edge tools and until we get closer to a 6 release branch we will
> bump 6 tools periodically. So testing 7 by building all bsps is desirable but
> not pressing at the moment.

Thank you. I have added it to my list. There is the building with waf.

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

Status update for autotools build system removal

2020-10-26 Thread Chris Johns 
Hi,

Nov 1st 2020 was set as the point to start removing the autotools build system
and so I wanting to see what the status is and if there are any blocking issues
that need to be discussed?

I am OK with the removal and I have not seen any issues on the BSPs I am working
with.

The tickets I can see on this task are:

https://devel.rtems.org/ticket/4081
https://devel.rtems.org/ticket/3828

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

Re: LibBSD PowerPC motorola_shared BSP PCI Support

2020-10-26 Thread Chris Johns 
On 26/10/20 7:32 pm, Heinz Junkes wrote:
> Good morning Chris,
> i will now try out libbsd on a MVME6100 (beatnik).
> Is the mentioned patch in git? 

The PCI patch is in rtems-libbsd.git on the master and 6-freebsd-12 branches.

> Or do I have to prepare something special?

Yes I think you may need to patch libbsd for the beatnik bvoard. I have not
looked at that board and the net drivers it needs. The current list is we have
in libbsd is:

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h?h=6-freebsd-12

The BSP support is handled here:

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h?h=6-freebsd-12

The define is based on the header guard for the BSP:

https://git.rtems.org/rtems/tree/bsps/powerpc/beatnik/include/bsp.h#n25

I hope this helps.

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