unable to boot the kernel with qemu

[minux]

I built a kernel at rev 4720e5ed3c83c20c7da88659959b10ffea0b0aa4, and extracted ramdisk from the uImage posted at the reddit post (http://www.reddit.com/r/jailbreak/comments/1q04wa/bootable_armxnu_kernel_with_sample_root_filesystem/).

The qemu command line I used is: qemu-system-arm -serial stdio -M realview-pb-a8 -m 512 -kernel SampleBooter.elf.uImage -append 'rd=md0 debug=0x16e serial=3 -v -s'

It outputs the following and then hangs:

debug_init()
=======================================
::
:: GenericBooter for ARM RealView, Copyright 2013, winocm.
::
::  BUILD_TAG: GenericBooter-100.1
::
::  BUILD_STYLE: DEVELOPMENT
::
::  COMPILE_DATE: Dec  4 2014 02:53:17
::
=======================================
preparing system...
image3_get_tag_data: data at 0x80008070 of size 0x00843000 for image type 'krnl'
Loading kernel at 0x70001000
image3_get_tag_data: data at 0x8184b0d0 of size 0x00000a5b for image type 'xmdt'
image3_get_tag_data: data at 0x8084b0a0 of size 0x01000000 for image type 'rdsk'
creating ramdisk at 0x7084e000 of size 0x1000000, from image at 0x8084b0a0
creating device tree at 0x7184e000 of size 0x9f8
gBootArgs.commandLine = [rd=md0 debug=0x16e serial=3 -v -s]
kernel prepped at 0x70101350, transferring control out of booter now!

I've managed to extract the bootloader used in the aforementioned reddit post, and it could boot the kernel just fine (although bootstrap server of launchd still crashes and I still couldn't figure out how to execute any command from the "stuipidshell" prompt). The first few lines of qemu serial output are:

PE_RealView: pic at 0xc0002000, distribution at 0xc0003000
cache: initializing i+dcache ... done
Serial mode specified: 00000003
CPU: Cortex A8-r0 rev 0 (Cortex-A core)
 Supported features: ARM_ISA THUMB2 THUMBEE ARMv4 Security_Ext
 WB enabled LABT branch prediction enabled
LoUU:2 LoC:2 LoUIS:1 
Cache level 1: 
 16KB/64B 4-way data cache WT WB Read-Alloc
 16KB/64B 4-way instruction cache Read-Alloc
Darwin Kernel Version 13.0.0: Sat Nov 29 01:15:48 EST 2014; minux:xnu/BUILD/obj//DEBUG_ARM_ARMPBA8
pmap_steal_memory: C0307000 - C0309000; size=00002000
pmap_steal_memory: C0309000 - C030A000; size=00001000
pmap_steal_memory: C030A000 - C0310000; size=00006000
pmap_steal_memory: C0310000 - C0390000; size=00080000
pmap_steal_memory: C0390000 - C03E0000; size=00050000
pmap_steal_memory: C03E0000 - C08FE550; size=0051E550
// snip

[b-man]

minux,

have you tried using winocm's GenericBooter-next? https://github.com/winocm/GenericBooter-next Unfortunately the GenericBooter found here has gotten outdated, so I'll probably replace it with winocm's version.

Btw, to save you some trouble, you can use my ramdisk which has been verified to work with the kernel in it's current state: https://www.dropbox.com/s/j5id402t2er59vh/ramdisk_new.dmg?dl=0

[minux]

Hi b-man, thank you very much for both pointers.

I tried GenericBooter-next, and it worked perfectly. Please consider replace GenericBooter with that one. And the iOS 4.3.5 ramdisk works much better than the one in the old reddit post.

Btw, how did you build the ramdisk? Are you building the required libSystem, dyld and launchd or are they copied from an ipsw image? Does the xnu kernel support any block and network devices provided by qemu?

[b-man]

I obtained that ramdisk a while back from winocm. Unfortunately building the userspace in a portable way (on Linux and on Mac) has turned into one mammoth of a task. I've spent quite a bit of time trying to come up with a build system for things like Libc/launchd/dyld/dispatch/ect. I'm thinking the best route to go would be to use autotools.

As for networking and block device support, the qemu port supports neither. However winocm has created a basic semi-functional (apparently deadlocks if you root to mmc - but this could be outdated info) mmc driver that can be used on the beagleboard: https://github.com/winocm/OMAP3-Drivers - perhaps this could be used as a reference to start work on a PL180 mmc driver?

Another important thing to note at this time is that I'm not sure how well dynamically loaded kexts work as I haven't tested out this functionality yet. I know that statically linking the drivers via a kernelcache should work however.