About Beaglebone Black device tree

[Christian Mauderer]

On 09/02/2020 23:56, Chris Johns wrote:
> On 9/2/20 9:33 pm, Christian Mauderer wrote:
>> On 07/02/2020 18:23, Vijay Kumar Banerjee wrote:
>> On Mon, Feb 3, 2020 at 7:21 PM Christian Mauderer
>>> <christian.mauderer at embedded-brains.de
>>> <mailto: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>
>>>     > <mailto: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>>
>>>     >     > <mailto: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:
>>>     >     >
>>>     >     > 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? 
>>
>> I think it's a bit too small for a GSoC project but it could be a
>> starting point for someone who wants to get knowledge about the libbsd
>> build system. So: Yes, a ticket sounds good.
> 
> The rtems-boot-image handles loading FDT files onto an SD card and I plan to add
> overlay support when I find time to get back to this tool.
> 
> I am not sure if this is the right place to add what you are discussing. I raise
> this because getting these files on to an SD card and having u-boot load them is
> another issue so may be this tool can help solve this problem as well.
> 
> Chris
> 

Hello Chris,

thanks for your input. I'm still not entirely happy with the location
too. But I also don't know a better one. Currently I know of the
following necessary cases:

- Build a dtb from FreeBSD sources (or some other source).

- Build an overlay from some RTEMS source (for example: Using an i2c
adaption layer for libbsd instead of using the i2c hardware directly).

- For some targets with a simple bootloader that can only load one
device tree binary: Merge the overlays with the base tree.

The dts from FreeBSD could either be imported in libbsd or pulled from a
download (note: either many files for all dts, dtsi and headers or one
big file for the complete FreeBSD source tree). The overlays for RTEMS
are a bit less easy: There should be a place for them in RTEMS
somewhere. And I really don't know where would be a good one. Do you
have any suggestions?

Best regards

Christian
-- 
--------------------------------------------
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.