Replacing OE-Core device tree, kernel and u-boot binaries

Hi,

I’m looking to build a custom OE-Core image for use with my custom device tree, kernel and u-boot binaries. I’ve built the custom device tree, kernel and u-boot (including SPL) binaries outside the OE-Core environment. I’ve verified that each of these binaries works correctly by using them in place of the standard files in the ‘Apalis-iMX6_Console-Image-Tezi_3.0b2.65’ file from here. I.e. I can flash the modified files via a USB stick using the Easy Installer, and the console image boots correctly on my custom carrier board, running my custom kernel.

With the device tree, kernel and u-boot customisations and associated processes understood, I’ve turned my attention to the OE-Core process. I will endeavour to create a custom layer for my board/application in due course, but for the time being I’m looking to make a few changes to the standard LinuxImageV2.8 image via the OE-Core/build/conf/local.conf file. Namely I’m looking to add some Qt5 packages, and remove X11 and Wayland as I’ll be using eglfs. If I make the required local.conf changes and bitbake the standard console-tdx-image, I am able to flash the module and verify that the Qt5 packages are indeed installed, and am able to run the cinematicexperience program with the -platform eglfs flag. Success!

This is where I run into some issues. From what I’ve read, I should be able to replace the .dtb, u-boot.img (and SPL) and zImage files generated by the bitbake build in the ‘Apalis-iMX6_Console-Image-Tezi_2.8b6-20191002.tar’ folder in the OE-Core/deploy/images/apalis-imx6 directory with my custom equivalents, as I did earlier with the ‘Apalis-iMX6_Console-Image-Tezi_3.0b2.65’ image. This obviously requires extracting the bootfs folder, removing the standard .dtb and zImage files, adding my custom .dtb and zImage files then recompressing the folder in the tar.xz format. Similarly, the u-boot.img and SPL files can be swapped out, as well as the uEnv.txt file as I’ve made a few variable changes (namely vidargs for my custom board’s LVDS interface). I also make some minor changes to image.json.

I’m able to flash the module using the Easy Installer, but when I try and boot the device the console shows the following:

Booting from internal eMMC chip...
reading imx6q-apalis-custom.dtb
** Unable to read file imx6q-apalis-custom.dtb **
reading zImage
** Unable to read file zImage **

emmcboot failed

The *bootfs.tar.xz folder on the USB stick used for flashing has both the imx6q-apalis-custom.dtb and zImage files, so I’m not sure why this error is occurring? As mentioned above, if I don’t make these changes, the standard imx6q-apalis-eval.dtb and zImage are read without issue.

Any ideas as to what I’m doing wrong?

Hi @jars121

Thanks for writing to the Toradex Community!

Could you check if the device-tree and zImage was flashed to the boot partition of the eMMC Flash of the SOM by mounting the device in U-Boot ( ums 0 mmc 0 ) ?

Best regards,
Jaski

Hi @jaski.tx

I’ve tried running ums 0 mmc 0 in U-Boot and I get a perpetual loading animation, so I suspect that hasn’t worked. I’m thinking that the version of the Linux kernel I’ve compiled doesn’t match that of the version used by OE-Core. I’ve tried to following along with this article to ensure I’m using the correct version, but it’s somewhat challenging as the meta layers seem to have changed considerably since this was written. E.g. meta-toradex doesn’t seem to exist anymore, so I believe the apalis-imx6 files are actually now included in meta-freescale-3rdparty?

From the above linked article, I checked the SRCREV against those available in git but couldn’t seem to find a match, despite following along in the article. I’m building LinuxImage3.0 at the moment as V2.8 seems a little dated, so perhaps I’ll have better luck with SRCREV on the newer image.

Hi @jars121

I’ve tried running ums 0 mmc 0 in U-Boot and I get a perpetual loading animation, so I suspect that hasn’t worked.

Did you connect a USB Cable between the OTG connecter of the carrier board and your Host?

I’m thinking that the version of the Linux kernel I’ve compiled doesn’t match that of the version used by OE-Core. I’ve tried to following along with this article to ensure I’m using the correct version, but it’s somewhat challenging as the meta layers seem to have changed considerably since this was written. E.g. meta-toradex doesn’t seem to exist anymore, so I believe the apalis-imx6 files are actually now included in meta-freescale-3rdparty?

For the actual Yocto vs Kernel version, you can check this [site][1].

Best regards,
Jaski
[1]: https://developer.toradex.com/knowledge-base/board-support-package/openembedded-(core)

Hi @jaski.tx
I don’t believe I did use the OTG connector, just the regular console connector (X29 on the Apalis Evaluation board). Should I rather use X50?

I’ve just finished building the following:

  1. LinuxImage3.0 console-tdx-image
  2. toradex_4.14-2.0.x source and compiled zImage and custom.dtb completely independent of OE-Core environment.
  3. Replaced the zImage and added my custom .dtb file to the OE-Core /deploy/image TEZI folder (with .tar.xz extracting etc. where required).

I’m getting a different error now however. The emmcboot is still failing, but this time it doesn’t appear to even try and read the .dtb and zImage files:

Booting from internal eMMC chip...

emmcboot failed
MMC: no card present
MMC: no card present
starting USB...

I tried the ls mmc 0:1 command from within U-Boot which gave the following:

Custombootfs/
0 file(s), 1 dir(s)

Custombootfs is the .tar.xz directory which has the custom .dtb and zImage files on it.

You added the stuff to a Custombootfs folder instead of putting them right in the root of the bootfs.

They’re in the same folder as the standard .dtb files and zImage file when generated by the oe-core build, I’ve just changed the name of the folder, which is reflected in the image.json file.

I don’t believe I did use the OTG connector, just the regular console connector (X29 on the Apalis Evaluation board). Should I rather use X50?

You need to use both. X29 is for the Console and X50 for OTG.

Thanks for your help @marcel.tx and @jaski.tx . I’ve decided to go with the patching approach, as this will be the longer term method I use, and I can’t afford to spend anymore time trying to understand this temporary workaround.

Ok, thanks for your feedback.