ANALYSIS SUMMARY - Board A page-cache integrity detector
AXON V0.2, 8 GiB LPDDR4X, no ECC, kernel 6.1.75
Source: archived detector log, 4,412 passes across 16 service starts (~3 days)
========================================================================

1. HOW MUCH WAS CORRUPTED
------------------------------------------------------------------------
  distinct physical frames implicated      : 150
  distinct (frame, file-page) events       : 172
  bad bytes counted by the detector        : 2,045
  of those, printed as examples            : 664  (32.5% - see the cap note in section 5)
  total RAM ever implicated                : 600 KiB = 0.0074% of 7,926 MiB

  A page flagged as persistently wrong is re-flagged on every later pass, so the
  raw count of flagged passes (4,380 of 4,412) massively overstates the number of
  independent events. 172 is the honest number.

2. WHERE - PHYSICAL LOCALISATION
------------------------------------------------------------------------
  window containing 148 of 150 frames : 0x1c40a7000 .. 0x1c6a99000
  window size                        : 41.95 MiB = 0.529% of RAM
  outliers                           : 0x1d7d7c000, 0x1d7d7d000

  /proc/iomem System RAM banks:
    00200000-efffffff     3,838 MiB
    100000000-1ffffffff   4,096 MiB   <- every faulting frame is in this bank
    2f0000000-2ffffffff     256 MiB
  offset into that bank: 3137 - 3179 MiB of 4,096 MiB

  CONTROL (04-pagecache-control.txt) - without this the clustering means nothing,
  because it could simply be where the allocator puts this file's page cache:
    page cache under test spans          : 8,072 MiB of physical address space
    fraction of it inside the window     : 0.161%  (423 of 262,144 pages)
    frames expected inside if uniform    : 0.242
    frames observed inside               : 148
    enrichment                           : 611x
    P(>=148 of 150 landing there by luck): ~1e-409

3. THE FRAME IS THE DEFECT, NOT THE DATA
------------------------------------------------------------------------
  frames that corrupted more than one distinct file page: 20
     18 frame(s) corrupted 2 different file pages
      2 frame(s) corrupted 3 different file pages

  worked examples - same frame, unrelated file offsets:
    0x1c4999000  ->  file pages 199827, 382896, 1013034
    0x1c6658000  ->  file pages 407688, 606678, 779631
    0x1c40a7000  ->  file pages 29937, 716225
    0x1c4998000  ->  file pages 97207, 382895

  No file page was ever corrupted in two different frames (172 events, 172 distinct
  file pages). Corruption follows the frame, never the data.

4. SHAPE OF THE DAMAGE
------------------------------------------------------------------------
     50 run(s) of 1 consecutive 4 KiB frame(s)
     50 run(s) of 2 consecutive 4 KiB frame(s)
  -> the unit of damage is one 4 KiB frame or an 8 KiB contiguous pair. Never larger.

  bad bytes per event: min 1, median 3, max 63
    85 of 172 events are 1-2 bytes; 31 are 30 or more.

  bit-flip direction over the 664 distinct printed bytes:
    0 -> 1  (bits SET)     :   1174  (96.07%)
    1 -> 0  (bits CLEARED) :     48  (3.93%)
    bytes reading back numerically GREATER than truth: 97.0%

  per-bit - spread across all eight, so NOT one stuck DQ line:
    bit 0:  set  139   clear   6   (96% set)
    bit 1:  set  134   clear   8   (94% set)
    bit 2:  set  160   clear   4   (98% set)
    bit 3:  set  165   clear   5   (97% set)
    bit 4:  set  123   clear   5   (96% set)
    bit 5:  set  124   clear   9   (93% set)
    bit 6:  set  169   clear   7   (96% set)
    bit 7:  set  160   clear   4   (98% set)

  Strongly biased toward SETTING bits. Board B's faults are the exact opposite -
  pure clears - which is what two independent device faults would look like, rather
  than one shared design issue.

5. BURST ALIGNMENT - THE STRONGEST SINGLE CLUE
------------------------------------------------------------------------
  RK3588 drives 16-bit LPDDR4X channels; one BL16 burst is exactly 32 bytes.
  Byte offset mod 32, over distinct printed bytes:
    off%32 = 8      362
    off%32 = 10     290
    off%32 = 12       6
    off%32 = 14       6

  Every one is even, and all four values sit in beats 4-7 of the 16-beat burst.
  Not one bad byte at an odd offset; none in beats 0-3 or 8-15. In other words:
  always the LOW byte of the 16-bit word, never the high byte, and only in the
  middle of the burst.

  LIMIT, STATED DELIBERATELY: the detector prints at most 6 example bytes per page
  per pass, so this histogram covers 664 of 2,045 bad bytes (32%), not all of them.
  It computes an unbiased histogram at exit, but the service was always killed
  rather than exiting, so that line never printed. That is our defect, not the
  platform's, and it is why this is a strong pattern rather than a proof.
  The repeat-weighted view (207,173 byte reports) has the same shape, so the two
  independent weightings agree.
