Replace shell-based date calculations with comprehensive Python script
that provides:
- Proper RC numbering counting backwards from final release dates
- Dead period detection for dates too early in the cycle
- Automated documentation updates with commit tracking
- Better error handling and testing coverage
- Shell variable output for CI integration
The new Python-based approach replaces fragile shell arithmetic with
robust datetime calculations and includes comprehensive test coverage.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org)
Add docs for the new concept release system:
- concept_cycle.rst: Technical documentation explaining the release
mechanism, schedule calculations, and troubleshooting guide
- concept_releases.rst: Auto-updated release history file with
installation instructions and real-time schedule generation
- Updated index.rst to include both new documentation files
The documentation covers:
- Bimonthly release schedule (Feb, Apr, Jun, Aug, Oct, Dec)
- RC numbering system counting backwards from final releases
- Dead period handling for dates too early in cycle
- Snap package distribution via Ubuntu Store
- Automated release tracking and history
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org)
Add a Python script to replace shell-based release version calculations
with proper datetime handling:
Features:
- Calculates release versions based on U-Boot's bimonthly schedule
- RC numbering counts backwards from final release (rc1=2wks, rc2=4wks,
rc3=6wks)
- Dead-period detection for dates too early in release cycle
- Automatic Makefile version updates
- Release documentation generation and updates
- Multiple output formats (shell variables, JSON, version string)
Testing:
- 39 comprehensive test cases covering all scenarios
- 93% test coverage including edge cases and error handling
- Tests for cross-year boundaries, dead periods, and file operations
The script provides robust release automation for the GitLab CI pipeline
with proper error handling and extensive validation.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org)
Ensure SSH user is specified in git clone URLs. Clean up the key format
a little.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: GitLab CI Runner <trini@konsulko.com>
This is an attempt to trigger updates of the u-boot-concept-qemu/efi
snaps whenever code is merged in this repo.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the Rust examples to the 'Examples' test suite, so that we can be
sure they continue to build and run.
Series-to: concept
Series-cc: heinrich
Cover-letter:
ulib: Add support for Rust main programs
So far ulib only supports linking against C programs. While this is the
common case, there is no particular reason why other languages could not
be used to write the main program, so long as they can interoperate with
the libu-boot.so/.a library.
Rust provides a Foreign Function Interface feature, which makes it
possible to declare and call C functions from Rust code. It provides
memory safety without the uncertainty of garbage collection and with
less overhead. It would be nice if ulib could be used with Rust.
This series provides the necessary pieces to make this work. It adds an
example program which works just like the C one, but written in Rust. As
with the existing example, the program can be built against the static
ulib or can use dynamic linking.
Note that only sandbox is supported at present, i.e. native execution on
(for example) a Linux machine. Future work will add support for running
on other architectures.
In order to make more use of ulib features, U-Boot's headers will need
to be made available in Rust format. For now, only a very few are
provided, as a starting point.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a test which is similar to the ulib example, to make sure that
the Rust programs can be built correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add docs for the Rust examples in the ulib documentation, covering:
- Rust demo programs (dynamic and static linking)
- Build instructions using both Makefile and cargo
- u-boot-sys crate structure and FFI bindings
- Building examples outside the U-Boot tree
This provides parallel documentation to the existing C examples, making
it possible to use either language with ulib.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
It is already possible to call functions in any U-Boot header. Add more
detail to explain what is meant in this 'future work' item.
Signed-off-by: Simon Glass <sjg@chromium.org>
The U-Boot library can be used from Rust fairly easily. Add an example
for this, following along the lines of the existing ulib example.
Note that the new way of representing C strings is not used for now,
since it is not available in v1.75 of cargo, as shipped by Ubuntu 24.04
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Create a new lib/rust directory and add a very basic rust library in
there. This will eventually expand to include more features. For now
it only has a few ulib calls needed for the example programs.
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
Install a Rust toolchain in the CI image so that it is possible to build
the Rust examples.
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
At this point there's problems rebuilding coreboot-24.08 without manual
intervention. Let us upgrade to a newer version.
Signed-off-by: Tom Rini <trini@konsulko.com>
In the case of the shared/static libraries, the _end and _init symbols
are not necessarily provided since the linker script is provided by the
program which links against the U-Boot library.
In some cases the memory size can show up as less than available memory,
but enough that there is insufficient memory for U-Boot to start.
It seems better to just set the mon_len to 0 for the library.
Series-to: concept
Series-cc: heinrich
Signed-off-by: Simon Glass <sjg@chromium.org>
This fix turns out to be insufficient in the corner case where mon_len
is smaller than available, emulated RAM but large enough that there
isn't enough left.
This reverts commit 88b810e241.
This makes a few changes to improve code readability:
- Avoid skipping tests
- Put all tests at bottom
- Shorten messages
- Avoid searching for files; just use those known to be there
Series-to: concept
Series-cc: heinrich
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-links: 1:30
The input file is used to process the dtsi, so add a dependency. This
bug was previously masked by a FORCE which was removed in
7738c4c2d7 Makefile: Avoid FORCE with ESL
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>
Add test for ESL (EFI Signature List) dependency chain that verifies proper
dependency tracking when FORCE is removed. Tests the transformation chain:
certificate -> ESL file -> DTSI file
The test ensures that:
- Certificate changes trigger ESL file rebuild
- ESL file changes trigger DTSI file rebuild
- Template changes rebuild DTSI but not ESL file
- No unnecessary rebuilds occur when dependencies are unchanged
Series-to: concept
Cover-letter:
Makefile: Reduce unnecessary rebuilds
In a few cases, U-Boot always rebuilds files even if nothing has
changed. This series fixes these and adds some tests which attempt to
show that these changes cause no problems.
The affected build rules are:
- converting htids to dtsi
- building devicetree overlays
- converting a certificate to an ESL file and a dtsi
END
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need to force building of the ESL dtsi or capsule file if they
already exist. Drop the FORCE dependencies.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a comprehensive test to verify that the $(obj)/%.dtbo rule properly
tracks dependencies and rebuilds when the corresponding .dtso source
file is modified. This ensures that removing FORCE from the dtbo rule
still maintains correct dependency tracking behavior.
The test creates a sample device tree overlay (.dtso) file and verifies:
- Initial build creates the .dtbo file
- Subsequent builds don't rebuild when nothing changed
- Changes to the .dtso source file trigger a rebuild
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a comprehensive test to verify that Makefile dependency tracking
works correctly when FORCE is removed from build rules. The test
ensures that targets are rebuilt when dependencies change but not
when they remain unchanged.
Co-developed-by: Claude <noreply@anthropic.com>
Co-developed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
A few of the steps are longer than the 7 characters allowed. Shorten
them so that the build output looks better:
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>
Most of the ulib functionality is in place now. Update the documentation
to match. Include details of how to run the example.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the test to use both the system printf() and the U-Boot one, in
the same program. This provides verification that symbol-renaming is
working as expected.
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>
Plumb in generation of the u-boot-api.h file, containing renamed symbols
for inclusion by the program being linked with ulib.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a way to create a .ulib-objs file which contains all of the object
files from the build, but with symbols renamed according to the
rename.syms file.
The file excludes main() which is present in the sandbox build, so that
programs which link with libu-boot can provide their own main()
For now this file is not used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a file which lists various symbols to rename when building the
U-Boot library. For now it contains printf() and related functions, but
more can be added later, as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
