I do have problem which I haven`t solved many weeks.
I do have various CPU boards iMX6ULL v1.1A.
Using Kirkstone OS.
Most of the boards are without any problem and booting with all functionalities, but I have found some boards which are booting until SPI init which fails and there waits endless (deadlock) with same SD card, same carrier board, same u-boot settings. I tried imx6ull-colibri-emmc-eval-v3.dtb, imx6ull-colibri-eval-v3.dtb, my own with disabled spi, with the same result.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Hello Lubor,
Thank you for your detailed description of the issue. It’s helpful to know that most boards work fine, and only some hang at SPI initialization with the same hardware and software setup, which points toward a low-level compatibility or device tree issue.
Here are some steps to help you troubleshoot:
Device Tree Review
Since Kirkstone boots only some boards and Thud boots all, the issue may be due to changes in device tree requirements or compatibility. Make sure your device tree for Kirkstone is correctly enabling the SPI controller:
The relevant SPI node (e.g., spidev0) should have status = "okay".
If any conflicting nodes (for example, mcp2515) exist, ensure those are set to status = "disabled"(reference).
After boot, verify the presence of /dev/spidev0.0. Its absence means the SPI driver is not loaded or initialized properly.
Also check /sys/bus/spi/devices/ for registered devices.
Boot Logs
Use dmesg | grep spi or check the entire dmesg output to spot any SPI-related or device tree parsing errors. Errors like “unable to initialize controller” or “probe failed” can give strong hints.
Compare the boot logs between the boards that work and those that hang to find differences.
Hardware Revision Difference
Double-check the production batch or PCB revision of the problematic boards. Although you said they are all v1.1A, subtle component differences or soldering defects can sometimes cause issues that only impact certain kernel/device tree combinations.
However, since the boards boot with Thud, this tends to rule out hardware damage and points more towards a software-side issue.
Test with Device Tree Disabling SPI
You mentioned you built a device tree with SPI disabled and still had the hang. This suggests the SPI controller’s configuration or something else in the hardware initialization for this peripheral is hanging.
Try a device tree with all optional peripherals disabled (SPI, CAN, UART extras) to see if the problem persists. This can help isolate if SPI initialization is truly the cause.
Compare U-Boot Environment
Save and print the printenv settings from U-Boot in a working and non-working scenario to check for subtle differences in boot arguments, overlays, or device tree paths.
Kernel Version Compatibility
Some kernel versions in Kirkstone may expose timing or initialization behaviors not present in Thud. Double-check for known issues with SPI and iMX6ULL for your specific kernel release in the community.
If you can provide a relevant snippet of dmesg around the SPI initialization, or the diff of your device tree, I can offer more specific guidance.
Can you tell me a bit more about your setup? You said you are using “Kirkstone OS”. Do you mean you are building a Yocto image for your board with the kirkstone release? I suppose you are not using Torizon OS. Are you building your image with our BSP layer?
Let me know, and I can help you to investigate further.
