Our last sync with the kernel was 5.1. Even that was a partial one
as some patches from 4.x kernels were already missing making the
transition to a modern kbuild infeasible.
We are so out of sync now, that tracking the patches and backporting
them one by one makes little sense and it's going to take ages.
This is an attempt to sync up Makefile[.lib/.kbuild].
Unfortunately due to sheer amount of patches this is not easy to review,
but that's what we decided during a community call.
One of the biggest changes is get rid of partial linking entirely and
build .a archives isntead of .o.
We diaviate from the kernel on that. Instead of calling a custom script
to create the archive symbol table, we call ar with rcTP (isntead of
rcSTP) since we want a resulting archive that's sauble with the linker.
The only affected platforms are PPC ones. Unfortunately I don't have any
of them around to test, but the objdump of the resulting files --
arch/powerpc/lib/built-in.[oa] looks identical.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This option is very useful for A/B boot setups with read-only
filesystems: Letting U-Boot fill in the rootfs (and possibly related
parameters) allows keeping all boot parameters except the actual slot
selection in the extlinux.conf file, where they can be updated easily.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Cc: Tom Rini <trini@konsulko.com>
Sughosh Ganu <sughosh.ganu@linaro.org> says:
The LMB module has a bunch for API's which are used for allocating
memory. There are a couple of API's for requesting memory, and two
more for reserving regions of memory. Replace these different API's
with a single one, lmb_alloc_mem(). The type of allocation to be made
is specified through one of the parameters to the function.
Additionally, the two API's for reserving regions of memory,
lmb_reserve() and lmb_alloc_addr() are the same with one
difference. One can reserve any memory region with lmb_reserve(),
while lmb_alloc_addr() actually checks that the memory region being
requested is part of the LMB memory map. Reserving memory that is not
part of the LMB memory map is pretty futile -- the allocation
functions do not allocate memory which has not been added to the LMB
memory map.
This series also removes the functionality allowing for reserving
memory regions outside the LMB memory map. Any request for reserving a
region of memory outside the LMB memory map now returns an -EINVAL
error.
Certain places in the common code using the LMB API's were not
checking the return value of the functions. Checks have been added for
them. There are some calls being made from the architecture/platform
specific code which too do not check the return value. Those have been
kept the same, as I do not have the platform with me to check if it
causes any issues on those platforms.
In addition, there is a patch which refactors code in
lmb_overlaps_region() and lmb_can_reserve_region() so that both
functionalities can be put in a single function, lmb_overlap_checks().
Finally, a new patch has been added which checks the return value of
the lmb allocation function before copying the device-tree to the
allocated address.
Link: https://lore.kernel.org/r/20250617104346.1379981-1-sughosh.ganu@linaro.org
[trini: Rework arch/arm/mach-snapdragon/board.c merge]
Signed-off-by: Tom Rini <trini@konsulko.com>
The LMB module has undergone significant changes in the recent
past. Add a document which briefly describes what the LMB module does,
and the changes that have been made to it's design since the 2025.01
release.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmhZtLAACgkQFHw5/5Y0
tyyl/gv+LLsF/PdBp93gXaUVFQwh3lrAWltjK6n+gKDpIazlX8Ajiu2tFBzYgBdP
JNp3PsHJ8ER/GpU4nG/13KfWg8c4CGvAqY0zLxKufMckBdZAE5EwztvSNzZKZA6f
5FQCecidpwlWBNZRWVbxAAtl83nGBwUmgPAoxDBv4I7DQBJD7mJfzxVnWZuwSioP
ix3aingjRSIUpldHR5IAQfEmnPPfv7IS6EYb2lOoV22WtTfnF6bpteR/2OUxnW6z
YxXHaZrDkIfE+gXYOQu5Tau8R0ca4l+ws8GaocTD9VVCDem8JU7b0GCfoXg+ry2Q
dLYuROREeiXEi14I6arZznpPQM8iIAeDOy0w5b3qXbav0+GWB4rmJKLMniD5JT2r
r8Kle/QeagILMVPOaUVgjmkEnft4thD14ipvr8kUCurUh1VtFYWTGzKVS47yHaxY
I1zQaz1NNdtyQNWO/Nwbs+88C7v8q7DeLIIjUt2/J01Bu8ouf2WyfG04iBeZOitt
CxBZ++2z
=e4ez
-----END PGP SIGNATURE-----
Merge tag 'v2025.07-rc5' into next
Prepare v2025.07-rc5
With this merge, tighten up the LTO_FLAGS removal we added to not
trigger on ARMv7 (which is Thumb-2 and should be fine).
This will allow arch(s) that use device tree blobs to pad the end of the
device tree so they can be modified by board files at run time. This will
help prevent errors such as FDT_ERR_NOSPACE from occurring.
Signed-off-by: Eric Schikschneit <eric.schikschneit@novatechautomation.com>
[trini: Change default order so that X86 && EFI_APP works correctly]
Martin Schwan <m.schwan@phytec.de> says:
This series implements a new bootmeth for RAUC A/B systems. RAUC (Robust
Auto Update Controller) is a lightweight update client, providing "Safe
and Secure OTA Updates for Embedded Linux". See the following links for
more information about RAUC:
https://rauc.io/https://rauc.readthedocs.io/en/latest/
PHYTEC uses RAUC in its Yocto based distribution "Ampliphy" as the
default way of updating embedded devices based on PHYTEC hardware. So
far, the logic selecting the correct partitions and files to boot was
being implemented in the U-Boot environment. While this is a
straightforward way to do it, adding and supporting new platforms became
somewhat tedious and is platform-specific. The introduction of U-Boot's
"Standard Boot" provided a convincing alternative, promising a simpler
and more portable way of booting, even for RAUC systems. This led me to
implement a new bootmeth supporting RAUC A/B systems. Note, that this
new bootmeth is not proprietary to PHYTEC products and is designed to
work on other hardware with a RAUC A/B system, too.
The bootmeth currently only supports symmetric A/B partitioning layouts.
E.g. A/rescue is not (yet) supported. The partition indexes and default
slot tries can be specified via configuration options.
For now, the bootmeth_rauc uses a similar approach for loading the
Kernel and device tree as the bootmeth_script, in that it requires a FIT
containing a U-Boot script loading the desired distro. It could be
possible to support booting without a script and load the Kernel and DT
directly with this bootmeth, but I found the script method to be very
flexible for now, in letting the distro decide what to load.
The bootmeth_rauc was tested on a phyBOARD-Pollux i.MX8M Plus [1] with
BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 [2].
Supported boot devices are currently only MMC devices, but it should be
possible to add SPI flashes in the future.
To test this patch stack with PHYTEC's phyBOARD-Pollux i.MX8M Plus
board, you need to adjust the boot files to include the boot.scr.uimg
containing the distro's boot script and set "optargs" to "${raucargs}"
in it. Also disable any legacyboot in the U-Boot environment and simply
boot with Standard Boot:
bootmeth order rauc
bootflow scan -lb
[1]: https://www.phytec.eu/en/produkte/single-board-computer/phyboard-pollux/
[2]: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/
Link: https://lore.kernel.org/r/20250604-wip-bootmeth-rauc-v3-0-f9fad913c57e@phytec.de
[trini: Don't enable by default]
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>
Add support for left, right and centred alignment for text, in the
horizontal dimension.
Also support top, bottom and centred in the vertical dimension, for the
text object as a whole.
Alignment is not yet implemented for images. It has no meaning for
menus. A textline object uses a text object internally, so alignment
is supported there.
Provide some documentation to explain how objects are positioned.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to draw a box around elements in the menu. Add
support for an unfilled box with a selectable thickness.
Note that there is no support for selecting the colour for any expo
objects yet.
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>
This function is sometimes useful outside tests. Also it can affect how
terminal output is done, e.g. whether ANSI characters should be emitted
or not.
Move it out of the test_util package and into terminal.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases we have alternative configuration options that supply the
same functionality, e.g CONFIG_NET and CONFIG_NET_LWIP.
Allow to specify all of them as arguments for buildconfigspec() and execute
the text if any of these is fulfilled, e.g.
@pytest.mark.buildconfigspec('net', 'net_lwip')
Update the documentation.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
After the original series was merged, Quentin noted that we could handle
adding additional tests more easily by using the glob feature. Do so.
Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Add this test to the documentation. No changes to the test itself were
required.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add this test to the documentation. There was already a function comment
that included the argument, so convert it to the right style to be
rendered correctly in output.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add this test to the documentation. None of the functions had comments,
so attempt to explain what each does.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add this test to the documentation. We need to add a code-block
annotation to the example and indent it correctly. We also need to
document the do_test_efi_helloworld_net function and that in turn means
changing the documentation to test_efi_helloworld_net_http and
test_efi_helloworld_net_tftp to reflect what is and isn't done in those
functions themselves now.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add this test to the documentation. We need to move the import to follow
the main comment so that it renders correctly, and add a code-block
annotation to the example and indent it correctly. Next, neither of the
functions had comments themselves, so document them now.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add this test to the documentation. While the diff appears large at
first, the only changes within the test are to move the imports to
follow the pydoc comment and then to code-block and indent the example
configuration.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the test_net_boot.py test to the generated documentation. While most
of this was already commented correctly for inclusion the biggest
problem was examples of code without a code-block notation. This in turn
broke parsing. Add the missing notations. We also must have the comment
prior to any import lines or it will not be seen as a comment on the
overall file and thus not included.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to easily document pytests, we need to include the autodoc
extension. We also need to make sure that for building the docs, CI
includes pytest and that we have PYTHONPATH configured such that it will
find all of the tests and related files. Finally, we need to have our
comments in the test file by in proper pydoc format in order to be
included in the output.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Begin the work of documenting all of our pytests. To do this, we should
have a directory under develop for it as there will be a large number of
new files. As the current document is referenced externally in a number
of locations, add the sphinx_reredirects module so that we can redirect
from the old location to the new.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The scripts u-boot-test-release is called at the end of testing.
Describe it.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Using power cycling is a valid option to implement u-boot-test-reset.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Using some form of sandbox with Python modules is a long standing best
practice with the language. There are a number of ways to have a Python
sandbox be created. At this point in time, it seems the Python community
is moving towards using the "venv" module provided with Python rather
than a separate tool. To match that we make the following changes:
- Refer to a "Python sandbox" rather than virtualenv in comments, etc.
- Install the python3-venv module in our container and not virtualenv.
- In our CI files, invoke "python -m venv" rather than "virtualenv".
- In documentation, tell users to install python3-venv and not
virtualenv.
Signed-off-by: Tom Rini <trini@konsulko.com>
Use only a single -machine parameter.
Describe that the same invocation of qemu-system-<arch> has to be
used for dumping the device-tree as will be used when executing U-Boot.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
To avoid the problem fixed in commit 57a95d522ca8 ("doc: release_cycle:
fix next release version") moving forward, make use of the variable
substitution feature of rST. This adds a next_ver variable and
references it in all of the places where I had been listing the version
being worked on.
Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
Expand the conditional compilation section to explain when to use
CONFIG_IS_ENABLED rather than IS_ENABLED and provide an example. Next,
note what the PHASE_ macro is supposed to be used for as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
In order to make a start on explaining how and when to use certain
macros, we need to document their usage somewhere. As a first step, take
section 21 of the v6.13 Linux Kernel coding-style document on
conditional compilation, verbatim, and add it to our documentation.
Further rewording to be clearer about U-Boot will be done next.
Signed-off-by: Tom Rini <trini@konsulko.com>
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we moved out the capsule signature from the DTB, remove the
relevant documentation.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
`.priv_data_size` does not exist. I believe the actual structure member
was supposed to be `.priv_auto`.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Neha Malcom Francis <n-francis@ti.com> says:
This short series is an ongoing effort to make RAM utilization clearer for
easier debugging and understanding of code. Intention is for users to quickly
be able to identify the CONFIGs needed to modify for their RAM usecase.
Link: https://lore.kernel.org/r/20250319140327.301266-1-n-francis@ti.com
