Requested sample rate versus playback sample rate

[djagabParticipant]

No devices that might be related to this ir_rec section. Just the following:
event0 input0 mice

Best Regards,

P.

[VoltaStreamKeymaster]

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.

Best wishes,
Philip.

[djagabParticipant]

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.

Best Regards,

Patrick

[VoltaStreamKeymaster]

Hi Patrick,

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.

MX6UL_PAD_ENET2_TX_DATA1_GPIO2_IO12

should actually be

MX6UL_PAD_ENET2_TX_DATA1__GPIO2_IO12

So one “_” was missing.

Best wishes,
Philip.

[djagabParticipant]

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.

Best regards,

Patrick

[djagabParticipant]

Hi Philip,
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.

Best Regards

Patrick

[VoltaStreamKeymaster]

Hi Patrick,

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.

Best wishes,
Philip.

[djagabParticipant]

HI,

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.

Best regards,

Patrick

[VoltaStreamKeymaster]

Hi Patrick,

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.

Best wishes,
Philip.

[djagabParticipant]

Hi Philip,

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:

/sys/class/input/
input1, input2 all point to a device gpio_ir_recv and the folders show signs of lirc0.

/dev/input/
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?
Thanks.

Best regards,

Patrick

[djagabParticipant]

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.

[VoltaStreamKeymaster]

Hi Patrick,

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.

Best wishes,
Philip.

[djagabParticipant]

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 😉

[VoltaStreamKeymaster]

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! 🙂

[Author]

Posts