We’re having a boot issue with the Verdin iMX8MP v1.1B (00631101) SOMs using the same custom image that we’ve been using without issues on the Verdin iMX8MP v1.1A (00631100) SOMs. Our custom Torizon image version is 6.5.0. In order to get better info on the issue I ran some tests using downloaded TorizonCore images rather than our custom image. I ran the images through TorizonCore builder and added the verdin-imx8mp_hmp_overlay.dts overlay from device-tree-overlays.git. I tested v6.5.0, v6.6.1, and v6.7.0 with v1.1A and v1.1B SOMs. The v1.1B SOMs will not boot with any of the kernel versions. The v1.1A SOMs will boot with all kernel versions. The 6.5.0 image boot fails at the following point:
Given your observations here it would appear there is some difference between the 1.1A and 1.1B hardware revisions that cause your boot to fail.
At the moment I don’t have these specific hardware revisions that you do, so I can’t attempt a reproduction at this time. In the meantime could you try some tests and answer some questions for me.
First of all in your bootcmd variable I see you run m4boot then run bootcmd_mmc2. From your logs I can see in both the 1.1B and 1.1A cases it failed to load /ostree/deploy/torizon/var/pwmcontroller.bin, is that expected for you?
Next, could you try and see if this same behavior happens with our reference BSP images? Torizon OS is based on top of our BSP, so it would help narrow down the issue. If the issue still happens on our reference BSP it means the issue is inherent with our BSP itself, if not then it must be something specific about Torizon OS.
We copy the M7 binary to /var in a later configuration step so the failed to load message is expected. The 1.1A SOM will run the pwmcontroller.bin binary on the M7 without issues.
I repeated the tests using Reference-Minimal-Image_6.5.0+build+9. I first booted the image and modified overlays.txt to include the verdin-imx8mp_hmp_overlay.dtbo overlay. The u-boot environment variables are set as follows:
The behavior of the two SOM versions is the same. The v1.1A SOM boots without issues and ran the M7 binary after I copied it over. I’m seeing the same kernel paging request error at line 396 on the v1.1B boot log. Here are both boot logs:
Given that you were able to see the same issue with 1.1B on our reference BSP, it would appear the issue is somewhere in our base BSP. That does help narrow things by a bit.
Let me report this to our BSP team and see if something can be discovered. Thank you for reporting this possible issue to us.
Considering it’s the same binary that’s being loaded in both cases, I can’t explain the different behavior between the two SoM versions.
Could you share the pwmcontroller.bin file with us? It would be even better if you could share the source code as well, I think it can help reproduce the issue on our end. You can share privately if you want.
I also noticed that the boot failure is dependent on setting m4boot. It will fail with m4boot set while only booting the kernel. It will boot fine once m4boot is cleared.
Our team is still investigating and analyzing the issue you brought up here. Our team was able to easily reproduce this on 1.1B as you said. On your 1.1B units you can try the following interim solution by executing the following in U-Boot:
Verdin iMX8MP # mw.w 0x550ff000 0 64
This forces the memory region here to be set to 0 which puts it in a good state to work with the M7 core.
I ran the test you suggested on a v1.1B with the Verdin-iMX8MP_Reference-Minimal-Image-Tezi_6.5.0+build.9 image and hello_world.bin. After executing mw.w 0x550ff000 0 64 the kernel boots with the M7 normally.
Thank you for confirming the interim solution. Our team is still working on a final solution for this. We’ll try and inform you once we have something.
