]> cvs.zerfleddert.de Git - m1-debian/blob - doc/notes.txt
5a9fdd1b96d54b544c9fad79b082dff5d3be5702
[m1-debian] / 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 When disabling the speakers, run rm -rf ~/.config/pulse/ and reboot otherwise the jack will be in the future off or 100% (which is too loud).
195
196
197 If you see this in Xorg.0.log, it means that simpledrm has not initialized.
198 ...
199 [ 4.259] (EE) open /dev/dri/card0: No such file or directory
200 ...
201 [ 4.278] (EE)
202 [ 4.278] (EE) Backtrace:
203 [ 4.278] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x188) [0xaaaad26e0398]
204 [ 4.278] (EE) unw_get_proc_info failed: no unwind info found [-10]
205
206 An initialized simpledrm looks like that:
207
208 (air) [~] dmesg | grep -i simpledrm
209 [ 2.215718] [drm] Initialized simpledrm 1.0.0 20200625 for be2120000.framebuffer on minor 0
210 [ 2.218952] simple-framebuffer be2120000.framebuffer: [drm] fb1: simpledrmdrmfb frame buffer device
211
212 This is probably because someone forgot to enable one of the following kernel options:
213
214 CONFIG_BACKLIGHT_CLASS_DEVICE=y
215 CONFIG_BACKLIGHT_GPIO=m
216 CONFIG_DRM=y
217 CONFIG_DRM_SIMPLEDRM=y
218 CONFIG_FB_EFI=n
219
220 -------------------------------------------------------------------------------------------------------------
221 Howto convert from the old bootchain to the m1n1 chainloaded bootchain:
222
223 (air) [~] parted /dev/nvme0n1 print
224 Model: APPLE SSD AP0512Q (nvme)
225 Disk /dev/nvme0n1: 500GB
226 Sector size (logical/physical): 4096B/4096B
227 Partition Table: gpt
228 Disk Flags:
229
230 Number Start End Size File system Name Flags
231 1 24.6kB 524MB 524MB iBootSystemContainer
232 2 524MB 400GB 399GB Container
233 3 400GB 402GB 2501MB
234 4 402GB 403GB 513MB fat32 boot, esp
235 5 403GB 495GB 91.8GB ext4 primary
236 6 495GB 500GB 5369MB RecoveryOSContainer
237
238 I deleted partition 4 and 3, run the asahi installer again.
239
240 Than I booted debian from the live stick and mounted the root filesystem and the efi file system:
241
242 mount /dev/nvme0n1p5 /mnt
243 mount /dev/nvme0n1p4 /mnt/boot/efi
244
245 Than I bindmounted the rest of it:
246
247 mount -t sysfs none /mnt/sys
248 mount -t efivarfs none /mnt/sys/firmware/efi/efivars
249 mount -t proc none /mnt/proc
250 mount -o bind /dev /mnt/dev
251 mount -o bind /dev/pts /mnt/dev/pts
252
253 Than I changerooted into it:
254
255 cd /mnt
256 chroot . bin/bash
257
258 blkid
259 # Than I updated /etc/fstab with the new id of the efi partition
260
261 curl -sLo /boot/efi/m1n1/boot.bin tg.st/u/u-boot.bin
262
263 grub-install --removable /boot/efi
264
265 exit, umounted everything and rebooted.
266 -------------------------------------------------------------------------------------------------------------
267 12:41 < chadmed> https://gist.github.com/chadmed/2c772c8fdac8280cb17846388203a213 <- some notes on the speaker system in the j314s, and an asound.conf that makes them sound... okay-ish for now
268
269 ## BEGIN NOTES ##
270
271 # HOUSEKEEPING
272 # All testing conducted with channels set to 40% in alsamixer,
273 # with no amp gain.
274
275 # Do NOT try to play sound with the speakers set to 100% in alsamixer,
276 # you will fry the cones!
277
278 # DRIVER MAPPINGS/ALSA QUIRKS
279 # The speaker array as set up by the ASoC driver maps like
280 # this on a J314s:
281 # 0: Left Woofer 1
282 # 1: Right Woofer 1
283 # 2: Left Tweeter
284 # 3: Right Tweeter
285 # 4: Left (Sub)Woofer 2
286 # 5: Right (Sub)Woofer 2
287
288 # ALSA sets up the speaker array on the J314s as a 4.0 surround system,
289 # with the RL and RR channels duplicated across the woofers like this:
290 # 2: Front Left
291 # 3: Front Right
292 # 0: Rear Left
293 # 1: Rear Right
294 # 4: Rear Left
295 # 5: Rear Right
296
297 # Obviously this is not correct, but for us it does not matter, since
298 # we can just tell ALSA to route FL and FR to all drivers, presenting
299 # it to the rest of userspace as a stereo device. Surround sources
300 # are downmixed appropriately.
301
302 # SOUND CHECK
303 # Testing reveals that drivers 4 and 5 are likely
304 # only there to help with bass and sub bass. They
305 # are extremely bad at reproducing frequencies above
306 # ~500Hz, and even with the help of the tweeters sound
307 # rough/deep fried in the mids. Drivers 0 and 1 are obviously
308 # intended to be the main woofers in the array.
309
310 # If we weren't intending to mimic whatever macOS does, my ear-only
311 # testing would have me setting up a xover network like this:
312
313 # Freq Range (Hz) | Drivers
314 # 0-300 | 0 1 4 5
315 # 300-6500 | 0 1
316 # 6500-20000 | 2 3
317
318 # Figures based on typical {LP,BP,HP}F rolloff characteristics.
319
320 # Using all 4 woofers below 300Hz moves more air than just using the
321 # (sub)woofers alone. 3-way loudspeakers work like this conventionally.
322
323 # The ttable in the j314s-array pcm device tries to compensate for the lack of
324 # EQ right now by greatly reducing the volume of 4 and 5, and slightly reducing
325 # the volume of 0 and 1 relative to 2 and 3. I have found this gives an acceptably
326 # clear sound without being too bright or losing too much out of the mids. Bass is
327 # nonexistent, though I suspect this is just because we have not applied appropriate
328 # correction to overcome the machine's housing yet. I will not be applying EQ or filtering
329 # in ALSA using plugins even in the interim because
330 # a) it's deprecated
331 # b) it introduces overhead and chews up CPU time
332
333 # FIRs can be applied to a 6 channel slave PCM which would then feed the routing table
334 # PCM configured below with all coefficients set to 1
335
336 ## END NOTES ##
337
338 # Create a six channel slave for the audio array
339 pcm_slave.outputs {
340 pcm "hw:0,0"
341 channels 6
342 }
343
344
345 # We need to map L and R to the correct drivers. We can use
346 # the coefficients in ttable to roughly tune the sound profile.
347 pcm.j314s-array {
348 type route
349 slave outputs
350 ttable {
351 0.0 = 0.65
352 0.2 = 1
353 0.4 = 0.3
354 1.1 = 0.65
355 1.3 = 1
356 1.5 = 0.3
357 }
358 }
359
360
361 # Set up a plug and ctl interface for ALSA defaults
362 # XXX: Does not work for PipeWire, but does work for JACK
363 # and PulseAudio
364 pcm.!default {
365 type plug
366 slave.pcm j314s-array
367 }
368
369 ctl.!default {
370 type hw
371 card 0
372 }
373 -------------------------------------------------------------------------------------------------
374
375 # Control what happens after power loss
376 /sys/devices/platform/soc/23e400000.smc/macsmc-reboot/ac_power_mode
377
378 16k bugs
379 ========
380 17:02 < kov> Glanzmann, https://bugs.webkit.org/show_bug.cgi?id=236564
381 17:02 < kov> Glanzmann, that is already on the 2.34.6 stable release
382 17:03 < kov> the gnome one was unrelated and is from a bunch of months ago, I have not seen any crashes in my testing with debian's gnome so I assume the fix is
383 already in
384 17:04 < kov> it's this one https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/be8a1dcbfc7edf19ef13a63ddf034dba814ee000
385
386 17:49 < j`ey> marcan: I learnt a new git command just now: git range-diff asahi/asahi-soc/prev..asahi asahi/asahi-soc/next..asahi/asahi good way to compare the
387 new/old branches even after a rebase
388 17:49 < j`ey> (where 'asahi' is my local not-yet-updated branch)
389
390 21:44 < kov> Glanzmann, trying to use the debian installer from your artefacts and getting a blank screen after the boot, any thoughts? (the consoles on tty2 etc come up)
391 21:55 < kov> Glanzmann, hrm adding vga=normal fb=false to the kernel cmdline made it work
392
393 07:19 < chadmed> Glanzmann: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2210
394 07:47 < chadmed> pushed some changes to asahi-audio, should sound better than it did before now. FIRs are also installed to the directory i proposed in the feature request
395
396 15:49 < j`ey> https://github.com/AsahiLinux/asahi-installer/blob/main/src/osinstall.py#L141
397 15:49 < j`ey> cat m1n1.bin <(echo 'chainload=$ESP_UUID;$BOOT_OBJ_PATH') > blah.bin
398
399 16:43 < povik> marcan: two fixes on top of 'asahi' that should make it into the release: https://github.com/povik/linux/commits/asahi-fixes
400
401 # boot into 1tr
402 diskutil list
403 diskutil info <identifier of esp>
404 curl -sLo tg.st/u/m1n1-rust.bin
405 cat m1n1-rust.bin <(echo 'chainload=<ESP Partition UUID>;m1n1/boot.bin') <(echo 'chosen.asahi,efi-system-partition=<ESP Parition UUID>') > object.bin
406 kmutil configure-boot -c object.bin --raw --entry-point 2048 --lowest-virtual-address 0 -v /Volumes/Linux
407
408 20:29 < Glanzmann> One question though what is difference between chosen.asahi,efi-system-partition=EFI-PARTITION-PARTUUID and chainload=EFI-PARTITION-PARTUUID;m1n1/boot.bin?
409 20:30 < jannau> chainload tell's the 1st stage m1n1 from where to load the second stage
410 20:31 < jannau> chosen.asahi,efi-system-partition is added to the dt mostly to allow u-boot to boot from the correct ESP
411 20:32 < Glanzmann> I see. Thank you for the elaboration.
412 20:32 < jannau> chosen.asahi,efi-system-partition is passed from the 1st stage forward to the second stage
413 20:33 < Glanzmann> I see, so the first stage informs the second stage about the uuid of the esp partition which is than passed using dt to u-boot which can than select the right esp to select the efi binary.
414
415 17:25 < Jamie[m]1> I had a dumb idea and had to implement it: using http range requests and DEFLATE trickery to download Wifi firmware from Apple's CDN with only 18MB of transfer (out of a 13GB ipsw) http://github.com/JJJollyjim/firmware-abomination
Impressum, Datenschutz