About Beaglebone Black device tree

[Christian Mauderer]

On 10/02/2020 17:24, Vijay Kumar Banerjee wrote:
> 
> On Mon, Feb 10, 2020 at 9:43 PM Vijay Kumar Banerjee
> <vijaykumar9597 at gmail.com <mailto:vijaykumar9597 at gmail.com>> wrote:
> 
>     On Mon, Feb 10, 2020 at 5:21 PM Christian Mauderer
>     <christian.mauderer at embedded-brains.de
>     <mailto: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>
>         > <mailto: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?
> 
> Saying without checking with the FreeBSD build:
> Looks like the fdt drivers should be looking for the child of the
> target-module
> node, instead of the the target-module, I have checked this approach with an
> overlay hack where I modified the target-module to have all the
> device-related
> values. The issue is from the FDT framework it seems. I'm not sure if
> the issue
> is from our side or not but I suspect that the FreeBSD build of the same
> version
> will not work either, I couldn't verify this because of slow downloads.

I understand. As soon as I find some time I'll try to take a look at the
FreeBSD history. Somewhere should be a commit that takes the adapted
structure into account.

Best regards

Christian

> 
>         Best regards
> 
>         Christian
>         -- 
>         --------------------------------------------
>         embedded brains GmbH
>         Herr Christian Mauderer
>         Dornierstr. 4
>         D-82178 Puchheim
>         Germany
>         email: christian.mauderer at embedded-brains.de
>         <mailto: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.
> 

-- 
--------------------------------------------
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.