About Beaglebone Black device tree

[Vijay Kumar Banerjee]

On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200210/2bdd5e21/attachment.html>