How to support the 7" touch display from raspberrypi org on a custom kernel? #1147
Comments
|
Add: and make sure you ship rpi-ft5406-overlay.dtb The touchscreen overlay is enabled automatically when the LCD is detected by firmware. |
|
Would I be able to add this touchscreen driver to the Kernel used with NOOBS (3.18.7-rescue-v7)? EDIT: On further investigation I would need to add: |
|
Thanks for the answers. I had all the right kernel setting still applied, but was missing to enable the Device Tree support on the kernel with the script |
|
Hmmm. I'd forgotten DT support - I don't think that is in v3.18. Is this a showstopper, or is there a workaround? |
|
3.18 is the first released Pi kernel that supported DT, so that in itself shouldn't be a problem. |
|
OK down the rabbit hole then! :) Is this the correct way? |
|
The mach-bcm2708 support defines CONFIG_BCM2708_DT, which when set enables the options required for a DT-enabled kernel. It's a shorthand for USE_OF + ARCH_REQUIRE_GPIOLIB + PINCTRL + PINCTRL_BCM2835, but it also triggers the building of the DTB files. Does buildroot not yet you use a defconfig such as bcmrpi_defconfig (Pi 1) or bcm2709_defconfig (Pi 2) instead? The other steps look correct. |
|
Thanks, I think that was the missing piece I needed. I'll give it a go. Yes, the defconfig files are present, but NOOBS uses 2 preconfigured 'kernelconfig_recovery.armv6/7' files instead. Contrary to what I read on github in |
|
The device-tree guide isn't saying that the NOOBS recovery image is DT-enabled, but rather that shipping NOOBS images with Raspbian pre-installed now include a DT-capable Raspbian. Sorry for any confusion. |
|
So, I built a clean version of NOOBS. I then set the BCM2709 Device Tree Support (I am building for Pi2) which also set Flattened Device Tree Support for me. I recompiled the kernel. of_dma_request_slave_channel: dma-names property of node '/soc/uart@7e201000' missing or empty The recovery program started, and then crashed. What did I miss? I added device_tree=bcm2709-rpi-2-b.dtb to config.txt with no effect. |
|
I've seen the first error before - we can ignore that for now. The other two don't make much sense to me - they appear to come from sdhci_pltfm_init, but the bcm2835-mmc driver doesn't call into that function (as far as I can tell). If you are up for a bit of digging, can you edit drivers/mmc/host/sdhci-pltfm.c, locate sdchi_pltfm_init and insert This should cause a stack backtrace to appear in the kernel log during booting, so we can work out what is calling into that function. |
|
I'm willing to do any digging as I am using NOOBS as a way to learn more about linux development. |
|
I get my logging output from the serial port on pins 6,8&10 (GND,TXD,RXD). Put "console=ttyAMA0,115200 loglevel=8" in the NOOBS cmdline.txt (the one in the first VFAT partition). |
|
Hmm. OK. that will take me a while to setup (I have to convert my USB TTY cable from 5V to 3.3V). Is there an alternative in the meantime? Don't worry if not. I'll report back when I have some logs. |
|
I modified my recovery.cmdline to say: If can get to a login console (Ctrl-Alt-F2 to switch to a different window), log in using "root" and "raspberry", then "dmesg" will get you the message log. |
|
Doh! I was looking for something more complicated than that! |
|
Interesting. That's not the warning I was expecting, which is likely to be about 2 seconds later in the log. This warning looks to be because the dtb you have copied from the recent Raspbian Jessie image isn't compatible with the kernel. This shouldn't be the case with Device Tree, which should be an OS-neutral description of the hardware, but at the moment the two are evolving hand-in-hand and this kind of problem is likely if you mix and match. It's better to use the |
|
ok I'll give it a try. Kernel compression mode > 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) (NEW) 3. LZMA (KERNEL_LZMA) 4. XZ (KERNEL_XZ) 5. LZO (KERNEL_LZO) 6. LZ4 (KERNEL_LZ4) choice[1-6?]: Edit: I carried on, and had the feeling this isn't what I am supposed to be doing.....Too many x86 references. Edit2: I deleted the dtb and overlays copied from Jessie and instead used the ones I found in rpi-firmware/boot. The error messages seem to have gone away. So now on to step 4..... |
|
Always include "ARCH=arm" on kernel make lines, or you will default to x86 config. E.g. |
|
Thanks. |
|
Step 4: backporting from linux-b630db9dcb5c73367050a672823047b0466b16b9 I couldn't find rpi-ft5406-overlay.dtb so, HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/bin2c HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release UPD include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CC kernel/bounds.s gcc: error: unrecognized argument in option ‘-mabi=aapcs-linux’ gcc: note: valid arguments to ‘-mabi=’ are: ms sysv gcc: error: unrecognized command line option ‘-mlittle-endian’ gcc: error: unrecognized command line option ‘-mapcs’ gcc: error: unrecognized command line option ‘-mno-sched-prolog’ gcc: error: unrecognized command line option ‘-mno-thumb-interwork’ gcc: error: unrecognized command line option ‘-mfpu=vfp’ make[1]: *** [kernel/bounds.s] Error 1 make: *** [prepare0] Error 2 So, I copied the dtb from Jessie again (probably wrong!) and put it in /overlays of SD card. |
|
I guessed that the above errors were because I was using the wrong gcc (x86 on Ubuntu) so I tried: |
|
Nope. Still no touchdriver. |
|
Copy the vcdbg from a normal image - you could put it in the vfat partition to make things easier - and then use it to look for messages from the firmware. |
|
Yes. Thought of that overnight so tried copying it to both vfat and tmp and all I get is |
|
It works ok in Jessie where I can see the line: |
|
That "not found" error can also be caused by missing shared-library dependencies. Running it on Jessie under strace shows it loading the following .so's: I would expect most of those to be available in NOOBS, but perhaps not libvcos.so and libdebug_sym.so. Make sure that all are somewhere in the library path. |
|
Thanks. I copied them all over from Jessie into the vfat partition in preparation, so I'll try it out tonight & report back. |
|
I don't know how, but I finally got vcdbg to run after putting ld-linux-armhf.so in /lib. Woo-Hoo!, But by this time I was debugging on my lapdock instead of the touchscreen for better visibility. I was even able to run strace on it. Nevertheless, config.txt had dtoverlay=rpi-ft5406 so I hoped it was trying to load the overlay. In the log it mentions "Failed to resolve overlay 'rpi-ft5406;" although it exists as /overlays/rpi-ft5406-overlay.dtb as per Jessie. Is this the right location for v3.18, or should it be in the root? I'm going to have to reboot using the touchscreen and remember how I got vcdbg working again in order to get any more logs, so that will have to wait til tomorrow. I saved the strace and vcdbg output if it is of any use without the touchscreen - but I'll try and do it again with the touchscreen attached tomorrow. |
|
From memory a failure to resolve isn't a failure to load. The overlays live in the "overlays" directory of the VFAT directory, so one level down from bootcode.bin. It is more likely that there is a symbol absent from the .dtb file that the overlay is referring to. Seeing the vcdbg output would be helpful, but set dtdebug=1 for the next run. |
|
Nice work! I hope you realise that I'll be expecting a patch set at the end of this. |
|
@procount great work! |
|
Thanks. I don't understand the scaling issue because the screen res already seems to be 800x480 that the driver expects (I don't think it can be anything different). Maybe it is something to do with the QT screen driver in the Noobs recovery program? |
|
Official Touchscreen now working properly in NOOBS! Woo Hoo! |
|
@pelwell, @ghollingworth - Before I move onto the device tree version of the rpi-ft5406 touchscreen driver, I want to make sure I have integrated it properly as a platform driver in NOOBS. So are there any specific resources (or dma_mask) I should be setting for it in static struct resource rpi_ft5406_resources[] ?It seems to work without, but not sure if that is correct. |
|
No, there shouldn't need to be anything in there since it doesn't talk directly to hardware - instead it uses the firmware/mailbox driver to communicate with the firmware that actually talks to the device via I2C. This is expressed in Device Tree like this: i.e. an identifier for the device driver and a reference to the firmware/mailbox device. |
|
Thanks for confirming. I wasn't sure exactly which resources I found in ft5406_probe() needed to be registered, and as you say, the DTS file was devoid of such things so I just assumed there was nothing relevant. |
|
To get the touchscreen working with NOOBs, I need to know the name of the device it enumerates as (and these things seem to move around according to what is attached). And because I need to specify this, I also need to specify the device name of any mouse attached. |
|
use a udev rule to make a symlink that you can use in the config? Somthing like this does it for the event file for similar use in tslib/SDL |
|
@pssc Thanks for the suggestion, but NOOBs doesn't use UDEV. And the question remains as to what the equivalent UDEV rule for a mouse would be. I decided to tackle it another way and add all mouseX handlers that are NOT the touchscreen driver as this will avoid the variety of possible names. In fact I think I can just use /dev/input/mice. |
|
Could you explain what should be enabled to support the 7" display? |
|
The latest kernel used for Noobs now contans device tree support for the 7" display and touchscreen so you could just use that now. |
|
Thank you I will try it. Which is the right device tree blob file I have to use? Currently I use a custom image so I would like to add the display support to my config files. |
|
Including: and making sure the |
|
If I understand right I tried the latest OS for the raspberry pi and it works successfully. No I will try my custom kernel version but I saw that the Kernel 3.18 has no config for the FT5406. |
|
The display is controlled by the GPU so you just need the latest start.elf bootcode.bin files etc. And the touchscreen display will work without any kernel mods. |
|
OK know I understand it. Thank you for your patience. I think a update to the new kernel 4.x is the best choice. |
|
@mllapps If you deperately need to port the ft5406 driver into v3.18, I could possibly provide a patch for what I did to the 3.18 kernel in NOOBS, but It looks like Device Tree is the way to go. Plus, by upgrading to a later kernel you should get better SD card stability, from what I understand. |
|
@procount Thank you for your offer. If you have a patch for the kernel 3.19 I would like to port it to 3.18.x. If I have finished I will post it here. |
|
Where can I begin with non device tree support, or was did you have a PR? |
|
Sorry what do you mean with PR? The drivers are prepared for the device tree so I think you have to copy the files from the latest version and back port it. |
|
@cmon-meow - If I understand you correctly, you want to add the touchscreen driver to a non-DT enabled kernel, like I did? |
|
Would be greatly appreciated, you are correct. |
|
OK, so I found a folder with what looks like all the mods I made to the NOOBS linux kernel with commit id b630db9 to enable the touchscreen. There is a file included called I also found a patch file that looks like it does the same thing, but I'm not sure what version it applies to. (It was my first ever attempt at creating a patch file and I have not used it, as far as I remember). 0001-Add-RPI-Touchscreen.patch.gz Please let me know if either (or both) of these work for you (otherwise I'll have to do some more digging). |
|
Thank you both were very useful, though my card corrupted under kernel 4.1.18 "can't remember why I had it" while compiling my kernel "lockup on successful compile", so I must determine how much data I can recover from backups, and no better time to update. If I cross this road again I will try to leave a working archive for anyone else wanting to head this direction. |
|
@DieterReuter has your issue been resolved? If so, please close this issue. Thanks. |
|
Yes, it's resolved. |
We do use a custom built kernel 4.1.x for the Raspberry Pi and would like to support the new 7" touch display. Until now I do have the pure display supported but without the touch feature.
I just need a pointer what kernel config is necessary, and/or what DTS overlay file we have to include and maybe how to activate it.
Thanks for any help or pointers!
The text was updated successfully, but these errors were encountered: