About Beaglebone Black device tree

[Vijay Kumar Banerjee]

On Mon, Feb 10, 2020 at 5:21 PM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:

> On 10/02/2020 10:58, Vijay Kumar Banerjee wrote:
> > On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer <list at c-mauderer.de
> > <mailto:list at c-mauderer.de>> wrote:
> >
> >
> >     > Hi!
> >     >
> >     > I looked into it in more detail, the issue isn't with the overlay,
> I
> >     > verified it
> >     > using u-boot fdt tool as well. Looks like the base dts file is
> >     producing
> >     > a lot
> >     > of "target-module" and during startup, the driver probes are
> >     looping over
> >     > these target modules for the device tree values instead of looking
> >     at the
> >     > device node under the target module.
> >     >
> >     > For example, in case of i2c the device tree looks like this:
> >     > ```
> >     >                 target-module at b000 {
> >     >                     status = "okay";
> >     >                     compatible = "ti,sysc-omap2\0ti,sysc";
> >     >                     ....
> >     >
> >     >                     i2c at 0 {
> >     >                         rtems-pinctrl-0 = < 0x2e >;
> >     >                         rtems,i2c-path = "/dev/i2c-0";
> >     >                         compatible = "rtems,bsp-i2c\0ti,omap4-i2c";
> >     >                         .....
> >     > ```
> >     >
> >     > In the above snippet, the probe function expects the compat value
> >     to be
> >     > "rtems,bsp-i2c" but is getting "ti,sysc-omap2" from the
> target-module
> >     > and returning ENXIO. This is true for all the values, not just
> compat.
> >     >
> >     > When I added all the required values of i2c into the target-module
> >     through
> >     > overlay, the iicbus worked. As you said in the thread, looks like
> i2c
> >     > isn't the
> >     > only device that's affected looks like a lot of devices are failing
> >     > because of
> >     > this dts issue. Here's a dump
> >     > <https://paste.ofcode.org/iDKusQxibBXCLMVJb6KG6q> of start
> messages
> >     > after applying the overlay
> >     > hack for i2c and lcd probe. (Note that this is an issue with the
> >     > tda19988 as well,
> >     > because of which framebuffer isn't working)
> >
> >     Did something in the FreeBSD device tree sources change to cause
> >     that issue?
> >
> >
> > The FreeBSD device tree was updated with the DTS from Linux 5.0 in
> > this commit: 1b4c7d421757 . This changed the structure of the device tree
> > and the issue is coming up since this commit.
>
> Sorry: I asked the wrong question. It's quite clear that the DTS
> changed. But it sounds like FreeBSD should have the same problems,
> shouldn't they? So I'm a bit astonished that the drivers haven't been
> adapted. Is there something that we missed during an update or would you
> expect that FreeBSD in that version don't work either?
>
> Best regards
>
> Christian
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200210/32c6701d/attachment-0001.html>