On 07/02/2020 18:23, Vijay Kumar Banerjee wrote: > > > > On Mon, Feb 3, 2020 at 7:21 PM Christian Mauderer > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>> wrote: > > On 02/02/2020 18:34, Vijay Kumar Banerjee wrote: > > > > > > > > On Sun, Feb 2, 2020 at 9:49 PM Christian Mauderer > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote: > > > > > > On 31/01/2020 17:43, Vijay Kumar Banerjee wrote: > > > > > > > > > On Fri, Jan 31, 2020 at 9:59 PM Christian Mauderer > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> wrote: > > > > > > On 31/01/2020 17:25, Christian Mauderer wrote: > > > > On 31/01/2020 16:04, Vijay Kumar Banerjee wrote: > > > >> Hi, > > > >> > > > >> While trying to run an rtems-littlevgl app on BBB, I > found that > > > the device > > > >> tree generated from the freebsd source matching the > freebsd-org > > > >> HEAD commit doesn't work with the app and framebuffer > > device fails > > > >> to open. This is most likely due to the changes in the > > freebsd dts > > > >> sources because of which the overlay isn't working as > expected. > > > > > > > > If I remember correctly, SD card doesn't work either > with a FDT > > > that is > > > > too new. > > > > > > > >> > > > >> I haven't had a detailed look at what's missing and the > > u-boot isn't > > > >> reporting any error in applying the overlay either. I > checked > > > that the > > > >> device tree built from freebsd tree matching the > > following commit > > > >> works: > > > >> 19a6ceb89dbacf74697d493e48c388767126d418 > > > > > > > > At the moment that's the right one. But that can change if > > someone > > > > updates libbsd again. > > > > > > And I have to correct myself: That is not the right one. The > > current > > > libbsd HEAD should work with > > 6b0307a0a5184339393f555d5d424190d8a8277a. > > > > > > I meant to say that the framebuffer doesn't work with the > current HEAD > > > (6b0307). > > > I checked with a previous commit, which is 19a6ce and found it > > working. > > > I should have been clear in the problem statement, sorry > about that. > > > > Thats not good. But the correct way would be to find out > what's wrong > > and fix it. Did they add a fix in a future FreeBSD version? > > > > Most likely the overlay isn't working as expected. I'll have to have a > > detailed > > look to figure out what's going on there. > > > > 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? > > > > > > > > > > > > >> > > > >> This brings up two questions: > > > >> 1. Should we add the commit hash in the user manual > so that the > > > user can > > > >> build > > > >> from source matching that commits instead of > HEAD. This > > can be a > > > >> problem > > > >> as other codes ported from freebsd might break if the > > device tree > > > >> doesn't > > > >> match the HEAD commit of freebsd-org > > > > > > > > Adding a fixed commit id isn't really a good idea > either. It > > is nearly > > > > guaranteed that no one updates it if libbsd is updated. It > > would be > > > > better to add instructions how to find out which commit > > should be > > > used. > > > > > > The command would be: > > > > > > git ls-files -s freebsd-org > > > > > > It works regardless whether the sub-module is > initialized or not. > > > > > > > > > > >> > > > >> 2. How do we manage the device tree overlays required by > > RTEMS or > > > libbsd? > > > >> I guess only BBB uses an overlay currently. Can > we add > > a BSD > > > license to > > > >> the overlay and add it somewhere in rtems or > rtems-libbsd > > > repository and > > > >> maintain it? > > > > > > > > I think you wrote the overlay so you can add any > license you > > want. But > > > > I'm really not sure where to put it. We currently > don't have a > > > location > > > > for that. Do you have a good suggestion? > > > > > > > > > > How about rtemsbsd/sys/dts/arm/overlays ? > > > Following the freebsd tree freebsd/sys/dts/arm/overlays/ > > > > Following the FreeBSD tree is a good point. But would they be > visible > > there? Beneath that: We currently don't have support for > building the > > overlays. Do you have an idea how that could look like? > > > > keeping it visible will be a problem. For building the overlay, we can > > use dtc > > and add a script to build the overlay. I see that rsb has a build > > package for > > devel/dtc.bset as well. > > Hm. Optimal would be an integration into waf. Something like "waf > fdt-overlay". Even better would be if we could build the original fdt > too. But I'm sure that both would be quite a bit tricky to integrate > (the waf scripts in libbsd are not really easy to understand). So I'm > not insisting on that. > > Sounds like it can become a good small project. Do we want a ticket > for this? I think it's a bit too small for a GSoC project but it could be a starting point for someone who wants to get knowledge about the libbsd build system. So: Yes, a ticket sounds good. > > > > > Best regards > > > > Christian > > > > > > > > > Best regards > > > > > > > > Christian > > > > > > > >> > > > >> Best regards, > > > >> Vijay> > > > >> _______________________________________________ > > > >> devel mailing list > > > >> devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>>> > > > >> http://lists.rtems.org/mailman/listinfo/devel > > > >> > > > > > > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org <mailto:devel@rtems.org> > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > -------------------------------------------- > 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. > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
