On 10/02/2020 17:24, Vijay Kumar Banerjee wrote: > > On Mon, Feb 10, 2020 at 9:43 PM Vijay Kumar Banerjee > <vijaykumar9...@gmail.com <mailto:vijaykumar9...@gmail.com>> wrote: > > On Mon, Feb 10, 2020 at 5:21 PM Christian Mauderer > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@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 > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto: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. > > 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.maude...@embedded-brains.de > <mailto:christian.maude...@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.maude...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
