On Mon, Feb 10, 2020 at 9:43 PM Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote:
> > > On Mon, Feb 10, 2020 at 5:21 PM Christian Mauderer < > 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>> 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. > Best regards >> >> Christian >> -- >> -------------------------------------------- >> 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
