Hi Michael, Emanuele,
On 11/12/2025 6:07 PM, Michael Nazzareno Trimarchi wrote:
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
Can you help to measure the VDD_ARM_CAP and VDD_SOC_CAP on your devices
with high temperature read issue, when REFTOP_VBGADJ is set to 3'b000
and 3'b110 respectively. Provide the measured voltage and target voltage.
And please read the Unique ID fuse of this device by "fuse read 0 1 2".
Best regards,
Ye Li
Kind regards,
Emanuele
Best regards,
Ye Li
Please advise, thanks.
