[OpenWrt-Devel] [PATCH] mvebu, tegra: make CPU subtype default to vfp3-d16

[Christian Lamparter]

On Wednesday, 1 April 2020 15:17:31 CEST Tomasz Maciej Nowak wrote:
> W dniu 31.03.2020 o 11:21, Petr Štetiar pisze:
> > Armada 370 and Tegra2 processors have only 16 double-precision
> > registers. The change introduced by commit 8dcc1087602e ("toolchain:
> > ARM: Fix toolchain compilation for gcc 8.x") switched accidentally the
> > toolchain for mvebu cortexa9 subtarget to cpu type with 32
> > double-precision registers.
> > 
> > This stems from gcc defaults which assume "vfpv3-d32" if only "vfpv3" as
> > mfpu is specified. That change resulted in unusable image, in which
> > kernel will kill userspace as soon as it causing "Illegal instruction".
> > 
> > In order to fix those issues Tomas in commit 2d61f8821c7c ("mvebu:
> > cortexa9: correct cpu subtype") and commit 43d1d8851062 ("tegra: correct
> > cpu subtype") changed the CPU subtype to explicit vfpv3-d16 which fixed
> > the above mentioned issue, but on the other end it has resulted in the
> > need of building packages for this new CPU subtype which is not wanted
> > due to the increased infrastructure costs, like disk space and
> > additional build time which is huge for packages feed.
> > 
> > So lets just take a step back and make the vfp3-d16 explicit again.
[...]
> > ---
> >  include/target.mk                     | 3 +++
> >  target/linux/mvebu/cortexa9/target.mk | 2 +-
> >  target/linux/tegra/Makefile           | 2 +-
> >  3 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/target.mk b/include/target.mk
> > index 9bd4c14936c1..94ea1a9e0001 100644
> > --- a/include/target.mk
> > +++ b/include/target.mk
> > @@ -179,6 +179,9 @@ ifeq ($(DUMP),1)
> >    endif
> >    ifneq ($(findstring arm,$(ARCH)),)
> >      CPU_TYPE ?= xscale
> > +    ifeq ($(CONFIG_SOFT_FLOAT),)
> > +      CPU_CFLAGS_vfpv3 = -mfpu=vfpv3-d16
> > +    endif

The question I'm pondering is: Do you really want to maintain this specifc maps
for this (only this arch) or not? Because I do think this will creep up sooner or
later again. So we could also defuse this a bit by replacing that monicer "vfpv3"
(as this is a gcc/binutils thing and not under our control) with something 
"clearly from OpenWrt". like CPU_CFLAGS_fpu = -mfpu=vfpv3-d16 (if that doesn't
clash with something else).

But then again, I'm not here to tell you what to do. If you want your patch as-is
then go for it! :D

Cheers,
Christian




_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel