Leveraging uBoot?

[christinaa]

Kernel bringup is painful for any new platform, and is generally you don't really want to deal with bootloader bringup at the same time and have to deal with things like hardware errata and other things like that.

Why not use uBoot which already suports a variety of target platforms and integrate your code into it? It also provides things like TFTP support and network drivers which can be invaluable since you will be doing constant rebuilds of your kernel and uploading it over serial is just not viable. On top of that early boot networking is generally fairly slow for various reasons, I would generally advise compressing either the entire image or sections of the image.

Image3 is not a flexible format, Image4 is not much better either, it's not intended to be, if you'd like to give it a try, I could give you all of my bootkit sources under LGPLv3 (it's a superset and newer versions, though still pretty old since it was all done around 2012-2013) of a lot of the code that you derived from mach_boot or GenericBooter. It's something that is a uBoot "module" and provides various features such as support for the ImageX format, as well as instrumentation for creating or modifying such images (the fuser tools are absolutely horrid in terms of coding but they work) and in general the format allows for quite a lot of things including loading Linux-like kernels, Darwin kernel and drivers, device tress, bootscripts, standalone Mach-O applications.

In terms of compression I would suggest QuickLz or Lz4, QuickLz, in my experience is the best one but it's only provided under either GPLv1/2/3 though if you abstract compression you can easily drop QuickLz to revert back to LGPLv3 or find an alternative compressor (Lz4 is definitely worth looking at).

This is generally the sort of flexibility it provided:

RAW_IMAGES = [
    ('/Volumes/builder2/xen/xen/xen-uimg', 'xen.omap5', 0xe0000000, 'C'),
    ('/Volumes/builder2/linux-3.8.13-0-omap5/omap5hvm_xen_patched.dtb', 'devicetree.omap5', 0xe1000000, 'C'),
    ('/Volumes/builder2/linux-3.8.13-0-omap5/arch/arm/boot/zImage', 'linux.omap5', 0xe2000000, '')
]

MACH_KERN  = '%s/BuildRoot/Caches/Kernels/mach.debug.omap5hvm' % BASEPATH)
BOOTSCRIPT = '%s/BuildRoot/Sources/BootScripts/bootscript.omap5hvm.ubs' % BASEPATH)
MACH_DTRE  = '%s/BuildRoot/Sources/DeviceTrees/devicetree.omap5hvm.js' % BASEPATH
OUTPUT     = '%s/BuildRoot/Caches/TFTP_Root/Omap5HVM.imgx' % BASEPATH

make_imgx(
    rawimages=RAW_IMAGES,
    output=OUTPUT,
    bootscript=BOOTSCRIPT,
    kernel=MACH_KERN,
    compression='QLZ',
    device_tree_js=MACH_DTRE
)

Just advising, if you're interested I can give you the old u-boot stuff under LGPLv3, sans QuickLz which you can get from their website yourself. I can't really hold your hand much or work on this but I would very much like to see your attempt to get XNU running on at least one platform. If you want an easy way RaspberryPi2 or 3 are good candidates because of the firmware doing everything for you (in RPi case you would likely use a small bootstub stitched to the kernel, I highly advise against trying to read anything off eMMC early in boot on those SoCs).

Poke me (kristina) on Rizon or Espernet, would very much like to finally see Open Darwin come to life on embedded, would be interesting to have a chat when you're around.

[b-man]

@christinaa Sure, I would love to use your u-boot based solution. The nice thing about u-boot is that it is already supported on the Raspberry Pi, so apart from forward porting BootKit to a current branch of u-boot, I would be able to start working on a kernel port right away.

When would be a good time for me to contact you on IRC?

[christinaa]

This may help, no idea what state it is in right now: https://github.com/christinaa/xnu-uboot-arm32

[b-man]

Thanks for releasing this code @christinaa. It looks like the bootkit header files are missing but from looking at the code those should be pretty trivial to implement.

Happy Holidays!

[christinaa]

Most of the IMGX stuff is in loader.c, for TFTP you'll want to patch the TFTP stack to set filesize and fileaddr env vars so you can reference the IMGX or whatever file in a bootscript. But yeah I don't know what I did with the actual uboot code, only found this.