I've built a standalone application that uses exported u-boot functions. It worked fine when I was loading the binary with "go", but when I attempted to package the binary in a FIT image, to be loaded with bootm, I ran into trouble...

Specifically, although the header seems to be parsed correctly, u-boot eventually fails (in bootm_find_os) with the following message:

ERROR: can't get kernel image!

I'm packaging with the following mkimage parameters:

type = standalone os = u-boot arch = arm64

The problem appears to arise in fit_image_load, which doesn't consider "standalone" a valid type for a FIT image. I was able to get my standalone app to load properly by changing type from "standalone" to "firmware". But why is this necessary? "Standalone" seems a more appropriate choice than "firmware" for an application built using u-boot's standalone template. Is there a reason I shouldn't be attempting to package a u-boot standalone app in a FIT image?

Note: The reason I decided to switch from flat binary image to FIT image is that I'm loading from flash memory (not a file system); thus, I wanted to add a header that encoded the size of the binary so I'd know how much to copy from flash to RAM. I've since discovered that the u-boot shell doesn't provide any utilities for extracting size from a FIT header in flash, so if I want to copy only the bytes in the image, I'd need to read the size from a hard-coded offset in the FIT header, which seems a bit ugly... Bottom line: Perhaps there's no reason to prefer bootm/FIT over go/binary after all... But I'd still like to understand why packaging as type = "standalone" doesn't work. I can't imagine mkimage would support the standalone type if there were never a reason to use it...

Thanks, Brett S.