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

[Christian Mauderer]

On 09/06/2019 08:59, Chris Johns wrote:
> On 9/6/19 4:29 pm, Vijay Kumar Banerjee wrote:
>> On Sun, Jun 9, 2019 at 6:22 AM Chris Johns <chrisj at rtems.org
>> <mailto: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
>>     <mailto:amalaye.oyake at jpl.nasa.gov>>
>>     >> An: "Chris Johns" <chrisj at rtems.org <mailto:chrisj at rtems.org>>, "Vijay
>>     Kumar Banerjee" <vijaykumar9597 at gmail.com
>>     <mailto:vijaykumar9597 at gmail.com>>, "Christian Mauderer"
>>     >> <christian.mauderer at embedded-brains.de
>>     <mailto:christian.mauderer at embedded-brains.de>>
>>     >> CC: "RTEMS Users" <users at rtems.org <mailto: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. 
> 
> Could cpukit/dtc/libfd in RTEMS be updated to support this code? I see freebsd's
> kernel has the code.
> 

Theoretically that could be possible. If I understand it correctly, that
would mean that we could apply an overlay after boot. That would mean a
lot of additional stuff. For all changed parts the matching drivers
would have to be load or maybe some other ones have to be unload.
Basically we would need a dynamic device management for that. As long as
there is no concrete use case I don't think it's useful to do that work.

>>
>>     > 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 <mailto:users-bounces at rtems.org> on
>>     >> behalf of chrisj at rtems.org <mailto: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.
> 
> Ah I see. I think this could be added to rtems-boot-image. There is something
> attractive about building the fdt at run time on the board from the needed pieces.

If you try to do a more general purpose approach it could be worth
having a look at the boot sequences done on boards like the Beagle or
Raspberry. As far as I know they have sequences that just apply all
overlays from a directory.

Best regards

Christian

> 
> Chris
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>