<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 10, 2020 at 5:21 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.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">On 10/02/2020 10:58, Vijay Kumar Banerjee wrote:<br>
> On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
> <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<br>
>     producing<br>
>     > a lot<br>
>     > of "target-module" and during startup, the driver probes are<br>
>     looping over<br>
>     > these target modules for the device tree values instead of looking<br>
>     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<br>
>     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<br>
>     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<br>
>     that issue?<br>
> <br>
> <br>
> The FreeBSD device tree was updated with the DTS from Linux 5.0 in<br>
> this commit: 1b4c7d421757 . This changed the structure of the device tree<br>
> and the issue is coming up since this commit.<br>
<br>
Sorry: I asked the wrong question. It's quite clear that the DTS<br>
changed. But it sounds like FreeBSD should have the same problems,<br>
shouldn't they? So I'm a bit astonished that the drivers haven't been<br>
adapted. Is there something that we missed during an update or would you<br>
expect that FreeBSD in that version don't work either?<br>
<br>
Best regards<br>
<br>
Christian<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax:   +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div></div>