About Beaglebone Black device tree

[Vijay Kumar Banerjee]

On Mon, Feb 10, 2020 at 9:43 PM Vijay Kumar Banerjee <
vijaykumar9597 at gmail.com> wrote:

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

> 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/66d37855/attachment.html>