<div dir="ltr"><div dir="ltr"><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>> Hi!<br>
> <br>
> I looked into it in more detail, the issue isn't with the overlay, I<br>
> verified it<br>
> using u-boot fdt tool as well. Looks like the base dts file is producing<br>
> a lot<br>
> of "target-module" and during startup, the driver probes are looping over<br>
> these target modules for the device tree values instead of looking at the<br>
> device node under the target module.<br>
> <br>
> For example, in case of i2c the device tree looks like this:<br>
> ```<br>
>                 target-module@b000 {<br>
>                     status = "okay";<br>
>                     compatible = "ti,sysc-omap2\0ti,sysc";<br>
>                     ....<br>
> <br>
>                     i2c@0 {<br>
>                         rtems-pinctrl-0 = < 0x2e >;<br>
>                         rtems,i2c-path = "/dev/i2c-0";<br>
>                         compatible = "rtems,bsp-i2c\0ti,omap4-i2c";<br>
>                         .....<br>
> ```<br>
> <br>
> In the above snippet, the probe function expects the compat value to be<br>
> "rtems,bsp-i2c" but is getting "ti,sysc-omap2" from the target-module<br>
> and returning ENXIO. This is true for all the values, not just compat.<br>
> <br>
> When I added all the required values of i2c into the target-module through<br>
> overlay, the iicbus worked. As you said in the thread, looks like i2c<br>
> isn't the<br>
> only device that's affected looks like a lot of devices are failing<br>
> because of<br>
> this dts issue. Here's a dump<br>
> <<a href="https://paste.ofcode.org/iDKusQxibBXCLMVJb6KG6q" rel="noreferrer" target="_blank">https://paste.ofcode.org/iDKusQxibBXCLMVJb6KG6q</a>> of start messages<br>
> after applying the overlay<br>
> hack for i2c and lcd probe. (Note that this is an issue with the<br>
> tda19988 as well,<br>
> because of which framebuffer isn't working) <br>
<br>
Did something in the FreeBSD device tree sources change to cause that issue?<br></blockquote><div><br></div><div>The FreeBSD device tree was updated with the DTS from Linux 5.0 in</div><div>this commit: 1b4c7d421757 . This changed the structure of the device tree</div><div>and the issue is coming up since this commit.</div></div></div>