PiTFT and rpi-update

[spencersm]

Having run rpi-update, and updated to kernel 3.10.33+ (from 3.10.32+), I can no longer load the drivers.
If I re-run dpkg, it will overwrite my current boot and module files.

Does this mean I will have to build the drivers myself if I want to use the PiTFT with newer versions of the kernel?

Steve

[adafruit_support_mike]

I'm not even sure compiling from source would work. At its core the Linux kernel is still monolithic, so the official solution is to compile a version of the kernel that contains all the pieces you want.

The various package managers try to make that less painful, but I don't know of any package manager that's designed to stay in sync with some or all of the others.

Your best bet would be to use dpkg for all your kernel modules. That will automate the dependency checking and recompilation as much as possible.

[spencersm]

Are you saying that the fbtft and stmpe-ts drivers are not dynamically loaded?
Since the documentation for assembly/installation refers specifically to using modprobe and rmmod, I assumed that building compatible (3.10.33+) versions of the drivers and kernel would be what I needed to do.

Since I have a couple of PiTFTs, I have reverted to 3.10.32+ for the time being, until I set up a cross-compilation environment on something a little bigger than a Pi and I can build the kernel/drivers from the RPi git repo.

Are there plans to provide updated versions of the packages? I can't imagine that having to stick to a particular release of the kernel/firmware makes sense.

[notro]

I have a 3.10.33+ kernel with the FBTFT drivers built into the kernel proper. See https://github.com/notro/fbtft/issues/82
It's hasn't seen a lot of testing with the PiTFT, but if you test it, let me know how it goes.

I can't imagine that having to stick to a particular release of the kernel/firmware makes sense.

It makes sense in a support perspective.
I thought about having a continously built kernel for my own project, but decided against it.
I will rather make a new build in case a major problem is solved in the kernel, or if the FBTFT drivers are updated.

3.10 is a Long Term Release, and it is updated with a new minor version every other week or so. Not many distros keep up with all those version updates.

[spencersm]

That sounds great. I'll let you know how I get on.
There also looks to be enough information for me to build my own image later on.

Many thanks, and like everyone else, I love what you've done to make cheaper displays possible for the Pi.

Steve

[tz1]

I've not been able to get the PiTFT working from your tree. It might be some configuration differences or parameters to fbtft_device which I don't have set right, but the PiTFT tree differs.

To see what I'm doing, see https://github.com/tz1/pikernomatic - one of the scripts has a variant for fbtft v.s. adafruit-rpi-fbtft.

I can't get the touchscreen or reset button working at all. I can load the touchscreen module, but either it loads silently and doesn't work, or complains about not being able to allocate the interrupt properly

Note the patches in the tutorial mostly fail on the recent (2014) kernel trees, so aren't very helpful.

[carlrj]

Adafruit updated their PiTFT setup tutorial recently with pointers to an Adafruit-built 3.10.32+ kernel with support for all their devices - I dropped it into my existing Pi and it's working with the PiTFT without a hitch (presumably it incorporates notro's latest mods - I'm looking forward to trying it with his splash screen mod, which required a newer kernel than the previous Adafruit-supplied one).

[notro]

To see what I'm doing, see https://github.com/tz1/pikernomatic - one of the scripts has a variant for fbtft v.s. adafruit-rpi-fbtft.

This won't work: #define ARCH_NR_GPIOS 54+100 // number of gpio lines
arch/arm/mach-bcm2708/bcm2708_gpio.c will use all of them: ucb->gc.ngpio = ARCH_NR_GPIOS;
See here: https://github.com/notro/rpi-build/blob ... hips.patch

Adafruit has patched up fbtft_device to also add a device for stmpe. I have chosen a different approach and made stmpe_device: https://github.com/notro/fbtft_tools/tr ... mpe_device

If you make a dedicated kernel for the PiTFT, it is also possible to add the stmpe spi_board_info directly to arch/arm/mach-bcm2708/bcm2708.c. The same goes for the display as well.
This way neither fbtft_device nor stpme_device is needed.
Note: You loose the ability to change speed, rotation etc. at runtime.