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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel