Re: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing
On 5/13/21 7:12 AM, Masami Hiramatsu wrote:
Hi Heinrich,
2021年5月13日(木) 13:22 Heinrich Schuchardt :
On 5/13/21 5:08 AM, AKASHI Takahiro wrote:
On Wed, May 12, 2021 at 10:56:41AM +0200, Heinrich Schuchardt wrote:
On 12.05.21 06:57, AKASHI Takahiro wrote:
With this enhancement, mkeficapsule will be able to create a capsule
file with a signature which will be verified later by FMP's SetImage().
We will have to specify addtional command parameters:
-monotonic-cout : monotonic count
-private-key : private key file
-certificate : certificate file
Only when those parameters are given, a signature will be added
to a capsule file.
Users are expected to maintain the monotonic count for each firmware
image.
Signed-off-by: AKASHI Takahiro
---
tools/Makefile | 4 +
tools/mkeficapsule.c | 324 +++
2 files changed, 303 insertions(+), 25 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index d020c55d6644..02eae0286e20 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -231,6 +231,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler
HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
+ifneq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),)
+HOSTLDLIBS_mkeficapsule += \
+ $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl
-lcrypto")
I don't expect any user wants to install two tool versions in parallel.
The tool should always be able to add a signature.
Adding a signature must be optional.
It seems to me that those two statements mutually contradict.
Or do you intend to say that we should have a separate kconfig
option to enable/disable signing feature in mkeficapsule?
If so, I can agree.
In either way, we should have an option to turn on/off this functionality
as not all users use signed capsules.
I want to have a single binary to distribute with Linux distros (e.g.
Debian/Ubuntu package u-boot-tools).
I couldn't catch your point. If so, the distros can build u-boot with
CONFIG_EFI_CAPSULE_AUTHENTICATE=y...
Why should the tool depend on board configuration?
Who would want capsule updates without authentication?
BTW, IMHO, if u-boot.bin can not find the ESL in the device tree,
it should skip authentication too.
In this case the capsule should be rejected (if
CONFIG_EFI_CAPSULE_AUTHENTICATE=y).
Then, user can choose whether enabling capsule authentication or not
by embedding ESL into their devicetree.
The user shall not be able to decide anything that might hamper
security. The U-Boot binary must dictate if a capsule is safe.
Best regards
Heinrich
Thank you
This should allow both
- create signed capsules
- create unsigned capsules
The user shall select signing via command line parameters.
Support for signing via the tool shall not depend on board Kconfig
parameters.
Best regards
Heinrich
+endif
mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS)
hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index de0a62898886..34ff1bdd82eb 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -18,7 +18,17 @@
#include
#include
-#include "fdt_host.h"
+#include
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+#include
+#include
+#include
+#include
+#include
+#include
+#endif
+
+#include
typedef __u8 u8;
typedef __u16 u16;
@@ -46,6 +56,13 @@ efi_guid_t efi_guid_image_type_uboot_fit =
EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
efi_guid_t efi_guid_image_type_uboot_raw =
EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
+efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
+
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+static const char *opts_short = "f:r:i:I:v:D:K:P:C:m:dOh";
+#else
+static const char *opts_short = "f:r:i:I:v:D:K:Oh";
+#endif
static struct option options[] = {
{"fit", required_argument, NULL, 'f'},
@@ -54,6 +71,12 @@ static struct option options[] = {
{"instance", required_argument, NULL, 'I'},
{"dtb", required_argument, NULL, 'D'},
{"public key", required_argument, NULL, 'K'},
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
+ {"private-key", required_argument, NULL, 'P'},
+ {"certificate", required_argument, NULL, 'C'},
+ {"monotonic-count", required_argument, NULL, 'm'},
These options should not be required.
I don't get you. What do you mean?
+ {"dump-sig", no_argument, NULL, 'd'},
+#endif
{"overlay", no_argument, NULL, 'O'},
{"help", no_argument, NULL, 'h'},
{NULL, 0, NULL, 0},
@@ -70,6 +93,12 @@ static void print_usage(void)
"\t-I, --instanceupdate hardware instance\n"
"\t-K, --public-key public key esl file\n"
"\t-D, --dtb dtb file\n"
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+ "\t-P, --private-key private key file\n"
+
Re: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing
On 5/13/21 7:00 AM, AKASHI Takahiro wrote:
On Thu, May 13, 2021 at 06:22:39AM +0200, Heinrich Schuchardt wrote:
On 5/13/21 5:08 AM, AKASHI Takahiro wrote:
On Wed, May 12, 2021 at 10:56:41AM +0200, Heinrich Schuchardt wrote:
On 12.05.21 06:57, AKASHI Takahiro wrote:
With this enhancement, mkeficapsule will be able to create a capsule
file with a signature which will be verified later by FMP's SetImage().
We will have to specify addtional command parameters:
-monotonic-cout : monotonic count
-private-key : private key file
-certificate : certificate file
Only when those parameters are given, a signature will be added
to a capsule file.
Users are expected to maintain the monotonic count for each firmware
image.
Signed-off-by: AKASHI Takahiro
---
tools/Makefile | 4 +
tools/mkeficapsule.c | 324 +++
2 files changed, 303 insertions(+), 25 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index d020c55d6644..02eae0286e20 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -231,6 +231,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
hostprogs-$(CONFIG_ASN1_COMPILER)+= asn1_compiler
HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
+ifneq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),)
+HOSTLDLIBS_mkeficapsule += \
+ $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl
-lcrypto")
I don't expect any user wants to install two tool versions in parallel.
The tool should always be able to add a signature.
Adding a signature must be optional.
It seems to me that those two statements mutually contradict.
Or do you intend to say that we should have a separate kconfig
option to enable/disable signing feature in mkeficapsule?
If so, I can agree.
In either way, we should have an option to turn on/off this functionality
as not all users use signed capsules.
I want to have a single binary to distribute with Linux distros (e.g.
Debian/Ubuntu package u-boot-tools).
This should allow both
- create signed capsules
- create unsigned capsules
The user shall select signing via command line parameters.
Support for signing via the tool shall not depend on board Kconfig
parameters.
That is why I proposed that we create a new kconfig option.
What do you want to configure? Signing shall always be enabled in
mkeficapsule.
Please note that enabling signing feature in mkeficapsule
requires openssl library, and we should not enforce users who don't
need this feature to install an unnecessary package.
Why? There are dozens of other packages depending on OpenSSL on a
developer's machine.
Best regards
Heinrich
-Takahiro Akashi
Best regards
Heinrich
+endif
mkeficapsule-objs:= mkeficapsule.o $(LIBFDT_OBJS)
hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index de0a62898886..34ff1bdd82eb 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -18,7 +18,17 @@
#include
#include
-#include "fdt_host.h"
+#include
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+#include
+#include
+#include
+#include
+#include
+#include
+#endif
+
+#include
typedef __u8 u8;
typedef __u16 u16;
@@ -46,6 +56,13 @@ efi_guid_t efi_guid_image_type_uboot_fit =
EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
efi_guid_t efi_guid_image_type_uboot_raw =
EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
+efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
+
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+static const char *opts_short = "f:r:i:I:v:D:K:P:C:m:dOh";
+#else
+static const char *opts_short = "f:r:i:I:v:D:K:Oh";
+#endif
static struct option options[] = {
{"fit", required_argument, NULL, 'f'},
@@ -54,6 +71,12 @@ static struct option options[] = {
{"instance", required_argument, NULL, 'I'},
{"dtb", required_argument, NULL, 'D'},
{"public key", required_argument, NULL, 'K'},
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
+ {"private-key", required_argument, NULL, 'P'},
+ {"certificate", required_argument, NULL, 'C'},
+ {"monotonic-count", required_argument, NULL, 'm'},
These options should not be required.
I don't get you. What do you mean?
+ {"dump-sig", no_argument, NULL, 'd'},
+#endif
{"overlay", no_argument, NULL, 'O'},
{"help", no_argument, NULL, 'h'},
{NULL, 0, NULL, 0},
@@ -70,6 +93,12 @@ static void print_usage(void)
"\t-I, --instanceupdate hardware instance\n"
"\t-K, --public-key public key esl file\n"
"\t-D, --dtb dtb file\n"
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+ "\t-P, --private-key private key file\n"
+ "\t-C, --certificate signer's certificate file\n"
+ "\t-m, --monotonic-count monotonic count\n"
+ "\t-d,
Re: [PATCH 3/4] tools: add fdtsig command
On 5/12/21 6:57 AM, AKASHI Takahiro wrote:
This command allows us to add a certificate (or public key) to dtb blob:
{
signature {
capsule-key = "...";
};
}
The value is actually a signature list in terms of UEFI specificaion,
and used in verifying UEFI capsules.
The code was originally developed by Sughosh and derived from
mkeficapsule.c.
I have no clue how you want to use this command. Please, provide a
description of the workflow using this command.
In your comments for patch 2 you wrote that the -K and -D option can be
replaced by tools provided by the device-tree compiler package. Why do
they reappear here?
Please, add a man-page (/doc/fdtsig.1).
Signed-off-by: AKASHI Takahiro
---
Makefile | 2 +-
tools/Makefile | 2 +
tools/fdtsig.c | 274 +
3 files changed, 277 insertions(+), 1 deletion(-)
create mode 100644 tools/fdtsig.c
diff --git a/Makefile b/Makefile
index 9806464357e0..8b40987234a0 100644
--- a/Makefile
+++ b/Makefile
@@ -1016,7 +1016,7 @@ quiet_cmd_lzma = LZMA$@
cmd_lzma = lzma -c -z -k -9 $< > $@
quiet_cmd_fdtsig = FDTSIG $@
-cmd_fdtsig = $(srctree)/tools/fdtsig.sh $(CONFIG_EFI_PKEY_FILE) $@
+cmd_fdtsig = $(objtree)/tools/fdtsig -K $(CONFIG_EFI_PKEY_FILE) -D $@
cfg: u-boot.cfg
diff --git a/tools/Makefile b/tools/Makefile
index 71a52719620c..e6fd1dbade19 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -234,6 +234,8 @@ HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
ifneq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),)
HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl
-lcrypto")
+ fdtsig-objs := fdtsig.o $(LIBFDT_OBJS)
+ hostprogs-y += fdtsig
endif
hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
diff --git a/tools/fdtsig.c b/tools/fdtsig.c
new file mode 100644
index ..daa1e63c3b33
--- /dev/null
+++ b/tools/fdtsig.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2021 Linaro Limited
+ * The code in this file was extracted from mkeficapsule.c
That information is better described by the git log.
Please, explain here what this tool is used for.
Best regards
Heinrich
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define SIGNATURE_NODENAME "signature"
+#define OVERLAY_NODENAME "__overlay__"
+
+static const char *tool_name = "fdtsig";
+
+static const char *opts_short = "D:K:Oh";
+
+static struct option options[] = {
+ {"dtb", required_argument, NULL, 'D'},
+ {"public key", required_argument, NULL, 'K'},
+ {"overlay", no_argument, NULL, 'O'},
+ {"help", no_argument, NULL, 'h'},
+ {NULL, 0, NULL, 0},
+};
+
+static void print_usage(void)
+{
+ printf("Usage: %s [options]\n"
+ "Options:\n"
+
+ "\t-K, --public-key public key esl file\n"
+ "\t-D, --dtb dtb file\n"
+ "\t-O, --overlay the dtb file is an overlay\n"
+ "\t-h, --help print a help message\n",
+ tool_name);
+}
+
+static int fdt_add_pub_key_data(void *sptr, void *dptr, size_t key_size,
+ bool overlay)
+{
+ int parent;
+ int ov_node;
+ int frag_node;
+ int ret = 0;
+
+ if (overlay) {
+ /*
+* The signature would be stored in the
+* first fragment node of the overlay
+*/
+ frag_node = fdt_first_subnode(dptr, 0);
+ if (frag_node == -FDT_ERR_NOTFOUND) {
+ fprintf(stderr,
+ "Couldn't find the fragment node: %s\n",
+ fdt_strerror(frag_node));
+ goto done;
+ }
+
+ ov_node = fdt_subnode_offset(dptr, frag_node, OVERLAY_NODENAME);
+ if (ov_node == -FDT_ERR_NOTFOUND) {
+ fprintf(stderr,
+ "Couldn't find the __overlay__ node: %s\n",
+ fdt_strerror(ov_node));
+ goto done;
+ }
+ } else {
+ ov_node = 0;
+ }
+
+ parent = fdt_subnode_offset(dptr, ov_node, SIGNATURE_NODENAME);
+ if (parent == -FDT_ERR_NOTFOUND) {
+ parent = fdt_add_subnode(dptr, ov_node, SIGNATURE_NODENAME);
+ if (parent < 0) {
+ ret = parent;
+ if (ret != -FDT_ERR_NOSPACE) {
+ fprintf(stderr,
+ "Couldn't create signature node: %s\n",
+ fdt_strerror(parent));
+ }
+ }
+ }
+ if (ret)
+ goto done;
+
+ /* Write the
Re: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing
Hi Heinrich,
2021年5月13日(木) 13:22 Heinrich Schuchardt :
>
> On 5/13/21 5:08 AM, AKASHI Takahiro wrote:
> > On Wed, May 12, 2021 at 10:56:41AM +0200, Heinrich Schuchardt wrote:
> >> On 12.05.21 06:57, AKASHI Takahiro wrote:
> >>> With this enhancement, mkeficapsule will be able to create a capsule
> >>> file with a signature which will be verified later by FMP's SetImage().
> >>>
> >>> We will have to specify addtional command parameters:
> >>>-monotonic-cout : monotonic count
> >>>-private-key : private key file
> >>>-certificate : certificate file
> >>> Only when those parameters are given, a signature will be added
> >>> to a capsule file.
> >>>
> >>> Users are expected to maintain the monotonic count for each firmware
> >>> image.
> >>>
> >>> Signed-off-by: AKASHI Takahiro
> >>> ---
> >>> tools/Makefile | 4 +
> >>> tools/mkeficapsule.c | 324 +++
> >>> 2 files changed, 303 insertions(+), 25 deletions(-)
> >>>
> >>> diff --git a/tools/Makefile b/tools/Makefile
> >>> index d020c55d6644..02eae0286e20 100644
> >>> --- a/tools/Makefile
> >>> +++ b/tools/Makefile
> >>> @@ -231,6 +231,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
> >>> hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler
> >>> HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
> >>>
> >>> +ifneq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),)
> >>> +HOSTLDLIBS_mkeficapsule += \
> >>> + $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo
> >>> "-lssl -lcrypto")
> >>
> >> I don't expect any user wants to install two tool versions in parallel.
> >>
> >> The tool should always be able to add a signature.
> >> Adding a signature must be optional.
> >
> > It seems to me that those two statements mutually contradict.
> > Or do you intend to say that we should have a separate kconfig
> > option to enable/disable signing feature in mkeficapsule?
> >
> > If so, I can agree.
> >
> > In either way, we should have an option to turn on/off this functionality
> > as not all users use signed capsules.
>
> I want to have a single binary to distribute with Linux distros (e.g.
> Debian/Ubuntu package u-boot-tools).
I couldn't catch your point. If so, the distros can build u-boot with
CONFIG_EFI_CAPSULE_AUTHENTICATE=y...
BTW, IMHO, if u-boot.bin can not find the ESL in the device tree,
it should skip authentication too.
Then, user can choose whether enabling capsule authentication or not
by embedding ESL into their devicetree.
Thank you
>
> This should allow both
>
> - create signed capsules
> - create unsigned capsules
>
> The user shall select signing via command line parameters.
>
> Support for signing via the tool shall not depend on board Kconfig
> parameters.
>
> Best regards
>
> Heinrich
>
> >
> >>> +endif
> >>> mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS)
> >>> hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
> >>>
> >>> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> >>> index de0a62898886..34ff1bdd82eb 100644
> >>> --- a/tools/mkeficapsule.c
> >>> +++ b/tools/mkeficapsule.c
> >>> @@ -18,7 +18,17 @@
> >>> #include
> >>> #include
> >>>
> >>> -#include "fdt_host.h"
> >>> +#include
> >>> +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> >>
> >> see above
> >>
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#endif
> >>> +
> >>> +#include
> >>>
> >>> typedef __u8 u8;
> >>> typedef __u16 u16;
> >>> @@ -46,6 +56,13 @@ efi_guid_t efi_guid_image_type_uboot_fit =
> >>> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
> >>> efi_guid_t efi_guid_image_type_uboot_raw =
> >>> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
> >>> +efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> >>> +
> >>> +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> >>
> >> see above
> >>
> >>> +static const char *opts_short = "f:r:i:I:v:D:K:P:C:m:dOh";
> >>> +#else
> >>> +static const char *opts_short = "f:r:i:I:v:D:K:Oh";
> >>> +#endif
> >>>
> >>> static struct option options[] = {
> >>> {"fit", required_argument, NULL, 'f'},
> >>> @@ -54,6 +71,12 @@ static struct option options[] = {
> >>> {"instance", required_argument, NULL, 'I'},
> >>> {"dtb", required_argument, NULL, 'D'},
> >>> {"public key", required_argument, NULL, 'K'},
> >>> +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> >>> + {"private-key", required_argument, NULL, 'P'},
> >>> + {"certificate", required_argument, NULL, 'C'},
> >>> + {"monotonic-count", required_argument, NULL, 'm'},
> >>
> >> These options should not be required.
> >
> > I don't get you. What do you mean?
> >
> >>> + {"dump-sig", no_argument, NULL, 'd'},
> >>> +#endif
> >>> {"overlay", no_argument, NULL, 'O'},
> >>> {"help", no_argument, NULL, 'h'},
> >>> {NULL, 0, NULL, 0},
> >>> @@ -70,6 +93,12 @@ static void print_usage(void)
> >>>"\t-I, --instanceupdate hardware instance\n"
> >>>
Re: [PATCH v5 1/3] efi_loader: expose efi_image_parse() even if UEFI Secure Boot is disabled
On Thu, 13 May 2021 at 13:35, Heinrich Schuchardt wrote: > > On 5/12/21 1:32 PM, Masahisa Kojima wrote: > > This is preparation for PE/COFF measurement support. > > PE/COFF image hash calculation is same in both > > UEFI Secure Boot image verification and measurement in > > measured boot. PE/COFF image parsing functions are > > gathered into efi_image_loader.c, and exposed even if > > UEFI Secure Boot is not enabled. > > > > This commit also adds the EFI_SIGNATURE_SUPPORT option > > to decide if efi_signature.c shall be compiled. > > > > Signed-off-by: Masahisa Kojima > > This patch leads to an error: > > lib/crypto/x509_public_key.c:85: more undefined references to > `hash_calculate' follow > collect2: error: ld returned 1 exit status > make: *** [Makefile:1726: u-boot] Error 1 > > Applying the patches in the given sequence will break git bisect. > > Please, correct the sequence of the patches in the series. Sorry, my patch sequence is wrong. Modification to include hash-checksum.o as compilation target must be the first patch. > > Best regards > > Heinrich > > > --- > > > > (no changes since v4) > > > > Changes in v4: > > - revert #ifdef instead of using "if (!IS_ENABLED())" statement, > >not to rely on the compiler optimization. > > > > Changes in v3: > > - hide EFI_SIGNATURE_SUPPORT option > > > > Changes in v2: > > - Remove all #ifdef from efi_image_loader.c and efi_signature.c > > - Add EFI_SIGNATURE_SUPPORT option > > - Explicitly include > > - Gather PE/COFF parsing functions into efi_image_loader.c > > - Move efi_guid_t efi_guid_image_security_database in efi_var_common.c > > > > lib/efi_loader/Kconfig| 6 +++ > > lib/efi_loader/Makefile | 2 +- > > lib/efi_loader/efi_image_loader.c | 64 - > > lib/efi_loader/efi_signature.c| 67 +-- > > lib/efi_loader/efi_var_common.c | 3 ++ > > 5 files changed, 74 insertions(+), 68 deletions(-) > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > index c259abe033..385a81d7d9 100644 > > --- a/lib/efi_loader/Kconfig > > +++ b/lib/efi_loader/Kconfig > > @@ -174,6 +174,7 @@ config EFI_CAPSULE_AUTHENTICATE > > select PKCS7_MESSAGE_PARSER > > select PKCS7_VERIFY > > select IMAGE_SIGN_INFO > > + select EFI_SIGNATURE_SUPPORT > > default n > > help > > Select this option if you want to enable capsule > > @@ -342,6 +343,7 @@ config EFI_SECURE_BOOT > > select X509_CERTIFICATE_PARSER > > select PKCS7_MESSAGE_PARSER > > select PKCS7_VERIFY > > + select EFI_SIGNATURE_SUPPORT > > default n > > help > > Select this option to enable EFI secure boot support. > > @@ -349,6 +351,10 @@ config EFI_SECURE_BOOT > > it is signed with a trusted key. To do that, you need to install, > > at least, PK, KEK and db. > > > > +config EFI_SIGNATURE_SUPPORT > > + bool > > + depends on EFI_SECURE_BOOT || EFI_CAPSULE_AUTHENTICATE > > + > > config EFI_ESRT > > bool "Enable the UEFI ESRT generation" > > depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT > > diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile > > index 8bd343e258..fd344cea29 100644 > > --- a/lib/efi_loader/Makefile > > +++ b/lib/efi_loader/Makefile > > @@ -63,7 +63,7 @@ obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o > > obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o > > obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o > > obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o > > -obj-y += efi_signature.o > > +obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o > > > > EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE)) > > $(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE) > > diff --git a/lib/efi_loader/efi_image_loader.c > > b/lib/efi_loader/efi_image_loader.c > > index f53ef367ec..fe1ee198e2 100644 > > --- a/lib/efi_loader/efi_image_loader.c > > +++ b/lib/efi_loader/efi_image_loader.c > > @@ -213,7 +213,68 @@ static void efi_set_code_and_data_type( > > } > > } > > > > -#ifdef CONFIG_EFI_SECURE_BOOT > > +/** > > + * efi_image_region_add() - add an entry of region > > + * @regs:Pointer to array of regions > > + * @start: Start address of region (included) > > + * @end: End address of region (excluded) > > + * @nocheck: flag against overlapped regions > > + * > > + * Take one entry of region [@start, @end[ and insert it into the list. > > + * > > + * * If @nocheck is false, the list will be sorted ascending by address. > > + * Overlapping entries will not be allowed. > > + * > > + * * If @nocheck is true, the list will be sorted ascending by sequence > > + * of adding the entries. Overlapping is allowed. > > + * > > + * Return: status code > > + */ > > +efi_status_t efi_image_region_add(struct efi_image_regions *regs, > > + const void *start, const void *end, > > + int
Re: [PATCH 2/4] tools: mkeficapsule: remove device-tree related operation
On 5/13/21 4:33 AM, AKASHI Takahiro wrote:
On Wed, May 12, 2021 at 12:01:32PM +0200, Heinrich Schuchardt wrote:
On 12.05.21 10:01, Ilias Apalodimas wrote:
On Wed, May 12, 2021 at 04:49:02PM +0900, Masami Hiramatsu wrote:
Hi Ilias,
2021年5月12日(水) 16:21 Ilias Apalodimas :
Akashi-san,
On Wed, May 12, 2021 at 01:57:51PM +0900, AKASHI Takahiro wrote:
As we discussed, "-K" and "-D" options have nothing to do with
creating a capsule file. The same result can be obtained by
using standard commands like:
=== signature.dts ===
/dts-v1/;
/plugin/;
&{/} {
signature {
capsule-key = /incbin/("SIGNER.esl");
};
};
===
$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
$ fdtoverlay -i test.dtb -o test_sig.dtb -v signature.dtbo
So just remove this feature.
(Effectively revert the commit 322c813f4bec ("mkeficapsule: Add support
for embedding public key in a dtb").)
The same feature is implemented by a shell script (tools/fdtsig.sh).
The only reason I can see to keep this, is if mkeficapsule gets included
intro distro packages in the future. That would make end users life a bit
easier, since they would need a single binary to create the whole
CapsuleUpdate sequence.
Hmm, I think it is better to write a manpage of mkeficapsule which
also describes
how to embed the key into dtb as in the above example if it is so short.
Or, distros can package the above shell script with mkeficapsule.
Embedding a key and signing a capsule are different operations but
using the same tool may confuse users (at least me).
Sure fair enough. I am merely pointing out we need a way to explain all of
those to users.
This is currently our only documentation:
https://u-boot.readthedocs.io/en/latest/board/emulation/qemu_capsule_update.html?highlight=mkeficapsule
As I mentioned several times (and TODO in the cover letter),
this text must be reviewed, revised and generalized
as a platform-independent document.
It contains a couple of errors.
For mkimage we have a man-page ./doc/mkimage.1 that is packaged with
Debians u-boot-tools package. Please, provide a similar man-page as
./doc/mkeficapsule.1.
So after all do you agree to removing "-K/-D"?
I see no need to replicate in U-Boot what is already in the device tree
compiler package.
In the current workflow the fdt command is used to load the public key.
This is insecure and not usable for production.
The public key used to verify the capsule must be built into the U-Boot
binary. This will supplant the -K and -D options.
Best regards
Heinrich
Otherwise, I cannot complete the man page.
-Takahiro Akashi
Best regards
Heinrich
Re: [PATCH V4 2/2] riscv: board: Support OpenPiton SoC
Hi Sean, On 5/13/2021 1:14 AM, Sean Anderson wrote: [snip] On 5/8/2021 11:14 PM, Sean Anderson wrote: On 5/8/21 12:57 AM, Tianrui Wei wrote: On 5/7/2021 9:03 PM, Sean Anderson wrote: On 5/6/21 11:48 PM, Tianrui Wei wrote: On 5/7/2021 11:41 AM, Sean Anderson wrote: On 5/6/21 11:28 PM, Tianrui Wei wrote: On 5/7/2021 11:15 AM, Sean Anderson wrote: On 5/6/21 11:06 PM, Tianrui Wei wrote: On 5/7/2021 10:32 AM, Sean Anderson wrote: Please use a log without debug uart. So this is the part where it was a little confusing. Disabling debug uart acutally doesn't work for some reason, so we had to keep it open. Will submit another patch if we got it working with debug uart turned off. This is a bit of a strange request, but can you try adding some nops() (around 10-30) to some function (e.g. board_init). I've been having alignment problems in k210, so it could be something similar. I was wondering if you have any idea what may cause the alignment problems, we're also hitting it constantly and adding nops seems to have no impact so far. I have no idea :) If adding nop()s doesn't solve it, it may not be an alignment problem. You can also try switching from -Os to -O2, which should move things around a bit. My attempts to dig into this have been stymied by the poor debugging tools for the k210. The upstream openocd port only supports debugging hart 0. While Canaan's fork supports debugging both harts, you must pick the one to debug when launching the debugger. And both debuggers are very buggy themselves. The other problem on the k210 at least is that the typical failure mode (trying to read from unaddressable/unmapped addresses) hangs the bus. This also has the tendancy of hanging the jtag debug port. I did try to switch from -Os to -O2, and it didn't help either. I've also encountered the same debugger situation unfortunately, so I have not much luck finding the faulty instruction either. Maybe we should bring this issue up with the others along the compilation error? Thanks, Tianrui --Sean
Re: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing
On Thu, May 13, 2021 at 06:22:39AM +0200, Heinrich Schuchardt wrote:
> On 5/13/21 5:08 AM, AKASHI Takahiro wrote:
> > On Wed, May 12, 2021 at 10:56:41AM +0200, Heinrich Schuchardt wrote:
> > > On 12.05.21 06:57, AKASHI Takahiro wrote:
> > > > With this enhancement, mkeficapsule will be able to create a capsule
> > > > file with a signature which will be verified later by FMP's SetImage().
> > > >
> > > > We will have to specify addtional command parameters:
> > > >-monotonic-cout : monotonic count
> > > >-private-key : private key file
> > > >-certificate : certificate file
> > > > Only when those parameters are given, a signature will be added
> > > > to a capsule file.
> > > >
> > > > Users are expected to maintain the monotonic count for each firmware
> > > > image.
> > > >
> > > > Signed-off-by: AKASHI Takahiro
> > > > ---
> > > > tools/Makefile | 4 +
> > > > tools/mkeficapsule.c | 324 +++
> > > > 2 files changed, 303 insertions(+), 25 deletions(-)
> > > >
> > > > diff --git a/tools/Makefile b/tools/Makefile
> > > > index d020c55d6644..02eae0286e20 100644
> > > > --- a/tools/Makefile
> > > > +++ b/tools/Makefile
> > > > @@ -231,6 +231,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
> > > > hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler
> > > > HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
> > > >
> > > > +ifneq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),)
> > > > +HOSTLDLIBS_mkeficapsule += \
> > > > + $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo
> > > > "-lssl -lcrypto")
> > >
> > > I don't expect any user wants to install two tool versions in parallel.
> > >
> > > The tool should always be able to add a signature.
> > > Adding a signature must be optional.
> >
> > It seems to me that those two statements mutually contradict.
> > Or do you intend to say that we should have a separate kconfig
> > option to enable/disable signing feature in mkeficapsule?
> >
> > If so, I can agree.
> >
> > In either way, we should have an option to turn on/off this functionality
> > as not all users use signed capsules.
>
> I want to have a single binary to distribute with Linux distros (e.g.
> Debian/Ubuntu package u-boot-tools).
>
> This should allow both
>
> - create signed capsules
> - create unsigned capsules
>
> The user shall select signing via command line parameters.
>
> Support for signing via the tool shall not depend on board Kconfig
> parameters.
That is why I proposed that we create a new kconfig option.
Please note that enabling signing feature in mkeficapsule
requires openssl library, and we should not enforce users who don't
need this feature to install an unnecessary package.
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> >
> > > > +endif
> > > > mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS)
> > > > hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
> > > >
> > > > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> > > > index de0a62898886..34ff1bdd82eb 100644
> > > > --- a/tools/mkeficapsule.c
> > > > +++ b/tools/mkeficapsule.c
> > > > @@ -18,7 +18,17 @@
> > > > #include
> > > > #include
> > > >
> > > > -#include "fdt_host.h"
> > > > +#include
> > > > +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > >
> > > see above
> > >
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#endif
> > > > +
> > > > +#include
> > > >
> > > > typedef __u8 u8;
> > > > typedef __u16 u16;
> > > > @@ -46,6 +56,13 @@ efi_guid_t efi_guid_image_type_uboot_fit =
> > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
> > > > efi_guid_t efi_guid_image_type_uboot_raw =
> > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
> > > > +efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> > > > +
> > > > +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > >
> > > see above
> > >
> > > > +static const char *opts_short = "f:r:i:I:v:D:K:P:C:m:dOh";
> > > > +#else
> > > > +static const char *opts_short = "f:r:i:I:v:D:K:Oh";
> > > > +#endif
> > > >
> > > > static struct option options[] = {
> > > > {"fit", required_argument, NULL, 'f'},
> > > > @@ -54,6 +71,12 @@ static struct option options[] = {
> > > > {"instance", required_argument, NULL, 'I'},
> > > > {"dtb", required_argument, NULL, 'D'},
> > > > {"public key", required_argument, NULL, 'K'},
> > > > +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > > > + {"private-key", required_argument, NULL, 'P'},
> > > > + {"certificate", required_argument, NULL, 'C'},
> > > > + {"monotonic-count", required_argument, NULL, 'm'},
> > >
> > > These options should not be required.
> >
> > I don't get you. What do you mean?
> >
> > > > + {"dump-sig", no_argument, NULL, 'd'},
> > > > +#endif
> > > > {"overlay", no_argument, NULL, 'O'},
> >
Re: [PATCH v5 1/3] efi_loader: expose efi_image_parse() even if UEFI Secure Boot is disabled
On 5/12/21 1:32 PM, Masahisa Kojima wrote:
This is preparation for PE/COFF measurement support.
PE/COFF image hash calculation is same in both
UEFI Secure Boot image verification and measurement in
measured boot. PE/COFF image parsing functions are
gathered into efi_image_loader.c, and exposed even if
UEFI Secure Boot is not enabled.
This commit also adds the EFI_SIGNATURE_SUPPORT option
to decide if efi_signature.c shall be compiled.
Signed-off-by: Masahisa Kojima
This patch leads to an error:
lib/crypto/x509_public_key.c:85: more undefined references to
`hash_calculate' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:1726: u-boot] Error 1
Applying the patches in the given sequence will break git bisect.
Please, correct the sequence of the patches in the series.
Best regards
Heinrich
---
(no changes since v4)
Changes in v4:
- revert #ifdef instead of using "if (!IS_ENABLED())" statement,
not to rely on the compiler optimization.
Changes in v3:
- hide EFI_SIGNATURE_SUPPORT option
Changes in v2:
- Remove all #ifdef from efi_image_loader.c and efi_signature.c
- Add EFI_SIGNATURE_SUPPORT option
- Explicitly include
- Gather PE/COFF parsing functions into efi_image_loader.c
- Move efi_guid_t efi_guid_image_security_database in efi_var_common.c
lib/efi_loader/Kconfig| 6 +++
lib/efi_loader/Makefile | 2 +-
lib/efi_loader/efi_image_loader.c | 64 -
lib/efi_loader/efi_signature.c| 67 +--
lib/efi_loader/efi_var_common.c | 3 ++
5 files changed, 74 insertions(+), 68 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c259abe033..385a81d7d9 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -174,6 +174,7 @@ config EFI_CAPSULE_AUTHENTICATE
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
select IMAGE_SIGN_INFO
+ select EFI_SIGNATURE_SUPPORT
default n
help
Select this option if you want to enable capsule
@@ -342,6 +343,7 @@ config EFI_SECURE_BOOT
select X509_CERTIFICATE_PARSER
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
+ select EFI_SIGNATURE_SUPPORT
default n
help
Select this option to enable EFI secure boot support.
@@ -349,6 +351,10 @@ config EFI_SECURE_BOOT
it is signed with a trusted key. To do that, you need to install,
at least, PK, KEK and db.
+config EFI_SIGNATURE_SUPPORT
+ bool
+ depends on EFI_SECURE_BOOT || EFI_CAPSULE_AUTHENTICATE
+
config EFI_ESRT
bool "Enable the UEFI ESRT generation"
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 8bd343e258..fd344cea29 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o
-obj-y += efi_signature.o
+obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o
EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
$(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index f53ef367ec..fe1ee198e2 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -213,7 +213,68 @@ static void efi_set_code_and_data_type(
}
}
-#ifdef CONFIG_EFI_SECURE_BOOT
+/**
+ * efi_image_region_add() - add an entry of region
+ * @regs: Pointer to array of regions
+ * @start: Start address of region (included)
+ * @end: End address of region (excluded)
+ * @nocheck: flag against overlapped regions
+ *
+ * Take one entry of region [@start, @end[ and insert it into the list.
+ *
+ * * If @nocheck is false, the list will be sorted ascending by address.
+ * Overlapping entries will not be allowed.
+ *
+ * * If @nocheck is true, the list will be sorted ascending by sequence
+ * of adding the entries. Overlapping is allowed.
+ *
+ * Return: status code
+ */
+efi_status_t efi_image_region_add(struct efi_image_regions *regs,
+ const void *start, const void *end,
+ int nocheck)
+{
+ struct image_region *reg;
+ int i, j;
+
+ if (regs->num >= regs->max) {
+ EFI_PRINT("%s: no more room for regions\n", __func__);
+ return EFI_OUT_OF_RESOURCES;
+ }
+
+ if (end < start)
+ return EFI_INVALID_PARAMETER;
+
+ for (i = 0; i < regs->num; i++) {
+ reg = >reg[i];
+ if (nocheck)
+ continue;
+
+ /* new data after registered region */
+ if (start >= reg->data + reg->size)
+ continue;
+
+
Re: [PATCH] mvebu: x530: Reduce SPL image size
Hi Chris, On 12.05.21 23:20, Chris Packham wrote: On Wed, May 12, 2021 at 8:06 PM Stefan Roese wrote: On 12.05.21 09:59, Chris Packham wrote: On Wed, May 12, 2021 at 7:18 PM Stefan Roese wrote: Currently, building U-Boot for x530 fails since the SPL image is too big. Currently? It's working for me on master. Are there upcoming mvebu changes that push us over the limit? Yes, I'm working on a pull request right now. Some enhancements to the SPI driver are most likely responsible for the code increase. This patch reduces the SPL size by changing the following Kconfig options: Enable CONFIG_SPL_TINY_MEMSET Disable CONFIG_SPI_FLASH_BAR By disabling CONFIG_SPI_FLASH_BAR, the tiny SPI NOR framework can be used. I've got a nagging feeling I needed CONFIG_SPI_FLASH_BAR for some reason. Possibly for some alternate part we were looking at, on the other hand it could also be from the db88f6820-amc board which I based the initial defconfig on. Looking at what CONFIG_SPI_FLASH_BAR does I think we should be safe. We only fit 16MiB parts and aren't likely to start fitting bigger parts unless all the spi-nor vendors decide to stop making ones <16MiB. Please note that there are better ways to handle the > 16MiB SPI NOR issue. E.g. by using 3 vs 4 byte commands and Serial Flash Discoverable Parameters (SFDP) parsing, which is supported in U-Boot since quite some time. I did not use CONFIG_SPI_FLASH_BAR for a longer time now IIRC. I think (but am not sure) that the 4 byte command mode upsets the bootrom when booting from spi flash. On and off I've hit a problem on the db-88f6820-amc which does have a 32MiB flash fitted where the bootrom can't fetch the first boot stage on reboot after booting linux (for some kernel versions). Power cycling resolves the problem. I think this might be because the bootrom only speaks the 3 byte protocol and once the chip is put into 4 byte mode the bootrom lacks the ability to change back. None of this affects the x530 so there is no problem with this change. I'm just putting this out there for future mailing list readers. Yes, this is known issue. Or it was a known issue. Newer version support the stateless 4-byte opcodes, which don't configure the SPI NOR into 4-byte mode. This resolves this problem with the bootrom AFAIR. Thanks, Stefan
Re: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing
On 5/13/21 5:08 AM, AKASHI Takahiro wrote:
On Wed, May 12, 2021 at 10:56:41AM +0200, Heinrich Schuchardt wrote:
On 12.05.21 06:57, AKASHI Takahiro wrote:
With this enhancement, mkeficapsule will be able to create a capsule
file with a signature which will be verified later by FMP's SetImage().
We will have to specify addtional command parameters:
-monotonic-cout : monotonic count
-private-key : private key file
-certificate : certificate file
Only when those parameters are given, a signature will be added
to a capsule file.
Users are expected to maintain the monotonic count for each firmware
image.
Signed-off-by: AKASHI Takahiro
---
tools/Makefile | 4 +
tools/mkeficapsule.c | 324 +++
2 files changed, 303 insertions(+), 25 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index d020c55d6644..02eae0286e20 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -231,6 +231,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler
HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
+ifneq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),)
+HOSTLDLIBS_mkeficapsule += \
+ $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl
-lcrypto")
I don't expect any user wants to install two tool versions in parallel.
The tool should always be able to add a signature.
Adding a signature must be optional.
It seems to me that those two statements mutually contradict.
Or do you intend to say that we should have a separate kconfig
option to enable/disable signing feature in mkeficapsule?
If so, I can agree.
In either way, we should have an option to turn on/off this functionality
as not all users use signed capsules.
I want to have a single binary to distribute with Linux distros (e.g.
Debian/Ubuntu package u-boot-tools).
This should allow both
- create signed capsules
- create unsigned capsules
The user shall select signing via command line parameters.
Support for signing via the tool shall not depend on board Kconfig
parameters.
Best regards
Heinrich
+endif
mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS)
hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index de0a62898886..34ff1bdd82eb 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -18,7 +18,17 @@
#include
#include
-#include "fdt_host.h"
+#include
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+#include
+#include
+#include
+#include
+#include
+#include
+#endif
+
+#include
typedef __u8 u8;
typedef __u16 u16;
@@ -46,6 +56,13 @@ efi_guid_t efi_guid_image_type_uboot_fit =
EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
efi_guid_t efi_guid_image_type_uboot_raw =
EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
+efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
+
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+static const char *opts_short = "f:r:i:I:v:D:K:P:C:m:dOh";
+#else
+static const char *opts_short = "f:r:i:I:v:D:K:Oh";
+#endif
static struct option options[] = {
{"fit", required_argument, NULL, 'f'},
@@ -54,6 +71,12 @@ static struct option options[] = {
{"instance", required_argument, NULL, 'I'},
{"dtb", required_argument, NULL, 'D'},
{"public key", required_argument, NULL, 'K'},
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
+ {"private-key", required_argument, NULL, 'P'},
+ {"certificate", required_argument, NULL, 'C'},
+ {"monotonic-count", required_argument, NULL, 'm'},
These options should not be required.
I don't get you. What do you mean?
+ {"dump-sig", no_argument, NULL, 'd'},
+#endif
{"overlay", no_argument, NULL, 'O'},
{"help", no_argument, NULL, 'h'},
{NULL, 0, NULL, 0},
@@ -70,6 +93,12 @@ static void print_usage(void)
"\t-I, --instanceupdate hardware instance\n"
"\t-K, --public-key public key esl file\n"
"\t-D, --dtb dtb file\n"
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
+ "\t-P, --private-key private key file\n"
+ "\t-C, --certificate signer's certificate file\n"
+ "\t-m, --monotonic-count monotonic count\n"
+ "\t-d, --dump_sig dump signature (*.p7)\n"
+#endif
"\t-O, --overlay the dtb file is an overlay\n"
"\t-h, --help print a help message\n",
tool_name);
@@ -249,12 +278,167 @@ err:
return ret;
}
+struct auth_context {
+ char *key_file;
+ char *cert_file;
+ u8 *image_data;
+ size_t image_size;
+ struct efi_firmware_image_authentication auth;
+ u8 *sig_data;
+ size_t sig_size;
+};
+
+static int dump_sig;
+
+#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
RE: [PATCH v2] mmc: Update environment variable with active partition
Hi Jaehoon, > is mandatory, and [ ] is > optional. > If optional variable will be used, those variables can be mandatory, right? > > mmc partconf is displayed even without other variables. > > "mmc partconf [[varname] | [ > ]]" is correct usage for yours. > > It means varname or other options variable can be chosen. I agree, this seems like a better way to format the help. I have sent a new patch with it changed to your suggestion. Regards, Reuben
[PATCH v3] mmc: Update environment variable with active partition
This patch allows uboot scripts make choices about where to boot from based
on the active mmc boot partition. This allows having two copies of kernel,
filesystems etc, and choosing which to boot from based off of the active
bootloader partition.
Signed-off-by: Reuben Dowle
---
cmd/mmc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index a10f137..b942576 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -808,7 +808,7 @@ static int do_mmc_boot_resize(struct cmd_tbl *cmdtp, int
flag,
return CMD_RET_SUCCESS;
}
-static int mmc_partconf_print(struct mmc *mmc)
+static int mmc_partconf_print(struct mmc *mmc, const char *varname)
{
u8 ack, access, part;
@@ -821,6 +821,9 @@ static int mmc_partconf_print(struct mmc *mmc)
ack = EXT_CSD_EXTRACT_BOOT_ACK(mmc->part_config);
part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
+ if(varname)
+ env_set_hex(varname, part);
+
printf("EXT_CSD[179], PARTITION_CONFIG:\n"
"BOOT_ACK: 0x%x\n"
"BOOT_PARTITION_ENABLE: 0x%x\n"
@@ -836,7 +839,7 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
struct mmc *mmc;
u8 ack, part_num, access;
- if (argc != 2 && argc != 5)
+ if (argc != 2 && argc != 3 && argc != 5)
return CMD_RET_USAGE;
dev = simple_strtoul(argv[1], NULL, 10);
@@ -850,8 +853,8 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
return CMD_RET_FAILURE;
}
- if (argc == 2)
- return mmc_partconf_print(mmc);
+ if (argc == 2 || argc == 3)
+ return mmc_partconf_print(mmc, argc == 3 ? argv[2] : NULL);
ack = simple_strtoul(argv[2], NULL, 10);
part_num = simple_strtoul(argv[3], NULL, 10);
@@ -1061,8 +1064,9 @@ U_BOOT_CMD(
" - Set the BOOT_BUS_WIDTH field of the specified device\n"
"mmc bootpart-resize \n"
" - Change sizes of boot and RPMB partitions of specified device\n"
- "mmc partconf [boot_ack boot_partition partition_access]\n"
+ "mmc partconf [[varname] | [
]]\n"
" - Show or change the bits of the PARTITION_CONFIG field of the
specified device\n"
+ " If showing the bits, optionally store the boot_partition field into
varname\n"
"mmc rst-function \n"
" - Change the RST_n_FUNCTION field of the specified device\n"
" WARNING: This is a write-once field and 0 / 1 / 2 are the only
valid values.\n"
--
2.7.4
Re: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing
On Wed, May 12, 2021 at 10:56:41AM +0200, Heinrich Schuchardt wrote:
> On 12.05.21 06:57, AKASHI Takahiro wrote:
> > With this enhancement, mkeficapsule will be able to create a capsule
> > file with a signature which will be verified later by FMP's SetImage().
> >
> > We will have to specify addtional command parameters:
> > -monotonic-cout : monotonic count
> > -private-key : private key file
> > -certificate : certificate file
> > Only when those parameters are given, a signature will be added
> > to a capsule file.
> >
> > Users are expected to maintain the monotonic count for each firmware
> > image.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > tools/Makefile | 4 +
> > tools/mkeficapsule.c | 324 +++
> > 2 files changed, 303 insertions(+), 25 deletions(-)
> >
> > diff --git a/tools/Makefile b/tools/Makefile
> > index d020c55d6644..02eae0286e20 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -231,6 +231,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
> > hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler
> > HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
> >
> > +ifneq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),)
> > +HOSTLDLIBS_mkeficapsule += \
> > + $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl
> > -lcrypto")
>
> I don't expect any user wants to install two tool versions in parallel.
>
> The tool should always be able to add a signature.
> Adding a signature must be optional.
It seems to me that those two statements mutually contradict.
Or do you intend to say that we should have a separate kconfig
option to enable/disable signing feature in mkeficapsule?
If so, I can agree.
In either way, we should have an option to turn on/off this functionality
as not all users use signed capsules.
> > +endif
> > mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS)
> > hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
> >
> > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> > index de0a62898886..34ff1bdd82eb 100644
> > --- a/tools/mkeficapsule.c
> > +++ b/tools/mkeficapsule.c
> > @@ -18,7 +18,17 @@
> > #include
> > #include
> >
> > -#include "fdt_host.h"
> > +#include
> > +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
>
> see above
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#endif
> > +
> > +#include
> >
> > typedef __u8 u8;
> > typedef __u16 u16;
> > @@ -46,6 +56,13 @@ efi_guid_t efi_guid_image_type_uboot_fit =
> > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
> > efi_guid_t efi_guid_image_type_uboot_raw =
> > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
> > +efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> > +
> > +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
>
> see above
>
> > +static const char *opts_short = "f:r:i:I:v:D:K:P:C:m:dOh";
> > +#else
> > +static const char *opts_short = "f:r:i:I:v:D:K:Oh";
> > +#endif
> >
> > static struct option options[] = {
> > {"fit", required_argument, NULL, 'f'},
> > @@ -54,6 +71,12 @@ static struct option options[] = {
> > {"instance", required_argument, NULL, 'I'},
> > {"dtb", required_argument, NULL, 'D'},
> > {"public key", required_argument, NULL, 'K'},
> > +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > + {"private-key", required_argument, NULL, 'P'},
> > + {"certificate", required_argument, NULL, 'C'},
> > + {"monotonic-count", required_argument, NULL, 'm'},
>
> These options should not be required.
I don't get you. What do you mean?
> > + {"dump-sig", no_argument, NULL, 'd'},
> > +#endif
> > {"overlay", no_argument, NULL, 'O'},
> > {"help", no_argument, NULL, 'h'},
> > {NULL, 0, NULL, 0},
> > @@ -70,6 +93,12 @@ static void print_usage(void)
> >"\t-I, --instanceupdate hardware instance\n"
> >"\t-K, --public-key public key esl file\n"
> >"\t-D, --dtb dtb file\n"
> > +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
>
> see above
>
> > + "\t-P, --private-key private key file\n"
> > + "\t-C, --certificate signer's certificate file\n"
> > + "\t-m, --monotonic-count monotonic count\n"
> > + "\t-d, --dump_sig dump signature (*.p7)\n"
> > +#endif
> >"\t-O, --overlay the dtb file is an overlay\n"
> >"\t-h, --help print a help message\n",
> >tool_name);
> > @@ -249,12 +278,167 @@ err:
> > return ret;
> > }
> >
> > +struct auth_context {
> > + char *key_file;
> > + char *cert_file;
> > + u8 *image_data;
> > + size_t image_size;
> > + struct efi_firmware_image_authentication auth;
> > + u8 *sig_data;
> > + size_t sig_size;
> > +};
> > +
> > +static int dump_sig;
> > +
> > +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
>
> see above
>
> > +static EVP_PKEY *fileio_read_pkey(const char *filename)
Re: [PATCH 2/4] tools: mkeficapsule: remove device-tree related operation
On Wed, May 12, 2021 at 12:01:32PM +0200, Heinrich Schuchardt wrote:
> On 12.05.21 10:01, Ilias Apalodimas wrote:
> > On Wed, May 12, 2021 at 04:49:02PM +0900, Masami Hiramatsu wrote:
> >> Hi Ilias,
> >>
> >> 2021年5月12日(水) 16:21 Ilias Apalodimas :
> >>>
> >>> Akashi-san,
> >>>
> >>> On Wed, May 12, 2021 at 01:57:51PM +0900, AKASHI Takahiro wrote:
> As we discussed, "-K" and "-D" options have nothing to do with
> creating a capsule file. The same result can be obtained by
> using standard commands like:
> === signature.dts ===
> /dts-v1/;
> /plugin/;
>
> &{/} {
> signature {
> capsule-key = /incbin/("SIGNER.esl");
> };
> };
> ===
> $ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
> $ fdtoverlay -i test.dtb -o test_sig.dtb -v signature.dtbo
>
> So just remove this feature.
> (Effectively revert the commit 322c813f4bec ("mkeficapsule: Add support
> for embedding public key in a dtb").)
>
> The same feature is implemented by a shell script (tools/fdtsig.sh).
> >>>
> >>>
> >>> The only reason I can see to keep this, is if mkeficapsule gets included
> >>> intro distro packages in the future. That would make end users life a bit
> >>> easier, since they would need a single binary to create the whole
> >>> CapsuleUpdate sequence.
> >>
> >> Hmm, I think it is better to write a manpage of mkeficapsule which
> >> also describes
> >> how to embed the key into dtb as in the above example if it is so short.
> >> Or, distros can package the above shell script with mkeficapsule.
> >>
> >> Embedding a key and signing a capsule are different operations but
> >> using the same tool may confuse users (at least me).
> >
> > Sure fair enough. I am merely pointing out we need a way to explain all of
> > those to users.
>
> This is currently our only documentation:
>
> https://u-boot.readthedocs.io/en/latest/board/emulation/qemu_capsule_update.html?highlight=mkeficapsule
As I mentioned several times (and TODO in the cover letter),
this text must be reviewed, revised and generalized
as a platform-independent document.
It contains a couple of errors.
> For mkimage we have a man-page ./doc/mkimage.1 that is packaged with
> Debians u-boot-tools package. Please, provide a similar man-page as
> ./doc/mkeficapsule.1.
So after all do you agree to removing "-K/-D"?
Otherwise, I cannot complete the man page.
-Takahiro Akashi
> Best regards
>
> Heinrich
Re: [PATCH] riscv: ax25-ae350: doc: Fix minor format issues
> From: Bin Meng > Sent: Wednesday, May 12, 2021 11:26 PM > To: Rick Jian-Zhi Chen(陳建志) ; u-boot@lists.denx.de > Cc: Bin Meng > Subject: [PATCH] riscv: ax25-ae350: doc: Fix minor format issues > > This fixes two minor format issues of the ax25-ae350 reST file. > > Signed-off-by: Bin Meng > --- > > doc/board/AndesTech/ax25-ae350.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Rick Chen
[PATCH 2/2 v2] Add EV-iMX280-NANO-X-MB board
A simple prototyping board with one microSD port, one Ethernet port,
2 USB ports, I2C, SPI, GPIO, and UART interfaces.
Signed-off-by: Oleh Kravchenko
Cc: Stefano Babic
---
MAINTAINERS | 2 +
arch/arm/dts/Makefile| 3 +
arch/arm/dts/ev-imx280-nano-x-mb.dts | 109 +++
board/out4/o4-imx6ull-nano/Kconfig | 7 ++
board/out4/o4-imx6ull-nano/o4-imx6ull-nano.c | 22 ++--
configs/ev-imx280-nano-x-mb_defconfig| 91
6 files changed, 224 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/dts/ev-imx280-nano-x-mb.dts
create mode 100644 configs/ev-imx280-nano-x-mb_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 786476c016..609d059f17 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -920,9 +920,11 @@ OUT4-IMX6ULL-NANO BOARD
M: Oleh Kravchenko
S: Maintained
T: git https://github.com/Oleh-Kravchenko/u-boot-out4.git
+F: arch/arm/dts/ev-imx280-nano-x-mb.dts
F: arch/arm/dts/o4-imx-nano.dts
F: arch/arm/dts/o4-imx6ull-nano.dtsi
F: board/out4
+F: configs/ev-imx280-nano-x-mb_defconfig
F: configs/o4-imx6ull-nano_defconfig
F: include/configs/o4-imx6ull-nano.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0b2de37280..3868d4d0f9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -767,6 +767,9 @@ dtb-$(CONFIG_ARCH_MX6) += \
dtb-$(CONFIG_O4_IMX_NANO) += \
o4-imx-nano.dtb
+dtb-$(CONFIG_EV_IMX280_NANO_X_MB) += \
+ ev-imx280-nano-x-mb.dtb
+
dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
imx7d-sdb-qspi.dtb \
imx7-colibri-emmc.dtb \
diff --git a/arch/arm/dts/ev-imx280-nano-x-mb.dts
b/arch/arm/dts/ev-imx280-nano-x-mb.dts
new file mode 100644
index 00..7aec076af3
--- /dev/null
+++ b/arch/arm/dts/ev-imx280-nano-x-mb.dts
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2021 Oleh Kravchenko
+
+/dts-v1/;
+
+#include "o4-imx6ull-nano.dtsi"
+
+/ {
+ model = "EV-iMX280-NANO-X-MB";
+ compatible = "evodbg,ev-imx280-nano-x-mb",
+"out4,o4-imx6ull-nano",
+"fsl,imx6ull";
+
+ aliases {
+ mmc1 =
+ };
+
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10069
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ MX6UL_PAD_UART1_RTS_B__USDHC1_CD_B 0x03029
+ >;
+ };
+
+ pinctrl_mdio: mdiogrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO0x1b0b0
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_SNVS_TAMPER1__GPIO5_IO01 0xb0b0 /* RST */
+ >;
+ };
+
+ pinctrl_usb_otg1_id: usbotg1idgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID0x17059
+ >;
+ };
+};
+
+ {
+ pinctrl-0 = <_uart1>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+ {
+ bus-width = <4>;
+ no-1-8-v;
+ pinctrl-0 = <_usdhc1>;
+ pinctrl-names = "default";
+ status = "okay";
+ wakeup-source;
+};
+
+ {
+ phy-handle = <>;
+ phy-mode = "rmii";
+ phy-reset-duration = <250>;
+ phy-reset-post-delay = <100>;
+ phy-reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <_fec1 _mdio>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@0 {
+ clocks = < IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ interrupt-parent = <>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <_phy0_irq>;
+ pinctrl-names = "default";
+ reg = <0>;
+ };
+ };
+};
+
+ {
+ dr_mode = "otg";
+ pinctrl-0 = <_usb_otg1_id>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+ {
+ dr_mode = "host";
+ status = "okay";
+};
diff --git a/board/out4/o4-imx6ull-nano/Kconfig
b/board/out4/o4-imx6ull-nano/Kconfig
index
[PATCH 1/2 v2] Add out4.ru O4-iMX-NANO board
Board designed for quick prototyping and has one microSD port,
2 Ethernet ports, 2 USB ports, I2C, SPI, CAN, RS-485, GPIO,
UART interfaces, and 2 RGB LEDs.
Signed-off-by: Oleh Kravchenko
Cc: Stefano Babic
---
MAINTAINERS | 10 +
arch/arm/dts/Makefile | 3 +
arch/arm/dts/o4-imx-nano.dts | 241 ++
arch/arm/dts/o4-imx6ull-nano.dtsi | 87 +++
arch/arm/mach-imx/mx6/Kconfig | 13 +
.../out4/o4-imx6ull-nano/K4B4G1646D-BCMA.cfg | 91 +++
board/out4/o4-imx6ull-nano/Kconfig| 57 +
.../o4-imx6ull-nano/MT41K256M16HA-125E.cfg| 91 +++
board/out4/o4-imx6ull-nano/Makefile | 4 +
board/out4/o4-imx6ull-nano/o4-imx6ull-nano.c | 86 +++
configs/o4-imx6ull-nano_defconfig | 103
include/configs/o4-imx6ull-nano.h | 25 ++
12 files changed, 811 insertions(+)
create mode 100644 arch/arm/dts/o4-imx-nano.dts
create mode 100644 arch/arm/dts/o4-imx6ull-nano.dtsi
create mode 100644 board/out4/o4-imx6ull-nano/K4B4G1646D-BCMA.cfg
create mode 100644 board/out4/o4-imx6ull-nano/Kconfig
create mode 100644 board/out4/o4-imx6ull-nano/MT41K256M16HA-125E.cfg
create mode 100644 board/out4/o4-imx6ull-nano/Makefile
create mode 100644 board/out4/o4-imx6ull-nano/o4-imx6ull-nano.c
create mode 100644 configs/o4-imx6ull-nano_defconfig
create mode 100644 include/configs/o4-imx6ull-nano.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c6dd9bf838..786476c016 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -916,6 +916,16 @@ S: Orphaned (Since 2017-01)
T: git https://source.denx.de/u-boot/custodians/u-boot-onenand.git
F: drivers/mtd/onenand/
+OUT4-IMX6ULL-NANO BOARD
+M: Oleh Kravchenko
+S: Maintained
+T: git https://github.com/Oleh-Kravchenko/u-boot-out4.git
+F: arch/arm/dts/o4-imx-nano.dts
+F: arch/arm/dts/o4-imx6ull-nano.dtsi
+F: board/out4
+F: configs/o4-imx6ull-nano_defconfig
+F: include/configs/o4-imx6ull-nano.h
+
PATMAN
M: Simon Glass
S: Maintained
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9a8de46272..0b2de37280 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -764,6 +764,9 @@ dtb-$(CONFIG_ARCH_MX6) += \
imx6-apalis.dtb \
imx6-colibri.dtb
+dtb-$(CONFIG_O4_IMX_NANO) += \
+ o4-imx-nano.dtb
+
dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
imx7d-sdb-qspi.dtb \
imx7-colibri-emmc.dtb \
diff --git a/arch/arm/dts/o4-imx-nano.dts b/arch/arm/dts/o4-imx-nano.dts
new file mode 100644
index 00..d1785b7dc7
--- /dev/null
+++ b/arch/arm/dts/o4-imx-nano.dts
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2021 Oleh Kravchenko
+
+/dts-v1/;
+
+#include
+
+#include "o4-imx6ull-nano.dtsi"
+
+/ {
+ model = "O4-iMX-NANO";
+ compatible = "out4,o4-imx-nano",
+"out4,o4-imx6ull-nano",
+"fsl,imx6ull";
+
+ aliases {
+ mmc1 =
+ };
+
+ chosen {
+ stdout-path =
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led@0 {
+ color = ;
+ gpios = < 0 GPIO_ACTIVE_LOW>;
+ reg = <0>;
+ };
+
+ led@1 {
+ color = ;
+ gpios = < 1 GPIO_ACTIVE_LOW>;
+ reg = <1>;
+ };
+
+ led@2 {
+ gpios = < 2 GPIO_ACTIVE_LOW>;
+ color = ;
+ reg = <2>;
+ };
+
+ led@3 {
+ color = ;
+ gpios = < 3 GPIO_ACTIVE_LOW>;
+ reg = <3>;
+ };
+
+ led@4 {
+ color = ;
+ gpios = < 4 GPIO_ACTIVE_LOW>;
+ reg = <4>;
+ };
+
+ led@5 {
+ color = ;
+ gpios = < 5 GPIO_ACTIVE_LOW>;
+ reg = <5>;
+ };
+ };
+
+ usbotg1_vbus: reg_usbotg1_vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < 6 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <500>;
+ regulator-min-microvolt = <500>;
+ regulator-name = "usb0";
+ };
+
+ usbotg2_vbus: reg_usbotg2_vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <500>;
+ regulator-min-microvolt = <500>;
+ regulator-name = "usb1";
+ };
+};
+
+ {
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+
[PATCH] Fix flash and erase of EMMC_BOOT2 with fastboot
The current U-Boot version has the next matches for boot partitions:
> mmc0boot0 to EMMC_BOOT1
> mmc0boot1 to EMMC_BOOT1 (should be EMMC_BOOT2)
This patch fixes a typo for the boot partition number.
Signed-off-by: Oleh Kravchenko
Cc: Pantelis Antoniou
Cc: Marek Vasut
---
drivers/fastboot/fb_mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 8e74e50e91..1827ce5d12 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -525,7 +525,7 @@ void fastboot_mmc_flash_write(const char *cmd, void
*download_buffer,
if (strcmp(cmd, CONFIG_FASTBOOT_MMC_BOOT2_NAME) == 0) {
dev_desc = fastboot_mmc_get_dev(response);
if (dev_desc)
- fb_mmc_boot_ops(dev_desc, download_buffer, 1,
+ fb_mmc_boot_ops(dev_desc, download_buffer, 2,
download_bytes, response);
return;
}
@@ -655,7 +655,7 @@ void fastboot_mmc_erase(const char *cmd, char *response)
/* erase EMMC boot2 */
dev_desc = fastboot_mmc_get_dev(response);
if (dev_desc)
- fb_mmc_boot_ops(dev_desc, NULL, 1, 0, response);
+ fb_mmc_boot_ops(dev_desc, NULL, 2, 0, response);
return;
}
#endif
--
2.26.3
Re: [GIT PULL] TI changes for v2021.07 rc3
On Wed, May 12, 2021 at 07:31:15PM +0530, Lokesh Vutla wrote: > Hi Tom, > Please find the PR for master branch targeted for v2021.07-rc1 release. > Details about the PR are updated in the tag message. > > There are addition of new platform in this PR. I understand it is not > expected to send these this late in the release. However, these are > posted sometime ago and I could not spend time on these patches due > to personal reasons. Please consider this as an exception and accept > this PR. I ll try not to repeat this in future PRs. > > Gitlab build report: > https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7474 > > The following changes since commit b107761b817c421fb8eadee739656e1db38686c3: > > Prepare v2021.07-rc2 (2021-05-10 17:03:22 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.07-rc3 > > for you to fetch changes up to bbc9da58b332bd44e51ac5579040ea984b2f963b: > > ARM: dts: k3-am642-sk: Add ethernet related DT nodes (2021-05-12 16:36:39 > +0530) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
- Forwarded message from scan-ad...@coverity.com - Date: Mon, 10 May 2021 21:17:32 + (UTC) From: scan-ad...@coverity.com To: tom.r...@gmail.com Subject: New Defects reported by Coverity Scan for Das U-Boot Hi, Please find the latest report on new defect(s) introduced to Das U-Boot found with Coverity Scan. 1 new defect(s) introduced to Das U-Boot found with Coverity Scan. 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 331544: Null pointer dereferences (REVERSE_INULL) /drivers/core/ofnode.c: 317 in ofnode_get_addr_size_index() *** CID 331544: Null pointer dereferences (REVERSE_INULL) /drivers/core/ofnode.c: 317 in ofnode_get_addr_size_index() 311 uint flags; 312 313 prop_val = of_get_address(ofnode_to_np(node), index, , 314 ); 315 if (!prop_val) 316 return FDT_ADDR_T_NONE; >>> CID 331544: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "size" suggests that it may be null, but it has already >>> been dereferenced on all paths leading to the check. 317 if (size) 318 *size = size64; 319 320 ns = of_n_size_cells(ofnode_to_np(node)); 321 322 if (IS_ENABLED(CONFIG_OF_TRANSLATE) && To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yoA22WlOQ-2By3ieUvdbKmOyw68TMVT4Kip-2BBzfOGWXJ5yIiYplmPF9KAnKIja4Zd7tU-3DG8yI_EEm8SbLgSDsaDZif-2Bv7ch8WqhKpLoKErHi4nXpwDNTtU1-2Brl29AQnRBl5SDIhsdlk4JL-2BC60Yy99Ru0XHXKZmudWSFasqNbw3J8c8YsieibEgnFne8AQZsraqyZc6bSorO2VVj4yo2EYbDylqVK-2BNvmB4zxqglhPpQGYCxEyim-2BCmtR1oyAQcyUT-2F0UpwA2s3mUEbsptAVDqX6MTucjWlw-3D-3D To manage Coverity Scan email notifications for "tom.r...@gmail.com", click https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxWeIHzDeopm-2BEWQ6S6K-2FtUHv9ZTk8qZbuzkkz9sa-2BJFw4elYDyedRVZOC-2ButxjBZdouVmTGuWB6Aj6G7lm7t25-2Biv1B-2B9082pHzCCex2kqMs-3DcN-g_EEm8SbLgSDsaDZif-2Bv7ch8WqhKpLoKErHi4nXpwDNTtU1-2Brl29AQnRBl5SDIhsdlpXdtm0ziQZhCdYNwPtYo9juOCfJRYvUSD6RBDul3PpPJtEbQAvJyD64um9NlavMb-2FNhtaCPCgg1OZOg6fyHdjqmNc-2BSac4T2ShWFTENHS5073Orso2HRCvi56uwUJuZ8ILMBdsEOC5-2FtuCAU-2BmbVBQ-3D-3D - End forwarded message - -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/5] Fix i.MXRT1050 hang on lcdif init and improve DT for mxsfb
Hi Stefano, On 5/2/21 1:44 AM, Giulio Benetti wrote: On 4/13/21 1:05 AM, Giulio Benetti wrote: On 4/13/21 1:03 AM, Giulio Benetti wrote: This patchset fixes u-boot hang on i.MXRT1050 while setting lcdif in mxsfb driver. There are 2 gates to be enabled to initialize mxsfb so let's introduce the missing gate as a clock and rename "per" clock to "pix" clock since in the other .dts files using *-lcdif "pix" is used. This patchset add also "disp_axi" clock enabling in mxsfb that should make able to every i.MX SoC with lcdif using DT. I didn't test it other than i.MXRT1050 since I don't have the boards. If someone can test it it would be great. Note that i.MX23/28 should fail using DT instead because they don't specify any clock-names in their dts. I've forgotten to specify that this patchset depends on this patchset: https://patchwork.ozlabs.org/project/uboot/list/?series=237909 This ^^^ series is superseeded by v2: https://patchwork.ozlabs.org/project/uboot/list/?series=241701 Current patchset is not superseeded, only the one which depends to is superseeded by v2. Do you prefer me to send a unique patchset with all patches of both patchsets? Kind regards -- Giulio Benetti Benetti Engineering sas
RE: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
Hello Peng,
> -Original Message-
> From: U-Boot On Behalf Of Peng Fan (OSS)
> Sent: Friday, March 19, 2021 8:57 AM
> To: sba...@denx.de; feste...@gmail.com
> Cc: u-boot@lists.denx.de; uboot-...@nxp.com; Ye Li
> Subject: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
>
> From: Ye Li
>
> Update PMIC to use PCA9540, the legacy board not supported by NXP
This commit seems rather a "nuclear" to me, as de-facto it drops the
initialization of ROMH PMIC in
favor of PCA one, leaving all the previous board revisions not to be properly
sourced.
I know that there might be no intention to provide a support for earlier
revisions of i.MX8M Mini
EVKs from NXP, but providing no backward compatibility to those boards which
are still in use by
a lot of people for development purposes is highly undesirable either.
TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and
apart from having some
error messages in SPL regarding the register writes - it does boots. What
worries me the most though
is that DTS changes some voltage settings, which I'm not sure how the SOC would
react on.
To my opinion, this patch should either be complemented with the mechanism to
provide a
level of backward compatibility (where the PMIC can be dynamically identified
and instantiated),
or the separate implementation should be presented which would make the old
board type not to
be bootable at all if it is considered not to be supported any longer. Or this
patch should be reverted
in an effort to come up with a solution which covers new revision without
"damaging" the currently
integrated one.
Fabio / Stefano,
Do you have any thoughts here on how this should be handled further,
considering the fact that the
backward compatibility of 2021.07 release is not kept for this board type
across multiple revisions?
I'd really like to get your opinion here as I do have those boards in
development and would need to
come up with the idea on what to do with them.
Also, this should be taken care of in the Yocto, since there is only one
definition of the i.MX8MM EVK
machine which does not make any distinction regarding the revision.
Thanks a lot!
>
> Signed-off-by: Ye Li
> ---
> arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4 +-
> arch/arm/dts/imx8mm-evk.dtsi| 127 +++-
> board/freescale/imx8mm_evk/spl.c| 33
> configs/imx8mm_evk_defconfig| 2 +-
> 4 files changed, 86 insertions(+), 80 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-
> u-boot.dtsi
> index e843a5648e..7f48912b49 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -114,11 +114,11 @@
> u-boot,dm-spl;
> };
>
> -&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
> +&{/soc@0/bus@3080/i2c@30a2/pca9450@25} {
> u-boot,dm-spl;
> };
>
> -&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
> +&{/soc@0/bus@3080/i2c@30a2/pca9450@25/regulators} {
> u-boot,dm-spl;
> };
>
> diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> index 6518f088b2..60179e006d 100644
> --- a/arch/arm/dts/imx8mm-evk.dtsi
> +++ b/arch/arm/dts/imx8mm-evk.dtsi
> @@ -126,115 +126,120 @@
> pinctrl-0 = <_i2c1>;
> status = "okay";
>
> - pmic@4b {
> - compatible = "rohm,bd71847";
> - reg = <0x4b>;
> - pinctrl-names = "default";
> + pmic: pca9450@25 {
> + reg = <0x25>;
> + compatible = "nxp,pca9450a";
> + /* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */
> pinctrl-0 = <_pmic>;
> - interrupt-parent = <>;
> - interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> - rohm,reset-snvs-powered;
> -
> - #clock-cells = <0>;
> - clocks = <_32k 0>;
> - clock-output-names = "clk-32k-out";
> + gpio_intr = < 3 GPIO_ACTIVE_LOW>;
>
> regulators {
> - buck1_reg: BUCK1 {
> - regulator-name = "buck1";
> - regulator-min-microvolt = <70>;
> - regulator-max-microvolt = <130>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pca9450,pmic-buck2-uses-i2c-dvs;
> + /* Run/Standby voltage */
> + pca9450,pmic-buck2-dvs-voltage = <95>,
> + <85>;
> +
> + buck1_reg: regulator@0 {
> + reg = <0>;
> + regulator-compatible = "buck1";
> + regulator-min-microvolt = <60>;
> + regulator-max-microvolt = <2187500>;
> regulator-boot-on;
>
Re: [PATCH 1/1] sandbox: ensure that state->ram_buf is in low memory
Am 12. Mai 2021 18:01:17 MESZ schrieb Simon Glass : >Hi Heinrich, > >On Tue, 11 May 2021 at 13:03, Heinrich Schuchardt >wrote: >> >> Addresses in state->ram_buf must be in the low 4 GiB of the address >space. >> Otherwise we cannot correctly fill SMBIOS tables. This shows up in >warnings >> like: >> >> WARNING: SMBIOS table_address overflow 7f752735e020 > >This sounds like a bug in the smbios-table code. For sandbox it should >perhaps use addresses instead of pointers. > >I think that code (that I unfortunately wrote) was an expeditious way >of getting it running, but is not correct. The field you are filling is only 32bit wide. I wonder how that table is meant to work on systems where the lowest memory address is above 4 GiB. Such ARMv8 systems exist. Best regards Heinrich > >> >> Ensure that state->ram_buf is initialized by the first invocation of >> os_malloc(). >> >> Signed-off-by: Heinrich Schuchardt >> --- >> arch/sandbox/cpu/start.c | 12 >> 1 file changed, 8 insertions(+), 4 deletions(-) >> > >Regards, >Simon
Re: [PATCH 3/3] hash: Allow for SHA512 hardware implementations
Am 12. Mai 2021 19:32:42 MESZ schrieb Simon Glass : >Hi Heinrich, > >On Wed, 12 May 2021 at 10:25, Heinrich Schuchardt >wrote: >> >> On 12.05.21 18:05, Simon Glass wrote: >> > Hi Heinrich, >> > >> > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt > wrote: >> >> >> >> On 17.02.21 04:20, Joel Stanley wrote: >> >>> Similar to support for SHA1 and SHA256, allow the use of hardware >hashing >> >>> engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL >/ >> >>> CONFIG_SHA_PROG_HW_ACCEL. >> >>> >> >>> Signed-off-by: Joel Stanley >> >> >> >> This merged patch leads to errors compiling the EFI TCG2 protocol >on >> >> boards with CONFIG_SHA_HW_ACCEL. >> >> >> >> There is not as single implementation of hw_sha384 and hw_sha512. >You >> >> could only use CONFIG_SHA_HW_ACCEL for selecting these functions >if >> >> these were implemented for *all* boards with >CONFIG_SHA_HW_ACCEL=y. But >> >> this will never happen. >> >> >> >> *This patch needs to be reverted.* >> >> >> >> Why do we have CONFIG_SHA_HW_ACCEL at all and don't use weak >functions >> >> instead? >> > >> > This is all a mess. We should not use weak functions IMO, but >instead >> > have a driver interface, like we do with filesystems. >> > >> > Part of the challenge is the need to keep code size small for >> > platforms that only need one algorithm. >> >> If a function is not referenced, the linker will eliminate it. But >with >> a driver interface every function in the interface is referenced. > >Indeed, but we can still have an option for enabling the progressive >interface. My point is that the implementation (software or hardware) >should use a driver. > >Regards, >Simon Anyway that should not stop us from reverting a problematic patch. We can work on refactoring afterwards. Best regards Heinrich
Zynq MPSoC Dynamic DDR DIMM Configuration support
Hi Michal We are doing some work on an MPSoC UZ3EG platform part of which requires us to replace FSBL with SPL. It seems the actual boot process is becoming an issue on these SoCs; currently, 1) we embed the PMU firmware on SPL so the bootrom can extract it and program it; 2) then SPL configures the PMU using a platform specific binary that gets built also with SPL; and finally, 3) SPL sets up the DDR using its psu_init_gpl.c settings (also board specific, part of the XSA). It is this final step in the boot sequence that is being broken by the Dynamic DDR DIMM configuration feature [1] [1] https://www.xilinx.com/support/answers/75768.html Are you aware of any work in progress to support this? Any thoughts on how to work around it and train the DDR? will the functionality required to implmenet Dynamic DDR DIMM configuration be added as a separate file to the XSA tarball or will we need to do some native implementation in SPL? Becase without a change in the last link in the process chain described earlier (calls to psu_init()), DDR just wont be accessible to U-BOOT or OP-TEE. In our case, we were able to boot from QSPI, boot SPL (in OCM), have SPL unpack and validate the FIT image, execute TF-A(in OCM), but then any jumps to OP-TEE or U-BOOT would obviously not progress since the DDR wasnt properly trained/initialized. so, any thoughts or plans you can share? TIA! jorge
Re: [PATCH] mvebu: x530: Reduce SPL image size
On Wed, May 12, 2021 at 8:06 PM Stefan Roese wrote: > > On 12.05.21 09:59, Chris Packham wrote: > > On Wed, May 12, 2021 at 7:18 PM Stefan Roese wrote: > >> > >> Currently, building U-Boot for x530 fails since the SPL image is too > >> big. > > > > Currently? It's working for me on master. Are there upcoming mvebu > > changes that push us over the limit? > > Yes, I'm working on a pull request right now. Some enhancements to the > SPI driver are most likely responsible for the code increase. > > >> This patch reduces the SPL size by changing the following Kconfig > >> options: > >> > >> Enable CONFIG_SPL_TINY_MEMSET > >> Disable CONFIG_SPI_FLASH_BAR > >> > >> By disabling CONFIG_SPI_FLASH_BAR, the tiny SPI NOR framework can be > >> used. > > > > I've got a nagging feeling I needed CONFIG_SPI_FLASH_BAR for some > > reason. Possibly for some alternate part we were looking at, on the > > other hand it could also be from the db88f6820-amc board which I based > > the initial defconfig on. > > > > Looking at what CONFIG_SPI_FLASH_BAR does I think we should be safe. > > We only fit 16MiB parts and aren't likely to start fitting bigger > > parts unless all the spi-nor vendors decide to stop making ones > > <16MiB. > > Please note that there are better ways to handle the > 16MiB SPI > NOR issue. E.g. by using 3 vs 4 byte commands and Serial Flash > Discoverable Parameters (SFDP) parsing, which is supported in > U-Boot since quite some time. I did not use CONFIG_SPI_FLASH_BAR > for a longer time now IIRC. > I think (but am not sure) that the 4 byte command mode upsets the bootrom when booting from spi flash. On and off I've hit a problem on the db-88f6820-amc which does have a 32MiB flash fitted where the bootrom can't fetch the first boot stage on reboot after booting linux (for some kernel versions). Power cycling resolves the problem. I think this might be because the bootrom only speaks the 3 byte protocol and once the chip is put into 4 byte mode the bootrom lacks the ability to change back. None of this affects the x530 so there is no problem with this change. I'm just putting this out there for future mailing list readers. > >> > >> Signed-off-by: Stefan Roese > >> Cc: Chris Packham > >> Cc: Pratyush Yadav > >> Cc: Tom Rini > > > > Tested-by: Chris Packham > > > > (yes I'm mixing work and personal email addresses. I can re-send > > tomorrow from the office if that's a concern). > > This is okay for me. > > Thanks for the quick review and test. > > Thanks, > Stefan > > >> --- > >> configs/x530_defconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/configs/x530_defconfig b/configs/x530_defconfig > >> index 890c94b5c1fe..76574c4de4be 100644 > >> --- a/configs/x530_defconfig > >> +++ b/configs/x530_defconfig > >> @@ -62,7 +62,6 @@ CONFIG_SYS_NAND_USE_FLASH_BBT=y > >> CONFIG_NAND_PXA3XX=y > >> CONFIG_SF_DEFAULT_BUS=1 > >> CONFIG_SF_DEFAULT_SPEED=5000 > >> -CONFIG_SPI_FLASH_BAR=y > >> CONFIG_SPI_FLASH_MACRONIX=y > >> CONFIG_SPI_FLASH_STMICRO=y > >> CONFIG_SPI_FLASH_SST=y > >> @@ -84,3 +83,4 @@ CONFIG_USB_ETHER_ASIX=y > >> CONFIG_USB_ETHER_ASIX88179=y > >> CONFIG_WDT=y > >> CONFIG_WDT_ORION=y > >> +CONFIG_SPL_TINY_MEMSET=y > >> -- > >> 2.31.1 > >> > > > Viele Grüße, > Stefan > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v5 00/10] Add support for extension boards detection and DT overlays application
Hello Tom, On Tue, 4 May 2021 19:31:20 +0200 Kory Maincent wrote: > Kory Maincent (10): > fdt_support: move fdt_valid from cmd_fdt.c to fdt_support.c > cmd: add support for a new "extension" command > pytest: add sandbox test for "extension" command > ti/common: add support for extension_scan_board function > am57xx: add support for cape detect functionality > w1: replace dt detection by automatic detection > arm: sunxi: add support for DIP detection to CHIP board > configs: CHIP: add support for DIP detect functionality > arm: am335x: add support for i2c2 bus > am335x: add support for cape detect functionality This series has gone through 5 iterations since the first posting mid-February. On version 4, we haven't received any feedback except your request to resend an updated version based on the latest master. What are the plans with this series? Do you expect to receive more reviews? Or do you plan to apply it? Indeed, as the only comment on v4 was to rebase on master and v5 doesn't get apply soon enough, it will again no longer cleanly apply on master :-) Do not hesitate to let us know what is needed to get this series considered for merging. Thanks a lot! Thomas Petazzoni -- Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH] ARM: rmobile: Add missing rcar-common/common.c to Beacon RZG2M kit
On Wed, May 12, 2021 at 2:58 PM Marek Vasut wrote:
>
> The rcar-common/common.c contains various common board functions shared
> by all R-Car and RZG boards. This board is not compiling the file in, so
> add it. This way, part of the board code can be de-duplicated too.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Adam Ford
> Cc: Adam Ford
> ---
> board/beacon/beacon-rzg2m/Makefile | 2 +-
> board/beacon/beacon-rzg2m/beacon-rzg2m.c | 15 ---
> 2 files changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/board/beacon/beacon-rzg2m/Makefile
> b/board/beacon/beacon-rzg2m/Makefile
> index 439f3199aa..9131a92efa 100644
> --- a/board/beacon/beacon-rzg2m/Makefile
> +++ b/board/beacon/beacon-rzg2m/Makefile
> @@ -6,4 +6,4 @@
> # SPDX-License-Identifier: GPL-2.0+
> #
>
> -obj-y := beacon-rzg2m.o
> +obj-y := beacon-rzg2m.o ../../renesas/rcar-common/common.o
> diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> index 0c7f8e54e9..c12ff77fb2 100644
> --- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> +++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> @@ -28,21 +28,6 @@ int board_init(void)
> return 0;
> }
>
> -int dram_init(void)
> -{
> - if (fdtdec_setup_mem_size_base() != 0)
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -int dram_init_banksize(void)
> -{
> - fdtdec_setup_memory_banksize();
> -
> - return 0;
> -}
> -
> #define RST_BASE 0xE616
> #define RST_CA57RESCNT (RST_BASE + 0x40)
> #define RST_CODE 0xA5A5000F
> --
> 2.30.2
>
[PATCH] ARM: rmobile: Add missing rcar-common/common.c to Beacon RZG2M kit
The rcar-common/common.c contains various common board functions shared
by all R-Car and RZG boards. This board is not compiling the file in, so
add it. This way, part of the board code can be de-duplicated too.
Signed-off-by: Marek Vasut
Cc: Adam Ford
---
board/beacon/beacon-rzg2m/Makefile | 2 +-
board/beacon/beacon-rzg2m/beacon-rzg2m.c | 15 ---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/board/beacon/beacon-rzg2m/Makefile
b/board/beacon/beacon-rzg2m/Makefile
index 439f3199aa..9131a92efa 100644
--- a/board/beacon/beacon-rzg2m/Makefile
+++ b/board/beacon/beacon-rzg2m/Makefile
@@ -6,4 +6,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y := beacon-rzg2m.o
+obj-y := beacon-rzg2m.o ../../renesas/rcar-common/common.o
diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
index 0c7f8e54e9..c12ff77fb2 100644
--- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
+++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
@@ -28,21 +28,6 @@ int board_init(void)
return 0;
}
-int dram_init(void)
-{
- if (fdtdec_setup_mem_size_base() != 0)
- return -EINVAL;
-
- return 0;
-}
-
-int dram_init_banksize(void)
-{
- fdtdec_setup_memory_banksize();
-
- return 0;
-}
-
#define RST_BASE 0xE616
#define RST_CA57RESCNT (RST_BASE + 0x40)
#define RST_CODE 0xA5A5000F
--
2.30.2
Re: [PATCH 1/1] sandbox: fix sandbox_reset()
On Wed, May 12, 2021 at 06:38:51PM +0200, Heinrich Schuchardt wrote: > state_uninit() and dm_uninit() are mutually exclusive: > > state_uninit() prints via drivers. So it cannot be executed after > dm_uninit(). > > dm_uninit() requires memory. So it cannot be executed after state_uninit() > which releases all memory. > > Just skip dm_uninit() when resetting the sandbox. We will wake up in a new > process and allocate new memory. So this cleanup is not required. We don't > do it in sandbox_exit() either. > > This avoids a segmentation error when efi_reset_system_boottime() is > invoked by a UEFI application. Hi Heinrich, Thanks for fixing this! Before, I was hitting the following segfault with the sandbox under qemu arm64 when running the UEFI SCT: Boot services test: ExitBootServices_Conf Iterations: 1/1 System will cold reset after 2 second and test will be resumed after reboot.resetting ... Writing sandbox state qemu: uncaught target signal 11 (Segmentation fault) - core dumped With your patch I do not hit this segfault anymore. FWIW, feel free to add (or not): Tested-by: Vincent Stehlé Best regards, Vincent. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/start.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c > index e87365e800..4ffd97ccbc 100644 > --- a/arch/sandbox/cpu/start.c > +++ b/arch/sandbox/cpu/start.c > @@ -425,9 +425,6 @@ void sandbox_reset(void) > if (state_uninit()) > os_exit(2); > > - if (dm_uninit()) > - os_exit(2); > - > /* Restart U-Boot */ > os_relaunch(os_argv); > } > -- > 2.30.2 >
Re: [PATCH 3/3] hash: Allow for SHA512 hardware implementations
Hi Heinrich, On Wed, 12 May 2021 at 10:25, Heinrich Schuchardt wrote: > > On 12.05.21 18:05, Simon Glass wrote: > > Hi Heinrich, > > > > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt > > wrote: > >> > >> On 17.02.21 04:20, Joel Stanley wrote: > >>> Similar to support for SHA1 and SHA256, allow the use of hardware hashing > >>> engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL / > >>> CONFIG_SHA_PROG_HW_ACCEL. > >>> > >>> Signed-off-by: Joel Stanley > >> > >> This merged patch leads to errors compiling the EFI TCG2 protocol on > >> boards with CONFIG_SHA_HW_ACCEL. > >> > >> There is not as single implementation of hw_sha384 and hw_sha512. You > >> could only use CONFIG_SHA_HW_ACCEL for selecting these functions if > >> these were implemented for *all* boards with CONFIG_SHA_HW_ACCEL=y. But > >> this will never happen. > >> > >> *This patch needs to be reverted.* > >> > >> Why do we have CONFIG_SHA_HW_ACCEL at all and don't use weak functions > >> instead? > > > > This is all a mess. We should not use weak functions IMO, but instead > > have a driver interface, like we do with filesystems. > > > > Part of the challenge is the need to keep code size small for > > platforms that only need one algorithm. > > If a function is not referenced, the linker will eliminate it. But with > a driver interface every function in the interface is referenced. Indeed, but we can still have an option for enabling the progressive interface. My point is that the implementation (software or hardware) should use a driver. Regards, Simon > Heinrich
Re: [PATCH] usb: dwc3-generic: Disable host driver definition if gadget only
On 5/12/21 4:11 PM, Kunihiko Hayashi wrote: Even if only USB gadget is defined, dwc3 generic driver enables a definition and probe/remove functions for host driver. This enables the definition if USB_HOST is enabled only. Applied, thanks.
Re: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build
Hi Alex, On Wed, 12 May 2021 at 10:18, Alex G. wrote: > > > > On 5/12/21 10:54 AM, Simon Glass wrote: > > Hi Alex, > > > > On Wed, 12 May 2021 at 09:48, Alex G. wrote: > >> > >> > >> > >> On 5/12/21 9:51 AM, Simon Glass wrote: > >>> Hi Alex, > >>> > >>> On Tue, 11 May 2021 at 13:57, Alex G. wrote: > > On 5/6/21 9:24 AM, Simon Glass wrote: > >> > >> [snip] > >> > > > + > > +config HOST_FIT_PRINT > > + def_bool y > > + help > > + Print the content of the FIT verbosely in the host build > > This option also doesn't make sense.This seems to do what 'mkimage -l' > already supports. > >>> > >>> Are you sure you have looked at the goal of the CONFIG_IS_ENABLED() > >>> changes? This is here purely to avoid #ifdefs in the share code. > >> > >> On the one hand, we have the cosmetic inconvenience caused by #ifdefs. > >> On the other hand we have the config system. To most users, the config > >> system is likely more visible, while it's mostly developers who will > >> ever see the ifdefs. > >> > >> Therefore, in order to get the developer convenience of less ifdefs, we > >> have to sacrifice user convenience by cloberring the Kconfig options. I > >> think this is back-to-front. > > > > These Kconfig options are not visible to users. They cannot be updated > > in defconfig, nor in 'make menuconfig', etc. They are purely there for > > the build system. > > > >> > >> Can we reduce the host config count to just SLL/NOSSL? > > > > The point here is that the code has a special case for host builds, > > and this is a means to remove that special case and make the code > > easier to maintain and follow. > > I understand where you're coming from. Without these changes, the code > knows what it should and should not do, correct? My argument is that if > the code has the logic to do the correct thing, that logic should not be > split with the config system. > > I agree with the goal of reducing clutter in the source code. I disagree > with this specific course of fixing it. Instead, I propose a single > kconfig for host tools for SSL on/off. > > The disadvantage of my proposal is that we have to refactor the common > code in a way consistent with the goals, instead of just changing some > #ifdefs to if(CONFIG_IS_ENABLED()). I admit that, off the top of my > head, I don't have a detailed plan on how to achieve this. You are mostly describing the status quo, so far as I understand it. The problem is with the code that is built for both boards and tools. For boards, we want this code to be compiled conditionally, depending on what options are enabled. For tools, we want the code to be compiled unconditionally. I can think of only three ways to do this: - status quo (add #ifdefs USE_HOSTCC wherever we need to) - my series (make use of hidden Kconfig options to avoid that) - put every single feature and associated lines of code in separate files and compile them conditionally for boards, but always for tools I believe the last option is actually impossible, or at least impractical. It would cause an explosion of source files to deal with all the various combinations, and would be quite painful to maintain also. Regards, SImon
Re: [PATCH 3/3] hash: Allow for SHA512 hardware implementations
Hi, On Wed, May 12, 2021 at 06:19:58PM +0200, Heinrich Schuchardt wrote: > On 12.05.21 18:05, Simon Glass wrote: > > Hi Heinrich, > > > > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt > > wrote: > >> > >> On 17.02.21 04:20, Joel Stanley wrote: > >>> Similar to support for SHA1 and SHA256, allow the use of hardware hashing > >>> engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL / > >>> CONFIG_SHA_PROG_HW_ACCEL. > >>> > >>> Signed-off-by: Joel Stanley > >> > >> This merged patch leads to errors compiling the EFI TCG2 protocol on > >> boards with CONFIG_SHA_HW_ACCEL. > >> > >> There is not as single implementation of hw_sha384 and hw_sha512. You > >> could only use CONFIG_SHA_HW_ACCEL for selecting these functions if > >> these were implemented for *all* boards with CONFIG_SHA_HW_ACCEL=y. But > >> this will never happen. > >> > >> *This patch needs to be reverted.* > >> > >> Why do we have CONFIG_SHA_HW_ACCEL at all and don't use weak functions > >> instead? > > > > This is all a mess. We should not use weak functions IMO, but instead > > have a driver interface, like we do with filesystems. > > > > Part of the challenge is the need to keep code size small for > > platforms that only need one algorithm. > > If a function is not referenced, the linker will eliminate it. But with > a driver interface every function in the interface is referenced. > > Best regards > > Heinrich There's a fundamental problem with TCG2. The algorithms you need to support and log are dictated by the TPM2 hardware and it's configuration. That's a thing we can't detect at build time. So since we don't know that, we are requiring support for all the known algorithms U-Boot supports and are mandated from the spec (SHA1/256/384/512). One way to solve this is move the 'select' to 'depends', and only allow for the protocol, if all the algorithms we need are present in the .config. But this is just a way to sidestep the problem for now. I agree with Heinrich that using a single Kconfig isn't realistic.
Re: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build
On Wed, May 12, 2021 at 11:19:52AM -0500, Alex G. wrote: > > > On 5/12/21 10:52 AM, Simon Glass wrote: > > Hi, > > > > On Tue, 11 May 2021 at 19:10, Tom Rini wrote: > > > > > > On Tue, May 11, 2021 at 07:50:38PM -0500, Alex G. wrote: > > > > On 5/11/21 5:34 PM, Tom Rini wrote: > > > > > On Tue, May 11, 2021 at 02:57:03PM -0500, Alex G. wrote: > > > > > > On 5/6/21 9:24 AM, Simon Glass wrote: > > > > > > > In preparation for enabling CONFIG_IS_ENABLED() on the host > > > > > > > build, add > > > > > > > some options to enable the various FIT options expected in these > > > > > > > tools. > > > > > > > This will ensure that the code builds correctly when > > > > > > > CONFIG_HOST_xxx > > > > > > > is distinct from CONFIG_xxx. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > Reviewed-by: Alexandru Gagniuc > > > > > > > > > > > > This makes me wonder whether we should just always enable host > > > > > > features. > > > > > > Right now, each defconfig can have a different mkimage config. So > > > > > > we should > > > > > > really have mkimage-imx8, mkimage-stm32mp, etc, which support > > > > > > different > > > > > > feature sets. This doesn't make much sense. > > > > > > > > > > > > The alternative is to get rid of all these configs and always > > > > > > enable mkimage > > > > > > features. The disadvantage is that we'd require openssl for > > > > > > building target > > > > > > code. > > > > > > > > > > > > A second alternative is to have a mkimage-nossl that gets built and > > > > > > used > > > > > > when openssl isn't available. It's really just openssl that causes > > > > > > such a > > > > > > schism. > > > > > > > > > > It would probably be best to have a single mkimage for everyone, with > > > > > everything on. But before then we really need to move from openssl to > > > > > gnutls or some other library that's compatible as it's been raised > > > > > before that linking with openssl like we do is a license violation I > > > > > believe. > > > > > > > > How about the former alternative for now? i.e. compile mkimage with or > > > > without openssl, and have that be the only host side switch. > > > > > > That would be a step in the right direction, yeah. > > > > We have a NO_SDL build-time control. Perhaps have a NO_SSL one as well? > > It could be a config option instead of an environment variable. I think it > can be independent of target options, since we don't sign images in the > buildsystem anyway -- we can enable FIT verification, but mkimage without > openssl. As people point out from time to time, "NO_SDL" is very non-obvious and doesn't fit with how the rest of U-Boot is configured. So I would rather not see NO_SSL added. Frankly, given everything else that's needed to build today, I don't think just enabling the support for verified boot in mkimage by default and making it a bit odd to turn off is a problem. But given: https://lists.denx.de/pipermail/u-boot/2017-December/313742.html I would really like to see the switch to gnutls or some other clearly compatibly licensed library first. -- Tom signature.asc Description: PGP signature
Re: [PATCH V4 2/2] riscv: board: Support OpenPiton SoC
[snip] On 5/8/2021 11:14 PM, Sean Anderson wrote: On 5/8/21 12:57 AM, Tianrui Wei wrote: On 5/7/2021 9:03 PM, Sean Anderson wrote: On 5/6/21 11:48 PM, Tianrui Wei wrote: On 5/7/2021 11:41 AM, Sean Anderson wrote: On 5/6/21 11:28 PM, Tianrui Wei wrote: On 5/7/2021 11:15 AM, Sean Anderson wrote: On 5/6/21 11:06 PM, Tianrui Wei wrote: On 5/7/2021 10:32 AM, Sean Anderson wrote: Please use a log without debug uart. So this is the part where it was a little confusing. Disabling debug uart acutally doesn't work for some reason, so we had to keep it open. Will submit another patch if we got it working with debug uart turned off. This is a bit of a strange request, but can you try adding some nops() (around 10-30) to some function (e.g. board_init). I've been having alignment problems in k210, so it could be something similar. I was wondering if you have any idea what may cause the alignment problems, we're also hitting it constantly and adding nops seems to have no impact so far. I have no idea :) If adding nop()s doesn't solve it, it may not be an alignment problem. You can also try switching from -Os to -O2, which should move things around a bit. My attempts to dig into this have been stymied by the poor debugging tools for the k210. The upstream openocd port only supports debugging hart 0. While Canaan's fork supports debugging both harts, you must pick the one to debug when launching the debugger. And both debuggers are very buggy themselves. The other problem on the k210 at least is that the typical failure mode (trying to read from unaddressable/unmapped addresses) hangs the bus. This also has the tendancy of hanging the jtag debug port. --Sean
Re: imx8mn booting
Hi Sorry I have already solved ;) On Wed, May 12, 2021 at 6:07 PM Michael Nazzareno Trimarchi wrote: > > Hi all > > I have this sequence > > U-Boot SPL 2020.04-5.4.70-2.3.2+g8991308b4b (May 12 2021 - 12:44:10 +) > spl_init > power_bd71837_init > DDRINFO: start DRAM init > DDRINFO: DRAM rate 1600MTS > DDRINFO:ddrphy calibration done > DDRINFO: ddrmix config done > >>SPL: board_init_r() > Normal Boot > Trying to boot from BOOTROM > Find FIT header 0x&4403c1a0, size 1047 > Need continue download 1024 > fit read sector 4403c1a0, sectors=1048, dst=401ffb80, count=1048, size=0x418 > firmware: 'uboot@1' > External data: dst=4020, offset=3000, size=a1010 > fdt: 'fdt@1' > External data: dst=402a1040, offset=a4010, size=6b20 > loadables: 'atf@1' > External data: dst=96, offset=aab30, size=b1b0 > loadables: 'tee@1' > External data: dst=4800, offset=b5ce0, size=203e70 > no string for index 2 > Download 2856176, total fit 2857808 > fit read sector 4403c1a0, sectors=1048, dst=401ffb80, count=1048, size=0x418 > firmware: 'uboot@1' > External data: dst=4020, offset=3000, size=a1010 > fdt: 'fdt@1' > External data: dst=402a1040, offset=a4010, size=6b20 > loadables: 'atf@1' > External data: dst=96, offset=aab30, size=b1b0 > loadables: 'tee@1' > External data: dst=4800, offset=b5ce0, size=203e70 > no string for index 2 > Jumping to U-Boot > loaded - jumping to U-Boot... > image entry point: 0x96 > > I need to move some components to fit on 256Mb but I would like to > know if I can get to atf and atf is running or not. During this time I > need to use the same uart > of the spl but I don't find any debug printing in the code (imx-atf). > Can someone has some experience? > > Michael -- Michael Nazzareno Trimarchi Amarula Solutions Corporate CEO Co-Founder Cruquiuskade 47 Amsterdam 1018 AM NL T. +31(0)851119172 M. +39(0)3479132170 [`as] https://www.amarulasolutions.com
[PATCH 1/1] hash: revert Allow for SHA512 hardware implementations
We don't have a hardware implementation of SHA384 and SHA512 for any board.
We don't expect to ever have a hardware implementation for ALL boards that
have a hardware implementation for SHA1 and SHA512. So we cannot use
CONFIG_SHA_HW_ACCEL to switch SHA384 and SHA512 to the hardware functions.
As the commit a479f103dc1c ("hash: Allow for SHA512 hardware
implementations") leads to failure to compile peach-pi_defconfig board with
the EFI TCG2 protocol revert the patch.
Fixes: a479f103dc1c ("hash: Allow for SHA512 hardware implementations")
Signed-off-by: Heinrich Schuchardt
---
common/hash.c| 24 ++--
include/hw_sha.h | 26 --
lib/Kconfig | 15 ---
3 files changed, 10 insertions(+), 55 deletions(-)
diff --git a/common/hash.c b/common/hash.c
index 10dff7ddb0..fc64002f73 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -97,7 +97,7 @@ static int hash_finish_sha256(struct hash_algo *algo, void
*ctx, void
}
#endif
-#if defined(CONFIG_SHA384) && !defined(CONFIG_SHA_PROG_HW_ACCEL)
+#if defined(CONFIG_SHA384)
static int hash_init_sha384(struct hash_algo *algo, void **ctxp)
{
sha512_context *ctx = malloc(sizeof(sha512_context));
@@ -125,7 +125,7 @@ static int hash_finish_sha384(struct hash_algo *algo, void
*ctx, void
}
#endif
-#if defined(CONFIG_SHA512) && !defined(CONFIG_SHA_PROG_HW_ACCEL)
+#if defined(CONFIG_SHA512)
static int hash_init_sha512(struct hash_algo *algo, void **ctxp)
{
sha512_context *ctx = malloc(sizeof(sha512_context));
@@ -260,20 +260,10 @@ static struct hash_algo hash_algo[] = {
.name = "sha384",
.digest_size= SHA384_SUM_LEN,
.chunk_size = CHUNKSZ_SHA384,
-#ifdef CONFIG_SHA_HW_ACCEL
- .hash_func_ws = hw_sha384,
-#else
.hash_func_ws = sha384_csum_wd,
-#endif
-#ifdef CONFIG_SHA_PROG_HW_ACCEL
- .hash_init = hw_sha_init,
- .hash_update= hw_sha_update,
- .hash_finish= hw_sha_finish,
-#else
.hash_init = hash_init_sha384,
.hash_update= hash_update_sha384,
.hash_finish= hash_finish_sha384,
-#endif
},
#endif
#ifdef CONFIG_SHA512
@@ -281,20 +271,10 @@ static struct hash_algo hash_algo[] = {
.name = "sha512",
.digest_size= SHA512_SUM_LEN,
.chunk_size = CHUNKSZ_SHA512,
-#ifdef CONFIG_SHA_HW_ACCEL
- .hash_func_ws = hw_sha512,
-#else
.hash_func_ws = sha512_csum_wd,
-#endif
-#ifdef CONFIG_SHA_PROG_HW_ACCEL
- .hash_init = hw_sha_init,
- .hash_update= hw_sha_update,
- .hash_finish= hw_sha_finish,
-#else
.hash_init = hash_init_sha512,
.hash_update= hash_update_sha512,
.hash_finish= hash_finish_sha512,
-#endif
},
#endif
{
diff --git a/include/hw_sha.h b/include/hw_sha.h
index d4f3471c43..15b1a1c798 100644
--- a/include/hw_sha.h
+++ b/include/hw_sha.h
@@ -8,32 +8,6 @@
#define __HW_SHA_H
#include
-/**
- * Computes hash value of input pbuf using h/w acceleration
- *
- * @param in_addr A pointer to the input buffer
- * @param bufleni Byte length of input buffer
- * @param out_addr A pointer to the output buffer. When complete
- * 64 bytes are copied to pout[0]...pout[63]. Thus, a user
- * should allocate at least 64 bytes at pOut in advance.
- * @param chunk_size chunk size for sha512
- */
-void hw_sha512(const uchar *in_addr, uint buflen, uchar *out_addr,
- uint chunk_size);
-
-/**
- * Computes hash value of input pbuf using h/w acceleration
- *
- * @param in_addr A pointer to the input buffer
- * @param bufleni Byte length of input buffer
- * @param out_addr A pointer to the output buffer. When complete
- * 48 bytes are copied to pout[0]...pout[47]. Thus, a user
- * should allocate at least 48 bytes at pOut in advance.
- * @param chunk_size chunk size for sha384
- */
-void hw_sha384(const uchar *in_addr, uint buflen, uchar *out_addr,
- uint chunk_size);
-
/**
* Computes hash value of input pbuf using h/w acceleration
*
diff --git a/lib/Kconfig b/lib/Kconfig
index 6d2d41de30..9ef92a57d6 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -391,18 +391,19 @@ config SHA384
config SHA_HW_ACCEL
bool "Enable hashing using hardware"
help
- This option enables hardware acceleration for SHA hashing.
- This affects the 'hash' command and also the hash_lookup_algo()
- function.
+ This option enables hardware acceleration
+ for SHA1/SHA256 hashing.
+ This affects the 'hash' command and also the
+ hash_lookup_algo() function.
config SHA_PROG_HW_ACCEL
bool "Enable
Re: [PATCH 1/1] efi_loader: build warning in efi_tcg2_hash_log_extend_event
Reviewed-by: Ilias Apalodimas On Wed, 12 May 2021 at 18:40, Heinrich Schuchardt wrote: > > Building 32bit boards with the TCG2 protocol enabled leads to a build > warning due to a missing conversion. > > lib/efi_loader/efi_tcg2.c:774:27: > error: cast to pointer from integer of different size > [-Werror=int-to-pointer-cast] > 774 | ret = tcg2_create_digest((u8 *)data_to_hash, data_to_hash_len, > | ^ > > Signed-off-by: Heinrich Schuchardt > --- > lib/efi_loader/efi_tcg2.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c > index 7b5a443fb6..39ef250bf9 100644 > --- a/lib/efi_loader/efi_tcg2.c > +++ b/lib/efi_loader/efi_tcg2.c > @@ -771,8 +771,8 @@ efi_tcg2_hash_log_extend_event(struct efi_tcg2_protocol > *this, u64 flags, > pcr_index = efi_tcg_event->header.pcr_index; > event_type = efi_tcg_event->header.event_type; > > - ret = tcg2_create_digest((u8 *)data_to_hash, data_to_hash_len, > -_list); > + ret = tcg2_create_digest((u8 *)(uintptr_t)data_to_hash, > +data_to_hash_len, _list); > if (ret != EFI_SUCCESS) > goto out; > > -- > 2.31.1 >
[PATCH 1/1] sandbox: fix sandbox_reset()
state_uninit() and dm_uninit() are mutually exclusive: state_uninit() prints via drivers. So it cannot be executed after dm_uninit(). dm_uninit() requires memory. So it cannot be executed after state_uninit() which releases all memory. Just skip dm_uninit() when resetting the sandbox. We will wake up in a new process and allocate new memory. So this cleanup is not required. We don't do it in sandbox_exit() either. This avoids a segmentation error when efi_reset_system_boottime() is invoked by a UEFI application. Signed-off-by: Heinrich Schuchardt --- arch/sandbox/cpu/start.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c index e87365e800..4ffd97ccbc 100644 --- a/arch/sandbox/cpu/start.c +++ b/arch/sandbox/cpu/start.c @@ -425,9 +425,6 @@ void sandbox_reset(void) if (state_uninit()) os_exit(2); - if (dm_uninit()) - os_exit(2); - /* Restart U-Boot */ os_relaunch(os_argv); } -- 2.30.2
Re: [PATCH V4 2/2] riscv: board: Support OpenPiton SoC
Hi Sean,
On 5/8/2021 11:14 PM, Sean Anderson wrote:
On 5/8/21 12:57 AM, Tianrui Wei wrote:
Hi Sean,
On 5/7/2021 9:03 PM, Sean Anderson wrote:
On 5/6/21 11:48 PM, Tianrui Wei wrote:
On 5/7/2021 11:41 AM, Sean Anderson wrote:
On 5/6/21 11:28 PM, Tianrui Wei wrote:
On 5/7/2021 11:15 AM, Sean Anderson wrote:
On 5/6/21 11:06 PM, Tianrui Wei wrote:
Hi Sean,
Many thanks again for reviewing our code! We really appreciate
it. Will fix the things you're suggesting ;p Though I have a
few questions in line in the comment. Also, checkpatch didn't
catch any of the identation issues. I was wondering if there
are some specific flags to enable some of the checks? I'm
running ./utils/checkpatch.pl this.patch right now.
On 5/7/2021 10:32 AM, Sean Anderson wrote:
On 5/5/21 11:42 PM, Tianrui Wei wrote:
From: Tianrui Wei
Date: Thu, 6 May 2021 11:30:20 +0800
Subject: [PATCH V4 2/2] riscv: board: Support OpenPiton SoC
This patch add board support for OpenPiton.
Please add some information to the commit message describing
the board.
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
---
arch/riscv/Kconfig | 4 +
arch/riscv/dts/Makefile | 1 +
arch/riscv/dts/openpiton-riscv64.dts | 159 +
board/openpiton/riscv/Kconfig | 42 ++
board/openpiton/riscv/MAINTAINERS | 6 +
board/openpiton/riscv/Makefile | 5 +
board/openpiton/riscv/openpiton-riscv.c | 41 ++
configs/openpiton_riscv64_defconfig | 132
doc/board/index.rst | 1 +
doc/board/openpiton/index.rst | 9 +
doc/board/openpiton/riscv64.rst | 885
include/configs/openpiton-riscv.h | 58 ++
12 files changed, 1343 insertions(+)
create mode 100644 arch/riscv/dts/openpiton-riscv64.dts
create mode 100644 board/openpiton/riscv/Kconfig
create mode 100644 board/openpiton/riscv/MAINTAINERS
create mode 100644 board/openpiton/riscv/Makefile
create mode 100644 board/openpiton/riscv/openpiton-riscv.c
create mode 100644 configs/openpiton_riscv64_defconfig
create mode 100644 doc/board/openpiton/index.rst
create mode 100644 doc/board/openpiton/riscv64.rst
create mode 100644 include/configs/openpiton-riscv.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 30b05408..9e7deb34 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -23,6 +23,9 @@ config TARGET_SIFIVE_FU540
config TARGET_SIPEED_MAIX
bool "Support Sipeed Maix Board"
+config TARGET_OPENPITON_RISCV
+ bool "Support riscv cores on openpiton SoC"
+
endchoice
config SYS_ICACHE_OFF
@@ -55,6 +58,7 @@ config SPL_SYS_DCACHE_OFF
source "board/AndesTech/ax25-ae350/Kconfig"
source "board/emulation/qemu-riscv/Kconfig"
source "board/microchip/mpfs_icicle/Kconfig"
+source "board/openpiton/riscv/Kconfig"
Fix indentation.
It shows correct formatting in my client, and there's no
warning in checkpatch for some reason
Ignore this, sorry.
source "board/sifive/fu540/Kconfig"
source "board/sipeed/maix/Kconfig"
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 3a6f96c6..b511cd74 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
+dtb-$(CONFIG_TARGET_OPENPITON_RISCV) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
diff --git a/arch/riscv/dts/openpiton-riscv64.dts
b/arch/riscv/dts/openpiton-riscv64.dts
new file mode 100644
index ..ce732b92
--- /dev/null
+++ b/arch/riscv/dts/openpiton-riscv64.dts
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2021 Tianrui Wei */
+
+/*
+ * This dts is for a dual core instance of OpenPiton+Ariane
built
+ * to run on a Digilent Genesys 2 FPGA at 66.67MHz. These files
+ * are automatically generated by the OpenPiton build system
and
+ * this configuration may not be what you need if your
configuration
+ * is different from the below.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ u-boot,dm-pre-reloc;
+ compatible = "openpiton,ariane";
+
+ chosen {
+ stdout-path = "uart0:115200";
+ };
+
+ aliases {
+ console =
+ serial0 =
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ u-boot,dm-pre-reloc;
This is unnecessary since riscv_cpu has DM_FLAG_PRE_RELOC.
+ timebase-frequency = <520835>;
+
+ CPU0: cpu@0 {
+ clock-frequency = <7000>;
Please add a clocks node. If you just have one clock for the
whole soc,
you can always use a fixed-clock binding.
+ u-boot,dm-pre-reloc;
+ device_type = "cpu";
+ reg = <0>;
+ status = "okay";
+ compatible = "eth, ariane", "riscv";
There
Re: [PATCH 3/3] hash: Allow for SHA512 hardware implementations
On 12.05.21 18:05, Simon Glass wrote: > Hi Heinrich, > > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt wrote: >> >> On 17.02.21 04:20, Joel Stanley wrote: >>> Similar to support for SHA1 and SHA256, allow the use of hardware hashing >>> engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL / >>> CONFIG_SHA_PROG_HW_ACCEL. >>> >>> Signed-off-by: Joel Stanley >> >> This merged patch leads to errors compiling the EFI TCG2 protocol on >> boards with CONFIG_SHA_HW_ACCEL. >> >> There is not as single implementation of hw_sha384 and hw_sha512. You >> could only use CONFIG_SHA_HW_ACCEL for selecting these functions if >> these were implemented for *all* boards with CONFIG_SHA_HW_ACCEL=y. But >> this will never happen. >> >> *This patch needs to be reverted.* >> >> Why do we have CONFIG_SHA_HW_ACCEL at all and don't use weak functions >> instead? > > This is all a mess. We should not use weak functions IMO, but instead > have a driver interface, like we do with filesystems. > > Part of the challenge is the need to keep code size small for > platforms that only need one algorithm. If a function is not referenced, the linker will eliminate it. But with a driver interface every function in the interface is referenced. Best regards Heinrich
Re: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build
On 5/12/21 10:52 AM, Simon Glass wrote: Hi, On Tue, 11 May 2021 at 19:10, Tom Rini wrote: On Tue, May 11, 2021 at 07:50:38PM -0500, Alex G. wrote: On 5/11/21 5:34 PM, Tom Rini wrote: On Tue, May 11, 2021 at 02:57:03PM -0500, Alex G. wrote: On 5/6/21 9:24 AM, Simon Glass wrote: In preparation for enabling CONFIG_IS_ENABLED() on the host build, add some options to enable the various FIT options expected in these tools. This will ensure that the code builds correctly when CONFIG_HOST_xxx is distinct from CONFIG_xxx. Signed-off-by: Simon Glass Reviewed-by: Alexandru Gagniuc This makes me wonder whether we should just always enable host features. Right now, each defconfig can have a different mkimage config. So we should really have mkimage-imx8, mkimage-stm32mp, etc, which support different feature sets. This doesn't make much sense. The alternative is to get rid of all these configs and always enable mkimage features. The disadvantage is that we'd require openssl for building target code. A second alternative is to have a mkimage-nossl that gets built and used when openssl isn't available. It's really just openssl that causes such a schism. It would probably be best to have a single mkimage for everyone, with everything on. But before then we really need to move from openssl to gnutls or some other library that's compatible as it's been raised before that linking with openssl like we do is a license violation I believe. How about the former alternative for now? i.e. compile mkimage with or without openssl, and have that be the only host side switch. That would be a step in the right direction, yeah. We have a NO_SDL build-time control. Perhaps have a NO_SSL one as well? It could be a config option instead of an environment variable. I think it can be independent of target options, since we don't sign images in the buildsystem anyway -- we can enable FIT verification, but mkimage without openssl. Alex
Re: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build
On 5/12/21 10:54 AM, Simon Glass wrote: Hi Alex, On Wed, 12 May 2021 at 09:48, Alex G. wrote: On 5/12/21 9:51 AM, Simon Glass wrote: Hi Alex, On Tue, 11 May 2021 at 13:57, Alex G. wrote: On 5/6/21 9:24 AM, Simon Glass wrote: [snip] + +config HOST_FIT_PRINT + def_bool y + help + Print the content of the FIT verbosely in the host build This option also doesn't make sense.This seems to do what 'mkimage -l' already supports. Are you sure you have looked at the goal of the CONFIG_IS_ENABLED() changes? This is here purely to avoid #ifdefs in the share code. On the one hand, we have the cosmetic inconvenience caused by #ifdefs. On the other hand we have the config system. To most users, the config system is likely more visible, while it's mostly developers who will ever see the ifdefs. Therefore, in order to get the developer convenience of less ifdefs, we have to sacrifice user convenience by cloberring the Kconfig options. I think this is back-to-front. These Kconfig options are not visible to users. They cannot be updated in defconfig, nor in 'make menuconfig', etc. They are purely there for the build system. Can we reduce the host config count to just SLL/NOSSL? The point here is that the code has a special case for host builds, and this is a means to remove that special case and make the code easier to maintain and follow. I understand where you're coming from. Without these changes, the code knows what it should and should not do, correct? My argument is that if the code has the logic to do the correct thing, that logic should not be split with the config system. I agree with the goal of reducing clutter in the source code. I disagree with this specific course of fixing it. Instead, I propose a single kconfig for host tools for SSL on/off. The disadvantage of my proposal is that we have to refactor the common code in a way consistent with the goals, instead of just changing some #ifdefs to if(CONFIG_IS_ENABLED()). I admit that, off the top of my head, I don't have a detailed plan on how to achieve this. Alex
Re: [PATCH v2 3/7] common: integrate crypt-based passwords
Hi Steffen,
On Tue, 11 May 2021 at 12:30, Steffen Jaeckel
wrote:
>
> Hi Simon,
>
> On 5/11/21 5:27 PM, Simon Glass wrote:
> >>
> >> [snip]
> >>
> diff --git a/common/autoboot.c b/common/autoboot.c
> index 50ab9281e7..6f55abe388 100644
> --- a/common/autoboot.c
> +++ b/common/autoboot.c
> @@ -316,3 +316,4 @@ static int abortboot_key_sequence(int bootdelay)
> if (IS_ENABLED(CONFIG_AUTOBOOT_ENCRYPTION)) {
> - if (IS_ENABLED(CONFIG_CRYPT_PW))
> + if (IS_ENABLED(CONFIG_CRYPT_PW) &&
> + env_get_yesno("bootstopusesha256") != 1)
> abort = passwd_abort_crypt(etime);
> >>>
> >>> Yes, and then you can enable both in sandbox and potentially have a
> >>> test for your code within the standard sandbox build.
> >>
> >> What kind of tests do you want to have added? Python based or C based ones?
> >>
> >> TBH I don't see an easy way (yet) to add more tests than the ones I
> >> already added, as enabling AUTOBOOT_KEYED (which is required for both,
> >> crypt and sha256) would change the startup behavior of the sandbox...
> >
> > Here is my idea...we have console monitoring, like this:
> >
> > console_record_reset();
> > run_command("acpi dump rdst", 0);
> > ut_assert_nextline("Table 'RDST' not found");
> > ut_assert_console_end();
> >
> > What is needed is the ability to inject console input. We have
> > gd->console_in (in console.c) but there is currently no function to
> > add input to it. Something similar to console_record_puts() is needed,
> > perhaps called console_write_in(), which does a
> > membuff_put(>console_in, ...) with some input data (the hash).
> > That way the input can be read by sandbox.
> >
> > Then I think you could write a test like this:
> >
> > console_record_reset();
> > console_write_in(hash_string, strlen(hash_string));
> > ut_assertok(autoboot_command(""));
> > ut_assert_nextline("whatever indicates success");
> > ut_assert_console_end();
>
> OK, that sounds fine, with the only problem that there's no way to
> enable the necessary features without also having them enabled in the
> autoboot flow!?
>
> i.e. instead of having a single keypress to enable the console of the
> sandbox, one would always have to enter the password, or am I missing
> something?
Yes I see. Perhaps have a function to indicate whether it should be
enabled at runtime? For sandbox it can return false?
You could add a sandbox command-line flag to make it skip this, I
suppose. An environment variable is another option.
We often have little tweaks with tests to get them to do what we want.
Regards,
Simon
imx8mn booting
Hi all I have this sequence U-Boot SPL 2020.04-5.4.70-2.3.2+g8991308b4b (May 12 2021 - 12:44:10 +) spl_init power_bd71837_init DDRINFO: start DRAM init DDRINFO: DRAM rate 1600MTS DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done >>SPL: board_init_r() Normal Boot Trying to boot from BOOTROM Find FIT header 0x&4403c1a0, size 1047 Need continue download 1024 fit read sector 4403c1a0, sectors=1048, dst=401ffb80, count=1048, size=0x418 firmware: 'uboot@1' External data: dst=4020, offset=3000, size=a1010 fdt: 'fdt@1' External data: dst=402a1040, offset=a4010, size=6b20 loadables: 'atf@1' External data: dst=96, offset=aab30, size=b1b0 loadables: 'tee@1' External data: dst=4800, offset=b5ce0, size=203e70 no string for index 2 Download 2856176, total fit 2857808 fit read sector 4403c1a0, sectors=1048, dst=401ffb80, count=1048, size=0x418 firmware: 'uboot@1' External data: dst=4020, offset=3000, size=a1010 fdt: 'fdt@1' External data: dst=402a1040, offset=a4010, size=6b20 loadables: 'atf@1' External data: dst=96, offset=aab30, size=b1b0 loadables: 'tee@1' External data: dst=4800, offset=b5ce0, size=203e70 no string for index 2 Jumping to U-Boot loaded - jumping to U-Boot... image entry point: 0x96 I need to move some components to fit on 256Mb but I would like to know if I can get to atf and atf is running or not. During this time I need to use the same uart of the spl but I don't find any debug printing in the code (imx-atf). Can someone has some experience? Michael
Re: [PATCH 3/3] hash: Allow for SHA512 hardware implementations
Hi Heinrich, On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt wrote: > > On 17.02.21 04:20, Joel Stanley wrote: > > Similar to support for SHA1 and SHA256, allow the use of hardware hashing > > engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL / > > CONFIG_SHA_PROG_HW_ACCEL. > > > > Signed-off-by: Joel Stanley > > This merged patch leads to errors compiling the EFI TCG2 protocol on > boards with CONFIG_SHA_HW_ACCEL. > > There is not as single implementation of hw_sha384 and hw_sha512. You > could only use CONFIG_SHA_HW_ACCEL for selecting these functions if > these were implemented for *all* boards with CONFIG_SHA_HW_ACCEL=y. But > this will never happen. > > *This patch needs to be reverted.* > > Why do we have CONFIG_SHA_HW_ACCEL at all and don't use weak functions > instead? This is all a mess. We should not use weak functions IMO, but instead have a driver interface, like we do with filesystems. Part of the challenge is the need to keep code size small for platforms that only need one algorithm. Regards, Simon
Re: [PATCH 3/3] hash: Allow for SHA512 hardware implementations
On 17.02.21 04:20, Joel Stanley wrote:
> Similar to support for SHA1 and SHA256, allow the use of hardware hashing
> engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL /
> CONFIG_SHA_PROG_HW_ACCEL.
>
> Signed-off-by: Joel Stanley
This merged patch leads to errors compiling the EFI TCG2 protocol on
boards with CONFIG_SHA_HW_ACCEL.
There is not as single implementation of hw_sha384 and hw_sha512. You
could only use CONFIG_SHA_HW_ACCEL for selecting these functions if
these were implemented for *all* boards with CONFIG_SHA_HW_ACCEL=y. But
this will never happen.
*This patch needs to be reverted.*
Why do we have CONFIG_SHA_HW_ACCEL at all and don't use weak functions
instead?
Best regards
Heinrich
> ---
> common/hash.c| 24 ++--
> include/hw_sha.h | 26 ++
> lib/Kconfig | 15 +++
> 3 files changed, 55 insertions(+), 10 deletions(-)
>
> diff --git a/common/hash.c b/common/hash.c
> index fc64002f736a..10dff7ddb0e7 100644
> --- a/common/hash.c
> +++ b/common/hash.c
> @@ -97,7 +97,7 @@ static int hash_finish_sha256(struct hash_algo *algo, void
> *ctx, void
> }
> #endif
>
> -#if defined(CONFIG_SHA384)
> +#if defined(CONFIG_SHA384) && !defined(CONFIG_SHA_PROG_HW_ACCEL)
> static int hash_init_sha384(struct hash_algo *algo, void **ctxp)
> {
> sha512_context *ctx = malloc(sizeof(sha512_context));
> @@ -125,7 +125,7 @@ static int hash_finish_sha384(struct hash_algo *algo,
> void *ctx, void
> }
> #endif
>
> -#if defined(CONFIG_SHA512)
> +#if defined(CONFIG_SHA512) && !defined(CONFIG_SHA_PROG_HW_ACCEL)
> static int hash_init_sha512(struct hash_algo *algo, void **ctxp)
> {
> sha512_context *ctx = malloc(sizeof(sha512_context));
> @@ -260,10 +260,20 @@ static struct hash_algo hash_algo[] = {
> .name = "sha384",
> .digest_size= SHA384_SUM_LEN,
> .chunk_size = CHUNKSZ_SHA384,
> +#ifdef CONFIG_SHA_HW_ACCEL
> + .hash_func_ws = hw_sha384,
> +#else
> .hash_func_ws = sha384_csum_wd,
> +#endif
> +#ifdef CONFIG_SHA_PROG_HW_ACCEL
> + .hash_init = hw_sha_init,
> + .hash_update= hw_sha_update,
> + .hash_finish= hw_sha_finish,
> +#else
> .hash_init = hash_init_sha384,
> .hash_update= hash_update_sha384,
> .hash_finish= hash_finish_sha384,
> +#endif
> },
> #endif
> #ifdef CONFIG_SHA512
> @@ -271,10 +281,20 @@ static struct hash_algo hash_algo[] = {
> .name = "sha512",
> .digest_size= SHA512_SUM_LEN,
> .chunk_size = CHUNKSZ_SHA512,
> +#ifdef CONFIG_SHA_HW_ACCEL
> + .hash_func_ws = hw_sha512,
> +#else
> .hash_func_ws = sha512_csum_wd,
> +#endif
> +#ifdef CONFIG_SHA_PROG_HW_ACCEL
> + .hash_init = hw_sha_init,
> + .hash_update= hw_sha_update,
> + .hash_finish= hw_sha_finish,
> +#else
> .hash_init = hash_init_sha512,
> .hash_update= hash_update_sha512,
> .hash_finish= hash_finish_sha512,
> +#endif
> },
> #endif
> {
> diff --git a/include/hw_sha.h b/include/hw_sha.h
> index 15b1a1c79836..d4f3471c4308 100644
> --- a/include/hw_sha.h
> +++ b/include/hw_sha.h
> @@ -8,6 +8,32 @@
> #define __HW_SHA_H
> #include
>
> +/**
> + * Computes hash value of input pbuf using h/w acceleration
> + *
> + * @param in_addrA pointer to the input buffer
> + * @param bufleniByte length of input buffer
> + * @param out_addr A pointer to the output buffer. When complete
> + * 64 bytes are copied to pout[0]...pout[63]. Thus, a user
> + * should allocate at least 64 bytes at pOut in advance.
> + * @param chunk_size chunk size for sha512
> + */
> +void hw_sha512(const uchar *in_addr, uint buflen, uchar *out_addr,
> +uint chunk_size);
> +
> +/**
> + * Computes hash value of input pbuf using h/w acceleration
> + *
> + * @param in_addrA pointer to the input buffer
> + * @param bufleniByte length of input buffer
> + * @param out_addr A pointer to the output buffer. When complete
> + * 48 bytes are copied to pout[0]...pout[47]. Thus, a user
> + * should allocate at least 48 bytes at pOut in advance.
> + * @param chunk_size chunk size for sha384
> + */
> +void hw_sha384(const uchar *in_addr, uint buflen, uchar *out_addr,
> +uint chunk_size);
> +
> /**
> * Computes hash value of input pbuf using h/w acceleration
> *
> diff --git a/lib/Kconfig b/lib/Kconfig
> index b35a71ac368b..0d753eedeced 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -389,19 +389,18 @@ config SHA384
> config SHA_HW_ACCEL
> bool "Enable hashing using hardware"
> help
> - This option enables hardware acceleration
> - for SHA1/SHA256 hashing.
> -
Re: [PATCH 1/1] sandbox: ensure that state->ram_buf is in low memory
Hi Heinrich, On Tue, 11 May 2021 at 13:03, Heinrich Schuchardt wrote: > > Addresses in state->ram_buf must be in the low 4 GiB of the address space. > Otherwise we cannot correctly fill SMBIOS tables. This shows up in warnings > like: > > WARNING: SMBIOS table_address overflow 7f752735e020 This sounds like a bug in the smbios-table code. For sandbox it should perhaps use addresses instead of pointers. I think that code (that I unfortunately wrote) was an expeditious way of getting it running, but is not correct. > > Ensure that state->ram_buf is initialized by the first invocation of > os_malloc(). > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/start.c | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > Regards, Simon
Re: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build
Hi Alex, On Wed, 12 May 2021 at 09:48, Alex G. wrote: > > > > On 5/12/21 9:51 AM, Simon Glass wrote: > > Hi Alex, > > > > On Tue, 11 May 2021 at 13:57, Alex G. wrote: > >> > >> On 5/6/21 9:24 AM, Simon Glass wrote: > > [snip] > > >> > >>> + > >>> +config HOST_FIT_PRINT > >>> + def_bool y > >>> + help > >>> + Print the content of the FIT verbosely in the host build > >> > >> This option also doesn't make sense.This seems to do what 'mkimage -l' > >> already supports. > > > > Are you sure you have looked at the goal of the CONFIG_IS_ENABLED() > > changes? This is here purely to avoid #ifdefs in the share code. > > On the one hand, we have the cosmetic inconvenience caused by #ifdefs. > On the other hand we have the config system. To most users, the config > system is likely more visible, while it's mostly developers who will > ever see the ifdefs. > > Therefore, in order to get the developer convenience of less ifdefs, we > have to sacrifice user convenience by cloberring the Kconfig options. I > think this is back-to-front. These Kconfig options are not visible to users. They cannot be updated in defconfig, nor in 'make menuconfig', etc. They are purely there for the build system. > > Can we reduce the host config count to just SLL/NOSSL? The point here is that the code has a special case for host builds, and this is a means to remove that special case and make the code easier to maintain and follow. Regards, Simon
Re: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build
Hi, On Tue, 11 May 2021 at 19:10, Tom Rini wrote: > > On Tue, May 11, 2021 at 07:50:38PM -0500, Alex G. wrote: > > On 5/11/21 5:34 PM, Tom Rini wrote: > > > On Tue, May 11, 2021 at 02:57:03PM -0500, Alex G. wrote: > > > > On 5/6/21 9:24 AM, Simon Glass wrote: > > > > > In preparation for enabling CONFIG_IS_ENABLED() on the host build, add > > > > > some options to enable the various FIT options expected in these > > > > > tools. > > > > > This will ensure that the code builds correctly when CONFIG_HOST_xxx > > > > > is distinct from CONFIG_xxx. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > Reviewed-by: Alexandru Gagniuc > > > > > > > > This makes me wonder whether we should just always enable host features. > > > > Right now, each defconfig can have a different mkimage config. So we > > > > should > > > > really have mkimage-imx8, mkimage-stm32mp, etc, which support different > > > > feature sets. This doesn't make much sense. > > > > > > > > The alternative is to get rid of all these configs and always enable > > > > mkimage > > > > features. The disadvantage is that we'd require openssl for building > > > > target > > > > code. > > > > > > > > A second alternative is to have a mkimage-nossl that gets built and used > > > > when openssl isn't available. It's really just openssl that causes such > > > > a > > > > schism. > > > > > > It would probably be best to have a single mkimage for everyone, with > > > everything on. But before then we really need to move from openssl to > > > gnutls or some other library that's compatible as it's been raised > > > before that linking with openssl like we do is a license violation I > > > believe. > > > > How about the former alternative for now? i.e. compile mkimage with or > > without openssl, and have that be the only host side switch. > > That would be a step in the right direction, yeah. We have a NO_SDL build-time control. Perhaps have a NO_SSL one as well? Regards, Simon
Re: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build
On 5/12/21 9:51 AM, Simon Glass wrote: Hi Alex, On Tue, 11 May 2021 at 13:57, Alex G. wrote: On 5/6/21 9:24 AM, Simon Glass wrote: [snip] + +config HOST_FIT_PRINT + def_bool y + help + Print the content of the FIT verbosely in the host build This option also doesn't make sense.This seems to do what 'mkimage -l' already supports. Are you sure you have looked at the goal of the CONFIG_IS_ENABLED() changes? This is here purely to avoid #ifdefs in the share code. On the one hand, we have the cosmetic inconvenience caused by #ifdefs. On the other hand we have the config system. To most users, the config system is likely more visible, while it's mostly developers who will ever see the ifdefs. Therefore, in order to get the developer convenience of less ifdefs, we have to sacrifice user convenience by cloberring the Kconfig options. I think this is back-to-front. Can we reduce the host config count to just SLL/NOSSL? Alex
[PATCH 1/1] efi_loader: build warning in efi_tcg2_hash_log_extend_event
Building 32bit boards with the TCG2 protocol enabled leads to a build warning due to a missing conversion. lib/efi_loader/efi_tcg2.c:774:27: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 774 | ret = tcg2_create_digest((u8 *)data_to_hash, data_to_hash_len, | ^ Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_tcg2.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c index 7b5a443fb6..39ef250bf9 100644 --- a/lib/efi_loader/efi_tcg2.c +++ b/lib/efi_loader/efi_tcg2.c @@ -771,8 +771,8 @@ efi_tcg2_hash_log_extend_event(struct efi_tcg2_protocol *this, u64 flags, pcr_index = efi_tcg_event->header.pcr_index; event_type = efi_tcg_event->header.event_type; - ret = tcg2_create_digest((u8 *)data_to_hash, data_to_hash_len, -_list); + ret = tcg2_create_digest((u8 *)(uintptr_t)data_to_hash, +data_to_hash_len, _list); if (ret != EFI_SUCCESS) goto out; -- 2.31.1
[PATCH] arm/mach-imx: Fix macros in mmdc_size.c
Make macros actually use passed parameter instead of local variables
that happen
to be named the same as symbols in macro expansion.
Signed-off-by: Kacper Kubkowski
---
arch/arm/mach-imx/mmdc_size.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-imx/mmdc_size.c b/arch/arm/mach-
imx/mmdc_size.c
index 1a094726aa..224cca7678 100644
--- a/arch/arm/mach-imx/mmdc_size.c
+++ b/arch/arm/mach-imx/mmdc_size.c
@@ -24,11 +24,11 @@ struct esd_mmdc_regs {
u32 misc;
};
-#define ESD_MMDC_CTL_GET_ROW(mdctl)((ctl >> 24) & 7)
-#define ESD_MMDC_CTL_GET_COLUMN(mdctl) ((ctl >> 20) & 7)
-#define ESD_MMDC_CTL_GET_WIDTH(mdctl) ((ctl >> 16) & 3)
-#define ESD_MMDC_CTL_GET_CS1(mdctl)((ctl >> 30) & 1)
-#define ESD_MMDC_MISC_GET_BANK(mdmisc) ((misc >> 5) & 1)
+#define ESD_MMDC_CTL_GET_ROW(mdctl)((mdctl >> 24) & 7)
+#define ESD_MMDC_CTL_GET_COLUMN(mdctl) ((mdctl >> 20) & 7)
+#define ESD_MMDC_CTL_GET_WIDTH(mdctl) ((mdctl >> 16) & 3)
+#define ESD_MMDC_CTL_GET_CS1(mdctl)((mdctl >> 30) & 1)
+#define ESD_MMDC_MISC_GET_BANK(mdmisc) ((mdmisc >> 5) & 1)
/*
* imx_ddr_size - return size in bytes of DRAM according MMDC config
--
2.25.1
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
Hi Green, On Wed, May 12, 2021 at 11:13 PM Green Wan wrote: > > Yes, noted. This patch should be applied based on the fu740 port. Thanks for > the reminder. > Just to clarify, the reverted patch *content* should be in your fu740 support series. @Rick, this revert patch itself should be applied in u-boot/master now, as the mainline U-Boot does not boot on the Unleashed board. Regards, Bin
[PATCH] riscv: ax25-ae350: doc: Fix minor format issues
This fixes two minor format issues of the ax25-ae350 reST file. Signed-off-by: Bin Meng --- doc/board/AndesTech/ax25-ae350.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/board/AndesTech/ax25-ae350.rst b/doc/board/AndesTech/ax25-ae350.rst index f795476d85..923649240e 100644 --- a/doc/board/AndesTech/ax25-ae350.rst +++ b/doc/board/AndesTech/ax25-ae350.rst @@ -343,7 +343,7 @@ cloned and build for AE350 as below: cd opensbi make PLATFORM=andes/ae350 -Copy OpenSBI FW_DYNAMIC image (build\platform\andes\ae350\firmware\fw_dynamic.bin) +Copy OpenSBI FW_DYNAMIC image (build/platform/andes/ae350/firmware/fw_dynamic.bin) into U-Boot root directory @@ -532,4 +532,4 @@ Messages of U-Boot SPL boots Kernel on AE350 board Sat Apr 6 23:33:53 CST 2019 nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering... -~ # +~ # -- 2.25.1
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
Yes, noted. This patch should be applied based on the fu740 port. Thanks for the reminder. - Green On Wed, May 12, 2021 at 9:01 PM Bin Meng wrote: > Hi Green, > > On Mon, May 10, 2021 at 5:08 PM Bin Meng wrote: > > > > This reverts commit bc8bbb77f74f21582b3bfd790334397757f88575. > > > > This commit breaks U-Boot booting on SiFive Unleashed board, as > > there is no such CSR on U54 core. > > > > Signed-off-by: Bin Meng > > --- > > > > arch/riscv/cpu/fu540/spl.c | 15 --- > > 1 file changed, 15 deletions(-) > > > > Please note you need to add the changes in the arch/riscv/cpu/fu740 > directory. > > Regards, > Bin >
[PATCH] tee: optee: sync cache on pre-reloc OP-TEE invocation
This change ensures both U-Boot and OP-TEE see the same content
from shared memory when OP-TEE is invoked prior U-Boot relocation.
This change is required since U-Boot may execute with data cahce off
while OP-TEE always enables cache on memory shared with U-Boot.
Signed-off-by: Etienne Carriere
---
drivers/tee/optee/core.c | 20 +++-
drivers/tee/tee-uclass.c | 18 +-
include/tee.h| 6 ++
3 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 73dbb22ba0..120d315813 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -1,9 +1,10 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (c) 2018 Linaro Limited
+ * Copyright (c) 2018-2020 Linaro Limited
*/
#include
+#include
#include
#include
#include
@@ -295,6 +296,15 @@ static u32 call_err_to_res(u32 call_err)
}
}
+static void flush_shm_dcache(struct udevice *dev, struct optee_msg_arg *arg)
+{
+ flush_dcache_range(rounddown((ulong)arg, CONFIG_SYS_CACHELINE_SIZE),
+ roundup((ulong)arg + sizeof(*arg),
+ CONFIG_SYS_CACHELINE_SIZE));
+
+ tee_flush_all_shm_dcache(dev);
+}
+
static u32 do_call_with_arg(struct udevice *dev, struct optee_msg_arg *arg)
{
struct optee_pdata *pdata = dev_get_plat(dev);
@@ -305,9 +315,17 @@ static u32 do_call_with_arg(struct udevice *dev, struct
optee_msg_arg *arg)
while (true) {
struct arm_smccc_res res;
+ /* If cache are off from U-Boot, sync the cache shared with
OP-TEE */
+ if (!dcache_status())
+ flush_shm_dcache(dev, arg);
+
pdata->invoke_fn(param.a0, param.a1, param.a2, param.a3,
param.a4, param.a5, param.a6, param.a7, );
+ /* If cache are off from U-Boot, sync the cache shared with
OP-TEE */
+ if (!dcache_status())
+ flush_shm_dcache(dev, arg);
+
free(page_list);
page_list = NULL;
diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
index 2cc6b6c407..81fcd4e801 100644
--- a/drivers/tee/tee-uclass.c
+++ b/drivers/tee/tee-uclass.c
@@ -1,9 +1,10 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (c) 2018 Linaro Limited
+ * Copyright (c) 2018-2020 Linaro Limited
*/
#include
+#include
#include
#include
#include
@@ -233,3 +234,18 @@ void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
d[7] = s->time_hi_and_version;
memcpy(d + 8, s->clock_seq_and_node, sizeof(s->clock_seq_and_node));
}
+
+void tee_flush_all_shm_dcache(struct udevice *dev)
+{
+ struct tee_uclass_priv *priv = dev_get_uclass_priv(dev);
+ struct tee_shm *s;
+
+ list_for_each_entry(s, >list_shm, link) {
+ ulong start = rounddown((ulong)s->addr,
+ CONFIG_SYS_CACHELINE_SIZE);
+ ulong end = roundup((ulong)s->addr + s->size,
+ CONFIG_SYS_CACHELINE_SIZE);
+
+ flush_dcache_range(start, end);
+ }
+}
diff --git a/include/tee.h b/include/tee.h
index 99367b258e..2ef29bfc8f 100644
--- a/include/tee.h
+++ b/include/tee.h
@@ -377,4 +377,10 @@ void tee_optee_ta_uuid_from_octets(struct
tee_optee_ta_uuid *d,
void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
const struct tee_optee_ta_uuid *s);
+/**
+ * tee_flush_all_shm_dcache() - Flush data cache for all shared memories
+ * @dev: The TEE device
+ */
+void tee_flush_all_shm_dcache(struct udevice *dev);
+
#endif /* __TEE_H */
--
2.17.1
[PATCH 2/2] tee: optee: support session login as REE kernel
OP-TEE supports an API extension to allow client to open a TEE session
as REE kernel which OP-TEE uses to differentiate client application
services from system services that only the REE OS kernel can access.
This change allows U-Boot to invoke OP-TEE which such kernel identity
and therefore access kernel client specific services.
Signed-off-by: Etienne Carriere
---
drivers/tee/optee/core.c | 24 +++-
drivers/tee/optee/optee_msg.h | 2 ++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 73dbb22ba0..526bf125a0 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -349,6 +349,28 @@ static int optee_close_session(struct udevice *dev, u32
session)
return 0;
}
+static uint32_t optee_login_id(enum tee_session_login login)
+{
+ /* Treat invalid IDs as public login */
+ switch (login) {
+ case TEE_SESSION_LOGIN_USER:
+ return OPTEE_MSG_LOGIN_USER;
+ case TEE_SESSION_LOGIN_GROUP:
+ return OPTEE_MSG_LOGIN_GROUP;
+ case TEE_SESSION_LOGIN_APPLICATION:
+ return OPTEE_MSG_LOGIN_APPLICATION;
+ case TEE_SESSION_LOGIN_APPLICATION_USER:
+ return OPTEE_MSG_LOGIN_APPLICATION;
+ case TEE_SESSION_LOGIN_APPLICATION_GROUP:
+ return OPTEE_MSG_LOGIN_APPLICATION;
+ case TEE_SESSION_LOGIN_REE_KERNEL:
+ return OPTEE_MSG_LOGIN_REE_KERNEL;
+ case TEE_SESSION_LOGIN_PUBLIC:
+ default:
+ return OPTEE_MSG_LOGIN_PUBLIC;
+ }
+}
+
static int optee_open_session(struct udevice *dev,
struct tee_open_session_arg *arg,
uint num_params, struct tee_param *params)
@@ -372,7 +394,7 @@ static int optee_open_session(struct udevice *dev,
OPTEE_MSG_ATTR_META;
memcpy(_arg->params[0].u.value, arg->uuid, sizeof(arg->uuid));
memcpy(_arg->params[1].u.value, arg->uuid, sizeof(arg->clnt_uuid));
- msg_arg->params[1].u.value.c = arg->clnt_login;
+ msg_arg->params[1].u.value.c = optee_login_id(arg->clnt_login);
rc = to_msg_param(msg_arg->params + 2, num_params, params);
if (rc)
diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
index 8d40ce60c2..17e8d28e52 100644
--- a/drivers/tee/optee/optee_msg.h
+++ b/drivers/tee/optee/optee_msg.h
@@ -95,6 +95,8 @@
#define OPTEE_MSG_LOGIN_APPLICATION0x0004
#define OPTEE_MSG_LOGIN_APPLICATION_USER 0x0005
#define OPTEE_MSG_LOGIN_APPLICATION_GROUP 0x0006
+/* OP-TEE extension: log as REE kernel */
+#define OPTEE_MSG_LOGIN_REE_KERNEL 0x8000
/*
* Page size used in non-contiguous buffer entries
--
2.17.1
[PATCH 1/2] tee: define session login identifiers
TEE header file defines a clnt_login field in struct tee_open_session_arg
but does not define the values expected. This change define identifiers
for the field using a enumerated type. Back end TEE driver is expected to
convert these IDs into IDs meaningful to the TEE.
Signed-off-by: Etienne Carriere
---
include/tee.h | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/include/tee.h b/include/tee.h
index 99367b258e..b8297601b4 100644
--- a/include/tee.h
+++ b/include/tee.h
@@ -31,6 +31,19 @@
#define TEE_PARAM_ATTR_MASK(TEE_PARAM_ATTR_TYPE_MASK | \
TEE_PARAM_ATTR_META)
+/*
+ * Value for tee_open_session_arg::clnt_login
+ */
+enum tee_session_login {
+ TEE_SESSION_LOGIN_PUBLIC = 0,
+ TEE_SESSION_LOGIN_USER,
+ TEE_SESSION_LOGIN_GROUP,
+ TEE_SESSION_LOGIN_APPLICATION,
+ TEE_SESSION_LOGIN_APPLICATION_USER,
+ TEE_SESSION_LOGIN_APPLICATION_GROUP,
+ TEE_SESSION_LOGIN_REE_KERNEL,
+};
+
/*
* Some Global Platform error codes which has a meaning if the
* TEE_GEN_CAP_GP bit is returned by the driver in
@@ -135,8 +148,8 @@ struct tee_param {
/**
* struct tee_open_session_arg - extra arguments for tee_open_session()
* @uuid: [in] UUID of the Trusted Application
- * @clnt_uuid: [in] Normally zeroes
- * @clnt_login:[in] Normally 0
+ * @clnt_uuid: [in] UUID of client, zeroes for PUBLIC/REE_KERNEL
+ * @clnt_login:[in] Class of client TEE_SESSION_LOGIN_*
* @session: [out] Session id
* @ret: [out] return value
* @ret_origin:[out] origin of the return value
@@ -144,7 +157,7 @@ struct tee_param {
struct tee_open_session_arg {
u8 uuid[TEE_UUID_LEN];
u8 clnt_uuid[TEE_UUID_LEN];
- u32 clnt_login;
+ enum tee_session_login clnt_login;
u32 session;
u32 ret;
u32 ret_origin;
--
2.17.1
[PATCH 2/2] firmware: scmi: fix sandbox and related test since clock discovery
Since SCMI clock are discovered because of integration in the CCF,
update SCMI emulation in sandbox accordingly. Sandbox must emulate all
clocks exposed by SCMI server since CCF clock discovery will query all
of them even if some clocks have no consumer. This change adds clock
discovery support in the sandbox and changes clock IDs so that less
clock shall be managed as each SCMI clock ID is actually an index
identifier.
For consistency, update also sandbox SCMI reset controller test to
conform with the IDs being also indices of exposed resources as per
SCMI specification.
Signed-off-by: Etienne Carriere
---
arch/sandbox/dts/test.dts | 4 +-
arch/sandbox/include/asm/scmi_test.h | 2 -
drivers/firmware/scmi/sandbox-scmi_agent.c | 102 ++---
test/dm/scmi.c | 29 --
4 files changed, 113 insertions(+), 24 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index fe26ced31d..91e488239b 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1346,8 +1346,8 @@
sandbox_scmi {
compatible = "sandbox,scmi-devices";
- clocks = <_scmi0 7>, <_scmi0 3>, <_scmi1 1>;
- resets = <_scmi0 3>;
+ clocks = <_scmi0 2>, <_scmi0 0>, <_scmi1 0>;
+ resets = <_scmi0 0>;
regul0-supply = <_scmi0>;
regul1-supply = <_scmi0>;
};
diff --git a/arch/sandbox/include/asm/scmi_test.h
b/arch/sandbox/include/asm/scmi_test.h
index 2930e686d7..bce18deeea 100644
--- a/arch/sandbox/include/asm/scmi_test.h
+++ b/arch/sandbox/include/asm/scmi_test.h
@@ -17,7 +17,6 @@ struct sandbox_scmi_service;
* @rate: Clock rate in Hertz
*/
struct sandbox_scmi_clk {
- uint id;
bool enabled;
ulong rate;
};
@@ -28,7 +27,6 @@ struct sandbox_scmi_clk {
* @asserted: Reset control state: true if asserted, false if desasserted
*/
struct sandbox_scmi_reset {
- uint id;
bool asserted;
};
diff --git a/drivers/firmware/scmi/sandbox-scmi_agent.c
b/drivers/firmware/scmi/sandbox-scmi_agent.c
index 4b968205c2..dee9e8fb58 100644
--- a/drivers/firmware/scmi/sandbox-scmi_agent.c
+++ b/drivers/firmware/scmi/sandbox-scmi_agent.c
@@ -27,7 +27,7 @@
* See IDs in scmi0_clk[]/scmi0_reset[] and "sandbox-scmi-agent@0" in test.dts.
*
* Agent #1 simulates 1 clock.
- * See IDs in scmi1_clk[] and "sandbox-scmi-agent@1" in test.dts.
+ * See scmi1_clk[] and "sandbox-scmi-agent@1" in test.dts.
*
* All clocks and regulators are default disabled and reset controller down.
*
@@ -40,12 +40,13 @@
#define SANDBOX_SCMI_AGENT_COUNT 2
static struct sandbox_scmi_clk scmi0_clk[] = {
- { .id = 7, .rate = 1000 },
- { .id = 3, .rate = 333 },
+ { .rate = 333 },
+ { .rate = 200 },
+ { .rate = 1000 },
};
static struct sandbox_scmi_reset scmi0_reset[] = {
- { .id = 3 },
+ { .asserted = false },
};
static struct sandbox_scmi_voltd scmi0_voltd[] = {
@@ -54,7 +55,7 @@ static struct sandbox_scmi_voltd scmi0_voltd[] = {
};
static struct sandbox_scmi_clk scmi1_clk[] = {
- { .id = 1, .rate = 44 },
+ { .rate = 44 },
};
/* The list saves to simulted end devices references for test purpose */
@@ -102,7 +103,6 @@ static struct sandbox_scmi_clk *get_scmi_clk_state(uint
agent_id, uint clock_id)
{
struct sandbox_scmi_clk *target = NULL;
size_t target_count = 0;
- size_t n;
switch (agent_id) {
case 0:
@@ -117,9 +117,8 @@ static struct sandbox_scmi_clk *get_scmi_clk_state(uint
agent_id, uint clock_id)
return NULL;
}
- for (n = 0; n < target_count; n++)
- if (target[n].id == clock_id)
- return target + n;
+ if (clock_id < target_count)
+ return target + clock_id;
return NULL;
}
@@ -127,14 +126,21 @@ static struct sandbox_scmi_clk *get_scmi_clk_state(uint
agent_id, uint clock_id)
static struct sandbox_scmi_reset *get_scmi_reset_state(uint agent_id,
uint reset_id)
{
- size_t n;
+ struct sandbox_scmi_reset *target = NULL;
+ size_t target_count = 0;
- if (agent_id == 0) {
- for (n = 0; n < ARRAY_SIZE(scmi0_reset); n++)
- if (scmi0_reset[n].id == reset_id)
- return scmi0_reset + n;
+ switch (agent_id) {
+ case 0:
+ target = scmi0_reset;
+ target_count = ARRAY_SIZE(scmi0_reset);
+ break;
+ default:
+ return NULL;
}
+ if (reset_id < target_count)
+ return target + reset_id;
+
return NULL;
}
@@ -156,6 +162,70 @@ static struct sandbox_scmi_voltd
*get_scmi_voltd_state(uint agent_id,
* Sandbox SCMI agent ops
*/
+static int
[PATCH 1/2] clk: scmi: register all scmi clock by name with CCF
From: Patrick Delaunay
This patch implements SCMI APIs to retrieve the number and the name of
SCMI clocks using SCMI_PROTOCOL_ATTRIBUTES messages.
Signed-off-by: Gabriel Fernandez
Signed-off-by: Patrick Delaunay
Signed-off-by: Etienne Carriere
---
drivers/clk/clk_scmi.c | 101 +++
include/scmi_protocols.h | 43 +
2 files changed, 144 insertions(+)
diff --git a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c
index 93a4819501..2a4c10a427 100644
--- a/drivers/clk/clk_scmi.c
+++ b/drivers/clk/clk_scmi.c
@@ -8,6 +8,50 @@
#include
#include
#include
+#include
+
+static u16 scmi_clk_get_num_clock(struct udevice *dev)
+{
+ struct scmi_clk_protocol_attr_out out;
+ struct scmi_msg msg = {
+ .protocol_id = SCMI_PROTOCOL_ID_CLOCK,
+ .message_id = SCMI_PROTOCOL_ATTRIBUTES,
+ .out_msg = (u8 *),
+ .out_msg_sz = sizeof(out),
+ };
+ int ret;
+
+ ret = devm_scmi_process_msg(dev->parent, );
+ if (ret)
+ return ret;
+
+ return out.attributes & SCMI_CLK_PROTO_ATTR_COUNT_MASK;
+}
+
+static int scmi_clk_get_attibute(struct udevice *dev, int clkid, char **name)
+{
+ struct scmi_clk_attribute_in in = {
+ .clock_id = clkid,
+ };
+ struct scmi_clk_attribute_out out;
+ struct scmi_msg msg = {
+ .protocol_id = SCMI_PROTOCOL_ID_CLOCK,
+ .message_id = SCMI_CLOCK_ATTRIBUTES,
+ .in_msg = (u8 *),
+ .in_msg_sz = sizeof(in),
+ .out_msg = (u8 *),
+ .out_msg_sz = sizeof(out),
+ };
+ int ret;
+
+ ret = devm_scmi_process_msg(dev->parent, );
+ if (ret)
+ return ret;
+
+ *name = out.clock_name;
+
+ return 0;
+}
static int scmi_clk_gate(struct clk *clk, int enable)
{
@@ -85,6 +129,62 @@ static ulong scmi_clk_set_rate(struct clk *clk, ulong rate)
return scmi_clk_get_rate(clk);
}
+static struct clk *scmi_clk_register(struct udevice *dev, const char *name)
+{
+ struct clk *clk;
+ int ret;
+
+ clk = kzalloc(sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return ERR_PTR(-ENOMEM);
+
+ ret = clk_register(clk, dev->driver->name, name, dev->name);
+ if (ret) {
+ kfree(clk);
+ return ERR_PTR(ret);
+ }
+
+ return clk;
+}
+
+static int scmi_clk_probe(struct udevice *dev)
+{
+ struct clk *clk;
+ int num_clocks;
+ int i;
+
+ if (!CONFIG_IS_ENABLED(CLK_CCF))
+ return 0;
+
+ /* register CCF children: CLK UCLASS, no probed again */
+ if (device_get_uclass_id(dev->parent) == UCLASS_CLK)
+ return 0;
+
+ num_clocks = scmi_clk_get_num_clock(dev);
+ if (!num_clocks)
+ return 0;
+
+ for (i = 0; i < num_clocks; i++) {
+ char *name;
+
+ if (!scmi_clk_get_attibute(dev, i, )) {
+ char *clock_name = strdup(name);
+
+ clk = scmi_clk_register(dev, clock_name);
+ if (!IS_ERR(clk)) {
+ clk->id = i;
+ clk_request(dev, clk);
+ } else {
+ free(clock_name);
+
+ return PTR_ERR(clk);
+ }
+ }
+ }
+
+ return 0;
+}
+
static const struct clk_ops scmi_clk_ops = {
.enable = scmi_clk_enable,
.disable = scmi_clk_disable,
@@ -96,4 +196,5 @@ U_BOOT_DRIVER(scmi_clock) = {
.name = "scmi_clk",
.id = UCLASS_CLK,
.ops = _clk_ops,
+ .probe = _clk_probe,
};
diff --git a/include/scmi_protocols.h b/include/scmi_protocols.h
index 2db71697e8..3fc8ec95ef 100644
--- a/include/scmi_protocols.h
+++ b/include/scmi_protocols.h
@@ -40,22 +40,65 @@ enum scmi_status_code {
SCMI_PROTOCOL_ERROR = -10,
};
+/*
+ * Generic message IDs
+ */
+enum scmi_discovery_id {
+ SCMI_PROTOCOL_VERSION = 0x0,
+ SCMI_PROTOCOL_ATTRIBUTES = 0x1,
+ SCMI_PROTOCOL_MESSAGE_ATTRIBUTES = 0x2,
+};
+
/*
* SCMI Clock Protocol
*/
enum scmi_clock_message_id {
+ SCMI_CLOCK_ATTRIBUTES = 0x3,
SCMI_CLOCK_RATE_SET = 0x5,
SCMI_CLOCK_RATE_GET = 0x6,
SCMI_CLOCK_CONFIG_SET = 0x7,
};
+#define SCMI_CLK_PROTO_ATTR_COUNT_MASK GENMASK(15, 0)
#define SCMI_CLK_RATE_ASYNC_NOTIFY BIT(0)
#define SCMI_CLK_RATE_ASYNC_NORESP (BIT(0) | BIT(1))
#define SCMI_CLK_RATE_ROUND_DOWN 0
#define SCMI_CLK_RATE_ROUND_UP BIT(2)
#define SCMI_CLK_RATE_ROUND_CLOSESTBIT(3)
+#define SCMI_CLOCK_NAME_LENGTH_MAX 16
+
+/**
+ * struct scmi_clk_get_nb_out - Response for SCMI_PROTOCOL_ATTRIBUTES command
+ * @status:SCMI command status
+ * @attributes:Attributes of the clock protocol, mainly number of
clocks exposed
+
Re: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build
Hi Alex,
On Tue, 11 May 2021 at 13:57, Alex G. wrote:
>
> On 5/6/21 9:24 AM, Simon Glass wrote:
> > In preparation for enabling CONFIG_IS_ENABLED() on the host build, add
> > some options to enable the various FIT options expected in these tools.
> > This will ensure that the code builds correctly when CONFIG_HOST_xxx
> > is distinct from CONFIG_xxx.
> >
> > Signed-off-by: Simon Glass
>
> Reviewed-by: Alexandru Gagniuc
>
> This makes me wonder whether we should just always enable host features.
> Right now, each defconfig can have a different mkimage config. So we
> should really have mkimage-imx8, mkimage-stm32mp, etc, which support
> different feature sets. This doesn't make much sense.
My intent is that we enable all features in host tools. For
distributions they build the tools-only config and make things work
that way. But perhaps we could avoid building the tools, or do it
separately, if there were no different between boards.
>
> The alternative is to get rid of all these configs and always enable
> mkimage features. The disadvantage is that we'd require openssl for
> building target code.
>
> A second alternative is to have a mkimage-nossl that gets built and used
> when openssl isn't available. It's really just openssl that causes such
> a schism.
Why is openssl such a problem?
>
> Alex
>
> > ---
> >
> > (no changes since v1)
> >
> > common/image-fit-sig.c | 3 ++-
> > common/image-fit.c | 4 ++--
> > tools/Kconfig | 25 +
> > tools/Makefile | 18 +-
> > 4 files changed, 38 insertions(+), 12 deletions(-)
> >
> > diff --git a/common/image-fit-sig.c b/common/image-fit-sig.c
> > index 55ddf1879ed..12a6745c642 100644
> > --- a/common/image-fit-sig.c
> > +++ b/common/image-fit-sig.c
> > @@ -72,11 +72,12 @@ static int fit_image_setup_verify(struct
> > image_sign_info *info,
> > char *algo_name;
> > const char *padding_name;
> >
> > +#ifndef USE_HOSTCC
> > if (fdt_totalsize(fit) > CONFIG_FIT_SIGNATURE_MAX_SIZE) {
> > *err_msgp = "Total size too large";
> > return 1;
> > }
> > -
> > +#endif
> > if (fit_image_hash_get_algo(fit, noffset, _name)) {
> > *err_msgp = "Can't get hash algo property";
> > return -1;
> > diff --git a/common/image-fit.c b/common/image-fit.c
> > index e614643fe39..a16e2dd54a5 100644
> > --- a/common/image-fit.c
> > +++ b/common/image-fit.c
> > @@ -165,7 +165,7 @@ int fit_get_subimage_count(const void *fit, int
> > images_noffset)
> > return count;
> > }
> >
> > -#if CONFIG_IS_ENABLED(FIT_PRINT) || CONFIG_IS_ENABLED(SPL_FIT_PRINT)
> > +#if CONFIG_IS_ENABLED(FIT_PRINT)
> > /**
> >* fit_image_print_data() - prints out the hash node details
> >* @fit: pointer to the FIT format image header
> > @@ -573,7 +573,7 @@ void fit_image_print(const void *fit, int
> > image_noffset, const char *p)
> > #else
> > void fit_print_contents(const void *fit) { }
> > void fit_image_print(const void *fit, int image_noffset, const char *p) {
> > }
> > -#endif /* CONFIG_IS_ENABLED(FIR_PRINT) || CONFIG_IS_ENABLED(SPL_FIT_PRINT)
> > */
> > +#endif /* CONFIG_IS_ENABLED(FIT_PRINT) */
> >
> > /**
> >* fit_get_desc - get node description property
> > diff --git a/tools/Kconfig b/tools/Kconfig
> > index b2f5012240c..f00ab661135 100644
> > --- a/tools/Kconfig
> > +++ b/tools/Kconfig
> > @@ -9,4 +9,29 @@ config MKIMAGE_DTC_PATH
> > some cases the system dtc may not support all required features
> > and the path to a different version should be given here.
> >
> > +config HOST_FIT
> > + def_bool y
> > + help
> > + Enable FIT support in the host build.
>
> Don't we always want to enable this for mkimage?
Yes, that's right.
>
> > +
> > +config HOST_FIT_FULL_CHECK
> > + def_bool y
> > + help
> > + Do a full check of the FIT before using it in the host build
>
> How would this be used? FIT vs FIT_FULL is mostly an SPL distinction. I
> don't think we should have it in host tools.
It allows us to use CONFIG_IS_ENABLED() everywhere, including in code
built as part of host tools. In fact that is the main purpose of this
series.
>
> > +
> > +config HOST_FIT_PRINT
> > + def_bool y
> > + help
> > + Print the content of the FIT verbosely in the host build
>
> This option also doesn't make sense.This seems to do what 'mkimage -l'
> already supports.
Are you sure you have looked at the goal of the CONFIG_IS_ENABLED()
changes? This is here purely to avoid #ifdefs in the share code.
>
> > +
> > +config HOST_FIT_SIGNATURE
> > + def_bool y
> > + help
> > + Enable signature verification of FIT uImages in the host build
>
> s/verification/signing and verification/
OK, yes it does control that in the tools, by virtue of tools/Makefile
>
> > +
> > +config HOST_FIT_SIGNATURE_MAX_SIZE
> > + hex
> > + depends on HOST_FIT_SIGNATURE
> > + default 0x1000
>
[PATCH] configs: am64x_evm_a53_defconfig: Enable DP83867 PHY driver
AM64x GP and SK EVM have DP83867 PHY connected to CPSW external port0. Enable the driver in order to use ethernet at U-Boot prompt. CONFIG_PHY_TI is selected by CONFIG_PHY_TI_DP83867 and thus can be dropped. Signed-off-by: Vignesh Raghavendra --- Based on top of https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.07-rc3 configs/am64x_evm_a53_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index 0e942e36b4..e1e1c375cf 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -76,6 +76,7 @@ CONFIG_SF_DEFAULT_MODE=0 CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHY_TI=y +CONFIG_PHY_TI_DP83867=y CONFIG_PHY_FIXED=y CONFIG_DM_ETH=y CONFIG_TI_AM65_CPSW_NUSS=y -- 2.31.1
[PATCH] usb: dwc3-generic: Disable host driver definition if gadget only
Even if only USB gadget is defined, dwc3 generic driver enables
a definition and probe/remove functions for host driver.
This enables the definition if USB_HOST is enabled only.
Signed-off-by: Kunihiko Hayashi
---
drivers/usb/dwc3/dwc3-generic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 30f835e..c8bf4ae 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -163,7 +163,8 @@ U_BOOT_DRIVER(dwc3_generic_peripheral) = {
};
#endif
-#if defined(CONFIG_SPL_USB_HOST_SUPPORT) || !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_SPL_USB_HOST_SUPPORT) || \
+ !defined(CONFIG_SPL_BUILD) && defined(CONFIG_USB_HOST)
static int dwc3_generic_host_probe(struct udevice *dev)
{
struct xhci_hcor *hcor;
--
2.7.4
[PATCH] env: Leave invalid env for nowhere location
When CONFIG_ENV_IS_NOWHERE is enabled, env_nowhere_init() sets ENV_INVALID
to gd->env_valid, and sets default_environment before relocation to
gd->env_addr. After that, env_init() switches gd->env_valid to ENV_VALID
by the previous fix.
If gd->env_valid is ENV_INVALID, env_get_char() returns relocated
default_environment, however, env_get_char() returns gd->env_addr before
relocation since gd->env_valid is ENV_VALID, and access to gd->env_addr
will cause a fault.
This leaves gd->env_valid as ENV_INVALID for "nowhere" location.
Cc: Marek Vasut
Fixes: 5557eec01cbf ("env: Fix invalid env handling in env_init()")
Signed-off-by: Kunihiko Hayashi
---
env/env.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/env/env.c b/env/env.c
index e534008..3233172 100644
--- a/env/env.c
+++ b/env/env.c
@@ -336,7 +336,8 @@ int env_init(void)
debug("%s: Environment %s init done (ret=%d)\n", __func__,
drv->name, ret);
- if (gd->env_valid == ENV_INVALID)
+ if (gd->env_valid == ENV_INVALID
+ && drv->location != ENVL_NOWHERE)
ret = -ENOENT;
}
--
2.7.4
Re: [PATCH v5 2/3] efi_loader: add PE/COFF image measurement
[...]
> +
> /**
> * efi_tcg2_hash_log_extend_event() - extend and optionally log events
> *
> @@ -758,24 +937,32 @@ efi_tcg2_hash_log_extend_event(struct efi_tcg2_protocol
> *this, u64 flags,
> /*
>* if PE_COFF_IMAGE is set we need to make sure the image is not
>* corrupted, verify it and hash the PE/COFF image in accordance with
> - * the procedure specified in "Calculating the PE Image Hash"
> - * section of the "Windows Authenticode Portable Executable Signature
> + * the procedure specified in "Calculating the PE Image Hash"
> + * section of the "Windows Authenticode Portable Executable Signature
>* Format"
> - * Not supported for now
>*/
> if (flags & PE_COFF_IMAGE) {
> - ret = EFI_UNSUPPORTED;
> - goto out;
> - }
> + IMAGE_NT_HEADERS32 *nt;
>
> - pcr_index = efi_tcg_event->header.pcr_index;
> - event_type = efi_tcg_event->header.event_type;
> + ret = efi_check_pe((void *)data_to_hash, data_to_hash_len,
> +(void **));
> + if (ret != EFI_SUCCESS) {
> + log_err("Not a valid PE-COFF file\n");
> + goto out;
> + }
>
> - ret = tcg2_create_digest((u8 *)data_to_hash, data_to_hash_len,
> - _list);
> + ret = tcg2_hash_pe_image((void *)data_to_hash, data_to_hash_len,
> + _list);
> + } else {
> + ret = tcg2_create_digest((u8 *)data_to_hash, data_to_hash_len,
I think this needs a (u8 *)(uintptr_t) which is carried on from the
original code. I don't mind merging this as-is and I send a follow up.
Heinrich any preference?
> + _list);
> + }
> if (ret != EFI_SUCCESS)
> goto out;
>
> + pcr_index = efi_tcg_event->header.pcr_index;
> + event_type = efi_tcg_event->header.event_type;
> +
> ret = tcg2_pcr_extend(dev, pcr_index, _list);
> if (ret != EFI_SUCCESS)
> goto out;
> --
> 2.17.1
>
Cheers
/Ilias
[GIT PULL] TI changes for v2021.07 rc3
Hi Tom, Please find the PR for master branch targeted for v2021.07-rc1 release. Details about the PR are updated in the tag message. There are addition of new platform in this PR. I understand it is not expected to send these this late in the release. However, these are posted sometime ago and I could not spend time on these patches due to personal reasons. Please consider this as an exception and accept this PR. I ll try not to repeat this in future PRs. Gitlab build report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7474 The following changes since commit b107761b817c421fb8eadee739656e1db38686c3: Prepare v2021.07-rc2 (2021-05-10 17:03:22 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.07-rc3 for you to fetch changes up to bbc9da58b332bd44e51ac5579040ea984b2f963b: ARM: dts: k3-am642-sk: Add ethernet related DT nodes (2021-05-12 16:36:39 +0530) - Initial support for AM64 EVM and SK - K3 DDR driver unification for J7 and AM64 platforms. - Minor fixes for TI clock driver Dario Binacchi (5): clk: ti: add custom API for memory access clk: ti: change clk_ti_latch() signature clk: ti: gate: use custom API for memory access clk: ti: am3-dpll: use custom API for memory access Revert "fdt: translate address if #size-cells = <0>" Dave Gerlach (30): arm: mach-k3: Add basic support for AM642 SoC definition arm: mach-k3: am642: Unlock all applicable control MMR registers arm: mach-k3: am642: Store boot info from ROM arm: mach-k3: am642: Load SYSFW binary and config from boot media arm: mach-k3: am642: Use mmc start and stop callbacks mmc: sdhci_am654: Add Support for TI's AM642 SoC mailbox: k3-sec-proxy: Extend valid thread IDs board: ti: am64x: Add board support for am64x evm dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64 arm: dts: ti: Add Support for AM642 SoC arm: dts: k3-am642: Add initial support for EVM arm: dts: k3-am642: Add r5 specific dt support configs: am64x_evm_r5: Add Initial support configs: am64x_evm_a53: Add Initial support dt-bindings: memory-controller: Add K3 AM64 DDRSS compatible ram: k3-j721e: lpddr4_address_slice_0_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_0_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_1_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_2_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_3_macros: Fix indentation issues ram: k3-j721e: lpddr4_ddr_controller_macros: Fix indentation issues ram: k3-j721e: lpddr4_phy_core_macros: Fix indentation issues ram: k3-j721e: lpddr4_pi_macros: Fix indentation issues ram: k3-j721e: lpddr4_ctl_regs: Fix checkpatch issue for types ram: k3-j721e: Rename to k3-ddrss ram: k3-ddrss: Introduce top-level CONFIG_K3_DDRSS ram: k3-ddrss: Introduce common driver with J7 SoC support ram: k3-ddrss: Introduce support for AM642 SoCs arm: dts: k3-am642: Add ddr node arm: mach-k3: am642: Add support for triggering ddr init from SPL Keerthy (2): arm: mach-k3: am642: Add support for boot device detection armv8: mach-k3: am642: Add custom MMU support Lokesh Vutla (19): ram: k3-ddrss: Enable vtt regulator if present soc: ti: k3-socinfo: Add entry for AM64X SoC family board: ti: am64x: Add support for reading eeprom data board: ti: am64x: Enable support for reading EEPROM in R5 SPL board: ti: am64x: Add support for detecting multiple device trees arm: am64x: Add support for selecting DT based on EEPROM include: configs: am64x: Avoid overlap of BSS and stack area include: configs: am64x_evm: Optimize size of SPL BSS include: configs: Update env for selecting right dtb arm: dts: k3-am64-evm: Make chip id available before pre-reloc arm: dts: k3-am642-r5-evm: Do not use power-domains for I2C arm: dts: am642-evm: Add I2C nodes arm: dts: am642-sk: Add initial sk dts arm: dts: am642-r5-sk: Add r5 specific dts configs: am64x_evm_r5: Enable checks for spl and stack sizes configs: am64x_evm_r5: Enable support for building multiple device trees configs: am64x_evm_a53: Enable configs for printing cpuinfo configs: am64x_evm_a53: Enable support for reading eeprom configs: am64x_evm_a53: Enable support for building multiple dtbs Nishanth Menon (3): arm: dts: k3-am64-main: Add GPIO nodes arm: dts: k3-am642-r5-evm: Add GPIO DDR VTT regulator configs: am64x_evm_r5: Enable GPIO regulator Suman Anna (1): arm: mach-k3: am642: Shut down R5 core after ATF startup on A53 Vignesh Raghavendra (13): board: ti: am64x: Parse MAC address from board EEPROM firmware: ti_sci: Update ti_sci_cmd_rm_udmap_tx_ch_cfg() API to the latest soc: ti: k3-navss-ringacc: Add AM64 ringacc support soc: ti: k3-navss-ringacc: Remove unused ring modes
Re: [PATCH] board: ti: am64x: Parse MAC address from board EEPROM
On 10/05/21 11:44 pm, Vignesh Raghavendra wrote: > Parse MAC addresses from EEPROM and set them in the env. This is needed > to get MAC address for additional ethernet ports on the EVM. > > Signed-off-by: Vignesh Raghavendra Applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH 00/12] AM64x: DMA and ethernet support
On 10/05/21 8:06 pm, Vignesh Raghavendra wrote: > This series add ethernet and DMA support for AM64x SoC. Applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH 00/18] arm: k3-am64: Add initial support for AM64 SK
On 06/05/21 4:44 pm, Lokesh Vutla wrote: > AM642 StarterKit (SK) board is a low cost, small form factor board > designed for TI’s AM642 SoC. It supports the following interfaces: > * 2 GB LPDDR4 RAM > * x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode > * x1 USB 3.0 Type-A port > * x1 UHS-1 capable µSD card slot > * 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837 > * 512 Mbit OSPI flash > * x2 UART through UART-USB bridge > * XDS110 for onboard JTAG debug using USB > * Temperature sensors, user push buttons and LEDs > * 40-pin Raspberry Pi compatible GPIO header > * 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO) > * 54-pin header for Programmable Realtime Unit (PRU) IO pins > * Interface for remote automation. Includes: > * power measurement and reset control > * boot mode change > > This series adds support for: > - AM64 SoC detection > - AM64 board detection > - AM64 SK initial support > - Re-use EVM defconfigs for SK. > > This series depends on the following series: > - https://patchwork.ozlabs.org/user/todo/uboot/?series=240546 > - https://patchwork.ozlabs.org/user/todo/uboot/?series=241946 > - https://patchwork.ozlabs.org/user/todo/uboot/?series=242110 Fixed the timer clock frequency locally and applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH 00/17] arm: mach-k3: Initial Support for Texas Instruments AM642 Platform
On 23/04/21 9:57 pm, Dave Gerlach wrote: > Hi, > > This series adds initial support for the latest new SoC, AM642, > from Texas Instruments. > > Additional detail can be found in the patch descriptions, also > see AM64X Technical Reference Manual (SPRUIM2, Revised Jan 2021) > for further details: https://www.ti.com/lit/pdf/spruim2 Fixed the MAINTAINERS file and Timer clock frequency and applied to u-boot-ti/for-rc Thanks and regards, Lokesh > > Regards, > Dave > > Dave Gerlach (14): > arm: mach-k3: Add basic support for AM642 SoC definition > arm: mach-k3: am642: Unlock all applicable control MMR registers > arm: mach-k3: am642: Store boot info from ROM > arm: mach-k3: am642: Load SYSFW binary and config from boot media > arm: mach-k3: am642: Use mmc start and stop callbacks > mmc: sdhci_am654: Add Support for TI's AM642 SoC > mailbox: k3-sec-proxy: Extend valid thread IDs > board: ti: am64x: Add board support for am64x evm > dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64 > arm: dts: ti: Add Support for AM642 SoC > arm: dts: k3-am642: Add initial support for EVM > arm: dts: k3-am642: Add r5 specific dt support > configs: am64x_evm_r5: Add Initial support > configs: am64x_evm_a53: Add Initial support > > Keerthy (2): > arm: mach-k3: am642: Add support for boot device detection > armv8: mach-k3: am642: Add custom MMU support > > Suman Anna (1): > arm: mach-k3: am642: Shut down R5 core after ATF startup on A53 > > arch/arm/dts/Makefile | 2 + > arch/arm/dts/k3-am64-main.dtsi| 405 ++ > arch/arm/dts/k3-am64-mcu.dtsi | 76 > arch/arm/dts/k3-am64.dtsi | 103 + > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 58 +++ > arch/arm/dts/k3-am642-evm.dts | 246 +++ > arch/arm/dts/k3-am642-r5-evm.dts | 169 > arch/arm/dts/k3-am642.dtsi| 65 +++ > arch/arm/mach-k3/Kconfig | 15 +- > arch/arm/mach-k3/Makefile | 1 + > arch/arm/mach-k3/am642_init.c | 283 > arch/arm/mach-k3/arm64-mmu.c | 41 ++ > arch/arm/mach-k3/include/mach/am64_hardware.h | 52 +++ > arch/arm/mach-k3/include/mach/am64_spl.h | 44 ++ > arch/arm/mach-k3/include/mach/hardware.h | 4 + > arch/arm/mach-k3/include/mach/spl.h | 4 + > board/ti/am64x/Kconfig| 53 +++ > board/ti/am64x/Makefile | 8 + > board/ti/am64x/evm.c | 48 +++ > configs/am64x_evm_a53_defconfig | 96 + > configs/am64x_evm_r5_defconfig| 91 > drivers/mailbox/k3-sec-proxy.c| 10 +- > drivers/mmc/am654_sdhci.c | 18 + > include/configs/am64x_evm.h | 105 + > include/dt-bindings/pinctrl/k3.h | 5 +- > 25 files changed, 1988 insertions(+), 14 deletions(-) > create mode 100644 arch/arm/dts/k3-am64-main.dtsi > create mode 100644 arch/arm/dts/k3-am64-mcu.dtsi > create mode 100644 arch/arm/dts/k3-am64.dtsi > create mode 100644 arch/arm/dts/k3-am642-evm-u-boot.dtsi > create mode 100644 arch/arm/dts/k3-am642-evm.dts > create mode 100644 arch/arm/dts/k3-am642-r5-evm.dts > create mode 100644 arch/arm/dts/k3-am642.dtsi > create mode 100644 arch/arm/mach-k3/am642_init.c > create mode 100644 arch/arm/mach-k3/include/mach/am64_hardware.h > create mode 100644 arch/arm/mach-k3/include/mach/am64_spl.h > create mode 100644 board/ti/am64x/Kconfig > create mode 100644 board/ti/am64x/Makefile > create mode 100644 board/ti/am64x/evm.c > create mode 100644 configs/am64x_evm_a53_defconfig > create mode 100644 configs/am64x_evm_r5_defconfig > create mode 100644 include/configs/am64x_evm.h >
Re: [PATCH 0/5] arm: mach-k3: k3-am64: Add DDR configuration and enable
On 05/05/21 4:30 am, Dave Gerlach wrote: > This series adds the required configuration needed to use the new common > k3-ddrss driver on am64 and also adds the required dts data needed to > enable DDR usage on the k3-am642-evm platform. > > This series depends on the AM64 base support series [1] and the Common > K3 DDRSS series here [2]. > > Regards, > Dave Applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH v2 00/15] ram: k3-ddrss: Convert k3-j721e to common driver with k3-am64 support
On 11/05/21 8:51 pm, Dave Gerlach wrote: > This is v2 of the series to update the existing k3-j721e driver to a > common driver to support both j721e and the new am642 SoC. It renames > drivers/ram/k3-j721e to drivers/ram/k3-ddrss and then introduces a > refactored common driver with the existing j721e support moved to files > named with 32bit and am64 support introduced in files named with 16bit. > > Changes since v1: > * Drop unnecessary error macro re-definitions and use normal errno header > * Drop other unnecessary headers that wrap standard kernel headers > * Fixed a few camelCase functions that slipped through > * Fixed clock initialization sequence based on comment from Vignesh > > v1: https://lists.denx.de/pipermail/u-boot/2021-May/448716.html > Applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH v2 0/5] Revert "fdt: translate address if #size-cells = <0>"
On 01/05/21 8:35 pm, Dario Binacchi wrote:
>
> As pointed by [1] and [2] the d64b9cdcd4 ("fdt: translate address if
> #size-cells = <0>")
> commit was wrong. The series reverts the patch and fixes the issue with
> platform code, adding custom routines to access the clocks registers.
> The solution has been inspired by the Linux Kernel code.
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/1614324949-61314-1-git-send-email-bmeng...@gmail.com/
> [2]
> https://lore.kernel.org/linux-clk/20210402192054.7934-1-dario...@libero.it/T/
>
> Changes in v2:
> - Remove #if CONFIG_IS_ENABLED(AM33XX). It was counter intuitive.
> - Added Bin Meng Reviewed-by tag.
>
Applied to u-boot-ti/for-rc
Thanks and regards,
Lokesh
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
Hi Green, On Mon, May 10, 2021 at 5:08 PM Bin Meng wrote: > > This reverts commit bc8bbb77f74f21582b3bfd790334397757f88575. > > This commit breaks U-Boot booting on SiFive Unleashed board, as > there is no such CSR on U54 core. > > Signed-off-by: Bin Meng > --- > > arch/riscv/cpu/fu540/spl.c | 15 --- > 1 file changed, 15 deletions(-) > Please note you need to add the changes in the arch/riscv/cpu/fu740 directory. Regards, Bin
[PATCH] rpi: always set fdt_addr with firmware-provided FDT address
Raspberry firmware prepares the FDT blob in memory at an address
that depends on both the memory size and the blob size [1].
After commit ade243a211d6 ("rpi: passthrough of the firmware provided FDT
blob") this FDT is passed to kernel through fdt_addr environment variable,
handled in set_fdt_addr() function in board file.
When u-boot environment is persistently saved, if a change happens
in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT
address different from the saved one, but u-boot still use the saved
one because set_fdt_addr() function does not overwrite the fdt_addr
variable. So, for example, if there is a script that uses fdt commands for
e.g. manipulate the bootargs, boot hangs with error
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Removing the fdt_addr variable in saved environment allows to boot.
With this patch set_fdt_addr() function always overwrite fdt_addr value.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018
Signed-off-by: Mauro Salvini
Cc: Cédric Schieli
Cc: Matthias Brugger
---
board/raspberrypi/rpi/rpi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index df52a4689f..611013471e 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -318,9 +318,6 @@ static void set_fdtfile(void)
*/
static void set_fdt_addr(void)
{
- if (env_get("fdt_addr"))
- return;
-
if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
return;
--
2.17.1
[PATCH] xilinx: versal: Enable CONFIG_POSITION_INDEPENDENT
From: T Karthik Reddy
U-Boot expects to be linked to a specific hard-coded address and to
be loaded to and run from that address. CONFIG_POSITION_INDEPENDENT
config lifts that restriction & allowing the code to be loaded to
and executed from almost any address.
As we enabled CONFIG_POSITION_INDEPENDENT, CONFIG_INIT_SP_RELATIVE
is enabled by default, where it will set the early stack pointer at
runtime by adding an offset value to &_bss_start. The offset value
is taken from SYS_INIT_SP_BSS_OFFSET.
SYS_INIT_SP_BSS_OFFSET offset should be large enough so that the
early malloc region, global data (gd), and early stack should fit.
With commit d8fabcc424bd ("arm64: versal: Increase SYS_MALLOC_F_LEN")
SYS_MALLOC_F_LEN is increased from 32KB to 1MB, so we need to
accommodate this space with SYS_INIT_SP_BSS_OFFSET. Hence increasing
SYS_INIT_SP_BSS_OFFSET to 1.5MB.
Signed-off-by: T Karthik Reddy
Acked-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
configs/xilinx_versal_virt_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/xilinx_versal_virt_defconfig
b/configs/xilinx_versal_virt_defconfig
index 707693713a7e..f4e9a80728d7 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_POSITION_INDEPENDENT=y
+CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864
CONFIG_ARCH_VERSAL=y
CONFIG_SYS_TEXT_BASE=0x800
CONFIG_SYS_MALLOC_F_LEN=0x10
--
2.31.1
[PATCH v5 3/3] efi_loader: add FIT_SIGNATURE option to use hash_calculate()
Build error occurs when CONFIG_EFI_SECURE_BOOT/
CONFIG_EFI_CAPSULE_AUTHENTICATE/CONFIG_EFI_TCG2_PROTOCOL
is enabled, because hash-checksum.c is not compiled.
With the following commit,
commit 0bcb28dfb946 ("lib: Rename rsa-checksum.c to hash-checksum.c")
CONFIG_FIT_SIGNATURE option is required to use hash_calculate() function.
This commit selects FIT_SIGNATURE option in Kconfig.
Signed-off-by: Masahisa Kojima
---
Changes in v5:
- Missing option for EFI_TCG2_PROTOROL already added in different commit.
This commit adds FIT_SIGNATRE only.
Changes in v4:
- newly added in this patch series, due to rebasing
the base code.
lib/efi_loader/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 385a81d7d9..0ffced25b1 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -175,6 +175,7 @@ config EFI_CAPSULE_AUTHENTICATE
select PKCS7_VERIFY
select IMAGE_SIGN_INFO
select EFI_SIGNATURE_SUPPORT
+ select FIT_SIGNATURE
default n
help
Select this option if you want to enable capsule
@@ -308,6 +309,7 @@ config EFI_TCG2_PROTOCOL
select SHA512_ALGO
select SHA384
select SHA512
+ select FIT_SIGNATURE
help
Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
of the platform.
@@ -344,6 +346,7 @@ config EFI_SECURE_BOOT
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
select EFI_SIGNATURE_SUPPORT
+ select FIT_SIGNATURE
default n
help
Select this option to enable EFI secure boot support.
--
2.17.1
[PATCH v5 2/3] efi_loader: add PE/COFF image measurement
"TCG PC Client Platform Firmware Profile Specification"
requires to measure every attempt to load and execute
a OS Loader(a UEFI application) into PCR[4].
This commit adds the PE/COFF image measurement, extends PCR,
and appends measurement into Event Log.
Acked-by: Ilias Apalodimas
Tested-by: Ilias Apalodimas
Signed-off-by: Masahisa Kojima
---
(no changes since v2)
Changes in v2:
- Remove duplicate include
- Remove unnecessary __packed attribute
- Add all EV_EFI_* event definition
- Create common function to prepare 8-byte aligned image
- Add measurement for EV_EFI_BOOT_SERVICES_DRIVER and
EV_EFI_RUNTIME_SERVICES_DRIVER
- Use efi_search_protocol() to get device_path
- Add function comment
include/efi_loader.h | 6 +
include/efi_tcg2.h| 9 ++
include/tpm-v2.h | 18 +++
lib/efi_loader/efi_image_loader.c | 59 +++--
lib/efi_loader/efi_tcg2.c | 207 --
5 files changed, 275 insertions(+), 24 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index de1a496a97..9f2854a255 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -426,6 +426,10 @@ efi_status_t efi_disk_register(void);
efi_status_t efi_rng_register(void);
/* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */
efi_status_t efi_tcg2_register(void);
+/* measure the pe-coff image, extend PCR and add Event Log */
+efi_status_t tcg2_measure_pe_image(void *efi, u64 efi_size,
+ struct efi_loaded_image_obj *handle,
+ struct efi_loaded_image *loaded_image_info);
/* Create handles and protocols for the partitions of a block device */
int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
const char *if_typename, int diskid,
@@ -847,6 +851,8 @@ bool efi_secure_boot_enabled(void);
bool efi_capsule_auth_enabled(void);
+void *efi_prepare_aligned_image(void *efi, u64 *efi_size, void **new_efi);
+
bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp,
WIN_CERTIFICATE **auth, size_t *auth_len);
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index 40e241ce31..bcfb98168a 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -9,6 +9,7 @@
#if !defined _EFI_TCG2_PROTOCOL_H_
#define _EFI_TCG2_PROTOCOL_H_
+#include
#include
#define EFI_TCG2_PROTOCOL_GUID \
@@ -53,6 +54,14 @@ struct efi_tcg2_event {
u8 event[];
} __packed;
+struct uefi_image_load_event {
+ efi_physical_addr_t image_location_in_memory;
+ u64 image_length_in_memory;
+ u64 image_link_time_address;
+ u64 length_of_device_path;
+ struct efi_device_path device_path[];
+};
+
struct efi_tcg2_boot_service_capability {
u8 size;
struct efi_tcg2_version structure_version;
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 7de7d6a57d..247b386967 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -70,6 +70,24 @@ struct udevice;
#define EV_TABLE_OF_DEVICES((u32)0x000B)
#define EV_COMPACT_HASH((u32)0x000C)
+/*
+ * event types, cf.
+ * "TCG PC Client Platform Firmware Profile Specification", Family "2.0"
+ * rev 1.04, June 3, 2019
+ */
+#define EV_EFI_EVENT_BASE ((u32)0x8000)
+#define EV_EFI_VARIABLE_DRIVER_CONFIG ((u32)0x8001)
+#define EV_EFI_VARIABLE_BOOT ((u32)0x8002)
+#define EV_EFI_BOOT_SERVICES_APPLICATION ((u32)0x8003)
+#define EV_EFI_BOOT_SERVICES_DRIVER((u32)0x8004)
+#define EV_EFI_RUNTIME_SERVICES_DRIVER ((u32)0x8005)
+#define EV_EFI_GPT_EVENT ((u32)0x8006)
+#define EV_EFI_ACTION ((u32)0x8007)
+#define EV_EFI_PLATFORM_FIRMWARE_BLOB ((u32)0x8008)
+#define EV_EFI_HANDOFF_TABLES ((u32)0x8009)
+#define EV_EFI_HCRTM_EVENT ((u32)0x8010)
+#define EV_EFI_VARIABLE_AUTHORITY ((u32)0x80E0)
+
/* TPMS_TAGGED_PROPERTY Structure */
struct tpms_tagged_property {
u32 property;
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index fe1ee198e2..f37a85e56e 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -302,6 +302,40 @@ static int cmp_pe_section(const void *arg1, const void
*arg2)
return 1;
}
+/**
+ * efi_prepare_aligned_image() - prepare 8-byte aligned image
+ * @efi: pointer to the EFI binary
+ * @efi_size: size of @efi binary
+ * @new_efi: pointer to the newly allocated image
+ *
+ * If @efi is not 8-byte aligned, this function newly allocates
+ * the image buffer and updates @efi_size.
+ *
+ * Return: valid pointer to a image, return NULL if allocation fails.
+ */
+void *efi_prepare_aligned_image(void *efi, u64 *efi_size,
[PATCH v5 1/3] efi_loader: expose efi_image_parse() even if UEFI Secure Boot is disabled
This is preparation for PE/COFF measurement support.
PE/COFF image hash calculation is same in both
UEFI Secure Boot image verification and measurement in
measured boot. PE/COFF image parsing functions are
gathered into efi_image_loader.c, and exposed even if
UEFI Secure Boot is not enabled.
This commit also adds the EFI_SIGNATURE_SUPPORT option
to decide if efi_signature.c shall be compiled.
Signed-off-by: Masahisa Kojima
---
(no changes since v4)
Changes in v4:
- revert #ifdef instead of using "if (!IS_ENABLED())" statement,
not to rely on the compiler optimization.
Changes in v3:
- hide EFI_SIGNATURE_SUPPORT option
Changes in v2:
- Remove all #ifdef from efi_image_loader.c and efi_signature.c
- Add EFI_SIGNATURE_SUPPORT option
- Explicitly include
- Gather PE/COFF parsing functions into efi_image_loader.c
- Move efi_guid_t efi_guid_image_security_database in efi_var_common.c
lib/efi_loader/Kconfig| 6 +++
lib/efi_loader/Makefile | 2 +-
lib/efi_loader/efi_image_loader.c | 64 -
lib/efi_loader/efi_signature.c| 67 +--
lib/efi_loader/efi_var_common.c | 3 ++
5 files changed, 74 insertions(+), 68 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c259abe033..385a81d7d9 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -174,6 +174,7 @@ config EFI_CAPSULE_AUTHENTICATE
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
select IMAGE_SIGN_INFO
+ select EFI_SIGNATURE_SUPPORT
default n
help
Select this option if you want to enable capsule
@@ -342,6 +343,7 @@ config EFI_SECURE_BOOT
select X509_CERTIFICATE_PARSER
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
+ select EFI_SIGNATURE_SUPPORT
default n
help
Select this option to enable EFI secure boot support.
@@ -349,6 +351,10 @@ config EFI_SECURE_BOOT
it is signed with a trusted key. To do that, you need to install,
at least, PK, KEK and db.
+config EFI_SIGNATURE_SUPPORT
+ bool
+ depends on EFI_SECURE_BOOT || EFI_CAPSULE_AUTHENTICATE
+
config EFI_ESRT
bool "Enable the UEFI ESRT generation"
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 8bd343e258..fd344cea29 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o
-obj-y += efi_signature.o
+obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o
EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
$(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index f53ef367ec..fe1ee198e2 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -213,7 +213,68 @@ static void efi_set_code_and_data_type(
}
}
-#ifdef CONFIG_EFI_SECURE_BOOT
+/**
+ * efi_image_region_add() - add an entry of region
+ * @regs: Pointer to array of regions
+ * @start: Start address of region (included)
+ * @end: End address of region (excluded)
+ * @nocheck: flag against overlapped regions
+ *
+ * Take one entry of region [@start, @end[ and insert it into the list.
+ *
+ * * If @nocheck is false, the list will be sorted ascending by address.
+ * Overlapping entries will not be allowed.
+ *
+ * * If @nocheck is true, the list will be sorted ascending by sequence
+ * of adding the entries. Overlapping is allowed.
+ *
+ * Return: status code
+ */
+efi_status_t efi_image_region_add(struct efi_image_regions *regs,
+ const void *start, const void *end,
+ int nocheck)
+{
+ struct image_region *reg;
+ int i, j;
+
+ if (regs->num >= regs->max) {
+ EFI_PRINT("%s: no more room for regions\n", __func__);
+ return EFI_OUT_OF_RESOURCES;
+ }
+
+ if (end < start)
+ return EFI_INVALID_PARAMETER;
+
+ for (i = 0; i < regs->num; i++) {
+ reg = >reg[i];
+ if (nocheck)
+ continue;
+
+ /* new data after registered region */
+ if (start >= reg->data + reg->size)
+ continue;
+
+ /* new data preceding registered region */
+ if (end <= reg->data) {
+ for (j = regs->num - 1; j >= i; j--)
+ memcpy(>reg[j + 1], >reg[j],
+ sizeof(*reg));
+ break;
+ }
+
+ /* new data overlapping registered region */
+
[PATCH v5 0/3] PE/COFF measurement support
This patch series add the PE/COFF measurement support. Extending PCR and Event Log is tested with fTPM running as a OP-TEE TA. Unit test will be added in the separate series. Masahisa Kojima (3): efi_loader: expose efi_image_parse() even if UEFI Secure Boot is disabled efi_loader: add PE/COFF image measurement efi_loader: add FIT_SIGNATURE option to use hash_calculate() include/efi_loader.h | 6 + include/efi_tcg2.h| 9 ++ include/tpm-v2.h | 18 +++ lib/efi_loader/Kconfig| 9 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_image_loader.c | 123 +++--- lib/efi_loader/efi_signature.c| 67 +- lib/efi_loader/efi_tcg2.c | 207 -- lib/efi_loader/efi_var_common.c | 3 + 9 files changed, 352 insertions(+), 92 deletions(-) -- 2.17.1
Re: [PATCH v4 3/3] efi_loader: add required option to use hash_calculate()
On Wed, 12 May 2021 at 17:32, Ilias Apalodimas
wrote:
>
> On Wed, May 12, 2021 at 03:59:47PM +0900, Masahisa Kojima wrote:
> > Build error occurs when CONFIG_EFI_SECURE_BOOT/
> > CONFIG_EFI_CAPSULE_AUTHENTICATE/CONFIG_EFI_TCG2_PROTOCOL
> > is enabled, because hash-checksum.c is not compiled.
> >
> > With the following commit,
> > commit 0bcb28dfb946 ("lib: Rename rsa-checksum.c to hash-checksum.c")
> > CONFIG_FIT_SIGNATURE option is required to use hash_calculate() function.
> >
> > This commit adds CONFIG_FIT_SIGNATURE option in Kconfig, and missing
> > required options for CONFIG_EFI_TCG2_PROTOCOL.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> >
> > Changes in v4:
> > - newly added in this patch series, due to rebasing
> > the base code.
> >
> > lib/efi_loader/Kconfig | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index b76e77180e..93463fb362 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -175,6 +175,7 @@ config EFI_CAPSULE_AUTHENTICATE
> > select PKCS7_VERIFY
> > select IMAGE_SIGN_INFO
> > select EFI_SIGNATURE_SUPPORT
> > + select FIT_SIGNATURE
> > default n
> > help
> > Select this option if you want to enable capsule
> > @@ -302,6 +303,12 @@ config EFI_RNG_PROTOCOL
> > config EFI_TCG2_PROTOCOL
> > bool "EFI_TCG2_PROTOCOL support"
> > depends on TPM_V2
> > + select FIT_SIGNATURE
> > + select SHA1
> > + select SHA256
> > + select SHA512_ALGO
> > + select SHA384
> > + select SHA512
> > help
> > Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
> > of the platform.
> > @@ -338,6 +345,7 @@ config EFI_SECURE_BOOT
> > select PKCS7_MESSAGE_PARSER
> > select PKCS7_VERIFY
> > select EFI_SIGNATURE_SUPPORT
> > + select FIT_SIGNATURE
> > default n
> > help
> > Select this option to enable EFI secure boot support.
> > --
> > 2.17.1
> >
>
> I've sent a similar patch yesterday that Heinrich already applied on his
> tree, you'll only need to add FIT_SIGNATURE now
Hi Ilias,
Thank you for your comment.
I rebase and will send v5.
Thanks,
Masahisa
>
> Cheers
> /Ilias
[PATCH] MAINTAINERS, git-mailrc: socfpga: Update email address for Ley Foon
My mail address doesn't work any longer, change to gmail. Signed-off-by: Ley Foon Tan --- MAINTAINERS| 2 +- doc/git-mailrc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 20092cb36740..fc1529ff3c1f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -118,7 +118,7 @@ F: cmd/arm/ ARM ALTERA SOCFPGA M: Marek Vasut M: Simon Goldschmidt -M: Ley Foon Tan +M: Ley Foon Tan S: Maintainted T: git https://source.denx.de/u-boot/custodians/u-boot-socfpga.git F: arch/arm/mach-socfpga/ diff --git a/doc/git-mailrc b/doc/git-mailrc index f520ff89b390..34f936f4d83c 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -29,7 +29,7 @@ alias jaehoonJaehoon Chung alias jagan Jagan Teki alias jhersh Joe Hershberger alias kevery Kever Yang -alias leyfoonLey Foon Tan +alias leyfoonLey Foon Tan alias lokeshvutlaLokesh Vutla alias lukma Lukasz Majewski alias macpaulMacpaul Lin -- 2.26.2
Re: [PATCH 2/4] tools: mkeficapsule: remove device-tree related operation
On 12.05.21 10:01, Ilias Apalodimas wrote:
> On Wed, May 12, 2021 at 04:49:02PM +0900, Masami Hiramatsu wrote:
>> Hi Ilias,
>>
>> 2021年5月12日(水) 16:21 Ilias Apalodimas :
>>>
>>> Akashi-san,
>>>
>>> On Wed, May 12, 2021 at 01:57:51PM +0900, AKASHI Takahiro wrote:
As we discussed, "-K" and "-D" options have nothing to do with
creating a capsule file. The same result can be obtained by
using standard commands like:
=== signature.dts ===
/dts-v1/;
/plugin/;
&{/} {
signature {
capsule-key = /incbin/("SIGNER.esl");
};
};
===
$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
$ fdtoverlay -i test.dtb -o test_sig.dtb -v signature.dtbo
So just remove this feature.
(Effectively revert the commit 322c813f4bec ("mkeficapsule: Add support
for embedding public key in a dtb").)
The same feature is implemented by a shell script (tools/fdtsig.sh).
>>>
>>>
>>> The only reason I can see to keep this, is if mkeficapsule gets included
>>> intro distro packages in the future. That would make end users life a bit
>>> easier, since they would need a single binary to create the whole
>>> CapsuleUpdate sequence.
>>
>> Hmm, I think it is better to write a manpage of mkeficapsule which
>> also describes
>> how to embed the key into dtb as in the above example if it is so short.
>> Or, distros can package the above shell script with mkeficapsule.
>>
>> Embedding a key and signing a capsule are different operations but
>> using the same tool may confuse users (at least me).
>
> Sure fair enough. I am merely pointing out we need a way to explain all of
> those to users.
This is currently our only documentation:
https://u-boot.readthedocs.io/en/latest/board/emulation/qemu_capsule_update.html?highlight=mkeficapsule
For mkimage we have a man-page ./doc/mkimage.1 that is packaged with
Debians u-boot-tools package. Please, provide a similar man-page as
./doc/mkeficapsule.1.
Best regards
Heinrich
Re: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing
On 12.05.21 06:57, AKASHI Takahiro wrote:
> With this enhancement, mkeficapsule will be able to create a capsule
> file with a signature which will be verified later by FMP's SetImage().
>
> We will have to specify addtional command parameters:
> -monotonic-cout : monotonic count
> -private-key : private key file
> -certificate : certificate file
> Only when those parameters are given, a signature will be added
> to a capsule file.
>
> Users are expected to maintain the monotonic count for each firmware
> image.
>
> Signed-off-by: AKASHI Takahiro
> ---
> tools/Makefile | 4 +
> tools/mkeficapsule.c | 324 +++
> 2 files changed, 303 insertions(+), 25 deletions(-)
>
> diff --git a/tools/Makefile b/tools/Makefile
> index d020c55d6644..02eae0286e20 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -231,6 +231,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
> hostprogs-$(CONFIG_ASN1_COMPILER)+= asn1_compiler
> HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
>
> +ifneq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),)
> +HOSTLDLIBS_mkeficapsule += \
> + $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl
> -lcrypto")
I don't expect any user wants to install two tool versions in parallel.
The tool should always be able to add a signature.
Adding a signature must be optional.
> +endif
> mkeficapsule-objs:= mkeficapsule.o $(LIBFDT_OBJS)
> hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
>
> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> index de0a62898886..34ff1bdd82eb 100644
> --- a/tools/mkeficapsule.c
> +++ b/tools/mkeficapsule.c
> @@ -18,7 +18,17 @@
> #include
> #include
>
> -#include "fdt_host.h"
> +#include
> +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#endif
> +
> +#include
>
> typedef __u8 u8;
> typedef __u16 u16;
> @@ -46,6 +56,13 @@ efi_guid_t efi_guid_image_type_uboot_fit =
> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
> efi_guid_t efi_guid_image_type_uboot_raw =
> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
> +efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> +
> +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
> +static const char *opts_short = "f:r:i:I:v:D:K:P:C:m:dOh";
> +#else
> +static const char *opts_short = "f:r:i:I:v:D:K:Oh";
> +#endif
>
> static struct option options[] = {
> {"fit", required_argument, NULL, 'f'},
> @@ -54,6 +71,12 @@ static struct option options[] = {
> {"instance", required_argument, NULL, 'I'},
> {"dtb", required_argument, NULL, 'D'},
> {"public key", required_argument, NULL, 'K'},
> +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> + {"private-key", required_argument, NULL, 'P'},
> + {"certificate", required_argument, NULL, 'C'},
> + {"monotonic-count", required_argument, NULL, 'm'},
These options should not be required.
> + {"dump-sig", no_argument, NULL, 'd'},
> +#endif
> {"overlay", no_argument, NULL, 'O'},
> {"help", no_argument, NULL, 'h'},
> {NULL, 0, NULL, 0},
> @@ -70,6 +93,12 @@ static void print_usage(void)
> "\t-I, --instanceupdate hardware instance\n"
> "\t-K, --public-key public key esl file\n"
> "\t-D, --dtb dtb file\n"
> +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
> +"\t-P, --private-key private key file\n"
> +"\t-C, --certificate signer's certificate file\n"
> +"\t-m, --monotonic-count monotonic count\n"
> +"\t-d, --dump_sig dump signature (*.p7)\n"
> +#endif
> "\t-O, --overlay the dtb file is an overlay\n"
> "\t-h, --help print a help message\n",
> tool_name);
> @@ -249,12 +278,167 @@ err:
> return ret;
> }
>
> +struct auth_context {
> + char *key_file;
> + char *cert_file;
> + u8 *image_data;
> + size_t image_size;
> + struct efi_firmware_image_authentication auth;
> + u8 *sig_data;
> + size_t sig_size;
> +};
> +
> +static int dump_sig;
> +
> +#if IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)
see above
> +static EVP_PKEY *fileio_read_pkey(const char *filename)
> +{
> + EVP_PKEY *key = NULL;
> + BIO *bio;
> +
> + bio = BIO_new_file(filename, "r");
> + if (!bio)
> + goto out;
> +
> + key = PEM_read_bio_PrivateKey(bio, NULL, NULL, NULL);
> +
> +out:
> + BIO_free_all(bio);
> + if (!key) {
> + printf("Can't load key from file '%s'\n", filename);
Please, you use fprintf(stderr,) for error messages.
> + ERR_print_errors_fp(stderr);
> + }
> +
> + return key;
> +}
> +
> +static X509 *fileio_read_cert(const char *filename)
> +{
> + X509 *cert = NULL;
> + BIO *bio;
> +
> + bio = BIO_new_file(filename,
Re: [PATCH v8 1/7] riscv: cpu: fu740: Add support for cpu fu740
Hi Leo, It failed to compile ./drivers/pci/pcie_dw_common.c. And the file is not included in this patch actually. I guess the CI has the "-Werror=format" in CFLGAS and hits the error. But I do see lots of warnings without " -Werror=format" option. Loop Neil here and see if he can help on to fix those warnings. Thanks, - Green On Wed, May 12, 2021 at 2:11 PM Leo Liang wrote: > Hi Green, > > This patch series seems to have failed CI test. > Could you please check the CI result ? Thanks! > > > https://dev.azure.com/ycliang-tw/u-boot-riscv/_build/results?buildId=28=results > > Best regards, > Leo > > On Fri, May 07, 2021 at 10:36:47AM -0700, Green Wan wrote: > > Add SiFive fu740 cpu to support RISC-V arch > > > > Signed-off-by: Green Wan > > Reviewed-by: Bin Meng > > --- > > arch/riscv/Kconfig| 1 + > > arch/riscv/cpu/fu740/Kconfig | 37 +++ > > arch/riscv/cpu/fu740/Makefile | 12 + > > arch/riscv/cpu/fu740/cache.c | 55 +++ > > arch/riscv/cpu/fu740/cpu.c| 22 + > > arch/riscv/cpu/fu740/dram.c | 38 > > arch/riscv/cpu/fu740/spl.c| 23 ++ > > arch/riscv/include/asm/arch-fu740/cache.h | 14 ++ > > arch/riscv/include/asm/arch-fu740/clk.h | 14 ++ > > arch/riscv/include/asm/arch-fu740/gpio.h | 38 > > arch/riscv/include/asm/arch-fu740/reset.h | 13 ++ > > arch/riscv/include/asm/arch-fu740/spl.h | 14 ++ > > 12 files changed, 281 insertions(+) > > create mode 100644 arch/riscv/cpu/fu740/Kconfig > > create mode 100644 arch/riscv/cpu/fu740/Makefile > > create mode 100644 arch/riscv/cpu/fu740/cache.c > > create mode 100644 arch/riscv/cpu/fu740/cpu.c > > create mode 100644 arch/riscv/cpu/fu740/dram.c > > create mode 100644 arch/riscv/cpu/fu740/spl.c > > create mode 100644 arch/riscv/include/asm/arch-fu740/cache.h > > create mode 100644 arch/riscv/include/asm/arch-fu740/clk.h > > create mode 100644 arch/riscv/include/asm/arch-fu740/gpio.h > > create mode 100644 arch/riscv/include/asm/arch-fu740/reset.h > > create mode 100644 arch/riscv/include/asm/arch-fu740/spl.h >
Re: [PATCH v4 2/3] efi_loader: add PE/COFF image measurement
On Wed, May 12, 2021 at 03:59:46PM +0900, Masahisa Kojima wrote:
> "TCG PC Client Platform Firmware Profile Specification"
> requires to measure every attempt to load and execute
> a OS Loader(a UEFI application) into PCR[4].
> This commit adds the PE/COFF image measurement, extends PCR,
> and appends measurement into Event Log.
>
> Signed-off-by: Masahisa Kojima
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Remove duplicate include
> - Remove unnecessary __packed attribute
> - Add all EV_EFI_* event definition
> - Create common function to prepare 8-byte aligned image
> - Add measurement for EV_EFI_BOOT_SERVICES_DRIVER and
> EV_EFI_RUNTIME_SERVICES_DRIVER
> - Use efi_search_protocol() to get device_path
> - Add function comment
>
> include/efi_loader.h | 6 +
> include/efi_tcg2.h| 9 ++
> include/tpm-v2.h | 18 +++
> lib/efi_loader/efi_image_loader.c | 59 +++--
> lib/efi_loader/efi_tcg2.c | 207 --
> 5 files changed, 275 insertions(+), 24 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index de1a496a97..9f2854a255 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -426,6 +426,10 @@ efi_status_t efi_disk_register(void);
> efi_status_t efi_rng_register(void);
> /* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */
> efi_status_t efi_tcg2_register(void);
> +/* measure the pe-coff image, extend PCR and add Event Log */
> +efi_status_t tcg2_measure_pe_image(void *efi, u64 efi_size,
> +struct efi_loaded_image_obj *handle,
> +struct efi_loaded_image *loaded_image_info);
> /* Create handles and protocols for the partitions of a block device */
> int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
> const char *if_typename, int diskid,
> @@ -847,6 +851,8 @@ bool efi_secure_boot_enabled(void);
>
> bool efi_capsule_auth_enabled(void);
>
> +void *efi_prepare_aligned_image(void *efi, u64 *efi_size, void **new_efi);
> +
> bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp,
>WIN_CERTIFICATE **auth, size_t *auth_len);
>
> diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> index 40e241ce31..bcfb98168a 100644
> --- a/include/efi_tcg2.h
> +++ b/include/efi_tcg2.h
> @@ -9,6 +9,7 @@
> #if !defined _EFI_TCG2_PROTOCOL_H_
> #define _EFI_TCG2_PROTOCOL_H_
>
> +#include
> #include
>
> #define EFI_TCG2_PROTOCOL_GUID \
> @@ -53,6 +54,14 @@ struct efi_tcg2_event {
> u8 event[];
> } __packed;
>
> +struct uefi_image_load_event {
> + efi_physical_addr_t image_location_in_memory;
> + u64 image_length_in_memory;
> + u64 image_link_time_address;
> + u64 length_of_device_path;
> + struct efi_device_path device_path[];
> +};
> +
> struct efi_tcg2_boot_service_capability {
> u8 size;
> struct efi_tcg2_version structure_version;
> diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> index 7de7d6a57d..247b386967 100644
> --- a/include/tpm-v2.h
> +++ b/include/tpm-v2.h
> @@ -70,6 +70,24 @@ struct udevice;
> #define EV_TABLE_OF_DEVICES ((u32)0x000B)
> #define EV_COMPACT_HASH ((u32)0x000C)
>
> +/*
> + * event types, cf.
> + * "TCG PC Client Platform Firmware Profile Specification", Family "2.0"
> + * rev 1.04, June 3, 2019
> + */
> +#define EV_EFI_EVENT_BASE((u32)0x8000)
> +#define EV_EFI_VARIABLE_DRIVER_CONFIG((u32)0x8001)
> +#define EV_EFI_VARIABLE_BOOT ((u32)0x8002)
> +#define EV_EFI_BOOT_SERVICES_APPLICATION ((u32)0x8003)
> +#define EV_EFI_BOOT_SERVICES_DRIVER ((u32)0x8004)
> +#define EV_EFI_RUNTIME_SERVICES_DRIVER ((u32)0x8005)
> +#define EV_EFI_GPT_EVENT ((u32)0x8006)
> +#define EV_EFI_ACTION((u32)0x8007)
> +#define EV_EFI_PLATFORM_FIRMWARE_BLOB((u32)0x8008)
> +#define EV_EFI_HANDOFF_TABLES((u32)0x8009)
> +#define EV_EFI_HCRTM_EVENT ((u32)0x8010)
> +#define EV_EFI_VARIABLE_AUTHORITY((u32)0x80E0)
> +
> /* TPMS_TAGGED_PROPERTY Structure */
> struct tpms_tagged_property {
> u32 property;
> diff --git a/lib/efi_loader/efi_image_loader.c
> b/lib/efi_loader/efi_image_loader.c
> index fe1ee198e2..f37a85e56e 100644
> --- a/lib/efi_loader/efi_image_loader.c
> +++ b/lib/efi_loader/efi_image_loader.c
> @@ -302,6 +302,40 @@ static int cmp_pe_section(const void *arg1, const void
> *arg2)
> return 1;
> }
>
> +/**
> + * efi_prepare_aligned_image() - prepare 8-byte aligned image
> + * @efi: pointer to the EFI binary
> + * @efi_size:size of @efi binary
> + * @new_efi: pointer to the newly allocated image
> + *
> + * If
Re: [PATCH v4 3/3] efi_loader: add required option to use hash_calculate()
On Wed, May 12, 2021 at 03:59:47PM +0900, Masahisa Kojima wrote:
> Build error occurs when CONFIG_EFI_SECURE_BOOT/
> CONFIG_EFI_CAPSULE_AUTHENTICATE/CONFIG_EFI_TCG2_PROTOCOL
> is enabled, because hash-checksum.c is not compiled.
>
> With the following commit,
> commit 0bcb28dfb946 ("lib: Rename rsa-checksum.c to hash-checksum.c")
> CONFIG_FIT_SIGNATURE option is required to use hash_calculate() function.
>
> This commit adds CONFIG_FIT_SIGNATURE option in Kconfig, and missing
> required options for CONFIG_EFI_TCG2_PROTOCOL.
>
> Signed-off-by: Masahisa Kojima
> ---
>
> Changes in v4:
> - newly added in this patch series, due to rebasing
> the base code.
>
> lib/efi_loader/Kconfig | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index b76e77180e..93463fb362 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -175,6 +175,7 @@ config EFI_CAPSULE_AUTHENTICATE
> select PKCS7_VERIFY
> select IMAGE_SIGN_INFO
> select EFI_SIGNATURE_SUPPORT
> + select FIT_SIGNATURE
> default n
> help
> Select this option if you want to enable capsule
> @@ -302,6 +303,12 @@ config EFI_RNG_PROTOCOL
> config EFI_TCG2_PROTOCOL
> bool "EFI_TCG2_PROTOCOL support"
> depends on TPM_V2
> + select FIT_SIGNATURE
> + select SHA1
> + select SHA256
> + select SHA512_ALGO
> + select SHA384
> + select SHA512
> help
> Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
> of the platform.
> @@ -338,6 +345,7 @@ config EFI_SECURE_BOOT
> select PKCS7_MESSAGE_PARSER
> select PKCS7_VERIFY
> select EFI_SIGNATURE_SUPPORT
> + select FIT_SIGNATURE
> default n
> help
> Select this option to enable EFI secure boot support.
> --
> 2.17.1
>
I've sent a similar patch yesterday that Heinrich already applied on his
tree, you'll only need to add FIT_SIGNATURE now
Cheers
/Ilias
[PATCH] xilinx: zynqmp: Enable DM_RTC/emul driver/cmd date/gettime and efi settime
Right now U-Boot is not aware about date/time that's why enable it by default also with EFI runtime service for setting time. Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_virt_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index b17a950db11e..e2968cb8411e 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -63,6 +63,7 @@ CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y +CONFIG_CMD_GETTIME=y CONFIG_CMD_TIMER=y CONFIG_CMD_TPM=y CONFIG_CMD_EXT4_WRITE=y @@ -144,6 +145,8 @@ CONFIG_PHY_XILINX_GMII2RGMII=y CONFIG_PHY_FIXED=y CONFIG_XILINX_AXIEMAC=y CONFIG_ZYNQ_GEM=y +CONFIG_DM_RTC=y +CONFIG_RTC_EMULATION=y CONFIG_SCSI=y CONFIG_DM_SCSI=y CONFIG_ARM_DCC=y @@ -184,6 +187,7 @@ CONFIG_TPM=y CONFIG_SPL_GZIP=y # CONFIG_SPL_HEXDUMP is not set CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_EFI_SET_TIME=y CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y -- 2.31.1
Re: [PATCH] mvebu: x530: Reduce SPL image size
On 12/05/21 09:18AM, Stefan Roese wrote: > Currently, building U-Boot for x530 fails since the SPL image is too > big. This patch reduces the SPL size by changing the following Kconfig > options: > > Enable CONFIG_SPL_TINY_MEMSET > Disable CONFIG_SPI_FLASH_BAR > > By disabling CONFIG_SPI_FLASH_BAR, the tiny SPI NOR framework can be > used. > > Signed-off-by: Stefan Roese > Cc: Chris Packham > Cc: Pratyush Yadav > Cc: Tom Rini Acked-by: Pratyush Yadav -- Regards, Pratyush Yadav Texas Instruments Inc.
Re: [PATCH] mvebu: x530: Reduce SPL image size
On 12.05.21 09:59, Chris Packham wrote: On Wed, May 12, 2021 at 7:18 PM Stefan Roese wrote: Currently, building U-Boot for x530 fails since the SPL image is too big. Currently? It's working for me on master. Are there upcoming mvebu changes that push us over the limit? Yes, I'm working on a pull request right now. Some enhancements to the SPI driver are most likely responsible for the code increase. This patch reduces the SPL size by changing the following Kconfig options: Enable CONFIG_SPL_TINY_MEMSET Disable CONFIG_SPI_FLASH_BAR By disabling CONFIG_SPI_FLASH_BAR, the tiny SPI NOR framework can be used. I've got a nagging feeling I needed CONFIG_SPI_FLASH_BAR for some reason. Possibly for some alternate part we were looking at, on the other hand it could also be from the db88f6820-amc board which I based the initial defconfig on. Looking at what CONFIG_SPI_FLASH_BAR does I think we should be safe. We only fit 16MiB parts and aren't likely to start fitting bigger parts unless all the spi-nor vendors decide to stop making ones <16MiB. Please note that there are better ways to handle the > 16MiB SPI NOR issue. E.g. by using 3 vs 4 byte commands and Serial Flash Discoverable Parameters (SFDP) parsing, which is supported in U-Boot since quite some time. I did not use CONFIG_SPI_FLASH_BAR for a longer time now IIRC. Signed-off-by: Stefan Roese Cc: Chris Packham Cc: Pratyush Yadav Cc: Tom Rini Tested-by: Chris Packham (yes I'm mixing work and personal email addresses. I can re-send tomorrow from the office if that's a concern). This is okay for me. Thanks for the quick review and test. Thanks, Stefan --- configs/x530_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/x530_defconfig b/configs/x530_defconfig index 890c94b5c1fe..76574c4de4be 100644 --- a/configs/x530_defconfig +++ b/configs/x530_defconfig @@ -62,7 +62,6 @@ CONFIG_SYS_NAND_USE_FLASH_BBT=y CONFIG_NAND_PXA3XX=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_SF_DEFAULT_SPEED=5000 -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_SST=y @@ -84,3 +83,4 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_WDT=y CONFIG_WDT_ORION=y +CONFIG_SPL_TINY_MEMSET=y -- 2.31.1 Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCHv2] net: convert TFTP_TSIZE to proper Kconfig option
TFTP transfer size can be used to re-size the TFTP progress bar on single line based on the server reported file size. The support for this has been around from 2019, but it was never converted to proper Kconfig. While adding this new Kconfig, enable it by default for OMAP2+ and K3 devices also. Signed-off-by: Tero Kristo --- v2: convert to proper Kconfig and add defaults for TI platforms net/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/net/Kconfig b/net/Kconfig index c4b4dae064..ba0ca813ce 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -74,6 +74,17 @@ config TFTP_WINDOWSIZE before an ack response is required. The default TFTP implementation implies a window size of 1. +config TFTP_TSIZE + bool "Track TFTP transfers based on file size option" + depends on CMD_TFTPBOOT + default y if (ARCH_OMAP2PLUS || ARCH_K3) + help + By default, TFTP progress bar is increased for each received UDP + frame, which can lead into long time being spent for sending + data over the UART. Enabling this option, TFTP queries the file + size from server, and if supported, limits the progress bar to + 50 characters total which fits on single line. + config SERVERIP_FROM_PROXYDHCP bool "Get serverip value from Proxy DHCP response" help -- 2.17.1
Re: [PATCH 2/4] tools: mkeficapsule: remove device-tree related operation
On Wed, May 12, 2021 at 04:49:02PM +0900, Masami Hiramatsu wrote:
> Hi Ilias,
>
> 2021年5月12日(水) 16:21 Ilias Apalodimas :
> >
> > Akashi-san,
> >
> > On Wed, May 12, 2021 at 01:57:51PM +0900, AKASHI Takahiro wrote:
> > > As we discussed, "-K" and "-D" options have nothing to do with
> > > creating a capsule file. The same result can be obtained by
> > > using standard commands like:
> > > === signature.dts ===
> > > /dts-v1/;
> > > /plugin/;
> > >
> > > &{/} {
> > > signature {
> > > capsule-key = /incbin/("SIGNER.esl");
> > > };
> > > };
> > > ===
> > > $ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
> > > $ fdtoverlay -i test.dtb -o test_sig.dtb -v signature.dtbo
> > >
> > > So just remove this feature.
> > > (Effectively revert the commit 322c813f4bec ("mkeficapsule: Add support
> > > for embedding public key in a dtb").)
> > >
> > > The same feature is implemented by a shell script (tools/fdtsig.sh).
> >
> >
> > The only reason I can see to keep this, is if mkeficapsule gets included
> > intro distro packages in the future. That would make end users life a bit
> > easier, since they would need a single binary to create the whole
> > CapsuleUpdate sequence.
>
> Hmm, I think it is better to write a manpage of mkeficapsule which
> also describes
> how to embed the key into dtb as in the above example if it is so short.
> Or, distros can package the above shell script with mkeficapsule.
>
> Embedding a key and signing a capsule are different operations but
> using the same tool may confuse users (at least me).
Sure fair enough. I am merely pointing out we need a way to explain all of
those to users.
Thanks!
/Ilias
>
> Thank you,
>
> --
> Masami Hiramatsu
Re: [PATCH] mvebu: x530: Reduce SPL image size
On Wed, May 12, 2021 at 7:18 PM Stefan Roese wrote: > > Currently, building U-Boot for x530 fails since the SPL image is too > big. Currently? It's working for me on master. Are there upcoming mvebu changes that push us over the limit? > This patch reduces the SPL size by changing the following Kconfig > options: > > Enable CONFIG_SPL_TINY_MEMSET > Disable CONFIG_SPI_FLASH_BAR > > By disabling CONFIG_SPI_FLASH_BAR, the tiny SPI NOR framework can be > used. I've got a nagging feeling I needed CONFIG_SPI_FLASH_BAR for some reason. Possibly for some alternate part we were looking at, on the other hand it could also be from the db88f6820-amc board which I based the initial defconfig on. Looking at what CONFIG_SPI_FLASH_BAR does I think we should be safe. We only fit 16MiB parts and aren't likely to start fitting bigger parts unless all the spi-nor vendors decide to stop making ones <16MiB. > > Signed-off-by: Stefan Roese > Cc: Chris Packham > Cc: Pratyush Yadav > Cc: Tom Rini Tested-by: Chris Packham (yes I'm mixing work and personal email addresses. I can re-send tomorrow from the office if that's a concern). > --- > configs/x530_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configs/x530_defconfig b/configs/x530_defconfig > index 890c94b5c1fe..76574c4de4be 100644 > --- a/configs/x530_defconfig > +++ b/configs/x530_defconfig > @@ -62,7 +62,6 @@ CONFIG_SYS_NAND_USE_FLASH_BBT=y > CONFIG_NAND_PXA3XX=y > CONFIG_SF_DEFAULT_BUS=1 > CONFIG_SF_DEFAULT_SPEED=5000 > -CONFIG_SPI_FLASH_BAR=y > CONFIG_SPI_FLASH_MACRONIX=y > CONFIG_SPI_FLASH_STMICRO=y > CONFIG_SPI_FLASH_SST=y > @@ -84,3 +83,4 @@ CONFIG_USB_ETHER_ASIX=y > CONFIG_USB_ETHER_ASIX88179=y > CONFIG_WDT=y > CONFIG_WDT_ORION=y > +CONFIG_SPL_TINY_MEMSET=y > -- > 2.31.1 >
Re: [PATCH 2/4] tools: mkeficapsule: remove device-tree related operation
Hi Ilias,
2021年5月12日(水) 16:21 Ilias Apalodimas :
>
> Akashi-san,
>
> On Wed, May 12, 2021 at 01:57:51PM +0900, AKASHI Takahiro wrote:
> > As we discussed, "-K" and "-D" options have nothing to do with
> > creating a capsule file. The same result can be obtained by
> > using standard commands like:
> > === signature.dts ===
> > /dts-v1/;
> > /plugin/;
> >
> > &{/} {
> > signature {
> > capsule-key = /incbin/("SIGNER.esl");
> > };
> > };
> > ===
> > $ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
> > $ fdtoverlay -i test.dtb -o test_sig.dtb -v signature.dtbo
> >
> > So just remove this feature.
> > (Effectively revert the commit 322c813f4bec ("mkeficapsule: Add support
> > for embedding public key in a dtb").)
> >
> > The same feature is implemented by a shell script (tools/fdtsig.sh).
>
>
> The only reason I can see to keep this, is if mkeficapsule gets included
> intro distro packages in the future. That would make end users life a bit
> easier, since they would need a single binary to create the whole
> CapsuleUpdate sequence.
Hmm, I think it is better to write a manpage of mkeficapsule which
also describes
how to embed the key into dtb as in the above example if it is so short.
Or, distros can package the above shell script with mkeficapsule.
Embedding a key and signing a capsule are different operations but
using the same tool may confuse users (at least me).
Thank you,
--
Masami Hiramatsu
Re: [PATCH v2 00/15] ram: k3-ddrss: Convert k3-j721e to common driver with k3-am64 support
On 11/05/2021 18:21, Dave Gerlach wrote: This is v2 of the series to update the existing k3-j721e driver to a common driver to support both j721e and the new am642 SoC. It renames drivers/ram/k3-j721e to drivers/ram/k3-ddrss and then introduces a refactored common driver with the existing j721e support moved to files named with 32bit and am64 support introduced in files named with 16bit. Changes since v1: * Drop unnecessary error macro re-definitions and use normal errno header * Drop other unnecessary headers that wrap standard kernel headers * Fixed a few camelCase functions that slipped through * Fixed clock initialization sequence based on comment from Vignesh v1: https://lists.denx.de/pipermail/u-boot/2021-May/448716.html Regards, Dave Hi Dave, Thanks for the changes, did a diff between v1 and v2 of these patches and they look good. There is one thing that should maybe fixed sometime in future still, but I am not holding my review based on that. The function prototypes that return error codes should be changed to be int instead of u32, and change all the error return values to be negatives. Right now the driver is using positive values so some piece of code might get confused by that. Just keep it in mind for future improvements. For the whole series (did a quick test run with the latest v4 HSM rearch series also): Reviewed-by: Tero Kristo Tested-by: Tero Kristo Dave Gerlach (14): dt-bindings: memory-controller: Add K3 AM64 DDRSS compatible ram: k3-j721e: lpddr4_address_slice_0_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_0_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_1_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_2_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_3_macros: Fix indentation issues ram: k3-j721e: lpddr4_ddr_controller_macros: Fix indentation issues ram: k3-j721e: lpddr4_phy_core_macros: Fix indentation issues ram: k3-j721e: lpddr4_pi_macros: Fix indentation issues ram: k3-j721e: lpddr4_ctl_regs: Fix checkpatch issue for types ram: k3-j721e: Rename to k3-ddrss ram: k3-ddrss: Introduce top-level CONFIG_K3_DDRSS ram: k3-ddrss: Introduce common driver with J7 SoC support ram: k3-ddrss: Introduce support for AM642 SoCs Lokesh Vutla (1): ram: k3-ddrss: Enable vtt regulator if present board/ti/j721e/Kconfig|4 +- .../memory-controller/k3-j721e-ddrss.txt |3 +- drivers/ram/Kconfig | 24 +- drivers/ram/Makefile |2 +- drivers/ram/k3-ddrss/16bit/lpddr4_16bit_if.h | 108 + .../ram/k3-ddrss/16bit/lpddr4_16bit_obj_if.h | 14 + .../k3-ddrss/16bit/lpddr4_16bit_structs_if.h | 15 + .../16bit/lpddr4_address_slice_0_macros.h | 624 ++ .../16bit/lpddr4_address_slice_1_macros.h | 624 ++ .../16bit/lpddr4_address_slice_2_macros.h | 624 ++ drivers/ram/k3-ddrss/16bit/lpddr4_ctl_regs.h | 1306 +++ .../k3-ddrss/16bit/lpddr4_ctl_regs_rw_masks.h | 23 + .../16bit/lpddr4_data_slice_0_macros.h| 2036 + .../16bit/lpddr4_data_slice_1_macros.h| 2036 + .../16bit/lpddr4_ddr_controller_macros.h | 6436 ++ .../k3-ddrss/16bit/lpddr4_phy_core_macros.h | 1838 drivers/ram/k3-ddrss/16bit/lpddr4_pi_macros.h | 5784 drivers/ram/k3-ddrss/32bit/lpddr4_32bit_if.h | 91 + .../ram/k3-ddrss/32bit/lpddr4_32bit_obj_if.h | 14 + .../k3-ddrss/32bit/lpddr4_32bit_structs_if.h | 15 + .../32bit}/lpddr4_address_slice_0_macros.h| 343 +- drivers/ram/k3-ddrss/32bit/lpddr4_ctl_regs.h | 1545 .../k3-ddrss/32bit/lpddr4_ctl_regs_rw_masks.h | 23 + .../32bit}/lpddr4_data_slice_0_macros.h | 1443 ++- .../32bit}/lpddr4_data_slice_1_macros.h | 1363 ++- .../32bit}/lpddr4_data_slice_2_macros.h | 1363 ++- .../32bit}/lpddr4_data_slice_3_macros.h | 1363 ++- .../32bit/lpddr4_ddr_controller_macros.h | 7792 .../32bit}/lpddr4_phy_core_macros.h | 1397 ++- drivers/ram/k3-ddrss/32bit/lpddr4_pi_macros.h | 5396 drivers/ram/k3-ddrss/Makefile | 17 + drivers/ram/k3-ddrss/cps_drv_lpddr4.h | 102 + .../k3-j721e-ddrss.c => k3-ddrss/k3-ddrss.c} | 289 +- drivers/ram/k3-ddrss/lpddr4.c | 1079 +++ drivers/ram/k3-ddrss/lpddr4.h | 73 + drivers/ram/k3-ddrss/lpddr4_16bit.c | 396 + drivers/ram/k3-ddrss/lpddr4_16bit.h | 33 + .../k3-ddrss/lpddr4_16bit_ctl_regs_rw_masks.c | 1309 +++ drivers/ram/k3-ddrss/lpddr4_16bit_sanity.h| 257 + drivers/ram/k3-ddrss/lpddr4_32bit.c | 302 + drivers/ram/k3-ddrss/lpddr4_32bit.h | 30 + .../k3-ddrss/lpddr4_32bit_ctl_regs_rw_masks.c | 1548 drivers/ram/k3-ddrss/lpddr4_32bit_sanity.h| 223 + drivers/ram/k3-ddrss/lpddr4_if.h | 144 +
Re: [PATCH 2/4] tools: mkeficapsule: remove device-tree related operation
Akashi-san,
On Wed, May 12, 2021 at 01:57:51PM +0900, AKASHI Takahiro wrote:
> As we discussed, "-K" and "-D" options have nothing to do with
> creating a capsule file. The same result can be obtained by
> using standard commands like:
> === signature.dts ===
> /dts-v1/;
> /plugin/;
>
> &{/} {
> signature {
> capsule-key = /incbin/("SIGNER.esl");
> };
> };
> ===
> $ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
> $ fdtoverlay -i test.dtb -o test_sig.dtb -v signature.dtbo
>
> So just remove this feature.
> (Effectively revert the commit 322c813f4bec ("mkeficapsule: Add support
> for embedding public key in a dtb").)
>
> The same feature is implemented by a shell script (tools/fdtsig.sh).
The only reason I can see to keep this, is if mkeficapsule gets included
intro distro packages in the future. That would make end users life a bit
easier, since they would need a single binary to create the whole
CapsuleUpdate sequence.
Regards
/Ilias
[PATCH] mvebu: x530: Reduce SPL image size
Currently, building U-Boot for x530 fails since the SPL image is too big. This patch reduces the SPL size by changing the following Kconfig options: Enable CONFIG_SPL_TINY_MEMSET Disable CONFIG_SPI_FLASH_BAR By disabling CONFIG_SPI_FLASH_BAR, the tiny SPI NOR framework can be used. Signed-off-by: Stefan Roese Cc: Chris Packham Cc: Pratyush Yadav Cc: Tom Rini --- configs/x530_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/x530_defconfig b/configs/x530_defconfig index 890c94b5c1fe..76574c4de4be 100644 --- a/configs/x530_defconfig +++ b/configs/x530_defconfig @@ -62,7 +62,6 @@ CONFIG_SYS_NAND_USE_FLASH_BBT=y CONFIG_NAND_PXA3XX=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_SF_DEFAULT_SPEED=5000 -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_SST=y @@ -84,3 +83,4 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_WDT=y CONFIG_WDT_ORION=y +CONFIG_SPL_TINY_MEMSET=y -- 2.31.1
