X-Git-Url: http://cvs.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/blobdiff_plain/2da241513a048ff82c2ef27a49195ed2c58c5971..62ab3460d78190f12475ff598f5f1e17b8e96fba:/doc/notes.txt?ds=inline diff --git a/doc/notes.txt b/doc/notes.txt index 3aa321f..0e8bec1 100644 --- a/doc/notes.txt +++ b/doc/notes.txt @@ -68,3 +68,195 @@ echo 1 > /sys/module/hid_apple/parameters/swap_opt_cmd 23:24 < kettenis> looks like you could try hooking that up using gpio-keys-polled 23:27 < Glanzmann> kettenis: So gpio-keys-polled would poll gP01 and send a key event and than I could use my window manager to do something when that key event is received? 23:29 < kettenis> look at arch/arm/boot/dts/imx6q-novena.dts + +# How to subscribe to smc events +23:45 < j`ey> Glanzmann: if youre still interested in looking: drivers/power/supply/macsmc_power.c apple_smc_register_notifier(power->smc, &power->nb); +23:46 < j`ey> so this driver gets called, when an SMC notification happens. looks like all registered handlers would be called and its up to the callback to figure out if it needs to do something + +# More background +23:54 < kettenis> if the interrupts are hooked up correctly for thise SMC gpios, gpio-keys instead of gpio-keys-polled should work +23:54 < j`ey> no irq_chip in the current driver + +17:34 the image as built will have a real grub config with static UUIDs +17:35 well, a systemd early unit but yes + +{ + "os_list": [ + { + "name": "Asahi Linux reference distro (Arch Linux ARM)", + "default_os_name": "Asahi Linux", + "boot_object": "m1n1_uboot.bin", + "package": "asahi-alarm.zip", + "partitions": [ + { + "name": "EFI", + "type": "EFI", + "size": "512MB", + "format": "fat", + "volume_id": "0x03f103f1", + "copy_firmware": true, + "copy_installer_data": true, + "source": "esp" + }, + { + "name": "Root", + "type": "Linux", + "size": "5GB", + "expand": true, + "image": "root.img" + } + ] + }, + { + "name": "UEFI environment only (m1n1 + U-Boot + ESP)", + "default_os_name": "UEFI boot", + "boot_object": "m1n1_uboot.bin", + "partitions": [ + { + "name": "EFI", + "type": "EFI", + "size": "512MB", + "format": "fat", + "copy_firmware": true, + "copy_installer_data": true + } + ] + }, + { + "name": "Tethered boot (m1n1, for development)", + "default_os_name": "m1n1 proxy", + "expert": true, + "boot_object": "m1n1.bin", + "partitions": [] + } + ] +} + +cloud-initramfs-growroot +16:00 < Glanzmann> So applying a new uuid to the rootfs needs to be done in the initrd. +tune2fs -U random /dev/whatever + +07:54 < VinDuv> So I’ve been looking at how macOS installation from USB works on M1 Macs and I think it might be interesting for the Asashi installer. The way it works is that there’s a hidden plist file on the USB drive that references a macOS + application on the drive; if this file is present, the USB drive will show up in the power-button-held boot menu, and when selected, it will run the application. It doesn’t seem to care about file signature +07:54 < VinDuv> (it works even if the app is just a shell script) and it looks like it’s in 1TR mode. +07:56 < VinDuv> So the installation workflow from 1TR could be “plug in a USB stick, hold the power button, select Install Asahi” instead of having to manually open the terminal and run curl | sh. The installer doesn’t even need to be graphical since + it’s possible for the launched shell script to start the recovery environment’s Terminal and giving it an arbitrary command to run. +07:59 < VinDuv> This is also not limited to external USB drives; it also works if the files are in an APFS volume in internal storage, which I guess might be useful to have a Asahi Recovery boot option in the boot menu or something. + +---- .IAPhysicalMedia --------------------------------------------------------- + + + + + AppName + Some App.app + ProductBuildVersion + 00A191 + ProductVersion + 12.2.1 + + + +---- Some App.app/Contents/Info.plist ----------------------------------------- + + + + + CFBundleDisplayName + Some App + CFBundleExecutable + SomeApp + + + +---- Some App.app/Contents/Resources/.lproj/InfoPlist.strings ------ +"CFBundleDisplayName" = "Some App"; + +---- Some App.app/Contents/MacOS/SomeApp (executable) ------------------------- +#!/bin/bash +exec /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal "${0%/*}/../Resources/myscript.command" + +---- Some App.app/Contents/Resources/myscript.command ------------------------- +#!/bin/sh + +echo "Hello, world!" +exec /bin/bash + + +19:14 marcan: I have done a bit more testing with the .IAPhysicalMedia file and it looks like ProductBuildVersion can be any value including blank. ProductVersion seems to be checked against the minimal macOS version supported by the Mac; on my mini the icon shows up in the boot menu only if it’s >= 11.3. +19:15 Maybe it should be set to a higher value for forward compatibility with future Macs that will require 13.0? I’ve tested setting it to 99 and it works. + +21:46 < povik> with pulse, you can get the jack by getting into pacmd +21:46 < povik> and running: load-module module-alsa-sink device=hw:0,1 +21:56 < povik> that mode of playing in parallel through the speakers and jack has a defect +21:57 < povik> there's noise mixed-in then, at a period +21:57 < povik> don't know how that happens yet + +If you see this in Xorg.0.log, it means that simpledrm has not initialized. +... +[ 4.259] (EE) open /dev/dri/card0: No such file or directory +... +[ 4.278] (EE) +[ 4.278] (EE) Backtrace: +[ 4.278] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x188) [0xaaaad26e0398] +[ 4.278] (EE) unw_get_proc_info failed: no unwind info found [-10] + +An initialized simpledrm looks like that: + +(air) [~] dmesg | grep -i simpledrm +[ 2.215718] [drm] Initialized simpledrm 1.0.0 20200625 for be2120000.framebuffer on minor 0 +[ 2.218952] simple-framebuffer be2120000.framebuffer: [drm] fb1: simpledrmdrmfb frame buffer device + +This is probably because someone forgot to enable one of the following kernel options: + +CONFIG_BACKLIGHT_CLASS_DEVICE=y +CONFIG_BACKLIGHT_GPIO=m +CONFIG_DRM=y +CONFIG_DRM_SIMPLEDRM=y +CONFIG_FB_EFI=n + +------------------------------------------------------------------------------------------------------------- +Howto convert from the old bootchain to the m1n1 chainloaded bootchain: + +(air) [~] parted /dev/nvme0n1 print +Model: APPLE SSD AP0512Q (nvme) +Disk /dev/nvme0n1: 500GB +Sector size (logical/physical): 4096B/4096B +Partition Table: gpt +Disk Flags: + +Number Start End Size File system Name Flags + 1 24.6kB 524MB 524MB iBootSystemContainer + 2 524MB 400GB 399GB Container + 3 400GB 402GB 2501MB + 4 402GB 403GB 513MB fat32 boot, esp + 5 403GB 495GB 91.8GB ext4 primary + 6 495GB 500GB 5369MB RecoveryOSContainer + +I deleted partition 4 and 3, run the asahi installer again. + +Than I booted debian from the live stick and mounted the root filesystem and the efi file system: + +mount /dev/nvme0n1p5 /mnt +mount /dev/nvme0n1p4 /mnt/boot/efi + +Than I bindmounted the rest of it: + +mount -t sysfs none /mnt/sys +mount -t efivarfs none /mnt/sys/firmware/efi/efivars +mount -t proc none /mnt/proc +mount -o bind /dev /mnt/dev +mount -o bind /dev/pts /mnt/dev/pts + +Than I changerooted into it: + +cd /mnt +chroot . bin/bash + +blkid +# Than I updated /etc/fstab with the new id of the efi partition + +curl -sLo /boot/efi/m1n1/boot.bin tg.st/u/u-boot.bin + +exit, umounted everything and rebooted. +-------------------------------------------------------------------------------------------------------------