Commit aeb40f1166 ("tools: env: use /run to store lockfile") updated the
path to the lockfile but did not update the documentation to match.
Use the new path in the documentation.
Fixes: aeb40f1166 ("tools: env: use /run to store lockfile")
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This member is used in series.MakeCcFile() so should be declared in the
Series class.
Add a declaration to silence the warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
The codes forget to call munmap() to unmap the ELF image that was
mapped by previous mmap().
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Rick Chen <rick@andestech.com>
Currently kwboot expected that sector size for SATA image is always 512
bytes. If SATA image cannot be parsed with sector size of 512 bytes, try
larger sector sizes which are power of two and up to the 32 kB. Maximal
theoretical value is 32 kB because ATA IDENTIFY command returns sector size
as 16-bit number.
Signed-off-by: Pali Rohár <pali@kernel.org>
SATA kwbimage contains offsets in block size unit, not in bytes.
Until now kwbimage expected that SATA disk always have block size of 512
bytes. But there are 4K Native SATA disks with block size of 4096 bytes.
New SATA_BLKSZ command allows to specify different block size than 512
bytes and therefore allows to generate kwbimage for disks with different
block sizes.
This change add support for generating SATA images with different block
size. Also it add support for verifying and dumping such images.
Because block size itself is not stored in SATA kwbimage, image
verification is done by checking every possible block size (it is any
power of two value between 512 and 32 kB).
Signed-off-by: Pali Rohár <pali@kernel.org>
This allows image type print_header() callback to access struct
image_tool_params *params.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building with -Wimplicit-fallthrough we get a warning
tools/fdt_add_pubkey.c:52:25: warning:
this statement may fall through [-Wimplicit-fallthrough=]
52 | print_help();
|
Explicitly declare which functions don't return.
Fixes: 30238e9961 ("tools: add fdt_add_pubkey")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
According this issue https://github.com/ppp-project/ppp/issues/339.
Eventually, the dt-utils changed lock directory to fix missing /var/lock
directory error then make dt-utils can run normally.
We also have a similar issue with these two utilities fw_printenv and
fw_setenv will failed when the directory /var/lock is non-existent.
We have a custom linux distribution built with yocto (OpenBMC) that
use systemd and it deprecated the /var/lock directory.
More discussion in systemd/systemd#15668.
Thus, we sync with community's solution for uboot/tools/env utilities:
The current location /var/lock is considered legacy (at least by systemd).
Just use /run to store the lockfile and append the usual .lock suffix.
Tested:
Verified /run/lock is now present and fw_printenv can work in OpenBMC.
Signed-off-by: Tim Lee <timlee660101@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
mkbootimg tool is part of the Android project and it is
used to pack Android boot images such as boot image
and vendor_boot image.
Use the following command to run mkbootimg:
$ python3 -m mkbootimg
Add mkbootimg to the docker file
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
As this is now the stable release, move to using that now for our tests.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Given the number of jobs in CI we have which use python and pip install
packages, we should do this once in the Dockerfile, in order to populate
the cache. We let each job continue to create and use the virtual
environments they need to facilitate making updates to these
environments easier.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The toolchain test causes the settings file to be overwritten, which is
annoying for local development. Fix it by passing None as the filename.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use external blob otpcmd.bin to replace the 0xff filled OTP programming
command block to create a firmware image that provisions the OTP on
first boot. This otpcmd.bin is generated from the customer keys using
steps described in the meta-iot2050 integration layer for the device.
Based on original patch by Baocheng Su.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
There are many ways to get a signed firmware for the IOT2050 devices,
namely for the parts under user-control. This script documents one way
of doing it, given a signing key. Augment the board documentation with
the required procedure around it.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Allows to create a public key device tree dtsi for inclusion into U-Boot
SPL and proper during first build already. This can be achieved via
CONFIG_DEVICE_TREE_INCLUDES.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
The latest version of the binary-only firmware parts come in a combined
form of FSBL and sysfw containers. This implies some layout changes to
the generated firmware image but also makes handling of artifacts much
simpler (4 files less). The env locations will not change, just the
space reserved for U-Boot will shrink from 4 to 3 MB - still plenty of
space left in practice.
Adjust configuration and documentation accordingly.
Along this change, add a new reservation for update commands of the
user-controlled OTP part. A specific userspace tool will fill it, and
the FSBL will evaluate it during boot. This reservation will use 64K of
the former sysfw section.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
A38x BootROM has a bug which cause that BootROM loads data part of UART
image into RAM target address increased by one byte when source address
and header size stored in the image header are not same.
Workaround this bug by completely removing a gap between header and data
part of the UART image. Without gap, this BootROM bug is not triggered.
This gap can be present in SDIO or SATA image types which have aligned
start of the data part to the media sector size. With this workaround
kwboot should be able to convert and send SDIO or SATA images for UART
booting.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Sending of very small images (smaller than 128 bytes = xmodem block size)
cause out-of-bound memory read access. Fix this issue by ensuring that
hdrsz when sending image is not larger than total size of the image.
Issue was introduced in commit f8017c3779 ("tools: kwboot: Fix sending
Kirkwood v0 images"). Special case when total image is smaller than header
size aligned to multiply of xmodem size is already handled since that
commit.
Fixes: f8017c3779 ("tools: kwboot: Fix sending Kirkwood v0 images")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Commit 7665ed2fa0 ("tools: kwboot: Fix parsing UART image without data
checksum") added fixup code to insert place for data checksum if UART image
does not have it. Together with option -B (change baudrate), kwboot
calculates this checksum. Without option -B, it inserts only place for
checksum but does not calculate it.
This commit fix above logic and calculate data checksum also when kwboot is
used without -B option.
Fixes: 7665ed2fa0 ("tools: kwboot: Fix parsing UART image without data checksum")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Ensure that UART aligned header size is always stored into kwbimage v1
header. It is needed for proper UART booting. Calculation of headersz field
was broken in commit d656f5a0ee ("tools: kwboot: Calculate real used
space in kwbimage header when calling kwboot_img_grow_hdr()") which
introduced optimization of kwboot_img_grow_hdr() function.
Fixes: d656f5a0ee ("tools: kwboot: Calculate real used space in kwbimage header when calling kwboot_img_grow_hdr()")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Armada 385 BootROM ignores low 7 bits of headersz when parsing kwbimage
header of UART type, which effectively means that headersz is rounded down
to multiply of 128 bytes. For all other image types BootROM reads and use
all bits of headersz. Therefore fill into UART type of kwbimage v1 headersz
aligned to 128 bytes.
Fixes: 2b0980c240 ("tools: kwbimage: Fill the real header size into the main header")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
With clang-15 we now get reported that in the make_flame_tree function,
neither the missing_count nor depth variables are used, only
incremenete/decremented. Remove these.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
With clang-15, it is now reported that cont_img_count is unused. This is
true as the code will increment / reset this counter, but never
functionally use it. Remove it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Given efforts to add an m68k target to CI, build qemu for it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
binman signing feature
fix buildman -A bug introduced recently
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmQQ8KIRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreYRmwgA1XAHafEOfhaya54nalUgW9qYZe5Ntfqd
4Tg7zj3gadZuv82LuyskEyBKptwRCzgX0Tyx62V3Oop9vJ/cCwjIB4AGhCsMKERf
NqcMd8fbGbJ9jJzOp7gNTHzV4vSmwKM0lRkxbClMFcvMsfVdKcBRPswLLghk5/xL
Uu4Ww4yfe7UCqgBm9uouVaIbcNNcl8p0QnSJT9HvwjGKawPT6uSHOHK9Wpkud0q1
ZyrPpCMA29mifhIU8aH5CJH5G61UbGcVSDhm9lIKwqZg+KJGuYf64JbZoY9JI2/z
pOUHLZx7fVHoFyWKWfVkA9l6HRjZTRc0nJhYFx5HyNUOU50hMENeTQ==
=ko2P
-----END PGP SIGNATURE-----
Merge tag 'dm-next-12mar23a' of git://git.denx.de/u-boot-dm into next
More tests and fixes for fdt command
binman signing feature
fix buildman -A bug introduced recently
Signed-off-by: Tom Rini <trini@konsulko.com>
The previous attempt at fixing this broke the normal usage of the -A
flag.
At present, 'buildman -A sandbox' adds the path containing the
toolchain. We can assume that this is in the path and we don't want to
set CROSS_COMPILE=/bin/
Change this to align with what MakeEnvironment() does, but only for
sandbox boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
Having to use the -K option to mkimage to populate U-Boot's .dtb with the
public key while signing the kernel FIT image is often a little
awkward. In particular, when using a meta-build system such as
bitbake/Yocto, having the tasks of the kernel and U-Boot recipes
intertwined, modifying deployed artifacts and rebuilding U-Boot with
an updated .dtb is quite cumbersome. Also, in some scenarios one may
wish to build U-Boot complete with the public key(s) embedded in the
.dtb without the corresponding private keys being present on the same
build host.
So this adds a simple tool that allows one to disentangle the kernel
and U-Boot builds, by simply copy-pasting just enough of the mkimage
code to allow one to add a public key to a .dtb. When using mkimage,
some of the information is taken from the .its used to build the
kernel (algorithm and key name), so that of course needs to be
supplied on the command line.
Signed-off-by: Roman Kopytin <Roman.Kopytin@kaspersky.com>
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Add the test which provides sequence of actions:
1. create the image from binman dts
2. create public and private keys
3. add public key into dtb with fdt_add_pubkey
4. 1. sign FIT container with new sign option with extracting from
image
2. sign exact FIT container with replacing of it in image
5. check with fit_check_sign
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Renumber test file from 277 to 280;
Move UpdateSignatures() to Entry base class;
Don't allow missing mkimage as it doesn't make sense;
Propagate --toolpath for CI;
Call mark_build_done() to avoid regenerating FIT:
Signed-off-by: Simon Glass <sjg@chromium.org>
Introduce proof of concept for binman's new option which provides sign
and replace FIT containers in binary images.
Usage as example:
from:
mkimage -G privateky -r -o sha256,rsa4096 -F fit
binman replace -i flash.bin -f fit.fit fit
to:
binman sign -i flash.bin -k privatekey -a sha256,rsa4096 -f fit.fit fit
and to this one if it's need to be extracted, signed with key and put it
back in image:
binman sign -i flash.bin -k privatekey -a sha256,rsa4096 fit
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Add the documentation about binman sign option and providing an
example.
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Add a section about 'binman sign' at the bottom:
Signed-off-by: Simon Glass <sjg@chromium.org>
Currently, a microblaze build with CONFIG_SYS_BIG_ENDIAN=y and
CONFIG_STATIC_RELA=y fails with:
tools/relocate-rela: Not supported machine type
ELF decoding failed
make[2]: *** [u-boot/Makefile:1306: u-boot-nodtb.bin] Error 1
To fix this, convert the 32-bit codepath to use the previously added
elf{16,32}_to_cpu() functions. The aarch64 codepath is left untouched.
This commit ensures that CI doesn't fail for the next patches which enable
runtime relocation by default for microblaze.
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Link: https://lore.kernel.org/r/20230311173838.521804-3-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add elf16_to_cpu() and elf32_to_cpu() functions that allow to read data in
both big-endian and little-endian formats.
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Link: https://lore.kernel.org/r/20230311173838.521804-2-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The sh_addr/sh_offset/sh_size fields in Elf32_Shdr are 32-bits wide, so
use le32_to_cpu() instead of the 64-bit variant.
Fixes: 5e0e1a86d3 ("tools: relocate-rela: Fix ELF decoding on big-endian hosts")
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Link: https://lore.kernel.org/r/20230311173838.521804-1-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
And a new entry type which supports generation of x509 certificates.
This uses a new 'openssl' btool with just one operation so far.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present these are handled as if they are allowed to be missing, but
this is only true if the -M flag is provided. Fix this and add a test.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present, 'buildman -A sandbox' adds the path containing the
toolchain at present. We can assume that this is in the path and
we don't want to set CROSS_COMPILE=/bin/ so change this to align
with what MakeEnvironment() does.
Signed-off-by: Simon Glass <sjg@chromium.org>
For large series this can take a while. Run checkpatch in parallel to
try to reduce the time. The checkpatch information is still reported in
sequential order, so a very slow patch at the start can still slow
things down. But overall this gives good results.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
This script can take ages on some series. Try to limit the time by
using threads. If a few stubborn patches remain, show progress so the
user has some idea what is going on.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
This function is quite long. Moving the handling of a commit into a
separate function. This will make it easier to do the work in parallel.
Update function comments while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Patman does not do this anymore, as of this commit:
7428dc14b0 ("patman: Remove the -a option")
Drop the comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
