d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
58f351825a
freebsd-dev/sys/conf/dtb.build.mk

82 lines
2.6 KiB
Makefile
Raw Normal View History

Allow kernel config to specify DTS/DTSO to build, and out-of-tree support This allows for directives such as makeoptions DTS+=/out/of/tree/myboard.dts # in tree! Same rules applied as if this were in a dtb/ module makeoptions DTS+=otherboard.dts to be specified in config(5) and have these built/installed alongside th 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. The build/install targets were split out of dtb.mk to centralize the build logic and leave out the all/realinstall/CLEANFILES additions... it was believed that we didn't want to pollute the kernel build with these. The build rules were converted to suffix rules at the suggestion of Ian to clean things up a little bit in a world where we can have mixed in-tree/out-of-tree DTS/DTSO specified. Reviewed by: ian MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D19351
2019-03-26 02:45:23 +00:00
# $FreeBSD$
.include <bsd.init.mk>
# Grab all the options for a kernel build. For backwards compat, we need to
# do this after bsd.own.mk.
.include "kern.opts.mk"
DTC?= dtc
.if !defined(SYSDIR)
.if defined(S)
SYSDIR= ${S}
.else
Introduce bsd.sysdir.mk to consolidate looking for the kernel. Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D22144
2019-11-21 15:59:33 +00:00
.include <bsd.sysdir.mk>
Allow kernel config to specify DTS/DTSO to build, and out-of-tree support This allows for directives such as makeoptions DTS+=/out/of/tree/myboard.dts # in tree! Same rules applied as if this were in a dtb/ module makeoptions DTS+=otherboard.dts to be specified in config(5) and have these built/installed alongside th 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. The build/install targets were split out of dtb.mk to centralize the build logic and leave out the all/realinstall/CLEANFILES additions... it was believed that we didn't want to pollute the kernel build with these. The build rules were converted to suffix rules at the suggestion of Ian to clean things up a little bit in a world where we can have mixed in-tree/out-of-tree DTS/DTSO specified. Reviewed by: ian MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D19351
2019-03-26 02:45:23 +00:00
.endif # defined(S)
.endif # defined(SYSDIR)
.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/)
.error "can't find kernel source tree"
.endif
fdt: Fix installation of aarch64 dtb r345519 rewrote parts of how we build .dtb, but mistakenly dropped the vendor dir for aarch64. Simply drop the :T for building ${DTB} in the aarch64 case- it'll get applied at install-time as-needed, with :H:T for determining the vendor dir. Reported by: manu Tested by: manu Reviewed by: manu MFC after: 3 days
2019-05-02 16:56:03 +00:00
.for _dts in ${DTS}
# DTB for aarch64 needs to preserve the immediate parent of the .dts, because
# these DTS are vendored and should be installed into their vendored directory.
Use MACHINE_CPUARCH when checking for arm64 Use MACHINE_CPUARCH with arm64 (aarch64) when we build code that could run on any 64-bit Arm instruction set. This will simplify checks in downstream consumers targeting prototype instruction sets. The only place we check for MACHINE_ARCH == aarch64 is when building the device tree blobs. As these are targeting current generation ISAs. Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D26370
2020-09-14 16:12:28 +00:00
.if ${MACHINE_CPUARCH} == "aarch64"
fdt: Fix installation of aarch64 dtb r345519 rewrote parts of how we build .dtb, but mistakenly dropped the vendor dir for aarch64. Simply drop the :T for building ${DTB} in the aarch64 case- it'll get applied at install-time as-needed, with :H:T for determining the vendor dir. Reported by: manu Tested by: manu Reviewed by: manu MFC after: 3 days
2019-05-02 16:56:03 +00:00
DTB+= ${_dts:R:S/$/.dtb/}
.else
DTB+= ${_dts:T:R:S/$/.dtb/}
.endif
.endfor
Allow kernel config to specify DTS/DTSO to build, and out-of-tree support This allows for directives such as makeoptions DTS+=/out/of/tree/myboard.dts # in tree! Same rules applied as if this were in a dtb/ module makeoptions DTS+=otherboard.dts to be specified in config(5) and have these built/installed alongside th 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. The build/install targets were split out of dtb.mk to centralize the build logic and leave out the all/realinstall/CLEANFILES additions... it was believed that we didn't want to pollute the kernel build with these. The build rules were converted to suffix rules at the suggestion of Ian to clean things up a little bit in a world where we can have mixed in-tree/out-of-tree DTS/DTSO specified. Reviewed by: ian MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D19351
2019-03-26 02:45:23 +00:00
DTBO=${DTSO:T:R:S/$/.dtbo/}
.SUFFIXES: .dtb .dts .dtbo .dtso
.PATH.dts: ${SYSDIR}/gnu/dts/${MACHINE} ${SYSDIR}/dts/${MACHINE}
.PATH.dtso: ${SYSDIR}/dts/${MACHINE}/overlays
.export DTC ECHO
.dts.dtb: ${OP_META}
@${ECHO} Generating ${.TARGET} from ${.IMPSRC}
@${SYSDIR}/tools/fdt/make_dtb.sh ${SYSDIR} ${.IMPSRC} ${.OBJDIR}
.dtso.dtbo: ${OP_META}
@${ECHO} Generating ${.TARGET} from ${.IMPSRC}
@${SYSDIR}/tools/fdt/make_dtbo.sh ${SYSDIR} ${.IMPSRC} ${.OBJDIR}
# Add dependencies on the source file so that out-of-tree things can be included
# without any .PATH additions.
fdt: stop installing FDT_DTS_FILE r346307 inadvertently started installing FDT_DTS_FILE along with the kernel. While this isn't necessarily bad, it was not intended or discussed and it actively breaks some current setups that don't anticipate any .dtb being installed when it's using static fdt. This change could be reconsidered down the line, but it needs to be done with prior discussion. Fix it by pushing FDT_DTS_FILE build down into the raw dtb.build.mk bits. This technically allows modules building DTS to accidentally specify an FDT_DTS_FILE that gets built but isn't otherwise useful (since it's not installed), but I suspect this isn't a big deal and would get caught with any kind of testing -- and perhaps this might end up useful in some other way, for example by some module wanting to embed fdt in some other way than our current/normal mechanism. Reported by: Mori Hiroki <yamori813@yahoo.co.jp> MFC after: 3 days X-MFC-With: r346307
2019-04-24 01:11:50 +00:00
.for _dts in ${DTS} ${FDT_DTS_FILE}
Allow kernel config to specify DTS/DTSO to build, and out-of-tree support This allows for directives such as makeoptions DTS+=/out/of/tree/myboard.dts # in tree! Same rules applied as if this were in a dtb/ module makeoptions DTS+=otherboard.dts to be specified in config(5) and have these built/installed alongside th 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. The build/install targets were split out of dtb.mk to centralize the build logic and leave out the all/realinstall/CLEANFILES additions... it was believed that we didn't want to pollute the kernel build with these. The build rules were converted to suffix rules at the suggestion of Ian to clean things up a little bit in a world where we can have mixed in-tree/out-of-tree DTS/DTSO specified. Reviewed by: ian MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D19351
2019-03-26 02:45:23 +00:00
${_dts:R:T}.dtb: ${_dts}
.endfor
.for _dtso in ${DTSO}
${_dtso:R:T}.dtbo: ${_dtso}
.endfor
_dtbinstall:
# Need to create this because installkernel doesn't invoke mtree with BSD.root.mtree
# to make sure the tree is setup properly. We don't recreate it to avoid duplicate
# entries in the NO_ROOT case.
test -d ${DESTDIR}${DTBDIR} || ${INSTALL} -d -o ${DTBOWN} -g ${DTBGRP} ${DESTDIR}${DTBDIR}
.for _dtb in ${DTB}
.if ${MACHINE_CPUARCH} == "aarch64"
# :H:T here to grab the vendor component of the DTB path in a way that
# allows out-of-tree DTS builds, too. We make the assumption that
# out-of-tree DTS will have a similar directory structure to in-tree,
# with .dts files appearing in a vendor/ directory.
test -d ${DESTDIR}${DTBDIR}/${_dtb:H:T} || ${INSTALL} -d -o ${DTBOWN} -g ${DTBGRP} ${DESTDIR}${DTBDIR}/${_dtb:H:T}
${INSTALL} -o ${DTBOWN} -g ${DTBGRP} -m ${DTBMODE} \
${_INSTALLFLAGS} ${_dtb:T} ${DESTDIR}${DTBDIR}/${_dtb:H:T}
.else
${INSTALL} -o ${DTBOWN} -g ${DTBGRP} -m ${DTBMODE} \
${_INSTALLFLAGS} ${_dtb} ${DESTDIR}${DTBDIR}/
.endif
.endfor
test -d ${DESTDIR}${DTBODIR} || ${INSTALL} -d -o ${DTBOWN} -g ${DTBGRP} ${DESTDIR}${DTBODIR}
.for _dtbo in ${DTBO}
${INSTALL} -o ${DTBOWN} -g ${DTBGRP} -m ${DTBMODE} \
${_INSTALLFLAGS} ${_dtbo} ${DESTDIR}${DTBODIR}/
.endfor
Reference in New Issue Copy Permalink