We are developing a custom board based on the i.MX8MMQ CPU and a Micron 2GB LPDDR4 RAM module. Main inspiration for the design was taken from the NXP IMX8MM-EVK board For our application we need to make sure that suspend mode on the board operates correctly.
For our system we use forked nxp 5.4.70 Linux Kernel source and nxp 2020.04 u-boot source
The problem starts after the system finishes booting. After a short period of time, the current consumption of the board drops from 300mA to around 170mA and no signs of life are demonstrated from the board. In the other thread I found that disabling the 'busfreq' node in the device-tree solves the problem of system hanging, but in return makes RAM frequency scaling unavailable. And it worked the same way as I tested it. After some debugging of the issue, I found that the problem occurs after executing the following lines of code in the "drivers/soc/imx/busfreq-imx8mq.c" driver
/*
* check to see if we need to got from low bus
* freq mode to audio bus freq mode.
* If so, the change needs to be done immediately.
*/
if (audio_bus_count && low_bus_freq_mode){
reduce_bus_freq();
} else {
schedule_delayed_work(&low_bus_freq_handler,
usecs_to_jiffies(1000000));
}
Namely the 'else' statement, after reading through the source code, I found out that the 'low_bus_freq_handler' uses the same function 'reduce_bus_freq()' but via some intermediary handler. After changing the 'schedule_delayed_work()' function to simply 'reduce_bus_freq()' I got DDR frequency scaling operating correctly, however this case didn't look good to me
When I send the board to a Suspend mode with
echo enabled > /sys/class/tty/ttymxc1/power/wakeup
echo mem > /sys/power/state
The PMIC changes its registers to a correct position and disables VDD_DRAM, VDD_ARM, VDD_GPU and VDD_VPU as it should based on the datasheet, meanwhile current consumption falls from around 300mA to around 50-70mA. After triggering an interrupt from the tty, the current consumption raises by around 10mA for some period of time, powers get restored on the disabled ports, but the system doesn't return to a normal state until the reboot
We have Technexion PICO-PI boards and to double-check the software operation of the system the same system was booted on the PICO-PI board and there Suspend operates correctly, which in my understanding narrows down the issue to being bound to a hardware implementation or timing. I tried using the Memory tool provided by NXP, but while using the timings generated by the program, board didn't even boot.
Are there any additional quirks we need to know while designing the hardware DRAM system on the board or using the timings file generated by the software?
What worked on our WIP board is soldering a parallel resistor between the XTALI and XTALO lines. After that re-enabling of the frequency generator started working fine. In this board we also used 100mW oscillator, which is smaller than recommended by the datasheet. It was placed due to unavailability of recommended oscillators in similar casing, now they are available, so we are using them for second revision of the board
What worked on our WIP board is soldering a parallel resistor between the XTALI and XTALO lines. After that re-enabling of the frequency generator started working fine. In this board we also used 100mW oscillator, which is smaller than recommended by the datasheet. It was placed due to unavailability of recommended oscillators in similar casing, now they are available, so we are using them for second revision of the board
I agree with the idea to check the hardware and the software.
Please check the hardware design guide for iMX8 and follow the steps to generate the DDR timing is a little confusing but for custom, boards are necessary to do it to ensure better performance and functionality in your system.
I check in my iMX8MM-EVK and works fine, I think is a minimal problem if we are referring to software.
First of all, thank you for you reply. I once again tried to tinker with the timing structure generated by the DDR Tool. Now I managed to boot the board with the timings provided by the software. Suspend mode, however, didn't work for me anyway. I'll try to do more experiments and search on the matter and write out when I discover what the problem was
Application of calibrated timings for DDR, generated by DDR Tool fixed the problem with the driver described in the original post. Suspend mode fix is still being searched for
After some investigation we decided to check the operation of the 24MHz oscillator with the oscilloscope. In our board we use the ECS-240-10-37B2-CWN-TR oscillator. On the XTALOUT line we didn't see frequency generated after the suspend wake interrupt sent. However, after the line is released from the oscilloscope, device wakes up from Suspend after short period of time and the frequency can be observed on the line being generated correctly.
Given the observations, we think that the reasons may be in the absence of feedback resistor near the oscillator and/or in the hardware placement of oscillator on the back side of the board relatively to the CPU, which is dictated by the area constraints of the board. If you have any further suggestions about the matter, would greatly appreciate it
