About Beaglebone Black device tree

[Christian Mauderer]

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.