<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 3, 2020 at 7:21 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02/02/2020 18:34, Vijay Kumar Banerjee wrote:<br>
> <br>
> <br>
> <br>
> On Sun, Feb 2, 2020 at 9:49 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
> <br>
>  Â  Â On 31/01/2020 17:43, Vijay Kumar Banerjee wrote:<br>
>  Â  Â ><br>
>  Â  Â ><br>
>  Â  Â > On Fri, Jan 31, 2020 at 9:59 PM Christian Mauderer<br>
>  Â  Â <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>  Â  Â > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>> wrote:<br>
>  Â  Â ><br>
>  Â  Â >  Â  Â On 31/01/2020 17:25, Christian Mauderer wrote:<br>
>  Â  Â >  Â  Â > On 31/01/2020 16:04, Vijay Kumar Banerjee wrote:<br>
>  Â  Â >  Â  Â >> Hi,<br>
>  Â  Â >  Â  Â >><br>
>  Â  Â >  Â  Â >> While trying to run an rtems-littlevgl app on BBB, I found that<br>
>  Â  Â >  Â  Â the device<br>
>  Â  Â >  Â  Â >> tree generated from the freebsd source matching the freebsd-org<br>
>  Â  Â >  Â  Â >> HEAD commit doesn't work with the app and framebuffer<br>
>  Â  Â device fails<br>
>  Â  Â >  Â  Â >> to open. This is most likely due to the changes in the<br>
>  Â  Â freebsd dts<br>
>  Â  Â >  Â  Â >> sources because of which the overlay isn't working as expected.<br>
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â > If I remember correctly, SD card doesn't work either with a FDT<br>
>  Â  Â >  Â  Â that is<br>
>  Â  Â >  Â  Â > too new.<br>
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â >><br>
>  Â  Â >  Â  Â >> I haven't had a detailed look at what's missing and the<br>
>  Â  Â u-boot isn't<br>
>  Â  Â >  Â  Â >> reporting any error in applying the overlay either. I checked<br>
>  Â  Â >  Â  Â that the<br>
>  Â  Â >  Â  Â >> device tree built from freebsd tree matching the<br>
>  Â  Â following commit<br>
>  Â  Â >  Â  Â >> works:<br>
>  Â  Â >  Â  Â >> 19a6ceb89dbacf74697d493e48c388767126d418<br>
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â > At the moment that's the right one. But that can change if<br>
>  Â  Â someone<br>
>  Â  Â >  Â  Â > updates libbsd again.<br>
>  Â  Â ><br>
>  Â  Â >  Â  Â And I have to correct myself: That is not the right one. The<br>
>  Â  Â current<br>
>  Â  Â >  Â  Â libbsd HEAD should work with<br>
>  Â  Â 6b0307a0a5184339393f555d5d424190d8a8277a.<br>
>  Â  Â ><br>
>  Â  Â > I meant to say that the framebuffer doesn't work with the current HEAD<br>
>  Â  Â > (6b0307).<br>
>  Â  Â > I checked with a previous commit, which is 19a6ce and found it<br>
>  Â  Â working.<br>
>  Â  Â > I should have been clear in the problem statement, sorry about that.<br>
> <br>
>  Â  Â Thats not good. But the correct way would be to find out what's wrong<br>
>  Â  Â and fix it. Did they add a fix in a future FreeBSD version?<br>
> <br>
> Most likely the overlay isn't working as expected. I'll have to have a<br>
> detailed<br>
> look to figure out what's going on there. <br>
> <br></blockquote><div>Hi!</div><div><br></div><div>I looked into it in more detail, the issue isn't with the overlay, I verified it</div><div>using u-boot fdt tool as well. Looks like the base dts file is producing a lot</div><div>of "target-module" and during startup, the driver probes are looping over</div><div>these target modules for the device tree values instead of looking at the</div><div>device node under the target module.</div><div><br></div><div>For example, in case of i2c the device tree looks like this:</div><div>```<br>  Â  Â  Â  Â  Â  Â  Â  target-module@b000 {<br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  status = "okay";<br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  compatible = "ti,sysc-omap2\0ti,sysc";<br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  ....</div><div><br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  i2c@0 {<br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  rtems-pinctrl-0 = < 0x2e >;<br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  rtems,i2c-path = "/dev/i2c-0";<br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  compatible = "rtems,bsp-i2c\0ti,omap4-i2c";<br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  .....<br></div><div>```</div><div><br></div><div>In the above snippet, the probe function expects the compat value to be</div><div>"rtems,bsp-i2c" but is getting "ti,sysc-omap2" from the target-module</div><div>and returning ENXIO. This is true for all the values, not just compat.</div><div><br></div><div>When I added all the required values of i2c into the target-module through</div><div>overlay, the iicbus worked. As you said in the thread, looks like i2c isn't the</div><div>only device that's affected looks like a lot of devices are failing because of</div><div>this dts issue. Here's a <a href="https://paste.ofcode.org/iDKusQxibBXCLMVJb6KG6q">dump</a> of start messages after applying the overlay</div><div>hack for i2c and lcd probe. (Note that this is an issue with the tda19988 as well,</div><div>because of which framebuffer isn't working) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>  Â  Â > </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â >><br>
>  Â  Â >  Â  Â >> This brings up two questions:<br>
>  Â  Â >  Â  Â >> 1. Should we add the commit hash in the user manual so that the<br>
>  Â  Â >  Â  Â user can<br>
>  Â  Â >  Â  Â >> build<br>
>  Â  Â >  Â  Â >> Â  Â  from source matching that commits instead of HEAD. This<br>
>  Â  Â can be a<br>
>  Â  Â >  Â  Â >> problem <br>
>  Â  Â >  Â  Â >> Â  Â  as other codes ported from freebsd might break if the<br>
>  Â  Â device tree<br>
>  Â  Â >  Â  Â >> doesn't<br>
>  Â  Â >  Â  Â >> Â  Â  match the HEAD commit of freebsd-org<br>
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â > Adding a fixed commit id isn't really a good idea either. It<br>
>  Â  Â is nearly<br>
>  Â  Â >  Â  Â > guaranteed that no one updates it if libbsd is updated. It<br>
>  Â  Â would be<br>
>  Â  Â >  Â  Â > better to add instructions how to find out which commit<br>
>  Â  Â should be<br>
>  Â  Â >  Â  Â used.<br>
>  Â  Â ><br>
>  Â  Â >  Â  Â The command would be:<br>
>  Â  Â ><br>
>  Â  Â >  Â  Â Â  Â  git ls-files -s freebsd-org<br>
>  Â  Â ><br>
>  Â  Â >  Â  Â It works regardless whether the sub-module is initialized or not.<br>
>  Â  Â ><br>
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â >><br>
>  Â  Â >  Â  Â >> 2. How do we manage the device tree overlays required by<br>
>  Â  Â RTEMS or<br>
>  Â  Â >  Â  Â libbsd?<br>
>  Â  Â >  Â  Â >> Â  Â  I guess only BBB uses an overlay currently. Can we add<br>
>  Â  Â a BSD<br>
>  Â  Â >  Â  Â license to<br>
>  Â  Â >  Â  Â >> Â  Â  the overlay and add it somewhere in rtems or rtems-libbsd<br>
>  Â  Â >  Â  Â repository and<br>
>  Â  Â >  Â  Â >> Â  Â  maintain it?<br>
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â > I think you wrote the overlay so you can add any license you<br>
>  Â  Â want. But<br>
>  Â  Â >  Â  Â > I'm really not sure where to put it. We currently don't have a<br>
>  Â  Â >  Â  Â location<br>
>  Â  Â >  Â  Â > for that. Do you have a good suggestion?<br>
>  Â  Â >  Â  Â ><br>
>  Â  Â ><br>
>  Â  Â > How about rtemsbsd/sys/dts/arm/overlays ?<br>
>  Â  Â > Following the freebsd tree freebsd/sys/dts/arm/overlays/<br>
> <br>
>  Â  Â Following the FreeBSD tree is a good point. But would they be visible<br>
>  Â  Â there? Beneath that: We currently don't have support for building the<br>
>  Â  Â overlays. Do you have an idea how that could look like?<br>
> <br>
> keeping it visible will be a problem. For building the overlay, we can<br>
> use dtc<br>
> and add a script to build the overlay. I see that rsb has a build<br>
> package for<br>
> devel/dtc.bset as well. <br>
<br>
Hm. Optimal would be an integration into waf. Something like "waf<br>
fdt-overlay". Even better would be if we could build the original fdt<br>
too. But I'm sure that both would be quite a bit tricky to integrate<br>
(the waf scripts in libbsd are not really easy to understand). So I'm<br>
not insisting on that.<br>
<br></blockquote><div>Sounds like it can become a good small project. Do we want a ticket</div><div>for this? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
>  Â  Â Best regards<br>
> <br>
>  Â  Â Christian<br>
> <br>
>  Â  Â ><br>
>  Â  Â >  Â  Â > Best regards<br>
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â > Christian<br>
>  Â  Â >  Â  Â ><br>
>  Â  Â >  Â  Â >><br>
>  Â  Â >  Â  Â >> Best regards,<br>
>  Â  Â >  Â  Â >> Vijay><br>
>  Â  Â >  Â  Â >> _______________________________________________<br>
>  Â  Â >  Â  Â >> devel mailing list<br>
>  Â  Â >  Â  Â >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
>  Â  Â <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>><br>
>  Â  Â >  Â  Â >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>  Â  Â >  Â  Â >><br>
>  Â  Â ><br>
> <br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax:  Â +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div></div>
</div>