Load m1n1 at top of kernel data

[asdfugil]

m1n1 expects itself to be loaded below top of kernel data, so load it right at top of kernel data and then update top of kernel so that it is below top of kernel data.

In particular, its memory allocator start at topOfKernelData and assumes all memory between that and physBase + memSize is free. More severely, the chainloading scripts will derive new topOfKernelData from the current m1n1, so the current approach of loading would actually cause chainloading to set topOfKernelData to near the end of memory, causing problems.

[Siguza]

Would it not make more sense to load m1n1 over XNU itself? I'm assuming in 99.9% of cases it will be a smaller image, right? And if it isn't... well, there's alloc_static().

Also, gBootArgs->topOfKernelData is the value originally set by iBoot, while gTopOfKernelData takes into account all alloc_static() allocations done by Pongo - did you actually mean to use the former rather than the latter as source?
And we currently update it back in xnu_boot(), but this makes me wonder whether we should just do that for all types of boots, if we're going to pass them gBootArgs either way...

[asdfugil]

m1n1 can have kernel or ramdisk appended so it can be arbitrarily large. gTopOfKernelData is updated in this case so the boot trampoline goes elsewhere. It may be worthwhile to keep (patched) XNU around for potential dynamic tracing. Unless the plan is to have Linux boot in pongoOS again, gTopOfKernelData doesn’t need to exist. I think the solution here is to nuke gTopOfKernelData altogether?

[Siguza]

gTopOfKernelData is already exported to modules, so I'd rather not remove it now. And I do think there could be some value in preserving the original boot_args struct during Pongo runtime.