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)
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>
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
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>
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>
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>
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>
When U-Boot is used as a library with other programs, some U-Boot
function names may conflict with the program, or with standard-library
functions. For example, printf() is defined by U-Boot but is typically
used by the program as well.
The easiest solution is to rename symbols in the object file, so that
they appear with a 'ub_' prefix when linked with the program.
Add a new build_api.py script which can:
- rename symbols based on a rename.syms file
- generate a header file (with the renamed symbols) for use by the
program
This makes use of the 'objcopy --redefine-sym' feature.
The tool has 100% test coverage.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to run a command in a particular subdirectory.
Add support for this to the run_and_log() functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
The sandbox build is about to be used for ulib, so will not support LTO.
Use the sandbox_flatree build to check disabling LTO.
There is limited value in this, since sandbox will already check
building without LTO. But it seems reasonable to keep the test working,
making sure that the same board can build with and without LTO.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the test is run, indicate which library the test was linked
against, static or dynamic.
Drop the printf() at the start of main(). Since all printf() calls go to
U-Boot, this message is not shown anyway, since the global-data pointer
gd is NULL at this point and console_puts() just returns immediately.
Signed-off-by: Simon Glass <sjg@chromium.org>
We now have rules in the main Makefile to ensure that the library is
built before the ulib test-binaries. Drop the unnecessary dependency.
Also the link is done entirely in the main Makefile, so drop the flags
as well.
Add a comment to explain what is going on.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide an arch-neutral init function that can be used by including a
single header file.
This declares a static global_data which is used for the initial startup
process. Once board_init_r() is called, the global_data is moved into
a new place and the static version is not needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a simple function to set up the library, to avoid having to
worry about the details. This requires the caller to know about
global_data
Signed-off-by: Simon Glass <sjg@chromium.org>
The API is not very useful these days, since it doesn't support driver
model. It is laborious to add new functions to the API as there are so
many needed.
A better approach would be to create a library containing all of U-Boot,
then have the API be generated by a script containing a list of
functions, perhaps with wildcards. Then a stub could be created, with
a list of entry points, which links with and calls through into the
library.
In preparation for heading in this direction, rename some of the
existing files and directories:
- examples/api -> examples/legacy_api
- include/api*.h -> include/legacy_api*.h
- API_BUILD to LEGACY_API_BUILD
Co-developed-by: Claude <noreply@anthropic.com>
Add a new global_data flag GD_FLG_ULIB to indicate that U-Boot is being
used as a shared library. This allows suppressing console output that
is inappropriate for library usage while preserving normal boot messages
for standalone operation.
For now the flag must be enabled by the caller and it has no effect.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a host program which can use the shared library. For now this
operates similarly to sandbox itself, but future work will make it more
flexible.
Leave it out of the build, since there are a few other pieces needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move pci_map_physmem(), pci_unmap_physmem(), and
sandbox_set_enable_pci_map() from u-boot-sandbox.h to a new file
sandbox_pci.h to simplify dependencies.
Fix the header order in the PCI emul file while we are here.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new 'chid compat' subcommand that finds the compatible string
matching the current hardware's CHID and sets the fdtcompat environment
variable. This examines the devicetree under /chid for nodes with
hardware-id child nodes containing CHID data that matches the system's
generated CHIDs.
The command prints the found compatible string to the console and
automatically sets the fdtcompat environment variable for use by
other U-Boot commands.
Series-to: concept
Cover-letter:
Selection of devicetree using CHIDs
This series implements support for Microsoft's Computer Hardware
Identifier (CHID) specification in U-Boot. CHIDs provide a standardised
way to identify hardware configurations using SMBIOS data, enabling
automatic selection of appropriate device tree overlays and drivers when
the firmware itself lacks support for devicetree.
The CHID system generates UUIDs from various combinations of hardware
information (manufacturer, product name, BIOS version, etc.) creating a
hierarchy from most to least specific. This allows U-Boot to
automatically select the correct devicetree compatible-string for the
hardware on which it running.
This series includes:
* Core CHID Infrastructure:
- UUID v5 generation with Microsoft's CHID namespace
- Support for all 15 CHID variants (HardwareID-00 through HardwareID-14)
- SMBIOS data extraction and processing
* Devicetree Integration:
- hwids_to_dtsi.py script to convert CHID files to devicetree .dtsi
- Automatic inclusion of the .dtsi into the board'' devicetree
- Runtime compatible-string-selection based on hardware CHIDs
* chid command:
- chid show - show current hardware information and generated CHIDs
- chid list - list all supported CHID variants and generated UUIDs
- chid variants - show information about CHID variant restrictions
- chid compat - select the compatible string for current hardware
* ARM/EFI Support:
- CHID mappings for a selection of ARM-based Windows devices
- Support for Qualcomm Snapdragon platforms (MSM8998, SC7180, SC8180X,
SC8280XP, SDM850, X1E series)
* Testing:
- Sandbox tests using mock SMBIOS data
- CI integration for hwids_to_dtsi validation
- Validation against Microsoft's ComputerHardwareIds.exe output
Documentation is provided for this new subsystem and associated
commands.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-links: 1:22
Search the available CHIDs to determine the device on which U-Boot is
running. Use this to select the correct compatible string.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a Python script to convert Hardware ID files (as produced by
'fwupd hwids') into a devicetree format suitable for use within U-Boot.
Provide a simple test as well.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a 'chid list' command to display the values for all CHID variants.
Also add 'chid detail' to see all details about a variant.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a table of variants which indicates which fields are included in
each. Use this to calculate the CHID for a variant. Add some tests to
cover this.
Provide a constant for the length of a uuid.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a simple command which supports showing the information which
goes into calculating a CHID. The information is obtained entirely from
SMBIOS tables at present.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Some common smbios settings are not included with sandbox. Add these to
test.dts so the data is more meaningful.
Update smbios tests to match the new devicetree values.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Create a sandbox test for the smbios command. This checks that the
expected output is produced.
Drop the unnecessary 0x before each address, since U-Boot uses hex by
default.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add new SYSRESET_TO_FIRMWARE_UI reset type to allow resetting directly
to firmware UI. This is implemented via the reset command's new -u flag.
For the EFI app, this sets the EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit in
the OsIndications variable before performing a warm reset, causing the
firmware to boot to its setup interface.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases we may wish to return back to the program which started
U-Boot. Add the concept of a 'hot' reset, to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'bootflow list' command supports looking at the EFI device-path when
available. Move this piece into a common function so it can be used
elsewhere.
This updates the output from 'bootflow list'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new 'fdt reserved' subcommand that displays all reserved memory
regions defined in the device tree's /reserved-memory node. This command
provides a formatted table showing the ID, name, start address, and size
of each reserved memory region.
Avoid a conflict with the existing 'fdt resize' command. Update the docs
and add a test.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Move fdt_print() function from cmd/fdt.c to a new lib/fdt_print.c file
to make it available as a library function for other code to use.
Move and rename is_printable_string(), making it available as well.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add tests for checking:
- environment variable override with hex values
- invalid environment variable handling
- Kconfig-default behavior with device detection
- precedence rules (environment overrides device detection)
- serial terminal detection by manipulating sandbox state
Also expose calc_check_console_lines() in console.h for testing
and update pager functionality to use bypass mode when serial
is not connected to a terminal.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Show the actual value being used by the pager, if enabled.
Series-changes: 2
- Add new patch to show the pager page_len value
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a test that the prompt is displayed and another that paging
happens but does not appear in the recorded console-output.
Signed-off-by: Simon Glass <sjg@chromium.org>
A single character may result in a stall waiting for user input, which
means that it may request that a string be output. So when the pager is
active we never actually use the devices' putc() methods. Add a special
case so they don't go to wrack and ruin.
As before, the pager is only supported with CONFIG_CONSOLE_MUX enabled.
Series-changes: 2
- Drop unnecessary '!= NULL'
Signed-off-by: Simon Glass <sjg@chromium.org>
We generally don't want the pager to be active when running tests,
since U-Boot appears to hang forever. Perhaps we could detect when the
tests are being run interactively and use the pager in that case. But
for now, just bypass it.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The pager gets in the way of most tests, since it kicks in (by default)
when a command results in more than 25 lines of output. Use the -P flag
to bypass it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes output should be sent ignoring the pager, such as when it is
a message related to paging. Add a parameter to support this.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Cover the various cases in the base code. Put the tests in the 'common'
suite to match where the pager implementation is.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Change the default behavior of 'printenv -e' to show only EFI variable
names. The previous verbose output is now available with the -v flag.
This makes the command more user-friendly for quick variable listing.
Update documentation to reflect the new behavior and provide examples
of all three output modes: default (names only), -n (details without
hex dump), and -v (full verbose output).
It might be nicer to use -d to enable the dump, rather than have it on
by default.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that the EFI app supports booting Ubuntu via the EFI bootmeth, add
a test for this, for ARM. This uses the sjg lab.
Series-to: concept
Series-cc: heinrich
Cover-letter:
efi: app: Support booting an OS
This series completes the work to get the EFI app booting an EFI
application (e.g. Ubuntu):
- efidebug dh now works, and is slightly enhanced
- device paths which refer to the underlying EFI layer can now be
requested by the app
- a test is provided, for EFI on ARM booting into Ubuntu using the sjg
lab
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-links: 1:12
If only a single test runs, it does not set the max_count variable, so
it remains as zero. Handle this situation as a special case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Binman needs access to tools like mkimage and cbfstool to run all the
tests. Set up the TOOLS_DIR earlier and allow use of a TOOLS_DIR
environment variable to specify where the tools are. This can be used
from CI, for example.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pytest shows about 10 lines of output of limited merit at the top. Use
the -q flag to request that it doesn't so that the actionable things are
more visible.
Signed-off-by: Simon Glass <sjg@chromium.org>
