[PATCH v2] efi_selftests: fix controllers repeated selftesting
Running the controller selftest more than one times fails with
=> setenv efi_selftest 'controllers' && bootefi selftest
Testing EFI API implementation
Selected test: 'controllers'
Setting up 'controllers'
Setting up 'controllers' succeeded
Executing 'controllers'
Executing 'controllers' succeeded
Summary: 0 failures
=> bootefi selftest
Testing EFI API implementation
Selected test: 'controllers'
Setting up 'controllers'
lib/efi_selftest/efi_selftest_controllers.c(280):
ERROR: InstallProtocolInterface failed
lib/efi_selftest/efi_selftest.c(89):
ERROR: Setting up 'controllers' failed
Summary: 1 failures
There are multiple reason for this. We don't uninstall the binding
interface from the controller handle and we don't reset the handle
pointers either. So let's uninstall all the protocols properly and
reset the handles to NULL on setup().
While at it add a forgotten check when uninstalling protocols from the
handle_controller and make sure the number of child controllers is 0
Signed-off-by: Ilias Apalodimas
---
Changes since v1:
- Move the binding protocol removal to .teardown()
- return EFI_ST_FAILURE if the last count_child_controllers() fails
lib/efi_selftest/efi_selftest_controllers.c | 26 -
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/lib/efi_selftest/efi_selftest_controllers.c
b/lib/efi_selftest/efi_selftest_controllers.c
index d2bbd1c4f65b..79bc86fb0c3a 100644
--- a/lib/efi_selftest/efi_selftest_controllers.c
+++ b/lib/efi_selftest/efi_selftest_controllers.c
@@ -271,6 +271,8 @@ static int setup(const efi_handle_t img_handle,
efi_status_t ret;
boottime = systable->boottime;
+ handle_controller = NULL;
+ handle_driver = NULL;
/* Create controller handle */
ret = boottime->install_protocol_interface(
@@ -402,14 +404,36 @@ static int execute(void)
/* Check number of child controllers */
ret = count_child_controllers(handle_controller, &guid_controller,
&count);
- if (ret == EFI_SUCCESS)
+ if (ret == EFI_SUCCESS || count != 0) {
efi_st_error("Uninstall failed\n");
+ return EFI_ST_FAILURE;
+ }
+
+
return EFI_ST_SUCCESS;
}
+ /*
+ * Tear down unit test.
+ *
+ */
+static int teardown(void)
+{
+ efi_status_t ret;
+ /* Uninstall binding protocol */
+ ret = boottime->uninstall_protocol_interface(handle_driver,
+
&guid_driver_binding_protocol,
+&binding_interface);
+ if (ret != EFI_SUCCESS)
+ efi_st_error("Failed to uninstall protocols\n");
+
+ return ret;
+}
+
EFI_UNIT_TEST(controllers) = {
.name = "controllers",
.phase = EFI_EXECUTE_BEFORE_BOOTTIME_EXIT,
.setup = setup,
.execute = execute,
+ .teardown = teardown,
};
--
2.39.2
Re: [PATCH] riscv: add backtrace support
On 5/25/23 4:05 AM, Ben Dooks wrote: On 15/05/2023 14:03, Ben Dooks wrote: When debugging, it is useful to have a backtrace to find out what is in the call stack as the previous function (RA) may not have been the culprit. Since this adds size to the build, do not add it by default and avoid putting it in the SPL build if not needed. Hi, has anyone had time to review this? Hi Ben, this looks really useful. I'd like to use it in SPL, but I'm unable to enable CONFIG_SPL_FRAMEPOINTER=y. It's likely that you need to add a SPL_FRAMEPOINTER entry to Kconfig as well.
Re: [PATCH] watchdog: versal: Use new compatible xlnx,versal-wwdt
On 6/13/23 13:22, Michal Simek wrote:
DT binding has been approved that's why use new compatible string.
The old one is mark as deprecated and should be removed after some
releases.
Link: https://lore.kernel.org/r/20230420104231.2243079-3-srinivas.ne...@amd.com/
Signed-off-by: Michal Simek
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/watchdog/xilinx_wwdt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/xilinx_wwdt.c b/drivers/watchdog/xilinx_wwdt.c
index d582e3cc8f41..8b6fc30edbe3 100644
--- a/drivers/watchdog/xilinx_wwdt.c
+++ b/drivers/watchdog/xilinx_wwdt.c
@@ -191,7 +191,8 @@ static const struct wdt_ops xlnx_wwdt_ops = {
};
static const struct udevice_id xlnx_wwdt_ids[] = {
- { .compatible = "xlnx,versal-wwdt-1.0", },
+ { .compatible = "xlnx,versal-wwdt", },
+ { .compatible = "xlnx,versal-wwdt-1.0", }, /* deprecated */
{},
};
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
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 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
On Wed, Jun 14, 2023 at 10:56:23AM +0530, Sughosh Ganu wrote:
> hi Takahiro,
>
> On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi
> wrote:
> >
> > Hi Sughosh,
> >
> > I think this is a good extension to mkeficapsule, but
> >
> > On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
> > > Add support for specifying the parameters needed for capsule
> > > generation through a config file, instead of passing them through
> > > command-line. Parameters for more than a single capsule file can be
> > > specified, resulting in generation of multiple capsules through a
> > > single invocation of the command.
> > >
> > > This path is to be used for generating capsules through a make target,
> > > with the parameters being parsed from the config file.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > tools/Kconfig | 9 +
> > > tools/Makefile | 1 +
> > > tools/eficapsule.h | 110
> > > tools/mkeficapsule.c | 106 +++-
> > > tools/mkeficapsule_parse.c | 345 +
> > > 5 files changed, 531 insertions(+), 40 deletions(-)
> > > create mode 100644 tools/mkeficapsule_parse.c
> > >
> > > diff --git a/tools/Kconfig b/tools/Kconfig
> > > index 539708f277..95f27b7c45 100644
> > > --- a/tools/Kconfig
> > > +++ b/tools/Kconfig
> > > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
> > > optionally sign that file. If you want to enable UEFI capsule
> > > update feature on your target, you certainly need this.
> > >
> > > +config EFI_CAPSULE_CFG_FILE
> > > + string "Path to the EFI Capsule Config File"
> > > + default ""
> > > + help
> > > + Path to the EFI capsule config file which provides the
> > > + parameters needed to build capsule(s). Parameters can be
> > > + provided for multiple payloads resulting in corresponding
> > > + capsule images being generated.
> > > +
> > > menuconfig FSPI_CONF_HEADER
> > > bool "FlexSPI Header Configuration"
> > > help
> > > diff --git a/tools/Makefile b/tools/Makefile
> > > index d793cf3bec..ef366f3d61 100644
> > > --- a/tools/Makefile
> > > +++ b/tools/Makefile
> > > @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
> > > HOSTLDLIBS_mkeficapsule += \
> > > $(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
> > > hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> > > +mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
> > >
> > > # We build some files with extra pedantic flags to try to minimize things
> > > # that won't build on some weird host compiler -- though there are lots
> > > of
> > > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > > index 072a4b5598..42e66c6d6a 100644
> > > --- a/tools/eficapsule.h
> > > +++ b/tools/eficapsule.h
> > > @@ -52,6 +52,38 @@ typedef struct {
> > > /* flags */
> > > #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
> > >
> > > +enum capsule_type {
> > > + CAPSULE_NORMAL_BLOB = 0,
> > > + CAPSULE_ACCEPT,
> > > + CAPSULE_REVERT,
> > > +};
> > > +
> > > +/**
> > > + * struct efi_capsule_params - Capsule parameters
> > > + * @image_guid: Guid value of the payload input image
> > > + * @image_index: Image index value
> > > + * @hardware_instance: Hardware instance to be used for the image
> > > + * @monotonic_count: Monotonic count value to be used for signed capsule
> > > + * @privkey_file: Path to private key used in capsule signing
> > > + * @cert_file: Path to public key certificate used in capsule signing
> > > + * @input_file: Path to payload input image
> > > + * @capsule_file: Path to the output capsule file
> > > + * @oemflags: Oemflags to be populated in the capsule header
> > > + * @capsule: Capsule Type, normal or accept or revert
> > > + */
> > > +struct efi_capsule_params {
> > > + efi_guid_t *image_guid;
> > > + unsigned long image_index;
> > > + unsigned long hardware_instance;
> > > + uint64_t monotonic_count;
> > > + char *privkey_file;
> > > + char *cert_file;
> > > + char *input_file;
> > > + char *capsule_file;
> > > + unsigned long oemflags;
> > > + enum capsule_type capsule;
> > > +};
> > > +
> > > struct efi_capsule_header {
> > > efi_guid_t capsule_guid;
> > > uint32_t header_size;
> > > @@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
> > > struct win_certificate_uefi_guid auth_info;
> > > } __packed;
> > >
> > > +/**
> > > + * capsule_with_cfg_file() - Generate capsule from config file
> > > + * @cfg_file: Path to the config file
> > > + *
> > > + * Parse the capsule parameters from the config file and use the
> > > + * parameters for generating one or more capsules.
> > > + *
> > > + * Return: None
> > > + *
> > > + */
> > > +void capsule_with_cfg_file(const char *cfg_file);
> > > +
> > > +/**
> > > + * convert_uuid_to_guid() - convert UUID to GUID
> > > + * @buf: UUID binary
> > > + *
> > > + * UUID and GUID have the
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Takahiro,
On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi
wrote:
>
> Hi Sughosh,
>
> I think this is a good extension to mkeficapsule, but
>
> On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
> > Add support for specifying the parameters needed for capsule
> > generation through a config file, instead of passing them through
> > command-line. Parameters for more than a single capsule file can be
> > specified, resulting in generation of multiple capsules through a
> > single invocation of the command.
> >
> > This path is to be used for generating capsules through a make target,
> > with the parameters being parsed from the config file.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > tools/Kconfig | 9 +
> > tools/Makefile | 1 +
> > tools/eficapsule.h | 110
> > tools/mkeficapsule.c | 106 +++-
> > tools/mkeficapsule_parse.c | 345 +
> > 5 files changed, 531 insertions(+), 40 deletions(-)
> > create mode 100644 tools/mkeficapsule_parse.c
> >
> > diff --git a/tools/Kconfig b/tools/Kconfig
> > index 539708f277..95f27b7c45 100644
> > --- a/tools/Kconfig
> > +++ b/tools/Kconfig
> > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
> > optionally sign that file. If you want to enable UEFI capsule
> > update feature on your target, you certainly need this.
> >
> > +config EFI_CAPSULE_CFG_FILE
> > + string "Path to the EFI Capsule Config File"
> > + default ""
> > + help
> > + Path to the EFI capsule config file which provides the
> > + parameters needed to build capsule(s). Parameters can be
> > + provided for multiple payloads resulting in corresponding
> > + capsule images being generated.
> > +
> > menuconfig FSPI_CONF_HEADER
> > bool "FlexSPI Header Configuration"
> > help
> > diff --git a/tools/Makefile b/tools/Makefile
> > index d793cf3bec..ef366f3d61 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
> > HOSTLDLIBS_mkeficapsule += \
> > $(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
> > hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> > +mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
> >
> > # We build some files with extra pedantic flags to try to minimize things
> > # that won't build on some weird host compiler -- though there are lots of
> > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > index 072a4b5598..42e66c6d6a 100644
> > --- a/tools/eficapsule.h
> > +++ b/tools/eficapsule.h
> > @@ -52,6 +52,38 @@ typedef struct {
> > /* flags */
> > #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
> >
> > +enum capsule_type {
> > + CAPSULE_NORMAL_BLOB = 0,
> > + CAPSULE_ACCEPT,
> > + CAPSULE_REVERT,
> > +};
> > +
> > +/**
> > + * struct efi_capsule_params - Capsule parameters
> > + * @image_guid: Guid value of the payload input image
> > + * @image_index: Image index value
> > + * @hardware_instance: Hardware instance to be used for the image
> > + * @monotonic_count: Monotonic count value to be used for signed capsule
> > + * @privkey_file: Path to private key used in capsule signing
> > + * @cert_file: Path to public key certificate used in capsule signing
> > + * @input_file: Path to payload input image
> > + * @capsule_file: Path to the output capsule file
> > + * @oemflags: Oemflags to be populated in the capsule header
> > + * @capsule: Capsule Type, normal or accept or revert
> > + */
> > +struct efi_capsule_params {
> > + efi_guid_t *image_guid;
> > + unsigned long image_index;
> > + unsigned long hardware_instance;
> > + uint64_t monotonic_count;
> > + char *privkey_file;
> > + char *cert_file;
> > + char *input_file;
> > + char *capsule_file;
> > + unsigned long oemflags;
> > + enum capsule_type capsule;
> > +};
> > +
> > struct efi_capsule_header {
> > efi_guid_t capsule_guid;
> > uint32_t header_size;
> > @@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
> > struct win_certificate_uefi_guid auth_info;
> > } __packed;
> >
> > +/**
> > + * capsule_with_cfg_file() - Generate capsule from config file
> > + * @cfg_file: Path to the config file
> > + *
> > + * Parse the capsule parameters from the config file and use the
> > + * parameters for generating one or more capsules.
> > + *
> > + * Return: None
> > + *
> > + */
> > +void capsule_with_cfg_file(const char *cfg_file);
> > +
> > +/**
> > + * convert_uuid_to_guid() - convert UUID to GUID
> > + * @buf: UUID binary
> > + *
> > + * UUID and GUID have the same data structure, but their binary
> > + * formats are different due to the endianness. See lib/uuid.c.
> > + * Since uuid_parse() can handle only UUID, this function must
> > + * be called to get correct data for GUID when parsing a string.
> > + *
> > + * The correct data will be returned in @buf.
> > + */
> > +v
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
Hi Sughosh,
I think this is a good extension to mkeficapsule, but
On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
> Add support for specifying the parameters needed for capsule
> generation through a config file, instead of passing them through
> command-line. Parameters for more than a single capsule file can be
> specified, resulting in generation of multiple capsules through a
> single invocation of the command.
>
> This path is to be used for generating capsules through a make target,
> with the parameters being parsed from the config file.
>
> Signed-off-by: Sughosh Ganu
> ---
> tools/Kconfig | 9 +
> tools/Makefile | 1 +
> tools/eficapsule.h | 110
> tools/mkeficapsule.c | 106 +++-
> tools/mkeficapsule_parse.c | 345 +
> 5 files changed, 531 insertions(+), 40 deletions(-)
> create mode 100644 tools/mkeficapsule_parse.c
>
> diff --git a/tools/Kconfig b/tools/Kconfig
> index 539708f277..95f27b7c45 100644
> --- a/tools/Kconfig
> +++ b/tools/Kconfig
> @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
> optionally sign that file. If you want to enable UEFI capsule
> update feature on your target, you certainly need this.
>
> +config EFI_CAPSULE_CFG_FILE
> + string "Path to the EFI Capsule Config File"
> + default ""
> + help
> + Path to the EFI capsule config file which provides the
> + parameters needed to build capsule(s). Parameters can be
> + provided for multiple payloads resulting in corresponding
> + capsule images being generated.
> +
> menuconfig FSPI_CONF_HEADER
> bool "FlexSPI Header Configuration"
> help
> diff --git a/tools/Makefile b/tools/Makefile
> index d793cf3bec..ef366f3d61 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
> HOSTLDLIBS_mkeficapsule += \
> $(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
> hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> +mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
>
> # We build some files with extra pedantic flags to try to minimize things
> # that won't build on some weird host compiler -- though there are lots of
> diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> index 072a4b5598..42e66c6d6a 100644
> --- a/tools/eficapsule.h
> +++ b/tools/eficapsule.h
> @@ -52,6 +52,38 @@ typedef struct {
> /* flags */
> #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
>
> +enum capsule_type {
> + CAPSULE_NORMAL_BLOB = 0,
> + CAPSULE_ACCEPT,
> + CAPSULE_REVERT,
> +};
> +
> +/**
> + * struct efi_capsule_params - Capsule parameters
> + * @image_guid: Guid value of the payload input image
> + * @image_index: Image index value
> + * @hardware_instance: Hardware instance to be used for the image
> + * @monotonic_count: Monotonic count value to be used for signed capsule
> + * @privkey_file: Path to private key used in capsule signing
> + * @cert_file: Path to public key certificate used in capsule signing
> + * @input_file: Path to payload input image
> + * @capsule_file: Path to the output capsule file
> + * @oemflags: Oemflags to be populated in the capsule header
> + * @capsule: Capsule Type, normal or accept or revert
> + */
> +struct efi_capsule_params {
> + efi_guid_t *image_guid;
> + unsigned long image_index;
> + unsigned long hardware_instance;
> + uint64_t monotonic_count;
> + char *privkey_file;
> + char *cert_file;
> + char *input_file;
> + char *capsule_file;
> + unsigned long oemflags;
> + enum capsule_type capsule;
> +};
> +
> struct efi_capsule_header {
> efi_guid_t capsule_guid;
> uint32_t header_size;
> @@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
> struct win_certificate_uefi_guid auth_info;
> } __packed;
>
> +/**
> + * capsule_with_cfg_file() - Generate capsule from config file
> + * @cfg_file: Path to the config file
> + *
> + * Parse the capsule parameters from the config file and use the
> + * parameters for generating one or more capsules.
> + *
> + * Return: None
> + *
> + */
> +void capsule_with_cfg_file(const char *cfg_file);
> +
> +/**
> + * convert_uuid_to_guid() - convert UUID to GUID
> + * @buf: UUID binary
> + *
> + * UUID and GUID have the same data structure, but their binary
> + * formats are different due to the endianness. See lib/uuid.c.
> + * Since uuid_parse() can handle only UUID, this function must
> + * be called to get correct data for GUID when parsing a string.
> + *
> + * The correct data will be returned in @buf.
> + */
> +void convert_uuid_to_guid(unsigned char *buf);
> +
> +/**
> + * create_empty_capsule() - Generate an empty capsule
> + * @path: Path to the empty capsule file to be generated
> + * @guid: Guid value of the image for which empty capsule is generated
> + * @fw_accept: Flag to specify whether to generate accept or
Re: [PATCH 2/3] riscv: clint: Update the sifive clint ipi driver to support aclint
> From: Bin Meng > Sent: Monday, June 12, 2023 3:36 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > > Subject: [PATCH 2/3] riscv: clint: Update the sifive clint ipi driver to > support aclint > > This RISC-V ACLINT specification [1] defines a set of memory mapped devices > which provide inter-processor interrupts (IPI) and timer functionalities for > each HART on a multi-HART RISC-V platform. > > The RISC-V ACLINT specification is defined to be backward compatible with the > SiFive CLINT specification, however the device tree binding is a new one. > This change updates the sifive clint ipi driver to support ACLINT mswi > device, by checking the per-driver data field of the ACLINT mtimer driver to > determine whether a syscon based approach needs to be taken to get the base > address of the ACLINT mswi device. > > [1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc > > Signed-off-by: Bin Meng LGTM. Thanks, Rick
Re: [RFC] disable NFS support by default
On Wed, Jun 14, 2023 at 2:41 AM Tom Rini wrote: > > On Tue, Jun 13, 2023 at 11:52:16AM +0100, Peter Robinson wrote: > > > While NFS is widely used in data centres, and private > > networks it's quite a nuanced usecase for device firmware. > > A lot of devices already disable it. > > > > Various network protocols should really be opt in, not opt > > out, because they add extra size and are potential attack > > vectors from a security PoV. In the NFS case it doesn't > > really make sense for a lot of devices like tables, SBCs etc. > > It's also something we don't really want for SystemReady-IR > > due to security concerns. > > > > Signed-off-by: Peter Robinson > > --- > > > > This is a RFC to start a discussion around things like NFS, > > with the addistion of old protocols like NFSv1 that were never > > publicly released [1] we really shouldn't be enabling this by > > default. > > > > I am aware it will likely break the functionality for users > > that do use the various versions of NFS but it's straight forward > > to add CMD_NFS as an explicit config. It's for this reason I > > label the patch as RFC. > > > > There was about a 5Kb saving here when I tested a build with > > pinebook-pro-rk3399. > > > > Peter > > > > [1] https://en.wikipedia.org/wiki/Network_File_System > [snip] > > This is probably fine, honestly. I don't see any environments that > default to making use of NFS within U-Boot (which is not the same as > nfsroot for Linux, which a number of platforms have options for by > default). > How about changing config CMD_NFS bool "nfs" default y help Boot image via network using NFS protocol. To default n ? Regards, Bin
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
Hi Xavier, On Tue, 13 Jun 2023 at 17:04, Xavier Drudis Ferran wrote: > > El Tue, Jun 13, 2023 at 03:58:22PM +0100, Simon Glass deia: > > > > Yes that's right. So 'usb info' should ignore UCLASS_BOOTDEV devices. > > That's a possibility, yes. It should work until someone adds another > device there for some other purpose. > > > That is better than checking for the NULL pointer. > > > > Why? What's wrong about checking for null ? > Or maybe checking for both not null and not UCLASS_BOOTDEV ? > > Not that I care too much, just to understand your reasoning. Well, devices may have something attached there, so it may be non-NULL, but point to a different struct from the expected one. > > Or can we check for recursible devices somehow ? > Maybe flag them or something ? > > Why is better to state all devices are recursible except some UCLASSes > (meaning they can have stuff that needs listed in usb info - or > likewise usb tree -) instead of stating that some closed set are > recursible ? > For USB we can have lots of different types of devices as children, so it would be a pain to enumerate them all. At least that's how I see it. Regards, Simon
Re: [PATCH v2] sandbox: fix a compilation error
Hi, On Tue, 13 Jun 2023 at 18:33, Tom Rini wrote: > > On Tue, Jun 13, 2023 at 07:05:52PM +0300, Sergei Antonov wrote: > > On Tue, 13 Jun 2023 at 17:58, Simon Glass wrote: > > > The problem with this is it then cannot be built on non-sandbox > > > boards. I think v1 was OK. > > > > Before the patch as well as after the patch: > > if CONFIG_SANDBOX_SDL > > declaration of sandbox_sdl_set_bpp() > > else > > definition of sandbox_sdl_set_bpp() returning error > > end > > This patch only moves code to another header file in > > arch/sandbox/include/asm. > > How can a non-sandbox build fail because of this patch? > > Right, test/dm/video.c is for sandbox-only. OK, yes. Reviewed-by: Simon Glass Regards, Simon
Re: Pull request for tpm-for_tom-13062023
On Tue, Jun 13, 2023 at 11:02:53AM +0300, Ilias Apalodimas wrote: > Hi Tom, > > The following changes since commit 260d4962e06c0a7d2713523c131416a3f70d7f2c: > > Merge tag v2023.07-rc4 into next (2023-06-12 14:55:33 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-tpm/ > tags/tpm-for_tom-13062023 > > for you to fetch changes up to 011f015540d788227a1a2d16dd6245120827bdec: > > test/py: Account PCR updates properly during testing (2023-06-13 08:51:07 > +0300) > > The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/16574 > showed no issues > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 1/1] doc: man-page for imxtract
Provide a man-page for the imxtract command. Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/imxtract.rst | 81 ++ doc/usage/index.rst| 1 + 2 files changed, 82 insertions(+) create mode 100644 doc/usage/cmd/imxtract.rst diff --git a/doc/usage/cmd/imxtract.rst b/doc/usage/cmd/imxtract.rst new file mode 100644 index 00..eb64b1cefa --- /dev/null +++ b/doc/usage/cmd/imxtract.rst @@ -0,0 +1,81 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +imxtract command + + +Synopsis + + +:: + +imxtract addr part [dest] +imxtract addr uname [dest] + +Description +--- + +The imxtract command is used to extract a part of a multi-image file. + +Two different file formats are supported: + +* FIT images +* legacy U-Boot images + +addr +Address of the multi-image file from which a part shall be extracted + +part +Index (hexadecimal) of the part of a legacy U-Boot image to be extracted + +uname +Name of the part of a FIT image to be extracted + +dest +Destination address (defaults to 0x0) + +The value of environment variable *verify* controls if the hashes and +signatures of FIT images or the check sums of legacy U-Boot images are checked. +To enable checking set *verify* to one of the values *1*, *yes*, *true*. +(Actually only the first letter is checked disregarding the case.) + +To list the parts of an image the *iminfo* command can be used. + +Examples + + +With verify=no incorrect hashes, signatures, or check sums don't stop the +extraction. But correct hashes are still indicated in the output +(here: md5, sha1). + +.. code-block:: console + +=> setenv verify no +=> imxtract $loadaddr kernel-1 $kernel_addr_r +## Copying 'kernel-1' subimage from FIT image at 4020 ... +md5+ sha1+Loading part 0 ... OK +=> + +With verify=yes incorrect hashes, signatures, or check sums stop the extraction. + +.. code-block:: console + +=> setenv verify yes +=> imxtract $loadaddr kernel-1 $kernel_addr_r +## Copying 'kernel-1' subimage from FIT image at 4020 ... +md5 error! +Bad hash value for 'hash-1' hash node in 'kernel-1' image node +Bad Data Hash +=> + +Configuration +- + +The imxtract command is only available if CONFIG_CMD_XIMG=y. Support for FIT +images requires CONFIG_FIT=y. Support for legacy U-Boot images requires +CONFIG_LEGACY_IMAGE_FORMAT=y. + +Return value + + +On success the return value $? of the command is 0 (true). On failure the +return value is 1 (false). diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 84ef8a9a42..54ef89edb2 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -62,6 +62,7 @@ Shell commands cmd/fwu_mdata cmd/gpio cmd/host + cmd/imxtract cmd/load cmd/loadb cmd/loadm -- 2.40.1
Re: [PATCH v6 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support
On Tue, Jun 13, 2023 at 04:38:47PM +, Tom Warren wrote: > Svyatoslav, > > I've got your V6 patches applied, and buildman tegra is OK. I've never run > the CI tests before, so I'll have to look into that. I'll update > u-boot-tegra/master TOT today, though. > > TomR & Simon - I'm retiring the first week in July, so I won't be the Tegra > custodian going forward - we've yet to assign that job to another engineer > here, hopefully that'll get done before I leave & you can help them get > up-to-speed on custodial duties w/the Tegra repo, if needed. Ah, OK. Thanks for all your hard work over the years! > > Tom > > -Original Message- > From: Svyatoslav Ryhel > Sent: Tuesday, June 13, 2023 2:51 AM > To: Tom Warren > Cc: u-boot@lists.denx.de; Tom Rini ; Simon Glass > ; Svyatoslav Ryhel > Subject: Re: [PATCH v6 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support > > External email: Use caution opening links or attachments > > > 9 червня 2023 р. 07:34:41 GMT+03:00, Svyatoslav Ryhel > написав(-ла): > >This patchset adds support for native use of U-Boot on: > >- ASUS T30 Transformers (7 devices, all models); > >- ASUS/Google Nexus 7 (2012), both grouper and tilapia > >- LG Optimus 4X HD (P880) and Optimus Vu (P895) > >- HTC One X (endeavoru) > >as a replacement for the vendor bootloader. > > > >Current commits are designed to work on re-crypted devices but can be > >used on clean unmodified devices with slight restrictions (like no > >booting/mounting emmc and no self updating feature). > > > >All device setup commits fall under the same pattern. Alongside device > >bringup tegra requires few small patches: > > - add gpio keyboard as stdin device > > - make networking boot options optional > > - add a small tool to generate SoC UID > > > >Commits passed ./tools/buildman/buildman tegra Building current source > >for 30 boards (12 threads, 1 job per thread) > > 3000 /30 0:00:06 : apalis_t30 > >Completed: 30 total built, 30 newly), duration 0:05:23, rate 0.09 > > > >Passed 50/53 GitLab CI Pipelines and then I ran off CI minures. > > > >--- > >Changes from v5: > >- fixed maintained files inclusion > > > >Changes from v4: > >- fixed documentation > >- fixed CONFIG_* definitions > > > >Changes from v3: > >- extended amount of devices supported > > > >Changes from v2: > > - fuse build is excluded for T186 (it is not supported in it anyway) > > > >Changes from v1: > > - fix fuse headers for newer Tegra generations > > - allow grouper_common_defconfig to pass without fragments > >--- > > > >Jonas Schwöbel (1): > > configs: tegra-common-post: make PXE and DHCP boot targets optional > > > >Svyatoslav Ryhel (6): > > configs: tegra-common-post: add GPIO keyboard as STDIN device > > ARM: tegra: add SoC UID calculation function > > board: asus: transformer: add ASUS Transformer T30 family support > > board: asus: grouper: add Google Nexus 7 (2012) support > > board: lg: x3: add Optimus 4X HD and Optimus Vu support > > board: htc: endeavoru: add One X support > > > > arch/arm/dts/Makefile | 12 + > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 157 ++ > > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 43 ++ > > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 36 ++ > > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 62 +++ > > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 + > > arch/arm/dts/tegra30-asus-tf201.dts | 9 + > > arch/arm/dts/tegra30-asus-tf300t.dts | 18 + > > arch/arm/dts/tegra30-asus-tf300tg.dts | 9 + > > arch/arm/dts/tegra30-asus-tf300tl.dts | 9 + > > arch/arm/dts/tegra30-asus-tf600t.dts | 89 > > arch/arm/dts/tegra30-asus-tf700t.dts | 13 + > > arch/arm/dts/tegra30-asus-transformer.dtsi| 211 > > arch/arm/dts/tegra30-htc-endeavoru.dts| 166 +++ > > arch/arm/dts/tegra30-lg-p880.dts | 40 ++ > > arch/arm/dts/tegra30-lg-p895.dts | 50 ++ > > arch/arm/dts/tegra30-lg-x3.dtsi | 180 +++ > > arch/arm/include/asm/arch-tegra/fuse.h| 7 + > > arch/arm/mach-tegra/Makefile | 4 + > > arch/arm/mach-tegra/fuse.c| 151 ++ > > arch/arm/mach-tegra/tegra30/Kconfig | 20 + > > board/asus/grouper/Kconfig| 22 + > > board/asus/grouper/MAINTAINERS| 10 + > > board/asus/grouper/Makefile | 14 + > > board/asus/grouper/grouper-spl-max.c | 45 ++ > > board/asus/grouper/grouper-spl-ti.c | 41 ++ > > board/asus/grouper/grouper.c | 202 > > board/asus/grouper/pinmux-config-grouper.h| 362 ++ > > board/asus/transformer-t30/Kconfig| 23 + > > board/asus/transformer-t30/MAINTAINERS| 15 + > > board/asus/transformer-t30/Makefile | 11 + > > .../pinmux-config-transformer.h | 365 ++ > > .../t
Re: [PATCH v2 5/5] rockchip: rockpro64: Build u-boot-rockchip-spi.bin
Hi Peter, On 2023-06-13 09:58, Peter Robinson wrote: > On Mon, Jun 12, 2023 at 11:20 PM Jonas Karlman wrote: >> >> Hi Peter, >> >> On 2023-06-11 22:22, Peter Robinson wrote: >>> Hi Jonas, >>> >>> This regresses the Rockpro64 build for me when building with gcc 12/13 >>> with the following error, if I remove CONFIG_LTO it builds, but >>> overlaps. >>> >>> /usr/bin/aarch64-linux-gnu-ld: >>> /usr/lib/gcc/aarch64-linux-gnu/13/libgcc.a(lse-init.o): in function >>> `init_have_lse_atomics': >>> /builddir/build/BUILD/gcc-13.1.1-20230519/aarch64-linux-gnu/aarch64-linux-gnu/libgcc/../../../gcc-13.1.1-20230519/libgcc/config/aarch64/lse-init.c:46: >>> undefined reference to `__getauxval' >>> collect2: fatal error: ld terminated with signal 11 [Segmentation >>> fault], core dumped >>> compilation terminated. >> >> Interesting, my test build using ubuntu-22.04 and gcc-12 did not seem >> to fail, see [1]. Compiling with -mno-outline-atomics flag may work, not >> sure that is a good workaround. > > I would prefer a fix. Not sure what such fix could be, cross compiling in CI and under ubuntu 22.04 does not trigger this linking issue, not sure what is different in your build environment to not allow build with CONFIG_LTO=y. Searching for similar linking issue suggest it could be related to outline-atomics, do you use any special C/LDFLAGS or similar? > >> An alternative could be to move the payload to @ 512KB instead of @ 384KB. > > What impact will moving this around have on upgrades? I am not sure we > should be randomly moving stuff without knowing the impact TBH. Will > this break existing users vs what you feel is appropriate for your > usecase? I did a re-calculation and using @ 512 KB offset may not be enough for a worst-case scenario. mkimage will enforce a 184 KB limit for the TPL on RK3399. With SPL loaded at 0x0 and TF-A loaded to 0x4, we have a 256 KB size limit of SPL. BootRom that loads both TPL and SPL only read first 2 KB of every 4 KB page of SPI flash, so idbloader.img (TPL+SPL) could grow up to ~880 KB in a worst-case scenario. (184+256) x 2 = 880 Using a payload offset of @ 896 KB (0xE) is probably the safest default option if we need to revert the CONFIG_LTO=y change. As long as u-boot-rockchip-spi.bin is used to update SPI flash changing offset should not have an impact. However, there are guides and scripts that write idbloader.img and u-boot.itb separately, those could break. Such guides and scripts can already lead to users overwriting part of SPL when the produced idbloader.img is over 384 KB in size. With CONFIG_ROCKCHIP_SPI_IMAGE=y the size of idbloader.img is instead enforced to not cause an overlap of the u-boot.itb at build time. Regards, Jonas > >> configs/rockpro64-rk3399_defconfig: >> CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 >> >> arch/arm/dts/rk3399-rockpro64-u-boot.dtsi: >> u-boot,spl-payload-offset = <0x8>; >> >> >> [1] >> https://github.com/Kwiboo/u-boot-build/actions/runs/5248398191/jobs/9479827969 >> >> Regards, >> Jonas >> >>> >>> Peter >>> >>> On Wed, May 17, 2023 at 7:41 PM Jonas Karlman wrote: Enable CONFIG_ROCKCHIP_SPI_IMAGE to build u-boot-rockchip-spi.bin. Define CONFIG_SYS_SPI_U_BOOT_OFFS to write u-boot.itb at the expected offset. Enable CONFIG_LTO to reduce size of SPL so that the mkimage output fit before the 0x6 offset in u-boot-rockchip-spi.bin. => sf probe SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load mmc 1:1 1000 u-boot-rockchip-spi.bin 1442304 bytes read in 27 ms (50.9 MiB/s) => sf update $fileaddr 0 $filesize device 0 offset 0x0, size 0x160200 1421824 bytes written, 20480 bytes skipped in 9.501s, speed 155432 B/s Signed-off-by: Jonas Karlman Reviewed-by: Kever Yang --- v2: - Collect r-b tag configs/rockpro64-rk3399_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig index 0ca2cecade25..f41c03067903 100644 --- a/configs/rockpro64-rk3399_defconfig +++ b/configs/rockpro64-rk3399_defconfig @@ -11,6 +11,7 @@ CONFIG_ENV_OFFSET=0x3F8000 CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64" CONFIG_DM_RESET=y CONFIG_ROCKCHIP_RK3399=y +CONFIG_ROCKCHIP_SPI_IMAGE=y CONFIG_TARGET_ROCKPRO64_RK3399=y CONFIG_SPL_STACK=0x40 CONFIG_DEBUG_UART_BASE=0xFF1A @@ -20,6 +21,7 @@ CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_PCI=y CONFIG_DEBUG_UART=y +CONFIG_LTO=y CONFIG_SPL_FIT_SIGNATURE=y CONFIG_BOOTSTAGE=y CONFIG_BOOTSTAGE_REPORT=y @@ -37,6 +39,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 CONFIG_TPL=y CONFIG_CMD_BOOTZ=y >
Re: [PATCH v2 4/4] net: add NFSv1 support
On Tue, Jun 13, 2023 at 12:24:44PM +0100, Peter Robinson wrote: > > > To clarify a fact: I am happy with the patch. I am unhappy with the > > > wrong "naming" that my old > > > employer used and influenced this patch. Also the company is shipping > > > thousands of devices per > > > year where these patches are used. > > > > Further clean-ups and clarifications to the support here in terms of > > what it does and doesn't provide are good. But to the point on reviews, > > yes, I do wish we had more people interested in various areas, and with > > time to devote to reviewing code as well. Sadly, we don't always, and I > > took this particular set of patches as being small enough of a global > > impact while (hopefully!) making future contributions both in this area > > and the related platforms using it more likely. > > I understand your sentiment but even feedback for things like having > it behind a Kconfig option to opt into, especially for a default on > option, and CI weren't even addressed, it was just landed without > additional revisions. I feel some of those negate the "just land it" > sentiment. I went back and forth on if it should get a Kconfig option, but the size increase was very small (200-300 bytes) which is below the "gate this for size" reasons. I have a harder time with "gate this for security reasons" when "go modify memory however you want" is a default enabled command, and if you're already using NFS in your bootloader you had better have already taken some precautions. But I'm also agreeable with your RFC to disable NFS command by default. > > Peter -- Tom signature.asc Description: PGP signature
Re: [RFC] disable NFS support by default
On Tue, Jun 13, 2023 at 11:52:16AM +0100, Peter Robinson wrote: > While NFS is widely used in data centres, and private > networks it's quite a nuanced usecase for device firmware. > A lot of devices already disable it. > > Various network protocols should really be opt in, not opt > out, because they add extra size and are potential attack > vectors from a security PoV. In the NFS case it doesn't > really make sense for a lot of devices like tables, SBCs etc. > It's also something we don't really want for SystemReady-IR > due to security concerns. > > Signed-off-by: Peter Robinson > --- > > This is a RFC to start a discussion around things like NFS, > with the addistion of old protocols like NFSv1 that were never > publicly released [1] we really shouldn't be enabling this by > default. > > I am aware it will likely break the functionality for users > that do use the various versions of NFS but it's straight forward > to add CMD_NFS as an explicit config. It's for this reason I > label the patch as RFC. > > There was about a 5Kb saving here when I tested a build with > pinebook-pro-rk3399. > > Peter > > [1] https://en.wikipedia.org/wiki/Network_File_System [snip] This is probably fine, honestly. I don't see any environments that default to making use of NFS within U-Boot (which is not the same as nfsroot for Linux, which a number of platforms have options for by default). -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/1] virtio: add driver for virtio_console devices
On 2023/6/9 17:27, Bin Meng wrote: Hi, On Tue, Jun 6, 2023 at 9:26 PM Ying-Chun Liu (PaulLiu) wrote: This is an implementation of single-character virtio-console. Part of the patch is based on barebox implementations. To test the patch, we can build qemu_arm64_defconfig target. Enable CONFIG_VIRTIO_CONSOLE. And run qemu-system-aarch64 with -device virtio-serial-pci,id=virtio-serial0 \ -chardev file,id=charconsole0,path=/tmp/serialconsolelog \ -device virtconsole,chardev=charconsole0,id=console0 \ With this command, it still uses the on-board UART but not virtio-console. Would you please post test instructions on using virtio-console as the U-Boot serial console? Thanks! Hi Bin, Yes. The way to test this is. I compile U-boot for qemu_arm64_defconfig Enable the following configs manually. CONFIG_VIRTIO_CONSOLE=y CONFIG_CONSOLE_MUX=y CONFIG_SYS_CONSOLE_IS_IN_ENV=y Now run qemu with the following commands. qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic \ -device virtio-serial-pci,id=virtio-serial0 \ -chardev file,id=charconsole0,path=/tmp/serialconsolelog \ -device virtconsole,chardev=charconsole0,id=console0 \ -bios /tmp/uboot-qemu-clang/u-boot.bin In U-boot prompt, we run 1. virtio scan 2. coninfo In coninfo, we can see there is a new console device called virtio-console#XX Then. 3. setenv stdout pl011@900,virtio-console#XX And then all the output will also be output to /tmp/serialconsolelog on host. This is the minimum example of testing the driver. If we want to test it more then we might need to modify the -chardev to not use a file. For example, we can use a telnet server. -chardev socket,id=charconsole0,host=127.0.0.1,port=10023,telnet=on,server After set stdin and stdout to pl011@900,virtio-console#XX We can use "telnet localhost 10023" to access the U-boot prompt in qemu. Yours, Paul
Re: [PATCH v2] sandbox: fix a compilation error
On Tue, Jun 13, 2023 at 07:05:52PM +0300, Sergei Antonov wrote: > On Tue, 13 Jun 2023 at 17:58, Simon Glass wrote: > > The problem with this is it then cannot be built on non-sandbox > > boards. I think v1 was OK. > > Before the patch as well as after the patch: > if CONFIG_SANDBOX_SDL > declaration of sandbox_sdl_set_bpp() > else > definition of sandbox_sdl_set_bpp() returning error > end > This patch only moves code to another header file in arch/sandbox/include/asm. > How can a non-sandbox build fail because of this patch? Right, test/dm/video.c is for sandbox-only. -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] xilinx patches for v2023.10-rc1
On Mon, Jun 12, 2023 at 07:30:38PM +0200, Michal Simek wrote: > Hi Tom, > > please pull these patches for next version. CI didn't show any issue on > previous base but I see a lot of times that 32bit arm builds are failing > because of 1h limit. Note that this is a per-project setting, so I can't change the defaults for everyone. But, you can bump this up under General pipelines portion of CI/CD settings. > I had to rebase the branch based on latest master branch and hope that this > won't be an issue for you. Please let me know if you want me something to > change. I don't like that exactly, but since I needed to do -rc4 today anyhow, I've merged that in first. > The biggest change is that s/u-boot/U-Boot replacement which touches a lot of > files. > > Thanks, > Michal > > The following changes since commit addd47379df54a3eb247c6db4f799f14af43e523: > > Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2023-06-08 > 18:23:06 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2023.10-rc1 > > for you to fetch changes up to 89240bc0c44b985e461a4220475cb462263df5be: > > arm64: versal: Add missing prototypes (2023-06-12 13:25:02 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] virtio: add driver for virtio_console devices
Hello,
On 06.06.23 15:25, Ying-Chun Liu (PaulLiu) wrote:
> From: "A. Cody Schuffelen"
>
> This is an implementation of single-character virtio-console. Part of the
> patch is based on barebox implementations.
Cool to see others found this useful. I had originally written this for the demo
at https://barebox.org/jsbarebox/ :-)
Back then I had trouble getting more than one console to work, whether through
multiport consoles or via having one virtio device per console. The original
barebox source code has a comment about what I tried. Did you manage to resolve
this limitation?
If not, you should add some check into your patch to prevent registering more
than
one console with the driver.
Cheers,
Ahmad
>
> Signed-off-by: A. Cody Schuffelen
> [ Paul: pick from the Android tree. Rebase to the upstream. Small fixes. ]
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Link:
> https://android.googlesource.com/platform/external/u-boot/+/bc68da98ebf835a50d869cf01c535ac936bfcb11
> Link:
> https://git.pengutronix.de/cgit/barebox/tree/drivers/serial/virtio_console.c?id=180a551d542844b70012d7b94a415aacdcf31d45
> Link:
> https://android.googlesource.com/platform/external/u-boot/+/4581f7c6e96d7332b534ae20de356a4554594d08
> Cc: Bin Meng
> ---
> drivers/virtio/Kconfig | 8 ++
> drivers/virtio/Makefile | 1 +
> drivers/virtio/virtio-uclass.c | 1 +
> drivers/virtio/virtio_console.c | 158
> include/virtio.h| 2 +
> 5 files changed, 170 insertions(+)
> create mode 100644 drivers/virtio/virtio_console.c
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 852f6735b6..94aaf70ab9 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -68,6 +68,14 @@ config VIRTIO_BLK
> This is the virtual block driver for virtio. It can be used with
> QEMU based targets.
>
> +config VIRTIO_CONSOLE
> + bool "virtio console driver"
> + depends on VIRTIO
> + default y
> + help
> + This is the virtual console driver for virtio. It can be used
> + with QEMU based targets.
> +
> config VIRTIO_RNG
> bool "virtio rng driver"
> depends on DM_RNG
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index 4c63a6c690..c816f66aa6 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -10,4 +10,5 @@ obj-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
> obj-$(CONFIG_VIRTIO_SANDBOX) += virtio_sandbox.o
> obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> obj-$(CONFIG_VIRTIO_BLK) += virtio_blk.o
> +obj-$(CONFIG_VIRTIO_CONSOLE) += virtio_console.o
> obj-$(CONFIG_VIRTIO_RNG) += virtio_rng.o
> diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
> index 31bb21c534..9c54c67572 100644
> --- a/drivers/virtio/virtio-uclass.c
> +++ b/drivers/virtio/virtio-uclass.c
> @@ -30,6 +30,7 @@
> static const char *const virtio_drv_name[VIRTIO_ID_MAX_NUM] = {
> [VIRTIO_ID_NET] = VIRTIO_NET_DRV_NAME,
> [VIRTIO_ID_BLOCK] = VIRTIO_BLK_DRV_NAME,
> + [VIRTIO_ID_CONSOLE] = VIRTIO_CONSOLE_DRV_NAME,
> [VIRTIO_ID_RNG] = VIRTIO_RNG_DRV_NAME,
> };
>
> diff --git a/drivers/virtio/virtio_console.c b/drivers/virtio/virtio_console.c
> new file mode 100644
> index 00..1d4b319b08
> --- /dev/null
> +++ b/drivers/virtio/virtio_console.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Tuomas Tynkkynen
> + * Copyright (C) 2018, Bin Meng
> + * Copyright (C) 2006, 2007, 2009 Rusty Russell, IBM Corporation
> + * Copyright (C) 2009, 2010, 2011 Red Hat, Inc.
> + * Copyright (C) 2009, 2010, 2011 Amit Shah
> + * Copyright (C) 2021 Ahmad Fatoum
> + * Copyright (C) 2021, Google LLC, schuffe...@google.com (A. Cody Schuffelen)
> + * Copyright (C) 2023, Linaro
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "virtio_blk.h"
> +
> +struct virtio_console_priv {
> + struct virtqueue *receiveq_port0;
> + struct virtqueue *transmitq_port0;
> + unsigned char inbuf[1] __aligned(4);
> +};
> +
> +static int virtio_console_bind(struct udevice *dev)
> +{
> + struct virtio_dev_priv *uc_priv = dev_get_uclass_priv(dev->parent);
> +
> + /* Indicate what driver features we support */
> + virtio_driver_features_init(uc_priv, NULL, 0, NULL, 0);
> +
> + return 0;
> +}
> +
> +/*
> + * Create a scatter-gather list representing our input buffer and put
> + * it in the queue.
> + */
> +static void add_inbuf(struct virtio_console_priv *priv)
> +{
> + struct virtio_sg sg;
> + struct virtio_sg *sgs[1];
> + int ret;
> +
> + sgs[0] = &sg;
> + sg.addr = priv->inbuf;
> + sg.length = sizeof(priv->inbuf);
> +
> + ret = virtqueue_add(priv->receiveq_port0, sgs, 0, 1);
> + /* We should always be able to add one buffer to an empty queue. */
> + WARN(ret < 0, "%s: virtq
RE: [PATCH v6 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support
Svyatoslav, I've got your V6 patches applied, and buildman tegra is OK. I've never run the CI tests before, so I'll have to look into that. I'll update u-boot-tegra/master TOT today, though. TomR & Simon - I'm retiring the first week in July, so I won't be the Tegra custodian going forward - we've yet to assign that job to another engineer here, hopefully that'll get done before I leave & you can help them get up-to-speed on custodial duties w/the Tegra repo, if needed. Tom -Original Message- From: Svyatoslav Ryhel Sent: Tuesday, June 13, 2023 2:51 AM To: Tom Warren Cc: u-boot@lists.denx.de; Tom Rini ; Simon Glass ; Svyatoslav Ryhel Subject: Re: [PATCH v6 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support External email: Use caution opening links or attachments 9 червня 2023 р. 07:34:41 GMT+03:00, Svyatoslav Ryhel написав(-ла): >This patchset adds support for native use of U-Boot on: >- ASUS T30 Transformers (7 devices, all models); >- ASUS/Google Nexus 7 (2012), both grouper and tilapia >- LG Optimus 4X HD (P880) and Optimus Vu (P895) >- HTC One X (endeavoru) >as a replacement for the vendor bootloader. > >Current commits are designed to work on re-crypted devices but can be >used on clean unmodified devices with slight restrictions (like no >booting/mounting emmc and no self updating feature). > >All device setup commits fall under the same pattern. Alongside device >bringup tegra requires few small patches: > - add gpio keyboard as stdin device > - make networking boot options optional > - add a small tool to generate SoC UID > >Commits passed ./tools/buildman/buildman tegra Building current source >for 30 boards (12 threads, 1 job per thread) > 3000 /30 0:00:06 : apalis_t30 >Completed: 30 total built, 30 newly), duration 0:05:23, rate 0.09 > >Passed 50/53 GitLab CI Pipelines and then I ran off CI minures. > >--- >Changes from v5: >- fixed maintained files inclusion > >Changes from v4: >- fixed documentation >- fixed CONFIG_* definitions > >Changes from v3: >- extended amount of devices supported > >Changes from v2: > - fuse build is excluded for T186 (it is not supported in it anyway) > >Changes from v1: > - fix fuse headers for newer Tegra generations > - allow grouper_common_defconfig to pass without fragments >--- > >Jonas Schwöbel (1): > configs: tegra-common-post: make PXE and DHCP boot targets optional > >Svyatoslav Ryhel (6): > configs: tegra-common-post: add GPIO keyboard as STDIN device > ARM: tegra: add SoC UID calculation function > board: asus: transformer: add ASUS Transformer T30 family support > board: asus: grouper: add Google Nexus 7 (2012) support > board: lg: x3: add Optimus 4X HD and Optimus Vu support > board: htc: endeavoru: add One X support > > arch/arm/dts/Makefile | 12 + > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 157 ++ > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 43 ++ > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 36 ++ > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 62 +++ > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 + > arch/arm/dts/tegra30-asus-tf201.dts | 9 + > arch/arm/dts/tegra30-asus-tf300t.dts | 18 + > arch/arm/dts/tegra30-asus-tf300tg.dts | 9 + > arch/arm/dts/tegra30-asus-tf300tl.dts | 9 + > arch/arm/dts/tegra30-asus-tf600t.dts | 89 > arch/arm/dts/tegra30-asus-tf700t.dts | 13 + > arch/arm/dts/tegra30-asus-transformer.dtsi| 211 > arch/arm/dts/tegra30-htc-endeavoru.dts| 166 +++ > arch/arm/dts/tegra30-lg-p880.dts | 40 ++ > arch/arm/dts/tegra30-lg-p895.dts | 50 ++ > arch/arm/dts/tegra30-lg-x3.dtsi | 180 +++ > arch/arm/include/asm/arch-tegra/fuse.h| 7 + > arch/arm/mach-tegra/Makefile | 4 + > arch/arm/mach-tegra/fuse.c| 151 ++ > arch/arm/mach-tegra/tegra30/Kconfig | 20 + > board/asus/grouper/Kconfig| 22 + > board/asus/grouper/MAINTAINERS| 10 + > board/asus/grouper/Makefile | 14 + > board/asus/grouper/grouper-spl-max.c | 45 ++ > board/asus/grouper/grouper-spl-ti.c | 41 ++ > board/asus/grouper/grouper.c | 202 > board/asus/grouper/pinmux-config-grouper.h| 362 ++ > board/asus/transformer-t30/Kconfig| 23 + > board/asus/transformer-t30/MAINTAINERS| 15 + > board/asus/transformer-t30/Makefile | 11 + > .../pinmux-config-transformer.h | 365 ++ > .../transformer-t30/transformer-t30-spl.c | 41 ++ > board/asus/transformer-t30/transformer-t30.c | 201 > board/htc/endeavoru/Kconfig | 12 + > board/htc/endeavoru/MAINTAINERS | 7 + > board/htc/endeavoru/Makefile | 11 + > board/htc/endeavoru/endeavoru-spl.c | 47 ++ > boar
Re: [PATCH v2] sandbox: fix a compilation error
On Tue, 13 Jun 2023 at 17:58, Simon Glass wrote: > The problem with this is it then cannot be built on non-sandbox > boards. I think v1 was OK. Before the patch as well as after the patch: if CONFIG_SANDBOX_SDL declaration of sandbox_sdl_set_bpp() else definition of sandbox_sdl_set_bpp() returning error end This patch only moves code to another header file in arch/sandbox/include/asm. How can a non-sandbox build fail because of this patch?
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
El Tue, Jun 13, 2023 at 03:58:22PM +0100, Simon Glass deia: > > Yes that's right. So 'usb info' should ignore UCLASS_BOOTDEV devices. That's a possibility, yes. It should work until someone adds another device there for some other purpose. > That is better than checking for the NULL pointer. > Why? What's wrong about checking for null ? Or maybe checking for both not null and not UCLASS_BOOTDEV ? Not that I care too much, just to understand your reasoning. Or can we check for recursible devices somehow ? Maybe flag them or something ? Why is better to state all devices are recursible except some UCLASSes (meaning they can have stuff that needs listed in usb info - or likewise usb tree -) instead of stating that some closed set are recursible ?
[PATCH] board:pm9g45:add missing gpio_request()
This fixes the following run time error message: set_dir_flags: error: gpio PIOD3 not reserved set_dir_flags: error: gpio PIOC14 not reserved Signed-off-by: Ilko Iliev --- board/ronetix/pm9g45/pm9g45.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c index c56582a194..aa5c80ac64 100644 --- a/board/ronetix/pm9g45/pm9g45.c +++ b/board/ronetix/pm9g45/pm9g45.c @@ -67,10 +67,12 @@ static void pm9g45_nand_hw_init(void) #ifdef CFG_SYS_NAND_READY_PIN /* Configure RDY/BSY */ + gpio_request(CFG_SYS_NAND_READY_PIN, "NAND RDY/BSY"); gpio_direction_input(CFG_SYS_NAND_READY_PIN); #endif /* Enable NandFlash */ + gpio_request(CFG_SYS_NAND_ENABLE_PIN, "NAND enable"); gpio_direction_output(CFG_SYS_NAND_ENABLE_PIN, 1); } #endif -- 2.34.1
Re: [PATCH] efi_selftests: fix controllers repeated selftesting
Hi Heinrich,
On Tue, 13 Jun 2023 at 18:00, Heinrich Schuchardt wrote:
>
> On 6/13/23 15:23, Ilias Apalodimas wrote:
> > Running the controller selftest more than one times fails with
> >
> > => setenv efi_selftest 'controllers' && bootefi selftest
> > Testing EFI API implementation
> > Selected test: 'controllers'
> > Setting up 'controllers'
> > Setting up 'controllers' succeeded
> > Executing 'controllers'
> > Executing 'controllers' succeeded
> > Summary: 0 failures
> >
> > => bootefi selftest
> > Testing EFI API implementation
> > Selected test: 'controllers'
> > Setting up 'controllers'
> > lib/efi_selftest/efi_selftest_controllers.c(280):
> > ERROR: InstallProtocolInterface failed
> > lib/efi_selftest/efi_selftest.c(89):
> > ERROR: Setting up 'controllers' failed
> > Summary: 1 failures
> >
> > There are multiple reason for this. We don't uninstall the binding
> > interface from the controller handle and we don't reset the handle
> > pointers either. So let's uninstall all the protocols properly and
> > reset the handles to NULL on setup().
> >
> > While at it add a forgotten check when uninstalling protocols from the
> > handle_controller and make sure the number of child controllers is 0
> >
> > Signed-off-by: Ilias Apalodimas
> > ---
> > lib/efi_selftest/efi_selftest_controllers.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_selftest/efi_selftest_controllers.c
> > b/lib/efi_selftest/efi_selftest_controllers.c
> > index d2bbd1c4f65b..07a17ed866a9 100644
> > --- a/lib/efi_selftest/efi_selftest_controllers.c
> > +++ b/lib/efi_selftest/efi_selftest_controllers.c
> > @@ -271,6 +271,8 @@ static int setup(const efi_handle_t img_handle,
> > efi_status_t ret;
> >
> > boottime = systable->boottime;
> > + handle_controller = NULL;
> > + handle_driver = NULL;
>
> Other instances of the same problem could be in
>
> lib/efi_selftest/efi_selftest_open_protocol.c
> lib/efi_selftest/efi_selftest_loadimage.c
> lib/efi_selftest/efi_selftest_manageprotocols.c
>
> We should probably try for each test if it can be repeated.
I've fixed the manageprotocols in a subsequent patch. The rest are
probably problematic as well, but I was planning to deal with them
after I am done with the protocol refactoring.
>
> >
> > /* Create controller handle */
> > ret = boottime->install_protocol_interface(
> > @@ -402,8 +404,18 @@ static int execute(void)
> > /* Check number of child controllers */
> > ret = count_child_controllers(handle_controller, &guid_controller,
> > &count);
> > - if (ret == EFI_SUCCESS)
> > + if (ret == EFI_SUCCESS || count != 0)
> > efi_st_error("Uninstall failed\n");
> > +
> > + /* Uninstall binding protocol */
> > + ret = boottime->uninstall_protocol_interface(handle_driver,
> > +
> > &guid_driver_binding_protocol,
> > + &binding_interface);
> > + if (ret != EFI_SUCCESS) {
> > + efi_st_error("Failed to uninstall protocols\n");
> > + return EFI_ST_FAILURE;
> > + }
> > +
>
> Could this easily be moved to teardown()?
Yea, I don't think this will be a problem
Thanks
/Ilias
>
> Best regards
>
> Heinrich
>
> > return EFI_ST_SUCCESS;
> > }
> >
>
Re: [PATCH] efi_selftests: fix controllers repeated selftesting
On 6/13/23 15:23, Ilias Apalodimas wrote:
Running the controller selftest more than one times fails with
=> setenv efi_selftest 'controllers' && bootefi selftest
Testing EFI API implementation
Selected test: 'controllers'
Setting up 'controllers'
Setting up 'controllers' succeeded
Executing 'controllers'
Executing 'controllers' succeeded
Summary: 0 failures
=> bootefi selftest
Testing EFI API implementation
Selected test: 'controllers'
Setting up 'controllers'
lib/efi_selftest/efi_selftest_controllers.c(280):
ERROR: InstallProtocolInterface failed
lib/efi_selftest/efi_selftest.c(89):
ERROR: Setting up 'controllers' failed
Summary: 1 failures
There are multiple reason for this. We don't uninstall the binding
interface from the controller handle and we don't reset the handle
pointers either. So let's uninstall all the protocols properly and
reset the handles to NULL on setup().
While at it add a forgotten check when uninstalling protocols from the
handle_controller and make sure the number of child controllers is 0
Signed-off-by: Ilias Apalodimas
---
lib/efi_selftest/efi_selftest_controllers.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/lib/efi_selftest/efi_selftest_controllers.c
b/lib/efi_selftest/efi_selftest_controllers.c
index d2bbd1c4f65b..07a17ed866a9 100644
--- a/lib/efi_selftest/efi_selftest_controllers.c
+++ b/lib/efi_selftest/efi_selftest_controllers.c
@@ -271,6 +271,8 @@ static int setup(const efi_handle_t img_handle,
efi_status_t ret;
boottime = systable->boottime;
+ handle_controller = NULL;
+ handle_driver = NULL;
Other instances of the same problem could be in
lib/efi_selftest/efi_selftest_open_protocol.c
lib/efi_selftest/efi_selftest_loadimage.c
lib/efi_selftest/efi_selftest_manageprotocols.c
We should probably try for each test if it can be repeated.
/* Create controller handle */
ret = boottime->install_protocol_interface(
@@ -402,8 +404,18 @@ static int execute(void)
/* Check number of child controllers */
ret = count_child_controllers(handle_controller, &guid_controller,
&count);
- if (ret == EFI_SUCCESS)
+ if (ret == EFI_SUCCESS || count != 0)
efi_st_error("Uninstall failed\n");
+
+ /* Uninstall binding protocol */
+ ret = boottime->uninstall_protocol_interface(handle_driver,
+
&guid_driver_binding_protocol,
+&binding_interface);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("Failed to uninstall protocols\n");
+ return EFI_ST_FAILURE;
+ }
+
Could this easily be moved to teardown()?
Best regards
Heinrich
return EFI_ST_SUCCESS;
}
Re: [PATCH v2] sandbox: fix a compilation error
On Tue, Jun 13, 2023 at 03:58:25PM +0100, Simon Glass wrote:
> Hi Sergei,
>
> On Mon, 12 Jun 2023 at 22:19, Sergei Antonov wrote:
> >
> > With sandbox and sandbox64 configurations:
> >
> > In file included from .../u-boot/include/test/test.h:156,
> > from .../u-boot/include/test/lib.h:9,
> > from .../u-boot/test/lib/test_crc8.c:8:
> > .../u-boot/arch/sandbox/include/asm/test.h: In function
> > ‘sandbox_sdl_set_bpp’:
> > .../u-boot/arch/sandbox/include/asm/test.h:323:17: error: ‘ENOSYS’
> > undeclared (first use in this function)
> > 323 | return -ENOSYS;
> > | ^~
> >
> > Per Tom Rini's suggestion:
> > move that function prototype over to arch/sandbox/include/asm/sdl.h
> > and make test/dm/video.c include
> >
> > Cc: Simon Glass
> > Suggested-by: Tom Rini
> > Signed-off-by: Sergei Antonov
> > ---
> >
> > v2:
> > * move the function to another file instead of including
> >
> > arch/sandbox/include/asm/sdl.h | 23 +++
> > arch/sandbox/include/asm/test.h | 25 -
> > test/dm/video.c | 1 +
> > 3 files changed, 24 insertions(+), 25 deletions(-)
> >
> > diff --git a/arch/sandbox/include/asm/sdl.h b/arch/sandbox/include/asm/sdl.h
> > index 56dcb84803d3..ee4991f7c24a 100644
> > --- a/arch/sandbox/include/asm/sdl.h
> > +++ b/arch/sandbox/include/asm/sdl.h
> > @@ -7,6 +7,7 @@
> > #define __SANDBOX_SDL_H
> >
> > #include
> > +#include
> >
> > #ifdef CONFIG_SANDBOX_SDL
> >
> > @@ -87,6 +88,22 @@ int sandbox_sdl_sound_stop(void);
> > */
> > int sandbox_sdl_sound_init(int rate, int channels);
> >
> > +/**
> > + * sandbox_sdl_set_bpp() - Set the depth of the sandbox display
> > + *
> > + * The device must not be active when this function is called. It
> > activiates it
> > + * before returning.
> > + *
> > + * This updates the depth value and adjusts a few other settings
> > accordingly.
> > + * It must be called before the display is probed.
> > + *
> > + * @dev: Device to adjust
> > + * @l2bpp: depth to set
> > + * Return: 0 if the device was already active, other error if it fails to
> > probe
> > + * after the change
> > + */
> > +int sandbox_sdl_set_bpp(struct udevice *dev, enum video_log2_bpp l2bpp);
> > +
> > #else
> > static inline int sandbox_sdl_init_display(int width, int height, int
> > log2_bpp,
> >bool double_size)
> > @@ -134,6 +151,12 @@ static inline int sandbox_sdl_sound_init(int rate, int
> > channels)
> > return -ENODEV;
> > }
> >
> > +static inline int sandbox_sdl_set_bpp(struct udevice *dev,
> > + enum video_log2_bpp l2bpp)
> > +{
> > + return -ENOSYS;
> > +}
> > +
> > #endif
> >
> > #endif
> > diff --git a/arch/sandbox/include/asm/test.h
> > b/arch/sandbox/include/asm/test.h
> > index e482271fe975..17159f8d674a 100644
> > --- a/arch/sandbox/include/asm/test.h
> > +++ b/arch/sandbox/include/asm/test.h
> > @@ -8,7 +8,6 @@
> > #ifndef __ASM_TEST_H
> > #define __ASM_TEST_H
> >
> > -#include
> > #include
> >
> > struct unit_test_state;
> > @@ -300,30 +299,6 @@ void sandbox_cros_ec_set_test_flags(struct udevice
> > *dev, uint flags);
> > */
> > int sandbox_cros_ec_get_pwm_duty(struct udevice *dev, uint index, uint
> > *duty);
> >
> > -#if IS_ENABLED(CONFIG_SANDBOX_SDL)
> > -/**
> > - * sandbox_sdl_set_bpp() - Set the depth of the sandbox display
> > - *
> > - * The device must not be active when this function is called. It
> > activiates it
> > - * before returning.
> > - *
> > - * This updates the depth value and adjusts a few other settings
> > accordingly.
> > - * It must be called before the display is probed.
> > - *
> > - * @dev: Device to adjust
> > - * @l2bpp: depth to set
> > - * Return: 0 if the device was already active, other error if it fails to
> > probe
> > - * after the change
> > - */
> > -int sandbox_sdl_set_bpp(struct udevice *dev, enum video_log2_bpp l2bpp);
> > -#else
> > -static inline int sandbox_sdl_set_bpp(struct udevice *dev,
> > - enum video_log2_bpp l2bpp)
> > -{
> > - return -ENOSYS;
> > -}
> > -#endif
> > -
> > /**
> > * sandbox_set_fake_efi_mgr_dev() - Control EFI bootmgr producing valid
> > bootflow
> > *
> > diff --git a/test/dm/video.c b/test/dm/video.c
> > index 30778157d940..1c63d16bd28b 100644
> > --- a/test/dm/video.c
> > +++ b/test/dm/video.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> The problem with this is it then cannot be built on non-sandbox
> boards. I think v1 was OK.
I suggested this since the test is sandbox specific (the code itself is
full of sandbox_foo).
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] sandbox: fix a compilation error
Hi Sergei,
On Mon, 12 Jun 2023 at 22:19, Sergei Antonov wrote:
>
> With sandbox and sandbox64 configurations:
>
> In file included from .../u-boot/include/test/test.h:156,
> from .../u-boot/include/test/lib.h:9,
> from .../u-boot/test/lib/test_crc8.c:8:
> .../u-boot/arch/sandbox/include/asm/test.h: In function ‘sandbox_sdl_set_bpp’:
> .../u-boot/arch/sandbox/include/asm/test.h:323:17: error: ‘ENOSYS’ undeclared
> (first use in this function)
> 323 | return -ENOSYS;
> | ^~
>
> Per Tom Rini's suggestion:
> move that function prototype over to arch/sandbox/include/asm/sdl.h
> and make test/dm/video.c include
>
> Cc: Simon Glass
> Suggested-by: Tom Rini
> Signed-off-by: Sergei Antonov
> ---
>
> v2:
> * move the function to another file instead of including
>
> arch/sandbox/include/asm/sdl.h | 23 +++
> arch/sandbox/include/asm/test.h | 25 -
> test/dm/video.c | 1 +
> 3 files changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/arch/sandbox/include/asm/sdl.h b/arch/sandbox/include/asm/sdl.h
> index 56dcb84803d3..ee4991f7c24a 100644
> --- a/arch/sandbox/include/asm/sdl.h
> +++ b/arch/sandbox/include/asm/sdl.h
> @@ -7,6 +7,7 @@
> #define __SANDBOX_SDL_H
>
> #include
> +#include
>
> #ifdef CONFIG_SANDBOX_SDL
>
> @@ -87,6 +88,22 @@ int sandbox_sdl_sound_stop(void);
> */
> int sandbox_sdl_sound_init(int rate, int channels);
>
> +/**
> + * sandbox_sdl_set_bpp() - Set the depth of the sandbox display
> + *
> + * The device must not be active when this function is called. It activiates
> it
> + * before returning.
> + *
> + * This updates the depth value and adjusts a few other settings accordingly.
> + * It must be called before the display is probed.
> + *
> + * @dev: Device to adjust
> + * @l2bpp: depth to set
> + * Return: 0 if the device was already active, other error if it fails to
> probe
> + * after the change
> + */
> +int sandbox_sdl_set_bpp(struct udevice *dev, enum video_log2_bpp l2bpp);
> +
> #else
> static inline int sandbox_sdl_init_display(int width, int height, int
> log2_bpp,
>bool double_size)
> @@ -134,6 +151,12 @@ static inline int sandbox_sdl_sound_init(int rate, int
> channels)
> return -ENODEV;
> }
>
> +static inline int sandbox_sdl_set_bpp(struct udevice *dev,
> + enum video_log2_bpp l2bpp)
> +{
> + return -ENOSYS;
> +}
> +
> #endif
>
> #endif
> diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
> index e482271fe975..17159f8d674a 100644
> --- a/arch/sandbox/include/asm/test.h
> +++ b/arch/sandbox/include/asm/test.h
> @@ -8,7 +8,6 @@
> #ifndef __ASM_TEST_H
> #define __ASM_TEST_H
>
> -#include
> #include
>
> struct unit_test_state;
> @@ -300,30 +299,6 @@ void sandbox_cros_ec_set_test_flags(struct udevice *dev,
> uint flags);
> */
> int sandbox_cros_ec_get_pwm_duty(struct udevice *dev, uint index, uint
> *duty);
>
> -#if IS_ENABLED(CONFIG_SANDBOX_SDL)
> -/**
> - * sandbox_sdl_set_bpp() - Set the depth of the sandbox display
> - *
> - * The device must not be active when this function is called. It activiates
> it
> - * before returning.
> - *
> - * This updates the depth value and adjusts a few other settings accordingly.
> - * It must be called before the display is probed.
> - *
> - * @dev: Device to adjust
> - * @l2bpp: depth to set
> - * Return: 0 if the device was already active, other error if it fails to
> probe
> - * after the change
> - */
> -int sandbox_sdl_set_bpp(struct udevice *dev, enum video_log2_bpp l2bpp);
> -#else
> -static inline int sandbox_sdl_set_bpp(struct udevice *dev,
> - enum video_log2_bpp l2bpp)
> -{
> - return -ENOSYS;
> -}
> -#endif
> -
> /**
> * sandbox_set_fake_efi_mgr_dev() - Control EFI bootmgr producing valid
> bootflow
> *
> diff --git a/test/dm/video.c b/test/dm/video.c
> index 30778157d940..1c63d16bd28b 100644
> --- a/test/dm/video.c
> +++ b/test/dm/video.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
The problem with this is it then cannot be built on non-sandbox
boards. I think v1 was OK.
> #include
> #include
> #include
> --
> 2.37.2
>
Regards,
Simon
Re: [PATCH 3/3 v2] test/py: Account PCR updates properly during testing
Hi Ilias, On Tue, 13 Jun 2023 at 06:48, Ilias Apalodimas wrote: > > On Mon, Jun 12, 2023 at 10:17:28PM +0100, Simon Glass wrote: > > Hi Ilias, > > > > On Wed, 7 Jun 2023 at 10:18, Ilias Apalodimas > > wrote: > > > > > > Currently we only read the pcr updates once on test_tpm2_pcr_read(). > > > It turns out that the tpm init sequence of force_init() which consists > > > of: > > > - tpm2 init > > > - tpm2 startup TPM2_SU_CLEAR > > > - tpm2 self_test full > > > - tpm2 clear TPM2_RH_LOCKOUT > > > > > > also counts as an update. Running this in the console verifies the > > > update bump > > > => tpm2 init > > > => tpm2 startup TPM2_SU_CLEAR > > > => tpm2 self_test full > > > => tpm pcr_read 10 $loadaddr > > > PCR #10 content (28 known updates): > > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > => tpm2 clear TPM2_RH_LOCKOUT > > > => tpm pcr_read 10 $loadaddr > > > PCR #10 content (29 known updates): > > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > => > > > > > > With the recent changes of replacing 'tpm2 init' with 'tpm2 autostart' > > > we end up always running the full init. The reason is 'tpm init' > > > returns -EBUSY if the tpm is already open, while 'tpm autostart' handles > > > ths gracefully and continues with the initialization. It's worth noting > > > that this won't affect the device functionality at all since > > > retriggering the startup sequence and selftests has no side effects. > > > > This may be true for some TPMs. > > The responses to the startup command are described by the spec, so unless > the device isn't a standard TPM, this should be safe Yes, that could be the problem. > > > > > > > > > Instead of relying on the initial value, reread the 'known updates' > > > just before updating the PCR to ensure we read the correct values > > > before testing > > > > > > Signed-off-by: Ilias Apalodimas > > > --- > > > Changes since v1: > > > - new patch to fix the python testing failures > > > > > > test/py/tests/test_tpm2.py | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > > Reviewed-by: Simon Glass > > > > BTW this is an example of why I still want to be able to just init the > > TPM to a basic level. Here we see that autostart changes the PCRs. > > > It doesnt change the PCRs. That code is checking how many commands have > been sent to the TPM in total. In the previous version of the code 'tpm > init' would return -EBUSY and we would never re-run the next commands. The > new command returns 0 and as a result we end up running the TPM2_RH_LOCKOUT > again. OK. Regards, Simon
Re: [PATCH 01/12] fdt_support: include dm/ofnode.h
Hi Patrick, On Thu, 8 Jun 2023 at 16:16, Patrick Delaunay wrote: > > This patch is a preliminary patch to use ofnode function > is fdt_support to read the U-Boot device tree with livetree > compatible functions. When will the real patch come? Reviewed-by: Simon Glass Regards, Simon > > Signed-off-by: Patrick Delaunay > --- > > common/fdt_support.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/fdt_support.c b/common/fdt_support.c > index 2053fe3bad83..ffc59fd8b36a 100644 > --- a/common/fdt_support.c > +++ b/common/fdt_support.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1065,7 +1066,6 @@ void fdt_del_node_and_alias(void *blob, const char > *alias) > > /* Max address size we deal with */ > #define OF_MAX_ADDR_CELLS 4 > -#define OF_BAD_ADDRFDT_ADDR_T_NONE > #define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <= > OF_MAX_ADDR_CELLS && \ > (ns) > 0) > > -- > 2.25.1 >
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
Hi Xavier,
On Tue, 13 Jun 2023 at 07:52, Xavier Drudis Ferran wrote:
>
> Ok. New test.
>
> This uses yesterday morning's next branch.
> commit 5b589e139620214f
> Merge: cc5a940923 32d2461e04
> Merge branch 'next_net/phy_connect_dev'
>
> USB2 does not work for rk3399 in next (fixes are in master, thanks),
> but USB3 is enough.
>
> I compiled for rock-pi-4-rk3399_defconfig
>
> flashed to a new microSD card as per doc/board/rockchip/rockchip.rst :
>
>dd if=u-boot-rockchip.bin of=/dev/sda seek=64
>sync
>
> Put this microSD card in a Rock Pi 4 B+
> Put a new USB stick in the USB3 port (center blue port closer to board).
>
> (the microSD card and USB stick come from factory, I guess they were
> partitioned with a single FAT partition)
>
> (make sure emmc and spi are blank)
>
> Connected only serial console and power.
>
> Got this:
>
> U-Boot TPL 2023.07-rc2-00144-g497967f1ee (Jun 12 2023 - 11:15:47)
> lpddr4_set_rate: change freq to 400MHz 0, 1
> Channel 0: LPDDR4, 400MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Channel 1: LPDDR4, 400MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> 256B stride
> lpddr4_set_rate: change freq to 800MHz 1, 0
> Trying to boot from BOOTROM
> Returning to boot ROM...
>
> U-Boot SPL 2023.07-rc2-00144-g497967f1ee (Jun 12 2023 - 11:15:47 +0200)
> Trying to boot from MMC1
> NOTICE: BL31: v2.1(release):v2.1-728-ged01e0c4-dirty
> NOTICE: BL31: Built : 18:29:11, Mar 22 2022
>
>
> U-Boot 2023.07-rc2-00144-g497967f1ee (Jun 12 2023 - 11:15:47 +0200)
>
> SoC: Rockchip rk3399
> Reset cause: POR
> Model: Radxa ROCK Pi 4B
> DRAM: 4 GiB (effective 3.9 GiB)
> PMIC: RK808
> Core: 283 devices, 29 uclasses, devicetree: separate
> MMC: mmc@fe31: 2, mmc@fe32: 1, mmc@fe33: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> In:serial
> Out: serial
> Err: serial
> Model: Radxa ROCK Pi 4B
> Net: eth0: ethernet@fe30
> Hit any key to stop autoboot: 2 1 0
> rockchip_pcie pcie@f800: PCIe link training gen1 timeout!
> Bus usb@fe38: ehci_generic usb@fe38: Failed to get clocks (ret=-19)
> Port not available.
> Bus usb@fe3c: ehci_generic usb@fe3c: Failed to get clocks (ret=-19)
> Port not available.
> Bus usb@fe80: Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.10
> Bus usb@fe90: Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.10
> scanning bus usb@fe80 for devices... 1 USB Device(s) found
> scanning bus usb@fe90 for devices... cannot reset port 1!?
> 2 USB Device(s) found
> rockchip_pcie pcie@f800: failed to find ep-gpios property
> ethernet@fe30 Waiting for PHY auto negotiation to complete.
> TIMEOUT !
> Could not initialize PHY ethernet@fe30
> rockchip_pcie pcie@f800: failed to find ep-gpios property
> ethernet@fe30 Waiting for PHY auto negotiation to complete.
> TIMEOUT !
> Could not initialize PHY ethernet@fe30
> => printenv preboot
> ## Error: "preboot" not defined
> => printenv
> arch=arm
> baudrate=150
> board=evb_rk3399
> board_name=evb_rk3399
> boot_targets=mmc1 mmc0 nvme scsi usb pxe dhcp spi
>
> bootcmd=bootflow scan
>
> bootdelay=2
> cpu=armv8
> cpuid#=[something]
> eth1addr=[:so:me:th:in:g]
> ethact=ethernet@fe30
> ethaddr=[:so:me:th:in:g]
> fdt_addr_r=0x01f0
> fdtcontroladdr=f1ef9170
> fdtfile=rockchip/rk3399-rock-pi-4b.dtb
> fdtoverlay_addr_r=0x0200
> kernel_addr_r=0x0208
> kernel_comp_addr_r=0x0800
> kernel_comp_size=0x200
> loadaddr=0x800800
> partitions=uuid_disk=${uuid_gpt_disk};name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};name=loader2,start=8MB,size=4MB,uuid=${uuid_gpt_loader2};name=trust,size=4M,uuid=${uuid_gpt_atf};name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};name=rootfs,size=-,uuid=[something];
> pxefile_addr_r=0x0060
> ramdisk_addr_r=0x0600
> script_offset_f=0xffe000
> script_size_f=0x2000
> scriptaddr=0x0050
> serial#=[something]
> soc=rk3399
> stderr=serial,vidconsole
> stdin=serial,usbkbd
> stdout=serial,vidconsole
> vendor=rockchip
>
> Environment size: 1041/32764 bytes
> => usb info
> 1: Hub, USB Revision 3.0
> - U-Boot XHCI Host Controller
> - Class: Hub
> - PacketSize: 512 Configurations: 1
> - Vendor: 0x Product 0x Version 1.0
>Configuration: 1
>- Interfaces: 1 Self Powered 0mA
> Interface: 0
> - Alternate Setting 0, Endpoints: 1
> - Class Hub
> - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
>
> 1: Hub, USB Revision 3.0
> - U-Boot XHCI Host Controller
> - Class: Hub
> - PacketSize: 512 Configurations: 1
> - Vendor: 0x Product 0x Version 1.0
>Configuration: 1
>- Interfaces: 1 Self Powered 0mA
> Interface: 0
> - Alternate Setting 0, Endpoints: 1
> - Class Hub
> - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
>
> 2: Mass Storage, USB Revision 3.20
> - USB SanDisk 3
[PATCH 1/2] dm: adc: add iMX93 ADC support
This commit adds driver for iMX93 ADC.
The driver is implemented using driver model and provides
ADC uclass's methods for ADC single channel operations:
- adc_start_channel()
- adc_channel_data()
- adc_stop()
ADC features:
- channels: 4
- resolution: 12-bit
Signed-off-by: Luca Ellero
---
drivers/adc/Kconfig | 8 ++
drivers/adc/Makefile| 1 +
drivers/adc/imx93-adc.c | 290
3 files changed, 299 insertions(+)
create mode 100644 drivers/adc/imx93-adc.c
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index e719c38bb3..4336732dee 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -63,3 +63,11 @@ config STM32_ADC
- core driver to deal with common resources
- child driver to deal with individual ADC resources (declare ADC
device and associated channels, start/stop conversions)
+
+config ADC_IMX93
+ bool "Enable NXP IMX93 ADC driver"
+ help
+ This enables basic driver for NXP IMX93 ADC.
+ It provides:
+ - 4 analog input channels
+ - 12-bit resolution
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index c1387f3a34..5336c82097 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
obj-$(CONFIG_SARADC_ROCKCHIP) += rockchip-saradc.o
obj-$(CONFIG_SARADC_MESON) += meson-saradc.o
obj-$(CONFIG_STM32_ADC) += stm32-adc.o stm32-adc-core.o
+obj-$(CONFIG_ADC_IMX93) += imx93-adc.o
diff --git a/drivers/adc/imx93-adc.c b/drivers/adc/imx93-adc.c
new file mode 100644
index 00..41d04e0426
--- /dev/null
+++ b/drivers/adc/imx93-adc.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 ASEM Srl
+ * Author: Luca Ellero
+ *
+ * Originally based on NXP linux-imx kernel v5.15 drivers/iio/adc/imx93_adc.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IMX93_ADC_MCR 0x00
+#define IMX93_ADC_MSR 0x04
+#define IMX93_ADC_ISR 0x10
+#define IMX93_ADC_IMR 0x20
+#define IMX93_ADC_CIMR00x24
+#define IMX93_ADC_CTR0 0x94
+#define IMX93_ADC_NCMR00xA4
+#define IMX93_ADC_PCDR00x100
+#define IMX93_ADC_PCDR10x104
+#define IMX93_ADC_PCDR20x108
+#define IMX93_ADC_PCDR30x10c
+#define IMX93_ADC_PCDR40x110
+#define IMX93_ADC_PCDR50x114
+#define IMX93_ADC_PCDR60x118
+#define IMX93_ADC_PCDR70x11c
+#define IMX93_ADC_CALSTAT 0x39C
+
+#define IMX93_ADC_MCR_MODE_MASKBIT(29)
+#define IMX93_ADC_MCR_NSTART_MASK BIT(24)
+#define IMX93_ADC_MCR_CALSTART_MASKBIT(14)
+#define IMX93_ADC_MCR_ADCLKSE_MASK BIT(8)
+#define IMX93_ADC_MCR_PWDN_MASKBIT(0)
+
+#define IMX93_ADC_MSR_CALFAIL_MASK BIT(30)
+#define IMX93_ADC_MSR_CALBUSY_MASK BIT(29)
+#define IMX93_ADC_MSR_ADCSTATUS_MASK GENMASK(2, 0)
+
+#define IMX93_ADC_ISR_EOC_MASK BIT(1)
+
+#define IMX93_ADC_IMR_EOC_MASK BIT(1)
+#define IMX93_ADC_IMR_ECH_MASK BIT(0)
+
+#define IMX93_ADC_PCDR_CDATA_MASK GENMASK(11, 0)
+
+#define IDLE 0
+#define POWER_DOWN 1
+#define WAIT_STATE 2
+#define BUSY_IN_CALIBRATION3
+#define SAMPLE 4
+#define CONVERSION 6
+
+#define IMX93_ADC_MAX_CHANNEL 3
+#define IMX93_ADC_DAT_MASK 0xfff
+#define IMX93_ADC_TIMEOUT 10
+
+struct imx93_adc_priv {
+ int active_channel;
+ void __iomem *regs;
+ struct clk ipg_clk;
+};
+
+static void imx93_adc_power_down(struct imx93_adc_priv *adc)
+{
+ u32 mcr, msr;
+ int ret;
+
+ mcr = readl(adc->regs + IMX93_ADC_MCR);
+ mcr |= FIELD_PREP(IMX93_ADC_MCR_PWDN_MASK, 1);
+ writel(mcr, adc->regs + IMX93_ADC_MCR);
+
+ ret = readl_poll_timeout(adc->regs + IMX93_ADC_MSR, msr,
+ ((msr & IMX93_ADC_MSR_ADCSTATUS_MASK) == POWER_DOWN), 50);
+ if (ret == -ETIMEDOUT)
+ pr_warn("ADC not in power down mode, current MSR: %x\n", msr);
+}
+
+static void imx93_adc_power_up(struct imx93_adc_priv *adc)
+{
+ u32 mcr;
+
+ /* bring ADC out of power down state, in idle state */
+ mcr = readl(adc->regs + IMX93_ADC_MCR);
+ mcr &= ~FIELD_PREP(IMX93_ADC_MCR_PWDN_MASK, 1);
+ writel(mcr, adc->regs + IMX93_ADC_MCR);
+}
+
+static void imx93_adc_config_ad_clk(struct imx93_adc_priv *adc)
+{
+ u32 mcr;
+
+ /* put adc in power down mode */
+ imx93_adc_power_down(adc);
+
+ /* config the AD_CLK equal to bus clock */
+ mcr = readl(adc->regs + IMX93_ADC_MCR);
+ mcr |= FIELD_P
[PATCH 2/2] imx93_evk: defconfig: add adc support
iMX93 ADC features: - 4 channels - 12 bit resolution Signed-off-by: Luca Ellero --- configs/imx93_11x11_evk_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/imx93_11x11_evk_defconfig b/configs/imx93_11x11_evk_defconfig index 89edebc4c6..30ef460c80 100644 --- a/configs/imx93_11x11_evk_defconfig +++ b/configs/imx93_11x11_evk_defconfig @@ -81,6 +81,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_DM=y CONFIG_REGMAP=y CONFIG_SYSCON=y +CONFIG_ADC_IMX93=y CONFIG_CPU=y CONFIG_CPU_IMX=y CONFIG_IMX_RGPIO2P=y -- 2.25.1
[PATCH v5 0/2 RESEND] imx93: add ADC support
Add ADC support for NXP iMX93 Changes for v2: - add "static" to functions - enable ADC in iMX93 EVK Changes for v3: - split in 3 commits - keep dts file in sync with Linux devicetree - add comments to commits Changes for v4: - add imx93_adc_power_down() in imx93_adc_stop() Changes for v5: - simplify code - remove redundant code - add clock handling Luca Ellero (2): dm: adc: add iMX93 ADC support imx93_evk: defconfig: add adc support configs/imx93_11x11_evk_defconfig | 1 + drivers/adc/Kconfig | 8 + drivers/adc/Makefile | 1 + drivers/adc/imx93-adc.c | 290 ++ 4 files changed, 300 insertions(+) create mode 100644 drivers/adc/imx93-adc.c -- 2.25.1
[PATCH] xilinx: board: Add support to pick bootscr address from DT
From: Algapally Santosh Sagar
The bootscript is expected at a default address specific to each
platform.
When high speed memory like Programmable Logic Double Data Rate RAM
(PL DDR RAM) or Higher Bandwidth Memory RAM (HBM) is used the boot.scr
may be loaded at a different offset. The offset needs to be set through
setenv. Due to the default values in some cases the boot.scr is falling
in between the kernel partition.
The bootscript address or the bootscript offset is fetched directly from
the DT and updated in the environment making it easier for automated
flows.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Michal Simek
---
board/xilinx/common/board.c | 43 ++---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index d071ebfb9cc2..bdd4113b0916 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -405,6 +405,31 @@ static int env_set_by_index(const char *name, int index,
char *data)
return env_set(var, data);
}
+static int get_bootscript_address(u64 *bootscr_address, u64 *bootscr_offset)
+{
+ int ret;
+ ofnode uboot;
+
+ *bootscr_address = 0;
+ *bootscr_offset = 0;
+
+ uboot = ofnode_path("/options/u-boot");
+ if (!ofnode_valid(uboot)) {
+ printf("%s: Missing /u-boot node\n", __func__);
+ return -EINVAL;
+ }
+
+ ret = ofnode_read_u64(uboot, "bootscr-address", bootscr_address);
+ if (ret) {
+ ret = ofnode_read_u64(uboot, "bootscr-offset-from-ram-start",
+ bootscr_offset);
+ if (ret)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int board_late_init_xilinx(void)
{
u32 ret = 0;
@@ -414,9 +439,21 @@ int board_late_init_xilinx(void)
if (!IS_ENABLED(CONFIG_MICROBLAZE)) {
ulong scriptaddr;
-
- scriptaddr = env_get_hex("scriptaddr", 0);
- ret |= env_set_hex("scriptaddr", gd->ram_base + scriptaddr);
+ u64 bootscr_address;
+ u64 bootscr_offset;
+
+ /* Fetch bootscr_address/bootscr_offset from DT and update */
+ if (!get_bootscript_address(&bootscr_address, &bootscr_offset))
{
+ if (bootscr_offset)
+ ret |= env_set_hex("scriptaddr",
+ gd->ram_base +
bootscr_offset);
+ else
+ ret |= env_set_hex("scriptaddr",
bootscr_address);
+ } else {
+ /* Update scriptaddr(bootscr offset) from env */
+ scriptaddr = env_get_hex("scriptaddr", 0);
+ ret |= env_set_hex("scriptaddr", gd->ram_base +
scriptaddr);
+ }
}
if (IS_ENABLED(CONFIG_ARCH_ZYNQ) || IS_ENABLED(CONFIG_MICROBLAZE))
--
2.36.1
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Tue, Jun 13, 2023 at 07:28:34AM -0600, Rob Herring wrote:
> On Mon, Jun 12, 2023 at 3:23 PM Conor Dooley wrote:
> > On Thu, Jun 08, 2023 at 08:30:28PM +0100, Conor Dooley wrote:
> > > On Thu, Jun 08, 2023 at 01:15:37PM -0600, Rob Herring wrote:
> > > > On Tue, May 30, 2023 at 03:12:12PM +0100, Conor Dooley wrote:
> > > > > On Thu, May 18, 2023 at 10:42:34PM +0100, Conor Dooley wrote:
> > > > > > On Thu, May 18, 2023 at 02:30:53PM -0400, Sean Anderson wrote:
> > > > >
> > > > > > >
> > > > > > > Why not just have something like
> > > > > > >
> > > > > > > mycpu {
> > > > > > > ...
> > > > > > > riscv,isa {
> > > > > > > i;
> > > > > > > m;
> > > > > > > a;
> > > > > > > zicsr;
> > > > > > > ...
> > > >
> > > > I prefer property names be globally unique. The tools are geared towards
> > > > that too. That's largely a symptom of having 0 type information in the
> > > > DT.
> > > >
> > > > For example if you had an extension called 'reg', it would be a problem.
> > >
> > > Per the current ISA rules, that'd not be valid. But then again, I do
> > > have trust issues & it's not like "reg" is the only property name in DT
> > > land.
> >
> > ...you say "prefer" here. Is that a NAK, or a "you keep the pieces"?
>
> Don't do the above node.
Yeah, that's more helpful wording than "prefer" for sure!
If that's a no-go & so are the booleans prefixed with "riscv,whatever-",
since people have size concerns, I guess that leaves your string
suggestion (there is a helper in Linux at least, haven't checked
elsewhere yet).
I guess that means something like:
riscv,isa-extensions:
$ref: /schemas/types.yaml#/definitions/string-array
minItems: 1
description: Extensions supported by the hart.
items:
anyOf:
- const: i
description: foo
- const: m
description: foo
- const: a
description: foo
- const: f
description: foo
- const: d
description: foo
- const: c
description: foo
- const: zifencei
description: foo
- etc
Obviously with "foo" replaced by the existing descriptions in this
patch.
signature.asc
Description: PGP signature
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Mon, Jun 12, 2023 at 3:23 PM Conor Dooley wrote:
>
> Rob,
> Before I press on with more versions...
>
> On Thu, Jun 08, 2023 at 08:30:28PM +0100, Conor Dooley wrote:
> > On Thu, Jun 08, 2023 at 01:15:37PM -0600, Rob Herring wrote:
> > > On Tue, May 30, 2023 at 03:12:12PM +0100, Conor Dooley wrote:
> > > > On Thu, May 18, 2023 at 10:42:34PM +0100, Conor Dooley wrote:
> > > > > On Thu, May 18, 2023 at 02:30:53PM -0400, Sean Anderson wrote:
> > > >
> > > > > >
> > > > > > Why not just have something like
> > > > > >
> > > > > > mycpu {
> > > > > > ...
> > > > > > riscv,isa {
> > > > > > i;
> > > > > > m;
> > > > > > a;
> > > > > > zicsr;
> > > > > > ...
> > >
> > > I prefer property names be globally unique. The tools are geared towards
> > > that too. That's largely a symptom of having 0 type information in the
> > > DT.
> > >
> > > For example if you had an extension called 'reg', it would be a problem.
> >
> > Per the current ISA rules, that'd not be valid. But then again, I do
> > have trust issues & it's not like "reg" is the only property name in DT
> > land.
>
> ...you say "prefer" here. Is that a NAK, or a "you keep the pieces"?
Don't do the above node.
Rob
[PATCH] efi_selftests: fix protocol repeated selftesting
Running the protocols selftest more than one times fails with => setenv efi_selftest 'manage protocols' && bootefi selftest Testing EFI API implementation Selected test: 'manage protocols' Setting up 'manage protocols' Setting up 'manage protocols' succeeded Executing 'manage protocols' Executing 'manage protocols' succeeded Tearing down 'manage protocols' Tearing down 'manage protocols' succeeded Summary: 0 failures => bootefi selftest Testing EFI API implementation Selected test: 'manage protocols' Setting up 'manage protocols' lib/efi_selftest/efi_selftest_manageprotocols.c(88): ERROR: InstallProtocolInterface failed lib/efi_selftest/efi_selftest.c(89): ERROR: Setting up 'manage protocols' failed Tearing down 'manage protocols' Tearing down 'manage protocols' succeeded Summary: 1 failures The reason is that we don't set the handles to NULL after deleting and freeing them. As a result the subsequent protocol installation will try to use an existing handle which we just removed that from our object list. Signed-off-by: Ilias Apalodimas --- lib/efi_selftest/efi_selftest_manageprotocols.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/efi_selftest/efi_selftest_manageprotocols.c b/lib/efi_selftest/efi_selftest_manageprotocols.c index 8edb1e4d4671..097b2ae35456 100644 --- a/lib/efi_selftest/efi_selftest_manageprotocols.c +++ b/lib/efi_selftest/efi_selftest_manageprotocols.c @@ -79,6 +79,8 @@ static int setup(const efi_handle_t img_handle, efi_status_t ret; efi_handle_t handle; + handle1 = NULL; + handle2 = NULL; boottime = systable->boottime; ret = boottime->install_protocol_interface(&handle1, &guid3, -- 2.39.2
[PATCH] efi_selftests: fix controllers repeated selftesting
Running the controller selftest more than one times fails with
=> setenv efi_selftest 'controllers' && bootefi selftest
Testing EFI API implementation
Selected test: 'controllers'
Setting up 'controllers'
Setting up 'controllers' succeeded
Executing 'controllers'
Executing 'controllers' succeeded
Summary: 0 failures
=> bootefi selftest
Testing EFI API implementation
Selected test: 'controllers'
Setting up 'controllers'
lib/efi_selftest/efi_selftest_controllers.c(280):
ERROR: InstallProtocolInterface failed
lib/efi_selftest/efi_selftest.c(89):
ERROR: Setting up 'controllers' failed
Summary: 1 failures
There are multiple reason for this. We don't uninstall the binding
interface from the controller handle and we don't reset the handle
pointers either. So let's uninstall all the protocols properly and
reset the handles to NULL on setup().
While at it add a forgotten check when uninstalling protocols from the
handle_controller and make sure the number of child controllers is 0
Signed-off-by: Ilias Apalodimas
---
lib/efi_selftest/efi_selftest_controllers.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/lib/efi_selftest/efi_selftest_controllers.c
b/lib/efi_selftest/efi_selftest_controllers.c
index d2bbd1c4f65b..07a17ed866a9 100644
--- a/lib/efi_selftest/efi_selftest_controllers.c
+++ b/lib/efi_selftest/efi_selftest_controllers.c
@@ -271,6 +271,8 @@ static int setup(const efi_handle_t img_handle,
efi_status_t ret;
boottime = systable->boottime;
+ handle_controller = NULL;
+ handle_driver = NULL;
/* Create controller handle */
ret = boottime->install_protocol_interface(
@@ -402,8 +404,18 @@ static int execute(void)
/* Check number of child controllers */
ret = count_child_controllers(handle_controller, &guid_controller,
&count);
- if (ret == EFI_SUCCESS)
+ if (ret == EFI_SUCCESS || count != 0)
efi_st_error("Uninstall failed\n");
+
+ /* Uninstall binding protocol */
+ ret = boottime->uninstall_protocol_interface(handle_driver,
+
&guid_driver_binding_protocol,
+&binding_interface);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("Failed to uninstall protocols\n");
+ return EFI_ST_FAILURE;
+ }
+
return EFI_ST_SUCCESS;
}
--
2.39.2
Re: [PATCH] env: mmc: statically set the environment partition name
Hi,
On 6/13/23 13:05, Emmanuel Di Fede wrote:
The new opt-out setting, CONFIG_ENV_MMC_PARTITION, statically sets
the MMC environment partition name. Prior to this patch, the only way
to declare this partition name was by creating a
'u-boot,mmc-env-partition' parameter in the device-tree's /config node.
This setting provides additional flexibility, particularly in cases
where accessing the device-tree is not straightforward (e.g. QEMU).
If undeclared, the device-tree's setting will be used.
Signed-off-by: Emmanuel Di Fede
Cc: Joe Hershberger
Cc: Patrick Delaunay
---
doc/device-tree-bindings/config.txt | 2 ++
env/Kconfig | 8
env/mmc.c | 9 +++--
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/doc/device-tree-bindings/config.txt
b/doc/device-tree-bindings/config.txt
index 3151778b2c..f50c68bbdc 100644
--- a/doc/device-tree-bindings/config.txt
+++ b/doc/device-tree-bindings/config.txt
@@ -76,6 +76,8 @@ u-boot,mmc-env-partition (int)
precedence. In that case, only if the partition is not found,
mmc-env-offset* will be tried.
+ Note that CONFIG_ENV_MMC_PARTITION overrides this device-tree setting.
+
u-boot,no-apm-finalize (bool)
For x86 devices running on coreboot, this tells U-Boot not to lock
down the Intel Management Engine (ME) registers. This allows U-Boot to
diff --git a/env/Kconfig b/env/Kconfig
index 2bbe4c466a..de38b00bd1 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -659,6 +659,14 @@ config SYS_MMC_ENV_PART
partition 0 or the first boot partition, which is 1 or some other
defined
partition.
+config ENV_MMC_PARTITION
+ string "mmc environment partition name"
+ depends on ENV_IS_IN_MMC
+ help
+ MMC partition name used to save environment variables.
+ If this variable is unset, u-boot will try to get the env partition
name
+ from the DTB's /config node.
+
as it is sting this define is always activated => with default ""
if you want to test it with IS_ENABLED you need to add a other bolean config
I encounter the same issue several time
example: CONFIG_USE_DEFAULT_ENV_FILE/CONFIG_DEFAULT_ENV_FILE
CONFIG_USE_BOOTCOMMAND / CONFIG_BOOTCOMMAND
CONFIG_USE_BOOTARGS / CONFIG_BOOTARGS
sometthing like:
+config USE_ENV_MMC_PARTITION
+ boolean "use the mmc environment partition name"
+ depends on ENV_IS_IN_MMC
+config ENV_MMC_PARTITION
+ string "mmc environment partition name"
+ depends on USE_ENV_MMC_PARTITION
+ help
+ MMC partition name used to save environment variables.
+ If this variable is unset, u-boot will try to get the env partition
name
+ from the DTB's /config node.
config ENV_MMC_USE_DT
bool "Read partition name and offset in DT"
depends on ENV_IS_IN_MMC && OF_CONTROL
diff --git a/env/mmc.c b/env/mmc.c
index 7a5836ad66..887df61fbe 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -114,8 +114,13 @@ static inline s64 mmc_offset(struct mmc *mmc, int copy)
if (IS_ENABLED(CONFIG_SYS_MMC_ENV_PART))
hwpart = mmc_get_env_part(mmc);
- /* look for the partition in mmc CONFIG_SYS_MMC_ENV_DEV */
- str = ofnode_conf_read_str(dt_prop.partition);
+ if (IS_ENABLED(CONFIG_ENV_MMC_PARTITION)) {
see previous comment =>
if (IS_ENABLED(CONFIG_USE_ENV_MMC_PARTITION)) {
+ str = CONFIG_ENV_MMC_PARTITION;
+ } else {
+ /* look for the partition in mmc CONFIG_SYS_MMC_ENV_DEV */
+ str = ofnode_conf_read_str(dt_prop.partition);
+ }
I think it is can be simplified by using the macro with parameters
str = IS_ENABLED(CONFIG_USE_ENV_MMC_PARTITION,
CONFIG_ENV_MMC_PARTITION,
ofnode_conf_read_str(dt_prop.partition));
and that corrects a compilation issue when
CONFIG_USE_ENV_MMC_PARTITION / CONFIG_ENV_MMC_PARTITION
are not defined
+
if (str) {
/* try to place the environment at end of the partition */
err = mmc_offset_try_partition(str, copy, &val);
Patrick
Re: [PATCH] menu: Re-enable the ANSI codes
> From: Simon Glass
> Date: Mon, 12 Jun 2023 21:14:32 +0100
>
> The intent here was to allow ANSI codes to be disabled, since it was
> proving impoosible to test operation of the menu code when it kept moving
> the cursor. Unfortunately this ended up in the patch.
>
> Correct this by enabling ANSI again.
>
> Signed-off-by: Simon Glass
> Reported-by: Pali Rohár
> Reported-by: Mark Kettenis
> Reported-by: Frank Wunderlich
> Fixes: 32bab0eae51b ("menu: Make use of CLI character processing")
Tested-by: Mark Kettenis
Reviewed-by: Mark Kettenis
> ---
>
> common/menu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/menu.c b/common/menu.c
> index 94514177e4e9..b55cf7b99967 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -15,7 +15,7 @@
>
> #include "menu.h"
>
> -#define ansi 0
> +#define ansi 1
>
> /*
> * Internally, each item in a menu is represented by a struct menu_item.
> --
> 2.41.0.162.gfafddb0af9-goog
>
>
Re: [PATCH v2 4/4] net: add NFSv1 support
Am Di., 13. Juni 2023 um 13:24 Uhr schrieb Peter Robinson : > > > > To clarify a fact: I am happy with the patch. I am unhappy with the > > > wrong "naming" that my old > > > employer used and influenced this patch. Also the company is shipping > > > thousands of devices per > > > year where these patches are used. > > > > Further clean-ups and clarifications to the support here in terms of > > what it does and doesn't provide are good. But to the point on reviews, > > yes, I do wish we had more people interested in various areas, and with > > time to devote to reviewing code as well. Sadly, we don't always, and I > > took this particular set of patches as being small enough of a global > > impact while (hopefully!) making future contributions both in this area > > and the related platforms using it more likely. > > I understand your sentiment but even feedback for things like having > it behind a Kconfig option to opt into, especially for a default on > option, and CI weren't even addressed, it was just landed without > additional revisions. I feel some of those negate the "just land it" > sentiment. > Let's move a little bit back in time when I send out V2 of this series. When reading the cover letter thread again https://lore.kernel.org/u-boot/20230310095155.29832-1-christian.gmei...@gmail.com/ you had a very strong opinion against it Peter. After that I lost motivation on working on this series as I had the feeling you will always be against adding legacy stuff that is still used today. Tom had taken it and committed it to the master branch. Peter, If you feel better let's revert all the changes. -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy
[PATCH] env: mmc: statically set the environment partition name
The new opt-out setting, CONFIG_ENV_MMC_PARTITION, statically sets
the MMC environment partition name. Prior to this patch, the only way
to declare this partition name was by creating a
'u-boot,mmc-env-partition' parameter in the device-tree's /config node.
This setting provides additional flexibility, particularly in cases
where accessing the device-tree is not straightforward (e.g. QEMU).
If undeclared, the device-tree's setting will be used.
Signed-off-by: Emmanuel Di Fede
Cc: Joe Hershberger
Cc: Patrick Delaunay
---
doc/device-tree-bindings/config.txt | 2 ++
env/Kconfig | 8
env/mmc.c | 9 +++--
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/doc/device-tree-bindings/config.txt
b/doc/device-tree-bindings/config.txt
index 3151778b2c..f50c68bbdc 100644
--- a/doc/device-tree-bindings/config.txt
+++ b/doc/device-tree-bindings/config.txt
@@ -76,6 +76,8 @@ u-boot,mmc-env-partition (int)
precedence. In that case, only if the partition is not found,
mmc-env-offset* will be tried.
+ Note that CONFIG_ENV_MMC_PARTITION overrides this device-tree setting.
+
u-boot,no-apm-finalize (bool)
For x86 devices running on coreboot, this tells U-Boot not to lock
down the Intel Management Engine (ME) registers. This allows U-Boot to
diff --git a/env/Kconfig b/env/Kconfig
index 2bbe4c466a..de38b00bd1 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -659,6 +659,14 @@ config SYS_MMC_ENV_PART
partition 0 or the first boot partition, which is 1 or some other
defined
partition.
+config ENV_MMC_PARTITION
+ string "mmc environment partition name"
+ depends on ENV_IS_IN_MMC
+ help
+ MMC partition name used to save environment variables.
+ If this variable is unset, u-boot will try to get the env partition
name
+ from the DTB's /config node.
+
config ENV_MMC_USE_DT
bool "Read partition name and offset in DT"
depends on ENV_IS_IN_MMC && OF_CONTROL
diff --git a/env/mmc.c b/env/mmc.c
index 7a5836ad66..887df61fbe 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -114,8 +114,13 @@ static inline s64 mmc_offset(struct mmc *mmc, int copy)
if (IS_ENABLED(CONFIG_SYS_MMC_ENV_PART))
hwpart = mmc_get_env_part(mmc);
- /* look for the partition in mmc CONFIG_SYS_MMC_ENV_DEV */
- str = ofnode_conf_read_str(dt_prop.partition);
+ if (IS_ENABLED(CONFIG_ENV_MMC_PARTITION)) {
+ str = CONFIG_ENV_MMC_PARTITION;
+ } else {
+ /* look for the partition in mmc CONFIG_SYS_MMC_ENV_DEV */
+ str = ofnode_conf_read_str(dt_prop.partition);
+ }
+
if (str) {
/* try to place the environment at end of the partition */
err = mmc_offset_try_partition(str, copy, &val);
--
2.41.0
Re: [PATCH v2 4/4] net: add NFSv1 support
> > To clarify a fact: I am happy with the patch. I am unhappy with the > > wrong "naming" that my old > > employer used and influenced this patch. Also the company is shipping > > thousands of devices per > > year where these patches are used. > > Further clean-ups and clarifications to the support here in terms of > what it does and doesn't provide are good. But to the point on reviews, > yes, I do wish we had more people interested in various areas, and with > time to devote to reviewing code as well. Sadly, we don't always, and I > took this particular set of patches as being small enough of a global > impact while (hopefully!) making future contributions both in this area > and the related platforms using it more likely. I understand your sentiment but even feedback for things like having it behind a Kconfig option to opt into, especially for a default on option, and CI weren't even addressed, it was just landed without additional revisions. I feel some of those negate the "just land it" sentiment. Peter
[PATCH] watchdog: versal: Use new compatible xlnx,versal-wwdt
DT binding has been approved that's why use new compatible string.
The old one is mark as deprecated and should be removed after some
releases.
Link: https://lore.kernel.org/r/20230420104231.2243079-3-srinivas.ne...@amd.com/
Signed-off-by: Michal Simek
---
drivers/watchdog/xilinx_wwdt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/xilinx_wwdt.c b/drivers/watchdog/xilinx_wwdt.c
index d582e3cc8f41..8b6fc30edbe3 100644
--- a/drivers/watchdog/xilinx_wwdt.c
+++ b/drivers/watchdog/xilinx_wwdt.c
@@ -191,7 +191,8 @@ static const struct wdt_ops xlnx_wwdt_ops = {
};
static const struct udevice_id xlnx_wwdt_ids[] = {
- { .compatible = "xlnx,versal-wwdt-1.0", },
+ { .compatible = "xlnx,versal-wwdt", },
+ { .compatible = "xlnx,versal-wwdt-1.0", }, /* deprecated */
{},
};
--
2.36.1
[PATCH] usb: musb-new: sunxi: read SRAM controller address from DT
Some older SoCs (<=A20, F1C100s) do not have a dedicated SRAM buffer for
the USB-OTG controller, but require the CPU to relinquish one of its SRAM
blocks to the USB controller. This is done by flipping a bit in the SRAM
controller (aka "syscon").
So far we were doing this using the hardcoded SRAM controller address,
but that breaks the abstraction, and we can find that address in the DT.
Follow the "allwinner,sram" phandle property in the devicetree to get to
the SRAM node. The reg property in there gives us the SRAM MMIO address,
as seen by the CPU, but we need the SRAM *controller* address, which is
two levels up from that node.
Utilise U-Boot's DT code to do the traversal and DT address translation
for us, then store the controller address in the glue struct, to later
hand it to the routine that programs the SRAM controller.
This allows us to drop the usage of the hardcoded SUNXI_SRAMC_BASE from
the MUSB code.
Signed-off-by: Andre Przywara
---
Hi,
this patch goes on top of Sam's musb sunxi fixes. Can someone look at
the DT calls? There are quite some interfaces to U-Boot's DT framework,
so I want to be sure to got the right one.
If that patch looks fine, I would send a new series including Sam's two
patches, this patch here, and a (simple) patch adding F1C100s support.
Cheers,
Andre
drivers/usb/musb-new/sunxi.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 4bf0ee346a4..1da05e29a56 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -23,13 +23,12 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
#include
#include
+#include
#include
#include "linux-compat.h"
#include "musb_core.h"
@@ -93,6 +92,7 @@ struct sunxi_glue {
struct sunxi_musb_config *cfg;
struct device dev;
struct phy phy;
+ uintptr_t syscon_base;
};
#define to_sunxi_glue(d) container_of(d, struct sunxi_glue, dev)
@@ -181,6 +181,7 @@ static void USBC_ForceVbusValidToHigh(__iomem void *base)
*/
static void sunxi_musb_claim_sram(uintptr_t syscon_base)
{
+ debug("%s(0x%lx);\n", __func__, (unsigned long)syscon_base);
/*
* BIT(0) of SRAM_CTRL_REG1 (syscon+0x04) controls SRAM-D ownership:
* '0' -> exclusive access by CPU
@@ -326,7 +327,7 @@ static int sunxi_musb_init(struct musb *musb)
* block 'D', ownership of which needs to be handed over by
* the CPU
*/
- sunxi_musb_claim_sram(SUNXI_SRAMC_BASE);
+ sunxi_musb_claim_sram(glue->syscon_base);
}
USBC_EnableDpDmPullUp(musb->mregs);
@@ -450,6 +451,7 @@ static int musb_usb_probe(struct udevice *dev)
struct sunxi_glue *glue = dev_get_priv(dev);
struct musb_host_data *host = &glue->mdata;
struct musb_hdrc_platform_data pdata;
+ struct ofnode_phandle_args args;
void *base = dev_read_addr_ptr(dev);
int ret;
@@ -476,6 +478,24 @@ static int musb_usb_probe(struct udevice *dev)
return ret;
}
+ ret = dev_read_phandle_with_args(dev, "allwinner,sram", NULL, 1, 0,
+&args);
+ if (ret && ret != -ENOENT) {
+ dev_err(dev, "failed to get SRAM node\n");
+ return ret;
+ } else if (!ret) {
+ /* The SRAM *controller* address is in the grandparent node. */
+ ofnode node = ofnode_get_parent(ofnode_get_parent(args.node));
+ struct resource res;
+
+ ret = ofnode_read_resource(node, 0, &res);
+ if (ret) {
+ dev_err(dev, "failed to read SRAM controller base\n");
+ return ret;
+ }
+ glue->syscon_base = res.start;
+ }
+
ret = generic_phy_get_by_name(dev, "usb", &glue->phy);
if (ret) {
pr_err("failed to get usb PHY\n");
--
2.25.1
[RFC] disable NFS support by default
While NFS is widely used in data centres, and private networks it's quite a nuanced usecase for device firmware. A lot of devices already disable it. Various network protocols should really be opt in, not opt out, because they add extra size and are potential attack vectors from a security PoV. In the NFS case it doesn't really make sense for a lot of devices like tables, SBCs etc. It's also something we don't really want for SystemReady-IR due to security concerns. Signed-off-by: Peter Robinson --- This is a RFC to start a discussion around things like NFS, with the addistion of old protocols like NFSv1 that were never publicly released [1] we really shouldn't be enabling this by default. I am aware it will likely break the functionality for users that do use the various versions of NFS but it's straight forward to add CMD_NFS as an explicit config. It's for this reason I label the patch as RFC. There was about a 5Kb saving here when I tested a build with pinebook-pro-rk3399. Peter [1] https://en.wikipedia.org/wiki/Network_File_System cmd/Kconfig | 1 - configs/10m50_defconfig | 1 - configs/3c120_defconfig | 1 - configs/CMPC885_defconfig | 1 - configs/CMPCPRO_defconfig | 1 - configs/apalis-tk1_defconfig | 1 - configs/apalis_imx6_defconfig | 1 - configs/apalis_t30_defconfig | 1 - configs/bayleybay_defconfig | 1 - configs/beaver_defconfig | 1 - configs/bitmain_antminer_s9_defconfig | 1 - configs/brppt1_mmc_defconfig | 1 - configs/brppt2_defconfig | 1 - configs/brsmarc1_defconfig| 1 - configs/brxre1_defconfig | 1 - configs/cardhu_defconfig | 1 - configs/cei-tk1-som_defconfig | 1 - configs/cherryhill_defconfig | 1 - configs/chromebook_link64_defconfig | 1 - configs/chromebook_link_defconfig | 1 - configs/chromebook_samus_defconfig| 1 - configs/chromebox_panther_defconfig | 1 - configs/cm_t43_defconfig | 1 - configs/colibri_imx6_defconfig| 1 - configs/colibri_t20_defconfig | 1 - configs/colibri_t30_defconfig | 1 - configs/colibri_vf_defconfig | 1 - configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 - configs/conga-qeval20-qa3-e3845_defconfig | 1 - configs/coreboot64_defconfig | 1 - configs/coreboot_defconfig| 1 - configs/corstone1000_defconfig| 1 - configs/cougarcanyon2_defconfig | 1 - configs/crownbay_defconfig| 1 - configs/dalmore_defconfig | 1 - configs/dfi-bt700-q7x-151_defconfig | 1 - configs/edison_defconfig | 1 - configs/efi-x86_payload32_defconfig | 1 - configs/efi-x86_payload64_defconfig | 1 - configs/galileo_defconfig | 1 - configs/gazerbeam_defconfig | 1 - configs/ge_bx50v3_defconfig | 1 - configs/harmony_defconfig | 1 - configs/jetson-tk1_defconfig | 1 - configs/malta64_defconfig | 1 - configs/malta64el_defconfig | 1 - configs/malta_defconfig | 1 - configs/maltael_defconfig | 1 - configs/medcom-wide_defconfig | 1 - configs/minnowmax_defconfig | 1 - configs/mscc_jr2_defconfig| 1 - configs/mscc_luton_defconfig | 1 - configs/mscc_ocelot_defconfig | 1 - configs/mscc_serval_defconfig | 1 - configs/mscc_servalt_defconfig| 1 - configs/mt7620_mt7530_rfb_defconfig | 1 - configs/mt7620_rfb_defconfig | 1 - configs/mt7621_nand_rfb_defconfig | 1 - configs/mt7621_rfb_defconfig | 1 - configs/mt7623a_unielec_u7623_02_defconfig| 1 - configs/mt7623n_bpir2_defconfig
[PATCH 6/7] test: efi_capsule: Test capsule generation from config file
Support has been added to generate capsules through parameters
specified in the config file. To bring this under the testing ambit,
make changes in the EFI capsule test logic to generate the capsule
files by parsing the config file, when the path to the config file is
specified.
Signed-off-by: Sughosh Ganu
---
configs/sandbox_defconfig | 1 +
test/py/tests/test_efi_capsule/conftest.py| 106 +++---
.../test_efi_capsule/sandbox_capsule_cfg.txt | 75 +
3 files changed, 139 insertions(+), 43 deletions(-)
create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index d8a2386bb0..ba26816898 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -340,6 +340,7 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
+CONFIG_EFI_CAPSULE_CFG_FILE="/tmp/capsules/sandbox_capsule_cfg.txt"
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index 4269c41a74..4eb54c1a61 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -42,21 +42,6 @@ def efi_capsule_data(request, u_boot_config):
check_call('cd %s; %s/tools/mkimage -f uboot_bin_env.its
uboot_bin_env.itb' %
(data_dir, u_boot_config.build_dir),
shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
09D7CF52-0720-4710-91D1-08469B7FE9C8 u-boot.bin.new Test01' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 2 --guid
5A7021F5-FEF2-48B4-AABA-832E777418C0 u-boot.env.new Test02' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
058B7D83-50D5-4C47-A195-60D86AD341C4 u-boot.bin.new Test03' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
3673B45D-6A7C-46F3-9E60-ADABB03F7937 uboot_bin_env.itb Test04' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
058B7D83-50D5-4C47-A195-60D86AD341C4 uboot_bin_env.itb Test05' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
capsule_auth_enabled = u_boot_config.buildconfig.get(
'config_efi_capsule_authenticate')
@@ -66,40 +51,75 @@ def efi_capsule_data(request, u_boot_config):
check_call('cp %s/arch/sandbox/dts/test.dtb %s/test_sig.dtb' %
(u_boot_config.build_dir, data_dir), shell=True)
-# raw firmware signed with proper key
-check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER.key --certificate SIGNER.crt
'
-'--guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 '
-'u-boot.bin.new Test11'
- % (data_dir, u_boot_config.build_dir),
+cfg_file = u_boot_config.buildconfig.get(
+'config_efi_capsule_cfg_file')[1:-1]
+if cfg_file:
+capsules_path_dir = '/tmp/capsules/'
+check_call('mkdir -p %s ;'
+ 'cp -a %s/* %s/' % (capsules_path_dir, data_dir,
capsules_path_dir),
shell=True)
-# raw firmware signed with *mal* key
-check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER2.key '
-'--certificate SIGNER2.crt '
-'--guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 '
-'u-boot.bin.new Test12'
- % (data_dir, u_boot_config.build_dir),
+check_call(' cp
%s/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt %s'
+ % (u_boot_config.source_dir, capsules_path_dir),
shell=True)
-# FIT firmware signed with proper key
check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER.key --certificate SIGNER.crt
'
-'--guid 3673B45D-6A7C-46F3-9E60-ADABB03F7937 '
-'uboot_bin_env.itb Test13'
- % (data_dir, u_boot_config.build_dir),
+ 'make capsule O=%s' % (u_boot_config.source_d
[PATCH 7/7] doc: Add documentation to describe capsule config file format
The UEFI capsule can be generated either through command-line
parameters, or, by specifying those in a config file. Add
documentation to describe the format of the config file.
Signed-off-by: Sughosh Ganu
---
doc/develop/uefi/uefi.rst | 64 +++
1 file changed, 64 insertions(+)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index f96762af39..09b32c9921 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -442,6 +442,70 @@ following command can be issued
--guid c1b629f1-ce0e-4894-82bf-f0a38387e630 \
optee.bin optee.capsule
+Or alternatively, the capsule can be generated through a make target
+
+.. code-block:: bash
+
+$ make capsule
+
+Issuing the above make command requires specifying the capsule
+parameters through a config file instead. The Kconfig symbol
+CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the path to
+the config file.
+
+The config file describes the parameters that are used for generating
+one or more capsules. The parameters for a given capsule file are
+specified within curly braces, in the form of "key:value" pairs. All
+the parameters that are currently supported by the mkeficapsule tool
+can be specified through the config file.
+
+The following are some example payload parameters specified through
+the config file.
+
+.. code-block:: none
+
+ {
+ image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
+ hardware-instance: 0
+ monotonic-count: 1
+ payload: u-boot.bin
+ image-index: 1
+ private-key: /path/to/priv/key
+ pub-key-cert: /path/to/pub/key
+ capsule: u-boot.capsule
+ }
+ {
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ hardware-instance: 0
+ payload: u-boot.itb
+ image-index: 2
+ oemflags: 0x8000
+ capsule: fit.capsule
+ }
+ {
+ capsule-type: accept
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ capsule: accept.capsule
+ }
+ {
+ capsule-type: revert
+ capsule: revert.capsule
+ }
+
+The following are the keys that specify the capsule parameters
+
+..code-block:: none
+
+image-guid: Image GUID
+image-index: Image index value
+private-key: Path to the private key file used for capsule signing
+pub-key-cert: Path to the public key crt file used for capsule signing
+payload: Path to the capsule payload file
+capsule: Path to the output capsule file that is generated
+hardware-instance: Hardware Instance value
+monotonic-count: Monotonic count value
+capsule-type: Specifies capsule type. normal(default), accept or revert
+oemflags: 16bit Oemflags value to be used(populated in capsule header)
Enabling Capsule Authentication
***
--
2.34.1
[PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through a
single invocation of the command.
This path is to be used for generating capsules through a make target,
with the parameters being parsed from the config file.
Signed-off-by: Sughosh Ganu
---
tools/Kconfig | 9 +
tools/Makefile | 1 +
tools/eficapsule.h | 110
tools/mkeficapsule.c | 106 +++-
tools/mkeficapsule_parse.c | 345 +
5 files changed, 531 insertions(+), 40 deletions(-)
create mode 100644 tools/mkeficapsule_parse.c
diff --git a/tools/Kconfig b/tools/Kconfig
index 539708f277..95f27b7c45 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
optionally sign that file. If you want to enable UEFI capsule
update feature on your target, you certainly need this.
+config EFI_CAPSULE_CFG_FILE
+ string "Path to the EFI Capsule Config File"
+ default ""
+ help
+ Path to the EFI capsule config file which provides the
+ parameters needed to build capsule(s). Parameters can be
+ provided for multiple payloads resulting in corresponding
+ capsule images being generated.
+
menuconfig FSPI_CONF_HEADER
bool "FlexSPI Header Configuration"
help
diff --git a/tools/Makefile b/tools/Makefile
index d793cf3bec..ef366f3d61 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
+mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
# We build some files with extra pedantic flags to try to minimize things
# that won't build on some weird host compiler -- though there are lots of
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
index 072a4b5598..42e66c6d6a 100644
--- a/tools/eficapsule.h
+++ b/tools/eficapsule.h
@@ -52,6 +52,38 @@ typedef struct {
/* flags */
#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
+enum capsule_type {
+ CAPSULE_NORMAL_BLOB = 0,
+ CAPSULE_ACCEPT,
+ CAPSULE_REVERT,
+};
+
+/**
+ * struct efi_capsule_params - Capsule parameters
+ * @image_guid: Guid value of the payload input image
+ * @image_index: Image index value
+ * @hardware_instance: Hardware instance to be used for the image
+ * @monotonic_count: Monotonic count value to be used for signed capsule
+ * @privkey_file: Path to private key used in capsule signing
+ * @cert_file: Path to public key certificate used in capsule signing
+ * @input_file: Path to payload input image
+ * @capsule_file: Path to the output capsule file
+ * @oemflags: Oemflags to be populated in the capsule header
+ * @capsule: Capsule Type, normal or accept or revert
+ */
+struct efi_capsule_params {
+ efi_guid_t *image_guid;
+ unsigned long image_index;
+ unsigned long hardware_instance;
+ uint64_t monotonic_count;
+ char *privkey_file;
+ char *cert_file;
+ char *input_file;
+ char *capsule_file;
+ unsigned long oemflags;
+ enum capsule_type capsule;
+};
+
struct efi_capsule_header {
efi_guid_t capsule_guid;
uint32_t header_size;
@@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
struct win_certificate_uefi_guid auth_info;
} __packed;
+/**
+ * capsule_with_cfg_file() - Generate capsule from config file
+ * @cfg_file: Path to the config file
+ *
+ * Parse the capsule parameters from the config file and use the
+ * parameters for generating one or more capsules.
+ *
+ * Return: None
+ *
+ */
+void capsule_with_cfg_file(const char *cfg_file);
+
+/**
+ * convert_uuid_to_guid() - convert UUID to GUID
+ * @buf: UUID binary
+ *
+ * UUID and GUID have the same data structure, but their binary
+ * formats are different due to the endianness. See lib/uuid.c.
+ * Since uuid_parse() can handle only UUID, this function must
+ * be called to get correct data for GUID when parsing a string.
+ *
+ * The correct data will be returned in @buf.
+ */
+void convert_uuid_to_guid(unsigned char *buf);
+
+/**
+ * create_empty_capsule() - Generate an empty capsule
+ * @path: Path to the empty capsule file to be generated
+ * @guid: Guid value of the image for which empty capsule is generated
+ * @fw_accept: Flag to specify whether to generate accept or revert capsule
+ *
+ * Generate an empty capsule, either an accept or a revert capsule to be
+ * used to flag acceptance or rejection of an earlier executed firmware
+ * update operation. Being used in the FWU Multi Bank firmware update
+ * feature.
+ *
+ * Return: 0 if OK, -ve on error
+ *
+ */
+int create_empty_capsule(char
[PATCH 5/7] Makefile: Add a target for building capsules
Add a target for building EFI capsules. The capsule parameters are specified through a config file, and the path to the config file is specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the config file is not specified, the command only builds tools. Signed-off-by: Sughosh Ganu --- Makefile | 9 + 1 file changed, 9 insertions(+) diff --git a/Makefile b/Makefile index 10bfaa52ad..96db29aa77 100644 --- a/Makefile +++ b/Makefile @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb dts/dt.dtb: u-boot $(Q)$(MAKE) $(build)=dts dtbs +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ + +PHONY += capsule +capsule: tools +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") + $(call cmd,mkeficapsule) +endif + quiet_cmd_copy = COPY$@ cmd_copy = cp $< $@ -- 2.34.1
[PATCH 3/7] doc: capsule: Document the new mechanism to embed ESL file into dtb
Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the u-boot build.
Signed-off-by: Sughosh Ganu
---
doc/develop/uefi/uefi.rst | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index ffe25ca231..f96762af39 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -495,20 +495,11 @@ and used by the steps highlighted below.
...
}
-You can do step-4 manually with
-
-.. code-block:: console
-
-$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
-$ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo
-
-where signature.dts looks like::
-
-&{/} {
-signature {
-capsule-key = /incbin/("CRT.esl");
-};
-};
+You can perform step-4 by defining the Kconfig symbol
+CONFIG_EFI_CAPSULE_ESL_FILE. This symbol defines the path to the esl
+file generated in step-2. Once the symbol has been populated with the
+path to the esl file, the esl file will automatically get embedded
+into the platform's dtb as part of u-boot build.
Executing the boot manager
~~
--
2.34.1
[PATCH 2/7] test: py: Generate capsule keys prior to building u-boot
Currently, the keys and the EFI Signature List(ESL) file used for
capsule authentication can be generated after the u-boot image has
been built. The ESL file is then manually embedded into the platform's
dtb for capsule authentication.
This flow has been changed through an earlier commit, which embeds the
ESL file into the platform's dtb(s) as part of the u-boot build. This
requires generating the keys and the ESL file prior to invoking the
u-boot build.
Bring about the same sequence of generating these files prior to
invoking the u-boot build while testing.
Signed-off-by: Sughosh Ganu
---
configs/sandbox_defconfig| 1 +
configs/sandbox_flattree_defconfig | 1 +
test/py/conftest.py | 64
test/py/tests/test_efi_capsule/conftest.py | 38 +++-
test/py/tests/test_efi_capsule/signature.dts | 10 ---
5 files changed, 74 insertions(+), 40 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/signature.dts
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 1ec44d5b33..d8a2386bb0 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -339,6 +339,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index e7657d40dc..8d60744771 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -226,6 +226,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
diff --git a/test/py/conftest.py b/test/py/conftest.py
index fc9dd3a83f..b7166508d4 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -80,6 +80,65 @@ def pytest_addoption(parser):
help='Run sandbox under gdbserver. The argument is the channel '+
'over which gdbserver should communicate, e.g. localhost:1234')
+def setup_capsule_auth_build(source_dir, build_dir, board_type, log):
+"""Setup the platform's build for capsule authenticate
+
+This generates the signatures needed for signing the capsules along
+with the EFI Signature List(ESL) file, with the capsule
+authentication feature enabled.
+
+The ESL file is subsequently embedded into the platform's
+dtb during the u-boot build, to be used for capsule
+authentication.
+
+Two sets of signatures are generated, namely SIGNER and SIGNER2.
+The SIGNER2 key pair is used as a malicious key for testing the
+the capsule authentication functionality.
+
+Args:
+soruce_dir (str): Directory containing source code
+build_dir (str): Directory to build in
+board_type (str): board_type parameter (e.g. 'sandbox')
+log (Logfile): Log file to use
+
+Returns:
+Nothing.
+"""
+def run_command(name, cmd, source_dir):
+with log.section(name):
+if isinstance(cmd, str):
+cmd = cmd.split()
+runner = log.get_runner(name, None)
+runner.run(cmd, cwd=source_dir)
+runner.close()
+log.status_pass('OK')
+
+capsule_sig_dir = '/tmp/capsules/'
+sig_name = 'SIGNER'
+mkdir_p(capsule_sig_dir)
+name = 'openssl'
+cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout %s%s.key '
+'-out %s%s.crt -nodes -days 365'
+% (capsule_sig_dir, sig_name, capsule_sig_dir, sig_name)
+ )
+run_command(name, cmd, source_dir)
+
+name = 'cert-to-efi-sig-list'
+cmd = ( 'cert-to-efi-sig-list %s%s.crt %s%s.esl'
+% (capsule_sig_dir, sig_name, capsule_sig_dir, sig_name)
+ )
+run_command(name, cmd, source_dir)
+
+sig_name = 'SIGNER2'
+name = 'openssl'
+cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout %s%s.key '
+'-out %s%s.crt -nodes -days 365'
+% (capsule_sig_dir, sig_name, capsule_sig_dir, sig_name)
+ )
+run_command(name, cmd, source_dir)
+
def run_build(config, source_dir, build_dir, board_type, log):
"""run_build: Build U-Boot
@@ -102,6 +161,11 @@ def run_build(config, source_dir, build_dir, board_type,
log):
o_opt = 'O=%s' % build_dir
else:
o_opt = ''
+
+capsule_auth_boards = ( 'sandbox', 'sandbox_flattree' )
+if board_type in capsule_auth_boards:
+setup_capsule_auth_build(source_dir, build_dir, board_type, log)
+
cmds = (
['make', o_opt, '-s', board_type + '_defconfig'],
[PATCH 1/7] capsule: authenticate: Embed capsule public key in platform's dtb
The EFI capsule authentication logic in u-boot expects the public key
in the form of an EFI Signature List(ESL) to be provided as part of
the platform's dtb. Currently, the embedding of the ESL file into the
dtb needs to be done manually.
Add a script for embedding the ESL used for capsule authentication in
the platform's dtb, and call this as part of building the dtb(s). This
brings the embedding of the ESL in the dtb into the u-boot build flow.
The path to the ESL file is specified through the
CONFIG_EFI_CAPSULE_ESL_FILE symbol.
Signed-off-by: Sughosh Ganu
---
lib/efi_loader/Kconfig | 11 +++
scripts/Makefile.lib | 8
scripts/embed_capsule_key.sh | 25 +
3 files changed, 44 insertions(+)
create mode 100755 scripts/embed_capsule_key.sh
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c5835e6ef6..1326a1d109 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -234,6 +234,17 @@ config EFI_CAPSULE_MAX
Select the max capsule index value used for capsule report
variables. This value is used to create CapsuleMax variable.
+config EFI_CAPSULE_ESL_FILE
+ string "Path to the EFI Signature List File"
+ default ""
+ depends on EFI_CAPSULE_AUTHENTICATE
+ help
+ Provides the absolute path to the EFI Signature List
+ file which will be embedded in the platform's device
+ tree and used for capsule authentication at the time
+ of capsule update.
+
+
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 7b27224b5d..a4083d0a26 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -192,6 +192,8 @@ dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc
\
-D__ASSEMBLY__ \
-undef -D__DTS__
+export dtc_cpp_flags
+
# Finds the multi-part object the current object will be linked into
modname-multi = $(sort $(foreach m,$(multi-used),\
$(if $(filter $(subst $(obj)/,,$*.o), $($(m:.o=-objs))
$($(m:.o=-y))),$(m:.o=
@@ -315,6 +317,9 @@ ifeq ($(CONFIG_OF_LIBFDT_OVERLAY),y)
DTC_FLAGS += -@
endif
+quiet_cmd_embedcapsulekey = EMBEDCAPSULEKEY $@
+cmd_embedcapsulekey = $(srctree)/scripts/embed_capsule_key.sh $@
+
quiet_cmd_dtc = DTC $@
# Modified for U-Boot
# Bring in any U-Boot-specific include at the end of the file
@@ -333,6 +338,9 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
$(obj)/%.dtb: $(src)/%.dts FORCE
$(call if_changed_dep,dtc)
+ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
+ $(call cmd,embedcapsulekey,$@)
+endif
pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
diff --git a/scripts/embed_capsule_key.sh b/scripts/embed_capsule_key.sh
new file mode 100755
index 00..1c2e45f758
--- /dev/null
+++ b/scripts/embed_capsule_key.sh
@@ -0,0 +1,25 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2023, Linaro Limited
+#
+
+gen_capsule_signature_file() {
+cat >> $1 << EOF
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+};
+EOF
+}
+
+gen_capsule_signature_file signature.$$.dts > /dev/null 2>&1
+$CPP $dtc_cpp_flags -x assembler-with-cpp -o signature.$$.tmp signature.$$.dts
> /dev/null 2>&1
+dtc -@ -O dtb -o signature.$$.dtbo signature.$$.tmp > /dev/null 2>&1
+fdtoverlay -i $1 -o temp.$$.dtb -v signature.$$.dtbo > /dev/null 2>&1
+mv temp.$$.dtb $1 > /dev/null 2>&1
+rm -f signature.$$.* > /dev/null 2>&1
--
2.34.1
[PATCH 0/7] Integrate EFI capsule tasks into u-boot's build flow
This patchset aims to bring two capsule related tasks under the u-boot build flow. One is the embedding of the public key into the platform's dtb as part of dtb' build. The public key is in the form of an EFI Signature List(ESL) file and is used for capsule authentication. This is achieved at the time of the dtb generation, with the path to the ESL file being provided through a Kconfig symbol(CONFIG_EFI_CAPSULE_ESL_FILE). Changes have also been made to the test flow so that the keys used for signing the capsule, and the ESL file, are generated prior to invoking the u-boot's build, which enables embedding the ESL file into the dtb as part of the u-boot build flow. The other task is to add a make target for generating capsules. This is being achieved by adding support for parsing a config file to get the capsule generation parameters. Multiple payloads can be specified, resulting in generation of multiple capsules with a single invocation of the command. The path to the config file is to be specified through a Kconfig symbol(CONFIG_EFI_CAPSULE_CFG_FILE). Changes have also been made to the efi capsule test setup, whereby, with the above config symbol having been populated, the capsule files are generated through the make capsule command. The requisite config file has been placed under the test/py/tests/test_efi_capsule/ directory, which results in generation of the same set of capsule files. Currently, the capsule authentication feature is tested on the sandbox and sandbox_flattree variants. The capsule generation through config file is enabled for the sandbox variant, with the sandbox_flattree variant generating capsules through the command-line parameters. The document has been updated to reflect the above changes. Sughosh Ganu (7): capsule: authenticate: Embed capsule public key in platform's dtb test: py: Generate capsule keys prior to building u-boot doc: capsule: Document the new mechanism to embed ESL file into dtb tools: mkeficapsule: Add support for parsing capsule params from config file Makefile: Add a target for building capsules test: efi_capsule: Test capsule generation from config file doc: Add documentation to describe capsule config file format Makefile | 9 + configs/sandbox_defconfig | 2 + configs/sandbox_flattree_defconfig| 1 + doc/develop/uefi/uefi.rst | 83 - lib/efi_loader/Kconfig| 11 + scripts/Makefile.lib | 8 + scripts/embed_capsule_key.sh | 25 ++ test/py/conftest.py | 64 test/py/tests/test_efi_capsule/conftest.py| 144 .../test_efi_capsule/sandbox_capsule_cfg.txt | 75 test/py/tests/test_efi_capsule/signature.dts | 10 - tools/Kconfig | 9 + tools/Makefile| 1 + tools/eficapsule.h| 110 ++ tools/mkeficapsule.c | 106 -- tools/mkeficapsule_parse.c| 345 ++ 16 files changed, 866 insertions(+), 137 deletions(-) create mode 100755 scripts/embed_capsule_key.sh create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt delete mode 100644 test/py/tests/test_efi_capsule/signature.dts create mode 100644 tools/mkeficapsule_parse.c -- 2.34.1
Re: [PATCH v6 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support
9 червня 2023 р. 07:34:41 GMT+03:00, Svyatoslav Ryhel написав(-ла): >This patchset adds support for native use of U-Boot on: >- ASUS T30 Transformers (7 devices, all models); >- ASUS/Google Nexus 7 (2012), both grouper and tilapia >- LG Optimus 4X HD (P880) and Optimus Vu (P895) >- HTC One X (endeavoru) >as a replacement for the vendor bootloader. > >Current commits are designed to work on re-crypted devices but can >be used on clean unmodified devices with slight restrictions (like >no booting/mounting emmc and no self updating feature). > >All device setup commits fall under the same pattern. Alongside device >bringup tegra requires few small patches: > - add gpio keyboard as stdin device > - make networking boot options optional > - add a small tool to generate SoC UID > >Commits passed ./tools/buildman/buildman tegra >Building current source for 30 boards (12 threads, 1 job per thread) > 3000 /30 0:00:06 : apalis_t30 >Completed: 30 total built, 30 newly), duration 0:05:23, rate 0.09 > >Passed 50/53 GitLab CI Pipelines and then I ran off CI minures. > >--- >Changes from v5: >- fixed maintained files inclusion > >Changes from v4: >- fixed documentation >- fixed CONFIG_* definitions > >Changes from v3: >- extended amount of devices supported > >Changes from v2: > - fuse build is excluded for T186 (it is not supported in it anyway) > >Changes from v1: > - fix fuse headers for newer Tegra generations > - allow grouper_common_defconfig to pass without fragments >--- > >Jonas Schwöbel (1): > configs: tegra-common-post: make PXE and DHCP boot targets optional > >Svyatoslav Ryhel (6): > configs: tegra-common-post: add GPIO keyboard as STDIN device > ARM: tegra: add SoC UID calculation function > board: asus: transformer: add ASUS Transformer T30 family support > board: asus: grouper: add Google Nexus 7 (2012) support > board: lg: x3: add Optimus 4X HD and Optimus Vu support > board: htc: endeavoru: add One X support > > arch/arm/dts/Makefile | 12 + > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 157 ++ > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 43 ++ > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 36 ++ > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 62 +++ > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 + > arch/arm/dts/tegra30-asus-tf201.dts | 9 + > arch/arm/dts/tegra30-asus-tf300t.dts | 18 + > arch/arm/dts/tegra30-asus-tf300tg.dts | 9 + > arch/arm/dts/tegra30-asus-tf300tl.dts | 9 + > arch/arm/dts/tegra30-asus-tf600t.dts | 89 > arch/arm/dts/tegra30-asus-tf700t.dts | 13 + > arch/arm/dts/tegra30-asus-transformer.dtsi| 211 > arch/arm/dts/tegra30-htc-endeavoru.dts| 166 +++ > arch/arm/dts/tegra30-lg-p880.dts | 40 ++ > arch/arm/dts/tegra30-lg-p895.dts | 50 ++ > arch/arm/dts/tegra30-lg-x3.dtsi | 180 +++ > arch/arm/include/asm/arch-tegra/fuse.h| 7 + > arch/arm/mach-tegra/Makefile | 4 + > arch/arm/mach-tegra/fuse.c| 151 ++ > arch/arm/mach-tegra/tegra30/Kconfig | 20 + > board/asus/grouper/Kconfig| 22 + > board/asus/grouper/MAINTAINERS| 10 + > board/asus/grouper/Makefile | 14 + > board/asus/grouper/grouper-spl-max.c | 45 ++ > board/asus/grouper/grouper-spl-ti.c | 41 ++ > board/asus/grouper/grouper.c | 202 > board/asus/grouper/pinmux-config-grouper.h| 362 ++ > board/asus/transformer-t30/Kconfig| 23 + > board/asus/transformer-t30/MAINTAINERS| 15 + > board/asus/transformer-t30/Makefile | 11 + > .../pinmux-config-transformer.h | 365 ++ > .../transformer-t30/transformer-t30-spl.c | 41 ++ > board/asus/transformer-t30/transformer-t30.c | 201 > board/htc/endeavoru/Kconfig | 12 + > board/htc/endeavoru/MAINTAINERS | 7 + > board/htc/endeavoru/Makefile | 11 + > board/htc/endeavoru/endeavoru-spl.c | 47 ++ > board/htc/endeavoru/endeavoru.c | 116 + > board/htc/endeavoru/pinmux-config-endeavoru.h | 362 ++ > board/lg/x3-t30/Kconfig | 26 + > board/lg/x3-t30/MAINTAINERS | 9 + > board/lg/x3-t30/Makefile | 11 + > board/lg/x3-t30/pinmux-config-x3.h| 449 ++ > board/lg/x3-t30/x3-t30-spl.c | 48 ++ > board/lg/x3-t30/x3-t30.c | 176 +++ > configs/endeavoru_defconfig | 84 > configs/grouper_E1565.config | 2 + > configs/grouper_PM269.config | 2 + > configs/grouper_common_defconfig | 84 > configs/p1801-t.config| 2 + > configs/p880.config
Re: [PATCH v2 4/4] net: add NFSv1 support
> I can help with reviews in this area. In this case, please CC me. I suggest adding yourself to the MAINTAINERS file as a reviewer, people won't know you've offered and in a year Tom may not remember.
[PATCH 1/1] bootm: don't call booti_setup for EFI images
On the arm64 architecture booti_setup() is called for EFI FIT images.
This function call fails because EFI images typically do not have a
kernel signature.
Check that the operating system property "os" of the image is "linux"
before invoking booti_setup().
Fixes: 487b5fa6deb1 ("bootm: Handle kernel_noload on arm64")
Signed-off-by: Heinrich Schuchardt
---
boot/bootm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 4144ff3b03..75f0b4a9af 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -240,7 +240,8 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag,
int argc,
if (images.os.type == IH_TYPE_KERNEL_NOLOAD) {
if (IS_ENABLED(CONFIG_CMD_BOOTI) &&
- images.os.arch == IH_ARCH_ARM64) {
+ images.os.arch == IH_ARCH_ARM64 &&
+ images.os.os == IH_OS_LINUX) {
ulong image_addr;
ulong image_size;
--
2.40.1
Pull request for tpm-for_tom-13062023
Hi Tom, The following changes since commit 260d4962e06c0a7d2713523c131416a3f70d7f2c: Merge tag v2023.07-rc4 into next (2023-06-12 14:55:33 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-for_tom-13062023 for you to fetch changes up to 011f015540d788227a1a2d16dd6245120827bdec: test/py: Account PCR updates properly during testing (2023-06-13 08:51:07 +0300) The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/16574 showed no issues In order to initialize a tpm device we usually need the following command sequence - tpm init - tpm startup TPM2_SU_CLEAR - tpm2 self_test full A few months ago we added a tpm_autostart() function which wraps that in a single function and always initializes the tpm correctly. We can now provide a command line for that function and simplify our CLI. Ilias Apalodimas (3): tpm: Add 'tpm autostart' shell command test/py: replace 'tpm2 init, startup, selftest' sequences test/py: Account PCR updates properly during testing cmd/tpm-common.c | 16 cmd/tpm-user-utils.h | 1 + cmd/tpm-v1.c | 6 +- cmd/tpm-v2.c | 6 ++ test/py/tests/test_tpm2.py | 19 --- 5 files changed, 36 insertions(+), 12 deletions(-)
Re: [PATCH v2 5/5] rockchip: rockpro64: Build u-boot-rockchip-spi.bin
On Mon, Jun 12, 2023 at 11:20 PM Jonas Karlman wrote: > > Hi Peter, > > On 2023-06-11 22:22, Peter Robinson wrote: > > Hi Jonas, > > > > This regresses the Rockpro64 build for me when building with gcc 12/13 > > with the following error, if I remove CONFIG_LTO it builds, but > > overlaps. > > > > /usr/bin/aarch64-linux-gnu-ld: > > /usr/lib/gcc/aarch64-linux-gnu/13/libgcc.a(lse-init.o): in function > > `init_have_lse_atomics': > > /builddir/build/BUILD/gcc-13.1.1-20230519/aarch64-linux-gnu/aarch64-linux-gnu/libgcc/../../../gcc-13.1.1-20230519/libgcc/config/aarch64/lse-init.c:46: > > undefined reference to `__getauxval' > > collect2: fatal error: ld terminated with signal 11 [Segmentation > > fault], core dumped > > compilation terminated. > > Interesting, my test build using ubuntu-22.04 and gcc-12 did not seem > to fail, see [1]. Compiling with -mno-outline-atomics flag may work, not > sure that is a good workaround. I would prefer a fix. > An alternative could be to move the payload to @ 512KB instead of @ 384KB. What impact will moving this around have on upgrades? I am not sure we should be randomly moving stuff without knowing the impact TBH. Will this break existing users vs what you feel is appropriate for your usecase? > configs/rockpro64-rk3399_defconfig: > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 > > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi: > u-boot,spl-payload-offset = <0x8>; > > > [1] > https://github.com/Kwiboo/u-boot-build/actions/runs/5248398191/jobs/9479827969 > > Regards, > Jonas > > > > > Peter > > > > On Wed, May 17, 2023 at 7:41 PM Jonas Karlman wrote: > >> > >> Enable CONFIG_ROCKCHIP_SPI_IMAGE to build u-boot-rockchip-spi.bin. > >> Define CONFIG_SYS_SPI_U_BOOT_OFFS to write u-boot.itb at the expected > >> offset. Enable CONFIG_LTO to reduce size of SPL so that the mkimage > >> output fit before the 0x6 offset in u-boot-rockchip-spi.bin. > >> > >> => sf probe > >> SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total > >> 16 MiB > >> => load mmc 1:1 1000 u-boot-rockchip-spi.bin > >> 1442304 bytes read in 27 ms (50.9 MiB/s) > >> => sf update $fileaddr 0 $filesize > >> device 0 offset 0x0, size 0x160200 > >> 1421824 bytes written, 20480 bytes skipped in 9.501s, speed 155432 B/s > >> > >> Signed-off-by: Jonas Karlman > >> Reviewed-by: Kever Yang > >> --- > >> v2: > >> - Collect r-b tag > >> > >> configs/rockpro64-rk3399_defconfig | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/configs/rockpro64-rk3399_defconfig > >> b/configs/rockpro64-rk3399_defconfig > >> index 0ca2cecade25..f41c03067903 100644 > >> --- a/configs/rockpro64-rk3399_defconfig > >> +++ b/configs/rockpro64-rk3399_defconfig > >> @@ -11,6 +11,7 @@ CONFIG_ENV_OFFSET=0x3F8000 > >> CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64" > >> CONFIG_DM_RESET=y > >> CONFIG_ROCKCHIP_RK3399=y > >> +CONFIG_ROCKCHIP_SPI_IMAGE=y > >> CONFIG_TARGET_ROCKPRO64_RK3399=y > >> CONFIG_SPL_STACK=0x40 > >> CONFIG_DEBUG_UART_BASE=0xFF1A > >> @@ -20,6 +21,7 @@ CONFIG_SPL_SPI=y > >> CONFIG_SYS_LOAD_ADDR=0x800800 > >> CONFIG_PCI=y > >> CONFIG_DEBUG_UART=y > >> +CONFIG_LTO=y > >> CONFIG_SPL_FIT_SIGNATURE=y > >> CONFIG_BOOTSTAGE=y > >> CONFIG_BOOTSTAGE_REPORT=y > >> @@ -37,6 +39,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 > >> CONFIG_SPL_STACK_R=y > >> CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 > >> CONFIG_SPL_SPI_LOAD=y > >> +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 > >> CONFIG_TPL=y > >> CONFIG_CMD_BOOTZ=y > >> CONFIG_CMD_GPT=y > >> -- > >> 2.40.1 > >> >
[PATCH v1 4/4] misc: nuvoton: fix type error
Signed-off-by: Jim Liu
---
drivers/misc/npcm_otp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/npcm_otp.c b/drivers/misc/npcm_otp.c
index 304910888b..08029724c0 100644
--- a/drivers/misc/npcm_otp.c
+++ b/drivers/misc/npcm_otp.c
@@ -33,7 +33,7 @@ static int npcm_otp_check_inputs(u32 arr, u32 word)
if (arr >= NPCM_NUM_OF_SA) {
if (IS_ENABLED(CONFIG_ARCH_NPCM8XX))
printf("\nError: npcm8XX otp includs only one bank:
0\n");
- if (IS_ENABLED(CONFIG_ARCH_NPCM7XX))
+ if (IS_ENABLED(CONFIG_ARCH_NPCM7xx))
printf("\nError: npcm7XX otp includs only two banks: 0
and 1\n");
return -1;
}
--
2.17.1
[PATCH v1 3/4] ARM: dts: npcm8xx: fix dts node error
The SHA and OTP should under the ahb node
Signed-off-by: Jim Liu
---
arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi | 33
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi
b/arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi
index be2ad0cf6c..e49e564b79 100644
--- a/arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi
+++ b/arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi
@@ -289,6 +289,23 @@
status = "disable";
};
+ aes: aes@f0858000 {
+ compatible = "nuvoton,npcm845-aes";
+ reg = <0x0 0xf0858000 0x0 0x1000>,
+ <0x0 0xf0851000 0x0 0x1000>;
+ status = "disabled";
+ clocks = <&clk NPCM8XX_CLK_AHB>;
+ clock-names = "clk_ahb";
+ };
+
+ sha:sha@f085a000 {
+ compatible = "nuvoton,npcm845-sha";
+ reg = <0x0 0xf085a000 0x0 0x1000>;
+ status = "disabled";
+ clocks = <&clk NPCM8XX_CLK_AHB>;
+ clock-names = "clk_ahb";
+ };
+
apb {
serial0: serial@0 {
compatible = "nuvoton,npcm845-uart";
@@ -417,22 +434,6 @@
status = "disabled";
};
- aes: aes@f0858000 {
- compatible = "nuvoton,npcm845-aes";
- reg = <0x0 0xf0858000 0x0 0x1000>,
- <0x0 0xf0851000 0x0 0x1000>;
- status = "disabled";
- clocks = <&clk NPCM8XX_CLK_AHB>;
- clock-names = "clk_ahb";
- };
-
- sha:sha@f085a000 {
- compatible = "nuvoton,npcm845-sha";
- reg = <0x0 0xf085a000 0x0 0x1000>;
- status = "disabled";
- clocks = <&clk NPCM8XX_CLK_AHB>;
- clock-names = "clk_ahb";
- };
};
};
pinctrl: pinctrl@f080 {
--
2.17.1
[PATCH v1 2/4] board: nuvoton: add env setting for boot to linux
add console and mem env to boot to linux kernel
Signed-off-by: Jim Liu
---
board/nuvoton/poleg_evb/poleg_evb.c | 7 +++
include/configs/poleg.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/board/nuvoton/poleg_evb/poleg_evb.c
b/board/nuvoton/poleg_evb/poleg_evb.c
index aef142a881..2052af6649 100644
--- a/board/nuvoton/poleg_evb/poleg_evb.c
+++ b/board/nuvoton/poleg_evb/poleg_evb.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -19,6 +20,7 @@ int board_init(void)
int dram_init(void)
{
+ char value[32];
struct npcm_gcr *gcr = (struct npcm_gcr *)NPCM_GCR_BA;
int ramsize = (readl(&gcr->intcr3) >> 8) & 0x7;
@@ -44,5 +46,10 @@ int dram_init(void)
break;
}
+ if (gd->ram_size > 0) {
+sprintf(value, "%ldM", (gd->ram_size / 0x10));
+env_set("mem", value);
+}
+
return 0;
}
diff --git a/include/configs/poleg.h b/include/configs/poleg.h
index c3f1d3393c..1e96e838be 100644
--- a/include/configs/poleg.h
+++ b/include/configs/poleg.h
@@ -27,6 +27,8 @@
"eth1addr=00:00:F7:A0:00:FD\0" \
"eth2addr=00:00:F7:A0:00:FE\0"\
"eth3addr=00:00:F7:A0:00:FF\0"\
+ "console=ttyS0,115200n8\0" \
+ "earlycon=uart8250,mmio32,0xf000\0" \
"common_bootargs=setenv bootargs earlycon=${earlycon}
root=/dev/ram " \
"console=${console} mem=${mem} ramdisk_size=48000
basemac=${ethaddr}\0"\
"sd_prog=fatload mmc 0 1000 image-bmc; cp.b 1000
8000 ${filesize}\0" \
--
2.17.1
[PATCH v1 1/4] ARM: config: Enable config to decompress the FIT image
Enable FIT and SHA config to decompress the kernel image Signed-off-by: Jim Liu --- configs/poleg_evb_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/poleg_evb_defconfig b/configs/poleg_evb_defconfig index b00fb48a5a..cab589d7aa 100644 --- a/configs/poleg_evb_defconfig +++ b/configs/poleg_evb_defconfig @@ -102,3 +102,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_WDT_NPCM=y CONFIG_LIB_HW_RAND=y CONFIG_SHA_HW_ACCEL=y +CONFIG_FIT=y +CONFIG_SHA256=y +CONFIG_SHA512=y -- 2.17.1
[PATCH v1 0/4] fix type error and add feature to boot to kernel
fix type error and add feature to boot to kernel Jim Liu (4): ARM: config: Enable config to decompress the FIT image board: nuvoton: add env setting for boot to linux ARM: dts: npcm8xx: fix dts node error misc: nuvoton: fix type error arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi | 33 board/nuvoton/poleg_evb/poleg_evb.c | 7 + configs/poleg_evb_defconfig | 3 +++ drivers/misc/npcm_otp.c | 2 +- include/configs/poleg.h | 2 ++ 5 files changed, 30 insertions(+), 17 deletions(-) -- 2.17.1
