lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <175501095338.74722.11604545949710100799@localhost>
Date: Tue, 12 Aug 2025 17:02:33 +0200
From: Stefan Klug <stefan.klug@...asonboard.com>
To: Krzysztof Hałasa <khalasa@...p.pl>, Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Dafna Hirschfeld <dafna@...tmail.com>, Heiko Stuebner <heiko@...ech.de>, Paul Elder <paul.elder@...asonboard.com>, Jacopo Mondi <jacopo.mondi@...asonboard.com>, Ondrej Jirman <megi@....cz>, linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: FYI: i.MX8MP ISP (RKISP1) MI registers corruption: resolved

Hi Krzysztof, hi Laurent,

Quoting Laurent Pinchart (2025-08-12 12:32:43)
> Hi Krzysztof,
> 
> On Tue, Aug 12, 2025 at 07:54:46AM +0200, Krzysztof Hałasa wrote:
> > Hi Stefan et al,
> > 
> > BTW I've added Lucas Stach and Shawn Guo to "Cc" list.
> > 
> > The problem is the CPU core power supply voltage :-)
> 
> Ah, the dreadful overdrive mode.
> 
> > - while the reference manual specifies the max ISP and MEDIA clocks at
> >   500 MHz, the datasheets show this requires the "overdrive" mode =
> >   increased CPU power supply voltage. In "normal" mode the ISPs are
> >   limited to 400 MHz (there are other limits, too).
> > 
> > - I've tried lowering the clock rate after booting the systems (with
> >   a CCM register write), but it didn't fix the problem. I guess some
> >   reset logic is affected here, and the (lower) clock rate must be set
> >   right from the start, in the DT.
> 
> That's interesting. I wouldn't have expected that.
> 
> > - anyway, lowering the frequencies of ISP and MEDIA root clocks fixes
> >   the ISP2 MI corruption. I'm currently investigating PMIC settings
> >   (both my Compulab and SolidRun modules use PCA9450C PMICs), so perhaps
> >   I'll be able to use the higher 500 MHz clocks. It doesn't matter much,
> >   though.
> > 
> > - the question is if we should lower the clocks in the main imx8mp.dtsi
> >   DT file, or the overdrive mode should stay there, and the changes
> >   should be made to the individual board files, or maybe the U-Boot
> >   configs (PMIC output voltages) should be changed etc.
> 
> I think it would make sense to lower the default clock frequencies, and
> provide an overlay to enable overdrive mode.
> 
> It's also interesting that the issue only affected the second ISP, as
> the first one should also be limited to 400 MHz in normal mode.

I support that. As a side note, there is already imx8mp-nominal.dtsi
which is only used by one board. That dtsi also uses the
fsl,operating-mode property which enables additional clock checks. So I
ask myself if the default imx8mp.dtsi should specify overdrive mode, or
if we should add a imx8mp-overdrive.dtsi (then we should possibly rename
them to imx8mp-mode-xxx.dtsi so that they sit side by side) to make it
easier to create overlays for both cases. 

Best regards,
Stefan

> 
> -- 
> Regards,
> 
> Laurent Pinchart

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ