Latest Pearl code (11.12.2021) on an M1 Mini: macOS 12/macOS 12.1 boot woes

[Johnnie390]

Hello Pip,

just tried the above out of interest. After the no4k prompt and "changing boot policy" message, nirvana. Screen black, nothing else, no diagnostic messages etc. Machine restarts constantly.

The only difference between now and last September is that the accursed mac os is now monterey.

Regards

Ry

[pipcet]

I'm afraid the state of the matter currently is this: Monterey means the firmware no longer initializes the frame buffer for us on the mini, which makes things unusable. I've only just become aware of the problem (it's possible to downgrade the mini to 11.6 using DFU mode, and I'm afraid that's what I ended up doing to my mini, just to see whether it was permanently unable to run Linux or not). We need a better DCP driver to get the mini working using the Monterey firmware.

It's easy enough to switch the screen resolution (to a black 4k screen, for example), but mapping the framebuffer hasn't worked for me so far. I'm going to have to have a look at the Asahi Linux folks' code to see how they do it.

[pipcet]

Okay, update: I've got things working locally, but it's a rather unsatisfactory process involving two versions of m1n1, a hacked chainload script, and some python interaction. Will think about how to do this properly (unless, of course, Apple decides to fix this in the next upgrade)...

[Johnnie390]

Hello all,

just tried the latest perl code using the curl -L url method. I spent a lot of the weekend downgrading from Monterey to Big Sur (11.6.1) as I have only one of the accursed apple devices.

After the initial csrutil disable and bputil stuff, I get as far as a few prompts after the "no4k" input, then as already mentioned in my first post, black screen and constant restarts. No error messages/diagnostics.

Any ideas?

Regards,

Ry

[pipcet]

Hmm. I'm not an expert on macOS internals, but I think it's entirely possible to install macOS 11.6 (the OS) but run macOS 12.0 firmware, or at least some of it. Did you use DFU mode to downgrade the mini?

Anyway, I've been busy working on just doing the (long, complicated, timing-sensitive) DCP dance to get us a framebuffer the hard way. I'm now looking at one, so that appears to work, but it still requires launching a script using the gadget USB port.

There are two major issues:

The first is stage1 will be entirely dark, it's only stage2 that can set up the framebuffer. That means no debugging for stage1 unless it's launched using a hacked m1n1 which sets up the framebuffer for it.

The second is that the DCP is very stateful, and I haven't figured out yet whether it is even possible to reset it to boot state with a working framebuffer: if we want to use the nifty DCP features in stage3, we need to hand over control of the DCP from stage2, including the memory buffers (and the DART page tables that are required to keep the framebuffer going).

The other issues are minor: what can we do to prepare for future macOS versions (not very much), how do we launch machos that aren't aware of the fixed framebuffer (we don't, for now), resolutions other than 4k (though I may be lazy and keep the actual display screen resolution at 4k).

Sorry if that got a bit technical. I'm working on it and making progress, and I'm close to having a usable mini again that also runs macOS 12.

Thanks, as always, for testing, and sorry for the difficulties, Pip

[Johnnie390]

Hello Pip,

"Hmm. I'm not an expert on macOS internals, but I think it's entirely possible to install macOS 11.6 (the OS) but run macOS 12.0 firmware, or at least some of it. Did you use DFU mode to downgrade the mini?" No I have only one apple device, I did the dowgrade the long way. I presume I am now running Big Sur (11.6.1) but the underlying firmware is (still) 12.0.1 (Monterrey). Not an ideal state of affairs.

Regards,

Ry

[Johnnie390]

Hello Pip,

"Hmm. I'm not an expert on macOS internals, but I think it's entirely possible to install macOS 11.6 (the OS) but run macOS 12.0 firmware, or at least some of it. Did you use DFU mode to downgrade the mini?" No I have only one apple device (M1). I did the dowgrade the long way. I presume I am now running Big Sur (11.6.1) but the underlying firmware is (still) 12.0.1 (Monterrey). Not an ideal state of affairs.

Regards,

Ry

[pipcet]

Did you mean to close this? I suggest reinstalling macOS 12, to be honest, since it's going to be much harder to support outdated versions, particularly the odd constellation where the OS is older than the firmware...

And we're nearly at the point where we have a framebuffer on macOS 12 firmware, even though it does require a huge song and dance I'd rather avoid. But I suppose we have to live with Apple's decisions :-)

[Johnnie390]

Hello Pip,

please "unclose" this issue. I am in the process of reinstalling macOS 12.

Does the same installation procedure hold i.e. curl -L xxxxxxx??

Regards

Ry

Did you mean to close this? I suggest reinstalling macOS 12, to be honest, since it's going to be much harder to support outdated versions, particularly the odd constellation where the OS is older than the firmware...

And we're nearly at the point where we have a framebuffer on macOS 12 firmware, even though it does require a huge song and dance I'd rather avoid. But I suppose we have to live with Apple's decisions :-)

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications on the go with GitHub Mobile for iOS [3] or Android [4]. You are receiving this because you modified the open/close state.Message ID: @.***>

Links:

[1] https://github.com/pipcet/pearl/issues/29#issuecomment-996723800 [2] https://github.com/notifications/unsubscribe-auth/AFOCI4Y4DCS2QNGQLEPIP5TURM3NRANCNFSM5J23WSYA [3] https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 [4] https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

[Johnnie390]

Reopening per Pipcet's wishes.

[pipcet]

Yes, the install procedure will be the same once I've got something working. It's possible the perl script will have to call kmutil differently for MacOS 12.1, if you're planning on installing that...

[Johnnie390]

Pip,

I have returned to 12.1 MacOs on the M1. The usual csrutil and bputil stuff has been done. The results are in the accompanying screenshot.

Regards,

Ry

[pipcet]

Thanks. The MacOS 12.1 problem is different (kmutil changed), and I'll try installing the new OS here, if Apple lets me, before implementing a solution...

Sorry this is taking a bit longer!

Pip

[Johnnie390]

Pip,

so many moving goalposts.. With Asahi releasing a workable soultion for the M1 mini (hopefully) soon and apple releasing an improved/enhanced M1 Mini in 2022. Not an envious task trying to keep track of all of this.

Ry

[pipcet]

Well, I've got a framebuffer on macOS 12.1 (in stage2 only, so far), so that's something...

I'll think about what to do with this project once I've got two working machines again. I might just decide not to update macOS on them ever again :-)

[Johnnie390]

Pip,

anything I can do from my end or are we (me) stuck here?

Ry

[Johnnie390]

Pip,

anything I can do from my end or are we (me) stuck here?

Ry

[Johnnie390]

Github playing up again..

[pipcet]

Sorry, occupied for a while longer with other matters.

I'll have some code later today, testing of which would be very much appreciated. Ideally, once it works it'll just keep working ;-)

[pipcet]

@Johnnie390 It's too buggy to be generally useful, but if you want to give the latest "release" a shot I'd be very interested to see whether anything at all happens on your device. Just loading it and waiting for two minutes to see whether the screen comes up would be great, but if it doesn't, USB stuff (type C ports only) would also be interesting.

The bugs mean it currently seems to be impossible to boot a third stage reliably. I'm not sure I understand what's happening there yet.

[Johnnie390]

Pip, the photos speak for themselves. Good work! Despite booting from RAM, I notice in NMON that the kernel page size is 16KB.. I presume that will be amended in the future. Any other information you need, please let me know. With an LXQT desktop installed and a few Firefox windows open, the memory utilisation is acceptable.

Would be nice to have some persistence at some stage.

Regards

Ry

[pipcet]

Thank you so much! That's excellent news (it's less excellent on my MacBook, which has a red screen until I run x8r8g8b8, and the backlight is back to being very dim because I used macOS and that resets the nvram setting...).

Can we open separate issues for the other questions?

Very briefly, the 16KB page size is a problem but appears to be the only thing the IOMMU supports, so it'll have to stay around until the Linux kernel IOMMU code is fixed to allow the IOMMU and CPU to have different page sizes, something I'm emphatically not volunteering for. The easiest way of getting persistence is probably a USB drive; using the nvme works but there's a good chance it'll make you require a DFU at some point...

[Johnnie390]

Pip, "which has a red screen until I run x8r8g8b8, and the backlight is back to being very dim because I used macOS and that resets the nvram setting...)." - I notice that when I use LXQT's Monitor settings it reports 1920x1080 with a refresh rate of 0 Hz. Xrandr reports the same. I can understand the IOMMU pandora's box issues... Regarding boot persistence, I would sooner wait until the dust has settled as running from a USB drive (compared to NVME) is not an option for me. DFU is a non-starter here, as I have only one apple device.

Regards,

Ry