It is possible to simply read the 'version_string' variable, but it
seems better to add a proper API call to get this. It is already
defined in lib/ulib/ulib.c
Add a prototype to u-boot-lib.h
Make use of it from the demo program.
Fix the comment for ulib_uninit() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
We need to check for the ulib library before building any examples. Add
this and ensure that the examples are rebuilt if the library changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an example of a program which boots an OS by calling into the U-Boot
library.
Series-to: concept
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-links: 1:28
The current Makefile for the ulib examples is not very easy to modify.
Split it into three parts:
- config.mk containing the variables used by the build tools
- a list of programs and the objects in each one
- rules.mk with some rules to make it all work
Use sys-objs to indicate objects which should be built with system
headers. Use U-Boot headers by default.
With this it is fairly simply to add a new program. Of course we could
make use of U-Boot's kbuild implementation to tidy this up, but the
purpose of the examples is to show how to do things outside the U-Boot
build system.
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a test that checks that ulib operates as expected.
Add a .gitignore file for the executables thus created
There is a strange interaction with PLATFORM_LIBS which can cause the
examples to fail to build via 'make qcheck':
- CI runs 'make qcheck'
- the main Makefile sets PLATFORM_LIBS
- test/run calls test.py
- at some point test_ulib_demos() starts, with PLATFORM_LIBS set
- the test calls 'make' on examples/ulib/Makefile
- PLATFORM_LIBS is left alone, since it already has a value
- lSDL ends up not being in the link line
Thank you to Claude for helping to debug this and figure out the
PLATFORM_LIBS interaction.
Series-to: concept
Series-cc: heinrich
Cover-letter:
ulib: Complete initial U-Boot library
This series completes support for building U-Boot as a shared or static
library, enabling reuse of U-Boot functionality in external programs and
test suites.
The U-Boot library (ulib) allows developers to:
- Link against U-Boot functionality without a full U-Boot image
- Use U-Boot's OS abstraction layer, drivers, and utility functions
- Build test programs that can exercise U-Boot code in isolation
- Create applications that benefit from U-Boot's hardware support
Key features:
- Builds both shared (libu-boot.so) and static (libu-boot.a) libraries
- Preserves U-Boot linker lists for proper driver/subsystem init
- Configurable symbol renaming to avoid conflicts with system libraries
- Generated API headers with renamed function declarations
- Documentation and working examples
- Currently only supports sandbox architecture
The series includes:
- More build-infrastructure and Makefile integration
- Python-based mechanism for symbol renaming and API generation
- Test programs demonstrating basic library usage
- A simple example program showing real-world usage patterns
Symbol renaming ensures that U-Boot functions don't conflict with system
libraries. For example, printf() remains the standard library function
while ub_printf() provides access to U-Boot's printf implementation.
This is handled automatically during the build process.
The library excludes main() to allow external programs to provide their own
entry points while still accessing U-Boot functionality through ulib_init()
and ulib_uninit().
For example:
#include <u-boot-lib.h>
#include <u-boot-api.h>
int main(int argc, char *argv[])
{
if (ulib_init(argv[0]) < 0)
return 1;
ub_printf("Hello from U-Boot library!\n");
ulib_uninit();
return 0;
}
License implications are documented - the GPL-2.0+ license applies to
any programs linked with the library, requiring source code distribution
for compliant usage.
Future work will look at expanding support to other architectures.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
It is possible to have some files that build in the system environment
and some in the U-Boot environment. To build for the system, the system
headers must be used, or at least have priority. For a U-Boot file, its
headers must be used exclusively.
Expand the Makefile example to have two files, one of which is built
using U-Boot headers. This shows how a program can be built which
straddles both domains.
Signed-off-by: Simon Glass <sjg@chromium.org>
