Waf Build System Status in RTEMS?

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Feb 26 06:23:55 UTC 2020



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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


More information about the devel mailing list