<div dir="ltr"><div dir="ltr"><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 9, 2019 at 6:22 AM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</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"><br>
<br>
On 8/6/19 5:58 pm, Christian Mauderer wrote:<br>
> ----- Ursprüngliche Mail -----<br>
>> Von: "Oyake, Amalaye (386M)" <<a href="mailto:amalaye.oyake@jpl.nasa.gov" target="_blank">amalaye.oyake@jpl.nasa.gov</a>><br>
>> An: "Chris Johns" <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>, "Vijay Kumar Banerjee" <<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a>>, "Christian Mauderer"<br>
>> <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
>> CC: "RTEMS Users" <<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
>> Gesendet: Samstag, 8. Juni 2019 04:57:02<br>
>> Betreff: Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)<br>
> <br>
>> Device Tree overays are a method used to update the Device Tree. Given a device<br>
>> tree that describes all the devices, let's say you add a new SPI device, you<br>
>> can update the device tree with a (blob) device tree overlay.<br>
>><br>
>> I should ask (without Googling), What is the Device Tree Overlay mechanism in<br>
>> RTEMS?<br>
> <br>
> <br>
> Hello Amalaye,<br>
> <br>
> 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:<br>
> <br>
> 1. Applying the overlay on a build machine. Vijay did that during his tests.<br>
<br>
How do you do this?<br>
<br></blockquote><div>I used `fdtoverlay` from libfdt on linux host. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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.<br>
<br>
OK<br>
<br>
>> On 6/7/19, 6:17 PM, "users on behalf of Chris Johns" <<a href="mailto:users-bounces@rtems.org" target="_blank">users-bounces@rtems.org</a> on<br>
>> behalf of <a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br>
>><br>
>>    On 8/6/19 1:53 am, Vijay Kumar Banerjee wrote:<br>
>>    > <br>
>>    > I would like to add that in two projects of this year( I2C and PRU-ICSS drivers)<br>
>>    > we<br>
>>    > are using our own device tree overlays that make our drivers work. Where to add<br>
>>    > the device<br>
>>    > tree related stuff seems like an important question.<br>
>>    <br>
>>    What are device tree overlays?<br>
> <br>
> 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.<br>
<br>
What is needed to do this? Maybe I can add it to rtems-boot-image as a way to<br>
handle this at the u-boot version.<br>
<br></blockquote><div>I have also tried to automate it by adding it in uEnv.txt as a script, it worked nicely to apply</div><div>the overlay on the blob, I haven't tested it with any app though, but the overlay applied</div><div>successfully. Here's what the test uEnv.txt looks like. <br>```</div><div>setenv bootdelay 5<br>uenvcmd=run overlay_cmd boot<br>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;<br>boot=bootm 0x80800000 - 0x88000000;<br>```</div><div><br></div><div>You can add something like this to the uEnv.txt in SD card image. In the above script</div><div>the am335x-boneblack.dtb is the one from linux and am335x-rtems.dtbo is generated</div><div>with dtc from the overlay written by me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> A practical example would be adding a I2C device like a DS1338 RTC to the extension connector of the Beagle: <a href="https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-RTC-DS1338.dts" rel="noreferrer" target="_blank">https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-RTC-DS1338.dts</a><br>
<br>
I see the need for this.<br>
<br>
> 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.<br>
<br>
OK.<br>
<br>
Chris<br>
</blockquote></div></div>