November 9, 2017 at 18:08 #1024
No devices that might be related to this ir_rec section. Just the following:
event0 input0 mice
P.November 9, 2017 at 18:16 #1025
According to the driver code it should be within input0…
You can also check with e.g.
dmesg | grep ir
if anything gets logged during startup.
Will have a deeper look into it tomorrow.
Philip.November 10, 2017 at 15:23 #1026
I have looked inside input0. It only contains information about a power button device.
dmesg | grep ir only returns irq related stuff, but no infrared device (error) messages.
I also added an optional line to the dts ir section: linux,rc-map-name = “rc-rc6-mce”; as an example to see if this improves anything. No luck, unfortunately.
PatrickNovember 11, 2017 at 16:18 #1027
okay, I found the problem. Although all LIRC related stuff was enabled in the defconfig one specific dependency was missing. Unfortunately no LIRC drivers were built into the kernel and the device-tree entry had no effect.
THIS commit solves the problem and I can confirm that the lirc gpio driver now gets loaded when enabled via dt. Haven’t had the chance yet to try IR reception as I’ve got no receiver currently but it looks like it should work now.
Nevertheless I’ve found a little mistake in your dt snippet.
should actually be
So one “_” was missing.
Philip.November 13, 2017 at 09:57 #1028
Thank you for the update. It looks promissing! I will give it a try as soon as I get my tool chain in order. Right now kernel builds fail with “redefinition of typedef …” errors. I’ll have to check my gcc version. As soon as I get this up and running I’ll connect a IR receiver and let you know the results.
PatrickNovember 13, 2017 at 14:24 #1029
The errors I encounter during kernel build are rather sticky. Meaning: a gcc update does not fix the “redefinition of typedef …”” error messages. This could mean the source has some issues, or I use a slightly different toolchain. What toolchain (not Yocto based) do you recommend for performing a kernel build using commands mentioned in THIS post? Please include, linux flavour, architecture x86 or 64, built essential, gcc version, etcetera.
Thanks for you help.
PatrickNovember 13, 2017 at 23:37 #1030
strange that you are having problems compiling the kernel.
I’m using a standard Ubuntu 16.04 x64 installation in VirtualBox.
As far as I can remember I installed the toolchain with
sudo apt-get install gcc-arm-linux-gnueabi lzop
and entered the steps like already in the other post mentioned.
git clone https://github.com/PolyVection/linux-imx/ cd linux-imx git checkout imx_4.1.15_2.1.0_ga_PV export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabi- make -j 6 imx_v7_PV_defconfig make -j 6 make -j 6 INSTALL_MOD_PATH=/path/to/folder modules_install
Does that not work for you?
If not, I’ll setup a new VM and document all steps needed right from the beginning.
Philip.November 14, 2017 at 18:01 #1031
Thanks for the reply. I made a new toolchain, based on Ubuntu 16.04 x64, like yours and I can confirm it is working now!
I can build the kernel modules using the commands above successfully. I had to issue the command apt-get install gcc-arm* in stead of gcc-arm-linux-gnueabi which is not a valid package according to the package manager.
Before this, I used an OpenSuse 13.1 environment to build the kernel without success. It probably has some settings set more strict when it come to allowing redefinitions of typedefs. On the Ubuntu environment after kernel build, a folder is created containing firmware and modules. Which I have to move over to the voltastream device. Isn’t it necessary to create a new [z|u]image a well?
Anyway, I am gonna add the infrared modifications needed to the dts file, rebuild the dtb, move all (including modules )to the voltastream zero, connect an Infrared sensor and see if I can get it working. I will let you know.
Thanks again for the help. It is very much appreciated.
PatrickNovember 14, 2017 at 18:37 #1032
okay, good to know that it’s working with Ubuntu 1604 now.
After the first compilation process is finished you can find the new zImage in arch/arm/boot and the device-tree binaries in /arch/arm/boot/dts.
In the next step you are generating the modules which will be shipped to the folder mentioned in the cmd line parameter.
Afterwards you copy the zImage and the both dtb’s to the /boot folder of the SD card and the whole modules folder to /lib/modules.
zImage version and modules folder name always need to match. Don’t touch the firmware folder as there are the binary blobs for the wifi drivers that aren’t part of the Kernel build.
If you only like to change the device-tree you neither have to copy over the modules nor the zImage.
Always happy to help.
Philip.November 16, 2017 at 11:50 #1033
Thanks again for your help. I now have rebuild the kernel and put all the files in the right place. I noticed the presence of the following items:
input1, input2 all point to a device gpio_ir_recv and the folders show signs of lirc0.
shows signs of a platform-ir-receiver-event
So thats a good thing.
I found the following: /sys/bus/platform/devices/ir-receiver/of_node
It contains items from the infrared section in the device tree but a “cat gpios” doesn’t show anything.
How do I know if the GPIO (2 12) was correctly assigned to one of these devices?
PatrickNovember 16, 2017 at 12:50 #1034
One additional positive note:
The infrared receiver is working! I connected an OS-1838B to the chosen GPIO pin2_12 (imx pin 44) and just watched the output of /dev/lirc0 with cat /dev/lirc0. It is outputting something when I press the rc5 remote button. So the routing is all okay. I just would like to know how I can verify this in the linux environment.November 20, 2017 at 23:16 #1035
great to hear that you’ve got it working!
Not sure what you mean with “verify this in linux environment”. From what you have written I understand that you connected the IR receiver to the mentioned GPIO pin and now you are able to see the received data in /dev/lirc0. In the device-tree you connected the GPIO2_12 pin to the lirc driver. What else you’d like to verify?
Rather than using cat on /dev/lirc0 you can also test the functionality with lirc’s mode2 tool.
Philip.November 21, 2017 at 12:10 #1036
Yeah, It’s a real joy to do this 😉 I indeed used lirc’s mode2 tool to see what happens in raw mode and it receives the pulse/pause time values correctly.
I taught my remote control which is an rc003 from Marantz, with irrecord. It has some buttons that are ment for a Marantz network player which I don’t have and would like to use for my DIY player. It works well 😉
Now for my question about how to verify if the GPIO was correctly assigned:
In linux I found the path: /sys/bus/platform/devices/ir-receiver/of_node
This folder contents resembles the hierarchy used in the device tree file.
I would however expect to see a gpio pin assignment value being returned when entering “cat gpios” in the above mentioned folder. It does not. Could be my mistake. It’s not that big a issue. Just out of curiousity.
Although I am very pleased with the sound quality of the onboard PCM5121, I am now going to attach an es9023 based DAC, just to make a comparison. When it’s finished, I’ll upload a picture of my setup 😉November 21, 2017 at 22:54 #1040
Yes, it always gives satisfaction when it finally works as expected. 🙂
Not sure if I can help you that much with your gpio verification check. Will have a look into it myself and report back if I’ll find something.
Great. Some pictures are always nice! 🙂
You must be logged in to reply to this topic.