On Sun, Jun 9, 2019 at 6:22 AM Chris Johns <chr...@rtems.org> wrote: > > > On 8/6/19 5:58 pm, Christian Mauderer wrote: > > ----- Ursprüngliche Mail ----- > >> Von: "Oyake, Amalaye (386M)" <amalaye.oy...@jpl.nasa.gov> > >> An: "Chris Johns" <chr...@rtems.org>, "Vijay Kumar Banerjee" < > vijaykumar9...@gmail.com>, "Christian Mauderer" > >> <christian.maude...@embedded-brains.de> > >> CC: "RTEMS Users" <users@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-boun...@rtems.org on > >> behalf of chr...@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 >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users