Trying to enable I2C5/6 using SODIMM pins 19 and 34 with tcbuilder

I still get a configuration error but it boots to the login >20 seconds faster.
[ 5.993686] ina2xx 3-0040: error configuring the device: -6

This message here refers to the power measurement IC that is found on some of our Verdin carrier boards: Verdin iMX8M Plus Power Consumption | Toradex Developer Center

By default it’s enabled in our device trees. I assume you’re seeing this on your custom carrier board that does not have this IC. In which case this error message makes sense since the software driver can’t find this IC that is not on your carrier board. You can just ignore this in that case, or disable this in the device tree overlay if it’s really bothering you.

Best Regards,
Jeremias

@jeremias.tx
Interesting. I tried adding &hwmon to disabled, but now, I can’t seem to get it to boot, once I install the modified tree. The board is complaining about not finding a valid device tree because of FDT_ERR_BADMAGIC.
I get no errors when I build or when it is unpacked. I tried taking that back out, and I can’t get it to read it, as it gives me the same error. I am using a deploy over ethernet. Is there a way to verify that the magic number is really wrong?

This is with 6.5.0. I went back to 6.4.0. I had no issues, using the same build with the exception of changing the names of the files.

So, I went back to 6.5 with no containers. I get the same issue as before: FDT_ERR_BADMAGIC

Steve

I just added the following to my device tree overlay:

&hwmon {
        status = "disabled";
};

And, it worked fine on 6.5.0 with no errors or issues.

The FDT_ERR_BADMAGIC is a fairly generic error that just implies something about your device tree/overlay is invalid. It’s not very specific so it could be many things really. Does not have anything to do with a “magic number” specifically.

So seeing as it worked for me, disabling &hwmon is a valid change. The only thing I would guess is that you must have changed or did something else besides this that is somehow invalidating your device tree here. I can’t really provide anymore information since, again it works just fine on my side.

You could try re-tracing/re-doing your steps until you find the specific change that triggers this error. I mean you had it working before, so there’s no way you just permanently broke your build.

Best Regards,
Jeremias

@jeremias.tx
Yep, I did this last night. I added it back in for 6.4.0, ran it, and I don’t get the error and the boot up issue for that the &hwmon, doesn’t show.
Then I went back to 6.5.0 with the exact same .dts file and the only changes were in the tcbuild.yaml to call out the 6.5.0 file. I get the same error and it won’t load the tree. I even deleted the tar folder and used the images download to make sure I was pulling the correct version.
BTW, I am using build 8 for 6.5.0 with no containers, which is the only one that shows unless you add in the overnight builds. Is that what build you are using?

Also, it looks like 6.5.0 version can’t seem to find my overlay. I see this line:
Applying Overlay: verdin-imx8mp-gimbal3b-overlay.dtbo
but then:
3788 bytes read in 2 ms (1.8 MiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
13421509 bytes read in 42 ms (304.8 MiB/s)
11574753 bytes read in 36 ms (306.6 MiB/s)

Whereas, under 6.4.0 I see:
Applying Overlay: verdin-imx8mp-gimbal3b-overlay.dtbo
3788 bytes read in 2 ms (1.8 MiB/s)
13347831 bytes read in 42 ms (303.1 MiB/s)
11537129 bytes read in 37 ms (297.4 MiB/s)

Does that mean it can’t find my overlay? The 3788 bytes is the same, which I assume is my overlay.
I find this odd.

FYI, I am using
torizoncore-builder 3.8.1

Thanks,
Steve

BTW, I am using build 8 for 6.5.0 with no containers, which is the only one that shows unless you add in the overnight builds. Is that what build you are using?

My build is still exactly the same as it was in the tcbuild.yml I shared earlier in this thread. So yes I’m using the 6.5.0 quarterly release, and I have been this entire time.

failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC

Oh wait, you’re getting FDT_ERR_NOTFOUND as well? Earlier you said you were just getting FDT_ERR_BADMAGIC. This is completely different then. Please make sure to share your full error information next time.

This set of errors implies that your overlay is trying to change/affect something that does not exist (i.e NOTFOUND). What does your overlay look like now?

Best Regards,
Jeremias

@jeremias.tx
Well, that is more helpful. I don’t remember another error originally. It wasn’t until I tried 6.5.0 bulid 20 that I saw this error. I thought it meant that it couldn’t find my overlay. I added in a bunch of things to make the hdmi become a non factor. But that wasn’t the end of it. Had to turn off some other things.
I will figure out what is causing the issue. This must be something new starting in 6.5.0 since 6.4.0 doesn’t complain.

Steve

I added in a bunch of things to make the hdmi become a non factor. But that wasn’t the end of it. Had to turn off some other things.
I will figure out what is causing the issue.

This is why I asked you to re-trace your steps. All of your steps, don’t just go between 6.4.0 and 6.5.0, then that’s it. You added something to your device tree overlay that is not valid for 6.5.0. Remove things one by one from your device tree overlay until you find the thing that makes it not valid.

For example if I add this to my overlay:

&foobar {
        status = "okay";
};

Then I get the same FDT_ERR_NOTFOUND that you’re seeing. This makes sense cause obviously &foobar is not a thing that actually exists in the device tree anywhere. So find the thing in your device tree overlay that is causing this and remove it.

Best Regards,
Jeremias

@jeremias.tx
Well, it wasn’t an issue before. I had the hdmi stuff I disabled (because I was disabling the overlay, for the container issue).
I didn’t realize that disabling something that was already disabled, would cause an issue. That is obviously something new in 6.5 and above.

Steve

I didn’t realize that disabling something that was already disabled, would cause an issue. That is obviously something new in 6.5 and above.

I think you’re misunderstanding again. This was not what I said. Please read carefully my previous message. I said that FDT_ERR_NOTFOUND can occur when your overlay is referencing something that does not exist in the base device tree. Disabling something does not make it not exist, it still exists it’s just disabled.

This should be simple, here is my overlay that I have based on our discussion so far:

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include "imx8mp-pinfunc.h"

/ {
        compatible = "toradex,verdin-imx8mp";
};

&nau8822_1a {
        status = "disabled";
};

&hwmon {
        status = "disabled";
};

&pwm3 {
        status = "disabled";
};

&i2c6 {
        clock-frequency = <400000>;
        pinctrl-names = "default", "gpio";
        pinctrl-0 = <&pinctrl_i2c6>;
        pinctrl-1 = <&pinctrl_i2c6_gpio>;
        scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
        sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
        status = "okay";
};

&iomuxc {
        pinctrl_i2c6: i2c6grp {
                fsl,pins =
                        <MX8MP_IOMUXC_SAI5_RXFS__I2C6_SCL 0x400001c6>,
                        <MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c6>;
        };

        pinctrl_i2c6_gpio: i2c6gpiogrp {
                fsl,pins =
                        <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19             0x400001c6>,
                        <MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20              0x400001c6>;
        };
};

I can confirm this 100% works on 6.5.0 with no issues, provided this is the only overlay being applied on the system. Now look at my overlay, compare it to your overlay. Spot the differences, one or more of these differences is responsible for this issue you’re seeing.

Every time you deviate from the instructions I am providing, you run into another issue. This thread can not go on forever like this.

Best Regards,
Jeremias

@jeremias.tx
Yes, it is also what I came up with.
I had other stuff in there when I had the hdmi overlay added in, trying to disable all of its parts. because of the container issue. I wasn’t expecting to have it decide that I can’t disable something that is already disabled or has no reference to. I am surprised it won’t boot with that, since it shouldn’t cause an issue, since it worked fine in 6.4.0. Also, it wasn’t caught in the builder either. I could see that it would throw an error though.

Thanks for your help!

Steve

I wasn’t expecting to have it decide that I can’t disable something that is already disabled or has no reference to

You’re still not understanding me on this part. There is NO issue with disabling something that is already disabled. The only issue is trying to change something that does not exist in the device tree like my example with &foobar.

I am surprised it won’t boot with that, since it shouldn’t cause an issue, since it worked fine in 6.4.0.

Perhaps there was a minor device tree change between 6.4.0 and 6.5.0 that causes your device tree overlay to be invalid. If you maybe showed me your full overlay like I’ve been asking I would be able to identify what the issue is.

Also, it wasn’t caught in the builder either. I could see that it would throw an error though.

The builder tool just cares that the overlay syntax is correct. It doesn’t check that it’s valid against the device tree running on the device, since it might not know what’s running on the device.

Best Regards,
Jeremias

@jeremias.tx
No, I understand you. The problem is that all the other things in had in there were directly copied out of the hdmi overlay file where it’s just enabling a bunch of things.

So I am not sure what was the problem because I put back everything and it booted fine. Anyway, I understand what you are saying about the “unknown” thing. But since this was all things that were enabled, I don’t see how that could be.

And my other point is why would it not boot if it can’t find something? I could see it complaining and giving an error, but not booting? That seems harsh.

Anyway, I don’t have time to chase this down anymore, I have a working system. I do have these things during the boot that it states. I know we don’t have a clock, since our product is not connected to the outside world at this point, it doesn’t matter. but if I could get rid of the other things, maybe it would boot even faster.

Starting kernel …

[ 0.895211] imx-drm display-subsystem: no available port
[ 1.019720] pca953x 3-0021: failed writing register
[ 1.085988] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[ 1.100010] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[ 1.109575] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[ 2.393076] +V3.3_SW: Underflow of regulator enable count

Thank you!
Steve

I could better assist you, if you would just simply provide your overlay file you are using as I have been requesting you multiple times now. I’m not sure how you expect me to help you without being provided the information I’ve requested from you.

This is my current overlay.

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include “imx8mp-pinfunc.h”

/ {
compatible = “toradex,verdin-imx8mp”;
};

&pinctrl_pwm_3 {
status = “disabled”;
};

&pinctrl_pwm_3_dsi_hpd_gpio {
status = “disabled”;
};

&pinctrl_sai1 {
status = “diabled”;
};

&pwm3 {
status = “disabled”;
};

&nau8822_1a {
status = “disabled”;
};

&hwmon {
status = “disabled”;
};

&i2c6 {
clock-frequency = <400000>;
pinctrl-names = “default”, “gpio”;
pinctrl-0 = <&pinctrl_i2c6>;
pinctrl-1 = <&pinctrl_i2c6_gpio>;
scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = “okay”;
};

/* Verdin SPI_1 */
&ecspi1 {
#address-cells = <1>;
#size-cells = <0>;
cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_ecspi1>;
};

&iomuxc {
pinctrl_i2c6: i2c6grp {
fsl,pins =
<MX8MP_IOMUXC_SAI5_RXFS__I2C6_SCL 0x400001c6>,
<MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c6>;
};

    pinctrl_i2c6_gpio: i2c6gpiogrp {
            fsl,pins =
                    <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19             0x400001c6>,  
                    <MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20              0x400001c6>;

    };
    pinctrl_ecspi1: ecspi1grp {
            fsl,pins =
                    <MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO          0x1c4>, /* SODIMM 198 */
                    <MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI          0x4>,   /* SODIMM 200 */
                    <MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK          0x4>,   /* SODIMM 196 */
                    <MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09            0x1c4>; /* SODIMM 202 */
    };        

};

/* Verdin SPI_1 this turns on the driver for SPI */
&ecspi1 {
#address-cells = <1>;
#size-cells = <0>;
status = “okay”;

    spidev@0 {
            /* Use compatible "rohm,dh2228fv" to bind spidev driver */
            compatible = "rohm,dh2228fv";
            reg = <0>;
            spi-max-frequency = <10000000>;
    };

};

/* EEPROM on Verdin Development board */
&eeprom_carrier_board {
status = “okay”;
};

Here’s a simpler version of what you have:

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include "imx8mp-pinfunc.h"

/ {
        compatible = "toradex,verdin-imx8mp";
};

&gpio_expander_21 {
        status = "disabled";
};

&nau8822_1a {
        status = "disabled";
};

&hwmon {
        status = "disabled";
};

&pwm3 {
        status = "disabled";
};

&i2c6 {
        clock-frequency = <400000>;
        pinctrl-names = "default", "gpio";
        pinctrl-0 = <&pinctrl_i2c6>;
        pinctrl-1 = <&pinctrl_i2c6_gpio>;
        scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
        sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
        status = "okay";
};

&ecspi1 {
        #address-cells = <1>;
        #size-cells = <0>;
        status = "okay";

        spidev@0 {
                /* Use compatible "rohm,dh2228fv" to bind spidev driver */
                compatible = "rohm,dh2228fv";
                reg = <0>;
                spi-max-frequency = <10000000>;
        };
};

&iomuxc {
        pinctrl_i2c6: i2c6grp {
                fsl,pins =
                        <MX8MP_IOMUXC_SAI5_RXFS__I2C6_SCL 0x400001c6>,
                        <MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c6>;
        };

        pinctrl_i2c6_gpio: i2c6gpiogrp {
                fsl,pins =
                        <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19             0x400001c6>,
                        <MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20              0x400001c6>;
        };
};

Most of your overlay wasn’t actually doing anything or was redundant. What I just shared has equivalent behavior to your overlay, removing the useless and redundant portions.

I was able to remove the pca953x 3-0021: failed writing register message by disabling gpio_expander_21 as you can see. All the other logs are inherent to the system and can’t be trivially removed. These logs are not harmful nor do they impact the boot time in any significant way.

If you have any further issues please open a new thread. This thread has gone on long enough and we have deviated from the original topic of the thread. I’ve given you the exact overlay you need for this situation, and I see no point in prolonging this discussion any further.

Best Regards,
Jeremias