Hi all On Wed, Nov 12, 2025 at 10:57 AM Emanuele Ghidoli <[email protected]> wrote: > > > > On 12/11/2025 09:16, Ye Li wrote: > > > > > > On 11/11/2025 9:47 PM, Fabio Estevam wrote: > >> Hi Emanuele, > >> > >> On Thu, Nov 6, 2025 at 7:22 AM Emanuele Ghidoli > >> <[email protected]> wrote: > >> > >>> Hi Fabio, Ye, > >>> > >>> At Toradex we have been struggling since quite some time (back to 2018) > >>> with > >> > >> Does this problem only affect early i.MX6ULL silicon samples? > > Hi Emanuele, > > > > I have same question as Fabio. Are these samples are early? Do you know > > the time of receiving these sample? And could you show the part number > > printed > > on the chip. > It could take a little to answer to the first two question. I can say that the > SoM I'm using to validate the patch was assembled in September 2021. Let me > know if this information are needed giving that I can report the marking on > the chip: > MCIMX6Y2CVM08AB CTDQ2107 1N70S CHINA QGDQCTA > > > > > >> > >>> the temperature readings and the thermal shutdown behavior on i.MX6ULL. > >>> The > >>> issue we observed is that the thermal shutdown seems to trigger too early. > >>> > >>> I have investigated the history around this topic and verified some > >>> internal > >>> notes in our bug tracker. With this revert applied, and on the devices we > >>> have > >>> (all trimmed with value 0), the reported temperature increases by about > >>> 10 °C > >>> compared to before the revert. The absolute accuracy of the readout is > >>> questionable: for example, on a device kept at around 20 °C, the > >>> temperature > >>> readout was ~19 °C before the revert, and ~31 °C after the revert. > >>> > >>> Consider that for devices with fuse value of 6, there is a -10 degrees > >>> offset > >>> after this revert (so, the other way around). > >>> > >>> I understand that for Sven this revert improves stability during large XZ > >>> decompression in userspace for few devices, but for us it means that the > >>> thermal shutdown happens roughly 10 °C earlier, which is a serious issue > >>> in > >>> our case. > >>> > >>> I would kindly ask NXP to double-check how these devices were trimmed. My > >>> gut > >>> feeling is that there might be an inconsistency, either the trimming > >>> scheme is > >>> not backward-compatible (e.g. old and new devices behave differently, and > >>> the > >>> code should cope, I don't know how, with this), or this patch must be > >>> reverted > >>> (because introduces a regression). > >> > >> Peng/Ye Li, > >> > >> How does NXP suggest we handle this? Were the early i.MX6ULL parts > >> incorrectly fused? > > I need to discuss it internally, will feedback you later. > > > >> > >> Can the fuse be read and dynamically adjusted? > >> > > The fuse is locked by MEM_TRIM_LOCK. Emanuele, can you help to read it by > > "fuse read 0 0 1". > Colibri iMX6ULL # fuse read 0 0 1 > Reading bank 0: > > Word 0x00000000: 00320003 > Colibri iMX6ULL # fuse read 1 0 1 > Reading bank 1: > > Word 0x00000000: 00000080 >
As is clear this problem was the same we had some months ago, so we are on the same page with Emanuele Michael > Kind regards, > Emanuele > > > > > Best regards, > > Ye Li > >> Please advise, thanks. > > > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 [email protected] __________________________________ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 [email protected] www.amarulasolutions.com
