You need to use make ARCH=arm menuconfig
to set the option. This can probably be added as a module, meaning you won't necessarily have to rebuild the kernel if you've already done it and it works otherwise.
Before you do this read the part at the bottom about defconfig
.
You can search for options by name in menuconfig by pressing /. If you then type "EGALAX" you should see a description of two matching entries, one is USB and one is not. The former looks like this:
Symbol: TOUCHSCREEN_USB_EGALAX [=n] │
Type : boolean
Prompt: eGalax, eTurboTouch CT-410/510/700 device support
Location:
-> Device Drivers
-> Input device support
-> Generic input layer (needed for keyboard, mouse, ...) (INPUT [=y])
(2) -> Touchscreens (INPUT_TOUCHSCREEN [=n])
Defined at drivers/input/touchscreen/Kconfig:714
Depends on: !UML && INPUT [=y] && INPUT_TOUCHSCREEN [=n] && TOUCHSCREEN_USB_COMPOSITE [=n]
Beware to do this yourself and not use this example as it may be slightly different. The "Location:" field shows how to find this option in the menu hierarchy (so you start with "Device Drivers" then choose the "Input device support" submenu, etc.). The actual name of the option in this subdirectory location is in the "Prompt:" field ("eGalax, eTurboTouch CT-410/510/700 device"). However, options will only appear if you meet the requirements in the "Depends on:" line. Notice in the example, I do not, so I will not be able to select this until I first find and select INPUT_TOUCHSCREEN
and TOUCHSCREEN_USB_COMPOSITE
.
If you want to avoid rebuilding the kernel, try and make all the new things you have to select modular by pressing M instead of Y when you select it. If the option is in [ ]
instead of < >
you can't, however, check the Help
and see if it says something like, "This option does not add any kernel code", then it doesn't matter -- you are just enabling a submenu. If all the options you select that add code are M
, then you don't have to rebuild the kernel and can just use make [your ARCH & CROSS_COMPILE settings] modules_install
. Since you are cross compiling, you'll presumably then have to copy the modules over as per whatever directions for that you've been following already.
You might actually want to build this support in (i.e., not make it a module), however. This could make it possible to get boot messages sent there -- I'm not sure. But if the driver is a module, the kernel will first have to mount the root filesystem to use it.
Remember to save the configuration before you exit. This will be in .config
.
i am confused as it says defconfig ,so would making changes to menuconfig should still load the defconfig or
What this does:
make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- bcmrpi_defconfig
Is create the default .config
for the pi. You need to do the before you run menuconfig
. Neither of these actually builds a kernel. To do that you run just make [your ARCH & CROSS_COMPILE settings]
.
If you want to use the configuration for a particular existing kernel, you'll have to copy /proc/config.gz
1 from the pi while it is runnning the kernel you want to use or modify. Take that copy and gunzip -c config.gz > .config
. Put that .config
in the top level of the kernel source where you run menuconfig from before you do it. You'll need to move/backup/delete the exiting .config
.
If you want to know some other things about compiling a kernel for the pi, see here. However, if you start with a .config
from one of the two sources above -- either by running bcmrpi_defconfig
or taking it from /proc/config.gz
, then you don't need to worry about this.
1. If you can't find it, try sudo modprobe configs
and look again.