]>
Commit | Line | Data |
---|---|---|
675e15e5 TG |
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 | |
37f23338 TG |
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 | |
6189d624 TG |
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 | |
e70d320b TG |
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 | |
0c4f408e TG |
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! | |
f6f13b9e TG |
18 | |
19 | Chromium 16KB patch: https://tg.st/u/Set-kernal-page-size-to-16K-on-loongson-MIPS-archtec.patch | |
bc854271 | 20 | 10:10 < jannau> see the commit message for 64k on ppc64 https://chromium.googlesource.com/chromium/src.git/+/445c099c6486b8e5ff8dafaefcd812a7ea4bdfff%5E%21/ |
aa2187f5 TG |
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 | |
f5e7256a | 23 | Upstream BUG: https://bugs.webkit.org/show_bug.cgi?id=236564 |
6de0ead9 TG |
24 | |
25 | 22:39 < jannau> `dtc -I fs -O dts -o - /proc/device-tree` will output the device-tree as seen by linux | |
54350e1e TG |
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 | |
7af338e8 TG |
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 | |
0bfb4169 TG |
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 | |
376e9a36 TG |
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 | |
77d777c5 TG |
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 | |
b04a3052 TG |
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 | |
848792f5 | 57 | 10:53 < j`ey> Glanzmann: for your notes: < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX |
5e24301e | 58 | 21:07 < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX |
b04a3052 | 59 | |
6b9ae994 | 60 | 08:54 < mixi> Glanzmann: the command you're looking for should be "dtc -I dtb -O dts /sys/firmware/fdt" |
20c4132a | 61 | 08: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 | |
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 | |
7c8aab25 TG |
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 | |
5ef66885 TG |
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 | ||
9ef76d5d TG |
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 | |
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 | |
135 | cloud-initramfs-growroot | |
f890e3ed TG |
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 | |
5064faae TG |
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. | |
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 | |
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 | |
7fada752 TG |
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. | |
b994e9f1 TG |
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 | |
4be972c0 TG |
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 | |
b994e9f1 TG |
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 | |
e5f68c50 TG |
217 | |
218 | ------------------------------------------------------------------------------------------------------------- | |
219 | Howto convert from the old bootchain to the m1n1 chainloaded bootchain: | |
220 | ||
221 | (air) [~] parted /dev/nvme0n1 print | |
222 | Model: APPLE SSD AP0512Q (nvme) | |
223 | Disk /dev/nvme0n1: 500GB | |
224 | Sector size (logical/physical): 4096B/4096B | |
225 | Partition Table: gpt | |
226 | Disk Flags: | |
227 | ||
228 | Number 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 | ||
236 | I deleted partition 4 and 3, run the asahi installer again. | |
237 | ||
238 | Than I booted debian from the live stick and mounted the root filesystem and the efi file system: | |
239 | ||
240 | mount /dev/nvme0n1p5 /mnt | |
241 | mount /dev/nvme0n1p4 /mnt/boot/efi | |
242 | ||
243 | Than I bindmounted the rest of it: | |
244 | ||
245 | mount -t sysfs none /mnt/sys | |
246 | mount -t efivarfs none /mnt/sys/firmware/efi/efivars | |
247 | mount -t proc none /mnt/proc | |
248 | mount -o bind /dev /mnt/dev | |
249 | mount -o bind /dev/pts /mnt/dev/pts | |
250 | ||
251 | Than I changerooted into it: | |
252 | ||
253 | cd /mnt | |
254 | chroot . bin/bash | |
255 | ||
256 | blkid | |
257 | # Than I updated /etc/fstab with the new id of the efi partition | |
258 | ||
259 | curl -sLo /boot/efi/m1n1/boot.bin tg.st/u/u-boot.bin | |
260 | ||
40c6aeff TG |
261 | grub-install --removable /boot/efi |
262 | ||
e5f68c50 TG |
263 | exit, umounted everything and rebooted. |
264 | ------------------------------------------------------------------------------------------------------------- | |
8adb3bee TG |
265 | 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 |
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 | |
337 | pcm_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. | |
345 | pcm.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 | |
362 | pcm.!default { | |
363 | type plug | |
364 | slave.pcm j314s-array | |
365 | } | |
366 | ||
367 | ctl.!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 | |
376 | 16k bugs | |
377 | ======== | |
378 | 17:02 < kov> Glanzmann, https://bugs.webkit.org/show_bug.cgi?id=236564 | |
379 | 17:02 < kov> Glanzmann, that is already on the 2.34.6 stable release | |
380 | 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 | |
381 | already in | |
382 | 17:04 < kov> it's this one https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/be8a1dcbfc7edf19ef13a63ddf034dba814ee000 | |
0d23d70f TG |
383 | |
384 | 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 | |
385 | new/old branches even after a rebase | |
386 | 17:49 < j`ey> (where 'asahi' is my local not-yet-updated branch) | |
e3cfc0d0 TG |
387 | |
388 | 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) | |
389 | 21:55 < kov> Glanzmann, hrm adding vga=normal fb=false to the kernel cmdline made it work | |
390 |