Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reading the last bytes of memory (sometimes) SErrors #97

Closed
pipcet opened this issue Aug 20, 2021 · 8 comments
Closed

Reading the last bytes of memory (sometimes) SErrors #97

pipcet opened this issue Aug 20, 2021 · 8 comments

Comments

@pipcet
Copy link
Contributor

pipcet commented Aug 20, 2021

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
Copy link
Member

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

@pipcet
Copy link
Contributor Author

pipcet commented Aug 21, 2021 •
edited
Loading

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

Yes, it is. It's vanilla m1n1 without, to the best of my knowledge, doing anything weird :-)

@svenpeter42
Copy link
Member

Why is 7c54aa3 not a valid commit in this repository and why does the version also mention -dirty then?

@pipcet
Copy link
Contributor Author

pipcet commented Aug 21, 2021 •
edited
Loading

Cause I can't copy-and-paste:

TTY> 
TTY> boot_args at 0x808484000
TTY>   revision:     2
TTY>   version:      2
TTY>   virt_base:    0xfffffe001ff44000
TTY>   phys_base:    0x801f44000
TTY>   mem_size:     0x3d7554000
TTY>   top_of_kdata: 0x808488000
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:      0xfffffe0021bec000
TTY>   devtree_size: 0x5c000
TTY>   cmdline:      -v
TTY>   boot_flags:   0x0
TTY>   mem_size_act: 0x400000000
TTY> 
TTY> 
TTY> 
TTY> m1n1 vc2c6da3
TTY> Copyright (C) 2021 The Asahi Linux Contributors
TTY> Licensed under the MIT license
TTY> 
TTY> Running in EL2
TTY> 
TTY> Heap base: 0x808488000
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 0x803da0000
TTY> No valid payload found
TTY> USB0: initialized at 0x808488030
TTY> USB1: initialized at 0x808488440
TTY> Running proxy...
m1n1 base: 0x803ca8000
Have fun!
>>> get_bootargs()
0x808484000
>>> 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/pearl/bootloaders/m1n1/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
>>>

Sorry about that.

(The problem was building from a zipfile of vanilla m1n1, to make sure it was actually vanilla. That calls git describe --always --dirty without creating a git repository first, so it ends up printing the surrounding repo's commit description)

@pipcet
Copy link
Contributor Author

pipcet commented Aug 21, 2021

(I'm perfectly willing to try someone else's m1n1.macho if you'd think it'd help).

@svenpeter42
Copy link
Member

No, I knew that this could happen because we map too much memory. The i2c error just made it obvious that this was not a vanilla m1n1 or at least not booted by iBoot.

The correct fix is to modify memory.c such that it doesn't map anything after the end of useable RAM. Not a high priority for me though.

@pipcet
Copy link
Contributor Author

pipcet commented Aug 21, 2021

No, I knew that this could happen because we map too much memory.

As I said, I guess it all makes sense.

The i2c error just made it obvious that this was not a vanilla m1n1 or at least not booted by iBoot.

???

I am booting straight from iBoot, and it is a vanilla m1n1, and the i2c error sometimes happens.

The correct fix is to modify memory.c such that it doesn't map anything after the end of useable RAM.

Well, we need to map (some of) that RAM for m1n1 to work, obviously.

@svenpeter42
Copy link
Member

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

@pipcet pipcet mentioned this issue Aug 24, 2021
Open
@marcan marcan closed this as completed in da024ff Oct 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@svenpeter42 @pipcet