After changing my base device tree to what i need for the project i get some errors while booting, which are understandable since some devices are disabled.
But i would like to change the boot code for these components so that the errors are not present.
Since i think this is not doable via the device tree and i need to change the linux o.s. image side for this, how would i go about removing some initializing blocks in the torizon o.s. image?
for example:
I disabled the SDHC1 controller in the device tree and now i get the following error while booting:
“[ 2.382555] reg-fixed-voltage regulator-sdhci1: Error applying setting, reverse things back”
I also disabled the SPI CS line in the device tree which results in the following errors while booting:
“[ 22.190673] pinctrl-single f4000.pinctrl: pin PIN112 already requested by 601000.gpio; cannot claim for spi0.1
[ 22.210220] pinctrl-single f4000.pinctrl: pin-112 (spi0.1) status -22
[ 22.223676] pinctrl-single f4000.pinctrl: could not request pin 112 (PIN112) from group main-gpio1-18-pins-default on device pinctrl-single
[ 22.251224] tpm_tis_spi spi0.1: Error applying setting, reverse things back”
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
To address the boot errors you’re encountering after disabling the SDHC1 controller and SPI CS line in the device tree, you will need to modify the Torizon OS image to prevent the initialization of these components. Here are the steps you can follow:
Identify Initialization Blocks:
Review the boot code and initialization scripts in the Torizon OS image to locate the sections responsible for initializing the SDHC1 controller and SPI CS line. This might involve looking into the kernel configuration or startup scripts that handle hardware initialization.
Modify the Boot Code:
Edit the relevant source code or configuration files to ensure that the system does not attempt to initialize these components. This could involve:
Commenting out or removing the initialization code for the SDHC1 controller and SPI CS line.
Adjusting the conditions under which these components are initialized based on their status in the device tree.
Rebuild the OS Image:
After making the necessary changes, rebuild the Torizon OS image to apply the modifications. This process typically involves using the Yocto Project build system to compile the modified source code into a new OS image.
Test the Changes:
Boot the modified OS image and check the dmesg log for any remaining errors related to the disabled components. Ensure that the system no longer attempts to initialize the SDHC1 controller and SPI CS line.
Documentation and Support:
Consult the Torizon OS documentation or support resources for specific guidance on modifying the boot code and rebuilding the OS image, as this process may vary based on the version and configuration of Torizon OS you are using.
By following these steps, you should be able to prevent the system from attempting to initialize the disabled components, thus eliminating the associated boot errors.
Please, also check if these links can help you solve your problem:
Just a few steps back, why do you want to disable log error messages? How did you make these modifications in your device tree? Did you write a device tree, or are you using our device tree? Besides that, could you specify which SoM and OS you are using?
The correct way to deal with it would be to understand and fix the errors. As far as I know, it is not possible to “exclude” errors from the boot log. The Torizon OS is already in “quiet” mode, which omits the kernel boot, but the error still appears. To achieve what you want, you would need to customize the kernel, which, in this case, is not recommended and would be quite difficult and time-demanding.
I don’t want to exclude the errors, i want to fix them.
I created a device tree where i excluded some peripherals as i needed these for basic GPIO.
So SDHC1 is completely disabled and the SPI CS line is disabled.
In response to this i get errors in DMESG (which is to be expected since the peripherals are disabled), but in order to fix my errors i need to exclude/disable the code which is generating the errors (probably some SDHC1 and SPI1 initialization code).
My setup is based on the Verdin AM62 module and i use the torizon o.s. based around:
Version: 6.7.0+build.18-tcbuilder.20241022123837
my device tree is based on the “verdin mallow non wifi” device tree which i copied and added my necessary changes to.
Why do you want to exclude the code responsible for the errors? If the interface is correctly disabled and the error is expected, you can just ignore it.
I’m saying that because it is not a simple task to exclude part of the kernel code that initializes the interfaces. It would take a lot of investigation to find the correct part to be excluded, and then you would need to create a patch with these changes and rebuild the kernel.
