Hi Alexander,
--- a/board/tq/tqma6/tqma6q.cfg +++ b/board/tq/tqma6/tqma6q.cfg @@ -36,7 +36,7 @@ DATA 4, MX6_IOM_DRAM_SDCLK_1, 0x00008030
DATA 4, MX6_IOM_DRAM_CAS, 0x00008030 DATA 4, MX6_IOM_DRAM_RAS, 0x00008030 DATA 4, MX6_IOM_GRP_ADDDS, 0x00000030
-DATA 4, MX6_IOM_DRAM_RESET, 0x000C3030 +DATA 4, MX6_IOM_DRAM_RESET, 0x00003030
Thank you for pointing this out. Originally this error came from an older/ancient reference manual. Sorry that we missed to bring this upstream. We will send the changes for DCD data in the next days.
No problem, I'm glad this can now be solved. By any chance, could you point to the relevant location of the manual (ddr or imx6 ?) explaining what this is actually about? Because I failed to bring any real explanation to my observations so far.
It's a bit hidden but the comment above that list indicates these settings are iomuxc configurations. In this case the register IOMUXC_SW_PAD_CTL_PAD_DRAM_RESET. See i.MX6Q RM Rev.6 05/2020 section 36.4.347. Your patch configures the field "DDR Select Field" from reserved3 to DDR3_LPDDR2. It seems this field has to be set to 0 in every case.
Yes, that's also what I get from reading the iMX6Q manual. But I'm sorry I don't understand why a runtime change of a reset pin configuration can be so impacting. It's not like it only affects the power-on sequence because I can reproduce the strange QoS/NIC issues with a devmem once the kernel has started. I believe there is a bit more than just a pad configuration behind this field.
Thanks, Miquèl