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 72913445..910e8eb9 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 little-endian 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")):