@zeno. Excellent stuff! I'm glad someone is continuing this. The BBB is great kit for its many and various IO ports, so its good that people that are using Arch, are also doing the various IO things. My own BBB, usually sits headless attached to my NAS. Its rare I go physically near it, let alone plug in the UART, or attach a cape. Alas my life is to busy. So I'm glad that others are doing so, and improving the methods of doing capes under arch.
Guess I should give some background to my method, where it came from. This is probably needed, as modifying device trees is terribly documented. Me I came across "fdt apply" browsing the uboot source code - I had a PocketBeagle, and uboot needed modifying to bring it, so whilst browsing source code - I came across "fdt apply", it needed an option set in uboot for it to be configured, but that option was on by default in the various Beagle configurations. I had never seen or heard of "fdt apply" - it wasn't documented on the denx web site. However digging like you came across:
http://git.denx.de/?p=u-boot.git;a=commit;h=e6628ad7b99b285b25147366c68a7b956e362878, "fdt apply" came into uboot something like 2 years ago, and if you read up on what Maxime has been doing - he's been patching master source code everywhere to these kind of embedded arm boards working in linux. But also like you came across RobertCNelson
https://groups.google.com/forum/#!topic/beagleboard/W0QPDee5u2s, Robert was using "fdt apply" before he went the direction of franken style uboot. Robert is the main man maintaining BBB and BBB overlays, don't know if he is a TI employee or not - but he must be pretty close.
Anyway Robert suggested "fdt resize; ftd apply; fdt resize", and said that the kernel bombed without this. Now I when I looked at removing the HDMI from the device tree, and doing overlays - my BBB was still attached to the NAS. This means that if you brick the device, I need to recover it - and its a hassle for me to plug in the UART, that at the moment being used on a Teensy, developing code. Hence when I made changes to the boot.txt - these were on the conservative side, as I needed it to come back up again. So before every change much research, and hence why I used the Robert "fdt resize; ftd apply; fdt resize"; but like you I questioned the need for the second "fdt resize" - as when its issued it is too late; anyway conservatism applied -so I kept it, at least until I could get the box to boot correctly.
One thing I did dig into, was the memory map, and that was why I posted it. Yes Robert said could write the overlay to the ramdisk memory area, I didn't like that as by default, as ArchArm uses a ramdisk, now the ramdisk I don't think has anything important in it - so the BBB could boot without the initramdisk, but wanted to keep the default, and didn't know if the overlay would interfere with the ramdisk. Hence why I split the device tree area, but I checked everything would fit.
Default uboot size: 512KB : 0x80000
BBB devicetree: 57KB
SPI Overaly: 1.5KB
So there was clearly room in the device tree area, and hence why I split that.
Now you resize by 0x60000, isn't that 384KB - I can't see why we would need anything that big for an overlay.
You said you had FDT_ERR_NOSPACE, was this with the 0x60000 option? With my option which adds 4KB (or is it taken to next 4KB boundary, not clear), should be able to apply twice without problems.
But good that you checked that we don't need the second "fdt reise".
Good find on changing the default device tree, yes you'll need to specify in the boot.txt - by defualt uboot reads the eeprom, and sets up a device tree depending on the signature there. So a BBB by default will always use the default device tree, unless you update. I never dug into what the other device trees did, I'm usually only happy decompiling them to source, and see what the differences are - whereas modifying a device tree, you can see what differences you make. Yes modification is more work, but also more transparent. So I'm myself quite neutral on that.
Anyway keep up the good work.