I’ve just started the test with my custom carrier board for Verdin iMX8M-Plus Quad 2GB WB IT V1.1A.
I customized the device tree (I hope i the right way) and rebuilt TorizonOS based on 6.6.1+build.14.
The SoM boot as expected, and “from the outside” everything seems ok.
I get these boot messages on the Linux console
Can someone explain the reasons for these errors?
Should I take care about them?
One more thing:
I connected a TTL to USB Serial Converter to Linux console (UART3).
If I plug it into a USB port of my PC, and then I power up th SoM, the boot is ok.
If I leave it unplugged from my PC, and then I power up th SoM, the boot is not done.
I did some test and the difference is the pin UART RX.
I see that when the converter is unplugged the voltage level is 0V, but I think it’s pulled to 0V (and not floating). And in this case the SoM doesn’t boot.
Is this an expected behavior?
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
The errors you’re encountering during boot, specifically the ones related to clk: failed to reparent hsio_axi to sys_pll2_500m: -16 and snd_soc_register_card failed (-517), indicate issues with clock configuration and the sound card registration process, respectively. These errors are often related to the device tree configuration, suggesting that the customization might not have been entirely correct or complete for your custom carrier board.
Clock Reparenting Error: This error suggests that the system is trying to change the parent clock of hsio_axi to sys_pll2_500m but fails. This could be due to the clock source (sys_pll2_500m) not being enabled or not available. Review your device tree to ensure that the PLL configurations and their dependencies are correctly defined and that the hsio_axi clock source is correctly set up.
Sound Card Registration Error: The -517 error code corresponds to -EPROBE_DEFER, which means the system is attempting to register the sound card before the necessary components (like I2C devices or codecs) are ready. This is common in device trees where dependencies are not correctly defined, causing the driver to load prematurely. Ensure that all dependencies for the HDMI sound output are correctly specified in your device tree, including any I2C controllers or codecs that the HDMI interface depends on.
Regarding the boot issue related to the TTL to USB Serial Converter, it seems like the SoM is sensitive to the UART RX pin’s state during boot. This behavior might not be directly related to the errors above but could indicate a misconfiguration or sensitivity in the boot process to certain UART lines. In many systems, UART lines are monitored during boot, and their state can influence boot behavior, especially if the bootloader is configured to wait for serial input. Ensuring that the UART RX pin is correctly pulled up or not left floating when not connected to the USB serial converter might help. However, this behavior might also be influenced by the specific configurations of your custom carrier board and the SoM’s bootloader settings.
In summary, for the device tree and boot errors, a thorough review and possibly reconfiguration of your device tree, focusing on clock sources and sound card dependencies, are recommended. For the UART issue, ensuring proper electrical behavior of the UART RX pin when disconnected might resolve the boot inconsistency.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Let me try and break down the messages you’re seeing here as best as I can.
clk: failed to reparent hsio_axi to sys_pll2_500m: -16
This happens also on our default Toradex device tree and carrier board. Just a non-fatal issue with trying to associate clocks with the hsio_axi subsystem. These clock settings come from the NXP side of things, though we haven’t noticed any consequences from this which is why it’s still present.
fsl-aud2htx 30cb0000.aud2htx: failed to pcm register
This is also related to HDMI audio. aud2htx is the HDMI RTX subsystem controller on some NXP SoCs like the verdin i.MX8MP. Seems like most of your warning messages are related to the HDMI audio subsystem not starting correctly.
That said, when I enable this I don’t see the same warning messages even when I don’t have anything connected to HDMI. That said if these aren’t causing issues for you, you can probably just ignore them, they all seem to be non-fatal warning messages at worst.
Is this an expected behavior?
That doesn’t sound quite right. At least our boards can boot just fine without anything connected to UART3. Out of curiosity have you had the schematic for your customer carrier board reviewed by anyone at Toradex?
Yes, by Matthias.
The schematics are highly inspirated by Yavia.
But keep in mind one important thing:
as an example, on the Yavia, a CP2105 USB to UART bridge is mounted on the PCB (and powered by the Yavia itself). With this configuration, the bridge it’s permanently connected to UART3 (and powered).
On my carrier, I have UART3 pins directly exposed. And so my TTL to USB Serial Converter is poweredon only when I plug it into my PC (and in this way it works).
If you want to reproduce my scenario, you need to remove U50 and L14 from the Yavia, and pull-down to 0V U3_RX pin.
Or, in an easy way on the Verdin Development Board, removing X16n2F and X16n2E jumpers and pulling SODIMM_147 to 0V.
I can confirm that they appear using Torizon OS on a Yavia, but only if HDMI1 (J15) is disconnected and the verdin-imx8mp_hdmi_overlay.dtbo device tree overlay is enabled.
If you are not using the native HDMI interface of the Verdin iMX8MP, I recommend that you disable the verdin-imx8mp_hdmi_overlay.dtbo device tree overlay and the error messages should no longer appear.
Regarding the boot problems with the serial adapter disconnected, as @jeremias.tx said, this is unexpected.
I tested if pulling SODIMM_147 and/or SODIMM_149 low would have this effect on a Verdin Development Board, but the boot process proceeded as expected.
What did cause a boot issue was to manually introduce noise into SODIMM_147, with the pin left disconnected and a noise source.
To check if this is the case in your board, can you connect only SODIMM_149 (UART_3_TXD) to your serial adapter and see what is the output you get?
If UART_3_RXD is receiving garbage, it should be visible in the serial output.
I see on the Yavia when the verdin-imx8mp_hdmi_overlay.dtbo device tree overlay is enabled, but even when HDMI1 (J15) is connected.
Is it possible that my HDMI display is “slow” to respond and so some error messages are printed (before it can be properly detected by the SoM)?
I can confirm that HDMI1 video + audio work properly on the Yavia, even if I see these messages.
I use the native HDMI interface, and so I need to leave the verdin-imx8mp_hdmi_overlay.dtbo device tree overlay enabled.
I confirm that even on my custom carrier board, HDMI video + audio work as expected, even if I see some messages.
For completeness, both on the Yavia and on my carrier board, the numer of the error messages is not the same at every boot. Sometimes no messages at all.
This is the reason why I suppose they can depend on how fast the SoM can detect the HDMI display connected.
You’re right.
The noise on the floating cable is the reason for the boot issue.
Probably we’re going to add some 100k pull-down resistor to UART_3_RXD (to avoid noise even if some floating cable is connected - by mistake).
Some HDMI displays don’t correctly implement the full HDMI specification, so some timing error on when a certain piece of information should be available could be the issue here.
Do you also see this problem on other HDMI displays?
That is good to know.
Matthias is currently on vacation, but he will be back on Monday.
When he is back I will ask for his input here, as he is familiar with your board’s design.
I tested this on two other displays here.
This error always happens if the display has no audio capabilities.
The error also happens between 1-3 times in a second display with audio capabilities.
I think these are just failed attempts to register the audio output.
Once the audio-hdmi HDMI Jack is registered, the sound works as expected.
Therefore, this error can be safely ignored, considering the audio is also working as expected on your end.
