This topic is a continuation from this previous one:
My goal is to setup the cortex M4 to read SPI and write the samples to a memory location where Linux can access them. After the previous topic I tried building and running some different examples from the TI SDK. I was able to run hello_world, rpmsg and a custom one where the M4 core could write a value to memory and linux could read it. So far so good.
Now I tried to run the spi loopback example. I was able to build this example with the changes discussed in the topic mentioned above and I could run this example on the M4 core. In the terminal I could see the output which stated that the loopback was successful. I am using SPI0 with the M4 and I made sure that SPI0 is disabled in the devicetree so that there is no conflict with linux. Now for the problem: I am no longer able to boot linux. Below is the output of the boot log
Hit any key to stop autoboot: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
973 bytes read in 9 ms (105.5 KiB/s)
## Executing script at 90280000
6641 bytes read in 10 ms (648.4 KiB/s)
69774 bytes read in 11 ms (6 MiB/s)
111 bytes read in 10 ms (10.7 KiB/s)
Working FDT set to 90200000
Applying Overlay: verdin-am62_dsi-to-hdmi_overlay.dtbo
3050 bytes read in 10 ms (297.9 KiB/s)
Applying Overlay: verdin-am62_spidev_overlay.dtbo
560 bytes read in 11 ms (48.8 KiB/s)
Applying Overlay: verdin-am62_hmp_overlay.dtbo
1848 bytes read in 10 ms (179.7 KiB/s)
10991337 bytes read in 117 ms (89.6 MiB/s)
6224824 bytes read in 71 ms (83.6 MiB/s)
Uncompressing Kernel Image
## Flattened Device Tree blob at 90200000
Booting using the fdt blob at 0x90200000
Working FDT set to 90200000
Loading Ramdisk to 988f3000, end 98ee2bb8 ... OK
Loading Device Tree to 00000000988be000, end 00000000988f2fff ... OK
Working FDT set to 988be000
Starting kernel ...
[ 1.035578] ti-sci-clk 44043000.system-controller:clock-controller: recalc-rate failed for dev=81, clk=20, ret=-19
[ 1.125059] pca953x 1-0021: failed writing register
[ 1.469968] mdio_bus 8000f00.mdio: MDIO device at address 7 is missing.
[ 1.482102] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
[ 1.497943] ti-sci-clk 44043000.system-controller:clock-controller: is_prepared failed for dev=81, clk=20, ret=-19
Starting version 250.5+
[ 6.228065] ina2xx 1-0040: error configuring the device: -121
[ 6.456382] nau8822 1-001a: Failed to issue reset: -121
[ 7.905051] k3-m4-rproc 5000000.m4fss: configured M4 for remoteproc mode
Here the boot hangs and starts over after some time. I have two questions about this.
How can I temporarily disable the M4 auto-boot so that the spi image does not get loaded
What would be the solution for this problem? @ lucas_az.tx, I believe you had a similar problem with the hello_world image (which worked normally for me), do you have an idea what could cause this?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Based on the context provided, here are the answers to your questions:
Disabling M4 Auto-Boot:
To temporarily disable the M4 auto-boot, you may need to modify the device tree or bootloader settings to prevent the M4 from loading its image during the Linux boot process. This can involve setting specific flags or parameters in the bootloader configuration. You might need to look into the U-Boot environment variables or the device tree to ensure that the M4 is not automatically started during the boot process.
Solution for the Boot Problem:
The boot issue you’re experiencing may be due to conflicts or misconfigurations in the device tree or hardware setup. Here are some steps you can take to address the problem:
Device Tree Configuration: Ensure that the SPI device is correctly set up in the device tree and that there are no conflicts with the Linux kernel. Since you mentioned disabling SPI0 in the device tree, double-check that this change is correctly applied.
Clock Configuration: Verify the clock configurations to ensure that all required devices are properly initialized before booting Linux. The error recalc-rate failed for dev=81, clk=20 suggests a potential issue with clock settings.
Investigate Boot Log Errors: Look into the specific errors in the boot log, such as the missing MDIO device and failed register writes, to identify potential hardware or configuration issues. These errors might indicate that certain devices are not being initialized correctly or that there are issues with the hardware setup.
By addressing these areas, you may be able to resolve the boot hanging issue and restore normal functionality. If the problem persists, further investigation into the specific hardware and software configurations may be necessary.
Please, also check if these links can help you solve your problem:
Sorry for the delayed response, I was running some tests.
When it occurred to me, I was not able to access Cortex A (Linux) terminal, so I had to reinstall the image using Toradex Easy Installer.
I could not find what was causing the error, although I only had it when I tried to build m4fss0-0_nortos. Are you building m4fss0-0_freertos or m4fss0-0_nortos?
That said, I would recommend using TI’s forum since they have the expertise that would help/guide you through the debug.
I am building nortos, but this has not been an issue for me with the other examples that I’ve build. I will try to build this with freertos, but the fact that we both have issues with nortos on different examples might indicate a larger bug or error somewhere.
I have submitted a request via TI since I cannot post directly on their forum because I’m a researcher linked to a university. I hope to receive an answer soon, but I don’t have the best experiences from previous question via this way. I’ll try to give an update if some kind of solution comes up.
Best regards
Edit: I got a response back from TI: " TI does not offer ongoing support for this hardware. For support, contact Toradex Inc"
Were you able to build it with freertos? Did it work?
About the issue, as we didn’t create the examples (Toradex does not maintain the MCU+SDK), debugging it can be difficult and time-consuming. For such a task, we can recommend partners that can evaluate the issue and help you to solve it.
Would you be interested in contacting a partner of ours?
Due to some other projects, I have not yet tried building it with freertos.
For the moment we have also decided to use the IMX8-mini in our project instead of the AM62, because we have more experience with the IMX architecture and the documentation for this board looks more complete.
This thread can be closed for now, I will make an update once I have been able to test with freertos.