[U-Boot] No support for "standalone" applications in FIT image?

Brett Stahlman brettstahlman at gmail.com
Mon May 7 20:00:27 UTC 2018


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.


More information about the U-Boot mailing list