Patch device Tree to disable PCIe

The hardware: Apalis IMX6Q 1Gb V1.1Y on Ixora 1.1A.
The software: Toradex BSP 6.4.0 devel.

I want to patch the device tree to disable the PCIe block and rebuild the image with Yocto.
I followed the Toradex “Build a Reference Image with Yocto Project/OpenEmbedded” tutorial with success and added my splash-screen following the " How to Add a Custom Splash Screen (Linux)".
So I already have the building environment

I’ve already read some tutorials on how to patch the device tree (thinking it’s the right way) but I’m confused. I think I don’t need a complete dts to substitute to the original, but only a patch where add:
&pcie {
status = “disabled”;
};
It’s right? How to?

Thanks,
Pipe

Hi @Pipe ,

I’ve already read some tutorials on how to patch the device tree (thinking it’s the right way) but I’m confused. I think I don’t need a complete dts to substitute to the original, but only a patch where add:
&pcie {
status = “disabled”;
};

On BSP 5 and 6, that’s correct. These patches you’re referring to are called Device Tree Overlays, and they’re ideal if you want to make small changes to the device tree.

Syntax-wise that’s pretty much it if you just want to disable PCIe, but nothing else. The only thing missing is the initial description, like the example below:

/dts-v1/;
/plugin/;
/ {
	compatible = "toradex,apalis_imx6q";
};

&pcie {
    status = “disabled”;
};

Keep in mind that non-used pins will not necessarily be available as GPIO, so you may have to describe them as GPIO pins in the overlay.


If I understand this right you already have built a reference image using Yocto by following the custom splash screen article, so I assume you’re familiarized with the concepts of Yocto layers and recipes, at least on a basic level, correct?

Before detailing the steps on putting a custom device tree overlay on your BSP ref. image, I’d like to know a bit more on what you want:

You want to disable PCIe but I assume you also want to use the pins used for PCIe for something else like GPIO, is this correct? You want to use all of them?

I ask this because in your last topic you wanted to use pin MXM3_15/GPIO7 as a GPIO. If you only need this pin as GPIO then the necessary device tree overlay will be simpler compared to setting all PCIe pins as GPIO.

Best regards,
Lucas Akira

Hi Lucas, thanks for answering,

Due to a modification request on a previous job, I had to move from a old boot2qt OS (where PCIe was not configured) to a new one, I tested Torizon but then moved to the multimedia image of the Toradex BSP. It is good for my purpose.
The target system is a standalone device with a dedicated Qt program that interfaces some peripherals and some digital IO, one of them is the famous GPIO7.

My goal for this job is to make the minimum modifications to the actual system to make correctly work the device. And everything is already working but the availability of GPIO7. I don’t want to use another GPIO because of a hardware pcb already wired to that pin.

Yes, I want to disable the PCIe because it’s not needed and it use GPIO7, and no, my need is to only have available the GPIO7 and I will manage it with the old ‘gpio’ instead of ‘gpiod’, as for the others gpio I use.

Yes… let say I’m at very basic level. As for reading on the community I think that the better solution should be to re-build the system with Yocto not disabling the entire PCIe feature but redirecting the GPIO7 to another unused pin. Another solution should be to disable the PCIe feature, thus letting tha GPIO free aswell. For my needs both are good.

YESS! That is what I want. My damned lack of knowledge on the Yocto environment block me, but if I could create a simple recipe to add a device tree overlay to let the GPIO7 free, this will resolve the whole problem.

Thanks Lucas, I wait for your suggestions.
Ciao
Pipe

Hi @Pipe ,

Right, so if you only want to use MXM3_15 as GPIO you only need an overlay that disables reg_pcie_switch.

Normally you would also have to do some additional steps in the overlay to enable the pin to be used in userspace as GPIO, but this pin in particular already has this setup made, so disabling the reg_pcie_switch should be enough.

So the overlay (let’s call it apalis-imx6_enable_gpio1_2_overlay.dts) will be:

/dts-v1/;
/plugin/;
/ {
	compatible = "toradex,apalis_imx6q";
};

&reg_pcie_switch {
	status = "disabled";
};

Now, for the Yocto part: I’ll do a quick overview on what you need to do in order to include a DT overlay in our BSP ref. images and enable it during boot. I did the same steps below and generated a ref. minimal image that has MXM3_15 working as GPIO with gpioset 0 2=1 and gpioset 0 2=0, as instructed here:

First thing you need to do is create and add a new Yocto layer where you will put the recipe directory, like instructed in the Splash Screen article.


  • Go to the directory where you have your Yocto file (if you followed this article the directory will be named oe-core). In it export the build environment with:
. export

After that be sure that build/conf/local.conf has MACHINE=apalis-imx6.


  • Create a new layer in the layers directory with bitbake-layers similar to this:
kirkstone@9080a3e561bf:/home/yocto/oe-core-6/build$ bitbake-layers create-layer ../layers/meta-custom-dtoverlays
kirkstone@9080a3e561bf:/home/yocto/oe-core-6/build$ bitbake-layers add-layer ../layers/meta-custom-dtoverlays

In this example I’ll call this layer meta-custom-dtoverlays. You can delete the recipes-example directory in it if you want, we won’t use it.


  • In the new layer create a new directory called recipes-kernel and inside of it a directory called linux. In linux create a text file called device-tree-overlays-mainline_git.bbappend and a directory named device-tree-overlays-mainline. This is where the overlay .dts file will be.

Your file/directory structure should be something similar to this:

meta-custom-dtoverlays/
├── conf
│   └── layer.conf
├── COPYING.MIT
├── README
└── recipes-kernel
    └── linux
        ├── device-tree-overlays-mainline
        │   └── apalis-imx6_enable_gpio1_2_overlay.dts
        └── device-tree-overlays-mainline_git.bbappend

This custom layer we just did will append changes to an existing recipe called device-tree-overlays-mainline_git.bb (found in meta-toradex-bsp-common), hence the .bbappend format. The directory organization for the .bbappend file has to follow the same organization as the .bb one, so that’s why it is like this.


  • The .bbappend file should be like this:
device-tree-overlays-mainline_git.bbappend
FILESEXTRAPATHS:prepend := "${THISDIR}/device-tree-overlays-mainline:"

CUSTOM_OVERLAYS_SOURCE = " \
    apalis-imx6_enable_gpio1_2_overlay.dts \
"

CUSTOM_OVERLAYS_BINARY = " \
    apalis-imx6_enable_gpio1_2_overlay.dtbo \
"

SRC_URI += " \
    file://apalis-imx6_enable_gpio1_2_overlay.dts \
"

TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:use-mainline-bsp += " \
    ${CUSTOM_OVERLAYS_BINARY} \
"

do_collect_overlays:prepend() {

    for DTS in ${CUSTOM_OVERLAYS_SOURCE}; do
        cp ${WORKDIR}/${DTS} ${S}
    done
}

I won’t go into detail on the syntax, but basically we’re adding an additional step in recipe device-tree-overlays-mainline to include our overlay into the build.


  • After that build the image with either
bitbake tdx-reference-minimal-image

or

bitbake tdx-reference-multimedia-image

I strongly recommend you read through our articles on Yocto and the Yocto documentation to better understand some general concepts, like bbclass, bbappend, recipe tasks, etc.:

You can also consult the Mega manual to seach for Yocto/Bitbake variables that are frequently used in recipes/recipes append like those for example:



As an alternative option to Yocto built images, you may want to consider using Torizon OS for future projects: With it you can avoid doing Yocto builds depending on what OS customization you want, and all apps run inside containers, which can simplify application development.

For instance, adding a custom DT Overlay in a Torizon OS image is much simpler than the Yocto route I just showed you: Apalis i.MX6 GPIO control - #18 by lucas_a.tx

Hope this helps.

Best regards,
Lucas Akira

Got it!

root@apalis-imx6-10980652:~# gpioinfo
gpiochip0 - 32 lines:
line 0: “MXM3_84” “regulator-usb-host-vbus” output active-high [used]
line 1: “MXM3_4” unused input active-high
line 2: “MXM3_15/GPIO7” unused input active-high

Many thanks Lucas, your instructions were clear and complete.

At my job I encourage the bosses to adopt the Linux choice because I know it’s robustness, flexibility, speed, etc. When I graduated 25 years ago, my thesis (in economics) was based on a webserver that serve a web-site to handle the investments wallet of people. At that time LAMP already was “the choice”. Altavista was the Internet search engine and RedHat was GPL.
Then at work the bosses choice is ever Ms oriented so I have to deal with Ms philosophy: shutdown and restart (and pray).
So, learning Yocto should be “the choice” but the reality is that I spend my time working in c#.

I tested it a little bit before to go with the BSP for this job but I intend to test it better. It’s powerful and easy but I think it’s intended for IOTs like kiosks and at my job we work on standalone machines with dedicated hardware and software. As I can undestand the containers structure, at the end, creates a needless layer for my programs to interact with pheripherals.

Anyway thanks alot for help, I appreciate.
Pipe

Glad I was able to help!

Best regards,
Lucas Akira

Hi Lucas,

please have a look at: Patch device tree to set a GPIO pin to LOW at kernel start

Due to an obsolescence at work they changed the TFT that now has the pwm brightness control inverted. Beacuse the arised problem is very similar to the one you previously resolved for me could be you have a suggestion.
Thanks,
Pipe

PS: in the new topic title I wrote “pin to LOW” but I think it’s default is to LOW and I want it to HIGH. Anyway I need to invert it.

Hi @Pipe ,

Sorry for the delay.

There are a couple of different ways to control GPIO pins before or while the kernel is loading. It depends on how early you want to control them.

If you want to control it before the kernel loads you’d have to make changes to the bootloader (called U-Boot), which is the program that loads the kernel.

You can also control it in the early stages of the kernel, which you could change the device tree to do this, as you inferred.

While I don’t know exactly the details on how to make the device tree changes, one of my colleagues who knows more about this subject will reply to you soon, if he hasn’t replied already.

Best regards,
Lucas Akira

Not really early. It’s enough at kernel start.
Your colleagues Alex and Henrique answered to me so now I can set/clear gpios at u-boot level passing bootcmd parameters, but unfortunately this doesn’t work with the Ixora X27 connector, pin 33, GPIO1_9 at u-boot level.

Yes I think this is my way.

Thanks,
Pipe