X-Git-Url: http://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/blobdiff_plain/376e9a36ae4fa105c8f7b34a8e9f765616527b5e..b16f82dcbd4bf0fa0b9129aca0b97ba2978ddbc5:/doc/notes.txt?ds=sidebyside diff --git a/doc/notes.txt b/doc/notes.txt index 2b10b84..605979f 100644 --- a/doc/notes.txt +++ b/doc/notes.txt @@ -47,3 +47,137 @@ From mps: echo 2 > /sys/module/hid_apple/parameters/fnmode echo 1 > /sys/module/hid_apple/parameters/swap_fn_leftctrl echo 1 > /sys/module/hid_apple/parameters/swap_opt_cmd + +19:19 < Glanzmann> sven: Do you know why axboe set the admin queue to 2 instead of 8? +19:19 < sven> yes +19:19 < sven> almost all commands go through the io queue, no need to waste that space for the admin queue + +# j`ey on deleting efi and Linux partitions from the gui in macos +20:46 < j`ey> Glanzmann: I didnt figure it out at the diskutil cli, but I managed to do it from the GUI, I think you have to erase/reformat as APFS before you can delete the volumes +10:53 < j`ey> Glanzmann: for your notes: < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX +21:07 < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX + +08:54 < mixi> Glanzmann: the command you're looking for should be "dtc -I dtb -O dts /sys/firmware/fdt" +08:57 < jannau> Glanzmann: dtc -I fs -O dts -o - /proc/device-tree + +# j`ey on hack to hookup lid close/open +23:19 < j`ey> apple_smc_event_received in drivers/platform/apple/smc_core.c is a good place to start looking + +# kettenis on the same issue using existing infrastructure +23:20 < kettenis> so the lid is hooked up to gP01 +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