Page MenuHomeFreeBSD

Allow kernel config to specify DTS/DTSO to build, and out-of-tree support
ClosedPublic

Authored by kevans on Feb 25 2019, 4:24 PM.

Details

Summary

This allows for directives such as

makeoptions DTS+=/out/of/tree/myboard.dts
makeoptions DTS+=/out/of/tree/otherboard.dts

to be specified in config(5) and have these built/installed alongside the kernel. The assumption that overlays live in an overlays/ directory is only made for in-tree DTSO, but we still make the assumption that out-of-tree arm64 DTS will be in vendored directories (for now).

This lowers the cost to hacking on an overlay or dts by being able to quickly throw it in a custom config, especially if it doesn't fit one of the current dtb/modules quite appropriately or it's not intended for commit there.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kevans created this revision.Feb 25 2019, 4:24 PM

Is there a reason to limit this to arm and arm64?

Is there a reason to limit this to arm and arm64?

I have no real reason, other than these two are the primary platforms that I thought would benefit from it. My understanding being that !arm{,v6,v7,64} FDT is either firmware-provided or hardly used (mips?). This could just as easily be included from kern.post.mk and be a nop most of the time -- I have no strong position.

kevans updated this revision to Diff 54391.Feb 26 2019, 5:05 AM

Notable changes:

  • Completely split the basic build/install rules out of dtb.mk so that we don't have to do hacky guess-work in the kernel path based on whether the kernel-install target exists or not.
  • Taught dtb.build.mk about $S rather than searching when S is defined instead of SYSDIR.
  • dtb.build.mk is now included from kern.post.mk instead of Makefile.<arch> if DTS or DTSO are defined -- there's no sense in restricting the platform here if someone wants to use it.
kevans updated this revision to Diff 54626.Mar 3 2019, 2:47 AM
kevans edited the summary of this revision. (Show Details)

Now using suffix rules to clean up the ugliness required (suggested by/discussed with Ian).

I also went ahead and scoped the .PATH additions to specific suffixes that we expect to find in each path. I have no strong reasoning for this change -- these paths shouldn't have anything that would cause problems in the rest of the kernel build.

kevans added a subscriber: bdrewery.

Tagging @bdrewery as well, since I'm hooking this up to the kernel build. A glance over to make sure I'm not doing anything too terrifying would be appreciated.

ian added inline comments.Mar 11 2019, 12:11 AM
sys/conf/dtb.build.mk
72 ↗(On Diff #54626)

This entire .for loop can be eliminated, and all occurrances of ${_dtb} changed to ${DTB}. install(1) will install multiple files or create multiple directories all at once, and the :H:T stuff will be applied to every item in the list if ${DTB} lists multiple files. Likewise with the DTBO loop below.

Hmm, except (now that I've tested that) it turns out that in place of the .for you need .if !empty(DTB/DTBO), otherwise it generates a broken install command when the variable expands to nothing. I like the .if better than the for loop though.

kevans added inline comments.Mar 11 2019, 6:45 PM
sys/conf/dtb.build.mk
72 ↗(On Diff #54626)

I think that's certainly the case for !aarch64, but I think the loop here is still required for aarch64 since those DTB get installed to vendored directories rather than the flattened structure we use everywhere else.

I will likely go ahead and move the loop to the aarch64 case and eliminate the !aarch64 loop as well as the DTBO loop to simplify things.

The test || ${INSTALL} seems like it should also be able to go away with install -d instead.

kevans added inline comments.Mar 11 2019, 6:48 PM
sys/conf/dtb.build.mk
72 ↗(On Diff #54626)

Scratch that last bit... I misrecalled the -d flag's functionality.

ian accepted this revision.Mar 24 2019, 7:22 PM

Looks good and works great.

This revision is now accepted and ready to land.Mar 24 2019, 7:22 PM
This revision was automatically updated to reflect the committed changes.