About Beaglebone Black device tree
Vijay Kumar Banerjee
vijaykumar9597 at gmail.com
Fri Feb 7 17:23:09 UTC 2020
On Mon, Feb 3, 2020 at 7:21 PM Christian Mauderer <
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>> 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>>> 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)
> > >
> > >
> > > >>
> > > >> 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?
> >
> > 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>>
> > > >> http://lists.rtems.org/mailman/listinfo/devel
> > > >>
> > >
> >
> >
> > _______________________________________________
> > devel mailing list
> > 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
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200207/129295bd/attachment.html>
More information about the devel
mailing list