Standalone application development

[Paul Barker]

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.com/T/

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,

-- 
Paul Barker
Principal Software Engineer
SanCloud Ltd

e: paul.barker at sancloud.com
w: https://sancloud.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA67255DFCCE62ECD.asc
Type: application/pgp-keys
Size: 7526 bytes
Desc: OpenPGP public key
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220509/8c02fdfb/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220509/8c02fdfb/attachment.sig>