10:12 <ldhacker[m]> What is the current status of this project? Is the wiki on the “cutting edge”?

10:12 <Glanzmann> Some progress has not been mentioned.

10:13 <j`ey> ldhacker[m]: status is linux has been booted, basic interrupt and UART works, so a shell has been reached

10:13 <Glanzmann> ldhacker[m]: Someone correct me if, I'm wrong. But what works so far is a simplyfied boot loader m1n1, which can be used to load a kernel and initrd over UART using some python code https://github.com/AsahiLinux/vdmtool. The kernel boots up with a single thread and a busybox bash is running.

10:13 <ldhacker[m]> Nice!

10:14 <Glanzmann> Some other guys seems to have some sort of hacky (tech demo), SMP, PCIe, USB, WIFI running.

10:14 <Glanzmann> Oh and framebuffer works also.

10:14 <Glanzmann> Oh and network card seems to work as well.

10:14 <Glanzmann> However the code needs to be improved on and pushed upstream.

10:15 <Glanzmann> And someone is working on reversing the GPU. The first triangle was produced using userland code on macos.

10:16 <Glanzmann> X is also working with the framerbuffer apparently.

10:16 <ldhacker[m]> Wow, so quite a bit more progress. I wish there was some way I could help. I have experience with C but have never worked on a GitHub project like this one. Not sure where to start lol

10:17 <Glanzmann> I think, just send some money to let marcan do its job.

10:17 <Glanzmann> You can use github (less taxes at least in germany) or using patreon.

10:17 <jix> ldhacker[m]: I'm sure contributing will get easier with time when more of the essentials are done

10:17 <Glanzmann> I do the same, however I'm eager to try it out.

10:18 <jix> ldhacker[m]: there'll be a very long tail of stuff to work on to improve the overall experience, and if you have experience with C I'm sure you'll find something

10:19 <ldhacker[m]> Next time I get paid I will definitely send some money that way. I just want to be running Linux again lol. I was using Manjaro on a laptop before I got the Mac mini.

10:19 <jix> (I also expect there to be more of a contributing guide at that point to get people started)

10:20 <ldhacker[m]> Thank you all for the updates. I will continue to check back and see when I feel comfortable contributing!

10:26 <ldhacker[m]> Just became a patron!

17:07 <modwizcode> I got m1n1 (partially) running on qemu (not on apple silicon) by doing some very hacky stuff. I'm planning to hack support for generating the bootargs struct that m1n1 expects and then start working on an actual machine definition.

17:08 <j`ey> sven also got it running on qemu

17:08 <modwizcode> Yeah I heard

17:08 <modwizcode> I wonder what sven had to do, I couldn't see a way to avoid modifying the code of qemu but I was specific trying to avoid patching m1n1 whatsoever

17:09 <sven> i patched m1n1 :D

17:09 <sven> in pretty horrible ways

17:09 <modwizcode> Yeah I couldn't imagine another way and the way I got it working without patching is insane

17:09 <modwizcode> (likewise for the qemu patches)

17:09 <sven> :>

17:10 <modwizcode> I can do it right I'm just not super familiar with the qemu codebase and so I was trying to avoid writing a new board/machine definition out of the gate.

17:10 <sven> so i just drop the .maco file into flash at 0x0, manually set the initial PC to 0x4800, then after _start in m1n1 i have a copy loop that moves it to 0x8_0000_0000

17:10 <sven> and then i replaced uart_write with something qemu emulates

17:11 <sven> it's... not great.

17:11 <sven> oh, and i commented out most of the bootargs stuff so that it doesn't crash

17:11 <modwizcode> So I patched the exynos board that's already in there by forcing it to create cortex-a57 cores (it seems like that code ignores the CPU option), then patching the cortex-a9 mp private peripheral to not get mad if you use it with a non cortex-a9 core (all the other ones A11/A15 don't get mad)

17:11 <modwizcode> I moved the serial peripheral (which is why I patched this specific board since it's the same UART) to the right address

17:12 <sven> ah, nice. i just took some random board which had a different serial

17:13 <modwizcode> And I made a 2 line change to the linker script because I'm using qemus -kernel option to save time (loading the elf not the macho) and I needed to set the base address of the image to a ram address because otherwise qemu gets weird (I've noticed this before with my own kernels, qemu's boot handling for non-linux is complete crap at least on arm) so I had to manually set base to 0x0 so that the

17:13 <modwizcode> offsets wouldn't be doubled when relocating.

17:13 <modwizcode> All of the changes I made need to be done right

17:13 <modwizcode> most of the time I spent was on the MP stuff, since the board launches two cpus (I could have just changed this but for some reason this board also ignores command line options for cpu count I think) so I patched the code to keep the other cpu in a busy loop until I fixed it proper

17:14 <modwizcode> I would like to know how real SMP bringup is done on the M1 so I can replicate

17:14 <modwizcode> I hear correlium has that working. It would be super helpful if I had a real M1 mac someone donate one pls kthx

17:14 <never_released> modwizcode: you can look at the code :)

17:15 <never_released> it's not hard to do core bringup

17:15 <modwizcode> Yeah but then I can't poke at it in glorius detail

17:15 <modwizcode> I have learned it's not while messing with learning aarch64 in prep for this experiment with the M1 emulation, I'm surprised actually how easy it is

17:15 <j`ey> how was the CPU bringup reverse engineered?

17:15 <modwizcode> the only bringup I was familiar with before is the godawful mess that x86 MP is

17:16 <modwizcode> It's generally super simple on arm from what I understand from all the other qemu smp stubs

17:16 <modwizcode> They probably dumped rom somewhere

17:16 <modwizcode> where the busy loop is

17:16 <modwizcode> It's pretty recognizable loop I think

17:18 <modwizcode> I'm not sure what qemu upstreaming is like, does anyone know? Is it worth trying to do this right to get a potential M1 board upstreamed?

17:18 <sven> ^-- agraf

17:20 <modwizcode> And if it is worth trying to do, should I base my code on an existing board? I wouldn't know what else to do but I can tell you for sure nothing should be based on that exynos board it's a mess and awful. At the very least I'd probably like to submit a patch to fix SMP bringup on non-linux ARM kernels because that issue is painful and doesn't seem challenging to solve at all.

18:45 <never_released> modwizcode: you might want to combine the existing efforts

18:45 <never_released> to boot macOS

18:49 <modwizcode> Yeah probably

19:00 <davidrysk[m]> upstreaming to qemu: https://wiki.qemu.org/Contribute/SubmitAPatch

19:00 <davidrysk[m]> very similar to the rules for kernel upstreaming

19:11 <modwizcode> never_released: do you know of specific efforts to boot macos?

19:16 <j`ey> there's some people booting iOS on qemu.. hm

19:17 <modwizcode> I've looked at those but that didn't seem particularly relevant, what I saw mostly involved hacks to both qemu and the iOS kernel.

19:28 <davidrysk[m]> https://worthdoingbadly.com/xnuqemu3/

19:40 <modwizcode> Yeah that's the one I read

19:40 <modwizcode> I wish that had gone further though :/

19:47 <j`ey> would be neat to write a test suite in m1n1, to verify a qemu port against real hardware

19:49 <modwizcode> yeah it would

20:01 <j`ey> https://github.com/alephsecurity/xnu-qemu-arm64

20:01 <j`ey> but nothing about the AIC for example

20:10 <modwizcode> Yeah

20:20 <never_released> j`ey: hm? that one simulates AIC too

20:22 <j`ey> oh it does?

20:22 <j`ey> I only took a brief look

20:24 <j`ey> I cant find any aic files

20:41 <modwizcode> there was some weirdness with the commits I think

20:42 <modwizcode> you have to like find the link to the specific commit or something the one I found was orphened from all branches