i.MX6ULL Integration woes

General Discussions
,
41

Also for reference, we recently did a board integration for i.MX8 on sumo branch (similar BSP to what you are using), you can take a look at the commit here,

I would suggest this as a good template for how I would have done it for i.MX6ULL

And the post,

But with these instructions,

mkdir mender-imx && cd mender-imx
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.0.0_ga.xml
wget --directory-prefix .repo/manifests https://raw.githubusercontent.com/mendersoftware/meta-mender-community/sumo/meta-mender-imx/scripts/imx-4.14.98-2.0.0_demo_mender.xml
repo init -m imx-4.14.98-2.0.0_demo_mender.xml
repo sync
DISTRO=fsl-imx-xwayland MACHINE=imx8mqevk . fsl-setup-mender.sh -b build

Which is not how it is currently done in that post as the imx-4.14.98-2.0.0_demo_mender.xml file was up-streamed.

42

Looking for some advice here.

I get the following warning:

WARNING: u-boot-imx-2017.03-r0 do_provide_mender_defines: Found more than one dtb specified in KERNEL_DEVICETREE. Only one should be specified. Choosing the last one.

The file meta-fsl-bsp-release/imx/meta-bsp/conf/machine/imx6ull14x14evk.conf which is my machine.conf file contains the following:

KERNEL_DEVICETREE = "imx6ull-14x14-evk.dtb imx6ull-14x14-evk-btwifi.dtb imx6ull-14x14-evk-gpmi-weim.dtb
imx6ull-14x14-evk-usb-certi.dtb imx6ull-14x14-evk-emmc.dtb
"

I think since this uses an ‘=’ that means I can’t override this in the local.conf

What is the best practice here to only have a single .dtb? Create a new machine, e.g. imx6ull14x14evk-mender ?

Thanks

43

What is the best practice here to only have a single .dtb? Create a new machine, e.g. imx6ull14x14evk-mender ?

I would try really hard to avoid creating custom machines.

I guess the appropriate fix is to make sure that imx6ull14x14evk.conf is changed to ? = to allow overrides.

But one workaround you can use in local.conf is

 KERNEL_DEVICETREE_remove "<name of the entries to you want to remove>"
1 Like
44

I’ve got a working build now so I’m just trying to absorb this post now (and find the things you are subtly saying I should change :wink: ). I’m still trying to understand repo too, so bear with me.

If I understand whats happening properly, you are still using the NXP manifest to download the NXP repositories, but you then download an additional manifest with the mender info.

repo sync will then download both manifests. (I didn’t know it could do this)

You have a custom initialise script that calls the NXP script in the fashion it expects, while also setting up the mender side of things.

Reading between the lines, are the benefits:

  • Can still get updates from NXP since we use their manifest directly
  • Can still use their initialisation script to support multiple MACHINE and DISTRO variables

?

45

I’ve got a working build now so I’m just trying to absorb this post now (and find the things you are subtly saying I should change :wink: ). I’m still trying to understand repo too, so bear with me.

Understandable and do not worry much about it :slight_smile:

If I understand whats happening properly, you are still using the NXP manifest to download the NXP repositories, but you then download an additional manifest with the mender info.

repo sync will then download both manifests. (I didn’t know it could do this)

You have a custom initialise script that calls the NXP script in the fashion it expects, while also setting up the mender side of things.

You have understood correctly.

Reading between the lines, are the benefits:

  • Can still get updates from NXP since we use their manifest directly

Exactly, it is usually a pain to keep a copy of the upstream manifest, which would get out of date fast and one needs keep updating it “manually”

  • Can still use their initialisation script to support multiple MACHINE and DISTRO variables

Yes, exactly. This is to make the Mender integration less “intrusive” to the upstream workflow even if the Mender integration is only valid for one MACHINE this could be extended to support more.

1 Like
46

I think I have most of the documentation done here: [INCOMPLETE] i.MX 6ULL EVK and a pull request here: https://github.com/mendersoftware/meta-mender-community/pull/73

Let me know what else I can do. Once PR is done I will update the docs with the correct links and run through the build process using the instructions, then do the runtime testing etc.

Thanks.

47

I will take a look at the PR tomorrow, today is a public holiday so trying to enjoy that :grin:

1 Like