Hi all,

Following on from my set of patches to improve clarity around the support for standalone applications [1], I'm trying to put together a minimal proof-of-concept for a u-boot standalone application in a separate repository. This is necessary as the application will link against non-GPLv2 licensed cryptography libraries and so we don't want to create any confusion between the two source trees.

[1]: https://lore.kernel.org/u-boot/20220505153242.1598807-1-paul.barker@sancloud...

The liscense exception is intended to allow a standalone application to include the "exports.h" header and the "stubs.c" source file without the application being considered a derivative work of u-boot. However, those files include other u-boot headers covered by the GPLv2 (both directly and indirectly) as well as generated headers which depend on the kconfig options selected when building u-boot.

In particular, the stubs defined for each function in the jumptable depend on being able to calculate the offset of a field within the gd_t struct. Looking at "include/asm-generic/global_data.h", it's clear that these offsets will depend on the kconfig options. The offset calculation is required as the standalone application is only given the address of the gd_t struct, not the address of the jump table itself. This appears to preclude the ability to build a standalone application outside of the u-boot build system, and the ability to build the standalone application once and run it from multiple different u-boot versions or builds.

My preference here would be to:

1) modify the interface for standalone applications so that the address of the jump table is provided directly. This would remove the need to include a tree of u-boot headers in "stubs.c" and allow standalone applications to be built once and ran from different u-boot versions and builds (provided XF_VERSION is the same).

2) modify "exports.h" and "stubs.c" to be completely self-contained. This would allow these files to be copied into the source tree of a standalone application to simplify the build process. It would also make licensing simpler as no further GPLv2 headers and included indirectly.

3) Create a minimal demo of a standalone application in its own repository to act as a test that the above works. Once (1) and (2) are done, writing the minimal demo is trivial. Ideally this should be built regularly and tested with u-boot to make sure that the interface isn't accidentally broken. Ideally this demo should also be licensed under a permissive license (e.g. Apache-2.0 or MIT) to demonstrate how to comply with the licensing exception for standalone applications and give others a template to start from.

Obviously there's some work and testing involved here so I wanted to run this by the community before running ahead. Please confirm if I've understood the current state of standalone application support correctly and if patches to address (1) and (2) above would be welcome into the tree.

Many thanks,