[EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

[Vijay Kumar Banerjee]

On Sun, Jun 9, 2019 at 6:22 AM Chris Johns <chrisj at rtems.org> wrote:

>
>
> On 8/6/19 5:58 pm, Christian Mauderer wrote:
> > ----- Ursprüngliche Mail -----
> >> Von: "Oyake, Amalaye (386M)" <amalaye.oyake at jpl.nasa.gov>
> >> An: "Chris Johns" <chrisj at rtems.org>, "Vijay Kumar Banerjee" <
> vijaykumar9597 at gmail.com>, "Christian Mauderer"
> >> <christian.mauderer at embedded-brains.de>
> >> CC: "RTEMS Users" <users at rtems.org>
> >> Gesendet: Samstag, 8. Juni 2019 04:57:02
> >> Betreff: Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or
> wired)
> >
> >> Device Tree overays are a method used to update the Device Tree. Given
> a device
> >> tree that describes all the devices, let's say you add a new SPI
> device, you
> >> can update the device tree with a (blob) device tree overlay.
> >>
> >> I should ask (without Googling), What is the Device Tree Overlay
> mechanism in
> >> RTEMS?
> >
> >
> > Hello Amalaye,
> >
> > as far as I know, the device tree overlay mechanism in RTEMS is not
> implemented. There is the prototype of fdt_overlay_apply() in libfdt.h but
> there is no implementation. So there are two methods:
> >
> > 1. Applying the overlay on a build machine. Vijay did that during his
> tests.
>
> How do you do this?
>
> I used `fdtoverlay` from libfdt on linux host.

> > 2. Use the U-Boot mechanism to apply overlays before booting RTEMS. That
> should most likely work too. But I didn't test it yet.
>
> OK
>
> >> On 6/7/19, 6:17 PM, "users on behalf of Chris Johns" <
> users-bounces at rtems.org on
> >> behalf of chrisj at rtems.org> wrote:
> >>
> >>    On 8/6/19 1:53 am, Vijay Kumar Banerjee wrote:
> >>    >
> >>    > I would like to add that in two projects of this year( I2C and
> PRU-ICSS drivers)
> >>    > we
> >>    > are using our own device tree overlays that make our drivers work.
> Where to add
> >>    > the device
> >>    > tree related stuff seems like an important question.
> >>
> >>    What are device tree overlays?
> >
> > Like Oyake already said: They are some small pices of device trees that
> are just added to the base tree in it's binary form. Linux (and most likely
> FreeBSD too) supports that even after boot. If you add an overlay it
> re-parses the device tree, updates GPIO settings and loads new drivers. The
> alternative is to let the boot loader apply them during boot.
>
> What is needed to do this? Maybe I can add it to rtems-boot-image as a way
> to
> handle this at the u-boot version.
>
> I have also tried to automate it by adding it in uEnv.txt as a script, it
worked nicely to apply
the overlay on the blob, I haven't tested it with any app though, but the
overlay applied
successfully. Here's what the test uEnv.txt looks like.
```
setenv bootdelay 5
uenvcmd=run overlay_cmd boot
overlay_cmd=fatload mmc 0 0x80800000 rtems-app.img; fatload mmc 0
0x88000000 am335x-boneblack.dtb; fatload mmc 0 0x88100000
am335x-rtems.dtbo; fdt addr 0x88000000; fdt resize 0x1000; fdt apply
0x88100000;
boot=bootm 0x80800000 - 0x88000000;
```

You can add something like this to the uEnv.txt in SD card image. In the
above script
the am335x-boneblack.dtb is the one from linux and am335x-rtems.dtbo is
generated
with dtc from the overlay written by me.

> A practical example would be adding a I2C device like a DS1338 RTC to the
> extension connector of the Beagle:
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-RTC-DS1338.dts
>
> I see the need for this.
>
> > I suggested them for Vijays GSoC project to be able to add an I2C
> adaption layer so that libbsd uses the RTEMS i2c drivers. That's necessary
> so that RTEMS applications can still use the RTEMS i2c interface but at the
> same time the FreeBSD drivers (in that case for some chip related to HDMI)
> can use the BSD interface.
>
> OK.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190609/980760ed/attachment-0002.html>