Hi,
We have been investigating an issue using i.MX8M-MINI DDR4 configuration with which is related to using USB Hub when USB devices are connected via Hub. In specific, we tested with USB Headphones
Without USB Hub: Audio plays with popping noise,
With USB Hub: Audio will not play, USB hub resets with errors:
[ 119.283894] retire_capture_urb: 4 callbacks suppressed
[ 119.903969] usb 1-1.3: reset full-speed USB device number 4 using ci_hdrc
After long investigation of our HW/SW and NXP’s i.MX8MM DDR4 EVK board we have narrowed the cause of the issues to be the DDR4 register settings and in specific The “Low Priority Read CAM Register 1 (PERFLPR1)” register.
While in RPA tool provided by NXP MX8M_Mini_DDR4_RPA_v14.xlsx (and in our code as well) the value of this register is set to “0x7300b473”,
In imx8mm_evk board Uboot setting this register is not configured and has been omitted:
The register is described in the reference manual under section: 9.2.3.1.78 Low Priority Read CAM Register 1 (PERFLPR1). According to RM value after Reset is 0x0F00007F.
It seems there are additional registers settings which differ between RPA tool/imx8mm_val
settings vs. the mx8mm_evk settings:
NXP imx8mm_val settings:
mx8mm_evk settings:
We follow the RPA Tool settings. Can you please assist us in listing the specific registers as well as their corresponding values which should be modified from the RPA Tool default output. Please also list the registers which should be omitted from code such as Low Priority Read CAM Register 1 (PERFLPR) we have found.
Thank you for your support,
Aviad
解決済! 解決策の投稿を見る。
Hi Aviad,
thanks for the confirmation.
I discussed the issue with the BSP team and their feedback was that the BSP was later updated to use the default QoS settings in case of the 8MMini DDR4 EVK board since USB performance issues were identified on this board with the customized settings. This corresponds to your observations. Unfortunately, this update did not propagate to the RPA yet. That is why you see additional settings in the timing file generated from the RPA, which are missing in the code in the BSP. See the related diff from the update:
- { 0x3d400250, 0x317d1a07 },
- { 0x3d400254, 0xf },
- { 0x3d40025c, 0x2a001b76 },
- { 0x3d400264, 0x7300b473 },
- { 0x3d40026c, 0x30000e06 },
- { 0x3d400300, 0x14 },
- { 0x3d400304, 0x0 },
- { 0x3d40030c, 0x0 },
- { 0x3d400320, 0x1 },
- { 0x3d40036c, 0x10 },
- { 0x3d400400, 0x100 },
- { 0x3d400404, 0x13193 },
- { 0x3d400408, 0x6096 },
- { 0x3d400490, 0x1 },
- { 0x3d400494, 0x2000c00 },
- { 0x3d400498, 0x3c00db },
- { 0x3d40049c, 0x100009 },
- { 0x3d4004a0, 0x2 },
If you encounter similar differences between the RPA and the BSP configuration in the future, please report this like you did on this occasion. It is our goal to keep both in sync however, sometimes an update gets overlooked.
To comment in general on the settings of the QoS registers, the settings are determined and optimized manually by the BSP team. Therefore, we have no additional (deterministic) guidance beyond the register descriptions in the reference manual. In general, it is not recommended to modify the values, since they are considered as optimized.
In this case, please modify your timing file as outlined above. The RPA is going to be updated in the same way.
Best Regards,
Jan
Hi Aviad,
could you please confirm if my understanding is correct?
You encounter the issue if you set PERFLPR1 to 0x7300b473 and if you leave it at the reset value (0x0F00007F), the issue is not reproduced anymore?
Thanks.
Best Regards,
Jan
Hi,
Your understanding is correct, once we leave this register undefined and default out of reset value 0x0F00007F is read then USB issue does not occur.
Aviad
Hi Aviad,
thanks for the confirmation.
I discussed the issue with the BSP team and their feedback was that the BSP was later updated to use the default QoS settings in case of the 8MMini DDR4 EVK board since USB performance issues were identified on this board with the customized settings. This corresponds to your observations. Unfortunately, this update did not propagate to the RPA yet. That is why you see additional settings in the timing file generated from the RPA, which are missing in the code in the BSP. See the related diff from the update:
- { 0x3d400250, 0x317d1a07 },
- { 0x3d400254, 0xf },
- { 0x3d40025c, 0x2a001b76 },
- { 0x3d400264, 0x7300b473 },
- { 0x3d40026c, 0x30000e06 },
- { 0x3d400300, 0x14 },
- { 0x3d400304, 0x0 },
- { 0x3d40030c, 0x0 },
- { 0x3d400320, 0x1 },
- { 0x3d40036c, 0x10 },
- { 0x3d400400, 0x100 },
- { 0x3d400404, 0x13193 },
- { 0x3d400408, 0x6096 },
- { 0x3d400490, 0x1 },
- { 0x3d400494, 0x2000c00 },
- { 0x3d400498, 0x3c00db },
- { 0x3d40049c, 0x100009 },
- { 0x3d4004a0, 0x2 },
If you encounter similar differences between the RPA and the BSP configuration in the future, please report this like you did on this occasion. It is our goal to keep both in sync however, sometimes an update gets overlooked.
To comment in general on the settings of the QoS registers, the settings are determined and optimized manually by the BSP team. Therefore, we have no additional (deterministic) guidance beyond the register descriptions in the reference manual. In general, it is not recommended to modify the values, since they are considered as optimized.
In this case, please modify your timing file as outlined above. The RPA is going to be updated in the same way.
Best Regards,
Jan
Hi Jan,
I appreciate you fast and thorough response on this.
We will make the necessary updates in our BSP.
Thank you,
Aviad
Hi Aviad,
I will check internally and get back to you once I gather the feedback.
Best Regards,
Jan
@jan_spurek can you help here?