package/dahdi-linux: new package
dahdi-linux provides kernel modules to drive a variety of telephony
cards, ranging from low-end one-channel to higher-end multi-channel
cards. It also provides headers for userland to talk to those cards.
With a bit of love, dahdi-linux can use our kernel-module
infrastructure. Wee! :-)
Still, there are a few specificities about dahdi-linux.
First, it needs to install a few binary firmware blobs, which it wants
to download at install time. Since we do want to be able to do
completely off-line builds, we need to downlaod them manually. So we
have the full list of firmware blobs (even if some can only be used on
an i386/x86_64 target, we still uconditionally download them), for which
we have locally-computed sha256 (no hash provided by upstream for the
blobs).
Second, the install procedure for the firmware blobs needs to have
access to the Linux kernel .config file, so it can decide whether to
install the blobs or not. We can force not to install them, but we can't
force to install them... :-/ And anyway, we'd have to do the same check
as is already done by dahdi-linux, so no need to duplicate that.
Finally, the licensing is relatively weird. Although it is obvious and
straightforward for the most part of dahdi-linux, consisting of mostly
GPLv2 and a few LGPLv2.1, there is one gotcha.
Of the firmware blobs, one is provided as a .o file, with no licensing
information whatsoever, without any source available from upstream, but
is directly linked to a GPLv2 file.
This is very concerning, but there is not much we can do about it,
except delegate to the legal reviewer whether that is acceptable or not.
AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or
later, as it uses internals that have been removed in linux-4.0. There
has been no update upstream dahdi-linux to fix that. There's not much we
can do, except warn the user in the help text.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: use SPDX license names and add hashes for license files]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-09 23:39:26 +02:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# dahdi-linux
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
2021-11-05 00:12:10 +01:00
|
|
|
DAHDI_LINUX_VERSION = 5c840cf43838e0690873e73409491c392333b3b8
|
2022-04-01 23:56:53 +02:00
|
|
|
DAHDI_LINUX_SITE = https://gerrit.asterisk.org/dahdi-linux
|
|
|
|
|
DAHDI_LINUX_SITE_METHOD = git
|
package/dahdi-linux: new package
dahdi-linux provides kernel modules to drive a variety of telephony
cards, ranging from low-end one-channel to higher-end multi-channel
cards. It also provides headers for userland to talk to those cards.
With a bit of love, dahdi-linux can use our kernel-module
infrastructure. Wee! :-)
Still, there are a few specificities about dahdi-linux.
First, it needs to install a few binary firmware blobs, which it wants
to download at install time. Since we do want to be able to do
completely off-line builds, we need to downlaod them manually. So we
have the full list of firmware blobs (even if some can only be used on
an i386/x86_64 target, we still uconditionally download them), for which
we have locally-computed sha256 (no hash provided by upstream for the
blobs).
Second, the install procedure for the firmware blobs needs to have
access to the Linux kernel .config file, so it can decide whether to
install the blobs or not. We can force not to install them, but we can't
force to install them... :-/ And anyway, we'd have to do the same check
as is already done by dahdi-linux, so no need to duplicate that.
Finally, the licensing is relatively weird. Although it is obvious and
straightforward for the most part of dahdi-linux, consisting of mostly
GPLv2 and a few LGPLv2.1, there is one gotcha.
Of the firmware blobs, one is provided as a .o file, with no licensing
information whatsoever, without any source available from upstream, but
is directly linked to a GPLv2 file.
This is very concerning, but there is not much we can do about it,
except delegate to the legal reviewer whether that is acceptable or not.
AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or
later, as it uses internals that have been removed in linux-4.0. There
has been no update upstream dahdi-linux to fix that. There's not much we
can do, except warn the user in the help text.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: use SPDX license names and add hashes for license files]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-09 23:39:26 +02:00
|
|
|
|
2021-11-05 00:12:10 +01:00
|
|
|
# We need to download all those firmware blobs ourselves, otherwise
|
package/dahdi-linux: new package
dahdi-linux provides kernel modules to drive a variety of telephony
cards, ranging from low-end one-channel to higher-end multi-channel
cards. It also provides headers for userland to talk to those cards.
With a bit of love, dahdi-linux can use our kernel-module
infrastructure. Wee! :-)
Still, there are a few specificities about dahdi-linux.
First, it needs to install a few binary firmware blobs, which it wants
to download at install time. Since we do want to be able to do
completely off-line builds, we need to downlaod them manually. So we
have the full list of firmware blobs (even if some can only be used on
an i386/x86_64 target, we still uconditionally download them), for which
we have locally-computed sha256 (no hash provided by upstream for the
blobs).
Second, the install procedure for the firmware blobs needs to have
access to the Linux kernel .config file, so it can decide whether to
install the blobs or not. We can force not to install them, but we can't
force to install them... :-/ And anyway, we'd have to do the same check
as is already done by dahdi-linux, so no need to duplicate that.
Finally, the licensing is relatively weird. Although it is obvious and
straightforward for the most part of dahdi-linux, consisting of mostly
GPLv2 and a few LGPLv2.1, there is one gotcha.
Of the firmware blobs, one is provided as a .o file, with no licensing
information whatsoever, without any source available from upstream, but
is directly linked to a GPLv2 file.
This is very concerning, but there is not much we can do about it,
except delegate to the legal reviewer whether that is acceptable or not.
AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or
later, as it uses internals that have been removed in linux-4.0. There
has been no update upstream dahdi-linux to fix that. There's not much we
can do, except warn the user in the help text.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: use SPDX license names and add hashes for license files]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-09 23:39:26 +02:00
|
|
|
# dahdi-linux will try to download them at install time.
|
|
|
|
|
DAHDI_LINUX_FW_SITE = http://downloads.digium.com/pub/telephony/firmware/releases
|
|
|
|
|
DAHDI_LINUX_FW_FILES = \
|
|
|
|
|
dahdi-fwload-vpmadt032-1.25.0.tar.gz \
|
|
|
|
|
dahdi-fw-oct6114-032-1.05.01.tar.gz \
|
|
|
|
|
dahdi-fw-oct6114-064-1.05.01.tar.gz \
|
|
|
|
|
dahdi-fw-oct6114-128-1.05.01.tar.gz \
|
|
|
|
|
dahdi-fw-oct6114-256-1.05.01.tar.gz \
|
|
|
|
|
dahdi-fw-tc400m-MR6.12.tar.gz \
|
|
|
|
|
dahdi-fw-hx8-2.06.tar.gz \
|
|
|
|
|
dahdi-fw-vpmoct032-1.12.0.tar.gz \
|
|
|
|
|
dahdi-fw-te820-1.76.tar.gz \
|
|
|
|
|
dahdi-fw-te133-7a001e.tar.gz \
|
|
|
|
|
dahdi-fw-te134-780017.tar.gz \
|
|
|
|
|
dahdi-fw-a8b-1f001e.tar.gz \
|
|
|
|
|
dahdi-fw-a8a-1d0017.tar.gz \
|
|
|
|
|
dahdi-fw-a4b-d001e.tar.gz \
|
|
|
|
|
dahdi-fw-a4a-a0017.tar.gz \
|
|
|
|
|
dahdi-fw-te435-13001e.tar.gz \
|
|
|
|
|
dahdi-fw-te436-10017.tar.gz
|
|
|
|
|
|
|
|
|
|
DAHDI_LINUX_EXTRA_DOWNLOADS = \
|
|
|
|
|
$(patsubst %,$(DAHDI_LINUX_FW_SITE)/%,$(DAHDI_LINUX_FW_FILES))
|
|
|
|
|
|
|
|
|
|
# dahdi-linux claims to be GPLv2 with parts LGPLv2.1 (not 'or later'),
|
|
|
|
|
# but there are the so-called firmware files (downloaded above) for
|
|
|
|
|
# which the license is unclear: the header claims to be GPLv2, the
|
|
|
|
|
# 'loader-wrapper' claims to be GPLv2, but there are two so-called
|
|
|
|
|
# 'firmware' binary-only .o blobs for which the license is not
|
|
|
|
|
# explicited, which look like they end up as part of a kernel module,
|
|
|
|
|
# and for which the source is nowhere to be found on the upstream site
|
|
|
|
|
# (they are only for x86/x86_64, but we still list them unconditionally).
|
|
|
|
|
DAHDI_LINUX_LICENSE = GPL-2.0, LGPL-2.1, unknown (firmware files)
|
|
|
|
|
DAHDI_LINUX_LICENSE_FILES = LICENSE LICENSE.LGPL
|
|
|
|
|
|
|
|
|
|
DAHDI_LINUX_INSTALL_STAGING = YES
|
|
|
|
|
|
|
|
|
|
DAHDI_LINUX_MODULE_SUBDIRS = drivers/dahdi
|
|
|
|
|
|
|
|
|
|
DAHDI_LINUX_MODULE_MAKE_OPTS = \
|
|
|
|
|
KSRC=$(LINUX_DIR) \
|
|
|
|
|
KVERS=$(LINUX_VERSION_PROBED) \
|
|
|
|
|
DAHDI_BUILD_ALL=m \
|
|
|
|
|
DAHDI_INCLUDE=$(@D)/include \
|
|
|
|
|
INSTALL_MOD_DIR=dahdi
|
|
|
|
|
|
|
|
|
|
define DAHDI_LINUX_EXTRACT_FW
|
|
|
|
|
$(foreach f,$(DAHDI_LINUX_FW_FILES),\
|
2018-05-11 18:29:57 +02:00
|
|
|
cp $(DAHDI_LINUX_DL_DIR)/$(f) $(@D)/drivers/dahdi/firmware/$(f)$(sep))
|
package/dahdi-linux: new package
dahdi-linux provides kernel modules to drive a variety of telephony
cards, ranging from low-end one-channel to higher-end multi-channel
cards. It also provides headers for userland to talk to those cards.
With a bit of love, dahdi-linux can use our kernel-module
infrastructure. Wee! :-)
Still, there are a few specificities about dahdi-linux.
First, it needs to install a few binary firmware blobs, which it wants
to download at install time. Since we do want to be able to do
completely off-line builds, we need to downlaod them manually. So we
have the full list of firmware blobs (even if some can only be used on
an i386/x86_64 target, we still uconditionally download them), for which
we have locally-computed sha256 (no hash provided by upstream for the
blobs).
Second, the install procedure for the firmware blobs needs to have
access to the Linux kernel .config file, so it can decide whether to
install the blobs or not. We can force not to install them, but we can't
force to install them... :-/ And anyway, we'd have to do the same check
as is already done by dahdi-linux, so no need to duplicate that.
Finally, the licensing is relatively weird. Although it is obvious and
straightforward for the most part of dahdi-linux, consisting of mostly
GPLv2 and a few LGPLv2.1, there is one gotcha.
Of the firmware blobs, one is provided as a .o file, with no licensing
information whatsoever, without any source available from upstream, but
is directly linked to a GPLv2 file.
This is very concerning, but there is not much we can do about it,
except delegate to the legal reviewer whether that is acceptable or not.
AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or
later, as it uses internals that have been removed in linux-4.0. There
has been no update upstream dahdi-linux to fix that. There's not much we
can do, except warn the user in the help text.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: use SPDX license names and add hashes for license files]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-09 23:39:26 +02:00
|
|
|
endef
|
|
|
|
|
DAHDI_LINUX_POST_EXTRACT_HOOKS += DAHDI_LINUX_EXTRACT_FW
|
|
|
|
|
|
2021-11-05 00:12:08 +01:00
|
|
|
define DAHDI_LINUX_LINUX_CONFIG_FIXUPS
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CRC_CCITT)
|
|
|
|
|
endef
|
|
|
|
|
|
package/dahdi-linux: new package
dahdi-linux provides kernel modules to drive a variety of telephony
cards, ranging from low-end one-channel to higher-end multi-channel
cards. It also provides headers for userland to talk to those cards.
With a bit of love, dahdi-linux can use our kernel-module
infrastructure. Wee! :-)
Still, there are a few specificities about dahdi-linux.
First, it needs to install a few binary firmware blobs, which it wants
to download at install time. Since we do want to be able to do
completely off-line builds, we need to downlaod them manually. So we
have the full list of firmware blobs (even if some can only be used on
an i386/x86_64 target, we still uconditionally download them), for which
we have locally-computed sha256 (no hash provided by upstream for the
blobs).
Second, the install procedure for the firmware blobs needs to have
access to the Linux kernel .config file, so it can decide whether to
install the blobs or not. We can force not to install them, but we can't
force to install them... :-/ And anyway, we'd have to do the same check
as is already done by dahdi-linux, so no need to duplicate that.
Finally, the licensing is relatively weird. Although it is obvious and
straightforward for the most part of dahdi-linux, consisting of mostly
GPLv2 and a few LGPLv2.1, there is one gotcha.
Of the firmware blobs, one is provided as a .o file, with no licensing
information whatsoever, without any source available from upstream, but
is directly linked to a GPLv2 file.
This is very concerning, but there is not much we can do about it,
except delegate to the legal reviewer whether that is acceptable or not.
AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or
later, as it uses internals that have been removed in linux-4.0. There
has been no update upstream dahdi-linux to fix that. There's not much we
can do, except warn the user in the help text.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: use SPDX license names and add hashes for license files]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-09 23:39:26 +02:00
|
|
|
# Need to pass the same options as for building the modules, because
|
|
|
|
|
# it wants to scan Linux' .config file to check whether some options
|
|
|
|
|
# are set or not (like CONFIG_FW_LOADER).
|
|
|
|
|
define DAHDI_LINUX_CONFIGURE_CMDS
|
|
|
|
|
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \
|
|
|
|
|
$(DAHDI_LINUX_MODULE_MAKE_OPTS) \
|
|
|
|
|
prereq
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
define DAHDI_LINUX_INSTALL_STAGING_CMDS
|
|
|
|
|
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \
|
|
|
|
|
$(DAHDI_LINUX_MODULE_MAKE_OPTS) \
|
|
|
|
|
DESTDIR=$(STAGING_DIR) \
|
|
|
|
|
install-include
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
define DAHDI_LINUX_INSTALL_TARGET_CMDS
|
|
|
|
|
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \
|
|
|
|
|
$(DAHDI_LINUX_MODULE_MAKE_OPTS) \
|
|
|
|
|
DESTDIR=$(TARGET_DIR) \
|
|
|
|
|
install-firmware \
|
|
|
|
|
install-xpp-firm
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
$(eval $(kernel-module))
|
|
|
|
|
$(eval $(generic-package))
|
