Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #3820

    Well, I haven’t performed this since I posted the solution that worked for me (yes, firezpi, I did manage to figure it out, as I stated in my posts; not sure where to go with your response…), but the message you pointed out look almost like the kernel was updated beyond what it was when I created my configs, thus rendering my configs obsolete. You’re installing this on a Kali install? I don’t have a lot of spare time, but I can try to look into it. if nothing else, though, you can use my scripts and the description I posted above to figure out what the script is doing in concept, and just generate new configs. honestly, looks like that’s what it’s trying to do there; the part where it says restart config, and then starts going through the interactive kernel configuration is what suggests that.

    I would just compile and install your own kernel, making sure you include the drivers you need, and continue from the “git clone” line of that script.

    Please note, though, that “compile and install your own kernel” is by no means something that a lot of people do, nor is it something that you can just attempt if you’re looking for a plug and play experience. it’s slow, complex, and it’s easy to end up with a kernel that doesn’t work because something that should have been built in is a module or the other way around. I don’t lightly suggest you build it yourself, nor do I assume you have or don’t have the knowledge to do so, I just don’t know what other option you have other than waiting to see if I can figure out a working config.

    Also, this is assuming it’s breaking where I think it’s breaking. it would help if you could upload the entire output, so I can see if it’s telling you what it’s doing…although I know my scripts (being hastily bashed together) don’t provide much feedback at all.


    I attempted to upload my .config, piscreen-config.desktop, and the config scripts, but it denied me for security reasons. I am attempting to upload them as a tar, but if that doesn’t work, let me know if they’d be useful and I can send them to you.

    Looks like this worked. Not sure how one marks an issue as resolved, but I’ve gotten this working, now I just have to track down the on-screen keyboard and get it installed. should be fun. the rest from here is just tinkering.



    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
    export PATH=${PATH}:/root/arm-stuff/gcc-arm-linux-gnueabihf-4.7/bin
    git clone
    cd ~/arm-stuff/kali-arm-build-scripts
    mkdir testrpi

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

    git clone --depth 1 ./kernel
    git clone --depth 1 ./tools
    mkdir -p patches
    wget -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

    –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 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
    cd fbtft_tools/ads7846_device
    make install

    –At this point, I add the /etc/modules information as listed in Step 5 of
    –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 with the only modification of having to mount the boot partition first:
    mount /dev/mmcblk0p1 /boot

    –The instructions on 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 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]
    Name=piscreen Config

    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 
    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…


    Just as an update, I’ve found the process that Kali uses to generate raspberry pi images, and am following a manual format of that to preserve their kernel patches and generate a new set of modules for the kernel I’m using. It’s located at:

    I’m executing the build on the pi itself, so it’s taking a while, but the basic format I’m using is:
    –get the sources they download in the image builder
    –get the fbtft sources downloaded, as mentioned in notro’s git site
    –apply the patches that the Kali build scripts apply
    –make menuconfig to enable the drivers
    –make the kernel

    I am not yet certain where/how the boot process on the pi works, especially in Kali, but I’ll address that when I get to it. I will update with a full listing of the exact commands I did to update once I’ve proven the concept.


    ok, it appears it should be simple, assuming I can get the kernel sources downloaded. Sounds promising. I’ll update with my process (which will likely be as simple as following the readme on nostro’s fbtft site) and if I get it working.


    Thanks Mark! I’ll try figuring it out.


    Sorry, I did try one more thing that I should mention: after I figured out how to install the rpi-update script, I did try following the steps outlined on the driver install page. It did say it installed the new firmware and kernel, but when I added the flexfb and other lines to the module file, upon reboot it simply said they were unknown. That’s what makes me think I need to get a module installed, but doing a search in aptitude for anything that has flexfb, fbtft, or ads7846 in the package name or description didn’t turn up anything. Google searches seem to imply that I may be the only person trying to attach a gpio-attached touchscreen monitor to kali…

    or perhaps my google-fu is not strong today.

Viewing 7 posts - 1 through 7 (of 7 total)

Blip, blop, bloop…