U-Boot just hijacks the boot process from the main kernel that nolo tries to load - multiboot gets loaded early in the boot process initialized by nolo, reflashes the kernel, then reboots device.

As I understand it U-Boot will get loaded first, always (if the last kernel flashed by multiboot was one with U-Boot's image prepended to the kernel image), because for multiboot to load the kernel must have been initiated enough to run /sbin/preinit at least.

HOWEVER, for this to work consistently, one of your multiboot items must be a kernel with a u-boot image appended in front of it. If this is not done, then whenever you go to some other kernel, that kernel will be reflashed by multiboot, and then when you go back to the kernel where you originally had uboot prepended to, multiboot will use the kernel image it has to flash that back to the kernel partition - which will be a uboot-less kernel image unless you made sure you put the u-boot+kernel image instead of the plain kernel image into the place where multiboot keeps its kernel images.

The much better and less headache-y way would be for someone to get off their *** and figure out how to load the Android kernel from within u-boot, or for someone to figure out how to load both MeeGo and NITDroid with kexek - then we can finally use one of those, saner, methods, for multibooting, and multiboot can either use one of those methods in the backend, or just fade into obscurity.