linux-kernel - Re: FYI: i.MX8MP ISP (RKISP1) MI registers corruption

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: <m38qknx939.fsf@t19.piap.pl>
Date: Thu, 17 Jul 2025 15:03:54 +0200
From: Krzysztof Hałasa <khalasa@...p.pl>
To: Dafna Hirschfeld <dafna@...tmail.com>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.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

> The "reference" (NXP) VVCam driver simply does the operations twice
> (i.e., reads twice with the first result discarded, and writes twice).
> This fixes the problem on most accesses, but the problems still persist.

It appears the corruptions are quite frequent, though.
Using "ldp qXX, qYY, [x0]" (2 * 128-bit load pair) I get results like
this (each data row is a result of a single ldp):

addr:  32E21400 32E21404 32E21408 32E2140C 32E21410 32E21414 32E21418 32E2141C
--------------------------------------------------------------------------------
values 3D000007       20 3C300000   1FA400        0        0        0 3C380000 count 99993097
values        0       20 3C300000   1FA400        0        0        0 3C380000 count 5930
values    7E900       20 3C300000   1FA400        0        0        0 3C380000 count 338
values    FD200       20 3C300000   1FA400        0        0        0 3C380000 count 223
values 3C380000       20 3C300000   1FA400        0        0        0 3C380000 count 220
values       40       20 3C300000   1FA400        0        0        0 3C380000 count 192

The valid value (in 0x32E21400 register) is 3D000007 only, the rest are
corruptions: ca. 6 errors per 100k reads. With other registers, 15 errors
per 100k reads etc.

I also got this:
addr:  32E213F0 32E213F4 32E213F8 32E213FC 32E21400 32E21404 32E21408 32E2140C
--------------------------------------------------------------------------------
values        0        0        0        0 3D000007       20 3C300000   1FA400 count 98638773
values        0        0        0        0        0       20 3C300000   1FA400 count 1330227
values        0        0        0        0       40       20 3C300000   1FA400 count 3721
values        0        0        0        0 3C380000       20 3C300000   1FA400 count 314
values        0        0        0        0    7E900       20 3C300000   1FA400 count 572
values        0        0        0        0    FD200       20 3C300000   1FA400 count 428
values        0        0        0        0    4C010       20 3C300000   1FA400 count 25965

which is ca. 14 errors per 1k reads, though maybe it's special -
non-MI/MI boundary (at 0x32E21400), reserved addresses (0x32E213Fx) etc.

> The problems show themselves maybe in 5% or 10% of boots.

Well, now it appears more like 20%: e.g. in 41 system runs (soft reboots
only, no power-downs), I got problems 8 times.

Obviously I can post the tester source if anyone is interested.


Generally ISP MI register read accesses which can be corrupted are:
- first 32 bits read in a given transfer, and additionally
- every 32 bits on a 32-byte boundary (addresses 0x....00, ...20 etc.).

This means, in practice, on i.MX8MP only, RKISP1_CIF_MI_CTRL and
RKISP1_CIF_MI_MP_CB_SIZE_INIT (with the workaround).

What is this 32-byte boundary?

Writing is a bigger problem, though.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa