New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to support the 7" touch display from raspberrypi org on a custom kernel? #1147

Closed
DieterReuter opened this Issue Sep 28, 2015 · 82 comments

Comments

Projects
None yet
8 participants
@DieterReuter

DieterReuter commented Sep 28, 2015

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!

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Sep 28, 2015

Collaborator

Add:

CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_RPI_FT5406=m

and make sure you ship rpi-ft5406-overlay.dtb

The touchscreen overlay is enabled automatically when the LCD is detected by firmware.

Collaborator

popcornmix commented Sep 28, 2015

Add:

CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_RPI_FT5406=m

and make sure you ship rpi-ft5406-overlay.dtb

The touchscreen overlay is enabled automatically when the LCD is detected by firmware.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 14, 2015

Would I be able to add this touchscreen driver to the Kernel used with NOOBS (3.18.7-rescue-v7)?
Would it be easy or a complicated backport (I have no experience of backporting)? Which files do I need to port - just: drivers/input/touchscreen/rpi-ft5406.c & Kconfig?
Or is the preferred method to use a later v4.1.x Kernel for NOOBS?

EDIT: On further investigation I would need to add:
include/linux/platform_data/mailbox-bcm2708.h
drivers/input/touchscreen/Makefile
from commit fa2b33b

procount commented Oct 14, 2015

Would I be able to add this touchscreen driver to the Kernel used with NOOBS (3.18.7-rescue-v7)?
Would it be easy or a complicated backport (I have no experience of backporting)? Which files do I need to port - just: drivers/input/touchscreen/rpi-ft5406.c & Kconfig?
Or is the preferred method to use a later v4.1.x Kernel for NOOBS?

EDIT: On further investigation I would need to add:
include/linux/platform_data/mailbox-bcm2708.h
drivers/input/touchscreen/Makefile
from commit fa2b33b

@DieterReuter

This comment has been minimized.

Show comment
Hide comment
@DieterReuter

DieterReuter Oct 14, 2015

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 mkknlimg. Once this step was included in our build script, the 7" touch screen works just fine.

DieterReuter commented Oct 14, 2015

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 mkknlimg. Once this step was included in our build script, the 7" touch screen works just fine.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 14, 2015

Hmmm. I'd forgotten DT support - I don't think that is in v3.18. Is this a showstopper, or is there a workaround?

procount commented Oct 14, 2015

Hmmm. I'd forgotten DT support - I don't think that is in v3.18. Is this a showstopper, or is there a workaround?

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 14, 2015

Contributor

3.18 is the first released Pi kernel that supported DT, so that in itself shouldn't be a problem.

Contributor

pelwell commented Oct 14, 2015

3.18 is the first released Pi kernel that supported DT, so that in itself shouldn't be a problem.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 14, 2015

OK down the rabbit hole then! :) Is this the correct way?
Step 1 - Enable DT support in buildroot kernel with Boot Options/ Flattended DeviceTree Support
Step 2 - Tag the kernel image as DT aware using mkknlimg
Step 3 - Test kernel DT is working
Step 4 - Add the RPI_FT5406 touchscreen into the kernel
Step 5 - cross fingers & test

procount commented Oct 14, 2015

OK down the rabbit hole then! :) Is this the correct way?
Step 1 - Enable DT support in buildroot kernel with Boot Options/ Flattended DeviceTree Support
Step 2 - Tag the kernel image as DT aware using mkknlimg
Step 3 - Test kernel DT is working
Step 4 - Add the RPI_FT5406 touchscreen into the kernel
Step 5 - cross fingers & test

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 14, 2015

Contributor

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.

Contributor

pelwell commented Oct 14, 2015

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 14, 2015

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 device-tree.md#part-3-using-device-trees-on-raspberry-pi, the NOOBS kernel does not appear to be DT enabled yet (probably because there was no need).

procount commented Oct 14, 2015

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 device-tree.md#part-3-using-device-trees-on-raspberry-pi, the NOOBS kernel does not appear to be DT enabled yet (probably because there was no need).

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 14, 2015

Contributor

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.

Contributor

pelwell commented Oct 14, 2015

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 15, 2015

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.
I booted it and got messages about missing DT for CPU1,2,3 & 4 (or something).
So I used mkknlimg on recovery7.img.
I copied the DTBs from a Raspbian Jessie installation with the Overlays folder onto the NOOBS partition.
When I booted, I got the following 3 errors:

of_dma_request_slave_channel: dma-names property of node '/soc/uart@7e201000' missing or empty
mmc-bcm2835 mmc-bcm2835.o: cannot request region
mmc-bcm2835 mmc-bcm2835.o: bcm2835_mmc_probe failed -16

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 do have a /proc/device-tree with some stuff in it, including rpi_ft5406/

procount commented Oct 15, 2015

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.
I booted it and got messages about missing DT for CPU1,2,3 & 4 (or something).
So I used mkknlimg on recovery7.img.
I copied the DTBs from a Raspbian Jessie installation with the Overlays folder onto the NOOBS partition.
When I booted, I got the following 3 errors:

of_dma_request_slave_channel: dma-names property of node '/soc/uart@7e201000' missing or empty
mmc-bcm2835 mmc-bcm2835.o: cannot request region
mmc-bcm2835 mmc-bcm2835.o: bcm2835_mmc_probe failed -16

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 do have a /proc/device-tree with some stuff in it, including rpi_ft5406/

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 16, 2015

Contributor

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 WARN(1, "here"); at the top, as shown below:

    struct resource *iomem;
    int ret;
    WARN(1, "here"); // <=====

    iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);

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.

Contributor

pelwell commented Oct 16, 2015

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 WARN(1, "here"); at the top, as shown below:

    struct resource *iomem;
    int ret;
    WARN(1, "here"); // <=====

    iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 16, 2015

I'm willing to do any digging as I am using NOOBS as a way to learn more about linux development.
I added the WARN line above and recompiled. I can't find any kernel log - /var/log has nothing useful in it. Perhaps logging is disabled in the NOOBS kernel? Where should it be set? I had a quick look at busybox-menuconfig and syslogd is enabled. klogd is also enabled and set to use the klogctl() interface.

procount commented Oct 16, 2015

I'm willing to do any digging as I am using NOOBS as a way to learn more about linux development.
I added the WARN line above and recompiled. I can't find any kernel log - /var/log has nothing useful in it. Perhaps logging is disabled in the NOOBS kernel? Where should it be set? I had a quick look at busybox-menuconfig and syslogd is enabled. klogd is also enabled and set to use the klogctl() interface.

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 16, 2015

Contributor

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).

Contributor

pelwell commented Oct 16, 2015

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).

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 16, 2015

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.

procount commented Oct 16, 2015

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.

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 16, 2015

Contributor

I modified my recovery.cmdline to say:

qvt.cur_default=1 elevator=deadline console=ttyAMA0,115200 loglevel=8

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.

Contributor

pelwell commented Oct 16, 2015

I modified my recovery.cmdline to say:

qvt.cur_default=1 elevator=deadline console=ttyAMA0,115200 loglevel=8

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 16, 2015

Doh! I was looking for something more complicated than that!

[    0.194225] ------------[ cut here ]------------
[    0.194281] WARNING: CPU: 0 PID: 1 at arch/arm/mach-bcm2709/armctrl.c:148 armctrl_xlate+0x190/0x27c()
[    0.194331] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.7-rescue-v7 #6
[    0.194363] Backtrace: 
[    0.194405] [<80011928>] (dump_backtrace) from [<80011ac8>] (show_stack+0x18/0x1c)
[    0.194443]  r6:00000000 r5:85c36008 r4:80432310 r3:00000000
[    0.194503] [<80011ab0>] (show_stack) from [<803352e8>] (dump_stack+0x98/0xd0)
[    0.194550] [<80335250>] (dump_stack) from [<8001d328>] (warn_slowpath_common+0x70/0x8c)
[    0.194588]  r6:00000094 r5:00000009 r4:00000000 r3:00000000
[    0.194646] [<8001d2b8>] (warn_slowpath_common) from [<8001d41c>] (warn_slowpath_null+0x24/0x2c)
[    0.194686]  r8:00000000 r7:86ca02e8 r6:86ca02e8 r5:85c37c68 r4:85c10000
[    0.194754] [<8001d3f8>] (warn_slowpath_null) from [<80018e10>] (armctrl_xlate+0x190/0x27c)
[    0.194808] [<80018c80>] (armctrl_xlate) from [<80058f64>] (irq_create_of_mapping+0x6c/0x118)
[    0.194863] [<80058ef8>] (irq_create_of_mapping) from [<802993a8>] (irq_of_parse_and_map+0x2c/0x34)
[    0.194904]  r5:85d426c0 r4:00000000
[    0.194949] [<8029937c>] (irq_of_parse_and_map) from [<802993d0>] (of_irq_to_resource+0x20/0xc0)
[    0.195002] [<802993b0>] (of_irq_to_resource) from [<80299590>] (of_irq_to_resource_table+0x44/0x54)
[    0.195042]  r8:00000000 r7:00000001 r6:86ca02e8 r5:85d426dc r4:00000000
[    0.195111] [<8029954c>] (of_irq_to_resource_table) from [<80297108>] (of_device_alloc+0xf0/0x164)
[    0.195151]  r7:00000001 r6:85d4c800 r5:86ca02e8 r4:00000000
[    0.195212] [<80297018>] (of_device_alloc) from [<802971cc>] (of_platform_device_create_pdata+0x50/0xa0)
[    0.195253]  r10:85d32c10 r9:00000000 r8:00000000 r7:86ca0338 r6:00000000 r5:85d32c10
[    0.195318]  r4:86ca02e8
[    0.195354] [<8029717c>] (of_platform_device_create_pdata) from [<80297300>] (of_platform_bus_create+0xe4/0x2f4)
[    0.195397]  r8:00000000 r7:803635a0 r6:00000001 r5:00000000 r4:86ca02e8 r3:85d32c10
[    0.195474] [<8029721c>] (of_platform_bus_create) from [<8029735c>] (of_platform_bus_create+0x140/0x2f4)
[    0.195515]  r10:00000000 r9:85d32c10 r8:86ca02e8 r7:803635a0 r6:00000001 r5:00000000
[    0.195579]  r4:86c9c40c
[    0.195616] [<8029721c>] (of_platform_bus_create) from [<80297664>] (of_platform_populate+0x64/0xa8)
[    0.195656]  r10:00000000 r9:00000001 r8:00000000 r7:00000000 r6:803635a0 r5:86c9ad8c
[    0.195720]  r4:86c9c40c
[    0.195755] [<80297600>] (of_platform_populate) from [<803e48a8>] (bcm2709_init+0x6c/0x220)
[    0.195793]  r9:85c36038 r8:803e0870 r7:8043e1c0 r6:8043e624 r5:803ff7b8 r4:8042a100
[    0.195869] [<803e483c>] (bcm2709_init) from [<803e0898>] (customize_machine+0x28/0x48)
[    0.195907]  r6:85d2f040 r5:803ff7b8 r4:803ff7b8 r3:803fba48
[    0.195967] [<803e0870>] (customize_machine) from [<803dde44>] (do_one_initcall+0x120/0x1c4)
[    0.196018] [<803ddd24>] (do_one_initcall) from [<803de02c>] (kernel_init_freeable+0x144/0x1e8)
[    0.196058]  r10:803fffec r9:000000b7 r8:803dd5e8 r7:8043e1c0 r6:8043e1c0 r5:803fffd4
[    0.196122]  r4:00000003
[    0.196159] [<803ddee8>] (kernel_init_freeable) from [<803319b8>] (kernel_init+0x10/0xf8)
[    0.196197]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:803319a8
[    0.196260]  r4:00000000
[    0.196296] [<803319a8>] (kernel_init) from [<8000e898>] (ret_from_fork+0x14/0x3c)
[    0.196333]  r4:00000000 r3:85c36000
[    0.196390] ---[ end trace fa8ecb34b63f021c ]---

procount commented Oct 16, 2015

Doh! I was looking for something more complicated than that!

[    0.194225] ------------[ cut here ]------------
[    0.194281] WARNING: CPU: 0 PID: 1 at arch/arm/mach-bcm2709/armctrl.c:148 armctrl_xlate+0x190/0x27c()
[    0.194331] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.7-rescue-v7 #6
[    0.194363] Backtrace: 
[    0.194405] [<80011928>] (dump_backtrace) from [<80011ac8>] (show_stack+0x18/0x1c)
[    0.194443]  r6:00000000 r5:85c36008 r4:80432310 r3:00000000
[    0.194503] [<80011ab0>] (show_stack) from [<803352e8>] (dump_stack+0x98/0xd0)
[    0.194550] [<80335250>] (dump_stack) from [<8001d328>] (warn_slowpath_common+0x70/0x8c)
[    0.194588]  r6:00000094 r5:00000009 r4:00000000 r3:00000000
[    0.194646] [<8001d2b8>] (warn_slowpath_common) from [<8001d41c>] (warn_slowpath_null+0x24/0x2c)
[    0.194686]  r8:00000000 r7:86ca02e8 r6:86ca02e8 r5:85c37c68 r4:85c10000
[    0.194754] [<8001d3f8>] (warn_slowpath_null) from [<80018e10>] (armctrl_xlate+0x190/0x27c)
[    0.194808] [<80018c80>] (armctrl_xlate) from [<80058f64>] (irq_create_of_mapping+0x6c/0x118)
[    0.194863] [<80058ef8>] (irq_create_of_mapping) from [<802993a8>] (irq_of_parse_and_map+0x2c/0x34)
[    0.194904]  r5:85d426c0 r4:00000000
[    0.194949] [<8029937c>] (irq_of_parse_and_map) from [<802993d0>] (of_irq_to_resource+0x20/0xc0)
[    0.195002] [<802993b0>] (of_irq_to_resource) from [<80299590>] (of_irq_to_resource_table+0x44/0x54)
[    0.195042]  r8:00000000 r7:00000001 r6:86ca02e8 r5:85d426dc r4:00000000
[    0.195111] [<8029954c>] (of_irq_to_resource_table) from [<80297108>] (of_device_alloc+0xf0/0x164)
[    0.195151]  r7:00000001 r6:85d4c800 r5:86ca02e8 r4:00000000
[    0.195212] [<80297018>] (of_device_alloc) from [<802971cc>] (of_platform_device_create_pdata+0x50/0xa0)
[    0.195253]  r10:85d32c10 r9:00000000 r8:00000000 r7:86ca0338 r6:00000000 r5:85d32c10
[    0.195318]  r4:86ca02e8
[    0.195354] [<8029717c>] (of_platform_device_create_pdata) from [<80297300>] (of_platform_bus_create+0xe4/0x2f4)
[    0.195397]  r8:00000000 r7:803635a0 r6:00000001 r5:00000000 r4:86ca02e8 r3:85d32c10
[    0.195474] [<8029721c>] (of_platform_bus_create) from [<8029735c>] (of_platform_bus_create+0x140/0x2f4)
[    0.195515]  r10:00000000 r9:85d32c10 r8:86ca02e8 r7:803635a0 r6:00000001 r5:00000000
[    0.195579]  r4:86c9c40c
[    0.195616] [<8029721c>] (of_platform_bus_create) from [<80297664>] (of_platform_populate+0x64/0xa8)
[    0.195656]  r10:00000000 r9:00000001 r8:00000000 r7:00000000 r6:803635a0 r5:86c9ad8c
[    0.195720]  r4:86c9c40c
[    0.195755] [<80297600>] (of_platform_populate) from [<803e48a8>] (bcm2709_init+0x6c/0x220)
[    0.195793]  r9:85c36038 r8:803e0870 r7:8043e1c0 r6:8043e624 r5:803ff7b8 r4:8042a100
[    0.195869] [<803e483c>] (bcm2709_init) from [<803e0898>] (customize_machine+0x28/0x48)
[    0.195907]  r6:85d2f040 r5:803ff7b8 r4:803ff7b8 r3:803fba48
[    0.195967] [<803e0870>] (customize_machine) from [<803dde44>] (do_one_initcall+0x120/0x1c4)
[    0.196018] [<803ddd24>] (do_one_initcall) from [<803de02c>] (kernel_init_freeable+0x144/0x1e8)
[    0.196058]  r10:803fffec r9:000000b7 r8:803dd5e8 r7:8043e1c0 r6:8043e1c0 r5:803fffd4
[    0.196122]  r4:00000003
[    0.196159] [<803ddee8>] (kernel_init_freeable) from [<803319b8>] (kernel_init+0x10/0xf8)
[    0.196197]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:803319a8
[    0.196260]  r4:00000000
[    0.196296] [<803319a8>] (kernel_init) from [<8000e898>] (ret_from_fork+0x14/0x3c)
[    0.196333]  r4:00000000 r3:85c36000
[    0.196390] ---[ end trace fa8ecb34b63f021c ]---
@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 16, 2015

Contributor

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 dtbs kernel make target to build the right DTB files for a particular kernel.

Contributor

pelwell commented Oct 16, 2015

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 dtbs kernel make target to build the right DTB files for a particular kernel.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 16, 2015

ok I'll give it a try.
In buildroot/output/build/linux-b6.... I tried make dtbs.
What should I answer to this Question:

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

procount commented Oct 16, 2015

ok I'll give it a try.
In buildroot/output/build/linux-b6.... I tried make dtbs.
What should I answer to this Question:

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

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Oct 17, 2015

Collaborator

Always include "ARCH=arm" on kernel make lines, or you will default to x86 config. E.g.
make ARCH=arm dtbs

Collaborator

popcornmix commented Oct 17, 2015

Always include "ARCH=arm" on kernel make lines, or you will default to x86 config. E.g.
make ARCH=arm dtbs

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 17, 2015

Thanks.
Next problem- where to put the ft5406.dts file as there is no overlays folder in v3.18?
(Or would it just be easier to bump the NOOBS kernel to a version that includes this touchscreen driver already?)

procount commented Oct 17, 2015

Thanks.
Next problem- where to put the ft5406.dts file as there is no overlays folder in v3.18?
(Or would it just be easier to bump the NOOBS kernel to a version that includes this touchscreen driver already?)

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 17, 2015

Step 4: backporting from linux-b630db9dcb5c73367050a672823047b0466b16b9
Updated drivers/input/touchscreen/Kconfig to include rpi-ft5406 configuration.
Added drivers/input/touchscreen/rpi-ft5406.c
Updated drivers/input/touchscreen/Makefile to include rpi-ft5406 target
Added arch/arm/boot/dts/rpi-ft5406-pverlay.dts (is it supposed to be in dts/overlays?)
Added 'dtb-$(RPI_DT_OVERLAYS) += rpi-ft5406-overlay.dtb' to arch/arm/boot/dts/Makefile
ran ./make_arch_linux-menuconfig.sh armv7 and set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_RPI_FT5406=y
ran ./BUILDME.sh : rpi=ft5406.c fails.
Added missing include/linux/platform_data/mailbox-bcm2708.h
ran ./BUILDME.sh : successful.

I couldn't find rpi-ft5406-overlay.dtb so,
make ARCH=arm dtbs and got:

  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.
NOOBS booted fine, no errors, but no touchscreen either.

procount commented Oct 17, 2015

Step 4: backporting from linux-b630db9dcb5c73367050a672823047b0466b16b9
Updated drivers/input/touchscreen/Kconfig to include rpi-ft5406 configuration.
Added drivers/input/touchscreen/rpi-ft5406.c
Updated drivers/input/touchscreen/Makefile to include rpi-ft5406 target
Added arch/arm/boot/dts/rpi-ft5406-pverlay.dts (is it supposed to be in dts/overlays?)
Added 'dtb-$(RPI_DT_OVERLAYS) += rpi-ft5406-overlay.dtb' to arch/arm/boot/dts/Makefile
ran ./make_arch_linux-menuconfig.sh armv7 and set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_RPI_FT5406=y
ran ./BUILDME.sh : rpi=ft5406.c fails.
Added missing include/linux/platform_data/mailbox-bcm2708.h
ran ./BUILDME.sh : successful.

I couldn't find rpi-ft5406-overlay.dtb so,
make ARCH=arm dtbs and got:

  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.
NOOBS booted fine, no errors, but no touchscreen either.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 20, 2015

I guessed that the above errors were because I was using the wrong gcc (x86 on Ubuntu) so I tried:
make ARCH=arm CROSS_COMPILE="/home/kevin/noobs_dev/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-" dtbs and this compiled the dtbs, finally. I wonder if this will work now....

procount commented Oct 20, 2015

I guessed that the above errors were because I was using the wrong gcc (x86 on Ubuntu) so I tried:
make ARCH=arm CROSS_COMPILE="/home/kevin/noobs_dev/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-" dtbs and this compiled the dtbs, finally. I wonder if this will work now....

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 20, 2015

Nope. Still no touchdriver.
rpi-ft5406.c is being compiled and the DTBs have now been produced. mkknlimg used to tag img.
DMESG shows "Machine Model: Raspberry Pi 2 Model B Rev 1.1" but there is no message about "No ATAGs?"
There is a /proc/device-tree but there is no rpi-ft5406 file listed as I expected.
Added dtoverlay=rpi-ft5406 to config.txt but it did nothing.
I don't seem to have vcdbg to debug further.
Any ideas?

procount commented Oct 20, 2015

Nope. Still no touchdriver.
rpi-ft5406.c is being compiled and the DTBs have now been produced. mkknlimg used to tag img.
DMESG shows "Machine Model: Raspberry Pi 2 Model B Rev 1.1" but there is no message about "No ATAGs?"
There is a /proc/device-tree but there is no rpi-ft5406 file listed as I expected.
Added dtoverlay=rpi-ft5406 to config.txt but it did nothing.
I don't seem to have vcdbg to debug further.
Any ideas?

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 21, 2015

Contributor

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.

Contributor

pelwell commented Oct 21, 2015

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 21, 2015

Yes. Thought of that overnight so tried copying it to both vfat and tmp and all I get is
"-sh: ./vcdbg: not found."
Tried with & without ./ prefix.
vcdbg is 63583 bytes.
Type vcdbg says
"Vcdbg is a tracked alias for /usr/bin/vcdbg"
But that says "not found" too.
V. Odd.

procount commented Oct 21, 2015

Yes. Thought of that overnight so tried copying it to both vfat and tmp and all I get is
"-sh: ./vcdbg: not found."
Tried with & without ./ prefix.
vcdbg is 63583 bytes.
Type vcdbg says
"Vcdbg is a tracked alias for /usr/bin/vcdbg"
But that says "not found" too.
V. Odd.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 21, 2015

It works ok in Jessie where I can see the line:
"Loaded overlay 'rpi-ft5406'"
But not in my noobs kernel.

procount commented Oct 21, 2015

It works ok in Jessie where I can see the line:
"Loaded overlay 'rpi-ft5406'"
But not in my noobs kernel.

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 21, 2015

Contributor

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:

/usr/lib/arm-linux-gnueabihf/libarmmem.so
/opt/vc/lib/libdebug_sym.so
/opt/vc/lib/libvcos.so
/lib/arm-linux-gnueabihf/libpthread.so.0
/lib/arm-linux-gnueabihf/libdl.so.2
/lib/arm-linux-gnueabihf/librt.so.1
/lib/arm-linux-gnueabihf/libc.so.6

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.

Contributor

pelwell commented Oct 21, 2015

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:

/usr/lib/arm-linux-gnueabihf/libarmmem.so
/opt/vc/lib/libdebug_sym.so
/opt/vc/lib/libvcos.so
/lib/arm-linux-gnueabihf/libpthread.so.0
/lib/arm-linux-gnueabihf/libdl.so.2
/lib/arm-linux-gnueabihf/librt.so.1
/lib/arm-linux-gnueabihf/libc.so.6

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 21, 2015

Thanks. I copied them all over from Jessie into the vfat partition in preparation, so I'll try it out tonight & report back.

procount commented Oct 21, 2015

Thanks. I copied them all over from Jessie into the vfat partition in preparation, so I'll try it out tonight & report back.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 21, 2015

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.

procount commented Oct 21, 2015

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.

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 21, 2015

Contributor

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.

Contributor

pelwell commented Oct 21, 2015

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.

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Oct 29, 2015

Contributor

Nice work! I hope you realise that I'll be expecting a patch set at the end of this.

Contributor

pelwell commented Oct 29, 2015

Nice work! I hope you realise that I'll be expecting a patch set at the end of this.

@DieterReuter

This comment has been minimized.

Show comment
Hide comment
@DieterReuter

DieterReuter commented Oct 29, 2015

@procount great work!

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Oct 29, 2015

Thanks.
Patch set? - Hehehe - lol!
I wouldn't want to put you in a hypocritical position! ;-)
Maybe if I ever get it working with DT and can get the scaling right I can provide a PR to Noobs.

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?

procount commented Oct 29, 2015

Thanks.
Patch set? - Hehehe - lol!
I wouldn't want to put you in a hypocritical position! ;-)
Maybe if I ever get it working with DT and can get the scaling right I can provide a PR to Noobs.

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?

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Nov 3, 2015

Official Touchscreen now working properly in NOOBS! Woo Hoo!
No device tree support yet, but that should be the easy part, right?
What was that about a patch set? ;-)

procount commented Nov 3, 2015

Official Touchscreen now working properly in NOOBS! Woo Hoo!
No device tree support yet, but that should be the easy part, right?
What was that about a patch set? ;-)

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Nov 5, 2015

@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.

procount commented Nov 5, 2015

@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.

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Nov 5, 2015

Contributor

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:

    rpi_ft5406: rpi_ft5406 {
        compatible = "rpi,rpi-ft5406";
        firmware = <&firmware>;
        status = "okay";
    };

i.e. an identifier for the device driver and a reference to the firmware/mailbox device.

Contributor

pelwell commented Nov 5, 2015

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:

    rpi_ft5406: rpi_ft5406 {
        compatible = "rpi,rpi-ft5406";
        firmware = <&firmware>;
        status = "okay";
    };

i.e. an identifier for the device driver and a reference to the firmware/mailbox device.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Nov 5, 2015

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.

procount commented Nov 5, 2015

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Nov 19, 2015

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.
Currently I am looking at /proc/bus/input/devices for Name="FT5406 and then picking the next Handlers line which seems to work ok for the touchscreen. But is there a standard naming convention for the Name of any mouse attached? The ones I have seen all include Mouse But do I also need to look for mouse and MOUSE, or is there a better, more consistent way to find the name of the mouse driver (in a BusyBox Bourne shell script)?

procount commented Nov 19, 2015

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.
Currently I am looking at /proc/bus/input/devices for Name="FT5406 and then picking the next Handlers line which seems to work ok for the touchscreen. But is there a standard naming convention for the Name of any mouse attached? The ones I have seen all include Mouse But do I also need to look for mouse and MOUSE, or is there a better, more consistent way to find the name of the mouse driver (in a BusyBox Bourne shell script)?

@pssc

This comment has been minimized.

Show comment
Hide comment
@pssc

pssc Nov 19, 2015

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

/etc/udev/rules.d/95-rpi-lcd.rules 
# N: Name="FT5406 memory based driver"  -- Offical rpi touch screen lcd
SUBSYSTEM=="input", ATTRS{name}=="FT5406 memory based driver", ENV{DEVNAME}=="*event*", SYMLINK+="input/touchscreen-rpi-lcd"

pssc commented Nov 19, 2015

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

/etc/udev/rules.d/95-rpi-lcd.rules 
# N: Name="FT5406 memory based driver"  -- Offical rpi touch screen lcd
SUBSYSTEM=="input", ATTRS{name}=="FT5406 memory based driver", ENV{DEVNAME}=="*event*", SYMLINK+="input/touchscreen-rpi-lcd"
@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Nov 19, 2015

@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.

procount commented Nov 19, 2015

@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.

@mllapps

This comment has been minimized.

Show comment
Hide comment
@mllapps

mllapps Jan 10, 2016

Could you explain what should be enabled to support the 7" display?

mllapps commented Jan 10, 2016

Could you explain what should be enabled to support the 7" display?

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Jan 10, 2016

The latest kernel used for Noobs now contans device tree support for the 7" display and touchscreen so you could just use that now.

procount commented Jan 10, 2016

The latest kernel used for Noobs now contans device tree support for the 7" display and touchscreen so you could just use that now.

@mllapps

This comment has been minimized.

Show comment
Hide comment
@mllapps

mllapps Jan 10, 2016

Thank you I will try it. Which is the right device tree blob file I have to use?
I could find no documentation about it.

Currently I use a custom image so I would like to add the display support to my config files.

mllapps commented Jan 10, 2016

Thank you I will try it. Which is the right device tree blob file I have to use?
I could find no documentation about it.

Currently I use a custom image so I would like to add the display support to my config files.

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Jan 11, 2016

Contributor

Including:

CONFIG_TOUCHSCREEN_RPI_FT5406=m

and making sure the rpi-ft5406 overlay is built and installed ought to be sufficient.

Contributor

pelwell commented Jan 11, 2016

Including:

CONFIG_TOUCHSCREEN_RPI_FT5406=m

and making sure the rpi-ft5406 overlay is built and installed ought to be sufficient.

@mllapps

This comment has been minimized.

Show comment
Hide comment
@mllapps

mllapps Jan 12, 2016

If I understand right CONFIG_TOUCHSCREEN_RPI_FT5406=m is only the touchscreen not the display?

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.

mllapps commented Jan 12, 2016

If I understand right CONFIG_TOUCHSCREEN_RPI_FT5406=m is only the touchscreen not the display?

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Jan 12, 2016

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.
To add ft5406 support you need to backport the ft5406 driver like I did (see history above) or use a later kernel where the driver is built in.
The recommended way to backport the driver is to add device tree support as well but I found that difficult. So I added it as the old type of system driver.

procount commented Jan 12, 2016

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.
To add ft5406 support you need to backport the ft5406 driver like I did (see history above) or use a later kernel where the driver is built in.
The recommended way to backport the driver is to add device tree support as well but I found that difficult. So I added it as the old type of system driver.

@mllapps

This comment has been minimized.

Show comment
Hide comment
@mllapps

mllapps Jan 12, 2016

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 commented Jan 12, 2016

OK know I understand it. Thank you for your patience. I think a update to the new kernel 4.x is the best choice.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Jan 12, 2016

@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 commented Jan 12, 2016

@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.

@mllapps

This comment has been minimized.

Show comment
Hide comment
@mllapps

mllapps Jan 12, 2016

@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.

mllapps commented Jan 12, 2016

@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.

@cmon-meow

This comment has been minimized.

Show comment
Hide comment
@cmon-meow

cmon-meow Jun 16, 2016

Where can I begin with non device tree support, or was did you have a PR?
I leaned away from device tree support when it was introduced "Windows can keep it's 1 kernel fit's all approach", and seems unreasonable to drag a tree around for 1 driver. ;)

cmon-meow commented Jun 16, 2016

Where can I begin with non device tree support, or was did you have a PR?
I leaned away from device tree support when it was introduced "Windows can keep it's 1 kernel fit's all approach", and seems unreasonable to drag a tree around for 1 driver. ;)

@mllapps

This comment has been minimized.

Show comment
Hide comment
@mllapps

mllapps Jun 16, 2016

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.

mllapps commented Jun 16, 2016

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.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Jun 16, 2016

@cmon-meow - If I understand you correctly, you want to add the touchscreen driver to a non-DT enabled kernel, like I did?
Although I got it working, I abandoned this approach because the RPF released NOOBS version 1.5 that included the touchscreen driver support. I was also using an approach of including it as a platform driver instead of the preferred Device-tree approach, but if you want to avoid DT, then I think this is the only way.
I think I have a backup copy of my work that I did on the 3.18 kernel, but I'd have to dig it out and spin up another Linux VM to access it. It might take me a while, but if you are interested, I will see what I can do.

procount commented Jun 16, 2016

@cmon-meow - If I understand you correctly, you want to add the touchscreen driver to a non-DT enabled kernel, like I did?
Although I got it working, I abandoned this approach because the RPF released NOOBS version 1.5 that included the touchscreen driver support. I was also using an approach of including it as a platform driver instead of the preferred Device-tree approach, but if you want to avoid DT, then I think this is the only way.
I think I have a backup copy of my work that I did on the 3.18 kernel, but I'd have to dig it out and spin up another Linux VM to access it. It might take me a while, but if you are interested, I will see what I can do.

@cmon-meow

This comment has been minimized.

Show comment
Hide comment
@cmon-meow

cmon-meow Jun 16, 2016

Would be greatly appreciated, you are correct.

cmon-meow commented Jun 16, 2016

Would be greatly appreciated, you are correct.

@procount

This comment has been minimized.

Show comment
Hide comment
@procount

procount Jun 16, 2016

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 dotouch that copies these files into the linux folders. Please review the paths before using on your system. I have combined all of these files into touchscreen.tar.gz.

touchscreen.tar.gz

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).

procount commented Jun 16, 2016

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 dotouch that copies these files into the linux folders. Please review the paths before using on your system. I have combined all of these files into touchscreen.tar.gz.

touchscreen.tar.gz

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).

@cmon-meow

This comment has been minimized.

Show comment
Hide comment
@cmon-meow

cmon-meow Jun 18, 2016

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.

cmon-meow commented Jun 18, 2016

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.

@Ruffio

This comment has been minimized.

Show comment
Hide comment
@Ruffio

Ruffio Aug 17, 2016

@DieterReuter has your issue been resolved? If so, please close this issue. Thanks.

Ruffio commented Aug 17, 2016

@DieterReuter has your issue been resolved? If so, please close this issue. Thanks.

@DieterReuter

This comment has been minimized.

Show comment
Hide comment
@DieterReuter

DieterReuter Aug 17, 2016

Yes, it's resolved.

DieterReuter commented Aug 17, 2016

Yes, it's resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment