Reply To: [HOW TO]Driver Install for minimal install (Kali) on B Rev 2

[sheaiden]

Performed on raspberry pi itself, running kali. This takes a VERY long time. I think I have been averaging about 14 hours for the kernel and module compilation alone. This can be vastly sped up if you were to modify things in the build script from Kali to incorporate the appropriate drivers into the cross-compiling and image generation. I just haven’t gotten around to installing my second hard drive with Kali yet, so I had no source to cross compile from.

First I installed all prereq packages. Please note, this list was generated as a compilation of all the “prereq” lists I’d found as I progressed along. As such, there may be some that aren’t needed (qemu and mkimage, for example, are only needed if you’re generating a full image for the raspberry pi as is recommended by the Kali build scripts). Some are usually already installed, but aren’t in the Kali build (g++ and pkg-config, for example).

apt-get install -y git-core gnupg flex bison gperf libesd0-dev build-essential zip curl zlib1g-dev libncurses5-dev x11-xserver-utils libts-bin libtool libx11-dev parted kpartx debootstrap pixz qemu-user-static abootimg cgpt vboot-kernel-utils vboot-utils uboot-mkimage bc lzma lzop automake autoconf m4 dosfstools pixz rsync schedtool git dosfstools e2fsprogs device-tree-compiler fbi pkg-config g++ screen xinput libxi-dev x11proto-input-dev
mkdir ~/arm-stuff
cd ~/arm-stuff
git clone https://github.com/offensive-security/gcc-arm-linux-gnueabihf-4.7
export PATH=${PATH}:/root/arm-stuff/gcc-arm-linux-gnueabihf-4.7/bin
git clone https://github.com/offensive-security/kali-arm-build-scripts
cd ~/arm-stuff/kali-arm-build-scripts
mkdir testrpi

–from here I followed the steps in the rpi.sh script from the build repository, kernel section:

git clone --depth 1 https://github.com/raspberrypi/linux ./kernel
git clone --depth 1 https://github.com/raspberrypi/tools ./tools
mkdir -p patches
wget https://raw.github.com/offensive-security/kali-arm-build-scripts/master/patches/kali-wifi-injection-3.12.patch -O ./patches/mac80211.patch
cd kernel
patch -p1 --no-backup-if-mismatch < ../patches/mac80211.patch
cp ~/arm-stuff/kali-arm-build-scripts/kernel-configs/rpi-3.12.config .config

–Here I had to interject the section from the fbtft to get the driver into the source.

cd drivers/video
git clone https://github.com/notro/fbtft.git

–Add to drivers/video/Kconfig: source “drivers/video/fbtft/Kconfig”
–Add to drivers/video/Makefile: obj-y += fbtft/

cd ../../
make menuconfig

–Enable the modules for “device drivers/Graphics Support/Support for small TFT LCD display modules” devices (didn’t know which one specifically so chose all)
–Enable the touch screen module for “device drivers/input device support/touchscreens/ads7846
–Ensure spi_bcm2708 is enabled
–Please note, you may have to search for fbtft, ads7846, bcm2708 to make sure you enable everything.
–Alternatively, I’ve uploaded my .config file if you’d like to just trust it. you still have to add the lines mentioned above to the Kconfig and Makefile for fbtft

make
make modules
make modules_install
mount /dev/mmcblk0p1 /boot
mv /boot/kernel.img /boot/kernel.orig.img
cp arch/arm/boot/Image /boot/kernel.img

–The ads7846_device module is in a separate repository called fbtft_tools, so you have to do that one separately.

cd ~/arm-stuff
git clone https://github.com/notro/fbtft_tools.git
cd fbtft_tools/ads7846_device
make
make install

–At this point, I add the /etc/modules information as listed in Step 5 of https://ozzmaker.com/piscreen-driver-install-instructions-2/
–Not that Step 6 still won’t work, as you’ve not loaded the new kernel, but on your reboot you should see the screen light up.
–Reboot and you’re in the new kernel. If you want to test it, you can do the test in Step 6 of the driver install page.

–at this point, I followed the instructions at and https://ozzmaker.com/enable-console-on-piscreen/ with the only modification of having to mount the boot partition first:
mount /dev/mmcblk0p1 /boot

–The instructions on https://ozzmaker.com/enable-x-windows-on-piscreen/ have to be modified.
–Kali does not come with LXDE installed, it has xfce. It also does not thave fbturbo installed. As such, Step 1 is not necessary.
–Step 2 is necessary, though if you’ve been following along above, you’ve already gotten it done. If not, note that it is missing a package that it took me a bit to track down; the autogen.sh script needs pkg-config, and g++ installed (thought you’ve already gotten this if you compiled the kernel).
–Follow Step 3 as written
–Step 4 needs some modification. XFCE does not use the autostart script in the same way. the best way I could find to get the script to run for all users upon starting X for XFCE was to create a .desktop file in the /etc/xdg/autostart directory. I have attached it, but here’s what I put in the file /etc/xdg/autostart/piscreen-config.desktop:

[Desktop Entry]
Version=1.0
Name=piscreen Config
Exec=/etc/X11/Xsession.d/xinput_calibrator_pointercal.sh
Terminal=false
Type=Application
StartupNotify=false
OnlyShowIn=XFCE;

In order to start X windows automatically on boot, you need to either create a user and grant them both sudo access and run the “dpkg-reconfigure x11-common” command to enable X for all users, or modify the login to root. I know it’s against most admin’s best practices to log in as root, but since this is a Kali machine, many use it straight as root anyways. It’s your call, but by default on Kali, no one but root is able to startx. you’ll have to reconfigure if you want to change that.

Assuming you’re going to change the login to root, the line in inittab changes to:
1:2345:respawn:/bin/login -f root tty1 /dev/tty1 2>&1

and the line in rc.local changes to:
su -l root -c "env FRAMEBUFFER=/dev/fb1 startx &"

I have not changed the screen blanking in the autostart file; I have not tracked down that particular functionality in xfce, since I don’t mind it right now. perhaps when I start using it in my car I might, but we’ll see.

–On a related note, I do like to have the raspi-config script, so I install it

cd ~/arm-stuff 
wget http://archive.raspberrypi.org/debian/pool/main/r/raspi-config/raspi-config_20140902-1_all.deb
wget http://http.us.debian.org/debian/pool/main/l/lua5.1/lua5.1_5.1.5-7.1_armel.deb
wget http://http.us.debian.org/debian/pool/main/t/triggerhappy/triggerhappy_0.3.4-2_armel.deb
dpkg -i triggerhappy_0.3.4-2_armel.deb
dpkg -i lua5.1_5.1.5-7.1_armel.deb
dpkg -i raspi-config_20140902-1_all.deb

I have uploaded the scripts I used the last time I flashed a card and took it to a completed state. they take you through getting the device working, but because of the heavy text editing of very important files to get the autostart working, I left it off there. Essentially, when you reboot the last time from my scripts, you would have a fully loaded screen, but you would still have to pick up the steps listed above from enabling the console on the screen.

I apologize if this is a little disjointed, I’ve been working on this in spurts as free time permits, and as such have lost a few ssh sessions worth of scrollback, which means I have to reconstruct stuff from my history…