Hi,
I encounter issue on our imx8mm board when resume from suspend. Comparing to imx8mm-evk, we use lpddr4: FORESEE_LPDDR4X_NCLDXC1MJ512M32. both hardware design and software code are levelage from imx8mm-evk board. our software branch is yocto zeus.
Operation:
To enter suspend: echo mem > /sys/power/state
To resume: press power button.
Findings:
1. system works stable in active power state with 1500M, 1200M and 800M DDR frequency. whole day memory stress test passed also.
2. no any console output when resume with 1500M DDR frequency. Looks heavy error cause CPU execute error codes.
3. system crashes at random location when resume with 1200M DDR frequency. Looks less error cause CPU get error data and kernel report panic.
Debug:
1. Download our u-boot and Image/dtb image to imx8mm-evk board (works with 1500M DDR frequency), imx8mm-evk board can suspend/resume.
2. Download imx8mm-evk board u-boot and Image/dtb image (the image works with 1500M DDR frequency), to our board, our board also can not resume from suspend.
Point:
1. As DDR works fine under active power state, it should not be the issue of LPDDR4 chip timing, our board timing and DDR configuration.
2. It should be some difference between active power state and the state switch from suspend to resume. refer "i.MX_Reference_Manual.pdf" 2.5.1.2, to save power, soc core will do some action such as change the drive strength of DDR pad before enter suspend state and recover it before resume. Is it caused by the change to DDR is not well recovered by soc core before resume and our LPDDR4 timing margin is nallow as well?
1. Our LPDDR4 timing margin is nallow, which can explain why imx8mm-evk board can resume while our board can not resume with 1500M frequency.
2. When our board works with 800M DDR frequency, which provide more timing margin so system can resume also.
3. SOC core does not recover DDR well, which can explain why our board with 1500M DDR frequency can work in active state but can not work during resume.
Questions:
1. Is my point about the cause reasonable?
2. What we can do to help for this issue?
3. What NXP can do to help for this issue?
Best regards.
Johnson