Apalis iMX8 SOM
Ixora Carrier Board
We have an Apalis iMX8 SOM mounted on a Ixora Carrier Board.
We wish to evaluate drive encryption using DM-Crypt and CAAM secure keys per the attached document AN12714 Rev2.
I have successfully built and flashed a Yocto image per sections 3 and 4 of the attached document, iMX8 Devkit Procedure. According to the document, the image loaded per section 4 of the document should have support for DM-Crypt, however, when I check for that, it does not have the kernel options enabled. Specifically, when I run the command “dmsetup targets”, the command does not display an entry for “crypt” or “multipath”. Also, for example, when I run “zcat /proc/config.gz | grep CONFIG_DM_CRYPT”, the command returns “CONFIG_DM_CRYPT=m”, when it should return “CONFIG_DM_CRYPT=y”. I get the same return result for the other kernel options listed in the attached document AN12714 Rev2, the return state is “=m” not “=y”.
I am working to try and resolve this on my own, by rebuilding the Yocto image with a different configuration, and also by manually loading the kernel modules at run time, but if someone can provide assistance it would be appreciated.
AN12714_Rev2.pdf (204.7 KB)
iMX8_DevKitProcedure.pdf (188.3 KB)
To clarify are you building the NXP BSP image as specified in the document you referenced, or are you building one of our images and trying to integrate DM-Crypt support there?
In either case, how are you trying to set these kernel configs exactly?
I am building the image referenced in the document, however, I am open to trying one of your images instead, I just need the kernel support enabled. I have been trying to modify the defconfig file(s) to enable the kernel support, but so far I have not been successful.
Generally speaking the configs should still be fine if they are built as modules rather than built in directly (m vs y). You may have to manually load them as you said, but functionally should be the same after that.
But if you really desire to have them be built-in then you should be able to just configure this in the yocto build with a config fragment that gets sourced by the relevant Linux kernel recipe in the build. This should be the case for both ours and the NXP reference images. Assuming the NXP builds doesn’t do something strange that might interfere with this, but I can’t speak for their build. In any case a config fragment file like this should work just fine (as an example):
# From AN12714 CAAM support
# Enable DM-Crypt and its dependencies
# Enable CAAM black key/blob driver and its dependencies (this is enabled, by default)
Now if the default kernel config already sets some of these options as a module then this might override/interfere with the behavior. But as I said module or built-in shouldn’t matter too much.
One issue is that at least one of the CONFIGs is missing. I thought I could just modify the defconfig file, but there are multiple defconfig files, and it’s not clear to me which one(s) are used during the build.
The next step would be to add a config fragment as you suggest, I’m just not sure where to place it in the layers.
I am using a Toradex Yocto build, and I am using EasyInstaller to flash it, here are the commands to pull it and initialize it:
repo init -u Index of /toradex-manifest.git -b kirkstone-6.x.y -m tdxref/default.xml
If you know of a specific Toradex build that is configured for CAAM and DM-crypt, please share a link.
Well we don’t have a build with everything for CAAM configured by default since it’s more of an advanced feature.
That said you can just take the config fragment I provided and apply it to the relevant Linux kernel recipe in the build. If you’re using our build then the default recipe for Apalis i.MX8 should be
linux-toradex: linux-toradex_5.15-2.1.x.bb « linux « recipes-kernel - meta-toradex-nxp.git - Toradex BSP layer, recipes for NXP based modules
So either you can create a bbappend to this build or if you’re lazy just modify the original recipe so that the config fragment file is referenced in the recipe’s
I’ll take a look at it and let you know, thanks.
Which branch would you recommend? The master branch?
If you’re referring to what branch of our build to use, the answer is it depends, but not master. Our master branch in Yocto is typically just to track and develop upstream changes and is not stable in any way, so I can’t really recommend it for customer use.
In general you either want our Dunfell or Kirkstone branches. Dunfell is what we based our version 5.X.Y images on and Kirkstone is for our 6.X.Y images. Either works but Kirkstone is newer and therefore has newer versions of things (including the Linux kernel version). Again, it depends and maybe for your purposes here it doesn’t really matter which you go with.
This is our article on how to setup and build our basic reference image: Build a Reference Image with Yocto Project/OpenEmbedded | Toradex Developer Center
It also has a table outlining the branches/versions and such.
@jeremias.tx I have it working with the Dunfell branch, using a config fragment and adding
a SRC_URI_append command to the kernel .bb file. I am seeing if the same approach works with Kirkstone, will let you know.
Glad to hear you were able to make progress! I hope the smooth progress continues.