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