Reading the last bytes of memory (sometimes) SErrors

This is a bit of a weird one, but I’m using vanilla m1n1 and can reproduce this at will. Here’s a log that demonstrates what’s going on:

TTY> CPU init... CPU: M1 Icestorm
TTY> 
TTY> boot_args at 0x807f38000
TTY>   revision:     2
TTY>   version:      2
TTY>   virt_base:    0xfffffe0007f44000
TTY>   phys_base:    0x801f44000
TTY>   mem_size:     0x3d7554000
TTY>   top_of_kdata: 0x807f3c000
TTY>   video:
TTY>     base:       0xbdf438000
TTY>     display:    0x0
TTY>     stride:     0x2800
TTY>     width:      2560
TTY>     height:     1600
TTY>     depth:      65566bpp
TTY>   machine_type: 0
TTY>   devtree:      0xfffffe00096a0000
TTY>   devtree_size: 0x5c000
TTY>   cmdline:      -v
TTY>   boot_flags:   0x0
TTY>   mem_size_act: 0x400000000
TTY> 
TTY> 
TTY> 
TTY> m1n1 v7c54aa3-dirty
TTY> Copyright (C) 2021 The Asahi Linux Contributors
TTY> Licensed under the MIT license
TTY> 
TTY> Running in EL2
TTY> 
TTY> Heap base: 0x807f3c000
TTY> MMU: Initializing...
TTY> MMU: SCTLR_EL1: 30100180 -> 30901085
TTY> MMU: running with MMU and caches enabled!
TTY> fb init: 2560x1600 (30) [s=2560] @0xbdf438000
TTY> fb console: max rows 46, max cols 64
TTY> fb: display logo
TTY> Device info:
TTY>   Model: MacBookPro17,1
TTY>   Target: J293
TTY>   Board-ID: 0x24
TTY>   Chip-ID: 0x8103
TTY> 
TTY> WDT registers @ 0x23d2b0000
TTY> WDT disabled
TTY> pmgr: initialized, 272 devices found.
TTY> Initialization complete.
TTY> Checking for payloads...
TTY> No more payloads at 0x803854000
TTY> No valid payload found
TTY> i2c: want to read 1 bytes from addr 63 but can only read 0
TTY> usb: tps6598x_powerup failed for /arm-io/i2c0/hpmBusManager/hpm1.
TTY> usb: failed to init hpm1
TTY> USB0: initialized at 0x807f3c030
TTY> USB1: initialized at 0x807f3c440
TTY> Running proxy...
m1n1 base: 0x80375c000
Have fun!
>>> get_bootargs()
0x807f38000
>>> read64(get_bootargs()+16)
0x801f44000
>>> read64(get_bootargs()+24)
0x3d7554000
>>> top_of_mem = 0x801f44000 + 0x3d7554000
>>> readmem(top_of_mem-8, 8)
Traceback (most recent call last):
  File "/usr/lib/python3.9/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<console>", line 1, in <module>
  File "/home/pip/metalinux/m1n1/proxyclient/m1n1/proxy.py", line 400, in readmem
    raise UartChecksumError(f"Reply data sentinel error: Expected "
m1n1.proxy.UartChecksumError: Reply data sentinel error: Expected 0xb0cacc10, got 0x45cacc10

What happens on the console is an SError with ESR 0xbe000000 and L2C_ERR_ADR 0x300000bd9498000, which is the top_of_mem address.

(The “65566 bpp” thing and the i2c error are real, too, I’m afraid)

I guess this all makes sense since we did create a “normal” mapping for the poisoned page that starts unavailable “memory”, but I’m not sure how best to fix it. I think what happens is the CPU speculatively prefetches from the mapped-but-inaccessible page. The ringbuffer read code, which is where the SError hits, does look like it would trigger such a prefetch by reading bytes sequentially (which is why it might not be possible to reproduce this using a UART, come to think of it).

[svenpeter42]

Is this directly booted from iboot without any other code running before?

[svenpeter42]

Then just keep whatever is required above that mapped as well.