Seems like it was a *hot* weekend...
Ben, I agree with Wolfgang that while taking footprint and simplicity into account we should "try to think about the whole system, including boot loader, kernel, and any data that might need to get passed between these two".
My ppc64 Linux is booted from U-Boot on Marvell platform and it uses the simple board_info instead of the device-tree. There are only some minor hacks in arch files that by-pass the whole device-tree usage in head.S and setup.c, e.g. [1] early_init_board_info() instead of early_init_devtree(), and [2] skipping on unflatten_device_tree() and finish_device_tree(). As you know, the majority of these functions and sub-functions just parse and handle the device-tree. Frankly, although I'm willing to give device-tree a try, I think it is not the wise thing to do. It is simple and effective, and it can be nicer with minor _general_ support in arch files to non-OF loaders. A slightly different loading for embedded systems is not necessarily a mess. I'm sure that the ppc experience will make it be nice and structured even this way.
Imagine emerging ppc64 Linux embedded systems living outside the kernel due to embedded incompatibilities; this might make much more mess in the long run...
Best Regards, Tzachi