u-boot.git/lib/Makefile, branch v2022.01 Unnamed repository; edit this file 'description' to name the repository. image: Use the correct checks for CRC32 2021-10-08T19:53:26+00:00 Simon Glass sjg@chromium.org 2021-09-26T01:43:24+00:00 e7d285b2f38202f9d7ffbdcae59283f08bafd8b9 Add a host Kconfig for CRC32. With this we can use CONFIG_IS_ENABLED(CRC32) directly in the host build, so drop the unnecessary indirection. Add a few more conditions to SPL_CRC32 to avoid build failures as well as TPL_CRC32. Also update hash.c to make crc32 optional and to actually take notice of SPL_CRC32. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> 
Add a host Kconfig for CRC32. With this we can use CONFIG_IS_ENABLED(CRC32)
directly in the host build, so drop the unnecessary indirection.

Add a few more conditions to SPL_CRC32 to avoid build failures as well as
TPL_CRC32. Also update hash.c to make crc32 optional and to actually take
notice of SPL_CRC32.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add support for an owned buffer 2021-10-08T19:53:26+00:00 Simon Glass sjg@chromium.org 2021-09-25T13:03:07+00:00 67bc59df05331eaac56cd0a00219d1386130aee2 When passing a data buffer back from a function, it is not always clear who owns the buffer, i.e. who is responsible for freeing the memory used. An example of this is where multiple files are decompressed from the firmware image, using a temporary buffer for reading (since the compressed data has to live somewhere) and producing a temporary or permanent buffer with the resuilts. Where the firmware image can be memory-mapped, as on x86, the compressed data does not need to be buffered, but the complexity of having a buffer which is either allocated or not, makes the code hard to understand. Introduce a new 'abuf' which supports simple buffer operations: - encapsulating a buffer and its size - either allocated with malloc() or not - able to be reliably freed if necessary - able to be converted to an allocated buffer if needed This simple API makes it easier to deal with allocated and memory-mapped buffers. Signed-off-by: Simon Glass <sjg@chromium.org> 
When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>
lib: optee: remove the duplicate CONFIG_OPTEE 2021-10-05T12:44:48+00:00 Patrick Delaunay patrick.delaunay@foss.st.com 2021-09-02T09:56:16+00:00 51827f9a8be3def01b837a2809094e2fd2703b6a The configuration CONFIG_OPTEE is defined 2 times: 1- in lib/optee/Kconfig for support of OPTEE images loaded by bootm command 2- in drivers/tee/optee/Kconfig for support of OP-TEE driver. It is abnormal to have the same CONFIG define for 2 purpose; and it is difficult to managed correctly their dependencies. Moreover CONFIG_SPL_OPTEE is defined in common/spl/Kconfig to manage OPTEE image load in SPL. This definition causes an issue with the macro CONFIG_IS_ENABLED(OPTEE) to test the availability of the OP-TEE driver. This patch cleans the configuration dependency with: - CONFIG_OPTEE_IMAGE (renamed) => support of OP-TEE image in U-Boot - CONFIG_SPL_OPTEE_IMAGE (renamed) => support of OP-TEE image in SPL - CONFIG_OPTEE (same) => support of OP-TEE driver in U-Boot - CONFIG_OPTEE_LIB (new) => support of OP-TEE library After this patch, the macro have the correct behavior: - CONFIG_IS_ENABLED(OPTEE_IMAGE) => Load of OP-TEE image is supported - CONFIG_IS_ENABLED(OPTEE) => OP-TEE driver is supported Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> 
The configuration CONFIG_OPTEE is defined 2 times:
1- in lib/optee/Kconfig for support of OPTEE images loaded by bootm command
2- in drivers/tee/optee/Kconfig for support of OP-TEE driver.

It is abnormal to have the same CONFIG define for 2 purpose;
and it is difficult to managed correctly their dependencies.

Moreover CONFIG_SPL_OPTEE is defined in common/spl/Kconfig
to manage OPTEE image load in SPL.

This definition causes an issue with the macro CONFIG_IS_ENABLED(OPTEE)
to test the availability of the OP-TEE driver.

This patch cleans the configuration dependency with:
- CONFIG_OPTEE_IMAGE (renamed) => support of OP-TEE image in U-Boot
- CONFIG_SPL_OPTEE_IMAGE (renamed) => support of OP-TEE image in SPL
- CONFIG_OPTEE (same) => support of OP-TEE driver in U-Boot
- CONFIG_OPTEE_LIB (new) => support of OP-TEE library

After this patch, the macro have the correct behavior:
- CONFIG_IS_ENABLED(OPTEE_IMAGE) => Load of OP-TEE image is supported
- CONFIG_IS_ENABLED(OPTEE) => OP-TEE driver is supported

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
fdt: Update Makefile rules with the new OF_REAL Kconfig 2021-09-25T15:46:15+00:00 Simon Glass sjg@chromium.org 2021-08-07T13:24:07+00:00 f99cbe4e867f75f8e90917b997c338e20c7f7831 Simplify some of the Makefile rules using this Kconfig. Signed-off-by: Simon Glass <sjg@chromium.org> 
Simplify some of the Makefile rules using this Kconfig.

Signed-off-by: Simon Glass <sjg@chromium.org>
Merge tag 'v2021.10-rc4' into next 2021-09-16T14:29:40+00:00 Tom Rini trini@konsulko.com 2021-09-16T14:29:40+00:00 6674edaabfd271471608146806f5b6540bc76a1b Prepare v2021.10-rc4 Signed-off-by: Tom Rini <trini@konsulko.com> # gpg: Signature made Tue 14 Sep 2021 06:58:32 PM EDT # gpg: using RSA key 1A3C7F70E08FAB1707809BBF147C39FF9634B72C # gpg: Good signature from "Thomas Rini <trini@konsulko.com>" [ultimate] # Conflicts: # board/Arcturus/ucp1020/spl.c # cmd/mvebu/Kconfig # common/Kconfig.boot # common/image-fit.c # configs/UCP1020_defconfig # configs/sifive_unmatched_defconfig # drivers/pci/Kconfig # include/configs/UCP1020.h # include/configs/sifive-unmatched.h # lib/Makefile # scripts/config_whitelist.txt 
Prepare v2021.10-rc4

Signed-off-by: Tom Rini <trini@konsulko.com>

# gpg: Signature made Tue 14 Sep 2021 06:58:32 PM EDT
# gpg:                using RSA key 1A3C7F70E08FAB1707809BBF147C39FF9634B72C
# gpg: Good signature from "Thomas Rini <trini@konsulko.com>" [ultimate]

# Conflicts:
#	board/Arcturus/ucp1020/spl.c
#	cmd/mvebu/Kconfig
#	common/Kconfig.boot
#	common/image-fit.c
#	configs/UCP1020_defconfig
#	configs/sifive_unmatched_defconfig
#	drivers/pci/Kconfig
#	include/configs/UCP1020.h
#	include/configs/sifive-unmatched.h
#	lib/Makefile
#	scripts/config_whitelist.txt
common/spl: Drop [ST]PL_HASH_SUPPORT in favor of [ST]PL_HASH 2021-09-08T20:11:46+00:00 Alexandru Gagniuc mr.nuke.me@gmail.com 2021-09-03T00:54:19+00:00 0721209699c5092b4d364c3b57256840d3a7dcbc All of these configs exist. Stick to using CONFIG_[ST]PL_HASH, and drop all references to CONFIG_[ST]PL_HASH_SUPPORT. This means we need for CHAIN_OF_TRUST to select SPL_HASH now. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> [trini: Add TPL case, fix CHAIN_OF_TRUST, other tweaks] Signed-off-by: Tom Rini <trini@konsulko.com> 
All of these configs exist. Stick to using CONFIG_[ST]PL_HASH, and drop all
references to CONFIG_[ST]PL_HASH_SUPPORT.  This means we need for
CHAIN_OF_TRUST to select SPL_HASH now.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
[trini: Add TPL case, fix CHAIN_OF_TRUST, other tweaks]
Signed-off-by: Tom Rini <trini@konsulko.com>
lib: Drop SHA512_ALGO in lieu of SHA512 2021-09-08T20:11:46+00:00 Alexandru Gagniuc mr.nuke.me@gmail.com 2021-09-03T00:54:18+00:00 e60e449931201eaf9a1883dfddef1c5cb6bf161d SHA512_ALGO was used as a "either SHA512 or SHA384", although the implementations of these two algorithms share a majority of code. From a Kconfig interface perspective, it makes sense to present two distinct options. This requires #ifdefing out the SHA512 implementation from sha512.c. The latter doesn't make any sense. It's reasonable to say in Kconfig that SHA384 depends on SHA512, and seems to be the more polite way to handle the selection. Thus, automatically select SHA512 when SHA384 is enabled. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> 
SHA512_ALGO was used as a "either SHA512 or SHA384", although the
implementations of these two algorithms share a majority of code.

From a Kconfig interface perspective, it makes sense to present two
distinct options. This requires #ifdefing out the SHA512
implementation from sha512.c. The latter doesn't make any sense.

It's reasonable to say in Kconfig that SHA384 depends on SHA512, and
seems to be the more polite way to handle the selection.

Thus, automatically select SHA512 when SHA384 is enabled.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
lib: add crc16.o if CONFIG_MMC_SPI_CRC_ON for SPL build 2021-09-02T14:17:45+00:00 Andreas Schwab schwab@suse.de 2021-08-17T10:51:34+00:00 c8291f53b0523cf1af24dae8a41720fa7e7d035a CONFIG_MMC_SPI_CRC_ON needs the crc16 functions, but it was not included in an SPL build. For non-SPL builds, crc16.o is already added unconditionally. This also removes CONFIG_SPL_YMODEM_SUPPORT from the sifive board configs, which is only relevant for some ARM boards and was only set for its side effect of adding crc16.o. 
CONFIG_MMC_SPI_CRC_ON needs the crc16 functions, but it was not included
in an SPL build.  For non-SPL builds, crc16.o is already added
unconditionally.  This also removes CONFIG_SPL_YMODEM_SUPPORT from the
sifive board configs, which is only relevant for some ARM boards and was
only set for its side effect of adding crc16.o.
lib: ecdsa: Implement UCLASS_ECDSA verification on target 2021-08-16T08:49:35+00:00 Alexandru Gagniuc mr.nuke.me@gmail.com 2021-07-29T16:47:16+00:00 928a8be79480b0e2ea2461a7b2533d3e71bcb3e6 Implement the crypto_algo .verify() function for ecdsa256. Because it backends on UCLASS_ECDSA, this change is focused on parsing the keys from devicetree and passing this information to the specific UCLASS driver. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> 
Implement the crypto_algo .verify() function for ecdsa256. Because
it backends on UCLASS_ECDSA, this change is focused on parsing the
keys from devicetree and passing this information to the specific
UCLASS driver.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
lib: Create a new Kconfig option for charset conversion 2021-07-28T18:27:54+00:00 Simon Glass sjg@chromium.org 2021-07-02T18:36:17+00:00 1a46cb6c7e1860c8dfdfadbb2e3ac708edc5d388 Rather than looking at two KConfig options in the Makefile, create a new Kconfig option for compiling lib/charset.c Enable it for UFS also, which needs this support. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> 
Rather than looking at two KConfig options in the Makefile, create a new
Kconfig option for compiling lib/charset.c

Enable it for UFS also, which needs this support.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>