On 26/02/2020 03:18, Chris Johns wrote:
The FreeBSD device tree support should be fairly architecture independent.
However, it is not as good/complete/robust as the Linux device tree support. I
am not in favour of adding an RTEMS-specific device tree support.
What do you mean by "RTEMS-specific device tree support"? We have RTEMS support
for FDT in the kernel code and libbsd.

I mean the higher level device tree support which deals with device enumeration (e.g. finding drivers for devices):

https://lists.rtems.org/pipermail/devel/2020-February/057049.html


So again in case I was not making myself clear, I feel FDT support as it stands
is partially implemented and I regret not raising this before now. Having code
to load blobs and drivers that reference blobs is only one part of using FDT,
you need matching and valid FDT sources and blobs and this means we need to
manage the FDT source and maybe create blobs our code references (ie overlays).
As stated I am not in favor of documented URLs etc because they disappear or
change plus it breaks releases as it does not meet our long time requirement for
releases having all files contained in the release held on our servers.

This is blocking a release.

I am looking for solutions to this issue that we can work worth.

Yes, we have only a partial support for device trees. It is better than nothing. For now, I would just document this in the user manual section of the BSP and give some advice. I usually use the device tree that ships with the devices. If a driver cannot cope with it, then I fix the driver.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to