scripts/kconfig/conf --syncconfig Kconfig
| make[2]: *** No rule to make target 'arch/arm/boot/dts/imx6q-apalis-ixora-v1.2.dtb'. Stop.
| /data2/toradex-zeus/build/tmp/work-shared/apalis-imx6/kernel-source/Makefile:1238: recipe for target 'imx6q-apalis-ixora-v1.2.dtb' failed
| make[1]: *** [imx6q-apalis-ixora-v1.2.dtb] Error 2
| /data2/toradex-zeus/build/tmp/work-shared/apalis-imx6/kernel-source/Makefile:179: recipe for target 'sub-make' failed
| make: *** [sub-make] Error 2
| WARNING: exit code 1 from a shell command.
|
ERROR: Task (/data2/toradex-zeus/build/../layers/meta-toradex-bsp-common/recipes-kernel/linux/linux-toradex-mainline_5.4.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4660 tasks of which 4659 didn't need to be rerun and 1 failed.
NOTE: Writing buildhistory
NOTE: Writing buildhistory took: 1 seconds
Summary: 1 task failed:
/data2/toradex-zeus/build/../layers/meta-toradex-bsp-common/recipes-kernel/linux/linux-toradex-mainline_5.4.bb:do_compile
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Is the kernel 5.4 not supported for the IMX6 or am I missing something?
How can I figure out, which kernel versions are supported for which SoM? There are some instructions given here, but they seem outdated as my build directory does not have a “stuff” folder: Patching Kernel in OpenEmbedded
You need to use a different machine configuration to make it work. The reason for the failure is that the devicetee file is not available but selected in the machine configuration. So instead of:
thank you very much for your quick feedback. Unfortunately, this does not work for me, I get the following error:
msauer@PG-KA-S-Yocto:/data2/toradex-zeus/build$ bitbake console-tdx-image
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
MACHINE=apalis-imx6-mainline is invalid. Please set a valid MACHINE in your local.conf, environment or other configuration file.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
I’ve attached my local.conf file for your reference.
Using the LinuxImage3.0 branch, MACHINE ?= "apalis-imx6-mainline"successfully builds but the kernel version is 4.20.0-rc6. I was expecting to see 5.4.x when using the mainline branch?
Is there any documentation showing which SoMs are supporting which kernel version and how to build the corresponding image? As stated in my first post, the only documentation I’ve found seems to be outdated.
That is correct, Toradex will not release a BSP based on the zeus branch. However, in the past it was planned to do a 4.0 release which would have been zeus based that’s why there is already some work done. If you want you can try it out. However, we will never support that version officially. So if you can live with that you can use zeus but as said, unfortunately we will never do an official release there.
Sorry, if I did not make this clear. I did NOT recommend anything. I just tried to explain to you why it is what you were getting and what you may do to get what you seem to want.
Thank you very much for the explanation. So there won’t be a 4.0 release based on Zeus but instead you will make a 5.0 release that will be based on Dunfell?
I’m sorry, but I find this roadmap table very confusing. When is the planned release for BSP 5.0? Here you mentioned Q3/2020, but it would be great if you could be a little more precise.
We need kernel version >4.17 (preferred >5.4) for a product that goes into protoype phase around september, because we would like to re use existing software that we’re porting from an x386-IPC to the IMX8.
Could you please provide some more information, when you’re planning to release which BSP for which platform? We could also discuss this on a phone call if you prefer.
To put it in a nutshell, I’m looking for an iMX8-based SoM that supports kernel >4.17 and OpenGL 3.0 (not ES). Righ now It’s notimportant if it’s an iMX8 QuadMax, QuadPlus or QuadXPlus. I think even an iMX8M Nano would work, but unfortunately this isn’t within your portfolio.
If I can’t find a matchin SoM within your portfolio and don’t have any roadmap details when to expect it, we might be forced to switch to another supplier.
PS:I talked to our experts from SW development again and we don’t really need the full OpenGL 3.0 standard. We just need a subset that is guaranteed to be supported if the device supports OpenGL 3.0.
It’s still possible that our application will work with the OpenGL ES subset, but we have to get a recent kernel (>4.17, preferably 5.4) up and running on the HW to test that.
Unfortunately, we can’t just switch to a newer kernel version because it is what NXP provides and then we also need some time to integrate our own changes. Torizon uses for iMX6 and iMX7 kernel 5.4 because there we have mainline support but not for the new products (iMX8). I guarantee you our BSP team would love to provide newer versions but it’s just what we get from NXP…
What exact feature do you need from Kernel 4.17 which is not in Kernel 4.14? Could you maybe do a backport to 4.14?
If you really can’t wait, you could try to bring-up kernel 5.4 from NXP yourself. However, this is not an official release. Not from NXP and also not from Toradex! NXP is still working on that version! https://source.codeaurora.org/external/imx/linux-imx/log/?h=rel_imx_5.4.24_2.1.0
I’m sure you understand that we can’t support you on this because we didn’t work with this kernel version yet and we don’t plan to, until NXP makes an official release.
thank you very much for the quick response. Sorry if the answer to this question is obvious, but how does one distinguish an official release from an unofficial one? The 5.4 release can be found already found since a couple of weeks on the NXP homepage and I know that other SoM vendors are already integrating it. Therefore, I assumed it’s an official release: i.MX Software and Development Tools | NXP Semiconductors
Concerning the functionality: We’ve got an huge exisiting Qt-code base that we would like to reuse. As far as I understand from my colleagues in SW development, we need to get the etnaviv driver up and running to use this software with HW acceleration because it’s packaged for a Debian distribution (which we can port ourselfes).
Good point… It looks like the 5.4 is now officially released by NXP. However, we are still on 4.14 and currently we don’t have a roadmap when 5.4 will be released with our changes. Sorry about the confusion.
