Re: Device tree overlays

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jan 10, 2024, at 8:58 AM, Brook Milligan <brook%nmsu.edu@localhost> wrote:
> 
> I propose the following:
> 
> - Introduce a directory in the source code, presumably under sys, for device tree overlay (*.dts) files.  See below for some considerations of where this might be.

I agree, this would be a good thing.  I agree so much, in fact, that I’ve already put two of them in the tree :-)

	src/sys/arch/arm/dts/overlays/sunxi-h3-h5-nanopi-neo-nas-dock.dts
	src/sys/arch/arm/dts/overlays/sunxi-h3-h5-orangepi-zero-nas.dts

> - During a build, compile the overlay files into binary blobs (*.dtb) files, just as is already done for the main device tree files.

Yah, this part I didn’t do.  But I agree it would be a good thing.

> - As part of a release, install the compiled overlay files in /boot/overlays (or perhaps /boot/dtbo), i.e., in parallel to the main device trees in /boot/dtb.

Again, sounds good to me.

> This would greatly simplify the process of booting an embedded system that relies upon an overlay file and better ensure that the system would work without too much trouble.  It would also provide reference documentation for how to add overlays for less available hardware, something that might encourage embedded development with NetBSD.
> 
> Choice of a suitable source code location likely involves the following considerations:
> 
> - Most likely overlays will originate externally, and will probably have licenses.  Following the standard already in place for the device tree files this would dictate something like sys/external/gpl2/dts/dist/arch/..., which is where the main device tree files are.

Some are also home-grown (the ones above I wrote from scratch based on documentation), so they need a place to live.

> - The (few) overlays that I am familiar with have gpl2 licenses, so the above location may work.  However, if the collection has a mixture of licenses, this is a bit troublesome for tracking down source files.
> 
> - One purpose of integrating these into the NetBSD code base is to maintain them properly, so perhaps a BSD license is appropriate for the files and they do not have to be relegated to external.  The ones I am familiar with are small, are mostly boilerplate, and take details from the relevant TRMs; it is not clear that writing new files from scratch violates copyright, but IANAL.

If you have documentation on the hardware, I would encourage writing the overlays from scratch, using the conventions documented in the FDT bindings.  That’s what I do.

-- thorpej