Continued GCC Support for m68k was Fwd: BountySource campaign for gcc PR/91851

[Joel Sherrill]

Hi

Passing this along. This needs to happen for m68k and coldfire to be
supported in GCC beyond the current release.

--joel

-- Forwarded message -
From: John Paul Adrian Glaubitz 
Date: Sat, Oct 19, 2019 at 4:58 AM
Subject: BountySource campaign for gcc PR/91851
To: 


Hello!

For anyone who isn't aware of it yet, there is an ongoing BountySource
campaign
for gcc PR/91851 [1] which seeks to convert the m68k backend to MODE_CC so
that
it can be kept in gcc versions beyond version 11.

The campaign is currently at $3,290 and can be found at [2].

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
> [2]
https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bfin rtems5 gcc build failed on FreeBSD 12

[Joel Sherrill]

On Wed, Oct 30, 2019 at 3:54 PM Chris Johns  wrote:

> On 30/10/19 11:52 pm, Joel Sherrill wrote:
> > Does anyone else see this on FreeBSD? Seems to be ok on CentOS.
>
> No 
>
> https://lists.rtems.org/pipermail/build/2019-October/007287.html
>
> > gmake[4]: Leaving directory
> '/usr/home/joel/rtems-cron-5/rtems-source-builder/rt
> >
> ems/build/microblaze-rtems5-gcc-fb371a33fa6-newlib-6661a67-i386-freebsd12.0-1/bu
> > ild/microblaze-rtems5/bs/libgcc'
>
> Hmmm 'i386-freebsd12.0', why are you building on a 32bit version of
> FreeBSD?
>

Good spot. Wonder why Jeff didn't get a 64-bit version. I will get him to
put the 64-bit
version on it.

--joel


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

Re: bfin rtems5 gcc build failed on FreeBSD 12

[Chris Johns]

On 30/10/19 11:52 pm, Joel Sherrill wrote:
> Does anyone else see this on FreeBSD? Seems to be ok on CentOS.

No 

https://lists.rtems.org/pipermail/build/2019-October/007287.html

> gmake[4]: Leaving directory 
> '/usr/home/joel/rtems-cron-5/rtems-source-builder/rt
> ems/build/microblaze-rtems5-gcc-fb371a33fa6-newlib-6661a67-i386-freebsd12.0-1/bu
> ild/microblaze-rtems5/bs/libgcc'

Hmmm 'i386-freebsd12.0', why are you building on a 32bit version of FreeBSD?

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

Re: [PATCH v2] [rsb] Update Spike build

[Joel Sherrill]

>From my perspective, yes. If it breaks something else, we can fix that.

On Wed, Oct 30, 2019 at 9:47 AM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:

> OK to push?
>
> On Tue, 29 Oct 2019 at 09:25, Hesham Almatary
>  wrote:
> >
> > On Mon, 28 Oct 2019 at 23:15, Joel Sherrill  wrote:
> > >
> > >
> > >
> > > On Mon, Oct 28, 2019 at 5:20 AM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
> > >>
> > >> On Mon, 28 Oct 2019 at 04:01, Chris Johns  wrote:
> > >> >
> > >> >
> > >> >
> > >> > On 28/10/19 9:21 am, Hesham Almatary wrote:
> > >> > >
> > >> > >
> > >> > > On Sun, 27 Oct 2019 at 20:54, Chris Johns  > >> > > > wrote:
> > >> > >
> > >> > > On 27/10/19 9:37 pm, Hesham Almatary wrote:
> > >> > > > Yeah fesvr is now part of Spike in-tree. I didn't like it
> had to be
> > >> > > > built separately either [1].
> > >> > > >
> > >> > > > Joel, AFAIR, dtc was always needed.
> > >> > >
> > >> > > Please have the package build FDT if it is needed. Do no rely
> on it being
> > >> > > installed as some hosts do not have a package to install.
> > >> > >
> > >> > > I think Joel has already added it
> > >> > >
> https://github.com/RTEMS/rtems-source-builder/blob/master/bare/config/devel/spike.bset#L7
> > >> > >
> > >> >
> > >> > Thanks.
> > >> >
> > >> > The config file has some issues. I am fixing the %hash issues. Is
> the patch
> > >> > still needed if the version used has the fix?
> > >> >
> > >> The version that has the fix is a recent one, and it has fesvr in its
> > >> source tree, hence, there's no separate fesvr any more. The patch will
> > >> still be needed to get rid of the separate fesvr build for this recent
> > >> Spike revision.
> > >
> > >
> > > If you are bumping to a version which doesn't need my patch, great!
> > >
> > Yes, that's the point of the patch along with removing fesvr build.
> >
> > > Is this all pushed now?
> > >
> > Not yet, waiting for approval.
> >
> > >>
> > >> > Chris
> > >> > ___
> > >> > devel mailing list
> > >> > devel@rtems.org
> > >> > http://lists.rtems.org/mailman/listinfo/devel
> > >> ___
> > >> devel mailing list
> > >> devel@rtems.org
> > >> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] [rsb] Update Spike build

[Hesham Almatary]

OK to push?

On Tue, 29 Oct 2019 at 09:25, Hesham Almatary
 wrote:
>
> On Mon, 28 Oct 2019 at 23:15, Joel Sherrill  wrote:
> >
> >
> >
> > On Mon, Oct 28, 2019 at 5:20 AM Hesham Almatary 
> >  wrote:
> >>
> >> On Mon, 28 Oct 2019 at 04:01, Chris Johns  wrote:
> >> >
> >> >
> >> >
> >> > On 28/10/19 9:21 am, Hesham Almatary wrote:
> >> > >
> >> > >
> >> > > On Sun, 27 Oct 2019 at 20:54, Chris Johns  >> > > > wrote:
> >> > >
> >> > > On 27/10/19 9:37 pm, Hesham Almatary wrote:
> >> > > > Yeah fesvr is now part of Spike in-tree. I didn't like it had to 
> >> > > be
> >> > > > built separately either [1].
> >> > > >
> >> > > > Joel, AFAIR, dtc was always needed.
> >> > >
> >> > > Please have the package build FDT if it is needed. Do no rely on 
> >> > > it being
> >> > > installed as some hosts do not have a package to install.
> >> > >
> >> > > I think Joel has already added it
> >> > > https://github.com/RTEMS/rtems-source-builder/blob/master/bare/config/devel/spike.bset#L7
> >> > >
> >> >
> >> > Thanks.
> >> >
> >> > The config file has some issues. I am fixing the %hash issues. Is the 
> >> > patch
> >> > still needed if the version used has the fix?
> >> >
> >> The version that has the fix is a recent one, and it has fesvr in its
> >> source tree, hence, there's no separate fesvr any more. The patch will
> >> still be needed to get rid of the separate fesvr build for this recent
> >> Spike revision.
> >
> >
> > If you are bumping to a version which doesn't need my patch, great!
> >
> Yes, that's the point of the patch along with removing fesvr build.
>
> > Is this all pushed now?
> >
> Not yet, waiting for approval.
>
> >>
> >> > Chris
> >> > ___
> >> > devel mailing list
> >> > devel@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] user: Document patch review process

[Sebastian Huber]

On 28/10/2019 22:03, Chris Johns wrote:

On 29/10/19 1:42 am, Sebastian Huber wrote:

Any objections to commit this patch?

Should "Must be done by an RTEMS Maintainer" be "Push performed by an approved
RTEMS Committer" ? This covers "Maintainers" and those with commit access to a
specific area.

Otherwise this look good.


Thanks for having a look at it. I checked in the patches.  The last one 
with your changes.


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

bfin rtems5 gcc build failed on FreeBSD 12

[Joel Sherrill]

Hi

Does anyone else see this on FreeBSD? Seems to be ok on CentOS.

gmake[4]: Leaving directory
'/usr/home/joel/rtems-cron-5/rtems-source-builder/rt
ems/build/microblaze-rtems5-gcc-fb371a33fa6-newlib-6661a67-i386-freebsd12.0-1/bu
ild/microblaze-rtems5/bs/libgcc'
gmake[3]: *** [Makefile:1198: multi-do] Error 1
gmake[3]: Leaving directory
'/usr/home/joel/rtems-cron-5/rtems-source-builder/rt
ems/build/microblaze-rtems5-gcc-fb371a33fa6-newlib-6661a67-i386-freebsd12.0-1/bu
ild/microblaze-rtems5/libgcc'
gmake[2]: *** [Makefile:125: all-multi] Error 2
gmake[2]: *** Waiting for unfinished jobs
/tmp//cc2TKNc9.s: Assembler messages:
/tmp//cc2TKNc9.s:70: Fatal error: operand must be absolute in range
8000..7f
ff, not 3f80
Thanks.

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

Re: ARM BSP build failure.

[Sebastian Huber]

On 30/10/2019 10:29, Chris Johns wrote:

configure:3472: checking whether the C compiler works
configure:3494: arm-rtems5-gcc -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16
-mfloat-abi=hard -O2 -g -ffunction-sections -fdata-sections   conftest.c  >&5

/opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld: error:
/tmp//cch8jDwi.o uses VFP register arguments, a.out does not

/opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld: failed
to merge target specific data of file /tmp//cch8jDwi.o

/opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld:
warning: cannot find entry symbol _start; defaulting to 8000


This is a very strange error. Maybe you can run the command by hand to 
figure out what is going wrong.


Maybe the native Binutils are used at some stage?

--
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: Add chapter for newib build in RTEMS Docs

[Vaibhav Gupta]

So what's the final stand on this?

Should be working on standalone guide or add the contents to RTEMS Software
Engineering guide as suggested by Sebastian?

--Vaibhav


On Fri, Sep 13, 2019, 5:40 PM Vaibhav Gupta 
wrote:

> Well I have no problem in working on standalone guide or adding it to
> Software Engineering Manual. I saw that most of the development related
> work,
> even about patches, were in User Manual, so I proposed it at first place.
>
> - Vaibhav
>
> On Fri, Sep 13, 2019 at 10:40 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 13/09/2019 03:34, Chris Johns wrote:
>> > On 13/9/19 8:42 am, Joel Sherrill wrote:
>> >> On Thu, Sep 12, 2019 at 2:09 PM Gedare Bloom  wrote:
>> >>> Hello Vaibhav,
>> >>>
>> >>> It would be nice to provide such documentation, but I don't know that
>> >>> we have an existing location that would be an ideal fit. I think the
>> >>> topic is out of scope for User Manual. If you are motivated to write
>> >>> something though, you could prepare it first as a standalone guide.
>> >> If we have a name for the document like "Maintainers Guide" or
>> something,
>> >> it could have a focus on procedures that only core developers would
>> need.
>> >>
>> >> + bootstrapping newlib and building it independently
>> >> + modifying gcc, running tests,
>> >> + submitting Coverity runs
>> >> + running Doxygen
>> >> + ...
>> > These are all valid and important however can these reside in the
>> Software
>> > Engineering manual?
>> >
>> > We current have ...
>> >
>> >   1. RTEMS Software Engineering
>> >   2. RTEMS Filesystem Design Guide
>> >   3. RTEMS Development Environment Guide
>> >   4. RTEMS BSP and Driver Guide
>> >
>> > plus 'RTEMS BSP and Driver Guide' which I am not sure about. All these
>> cover
>> > some aspect of maintaining and developing RTEMS. Should we be
>> considering
>> > consolidation rather than expansion?
>>
>> Yes, we should definitely aim to consolidate the documentation set and
>> not add new documents. I would put this topic into the RTEMS Software
>> Engineering.
>>
>> --
>> 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: ARM BSP build failure.

[Chris Johns]

On 30/10/19 7:17 pm, Sebastian Huber wrote:
> On 30/10/2019 07:18, Chris Johns wrote:
>> Hi,
>>
>> Building all ARM BSPs on master today I get ...
>>
>> checking for arm-rtems5-gcc... (cached) arm-rtems5-gcc
>> checking whether the C compiler works... no
>> configure: error: in
>> `/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c/lpc40xx_ea_ram':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
>> gmake[2]: *** [Makefile:1064: lpc40xx_ea_ram] Error 1
>> gmake[2]: Leaving directory 
>> '/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c'
>> gmake[1]: *** [Makefile:289: all-recursive] Error 1
>> gmake[1]: Leaving directory 
>> '/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c'
>>
>> Is the lpc40xx_ea_ram BSP OK?
> 
> I built all BSPs this week, however, with an older tool chain. What do you see
> in the config.log?

configure:3441: arm-rtems5-gcc -v >&5
Using built-in specs.
COLLECT_GCC=arm-rtems5-gcc
COLLECT_LTO_WRAPPER=/opt/work/rtems/5/libexec/gcc/arm-rtems5/7.4.0/lto-wrapper
Target: arm-rtems5
Configured with: ../gcc-7.4.0/configure --prefix=/opt/work/rtems/5
--bindir=/opt/work/rtems/5/bin --exec_prefix=/opt/work/rtems/5
--includedir=/opt/work/rtems/5/include --libdir=/opt/work/rtems/5/lib
--libexecdir=/opt/work/rtems/5/libexe
c --mandir=/opt/work/rtems/5/share/man --infodir=/opt/work/rtems/5/share/info
--datadir=/opt/work/rtems/5/share --build=x86_64-freebsd12.0
--host=x86_64-freebsd12.0 --target=arm-rtems5 --disable-libstdcxx-pch
--with-gnu-as --with-gnu-ld
--verbose --with-newlib --disable-nls --without-included-gettext
--disable-win32-registry --enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp77
5,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_
u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plug
in --enable-libgomp --enable-languages=c,c++
Thread model: rtems
gcc version 7.4.0 20181206 (RTEMS 5, RSB
0956a2c089faf2600047577bb153afcaaba22288, Newlib 1d35a003f) (GCC)
configure:3452: $? = 0
configure:3441: arm-rtems5-gcc -V >&5
arm-rtems5-gcc: error: unrecognized command line option '-V'
arm-rtems5-gcc: fatal error: no input files
compilation terminated.
configure:3452: $? = 1
configure:3441: arm-rtems5-gcc -qversion >&5
arm-rtems5-gcc: error: unrecognized command line option '-qversion'; did you
mean '--version'?
arm-rtems5-gcc: fatal error: no input files
compilation terminated.
configure:3452: $? = 1
configure:3472: checking whether the C compiler works
configure:3494: arm-rtems5-gcc -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16
-mfloat-abi=hard -O2 -g -ffunction-sections -fdata-sections   conftest.c  >&5

/opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld: error:
/tmp//cch8jDwi.o uses VFP register arguments, a.out does not

/opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld: failed
to merge target specific data of file /tmp//cch8jDwi.o

/opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld:
warning: cannot find entry symbol _start; defaulting to 8000

collect2: error: ld returned 1 exit status


> This looks like a tool chain bug.

OK.

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

Re: [PATCH] bsps/riscv: UART - Read reg-shift from DTB to properly set/get registers

[Sebastian Huber]

Looks good.

--
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: ARM BSP build failure.

[Sebastian Huber]

On 30/10/2019 07:18, Chris Johns wrote:

Hi,

Building all ARM BSPs on master today I get ...

checking for arm-rtems5-gcc... (cached) arm-rtems5-gcc
checking whether the C compiler works... no
configure: error: in
`/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c/lpc40xx_ea_ram':
configure: error: C compiler cannot create executables
See `config.log' for more details
gmake[2]: *** [Makefile:1064: lpc40xx_ea_ram] Error 1
gmake[2]: Leaving directory '/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c'
gmake[1]: *** [Makefile:289: all-recursive] Error 1
gmake[1]: Leaving directory '/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c'

Is the lpc40xx_ea_ram BSP OK?


I built all BSPs this week, however, with an older tool chain. What do 
you see in the config.log?


This looks like a tool chain bug.

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

ARM BSP build failure.

[Chris Johns]

Hi,

Building all ARM BSPs on master today I get ...

checking for arm-rtems5-gcc... (cached) arm-rtems5-gcc
checking whether the C compiler works... no
configure: error: in
`/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c/lpc40xx_ea_ram':
configure: error: C compiler cannot create executables
See `config.log' for more details
gmake[2]: *** [Makefile:1064: lpc40xx_ea_ram] Error 1
gmake[2]: Leaving directory '/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c'
gmake[1]: *** [Makefile:289: all-recursive] Error 1
gmake[1]: Leaving directory '/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c'

Is the lpc40xx_ea_ram BSP OK?

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