@summers. Thanks, I am using BBB+arch in applications which are much more electronics oriented (I/O, PRU), for me this open community/collaboration is perfect. Still, the underlying development pace is quite fast, for a soloer like me, whenever there is a new approach in some part of the system, one has to dig deep everytime, that is good in the end as one has to study around and also it widens overall grasp of things.
Personally, I like the new DT approach, it seems to me as more mature solution - as I do think that parameters like hardware modes and such should be decided/set at boot time (ok, there are probably special cases). With the new boot.txt/mkscr way, you cleanly see what you do with u-boot on lowest level and general function of device trees is also brought closer to the user. The more experiments, the faster the documentation will gather up (forum sort of ). It could be also a good reference to users of other distributions, that hide this setup in front of them. Long live rolling (stone) release model.
As to the question, FDT_ERR_NOSPACE was returned when using resize WITHOUT the size parameter. Just out of curiosity I looked on the sizes of the main DTB and my overlay - DTB is of 56253 size in bytes, which has 1091 bytes remaining to its 4KB boundary, the size of my overlay is 2947 bytes - evidently won't fit. Seems like fdt resize function and FDT_ERR_NOSPACE is now clear. Therefore I will use the fdt resize 0x60000 approch from now on. To sum up again the process of loading DTB with overlays:
1) load base DTB
2) point fdt to its address, resize its size to accomodate desired overlays
3) load overlay to safe address (behind base DTB, or ramdisk space)
4) apply loaded overlay from its address
That is all I could comment on this problem for now.
Have a nice day.
Zeno