Reading NVRAM from Asahi Linux gives different results compared to nvram -p in macOS.

[nohajc]

I installed Fedora Asahi Remix on a Macbook Air M2 13" (2022) and I wanted to figure out how to select startup disk from Linux.

From what I found, it should be a matter of changing the boot-volume NVRAM entry to the appropriate value.
I came across the asahi-nvram repo which uses /dev/mtd0 for raw access.

First I had to fork it because it didn't support NVRAMv3 format which the M2 Air seems to be using. Then I tried changing the startup disk "the official way" when I'm booted into macOS (using the Settings UI) so that I can compare the raw contents read from mtd0 before and after.

Now here's the weird part. In macOS, I can dump NVRAM using nvram -p and I can see how boot-volume changes from the Macintosh HD partition to Fedora Asahi Remix and back. However, when I read supposedly the same thing from Linux (/dev/mtd0 or /dev/mtd0ro), it does not change at all. I tried to toggle the boot volumes several times and I will always get the same result. I even calculated sha1sum /dev/mtd0 but it always stays the same.

So it looks like the NVRAM in Linux is somehow "stuck in time". I have no idea what's going on...

[jannau]

I can't reproduce that on an M2 MacBook Pro 13-inch. MTD0 contents change between two Linux boots (with a boot to a different volumes in between). boot-volume differs as expected between two different Linux installations.

How do you switch between Linux and macOS? changing the startup disk or selecting a volume in the boot picker with 'control' pressed?

[nohajc]

No, not the boot picker. My goal is to avoid having to press anything during boot. I change the startup disk in Settings -> General, then restart. I also check with nvram -p that the boot-volume really changed.

In order to read nvram from Linux I either have the default boot volume set to Asahi or I enter the boot picker during boot. In both cases, the checksum is the same.

Ok, now I'm curious if there's any difference between MacBook Pro and Air or if it is something else entirely.

Btw, does asahi-nvram work for you or you get parse error? In my case the binary starts with a magic string 3VVN which is the new format. Interestingly, when I create a macOS guest VM in UTM, it still uses the old format. Can't use Asahi in a VM obviously, but I checked the auxiliary storage image which contains nvram among other things.

Not sure if the format difference has anything to do with the issue but it's worth mentioning nonetheless I think.

I'm running kernel 6.5.4-403.asahi.fc38.aarch64+16k at the moment. Last dnf upgrade was today.

[nohajc]

Anyway, if there's anything I can do to help investigating this, let me know. I'd be more than happy to learn something new along the way.

[nohajc]

@jannau
Ok, I believe I've figured out where the problem is:

$ ioreg -p IODeviceTree -lf | grep nvram-
    | |   "nvram-raw" = <01000000>
    | |   "nvram-proxy-data" =
    | |   "nvram-current-bank" = <03000000>
    | |   "nvram-bank-size" = <00000100>
    | |   "nvram-bank-count" = <10000000>

If I'm reading this right (4-byte little endian integers), my M2 MacBook Air has larger NVRAM than Asahi Linux is reporting.
I looked at the device trees in AsahiLinux/u-boot and they assume all M2 devices have 128 kB of NVRAM. For M2 Pro (MacBook Pro), it is increased to 1 MB (16 banks with a 64 kB bank size).

So, for my M2 Air, linux only shows the first two banks whereas macOS reports there is a total of sixteen just like on the M2 Pro. If I kept rewriting the boot-volume (or any other variable), I'd eventually see changes in /dev/mtd0 but I still haven't used up all the banks (current number is 3 out of 16) so it appears as though the contents don't change.

Does this mean there are potentially more HW revisions of M2 Air or is it a bug? Thanks.

[jannau]

The nvram-bank-count seems to depend on the iboot version. Seems to 16 on all devices with Ventura (13) but is 2 on Monterey (12). So we have to handle this in m1n1.

[jannau]

This seens to be dependent on the macOS version of the stub partition. All ADTs stored from 12.x (or earlier) installs have a nvram-bank-count of 2 while the same devices have a nvram-bank-count of 16 with 13.x based stubs.

[nohajc]

Thank you for the clarification. If I wanted a quick fix for myself, can I modify the device tree using dtc?
Is it just /boot/dtb/apple/t8112-j413.dtb or do I also need to make some changes in u-boot?

[jannau]

The size will be fixed by #179 and AsahiLinux/m1n1#336

yes, dtc can be used to modify the partition size.

[jannau]

Hej @nohajc,
please create a pull request with the NVRAMv3 support in asahi-nvram and close this issue.

[nohajc]

Well, regarding NVRAMv3, it's not yet ready for merging but it's kind of unrelated to this issue.

And tbh, I'm afraid to test it on my machine unless I'm absolutely sure it won't break the boot.

Anyway, I thought it wasn't officially a part of the asahi project... But I definitely want to contribute so there will be a pull request eventually.

Thanks for all your awesome work btw!