imx95: install mali firmware (mali_csffw.bin) in the rootfs #220
Conversation
leonheldattoradex
force-pushed
the
scarthgap-7.x.y
branch
2 times, most recently
from
264d24d to
08b43fa
Compare
leonheldattoradex
changed the title
We need the firmware as the kernel module expects it in specific places of the root filesystem, so it cannot be dynamically deployed from containers as the rest of the graphical stack is. On the imx8 and am62 for example the firmware is installed via 'driver' recipes (kernel-module-imx-gpu-viv and ti-img-rogue-installer), on the imx95, however, it comes from userspace portion, thus we need the bbappend to only install the firmware, nothing else (no libEGL, libGLES etc...). This follows the same logic as commits a7ec4b0 and b40b911. Related-to: TCCP-879 Signed-off-by: Leonardo Held <[email protected]>
leonheldattoradex
force-pushed
the
scarthgap-7.x.y
branch
from
08b43fa to
e385390
Compare
There was a problem hiding this comment.
@leonheldattoradex, this seems to be an .bbappend for the meta-imx-bsp layer, right? I believe it would be better if we added this .bbappend into dynamic-layers.
There was a problem hiding this comment.
It's for meta-freescale, I'm assuming we're building from that, right?
There was a problem hiding this comment.
Both layers have this recipe, don't know now from which layer we're actually getting it. Probably an easy way to check would be to run bitbake mali-imx -c devshell and comparing the checkout hash with the recipes
There was a problem hiding this comment.
Okay maybe I did something extremely wrong, was there supposed to be a meta-imx in the layers? I just repo sync, set the machine, distro and bitbake, no meta-imx on sight.
There was a problem hiding this comment.
Yup, there's no manifest for common-machines yet, so there's no way to repo sync iMX95. 😀
If you want to sync and have a local build for this just let me know and I can share with you the steps.
There was a problem hiding this comment.
Instead of changing torizon-base.inc, I think would be better organized adding the CORE_IMAGE_BASE_INSTALL:append directly into the machine file conf/machine/include/imx95-19x19-verdin.inc.
There was a problem hiding this comment.
Should I move the other configs too (I'm just doing what has been done before for the other machines)?
There was a problem hiding this comment.
No.
It's just that when we talk about common machines, I think i'ts best if any things needed don't spill into core Torizon stuff.
There was a problem hiding this comment.
Gotcha. I'm thinking that eventually we'll have smarc95 (and others) as a machine which will be COMPATIBLE with mx95-nxp-bsp. ie, the am62 fix for this same issue works for all am62 models, not only for an specific machine. What you think?
There was a problem hiding this comment.
Hmm, that makes sense. We can keep this in torizon-base.inc.
|
Alright drafting for a bit as I wasn't building it correctly. |
We need the firmware as the kernel module expects it in specific places of the
root filesystem, so it cannot be dynamically deployed from containers as the
rest of the graphical stack is.
On the imx8 and am62 for example the firmware is installed via 'driver' recipes
(kernel-module-imx-gpu-viv and ti-img-rogue-installer), on the imx95, however,
it comes from userspace portion, thus we need the bbappend to only install the
firmware, nothing else (no libEGL, libGLES etc...).
This follows the same logic as commits a7ec4b0 and b40b911.
Note that I haven't 100% tested this commit besides a build as I need to actually build the graphical userspace to trigger the kernel module to load the firmware, but having it in
lib/firmwareis, from my understanding, enough.Of course, the rest of the graphical stack belongs inside one of these: https://github.com/torizon/torizon-containers.