Imx7d blinking_imx_demo while Linux running

Hey,

I am trying to get the blinking_imx_demo running while Linux is running. For now I know that I probably have to change something in the device-tree.

“The interrupt part of the demo only works as long as Linux is not running. The reason for that is that Linux uses the same GPIO bank too, and reconfigures interrupts. The easiest way to use GPIO in interrupt mode on FreeRTOS while using Linux is to assign a complete GPIO bank to FreeRTOS and disabling the GPIO bank in Linux’ device tree.”

I tried disabling the GPIO1, since EXT_IO_0 ,1,2 which are used in the demo, are in the GPIO1 Bank.

Therefore I would appreciate some help on what else I could try to fix the problem.

Thanks in advance!

Greetings @Zimart!

Can you please share your changes to the device tree?

Sorry for the delay,

imx7d-colibri-emmc-eval-v3.dts :


/*
 * Copyright 2017 Toradex AG
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 */

/dts-v1/;
#include "imx7d-colibri-emmc.dtsi"
#include "imx7-colibri-eval-v3.dtsi"

/ {
	model = "Toradex Colibri iMX7D 1GB on Colibri Evaluation Board Zimmerl";
	compatible = "toradex,colibri_imx7d_emmc-eval", "toradex,colibri_imx7d_emmc", \
		     "fsl,imx7d";
};

&usbotg2 {
	vbus-supply = <&reg_usbh_vbus>;
	status = "okay";
};

&gpio1{
	status = "disabled";
};

I just changed the model name to insure that the DT updates properly.

Hope it helps to understand the issue.

Thanks in advance

Maybe I didn’t ask my question clearly. My main question is, what I need to disable in the device tree to run the demo while linux is running.

@Zimart,

I was able to reproduce your issue. For me, disabling the &gpio1 node actually lets Linux boot, but I never get to the login prompt and cannot interact with the TTY.

I’m investigating this closely and will update you ASAP.

Hey @gustavo.tx,
I want to clarify that the problem is, that the gpio LEDs don’t blink consistently or ever when Linux is booted.

Example:
I flash the blinking_imx_demo.elf LEDs are blinking at 100ms interval. When I type in the U-Boot “boot” the LEDs start to blink in different intervals and when the Linux boot process is done the LEDs stop to blink.

Kind regards!

Hey @gustavo.tx,

Have you found a Solution to the problem?

Kind regards

@Zimart,

I’m investigating this issue. Actually, on the i.MX 7, some of these GPIO1 pins are part of the LPSR IP, so they behave a little different under the hood.

Meanwhile, can you try modifying the blinking_imx_demo code and use other GPIOs to see if that works?

Dear friends,

I am stuck with the same problem. Kindly let me know if someone resolved it.

@gustavo.tx
No I was not able to get any solutions for this problem. Since this is a known problem, are there really no easy fixes? It seems to me that this problem hinders many projects.

Kind regards

@Zimart,

I’m still running some tests on this, but there’s no easy fix for now. I’m escalating this properly so we can at least have this documented.

Apart of using other GPIOs, the definitive solution would be to disable all 32 GPIOs which are in the same bank.

Note that just disabling the &gpio1 node won’t do, since some of those 32 pins might be used for other interfaces which are not GPIOs.

@gustavo.tx

Thanks for the quick reply.

You mentioned I could use other GPIOs. Which GPIO pins did you have in mind? I thougth this problem occurs with every Pin.

Thanks in advance!

@Zimart,

I thought about using pins that are not LPSR, but for any pin that you might use as an interrupt source on thte M4, it seems that you have to disable any function the pins on the whole bank might have.
I would go the trial and error route, preferably trying the pins that are GPIOs by default on the Colibri standard, avoiding the &gpio1 node you already tried.

I’ve been trying to get this same setup to work as well, I moved the GPIOs to GPIO6 and disabled that group in the devicetree. I’m partially booting but halting at the EHCI host controller setup. Now I’m stuffing printks into that code to try and see what’s going on.

It would be great if Toradex could provide a working example of M4 and Linux together. A 4 year-old archive of binary files isn’t enough here.

Loading the .bin post-boot with NXP’s m4fwloader project isn’t really viable for me as well, the armgcc project files generate only .elf and not .bin. This has been really frustating.

A bit more trial-and-error and it looks like the allocation of GPTA to the RDC in the demo stops Linux from booting fully for me. If I comment out the SetPdapAccess for GPTA (Gpt3 in board.h), the M4 firmware doesn’t run but Linux now boots.

@lkoziarz,

I’m having some issues such as this while messing with the GPIOs and the RDC. I’m trying to escalate this issue to the BSP team since it involves Linux. We should have some solution or some clear documentation on how to deal with this in those cases.

It would be nice if NXP/Freescale could provide more recent support or reference files as well. I’m checking to see if they have any updated documenation.

It seems that my observations are almost identical to this other question, which never got fully resolved as far as I can read:

Has the BSP team responded with any information?

@lkoziarz,

I had a meeting with the BSP team and it seems that we’re going to work on official M4 support on our BSPs. It’s a little bit of a pain to work with HMP since, as you mentioned, NXP does not provide extensive or detailed documentation, especially for the i.MX 7S/D.

I kindly ask you to keep me up to date on any progress and I’ll do the same here on my side.

My interaction with NXP has been unproductive and will probably not give any results now.

The answer that NXP provided through our distributor was this:

“Regarding FreeRTOS BSP it is indeed a bit old, unfortunately updates for this won’t be released.”

Very unfortunate. I’ve tried to at least get NXP to acknowledge that their FreeRTOS examples won’t run on Linux 5.x. They’re not listening to us. Maybe you can get some better results.