linux/meta-freescale.git/classes, branch g2d-rename

image_types_fsl.bbclass: Call named helpers from IMAGE_CMD

2026-09-14T17:03:03+00:00

oelint.task.dash rejects IMAGE_CMD:uboot-mxsboot-sdcard() for the dash in the function name, but the dash is the image type -- public, set by machine confs in IMAGE_FSTYPES and named by the wic files. OE-core instead assigns IMAGE_CMD a named helper, keeping the type and dropping the dash; the [doc] flags move with the functions they document. Tested on imx28evk with core-image-minimal: both bootstreams byte-identical. Signed-off-by: Luciano Dittgen

Merge pull request #2679 from lucianogdittgen/oelint-task-noanonpython

2026-09-10T18:06:52+00:00

Remove or document the layer's anonymous python functions

qoriq_build_64bit_kernel: Document the multilib promotion block

2026-09-10T17:12:25+00:00

The block conditionally replaces KERNEL_CC, KERNEL_LD and KERNEL_AR. A declarative form would have to state what those keep when the flag is unset, which means restating the kernel.bbclass defaults inside this class. DEPENDS is also read before the task graph exists, so a task cannot carry any of this. Signed-off-by: Luciano Dittgen

image_populate_mfgtool: Document the MFGTOOLCONFIG parse loop

2026-09-10T17:12:25+00:00

The loop enumerates the varflags of MFGTOOLCONFIG, which BitBake has no declarative syntax for, and it feeds do_populate_mfgtool[depends], which must be set before the task graph is built. Computing the two values with an inline ${@...} would move the flag validation into expansion, where it no longer fails the parse. OE-core parses PACKAGECONFIG the same way. Signed-off-by: Luciano Dittgen

qoriq_build_64bit_kernel: Append the multiarch distro feature

2026-09-10T15:42:31+00:00

Appending to REQUIRED_DISTRO_FEATURES:e6500 builds that scope up from empty, so on an e6500 machine it replaces REQUIRED_DISTRO_FEATURES rather than extending it. Nothing else sets it today, so the value is unchanged; :append keeps it that way if a consumer ever does. Tested on t2080rdb: bitbake -e still reports " multiarch" and linux-qoriq's buildhistory records no changes. Signed-off-by: Luciano Dittgen

qoriq_build_64bit_kernel: Suppress noncoreoverride on the anonymous python

2026-09-04T12:52:28+00:00

The class is gated by BUILD_64BIT_KERNEL, a variable any machine may set, not by a machine override, so it cannot carry one; e6500.inc is the only in-tree setter. Rewriting the block as :e6500 assignments would narrow that contract and needs an e6500 multilib kernel build to validate, which this tree cannot produce. The directive trades the warning for a false oelint.file.inlinesuppress_na info: oelint misses the blockoffset hit. Signed-off-by: Luciano Dittgen

use-imx-security-controller-firmware: Make PACKAGE_ARCH a weak default

2026-08-18T20:26:36+00:00

The class set PACKAGE_ARCH with a hard "=". imx-boot inherits the class and then sets its own PACKAGE_ARCH = "${MACHINE_ARCH}", while imx-seco and firmware-ele-imx inherit the class and rely on "${MACHINE_SOCARCH}". Use "?=" so the class provides a default that inheriting recipes can override, matching use-imx-headers.bbclass. This is value-preserving: bitbake.conf defines PACKAGE_ARCH with the weaker "??=", so "?=" here still yields "${MACHINE_SOCARCH}" for the non-overriding inheritors, while imx-boot's later "=" after the inherit still wins. Validated with a real build in a resolved environment for one of the non-overriding inheritors (MACHINE=imx93-11x11-lpddr4x-evk, target firmware-ele-imx): PACKAGE_ARCH resolves to "cortexa55-mx93" (= MACHINE_SOCARCH) both before and after, and comparing buildhistory across the parent and this commit shows the only delta is metadata-revs, with no change to the generated package. Behaviour-preserving. Signed-off-by: Luciano Dittgen

uuu_bootloader_tag: Make UUU_BOOTLOADER defaults weak

2026-08-18T20:26:36+00:00

uuu_bootloader_tag.bbclass set UUU_BOOTLOADER (and its mx8/mx9 generic-bsp specializations) with a hard "=". imx-boot_1.0.bb and u-boot-imx_2025.04.bb inherit the class and set their own UUU_BOOTLOADER, so oelint.var.override reported the class assignments as fully replaced, while u-boot-fslc_2025.01.bb inherits the class and uses its values unchanged. Weaken the three class assignments to "?=" so they read as the defaults they are. This is value-preserving: UUU_BOOTLOADER has no bitbake.conf default and the class is its first assignment, so "?=" yields the same value as "=" for u-boot-fslc, while imx-boot and u-boot-imx set the variable with a later "=" after the inherit and still win. The mx8/mx9 override selection is unchanged -- only the assignment operator differs. Validated on imx8mp-lpddr4-evk against u-boot-fslc, the inheritor that applies the class default (u-boot-fslc pinned as bootloader provider): UUU_BOOTLOADER resolves to "imx-boot" both before and after, and every task signature of the recipe -- including do_deploy, which consumes UUU_BOOTLOADER -- is identical across the parent and this commit. (do_compile is blocked in this checkout by an unrelated host-toolchain issue, identical on both sides; the equivalence is established from the resolved variable and the full set of task signatures.) Behaviour-preserving. Signed-off-by: Luciano Dittgen

oelint: Suppress noncoreoverride on the machine-gated bbappend idiom

2026-08-07T12:30:00+00:00

oelint.vars.noncoreoverride flags every statement in a bbappend that carries no MACHINE or DISTRO override suffix, because an unconditional override of core behaviour fails yocto-check-layer. The check is purely syntactic: it cannot see that a statement's effective value is already machine-gated, which is exactly how most of this layer is written. DRM-REMOVE = "" <- flagged DRM-REMOVE:imxgpu:mx6-nxp-bsp = "drm-gl drm-gles2" PACKAGECONFIG:remove = "${DRM-REMOVE}" <- flagged Neither line can be scoped. A fallback default cannot carry an override for the machines it is the fallback for, and the dispatch line that consumes it is a no-op wherever the helper expands empty. Scoping them anyway would damage correct metadata: weston-init reads HAS_G2D as "elif ${HAS_G2D};" in shell, where an empty value is a syntax error. Suppress the 58 sites proven inert, each with its own rationale. The proof is a bitbake -e comparison on MACHINE=qemuarm64 -- a machine this layer does not own -- with meta-freescale in and out of BBLAYERS. At every suppressed site SRC_URI, DEPENDS, PACKAGECONFIG, OPENGL_PKGCONFIGS and REQUIRED_DISTRO_FEATURES are unchanged; eight recipes show no effective difference at all. The helper variables are defined in the datastore but every consumer is override-scoped. For the 18 FILESEXTRAPATHS sites there is a stronger result: FILESPATH and FILESEXTRAPATHS are both in BB_BASEHASH_IGNORE_VARS, so they cannot reach a task signature. Two anonymous python blocks are deliberately left unsuppressed and explained in place instead. For those, oelint anchors the finding to the line before the block, so a directive placed above only moves the anchor onto itself: the finding survives and inlinesuppress_na is reported for the directive. oelint.task.noanonpython anchors the same block to the 'python' line and suppresses correctly, so the two rules disagree about where the construct starts. Upstream oelint bug candidate. The rule count goes 76 -> 18 and the layer total 548 -> 491. The 16 findings that remain are not noise: they are measured, genuine unconditional changes to machines this layer does not own, and are left open for separate fixes. This change is comment-only; no non-comment line is added or modified. Validated with bitbake -p (1166 recipes, 0 errors) and an authoritative driver rescan showing zero introduced findings in any of the 24 edited files. The residual override/outofcontext churn in the rescan is the known shared-metadata scan non-determinism and nets to zero. Signed-off-by: Luciano Dittgen

use-imx-headers: Order PACKAGE_ARCH before RDEPENDS per oelint

2026-08-07T12:29:54+00:00

Move the PACKAGE_ARCH assignment above the RDEPENDS:${PN}-dev block so the class follows the canonical variable order oelint.var.order enforces (PACKAGE_ARCH precedes RDEPENDS). The three assignments involved (DEPENDS:append, PACKAGE_ARCH ?=, RDEPENDS:${PN}-dev +=) are independent: none references another and none uses immediate (:=) expansion, so reordering them is behaviour-preserving. The explanatory comment stays with its RDEPENDS block. Validated: oelint scoped rescan of the class shows the finding removed and none introduced; bitbake -p over the full layer parses with 0 errors. Signed-off-by: Luciano Dittgen