Porting a kernel to a different architecture?

Question

I want to port the xnu kernel to the ARM architecture, with the ultimate goal of being able to run a full kernel inside Qemu. While I do realise that this is a very difficult task, I still want to have a go at it.

As far as I know, you're meant to write an entry point for the kernel (osfmk/arm/start.s) where you do general initialisation (MMU and PlatformExpert) after which the Kext/IOKit subsystems can be started and load CPU specific extensions (ie. traps, GPIO, clock) which are either prelinked into the binary or loaded by the bootloader (because the kernel can't interact with the filesystem due to the NAND extensions not being available yet).

While I do have a general idea on how ARM CPUs work, I don't even know where to get started with the xnu port, because I'm not entirely sure how to:

• Do low level debugging (since the kernel debugging facilities are unavailable early during startup).
• Integrate the ARM branch with the rest of the kernel source tree (ie. making sure the stuff in osfmk/kern is working).
• Create a sane environment for platform independent kernel to start (machine_startup());
• Fix up some platform specific code inside the main kernel code (most of the platform code is limited to osfmk/platform_name but some of it has to be integrated into osfmk/kern and others).

Are there any decent guides on porting the XNU (or at least Mach) kernel to different platforms, just like there are Linux guides?

Fauman

+1 I applaud your courage. Someone has to do hard stuff. I don't know anything about this but I'd reckon that if you start this then you'll be the one that will probably be writing the debugging guide! Kai Kaha bro. – Apraxia

Answer 1

Can't give you an answer, but a few hints:

The "big guys" do this sort of work on a system with special hardware attached that allows the processor to be single-cycled, the registers examined, etc. And they may do much of the work on an emulator that has the same facilities. The hardware debugger setup is probably outside your capabilities to build (and a bit expensive to buy), but the emulator is entirely feasible (and is how Gates and Allen got started on Altair BASIC -- if Allen hadn't written the emulator Gates would still be playing video games at Harvard).

Short of a full debugger, if you have any sort of character display attached, you can embed instructions in the code being debugged to write characters to the display as the code progresses. Path A may write "A" in the next location (an index kept in a reserved memory word somewhere) while path B would write "B", etc. Very crude, but it's sometimes enough to get by for small projects.

So I guess I'd recommend writing the emulator first. It's a good way to become familiar with the processor anyway.

(As to integrating stuff, I always just say "Hey, Jeremy! Integrate this for me, will you?")

Institutive

Answer 2

You will encounter a bit of a challenge as not all of the source code is available. Part of the source code of the Platform expert is available as part of the xnu sources, however the com.apple.driver.AppleACPIPlatform.kext is not.

Tank