| Age | Commit message (Collapse) | Author |
|---|
|
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
|
|
Take account of the new XPL_ and PHASE_ instead of the old SPL_ and
SPL_TPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Now that SPL means SPL (only) and is not defined for other phases,
update kconfig rules.
This is done in one patch since otherwise many Binman tests fail.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Complete this rename for all directories outside arch/ board/ drivers/
and include/
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This now appears in the code base, so add it to the list of ignored
symbols in qconfig
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
The TF-A URL was updated, as a result the name of the
directory changed as part of the new git URL and not
all the referenced directories were updated.
Fixes: 0ec0207fe07 ("Update the ARM trusted firmware git URL")
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
|
|
The primary upstream URL for tf-a has moved, in some cases
things like tags are not always pushed to the old URL so
update the URLs to the primary upstream project URL.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
|
|
Adds support for the secp521r1 ECDSA algorithm to mkimage.
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This patch is for Marek, to provide a starting point.
To try it, use 'binman test -T' and see the missing coverage.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Some images do not have an image_pos value, for example an image which
is part of a compressed section and therefore cannot be accessed
directly.
Handle this case, returning None as the value.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move the check for this further out, so that base_addr is computed in
Entry.WriteSymbols() rather than at lower levels.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The base address of the ELF containing symbols is normally added to
any symbols written, so that the value points to the correct address in
memory when everything is loaded. When the binary resides on disk, a
different offset may be needed, typically 0. Provide a way to specify
this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a clarification to the documentation and add a missing comment. Also
update the test so that when it fails it is easier to see what is going
on, rather than having to decode hex strings.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These functions get the value of a symbol. The reference to ELF files
is confusing since they are reading the position/size of entries, not
ELF symbols. Rename the functions and adjust the comments also.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
With OF_UPSTREAM the dts files are in an SoC-specific subdirectory,
meaning that the resulting dtb files all end up in a similar
subdirectory.
We don't want the subdirectory name to appear as a node name in the FIT,
so handle this as a special case.
Also the default devicetree may have a directory-name prefix, so handle
that when searching through the available devicetree files.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The section etype has its own implementation of SetImagePos(), most of
which is not useful since the code is included here. So call
Entry.SetImagePos() which has the only piece of this which we actually
want.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Use the more generic variable name 'entry' to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Since the files are known to be in the provided directory, use that
instead of requiring it to be added to the list of input directories.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Two places set this attribute directly. Update them to use the function
provided.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Update this entry type to resolve some pylint warnings and make sure
that functions and members are fully commented.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Improve the comments for this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This returns stdout, not a CommandResult so update the comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add tests for missing tools to complete the test coverage for this
etype.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
For most boards, the device-tree compiler is built in-tree, ignoring the
system version. Add a special option to skip this build. This can be
useful when the system dtc is up-to-date, as it speeds up the build.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Buildman retries a failed build when processing a branch, but does not
do this when building current source. It is useful to do this retry in
both cases, so add the logic for it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Jerome Forissier <jerome.forissier@linaro.org> says:
Miscellaneous fixes made when developing the lwIP series [1]. They are
posted separately since they make sense on their own. Subsequent
versions of the lwIP series will contain a squashed version of this one.
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=420712&state=%2A&archive=both
|
|
When building for sandbox, self.cross is empty.
In MakeEnvironment(), CROSS_COMPILE is defined to be self.cross (with
or without a full path), optionally prefixed by the toolchain wrapper
defined in ~/.buildman. This is fine when self.cross is not empty, but
it doesn't make sense when it is:
- Either there is no wrapper and we end up with an empty CROSS_COMPILE
which is the same as not defining it (the host compiler will be used),
- Or there is a wrapper and CROSS_COMPILE will contain only the wrapper
which obviously is not a valid compiler, hence an error.
Test case:
$ sudo apt install ccache
$ grep -q toolchain-wrapper ~/.buildman || \
printf "[toolchain-wrapper]\nwrapper = ccache\n" >>~/.buildman
$ make mrproper
$ ./tools/buildman/buildman sandbox_noinst
$ ./tools/buildman/buildman sandbox_noinst
Building current source for 1 boards (1 thread, 24 jobs per thread)
sandbox: + sandbox_noinst
+arch/sandbox/lib/reloc_sandbox_efi.c:10:15: error: operator '==' has no left operand
+ 10 | #if HOST_ARCH == HOST_ARCH_X86_64
+ | ^~
[...]
The GetEnvArgs function is modified too, since the VAR_CROSS_COMPILE
case has the same issue.
In tools/buildman/test.py, testGetEnvArgs is extended and
testMakeEnvironment is added. They check the 'arm' and 'sandbox'
toolchains, with and without a wrapper.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Prepare v2024.10-rc5
|
|
When linking to our documentation for submitting patches, we shouldn't
point at the old wiki but instead our current documentation.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Add support for generating GUIDs that match those generated internally
by U-Boot for capsule update fw_images when using dynamic UUIDs.
Dynamic UUIDs in U-Boot work by taking a namespace UUID and hashing it
with the board compatible and fw_image name. This feature just provides
a way to determine the UUIDs for a particular board without having to
actually boot U-Boot on it.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Replace the use of libuuid with U-Boot's own UUID library. This prepares
us to add support for generating v5 GUIDs.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Migrate sandbox over to generating it's capsule update image GUIDs
dynamically from the namespace and board/image info. Update the
reference and tests to use the new GUIDs.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
This let's us forward declare efi_guid_t in the UUID code without
pulling in efi.h
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
The Python virtualenv tool sets up a few things in the environment,
putting its path first in the PATH environment variable and setting up
a sys.prefix different from the sys.base_prefix value.
At present buildman puts the toolchain path first in PATH so that it can
be found easily during the build. For sandbox this causes problems since
/usr/bin/gcc (for example) results in '/usr/bin' being prepended to the
PATH variable. As a result, the venv is partially disabled.
The result is that sandbox builds within a venv ignore the venv, e.g.
when looking for packages.
Correct this by detecting the venv and adding the toolchain path after
the venv path.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Prepare v2024.10-rc4
|
|
This is not allowed, so use ljust() instead. This fixes the
'qconfig -i -I help' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 1bd43060b3e ("moveconfig: Use f strings where possible")
|
|
Python strings have their own notion of backslash-escaping, and that can
conflict with the intentions for strings passed to the 're' module. In
particular, I get warnings like this:
tools/patman/../patman/commit.py:9: SyntaxWarning: invalid escape sequence '\s'
re_subject_tag = re.compile('([^:\s]*):\s*(.*)')
We should use a raw string (r'...') so that all escaping is passed into
the regex module, not interpreted within the string itself.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The Linux kernel documentation has transitioned from using
kconfig-language.txt to kconfig-language.rst. Therefore update all
occurrences of kconfig-language.txt.
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
|
|
Newer versions of filelock use time.monotonic() instead of time.time().
Update the test the handle this.
It would be better if filelock had support for writing unit tests which
use locking.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
uint64_t is defined as unsigned long long on 32-bit ARM.
Use PRIX64 for printing uint64_t.
This avoid a build failure on 32-bit systems:
tools/mkeficapsule.c: In function 'dump_capsule_auth_header':
tools/mkeficapsule.c:694:66: warning: format '%lX' expects argument of
type 'long unsigned int', but argument 2 has type 'uint64_t'
{aka 'long long unsigned int'} [-Wformat=]
694 | printf("EFI_FIRMWARE_IMAGE_AUTH.MONOTONIC_COUNT\t\t: %08lX\n",
| ~~~~^
| |
| long unsigned int
| %08llX
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
|
|
This primarily updates our python cache.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Using "MAINTAINER" and "Description" have been replaced with
org.opencontainers.image namespace variables.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Part of the upower management was included in a previous commit [1].
This patch only adds the bits required to properly parse a config file
that would include the binary as follows:
IMAGE PWR upower.bin
[1] 6ec65c8558f (tools: image: support i.MX93)
Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
|
|
Currently the ULP token sets the soc as IMX9, making it impossible to
differentiate the two families of processors.
However, since the 8ULP requires specific binaries like upower which do
not exist in 93, they need to be separated.
Fixes: 6ec65c8558f (tools: image: support i.MX93)
Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
|
|
This updates the "old style" DTs to that of Linux v6.10, matching what
OF_UPSTREAM is at now. Hopefully we won't need to do this (manually)
anymore. Since this brings in the DT for a new board (Tanix TX1), also
add the defconfig for that, which has just been waiting for that sync.
There are three more fixes: two for the SPI clock setup, which avoids
too high frequencies in some cases, and one fix to avoid a build warning
with GCC 14 for the sunxi TOC0 part of the mkimage tool.
The gitlab CI passed, and I tested the SPI flash on the OrangePi Zero 3
and also booted that into Linux.
|
|
C99 introduced the possibility to mark function parameters declared as
arrays with an extra keyword "static":
void foo(uint8_t digest[static SHA256_DIGEST_LENGTH]);
This requires the respective function argument to be at least as large
as specified. Passing in random pointers (like NULL) then becomes
undefined behaviour, and compilers warn about this.
Newer GCC compilers (starting with GCC 14) will also automatically mark
those parameters as "nonnull", and thus warn if a (redundant) NULL check
is done inside the function:
tools/sunxi_toc0.o tools/sunxi_toc0.c
tools/sunxi_toc0.c: In function 'toc0_verify_cert_item':
tools/sunxi_toc0.c:447:12: warning: 'nonnull' argument 'digest' compared to NULL [-Wnonnull-compare]
447 | if (digest && memcmp(&extension->digest, digest, SHA256_DIGEST_LENGTH)) {
| ^
Remove the unnecessary NULL check from toc0_verify_cert_item(), to avoid
the warning.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: extend commit message]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
There is no need to remove input files. It makes it harder to diagnose
failures. Keep the payload file.
There is no test for this condition, but one could be added.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
|
