Opkg update failed on snapshot (arm_cortex-a9_vfpv3-d16)

Installing and Using OpenWrt
1

I installed latest snapshot and get this error when trying to opkg update, it's been doing this the last 3 snapshots. Router is wrt32x. Any ideas?

opkg
opkg1210×706 25.6 KB

2

Definitely related to this: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blobdiff;f=target/linux/mvebu/cortexa9/target.mk;h=cdd4d86e493668f455f6de6edb11cfc81e54f8af;hp=2a75599bc9a36a9aef7e37f9011409ac8a941249;hb=2d61f8821c7cf99354e904139226c132554ba180;hpb=43d1d88510621801d66a0a7f46f4c4f44d89633a

Looks like the buildbots either:

  • Haven't got to that new package arch yet
  • Don't know that they need to build the new arch
  • Some other breakage

https://buildbot.openwrt.org/master/packages/grid

The jobs have failed ever since that change though by the looks of it?

3

Looks like the phase2 buildbot has now been fixed by adding the new arm_cortex-a9_vfpv3-d16 package architecture.

The buildbot has not yet built it for the first time, so the new packages can't yet be downloaded.

4

On a side note, that whole "fix" is depressing. The Marvell EBU target should just be split, keeping the Armada 370 in same bag is preventing users from fully using the most recent SoCs (which support both VFPv3 with 32 registers and NEON). :roll_eyes:

1 Like
5

I agree. The "fix" means weakening the code to the level of the weakest hardware, while the more powerful units do not fully utilise their CPU features.

1 Like
6

Thanks for the replies guys, thought it might have been something on my end.

That's unfortunate about the more powerful units and the most recent SoCs. I assume we can compile our own firmware with NEON built-in?

7

Yes, just make the appropriate change in your cloned tree.

8

How do we go about that pleas?

9

You should be able to use the config CONFIG_EXTRA_OPTIMIZATION, or alter your tree:

patch 
diff --git a/target/linux/mvebu/cortexa9/target.mk b/target/linux/mvebu/cortexa9/target.mk
index cdd4d86e49..9af3c95d7b 100644
--- a/target/linux/mvebu/cortexa9/target.mk
+++ b/target/linux/mvebu/cortexa9/target.mk
@@ -10,5 +10,5 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARDNAME:=Marvell Armada 37x/38x/XP
 CPU_TYPE:=cortex-a9
-CPU_SUBTYPE:=vfpv3-d16
+CPU_SUBTYPE:=neon
 KERNELNAME:=zImage dtbs

whether it is worth the trouble will depend on your use-case. If you are just interested in VPN with openssl I would not bother.

10

That's strictly cosmetic, it only changes the package architecture suffix. I don't bother with that on my builds (since it also implies rebuiding the toolchain, which isn't needed at all).
What I do is set CONFIG_TARGET_OPTIMIZATION="-Ofast -pipe -mcpu=cortex-a9 -mfpu=neon", and also modify target/linux/generic/pending-4.14/201-extra_optimization.patch in order to compile the kernel with -O3.

11

I assume you are referring to this:

CONFIG_TARGET_ARCH_PACKAGES="arm_cortex-a9_vfpv3"

which is the naming qualifier, but this is very relevant to code generation:

CONFIG_CPU_TYPE="cortex-a9+vfpv3"

which is what this thread is all about.

But, like most things, there is more than one way to relieve the feline of the fuzzy wuzzy. The last option on the GCC option list usually prevails, so if you override previous settings in any of the OPTIMIZATION possibilities of menuconfig, that is what you get.

pending-4.19/201* patch? Things are there in the pending-5.4/201* patch, so you should be able to just add the kernel config to the target/linux/mvebu/config-5.4 file, but this may still be a WIP.

12

Hmmm... this reminds me of my current problems. https://forum.openwrt.org/t/dependencies-problem-installing-luci-ssl-openssl-and-luci-ssl-nginx/58443/8

I was at first seeing a failure of dependency for Luci, on a snapshot install, then trying things again was having 1, 2, 3 4 things fail to download in the opkg update beforehand.

Using that buildbot status link you provided, I do see that mips24kc was building and then failed compile just a few minutes ago. Hmmm... How often do they build a new snapshot, thought it was only once a day? Or, is it tomorrow over wherever yet?

13

Don't think this is at all related.
The bots are data-driven; i.e. relevant commits drive things, not the wall clock.

14

Now the buildbot has built the renamed architecture and packages are available.
http://downloads.openwrt.org/snapshots/packages/arm_cortex-a9_vfpv3-d16/

1 Like
15

Yep! It does prevail, which is why I don't bother changing CPU_SUBTYPE.

I forgot to mention this isn't on master, but 19.07.

16

Since April 19, there have been no package updates for arm_cortex-a9_vfpv3.

So for opkg update can we just change

src/gz openwrt_luci https://downloads.openwrt.org/releases/19.07.1/packages/arm_cortex-a9_vfpv3/luci

to

src/gz openwrt_luci https://downloads.openwrt.org/releases/19.07.1/packages/arm_cortex-a9_vfpv3-d16/luci

and run with those?

17

Yes, you should be able to do that.

The only actual change is that with -d16 the compiled code has been restricted to use less CPU registers (due to the smallest CPU in the series, Armada 370), so users with the more powerful CPUs should be just fine with those -d16 packages.

18

Why was this change made? All my custom packages I had for years dont work now anymore, because of this change.

Is there a way to force to install them?

This breaks all custom build packages... I dont have any way to recompile them.

19

Thanks.

I had to modify my opkg update settings in luci as above and also add these architecture settings to the opkg.conf setting in luci as well:

arch all 1
arch noarch 1
arch arm_cortex-a9_vfpv3 10
arch arm_cortex-a9_vfpv3-d16 20

The 'arch arm_cortex-a9_vfpv3 10' is probably unnecessary now. :slight_smile: