03:15 <nik875[m]> i was following the m1n1 hypervisor documentation, and at the step where i have to create a custom m1n1 boot object for my second macos installation, i tried running this kmutil command:

03:15 <nik875[m]> kmutil configure-boot -c [path to m1n1.bin] --entry-point 2048 --lowest-virtual-address 0)

03:15 <nik875[m]> this gave me an error saying that the required argument --volume was missing, however when i specified the volume of my second macos installation it complained that the mount point couldn't be found. this problem persisted even after using diskutil mount to mount the volume. does anyone know what might be happening?

03:16 <nik875[m]> exact error: Error Domain=KMErrorDomain Code=71 "Could not find: Could not find mount point for disk4s8." UserInfo={NSLocalizedDescription=Could not find: Could not find mount point for disk4s8.}

03:17 <amarioguy> nik875[m] path to m1n1 bin is the path to the m1n1 binary

03:17 <nik875[m]> yep i set that

03:17 <amarioguy> also all macOS installs are mounted under /Volumes already

03:17 <nik875[m]> that's what i thought too, so idk why it's complaining

03:17 <amarioguy> that is admittedly my bad

03:17 <nik875[m]> nik875[m]: used scp to transfer the build from my second laptop

03:18 <amarioguy> forgot to add you needed to specify --volume /Volumes/[os volume name here]

03:18 <amarioguy> that just goes on the end of the command

03:18 <nik875[m]> lmao /Volumes?? i should've tried that lol

03:18 <nik875[m]> okay i'll reboot

03:18 <amarioguy> it's already mounted

03:19 <amarioguy> when rOS starts

03:19 <amarioguy> you don't need to mount it

03:19 <amarioguy> you just specify /Volumes/[os install volume name here]

03:27 <nik875[m]> Different error now, Fileset error: invalid Mach-O boot properties

03:27 <chadmed> paste the _exact_ command you are runnign

03:30 <nik875[m]> kmutil configure-boot -c m1n1/build/m1n1.bin —entry-point 2048 —lowest-virtual-address 0 —volume “/Volumes/macOS RE”

03:30 <chadmed> oh you need to also pass --raw

03:30 <chadmed> before --entry-point

03:31 <chadmed> otherwise it assumes youre passing it a macho

03:35 <nik875[m]> “Boot policy error: Error setting 3rd party kexts tag: code unknown boot policy error: 17”

03:36 <nik875[m]> Might be sip actually, I think I did that step in the wrong order

03:53 <nik875[m]> Yep that was it, custom boot object is created successfully

03:54 <chadmed> new u-boot borks keeb on the m1 pro

05:03 <jannau> chadmed: confirmed with asahi linux. spihid keyboard is broken with u-boot in asahi-dev

05:39 <marcan> whoops, let me see what that's about

05:55 <chadmed> might have been too quick on merging that ebuild jannau :D

06:32 <jannau> nothing wrong with the ebuild, also it's ~arm64 keyworded for a reason

06:34 <jannau> although I can see the appeal of using ~arm64 in general. I'm using it so only where necessary but it's a little bit annoying

06:42 <chadmed> i meant merging it on my system lol

06:43 <chadmed> i only noticed kb was broken because i needed it in grub after trying again to debug the module loading thing and couldnt switch kernels

06:44 <jannau> I tested it only on the m2 macbook as I assumed m1 would continue to work

06:44 <chadmed> glad that stage2 is on the esp, means fixing it was as easy as grabbing the previous version boot image off the cdn

08:24 <kettenis> I'm keeping a backup m1n1.bin on my esp such that I can easily recover in recovery mode ;)

08:29 <sven> ^-- smart!

08:29 <_jannau_> we should update the update-m1n1 script to move the old version to m1n1.bin.old

08:29 <kettenis> that might make sense

08:30 <sven> sounds like a good idea, yeah

08:59 <marcan> yeah, I just had the same idea while writing that doc earlier :)

09:39 <marcan> uboot on spi keyboards is fixed

09:48 <chadmed> new tag?

09:48 <_jannau_> asahi-v2022.07-2

09:48 <kettenis> marcan: what was the issue (I didn't spot it while looking at the diffs)

09:48 <chadmed> updating the ebuild now

09:49 <marcan> kettenis: didn't pass through the priv into leaf functions when I moved the kbd stuff to another file

09:49 <marcan> so they were getting the wrong pointer and casting it; it worked for MTP because the inner priv was the first member

09:49 <marcan> tl;dr C is evil let's move to rust

09:50 <kettenis> might make sense to make the priv the first member in the spi case as well

09:51 <marcan> maybe, but that's more fragile anyway. glad I didn't so this happened and we caught it :)

09:51 <kettenis> true

09:57 <chadmed> fixed on my machine :)

19:40 <nik875[m]> i'm still following the m1n1 hypervisor documentation, and i did manage to successfully create the custom boot object. but connecting a second pc (running linux) via a usb-a to usb-c cable does not show anything in /dev on the host. this is true both when m1n1 is booted and when normal macos is booted. i tested all usb ports involved and they do work, and i tried two different cables (both of which are chargers that i've verified to

19:40 <nik875[m]> transfer power, though i couldn't check for data transfer since i don't have another device with a female usb-c port). anyone know what might be happening?

19:42 <nik875[m]> i have a theory that it might be because of a command that i didn't run yet from a different documentation page: "nvram boot-args=-v". i have no idea what that command does though

19:42 <nik875[m]> also i tried proxyclient/tools/picocom-sec.sh, but no dice

19:43 <j`ey> did you build m1n1?

19:43 <nik875[m]> Yes, it boots correctly on the guest machine

19:44 <povik> does it say 'running proxy' on the last line?

19:44 <nik875[m]> Yes

19:44 <j`ey> then it isnt the nvram command

19:45 <povik> what mac device is the target? i am not sure if you can use just any usb-c port on it

19:45 <povik> i learned ports that work and haven't been trying other :-p

19:48 <nik875[m]> macbook pro 2021, i tried all three ports and none worked

19:48 <povik> i use left rear there, but maybe it's occultism

19:49 <nik875[m]> rear meaning towards the lid?

19:49 <nik875[m]> i used the left one towards the lid

19:49 <jannau> all usb-c ports should provide acm over usb except on mac studio m1 max (front ports don't work) and the 4 port imac (I think only the 2 ports closest to the power connector work)

19:49 <j`ey> my guess is the cable

19:50 <povik> nik875[m]: ah disregard what i said then

19:51 <nik875[m]> i'm also thinking the cable, as unlikely as it is i might have two broken ones lol

19:51 <j`ey> well not broken, but maybe charge only

19:52 <nik875[m]> i'll see if i can get my hands on a fresh one to be sure, but this is definitely unlikely.

19:52 <nik875[m]> are you supposed to be able to see anything in /dev when the cable is connected and the guest machine is fully booted into normal macos? because i didn't see anything there lol

19:53 <povik> no

19:53 <jannau> do you see anything usb releated in dmesg or lsusb after connecting the cable?

19:54 <j`ey> after booting to m1n1 ^

19:54 <jannau> and the cable being connected before booting m1n1

19:55 <j`ey> plug both sides of the cable, boot to m1n1, check dmesg/lsusb on host

20:00 <nik875[m]> it was probably the cable—still booted into macos, but lsusb shows "Apple MacBook Pro". that wasn't happening with the old cable. i'll boot into m1n1 to verify

20:18 <nik875[m]> Okay it was the cable, after switching out I was able to start booting the target macOS installation. Now I’m stuck on the rainbow apple logo though

21:20 <povik> puzzle of the day: on j413, is the cs42l84 codec on i2c1 or i2c3?

21:21 <povik> sending a bottle of asahi beer to whoever can settle it by looking at ADT alone :p

21:26 <povik> anyway i am going with i2c3 for the FDT i am writing, that's where the jack codec was on m1 air

21:26 <povik> the first person to test it on m2 will find out...

21:26 <jannau> maybe there are two? ask marcan to look at the iboot processed adt

21:26 <povik> ah right, could be iboot disables one of the nodes

21:27 <povik> unlikely there are two, but maybe there are variations from device to device

21:27 <povik> although i don't know what would prompt it

21:27 <jannau> it's on i2c3 for j493

21:35 <povik> in the end we may see dt_disable_missing_devs in kboot.c descend to i2cX

21:35 <povik> it's tad annoying we need to refer to the surviving node elsewhere in DT

21:35 <povik> (apple doesn't need that)

21:35 <jannau> did you check the 12.5 adt as well?

21:36 <povik> no, i have some early adt

21:43 <kettenis> what was the codec again that's similar to the cs42l84?

21:45 <povik> none

21:47 <povik> not to the level of regmap compatibility, but cs42l83/42 has been a good guide in reversing the regmap

21:47 <povik> not an exact match all of the time, but good enough

21:49 <povik> https://github.com/povik/linux/blob/asahi-sound-wip/sound/soc/codecs/cs42l84.c

21:49 <povik> https://github.com/povik/linux/blob/asahi-sound-wip/sound/soc/codecs/cs42l84.h

21:49 <povik> ^ this is what we got

22:08 <jannau> congrats povik

22:09 <jannau> macos 12.5 j413 template adt still has two identical cs42l84 codec nodes on i2c1 and i2c3

22:10 <jannau> one getting zapped by iboot is the only reason I can think of. still strange that there would be two logic board variants which differ in this aspect

22:11 <povik> yeah