zynqmp-pmu.bbclass: Fix issues with zynqmp-pmu and multilib

When using multilib the MULTILIB_VARIANTS variable is populated, this
triggers differing code paths in certain recipes. These are not desired
for the firmware building, since they modify the install paths.

Also set the DEFAULTTUNE to avoid changes to BASELIB/baselib when
multilib is used, as it attempts to set BASELIB based on 'tune-*'
overrides.

Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Acked-by: Alistair Francis <alistair.francis@xilinx.com>
Tested-by: Alistair Francis <alistair.francis@xilinx.com>

1 files changed, 4 insertions, 0 deletions

diff --git a/classes/zynqmp-pmu.bbclass b/classes/zynqmp-pmu.bbclass
index 3ebe4881..714eb96a 100644
--- a/classes/zynqmp-pmu.bbclass
+++ b/classes/zynqmp-pmu.bbclass
@@ -16,6 +16,7 @@
 ORIG_TARGET_ARCH := "${TARGET_ARCH}"
 
 # zynqmp-pmu target arch (hardcoded based on pre-gen data from arch-microblaze.inc)
+DEFAULTTUNE = "microblaze"
 ABIEXTENSION = ""
 TUNE_ARCH = "microblazeel"
 #TUNE_FEATURES_tune-microblaze += "v9.2 barrel-shift pattern-compare"
@@ -65,6 +66,9 @@ python multitarget_zynqmp_pmu_virtclass_handler () {
     e.data.setVar("MLPREFIX", variant + "-")
     e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + ":virtclass-" + variant)
 
+    # hide multilib variants, this class is not one but this works around recipes thinking it is (due to MLPREFIX).
+    e.data.setVar("MULTILIB_VARIANTS", "")
+
     # work around for -cross recipes that embed the TARGET_ARCH value
     if bb.data.inherits_class('cross', e.data):
         if initialpn.endswith("-" + d.getVar("ORIG_TARGET_ARCH")):