]> git.zerfleddert.de Git - m1-debian/blame - doc/notes.txt
more notes
[m1-debian] / doc / notes.txt
CommitLineData
675e15e5
TG
109: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!
209:19 < _jannau_> Glanzmann: git rebase --onto 5.17-rc3 6f59bc24287
309:23 < j`ey> if you add -p it can also preserve the merges
37f23338
TG
4
519:13 < j`ey> but there's also CONFIG_OF_DMA_DEFAULT_COHERENT, which makes of_dma_is_coherent always return true
6
721:02 < jannau> mps: you need https://lore.kernel.org/u-boot/20220208210215.8612-1-j@jannau.net/ for extlinux
6189d624
TG
8
9ARCH: 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
e70d320b
TG
10
11https://lore.kernel.org/linux-arm-kernel/20211011165707.138157-1-marcan@marcan.st/
1219:02 < jannau> I think based on this branch https://github.com/AsahiLinux/linux/tree/cpufreq/v1
0c4f408e
TG
13
1423:41 < kov> Glanzmann, hmm interesting, I'll try upgrading libinput firs then, see if that fixes it
1523:42 < kov> it's weird because I remember the trackpad working a while ago
1623:45 -!- mtjzh (~mtjzh@2a02:8388:1742:9b80:658f:93d3:ec68:d60e) has joined #asahi
1723:46 < kov> yep, just upgrading to testing's libinput makes it work heh thanks Glanzmann!
f6f13b9e
TG
18
19Chromium 16KB patch: https://tg.st/u/Set-kernal-page-size-to-16K-on-loongson-MIPS-archtec.patch
bc854271 2010:10 < jannau> see the commit message for 64k on ppc64 https://chromium.googlesource.com/chromium/src.git/+/445c099c6486b8e5ff8dafaefcd812a7ea4bdfff%5E%21/
aa2187f5
TG
2115:26 < tpw_rules> Glanzmann: https://pastebin.com/NzJEQJDW - https://tg.st/u/NzJEQJDW
2215: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
f5e7256a 23Upstream BUG: https://bugs.webkit.org/show_bug.cgi?id=236564
6de0ead9
TG
24
2522:39 < jannau> `dtc -I fs -O dts -o - /proc/device-tree` will output the device-tree as seen by linux
54350e1e
TG
26
2719: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.
2819:11 < axboe> I just do: `echo "write through" > /sys/block/nvme0n1/queue/write_cache"` for now...
2919:11 < axboe> Glanzmann: ^^
3019:12 < axboe> Glanzmann: and yes, that's what it means
3119:12 < Glanzmann> axboe: Thanks.
3219:12 < axboe> Glanzmann: it'll bump your test case from 56 iops to 14k or something like that :)
3319:12 < axboe> alternatively, some sort of time based hack might make sense
3419:13 < axboe> "only issue flush if X seconds has passed since last issue"
3519:13 < axboe> kinda nasty, but safer
7af338e8
TG
36
3715:50 < mps> axboe: Glanzmann: `libinput Disable While Typing Enabled (268): 1` is set in my case and it works fine
3815:51 < mps> though I built latest beta of libinput and rebuilt xf86-input-libinput with it
3915:52 < mps> i.e. libinput-1.19.901
4015:52 < axboe> mps: promising
4115:53 < mps> but still didn't got it to detect thumb
0bfb4169
TG
4216:07 < mps> Glanzmann: `libinput quirks list /dev/input/event1` will show you features of input device
4316:09 < mps> and `libinput quirks list /dev/input/event1` will show quirks from libinput database
376e9a36
TG
44
45From mps:
46#!/bin/sh
47echo 2 > /sys/module/hid_apple/parameters/fnmode
48echo 1 > /sys/module/hid_apple/parameters/swap_fn_leftctrl
49echo 1 > /sys/module/hid_apple/parameters/swap_opt_cmd
77d777c5
TG
50
5119:19 < Glanzmann> sven: Do you know why axboe set the admin queue to 2 instead of 8?
5219:19 < sven> yes
5319:19 < sven> almost all commands go through the io queue, no need to waste that space for the admin queue
b04a3052
TG
54
55# j`ey on deleting efi and Linux partitions from the gui in macos
5620: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
848792f5 5710:53 < j`ey> Glanzmann: for your notes: < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX
5e24301e 5821:07 < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX
b04a3052 59
6b9ae994 6008:54 < mixi> Glanzmann: the command you're looking for should be "dtc -I dtb -O dts /sys/firmware/fdt"
20c4132a 6108:57 < jannau> Glanzmann: dtc -I fs -O dts -o - /proc/device-tree
2da24151
TG
62
63# j`ey on hack to hookup lid close/open
6423: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
6723:20 < kettenis> so the lid is hooked up to gP01
6823:24 < kettenis> looks like you could try hooking that up using gpio-keys-polled
6923: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?
7023:29 < kettenis> look at arch/arm/boot/dts/imx6q-novena.dts
7c8aab25
TG
71
72# How to subscribe to smc events
7323:45 < j`ey> Glanzmann: if youre still interested in looking: drivers/power/supply/macsmc_power.c apple_smc_register_notifier(power->smc, &power->nb);
7423: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
5ef66885
TG
75
76# More background
7723:54 < kettenis> if the interrupts are hooked up correctly for thise SMC gpios, gpio-keys instead of gpio-keys-polled should work
7823:54 < j`ey> no irq_chip in the current driver
79
9ef76d5d
TG
8017:34 <marcan> the image as built will have a real grub config with static UUIDs
8117:35 <marcan> well, a systemd early unit but yes
757a2286
TG
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}
1e964352
TG
134
135cloud-initramfs-growroot
f890e3ed
TG
13616:00 < Glanzmann> So applying a new uuid to the rootfs needs to be done in the initrd.
137tune2fs -U random /dev/whatever
5064faae
TG
138
13907: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
14107:54 < VinDuv> (it works even if the app is just a shell script) and it looks like it’s in 1TR mode.
14207: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.
14407: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.
b16f82dc
TG
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
177exec /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
182echo "Hello, world!"
183exec /bin/bash
7fada752
TG
184
185
18619: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.
18719: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.
b994e9f1
TG
188
18921:46 < povik> with pulse, you can get the jack by getting into pacmd
19021:46 < povik> and running: load-module module-alsa-sink device=hw:0,1
4be972c0
TG
19121:56 < povik> that mode of playing in parallel through the speakers and jack has a defect
19221:57 < povik> there's noise mixed-in then, at a period
19321:57 < povik> don't know how that happens yet
b994e9f1
TG
194
195If 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
204An 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
210This is probably because someone forgot to enable one of the following kernel options:
211
212CONFIG_BACKLIGHT_CLASS_DEVICE=y
213CONFIG_BACKLIGHT_GPIO=m
214CONFIG_DRM=y
215CONFIG_DRM_SIMPLEDRM=y
216CONFIG_FB_EFI=n
e5f68c50
TG
217
218-------------------------------------------------------------------------------------------------------------
219Howto convert from the old bootchain to the m1n1 chainloaded bootchain:
220
221(air) [~] parted /dev/nvme0n1 print
222Model: APPLE SSD AP0512Q (nvme)
223Disk /dev/nvme0n1: 500GB
224Sector size (logical/physical): 4096B/4096B
225Partition Table: gpt
226Disk Flags:
227
228Number Start End Size File system Name Flags
229 1 24.6kB 524MB 524MB iBootSystemContainer
230 2 524MB 400GB 399GB Container
231 3 400GB 402GB 2501MB
232 4 402GB 403GB 513MB fat32 boot, esp
233 5 403GB 495GB 91.8GB ext4 primary
234 6 495GB 500GB 5369MB RecoveryOSContainer
235
236I deleted partition 4 and 3, run the asahi installer again.
237
238Than I booted debian from the live stick and mounted the root filesystem and the efi file system:
239
240mount /dev/nvme0n1p5 /mnt
241mount /dev/nvme0n1p4 /mnt/boot/efi
242
243Than I bindmounted the rest of it:
244
245mount -t sysfs none /mnt/sys
246mount -t efivarfs none /mnt/sys/firmware/efi/efivars
247mount -t proc none /mnt/proc
248mount -o bind /dev /mnt/dev
249mount -o bind /dev/pts /mnt/dev/pts
250
251Than I changerooted into it:
252
253cd /mnt
254chroot . bin/bash
255
256blkid
257# Than I updated /etc/fstab with the new id of the efi partition
258
259curl -sLo /boot/efi/m1n1/boot.bin tg.st/u/u-boot.bin
260
40c6aeff
TG
261grub-install --removable /boot/efi
262
e5f68c50
TG
263exit, umounted everything and rebooted.
264-------------------------------------------------------------------------------------------------------------
8adb3bee
TG
26512: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
266
267## BEGIN NOTES ##
268
269# HOUSEKEEPING
270# All testing conducted with channels set to 40% in alsamixer,
271# with no amp gain.
272
273# Do NOT try to play sound with the speakers set to 100% in alsamixer,
274# you will fry the cones!
275
276# DRIVER MAPPINGS/ALSA QUIRKS
277# The speaker array as set up by the ASoC driver maps like
278# this on a J314s:
279# 0: Left Woofer 1
280# 1: Right Woofer 1
281# 2: Left Tweeter
282# 3: Right Tweeter
283# 4: Left (Sub)Woofer 2
284# 5: Right (Sub)Woofer 2
285
286# ALSA sets up the speaker array on the J314s as a 4.0 surround system,
287# with the RL and RR channels duplicated across the woofers like this:
288# 2: Front Left
289# 3: Front Right
290# 0: Rear Left
291# 1: Rear Right
292# 4: Rear Left
293# 5: Rear Right
294
295# Obviously this is not correct, but for us it does not matter, since
296# we can just tell ALSA to route FL and FR to all drivers, presenting
297# it to the rest of userspace as a stereo device. Surround sources
298# are downmixed appropriately.
299
300# SOUND CHECK
301# Testing reveals that drivers 4 and 5 are likely
302# only there to help with bass and sub bass. They
303# are extremely bad at reproducing frequencies above
304# ~500Hz, and even with the help of the tweeters sound
305# rough/deep fried in the mids. Drivers 0 and 1 are obviously
306# intended to be the main woofers in the array.
307
308# If we weren't intending to mimic whatever macOS does, my ear-only
309# testing would have me setting up a xover network like this:
310
311# Freq Range (Hz) | Drivers
312# 0-300 | 0 1 4 5
313# 300-6500 | 0 1
314# 6500-20000 | 2 3
315
316# Figures based on typical {LP,BP,HP}F rolloff characteristics.
317
318# Using all 4 woofers below 300Hz moves more air than just using the
319# (sub)woofers alone. 3-way loudspeakers work like this conventionally.
320
321# The ttable in the j314s-array pcm device tries to compensate for the lack of
322# EQ right now by greatly reducing the volume of 4 and 5, and slightly reducing
323# the volume of 0 and 1 relative to 2 and 3. I have found this gives an acceptably
324# clear sound without being too bright or losing too much out of the mids. Bass is
325# nonexistent, though I suspect this is just because we have not applied appropriate
326# correction to overcome the machine's housing yet. I will not be applying EQ or filtering
327# in ALSA using plugins even in the interim because
328# a) it's deprecated
329# b) it introduces overhead and chews up CPU time
330
331# FIRs can be applied to a 6 channel slave PCM which would then feed the routing table
332# PCM configured below with all coefficients set to 1
333
334## END NOTES ##
335
336# Create a six channel slave for the audio array
337pcm_slave.outputs {
338 pcm "hw:0,0"
339 channels 6
340}
341
342
343# We need to map L and R to the correct drivers. We can use
344# the coefficients in ttable to roughly tune the sound profile.
345pcm.j314s-array {
346 type route
347 slave outputs
348 ttable {
349 0.0 = 0.65
350 0.2 = 1
351 0.4 = 0.3
352 1.1 = 0.65
353 1.3 = 1
354 1.5 = 0.3
355 }
356}
357
358
359# Set up a plug and ctl interface for ALSA defaults
360# XXX: Does not work for PipeWire, but does work for JACK
361# and PulseAudio
362pcm.!default {
363 type plug
364 slave.pcm j314s-array
365}
366
367ctl.!default {
368 type hw
369 card 0
370}
371-------------------------------------------------------------------------------------------------
6620d516
TG
372
373# Control what happens after power loss
374/sys/devices/platform/soc/23e400000.smc/macsmc-reboot/ac_power_mode
c9f2ba7c
TG
375
37616k bugs
377========
37817:02 < kov> Glanzmann, https://bugs.webkit.org/show_bug.cgi?id=236564
37917:02 < kov> Glanzmann, that is already on the 2.34.6 stable release
38017: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
381 already in
38217:04 < kov> it's this one https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/be8a1dcbfc7edf19ef13a63ddf034dba814ee000
0d23d70f
TG
383
38417: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
385 new/old branches even after a rebase
38617:49 < j`ey> (where 'asahi' is my local not-yet-updated branch)
e3cfc0d0
TG
387
38821: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)
38921:55 < kov> Glanzmann, hrm adding vga=normal fb=false to the kernel cmdline made it work
390
Impressum, Datenschutz