git.zerfleddert.de Git - m1-debian/blob - doc/notes.txt

   1 09:10 < j`ey> Glanzmann: `git rev-list 6f59bc24287..smc/work` that might work, not sure how it deals with merges. git rebase is the better way. but if you do that youre on your own!
   2 09:19 < _jannau_> Glanzmann: git rebase --onto 5.17-rc3 6f59bc24287
   3 09:23 < j`ey> if you add -p it can also preserve the merges
   4
   5 19:13 < j`ey> but there's also CONFIG_OF_DMA_DEFAULT_COHERENT, which makes of_dma_is_coherent always return true
   6
   7 21:02 < jannau> mps: you need https://lore.kernel.org/u-boot/20220208210215.8612-1-j@jannau.net/ for extlinux
   8
   9 ARCH: 23:29 < ah-[m]> yep, exactly. I had to grub-mkconfig -o /boot/grub/grub.cfg, and move my Image.gz to /boot, otherwise it was just what was on the wiki page
  10
  11 https://lore.kernel.org/linux-arm-kernel/20211011165707.138157-1-marcan@marcan.st/
  12 19:02 < jannau> I think based on this branch https://github.com/AsahiLinux/linux/tree/cpufreq/v1
  13
  14 23:41 < kov> Glanzmann, hmm interesting, I'll try upgrading libinput firs then, see if that fixes it
  15 23:42 < kov> it's weird because I remember the trackpad working a while ago
  16 23:45 -!- mtjzh (~mtjzh@2a02:8388:1742:9b80:658f:93d3:ec68:d60e) has joined #asahi
  17 23:46 < kov> yep, just upgrading to testing's libinput makes it work heh thanks Glanzmann!
  18
  19 Chromium 16KB patch: https://tg.st/u/Set-kernal-page-size-to-16K-on-loongson-MIPS-archtec.patch
  20 10:10 < jannau> see the commit message for 64k on ppc64 https://chromium.googlesource.com/chromium/src.git/+/445c099c6486b8e5ff8dafaefcd812a7ea4bdfff%5E%21/
  21 15:26 < tpw_rules> Glanzmann: https://pastebin.com/NzJEQJDW - https://tg.st/u/NzJEQJDW
  22 15:26 < tpw_rules> last i checked the built chromium only worked with the flags --in-process-gpu --no-sandbox --no-zygote but that may have been a kernel config problem
  23 Upstream BUG: https://bugs.webkit.org/show_bug.cgi?id=236564
  24
  25 22:39 < jannau> `dtc -I fs -O dts -o - /proc/device-tree` will output the device-tree as seen by linux
  26
  27 19:11 < Glanzmann> axboe: Could you explain how to mark a device as write-through? Does that mean if I issue a sync in Linux that no flush will happen. Because this would be helpful for the m1 notebook owners to improve performance.
  28 19:11 < axboe> I just do: `echo "write through" > /sys/block/nvme0n1/queue/write_cache"` for now...
  29 19:11 < axboe> Glanzmann: ^^
  30 19:12 < axboe> Glanzmann: and yes, that's what it means
  31 19:12 < Glanzmann> axboe: Thanks.
  32 19:12 < axboe> Glanzmann: it'll bump your test case from 56 iops to 14k or something like that :)
  33 19:12 < axboe> alternatively, some sort of time based hack might make sense
  34 19:13 < axboe> "only issue flush if X seconds has passed since last issue"
  35 19:13 < axboe> kinda nasty, but safer
  36
  37 15:50 < mps> axboe: Glanzmann: `libinput Disable While Typing Enabled (268):    1` is set in my case and it works fine
  38 15:51 < mps> though I built latest beta of libinput and rebuilt xf86-input-libinput with it
  39 15:52 < mps> i.e. libinput-1.19.901
  40 15:52 < axboe> mps: promising
  41 15:53 < mps> but still didn't got it to detect thumb
  42 16:07 < mps> Glanzmann: `libinput quirks list /dev/input/event1` will show you features of input device
  43 16:09 < mps> and `libinput quirks list /dev/input/event1` will show quirks from libinput database
  44
  45 From mps:
  46 #!/bin/sh
  47 echo 2 > /sys/module/hid_apple/parameters/fnmode
  48 echo 1 > /sys/module/hid_apple/parameters/swap_fn_leftctrl
  49 echo 1 > /sys/module/hid_apple/parameters/swap_opt_cmd
  50
  51 19:19 < Glanzmann> sven: Do you know why axboe set the admin queue to 2 instead of 8?
  52 19:19 < sven> yes
  53 19:19 < sven> almost all commands go through the io queue, no need to waste that space for the admin queue
  54
  55 # j`ey on deleting efi and Linux partitions from the gui in macos
  56 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
  57 10:53 < j`ey> Glanzmann: for your notes: < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX
  58 21:07 < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX
  59
  60 08:54 < mixi> Glanzmann: the command you're looking for should be "dtc -I dtb -O dts /sys/firmware/fdt"
  61 08:57 < jannau> Glanzmann: dtc -I fs -O dts -o - /proc/device-tree
  62
  63 # j`ey on hack to hookup lid close/open
  64 23:19 < j`ey> apple_smc_event_received in drivers/platform/apple/smc_core.c is a good place to start looking
  65
  66 # kettenis on the same issue using existing infrastructure
  67 23:20 < kettenis> so the lid is hooked up to gP01
  68 23:24 < kettenis> looks like you could try hooking that up using gpio-keys-polled
  69 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?
  70 23:29 < kettenis> look at arch/arm/boot/dts/imx6q-novena.dts
  71
  72 # How to subscribe to smc events
  73 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);
  74 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
  75
  76 # More background
  77 23:54 < kettenis> if the interrupts are hooked up correctly for thise SMC gpios, gpio-keys instead of gpio-keys-polled should work
  78 23:54 < j`ey> no irq_chip in the current driver
  79
  80 17:34 <marcan> the image as built will have a real grub config with static UUIDs
  81 17:35 <marcan> well, a systemd early unit but yes
  82
  83 {
  84     "os_list": [
  85         {
  86             "name": "Asahi Linux reference distro (Arch Linux ARM)",
  87             "default_os_name": "Asahi Linux",
  88             "boot_object": "m1n1_uboot.bin",
  89             "package": "asahi-alarm.zip",
  90             "partitions": [
  91                 {
  92                     "name": "EFI",
  93                     "type": "EFI",
  94                     "size": "512MB",
  95                     "format": "fat",
  96                     "volume_id": "0x03f103f1",
  97                     "copy_firmware": true,
  98                     "copy_installer_data": true,
  99                     "source": "esp"
 100                 },
 101                 {
 102                     "name": "Root",
 103                     "type": "Linux",
 104                     "size": "5GB",
 105                     "expand": true,
 106                     "image": "root.img"
 107                 }
 108             ]
 109         },
 110         {
 111             "name": "UEFI environment only (m1n1 + U-Boot + ESP)",
 112             "default_os_name": "UEFI boot",
 113             "boot_object": "m1n1_uboot.bin",
 114             "partitions": [
 115                 {
 116                     "name": "EFI",
 117                     "type": "EFI",
 118                     "size": "512MB",
 119                     "format": "fat",
 120                     "copy_firmware": true,
 121                     "copy_installer_data": true
 122                 }
 123             ]
 124         },
 125         {
 126             "name": "Tethered boot (m1n1, for development)",
 127             "default_os_name": "m1n1 proxy",
 128             "expert": true,
 129             "boot_object": "m1n1.bin",
 130             "partitions": []
 131         }
 132     ]
 133 }
 134
 135 cloud-initramfs-growroot
 136 16:00 < Glanzmann> So applying a new uuid to the rootfs needs to be done in the initrd.
 137 tune2fs -U random /dev/whatever
 138
 139 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
 140                 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
 141 07:54 < VinDuv> (it works even if the app is just a shell script) and it looks like it’s in 1TR mode.
 142 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
 143                 it’s possible for the launched shell script to start the recovery environment’s Terminal and giving it an arbitrary command to run.
 144 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.
 145
 146 ---- .IAPhysicalMedia ---------------------------------------------------------
 147 <?xml version="1.0" encoding="UTF-8"?>
 148 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 149 <plist version="1.0">
 150 <dict>
 151         <key>AppName</key>
 152         <string>Some App.app</string>
 153         <key>ProductBuildVersion</key>
 154         <string>00A191</string>
 155         <key>ProductVersion</key>
 156         <string>12.2.1</string>
 157 </dict>
 158 </plist>
 159
 160 ---- Some App.app/Contents/Info.plist -----------------------------------------
 161 <?xml version="1.0" encoding="UTF-8"?>
 162 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 163 <plist version="1.0">
 164 <dict>
 165         <key>CFBundleDisplayName</key>
 166         <string>Some App</string>
 167         <key>CFBundleExecutable</key>
 168         <string>SomeApp</string>
 169 </dict>
 170 </plist>
 171
 172 ---- Some App.app/Contents/Resources/<lang code>.lproj/InfoPlist.strings ------
 173 "CFBundleDisplayName" = "Some App";
 174
 175 ---- Some App.app/Contents/MacOS/SomeApp (executable) -------------------------
 176 #!/bin/bash
 177 exec /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal "${0%/*}/../Resources/myscript.command"
 178
 179 ---- Some App.app/Contents/Resources/myscript.command -------------------------
 180 #!/bin/sh
 181
 182 echo "Hello, world!"
 183 exec /bin/bash
 184
 185
 186 19:14 <VinDuv> 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.
 187 19:15 <VinDuv> 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.
 188
 189 21:46 < povik> with pulse, you can get the jack by getting into pacmd
 190 21:46 < povik> and running: load-module module-alsa-sink device=hw:0,1
 191 21:56 < povik> that mode of playing in parallel through the speakers and jack has a defect
 192 21:57 < povik> there's noise mixed-in then, at a period
 193 21:57 < povik> don't know how that happens yet
 194
 195 If you see this in Xorg.0.log, it means that simpledrm has not initialized.
 196 ...
 197 [     4.259] (EE) open /dev/dri/card0: No such file or directory
 198 ...
 199 [     4.278] (EE)
 200 [     4.278] (EE) Backtrace:
 201 [     4.278] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x188) [0xaaaad26e0398]
 202 [     4.278] (EE) unw_get_proc_info failed: no unwind info found [-10]
 203
 204 An initialized simpledrm looks like that:
 205
 206 (air) [~] dmesg | grep -i simpledrm
 207 [    2.215718] [drm] Initialized simpledrm 1.0.0 20200625 for be2120000.framebuffer on minor 0
 208 [    2.218952] simple-framebuffer be2120000.framebuffer: [drm] fb1: simpledrmdrmfb frame buffer device
 209
 210 This is probably because someone forgot to enable one of the following kernel options:
 211
 212 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 213 CONFIG_BACKLIGHT_GPIO=m
 214 CONFIG_DRM=y
 215 CONFIG_DRM_SIMPLEDRM=y
 216 CONFIG_FB_EFI=n