[OpenWrt-Devel] [PATCH] mvebu, tegra: make CPU subtype default to vfp3-d16
chunkeey at gmail.com
Wed Apr 1 09:43:40 EDT 2020
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
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel