Re: [PATCH v2 02/12] firmware: scmi: implement SCMI base protocol

2023-08-07 Thread AKASHI Takahiro
Hi Etienne,

On Thu, Aug 03, 2023 at 09:35:57AM +, Etienne CARRIERE wrote:
> Hello Takahiro-san,
> 
> > From: AKASHI Takahiro 
> > Sent: Wednesday, July 26, 2023 10:37
> >  
> > SCMI base protocol is mandatory according to the SCMI specification.
> > 
> > With this patch, SCMI base protocol can be accessed via SCMI transport
> > layers. All the commands, except SCMI_BASE_NOTIFY_ERRORS, are supported.
> > This is because U-Boot doesn't support interrupts and the current transport
> > layers are not able to handle asynchronous messages properly.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> > v2
> > * add helper functions, removing direct uses of ops
> > * add function descriptions for each of functions in ops
> 
> A reported typo and a question on use of strcpy().

Thank you for pointing out typos not only in this file, but also others.
While I won't reply each time, I will fix all those typos.

> Otherwise the patch look to me. If  you strongly feel strcpy() is safe, 
> please get my R-b tag:

My initial thought was that commands in Base protocol are expected
to be used mostly internally so the string size check can be superfluous.
But for more safety, I will change the code so that data for returned
strings are dynamically allocated by helper functions.

This approach will also be helpful and consistent, in the future, when
"exntended name" is supported in other protocols as well so people
don't have to worry about the maximum length in any case.

-Takahiro Akashi


> Reviewed-by: Etienne Carriere 
> 
> > ---
> >  drivers/firmware/scmi/Makefile |   1 +
> >  drivers/firmware/scmi/base.c   | 637 +
> >  include/dm/uclass-id.h         |   1 +
> >  include/scmi_protocols.h       | 345 ++
> >  4 files changed, 984 insertions(+)
> >  create mode 100644 drivers/firmware/scmi/base.c
> > 
> > diff --git a/drivers/firmware/scmi/Makefile b/drivers/firmware/scmi/Makefile
> > index b2ff483c75a1..1a23d4981709 100644
> > --- a/drivers/firmware/scmi/Makefile
> > +++ b/drivers/firmware/scmi/Makefile
> > @@ -1,4 +1,5 @@
> >  obj-y   += scmi_agent-uclass.o
> > +obj-y  += base.o
> >  obj-y   += smt.o
> >  obj-$(CONFIG_SCMI_AGENT_SMCCC)          += smccc_agent.o
> >  obj-$(CONFIG_SCMI_AGENT_MAILBOX)        += mailbox_agent.o
> > diff --git a/drivers/firmware/scmi/base.c b/drivers/firmware/scmi/base.c
> > new file mode 100644
> > index ..2b61fa650d15
> > --- /dev/null
> > +++ b/drivers/firmware/scmi/base.c
> > @@ -0,0 +1,637 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * SCMI Base protocol as U-Boot device
> > + *
> > + * Copyright (C) 2023 Linaro Limited
> > + *             author: AKASHI Takahiro 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/**
> > + * scmi_generic_protocol_version - get protocol version
> > + * @dev:       SCMI device
> > + * @id:                SCMI protocol ID
> > + * @version:   Pointer to SCMI protocol version
> > + *
> > + * Obtain the protocol version number in @version.
> > + *
> > + * Return: 0 on success, error code otherwise
> > + */
> > +int scmi_generic_protocol_version(struct udevice *dev,
> > +                                 enum scmi_std_protocol id, u32 *version)
> > +{
> > +       struct scmi_protocol_version_out out;
> > +       struct scmi_msg msg = {
> > +               .protocol_id = id,
> > +               .message_id = SCMI_PROTOCOL_VERSION,
> > +               .out_msg = (u8 *),
> > +               .out_msg_sz = sizeof(out),
> > +       };
> > +       int ret;
> > +
> > +       ret = devm_scmi_process_msg(dev, );
> > +       if (ret)
> > +               return ret;
> > +       if (out.status)
> > +               return scmi_to_linux_errno(out.status);
> > +
> > +       *version = out.version;
> > +
> > +       return 0;
> > +}
> > +
> > +/**
> > + * scmi_base_protocol_version_int - get Base protocol version
> > + * @dev:       SCMI device
> > + * @version:   Pointer to SCMI protocol version
> > + *
> > + * Obtain the protocol version number in @version for Base protocol.
> > + *
> > + * Return: 0 on success, error code otherwise
> > + */
> > +static int scmi_base_protocol_version_int(struct udevice *dev, u32 
> > *version)
> > +{
> > +       return scmi_generic_protocol_version(dev, SCMI_PROTOCOL_ID_BASE,
> > +                                            version);
> > +}
> > +
> > +/**
> > + * scmi_protocol_attrs_int - get protocol attributes
> > + * @dev:               SCMI device
> > + * @num_agents:                Number of SCMI agents
> > + * @num_protocols:     Number of SCMI protocols
> > + *
> > + * Obtain the protocol attributes, the number of agents and the number
> > + * of protocols, in @num_agents and @num_protocols respectively, that
> > + * the device provides.
> > + *
> > + * Return: 0 on success, error code otherwise
> > + */
> > +static int scmi_protocol_attrs_int(struct udevice *dev, 

Re: [PATCH 4/7] net: dwc_eth_qos: Add glue driver for GMAC on Rockchip RK3568

2023-08-07 Thread Jonas Karlman
Hi Eugen,

On 2023-08-07 16:41, Eugen Hristev wrote:
> Hi Jonas,
> 
> Thank you for your work,

Thanks!

> 
> On 8/7/23 03:08, Jonas Karlman wrote:
>> Add a new glue driver for Rockchip SoCs, i.e RK3568, with a GMAC based
>> on Synopsys DWC Ethernet QoS IP.
>>
>> rk_gmac_ops was ported from linux commit:
>> 3bb3d6b1c195 ("net: stmmac: Add RK3566/RK3568 SoC support")
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>> Cc: David Wu 
>> Cc: Ezequiel Garcia 
>> ---
>>   drivers/net/Kconfig|   8 +
>>   drivers/net/Makefile   |   1 +
>>   drivers/net/dwc_eth_qos.c  |   8 +-
>>   drivers/net/dwc_eth_qos.h  |   2 +
>>   drivers/net/dwc_eth_qos_rockchip.c | 348 +
>>   5 files changed, 365 insertions(+), 2 deletions(-)
>>   create mode 100644 drivers/net/dwc_eth_qos_rockchip.c
>>
>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
>> index 0ed39a61e4de..29304fd77759 100644
>> --- a/drivers/net/Kconfig
>> +++ b/drivers/net/Kconfig
>> @@ -225,6 +225,14 @@ config DWC_ETH_QOS_IMX
>>The Synopsys Designware Ethernet QOS IP block with the specific
>>configuration used in IMX soc.
>>   
>> +config DWC_ETH_QOS_ROCKCHIP
>> +bool "Synopsys DWC Ethernet QOS device support for Rockchip SoCs"
>> +depends on DWC_ETH_QOS
>> +select DM_ETH_PHY
>> +help
>> +  The Synopsys Designware Ethernet QOS IP block with specific
>> +  configuration used in Rockchip SoCs.
>> +
>>   config DWC_ETH_QOS_STM32
>>  bool "Synopsys DWC Ethernet QOS device support for STM32"
>>  depends on DWC_ETH_QOS
>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
>> index d4af253b6f28..1d444f5b4a69 100644
>> --- a/drivers/net/Makefile
>> +++ b/drivers/net/Makefile
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_DRIVER_DM9000) += dm9000x.o
>>   obj-$(CONFIG_DSA_SANDBOX) += dsa_sandbox.o
>>   obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
>>   obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
>> +obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
>>   obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
>>   obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
>>   obj-$(CONFIG_E1000) += e1000.o
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
>> index 24fb3fac1f12..9fb98a2c3c74 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -1707,7 +1707,12 @@ static const struct udevice_id eqos_ids[] = {
>>  .data = (ulong)_imx_config
>>  },
>>   #endif
>> -
>> +#if IS_ENABLED(CONFIG_DWC_ETH_QOS_ROCKCHIP)
>> +{
>> +.compatible = "rockchip,rk3568-gmac",
>> +.data = (ulong)_rockchip_config
>> +},
>> +#endif
>>   #if IS_ENABLED(CONFIG_DWC_ETH_QOS_QCOM)
>>  {
>>  .compatible = "qcom,qcs404-ethqos",
>> @@ -1720,7 +1725,6 @@ static const struct udevice_id eqos_ids[] = {
>>  .data = (ulong)_jh7110_config
>>  },
>>   #endif
>> -
> Unintended change ?

A change to have it consistent without blank lines as remaining if/endif
blocks.

>>  { }
>>   };
>>   
>> diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
>> index 06a082da72ef..e3222e1e17e5 100644
>> --- a/drivers/net/dwc_eth_qos.h
>> +++ b/drivers/net/dwc_eth_qos.h
>> @@ -82,6 +82,7 @@ struct eqos_mac_regs {
>>   #define EQOS_MAC_MDIO_ADDRESS_PA_SHIFT 21
>>   #define EQOS_MAC_MDIO_ADDRESS_RDA_SHIFT16
>>   #define EQOS_MAC_MDIO_ADDRESS_CR_SHIFT 8
>> +#define EQOS_MAC_MDIO_ADDRESS_CR_100_1501
>>   #define EQOS_MAC_MDIO_ADDRESS_CR_20_35 2
>>   #define EQOS_MAC_MDIO_ADDRESS_CR_250_300   5
>>   #define EQOS_MAC_MDIO_ADDRESS_SKAP BIT(4)
>> @@ -287,5 +288,6 @@ void eqos_flush_buffer_generic(void *buf, size_t size);
>>   int eqos_null_ops(struct udevice *dev);
>>   
>>   extern struct eqos_config eqos_imx_config;
>> +extern struct eqos_config eqos_rockchip_config;
>>   extern struct eqos_config eqos_qcom_config;
>>   extern struct eqos_config eqos_jh7110_config;
>> diff --git a/drivers/net/dwc_eth_qos_rockchip.c 
>> b/drivers/net/dwc_eth_qos_rockchip.c
>> new file mode 100644
>> index ..c8abe351fc3e
>> --- /dev/null
>> +++ b/drivers/net/dwc_eth_qos_rockchip.c
>> @@ -0,0 +1,348 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "dwc_eth_qos.h"
>> +
>> +struct rk_gmac_ops {
>> +const char *compatible;
>> +int (*set_to_rgmii)(struct udevice *dev,
>> +int tx_delay, int rx_delay);
>> +int (*set_to_rmii)(struct udevice *dev);
>> +int (*set_gmac_speed)(struct udevice *dev);
>> +u32 regs[3];
> 
> Can't these be somehow const and point to a dedicated array for a 
> specific SoC ?
> 
> Also I believe the naming 'regs' is a bit 

Re: [PATCH v7 09/11] sandbox: capsule: Generate capsule related files through binman

2023-08-07 Thread Simon Glass
Hi Tom,

On Mon, 7 Aug 2023 at 12:08, Tom Rini  wrote:
>
> On Sun, Aug 06, 2023 at 04:43:06PM +0530, Sughosh Ganu wrote:
> > On Sun, 6 Aug 2023 at 03:48, Tom Rini  wrote:
> > >
> > > On Sat, Aug 05, 2023 at 09:04:00AM -0600, Simon Glass wrote:
> > > > Hi Sughosh,
> > > >
> > > > On Sat, 5 Aug 2023 at 05:35, Sughosh Ganu  
> > > > wrote:
> > > > >
> > > > > The EFI capsule files can now be generated as part of u-boot
> > > > > build through binman. Add capsule entry nodes in the u-boot.dtsi for
> > > > > the sandbox architecture for generating the capsules. These capsules
> > > > > are then used for testing the EFI capsule update functionality on the
> > > > > sandbox platforms. Also add binman nodes for generating the input
> > > > > files used for these capsules.
> > > > >
> > > > > Remove the corresponding logic which was used for generation of these
> > > > > input files which is now superfluous.
> > > > >
> > > > > Signed-off-by: Sughosh Ganu 
> > > > > ---
> > > > > Changes since V6:
> > > > > * Use macros defined in sandbox_efi_capsule for GUIDs and capsule
> > > > >   input filenames.
> > > > > * Generate the capsule input files through binman text entries.
> > > > >
> > > > >  arch/sandbox/dts/u-boot.dtsi  | 363 
> > > > > ++
> > > > >  include/sandbox_efi_capsule.h |  11 +
> > > > >  test/py/tests/test_efi_capsule/conftest.py| 168 +---
> > > > >  test/py/tests/test_efi_capsule/signature.dts  |  10 -
> > > > >  .../tests/test_efi_capsule/uboot_bin_env.its  |  36 --
> > > > >  5 files changed, 385 insertions(+), 203 deletions(-)
> > > > >  delete mode 100644 test/py/tests/test_efi_capsule/signature.dts
> > > > >  delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> > > >
> > > > I think you are still getting confused with using filenames when you
> > > > don't need to. See below...
> > > >
> > > >
> > > > >
> > > > > diff --git a/arch/sandbox/dts/u-boot.dtsi 
> > > > > b/arch/sandbox/dts/u-boot.dtsi
> > > > > index 60bd004937..f1b16b41c2 100644
> > > > > --- a/arch/sandbox/dts/u-boot.dtsi
> > > > > +++ b/arch/sandbox/dts/u-boot.dtsi
> >
> > 
> >
> > > >
> > > > > +   };
> > > > > +   };
> > > > > +
> > > > > +   capsule2 {
> > > > > +   filename = "Test02";
> > > > > +   capsule {
> > > > > +   type = "efi-capsule";
> > > > > +   image-index = <0x2>;
> > > > > +   image-type-id = SANDBOX_UBOOT_ENV_IMAGE_GUID;
> > > > > +
> > > > > +   blob {
> > > > > +   filename = UBOOT_ENV_IMAGE_NEW;
> > > > > +   };
> > > > > +   };
> > > > > +   };
> > > > > +
> > > > > +   capsule3 {
> > > > > +   filename = "Test03";
> > > > > +   capsule {
> > > > > +   type = "efi-capsule";
> > > > > +   image-index = <0x1>;
> > > > > +   image-type-id = SANDBOX_INCORRECT_GUID;
> > > > > +
> > > > > +   blob {
> > > > > +   filename = UBOOT_BIN_IMAGE_NEW;
> > > > > +   };
> > > > > +   };
> > > > > +   };
> > > > > +
> > > > > +   capsule4 {
> > > > > +   filename = "Test04";
> > > > > +   capsule {
> > > > > +   type = "efi-capsule";
> > > > > +   image-index = <0x1>;
> > > > > +   image-type-id = SANDBOX_FIT_IMAGE_GUID;
> > > > > +
> > > > > +   blob {
> > > > > +   filename =
> > > > [..]
> > > >
> > > > > +   capsule19 {
> > > > > +   filename = "Test115";
> > > >
> > > > [..]
> > > >
> > > > We really need to talk about these tests. So many cases! Can you not
> > > > reduce this?
> > >
> > > And why are these tests in the generic looking file and not one of the
> > > test dts files? This looks like something that would make implementation
> > > in real life confusing and non-obvious.
> >
> > These are not capsules that are being generated for binman tests.
> > Those dts files are indeed under tools/binman/test/. These capsules
> > are the ones used for testing the capsule update feature in the CI
> > run. The idea of having these capsule nodes defined in this file is to
> > have them generated as part of the standard build.
>
> The high level concern I have (so it applies to a few of these patches)
> is that it's not going to be clear and straightforward on how to use
> this regularly (for example, if I follow all of this right, I should be
> able to do a capsule update to push a build to one of my boards, and
> then run our pytest suite on it, instead of playing games with SD mux
> boards and so forth) or production (configure product-board so that we
> can deliver an updated firmware via $mechanism).

Well you can do that today with VBE...


Re: [PATCH] bloblist: Enforce CRC32

2023-08-07 Thread Simon Glass
On Mon, 7 Aug 2023 at 11:38, Tom Rini  wrote:
>
> In the common bloblist code we call crc32 to get a checksum for the
> data.  Ensure we will have the CRC32 code via select.
>
> Signed-off-by: Tom Rini 
> ---
>  common/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Simon Glass 


[PATCH] doc: Begin adding a best practices document for board ports

2023-08-07 Thread Tom Rini
To help guide developers down the right path, begin a document that
lists some best practices to follow when creating a new board port.

Signed-off-by: Tom Rini 
---
 doc/develop/board_best_practices.rst | 26 ++
 doc/develop/index.rst|  1 +
 2 files changed, 27 insertions(+)
 create mode 100644 doc/develop/board_best_practices.rst

diff --git a/doc/develop/board_best_practices.rst 
b/doc/develop/board_best_practices.rst
new file mode 100644
index ..835ea86dedb2
--- /dev/null
+++ b/doc/develop/board_best_practices.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+Best Practices for Board Ports
+==
+
+In addition to the regular best practices such as using :doc:`checkpatch` and
+following :doc:`docstyle` and :doc:`codingstyle` there are some things which
+are specific to creating a new board port.
+
+* Implement :doc:`bootstd` to ensure that the most number of operating systems
+  will be available for the platform.
+
+* The platform defconfig file must be generated via `make savedefconfig`.
+
+* The Kconfig and Kbuild infrastructure supports using "fragments" tha can be
+  used to make changes on top of a defconfig file.  These can be useful for
+  many things such as:
+
+  * Supporting different firmware locations (e.g. eMMC, SD, QSPI).
+
+  * Multiple board variants when runtime detection is not desired.
+
+  * Supporting different build types such as production and development.
+
+  And when used should reside in the board directory itself rather than the
+  top-level `configs/` directory.
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 263d404b4ca8..5b230d0321f2 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -9,6 +9,7 @@ General
 .. toctree::
:maxdepth: 1
 
+   board_best_practices
codingstyle
designprinciples
docstyle
-- 
2.34.1



Re: [EXT] Re: [PATCH] imx8m,imx9: Fix DRAM size calculation in SPL/dram_init_banksize()

2023-08-07 Thread Marek Vasut

On 8/7/23 18:43, Elena Popa wrote:



Subject tags should be (per git log arch/arm/mach-imx/imx8m/soc.c):

arm: imx: imx8m: imx9: Fix DRAM .


Will do!


If dram_init_banksize() is called from SPL, the rom_pointer, at that
point, is not correctly initialized. This causes wrong calculation of
DRAM start and size in dram_init_banksize(). The issue became apparent
only in Falcon Mode. Added an extra condition to prevent using
rom_pointer in SPL.


+CC Stefano, Fabio, Peng.


Signed-off-by: Elena Popa 
---
   arch/arm/mach-imx/imx8m/soc.c | 2 +-
   arch/arm/mach-imx/imx9/soc.c  | 2 +-
   2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c
b/arch/arm/mach-imx/imx8m/soc.c index d5254886be..dbb2154b08

100644

--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -273,7 +273,7 @@ int dram_init_banksize(void)
   }

   gd->bd->bi_dram[bank].start = PHYS_SDRAM;
- if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && rom_pointer[1]) {
+ if (!IS_ENABLED(CONFIG_ARMV8_PSCI) &&
+ !IS_ENABLED(CONFIG_SPL_BUILD) && rom_pointer[1]) {


Use ./scripts/checkpatch.pl , it should indicate line too long here.


I did that, but got no warning. For text, the script limit is 75 and code limit 
is 100.


I wasn't aware of that, thanks for pointing it out.


Should I break the line?


No


There seem to be other places which likely also need similar fix:

$ git grep CONFIG_ARMV8_PSCI.*rom_pointer arch/arm/mach-imx/
arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) &&
rom_pointer[1])
arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) &&
rom_pointer[1]) {
arch/arm/mach-imx/imx8m/soc.c:  if
(!IS_ENABLED(CONFIG_ARMV8_PSCI) && rom_pointer[1]) {
arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) &&
rom_pointer[0] &&


The other 2 places with similar conditions are in get_effective_memsize() and 
dram_init().
At least for i.MX8M and i.MX93 are not called from within SPL. Should we add 
nonetheless
the extra condition in those places as well? (for some of the other 
architectures,
dram_init() is called in SPL).


Better be consistent and fix them all, yes.


[PATCH] arm: Add arch/arm/dts/Makefile specifically to MAINTAINERS

2023-08-07 Thread Tom Rini
In order to reduce the number of people that are cc'd on a patch for
simply touching arch/arm/dts/Makefile (which is a big common file) add
an entry specifically to MAINTAINERS under the ARM entry.

Signed-off-by: Tom Rini 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2db052961b26..d678967baa32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -132,6 +132,7 @@ M:  Tom Rini 
 S: Maintained
 T: git https://source.denx.de/u-boot/custodians/u-boot-arm.git
 F: arch/arm/
+F: arch/arm/dts/Makefile
 F: cmd/arm/
 
 ARM ALTERA SOCFPGA
-- 
2.34.1



Re: Strange construct in binman description

2023-08-07 Thread Tim Harvey
On Sun, Jul 30, 2023 at 7:50 PM Simon Glass  wrote:
>
> Hi Tim,
>
> On Sun, 30 Jul 2023 at 17:42, Tim Harvey  wrote:
> >
> >
> > On Wed, Jul 26, 2023, 5:55 PM Simon Glass  wrote:
> >>
> >> Hi Tim,
> >>
> >> On Mon, 24 Jul 2023 at 08:53, Simon Glass  wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Sun, 23 Jul 2023 at 03:00, Marcel Ziswiler
> >> >  wrote:
> >> > >
> >> > > Hi Simon
> >> > >
> >> > > On Jul 23, 2023 05:48, Simon Glass  wrote:
> >> > >
> >> > > Hi Marcel,
> >> > >
> >> > > I just noticed this in an imx8 description:
> >> > >
> >> > > binman_configuration: @config-SEQ {
> >> > >
> >> > >
> >> > > I remember having stumbled over this before but I do not remember any 
> >> > > exact details, sorry.
> >> > >
> >> > > Since this is a generator node, binman blindly generates a phandle for
> >> > > each not it generates. This means that if there is more than one
> >> > > config node, then they will have duplicate phandles.
> >> > >
> >> > > I have sent a series to correct this, but it fails the build on:
> >> > > imx8mm_venice imx8mn_venice imx8mp_venice
> >> > >
> >> > >
> >> > > Ah, now I get it. You mixed up venice (Gate works) with verdin 
> >> > > (Toradex).
> >> > >
> >> > > I am a bit unsure about what this is supposed to do. Could you please
> >> > > take a look?
> >> > >
> >> > >
> >> > > I'm more than happy to do that but you are probably much better off 
> >> > > enquiring Tim Harvey from Gateworks about this. I put him on CC.
> >> >
> >> > Tim, any thoughts on this please?
> >>
> >> Can you please weigh in on this one?
> >
> >
> > Simon,
> >
> > I'm away from a computer until next week.
> >
> > Can you point me to the series in reference here?
> >
> > The -seq is for configs that support multiple dtbs which the Venice configs 
> > use.
>
> This is referring to code in mainline. it seems to have a phandle in a
> FIT template node, which means that Binman will generate multiple
> nodes with duplicate phandles.
>

Simon,

I don't know where the original discussion on this thread is from but
what I found is that your commit d4d97661d255: ("binman: Support
templates containing phandles") broke imx8mm_venice_defconfig,
imx8mn_venice_defconfig, and imx8mp_venice_defconfig. I see that you
merged commit 288ae53cb736: ("binman: Add a temporary hack for
duplicate phandles") while I was away as a temporary workaround for
these three boards instead of reverting the patch so I suppose we need
to figure out how to address it then remove your workaround.

The imx8mm-u-boot.dtsi contains a configurations node in the FIT image
to build configs for each dtb from CONFIG_OF_LIST.

configurations {
  default = "@config-DEFAULT-SEQ";

  binman_configuration: @config-SEQ {
description = "NAME";
fdt = "fdt-SEQ";
firmware = "uboot";
#ifndef CONFIG_ARMV8_PSCI
loadables = "atf";
#endif
  };
};

These three boards are the only imx8m* boards that support multiple
dtb's. If I look at the fit image (dtc -I dtb -O dts itb.fit.fit -f) I
see the following for imx8mm_venice_defconfig:

configurations {
default = "config-1";

config-1 {
description = "imx8mm-venice";
fdt = "fdt-1";
firmware = "uboot";
loadables = "atf";
phandle = <0x7f>;
};

config-2 {
description = "imx8mm-venice-gw71xx-0x";
fdt = "fdt-2";
firmware = "uboot";
loadables = "atf";
phandle = <0x7f>;
};

config-3 {
description = "imx8mm-venice-gw72xx-0x";
fdt = "fdt-3";
firmware = "uboot";
loadables = "atf";
phandle = <0x7f>;
};

config-4 {
description = "imx8mm-venice-gw73xx-0x";
fdt = "fdt-4";
firmware = "uboot";
loadables = "atf";
phandle = <0x7f>;
};

config-5 {
description = "imx8mm-venice-gw7901";
fdt = "fdt-5";
firmware = "uboot";
loadables = "atf";
phandle = <0x7f>;
};

config-6 {
description = "imx8mm-venice-gw7902";
fdt = "fdt-6";
firmware = "uboot";
loadables = "atf";
phandle = <0x7f>;
};

config-7 {
description = "imx8mm-venice-gw7903";
fdt = "fdt-7";
firmware = "uboot";
loadables = "atf";
   

[ANN] U-Boot v2023.10-rc2 released

2023-08-07 Thread Tom Rini
Hey all,

I'm back on track with -rc2, which is now tagged and pushed.  I have
just a few things I need to bring in myself still, and there's still a
few sets of updates I would like to see come in still, even if it's a
little late.  I'm now also opening up the next branch and will be
grabbing other changes for that soon.

In terms of a changelog, 
git log --merges v2023.10-rc1..v2023.10-rc2
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

I'm going to try and stay on schedule now and that means the rest of the
rcs every other Monday, and with final release on October 2nd, 2023.
Thanks all!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] board: ten64: add missing error checks for retimer power on

2023-08-07 Thread Tom Rini
On Mon, Aug 07, 2023 at 01:41:08AM +, Mathew McBride wrote:

> The retimer reset/power on logic was changed in a recent commit,
> however, it neglected to check if the commands sent to the
> board microcontroller (to control power to the retimer chip)
> actually completed.
> 
> Add return checks for these operations so any failures will
> be reported to the user.
> 
> Signed-off-by: Mathew McBride 
> Fixes: 7a041fea2 ("board: traverse: ten64: ensure retimer reset
> is done on new board revisions")

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] fs/erofs: Remove an unnecessary assertion

2023-08-07 Thread Tom Rini
On Wed, Jul 26, 2023 at 12:56:04PM +0800, Yifan Zhao wrote:

> In [1] Sam points out an assertion does not hold true for 32-bit
> platforms, which only impacts Large File Support (LFS) API usage
> in erofs-utils according to Xiang [2]. We don't think these APIs
> are used in u-boot and this restriction could be safely removed.
> 
> [1] https://lists.denx.de/pipermail/u-boot/2023-July/524679.html
> [2] https://lists.denx.de/pipermail/u-boot/2023-July/524727.html
> 
> Fixes: 3a21e92fc255 ("fs/erofs: Introduce new features including 
> ztailpacking, fragments and dedupe")
> Signed-off-by: Yifan Zhao 
> Tested-by: Sam Edwards 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 2/2] spl: move SPL_CRC32 option to lib/Kconfig

2023-08-07 Thread Tom Rini
On Thu, Aug 03, 2023 at 07:05:40PM +0300, Oleksandr Suvorov wrote:

> All SPL hash algorithm options are collected in lib/Kconfig. Move
> SPL_CRC32 there as well.
> 
> Signed-off-by: Oleksandr Suvorov 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/2] spl: remove duplicate SPL_MD5 option

2023-08-07 Thread Tom Rini
On Thu, Aug 03, 2023 at 07:05:39PM +0300, Oleksandr Suvorov wrote:

> There is another SPL_MD5 option defined in lib/Kconfig.
> Renaming SPL_MD5_SUPPORT introduced duplicate option with
> different description. As for now FIT and hash algorithm options
> are not related to each others, removing a duplicate option seems OK.
> 
> Fixes: 4b00fd1a84c ("Kconfig: Rename SPL_MD5_SUPPORT to SPL_MD5")
> Signed-off-by: Oleksandr Suvorov 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] common: fix detection of SYS_MALLOC_F_LEN=0x0

2023-08-07 Thread Tom Rini
On Tue, Aug 01, 2023 at 03:33:41PM +0200, Heinrich Schuchardt wrote:

> CONFIG_$(SPL_TPL_)SYS_MALLOC_F_LEN is defined as hex. If set to zero
> manually, .config contains '0x0' and not '0' as value.
> 
> The default value for CONFIG_SPL_SYS_MALLOC_F_LEN should not be set to 0
> but to 0x0 if CONFIG_SPL_FRAMEWORK=n to match a manually set value.
> 
> Fixes: c0126bd862a0 ("spl: Support bootstage, log, hash and early malloc in 
> TPL")
> Fixes: b61694705217 ("SPL: Do not enable SPL_SYS_MALLOC_SIMPLE without 
> SPL_FRAMEWORK by default")
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] common: Drop duplicate space in SPL_BMP description

2023-08-07 Thread Tom Rini
On Sat, Jul 29, 2023 at 03:34:51PM +0200, Marek Vasut wrote:

> Drop duplicate space in Kconfig symbol description.
> 
> Signed-off-by: Marek Vasut 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] ARM: renesas: Update MAINTAINERS file

2023-08-07 Thread Tom Rini
On Sun, Aug 06, 2023 at 08:57:34PM +0200, Marek Vasut wrote:

> Update MAINTAINERS file. Add missing MAINTAINERS file for Spider,
> Whitehawk and V3HSK boards. Update mail addresses. Add file globs
> to match on DT and driver files related to these boards.
> 
> The GRPEACH and R2DPLUS are special in that they are not R-Car
> and have their own set of specialized drivers.
> 
> Signed-off-by: Marek Vasut 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] get_maintainer.pl: Add an ignore list for git history

2023-08-07 Thread Tom Rini
On Mon, Aug 07, 2023 at 09:20:53AM -0400, Tom Rini wrote:

> As Pali Rohár has asked to not be copied on changes to files he is not
> a specific maintainer of, add his address to .get_maintainer.ignore.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] MAINTAINERS: Update rockchip platform maintain files

2023-08-07 Thread Tom Rini
On Mon, Aug 07, 2023 at 03:52:47PM +0800, Kever Yang wrote:

> Add px30, rv1126 soc, and rockchip soc based boards.
> 
> Signed-off-by: Kever Yang 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] MAINTAINERS: add DT/bindings files to at91 entry

2023-08-07 Thread Tom Rini
On Mon, Aug 07, 2023 at 10:22:03AM +0300, Eugen Hristev wrote:

> With this change the DT and binding files are under the at91 tree
> maintainer, and get_maintainer.pl correctly reports the entry.
> 
> Signed-off-by: Eugen Hristev 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] bloblist: Enforce CRC32

2023-08-07 Thread Tom Rini
On Mon, Aug 07, 2023 at 01:38:18PM -0400, Tom Rini wrote:

> In the common bloblist code we call crc32 to get a checksum for the
> data.  Ensure we will have the CRC32 code via select.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] Azure: Squash a number of jobs and re-order slightly

2023-08-07 Thread Tom Rini
On Sat, Aug 05, 2023 at 12:24:16PM -0400, Tom Rini wrote:

> To reduce overall job time, move a number of smaller jobs together.
> These should still be safely under 1 hour total time, but reducing the
> overall number of jobs should help with the queue slightly.
> 
> Signed-off-by: Tom Rini 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v11 3/8] tpm: Support boot measurements

2023-08-07 Thread Eddie James
Add TPM2 functions to support boot measurement. This includes
starting up the TPM, initializing/appending the event log, and
measuring the U-Boot version. Much of the code was used in the
EFI subsystem, so remove it there and use the common functions.

Signed-off-by: Eddie James 
---
Changes since v10:
 - Fix compile warning for armv7 (thanks Ilias)

Changes since v8:
 - Fix log parsing again - any data corruption seen while replaying the
   event log was failing the entire measurement.
 - Added an option to ignore the existing log. This should only be used
   for systems that know that U-Boot is the first stage bootloader. This
   is necessary because the reserved memory region may persist through
   resets and so U-Boot attempts to append to the previous boot's log.

Changes since v7:
 - Change name of tcg2_init_log and add more documentation
 - Add a check, when parsing the event log header, to ensure that the
   previous stage bootloader used all the active PCRs.
 - Change name of tcg2_log_find_end
 - Fix the greater than or equal to check to exit the log parsing
 - Make sure log_position is 0 if there is any error discovering the log
 - Return errors parsing the log if the data is corrupt so that we don't
   end up with half a log

Changes since v6:
 - Added Linaro copyright for all the EFI moved code
 - Changed tcg2_init_log (and by extension, tcg2_measurement_init) to
   copy any discovered event log to the user's log if passed in.

Changes since v5:
 - Remove unused platform_get_eventlog in efi_tcg2.c
 - First look for tpm_event_log_* properties instead of linux,sml-*
 - Fix efi_tcg2.c compilation
 - Select SHA* configs

Changes since v4:
 - Remove tcg2_measure_event function and check for NULL data in
   tcg2_measure_data
 - Use tpm_auto_startup
 - Fix efi_tcg2.c compilation for removing tcg2_pcr_read function

Changes since v3:
 - Reordered headers
 - Refactored more of EFI code into common code
Removed digest_info structure and instead used the common alg_to_mask
  and alg_to_len
Improved event log parsing in common code to get it equivalent to EFI
  Common code now extends PCR if previous bootloader stage couldn't
  No need to allocate memory in the common code, so EFI copies the
  discovered buffer like it did before
Rename efi measure_event function

Changes since v1:
 - Refactor TPM layer functions to allow EFI system to use them, and
   remove duplicate EFI functions

 include/efi_tcg2.h|   44 --
 include/tpm-v2.h  |  259 +
 lib/Kconfig   |4 +
 lib/efi_loader/efi_tcg2.c | 1054 +++--
 lib/tpm-v2.c  |  814 
 5 files changed, 1154 insertions(+), 1021 deletions(-)

diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index b1c3abd097..b21c5cb3dd 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -129,50 +129,6 @@ struct efi_tcg2_boot_service_capability {
 #define BOOT_SERVICE_CAPABILITY_MIN \
offsetof(struct efi_tcg2_boot_service_capability, number_of_pcr_banks)
 
-#define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MAJOR_TPM2 2
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MINOR_TPM2 0
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_ERRATA_TPM2 2
-
-/**
- *  struct TCG_EfiSpecIdEventAlgorithmSize - hashing algorithm information
- *
- *  @algorithm_id: algorithm defined in enum tpm2_algorithms
- *  @digest_size:  size of the algorithm
- */
-struct tcg_efi_spec_id_event_algorithm_size {
-   u16  algorithm_id;
-   u16  digest_size;
-} __packed;
-
-/**
- * struct TCG_EfiSpecIDEventStruct - content of the event log header
- *
- * @signature: signature, set to Spec ID Event03
- * @platform_class:class defined in TCG ACPI Specification
- * Client  Common Header.
- * @spec_version_minor:minor version
- * @spec_version_major:major version
- * @spec_version_errata:   major version
- * @uintn_size:size of the efi_uintn_t fields used in 
various
- * data structures used in this specification.
- * 0x01 indicates u32  and 0x02  indicates u64
- * @number_of_algorithms:  hashing algorithms used in this event log
- * @digest_sizes:  array of number_of_algorithms pairs
- * 1st member defines the algorithm id
- * 2nd member defines the algorithm size
- */
-struct tcg_efi_spec_id_event {
-   u8 signature[16];
-   u32 platform_class;
-   u8 spec_version_minor;
-   u8 spec_version_major;
-   u8 spec_errata;
-   u8 uintn_size;
-   u32 number_of_algorithms;
-   struct tcg_efi_spec_id_event_algorithm_size digest_sizes[];
-} __packed;
-
 /**
  * struct tdEFI_TCG2_FINAL_EVENTS_TABLE - log entries after Get Event Log
  * 

[PATCH v11 2/8] tpm: sandbox: Update for needed TPM2 capabilities

2023-08-07 Thread Eddie James
The driver needs to support getting the PCRs in the capabilities
command. Fix various other things and support the max number
of PCRs for TPM2.
Remove the !SANDBOX dependency for EFI TCG2 as well.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
Acked-by: Ilias Apalodimas 
---
Changes since v8:
 - Use >= for checking the property against TPM2_PROPERTIES_OFFSET

Changes since v5:
 - Remove the !SANDBOX dependency for EFI TCG2

 drivers/tpm/tpm2_tis_sandbox.c | 100 -
 lib/efi_loader/Kconfig |   2 -
 2 files changed, 72 insertions(+), 30 deletions(-)

diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
index e4004cfcca..d15a28d9fc 100644
--- a/drivers/tpm/tpm2_tis_sandbox.c
+++ b/drivers/tpm/tpm2_tis_sandbox.c
@@ -22,11 +22,6 @@ enum tpm2_hierarchy {
TPM2_HIERARCHY_NB,
 };
 
-/* Subset of supported capabilities */
-enum tpm2_capability {
-   TPM_CAP_TPM_PROPERTIES = 0x6,
-};
-
 /* Subset of supported properties */
 #define TPM2_PROPERTIES_OFFSET 0x020E
 
@@ -38,7 +33,8 @@ enum tpm2_cap_tpm_property {
TPM2_PROPERTY_NB,
 };
 
-#define SANDBOX_TPM_PCR_NB 1
+#define SANDBOX_TPM_PCR_NB TPM2_MAX_PCRS
+#define SANDBOX_TPM_PCR_SELECT_MAX ((SANDBOX_TPM_PCR_NB + 7) / 8)
 
 /*
  * Information about our TPM emulation. This is preserved in the sandbox
@@ -433,7 +429,7 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const u8 
*sendbuf,
int i, j;
 
/* TPM2_GetProperty */
-   u32 capability, property, property_count;
+   u32 capability, property, property_count, val;
 
/* TPM2_PCR_Read/Extend variables */
int pcr_index = 0;
@@ -542,19 +538,32 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
u8 *sendbuf,
case TPM2_CC_GET_CAPABILITY:
capability = get_unaligned_be32(sent);
sent += sizeof(capability);
-   if (capability != TPM_CAP_TPM_PROPERTIES) {
-   printf("Sandbox TPM only support TPM_CAPABILITIES\n");
-   return TPM2_RC_HANDLE;
-   }
-
property = get_unaligned_be32(sent);
sent += sizeof(property);
-   property -= TPM2_PROPERTIES_OFFSET;
-
property_count = get_unaligned_be32(sent);
sent += sizeof(property_count);
-   if (!property_count ||
-   property + property_count > TPM2_PROPERTY_NB) {
+
+   switch (capability) {
+   case TPM2_CAP_PCRS:
+   break;
+   case TPM2_CAP_TPM_PROPERTIES:
+   if (!property_count) {
+   rc = TPM2_RC_HANDLE;
+   return sandbox_tpm2_fill_buf(recv, recv_len,
+tag, rc);
+   }
+
+   if (property >= TPM2_PROPERTIES_OFFSET &&
+   ((property - TPM2_PROPERTIES_OFFSET) +
+property_count > TPM2_PROPERTY_NB)) {
+   rc = TPM2_RC_HANDLE;
+   return sandbox_tpm2_fill_buf(recv, recv_len,
+tag, rc);
+   }
+   break;
+   default:
+   printf("Sandbox TPM2 only supports TPM2_CAP_PCRS or "
+  "TPM2_CAP_TPM_PROPERTIES\n");
rc = TPM2_RC_HANDLE;
return sandbox_tpm2_fill_buf(recv, recv_len, tag, rc);
}
@@ -578,18 +587,53 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
u8 *sendbuf,
put_unaligned_be32(capability, recv);
recv += sizeof(capability);
 
-   /* Give the number of properties that follow */
-   put_unaligned_be32(property_count, recv);
-   recv += sizeof(property_count);
-
-   /* Fill with the properties */
-   for (i = 0; i < property_count; i++) {
-   put_unaligned_be32(TPM2_PROPERTIES_OFFSET + property +
-  i, recv);
-   recv += sizeof(property);
-   put_unaligned_be32(tpm->properties[property + i],
-  recv);
-   recv += sizeof(property);
+   switch (capability) {
+   case TPM2_CAP_PCRS:
+   /* Give the number of algorithms supported - just 
SHA256 */
+   put_unaligned_be32(1, recv);
+   recv += sizeof(u32);
+
+   /* Give SHA256 algorithm */
+   put_unaligned_be16(TPM2_ALG_SHA256, recv);
+   recv += sizeof(u16);
+
+   /* Select the PCRs supported */
+   *recv 

[PATCH v11 8/8] test: use a non system PCR for testing PCR extend

2023-08-07 Thread Eddie James
From: Ilias Apalodimas 

We currently use PCR 0 for testing the PCR read/extend functionality in
our selftests.  How ever those PCRs are defined by the TCG spec for
platform use.  For example if the tests run *after* the efi subsystem
initialization, which extends PCRs 0 & 7 it will give a false positive.

So let's switch over to a PCR which is more suitable and is defined for
OS use.  It's worth noting that we are using PCR10 here, since PCR9 is
used internally by U-Boot if we choose to measure the loaded DTB

Reviewed-by: Simon Glass 
Signed-off-by: Ilias Apalodimas 
---
 test/py/tests/test_tpm2.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/test/py/tests/test_tpm2.py b/test/py/tests/test_tpm2.py
index fce689cd99..8cd3046285 100644
--- a/test/py/tests/test_tpm2.py
+++ b/test/py/tests/test_tpm2.py
@@ -236,7 +236,7 @@ def test_tpm2_dam_parameters(u_boot_console):
 def test_tpm2_pcr_read(u_boot_console):
 """Execute a TPM2_PCR_Read command.
 
-Perform a PCR read of the 0th PCR. Must be zero.
+Perform a PCR read of the 10th PCR. Must be zero.
 """
 if is_sandbox(u_boot_console):
 tpm2_sandbox_init(u_boot_console)
@@ -244,7 +244,7 @@ def test_tpm2_pcr_read(u_boot_console):
 force_init(u_boot_console)
 ram = u_boot_utils.find_ram_base(u_boot_console)
 
-read_pcr = u_boot_console.run_command('tpm2 pcr_read 0 0x%x' % ram)
+read_pcr = u_boot_console.run_command('tpm2 pcr_read 10 0x%x' % ram)
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
@@ -254,7 +254,7 @@ def test_tpm2_pcr_read(u_boot_console):
 updates = int(re.findall(r'\d+', str)[0])
 
 # Check the output value
-assert 'PCR #0 content' in read_pcr
+assert 'PCR #10 content' in read_pcr
 assert '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00' in read_pcr
 
 @pytest.mark.buildconfigspec('cmd_tpm_v2')
@@ -272,19 +272,19 @@ def test_tpm2_pcr_extend(u_boot_console):
 force_init(u_boot_console)
 ram = u_boot_utils.find_ram_base(u_boot_console)
 
-read_pcr = u_boot_console.run_command('tpm2 pcr_read 0 0x%x' % (ram + 
0x20))
+read_pcr = u_boot_console.run_command('tpm2 pcr_read 10 0x%x' % (ram + 
0x20))
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 str = re.findall(r'\d+ known updates', read_pcr)[0]
 updates = int(re.findall(r'\d+', str)[0])
 
-u_boot_console.run_command('tpm2 pcr_extend 0 0x%x' % ram)
+u_boot_console.run_command('tpm2 pcr_extend 10 0x%x' % ram)
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
 # Read the value back into a different place so we can still use 'ram' as
 # our zero bytes
-read_pcr = u_boot_console.run_command('tpm2 pcr_read 0 0x%x' % (ram + 
0x20))
+read_pcr = u_boot_console.run_command('tpm2 pcr_read 10 0x%x' % (ram + 
0x20))
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 assert 'f5 a5 fd 42 d1 6a 20 30 27 98 ef 6e d3 09 97 9b' in read_pcr
@@ -294,11 +294,11 @@ def test_tpm2_pcr_extend(u_boot_console):
 new_updates = int(re.findall(r'\d+', str)[0])
 assert (updates + 1) == new_updates
 
-u_boot_console.run_command('tpm2 pcr_extend 0 0x%x' % ram)
+u_boot_console.run_command('tpm2 pcr_extend 10 0x%x' % ram)
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
-read_pcr = u_boot_console.run_command('tpm2 pcr_read 0 0x%x' % (ram + 
0x20))
+read_pcr = u_boot_console.run_command('tpm2 pcr_read 10 0x%x' % (ram + 
0x20))
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 assert '7a 05 01 f5 95 7b df 9c b3 a8 ff 49 66 f0 22 65' in read_pcr
-- 
2.39.3



[PATCH v11 5/8] test: Add sandbox TPM boot measurement

2023-08-07 Thread Eddie James
Use the sandbox TPM driver to measure some boot images in a unit
test case.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
Acked-by: Ilias Apalodimas 
---
Changes since v5:
 - Only compile in the measurement u-boot command when
   CONFIG_MEASURED_BOOT is enabled.

 arch/sandbox/dts/sandbox.dtsi | 13 +++
 arch/sandbox/dts/test.dts | 13 +++
 configs/sandbox_defconfig |  1 +
 include/test/suites.h |  1 +
 test/boot/Makefile|  1 +
 test/boot/measurement.c   | 66 +++
 test/cmd_ut.c |  4 +++
 7 files changed, 99 insertions(+)
 create mode 100644 test/boot/measurement.c

diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 30a305c4d2..ed39d20c6a 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -4,11 +4,23 @@
  * and sandbox64 builds.
  */
 
+#include 
 #include 
 
 #define USB_CLASS_HUB  9
 
 / {
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   event_log: tcg_event_log {
+   no-map;
+   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
+   };
+   };
+
binman {
};
 
@@ -336,6 +348,7 @@
 
tpm2 {
compatible = "sandbox,tpm2";
+   memory-region = <_log>;
};
 
triangle {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index ff9f9222e6..0bac073178 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -9,6 +9,7 @@
 
 /dts-v1/;
 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +67,17 @@
osd0 = "/osd";
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   event_log: tcg_event_log {
+   no-map;
+   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
+   };
+   };
+
binman: binman {
};
 
@@ -1365,6 +1377,7 @@
 
tpm2 {
compatible = "sandbox,tpm2";
+   memory-region = <_log>;
};
 
tpm {
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 1ec44d5b33..85ef821296 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -344,3 +344,4 @@ CONFIG_TEST_FDTDEC=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
+CONFIG_MEASURED_BOOT=y
diff --git a/include/test/suites.h b/include/test/suites.h
index 1c7dc65966..48ed549c13 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -45,6 +45,7 @@ int do_ut_font(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[]);
 int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]);
+int do_ut_measurement(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
argv[]);
 int do_ut_mem(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_optee(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_overlay(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/test/boot/Makefile b/test/boot/Makefile
index 22ed61c8fa..2dbb032a7e 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o
 obj-$(CONFIG_FIT) += image.o
+obj-$(CONFIG_MEASURED_BOOT) += measurement.o
 
 obj-$(CONFIG_EXPO) += expo.o
 
diff --git a/test/boot/measurement.c b/test/boot/measurement.c
new file mode 100644
index 00..9db2ed324c
--- /dev/null
+++ b/test/boot/measurement.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test for measured boot functions
+ *
+ * Copyright 2023 IBM Corp.
+ * Written by Eddie James 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MEASUREMENT_TEST(_name, _flags)\
+   UNIT_TEST(_name, _flags, measurement_test)
+
+static int measure(struct unit_test_state *uts)
+{
+   struct bootm_headers images;
+   const size_t size = 1024;
+   u8 *kernel;
+   u8 *initrd;
+   size_t i;
+
+   kernel = malloc(size);
+   initrd = malloc(size);
+
+   images.os.image_start = map_to_sysmem(kernel);
+   images.os.image_len = size;
+
+   images.rd_start = map_to_sysmem(initrd);
+   images.rd_end = images.rd_start + size;
+
+   images.ft_addr = malloc(size);
+   images.ft_len = size;
+
+   env_set("bootargs", "measurement testing");
+
+   for (i = 0; i < size; ++i) {
+   kernel[i] = 0xf0 | (i & 0xf);
+   initrd[i] = (i & 0xf0) | 0xf;
+   images.ft_addr[i] = i & 0xff;
+   }
+
+   ut_assertok(bootm_measure());
+
+   

[PATCH v11 1/8] tpm: Fix spelling for tpmu_ha union

2023-08-07 Thread Eddie James
tmpu -> tpmu

Signed-off-by: Eddie James 
Reviewed-by: Ilias Apalodimas 
---
 include/tpm-v2.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 2b6980e441..6684033deb 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -169,7 +169,7 @@ struct tcg_pcr_event {
 /**
  * Definition of TPMU_HA Union
  */
-union tmpu_ha {
+union tpmu_ha {
u8 sha1[TPM2_SHA1_DIGEST_SIZE];
u8 sha256[TPM2_SHA256_DIGEST_SIZE];
u8 sm3_256[TPM2_SM3_256_DIGEST_SIZE];
@@ -185,7 +185,7 @@ union tmpu_ha {
  */
 struct tpmt_ha {
u16 hash_alg;
-   union tmpu_ha digest;
+   union tpmu_ha digest;
 } __packed;
 
 /**
-- 
2.39.3



[PATCH v11 7/8] efi_loader: fix EFI_ENTRY point on get_active_pcr_banks

2023-08-07 Thread Eddie James
From: Ilias Apalodimas 

efi_tcg2_get_active_pcr_banks doesn't immediately call the
EFI_ENTRY() wrapper once it enters the function. Move the call a
few lines above to cover the error cases properly as well.

Signed-off-by: Ilias Apalodimas 
---
 lib/efi_loader/efi_tcg2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 5f0f4b5dd2..829bae7436 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -718,16 +718,16 @@ efi_tcg2_get_active_pcr_banks(struct efi_tcg2_protocol 
*this,
struct udevice *dev;
efi_status_t ret;
 
+   EFI_ENTRY("%p, %p", this, active_pcr_banks);
+
if (!this || !active_pcr_banks) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
-
ret = tcg2_platform_get_tpm2();
if (ret != EFI_SUCCESS)
goto out;
 
-   EFI_ENTRY("%p, %p", this, active_pcr_banks);
ret = tcg2_get_active_pcr_banks(dev, active_pcr_banks);
 
 out:
-- 
2.39.3



[PATCH v11 0/8] tpm: Support boot measurements

2023-08-07 Thread Eddie James
This series adds support for measuring the boot images more generically
than the existing EFI support. Several EFI functions have been moved to
the TPM layer. The series includes optional measurement from the bootm 
command.
A new test case has been added for the bootm measurement to test the new
path, and the sandbox TPM2 driver has been updated to support this use
case.

Changes since v10:
 - Fix commit message on efi_loader change
 - Drop python test change
 - Squash armv7 fix from Ilias

Changes since v9:
 - Rebase and add Ilias' fixes (thanks!)

Changes since v8:
 - Fix a sandbox driver off-by-one error in checking the property type.
 - Fix log parsing again - any data corruption seen while replaying the
   event log was failing the entire measurement.
 - Added an option to ignore the existing log and a configuration option
   for systems to select that for the bootm measurement. This would only
   be selected for systems that know that U-Boot is the first stage
   bootloader. This is necessary because the reserved memory region may
   persist through resets and so U-Boot attempts to append to the
   previous boot's log.

Changes since v7:
 - Change name of tcg2_init_log and add more documentation
 - Add a check, when parsing the event log header, to ensure that the
   previous stage bootloader used all the active PCRs.
 - Change name of tcg2_log_find_end
 - Fix the greater than or equal to check to exit the log parsing
 - Make sure log_position is 0 if there is any error discovering the log
 - Return errors parsing the log if the data is corrupt so that we don't
   end up with half a log

Changes since v6:
 - Added comment for bootm_measure
 - Fixed line length in bootm_measure
 - Added Linaro copyright for all the EFI moved code
 - Changed tcg2_init_log (and by extension, tcg2_measurement_init) to
   copy any discovered event log to the user's log if passed in.

Changes since v5:
 - Re-ordered the patches to put the sandbox TPM driver patch second
 - Remove unused platform_get_eventlog in efi_tcg2.c
 - First look for tpm_event_log_* properties instead of linux,sml-*
 - Fix efi_tcg2.c compilation
 - Select SHA* configs
 - Remove the !SANDBOX dependency for EFI TCG2
 - Only compile in the measurement u-boot command when CONFIG_MEASURED_BOOT
   is enabled

Changes since v4:
 - Remove tcg2_measure_event function and check for NULL data in
   tcg2_measure_data
 - Use tpm_auto_startup
 - Fix efi_tcg2.c compilation for removing tcg2_pcr_read function
 - Change PCR indexes for initrd and dtb
 - Drop u8 casting in measurement test
 - Use bullets in documentation

Changes since v3:
 - Reordered headers
 - Refactored more of EFI code into common code
Removed digest_info structure and instead used the common alg_to_mask
  and alg_to_len
Improved event log parsing in common code to get it equivalent to EFI
  Common code now extends PCR if previous bootloader stage couldn't
  No need to allocate memory in the common code, so EFI copies the
  discovered buffer like it did before
Rename efi measure_event function

Changes since v2:
 - Add documentation.
 - Changed reserved memory address to the top of the RAM for sandbox dts.
 - Add measure state to booti and bootz.
 - Skip measurement for EFI images that should be measured

Changes since v1:
 - Refactor TPM layer functions to allow EFI system to use them, and
   remove duplicate EFI functions.
 - Add test case
 - Drop #ifdefs for bootm
 - Add devicetree measurement config option
 - Update sandbox TPM driver

Eddie James (6):
  tpm: Fix spelling for tpmu_ha union
  tpm: sandbox: Update for needed TPM2 capabilities
  tpm: Support boot measurements
  bootm: Support boot measurement
  test: Add sandbox TPM boot measurement
  doc: Add measured boot documentation

Ilias Apalodimas (2):
  efi_loader: fix EFI_ENTRY point on get_active_pcr_banks
  test: use a non system PCR for testing PCR extend

 arch/sandbox/dts/sandbox.dtsi  |   13 +
 arch/sandbox/dts/test.dts  |   13 +
 boot/Kconfig   |   32 +
 boot/bootm.c   |   74 +++
 cmd/booti.c|1 +
 cmd/bootm.c|2 +
 cmd/bootz.c|1 +
 configs/sandbox_defconfig  |1 +
 doc/usage/index.rst|1 +
 doc/usage/measured_boot.rst|   23 +
 drivers/tpm/tpm2_tis_sandbox.c |  100 ++-
 include/bootm.h|   11 +
 include/efi_tcg2.h |   44 --
 include/image.h|1 +
 include/test/suites.h  |1 +
 include/tpm-v2.h   |  263 +++-
 lib/Kconfig|4 +
 lib/efi_loader/Kconfig |2 -
 lib/efi_loader/efi_tcg2.c  | 1056 +++-
 lib/tpm-v2.c   |  814 
 test/boot/Makefile |1 +
 test/boot/measurement.c|   66 ++
 test/cmd_ut.c  |4 +
 test/py/tests/test_tpm2.py |   16 +-
 24 files 

[PATCH v11 6/8] doc: Add measured boot documentation

2023-08-07 Thread Eddie James
Briefly describe the feature and specify the requirements.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
---
 doc/usage/index.rst |  1 +
 doc/usage/measured_boot.rst | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 doc/usage/measured_boot.rst

diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 388e59f173..64eb362aef 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -13,6 +13,7 @@ Use U-Boot
partitions
cmdline
semihosting
+   measured_boot
 
 Shell commands
 --
diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst
new file mode 100644
index 00..8357b1f480
--- /dev/null
+++ b/doc/usage/measured_boot.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Measured Boot
+=
+
+U-Boot can perform a measured boot, the process of hashing various components
+of the boot process, extending the results in the TPM and logging the
+component's measurement in memory for the operating system to consume.
+
+Requirements
+-
+
+* A hardware TPM 2.0 supported by the U-Boot drivers
+* CONFIG_TPM=y
+* CONFIG_MEASURED_BOOT=y
+* Device-tree configuration of the TPM device to specify the memory area
+  for event logging. The TPM device node must either contain a phandle to
+  a reserved memory region or "linux,sml-base" and "linux,sml-size"
+  indicating the address and size of the memory region. An example can be
+  found in arch/sandbox/dts/test.dts
+* The operating system must also be configured to use the memory regions
+  specified in the U-Boot device-tree in order to make use of the event
+  log.
-- 
2.39.3



[PATCH v11 4/8] bootm: Support boot measurement

2023-08-07 Thread Eddie James
Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
---
Changes since v8:
 - Added a configuration option to select to ignore any existing
   event log. This would only be selected for systems that know
   that U-Boot is the first stage bootloader. This is necessary
   because the reserved memory region may persist through resets
   and so U-Boot attempts to append to the previous boot's log.

Changes since v6:
 - Added comment for bootm_measure
 - Fixed line length in bootm_measure

 boot/Kconfig| 32 +
 boot/bootm.c| 74 +
 cmd/booti.c |  1 +
 cmd/bootm.c |  2 ++
 cmd/bootz.c |  1 +
 include/bootm.h | 11 
 include/image.h |  1 +
 7 files changed, 122 insertions(+)

diff --git a/boot/Kconfig b/boot/Kconfig
index a643a3d128..b160b20599 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -675,6 +675,38 @@ config LEGACY_IMAGE_FORMAT
  loaded. If a board needs the legacy image format support in this
  case, enable it here.
 
+config MEASURED_BOOT
+   bool "Measure boot images and configuration to TPM and event log"
+   depends on HASH && TPM_V2
+   help
+ This option enables measurement of the boot process. Measurement
+ involves creating cryptographic hashes of the binary images that
+ are booting and storing them in the TPM. In addition, a log of
+ these hashes is stored in memory for the OS to verify the booted
+ images and configuration. Enable this if the OS has configured
+ some memory area for the event log and you intend to use some
+ attestation tools on your system.
+
+if MEASURED_BOOT
+   config MEASURE_DEVICETREE
+   bool "Measure the devicetree image"
+   default y if MEASURED_BOOT
+   help
+ On some platforms, the devicetree is not static as it may contain
+ random MAC addresses or other such data that changes each boot.
+ Therefore, it should not be measured into the TPM. In that case,
+ disable the measurement here.
+
+   config MEASURE_IGNORE_LOG
+   bool "Ignore the existing event log"
+   default n
+   help
+ On platforms that use an event log memory region that persists
+ through system resets and are the first stage bootloader, then
+ this option should be enabled to ignore any existing data in the
+ event log memory region.
+endif # MEASURED_BOOT
+
 config SUPPORT_RAW_INITRD
bool "Enable raw initrd images"
help
diff --git a/boot/bootm.c b/boot/bootm.c
index 75f0b4a9af..c20a688749 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #if defined(CONFIG_CMD_USB)
 #include 
 #endif
@@ -673,6 +674,75 @@ int bootm_process_cmdline_env(int flags)
return 0;
 }
 
+int bootm_measure(struct bootm_headers *images)
+{
+   int ret = 0;
+
+   /* Skip measurement if EFI is going to do it */
+   if (images->os.os == IH_OS_EFI &&
+   IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
+   IS_ENABLED(CONFIG_BOOTM_EFI))
+   return ret;
+
+   if (IS_ENABLED(CONFIG_MEASURED_BOOT)) {
+   struct tcg2_event_log elog;
+   struct udevice *dev;
+   void *initrd_buf;
+   void *image_buf;
+   const char *s;
+   u32 rd_len;
+   bool ign;
+
+   elog.log_size = 0;
+   ign = IS_ENABLED(CONFIG_MEASURE_IGNORE_LOG);
+   ret = tcg2_measurement_init(, , ign);
+   if (ret)
+   return ret;
+
+   image_buf = map_sysmem(images->os.image_start,
+  images->os.image_len);
+   ret = tcg2_measure_data(dev, , 8, images->os.image_len,
+   image_buf, EV_COMPACT_HASH,
+   strlen("linux") + 1, (u8 *)"linux");
+   if (ret)
+   goto unmap_image;
+
+   rd_len = images->rd_end - images->rd_start;
+   initrd_buf = map_sysmem(images->rd_start, rd_len);
+   ret = tcg2_measure_data(dev, , 9, rd_len, initrd_buf,
+   EV_COMPACT_HASH, strlen("initrd") + 1,
+   (u8 *)"initrd");
+   if (ret)
+   goto unmap_initrd;
+
+   if (IS_ENABLED(CONFIG_MEASURE_DEVICETREE)) {
+   ret = tcg2_measure_data(dev, , 0, images->ft_len,
+   (u8 *)images->ft_addr,
+   EV_TABLE_OF_DEVICES,
+   strlen("dts") + 1,
+ 

Re: Re: [PATCH v1] board: rockchip: Add Bananapi R2Pro Board

2023-08-07 Thread Tom Rini
On Mon, Aug 07, 2023 at 07:54:19PM +0200, Frank Wunderlich wrote:
> > Gesendet: Montag, 07. August 2023 um 19:20 Uhr
> > Von: "Pali Rohár" 
> > Could you stop sending me these rockchip emails? What is not
> > understandable on the fact that I'm not rockchip maintainer?
> > https://lists.denx.de/pipermail/u-boot/2023-March/511199.html
> > https://lists.denx.de/pipermail/u-boot/2023-April/515012.html
> 
> sorry, but maintainer.pl returns you for the changes 
> (added_lines:16/181=9%,removed_lines:12/62=19%)...not maintainer, but because 
> of email i thought it could be interesting for you too...sorry about that.
> 
> maintainers.pl imho should not return you here (i guess because of 
> vendor-independ arm/dts directory/makefile).
> 
> Dropped some more people from thread which may not involved into 
> rockchip-changes.
> 
> maybe this should be changed like linux kernel does for arm64 
> (dts//...)? then maintainer-script can show the right people here.

The main thing that helps the kernel is that arch/arm/boot/dts/Makefile
is explicitly listed in a MAINTAINERS entry (same for arm64).  The
vendor directories largely aren't, so random board contributors will get
emails at some point.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v7 09/11] sandbox: capsule: Generate capsule related files through binman

2023-08-07 Thread Tom Rini
On Sun, Aug 06, 2023 at 04:43:06PM +0530, Sughosh Ganu wrote:
> On Sun, 6 Aug 2023 at 03:48, Tom Rini  wrote:
> >
> > On Sat, Aug 05, 2023 at 09:04:00AM -0600, Simon Glass wrote:
> > > Hi Sughosh,
> > >
> > > On Sat, 5 Aug 2023 at 05:35, Sughosh Ganu  wrote:
> > > >
> > > > The EFI capsule files can now be generated as part of u-boot
> > > > build through binman. Add capsule entry nodes in the u-boot.dtsi for
> > > > the sandbox architecture for generating the capsules. These capsules
> > > > are then used for testing the EFI capsule update functionality on the
> > > > sandbox platforms. Also add binman nodes for generating the input
> > > > files used for these capsules.
> > > >
> > > > Remove the corresponding logic which was used for generation of these
> > > > input files which is now superfluous.
> > > >
> > > > Signed-off-by: Sughosh Ganu 
> > > > ---
> > > > Changes since V6:
> > > > * Use macros defined in sandbox_efi_capsule for GUIDs and capsule
> > > >   input filenames.
> > > > * Generate the capsule input files through binman text entries.
> > > >
> > > >  arch/sandbox/dts/u-boot.dtsi  | 363 ++
> > > >  include/sandbox_efi_capsule.h |  11 +
> > > >  test/py/tests/test_efi_capsule/conftest.py| 168 +---
> > > >  test/py/tests/test_efi_capsule/signature.dts  |  10 -
> > > >  .../tests/test_efi_capsule/uboot_bin_env.its  |  36 --
> > > >  5 files changed, 385 insertions(+), 203 deletions(-)
> > > >  delete mode 100644 test/py/tests/test_efi_capsule/signature.dts
> > > >  delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> > >
> > > I think you are still getting confused with using filenames when you
> > > don't need to. See below...
> > >
> > >
> > > >
> > > > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > > > index 60bd004937..f1b16b41c2 100644
> > > > --- a/arch/sandbox/dts/u-boot.dtsi
> > > > +++ b/arch/sandbox/dts/u-boot.dtsi
> 
> 
> 
> > >
> > > > +   };
> > > > +   };
> > > > +
> > > > +   capsule2 {
> > > > +   filename = "Test02";
> > > > +   capsule {
> > > > +   type = "efi-capsule";
> > > > +   image-index = <0x2>;
> > > > +   image-type-id = SANDBOX_UBOOT_ENV_IMAGE_GUID;
> > > > +
> > > > +   blob {
> > > > +   filename = UBOOT_ENV_IMAGE_NEW;
> > > > +   };
> > > > +   };
> > > > +   };
> > > > +
> > > > +   capsule3 {
> > > > +   filename = "Test03";
> > > > +   capsule {
> > > > +   type = "efi-capsule";
> > > > +   image-index = <0x1>;
> > > > +   image-type-id = SANDBOX_INCORRECT_GUID;
> > > > +
> > > > +   blob {
> > > > +   filename = UBOOT_BIN_IMAGE_NEW;
> > > > +   };
> > > > +   };
> > > > +   };
> > > > +
> > > > +   capsule4 {
> > > > +   filename = "Test04";
> > > > +   capsule {
> > > > +   type = "efi-capsule";
> > > > +   image-index = <0x1>;
> > > > +   image-type-id = SANDBOX_FIT_IMAGE_GUID;
> > > > +
> > > > +   blob {
> > > > +   filename =
> > > [..]
> > >
> > > > +   capsule19 {
> > > > +   filename = "Test115";
> > >
> > > [..]
> > >
> > > We really need to talk about these tests. So many cases! Can you not
> > > reduce this?
> >
> > And why are these tests in the generic looking file and not one of the
> > test dts files? This looks like something that would make implementation
> > in real life confusing and non-obvious.
> 
> These are not capsules that are being generated for binman tests.
> Those dts files are indeed under tools/binman/test/. These capsules
> are the ones used for testing the capsule update feature in the CI
> run. The idea of having these capsule nodes defined in this file is to
> have them generated as part of the standard build.

The high level concern I have (so it applies to a few of these patches)
is that it's not going to be clear and straightforward on how to use
this regularly (for example, if I follow all of this right, I should be
able to do a capsule update to push a build to one of my boards, and
then run our pytest suite on it, instead of playing games with SD mux
boards and so forth) or production (configure product-board so that we
can deliver an updated firmware via $mechanism).

-- 
Tom


signature.asc
Description: PGP signature


Aw: Re: [PATCH v1] board: rockchip: Add Bananapi R2Pro Board

2023-08-07 Thread Frank Wunderlich
> Gesendet: Montag, 07. August 2023 um 19:20 Uhr
> Von: "Pali Rohár" 
> Could you stop sending me these rockchip emails? What is not
> understandable on the fact that I'm not rockchip maintainer?
> https://lists.denx.de/pipermail/u-boot/2023-March/511199.html
> https://lists.denx.de/pipermail/u-boot/2023-April/515012.html

sorry, but maintainer.pl returns you for the changes 
(added_lines:16/181=9%,removed_lines:12/62=19%)...not maintainer, but because 
of email i thought it could be interesting for you too...sorry about that.

maintainers.pl imho should not return you here (i guess because of 
vendor-independ arm/dts directory/makefile).

Dropped some more people from thread which may not involved into 
rockchip-changes.

maybe this should be changed like linux kernel does for arm64 
(dts//...)? then maintainer-script can show the right people here.

regards Frank


Re: [PATCH] get_maintainer.pl: Add an ignore list for git history

2023-08-07 Thread Michael Nazzareno Trimarchi
On Mon, Aug 7, 2023 at 3:21 PM Tom Rini  wrote:
>
> As Pali Rohár has asked to not be copied on changes to files he is not
> a specific maintainer of, add his address to .get_maintainer.ignore.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: "Pali Rohár" 
> ---
>  .get_maintainer.ignore | 1 +
>  .gitignore | 1 +
>  2 files changed, 2 insertions(+)
>  create mode 100644 .get_maintainer.ignore
>

Reviewed-by: Michael Trimarchi 


> diff --git a/.get_maintainer.ignore b/.get_maintainer.ignore
> new file mode 100644
> index ..899a1469b2ae
> --- /dev/null
> +++ b/.get_maintainer.ignore
> @@ -0,0 +1 @@
> +"Pali Rohár" 
> diff --git a/.gitignore b/.gitignore
> index 3a4d056edfc3..002f95de4feb 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -53,6 +53,7 @@ fit-dtb.blob*
>  #
>  !.gitignore
>  !.mailmap
> +!.get_maintainer.*
>
>  #
>  # Generated files
> --
> 2.34.1
>


--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


[PATCH] bloblist: Enforce CRC32

2023-08-07 Thread Tom Rini
In the common bloblist code we call crc32 to get a checksum for the
data.  Ensure we will have the CRC32 code via select.

Signed-off-by: Tom Rini 
---
 common/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index 1ca9fc3abfc4..cdb77a6a7da2 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -951,6 +951,7 @@ menu "Blob list"
 
 config BLOBLIST
bool "Support for a bloblist"
+   select CRC32
help
  This enables support for a bloblist in U-Boot, which can be passed
  from TPL to SPL to U-Boot proper (and potentially to Linux). The
@@ -961,6 +962,7 @@ config BLOBLIST
 config SPL_BLOBLIST
bool "Support for a bloblist in SPL"
depends on BLOBLIST && SPL_LIBGENERIC_SUPPORT && SPL_LIBCOMMON_SUPPORT
+   select SPL_CRC32
default y if SPL
help
  This enables a bloblist in SPL. If this is the first part of U-Boot
@@ -970,6 +972,7 @@ config SPL_BLOBLIST
 config TPL_BLOBLIST
bool "Support for a bloblist in TPL"
depends on BLOBLIST && TPL_LIBGENERIC_SUPPORT && TPL_LIBCOMMON_SUPPORT
+   select TPL_CRC32
default y if TPL
help
  This enables a bloblist in TPL. The bloblist is set up in TPL and
-- 
2.34.1



Re: [PATCH v10 07/10] efi_loader: fix EFI_ENTRY point on get_active_pcr_banks

2023-08-07 Thread Eddie James



On 8/7/23 10:56, Ilias Apalodimas wrote:

Hi Eddie,

On Mon, 7 Aug 2023 at 18:17, Eddie James  wrote:

From: Ilias Apalodimas 

We need a commit message for that.  Something along the lines of
efi_tcg2_get_active_pcr_banks() doesnt immediately call the
EFI_ENTRY() wrappers once it enters the function.  Move the call a few
lines above and cover the error cases properly as well



Oops, yep. I'll fix this too.


Thanks,

Eddie




Thanks
/Ilias

Signed-off-by: Ilias Apalodimas 
---
  lib/efi_loader/efi_tcg2.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 5f0f4b5dd2..829bae7436 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -718,16 +718,16 @@ efi_tcg2_get_active_pcr_banks(struct efi_tcg2_protocol 
*this,
 struct udevice *dev;
 efi_status_t ret;

+   EFI_ENTRY("%p, %p", this, active_pcr_banks);
+
 if (!this || !active_pcr_banks) {
 ret = EFI_INVALID_PARAMETER;
 goto out;
 }
-
 ret = tcg2_platform_get_tpm2();
 if (ret != EFI_SUCCESS)
 goto out;

-   EFI_ENTRY("%p, %p", this, active_pcr_banks);
 ret = tcg2_get_active_pcr_banks(dev, active_pcr_banks);

  out:
--
2.39.3



Re: [PATCH v1] board: rockchip: Add Bananapi R2Pro Board

2023-08-07 Thread Pali Rohár
Could you stop sending me these rockchip emails? What is not
understandable on the fact that I'm not rockchip maintainer?
https://lists.denx.de/pipermail/u-boot/2023-March/511199.html
https://lists.denx.de/pipermail/u-boot/2023-April/515012.html

On Monday 07 August 2023 19:14:53 Frank Wunderlich wrote:
> From: Frank Wunderlich 
> 
> Add rk3568 based Bananapi R2 Pro board.
> 
> Signed-off-by: Frank Wunderlich 
> ---
> because iodomain is different to evb and now iodomain driver is sent as
> patch we need to separate between EVB and R2Pro else board can be bricked.
> ---
>  arch/arm/dts/Makefile |   3 +-
>  arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi |  23 +
>  arch/arm/dts/rk3568-bpi-r2pro.dts | 597 ++
>  configs/bpi-r2pro-rk3568_defconfig| 101 
>  4 files changed, 723 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
>  create mode 100644 configs/bpi-r2pro-rk3568_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 8f43dba58632..1bd48a7e0535 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
>   rk3568-nanopi-r5s.dtb \
>   rk3568-odroid-m1.dtb \
>   rk3568-radxa-e25.dtb \
> - rk3568-rock-3a.dtb
> + rk3568-rock-3a.dtb \
> + rk3568-bpi-r2pro.dtb
>  
>  dtb-$(CONFIG_ROCKCHIP_RK3588) += \
>   rk3588-edgeble-neu6a-io.dtb \
> diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi 
> b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> new file mode 100644
> index ..382a52a28b10
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> + */
> +
> +#include "rk356x-u-boot.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = 
> + u-boot,spl-boot-order = "same-as-spl", , 
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + clock-frequency = <2400>;
> + bootph-pre-ram;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts 
> b/arch/arm/dts/rk3568-bpi-r2pro.dts
> new file mode 100644
> index ..9295e9836a56
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
> @@ -0,0 +1,597 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Author: Frank Wunderlich 
> + *
> + */
> +
> +/dts-v1/;
> +#include 
> +#include 
> +#include 
> +#include "rk3568.dtsi"
> +
> +/ {
> + model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
> + compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
> +
> + aliases {
> + ethernet0 = 
> + ethernet1 = 
> + mmc0 = 
> + mmc1 = 
> + };
> +
> + chosen: chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_led_pin _led_pin>;
> +
> + blue_led: led-0 {
> + color = ;
> + default-state = "off";
> + function = LED_FUNCTION_STATUS;
> + gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
> + };
> +
> + green_led: led-1 {
> + color = ;
> + default-state = "on";
> + function = LED_FUNCTION_POWER;
> + gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + dc_12v: dc-12v-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + vin-supply = <_12v>;
> + };
> +
> + vcc5v0_sys: vcc5v0-sys-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + vin-supply = <_12v>;
> + };
> +
> + vcc5v0_usb: vcc5v0-usb-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + 

[PATCH v1] board: rockchip: Add Bananapi R2Pro Board

2023-08-07 Thread Frank Wunderlich
From: Frank Wunderlich 

Add rk3568 based Bananapi R2 Pro board.

Signed-off-by: Frank Wunderlich 
---
because iodomain is different to evb and now iodomain driver is sent as
patch we need to separate between EVB and R2Pro else board can be bricked.
---
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi |  23 +
 arch/arm/dts/rk3568-bpi-r2pro.dts | 597 ++
 configs/bpi-r2pro-rk3568_defconfig| 101 
 4 files changed, 723 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
 create mode 100644 configs/bpi-r2pro-rk3568_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8f43dba58632..1bd48a7e0535 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3568-nanopi-r5s.dtb \
rk3568-odroid-m1.dtb \
rk3568-radxa-e25.dtb \
-   rk3568-rock-3a.dtb
+   rk3568-rock-3a.dtb \
+   rk3568-bpi-r2pro.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi 
b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
new file mode 100644
index ..382a52a28b10
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   clock-frequency = <2400>;
+   bootph-pre-ram;
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts 
b/arch/arm/dts/rk3568-bpi-r2pro.dts
new file mode 100644
index ..9295e9836a56
--- /dev/null
+++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
@@ -0,0 +1,597 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich 
+ *
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include 
+#include "rk3568.dtsi"
+
+/ {
+   model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+   compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
+
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   mmc0 = 
+   mmc1 = 
+   };
+
+   chosen: chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_led_pin _led_pin>;
+
+   blue_led: led-0 {
+   color = ;
+   default-state = "off";
+   function = LED_FUNCTION_STATUS;
+   gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+   };
+
+   green_led: led-1 {
+   color = ;
+   default-state = "on";
+   function = LED_FUNCTION_POWER;
+   gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   dc_12v: dc-12v-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc3v3_sys: vcc3v3-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_12v>;
+   };
+
+   vcc5v0_sys: vcc5v0-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
+   };
+
+   vcc5v0_usb: vcc5v0-usb-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_usb";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
+   };
+
+   vcc5v0_usb_host: vcc5v0-usb-host-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < RK_PA6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_host_en>;
+   regulator-name = "vcc5v0_usb_host";
+   regulator-min-microvolt = <500>;
+  

Re: [PATCH v10 10/10] fix armv7 compilation warning

2023-08-07 Thread Eddie James



On 8/7/23 10:50, Ilias Apalodimas wrote:

Hi Eddie,

On Mon, 7 Aug 2023 at 18:18, Eddie James  wrote:

From: Ilias Apalodimas 

Signed-off-by: Ilias Apalodimas 
---
  lib/tpm-v2.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
index d22e21985b..bd0fb078dc 100644
--- a/lib/tpm-v2.c
+++ b/lib/tpm-v2.c
@@ -671,7 +671,7 @@ __weak int tcg2_platform_get_log(struct udevice *dev, void 
**addr, u32 *size)
 } else {
 struct ofnode_phandle_args args;
 phys_addr_t a;
-   phys_size_t s;
+   fdt_size_t s;

It's been a while since I fixed this, but iirc this had to be squashed
to your changes?



Oh, ok, I can do that.

Thanks,

Eddie




Cheers
/Ilias

 if (dev_read_phandle_with_args(dev, "memory-region", NULL, 0,
0, ))
--
2.39.3



Re: [PATCH 00/22] x86: Move some boards to text environment

2023-08-07 Thread Pali Rohár
On Monday 07 August 2023 15:30:25 Michael Nazzareno Trimarchi wrote:
> Hi Andy
> 
> On Mon, Aug 7, 2023 at 3:04 PM Andy Shevchenko
>  wrote:
> >
> > On Mon, Aug 07, 2023 at 02:44:31PM +0200, Michael Nazzareno Trimarchi wrote:
> > > Hi Pali
> > >
> > > Can you just filter emails on your side?
> >
> > Independently on the question is default setup is good or not
> > (from _this_ point of view, I *disagree* with Pali), we have to
> > have a possibility to filter on _our_ side the email addresses
> > to make people happy. If Pali by some reasons does not want to
> > see, it must be easy to keep some deny list in the repository.
> >
> > What you are suggesting is not polite I believe.
> 
> I understand what you mean, I never consider emails to me as a problem
> if I'm working
> on an opensource project and mostly of the time I'm happy to receive them

No, I'm really not happy to receive emails from people who either
implicity or explicitly said that will ignore all my contributions there
and trying to convince me to go away and at the same time they want from
me to do review on their own changes in my free time. I was patient, I
wait one year to see if something happen - but absolutely nothing.

So why you cannot understand that if you are not interested in my
patches, then I'm obviously not interested in yours? Or you are
continuing trying to say that I'm idiot who should do exactly what you
wrote? No! You would have to find another fool who would follow these
your ideas.

> Michael
> 
> >
> > > On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár  wrote:
> > > >
> > > > So remove me from that list of dram.c file. I'm not interested to
> > > > receive emails from people who are ignoring me about unrelated things.
> > > >
> > > > On Monday 07 August 2023 09:43:01 Bin Meng wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár  wrote:
> > > > > >
> > > > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár  wrote:
> > > > > > > >
> > > > > > > > I'm not x86 maintainer, and I'm not going to review changes. So 
> > > > > > > > please
> > > > > > > > do not send me these emails. I have expressed it many times.
> > > > > > >
> > > > > > > You were sent one patch (and the cover letter) because you are the
> > > > > > > second committer on arch/x86/cpu/qemu/dram.c
> > > > > >
> > > > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I 
> > > > > > have to
> > > > > > repeat it? You do not understand? Or what you are trying to do now?
> > > > >
> > > > > I believe this cc list comes from patman which calls get_maintainer.pl
> > > > > to get the cc list.
> > > > > get_maintainer.pl determines the person names from 1. MAINTAINERS of
> > > > > the changed file 2. git commit history of the changed file.
> > > > >
> > > > > I can see the philosophy was that someone who touched the changed file
> > > > > should be copied for review.
> > > > > We certainly could argue that and just get the list solely from the
> > > > > MAINTAINERS file.
> > > > >
> > > > > Regards,
> > > > > Bin
> > >
> > >
> > >
> > > --
> > > Michael Nazzareno Trimarchi
> > > Co-Founder & Chief Executive Officer
> > > M. +39 347 913 2170
> > > mich...@amarulasolutions.com
> > > __
> > >
> > > Amarula Solutions BV
> > > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> > > T. +31 (0)85 111 9172
> > > i...@amarulasolutions.com
> > > www.amarulasolutions.com
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
> 
> 
> -- 
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
> 
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com


RE: [EXT] Re: [PATCH] imx8m,imx9: Fix DRAM size calculation in SPL/dram_init_banksize()

2023-08-07 Thread Elena Popa

> Subject tags should be (per git log arch/arm/mach-imx/imx8m/soc.c):
> 
> arm: imx: imx8m: imx9: Fix DRAM .

Will do!

> > If dram_init_banksize() is called from SPL, the rom_pointer, at that
> > point, is not correctly initialized. This causes wrong calculation of
> > DRAM start and size in dram_init_banksize(). The issue became apparent
> > only in Falcon Mode. Added an extra condition to prevent using
> > rom_pointer in SPL.
> 
> +CC Stefano, Fabio, Peng.
> 
> > Signed-off-by: Elena Popa 
> > ---
> >   arch/arm/mach-imx/imx8m/soc.c | 2 +-
> >   arch/arm/mach-imx/imx9/soc.c  | 2 +-
> >   2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/imx8m/soc.c
> > b/arch/arm/mach-imx/imx8m/soc.c index d5254886be..dbb2154b08
> 100644
> > --- a/arch/arm/mach-imx/imx8m/soc.c
> > +++ b/arch/arm/mach-imx/imx8m/soc.c
> > @@ -273,7 +273,7 @@ int dram_init_banksize(void)
> >   }
> >
> >   gd->bd->bi_dram[bank].start = PHYS_SDRAM;
> > - if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && rom_pointer[1]) {
> > + if (!IS_ENABLED(CONFIG_ARMV8_PSCI) &&
> > + !IS_ENABLED(CONFIG_SPL_BUILD) && rom_pointer[1]) {
> 
> Use ./scripts/checkpatch.pl , it should indicate line too long here.

I did that, but got no warning. For text, the script limit is 75 and code limit 
is 100. 
Should I break the line?

> 
> There seem to be other places which likely also need similar fix:
> 
> $ git grep CONFIG_ARMV8_PSCI.*rom_pointer arch/arm/mach-imx/
> arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) &&
> rom_pointer[1])
> arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) &&
> rom_pointer[1]) {
> arch/arm/mach-imx/imx8m/soc.c:  if
> (!IS_ENABLED(CONFIG_ARMV8_PSCI) && rom_pointer[1]) {
> arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) &&
> rom_pointer[0] &&

The other 2 places with similar conditions are in get_effective_memsize() and 
dram_init().
At least for i.MX8M and i.MX93 are not called from within SPL. Should we add 
nonetheless
the extra condition in those places as well? (for some of the other 
architectures,
dram_init() is called in SPL).

> 
> >   phys_addr_t optee_start = (phys_addr_t)rom_pointer[0];
> >   phys_size_t optee_size = (size_t)rom_pointer[1];
> >
> > diff --git a/arch/arm/mach-imx/imx9/soc.c
> > b/arch/arm/mach-imx/imx9/soc.c index f43b73a6c2..ca91f20fe7 100644
> > --- a/arch/arm/mach-imx/imx9/soc.c
> > +++ b/arch/arm/mach-imx/imx9/soc.c
> > @@ -390,7 +390,7 @@ int dram_init_banksize(void)
> >   }
> >
> >   gd->bd->bi_dram[bank].start = PHYS_SDRAM;
> > - if (rom_pointer[1]) {
> > + if (!IS_ENABLED(CONFIG_SPL_BUILD) && rom_pointer[1]) {
> >   phys_addr_t optee_start = (phys_addr_t)rom_pointer[0];
> >   phys_size_t optee_size = (size_t)rom_pointer[1];
> 
> [...]


Re: [PATCH v10 09/10] test/py: only run 'tpm2 autostart' to init the tpm

2023-08-07 Thread Ilias Apalodimas
On Mon, 7 Aug 2023 at 18:17, Eddie James  wrote:
>
> From: Ilias Apalodimas 
>
> commit  ("")
> replaced the forced and sandbox tpm2 initialization running 'tpm2
> autostart' instead of the startup tpm sequence.  The difference is that
> the new function handles the internal tpm_init state internally and
> doesn't return an error when trying to initialize the tpm multiple
> times.  Replace the remaining instances
>
> Signed-off-by: Ilias Apalodimas \

We don't need this anymore, commit 789ed2784256 ("test/py: replace
'tpm2 init, startup, selftest' sequences") should be enough.  In any
case, I'll queue this on the CI without this and make sure.

Cheers
/Ilias
> ---
>  test/py/tests/test_tpm2.py | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/test/py/tests/test_tpm2.py b/test/py/tests/test_tpm2.py
> index 8cd3046285..5bbb2d2069 100644
> --- a/test/py/tests/test_tpm2.py
> +++ b/test/py/tests/test_tpm2.py
> @@ -61,7 +61,7 @@ def test_tpm2_init(u_boot_console):
>  skip_test = u_boot_console.config.env.get('env__tpm_device_test_skip', 
> False)
>  if skip_test:
>  pytest.skip('skip TPM device test')
> -u_boot_console.run_command('tpm2 init')
> +u_boot_console.run_command('tpm2 autostart')
>  output = u_boot_console.run_command('echo $?')
>  assert output.endswith('0')
>
> @@ -97,11 +97,7 @@ def test_tpm2_sandbox_self_test_full(u_boot_console):
>  """
>  if is_sandbox(u_boot_console):
>  u_boot_console.restart_uboot()
> -u_boot_console.run_command('tpm2 init')
> -output = u_boot_console.run_command('echo $?')
> -assert output.endswith('0')
> -
> -u_boot_console.run_command('tpm2 startup TPM2_SU_CLEAR')
> +u_boot_console.run_command('tpm2 autostart')
>  output = u_boot_console.run_command('echo $?')
>  assert output.endswith('0')
>
> --
> 2.39.3
>


Re: [PATCH] imx8m,imx9: Fix DRAM size calculation in SPL/dram_init_banksize()

2023-08-07 Thread Marek Vasut

On 8/7/23 12:56, Elena Popa wrote:

Subject tags should be (per git log arch/arm/mach-imx/imx8m/soc.c):

arm: imx: imx8m: imx9: Fix DRAM .


If dram_init_banksize() is called from SPL, the rom_pointer, at that
point, is not correctly initialized. This causes wrong calculation of
DRAM start and size in dram_init_banksize(). The issue became apparent
only in Falcon Mode. Added an extra condition to prevent using
rom_pointer in SPL.


+CC Stefano, Fabio, Peng.


Signed-off-by: Elena Popa 
---
  arch/arm/mach-imx/imx8m/soc.c | 2 +-
  arch/arm/mach-imx/imx9/soc.c  | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index d5254886be..dbb2154b08 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -273,7 +273,7 @@ int dram_init_banksize(void)
}
  
  	gd->bd->bi_dram[bank].start = PHYS_SDRAM;

-   if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && rom_pointer[1]) {
+   if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && !IS_ENABLED(CONFIG_SPL_BUILD) && 
rom_pointer[1]) {


Use ./scripts/checkpatch.pl , it should indicate line too long here.

There seem to be other places which likely also need similar fix:

$ git grep CONFIG_ARMV8_PSCI.*rom_pointer arch/arm/mach-imx/
arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && 
rom_pointer[1])
arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && 
rom_pointer[1]) {
arch/arm/mach-imx/imx8m/soc.c:  if 
(!IS_ENABLED(CONFIG_ARMV8_PSCI) && rom_pointer[1]) {
arch/arm/mach-imx/imx8m/soc.c:  if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && 
rom_pointer[0] &&



phys_addr_t optee_start = (phys_addr_t)rom_pointer[0];
phys_size_t optee_size = (size_t)rom_pointer[1];
  
diff --git a/arch/arm/mach-imx/imx9/soc.c b/arch/arm/mach-imx/imx9/soc.c

index f43b73a6c2..ca91f20fe7 100644
--- a/arch/arm/mach-imx/imx9/soc.c
+++ b/arch/arm/mach-imx/imx9/soc.c
@@ -390,7 +390,7 @@ int dram_init_banksize(void)
}
  
  	gd->bd->bi_dram[bank].start = PHYS_SDRAM;

-   if (rom_pointer[1]) {
+   if (!IS_ENABLED(CONFIG_SPL_BUILD) && rom_pointer[1]) {
phys_addr_t optee_start = (phys_addr_t)rom_pointer[0];
phys_size_t optee_size = (size_t)rom_pointer[1];


[...]


Re: [PATCH v10 07/10] efi_loader: fix EFI_ENTRY point on get_active_pcr_banks

2023-08-07 Thread Ilias Apalodimas
Hi Eddie,

On Mon, 7 Aug 2023 at 18:17, Eddie James  wrote:
>
> From: Ilias Apalodimas 

We need a commit message for that.  Something along the lines of
efi_tcg2_get_active_pcr_banks() doesnt immediately call the
EFI_ENTRY() wrappers once it enters the function.  Move the call a few
lines above and cover the error cases properly as well

Thanks
/Ilias
>
> Signed-off-by: Ilias Apalodimas 
> ---
>  lib/efi_loader/efi_tcg2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> index 5f0f4b5dd2..829bae7436 100644
> --- a/lib/efi_loader/efi_tcg2.c
> +++ b/lib/efi_loader/efi_tcg2.c
> @@ -718,16 +718,16 @@ efi_tcg2_get_active_pcr_banks(struct efi_tcg2_protocol 
> *this,
> struct udevice *dev;
> efi_status_t ret;
>
> +   EFI_ENTRY("%p, %p", this, active_pcr_banks);
> +
> if (!this || !active_pcr_banks) {
> ret = EFI_INVALID_PARAMETER;
> goto out;
> }
> -
> ret = tcg2_platform_get_tpm2();
> if (ret != EFI_SUCCESS)
> goto out;
>
> -   EFI_ENTRY("%p, %p", this, active_pcr_banks);
> ret = tcg2_get_active_pcr_banks(dev, active_pcr_banks);
>
>  out:
> --
> 2.39.3
>


Re: [PATCH v2 1/1] spl: spl_legacy: clean up spl_parse_legacy_validate

2023-08-07 Thread Marek Vasut

On 7/25/23 10:30, Heinrich Schuchardt wrote:

Simplify the check for an overlap of the loaded image and SPL.

Detect all cases of wrap around.

Use the SPL_TPL_NAME prefix to avoid printing 'SPL' in TPL
(both spl_parse_legacy_header and spl_parse_legacy_validate).

Fixes: 77aed22b48ab ("spl: spl_legacy: Add extra address checks")
Signed-off-by: Heinrich Schuchardt 
---
v2:
consider wrap around
fix TPL prefix

@Marek:

You suggested to carve out a function for memory region overlaps.
A function call for two comparisons would increase code size.


Even if the function is inlined ?


Introducing LMB for SPL would run into code size limitations and
is beyond the scope of a simple fix.
---
  common/spl/spl_legacy.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
index 095443c63d..dd91e1077b 100644
--- a/common/spl/spl_legacy.c
+++ b/common/spl/spl_legacy.c
@@ -22,14 +22,14 @@ static void spl_parse_legacy_validate(uintptr_t start, 
uintptr_t size)
uintptr_t spl_end = (uintptr_t)_image_binary_end;
uintptr_t end = start + size;
  
-	if ((start >= spl_start && start < spl_end) ||

-   (end > spl_start && end <= spl_end) ||
-   (start < spl_start && end >= spl_end) ||
-   (start > end && end > spl_start))
-   panic("SPL: Image overlaps SPL\n");
+   if (end > spl_start && start < spl_end)
+   panic(SPL_TPL_NAME ": Image overlaps SPL\n");
+
+   if (start >= end)


Really >= ? start == end means zero-size payload, no ?

Btw the extra string that is being printed here also increases code 
size, which might blow on at91.


Re: [PATCH v10 10/10] fix armv7 compilation warning

2023-08-07 Thread Ilias Apalodimas
Hi Eddie,

On Mon, 7 Aug 2023 at 18:18, Eddie James  wrote:
>
> From: Ilias Apalodimas 
>
> Signed-off-by: Ilias Apalodimas 
> ---
>  lib/tpm-v2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> index d22e21985b..bd0fb078dc 100644
> --- a/lib/tpm-v2.c
> +++ b/lib/tpm-v2.c
> @@ -671,7 +671,7 @@ __weak int tcg2_platform_get_log(struct udevice *dev, 
> void **addr, u32 *size)
> } else {
> struct ofnode_phandle_args args;
> phys_addr_t a;
> -   phys_size_t s;
> +   fdt_size_t s;

It's been a while since I fixed this, but iirc this had to be squashed
to your changes?

Cheers
/Ilias
>
> if (dev_read_phandle_with_args(dev, "memory-region", NULL, 0,
>0, ))
> --
> 2.39.3
>


Re: [PATCH v19 0/9] introduce Arm FF-A support

2023-08-07 Thread Abdellatif El Khlifi
Hi Tom,

> 
> > Adding support for Arm FF-A v1.0 (Arm Firmware Framework for Armv8-A) [A].
> > 
> > FF-A specifies interfaces that enable a pair of software execution 
> > environments aka partitions to
> > communicate with each other. A partition could be a VM in the Normal or 
> > Secure world, an
> > application in S-EL0, or a Trusted OS in S-EL1.
> > 
> > FF-A is a discoverable bus and similar to architecture features.
> > FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
> > by the PSCI driver.
> >  ...
> > 
> Depending on further feedback, I will pick this up but likely just after
> -rc2.  Given how long this has been going I will take it for v2023.10
> all the same, thanks.
> 

Very much appreciated. Thank you :)

Cheers,
Abdellatif



Re: [PATCH v19 8/9] arm_ffa: efi: introduce FF-A MM communication

2023-08-07 Thread Abdellatif El Khlifi
Hi Ilias,

> > Add MM communication support using FF-A transport
> > 
> > This feature allows accessing MM partitions services through
> > EFI MM communication protocol. MM partitions such as StandAlonneMM
> > or smm-gateway secure partitions which reside in secure world.
> > ...
> > 
> > Changelog:
> > ===
> > 
> > v19:
> > 
> > Tom:
> > 
> > * use CONFIG_FFA_SHARED_MM_BUF_* in place of macros
> > 
> > v18:
> > 
> > Ilias, Tom:
> > 
> > * drop the use of configs for the shared MM buffer, put back #ifdefs instead
> > * add test information to the commit log
> > 
> 
> Thanks for the quick rework.  I like the fact you have the SMC as a
> fallback to FF-A in case it's not discovered.  Once and if we get dynamic 
> buffer allocation for the NS-world we can easily switch this to an
> automatically scanable feature again.
> 
> Tom, I am fine with the series now.  I've reviewed the relevant EFI and asm
> bits, feel free to pull it in if the rest of the people are happy. 
> 
> Reviewed-by: Ilias Apalodimas 
> 

You're welcome :)

Cheers,
Abdellatif


[PATCH v10 05/10] test: Add sandbox TPM boot measurement

2023-08-07 Thread Eddie James
Use the sandbox TPM driver to measure some boot images in a unit
test case.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
Acked-by: Ilias Apalodimas 
---
Changes since v5:
 - Only compile in the measurement u-boot command when
   CONFIG_MEASURED_BOOT is enabled.

 arch/sandbox/dts/sandbox.dtsi | 13 +++
 arch/sandbox/dts/test.dts | 13 +++
 configs/sandbox_defconfig |  1 +
 include/test/suites.h |  1 +
 test/boot/Makefile|  1 +
 test/boot/measurement.c   | 66 +++
 test/cmd_ut.c |  4 +++
 7 files changed, 99 insertions(+)
 create mode 100644 test/boot/measurement.c

diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 30a305c4d2..ed39d20c6a 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -4,11 +4,23 @@
  * and sandbox64 builds.
  */
 
+#include 
 #include 
 
 #define USB_CLASS_HUB  9
 
 / {
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   event_log: tcg_event_log {
+   no-map;
+   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
+   };
+   };
+
binman {
};
 
@@ -336,6 +348,7 @@
 
tpm2 {
compatible = "sandbox,tpm2";
+   memory-region = <_log>;
};
 
triangle {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index ff9f9222e6..0bac073178 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -9,6 +9,7 @@
 
 /dts-v1/;
 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +67,17 @@
osd0 = "/osd";
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   event_log: tcg_event_log {
+   no-map;
+   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
+   };
+   };
+
binman: binman {
};
 
@@ -1365,6 +1377,7 @@
 
tpm2 {
compatible = "sandbox,tpm2";
+   memory-region = <_log>;
};
 
tpm {
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 1ec44d5b33..85ef821296 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -344,3 +344,4 @@ CONFIG_TEST_FDTDEC=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
+CONFIG_MEASURED_BOOT=y
diff --git a/include/test/suites.h b/include/test/suites.h
index 1c7dc65966..48ed549c13 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -45,6 +45,7 @@ int do_ut_font(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[]);
 int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]);
+int do_ut_measurement(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
argv[]);
 int do_ut_mem(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_optee(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_overlay(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/test/boot/Makefile b/test/boot/Makefile
index 22ed61c8fa..2dbb032a7e 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o
 obj-$(CONFIG_FIT) += image.o
+obj-$(CONFIG_MEASURED_BOOT) += measurement.o
 
 obj-$(CONFIG_EXPO) += expo.o
 
diff --git a/test/boot/measurement.c b/test/boot/measurement.c
new file mode 100644
index 00..9db2ed324c
--- /dev/null
+++ b/test/boot/measurement.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test for measured boot functions
+ *
+ * Copyright 2023 IBM Corp.
+ * Written by Eddie James 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MEASUREMENT_TEST(_name, _flags)\
+   UNIT_TEST(_name, _flags, measurement_test)
+
+static int measure(struct unit_test_state *uts)
+{
+   struct bootm_headers images;
+   const size_t size = 1024;
+   u8 *kernel;
+   u8 *initrd;
+   size_t i;
+
+   kernel = malloc(size);
+   initrd = malloc(size);
+
+   images.os.image_start = map_to_sysmem(kernel);
+   images.os.image_len = size;
+
+   images.rd_start = map_to_sysmem(initrd);
+   images.rd_end = images.rd_start + size;
+
+   images.ft_addr = malloc(size);
+   images.ft_len = size;
+
+   env_set("bootargs", "measurement testing");
+
+   for (i = 0; i < size; ++i) {
+   kernel[i] = 0xf0 | (i & 0xf);
+   initrd[i] = (i & 0xf0) | 0xf;
+   images.ft_addr[i] = i & 0xff;
+   }
+
+   ut_assertok(bootm_measure());
+
+   

[PATCH v10 10/10] fix armv7 compilation warning

2023-08-07 Thread Eddie James
From: Ilias Apalodimas 

Signed-off-by: Ilias Apalodimas 
---
 lib/tpm-v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
index d22e21985b..bd0fb078dc 100644
--- a/lib/tpm-v2.c
+++ b/lib/tpm-v2.c
@@ -671,7 +671,7 @@ __weak int tcg2_platform_get_log(struct udevice *dev, void 
**addr, u32 *size)
} else {
struct ofnode_phandle_args args;
phys_addr_t a;
-   phys_size_t s;
+   fdt_size_t s;
 
if (dev_read_phandle_with_args(dev, "memory-region", NULL, 0,
   0, ))
-- 
2.39.3



[PATCH v10 08/10] test: use a non system PCR for testing PCR extend

2023-08-07 Thread Eddie James
From: Ilias Apalodimas 

We currently use PCR 0 for testing the PCR read/extend functionality in
our selftests.  How ever those PCRs are defined by the TCG spec for
platform use.  For example if the tests run *after* the efi subsystem
initialization, which extends PCRs 0 & 7 it will give a false positive.

So let's switch over to a PCR which is more suitable and is defined for
OS use.  It's worth noting that we are using PCR10 here, since PCR9 is
used internally by U-Boot if we choose to measure the loaded DTB

Reviewed-by: Simon Glass 
Signed-off-by: Ilias Apalodimas 
---
 test/py/tests/test_tpm2.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/test/py/tests/test_tpm2.py b/test/py/tests/test_tpm2.py
index fce689cd99..8cd3046285 100644
--- a/test/py/tests/test_tpm2.py
+++ b/test/py/tests/test_tpm2.py
@@ -236,7 +236,7 @@ def test_tpm2_dam_parameters(u_boot_console):
 def test_tpm2_pcr_read(u_boot_console):
 """Execute a TPM2_PCR_Read command.
 
-Perform a PCR read of the 0th PCR. Must be zero.
+Perform a PCR read of the 10th PCR. Must be zero.
 """
 if is_sandbox(u_boot_console):
 tpm2_sandbox_init(u_boot_console)
@@ -244,7 +244,7 @@ def test_tpm2_pcr_read(u_boot_console):
 force_init(u_boot_console)
 ram = u_boot_utils.find_ram_base(u_boot_console)
 
-read_pcr = u_boot_console.run_command('tpm2 pcr_read 0 0x%x' % ram)
+read_pcr = u_boot_console.run_command('tpm2 pcr_read 10 0x%x' % ram)
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
@@ -254,7 +254,7 @@ def test_tpm2_pcr_read(u_boot_console):
 updates = int(re.findall(r'\d+', str)[0])
 
 # Check the output value
-assert 'PCR #0 content' in read_pcr
+assert 'PCR #10 content' in read_pcr
 assert '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00' in read_pcr
 
 @pytest.mark.buildconfigspec('cmd_tpm_v2')
@@ -272,19 +272,19 @@ def test_tpm2_pcr_extend(u_boot_console):
 force_init(u_boot_console)
 ram = u_boot_utils.find_ram_base(u_boot_console)
 
-read_pcr = u_boot_console.run_command('tpm2 pcr_read 0 0x%x' % (ram + 
0x20))
+read_pcr = u_boot_console.run_command('tpm2 pcr_read 10 0x%x' % (ram + 
0x20))
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 str = re.findall(r'\d+ known updates', read_pcr)[0]
 updates = int(re.findall(r'\d+', str)[0])
 
-u_boot_console.run_command('tpm2 pcr_extend 0 0x%x' % ram)
+u_boot_console.run_command('tpm2 pcr_extend 10 0x%x' % ram)
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
 # Read the value back into a different place so we can still use 'ram' as
 # our zero bytes
-read_pcr = u_boot_console.run_command('tpm2 pcr_read 0 0x%x' % (ram + 
0x20))
+read_pcr = u_boot_console.run_command('tpm2 pcr_read 10 0x%x' % (ram + 
0x20))
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 assert 'f5 a5 fd 42 d1 6a 20 30 27 98 ef 6e d3 09 97 9b' in read_pcr
@@ -294,11 +294,11 @@ def test_tpm2_pcr_extend(u_boot_console):
 new_updates = int(re.findall(r'\d+', str)[0])
 assert (updates + 1) == new_updates
 
-u_boot_console.run_command('tpm2 pcr_extend 0 0x%x' % ram)
+u_boot_console.run_command('tpm2 pcr_extend 10 0x%x' % ram)
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
-read_pcr = u_boot_console.run_command('tpm2 pcr_read 0 0x%x' % (ram + 
0x20))
+read_pcr = u_boot_console.run_command('tpm2 pcr_read 10 0x%x' % (ram + 
0x20))
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 assert '7a 05 01 f5 95 7b df 9c b3 a8 ff 49 66 f0 22 65' in read_pcr
-- 
2.39.3



[PATCH v10 01/10] tpm: Fix spelling for tpmu_ha union

2023-08-07 Thread Eddie James
tmpu -> tpmu

Signed-off-by: Eddie James 
Reviewed-by: Ilias Apalodimas 
---
 include/tpm-v2.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 2b6980e441..6684033deb 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -169,7 +169,7 @@ struct tcg_pcr_event {
 /**
  * Definition of TPMU_HA Union
  */
-union tmpu_ha {
+union tpmu_ha {
u8 sha1[TPM2_SHA1_DIGEST_SIZE];
u8 sha256[TPM2_SHA256_DIGEST_SIZE];
u8 sm3_256[TPM2_SM3_256_DIGEST_SIZE];
@@ -185,7 +185,7 @@ union tmpu_ha {
  */
 struct tpmt_ha {
u16 hash_alg;
-   union tmpu_ha digest;
+   union tpmu_ha digest;
 } __packed;
 
 /**
-- 
2.39.3



[PATCH v10 03/10] tpm: Support boot measurements

2023-08-07 Thread Eddie James
Add TPM2 functions to support boot measurement. This includes
starting up the TPM, initializing/appending the event log, and
measuring the U-Boot version. Much of the code was used in the
EFI subsystem, so remove it there and use the common functions.

Signed-off-by: Eddie James 
---
Changes since v8:
 - Fix log parsing again - any data corruption seen while replaying the
   event log was failing the entire measurement.
 - Added an option to ignore the existing log. This should only be used
   for systems that know that U-Boot is the first stage bootloader. This
   is necessary because the reserved memory region may persist through
   resets and so U-Boot attempts to append to the previous boot's log.

Changes since v7:
 - Change name of tcg2_init_log and add more documentation
 - Add a check, when parsing the event log header, to ensure that the
   previous stage bootloader used all the active PCRs.
 - Change name of tcg2_log_find_end
 - Fix the greater than or equal to check to exit the log parsing
 - Make sure log_position is 0 if there is any error discovering the log
 - Return errors parsing the log if the data is corrupt so that we don't
   end up with half a log

Changes since v6:
 - Added Linaro copyright for all the EFI moved code
 - Changed tcg2_init_log (and by extension, tcg2_measurement_init) to
   copy any discovered event log to the user's log if passed in.

Changes since v5:
 - Remove unused platform_get_eventlog in efi_tcg2.c
 - First look for tpm_event_log_* properties instead of linux,sml-*
 - Fix efi_tcg2.c compilation
 - Select SHA* configs

Changes since v4:
 - Remove tcg2_measure_event function and check for NULL data in
   tcg2_measure_data
 - Use tpm_auto_startup
 - Fix efi_tcg2.c compilation for removing tcg2_pcr_read function

Changes since v3:
 - Reordered headers
 - Refactored more of EFI code into common code
Removed digest_info structure and instead used the common alg_to_mask
  and alg_to_len
Improved event log parsing in common code to get it equivalent to EFI
  Common code now extends PCR if previous bootloader stage couldn't
  No need to allocate memory in the common code, so EFI copies the
  discovered buffer like it did before
Rename efi measure_event function

Changes since v1:
 - Refactor TPM layer functions to allow EFI system to use them, and
   remove duplicate EFI functions

 include/efi_tcg2.h|   44 --
 include/tpm-v2.h  |  259 +
 lib/Kconfig   |4 +
 lib/efi_loader/efi_tcg2.c | 1054 +++--
 lib/tpm-v2.c  |  814 
 5 files changed, 1154 insertions(+), 1021 deletions(-)

diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index b1c3abd097..b21c5cb3dd 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -129,50 +129,6 @@ struct efi_tcg2_boot_service_capability {
 #define BOOT_SERVICE_CAPABILITY_MIN \
offsetof(struct efi_tcg2_boot_service_capability, number_of_pcr_banks)
 
-#define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MAJOR_TPM2 2
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MINOR_TPM2 0
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_ERRATA_TPM2 2
-
-/**
- *  struct TCG_EfiSpecIdEventAlgorithmSize - hashing algorithm information
- *
- *  @algorithm_id: algorithm defined in enum tpm2_algorithms
- *  @digest_size:  size of the algorithm
- */
-struct tcg_efi_spec_id_event_algorithm_size {
-   u16  algorithm_id;
-   u16  digest_size;
-} __packed;
-
-/**
- * struct TCG_EfiSpecIDEventStruct - content of the event log header
- *
- * @signature: signature, set to Spec ID Event03
- * @platform_class:class defined in TCG ACPI Specification
- * Client  Common Header.
- * @spec_version_minor:minor version
- * @spec_version_major:major version
- * @spec_version_errata:   major version
- * @uintn_size:size of the efi_uintn_t fields used in 
various
- * data structures used in this specification.
- * 0x01 indicates u32  and 0x02  indicates u64
- * @number_of_algorithms:  hashing algorithms used in this event log
- * @digest_sizes:  array of number_of_algorithms pairs
- * 1st member defines the algorithm id
- * 2nd member defines the algorithm size
- */
-struct tcg_efi_spec_id_event {
-   u8 signature[16];
-   u32 platform_class;
-   u8 spec_version_minor;
-   u8 spec_version_major;
-   u8 spec_errata;
-   u8 uintn_size;
-   u32 number_of_algorithms;
-   struct tcg_efi_spec_id_event_algorithm_size digest_sizes[];
-} __packed;
-
 /**
  * struct tdEFI_TCG2_FINAL_EVENTS_TABLE - log entries after Get Event Log
  * @version:   version number for this structure
diff --git 

[PATCH v10 09/10] test/py: only run 'tpm2 autostart' to init the tpm

2023-08-07 Thread Eddie James
From: Ilias Apalodimas 

commit  ("")
replaced the forced and sandbox tpm2 initialization running 'tpm2
autostart' instead of the startup tpm sequence.  The difference is that
the new function handles the internal tpm_init state internally and
doesn't return an error when trying to initialize the tpm multiple
times.  Replace the remaining instances

Signed-off-by: Ilias Apalodimas 
---
 test/py/tests/test_tpm2.py | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/test/py/tests/test_tpm2.py b/test/py/tests/test_tpm2.py
index 8cd3046285..5bbb2d2069 100644
--- a/test/py/tests/test_tpm2.py
+++ b/test/py/tests/test_tpm2.py
@@ -61,7 +61,7 @@ def test_tpm2_init(u_boot_console):
 skip_test = u_boot_console.config.env.get('env__tpm_device_test_skip', 
False)
 if skip_test:
 pytest.skip('skip TPM device test')
-u_boot_console.run_command('tpm2 init')
+u_boot_console.run_command('tpm2 autostart')
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
@@ -97,11 +97,7 @@ def test_tpm2_sandbox_self_test_full(u_boot_console):
 """
 if is_sandbox(u_boot_console):
 u_boot_console.restart_uboot()
-u_boot_console.run_command('tpm2 init')
-output = u_boot_console.run_command('echo $?')
-assert output.endswith('0')
-
-u_boot_console.run_command('tpm2 startup TPM2_SU_CLEAR')
+u_boot_console.run_command('tpm2 autostart')
 output = u_boot_console.run_command('echo $?')
 assert output.endswith('0')
 
-- 
2.39.3



[PATCH v10 02/10] tpm: sandbox: Update for needed TPM2 capabilities

2023-08-07 Thread Eddie James
The driver needs to support getting the PCRs in the capabilities
command. Fix various other things and support the max number
of PCRs for TPM2.
Remove the !SANDBOX dependency for EFI TCG2 as well.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
Acked-by: Ilias Apalodimas 
---
Changes since v8:
 - Use >= for checking the property against TPM2_PROPERTIES_OFFSET

Changes since v5:
 - Remove the !SANDBOX dependency for EFI TCG2
 
 drivers/tpm/tpm2_tis_sandbox.c | 100 -
 lib/efi_loader/Kconfig |   2 -
 2 files changed, 72 insertions(+), 30 deletions(-)

diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
index e4004cfcca..d15a28d9fc 100644
--- a/drivers/tpm/tpm2_tis_sandbox.c
+++ b/drivers/tpm/tpm2_tis_sandbox.c
@@ -22,11 +22,6 @@ enum tpm2_hierarchy {
TPM2_HIERARCHY_NB,
 };
 
-/* Subset of supported capabilities */
-enum tpm2_capability {
-   TPM_CAP_TPM_PROPERTIES = 0x6,
-};
-
 /* Subset of supported properties */
 #define TPM2_PROPERTIES_OFFSET 0x020E
 
@@ -38,7 +33,8 @@ enum tpm2_cap_tpm_property {
TPM2_PROPERTY_NB,
 };
 
-#define SANDBOX_TPM_PCR_NB 1
+#define SANDBOX_TPM_PCR_NB TPM2_MAX_PCRS
+#define SANDBOX_TPM_PCR_SELECT_MAX ((SANDBOX_TPM_PCR_NB + 7) / 8)
 
 /*
  * Information about our TPM emulation. This is preserved in the sandbox
@@ -433,7 +429,7 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const u8 
*sendbuf,
int i, j;
 
/* TPM2_GetProperty */
-   u32 capability, property, property_count;
+   u32 capability, property, property_count, val;
 
/* TPM2_PCR_Read/Extend variables */
int pcr_index = 0;
@@ -542,19 +538,32 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
u8 *sendbuf,
case TPM2_CC_GET_CAPABILITY:
capability = get_unaligned_be32(sent);
sent += sizeof(capability);
-   if (capability != TPM_CAP_TPM_PROPERTIES) {
-   printf("Sandbox TPM only support TPM_CAPABILITIES\n");
-   return TPM2_RC_HANDLE;
-   }
-
property = get_unaligned_be32(sent);
sent += sizeof(property);
-   property -= TPM2_PROPERTIES_OFFSET;
-
property_count = get_unaligned_be32(sent);
sent += sizeof(property_count);
-   if (!property_count ||
-   property + property_count > TPM2_PROPERTY_NB) {
+
+   switch (capability) {
+   case TPM2_CAP_PCRS:
+   break;
+   case TPM2_CAP_TPM_PROPERTIES:
+   if (!property_count) {
+   rc = TPM2_RC_HANDLE;
+   return sandbox_tpm2_fill_buf(recv, recv_len,
+tag, rc);
+   }
+
+   if (property >= TPM2_PROPERTIES_OFFSET &&
+   ((property - TPM2_PROPERTIES_OFFSET) +
+property_count > TPM2_PROPERTY_NB)) {
+   rc = TPM2_RC_HANDLE;
+   return sandbox_tpm2_fill_buf(recv, recv_len,
+tag, rc);
+   }
+   break;
+   default:
+   printf("Sandbox TPM2 only supports TPM2_CAP_PCRS or "
+  "TPM2_CAP_TPM_PROPERTIES\n");
rc = TPM2_RC_HANDLE;
return sandbox_tpm2_fill_buf(recv, recv_len, tag, rc);
}
@@ -578,18 +587,53 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
u8 *sendbuf,
put_unaligned_be32(capability, recv);
recv += sizeof(capability);
 
-   /* Give the number of properties that follow */
-   put_unaligned_be32(property_count, recv);
-   recv += sizeof(property_count);
-
-   /* Fill with the properties */
-   for (i = 0; i < property_count; i++) {
-   put_unaligned_be32(TPM2_PROPERTIES_OFFSET + property +
-  i, recv);
-   recv += sizeof(property);
-   put_unaligned_be32(tpm->properties[property + i],
-  recv);
-   recv += sizeof(property);
+   switch (capability) {
+   case TPM2_CAP_PCRS:
+   /* Give the number of algorithms supported - just 
SHA256 */
+   put_unaligned_be32(1, recv);
+   recv += sizeof(u32);
+
+   /* Give SHA256 algorithm */
+   put_unaligned_be16(TPM2_ALG_SHA256, recv);
+   recv += sizeof(u16);
+
+   /* Select the PCRs supported */
+   *recv 

[PATCH v10 00/10] tpm: Support boot measurements

2023-08-07 Thread Eddie James
This series adds support for measuring the boot images more generically
than the existing EFI support. Several EFI functions have been moved to
the TPM layer. The series includes optional measurement from the bootm 
command.
A new test case has been added for the bootm measurement to test the new
path, and the sandbox TPM2 driver has been updated to support this use
case.

Changes since v9:
 - Rebase and add Ilias' fixes (thanks!)

Changes since v8:
 - Fix a sandbox driver off-by-one error in checking the property type.
 - Fix log parsing again - any data corruption seen while replaying the
   event log was failing the entire measurement.
 - Added an option to ignore the existing log and a configuration option
   for systems to select that for the bootm measurement. This would only
   be selected for systems that know that U-Boot is the first stage
   bootloader. This is necessary because the reserved memory region may
   persist through resets and so U-Boot attempts to append to the
   previous boot's log.

Changes since v7:
 - Change name of tcg2_init_log and add more documentation
 - Add a check, when parsing the event log header, to ensure that the
   previous stage bootloader used all the active PCRs.
 - Change name of tcg2_log_find_end
 - Fix the greater than or equal to check to exit the log parsing
 - Make sure log_position is 0 if there is any error discovering the log
 - Return errors parsing the log if the data is corrupt so that we don't
   end up with half a log

Changes since v6:
 - Added comment for bootm_measure
 - Fixed line length in bootm_measure
 - Added Linaro copyright for all the EFI moved code
 - Changed tcg2_init_log (and by extension, tcg2_measurement_init) to
   copy any discovered event log to the user's log if passed in.

Changes since v5:
 - Re-ordered the patches to put the sandbox TPM driver patch second
 - Remove unused platform_get_eventlog in efi_tcg2.c
 - First look for tpm_event_log_* properties instead of linux,sml-*
 - Fix efi_tcg2.c compilation
 - Select SHA* configs
 - Remove the !SANDBOX dependency for EFI TCG2
 - Only compile in the measurement u-boot command when CONFIG_MEASURED_BOOT
   is enabled

Changes since v4:
 - Remove tcg2_measure_event function and check for NULL data in
   tcg2_measure_data
 - Use tpm_auto_startup
 - Fix efi_tcg2.c compilation for removing tcg2_pcr_read function
 - Change PCR indexes for initrd and dtb
 - Drop u8 casting in measurement test
 - Use bullets in documentation

Changes since v3:
 - Reordered headers
 - Refactored more of EFI code into common code
Removed digest_info structure and instead used the common alg_to_mask
  and alg_to_len
Improved event log parsing in common code to get it equivalent to EFI
  Common code now extends PCR if previous bootloader stage couldn't
  No need to allocate memory in the common code, so EFI copies the
  discovered buffer like it did before
Rename efi measure_event function

Changes since v2:
 - Add documentation.
 - Changed reserved memory address to the top of the RAM for sandbox dts.
 - Add measure state to booti and bootz.
 - Skip measurement for EFI images that should be measured

Changes since v1:
 - Refactor TPM layer functions to allow EFI system to use them, and
   remove duplicate EFI functions.
 - Add test case
 - Drop #ifdefs for bootm
 - Add devicetree measurement config option
 - Update sandbox TPM driver

Eddie James (6):
  tpm: Fix spelling for tpmu_ha union
  tpm: sandbox: Update for needed TPM2 capabilities
  tpm: Support boot measurements
  bootm: Support boot measurement
  test: Add sandbox TPM boot measurement
  doc: Add measured boot documentation

Ilias Apalodimas (4):
  efi_loader: fix EFI_ENTRY point on get_active_pcr_banks
  test: use a non system PCR for testing PCR extend
  test/py: only run 'tpm2 autostart' to init the tpm
  fix armv7 compilation warning

 arch/sandbox/dts/sandbox.dtsi  |   13 +
 arch/sandbox/dts/test.dts  |   13 +
 boot/Kconfig   |   32 +
 boot/bootm.c   |   74 +++
 cmd/booti.c|1 +
 cmd/bootm.c|2 +
 cmd/bootz.c|1 +
 configs/sandbox_defconfig  |1 +
 doc/usage/index.rst|1 +
 doc/usage/measured_boot.rst|   23 +
 drivers/tpm/tpm2_tis_sandbox.c |  100 ++-
 include/bootm.h|   11 +
 include/efi_tcg2.h |   44 --
 include/image.h|1 +
 include/test/suites.h  |1 +
 include/tpm-v2.h   |  263 +++-
 lib/Kconfig|4 +
 lib/efi_loader/Kconfig |2 -
 lib/efi_loader/efi_tcg2.c  | 1056 +++-
 lib/tpm-v2.c   |  814 
 test/boot/Makefile |1 +
 test/boot/measurement.c|   66 ++
 test/cmd_ut.c  |4 +
 test/py/tests/test_tpm2.py |   24 +-
 24 files changed, 1484 insertions(+), 1068 

[PATCH v10 07/10] efi_loader: fix EFI_ENTRY point on get_active_pcr_banks

2023-08-07 Thread Eddie James
From: Ilias Apalodimas 

Signed-off-by: Ilias Apalodimas 
---
 lib/efi_loader/efi_tcg2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 5f0f4b5dd2..829bae7436 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -718,16 +718,16 @@ efi_tcg2_get_active_pcr_banks(struct efi_tcg2_protocol 
*this,
struct udevice *dev;
efi_status_t ret;
 
+   EFI_ENTRY("%p, %p", this, active_pcr_banks);
+
if (!this || !active_pcr_banks) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
-
ret = tcg2_platform_get_tpm2();
if (ret != EFI_SUCCESS)
goto out;
 
-   EFI_ENTRY("%p, %p", this, active_pcr_banks);
ret = tcg2_get_active_pcr_banks(dev, active_pcr_banks);
 
 out:
-- 
2.39.3



[PATCH v10 04/10] bootm: Support boot measurement

2023-08-07 Thread Eddie James
Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
---
Changes since v8:
 - Added a configuration option to select to ignore any existing
   event log. This would only be selected for systems that know
   that U-Boot is the first stage bootloader. This is necessary
   because the reserved memory region may persist through resets
   and so U-Boot attempts to append to the previous boot's log.

Changes since v6:
 - Added comment for bootm_measure
 - Fixed line length in bootm_measure

 boot/Kconfig| 32 +
 boot/bootm.c| 74 +
 cmd/booti.c |  1 +
 cmd/bootm.c |  2 ++
 cmd/bootz.c |  1 +
 include/bootm.h | 11 
 include/image.h |  1 +
 7 files changed, 122 insertions(+)

diff --git a/boot/Kconfig b/boot/Kconfig
index a643a3d128..b160b20599 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -675,6 +675,38 @@ config LEGACY_IMAGE_FORMAT
  loaded. If a board needs the legacy image format support in this
  case, enable it here.
 
+config MEASURED_BOOT
+   bool "Measure boot images and configuration to TPM and event log"
+   depends on HASH && TPM_V2
+   help
+ This option enables measurement of the boot process. Measurement
+ involves creating cryptographic hashes of the binary images that
+ are booting and storing them in the TPM. In addition, a log of
+ these hashes is stored in memory for the OS to verify the booted
+ images and configuration. Enable this if the OS has configured
+ some memory area for the event log and you intend to use some
+ attestation tools on your system.
+
+if MEASURED_BOOT
+   config MEASURE_DEVICETREE
+   bool "Measure the devicetree image"
+   default y if MEASURED_BOOT
+   help
+ On some platforms, the devicetree is not static as it may contain
+ random MAC addresses or other such data that changes each boot.
+ Therefore, it should not be measured into the TPM. In that case,
+ disable the measurement here.
+
+   config MEASURE_IGNORE_LOG
+   bool "Ignore the existing event log"
+   default n
+   help
+ On platforms that use an event log memory region that persists
+ through system resets and are the first stage bootloader, then
+ this option should be enabled to ignore any existing data in the
+ event log memory region.
+endif # MEASURED_BOOT
+
 config SUPPORT_RAW_INITRD
bool "Enable raw initrd images"
help
diff --git a/boot/bootm.c b/boot/bootm.c
index 75f0b4a9af..c20a688749 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #if defined(CONFIG_CMD_USB)
 #include 
 #endif
@@ -673,6 +674,75 @@ int bootm_process_cmdline_env(int flags)
return 0;
 }
 
+int bootm_measure(struct bootm_headers *images)
+{
+   int ret = 0;
+
+   /* Skip measurement if EFI is going to do it */
+   if (images->os.os == IH_OS_EFI &&
+   IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
+   IS_ENABLED(CONFIG_BOOTM_EFI))
+   return ret;
+
+   if (IS_ENABLED(CONFIG_MEASURED_BOOT)) {
+   struct tcg2_event_log elog;
+   struct udevice *dev;
+   void *initrd_buf;
+   void *image_buf;
+   const char *s;
+   u32 rd_len;
+   bool ign;
+
+   elog.log_size = 0;
+   ign = IS_ENABLED(CONFIG_MEASURE_IGNORE_LOG);
+   ret = tcg2_measurement_init(, , ign);
+   if (ret)
+   return ret;
+
+   image_buf = map_sysmem(images->os.image_start,
+  images->os.image_len);
+   ret = tcg2_measure_data(dev, , 8, images->os.image_len,
+   image_buf, EV_COMPACT_HASH,
+   strlen("linux") + 1, (u8 *)"linux");
+   if (ret)
+   goto unmap_image;
+
+   rd_len = images->rd_end - images->rd_start;
+   initrd_buf = map_sysmem(images->rd_start, rd_len);
+   ret = tcg2_measure_data(dev, , 9, rd_len, initrd_buf,
+   EV_COMPACT_HASH, strlen("initrd") + 1,
+   (u8 *)"initrd");
+   if (ret)
+   goto unmap_initrd;
+
+   if (IS_ENABLED(CONFIG_MEASURE_DEVICETREE)) {
+   ret = tcg2_measure_data(dev, , 0, images->ft_len,
+   (u8 *)images->ft_addr,
+   EV_TABLE_OF_DEVICES,
+   strlen("dts") + 1,
+ 

[PATCH v10 06/10] doc: Add measured boot documentation

2023-08-07 Thread Eddie James
Briefly describe the feature and specify the requirements.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
---
 doc/usage/index.rst |  1 +
 doc/usage/measured_boot.rst | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 doc/usage/measured_boot.rst

diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 388e59f173..64eb362aef 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -13,6 +13,7 @@ Use U-Boot
partitions
cmdline
semihosting
+   measured_boot
 
 Shell commands
 --
diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst
new file mode 100644
index 00..8357b1f480
--- /dev/null
+++ b/doc/usage/measured_boot.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Measured Boot
+=
+
+U-Boot can perform a measured boot, the process of hashing various components
+of the boot process, extending the results in the TPM and logging the
+component's measurement in memory for the operating system to consume.
+
+Requirements
+-
+
+* A hardware TPM 2.0 supported by the U-Boot drivers
+* CONFIG_TPM=y
+* CONFIG_MEASURED_BOOT=y
+* Device-tree configuration of the TPM device to specify the memory area
+  for event logging. The TPM device node must either contain a phandle to
+  a reserved memory region or "linux,sml-base" and "linux,sml-size"
+  indicating the address and size of the memory region. An example can be
+  found in arch/sandbox/dts/test.dts
+* The operating system must also be configured to use the memory regions
+  specified in the U-Boot device-tree in order to make use of the event
+  log.
-- 
2.39.3



Re: [PATCH v7 08/11] binman: capsule: Add support for generating EFI capsules

2023-08-07 Thread Simon Glass
Hi Sughosh,

On Mon, 7 Aug 2023 at 00:40, Sughosh Ganu  wrote:
>
> hi Simon,
>
> On Mon, 7 Aug 2023 at 07:04, Simon Glass  wrote:
> >
> > Hi Sughosh,
> >
> > On Sun, 6 Aug 2023 at 13:27, Sughosh Ganu  wrote:
> > >
> > > hi Simon,
> > >
> > > On Mon, 7 Aug 2023 at 00:16, Simon Glass  wrote:
> > > >
> > > > Hi Sughosh,
> > > >
> > > > On Sun, 6 Aug 2023 at 09:35, Sughosh Ganu  
> > > > wrote:
> > > > >
> > > > > hi Simon,
> > > > >
> > > > > On Sat, 5 Aug 2023 at 22:50, Simon Glass  wrote:
> > > > > >
> > > > > > Hi Sughosh,
> > > > > >
> > > > > > On Sat, 5 Aug 2023 at 09:03, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Sughosh,
> > > > > > >
> > > > > > > On Sat, 5 Aug 2023 at 05:35, Sughosh Ganu 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Add support in binman for generating EFI capsules. The capsule
> > > > > > > > parameters can be specified through the capsule binman entry. 
> > > > > > > > Also add
> > > > > > > > test cases in binman for testing capsule generation.
> > > > > > > >
> > > > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > > > ---
> > > > > > > > Changes since V6:
> > > > > > > > * Add macros for the GUID strings in sandbox_efi_capsule.h
> > > > > > > > * Highlight that the private and public keys are mandatory for 
> > > > > > > > capsule
> > > > > > > >   signing.
> > > > > > > > * Add a URL link to the UEFI spec, as used in the rst files.
> > > > > > > > * Use local vars for private and public keys in 
> > > > > > > > BuildSectionData()
> > > > > > > > * Use local vars for input payload and capsule filenames in
> > > > > > > >   BuildSectionData().
> > > > > > > > * Drop the ProcessContents() and SetImagePos() as the superclass
> > > > > > > >   functions suffice.
> > > > > > > > * Use GUID macro names in the capsule test dts files.
> > > > > > > > * Rename efi_capsule_payload.bin to capsule_input.bin.
> > > > > > > >
> > > > > > > >
> > > > > > > >  include/sandbox_efi_capsule.h |  14 ++
> > > > > > >
> > > > > > > Please move this file to a later patch - see below.
> > > > > > >
> > > > > > > Could we have a single header file with all the GUIDs, i.e. 
> > > > > > > sandbox, ARM, etc.
> > > > > > >
> > > > > > > >  tools/binman/entries.rst  |  62 
> > > > > > > >  tools/binman/etype/efi_capsule.py | 143 
> > > > > > > > ++
> > > > > > > >  tools/binman/ftest.py | 121 
> > > > > > > > +++
> > > > > > > >  tools/binman/test/307_capsule.dts |  23 +++
> > > > > > > >  tools/binman/test/308_capsule_signed.dts  |  25 +++
> > > > > > > >  tools/binman/test/309_capsule_version.dts |  24 +++
> > > > > > > >  tools/binman/test/310_capsule_signed_ver.dts  |  26 
> > > > > > > >  tools/binman/test/311_capsule_oemflags.dts|  24 +++
> > > > > > > >  tools/binman/test/312_capsule_missing_key.dts |  24 +++
> > > > > > > >  .../binman/test/313_capsule_missing_index.dts |  22 +++
> > > > > > > >  .../binman/test/314_capsule_missing_guid.dts  |  19 +++
> > > > > > > >  .../test/315_capsule_missing_payload.dts  |  19 +++
> > > > > > > >  13 files changed, 546 insertions(+)
> > > > > > > >  create mode 100644 include/sandbox_efi_capsule.h
> > > > > > > >  create mode 100644 tools/binman/etype/efi_capsule.py
> > > > > > > >  create mode 100644 tools/binman/test/307_capsule.dts
> > > > > > > >  create mode 100644 tools/binman/test/308_capsule_signed.dts
> > > > > > > >  create mode 100644 tools/binman/test/309_capsule_version.dts
> > > > > > > >  create mode 100644 tools/binman/test/310_capsule_signed_ver.dts
> > > > > > > >  create mode 100644 tools/binman/test/311_capsule_oemflags.dts
> > > > > > > >  create mode 100644 
> > > > > > > > tools/binman/test/312_capsule_missing_key.dts
> > > > > > > >  create mode 100644 
> > > > > > > > tools/binman/test/313_capsule_missing_index.dts
> > > > > > > >  create mode 100644 
> > > > > > > > tools/binman/test/314_capsule_missing_guid.dts
> > > > > > > >  create mode 100644 
> > > > > > > > tools/binman/test/315_capsule_missing_payload.dts
> > > > > > > >
> > > > > >
> > > > > > [..]
> > > > > >
> > > > > > > > diff --git a/tools/binman/test/307_capsule.dts 
> > > > > > > > b/tools/binman/test/307_capsule.dts
> > > > > > > > new file mode 100644
> > > > > > > > index 00..86552ff83f
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/tools/binman/test/307_capsule.dts
> > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > > > > +
> > > > > > > > +/dts-v1/;
> > > > > > > > +
> > > > > > > > +#include 
> > > > > > >
> > > > > > > We can't include sandbox files in binman! I Does it actually 
> > > > > > > matter
> > > > > > > what the GUID value is? Can they all be the same? For now I think 
> > > > > > > it
> > > > > > > is best to have
> > > > > > >
> > > > > > > #define BINMAN_TEST_GUID "xxx"
> > > > > > >
> > > > > > > repeated at the top of each .dts file. 

Re: [PATCH v9 4/6] bootm: Support boot measurement

2023-08-07 Thread Eddie James



On 8/7/23 09:52, Ilias Apalodimas wrote:

Hi,

On Mon, 7 Aug 2023 at 17:43, Eddie James  wrote:


On 8/4/23 13:10, Sean Edmond wrote:

On 2023-03-08 1:25 p.m., Eddie James wrote:

Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
---
Changes since v8:
   - Added a configuration option to select to ignore any existing
 event log. This would only be selected for systems that know
 that U-Boot is the first stage bootloader. This is necessary
 because the reserved memory region may persist through resets
 and so U-Boot attempts to append to the previous boot's log.

Changes since v6:
   - Added comment for bootm_measure
   - Fixed line length in bootm_measure

   boot/Kconfig| 32 +
   boot/bootm.c| 74 +
   cmd/booti.c |  1 +
   cmd/bootm.c |  2 ++
   cmd/bootz.c |  1 +
   include/bootm.h | 11 
   include/image.h |  1 +
   7 files changed, 122 insertions(+)

diff --git a/boot/Kconfig b/boot/Kconfig
index 5f491625c8..8119519c9f 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -629,6 +629,38 @@ config LEGACY_IMAGE_FORMAT
 loaded. If a board needs the legacy image format support in this
 case, enable it here.
   +config MEASURED_BOOT
+bool "Measure boot images and configuration to TPM and event log"
+depends on HASH && TPM_V2
+help
+  This option enables measurement of the boot process. Measurement
+  involves creating cryptographic hashes of the binary images that
+  are booting and storing them in the TPM. In addition, a log of
+  these hashes is stored in memory for the OS to verify the booted
+  images and configuration. Enable this if the OS has configured
+  some memory area for the event log and you intend to use some
+  attestation tools on your system.
+
+if MEASURED_BOOT
+config MEASURE_DEVICETREE
+bool "Measure the devicetree image"
+default y if MEASURED_BOOT
+help
+  On some platforms, the devicetree is not static as it may contain
+  random MAC addresses or other such data that changes each boot.
+  Therefore, it should not be measured into the TPM. In that case,
+  disable the measurement here.
+
+config MEASURE_IGNORE_LOG
+bool "Ignore the existing event log"
+default n
+help
+  On platforms that use an event log memory region that persists
+  through system resets and are the first stage bootloader, then
+  this option should be enabled to ignore any existing data in the
+  event log memory region.
+endif # MEASURED_BOOT
+
   config SUPPORT_RAW_INITRD
   bool "Enable raw initrd images"
   help
diff --git a/boot/bootm.c b/boot/bootm.c
index 2eec60ec7b..2685bdbd74 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -22,6 +22,7 @@
   #include 
   #include 
   #include 
+#include 
   #if defined(CONFIG_CMD_USB)
   #include 
   #endif
@@ -659,6 +660,75 @@ int bootm_process_cmdline_env(int flags)
   return 0;
   }
   +int bootm_measure(struct bootm_headers *images)
+{
+int ret = 0;
+
+/* Skip measurement if EFI is going to do it */
+if (images->os.os == IH_OS_EFI &&
+IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
+IS_ENABLED(CONFIG_BOOTM_EFI))
+return ret;
+

it looks like your measured boot implementation is hardcoding the
following PCR indexes:

PCR #8 - kernel image measurement
PCR #9 - initrd measurement
PCR #0 - kernel DTB measurement
PCR #1 - bootargs measurement


Hi,


Yes, I followed this document as closely as I could:
https://trustedcomputinggroup.org/wp-content/uploads/TCG_ServerManagementDomainFirmwareProfile_v1p00_11aug2020.pdf

Which provides what should go in what PCR. I can understand users
wanting a different setup, but as you say, that's probably out of the
scope of this series.


Completely out of scope* of the series.  The purpose is follow the TCG
spec.  The minor deviations is our choice of the DTB in PCR1 (but
that's what the spec does for ACPI tables) and the choice for initrd
(which is what we do in the linux kernel).

We can reuse the functions ofc to measure random blobs, but that would
require some kind of config (maybe in a dts??) of what to measure.


Eddie,  I've pinged you in the past.  I rebased and fixed a few issues
of your tree here [0]. Do you plan to resend it at some point?

[0]https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commits/eddie2/



Yes, sorry for the delay. I'll resend it now. Thank you for rebasing!

Thanks,

Eddie




Cheers
/Ilias

Thanks,

Eddie



I wasn't able to find any specificaton on this measured boot
"profile".  Are you able to provide a reference?

We've implemented our own version of measured boot, which maps
measurements to different PCR indexes.  In many cases, the data we're
measuring is also different.

To make this 

Re: [PATCH v9 4/6] bootm: Support boot measurement

2023-08-07 Thread Ilias Apalodimas
Hi,

On Mon, 7 Aug 2023 at 17:43, Eddie James  wrote:
>
>
> On 8/4/23 13:10, Sean Edmond wrote:
> > On 2023-03-08 1:25 p.m., Eddie James wrote:
> >> Add a configuration option to measure the boot through the bootm
> >> function. Add the measurement state to the booti and bootz paths
> >> as well.
> >>
> >> Signed-off-by: Eddie James 
> >> Reviewed-by: Simon Glass 
> >> ---
> >> Changes since v8:
> >>   - Added a configuration option to select to ignore any existing
> >> event log. This would only be selected for systems that know
> >> that U-Boot is the first stage bootloader. This is necessary
> >> because the reserved memory region may persist through resets
> >> and so U-Boot attempts to append to the previous boot's log.
> >>
> >> Changes since v6:
> >>   - Added comment for bootm_measure
> >>   - Fixed line length in bootm_measure
> >>
> >>   boot/Kconfig| 32 +
> >>   boot/bootm.c| 74 +
> >>   cmd/booti.c |  1 +
> >>   cmd/bootm.c |  2 ++
> >>   cmd/bootz.c |  1 +
> >>   include/bootm.h | 11 
> >>   include/image.h |  1 +
> >>   7 files changed, 122 insertions(+)
> >>
> >> diff --git a/boot/Kconfig b/boot/Kconfig
> >> index 5f491625c8..8119519c9f 100644
> >> --- a/boot/Kconfig
> >> +++ b/boot/Kconfig
> >> @@ -629,6 +629,38 @@ config LEGACY_IMAGE_FORMAT
> >> loaded. If a board needs the legacy image format support in this
> >> case, enable it here.
> >>   +config MEASURED_BOOT
> >> +bool "Measure boot images and configuration to TPM and event log"
> >> +depends on HASH && TPM_V2
> >> +help
> >> +  This option enables measurement of the boot process. Measurement
> >> +  involves creating cryptographic hashes of the binary images that
> >> +  are booting and storing them in the TPM. In addition, a log of
> >> +  these hashes is stored in memory for the OS to verify the booted
> >> +  images and configuration. Enable this if the OS has configured
> >> +  some memory area for the event log and you intend to use some
> >> +  attestation tools on your system.
> >> +
> >> +if MEASURED_BOOT
> >> +config MEASURE_DEVICETREE
> >> +bool "Measure the devicetree image"
> >> +default y if MEASURED_BOOT
> >> +help
> >> +  On some platforms, the devicetree is not static as it may contain
> >> +  random MAC addresses or other such data that changes each boot.
> >> +  Therefore, it should not be measured into the TPM. In that case,
> >> +  disable the measurement here.
> >> +
> >> +config MEASURE_IGNORE_LOG
> >> +bool "Ignore the existing event log"
> >> +default n
> >> +help
> >> +  On platforms that use an event log memory region that persists
> >> +  through system resets and are the first stage bootloader, then
> >> +  this option should be enabled to ignore any existing data in the
> >> +  event log memory region.
> >> +endif # MEASURED_BOOT
> >> +
> >>   config SUPPORT_RAW_INITRD
> >>   bool "Enable raw initrd images"
> >>   help
> >> diff --git a/boot/bootm.c b/boot/bootm.c
> >> index 2eec60ec7b..2685bdbd74 100644
> >> --- a/boot/bootm.c
> >> +++ b/boot/bootm.c
> >> @@ -22,6 +22,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #if defined(CONFIG_CMD_USB)
> >>   #include 
> >>   #endif
> >> @@ -659,6 +660,75 @@ int bootm_process_cmdline_env(int flags)
> >>   return 0;
> >>   }
> >>   +int bootm_measure(struct bootm_headers *images)
> >> +{
> >> +int ret = 0;
> >> +
> >> +/* Skip measurement if EFI is going to do it */
> >> +if (images->os.os == IH_OS_EFI &&
> >> +IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
> >> +IS_ENABLED(CONFIG_BOOTM_EFI))
> >> +return ret;
> >> +
> >
> > it looks like your measured boot implementation is hardcoding the
> > following PCR indexes:
> >
> > PCR #8 - kernel image measurement
> > PCR #9 - initrd measurement
> > PCR #0 - kernel DTB measurement
> > PCR #1 - bootargs measurement
>
>
> Hi,
>
>
> Yes, I followed this document as closely as I could:
> https://trustedcomputinggroup.org/wp-content/uploads/TCG_ServerManagementDomainFirmwareProfile_v1p00_11aug2020.pdf
>
> Which provides what should go in what PCR. I can understand users
> wanting a different setup, but as you say, that's probably out of the
> scope of this series.
>

Completely out of scope* of the series.  The purpose is follow the TCG
spec.  The minor deviations is our choice of the DTB in PCR1 (but
that's what the spec does for ACPI tables) and the choice for initrd
(which is what we do in the linux kernel).

We can reuse the functions ofc to measure random blobs, but that would
require some kind of config (maybe in a dts??) of what to measure.


Eddie,  I've pinged you in the past.  I rebased and fixed a few issues
of your tree here [0]. Do you plan to resend it at some point?


Re: [PATCH v19 8/9] arm_ffa: efi: introduce FF-A MM communication

2023-08-07 Thread Ilias Apalodimas
On Fri, Aug 04, 2023 at 02:33:44PM +0100, Abdellatif El Khlifi wrote:
> Add MM communication support using FF-A transport
> 
> This feature allows accessing MM partitions services through
> EFI MM communication protocol. MM partitions such as StandAlonneMM
> or smm-gateway secure partitions which reside in secure world.
> 
> An MM shared buffer and a door bell event are used to exchange
> the data.
> 
> The data is used by EFI services such as GetVariable()/SetVariable()
> and copied from the communication buffer to the MM shared buffer.
> 
> The secure partition is notified about availability of data in the
> MM shared buffer by an FF-A message (door bell).
> 
> On such event, MM SP can read the data and updates the MM shared
> buffer with the response data.
> 
> The response data is copied back to the communication buffer and
> consumed by the EFI subsystem.
> 
> MM communication protocol supports FF-A 64-bit direct messaging.
> 
> We tested the FF-A MM communication on the Corstone-1000 platform.
> 
> We ran the UEFI SCT test suite containing EFI setVariable, getVariable and
> getNextVariable tests which involve FF-A MM communication and all tests
> are passing with the current changes.
> 
> We made the SCT test reports (part of the ACS results) public following the
> latest Corstone-1000 platform software release. Please find the test
> reports at [1].
> 
> [1]: 
> https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip
> 
> Signed-off-by: Abdellatif El Khlifi 
> Tested-by: Gowtham Suresh Kumar 
> Reviewed-by: Simon Glass 
> Cc: Tom Rini 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> 
> ---
> 
> Changelog:
> ===
> 
> v19:
> 
> Tom:
> 
> * use CONFIG_FFA_SHARED_MM_BUF_* in place of macros
> 
> v18:
> 
> Ilias, Tom:
> 
> * drop the use of configs for the shared MM buffer, put back #ifdefs instead
> * add test information to the commit log
> 

Thanks for the quick rework.  I like the fact you have the SMC as a
fallback to FF-A in case it's not discovered.  Once and if we get dynamic 
buffer allocation for the NS-world we can easily switch this to an
automatically scanable feature again.

Tom, I am fine with the series now.  I've reviewed the relevant EFI and asm
bits, feel free to pull it in if the rest of the people are happy. 

Reviewed-by: Ilias Apalodimas 



> v17:
> 
> * show a debug message rather than an error when FF-A is not detected
> 
> v16:
> 
> * lib/efi_loader/Kconfig:
>rather than automatically selecting OPTEE and ARM_FFA_TRANSPORT configs by
>EFI_MM_COMM_TEE, set them as dependencies (Otherwise FF-A will be 
> automatically
>enabled for boards that don't need it).
> 
> v15:
> 
> Simon:
> 
> * replace FFA_SHARED_MM_BUFFER_* defines with configs
> 
> v14:
> 
> Ilias:
> 
> * drop truncating var_payload->size when using FF-A
> * map the MM SP return codes to errnos
> 
> v13:
> 
> * remove FF-A and Optee ifdefs
> 
> v12:
> 
> * drop use of calloc when querying SPs
> * address nits
> 
> v11:
> 
> * rename select_ffa_mm_comms() to select_mm_comms()
> * improve the logic of MM transport selection in mm_communicate()
> * addressing nits
> 
> v10:
> 
> * use the FF-A driver Uclass operations
> * use uclass_first_device()
> * addressing nits
> 
> v9: align how FF-A is used with FF-A discovery through DM
> 
> v8:
> 
> * isolate the compilation choices between FF-A and OP-TEE
> * update partition_info_get() second argument to be an SP count
> * pass NULL device pointer to the FF-A bus discovery and operations
> 
> v7:
> 
> * set the MM door bell event to use 64-bit direct messaging
> * issue a compile time error when one of these macros are not found :
>   FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_OFFSET, 
> FFA_SHARED_MM_BUFFER_ADDR
> * make mm_sp_svc_uuid static
> * replace EINVAL with ENOMEM in ffa_discover_mm_sp_id() when calloc() fails
> * improve use of unmap_sysmem() in ffa_mm_communicate()
> 
> v6:
> 
> * add FF-A runtime discovery at MM communication level
> * drop EFI runtime support for FF-A MM communication
> * revert the changes in include/mm_communication.h for
>   efi_mm_communicate_header and smm_variable_access structures
> 
> v4:
> 
> * use the new FF-A driver interfaces
> * discover MM partitions at runtime
> * copy FF-A driver private data to EFI runtime section at
>   ExitBootServices()
> * drop use of FFA_ERR_STAT_SUCCESS error code
> * replace EFI_BUFFER_TOO_SMALL with EFI_OUT_OF_RESOURCES
>   in ffa_mm_communicate(). No need for efi_memcpy_runtime() anymore
> * revert the error log in mm_communicate() in case of failure
> * remove packed attribute from efi_mm_communicate_header and
>   smm_variable_communicate_header
> 
> v2:
> 
> * set default values to 0 for FFA_SHARED_MM_BUFFER_SIZE, 
> FFA_SHARED_MM_BUFFER_ADDR and MM_SP_UUID_DATA and add warnings
> 
> v1:
> 
> * introduce FF-A MM communication
> 
> include/mm_communication.h|  

Re: [PATCH v9 4/6] bootm: Support boot measurement

2023-08-07 Thread Eddie James



On 8/4/23 13:10, Sean Edmond wrote:

On 2023-03-08 1:25 p.m., Eddie James wrote:

Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
---
Changes since v8:
  - Added a configuration option to select to ignore any existing
    event log. This would only be selected for systems that know
    that U-Boot is the first stage bootloader. This is necessary
    because the reserved memory region may persist through resets
    and so U-Boot attempts to append to the previous boot's log.

Changes since v6:
  - Added comment for bootm_measure
  - Fixed line length in bootm_measure

  boot/Kconfig    | 32 +
  boot/bootm.c    | 74 +
  cmd/booti.c |  1 +
  cmd/bootm.c |  2 ++
  cmd/bootz.c |  1 +
  include/bootm.h | 11 
  include/image.h |  1 +
  7 files changed, 122 insertions(+)

diff --git a/boot/Kconfig b/boot/Kconfig
index 5f491625c8..8119519c9f 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -629,6 +629,38 @@ config LEGACY_IMAGE_FORMAT
    loaded. If a board needs the legacy image format support in this
    case, enable it here.
  +config MEASURED_BOOT
+    bool "Measure boot images and configuration to TPM and event log"
+    depends on HASH && TPM_V2
+    help
+  This option enables measurement of the boot process. Measurement
+  involves creating cryptographic hashes of the binary images that
+  are booting and storing them in the TPM. In addition, a log of
+  these hashes is stored in memory for the OS to verify the booted
+  images and configuration. Enable this if the OS has configured
+  some memory area for the event log and you intend to use some
+  attestation tools on your system.
+
+if MEASURED_BOOT
+    config MEASURE_DEVICETREE
+    bool "Measure the devicetree image"
+    default y if MEASURED_BOOT
+    help
+  On some platforms, the devicetree is not static as it may contain
+  random MAC addresses or other such data that changes each boot.
+  Therefore, it should not be measured into the TPM. In that case,
+  disable the measurement here.
+
+    config MEASURE_IGNORE_LOG
+    bool "Ignore the existing event log"
+    default n
+    help
+  On platforms that use an event log memory region that persists
+  through system resets and are the first stage bootloader, then
+  this option should be enabled to ignore any existing data in the
+  event log memory region.
+endif # MEASURED_BOOT
+
  config SUPPORT_RAW_INITRD
  bool "Enable raw initrd images"
  help
diff --git a/boot/bootm.c b/boot/bootm.c
index 2eec60ec7b..2685bdbd74 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 
  #if defined(CONFIG_CMD_USB)
  #include 
  #endif
@@ -659,6 +660,75 @@ int bootm_process_cmdline_env(int flags)
  return 0;
  }
  +int bootm_measure(struct bootm_headers *images)
+{
+    int ret = 0;
+
+    /* Skip measurement if EFI is going to do it */
+    if (images->os.os == IH_OS_EFI &&
+    IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
+    IS_ENABLED(CONFIG_BOOTM_EFI))
+    return ret;
+


it looks like your measured boot implementation is hardcoding the 
following PCR indexes:


PCR #8 - kernel image measurement
PCR #9 - initrd measurement
PCR #0 - kernel DTB measurement
PCR #1 - bootargs measurement



Hi,


Yes, I followed this document as closely as I could: 
https://trustedcomputinggroup.org/wp-content/uploads/TCG_ServerManagementDomainFirmwareProfile_v1p00_11aug2020.pdf


Which provides what should go in what PCR. I can understand users 
wanting a different setup, but as you say, that's probably out of the 
scope of this series.



Thanks,

Eddie




I wasn't able to find any specificaton on this measured boot 
"profile".  Are you able to provide a reference?


We've implemented our own version of measured boot, which maps 
measurements to different PCR indexes.  In many cases, the data we're 
measuring is also different.


To make this feature more usable by others it would be nice to see a 
more generic interface that would allow the user to specify the PCR 
indexes, and the data to hash into these indexes.  This would allow 
everyone to create their own custom measured boot "profile".  This 
request is probably beyond the scope of your current efforts, but I 
except this implementation to evolve significantly if/when it's accepted.



+    if (IS_ENABLED(CONFIG_MEASURED_BOOT)) {
+    struct tcg2_event_log elog;
+    struct udevice *dev;
+    void *initrd_buf;
+    void *image_buf;
+    const char *s;
+    u32 rd_len;
+    bool ign;
+
+    elog.log_size = 0;
+    ign = IS_ENABLED(CONFIG_MEASURE_IGNORE_LOG);
+    ret = tcg2_measurement_init(, , ign);
+    if (ret)
+    return ret;
+
+    

Re: [PATCH 4/7] net: dwc_eth_qos: Add glue driver for GMAC on Rockchip RK3568

2023-08-07 Thread Eugen Hristev

Hi Jonas,

Thank you for your work,

On 8/7/23 03:08, Jonas Karlman wrote:

Add a new glue driver for Rockchip SoCs, i.e RK3568, with a GMAC based
on Synopsys DWC Ethernet QoS IP.

rk_gmac_ops was ported from linux commit:
3bb3d6b1c195 ("net: stmmac: Add RK3566/RK3568 SoC support")

Signed-off-by: Jonas Karlman 
---
Cc: David Wu 
Cc: Ezequiel Garcia 
---
  drivers/net/Kconfig|   8 +
  drivers/net/Makefile   |   1 +
  drivers/net/dwc_eth_qos.c  |   8 +-
  drivers/net/dwc_eth_qos.h  |   2 +
  drivers/net/dwc_eth_qos_rockchip.c | 348 +
  5 files changed, 365 insertions(+), 2 deletions(-)
  create mode 100644 drivers/net/dwc_eth_qos_rockchip.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0ed39a61e4de..29304fd77759 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -225,6 +225,14 @@ config DWC_ETH_QOS_IMX
  The Synopsys Designware Ethernet QOS IP block with the specific
  configuration used in IMX soc.
  
+config DWC_ETH_QOS_ROCKCHIP

+   bool "Synopsys DWC Ethernet QOS device support for Rockchip SoCs"
+   depends on DWC_ETH_QOS
+   select DM_ETH_PHY
+   help
+ The Synopsys Designware Ethernet QOS IP block with specific
+ configuration used in Rockchip SoCs.
+
  config DWC_ETH_QOS_STM32
bool "Synopsys DWC Ethernet QOS device support for STM32"
depends on DWC_ETH_QOS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d4af253b6f28..1d444f5b4a69 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_DRIVER_DM9000) += dm9000x.o
  obj-$(CONFIG_DSA_SANDBOX) += dsa_sandbox.o
  obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
  obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
+obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
  obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
  obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
  obj-$(CONFIG_E1000) += e1000.o
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 24fb3fac1f12..9fb98a2c3c74 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1707,7 +1707,12 @@ static const struct udevice_id eqos_ids[] = {
.data = (ulong)_imx_config
},
  #endif
-
+#if IS_ENABLED(CONFIG_DWC_ETH_QOS_ROCKCHIP)
+   {
+   .compatible = "rockchip,rk3568-gmac",
+   .data = (ulong)_rockchip_config
+   },
+#endif
  #if IS_ENABLED(CONFIG_DWC_ETH_QOS_QCOM)
{
.compatible = "qcom,qcs404-ethqos",
@@ -1720,7 +1725,6 @@ static const struct udevice_id eqos_ids[] = {
.data = (ulong)_jh7110_config
},
  #endif
-

Unintended change ?

{ }
  };
  
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h

index 06a082da72ef..e3222e1e17e5 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -82,6 +82,7 @@ struct eqos_mac_regs {
  #define EQOS_MAC_MDIO_ADDRESS_PA_SHIFT21
  #define EQOS_MAC_MDIO_ADDRESS_RDA_SHIFT   16
  #define EQOS_MAC_MDIO_ADDRESS_CR_SHIFT8
+#define EQOS_MAC_MDIO_ADDRESS_CR_100_150   1
  #define EQOS_MAC_MDIO_ADDRESS_CR_20_352
  #define EQOS_MAC_MDIO_ADDRESS_CR_250_300  5
  #define EQOS_MAC_MDIO_ADDRESS_SKAPBIT(4)
@@ -287,5 +288,6 @@ void eqos_flush_buffer_generic(void *buf, size_t size);
  int eqos_null_ops(struct udevice *dev);
  
  extern struct eqos_config eqos_imx_config;

+extern struct eqos_config eqos_rockchip_config;
  extern struct eqos_config eqos_qcom_config;
  extern struct eqos_config eqos_jh7110_config;
diff --git a/drivers/net/dwc_eth_qos_rockchip.c 
b/drivers/net/dwc_eth_qos_rockchip.c
new file mode 100644
index ..c8abe351fc3e
--- /dev/null
+++ b/drivers/net/dwc_eth_qos_rockchip.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dwc_eth_qos.h"
+
+struct rk_gmac_ops {
+   const char *compatible;
+   int (*set_to_rgmii)(struct udevice *dev,
+   int tx_delay, int rx_delay);
+   int (*set_to_rmii)(struct udevice *dev);
+   int (*set_gmac_speed)(struct udevice *dev);
+   u32 regs[3];


Can't these be somehow const and point to a dedicated array for a 
specific SoC ?


Also I believe the naming 'regs' is a bit unfortunate, as it does not 
hold the usual regmap, rather an array of addresses hardcoded used to 
figure out which of the GMAC instances we are referring to.



+};
+
+struct rockchip_platform_data {
+   struct reset_ctl_bulk resets;
+   const struct rk_gmac_ops *ops;
+   int id;
+   struct regmap *grf;
+};
+
+#define HIWORD_UPDATE(val, mask, shift) \
+   ((val) << (shift) | (mask) << ((shift) + 16))
+

[PATCH v2 2/3] riscv: Add ZERO_MEM_BEFORE_USE implementation

2023-08-07 Thread Shengyu Qu
Add the actual support code for ZERO_MEM_BEFORE_USE and remove existing
Starfive JH7110's L2 LIM clean code, since existing code has following
issues:
 1. Each hart (in the middle of a function call) overwriting its own
stack and other harts' stacks.
(data-race and data-corruption)
 2. Lottery winner hart can be doing "board_init_f_init_reserve",
while other harts are in the middle of zeroing L2 LIM.
(data-race)

Signed-off-by: Bo Gan 
Signed-off-by: Shengyu Qu 
---
 arch/riscv/cpu/jh7110/spl.c | 25 -
 arch/riscv/cpu/start.S  | 12 
 common/init/board_init.c|  3 +++
 3 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
index 72adcefa0e..4047b10efe 100644
--- a/arch/riscv/cpu/jh7110/spl.c
+++ b/arch/riscv/cpu/jh7110/spl.c
@@ -13,7 +13,6 @@
 #include 
 
 #define CSR_U74_FEATURE_DISABLE0x7c1
-#define L2_LIM_MEM_END 0x81FUL
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -59,9 +58,6 @@ int spl_soc_init(void)
 
 void harts_early_init(void)
 {
-   ulong *ptr;
-   u8 *tmp;
-   ulong len, remain;
/*
 * Feature Disable CSR
 *
@@ -70,25 +66,4 @@ void harts_early_init(void)
 */
if (CONFIG_IS_ENABLED(RISCV_MMODE))
csr_write(CSR_U74_FEATURE_DISABLE, 0);
-
-   /* clear L2 LIM  memory
-* set __bss_end to 0x81F region to zero
-* The L2 Cache Controller supports ECC. ECC is applied to SRAM.
-* If it is not cleared, the ECC part is invalid, and an ECC error
-* will be reported when reading data.
-*/
-   ptr = (ulong *)&__bss_end;
-   len = L2_LIM_MEM_END - (ulong)&__bss_end;
-   remain = len % sizeof(ulong);
-   len /= sizeof(ulong);
-
-   while (len--)
-   *ptr++ = 0;
-
-   /* clear the remain bytes */
-   if (remain) {
-   tmp = (u8 *)ptr;
-   while (remain--)
-   *tmp++ = 0;
-   }
 }
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 59d58a5a57..30cf674370 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -111,6 +111,18 @@ call_board_init_f:
  * It's essential before any function call, otherwise, we get data-race.
  */
 
+/* clear stack if necessary */
+#if CONFIG_IS_ENABLED(ZERO_MEM_BEFORE_USE)
+clear_stack:
+   li  t1, 1
+   sllit1, t1, CONFIG_STACK_SIZE_SHIFT
+   sub t1, sp, t1
+clear_stack_loop:
+   SREGzero, 0(t1) /* t1 is always 16 byte aligned */
+   addit1, t1, REGBYTES
+   blt t1, sp, clear_stack_loop
+#endif
+
 call_board_init_f_0:
/* find top of reserve space */
 #if CONFIG_IS_ENABLED(SMP)
diff --git a/common/init/board_init.c b/common/init/board_init.c
index 96ffb79a98..ab8c508ad8 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -162,6 +162,9 @@ void board_init_f_init_reserve(ulong base)
 #if CONFIG_VAL(SYS_MALLOC_F_LEN)
/* go down one 'early malloc arena' */
gd->malloc_base = base;
+#if CONFIG_IS_ENABLED(ZERO_MEM_BEFORE_USE)
+   memset((void *)base, '\0', CONFIG_VAL(SYS_MALLOC_F_LEN));
+#endif
 #endif
 
if (CONFIG_IS_ENABLED(SYS_REPORT_STACK_F_USAGE))
-- 
2.41.0



[PATCH v2 3/3] riscv: cpu: jh7110: Select SPL_ZERO_MEM_BEFORE_USE

2023-08-07 Thread Shengyu Qu
Add Kconfig item for Starfive JH7110 to select SPL_ZERO_MEM_BEFORE_USE.

Signed-off-by: Bo Gan 
Signed-off-by: Shengyu Qu 
---
 arch/riscv/cpu/jh7110/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/cpu/jh7110/Kconfig b/arch/riscv/cpu/jh7110/Kconfig
index 4d9581165b..2e26d0731f 100644
--- a/arch/riscv/cpu/jh7110/Kconfig
+++ b/arch/riscv/cpu/jh7110/Kconfig
@@ -13,6 +13,7 @@ config STARFIVE_JH7110
select SUPPORT_SPL
select SPL_RAM if SPL
select SPL_STARFIVE_DDR
+   select SPL_ZERO_MEM_BEFORE_USE
select PINCTRL_STARFIVE_JH7110
imply MMC
imply MMC_BROKEN_CD
-- 
2.41.0



[PATCH v2 1/3] riscv: Kconfig: Add SPL_ZERO_MEM_BEFORE_USE

2023-08-07 Thread Shengyu Qu
Add a Kconfig item to allow SPL to clear stack/GD/malloc area before
using them.

Signed-off-by: Bo Gan 
Signed-off-by: Shengyu Qu 
---
 arch/riscv/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 867cbcbe74..6771d8d919 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -64,6 +64,14 @@ config SPL_SYS_DCACHE_OFF
help
  Do not enable data cache in SPL.
 
+config SPL_ZERO_MEM_BEFORE_USE
+   bool "Zero memory before use"
+   depends on SPL
+   default n
+   help
+ Zero stack/GD/malloc area in SPL before using them, this is needed for
+ Sifive core devices that uses L2 cache to store SPL.
+
 # board-specific options below
 source "board/AndesTech/ae350/Kconfig"
 source "board/emulation/qemu-riscv/Kconfig"
-- 
2.41.0



[PATCH v2 0/3] arch: riscv: jh7110: Correctly zero L2 LIM

2023-08-07 Thread Shengyu Qu
This series is the second version of Bo Gan's L2 LIM series. Original
author hasn't sent v2 for almost 2 months, so I decided to take over
this series.

Background information:
 JH7110 SPL runs in L2 LIM (2M in size mapped at 0x800). It
 consists of 16 0x2 sized regions, each one can be used as
 either L2 cache way or SRAM (not both). From top to bottom, there're
 ways 0-15. The way 0 is always enabled, at most 0x1e can be used.

In SPL, we don't enable any cache ways, thus all 15 (except way 0)
ways can be used. However, due to HW requirement, we must zero the
LIM before use. This is because ECC is applied to LIM, and if not
cleared first, the ECC part is invalid, which can trigger ECC errors
when reading/writing data.

There are several issues currently. We clear L2 LIM from __bss_end
to 0x81F in `harts_early_init`. This is wrong because:

 1. Each hart (in the middle of a function call) overwriting its own
stack and other harts' stacks.
(data-race and data-corruption)
 2. Lottery winner hart can be doing `board_init_f_init_reserve`,
while other harts're in the middle of zeroing L2 LIM.
(data-race)

Changes since v1:
 - Seperate single patch into several patches

Shengyu Qu (3):
  riscv: Kconfig: Add SPL_ZERO_MEM_BEFORE_USE
  riscv: Add ZERO_MEM_BEFORE_USE implementation
  riscv: cpu: jh7110: Select SPL_ZERO_MEM_BEFORE_USE

 arch/riscv/Kconfig|  8 
 arch/riscv/cpu/jh7110/Kconfig |  1 +
 arch/riscv/cpu/jh7110/spl.c   | 25 -
 arch/riscv/cpu/start.S| 12 
 common/init/board_init.c  |  3 +++
 5 files changed, 24 insertions(+), 25 deletions(-)

-- 
2.41.0



Re: [PATCH 00/22] x86: Move some boards to text environment

2023-08-07 Thread Andy Shevchenko
On Mon, Aug 07, 2023 at 03:30:25PM +0200, Michael Nazzareno Trimarchi wrote:
> On Mon, Aug 7, 2023 at 3:04 PM Andy Shevchenko
>  wrote:
> > On Mon, Aug 07, 2023 at 02:44:31PM +0200, Michael Nazzareno Trimarchi wrote:
> > > Hi Pali
> > >
> > > Can you just filter emails on your side?
> >
> > Independently on the question is default setup is good or not
> > (from _this_ point of view, I *disagree* with Pali), we have to
> > have a possibility to filter on _our_ side the email addresses
> > to make people happy. If Pali by some reasons does not want to
> > see, it must be easy to keep some deny list in the repository.
> >
> > What you are suggesting is not polite I believe.
> 
> I understand what you mean, I never consider emails to me as a problem
> if I'm working
> on an opensource project and mostly of the time I'm happy to receive them

It really depends. I agree with Bin on that, but we should respect someone's
wishes (in case it's done automatically by heuristics [git history] rather than
letter of law [MAINTAINERS database]).

> > > On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár  wrote:
> > > >
> > > > So remove me from that list of dram.c file. I'm not interested to
> > > > receive emails from people who are ignoring me about unrelated things.
> > > >
> > > > On Monday 07 August 2023 09:43:01 Bin Meng wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár  wrote:
> > > > > >
> > > > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár  wrote:
> > > > > > > >
> > > > > > > > I'm not x86 maintainer, and I'm not going to review changes. So 
> > > > > > > > please
> > > > > > > > do not send me these emails. I have expressed it many times.
> > > > > > >
> > > > > > > You were sent one patch (and the cover letter) because you are the
> > > > > > > second committer on arch/x86/cpu/qemu/dram.c
> > > > > >
> > > > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I 
> > > > > > have to
> > > > > > repeat it? You do not understand? Or what you are trying to do now?
> > > > >
> > > > > I believe this cc list comes from patman which calls get_maintainer.pl
> > > > > to get the cc list.
> > > > > get_maintainer.pl determines the person names from 1. MAINTAINERS of
> > > > > the changed file 2. git commit history of the changed file.
> > > > >
> > > > > I can see the philosophy was that someone who touched the changed file
> > > > > should be copied for review.
> > > > > We certainly could argue that and just get the list solely from the
> > > > > MAINTAINERS file.

-- 
With Best Regards,
Andy Shevchenko




Re: [PATCH v1] doc: board: toradex: fix verdin module output

2023-08-07 Thread Tom Rini
On Mon, Aug 07, 2023 at 01:44:46AM +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Fix the Verdin module output which was missing white space for correct
> rendering.
> 
> While at it also leave product links, add section author also for the
> Verdin iMX8M Mini and Plus, and add a missing CROSS_COMPILE export for
> the Verdin iMX8M Mini.
> 
> Signed-off-by: Marcel Ziswiler 
[snip]
> @@ -74,57 +77,57 @@ Boot
>  
>  Output:
>  
> -.. code-block:: bash
> -
> -U-Boot SPL 2023.10-rc1-00210-gb678170a34c (Aug 03 2023 - 00:09:14 +0200)
[snip]
> +.. code-block:: none
> +
> +  U-Boot SPL 2023.10-rc1-00210-gb678170a34c (Aug 03 2023 - 00:09:14 +0200)

So, this renders nicely for me:

Reviewed-by: Tom Rini 

But I do want to note that other places just do:

Output::

For boot logs, and we should be consistent I think.  Heinrich?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v8 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support

2023-08-07 Thread Tom Rini
On Mon, Jul 31, 2023 at 11:29:19AM -0400, Tom Rini wrote:
> On Mon, Jul 31, 2023 at 03:19:08PM +0300, Svyatoslav Ryhel wrote:
> > Hello!
> > 
> > It has been a month since the last patchset was sent. Should I re-send them?
> 
> Not unless things don't apply.  Thierry, can you put together a pull
> request soon? Thanks!

Thierry? I'm OK with taking these boards after -rc2 if that helps move
things along, thanks.

> 
> > 
> > Bast regards,
> > Svyatoslav Ryhel.
> > 
> > 30 червня 2023 р. 10:28:59 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:33, rate 0.09
> > >
> > >---
> > >Changes from v7:
> > >- endeavoru dtb included into Makefile
> > >
> > >Changes from v6:
> > >- fixed typos
> > >- changed grouper base defconfig in doc
> > >- fixed references too microsd card for grouper, lg and htc
> > >- fixed name of p1801
> > >- removed pwm from p1801
> > >- added section about flashing uboot to tf600t
> > >- changed tf600t behavior (power off after update, not reboot)
> > >
> > >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 |  13 +
> > > 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 |  18 +
> > > 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 ++
> 

Re: [PATCH 00/22] x86: Move some boards to text environment

2023-08-07 Thread Michael Nazzareno Trimarchi
Hi Andy

On Mon, Aug 7, 2023 at 3:04 PM Andy Shevchenko
 wrote:
>
> On Mon, Aug 07, 2023 at 02:44:31PM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi Pali
> >
> > Can you just filter emails on your side?
>
> Independently on the question is default setup is good or not
> (from _this_ point of view, I *disagree* with Pali), we have to
> have a possibility to filter on _our_ side the email addresses
> to make people happy. If Pali by some reasons does not want to
> see, it must be easy to keep some deny list in the repository.
>
> What you are suggesting is not polite I believe.

I understand what you mean, I never consider emails to me as a problem
if I'm working
on an opensource project and mostly of the time I'm happy to receive them

Michael

>
> > On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár  wrote:
> > >
> > > So remove me from that list of dram.c file. I'm not interested to
> > > receive emails from people who are ignoring me about unrelated things.
> > >
> > > On Monday 07 August 2023 09:43:01 Bin Meng wrote:
> > > > Hi Pali,
> > > >
> > > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár  wrote:
> > > > >
> > > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár  wrote:
> > > > > > >
> > > > > > > I'm not x86 maintainer, and I'm not going to review changes. So 
> > > > > > > please
> > > > > > > do not send me these emails. I have expressed it many times.
> > > > > >
> > > > > > You were sent one patch (and the cover letter) because you are the
> > > > > > second committer on arch/x86/cpu/qemu/dram.c
> > > > >
> > > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I have 
> > > > > to
> > > > > repeat it? You do not understand? Or what you are trying to do now?
> > > >
> > > > I believe this cc list comes from patman which calls get_maintainer.pl
> > > > to get the cc list.
> > > > get_maintainer.pl determines the person names from 1. MAINTAINERS of
> > > > the changed file 2. git commit history of the changed file.
> > > >
> > > > I can see the philosophy was that someone who touched the changed file
> > > > should be copied for review.
> > > > We certainly could argue that and just get the list solely from the
> > > > MAINTAINERS file.
> > > >
> > > > Regards,
> > > > Bin
> >
> >
> >
> > --
> > Michael Nazzareno Trimarchi
> > Co-Founder & Chief Executive Officer
> > M. +39 347 913 2170
> > mich...@amarulasolutions.com
> > __
> >
> > Amarula Solutions BV
> > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> > T. +31 (0)85 111 9172
> > i...@amarulasolutions.com
> > www.amarulasolutions.com
>
> --
> With Best Regards,
> Andy Shevchenko
>
>


-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


[PATCH 2/2] doc: imx8mp_evk: Use in-tree build in the example

2023-08-07 Thread Fabio Estevam
From: Fabio Estevam 

To make it consistent with the instructions from other NXP imx8m boards,
such as imx8mm-evk and imx8mn-evk, use U-Boot in-tree build in the
examples.

Signed-off-by: Fabio Estevam 
---
 doc/board/nxp/imx8mp_evk.rst | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/doc/board/nxp/imx8mp_evk.rst b/doc/board/nxp/imx8mp_evk.rst
index e106c3c71872..0297cc8ffc16 100644
--- a/doc/board/nxp/imx8mp_evk.rst
+++ b/doc/board/nxp/imx8mp_evk.rst
@@ -37,20 +37,22 @@ Build U-Boot
 
 .. code-block:: bash
 
+Note: builddir is U-Boot build directory (source directory for in-tree builds).
+
$ export CROSS_COMPILE=aarch64-poky-linux-
$ make O=build imx8mp_evk_defconfig
-   $ cp ../imx-atf/build/imx8mp/release/bl31.bin ./build/bl31.bin
-   $ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin 
./build/
-   $ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin 
./build/
-   $ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin 
./build/
-   $ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin 
./build/
-   $ make O=build
+   $ cp ../imx-atf/build/imx8mp/release/bl31.bin $(builddir)
+   $ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin 
$(builddir)
+   $ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin 
$(builddir)
+   $ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin 
$(builddir)
+   $ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin 
$(builddir)
+   $ make
 
 Burn the flash.bin to the MicroSD card at offset 32KB:
 
 .. code-block:: bash
 
-   $sudo dd if=build/flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync
+   $ sudo dd if=flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync
 
 Boot
 
-- 
2.34.1



[PATCH 1/2] doc: imx8mp_evk: Remove unneeded export ATF_LOAD_ADDR line

2023-08-07 Thread Fabio Estevam
From: Fabio Estevam 

Originally, exporting the ATF_LOAD_ADDR was required, but since binman has
been used to generate the flash.bin, it is no longer needed to do
such manual export.

The ATF address is now passed via binman in imx8mp-u-boot.dtsi:

atf {
description = "ARM Trusted Firmware";
type = "firmware";
arch = "arm64";
compression = "none";
load = <0x97>;
entry = <0x97>;

atf_blob: atf-blob {
filename = "bl31.bin";
type = "atf-bl31";
};
};

Remove the  unneeded export ATF_LOAD_ADDR line.

Signed-off-by: Fabio Estevam 
---
 doc/board/nxp/imx8mp_evk.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/board/nxp/imx8mp_evk.rst b/doc/board/nxp/imx8mp_evk.rst
index e7cc7b396b57..e106c3c71872 100644
--- a/doc/board/nxp/imx8mp_evk.rst
+++ b/doc/board/nxp/imx8mp_evk.rst
@@ -44,7 +44,6 @@ Build U-Boot
$ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin 
./build/
$ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin 
./build/
$ cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin 
./build/
-   $ export ATF_LOAD_ADDR=0x97
$ make O=build
 
 Burn the flash.bin to the MicroSD card at offset 32KB:
-- 
2.34.1



Re: [PATCH 00/22] x86: Move some boards to text environment

2023-08-07 Thread Tom Rini
On Mon, Aug 07, 2023 at 04:03:45PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 07, 2023 at 02:44:31PM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi Pali
> > 
> > Can you just filter emails on your side?
> 
> Independently on the question is default setup is good or not
> (from _this_ point of view, I *disagree* with Pali), we have to
> have a possibility to filter on _our_ side the email addresses
> to make people happy. If Pali by some reasons does not want to
> see, it must be easy to keep some deny list in the repository.
> 
> What you are suggesting is not polite I believe.

I have to admit I didn't notice ".get_maintainer.ignore" until now.  So
yes, it sounds like we can do that too.

> 
> > On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár  wrote:
> > >
> > > So remove me from that list of dram.c file. I'm not interested to
> > > receive emails from people who are ignoring me about unrelated things.
> > >
> > > On Monday 07 August 2023 09:43:01 Bin Meng wrote:
> > > > Hi Pali,
> > > >
> > > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár  wrote:
> > > > >
> > > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár  wrote:
> > > > > > >
> > > > > > > I'm not x86 maintainer, and I'm not going to review changes. So 
> > > > > > > please
> > > > > > > do not send me these emails. I have expressed it many times.
> > > > > >
> > > > > > You were sent one patch (and the cover letter) because you are the
> > > > > > second committer on arch/x86/cpu/qemu/dram.c
> > > > >
> > > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I have 
> > > > > to
> > > > > repeat it? You do not understand? Or what you are trying to do now?
> > > >
> > > > I believe this cc list comes from patman which calls get_maintainer.pl
> > > > to get the cc list.
> > > > get_maintainer.pl determines the person names from 1. MAINTAINERS of
> > > > the changed file 2. git commit history of the changed file.
> > > >
> > > > I can see the philosophy was that someone who touched the changed file
> > > > should be copied for review.
> > > > We certainly could argue that and just get the list solely from the
> > > > MAINTAINERS file.
> > > >
> > > > Regards,
> > > > Bin
> > 
> > 
> > 
> > -- 
> > Michael Nazzareno Trimarchi
> > Co-Founder & Chief Executive Officer
> > M. +39 347 913 2170
> > mich...@amarulasolutions.com
> > __
> > 
> > Amarula Solutions BV
> > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> > T. +31 (0)85 111 9172
> > i...@amarulasolutions.com
> > www.amarulasolutions.com
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] get_maintainer.pl: Add an ignore list for git history

2023-08-07 Thread Tom Rini
As Pali Rohár has asked to not be copied on changes to files he is not
a specific maintainer of, add his address to .get_maintainer.ignore.

Signed-off-by: Tom Rini 
---
Cc: "Pali Rohár" 
---
 .get_maintainer.ignore | 1 +
 .gitignore | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 .get_maintainer.ignore

diff --git a/.get_maintainer.ignore b/.get_maintainer.ignore
new file mode 100644
index ..899a1469b2ae
--- /dev/null
+++ b/.get_maintainer.ignore
@@ -0,0 +1 @@
+"Pali Rohár" 
diff --git a/.gitignore b/.gitignore
index 3a4d056edfc3..002f95de4feb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -53,6 +53,7 @@ fit-dtb.blob*
 #
 !.gitignore
 !.mailmap
+!.get_maintainer.*
 
 #
 # Generated files
-- 
2.34.1



Re: [PATCH 00/22] x86: Move some boards to text environment

2023-08-07 Thread Andy Shevchenko
On Mon, Aug 07, 2023 at 02:44:31PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi Pali
> 
> Can you just filter emails on your side?

Independently on the question is default setup is good or not
(from _this_ point of view, I *disagree* with Pali), we have to
have a possibility to filter on _our_ side the email addresses
to make people happy. If Pali by some reasons does not want to
see, it must be easy to keep some deny list in the repository.

What you are suggesting is not polite I believe.

> On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár  wrote:
> >
> > So remove me from that list of dram.c file. I'm not interested to
> > receive emails from people who are ignoring me about unrelated things.
> >
> > On Monday 07 August 2023 09:43:01 Bin Meng wrote:
> > > Hi Pali,
> > >
> > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár  wrote:
> > > >
> > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár  wrote:
> > > > > >
> > > > > > I'm not x86 maintainer, and I'm not going to review changes. So 
> > > > > > please
> > > > > > do not send me these emails. I have expressed it many times.
> > > > >
> > > > > You were sent one patch (and the cover letter) because you are the
> > > > > second committer on arch/x86/cpu/qemu/dram.c
> > > >
> > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I have to
> > > > repeat it? You do not understand? Or what you are trying to do now?
> > >
> > > I believe this cc list comes from patman which calls get_maintainer.pl
> > > to get the cc list.
> > > get_maintainer.pl determines the person names from 1. MAINTAINERS of
> > > the changed file 2. git commit history of the changed file.
> > >
> > > I can see the philosophy was that someone who touched the changed file
> > > should be copied for review.
> > > We certainly could argue that and just get the list solely from the
> > > MAINTAINERS file.
> > >
> > > Regards,
> > > Bin
> 
> 
> 
> -- 
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
> 
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com

-- 
With Best Regards,
Andy Shevchenko




Re: [PATCH 00/22] x86: Move some boards to text environment

2023-08-07 Thread Michael Nazzareno Trimarchi
Hi Pali

Can you just filter emails on your side?

Michael

On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár  wrote:
>
> So remove me from that list of dram.c file. I'm not interested to
> receive emails from people who are ignoring me about unrelated things.
>
> On Monday 07 August 2023 09:43:01 Bin Meng wrote:
> > Hi Pali,
> >
> > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár  wrote:
> > >
> > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote:
> > > > Hi Pali,
> > > >
> > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár  wrote:
> > > > >
> > > > > I'm not x86 maintainer, and I'm not going to review changes. So please
> > > > > do not send me these emails. I have expressed it many times.
> > > >
> > > > You were sent one patch (and the cover letter) because you are the
> > > > second committer on arch/x86/cpu/qemu/dram.c
> > >
> > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I have to
> > > repeat it? You do not understand? Or what you are trying to do now?
> >
> > I believe this cc list comes from patman which calls get_maintainer.pl
> > to get the cc list.
> > get_maintainer.pl determines the person names from 1. MAINTAINERS of
> > the changed file 2. git commit history of the changed file.
> >
> > I can see the philosophy was that someone who touched the changed file
> > should be copied for review.
> > We certainly could argue that and just get the list solely from the
> > MAINTAINERS file.
> >
> > Regards,
> > Bin



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


[PATCH v2 2/2] usb: udc: Try to clarify an error message

2023-08-07 Thread Miquel Raynal
At some point when trying to use USB gadgets, two situations may arise
and lead to a failure. Either the UDC (USB Device Controller) is not
available at all (not described or not probed) or the UDC is already in
use. For instance, as the USB Ethernet gadget remains bound to the UDC,
the use of any other USB gadget (fastboot, dfu, etc) *after* will always
fail with the "couldn't find an available UDC" error.

Let's give a more helpful message by making a difference between the two
cases. Let's also hint people who would get this error and grep it into
the sources a better explanation of what's wrong with their workflow.

Signed-off-by: Miquel Raynal 
---
While doing this I really wanted to add "much more" error comments but I
faced another reality: often the messages are there but use
pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so
I consider this unnecessary, as decreasing the loglevel will make these
messages appear. I would have expected errors to be displayed, but I
understand it makes the binaries even bigger.

Changes in v2:
* s/UDC/UDCs/. I kept the sentence as it was as the suggested form did
  not sound well at all when there is only one UDC.
---
 drivers/usb/gadget/udc/udc-core.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 7f73926cb3e..8405b03462e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -323,6 +323,7 @@ err1:
 int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
 {
struct usb_udc  *udc = NULL;
+   unsigned intudc_count = 0;
int ret;
 
if (!driver || !driver->bind || !driver->setup)
@@ -330,12 +331,22 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
*driver)
 
mutex_lock(_lock);
list_for_each_entry(udc, _list, list) {
+   udc_count++;
+
/* For now we take the first one */
if (!udc->driver)
goto found;
}
 
-   printf("couldn't find an available UDC\n");
+   if (!udc_count)
+   printf("No UDC available in the system\n");
+   else
+   /* When this happens, users should 'unbind  '
+* using the output of 'dm tree' and looking at the line right
+* after the USB peripheral/device controller.
+*/
+   printf("All UDCs in use (%d available), use the unbind 
command\n",
+  udc_count);
mutex_unlock(_lock);
return -ENODEV;
 found:
-- 
2.34.1



[PATCH v2 1/2] cmd: bind: Try to improve the (un)bind help

2023-08-07 Thread Miquel Raynal
While it may sound totally obvious for the regular U-Boot developer to
get the parameters of the bind/unbind commands from the output of 'dm
tree', it did not felt straightforward to me until I was explicitly
told to look there. And even when I knew the command, I did not make a
direct link between the arguments of this command and the columns
returned by 'dm tree'.

Several of us lost a lot of time because of that, I would like to kindly
help other users by slightly improving this textual line. Unfortunately,
because of how this string is used (like within the 'help' command) I
cannot detail much more, but at least the pointer is there.

Signed-off-by: Miquel Raynal 
---
Changes in v2:
* Moved the details in the long text section as suggested by Heinrich.
* Rephrased the help text as well, not fully following Heinrich
  suggestion, but taking inspiration from it.
---
 cmd/bind.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/cmd/bind.c b/cmd/bind.c
index 4d1b7885e60..be0d4d2a711 100644
--- a/cmd/bind.c
+++ b/cmd/bind.c
@@ -246,6 +246,8 @@ U_BOOT_CMD(
"Bind a device to a driver",
" \n"
"bind   \n"
+   "Use 'dm tree' to list all devices registered in the driver model,\n"
+   "their path, class, index and current driver.\n"
 );
 
 U_BOOT_CMD(
@@ -254,4 +256,6 @@ U_BOOT_CMD(
"\n"
"unbind  \n"
"unbind   \n"
+   "Use 'dm tree' to list all devices registered in the driver model,\n"
+   "their path, class, index and current driver.\n"
 );
-- 
2.34.1



Re: [RFC PATCH] env: Export environment config to OS devicetree

2023-08-07 Thread Frieder Schrempf
Hi Simon, hi Stefano,

On 04.08.23 15:39, Stefano Babic wrote:
> Hi Simon,
> 
> On 04.08.23 05:42, Simon Glass wrote:
>> Hi,
>>
>> On Thu, 3 Aug 2023 at 07:21, Stefano Babic  wrote:
>>>
>>> Hi Frieder,
>>>
>>> On 03.08.23 14:51, Frieder Schrempf wrote:
 Hi Stefano,

 On 03.08.23 10:14, Stefano Babic wrote:
> Hi Frieder,
>
> On 01.08.23 16:46, Frieder Schrempf wrote:
>> From: Frieder Schrempf 
>>
>> There are plenty of cases where the OS wants to know where the
>> persistent environment is stored in order to print or manipulate it.
>>
>> In most cases a userspace tool like libubootenv [1] is used to handle
>> the environment. It uses hardcoded settings in a config file in the
>> rootfs to determine the exact location of the environment.
>>
>
> ...or the configuration file is generated, or it is located on a rw
> (overlayfs) partition.
>
>> In order to make systems more flexible and let userspace tools
>> detect the location of the environment currently in use, let's
>> add an option to export the runtime configuration to the FDT passed
>> to the OS.
>>> This is especially useful when your device is able to use multiple
>> locations for the environment and the rootfs containing the
>> fw_env.config file should be kept universal.
>
> Ok
>
> One possible issue is there is a hard dependency between the
> properties
> set in DT and the user space tool. The tool in user space is bound to
> the list of properties, and changes / extensions for the user tool
> requires changes in DT semantics (which properties, their path, etc).
>
> The same hard dependency is set by fw_env.config with its strong
> hardcoded and position dependent syntax. This one of the reason I
> introduced YAML support in libubootenv, so that the user tool is
> independent and can add own properties.
>
> I am just asking if this use case requires a new interface, or it is
> already available in some way. I mean, the configuration is YAML
> instead
> of fw_env.config and contains multiple setup ("namespaces"), like:
>
> mmc:
>     size : 0x10
>     lockfile : /var/lock/fw_printenv.lock
>     devices:
>   - path : /dev/mmcblk0boot0
>     offset : 0x1E
>     sectorsize : 0x10
>   - path : /dev/mmcblk0boot0
>     offset : 0x1E
>     sectorsize : 0x10
> spi:
>     size : 0x10
>     lockfile : /var/lock/fw_printenv.lock
>     devices:
>   - path : /dev/mtd0
>     offset : 0x1E
>     sectorsize : 0x10
>   - path : /dev/mtd0
>     offset : 0x1F
>     sectorsize : 0x10
>
> This configuration file can safely stored in your common rootfs and
> covers all possible storage for environment. It does not cover
> "runtime"
> changes, but well, I do not think this is a use case.
>
> An advantage here is that new options, useful for the User Space tool,
> can be simply introduced for the tool without the need to synchronize
> with DT spec and U-Boot.
>
> A mapping between location index and device path is not required. What
> is still required is a selector, and this can be implemented in DT
> or as
> kernel parameter.
>
> Does this already cover your use case or do we need the
> introduction of
> this new interface ?

 Thanks for the feedback! I've seen the YAML configuration feature in
 libubootenv but I missed the fact, that it already supports something
 like the namespace parameter for selecting different configurations.

 Indeed this would solve one part of the issue. And yes, I think we
 could
 use the DT or a kernel parameter to pass a selector from U-Boot to
 userspace.
>>>
>>> Exactly.
>>>

 Do you think we could add something to libubootenv to automatically
 select the default namespace based on some DT property or kernel
 parameter?
>>>
>>> Yes, we just need to add a way to set up a default "namespace". There is
>>> currently a default "uboot" namespace, and we just need a way to pass
>>> the information to the library. Maybe with an env ?
>>>

 If yes, I think this would be a viable solution for me.
>>>
>>> Fine !
>>>

>
>>
>> Currently the general information like location/type, size, offset
>> and redundancy are exported. Userspace tools might already be able
>> to guess the correct device to access based on this information.
>>
>> For further device-specific information two additional properties
>> 'id1' and 'id2' are used. The current implementation uses them for
>> MMC and SPI FLASH like this:
>>
>> | Type   | id1    |
>> id2    |
>> | -- | -- |

[PATCH] imx8m, imx9: Fix DRAM size calculation in SPL/dram_init_banksize()

2023-08-07 Thread Elena Popa
If dram_init_banksize() is called from SPL, the rom_pointer, at that
point, is not correctly initialized. This causes wrong calculation of
DRAM start and size in dram_init_banksize(). The issue became apparent
only in Falcon Mode. Added an extra condition to prevent using
rom_pointer in SPL.

Signed-off-by: Elena Popa 
---
 arch/arm/mach-imx/imx8m/soc.c | 2 +-
 arch/arm/mach-imx/imx9/soc.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index d5254886be..dbb2154b08 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -273,7 +273,7 @@ int dram_init_banksize(void)
}
 
gd->bd->bi_dram[bank].start = PHYS_SDRAM;
-   if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && rom_pointer[1]) {
+   if (!IS_ENABLED(CONFIG_ARMV8_PSCI) && !IS_ENABLED(CONFIG_SPL_BUILD) && 
rom_pointer[1]) {
phys_addr_t optee_start = (phys_addr_t)rom_pointer[0];
phys_size_t optee_size = (size_t)rom_pointer[1];
 
diff --git a/arch/arm/mach-imx/imx9/soc.c b/arch/arm/mach-imx/imx9/soc.c
index f43b73a6c2..ca91f20fe7 100644
--- a/arch/arm/mach-imx/imx9/soc.c
+++ b/arch/arm/mach-imx/imx9/soc.c
@@ -390,7 +390,7 @@ int dram_init_banksize(void)
}
 
gd->bd->bi_dram[bank].start = PHYS_SDRAM;
-   if (rom_pointer[1]) {
+   if (!IS_ENABLED(CONFIG_SPL_BUILD) && rom_pointer[1]) {
phys_addr_t optee_start = (phys_addr_t)rom_pointer[0];
phys_size_t optee_size = (size_t)rom_pointer[1];
 
-- 
2.25.1



memory hole close to 4GB on qemu risc-v

2023-08-07 Thread Wu, Fei
Hi All,

I am working on enabling PCIe passthrough on qemu risc-v, in order for
the guest to access the host x86 pci resource directly, ram on guest
won't cover this range, so if guest has 4GB ram, two ranges are created:
  1. 2G-3G
  2. 4G-7G

u-boot is not able to handle this but reports:

Reserving 869k for U-Boot at: ff725000
initcall: 80216f94
Reserving 8320k for malloc() at: fef05000
initcall: 80216ee8
Unhandled exception: Store/AMO access fault

EP: 80201a38 RA: 80216f10 TVAL: fef04f90

It looks like fdtdec_setup_mem_size_base() in u-boot sets ram_base/size
without considering all memory nodes, and board_get_usable_ram_top()
returns 4G-1 that causes gd->relocaddr set to the wrong address which
has no ram backed. More details can be found here:
  https://patchew.org/QEMU/20230731015317.1026996-1-fei2...@intel.com/


Can we add support for this multi-range ram setting? Any comments?

Thanks,
Fei.


Re: [PATCH 00/22] x86: Move some boards to text environment

2023-08-07 Thread Pali Rohár
So remove me from that list of dram.c file. I'm not interested to
receive emails from people who are ignoring me about unrelated things.

On Monday 07 August 2023 09:43:01 Bin Meng wrote:
> Hi Pali,
> 
> On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár  wrote:
> >
> > On Sunday 06 August 2023 08:39:43 Simon Glass wrote:
> > > Hi Pali,
> > >
> > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár  wrote:
> > > >
> > > > I'm not x86 maintainer, and I'm not going to review changes. So please
> > > > do not send me these emails. I have expressed it many times.
> > >
> > > You were sent one patch (and the cover letter) because you are the
> > > second committer on arch/x86/cpu/qemu/dram.c
> >
> > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I have to
> > repeat it? You do not understand? Or what you are trying to do now?
> 
> I believe this cc list comes from patman which calls get_maintainer.pl
> to get the cc list.
> get_maintainer.pl determines the person names from 1. MAINTAINERS of
> the changed file 2. git commit history of the changed file.
> 
> I can see the philosophy was that someone who touched the changed file
> should be copied for review.
> We certainly could argue that and just get the list solely from the
> MAINTAINERS file.
> 
> Regards,
> Bin


[PATCH] [*] fix RK3568 build under CONFIG_DISPLAY_CPUINFO flag

2023-08-07 Thread Anton
---
 arch/arm/include/asm/arch-rockchip/cru.h| 2 ++
 arch/arm/include/asm/arch-rockchip/cru_rk3568.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/cru.h 
b/arch/arm/include/asm/arch-rockchip/cru.h
index 13ea4aba8e..9778790f34 100644
--- a/arch/arm/include/asm/arch-rockchip/cru.h
+++ b/arch/arm/include/asm/arch-rockchip/cru.h
@@ -15,6 +15,8 @@
 # include 
 #elif defined(CONFIG_ROCKCHIP_RK3399)
 # include 
+#elif defined(CONFIG_ROCKCHIP_RK3568)
+#include 
 #endif
 
 /* CRU_GLB_RST_ST */
diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
index 399f19ad21..76f1ad5510 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
@@ -106,6 +106,8 @@ struct rk3568_cru {
unsigned int emmc_con[2];/* Address Offset: 0x0598 */
 };
 
+#define rockchip_cru rk3568_cru
+
 check_member(rk3568_cru, mode_con00, 0xc0);
 check_member(rk3568_cru, softrst_con[0], 0x400);
 
-- 
2.30.2



Re: [PATCH v5 2/2] board: mediatek: add mt8195 demo board

2023-08-07 Thread Michael Walle
Hi,

> + printf("Disabling WDT\n");
> + writel(0, 0x10007000);

Please don't use magic numbers. Also, I guess this should be a
real watchdog driver and u-boot will take care of disabling it
if the user wants to.

> +
> + printf("Enabling SCP SRAM\n");
> + for (unsigned int val = 0x; val != 0U;) {
> + val = val >> 1;
> + writel(val, 0x1072102C);

Even more magic numbers.

> + }

Thanks,
-michael


Re: [PATCH v1] doc: board: toradex: fix verdin module output

2023-08-07 Thread Nishanth Menon
On 01:44-20230807, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Fix the Verdin module output which was missing white space for correct
> rendering.
> 
> While at it also leave product links, add section author also for the
> Verdin iMX8M Mini and Plus, and add a missing CROSS_COMPILE export for
> the Verdin iMX8M Mini.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> - Add missing white space to output for correct rendering.
> - Also leave product links.
> Thanks to Nishanth for suggesting those.
> - Add section author also for the Verdin iMX8M Mini and Plus.
> - Add a missing CROSS_COMPILE export for the Verdin iMX8M Mini
> 
>  doc/board/toradex/verdin-am62.rst   | 111 ++--
>  doc/board/toradex/verdin-imx8mm.rst |  61 ---
>  doc/board/toradex/verdin-imx8mp.rst |  70 +-
>  3 files changed, 127 insertions(+), 115 deletions(-)
> 
[..]
Reviewed-by: Nishanth Menon  #verdin-am62

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D


Re: [RESEND, v1 3/4] riscv: starfive: Add SYS_CACHE_SHIFT_6 to enable SYS_CACHELINE_SIZE

2023-08-07 Thread Bin Meng
On Mon, Aug 7, 2023 at 4:53 PM Minda Chen  wrote:
>
> Some device driver need SYS_CACHELINE_SIZE macro. Add StarFive
> SYS_CACHE_SHIFT_6 to enable it.
>
> Signed-off-by: Minda Chen 
> ---
>  arch/riscv/cpu/jh7110/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v2 01/12] scmi: refactor the code to hide a channel from devices

2023-08-07 Thread AKASHI Takahiro
Hi Etienne,

On Thu, Aug 03, 2023 at 09:24:51AM +, Etienne CARRIERE wrote:
> Hello Takahiro-san,
> 
> Sorry again for this late feedback.
> Testing the series against stm32mp135f-dk board which is using SCMI 
> resources, I see the board fails to boot.
> 
> > From: AKASHI Takahiro 
> > To: tr...@konsulko.com, s...@chromium.org
> > Cc: etienne.carri...@st.com, u-boot@lists.denx.de,
> > AKASHI Takahiro 
> > Subject: [PATCH v2 01/12] scmi: refactor the code to hide a channel from 
> > devices
> > Date: Wed, 26 Jul 2023 17:37:57 +0900   [thread overview]
> > Message-ID: <20230726083808.140780-2-takahiro.aka...@linaro.org> (raw)
> > In-Reply-To: <20230726083808.140780-1-takahiro.aka...@linaro.org>
> > 
> > The commit 85dc58289238 ("firmware: scmi: prepare uclass to pass channel
> > reference") added an explicit parameter, channel, but it seems to make
> > the code complex.
> > 
> > Hiding this parameter will allow for adding a generic (protocol-agnostic)
> > helper function, i.e. for PROTOCOL_VERSION, in a later patch.
> > 
> > Signed-off-by: AKASHI Takahiro 
> >
> > ---
> > v2
> > * new patch
> > ---
> >  drivers/clk/clk_scmi.c| 27 ++---
> >  drivers/firmware/scmi/scmi_agent-uclass.c | 74 ++-
> >  drivers/power/regulator/scmi_regulator.c  | 27 +++--
> >  drivers/reset/reset-scmi.c| 19 +-
> >  include/scmi_agent.h  | 15 +++--
> >  5 files changed, 86 insertions(+), 76 deletions(-)
> > 
> > diff --git a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c
> > index d172fed24c9d..34a49363a51a 100644
> > --- a/drivers/clk/clk_scmi.c
> > +++ b/drivers/clk/clk_scmi.c
> > @@ -13,17 +13,8 @@
> >  #include 
> >  #include 
> >  
> > -/**
> > - * struct scmi_clk_priv - Private data for SCMI clocks
> > - * @channel: Reference to the SCMI channel to use
> > - */
> > -struct scmi_clk_priv {
> > -   struct scmi_channel *channel;
> > -};
> > -
> >  static int scmi_clk_get_num_clock(struct udevice *dev, size_t *num_clocks)
> >  {
> > -   struct scmi_clk_priv *priv = dev_get_priv(dev);
> > struct scmi_clk_protocol_attr_out out;
> > struct scmi_msg msg = {
> > .protocol_id = SCMI_PROTOCOL_ID_CLOCK,
> > @@ -33,7 +24,7 @@ static int scmi_clk_get_num_clock(struct udevice *dev, 
> > size_t *num_clocks)
> > };
> > int ret;
> >  
> > -   ret = devm_scmi_process_msg(dev, priv->channel, );
> > +   ret = devm_scmi_process_msg(dev, );
> > if (ret)
> > return ret;
> >  
> > @@ -44,7 +35,6 @@ static int scmi_clk_get_num_clock(struct udevice *dev, 
> > size_t *num_clocks)
> >  
> >  static int scmi_clk_get_attibute(struct udevice *dev, int clkid, char 
> > **name)
> >  {
> > -   struct scmi_clk_priv *priv = dev_get_priv(dev);
> > struct scmi_clk_attribute_in in = {
> > .clock_id = clkid,
> > };
> > @@ -59,7 +49,7 @@ static int scmi_clk_get_attibute(struct udevice *dev, int 
> > clkid, char **name)
> > };
> > int ret;
> >  
> > -   ret = devm_scmi_process_msg(dev, priv->channel, );
> > +   ret = devm_scmi_process_msg(dev, );
> > if (ret)
> > return ret;
> >  
> > @@ -70,7 +60,6 @@ static int scmi_clk_get_attibute(struct udevice *dev, int 
> > clkid, char **name)
> >  
> >  static int scmi_clk_gate(struct clk *clk, int enable)
> >  {
> > -   struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
> > struct scmi_clk_state_in in = {
> > .clock_id = clk->id,
> > .attributes = enable,
> > @@ -81,7 +70,7 @@ static int scmi_clk_gate(struct clk *clk, int enable)
> >   in, out);
> > int ret;
> >  
> > -   ret = devm_scmi_process_msg(clk->dev, priv->channel, );
> > +   ret = devm_scmi_process_msg(clk->dev, );
> > if (ret)
> > return ret;
> >  
> > @@ -100,7 +89,6 @@ static int scmi_clk_disable(struct clk *clk)
> >  
> >  static ulong scmi_clk_get_rate(struct clk *clk)
> >  {
> > -   struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
> > struct scmi_clk_rate_get_in in = {
> > .clock_id = clk->id,
> > };
> > @@ -110,7 +98,7 @@ static ulong scmi_clk_get_rate(struct clk *clk)
> >   in, out);
> > int ret;
> >  
> > -   ret = devm_scmi_process_msg(clk->dev, priv->channel, );
> > +   ret = devm_scmi_process_msg(clk->dev, );
> > if (ret < 0)
> > return ret;
> >  
> > @@ -123,7 +111,6 @@ static ulong scmi_clk_get_rate(struct clk *clk)
> >  
> >  static ulong scmi_clk_set_rate(struct clk *clk, ulong rate)
> >  {
> > -   struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
> > struct scmi_clk_rate_set_in in = {
> > .clock_id = clk->id,
> > .flags = SCMI_CLK_RATE_ROUND_CLOSEST,
> > @@ -136,7 +123,7 @@ static ulong scmi_clk_set_rate(struct clk *clk, ulong 
> > rate)
> >   in, out);
> > int ret;
> >  
> > -   ret = devm_scmi_process_msg(clk->dev, priv->channel, 

Re: [PATCH 2/2] usb: udc: Try to clarify an error message

2023-08-07 Thread Miquel Raynal
Hi Heinrich,

heinrich.schucha...@canonical.com wrote on Mon, 7 Aug 2023 11:29:08
+0200:

> On 04.08.23 21:14, Miquel Raynal wrote:
> > At some point when trying to use USB gadgets, two situations may arise
> > and lead to a failure. Either the UDC (USB Device Controller) is not
> > available at all (not described or not probed) or the UDC is already in
> > use. For instance, as the USB Ethernet gadget remains bound to the UDC,
> > the use of any other USB gadget (fastboot, dfu, etc) *after* will always
> > fail with the "couldn't find an available UDC" error.  
> 
> Are the UDCs real devices or only logical ones?

In this context there is a real device behind. But UDC is also the name
for kind of an interface for gadget drivers. In theory, on USB device
controller could expose several different functions.

> If they are only logical ones, can we generate new ones on the fly?

In general, it's not impossible, but it's not supported at all in U-Boot
(and for a good reason: it would be way too complex to handle) and I
think even in Linux, it's possible, but possibly only using
configfs (not 100% sure on that one).

> > Let's give a more helpful message by making a difference between the two
> > cases. Let's also hint people who would get this error and grep it into
> > the sources a better explanation of what's wrong with their workflow.
> > 
> > Signed-off-by: Miquel Raynal 
> > ---
> > 
> > While doing this I really wanted to add "much more" error comments but I
> > faced another reality: often the messages are there but use
> > pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so
> > I consider this unnecessary, as decreasing the loglevel will make these
> > messages appear. I would have expected errors to be displayed, but I
> > understand it makes the binaries even bigger.
> > ---
> >   drivers/usb/gadget/udc/udc-core.c | 13 -
> >   1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/gadget/udc/udc-core.c 
> > b/drivers/usb/gadget/udc/udc-core.c
> > index 7f73926cb3e..30f6d73f36e 100644
> > --- a/drivers/usb/gadget/udc/udc-core.c
> > +++ b/drivers/usb/gadget/udc/udc-core.c
> > @@ -323,6 +323,7 @@ err1:
> >   int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
> >   {
> > struct usb_udc  *udc = NULL;
> > +   unsigned intudc_count = 0;
> > int ret;  
> >   > if (!driver || !driver->bind || !driver->setup)  
> > @@ -330,12 +331,22 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
> > *driver)  
> >   > mutex_lock(_lock);  
> > list_for_each_entry(udc, _list, list) {
> > +   udc_count++;
> > +
> > /* For now we take the first one */
> > if (!udc->driver)
> > goto found;
> > }  
> >   > -   printf("couldn't find an available UDC\n");  
> > +   if (!udc_count)
> > +   printf("No UDC available in the system\n");
> > +   else
> > +   /* When this happens, users should 'unbind  '
> > +* using the output of 'dm tree' and looking at the line right
> > +* after the USB peripheral/device controller.
> > +*/
> > +   printf("All UDC in use (%d available), use the unbind 
> > command\n",  
> 
> 'UDC' should be plural, e.g.
> 
> %s/All UDC in use (%d available)/All %d UDCs bound/

Does not work well with one: "All 1 UDCs bound" does not look great.

I would prefer keeping the original sentence, s/UDC/UDCs/:
"All UDCs in use (%d available)".

Thanks,
Miquèl


Re: [PATCH] i2c: mvtwsi: reset controller if stuck in "bus error" state

2023-08-07 Thread Heiko Schocher
Hello Sam,

On 26.07.23 00:13, Sam Edwards wrote:
> The MVTWSI controller can act either as a master or slave device. When
> acting as a master, the FSM is driven by the CPU. As a slave, the FSM is
> driven by the bus directly. In what is (apparently) a safety mechanism,
> if the bus transitions our FSM in any improper way, the FSM goes to a
> "bus error" state (0x00). I could find no documented or experimental way
> to get the FSM out of this state, except for a controller reset.
> 
> Since U-Boot only uses the MVTWSI controller as a bus master, this
> feature only gets in the way: we do not care what happened on the bus
> previously as long as the bus is ready for a new transaction. So, when
> trying to start a new transaction, check for this state and reset the
> controller if necessary.
> 
> Note that this should not be confused with the "deblocking" technique
> (used by the `i2c reset` command), which involves pulsing SCL repeatedly
> if SDA is found to be held low, in an attempt to force the bus back to
> an idle state. This patch only resets the controller in case something
> else had previously upset it, and (in principle) results in no
> externally-observable change in behavior.
> 
> Signed-off-by: Sam Edwards 
> ---
>  drivers/i2c/mvtwsi.c | 42 ++
>  1 file changed, 42 insertions(+)

Reviewed-by: Heiko Schocher 

bye,
Heiko

-- 
DENX Software Engineering GmbH,  Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de


Re: [PATCH 1/2] cmd: bind: Try to improve the (un)bind help

2023-08-07 Thread Miquel Raynal
Hi Heinrich,

> >   U_BOOT_CMD(
> > bind,   4,  0,  do_bind_unbind,
> > -   "Bind a device to a driver",
> > +   "Bind a device to a driver, see 'dm tree' for the parameters\n",  
> 
> How about
> 
> "Use 'dm tree' to list classes, drivers, and devices."
> 
> as last line of the help long text.

Where is this supposed to be? Is there another macro to use than
U_BOOT_CMD()?

Thanks,
Miquèl


Re: [PATCH 2/2] usb: udc: Try to clarify an error message

2023-08-07 Thread Heinrich Schuchardt

On 04.08.23 21:14, Miquel Raynal wrote:

At some point when trying to use USB gadgets, two situations may arise
and lead to a failure. Either the UDC (USB Device Controller) is not
available at all (not described or not probed) or the UDC is already in
use. For instance, as the USB Ethernet gadget remains bound to the UDC,
the use of any other USB gadget (fastboot, dfu, etc) *after* will always
fail with the "couldn't find an available UDC" error.


Are the UDCs real devices or only logical ones?

If they are only logical ones, can we generate new ones on the fly?



Let's give a more helpful message by making a difference between the two
cases. Let's also hint people who would get this error and grep it into
the sources a better explanation of what's wrong with their workflow.

Signed-off-by: Miquel Raynal 
---

While doing this I really wanted to add "much more" error comments but I
faced another reality: often the messages are there but use
pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so
I consider this unnecessary, as decreasing the loglevel will make these
messages appear. I would have expected errors to be displayed, but I
understand it makes the binaries even bigger.
---
  drivers/usb/gadget/udc/udc-core.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 7f73926cb3e..30f6d73f36e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -323,6 +323,7 @@ err1:
  int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
  {
struct usb_udc  *udc = NULL;
+   unsigned intudc_count = 0;
int ret;
  
  	if (!driver || !driver->bind || !driver->setup)

@@ -330,12 +331,22 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
*driver)
  
  	mutex_lock(_lock);

list_for_each_entry(udc, _list, list) {
+   udc_count++;
+
/* For now we take the first one */
if (!udc->driver)
goto found;
}
  
-	printf("couldn't find an available UDC\n");

+   if (!udc_count)
+   printf("No UDC available in the system\n");
+   else
+   /* When this happens, users should 'unbind  '
+* using the output of 'dm tree' and looking at the line right
+* after the USB peripheral/device controller.
+*/
+   printf("All UDC in use (%d available), use the unbind 
command\n",


'UDC' should be plural, e.g.

%s/All UDC in use (%d available)/All %d UDCs bound/

Best regards

Heinrich


+  udc_count);
mutex_unlock(_lock);
return -ENODEV;
  found:




Re: [PATCH 1/2] cmd: bind: Try to improve the (un)bind help

2023-08-07 Thread Heinrich Schuchardt

On 04.08.23 21:13, Miquel Raynal wrote:

While it may sound totally obvious for the regular U-Boot developer to
get the parameters of the bind/unbind commands from the output of 'dm
tree', it did not felt straightforward to me until I was explicitly
told to look there. And even when I knew the command, I did not make a
direct link between the arguments of this command and the columns
returned by 'dm tree'.

Several of us lost a lot of time because of that, I would like to kindly
help other users by slightly improving this textual line. Unfortunately,
because of how this string is used (like within the 'help' command) I
cannot detail much more, but at least the pointer is there.

Signed-off-by: Miquel Raynal 
---
  cmd/bind.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cmd/bind.c b/cmd/bind.c
index 4d1b7885e60..8d29a42899e 100644
--- a/cmd/bind.c
+++ b/cmd/bind.c
@@ -243,14 +243,14 @@ static int do_bind_unbind(struct cmd_tbl *cmdtp, int 
flag, int argc,

  U_BOOT_CMD(
bind,   4,  0,  do_bind_unbind,
-   "Bind a device to a driver",
+   "Bind a device to a driver, see 'dm tree' for the parameters\n",


How about

"Use 'dm tree' to list classes, drivers, and devices."

as last line of the help long text.

Best regards

Heinrich


" \n"
"bind   \n"
  );

  U_BOOT_CMD(
unbind, 4,  0,  do_bind_unbind,
-   "Unbind a device from a driver",
+   "Unbind a device from a driver, see 'dm tree' for the parameters\n",
"\n"
"unbind  \n"
"unbind   \n"




Problem upon startup with halted USB device on RaspberryPi 4

2023-08-07 Thread Harry Waschkeit
Hi,

I have a RaspberryPi 4 where on one USB port a Sierra Wireless LTE 
module (EM7455) is attached via an PCIe-to-USB adapter.
The boot image I use gets built by Yocto with the help of poky 
(kirkstone) and meta-raspberry (beside a few other layers) which 
incorporates U-Boot 22.01.

When I apply power to the board it will come up until scanning USB 
devices (for potential boot devices), but then throw a BUG end reset the 
board.
This continues as long as the modem is unplugged.
The exact error message is:

scanning bus xhci_pci for devices... WARN halted endpoint, queuing URB 
anyway.
Unexpected XHCI event TRB, skipping... (3af519b0 0004 1300 02008401)
BUG at drivers/usb/host/xhci-ring.c:503/abort_td()!
BUG!
resetting ...

Some internet research brought up a patch (1) for 
drivers/usb/host/xhci-ring.c where halted devices simply get ignored 
during enumeration:

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index acf437104a..6d995f446e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -227,7 +227,8 @@ static int prepare_ring(struct xhci_ctrl *ctrl, 
struct xhci_ring *ep_ring,
puts("WARN waiting for error on ep to be cleared\n");
return -EINVAL;
case EP_STATE_HALTED:
- puts("WARN halted endpoint, queueing URB anyway.\n");
+ puts("WARN halted endpoint.\n");
+ return -EPIPE;
case EP_STATE_STOPPED:
case EP_STATE_RUNNING:
debug("EP STATE RUNNING.\n");

The driver file itself stems from the Linux sources, so I'm pretty sure 
that it is correct in that context.
Even though I'm not really into USB stuff and therefore I cannot not 
really follow the discussion for the proposed change, in my eyes the 
patch could be reasonable for U-Boot nevertheless given that a) in my 
experience driver code is often used in a simplified way in U-Boot 
compared to Linux kernel, and b) it's all about board start-up only and 
not about full OS use with all bells, whistles and full error handling.

Of course, I might be wrong while missing some important other use or 
corner cases, so I wanted to check here :-)

At least, what I can say: with this patch I see a bunch of these warning 
messages but the board comes up and is usable in the end by Linux.

fwiw: my internet search also showed another patch labelled in the first 
place "[PATCH] pi4: fix crash when issuing usb reset" (2) that didn't 
make it into the particular U-Boot 22.01 but was integrated right after 
that version in commit "Prepare v2022.04" with hash 
e4b6ebd3de982ae7185dbf689a030e73fd06e0d2 (3).
As I first hoped I could address my problem by just adding this patch I 
got promptly disappointed. The only thing I gained was to now get 
endless error messages followed by retries until I power-cycled the 
board (causing to start all over):

USB XHCI 1.00
scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB 
anyway.
Unexpected XHCI event TRB, skipping... (3afd6b30 0004 1300 02008401)
XHCI abort timeout
WARN halted endpoint, queueing URB anyway.
Unexpected XHCI event TRB, skipping... (3afd6b40 0004 1300 02008401)
XHCI abort timeout
WARN halted endpoint, queueing URB anyway.
Unexpected XHCI event TRB, skipping... (3afd6b50 0004 1300 02008401)
XHCI abort timeout
WARN halted endpoint, queueing URB anyway.
[...]

To me it means that this specific PCIe-to-USB bridge might misbehave 
somehow,
but the final question is: what are the odds to get that patch into 
official U-boot, or any other fix/quirk to make my hardware combo working?

And also interesting: if I cannot hope for an upstream change, what 
potential risks I would have to accept when keeping my patch?

Regards,
Harry

(1) 
https://linux-usb.vger.kernel.narkive.com/VW4VTVDU/patch-usb-host-xhci-fix-halted-endpoint-handling
(2) 
https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51...@denx.de/T/
(3) 
https://source.denx.de/u-boot/u-boot/-/commit/e4b6ebd3de982ae7185dbf689a030e73fd06e0d2

-- 
i.A. Harry Waschkeit
Senior Embedded Engineer
conplement AG
Südwestpark 92
90449 Nürnberg

Handelsregister: HRB 22863
Registergericht: Nürnberg
Vertreten durch: Britta Waligora und Thomas Wahle
Vorsitzender des Aufsichtsrates: Lorenz von Schröder



[PATCH v1 6/6] sysreset: implement PALMAS poweroff function

2023-08-07 Thread Svyatoslav Ryhel
PALMAS PMIC family has embedded poweroff function used by some
device to initiane device power off. Implement it as sysreset
driver.

Signed-off-by: Svyatoslav Ryhel 
---
 drivers/power/pmic/palmas.c| 33 +--
 drivers/sysreset/Kconfig   |  7 
 drivers/sysreset/Makefile  |  1 +
 drivers/sysreset/sysreset_palmas.c | 53 ++
 include/power/palmas.h | 11 +++
 5 files changed, 103 insertions(+), 2 deletions(-)
 create mode 100644 drivers/sysreset/sysreset_palmas.c

diff --git a/drivers/power/pmic/palmas.c b/drivers/power/pmic/palmas.c
index d6eb9cb433..eaa323ef8f 100644
--- a/drivers/power/pmic/palmas.c
+++ b/drivers/power/pmic/palmas.c
@@ -10,10 +10,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 
 static const struct pmic_child_info pmic_children_info[] = {
{ .prefix = "ldo", .driver = PALMAS_LDO_DRIVER },
@@ -46,7 +46,16 @@ static int palmas_bind(struct udevice *dev)
 {
ofnode pmic_node = ofnode_null(), regulators_node;
ofnode subnode;
-   int children;
+   int children, ret;
+
+   if (IS_ENABLED(CONFIG_SYSRESET_PALMAS)) {
+   ret = device_bind_driver(dev, PALMAS_RST_DRIVER,
+"sysreset", NULL);
+   if (ret) {
+   log_err("cannot bind SYSRESET (ret = %d)\n", ret);
+   return ret;
+   }
+   }
 
dev_for_each_subnode(subnode, dev) {
const char *name;
@@ -80,6 +89,24 @@ static int palmas_bind(struct udevice *dev)
return 0;
 }
 
+static int palmas_probe(struct udevice *dev)
+{
+   struct dm_i2c_chip *chip = dev_get_parent_plat(dev);
+   struct palmas_priv *priv = dev_get_priv(dev);
+   struct udevice *bus = dev_get_parent(dev);
+   u32 chip2_addr = chip->chip_addr + 1;
+   int ret;
+
+   /* Palmas PMIC is multi chip and chips are located in a row */
+   ret = i2c_get_chip(bus, chip2_addr, 1, >chip2);
+   if (ret) {
+   log_err("cannot get second PMIC I2C chip (err %d)\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static struct dm_pmic_ops palmas_ops = {
.read = palmas_read,
.write = palmas_write,
@@ -97,5 +124,7 @@ U_BOOT_DRIVER(pmic_palmas) = {
.id = UCLASS_PMIC,
.of_match = palmas_ids,
.bind = palmas_bind,
+   .probe = palmas_probe,
.ops = _ops,
+   .priv_auto = sizeof(struct palmas_priv),
 };
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 659170d156..0e52f99628 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -109,6 +109,13 @@ config SYSRESET_SPL_AT91
  This enables the system reset driver support for Microchip/Atmel
  SoCs in SPL.
 
+config SYSRESET_PALMAS
+   bool "Enable support for PALMAS System Reset"
+   depends on PMIC_PALMAS
+   select SYSRESET_CMD_POWEROFF if CMD_POWEROFF
+   help
+ Enable system power management functions found in PLAMAS PMIC family.
+
 config SYSRESET_PSCI
bool "Enable support for PSCI System Reset"
depends on ARM_PSCI_FW
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index 0d96a204a9..c9f1c625ae 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_$(SPL_TPL_)SYSRESET_MAX77663) += 
sysreset_max77663.o
 obj-$(CONFIG_SYSRESET_MPC83XX) += sysreset_mpc83xx.o
 obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
 obj-$(CONFIG_SYSRESET_OCTEON) += sysreset_octeon.o
+obj-$(CONFIG_$(SPL_TPL_)SYSRESET_PALMAS) += sysreset_palmas.o
 obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
 obj-$(CONFIG_SYSRESET_SBI) += sysreset_sbi.o
 obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
diff --git a/drivers/sysreset/sysreset_palmas.c 
b/drivers/sysreset/sysreset_palmas.c
new file mode 100644
index 00..d853c33504
--- /dev/null
+++ b/drivers/sysreset/sysreset_palmas.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Copyright(C) 2023 Svyatoslav Ryhel 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int palmas_sysreset_request(struct udevice *dev,
+  enum sysreset_t type)
+{
+   struct palmas_priv *priv = dev_get_priv(dev->parent);
+   int ret;
+
+   /*
+* Mask INT3 on second page which detects vbus
+* or device will immediately turn on.
+*/
+   ret = dm_i2c_reg_clrset(priv->chip2, PALMAS_INT3_MASK,
+   MASK_VBUS, MASK_VBUS);
+   if (ret < 0)
+   return ret;
+
+   switch (type) {
+   case SYSRESET_POWER:
+   /* PALMAS: SW_RST > DEV_CTRL */
+   pmic_reg_write(dev->parent, PALMAS_DEV_CTRL, SW_RST);
+   break;
+   case SYSRESET_POWER_OFF:
+   /* PALMAS: 

[PATCH v1 5/6] sysreset: implement TPS65910 sysreset functions

2023-08-07 Thread Svyatoslav Ryhel
TPS65910/TPS65911 PMICs have embedded power control functions
used by some device to initiane device power off. Implement it as
sysreset driver.

Signed-off-by: Svyatoslav Ryhel 
---
 drivers/power/pmic/pmic_tps65910_dm.c | 12 +-
 drivers/sysreset/Kconfig  |  8 
 drivers/sysreset/Makefile |  1 +
 drivers/sysreset/sysreset_tps65910.c  | 55 +++
 include/power/tps65910_pmic.h |  7 
 5 files changed, 82 insertions(+), 1 deletion(-)
 create mode 100644 drivers/sysreset/sysreset_tps65910.c

diff --git a/drivers/power/pmic/pmic_tps65910_dm.c 
b/drivers/power/pmic/pmic_tps65910_dm.c
index ff63c502d0..395c69a428 100644
--- a/drivers/power/pmic/pmic_tps65910_dm.c
+++ b/drivers/power/pmic/pmic_tps65910_dm.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,9 +57,18 @@ static int pmic_tps65910_read(struct udevice *dev, uint reg, 
u8 *buffer,
 static int pmic_tps65910_bind(struct udevice *dev)
 {
ofnode regulators_node;
-   int children;
+   int children, ret;
int type = dev_get_driver_data(dev);
 
+   if (IS_ENABLED(CONFIG_SYSRESET_TPS65910)) {
+   ret = device_bind_driver(dev, TPS65910_RST_DRIVER,
+"sysreset", NULL);
+   if (ret) {
+   log_err("cannot bind SYSRESET (ret = %d)\n", ret);
+   return ret;
+   }
+   }
+
regulators_node = dev_read_subnode(dev, "regulators");
if (!ofnode_valid(regulators_node)) {
debug("%s regulators subnode not found\n", dev->name);
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index cdb4ae2bb1..659170d156 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -157,6 +157,14 @@ config SYSRESET_TI_SCI
  This enables the system reset driver support over TI System Control
  Interface available on some new TI's SoCs.
 
+config SYSRESET_TPS65910
+   bool "Enable support for TPS65910/TPS65911 PMIC System Reset"
+   depends on DM_PMIC_TPS65910
+   select SYSRESET_CMD_POWEROFF if CMD_POWEROFF
+   help
+ Enable system power management functions found in TPS65910/TPS65911
+ PMICs.
+
 config SYSRESET_TPS80031
bool "Enable support for TPS80031/TPS80032 PMIC System Reset"
depends on DM_PMIC_TPS80031
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index f62db899da..0d96a204a9 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
 obj-$(CONFIG_SYSRESET_SOCFPGA_SOC64) += sysreset_socfpga_soc64.o
 obj-$(CONFIG_SYSRESET_TEGRA) += sysreset_tegra.o
 obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
+obj-$(CONFIG_$(SPL_TPL_)SYSRESET_TPS65910) += sysreset_tps65910.o
 obj-$(CONFIG_$(SPL_TPL_)SYSRESET_TPS80031) += sysreset_tps80031.o
 obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
 obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_tps65910.c 
b/drivers/sysreset/sysreset_tps65910.c
new file mode 100644
index 00..1a362dea0d
--- /dev/null
+++ b/drivers/sysreset/sysreset_tps65910.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Copyright(C) 2023 Svyatoslav Ryhel 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int tps65910_sysreset_request(struct udevice *dev,
+enum sysreset_t type)
+{
+   int val;
+
+   val = pmic_reg_read(dev->parent, TPS65910_REG_DEVICE_CTRL);
+   if (val < 0)
+   return val;
+
+   /* define power-off to be sequential */
+   val |= PWR_OFF_SEQ;
+   pmic_reg_write(dev->parent, TPS65910_REG_DEVICE_CTRL, val);
+
+   val &= ~DEV_ON;
+
+   switch (type) {
+   case SYSRESET_POWER:
+   /* TPS65910: DEV_OFF_RST > DEVICE_CTRL */
+   pmic_reg_write(dev->parent, TPS65910_REG_DEVICE_CTRL,
+  val | DEV_OFF_RST);
+   break;
+   case SYSRESET_POWER_OFF:
+   /* TPS65910: DEV_OFF > DEVICE_CTRL */
+   pmic_reg_write(dev->parent, TPS65910_REG_DEVICE_CTRL,
+  val | DEV_OFF);
+   break;
+   default:
+   return -EPROTONOSUPPORT;
+   }
+
+   return -EINPROGRESS;
+}
+
+static struct sysreset_ops tps65910_sysreset = {
+   .request = tps65910_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_tps65910) = {
+   .id = UCLASS_SYSRESET,
+   .name   = TPS65910_RST_DRIVER,
+   .ops= _sysreset,
+};
diff --git a/include/power/tps65910_pmic.h b/include/power/tps65910_pmic.h
index 10fe02b81a..f7b1b63b3c 100644
--- a/include/power/tps65910_pmic.h
+++ b/include/power/tps65910_pmic.h
@@ -20,6 +20,12 @@
 #define TPS65910_SUPPLY_STATE_OFF  0x0
 #define 

[PATCH v1 4/6] sysreset: implement TPS80031 sysreset functions

2023-08-07 Thread Svyatoslav Ryhel
TPS80031/TPS80032 PMICs have embedded power control functions
used by some device to initiane device power off. Implement it as
sysreset driver.

Signed-off-by: Svyatoslav Ryhel 
---
 drivers/power/pmic/tps80031.c| 12 +++-
 drivers/sysreset/Kconfig |  8 ++
 drivers/sysreset/Makefile|  1 +
 drivers/sysreset/sysreset_tps80031.c | 41 
 include/power/tps80031.h |  5 
 5 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 drivers/sysreset/sysreset_tps80031.c

diff --git a/drivers/power/pmic/tps80031.c b/drivers/power/pmic/tps80031.c
index c2b04fffdf..45e89ba5c9 100644
--- a/drivers/power/pmic/tps80031.c
+++ b/drivers/power/pmic/tps80031.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,7 +50,16 @@ static int tps80031_read(struct udevice *dev, uint reg, 
uint8_t *buff, int len)
 static int tps80031_bind(struct udevice *dev)
 {
ofnode regulators_node;
-   int children;
+   int children, ret;
+
+   if (IS_ENABLED(CONFIG_SYSRESET_TPS80031)) {
+   ret = device_bind_driver(dev, TPS80031_RST_DRIVER,
+"sysreset", NULL);
+   if (ret) {
+   log_err("cannot bind SYSRESET (ret = %d)\n", ret);
+   return ret;
+   }
+   }
 
regulators_node = dev_read_subnode(dev, "regulators");
if (!ofnode_valid(regulators_node)) {
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index bc35896101..cdb4ae2bb1 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -157,6 +157,14 @@ config SYSRESET_TI_SCI
  This enables the system reset driver support over TI System Control
  Interface available on some new TI's SoCs.
 
+config SYSRESET_TPS80031
+   bool "Enable support for TPS80031/TPS80032 PMIC System Reset"
+   depends on DM_PMIC_TPS80031
+   select SYSRESET_CMD_POWEROFF if CMD_POWEROFF
+   help
+ Enable system power management functions found in TPS80031/TPS80032
+ PMICs.
+
 config SYSRESET_SYSCON
bool "Enable support for mfd syscon reboot driver"
select REGMAP
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index c31f51c581..f62db899da 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
 obj-$(CONFIG_SYSRESET_SOCFPGA_SOC64) += sysreset_socfpga_soc64.o
 obj-$(CONFIG_SYSRESET_TEGRA) += sysreset_tegra.o
 obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
+obj-$(CONFIG_$(SPL_TPL_)SYSRESET_TPS80031) += sysreset_tps80031.o
 obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
 obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
 obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
diff --git a/drivers/sysreset/sysreset_tps80031.c 
b/drivers/sysreset/sysreset_tps80031.c
new file mode 100644
index 00..ea35f48ebd
--- /dev/null
+++ b/drivers/sysreset/sysreset_tps80031.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Copyright(C) 2023 Svyatoslav Ryhel 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int tps80031_sysreset_request(struct udevice *dev,
+enum sysreset_t type)
+{
+   switch (type) {
+   case SYSRESET_POWER:
+   /* TPS80031: SW_RESET > PHOENIX_DEV_ON */
+   pmic_reg_write(dev->parent, TPS80031_PHOENIX_DEV_ON, SW_RESET);
+   break;
+   case SYSRESET_POWER_OFF:
+   /* TPS80031: DEVOFF > PHOENIX_DEV_ON */
+   pmic_reg_write(dev->parent, TPS80031_PHOENIX_DEV_ON, DEVOFF);
+   break;
+   default:
+   return -EPROTONOSUPPORT;
+   }
+
+   return -EINPROGRESS;
+}
+
+static struct sysreset_ops tps80031_sysreset = {
+   .request = tps80031_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_tps80031) = {
+   .id = UCLASS_SYSRESET,
+   .name   = TPS80031_RST_DRIVER,
+   .ops= _sysreset,
+};
diff --git a/include/power/tps80031.h b/include/power/tps80031.h
index c80692a8af..983c841bfe 100644
--- a/include/power/tps80031.h
+++ b/include/power/tps80031.h
@@ -12,6 +12,7 @@
 /* Drivers name */
 #define TPS80031_LDO_DRIVER"tps80031_ldo"
 #define TPS80031_SMPS_DRIVER   "tps80031_smps"
+#define TPS80031_RST_DRIVER"tps80031_rst"
 
 #define TPS80031_SMPS_OFFSET   0xe0
 #define TPS80031_OFFSET_FLAG   BIT(0)
@@ -35,6 +36,10 @@
 #define LDO_VOLT_MIN   1018000
 #define LDO_VOLT_BASE  916000
 
+#define TPS80031_PHOENIX_DEV_ON0x25
+#define   SW_RESET BIT(6)
+#define   DEVOFF   BIT(0)
+
 /* register groups */
 enum {
CTRL,
-- 
2.39.2



[PATCH v1 3/6] sysreset: implement MAX77663 sysreset functions

2023-08-07 Thread Svyatoslav Ryhel
MAX77663 PMIC has embedded poweroff function used by some
device to initiane device power off. Implement it as sysreset
driver.

Signed-off-by: Svyatoslav Ryhel 
---
 drivers/power/pmic/max77663.c| 12 ++-
 drivers/sysreset/Kconfig |  7 
 drivers/sysreset/Makefile|  1 +
 drivers/sysreset/sysreset_max77663.c | 53 
 include/power/max77663.h |  5 +++
 5 files changed, 77 insertions(+), 1 deletion(-)
 create mode 100644 drivers/sysreset/sysreset_max77663.c

diff --git a/drivers/power/pmic/max77663.c b/drivers/power/pmic/max77663.c
index 4070235d3c..e333c8dcf5 100644
--- a/drivers/power/pmic/max77663.c
+++ b/drivers/power/pmic/max77663.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,7 +50,16 @@ static int max77663_read(struct udevice *dev, uint reg, 
uint8_t *buff, int len)
 static int max77663_bind(struct udevice *dev)
 {
ofnode regulators_node;
-   int children;
+   int children, ret;
+
+   if (IS_ENABLED(CONFIG_SYSRESET_MAX77663)) {
+   ret = device_bind_driver(dev, MAX77663_RST_DRIVER,
+"sysreset", NULL);
+   if (ret) {
+   log_err("cannot bind SYSRESET (ret = %d)\n", ret);
+   return ret;
+   }
+   }
 
regulators_node = dev_read_subnode(dev, "regulators");
if (!ofnode_valid(regulators_node)) {
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index eab556c349..bc35896101 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -74,6 +74,13 @@ config SYSRESET_GPIO
  example on Microblaze where reset logic can be controlled via GPIO
  pin which triggers cpu reset.
 
+config SYSRESET_MAX77663
+   bool "Enable support for MAX77663 PMIC System Reset"
+   depends on DM_PMIC_MAX77663
+   select SYSRESET_CMD_POWEROFF if CMD_POWEROFF
+   help
+ Enable system power management functions found in MAX77663 PMIC.
+
 config SYSRESET_MICROBLAZE
bool "Enable support for Microblaze soft reset"
depends on MICROBLAZE
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index a9ac123754..c31f51c581 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ARCH_STI) += sysreset_sti.o
 obj-$(CONFIG_SANDBOX) += sysreset_sandbox.o
 obj-$(CONFIG_POWEROFF_GPIO) += poweroff_gpio.o
 obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
+obj-$(CONFIG_$(SPL_TPL_)SYSRESET_MAX77663) += sysreset_max77663.o
 obj-$(CONFIG_SYSRESET_MPC83XX) += sysreset_mpc83xx.o
 obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
 obj-$(CONFIG_SYSRESET_OCTEON) += sysreset_octeon.o
diff --git a/drivers/sysreset/sysreset_max77663.c 
b/drivers/sysreset/sysreset_max77663.c
new file mode 100644
index 00..4a2a2275df
--- /dev/null
+++ b/drivers/sysreset/sysreset_max77663.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Copyright(C) 2023 Svyatoslav Ryhel 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int max77663_sysreset_request(struct udevice *dev,
+enum sysreset_t type)
+{
+   int val;
+
+   val = pmic_reg_read(dev->parent, MAX77663_REG_ONOFF_CFG1);
+   if (val < 0)
+   return val;
+
+   /* clear both bits */
+   val &= ~ONOFF_SFT_RST;
+   val &= ~ONOFF_PWR_OFF;
+
+   switch (type) {
+   case SYSRESET_POWER:
+   /* MAX77663: SFT_RST > ONOFF_CFG1 */
+   pmic_reg_write(dev->parent, MAX77663_REG_ONOFF_CFG1,
+  val | ONOFF_SFT_RST);
+   break;
+   case SYSRESET_POWER_OFF:
+   /* MAX77663: PWR_OFF > ONOFF_CFG1 */
+   pmic_reg_write(dev->parent, MAX77663_REG_ONOFF_CFG1,
+  val | ONOFF_PWR_OFF);
+   break;
+   default:
+   return -EPROTONOSUPPORT;
+   }
+
+   return -EINPROGRESS;
+}
+
+static struct sysreset_ops max77663_sysreset = {
+   .request = max77663_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_max77663) = {
+   .id = UCLASS_SYSRESET,
+   .name   = MAX77663_RST_DRIVER,
+   .ops= _sysreset,
+};
diff --git a/include/power/max77663.h b/include/power/max77663.h
index 0f764bcbcc..b3ae3dabf4 100644
--- a/include/power/max77663.h
+++ b/include/power/max77663.h
@@ -12,6 +12,7 @@
 /* Drivers name */
 #define MAX77663_LDO_DRIVER"max77663_ldo"
 #define MAX77663_SD_DRIVER "max77663_sd"
+#define MAX77663_RST_DRIVER"max77663_rst"
 
 /* Step-Down (SD) Regulator calculations */
 #define SD_STATUS_MASK 0x30
@@ -39,4 +40,8 @@
 
 #define LDO_VOLT_BASE  80
 
+#define MAX77663_REG_ONOFF_CFG10x41
+#define   ONOFF_SFT_RST

  1   2   >