About Beaglebone Black device tree
Christian Mauderer
list at c-mauderer.de
Sun Feb 9 10:33:29 UTC 2020
On 07/02/2020 18:23, Vijay Kumar Banerjee wrote:
>
>
>
> On Mon, Feb 3, 2020 at 7:21 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at 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
> <list at c-mauderer.de <mailto:list at c-mauderer.de>
> > <mailto:list at c-mauderer.de <mailto:list at 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
> > <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at 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 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?
>
> > >
>
> > > >
> > > >>
> > > >> 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 at rtems.org <mailto:devel at rtems.org>
> <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>
> <mailto:devel at rtems.org <mailto:devel at rtems.org>>>
> > > >> http://lists.rtems.org/mailman/listinfo/devel
> > > >>
> > >
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org <mailto:devel at rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> <mailto: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.
>
More information about the devel
mailing list