On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer <l...@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@b000 {
> > status = "okay";
> > compatible = "ti,sysc-omap2\0ti,sysc";
> > ....
> >
> > i2c@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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
