[PATCH] imx: Revert "imx: mx6ull: fix REFTOP_VBGADJ setting" and fix comments

[Michael Nazzareno Trimarchi]

Hi all

On Wed, Nov 12, 2025 at 10:57 AM Emanuele Ghidoli
<ghidoliemanuele at gmail.com> 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
> >> <ghidoliemanuele at gmail.com> 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
michael at amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info at amarulasolutions.com
www.amarulasolutions.com