kumquat-buildroot/linux/Config.ext.in
Thomas Petazzoni e7035d4eb9 rtai: remove option BR2_LINUX_KERNEL_EXT_RTAI_PATCH
This commit removes BR2_LINUX_KERNEL_EXT_RTAI_PATCH because this
option never worked. It was added in commit
8797a9cd1f, which added package/rtai/
and RTAI as a Linux extension.

The option prompt says "Path for RTAI patch file", so let's say you
specify /home/foo/bar/myrtai.patch as the value for
BR2_LINUX_KERNEL_EXT_RTAI_PATCH.

Then the code does:

RTAI_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_RTAI_PATCH))

and we have a package called 'rtai', so the normal logic of
<pkg>_PATCH applies. Since the <pkg>_PATCH value does not contain
ftp://, http:// or https://, the package infrastructure will try to
download $(RTAI_SITE)/$(RTAI_PATCH), i.e:

   https://www.rtai.org/userfiles/downloads/RTAI/home/foo/bar/myrtai.patch

Pretty clear that it has no chance of working.

Now, let's assume an URL is used as the value of
BR2_LINUX_KERNEL_EXT_RTAI_PATCH, such as
http://foo.com/bar/myrtai.patch. In this case, it will be properly
downloaded by the package infrastructure. But then, the following code
kicks in:

define RTAI_PREPARE_KERNEL
       $(APPLY_PATCHES)                        \
               $(LINUX_DIR)                    \
               $(dir $(RTAI_PATCH))            \
               $(notdir $(RTAI_PATCH))
endef

The value of $(dir $(RTAI_PATCH)) will be http://foo.com/bar/. How
can $(APPLY_PATCHES) make use of such a stupid patch location?

[Thomas: add Config.in.legacy handling, as suggested by Arnout, even
if we believe that no-one could have ever used this option.]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-04-22 22:12:15 +02:00

66 lines
1.9 KiB
Plaintext

menu "Linux Kernel Extensions"
# Xenomai
config BR2_LINUX_KERNEL_EXT_XENOMAI
bool "Adeos/Xenomai Real-time patch"
depends on BR2_TOOLCHAIN_HAS_THREADS
depends on BR2_i386 || BR2_x86_64 || BR2_arm || \
BR2_bfin || BR2_powerpc || BR2_sh4
select BR2_PACKAGE_XENOMAI
help
Xenomai is split in two parts: a kernel part and a userspace
part. Enabling this option automatically selects the Xenomai
package and helps in patching the Linux kernel built by
Buildroot with the Xenomai kernel part (ie Adeos/Ipipe).
You can find the currently supported kernel versions by
looking at the available patches in the Xenomai sources
tree: ksrc/arch/$(ARCH)/patches
However, it is recommended to use the latest version of the
Adeos/Ipipe patch available at
http://download.gna.org/adeos/patches
Xenomai is know to support Blackfin, SH4, x86, ARM, NIOS2
and PowerPC architectures.
comment "xenomai needs a toolchain w/ threads"
depends on BR2_i386 || BR2_x86_64 || BR2_arm || \
BR2_bfin || BR2_powerpc || BR2_sh4
depends on !BR2_TOOLCHAIN_HAS_THREADS
config BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH
depends on BR2_LINUX_KERNEL_EXT_XENOMAI
string "Path for Adeos patch file"
help
Optionally, explicitly specify the Adeos patch to use.
Download it at http://download.gna.org/adeos/patches
and verify that your kernel version in buildroot matches.
# RTAI
config BR2_LINUX_KERNEL_EXT_RTAI
bool "RTAI Real-time patch"
select BR2_PACKAGE_RTAI
help
RTAI Kernel part.
# fbtft
config BR2_LINUX_KERNEL_EXT_FBTFT
bool "FB TFT drivers"
select BR2_PACKAGE_FBTFT
help
Linux Framebuffer drivers for small TFT LCD display modules,
e.g. Adafruit PiTFT displays for Raspberry Pi.
To enable fbtft, e.g. for Adafruit 2.8 PiTFT, enable the
following kernel configurations:
- CONFIG_SPI
- CONFIG_GPIOLIB
- CONFIG_FB
- CONFIG_FB_TFT
- CONFIG_FB_TFT_ILI9341
https://github.com/notro/fbtft
endmenu