Provide more timing information for expo operation, including the time
taken to:
- render the scene
- sync the framebuffer to the display
- poll for keyboard / mouse input
These are averages calculated over the past second.
Update the documentation to mention these features.
Signed-off-by: Simon Glass <sjg@chromium.org>
In test mode, show the FPS (frames per second) below the frame count.
This is helpful for performance monitoring during development.
The FPS calculation averages over the last 5 seconds to provide a
stable reading.
Add a test for the FPS calculation logic as well.
Mention expo's test mode in the documentation.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide some developer documentation on the priority feature for global
bootmeths.
Series-changes: 2
- Add a bit more detail suggested by Heinrich
Series-to: concept
Series-cc: heinrich
Cover-letter:
boot: Support priority for global bootmeths
At present global bootmeths always run first, before all other
bootmeths. Optimisations in the code take advantage of this, putting
them at the end, so they can be used once and then forgotten.
In some cases it is useful to run global bootmeths later in the boot.
For example, the EFI-bootmgr bootmeth may itself scan devices and the
network, so running it first can hold up the boot significantly for
boards not actually relying on EFI-bootmgr to boot.
This series introduces a new field in global bootmeths which indicates
the priority, using the same scheme as is used with bootdev hunters.
Thus it is possible to insert the EFI-bootmgr bootmeth just before the
hunter for network bootdevs is invoked.
Despite the simplicity of the concept and the relatively small series,
this is a fairly significant enhancement. It is also quite tricky to
implement, largely due to the way the original code was written, with
global bootmeths being a small, size-optimised add-on to the original
bootstd implementation.
For now we only allow each global bootmeth to run at most once, but this
implementation is written in a way that we could relax that if needed.
Then the bootmeth itself could decide whether to run at any particular
point in the bootflow iteration.
Size growth is about 390 bytes on Thumb2 (e.g. firefly-rk3288) if
CONFIG_BOOTMETH_GLOBAL is enabled, which it normally is. With that
disabled (which saves about 4K on the same platform), there is no
growth.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-links: 1:41
Series-version: 2
At present boxes are not supported in the expo_build format. Also, it is
now possible to draw filled boxes, a recently added feature to the video
API.
Expand the box feature slightly to resolve these two items.
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 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>
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 documentation to point to the examples.
Series-to: concept
Cover-letter:
ulib: Provide examples for building outside the tree
The ulib tests are built within the U-Boot build system, so make use of
various settings which are provided.
When using ulib outside the U-Boot tree (and outside its build
environment), things are a little more tricky.
This series provides a few simple examples to illustrate how to make
it work. An example Makefile is provided as well.
The same Makefile is used from CI just to ensure that it continues to
work as expected.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Add documentation for the U-Boot Library (ulib) feature, explaining how
to build and use both shared (.so) and static (.a) libraries.
Series-to: concept
Cover-letter:
ulib: Provide test programs and documentation
This series completes the implementation of a basic U-Boot library:
- ensure that no output is written during init
- provide a static library to match the existing shared library
- add test programs for both, to ensure they continue to build correctly
- provide documentation to describe how to use the libraries
This is still very early in the implementation, but this series provides
enough for some initial experimentation.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-links: 1:25
Set a deadline of the end of 2027 for removal of what is now the legacy
API.
Series-to: concept
Series-cc: heinrich
Cover-letter:
api: Deprecate the API
The existing U-Boot API is quite old and doesn't support driver model.
Adding new functions is a manual process and no one has attempted this in
the 10 years that driver model has been present. Undertaking such a task
would be laborious and would require continued effort to maintain.
A better approach would be to create a library containing all of U-Boot, then
have the API be generated by a script from a list of functions. This would
allow for a more flexible and maintainable interface.
In preparation for this new direction, this series renames the existing API
components to clearly mark them as legacy:
- Rename api/ to legacy_api/
- Rename examples/api/ to examples/legacy_api/
- Rename include/api.h and include/api_public.h to include/legacy_api*.h
- Rename API_BUILD to LEGACY_API_BUILD
- Rename CONFIG_API to CONFIG_LEGACY_API
- Rename api_init() to legacy_api_init()
This provides a clean namespace for implementing the new library-based API
approach while maintaining backward compatibility for existing users of the
legacy interface.
This series also sets a deadline for removal of the legacy API.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Describe how this feature works and provide some helpful links.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Quite a few SMBIOS features are not yet described in the documentation.
Add a new section the 'usage' and add more to the developer
documentation, including how to use the devicetree to provide values.
Add some links between usage docs, developer docs and the command.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a note about the pager to the console documentation, with some more
information in the developer section. Also include the pager API.
Series-to: concept
Cover-letter:
Introduce a pager for the console
Some U-Boot commands can produce a lot of output and this can run off
top of the display. This series introduces a simple pager feature, to
allow the output to be read, before pressing SPACE to continue.
A fixed buffer size (4K) is used, which sets a limit on the permmited
output before paging fails and the output is simply written all in one
lot. In most cases this is plenty, but 'env print' does print the whole
environment as one string, so if the legacy distro-boot scripts are used
it could happen.
The default number of visible lines is set with a Kconfig option. Where
a video terminal is being used, the page size is set to match that. In
general U-Boot cannot guess the number of visible lines, since a serial
terminal may be in use.
There is also a 'pager' environment variable which can override any
detected value.
This initial series only counts newlines. It has no support for counting
characters so the result will be sub-optimal if very long lines are
written. This could be addressed in a future patch.
Some effort is made to handle common cases correctly. For example, if
stdout is changed to a serial or vidconsole device, that is used to
determine the page length. When redirecting sandbox to a file, no
attempt is made.
Future work may detect the terminal size by sending an ANSI sequence.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-version: 2
Mention the efidebug command specifically the EFI-app documentaion, to
highlight its usefulness.
Series-to: concept
Series-cc: heinrich
Cover-letter:
efi: Move towards the EFI app booting EFI applications
This series adds various new features to the EFI app, mostly by moving
code over from the EFI loader implementation.
In particular it adds support for the efidebug command (with only a
subset of subcommands so far).
The main approach is to make use of the system table (for both the app
and the loader) instead of directly calling EFI-loader code.
It also includes a few fixes, which likely have no effect but will help
to avoid confusion in future.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-version: 2
Series-changes: 2
- Mention the 'dh' subcommand
- Mention that 'order' allows the boot order to be changed
- Mention the eficonfig command and the underlying UEFI firmware
Series-links: 2:10
Add some information about this new bootmeth, including how to enable it
and how it works.
Series-to: concept
Cover-letter:
boot: Enhance VBE to support a separate devicetree FIT
It is sometimes desirable to have the devicetrees packaged with firware,
or in a different FIT from the OS. This series adds support for this,
including a test.
The new bootmeth can automatically locate a state file and use that to
decide what images to use when booting. The OS must update the file
before rebooting, if a different selection is required.
For now there is no logic to deal with boot failures.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some information about this new bootmeth, including how to enable it
and how it works.
Cover-letter:
boot: Enhance VBE to support a separate devicetree FIT
It is sometimes desirable to have the devicetrees packaged with firware,
or in a different FIT from the OS. This series adds support for this,
including a test.
The new bootmeth can automatically locate a state file and use that to
decide what images to use when booting. The OS must update the file
before rebooting, if a different selection is required.
For now there is no logic to deal with boot failures.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Normally the job itself controls which tests are run, by providing an
optional test spec and using the -k option.
It is sometimes useful to run a subset of tests on CI. Add a new
TEST_SPEC variable to control this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide some additional variables which can be used to deselect whole
stages, or select a particular test.py build.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to test a commit just on the lab, or even just on
a particular board in the lab. Add support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Expand the CI documentation to mention the concept tree. Add a reference
to the page from the build page.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to process just one or two defconfigs and it is
convenient to do this just by listing them in the arguments. Add a -D
option for this.
Update the docs to avoid mentioning boards which have been removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This existing function does not have any context associated with it.
Rename it so that fs_read() can be used for the new FS uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use programmatic boot so that it is possible to boot without
CONFIG_CMDLINE enabled.
Series-to: u-boot
Cover-letter:
emulation: Improve support for booting from QFW
U-Boot supports booting Linux from QFW which means that the kernel and
any initrd are provided on the QEMU command line instead of being found
in boot media.
This series improves this support in several ways:
- Enhances bootstd to implement 'bootflow read', thus allowing the
files to be loaded and inspected (with potential cmdline changes)
before booting
- Updates bootstd to use programmatic boot, so that it works even when
CONFIG_CMDLINE is disabled
- Expands build-qemu script to allow providing cmdline and root disk
It also includes a rough script to time U-Boot when running QEMU with
kvm, making use of the qemu-boot-time repo:
https://github.com/stefano-garzarella/qemu-boot-time.git
END
Signed-off-by: Simon Glass <sjg@chromium.org>
The zboot option is used on x86, so add support for it. Use the
programmatic boot API rather than building a command to run, so that it
can work without CONFIG_CMDLINE
For now the other boot options still use the cmdline.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to read the images into memory without actually
booting the kernel. This allows the cmdline to be changed using
'bootflow cmd', for example. Implement this for the QFW bootmeth.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a place where people can add contributions, along with
documentation. These may be useful to other developers of U-Boot but are
not maintained / supported by the core developers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that pre-relocation devicetree mnipulation uses an event rather than
a weak function, update the docs and remove the function from the init.h
header.
Series-to: u-boot
Cover-letter:
fdt: Use events for pre-relocation devicetree manipulation
At present a weak function is used to modify the devicetree before
relocation. This is not ideal, since it is hard to find out whether a
board provides this function or not.
Another issue is that the fixups happen in multiple places in the init
sequences, with a confusing set of #if checks.
A final issue is that the fixups are done on the flat tree, which can be
quite inefficient.
This series introduces a new event to handle these fixups, converts all
boards and update the docs. The event passes an oftree instead of a
void * so that in future it can support livetree updates.
It would be possible to remove OF_BOARD_FIXUP and just always send the
event, but this would have a small code-size impact on the majority of
boards, since only about 45 use this feature.
END
Add a Kconfig option to easily enable debugging of the app using the
recommended method. Provide some docs too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the links to an embedded style. Also drop the part about needing
to support ARM, as this is done now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add documentation about standard passage and update the maintainers.
Series-changes: 2
- Add detailed arch-specific information
- Add comments about passing a bloblist to Linux
- Add comments about how to pass standard passage to EFI
- Fix 'it' typo
Series-changes: 3
- Fix 'that' typo
- Update docs for the various code changes
Signed-off-by: Simon Glass <sjg@chromium.org>
Change-Id: I91d5b9ae45e8d1081b1e165620ad1946bd69af00
At present it is impossible to change the qemu_arm64 defconfig to
obtain a devicetree from the U-Boot build.
This is necessary for FIT validation, for example, where the signature
node must be compiled into U-Boot.
A proposed change to QEMU to allow device tree additions has been
blocked for several years. The only known workaround is to use QEMU's
dumpdtb option, merge in the signature node manually, disable
OF_HAS_PRIOR_STAGE and then start QEMU with special arguments. This is
complicated enough that it is documented in U-Boot[1].
Unfortunately the only way to disable OF_HAS_PRIOR_STAGE at present is
to hack the Kconfig.
Add a new QEMU_MANUAL_DTB Kconfig option which makes OF_HAS_PRIOR_STAGE
optional, thus avoiding needing to patch U-Boot to get this working.
This seems a clearer solution than just making OF_HAS_PRIOR_STAGE
visible, since that symbol is intended to be set automatically by each
platform.
Series-to: u-boot
Series-cc: trini
Series-cc: Peter Maydell <peter.maydell@linaro.org>
Series-cc: Andrew Phelps <andrew.phelps@canonical.com>
Series-cc: ilias
Series-changes: 2
- Add a new QEMU-specific Kconfig instead
- Move patch into the standard-passage series
Series-changes: 3
- Fix 'usiing' typo
- Add mention of QEMU_MANUAL_DTB in doc/
[1] https://docs.u-boot.org/en/latest/develop/devicetree/dt_qemu.html
Link: https://patchwork.kernel.org/project/qemu-devel/patch/20210926183410.256484-1-sjg@chromium.org/#24481799
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Now that these files are within the repo, link the documentation to the
normal U-Boot documentation. Update directory paths and convert it to
rST format.
Signed-off-by: Simon Glass <sjg@chromium.org>
Create a Kconfig which indicates that EFI functionality is in use,
either as a client (EFI app / stub) or provider (EFI loader). This will
make it easier to share code between these two parts of U-Boot
Signed-off-by: Simon Glass <sjg@chromium.org>
The generic name 'EFI' would be more useful for common EFI features. At
present it just refers to the EFI app and stub, which is confusing.
Rename it to EFI_CLIENT
Signed-off-by: Simon Glass <sjg@chromium.org>
This directory was created when U-Boot gained the ability to run as an
EFI app in 2015. Since then the EFI-loader feature has been added.
The code in lib/efi is not actually used by the loader, so the name is
confusing.
Rename the directory to efi_client to indicate that it includes files
just for U-Boot being a client of EFI, i.e. the EFI app and stub.
Signed-off-by: Simon Glass <sjg@chromium.org>
Insets are handled inconsistently at present, since menus use them to
offset the label text, whereas textlines don't. This is done because
menus need the margin to be visible when opened. However this causes an
alignment issue when menus and textlines appear in the same cedit.
Remove the offsets from menus and compensate by adjusting the bounding
boxes used for highlighting and the opened menu.
Line up menu items and textlines vertically and add a style option for
textlines to control how much padding is added.
Add a test to check the positions of objects in a cedit, since this is
more direct than the rendering tests. Add style information so that the
impact can be seen.
Signed-off-by: Simon Glass <sjg@chromium.org>
Describe the new subcommands and how they should be used in a normal
workflow.
Note that the naming of branches is very rigid, or 'opinionated' in
marketing terms. Patman can track a single branch for each version of a
series and they must all be named the same, except for the
version-number suffix. Version 1 series have no suffix.
This description is fairly bare-bones but should be enough for some
initial testing and comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
The .py extension isn't very useful. Drop it and update the shebang to
specify Python 3
Update the docs for this and also drop the old reference to 2021 images.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to edit text, e.g. to allow the user to edit the
environment or the command-line arguments for the OS.
Add the beginnings of an implementation. Future work is needed to finish
this: keypress handling and scrolling. For now it just displays the
text.
Signed-off-by: Simon Glass <sjg@chromium.org>
