10:02 <j_ey> (carrying on from yesterday) the kernelcache is the right one (md5 matched, so unless i got a collision.. heh)

10:14 <j_ey> is there a command line option to disable kaslr on macos?

10:34 <j_ey> I also realised that macOS serials port wont work with the hv uart

11:41 <sven> j_ey: uh, it should

11:41 <sven> that's what the second acm interface is for

11:52 <j_ey> sven: I think I've been booting the wrong thing, booting a bare kernel instead of the entire kernelcache

11:52 <j_ey> (just guessing)

11:53 <sven> oh, yes

11:53 <sven> you have to boot the kernelcache :)

11:54 <j_ey> if/when I get it working with the release kernel I'll update the wiki

12:08 <j_ey> sven: I see your mailbox now has an actual commit message :D

12:09 <sven> yeah, it's slowly getting there :D

12:09 <sven> it also supports that slightly different other mailbox now

12:10 <sven> still not happy with the rtkit handling, but i think we need to wait and see what alyssa needs for dcp and agx before we can make an informed decision there

12:11 <j_ey> hm, I dont see yet what has changed to support the different mailbox

12:12 <sven> APPLE_M3_*

12:12 <sven> it's essentially the same hardware just with different register offsets

12:12 <j_ey> thats not on asahi/nvme/new

12:12 <sven> uh. i pushed a new version about 5 minutes ago fwiw

12:13 <sven> i thought that's what you saw

12:13 <j_ey> lol, I guess I pulled 6mins ago :)

12:13 <sven> haha :D

12:16 <j_ey> apple_mbox_hw_regs is a nice way of handling that

12:17 <sven> it helps that the hw works almost identical with just different offsets :)(

12:17 <sven> *:)

12:29 <marcan> j_ey: kaslr is an iBoot thing and cannot be disabled on production systems

12:29 <j_ey> Ah

15:17 <alyssa> the weekly problem

15:17 <alyssa> do I do my homework or hack at DCP

15:21 <pipcet[m]> uhm, DCP!

15:22 <pipcet[m]> we don't have to have reasons, do we?

15:27 <alyssa> Hmmmm

15:27 <alyssa> pipcet[m]: which branch were you talking about btw?

15:28 <pipcet[m]> the number I quoted was from your PR at asahilinux/m1n1?

15:29 <pipcet[m]> the sys_shutdown bug seems to be on linux-next/master... I'm not sure which other branches I've been talking about :-)

15:32 <alyssa> something about DCP stubs? I'm curious what "creative" changes to the DART driver were needed

15:37 <pipcet[m]> https://github.com/pipcet/linux/tree/pn-dart

15:38 <pipcet[m]> note that you need to modify the device tree to map the memory for the page tables, though...

15:39 <pipcet[m]> (and just that memory, not all of high memory as I did)

15:39 <alyssa> I see

15:39 <alyssa> thanks :)

15:40 <pipcet[m]> I've got a version lying around somewhere that doesn't need the modified device tree, but leaks memory on mapping.

15:47 <pipcet[m]> sven: do you want a separate bug report for the i2c issue?

17:12 <alyssa> Adding a disp0 dart node to the linux DT causes an SError on boot uhhh

17:28 <pipcet[m]> disp0 or dcp?

17:54 <alyssa> disp0 but i was being a nub

17:55 <alyssa> j_ey: I probably need your uart patch huh

18:43 <kettenis> alyssa, that makes some sense

18:44 <kettenis> that DART is locked, so you can't write to its registers

18:45 <kettenis> the DART driver should probably check the appropriate bit and take over its page tables

18:46 <kettenis> alyssa, I also replied to some of the mails in the PCI driver series

19:06 <alyssa> kettenis: disp0 isn't locked, I just messed up the DT

19:07 <kettenis> ah

19:08 <kettenis> having the wrong address in there will do it as well ;)

19:09 <sven> you can also write to locked darts without serrors. it just won't change most regs

19:09 <sven> and the linux driver will fail to probe if it sees a locked dart

19:10 <kettenis> good!

19:12 <alyssa> kettenis: forgot to put the nodes in the soc { } block :V

19:12 <sven> if someone wants to add support for this: make sure devices in those darts always get a unique group in device_group, make sure they always use a translated domain in def_domain_type, then in attach_dev just read out the TTBRs and put them into the io-pgtable structure, and finally write a custom free function for those that checks if the

19:12 <sven> pagetables were taken over

19:12 <sven> this will destroy all mappings, if you want to keep them walk the pagetable and return them in reserved_regions

19:12 <sven> (and ofc create them in the new one :-))

22:49 <alyssa> See I would totally tweet this screenshot but it's liable to go viral and that's not really what I need irght now.

23:00 <alyssa> Oops. Too late. This just in: i'm still a teenager

23:17 <j_ey> alyssa: so this isnt using iboots framebuffer?

23:19 <j_ey> oh youre still tweeting the details