| Age | Commit message (Collapse) | Author |
|---|
|
Add new etype which generates the Renesas R-Car Gen4 SA0 header.
This header is placed at the beginning of SPI NOR and describes
where should data from SPI NOR offset 0x40000 be loaded to, and
how much data should be loaded there. In case of U-Boot, this is
used to load SPL and possibly other payload(s) into RT-VRAM.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
pkg_resources is deprecated, use migration guide in [1] to migrate to
importlib.resources.
Keep the Python 3.6 backwards compatibility.
This also fixes the binman version test which failed for setuptools
versions that print the deprecation warning.
Change from __name__ to __package__ as with the transition from
pkg_resources to importlib_resources using __name__ results in
TypeErrors [2].
[1] https://importlib-resources.readthedocs.io/en/latest/migration.html
[2] https://github.com/python/importlib_resources/issues/60
Reviewed-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
|
|
Commit 93b55636b09f ("tools: kwboot: Allow any baudrate on Linux") added a
tcgetattr() function to be used, instead of the libc's termios functions.
This was done to allow using the raw TCGETS2/TCSETS2 ioctls that allow to
support arbitrary baud rates.
This breaks the build for PowerPC, because that architecture does not have
a struct termios2 defined because the termios and ktermios are the same.
On PowerPC, the termios ioctl() emulates the TCGETS2/TCSETS*2 ioctls with
tcgetattr/tcsetattr using just the struct termios (that's as mentioned the
same than what is defined as struct termios2 in other architectures).
So there is no need to use the TCGETS2/TCSETS2 ioctls on that architecture
and just TCGETS/TCSETS ioctls with termios as defined by PowerPC is enough.
Fixes: 93b55636b09f ("tools: kwboot: Allow any baudrate on Linux")
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
This series from Ilias Apalodimas <ilias.apalodimas@linaro.org> largely
finishes the re-sync with the Linux Kernel v5.1 kbuild system.
Link: https://lore.kernel.org/r/20250627185723.342553-1-ilias.apalodimas@linaro.org
|
|
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>
|
|
|
|
key-name-hint in signature nodes"
Quentin Schulz <foss+uboot@0leil.net> says:
I misunderstood the documentation and put the signing key in a keys/
directory while setting key-name-hint property in the signature node and
u-boot-spl-pubkey-dtb to a path.
mkimage doesn't fail if it cannot find the public key when signing a
FIT but returns something on stderr to notify the user it couldn't find
the key. The issue is that bintool currently discards stderr if the
command successfully returns, so the FIT is not signed AND the user
isn't made aware of it unless the image is manually inspected.
mkimage does fail when trying to insert a public key in a DTB if it
isn't found but we can have a better error message.
Link: https://lore.kernel.org/r/20250418-binman-pubkey-dir-v2-0-b6b90a765ffe@cherry.de
|
|
key-name-hint with path
key-name-hint property in u-boot-spl-pubkey-dtb binman entry may contain
a path instead of a filename due to user mistake.
Because we currently assume it is a filename instead of a path, binman
will find the full path to the key based on that path, and return the
dirname of the full path but keeps the path in key-name-hint instead of
stripping the directories from it.
This means mkimage will fail with the following error message if we have
key-name-hint set to keys/dev:
binman: Error 1 running 'fdt_add_pubkey -a sha256,rsa2048 -k /home/qschulz/work/upstream/u-boot/keys -n keys/dev -r conf /home/qschulz/work/upstream/u-boot/build/ringneck/u-boot-spl-dtbdhsfx3mf': Couldn't open RSA certificate: '/home/qschulz/work/upstream/u-boot/keys/keys/dev.crt': No such file or directory
Let's make it a bit more obvious what the error is by erroring out in
binman if a path is provided in key-name-hint (it is named key-name-hint
and not key-path-hint after all).
Fixes: 5609843b57a4 ("binman: etype: Add u-boot-spl-pubkey-dtb etype")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
mkimage doesn't fail if it cannot find the public key but it prints to
stderr. Considering that btool.run() discards stderr, it means binman
happily returns an unsigned FIT and doesn't tell you something went
wrong.
Binman will actually find the file if there's a path in the
key-name-hint property but the current logic expects key-name-hint to be
a filename and thus returns the dirname of the found path for the key,
but with the original key-name-hint appended. This means we can have the
following:
- key-name-hint = "keys/dev"
- name = "/home/qschulz/work/upstream/u-boot/keys/"
so we pass /home/qschulz/work/upstream/u-boot/keys/ to the -k option of
mkimage but the FIT still contains "keys/dev" in key-name-hint which
means mkimage will try to find the key at
/home/qschulz/work/upstream/u-boot/keys/keys/, which doesn't exist.
Let's assume paths are simply not supported (it is named key-name-hint
and not key-path-hint after all) and raise an error if the property
contains a path so that the build fails and not quietly.
Fixes: 133c000ca334 ("binman: implement signing FIT images during image build")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Allow -w to be used with -i to do a build without a separate output
directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This option doesn't work as expected since it sets the cwd to the work
directory, which does not necessarily hold the source code.
It should be left unset, so that the current directory is the source
directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
When this utility was converted from run_pipe and to the new output
helper, two problems were introduced. First, the conversion for calling
"git rm -f" wasn't correct. Change this to match the other conversions.
Second, the final call we do we need to construct the list because we
print that command for the user to use to inspect remaining references.
Fixes: 3d094ce28a22 ("u_boot_pylib: Add a function to run a single command")
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Background:
I have several customers that will be using a certain remote signing
service for signing their images, in order that the private keys are
never exposed outside that company's secure servers. This is done via
a pkcs#11 interface that talks to the remote signing server, and all
of that works quite well.
However, the way this particular signing service works is that one
must upfront create a "signing session", where one indicates which
keys one will use and, importantly, how many times each key will (may)
be used. Then, depending on the keys requested and the customer's
configuration, one or more humans must authorize that signing session
So for example, if official release keys are to be used, maybe two
different people from upper management must authorize, while if
development keys are requested, the developer himself can authorize
the session.
Once authorized, the requester receives a token that must then be used
for signing via one of the keys associated to that session.
I have that integrated in Yocto in a way that when a CI starts a BSP
build, it automatically works out which keys will be needed (e.g. one
for signing U-Boot, another for signing a kernel FIT image) based on
bitbake metadata, requests an appropriate signing session, and the
appropriate people are then notified and can then look at the details
of that CI pipeline and confirm that it is legitimate.
The problem:
The way mkimage does FIT image signing means that the remote server
can be asked to perform a signature an unbounded number of times, or
at least a number of times that cannot be determined upfront. This
means that currently, I need to artificially say that a kernel key
will be used, say, 10 times, even when only a single FIT image with
just one configuration node is created.
Part of the security model is that once the number of signings using a
given key has been depleted, the authorization token becomes useless
even if somehow leaked from the CI - and _if_ it is leaked/compromised
and abused before the CI has gotten around to do its signings, the
build will then fail with a clear indication of the
compromise. Clearly, having to specify a "high enough" expected use
count is counter to that part of the security model, because it will
inevitably leave some allowed uses behind.
While not perfect, we can give a reasonable estimate of an upper bound
on the necessary extra size by simply counting the number of hash and
signature nodes in the FIT image.
As indicated in the comments, one could probably make it even more
precise, and if there would ever be signatures larger than 512 bytes,
probably one would have to do that. But this works well enough in
practice for now, and is in fact an improvement in the normal case:
Currently, starting with size_inc of 0 is guaranteed to fail, so we
always enter the loop at least twice, even when not doing any signing
but merely filling hash values.
Just in case I've missed anything, keep the loop incrementing 1024
bytes at a time, and also, in case the estimate turns out to be over
64K, ensure that we do at least one attempt by changing to a do-while
loop.
With a little debug printf, creating a FIT image with three
configuration nodes previously resulted in
Trying size_inc=0
Trying size_inc=1024
Trying size_inc=2048
Trying size_inc=3072
Succeeded at size_inc=3072
and dumping info from the signing session (where I've artifically
asked for 10 uses of the kernel key) shows
"keyid": "kernel-dev-20250218",
"usagecount": 9,
"maxusagecount": 10
corresponding to 1+2+3+3 signatures requested (so while the loop count
is roughly linear in the number of config nodes, the number of
signings is quadratic).
With this, I instead get
Trying size_inc=3456
Succeeded at size_inc=3456
and the expected
"keyid": "kernel-dev-20250218",
"usagecount": 3,
"maxusagecount": 10
thus allowing me to set maxusagecount correctly.
Update a binman test case accordingly: With the previous behaviour,
mkimage would try size_inc=0 and then size_inc=1024 and then
succeed. With this patch, we first try, and succeed, with 4*128=512
due to the four hash nodes (and no signature nodes) in 161_fit.dts, so
the image ends up 512 bytes smaller.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
|
|
supernodes"
Moteen Shah <m-shah@ti.com> says:
In the U-Boot pre-relocation stage, if the parent node lacks
bootph-all/bootph-some-ram property and the driver lacks a pre-reloc
flag, all of its subsequent subnodes gets skipped over from driver
binding—even if they have a bootph* property.
This series addresses the issue by scanning through all the nodes during
build time and propagating the applicable property to all of its supernode.
Link: https://lore.kernel.org/r/20250516114148.3862114-1-m-shah@ti.com
|
|
Add a testcase to ensure that scan_and_prop_bootph() actually
propagates bootph-* properties to supernodes.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
to supernodes
As per bootph schema, bootph-* property in child node should be
implied in their parent, but this feature is not implemented in
the U-Boot proper stage (before relocation) resulting in devices
not being bound because of the missing bootph-all or bootph-some-ram
property in the parent node.
To mitigate this issue, add a function to scan through all the nodes
in the device-tree for bootph-all and bootph-some-ram properties. If
found, propagate it to all of its parent nodes up the hierarchy.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Yannic Moog <y.moog@phytec.de> says:
This series solves a contradiction regarding ext blobs packaged in
binman. When they are marked as optional, by default they are faked, two
messages are emitted. One says the image is not functional the other
says the image is still functional. Both concern the same binman
entry/blob.
Binman is set up to have fake external blobs in case they are missing.
This is regardless on whether they are optional or not.
The implementation does not allow different types of entries to override
the faking decision; at least there wouldn't be much sense in doing so.
Here is an example build output of a phycore-imx8mp:
BINMAN .binman_stamp
Image 'image' is missing optional external blobs but is still functional: tee-os
/binman/section/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Image 'image' has faked optional external blobs and is still functional: tee.bin
OFCHK .config
The output stays to inform/warn the user, but in this case the tee-os
entry will not be present in the final image.
Link: https://lore.kernel.org/r/20250613-binman_faked_optional-v3-0-1e23dd7c41a2@phytec.de
|
|
When external blobs are marked optional, they should not cause a
build to fail. Extend the test cases for FitTeeOsOptional and
ExtblobOptional.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Some test cases don't use _DoTestFile directly which accepts
allow_fake_blobs. However, they specifically test functionality that
requires external blobs not to be faked. Extend the _DoReadFileDtb
signature to allow passing that option to _DoTestFile.
Also fix tests that require non-faked ext blobs.
By default, external blobs are faked. Some tests care only about more
basic functionality. In those cases no external blobs should be faked.
That would trigger a different (binman) case which is not in scope for
those particular tests.
Thus, disable faked blobs for those test cases.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When having an entry that is marked as optional and is missing in the
final image, the following output is observed:
CFGS spl/u-boot-spl.cfgout
BINMAN .binman_stamp
Image 'image' has faked external blobs and is non-functional: tee.bin
Image 'image' is missing optional external blobs but is still functional: tee-os
/binman/section/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Some images are invalid
make: *** [Makefile:1135: .binman_stamp] Error 103
To solve this contradictory messaging, when checking the faked blob
list, remove entries that are allowed to be missing. Instead add an
info message for faked optional blobs. Also reduce verbosity of the
optional image warning to an info message.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When blobs are absent and are marked as optional, they can be safely
dropped from the binman tree. Use the drop_absent function for that.
Rename drop_absent to drop_absent_optional as we do not want to drop any
entries that are absent; they should be reported by binman as errors
when they are missing.
We also reorder the processing of the image the following:
- We call the CheckForProblems function before the image is built.
- We drop entries after we checked for problems with the image.
This is okay because CheckForProblems does not look at the file we have
written but rather queries the data structure (image) built with binman.
This also allows us to get all error and warning messages that we want
to report while avoiding putting missing optional entries in the final
image.
As only the blobs are dropped, the sections still remain in the
assembled image. Thus add them to the expected test case checks where
necessary.
In addition, a rework of testPackTeeOsOptional test case is necessary.
The test did not really do what it was supposed to. The description said
that optional binary is tested, but the binary is not marked as
optional. Further, the tee.elf file, when included in the image
properly, also shows up in the image data. This must be added as well.
As there is no global variable for the elf data, set the pathname to the
elf file that was created when setting up the test suite.
For the test case get the filename and read the contents, comparing them
to the contents of the created binman image.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Optional blobs should mark themselves as absent to avoid being packed
into an image.
Extend the documentation of this behaviour. Although the documentation
implied this before, the "optional" property had not been explained
properly before.
The behaviour will change as now absent entries are no longer
packed into an image. The image map will also reflect this.
As a result, the CheckForProblems() function will no longer alert on
optional (blob) entries. This is because the missing optional images
were removed before CheckForProblems is called.
Adjust the testExtblobOptional test case to highlight that we are
testing not only an optional image but the image is missing as well. The
behaviour for these is different where the latter will not be packaged
into the image.
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
check_fake_fname sets the faked member of the entry. Use that member
to get the faked status instead of a returned value indicating the same.
Add type annotations to the modified functions while at it.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Bryan Brattlof <bb@ti.com> says:
Now that TIFS and DM firmwares are marked as mandatory items for a
successful build[0] we should provide some more descriptive help text on
where to get the firmware in the event they are not found and add links
to more information about them.
We do need to expand the regex to allow the '.' dot in 'ti-fs-enc.bin'
so we can add it to the list which was the lesser number of lines
changed than renaming all these entries to 'tifs' or 'ti-fs' which the
current regex will match.
Link: https://lore.kernel.org/r/20250612-missing-blob-help-entries-v2-0-36f1c8078155@ti.com
|
|
Aristo Chen <jj251510319013@gmail.com> says:
This series introduces a validation step in mkimage to ensure that all image
names referenced under the /configurations node of a FIT source (ITS) are
actually defined under the /images node.
### Motivation
When using mkimage to build FIT images, it's easy to mistakenly reference
nonexistent image nodes in configurations (e.g., referencing a missing `fdt` or
`firmware` node). Such issues are often not caught until runtime in U-Boot.
This series aims to catch these errors early during FIT image creation by
validating the configuration references in mkimage itself.
Link: https://lore.kernel.org/r/20250610074121.8308-1-aristo.chen@canonical.com
|
|
Now that the TIFS firmware is marked as a mandatory component to a
successful build, provide some helpful descriptions to what it is and
links to more information about how to get this needed firmware.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Extend the regex to add periods '.' in the tag so entries like
ti-fs-enc.bin can be represented in the missing-blob-help file.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Now that the inner certificate for TI's Foundation Security TIFS
firmware is mandatory to a successful build, provide some guidance on
what it is and links to the documentation on how to obtain the firmware
blobs.
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Now that ti-dm is marked as a mandatory component for a successful
build, adding some helping text about how to resolve a failed build will
be needed. Add some text around what ti-dm is and links to more
documentation on how to obtain the firmware binaries
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
As the list of entries grows let's alphabetize the list to make
searching a little easier. No functional changes intended
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Several binman FIT test device trees reference image nodes such as atf
and uboot in their /configurations sections, but those image nodes
were not actually defined in the /images node. This mismatch can lead
to validation errors when stricter consistency checks are introduced.
This patch adds minimal definitions for atf and uboot under the
/images node in all relevant test DTS files.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
When parsing a FIT image source (ITS), mkimage does not currently check
whether the image names referenced in the /configurations section (e.g.
"kernel", "fdt", "ramdisk", "loadables") actually exist in the /images
node.
This patch introduces a validation step during FIT import that iterates
over each configuration and verifies that all referenced image names are
defined under /images. If a missing image is detected, an appropriate
error is reported and mkimage exits with FDT_ERR_NOTFOUND.
This ensures that configuration integrity is validated at build time.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
The fit_handle_file() function previously returned a hardcoded -1 on
error. This change updates the logic to return the actual error code
stored in `ret`, allowing for error propagation.
This improves debuggability and enables downstream callers to
distinguish different failure causes, such as FDT_ERR_NOTFOUND or
other errors.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Typically boards operating in production environments will not be
monitored and so will not need JTAG access unlocked. Disable the debug
extension by default (set debugType = 0) unless we add the 'debug'
property in the binman configs.
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
The value passed to dcd_skip of build_container() should be obtained by
parsing .cfg file, and should not be fixed to false. For i.MX8QXP, dcd
data needs to be skipped, in which case dcd_skip should be true.
Fixes: 5f28a6599f01("tools: imx8image: add i.MX95 support")
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reported-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
|
|
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).
|
|
The function definition of fit_check_sign() is guarded by
"#ifdef CONFIG_FIT_SIGNATURE" in "tools/image-host.c". If we try
to build it without CONFIG_FIT_SIGNATURE, we will get an error:
/usr/bin/ld: tools/fit_check_sign.o: in function `main':
fit_check_sign.c:(.text.startup+0x165): undefined reference to `fit_check_sign'
collect2: error: ld returned 1 exit status
Fixes: 9c79c8fe70da ("tools/fit_check_sign: make key optional")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
|
|
The symbol TOOLS_IMAGE_PRE_LOAD doesn't depend on TOOLS_LIBCRYPTO.
If we choose to build tools without openssl, rsa_verify_openssl()
will attempt to call the unavailable openssl library functions.
Fixes: 942c8c8e6697 ("rsa: Add rsa_verify_openssl() to use openssl for host builds")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
|
|
Marek Vasut <marek.vasut+renesas@mailbox.org> says:
Rename the environment related variables and add ENV_ prefix, so that
all configuration options which are related to environment would have
an CONFIG_ENV_ prefix. No functional change.
Link: https://lore.kernel.org/r/20250609192701.20260-1-marek.vasut+renesas@mailbox.org
|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
E Shattow <e@freeshell.de> says:
Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot.
There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix
or placeholder in documentation and error messages.
External devicetree-rebasing dts/upstream and the generated code of
xilinx/zynq are ignored for the series.
Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de
|
|
Use consistent lowercase hex prefix style in tools/*
Signed-off-by: E Shattow <e@freeshell.de>
|
|
Some SoCs require a Trusted Firmware-A (TF-A) AP Trusted ROM (BL1) to
initialize the SoC before U-Boot can run properly. Add an atf-bl1 etype
so we can properly package BL1 into a final binary
Signed-off-by: Bryan Brattlof <bb@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Add support for generating STM32 Image V2.0, which is used by STM32MP13xx.
The image header layout is similar to STM32MP15xx STM32 Image V1.0, but is
different enough to justify duplicate functions to generate the v2 image.
This code at least attempts to align the V1 and V2 image handling where
possible.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
|
|
Prevent file descriptor leaks by properly closing 'fd' and 'new_fd'
when fstat() or write() operations fail.
- Added close(fd) before return in open_for_read() if fstat() fails.
- Added close(new_fd) before return in write_image() if write() fails.
- No close needed if open() fails (fd == -1 is invalid).
Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
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>
|
|
Add various tests for the Cseries functionality, including both direct
and via-cmdline variants.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a command to allow managing the upstream tree. This is very basic
so far, only allowing setting the name and URL. Further work may allow
checking whether series apply cleaning on the upstream tree, etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a command to support management of series. These are local branches
which may have been sent to the mailing list, so may appear on the
patchwork server.
The new functionality uses a database, stored in a local file.
Various operations are supported:
- add a new series
- send a series and automatically link it with patchwork
- 'increment' the version, to prepare to send an updated series
- gather review/test tags from patchwork
- check on progress, i.e. patches which are received new tags or
comments
- show comments on patches and cover letters
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Indicate whether 'git send-email' was actually called, so that we don't
bother waiting for patchwork to receive our series if it wasn't.
The 'git send-email' seems to always return a code of 0 even if nothing
was sent, so we cannot use clues there. Ideally we would watch the
output to determine which patches were sent and which not, but that is
left for another day.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
