Re: [PATCH v2] tpm: display warning if using gpio reset with TPM

2024-04-16 Thread Miquel Raynal
Hi Ilias,

ilias.apalodi...@linaro.org wrote on Wed, 17 Apr 2024 08:40:14 +0300:

> Hi Miquel
> 
> On Mon, 8 Apr 2024 at 10:23, Miquel Raynal  wrote:
> >
> > Hello,
> >
> > ilias.apalodi...@linaro.org wrote on Thu, 28 Mar 2024 09:08:37 +0200:
> >  
> > > Thanks Tim
> > >
> > > On Thu, 28 Mar 2024 at 00:12, Tim Harvey  wrote:  
> > > >
> > > > Instead of displaying what looks like an error message if a
> > > > gpio-reset dt prop is missing for a TPM display a warning that
> > > > having a gpio reset on a TPM should not be used for a secure production
> > > > device.
> > > >
> > > > TCG TIS spec [1] says:
> > > > "The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the
> > > > platform CPU Reset signal such that it complies with the requirements
> > > > specified in section 1.2.7 HOST Platform Reset in the PC Client
> > > > Implementation Specification for Conventional BIOS."
> > > >
> > > > The reasoning is that you should not be able to toggle a GPIO and reset
> > > > the TPM without resetting the CPU as well because if an attacker can
> > > > break into your OS via an OS level security flaw they can then reset the
> > > > TPM via GPIO and replay the measurements required to unseal keys
> > > > that you have otherwise protected.
> > > >
> > > > [1] 
> > > > https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf
> > > >
> > > > Signed-off-by: Tim Harvey 
> > > > ---
> > > > v2: change the message to a warning and update commit desc/log
> > > > ---
> > > >  drivers/tpm/tpm2_tis_spi.c | 8 
> > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
> > > > index de9cf8f21e07..c9c83f6f0fc8 100644
> > > > --- a/drivers/tpm/tpm2_tis_spi.c
> > > > +++ b/drivers/tpm/tpm2_tis_spi.c
> > > > @@ -237,14 +237,14 @@ static int tpm_tis_spi_probe(struct udevice *dev)
> > > > /* legacy reset */
> > > > ret = gpio_request_by_name(dev, "gpio-reset", 0,
> > > >&reset_gpio, 
> > > > GPIOD_IS_OUT);
> > > > -   if (ret) {
> > > > -   log(LOGC_NONE, LOGL_NOTICE,
> > > > -   "%s: missing reset GPIO\n", 
> > > > __func__);
> > > > +   if (ret)
> > > > goto init;
> > > > -   }
> > > > log(LOGC_NONE, LOGL_NOTICE,
> > > > "%s: gpio-reset is deprecated\n", __func__);
> > > > }
> > > > +   log(LOGC_NONE, LOGL_WARNING,
> > > > +   "%s: TPM gpio reset should not be used on secure 
> > > > production devices\n",
> > > > +   dev->name);
> > > > dm_gpio_set_value(&reset_gpio, 1);
> > > > mdelay(1);
> > > > dm_gpio_set_value(&reset_gpio, 0);  
> >
> > The current logic expects a reset gpio and bails out if it cannot get
> > it with a (questionable) goto statement.
> >
> > You want to invert that logic, and expect no gpio, but only if there is
> > one you want to warn.
> >
> > This is perfectly fine but the logic here must be clarified. I'd go for:
> >
> > ret = gpio_request()
> > if (ret) {
> > ret = gpio_request()
> > if (!ret)
> > warn(deprecated)
> > }
> >
> > if (!ret) {
> > warn(dangerous)
> > toggle_value()
> > }
> >
> > I would ideally replace the 'if (ret)' clauses with 'if (!reset_gpio)'
> > which would make the checks even clearer.  
> 
> Fair enough. But the code with the proposed change has no functional
> problems right?

No, this is functionally right, but the code is not clear like that.

> If so I'll send a PR to Tom as is and rework it as suggested later

Well, that's not how contribution work usually. Is there an emergency
in getting this merged?

Thanks,
Miquèl


Re: [PATCH v2] tpm: display warning if using gpio reset with TPM

2024-04-16 Thread Ilias Apalodimas
Hi Miquel

On Mon, 8 Apr 2024 at 10:23, Miquel Raynal  wrote:
>
> Hello,
>
> ilias.apalodi...@linaro.org wrote on Thu, 28 Mar 2024 09:08:37 +0200:
>
> > Thanks Tim
> >
> > On Thu, 28 Mar 2024 at 00:12, Tim Harvey  wrote:
> > >
> > > Instead of displaying what looks like an error message if a
> > > gpio-reset dt prop is missing for a TPM display a warning that
> > > having a gpio reset on a TPM should not be used for a secure production
> > > device.
> > >
> > > TCG TIS spec [1] says:
> > > "The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the
> > > platform CPU Reset signal such that it complies with the requirements
> > > specified in section 1.2.7 HOST Platform Reset in the PC Client
> > > Implementation Specification for Conventional BIOS."
> > >
> > > The reasoning is that you should not be able to toggle a GPIO and reset
> > > the TPM without resetting the CPU as well because if an attacker can
> > > break into your OS via an OS level security flaw they can then reset the
> > > TPM via GPIO and replay the measurements required to unseal keys
> > > that you have otherwise protected.
> > >
> > > [1] 
> > > https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf
> > >
> > > Signed-off-by: Tim Harvey 
> > > ---
> > > v2: change the message to a warning and update commit desc/log
> > > ---
> > >  drivers/tpm/tpm2_tis_spi.c | 8 
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
> > > index de9cf8f21e07..c9c83f6f0fc8 100644
> > > --- a/drivers/tpm/tpm2_tis_spi.c
> > > +++ b/drivers/tpm/tpm2_tis_spi.c
> > > @@ -237,14 +237,14 @@ static int tpm_tis_spi_probe(struct udevice *dev)
> > > /* legacy reset */
> > > ret = gpio_request_by_name(dev, "gpio-reset", 0,
> > >&reset_gpio, 
> > > GPIOD_IS_OUT);
> > > -   if (ret) {
> > > -   log(LOGC_NONE, LOGL_NOTICE,
> > > -   "%s: missing reset GPIO\n", __func__);
> > > +   if (ret)
> > > goto init;
> > > -   }
> > > log(LOGC_NONE, LOGL_NOTICE,
> > > "%s: gpio-reset is deprecated\n", __func__);
> > > }
> > > +   log(LOGC_NONE, LOGL_WARNING,
> > > +   "%s: TPM gpio reset should not be used on secure 
> > > production devices\n",
> > > +   dev->name);
> > > dm_gpio_set_value(&reset_gpio, 1);
> > > mdelay(1);
> > > dm_gpio_set_value(&reset_gpio, 0);
>
> The current logic expects a reset gpio and bails out if it cannot get
> it with a (questionable) goto statement.
>
> You want to invert that logic, and expect no gpio, but only if there is
> one you want to warn.
>
> This is perfectly fine but the logic here must be clarified. I'd go for:
>
> ret = gpio_request()
> if (ret) {
> ret = gpio_request()
> if (!ret)
> warn(deprecated)
> }
>
> if (!ret) {
> warn(dangerous)
> toggle_value()
> }
>
> I would ideally replace the 'if (ret)' clauses with 'if (!reset_gpio)'
> which would make the checks even clearer.

Fair enough. But the code with the proposed change has no functional
problems right?
If so I'll send a PR to Tom as is and rework it as suggested later

Thanks
/Ilias
>
> Thanks,
> Miquèl


Re: [PATCH] riscv: dts: jh7110: Enable PLL node in SPL

2024-04-16 Thread E Shattow
On Tue, Apr 9, 2024 at 11:44 PM Bo Gan  wrote:
>
> On 4/9/24 6:55 PM, E Shattow wrote:
> > Original speed class SD cards fail with this change "unable to change mode".
> >
>
> The BUS_ROOT clock will have to be switched to PLL2 anyway in U-Boot proper or
> in Linux, because it's the parent or grandparent clock for *lots* of devices,
> including PCIe, i2c, spi, qspi... If there's an issue with this change, then
> I suspect there's something wrong with the dw_mmc driver.
>
> Bo

I've bisected and can confirm this change is what breaks original
speed SD function on Milk-V Mars CM Lite (DFRobot mini router
carrier). Class 10 speed SD media does not seem to be affected.
Reverting the change allows the original speed SD media access to
function again. SD access is functional in Linux with and without the
change.

How to troubleshoot this?

Thanks,

E


[PATCH] board: ti: j721e: Add support for both esm probe

2024-04-16 Thread Udit Kumar
At present only MCU domain ESM is probed, this means errors
occurred in mcu domain will be propagate to MCU_SAFETY_ERRORn.
MCU ESM accepts SOC_SAFETY_ERRORn signal as Error
event and propagate to MCU_SAFETY_ERRORn.[0]

Therefore adding support to probe both main domain and mcu
domain ESM.

[0]: https://www.ti.com/lit/zip/spruil1
spruil1c.pdf from zip
Figure 12-1244. ESM Modules Overview

Signed-off-by: Udit Kumar 
---
 board/ti/j721e/evm.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index 9dc3ed6dff..539eaf4718 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -465,10 +465,13 @@ void spl_board_init(void)
}
 
if (IS_ENABLED(CONFIG_ESM_K3)) {
-   ret = uclass_get_device_by_driver(UCLASS_MISC,
- DM_DRIVER_GET(k3_esm), &dev);
+   ret = uclass_get_device_by_name(UCLASS_MISC, "esm@70", 
&dev);
+   if (ret)
+   printf("MISC init for esm@70 failed: %d\n", ret);
+
+   ret = uclass_get_device_by_name(UCLASS_MISC, "esm@4080", 
&dev);
if (ret)
-   printf("ESM init failed: %d\n", ret);
+   printf("MISC init for esm@4080 failed: %d\n", ret);
}
 
if (IS_ENABLED(CONFIG_ESM_PMIC)) {
-- 
2.34.1



Re: [PATCH 4/4] configs: visionfive2: enable SPL_YMODEM_SUPPORT

2024-04-16 Thread E Shattow
Successful in use w/ 'tio' serial tool and Adafruit CP2102N Friend
adapter on Mars CM Lite board in DFRobot mini router carrier.

While SPL and u-boot.itb payload are sourced via UART the environment
variables are from the environment variable storage as-is. This makes
sense in the use case for development but may have side-effects in the
case of U-Boot as a JH7110 recovery tool. There is now 'env default -f
-a' which does not purge non-default variables and retains the
non-default variables when migrating from vendor firmware. Consider to
also build for U-Boot the commands that can aid in cleaning the stored
environment variable state CONFIG_CMD_ERASEENV=y and in-memory state
CONFIG_CMD_NVEDIT_LOAD=y. With these it can be done easily with: 'env
erase; env load; env save'.

On Mon, Apr 15, 2024 at 4:51 AM Heinrich Schuchardt
 wrote:
>
> We can use U-Boot for recovering JH7110 based boards via UART
> if CONFIG_SPL_YMODEM_SUPPORT=y.
>
> * Send u-boot-spl.normal.out via XMODEM.
> * Send u-boot.itb via YMODEM.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  configs/starfive_visionfive2_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/starfive_visionfive2_defconfig 
> b/configs/starfive_visionfive2_defconfig
> index fa80d489f5e..e2d83c62b28 100644
> --- a/configs/starfive_visionfive2_defconfig
> +++ b/configs/starfive_visionfive2_defconfig
> @@ -62,6 +62,7 @@ CONFIG_SPL_I2C=y
>  CONFIG_SPL_DM_SPI_FLASH=y
>  CONFIG_SPL_DM_RESET=y
>  CONFIG_SPL_SPI_LOAD=y
> +CONFIG_SPL_YMODEM_SUPPORT=y
>  CONFIG_SYS_PROMPT="StarFive # "
>  CONFIG_CMD_EEPROM=y
>  CONFIG_SYS_EEPROM_SIZE=512
> --
> 2.43.0
>

Tested-by: E Shattow 


Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux

2024-04-16 Thread Dragan Simic

Hello Jaehoon,

On 2024-04-17 01:33, Jaehoon Chung wrote:

-Original Message-
From: Quentin Schulz 
Sent: Wednesday, April 10, 2024 5:57 PM
To: Dragan Simic 
Cc: Jonas Karlman ; Peng Fan ; 
Jaehoon Chung
; Tom Rini ; 
u-boot@lists.denx.de
Subject: Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to 
match linux


On 4/9/24 21:28, Dragan Simic wrote:

[...]

> Let's keep in mind that the troublesome DT properties describe the
> capabilities of the MMC controller and the board, not the capabilities
> of the MMC storage device.  As we know, eMMC devices provide automatic
> detection capabilities, to allow the host to determine its supported
> modes, and match them with the ones the host is configured to support.
> It's all described in the JEDEC standards.


I didn't see the above mail in my mailbox. So I can miss something.


It seems that, for some reason, the mail server(s) for @samsung.com
don't like the IP address of the @manjaro.org mail server, so my email
messages to you get rejected.


So why do we have those properties specified in board DTSes instead of
in the SoC DTSI? Logic would want us to have this defined in one place
only. I assume the issue is that even if the eMMC chip itself says it
supports HS400 but the HW routing or some other issue make it 
impossible

to use, we need a way to disable it from the DT for that board?

> Having that in mind, I find the approach in the Linux kernel rather
> reasonable, because I highly doubt that some MMC controllers support,
> for example, HS400 without supporting DDR52, or HS400 without supporting
> DDR52.  A reasonable approach for an MMC IP block is to make it capable
> of supporting all the speeds below its highest supported speed, to make
> itself capable of supporting more, if not all, MMC storage devices.
>

That's true for the IP block which is self-contained in the SoC, but
it's forgetting about the other part, the eMMC chip/card. It depends 
on
the HW routing, where mistakes/limitations can happen. And I don't 
think
we have a mechanism today to disable the modes set in the MMC 
controller
for a given MMC card from DT (aside from /delete-property/ in board 
files).


The both opinions make sense.
But, It doesn't set to all capabilities when nodes has mmc-hs400-* 
property.


That's why it's describing to each property is because they want to
clarify only which mode they use.

AFAIK, I can't remember exactly, there were some boards that even
though HS400 is working fine,
but HS200 was not working fine. (It's depends on which IP board is 
using.)


That's really good to know, thanks.


There were too many cases not to work fine because of *HW* design.
eMMC and Host IP were supporting the HS400/200 and all modes, but
there was a problem of handling clock.
So it couldn't use HS200/400 and other dual modes.


Yes, there are all kinds of eMMC signal integrity issues on different
designs.  There are also similar issues with different microSD cards,
causing some of them not to work in SDR104 mode on a particular board,
for example.


And We needs to know if it's working fine.
If we want to use hs400 mode, but board can be working to other mode
without any error.
Of course, we can see a mode as log. But it's at least approach to 
limit.



> In fact, I'll probably go ahead and submit a Linux kernel patch that
> updates the descriptions in the binding, to hopefully eliminate any
> ambiguities like these.  I hope you agree.

I for sure do not have enough knowledge in MMC to argue more than I 
just
did, so having people with more experience/knowledge have a look at 
this

would make sense, let's see what they have to say :)


Re: [PATCH v2] net: wget: fix TCP sequence number wrap around issue

2024-04-16 Thread Tom Rini
On Tue, 16 Apr 2024 09:26:24 +0900, Yasuharu Shibata wrote:

> If tcp_seq_num is wrap around, tcp_seq_num >= initial_data_seq_num
> isn't satisfied and store_block() isn't called.
> The condition has a wrap around issue, so it is fixed in this patch.
> 
> 

Applied to u-boot/master, thanks!

-- 
Tom




Re: [PATCH] net: wget: Support retransmission a dropped packet

2024-04-16 Thread Tom Rini
On Sun, 14 Apr 2024 19:46:07 +0900, Yasuharu Shibata wrote:

> The server sends multiple packets without waiting for an ACK
> by window control and if some packets are dropped,
> wget will return an ACK including the dropped packets.
> 
> Following log indicates this issue.
> 
>   wget_handler() wget: Transferring, seq=97bbdd4a, ack=30,len=580
>   wget_handler() wget: Transferring, seq=97bbedca, ack=30,len=580
> 
> [...]

Applied to u-boot/master, thanks!

-- 
Tom




RE: [PATCH] mmc: Support 32-bit only ADMA on 64-bit platforms

2024-04-16 Thread Jaehoon Chung



> -Original Message-
> From: Greg Malysa 
> Sent: Tuesday, March 26, 2024 11:28 AM
> To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung 
> 
> Cc: Greg Malysa ; Nathan Barrett-Morrison 
> ; Ian
> Roberts ; Jonas Karlman ; Kever 
> Yang  chips.com>; Marek Vasut ; Oleksandr Suvorov
> ; Paul Barker 
> ; Peter Geis
> ; Sean Anderson ; Simon Glass 
> ; Stefan
> Roese ; Tom Rini 
> Subject: [PATCH] mmc: Support 32-bit only ADMA on 64-bit platforms
> 
> Some arm64 platforms may include SDIO host controllers that
> only support 32-bit ADMA. While the Linux kernel detects which
> size is supported and adjusts the descriptor size used dynamically,
> the previous u-boot implementation statically selected between the
> two depending on whether DMA_ADDR_T_64BIT was defined. Because the
> static selection is already in place and effective for most platforms,
> this patch logically separates "64 bit addresses are used for DMA on
> this platform" and "64 bit addresses are used by the SDIO host
> controller for ADMA" in order to support the small number of platforms
> where these statements are not equivalent.
> 
> Using 32 bits is opt-in and existing 64 bit platforms should be
> unaffected by this change.
> 
> Co-developed-by: Nathan Barrett-Morrison 
> Signed-off-by: Nathan Barrett-Morrison 
> Co-developed-by: Ian Roberts 
> Signed-off-by: Ian Roberts 
> Signed-off-by: Greg Malysa 


Reviewed-by: Jaehoon Chung  

Best Regards,
Jaehoon Chung

> 
> ---
> 
> 
> ---
>  drivers/mmc/Kconfig  | 18 ++
>  drivers/mmc/sdhci-adma.c |  2 +-
>  drivers/mmc/sdhci.c  |  9 -
>  include/sdhci.h  |  4 ++--
>  4 files changed, 25 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index cef05790dd..4538286c64 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -495,6 +495,24 @@ config SPL_MMC_SDHCI_ADMA
> This enables support for the ADMA (Advanced DMA) defined
> in the SD Host Controller Standard Specification Version 3.00 in SPL.
> 
> +config MMC_SDHCI_ADMA_FORCE_32BIT
> + bool "Force 32 bit mode for ADMA on 64 bit platforms"
> + help
> +   This forces SDHCI ADMA to be built for 32 bit descriptors, even
> +   on a 64 bit platform where they would otherwise be assumed to
> +   be 64 bits. This is necessary for certain hardware platforms
> +   that are 64-bit but include only 32-bit support within the selected
> +   SD host controller IP.
> +
> +config MMC_SDHCI_ADMA_64BIT
> + bool "Use SHDCI ADMA with 64 bit descriptors"
> + depends on !MMC_SDHCI_ADMA_FORCE_32BIT
> + default y if DMA_ADDR_T_64BIT
> + help
> +   This selects 64 bit descriptors for SDHCI ADMA. It is enabled by
> +   default on 64 bit systems, but can be disabled if one of these
> +   systems includes 32-bit ADMA.
> +
>  config FIXED_SDHCI_ALIGNED_BUFFER
>   hex "SDRAM address for fixed buffer"
>   depends on SPL && MVEBU_SPL_BOOT_DEVICE_MMC
> diff --git a/drivers/mmc/sdhci-adma.c b/drivers/mmc/sdhci-adma.c
> index 8213223d3f..474647c3fd 100644
> --- a/drivers/mmc/sdhci-adma.c
> +++ b/drivers/mmc/sdhci-adma.c
> @@ -22,7 +22,7 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
>   desc->len = len;
>   desc->reserved = 0;
>   desc->addr_lo = lower_32_bits(addr);
> -#ifdef CONFIG_DMA_ADDR_T_64BIT
> +#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
>   desc->addr_hi = upper_32_bits(addr);
>  #endif
>  }
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 0178ed8a11..b27ce57d96 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -900,11 +900,10 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct 
> sdhci_host *host,
>   host->adma_desc_table = sdhci_adma_init();
>   host->adma_addr = (dma_addr_t)host->adma_desc_table;
> 
> -#ifdef CONFIG_DMA_ADDR_T_64BIT
> - host->flags |= USE_ADMA64;
> -#else
> - host->flags |= USE_ADMA;
> -#endif
> + if (IS_ENABLED(CONFIG_MMC_SDHCI_ADMA_64BIT))
> + host->flags |= USE_ADMA64;
> + else
> + host->flags |= USE_ADMA;
>  #endif
>   if (host->quirks & SDHCI_QUIRK_REG32_RW)
>   host->version =
> diff --git a/include/sdhci.h b/include/sdhci.h
> index a1b74e3bd7..07b84d6715 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -294,7 +294,7 @@ struct sdhci_ops {
>  };
> 
>  #define ADMA_MAX_LEN 65532
> -#ifdef CONFIG_DMA_ADDR_T_64BIT
> +#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
>  #define ADMA_DESC_LEN16
>  #else
>  #define ADMA_DESC_LEN8
> @@ -319,7 +319,7 @@ struct sdhci_adma_desc {
>   u8 reserved;
>   u16 len;
>   u32 addr_lo;
> -#ifdef CONFIG_DMA_ADDR_T_64BIT
> +#ifdef CONFIG_MMC_SDHCI_ADMA_64BIT
>   u32 addr_hi;
>  #endif
>  } __packed;
> --
> 2.43.2




RE: [PATCH] mmc: sdhci: Fix potential ADMA descriptor table overflow

2024-04-16 Thread Jaehoon Chung



> -Original Message-
> From: Greg Malysa 
> Sent: Tuesday, March 26, 2024 11:23 AM
> To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung 
> 
> Cc: Ian Roberts ; Nathan Barrett-Morrison 
> ; Greg
> Malysa ; Sean Anderson ; Tom 
> Rini
> 
> Subject: [PATCH] mmc: sdhci: Fix potential ADMA descriptor table overflow
> 
> From: Ian Roberts 
> 
> Change ADMA_TABLE_NO_ENTRIES to round the division up to fully
> contain CONFIG_SYS_MMC_MAX_BLK_COUNT, fixing potential buffer overflow
> of the ADMA descriptor table.
> 
> sdhci_prepare_adma_table() expecitily states it does _not_ check for
> overflow as the descriptor table size is dependent on
> CONFIG_SYS_MMC_MAX_BLK_COUNT. However, the ADMA_TABLE_NO_ENTRIES
> calculation does not round up the divison, so with the current u-boot
>  defaults:
> max_mmc_transfer = (CONFIG_SYS_MMC_MAX_BLK_COUNT * MMC_MAX_BLOCK_LEN) =
> 65535 * 512 = 33553920 bytes.
> ADMA_TABLE_NO_ENTRIES = max_mmc_transfer / ADMA_MAX_LEN =
> 33553920 / 65532, which does not divide cleanly.
> actual_max_transfer = ADMA_TABLE_NO_ENTRIES * ADMA_MAX_LEN = 512 *
> 65532 = 33552384, which is smaller than max_mmc_transfer.
> This can cause sdhci_prepare_adma_table() to write one extra
> descriptor, overflowing the table when a transaction larger than
> actual_max_transfer is issued.
> 
> Co-developed-by: Nathan Barrett-Morrison 
> Signed-off-by: Nathan Barrett-Morrison 
> Signed-off-by: Greg Malysa 
> Signed-off-by: Ian Roberts 


Reviewed-by: Jaehoon Chung  

Best Regards,
Jaehoon Chung

> 
> ---
> 
> 
> ---
>  include/sdhci.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/sdhci.h b/include/sdhci.h
> index a1b74e3bd7..fbc0f0391c 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -11,6 +11,7 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -299,8 +300,8 @@ struct sdhci_ops {
>  #else
>  #define ADMA_DESC_LEN8
>  #endif
> -#define ADMA_TABLE_NO_ENTRIES (CONFIG_SYS_MMC_MAX_BLK_COUNT * \
> -MMC_MAX_BLOCK_LEN) / ADMA_MAX_LEN
> +#define ADMA_TABLE_NO_ENTRIES DIV_ROUND_UP(CONFIG_SYS_MMC_MAX_BLK_COUNT * \
> +   MMC_MAX_BLOCK_LEN, ADMA_MAX_LEN)
> 
>  #define ADMA_TABLE_SZ (ADMA_TABLE_NO_ENTRIES * ADMA_DESC_LEN)
> 
> --
> 2.43.2




RE: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops

2024-04-16 Thread Jaehoon Chung



> -Original Message-
> From: Greg Malysa 
> Sent: Tuesday, March 26, 2024 11:18 AM
> To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung 
> 
> Cc: Ian Roberts ; Nathan Barrett-Morrison 
> ; Greg
> Malysa ; Jonas Karlman ; Kever Yang 
>  chips.com>; Peter Geis ; Sean Anderson 
> ; Simon Glass
> ; Tom Rini 
> Subject: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct 
> sdhci_ops
> 
> From: Ian Roberts 
> 
> Add this hook so that it can be overridden with driver specific
> implementations. We also let the original sdhci_adma_write_desc()
> accept &desc so that the function can set its new value. Then export
> the function so that it could be reused by driver's specific
> implementations.
> 
> The above is a port of Linux kernel commit 54552e4948cbf
> 
> In addition, allow drivers to allocate their own ADMA descriptor
> tables if additional space is required.
> 
> Finally, fix the assignment of adma_addr to fix compiler warning
> on 64-bit platforms that still use 32-bit DMA addressing.
> 
> Co-developed-by: Nathan Barrett-Morrison 
> Signed-off-by: Nathan Barrett-Morrison 
> Signed-off-by: Greg Malysa 
> Signed-off-by: Ian Roberts 

Reviewed-by: Jaehoon Chung  

Best Regards,
Jaehoon Chung

> 
> ---
> 
> 
> ---
>  drivers/mmc/fsl_esdhc.c  |  2 +-
>  drivers/mmc/sdhci-adma.c | 41 +++-
>  drivers/mmc/sdhci.c  |  8 +---
>  include/sdhci.h  | 12 ++--
>  4 files changed, 44 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index d50669..bd0671cc52 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -252,7 +252,7 @@ static void esdhc_setup_dma(struct fsl_esdhc_priv *priv, 
> struct mmc_data *data)
>   priv->adma_desc_table) {
>   debug("Using ADMA2\n");
>   /* prefer ADMA2 if it is available */
> - sdhci_prepare_adma_table(priv->adma_desc_table, data,
> + sdhci_prepare_adma_table(NULL, priv->adma_desc_table, data,
>priv->dma_addr);
> 
>   adma_addr = virt_to_phys(priv->adma_desc_table);
> diff --git a/drivers/mmc/sdhci-adma.c b/drivers/mmc/sdhci-adma.c
> index 8213223d3f..8c38448b6a 100644
> --- a/drivers/mmc/sdhci-adma.c
> +++ b/drivers/mmc/sdhci-adma.c
> @@ -9,9 +9,10 @@
>  #include 
>  #include 
> 
> -static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
> - dma_addr_t addr, u16 len, bool end)
> +void sdhci_adma_write_desc(struct sdhci_host *host, void **next_desc,
> +dma_addr_t addr, int len, bool end)
>  {
> + struct sdhci_adma_desc *desc = *next_desc;
>   u8 attr;
> 
>   attr = ADMA_DESC_ATTR_VALID | ADMA_DESC_TRANSFER_DATA;
> @@ -19,17 +20,30 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
>   attr |= ADMA_DESC_ATTR_END;
> 
>   desc->attr = attr;
> - desc->len = len;
> + desc->len = len & 0x;
>   desc->reserved = 0;
>   desc->addr_lo = lower_32_bits(addr);
>  #ifdef CONFIG_DMA_ADDR_T_64BIT
>   desc->addr_hi = upper_32_bits(addr);
>  #endif
> +
> + *next_desc += ADMA_DESC_LEN;
> +}
> +
> +static inline void __sdhci_adma_write_desc(struct sdhci_host *host,
> +void **desc, dma_addr_t addr,
> +int len, bool end)
> +{
> + if (host && host->ops && host->ops->adma_write_desc)
> + host->ops->adma_write_desc(host, desc, addr, len, end);
> + else
> + sdhci_adma_write_desc(host, desc, addr, len, end);
>  }
> 
>  /**
>   * sdhci_prepare_adma_table() - Populate the ADMA table
>   *
> + * @host:Pointer to the sdhci_host
>   * @table:   Pointer to the ADMA table
>   * @data:Pointer to MMC data
>   * @addr:DMA address to write to or read from
> @@ -39,25 +53,26 @@ static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
>   * Please note, that the table size depends on CONFIG_SYS_MMC_MAX_BLK_COUNT 
> and
>   * we don't have to check for overflow.
>   */
> -void sdhci_prepare_adma_table(struct sdhci_adma_desc *table,
> -   struct mmc_data *data, dma_addr_t addr)
> +void sdhci_prepare_adma_table(struct sdhci_host *host,
> +   struct sdhci_adma_desc *table,
> +   struct mmc_data *data, dma_addr_t start_addr)
>  {
> + dma_addr_t addr = start_addr;
>   uint trans_bytes = data->blocksize * data->blocks;
> - uint desc_count = DIV_ROUND_UP(trans_bytes, ADMA_MAX_LEN);
> - struct sdhci_adma_desc *desc = table;
> - int i = desc_count;
> + void *next_desc = table;
> + int i = DIV_ROUND_UP(trans_bytes, ADMA_MAX_LEN);
> 
>   while (--i) {
> - sdhci_adma_desc(desc, addr, ADMA_MAX_LEN, false);
> + __sdhci_adma_write_desc(host, &next_desc, addr,
> + ADMA_MAX_LEN, false);
>

Re: [PATCH 11/23] efi_loader: switch sha256 to mbedtls

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 08:22:23PM -0400, Raymond Mao wrote:
> Hi Tom,
> 
> On Tue, 16 Apr 2024 at 15:22, Tom Rini  wrote:
> 
> > On Tue, Apr 16, 2024 at 12:00:07PM -0700, Raymond Mao wrote:
> >
> > > When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from
> > > hash shim layer instead.
> > >
> > > Signed-off-by: Raymond Mao 
> > > ---
> > >  lib/efi_loader/efi_tcg2.c | 9 +
> > >  1 file changed, 9 insertions(+)
> >
> > Why can't we have the abstraction be at the level where we include one
> > library or the other so that the calling code doesn't change?
> >
> > Yes, we can do this - The only reason I added new hash APIs with "_mb" is
> just to
> avoid vendor drivers that are using hash functions switch to MbedTLS with
> this
> patch set (As a [RFC], I was going to control all effects within the EFI
> loader).
> But if you think a complete switching has more benefits for estimation, I
> can unify
> all APIs between on/off MbedTLS.

Yes, please, a complete switch.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 11/23] efi_loader: switch sha256 to mbedtls

2024-04-16 Thread Raymond Mao
Hi Tom,

On Tue, 16 Apr 2024 at 15:22, Tom Rini  wrote:

> On Tue, Apr 16, 2024 at 12:00:07PM -0700, Raymond Mao wrote:
>
> > When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from
> > hash shim layer instead.
> >
> > Signed-off-by: Raymond Mao 
> > ---
> >  lib/efi_loader/efi_tcg2.c | 9 +
> >  1 file changed, 9 insertions(+)
>
> Why can't we have the abstraction be at the level where we include one
> library or the other so that the calling code doesn't change?
>
> Yes, we can do this - The only reason I added new hash APIs with "_mb" is
just to
avoid vendor drivers that are using hash functions switch to MbedTLS with
this
patch set (As a [RFC], I was going to control all effects within the EFI
loader).
But if you think a complete switching has more benefits for estimation, I
can unify
all APIs between on/off MbedTLS.

Thanks and Regards,
Raymond


Re: [PATCH 06/23] image: remove redundant hash includes

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 08:13:53PM -0400, Raymond Mao wrote:
> Hi Tom,
> 
> On Tue, 16 Apr 2024 at 15:19, Tom Rini  wrote:
> 
> > On Tue, Apr 16, 2024 at 12:00:02PM -0700, Raymond Mao wrote:
> >
> > > Remove the redundant includes of u-boot/md5.h, u-boot/sha1.h,
> > > u-boot/sha256.h and u-boot/sha512.h
> > >
> > > Signed-off-by: Raymond Mao 
> > > ---
> > >  boot/image-fit.c | 4 
> > >  boot/image.c | 2 --
> > >  2 files changed, 6 deletions(-)
> >
> > Can you please explain how these are redundant? It's not clear, thanks.
> >
> > Both image.c and image-fit.c include image.h that
> includes .
> So we don't need to explicitly repeat "#include .h>" in
> both files.

OK, so lets move this to a prep series patch then please, and then later
 can if/as needed get the right headers for
mbedtls or not.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 06/23] image: remove redundant hash includes

2024-04-16 Thread Raymond Mao
Hi Tom,

On Tue, 16 Apr 2024 at 15:19, Tom Rini  wrote:

> On Tue, Apr 16, 2024 at 12:00:02PM -0700, Raymond Mao wrote:
>
> > Remove the redundant includes of u-boot/md5.h, u-boot/sha1.h,
> > u-boot/sha256.h and u-boot/sha512.h
> >
> > Signed-off-by: Raymond Mao 
> > ---
> >  boot/image-fit.c | 4 
> >  boot/image.c | 2 --
> >  2 files changed, 6 deletions(-)
>
> Can you please explain how these are redundant? It's not clear, thanks.
>
> Both image.c and image-fit.c include image.h that
includes .
So we don't need to explicitly repeat "#include .h>" in
both files.

Thanks and regards,
Raymond


Re: [PATCH 00/23] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 08:03:34PM -0400, Raymond Mao wrote:
> Hi Tom,
> 
> On Tue, 16 Apr 2024 at 19:50, Tom Rini  wrote:
> 
> > On Tue, Apr 16, 2024 at 07:47:44PM -0400, Raymond Mao wrote:
> > > Hi Tom,
> > >
> > > On Tue, 16 Apr 2024 at 19:12, Tom Rini  wrote:
> > >
> > > > On Tue, Apr 16, 2024 at 11:59:56AM -0700, Raymond Mao wrote:
> > > >
> > > > [snip]
> > > > > [1]: bloat-o-meter output between disabling/enabling MbedTLS
> > > > > ```
> > > > > add/remove: 231/69 grow/shrink: 12/5 up/down: 60196/-11166 (49030)
> > > >
> > > > I don't know if this is qemu_arm64 or sandbox.  With buildman's size
> > > > comparison functions we see:
> > > > qemu_arm64 : all +75537 bss -88 data +24 rodata +6349
> > text
> > > > +69252
> > > >u-boot: add: 274/-12, grow: 12/-4 bytes: 72002/-3800
> > (68202)
> > > > ...
> > > > sandbox: all +57008 bss +32 data +1632 rodata +352
> > > > text +54992
> > > >u-boot: add: 143/-75, grow: 21/-18 bytes: 64058/-16523
> > > > (47535)
> > > >
> > > > So please look in to using buildman to get more details about what's
> > > > changing, size-wise. Also, my goodness, that's far too much growth, and
> > > > we aren't removing anything? This needs to be a whole switch, not just
> > > > an addition. And then look in to what we can tweak / remove. Are we
> > > > perhaps not getting our usual link time garbage collection done?
> > > >
> > > As stated in the cover letter, with this patch set, we still build the
> > > original libs
> > > (lib/rsa, lib/asn1_decoder.c, lib/crypto/rsa_helper.c, lib/md5.c,
> > > lib/sha1.c,
> > > lib/sha256.c, lib/sha512.c) for the components outside of EFI loader.
> > > Eventually all these will be completely switched and removed.
> > > But I think we should do this in a sparated patch set - It is too big for
> > > one
> > > patch set.
> > > So, as the first patch set, this one will introduce MbedTLS and enable it
> > > with
> > > EFI loader, after they are merged, the next patch set will switch other
> > > components
> > > to use MbedTLS and remove the original libs.
> > > What are your thoughts?
> >
> > My thoughts are that we need to implement this as the optional
> > replacement for the existing libraries. We already have abstractions for
> > most if not all of the algorithms I believe. And we need to be able to
> > see how much size growth we get from this change because long term we
> > don't really want to have two sets of libraries for this functionality
> > (as a SW rather than HW implementation).
> >
> > I see. With this version most of the lib/crypto that are used by EFI loader
> (pkcs7, x509, public_key, mscode_parser, etc) are sharing the same
> abstractions except the ones for hash.
> I can replace them in v2, so that we can compare the final growth by
> switching
> on/off the MbedTLS build options.

If there's abstractions we need first, lets get that done as a prereq
series and then see what things are before/after. Thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 00/23] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot

2024-04-16 Thread Raymond Mao
Hi Tom,

On Tue, 16 Apr 2024 at 19:50, Tom Rini  wrote:

> On Tue, Apr 16, 2024 at 07:47:44PM -0400, Raymond Mao wrote:
> > Hi Tom,
> >
> > On Tue, 16 Apr 2024 at 19:12, Tom Rini  wrote:
> >
> > > On Tue, Apr 16, 2024 at 11:59:56AM -0700, Raymond Mao wrote:
> > >
> > > [snip]
> > > > [1]: bloat-o-meter output between disabling/enabling MbedTLS
> > > > ```
> > > > add/remove: 231/69 grow/shrink: 12/5 up/down: 60196/-11166 (49030)
> > >
> > > I don't know if this is qemu_arm64 or sandbox.  With buildman's size
> > > comparison functions we see:
> > > qemu_arm64 : all +75537 bss -88 data +24 rodata +6349
> text
> > > +69252
> > >u-boot: add: 274/-12, grow: 12/-4 bytes: 72002/-3800
> (68202)
> > > ...
> > > sandbox: all +57008 bss +32 data +1632 rodata +352
> > > text +54992
> > >u-boot: add: 143/-75, grow: 21/-18 bytes: 64058/-16523
> > > (47535)
> > >
> > > So please look in to using buildman to get more details about what's
> > > changing, size-wise. Also, my goodness, that's far too much growth, and
> > > we aren't removing anything? This needs to be a whole switch, not just
> > > an addition. And then look in to what we can tweak / remove. Are we
> > > perhaps not getting our usual link time garbage collection done?
> > >
> > As stated in the cover letter, with this patch set, we still build the
> > original libs
> > (lib/rsa, lib/asn1_decoder.c, lib/crypto/rsa_helper.c, lib/md5.c,
> > lib/sha1.c,
> > lib/sha256.c, lib/sha512.c) for the components outside of EFI loader.
> > Eventually all these will be completely switched and removed.
> > But I think we should do this in a sparated patch set - It is too big for
> > one
> > patch set.
> > So, as the first patch set, this one will introduce MbedTLS and enable it
> > with
> > EFI loader, after they are merged, the next patch set will switch other
> > components
> > to use MbedTLS and remove the original libs.
> > What are your thoughts?
>
> My thoughts are that we need to implement this as the optional
> replacement for the existing libraries. We already have abstractions for
> most if not all of the algorithms I believe. And we need to be able to
> see how much size growth we get from this change because long term we
> don't really want to have two sets of libraries for this functionality
> (as a SW rather than HW implementation).
>
> I see. With this version most of the lib/crypto that are used by EFI loader
(pkcs7, x509, public_key, mscode_parser, etc) are sharing the same
abstractions except the ones for hash.
I can replace them in v2, so that we can compare the final growth by
switching
on/off the MbedTLS build options.

Thanks and regards,
Raymond


Re: [PATCH 05/23] test: py: add sudo for virt-make-fs

2024-04-16 Thread Raymond Mao
Hi Tom,

On Tue, 16 Apr 2024 at 15:19, Tom Rini  wrote:

> On Tue, Apr 16, 2024 at 12:00:01PM -0700, Raymond Mao wrote:
>
> > Fix a permission issue when running virt-make-fs
> >
> > Signed-off-by: Raymond Mao 
> > ---
> >  test/py/tests/test_efi_secboot/conftest.py | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Can you elaborate please? The point of virt-make-fs was, I could have
> sworn, is that it doesn't require privileges.
>
> We can drop this patch from v2. The privileges issue is due to my Ubuntu
host setup (missing the permissions to access /boot/vmlinuz-*).

Thanks and regards,
Raymond


Re: [PATCH 00/23] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 07:47:44PM -0400, Raymond Mao wrote:
> Hi Tom,
> 
> On Tue, 16 Apr 2024 at 19:12, Tom Rini  wrote:
> 
> > On Tue, Apr 16, 2024 at 11:59:56AM -0700, Raymond Mao wrote:
> >
> > [snip]
> > > [1]: bloat-o-meter output between disabling/enabling MbedTLS
> > > ```
> > > add/remove: 231/69 grow/shrink: 12/5 up/down: 60196/-11166 (49030)
> >
> > I don't know if this is qemu_arm64 or sandbox.  With buildman's size
> > comparison functions we see:
> > qemu_arm64 : all +75537 bss -88 data +24 rodata +6349 text
> > +69252
> >u-boot: add: 274/-12, grow: 12/-4 bytes: 72002/-3800 (68202)
> > ...
> > sandbox: all +57008 bss +32 data +1632 rodata +352
> > text +54992
> >u-boot: add: 143/-75, grow: 21/-18 bytes: 64058/-16523
> > (47535)
> >
> > So please look in to using buildman to get more details about what's
> > changing, size-wise. Also, my goodness, that's far too much growth, and
> > we aren't removing anything? This needs to be a whole switch, not just
> > an addition. And then look in to what we can tweak / remove. Are we
> > perhaps not getting our usual link time garbage collection done?
> >
> As stated in the cover letter, with this patch set, we still build the
> original libs
> (lib/rsa, lib/asn1_decoder.c, lib/crypto/rsa_helper.c, lib/md5.c,
> lib/sha1.c,
> lib/sha256.c, lib/sha512.c) for the components outside of EFI loader.
> Eventually all these will be completely switched and removed.
> But I think we should do this in a sparated patch set - It is too big for
> one
> patch set.
> So, as the first patch set, this one will introduce MbedTLS and enable it
> with
> EFI loader, after they are merged, the next patch set will switch other
> components
> to use MbedTLS and remove the original libs.
> What are your thoughts?

My thoughts are that we need to implement this as the optional
replacement for the existing libraries. We already have abstractions for
most if not all of the algorithms I believe. And we need to be able to
see how much size growth we get from this change because long term we
don't really want to have two sets of libraries for this functionality
(as a SW rather than HW implementation).

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 00/23] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot

2024-04-16 Thread Raymond Mao
Hi Tom,

On Tue, 16 Apr 2024 at 19:12, Tom Rini  wrote:

> On Tue, Apr 16, 2024 at 11:59:56AM -0700, Raymond Mao wrote:
>
> [snip]
> > [1]: bloat-o-meter output between disabling/enabling MbedTLS
> > ```
> > add/remove: 231/69 grow/shrink: 12/5 up/down: 60196/-11166 (49030)
>
> I don't know if this is qemu_arm64 or sandbox.  With buildman's size
> comparison functions we see:
> qemu_arm64 : all +75537 bss -88 data +24 rodata +6349 text
> +69252
>u-boot: add: 274/-12, grow: 12/-4 bytes: 72002/-3800 (68202)
> ...
> sandbox: all +57008 bss +32 data +1632 rodata +352
> text +54992
>u-boot: add: 143/-75, grow: 21/-18 bytes: 64058/-16523
> (47535)
>
> So please look in to using buildman to get more details about what's
> changing, size-wise. Also, my goodness, that's far too much growth, and
> we aren't removing anything? This needs to be a whole switch, not just
> an addition. And then look in to what we can tweak / remove. Are we
> perhaps not getting our usual link time garbage collection done?
>
As stated in the cover letter, with this patch set, we still build the
original libs
(lib/rsa, lib/asn1_decoder.c, lib/crypto/rsa_helper.c, lib/md5.c,
lib/sha1.c,
lib/sha256.c, lib/sha512.c) for the components outside of EFI loader.
Eventually all these will be completely switched and removed.
But I think we should do this in a sparated patch set - It is too big for
one
patch set.
So, as the first patch set, this one will introduce MbedTLS and enable it
with
EFI loader, after they are merged, the next patch set will switch other
components
to use MbedTLS and remove the original libs.
What are your thoughts?

Thanks and regards,
Raymond


RE: [PATCH] mmc: cv1800b: Add transmit tap delay config to fix write error

2024-04-16 Thread Jaehoon Chung
Hi,

> -Original Message-
> From: Kongyang Liu 
> Sent: Tuesday, April 16, 2024 4:31 PM
> To: u-boot@lists.denx.de
> Cc: Jaehoon Chung ; Leo Yu-Chi Liang 
> ; Peng Fan
> ; Tom Rini 
> Subject: [PATCH] mmc: cv1800b: Add transmit tap delay config to fix write 
> error
> 
> Currently, only the receive delay is configured while the transmit delay
> is not set, which may result in errors when writing to the file. This issue
> can be resolved by setting PHY_TX_SRC_INVERT to SDHCI_PHY_TX_RX_DLY.
> 
> Signed-off-by: Kongyang Liu 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> 
>  drivers/mmc/cv1800b_sdhci.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c
> index 2275c53777..a50f4cff0d 100644
> --- a/drivers/mmc/cv1800b_sdhci.c
> +++ b/drivers/mmc/cv1800b_sdhci.c
> @@ -12,6 +12,8 @@
>  #define MMC_MAX_CLOCK37500
>  #define TUNE_MAX_PHCODE  128
> 
> +#define PHY_TX_SRC_INVERT  BIT(8)
> +
>  struct cv1800b_sdhci_plat {
>   struct mmc_config cfg;
>   struct mmc mmc;
> @@ -19,7 +21,7 @@ struct cv1800b_sdhci_plat {
> 
>  static void cv1800b_set_tap_delay(struct sdhci_host *host, u16 tap)
>  {
> - sdhci_writel(host, tap << 16, SDHCI_PHY_TX_RX_DLY);
> + sdhci_writel(host, PHY_TX_SRC_INVERT | tap << 16, SDHCI_PHY_TX_RX_DLY);
>  }
> 
>  static void cv1800b_sdhci_reset(struct sdhci_host *host, u8 mask)
> --
> 2.41.0




RE: [PATCH 2/2] mmc: Add support for the no-mmc-hs400 prop

2024-04-16 Thread Jaehoon Chung
Hi

> -Original Message-
> From: Jonas Karlman 
> Sent: Tuesday, April 9, 2024 6:06 AM
> To: Peng Fan ; Jaehoon Chung ; Tom 
> Rini 
> Cc: Jonas Karlman ; u-boot@lists.denx.de
> Subject: [PATCH 2/2] mmc: Add support for the no-mmc-hs400 prop
> 
> The linux commit f722e650d965 ("mmc: core: add support for disabling
> HS400 mode via DT") added support for a no-mmc-hs400 prop.
> 
> Add support for the no-mmc-hs400 prop to disable HS400 host caps.
> 
> Signed-off-by: Jonas Karlman 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/mmc-uclass.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 1349da72b102..1b454e8ec758 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -256,6 +256,9 @@ int mmc_of_parse(struct udevice *dev, struct mmc_config 
> *cfg)
>   cfg->host_caps |= MMC_CAP(MMC_HS_400) | MMC_CAP(MMC_HS_200);
>   if (dev_read_bool(dev, "mmc-hs400-enhanced-strobe"))
>   cfg->host_caps |= MMC_CAP(MMC_HS_400_ES);
> + if (dev_read_bool(dev, "no-mmc-hs400"))
> + cfg->host_caps &= ~(MMC_CAP(MMC_HS_400) |
> + MMC_CAP(MMC_HS_400_ES));
> 
>   if (dev_read_bool(dev, "non-removable")) {
>   cfg->host_caps |= MMC_CAP_NONREMOVABLE;
> --
> 2.43.2




RE: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux

2024-04-16 Thread Jaehoon Chung
Hi,

> -Original Message-
> From: Quentin Schulz 
> Sent: Wednesday, April 10, 2024 5:57 PM
> To: Dragan Simic 
> Cc: Jonas Karlman ; Peng Fan ; Jaehoon 
> Chung
> ; Tom Rini ; u-boot@lists.denx.de
> Subject: Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match 
> linux
> 
> Hi Dragan,
> 
> On 4/9/24 21:28, Dragan Simic wrote:
> 
> [...]
> 
> > Let's keep in mind that the troublesome DT properties describe the
> > capabilities of the MMC controller and the board, not the capabilities
> > of the MMC storage device.  As we know, eMMC devices provide automatic
> > detection capabilities, to allow the host to determine its supported
> > modes, and match them with the ones the host is configured to support.
> > It's all described in the JEDEC standards.
> >

I didn't see the above mail in my mailbox. So I can miss something.

> 
> So why do we have those properties specified in board DTSes instead of
> in the SoC DTSI? Logic would want us to have this defined in one place
> only. I assume the issue is that even if the eMMC chip itself says it
> supports HS400 but the HW routing or some other issue make it impossible
> to use, we need a way to disable it from the DT for that board?
> 
> > Having that in mind, I find the approach in the Linux kernel rather
> > reasonable, because I highly doubt that some MMC controllers support,
> > for example, HS400 without supporting DDR52, or HS400 without supporting
> > DDR52.  A reasonable approach for an MMC IP block is to make it capable
> > of supporting all the speeds below its highest supported speed, to make
> > itself capable of supporting more, if not all, MMC storage devices.
> >
> 
> That's true for the IP block which is self-contained in the SoC, but
> it's forgetting about the other part, the eMMC chip/card. It depends on
> the HW routing, where mistakes/limitations can happen. And I don't think
> we have a mechanism today to disable the modes set in the MMC controller
> for a given MMC card from DT (aside from /delete-property/ in board files).

The both opinions make sense.
But, It doesn't set to all capabilities when nodes has mmc-hs400-* property.

That's why it's describing to each property is because they want to clarify 
only which mode they use.

AFAIK, I can't remember exactly, there were some boards that even though HS400 
is working fine, 
but HS200 was not working fine. (It's depends on which IP board is using.)

There were too many cases not to work fine because of *HW* design. 
eMMC and Host IP were supporting the HS400/200 and all modes, but there was a 
problem of handling clock.
So it couldn't use HS200/400 and other dual modes.

And We needs to know if it's working fine. 
If we want to use hs400 mode, but board can be working to other mode without 
any error.
Of course, we can see a mode as log. But it's at least approach to limit.

Best Regards,
Jaehoon Chung

> 
> > In fact, I'll probably go ahead and submit a Linux kernel patch that
> > updates the descriptions in the binding, to hopefully eliminate any
> > ambiguities like these.  I hope you agree.
> 
> I for sure do not have enough knowledge in MMC to argue more than I just
> did, so having people with more experience/knowledge have a look at this
> would make sense, let's see what they have to say :)
> 
> Cheers,
> Quentin



Re: [PATCH 00/23] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot

2024-04-16 Thread Raymond Mao
Hi Tom,

On Tue, 16 Apr 2024 at 16:26, Tom Rini  wrote:

> On Tue, Apr 16, 2024 at 11:59:56AM -0700, Raymond Mao wrote:
>
> > Integrate MbedTLS v3.6 LTS (currently v3.6.0-RC1) with U-Boot.
>
> Please look in to:
> https://source.denx.de/u-boot/u-boot/-/jobs/818534

Yes. I am aware of the test failures of capsule UT and stated in the cover
letter.
This will be addressed when we have agreement on the current approach.

Regards,
Raymond


RE: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux

2024-04-16 Thread Jaehoon Chung
Hi,

> -Original Message-
> From: Quentin Schulz 
> Sent: Wednesday, April 10, 2024 12:27 AM
> To: Jonas Karlman ; Peng Fan ; Jaehoon 
> Chung
> ; Tom Rini 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match 
> linux
> 
> Hi Jonas,
> 
> On 4/8/24 23:06, Jonas Karlman wrote:
> > eMMC nodes in linux device tree files typically only contain a mmc-hs400
> > prop to signal support for both HS400 and HS200. However, U-Boot require
> > an explicit mmc-hs200 prop to signal support for the HS200 mode.
> >  > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled
> > using a mmc-hs400 prop.
> >
> 
> Technically speaking, the DT binding should be the one and only source
> of truth and should be implementation-agnostic.
> 
> There it says:
> """
>mmc-hs400-1_2v:
>  $ref: /schemas/types.yaml#/definitions/flag
>  description:
>eMMC HS400 mode (1.2V I/O) is supported.
> 
>mmc-hs400-1_8v:
>  $ref: /schemas/types.yaml#/definitions/flag
>  description:
>eMMC HS400 mode (1.8V I/O) is supported.
> """
> 
> So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it
> makes sense.
> 
> The point of the DT/DT binding is to be system-agnostic and
> representative of the **HW** implementation. At least that's what the DT
> people want it to be.
> 
> If the eMMC standard doesn't allow to have HS400 without HS200, then I
> think this change is acceptable as is, because it is the reality of the
> HW standard. Couldn't find this implied in the standard though (but I
> just skimmed through).
> 
> It's also quite surprising, as it's not because the eMMC works with
> HS400 that it necessarily does with HS200 or that it's desired (EMI,
> signal integrity/stability, etc...)?
> 
> Now, it wouldn't be the first time U-Boot follows whatever is done in
> Linux, so... up to you/the maintainers :)

I want to follow the linux kernel. 

> 
> Reviewed-by: Quentin Schulz 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> 
> Cheers,
> Quentin



Re: U-Boot/UKI Relationship Regarding Multiple DTBs

2024-04-16 Thread Tom Rini
On Mon, Apr 08, 2024 at 11:41:10AM -0500, vindicator wrote:

> Is u-boot capable of selecting the correct DTB in a UKI during boot?
> 
> I saw "doc/README.multi-dtb-fit", which at least somewhat addresses
> what I'm looking for I think, but I'm not sure if that will relate
> directly with executing a UKI that has multiple DTBs...
> 
> For my one board, I was working on building a workable "tinyconfig"
> kernel, but then also had the thought to maybe also build another
> "allyesconfig" kernel (one time) so I can figure out everything that
> gets used for ANY board (supported for $ARCH).
> Then another thought came after that, that maybe I could pile in all
> of the DTBs the kernel supports into a UKI (via "ukify"), which is
> where I came across https://github.com/systemd/systemd/issues/31946
> (convenient timing being so recent).
> 
> So it looks like my thinking is "doable", but just hasn't been done
> yet in "ukify", and I'd thought I'd check here if there's anything
> that needs to be done from u-boot's end as well.

Sorry for the delay in replying here. Yes, it's possible to have U-Boot
select the appropriate device tree in a FIT image that contains multiple
device trees.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 00/23] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 11:59:56AM -0700, Raymond Mao wrote:

[snip]
> [1]: bloat-o-meter output between disabling/enabling MbedTLS
> ```
> add/remove: 231/69 grow/shrink: 12/5 up/down: 60196/-11166 (49030)

I don't know if this is qemu_arm64 or sandbox.  With buildman's size
comparison functions we see:
qemu_arm64 : all +75537 bss -88 data +24 rodata +6349 text 
+69252
   u-boot: add: 274/-12, grow: 12/-4 bytes: 72002/-3800 (68202)
...
sandbox: all +57008 bss +32 data +1632 rodata +352 text 
+54992
   u-boot: add: 143/-75, grow: 21/-18 bytes: 64058/-16523 (47535)

So please look in to using buildman to get more details about what's
changing, size-wise. Also, my goodness, that's far too much growth, and
we aren't removing anything? This needs to be a whole switch, not just
an addition. And then look in to what we can tweak / remove. Are we
perhaps not getting our usual link time garbage collection done?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 00/23] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 11:59:56AM -0700, Raymond Mao wrote:

> Integrate MbedTLS v3.6 LTS (currently v3.6.0-RC1) with U-Boot.

Please look in to:
https://source.denx.de/u-boot/u-boot/-/jobs/818534

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot-mvebu 00/10] Turris Omnia DDR training changes

2024-04-16 Thread Tony Dinh
Hi Marek,

On Tue, Apr 16, 2024 at 3:11 AM Marek Behún  wrote:
>
> Hi Tony,
>
> hmm no I did not change the version number.
>
> The changes are only relevant for debug messages, there is no
> functional changes in how the DDR training is done, unless I made a
> mistake.
>
> I am not sure that changing the version is a good idea unless this is
> also done for the upstream where I sent the PR. But who knows if
> Marvell will have some people assigned to merge the PR.
>
> Since U-Boot prints its own version, people can easily reproduce the
> code for a given binary from U-Boot version string.

OK, sounds good.

Tested-by: Tony Dinh  # regression test for DS116

All the best,
Tony

>
> Marek
>
> On Mon, 15 Apr 2024 15:20:49 -0700
> Tony Dinh  wrote:
>
> > Hi Marek,
> >
> > I'm running a regression test with this patch on another Armada 385
> > board (Synology DS116). And
> > it is running without problem.
> >
> > I noticed that there is no version bump. Is this still 14.0.0? It's kind of
> > hard to see which version we are using without a minor revision such as 
> > 14.0.1.
> >
> > All the best,
> > Tony
> >
> > On Mon, Apr 15, 2024 at 9:39 AM Marek Behún  wrote:
> > >
> > > Hi Stefan,
> > >
> > > this series adds some changes to DDR3 training for Armada 38x and
> > > Turris Omnia.
> > >
> > > - patches 1-4 are meant to allow for reducing another 10 KiB in the
> > >   SPL binary. They were also sent to mv-ddr-marvell, via PR on github,
> > >   https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/45/
> > >   but I am told that Armada team has left Marvell, so who knows if this
> > >   will ever be merged there
> > > - patch 5 enables this reduction for Turris Omnia
> > > - patches 6-8 import old DDR3 training code and make some changes so
> > >   that it works with U-Boot. The reason why this is being done is
> > >   explained in patch 6
> > > - patch 9 glues the old DDR3 training code to current U-Boot
> > > - patch 10 allows for dynamic selection of old DDR3 training code on
> > >   Turris Omnia, via an U-Boot environment variable
> > >
> > > Marek
> > >
> > > Marek Behún (10):
> > >   ddr: marvell: a38x: debug: return from ddr3_tip_print_log() early if
> > > we won't print anything
> > >   ddr: marvell: a38x: debug: Remove unused variables
> > >   ddr: marvell: a38x: debug: Define DDR_VIEWER_TOOL variables only if
> > > needed, and make them static
> > >   ddr: marvell: a38x: debug: Allow compiling with immutable debug
> > > settings to reduce binary size
> > >   arm: mvebu: turris_omnia: Enable immutable debug settings in DDR3
> > > training by default
> > >   ddr: marvell: a38x: Import old DDR training code from 2017 version of
> > > U-Boot
> > >   ddr: marvell: a38x: old: Fix some compiler warning of the old code
> > >   ddr: marvell: a38x: old: Backport immutable debug settings
> > >   arm: mvebu: a38x: Add optional support for using old DDR3 training
> > > code
> > >   arm: mvebu: turris_omnia: Support old DDR3 training, selectable via
> > > env var
> > >
> > >  arch/arm/mach-mvebu/Kconfig   |   15 +
> > >  arch/arm/mach-mvebu/include/mach/cpu.h|1 +
> > >  arch/arm/mach-mvebu/spl.c |   37 +-
> > >  board/CZ.NIC/turris_omnia/Makefile|1 +
> > >  board/CZ.NIC/turris_omnia/old_ddr3_training.c |   79 +
> > >  board/CZ.NIC/turris_omnia/turris_omnia.c  |2 +-
> > >  configs/turris_omnia_defconfig|1 +
> > >  drivers/ddr/marvell/a38x/Makefile |2 +
> > >  drivers/ddr/marvell/a38x/ddr3_debug.c |   30 +-
> > >  drivers/ddr/marvell/a38x/ddr3_init.c  |3 +-
> > >  drivers/ddr/marvell/a38x/ddr3_init.h  |   43 +-
> > >  drivers/ddr/marvell/a38x/old/Makefile |   29 +
> > >  drivers/ddr/marvell/a38x/old/ddr3_a38x.c  |  738 +
> > >  drivers/ddr/marvell/a38x/old/ddr3_a38x.h  |   93 +
> > >  .../marvell/a38x/old/ddr3_a38x_mc_static.h|  226 ++
> > >  .../ddr/marvell/a38x/old/ddr3_a38x_topology.h |   22 +
> > >  .../ddr/marvell/a38x/old/ddr3_a38x_training.c |   40 +
> > >  drivers/ddr/marvell/a38x/old/ddr3_debug.c | 1545 ++
> > >  .../marvell/a38x/old/ddr3_hws_hw_training.c   |  148 +
> > >  .../marvell/a38x/old/ddr3_hws_hw_training.h   |   49 +
> > >  .../a38x/old/ddr3_hws_hw_training_def.h   |  464 +++
> > >  .../marvell/a38x/old/ddr3_hws_sil_training.h  |   17 +
> > >  drivers/ddr/marvell/a38x/old/ddr3_init.c  |  770 +
> > >  drivers/ddr/marvell/a38x/old/ddr3_init.h  |  405 +++
> > >  .../ddr/marvell/a38x/old/ddr3_logging_def.h   |  101 +
> > >  .../marvell/a38x/old/ddr3_patterns_64bit.h|  924 ++
> > >  .../ddr/marvell/a38x/old/ddr3_topology_def.h  |   76 +
> > >  drivers/ddr/marvell/a38x/old/ddr3_training.c  | 2651 +
> > >  .../ddr/marvell/a38x/old/ddr3_training_bist.c |  289 ++
> > >  .../a38x/old/ddr3_training_centralization.c   |  712 +
> > >  .../ddr/marvell/a38x/old/

Re: [PATCH 00/23] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 11:59:56AM -0700, Raymond Mao wrote:

> Integrate MbedTLS v3.6 LTS (currently v3.6.0-RC1) with U-Boot.
> 
> Patch 01 and 02 are for introducing MbedTLS release package.
> I have to split it into 2 parts due to the size limitation of Gmail.

So to be clear, for v2 you need to switch this to subtrees, like we do
for upstream dts files now. And a script to automate the "merge a new
release" should be done as well. Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 11/23] efi_loader: switch sha256 to mbedtls

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 12:00:07PM -0700, Raymond Mao wrote:

> When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from
> hash shim layer instead.
> 
> Signed-off-by: Raymond Mao 
> ---
>  lib/efi_loader/efi_tcg2.c | 9 +
>  1 file changed, 9 insertions(+)

Why can't we have the abstraction be at the level where we include one
library or the other so that the calling code doesn't change?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 06/23] image: remove redundant hash includes

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 12:00:02PM -0700, Raymond Mao wrote:

> Remove the redundant includes of u-boot/md5.h, u-boot/sha1.h,
> u-boot/sha256.h and u-boot/sha512.h
> 
> Signed-off-by: Raymond Mao 
> ---
>  boot/image-fit.c | 4 
>  boot/image.c | 2 --
>  2 files changed, 6 deletions(-)

Can you please explain how these are redundant? It's not clear, thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 05/23] test: py: add sudo for virt-make-fs

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 12:00:01PM -0700, Raymond Mao wrote:

> Fix a permission issue when running virt-make-fs
> 
> Signed-off-by: Raymond Mao 
> ---
>  test/py/tests/test_efi_secboot/conftest.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Can you elaborate please? The point of virt-make-fs was, I could have
sworn, is that it doesn't require privileges.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 20/23] lib/crypto: port MSCode parser on MbedTLS

2024-04-16 Thread Raymond Mao
Integrate MicroSoft Authenticate Code parser on top of MbedTLS
ASN.1 decoder.

Signed-off-by: Raymond Mao 
---
 include/crypto/mscode.h|   4 ++
 lib/crypto/mscode_parser.c | 104 +
 2 files changed, 108 insertions(+)

diff --git a/include/crypto/mscode.h b/include/crypto/mscode.h
index 551058b96e..c214fc87e4 100644
--- a/include/crypto/mscode.h
+++ b/include/crypto/mscode.h
@@ -9,6 +9,10 @@
 #ifndef __UBOOT__
 #include 
 #endif
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+#include 
+#include 
+#endif
 
 struct pefile_context {
 #ifndef __UBOOT__
diff --git a/lib/crypto/mscode_parser.c b/lib/crypto/mscode_parser.c
index 90d5b37a6c..167304def5 100644
--- a/lib/crypto/mscode_parser.c
+++ b/lib/crypto/mscode_parser.c
@@ -18,11 +18,113 @@
 #else
 #include "verify_pefile.h"
 #endif
+#if !CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
 #include "mscode.asn1.h"
+#endif
 
 /*
  * Parse a Microsoft Individual Code Signing blob
+ *
+ * U.P.SEQUENCE {
+ *U.P.OBJECTIDENTIFIER 1.3.6.1.4.1.311.2.1.15 (SPC_PE_IMAGE_DATA_OBJID)
+ *U.P.SEQUENCE {
+ *   U.P.BITSTRING NaN : 0 unused bit(s);
+ *   [C.P.0] {
+ *  [C.P.2] {
+ * [C.P.0] 
+ *  }
+ *   }
+ *}
+ * }
+ * U.P.SEQUENCE {
+ *U.P.SEQUENCE {
+ *   U.P.OBJECTIDENTIFIER 
+ *   U.P.NULL
+ *}
+ *U.P.OCTETSTRING 
+ * }
+ *
  */
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+
+int mscode_parse(void *_ctx, const void *content_data, size_t data_len,
+size_t asn1hdrlen)
+{
+   struct pefile_context *ctx = _ctx;
+   unsigned char *p = (unsigned char *)content_data;
+   unsigned char *end = (unsigned char *)content_data + data_len;
+   size_t len = 0;
+   int ret;
+   unsigned char *inner_p;
+   size_t seq_len = 0;
+
+   ret = mbedtls_asn1_get_tag(&p, end, &seq_len,
+  MBEDTLS_ASN1_CONSTRUCTED |
+  MBEDTLS_ASN1_SEQUENCE);
+   if (ret)
+   return ret;
+
+   inner_p = p;
+   ret = mbedtls_asn1_get_tag(&inner_p, inner_p + seq_len, &len, 
MBEDTLS_ASN1_OID);
+   if (ret)
+   return ret;
+
+   /* Sanity check on the PE Image Data OID (1.3.6.1.4.1.311.2.1.15) */
+   if (MBEDTLS_OID_CMP_RAW(MBEDTLS_OID_MICROSOFT_PEIMAGEDATA, inner_p, 
len))
+   return -EINVAL;
+
+   p += seq_len;
+   ret = mbedtls_asn1_get_tag(&p, end, &seq_len,
+  MBEDTLS_ASN1_CONSTRUCTED |
+  MBEDTLS_ASN1_SEQUENCE);
+   if (ret)
+   return ret;
+
+   ret = mbedtls_asn1_get_tag(&p, p + seq_len, &seq_len,
+  MBEDTLS_ASN1_CONSTRUCTED |
+  MBEDTLS_ASN1_SEQUENCE);
+   if (ret)
+   return ret;
+
+   inner_p = p;
+
+   /*
+* Check if the inner sequence contains a supported hash
+* algorithm OID
+*/
+   ret = mbedtls_asn1_get_tag(&inner_p, inner_p + seq_len, &len, 
MBEDTLS_ASN1_OID);
+   if (ret)
+   return ret;
+
+   if (!MBEDTLS_OID_CMP_RAW(MBEDTLS_OID_DIGEST_ALG_MD5, inner_p, len))
+   ctx->digest_algo = "md5";
+   else if (!MBEDTLS_OID_CMP_RAW(MBEDTLS_OID_DIGEST_ALG_SHA1, inner_p, 
len))
+   ctx->digest_algo = "sha1";
+   else if (!MBEDTLS_OID_CMP_RAW(MBEDTLS_OID_DIGEST_ALG_SHA224, inner_p, 
len))
+   ctx->digest_algo = "sha224";
+   else if (!MBEDTLS_OID_CMP_RAW(MBEDTLS_OID_DIGEST_ALG_SHA256, inner_p, 
len))
+   ctx->digest_algo = "sha256";
+   else if (!MBEDTLS_OID_CMP_RAW(MBEDTLS_OID_DIGEST_ALG_SHA384, inner_p, 
len))
+   ctx->digest_algo = "sha384";
+   else if (!MBEDTLS_OID_CMP_RAW(MBEDTLS_OID_DIGEST_ALG_SHA512, inner_p, 
len))
+   ctx->digest_algo = "sha512";
+
+   if (!ctx->digest_algo)
+   return -EINVAL;
+
+   p += seq_len;
+   ret = mbedtls_asn1_get_tag(&p, end, &len, MBEDTLS_ASN1_OCTET_STRING);
+   if (ret)
+   return ret;
+
+   ctx->digest = p;
+   ctx->digest_len = len;
+
+   return 0;
+}
+
+#else  /* !CONFIG_IS_ENABLED(MBEDTLS_LIB_X509) */
+
 int mscode_parse(void *_ctx, const void *content_data, size_t data_len,
 size_t asn1hdrlen)
 {
@@ -36,6 +138,8 @@ int mscode_parse(void *_ctx, const void *content_data, 
size_t data_len,
return asn1_ber_decoder(&mscode_decoder, ctx, content_data, data_len);
 }
 
+#endif /* CONFIG_IS_ENABLED(MBEDTLS_LIB_X509) */
+
 /*
  * Check the content type OID
  */
-- 
2.25.1



[PATCH 23/23] configs: enable MbedTLS as default setting

2024-04-16 Thread Raymond Mao
Enable MbedTLS as default setting for qemu arm64

Signed-off-by: Raymond Mao 
---
 configs/qemu_arm64_defconfig | 5 +
 configs/sandbox_defconfig| 4 
 2 files changed, 9 insertions(+)

diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index 7e166f4390..587a3fb912 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -67,4 +67,9 @@ CONFIG_TPM2_MMIO=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
 CONFIG_SEMIHOSTING=y
+CONFIG_MBEDTLS_LIB=y
+CONFIG_MBEDTLS_LIB_CRYPTO=y
+CONFIG_MBEDTLS_LIB_X509=y
+# CONFIG_MBEDTLS_LIB_TLS is not set
 CONFIG_TPM=y
+CONFIG_EFI_SECURE_BOOT=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 93b52f2de5..6f36fa0ac8 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -343,6 +343,10 @@ CONFIG_FS_CBFS=y
 CONFIG_FS_CRAMFS=y
 CONFIG_ADDR_MAP=y
 CONFIG_CMD_DHRYSTONE=y
+CONFIG_MBEDTLS_LIB=y
+CONFIG_MBEDTLS_LIB_CRYPTO=y
+CONFIG_MBEDTLS_LIB_X509=y
+# CONFIG_MBEDTLS_LIB_TLS is not set
 CONFIG_ECDSA=y
 CONFIG_ECDSA_VERIFY=y
 CONFIG_TPM=y
-- 
2.25.1



[PATCH 22/23] mbedtls: disable the unused features

2024-04-16 Thread Raymond Mao
Disable the unused features of MbedTLS to reduce the target size.

Signed-off-by: Raymond Mao 
---
 lib/mbedtls/mbedtls_def_config.h | 186 +++
 1 file changed, 93 insertions(+), 93 deletions(-)

diff --git a/lib/mbedtls/mbedtls_def_config.h b/lib/mbedtls/mbedtls_def_config.h
index 6e6d66716a..2a31ad7603 100644
--- a/lib/mbedtls/mbedtls_def_config.h
+++ b/lib/mbedtls/mbedtls_def_config.h
@@ -49,7 +49,7 @@
  *
  * Comment to disable the use of assembly code.
  */
-#define MBEDTLS_HAVE_ASM
+//#define MBEDTLS_HAVE_ASM
 
 /**
  * \def MBEDTLS_NO_UDBL_DIVISION
@@ -650,35 +650,35 @@
  *
  * Enable Cipher Block Chaining mode (CBC) for symmetric ciphers.
  */
-#define MBEDTLS_CIPHER_MODE_CBC
+//#define MBEDTLS_CIPHER_MODE_CBC
 
 /**
  * \def MBEDTLS_CIPHER_MODE_CFB
  *
  * Enable Cipher Feedback mode (CFB) for symmetric ciphers.
  */
-#define MBEDTLS_CIPHER_MODE_CFB
+//#define MBEDTLS_CIPHER_MODE_CFB
 
 /**
  * \def MBEDTLS_CIPHER_MODE_CTR
  *
  * Enable Counter Block Cipher mode (CTR) for symmetric ciphers.
  */
-#define MBEDTLS_CIPHER_MODE_CTR
+//#define MBEDTLS_CIPHER_MODE_CTR
 
 /**
  * \def MBEDTLS_CIPHER_MODE_OFB
  *
  * Enable Output Feedback mode (OFB) for symmetric ciphers.
  */
-#define MBEDTLS_CIPHER_MODE_OFB
+//#define MBEDTLS_CIPHER_MODE_OFB
 
 /**
  * \def MBEDTLS_CIPHER_MODE_XTS
  *
  * Enable Xor-encrypt-xor with ciphertext stealing mode (XTS) for AES.
  */
-#define MBEDTLS_CIPHER_MODE_XTS
+//#define MBEDTLS_CIPHER_MODE_XTS
 
 /**
  * \def MBEDTLS_CIPHER_NULL_CIPHER
@@ -757,20 +757,20 @@
  * Comment macros to disable the curve and functions for it
  */
 /* Short Weierstrass curves (supporting ECP, ECDH, ECDSA) */
-#define MBEDTLS_ECP_DP_SECP192R1_ENABLED
-#define MBEDTLS_ECP_DP_SECP224R1_ENABLED
-#define MBEDTLS_ECP_DP_SECP256R1_ENABLED
-#define MBEDTLS_ECP_DP_SECP384R1_ENABLED
-#define MBEDTLS_ECP_DP_SECP521R1_ENABLED
-#define MBEDTLS_ECP_DP_SECP192K1_ENABLED
-#define MBEDTLS_ECP_DP_SECP224K1_ENABLED
-#define MBEDTLS_ECP_DP_SECP256K1_ENABLED
-#define MBEDTLS_ECP_DP_BP256R1_ENABLED
-#define MBEDTLS_ECP_DP_BP384R1_ENABLED
-#define MBEDTLS_ECP_DP_BP512R1_ENABLED
+// #define MBEDTLS_ECP_DP_SECP192R1_ENABLED
+// #define MBEDTLS_ECP_DP_SECP224R1_ENABLED
+// #define MBEDTLS_ECP_DP_SECP256R1_ENABLED
+// #define MBEDTLS_ECP_DP_SECP384R1_ENABLED
+// #define MBEDTLS_ECP_DP_SECP521R1_ENABLED
+// #define MBEDTLS_ECP_DP_SECP192K1_ENABLED
+// #define MBEDTLS_ECP_DP_SECP224K1_ENABLED
+// #define MBEDTLS_ECP_DP_SECP256K1_ENABLED
+// #define MBEDTLS_ECP_DP_BP256R1_ENABLED
+// #define MBEDTLS_ECP_DP_BP384R1_ENABLED
+// #define MBEDTLS_ECP_DP_BP512R1_ENABLED
 /* Montgomery curves (supporting ECP) */
-#define MBEDTLS_ECP_DP_CURVE25519_ENABLED
-#define MBEDTLS_ECP_DP_CURVE448_ENABLED
+// #define MBEDTLS_ECP_DP_CURVE25519_ENABLED
+// #define MBEDTLS_ECP_DP_CURVE448_ENABLED
 
 /**
  * \def MBEDTLS_ECP_NIST_OPTIM
@@ -781,7 +781,7 @@
  *
  * Comment this macro to disable NIST curves optimisation.
  */
-#define MBEDTLS_ECP_NIST_OPTIM
+// #define MBEDTLS_ECP_NIST_OPTIM
 
 /**
  * \def MBEDTLS_ECP_RESTARTABLE
@@ -858,7 +858,7 @@
  *
  * Comment this macro to disable deterministic ECDSA.
  */
-#define MBEDTLS_ECDSA_DETERMINISTIC
+// #define MBEDTLS_ECDSA_DETERMINISTIC
 
 /**
  * \def MBEDTLS_KEY_EXCHANGE_PSK_ENABLED
@@ -878,7 +878,7 @@
  *  MBEDTLS_TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
  *  MBEDTLS_TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256
  */
-#define MBEDTLS_KEY_EXCHANGE_PSK_ENABLED
+// #define MBEDTLS_KEY_EXCHANGE_PSK_ENABLED
 
 /**
  * \def MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED
@@ -907,7 +907,7 @@
  * See dhm.h for more details.
  *
  */
-#define MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED
+// #define MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED
 
 /**
  * \def MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED
@@ -925,7 +925,7 @@
  *  MBEDTLS_TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
  *  MBEDTLS_TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
  */
-#define MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED
+// #define MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED
 
 /**
  * \def MBEDTLS_KEY_EXCHANGE_RSA_PSK_ENABLED
@@ -948,7 +948,7 @@
  *  MBEDTLS_TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256
  *  MBEDTLS_TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256
  */
-#define MBEDTLS_KEY_EXCHANGE_RSA_PSK_ENABLED
+// #define MBEDTLS_KEY_EXCHANGE_RSA_PSK_ENABLED
 
 /**
  * \def MBEDTLS_KEY_EXCHANGE_RSA_ENABLED
@@ -1005,7 +1005,7 @@
  * See dhm.h for more details.
  *
  */
-#define MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED
+// #define MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED
 
 /**
  * \def MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED
@@ -1030,7 +1030,7 @@
  *  MBEDTLS_TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
  *  MBEDTLS_TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
  */
-#define MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED
+// #define MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED
 
 /**
  * \def MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED
@@ -1054,7 +1054,7 @@
  *  MBEDTLS_TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
  *  MBEDTLS_TLS_ECDHE_ECDSA_WI

[PATCH 18/23] lib/crypto: Port x509_cert_parser on MbedTLS

2024-04-16 Thread Raymond Mao
Integrate x509_cert_parser on top of MbedTLS x509 library.
Add API x509_populate_cert and x509_populate_pubkey for code
reusability between x509 and pkcs7 parsers.

Signed-off-by: Raymond Mao 
---
 include/crypto/x509_parser.h  |  34 +++
 lib/crypto/x509_cert_parser.c | 430 ++
 2 files changed, 464 insertions(+)

diff --git a/include/crypto/x509_parser.h b/include/crypto/x509_parser.h
index 4cbdc1d661..6048e2fa4f 100644
--- a/include/crypto/x509_parser.h
+++ b/include/crypto/x509_parser.h
@@ -11,8 +11,36 @@
 #include 
 #include 
 #include 
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+#include 
+#include 
+#include 
+#endif
 
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+/* Backup of part of the parsing context */
+struct x509_cert_mbedtls_ctx {
+   void*tbs;   /* Signed data */
+   void*raw_serial;/* Raw serial number in ASN.1 */
+   void*raw_issuer;/* Raw issuer name in ASN.1 */
+   void*raw_subject;   /* Raw subject name in ASN.1 */
+   void*raw_skid;  /* Raw subjectKeyId in ASN.1 */
+};
+#endif
+
+/*
+ * MbedTLS integration Notes:
+ *
+ * Fields we don't need to populate from MbedTLS:
+ * 'raw_sig' and 'raw_sig_size' are buffer for x509_parse_context,
+ * not needed for MbedTLS.
+ * 'signer' and 'seen' are used internally by pkcs7_verify.
+ * 'verified' is not inuse.
+ */
 struct x509_certificate {
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+   struct x509_cert_mbedtls_ctx *mbedtls_ctx;
+#endif
struct x509_certificate *next;
struct x509_certificate *signer;/* Certificate that signed this 
one */
struct public_key *pub; /* Public key details */
@@ -48,6 +76,12 @@ struct x509_certificate {
  * x509_cert_parser.c
  */
 extern void x509_free_certificate(struct x509_certificate *cert);
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+int x509_populate_pubkey(mbedtls_x509_crt *cert, struct public_key **pub_key);
+int x509_populate_cert(mbedtls_x509_crt *mbedtls_cert,
+  struct x509_certificate **pcert);
+time64_t x509_get_timestamp(const mbedtls_x509_time *x509_time);
+#endif
 extern struct x509_certificate *x509_cert_parse(const void *data, size_t 
datalen);
 extern int x509_decode_time(time64_t *_t,  size_t hdrlen,
unsigned char tag,
diff --git a/lib/crypto/x509_cert_parser.c b/lib/crypto/x509_cert_parser.c
index a0f0689118..4c5b802afa 100644
--- a/lib/crypto/x509_cert_parser.c
+++ b/lib/crypto/x509_cert_parser.c
@@ -25,8 +25,10 @@
 #else
 #include "x509_parser.h"
 #endif
+#if !CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
 #include "x509.asn1.h"
 #include "x509_akid.asn1.h"
+#endif
 
 struct x509_parse_context {
struct x509_certificate *cert;  /* Certificate being 
constructed */
@@ -52,6 +54,270 @@ struct x509_parse_context {
unsignedakid_raw_issuer_size;
 };
 
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+
+static void x509_free_mbedtls_ctx(struct x509_cert_mbedtls_ctx *ctx)
+{
+   if (ctx) {
+   kfree(ctx->tbs);
+   kfree(ctx->raw_serial);
+   kfree(ctx->raw_issuer);
+   kfree(ctx->raw_subject);
+   kfree(ctx->raw_skid);
+   kfree(ctx);
+   }
+}
+
+static int x509_set_cert_flags(struct x509_certificate *cert)
+{
+   struct public_key_signature *sig = cert->sig;
+
+   if (!sig || !cert->pub) {
+   pr_err("Signature or public key is not initialized\n");
+   return -ENOPKG;
+   }
+
+   if (!cert->pub->pkey_algo)
+   cert->unsupported_key = true;
+
+   if (!sig->pkey_algo)
+   cert->unsupported_sig = true;
+
+   if (!sig->hash_algo)
+   cert->unsupported_sig = true;
+
+   /* TODO: is_hash_blacklisted()? */
+
+   /* Detect self-signed certificates and set self_signed flag */
+   return x509_check_for_self_signed(cert);
+}
+
+time64_t x509_get_timestamp(const mbedtls_x509_time *x509_time)
+{
+   unsigned int year, mon, day, hour, min, sec;
+
+   /* Adjust for year since 1900 */
+   year = x509_time->year - 1900;
+   /* Adjust for 0-based month */
+   mon = x509_time->mon - 1;
+   day = x509_time->day;
+   hour = x509_time->hour;
+   min = x509_time->min;
+   sec = x509_time->sec;
+
+   return (time64_t)mktime64(year, mon, day, hour, min, sec);
+}
+
+static char *x509_populate_dn_name_string(const mbedtls_x509_name *name)
+{
+   size_t len = 256;
+   size_t wb;
+   char *name_str;
+
+   do {
+   name_str = kzalloc(len, GFP_KERNEL);
+   if (!name_str)
+   return NULL;
+
+   wb = mbedtls_x509_dn_gets(name_str, len, name);
+   if (wb < 0) {
+   pr_err("Get DN string failed, ret:-0x%04x\n",
+  (unsigned int)-wb);
+   kfree(

[PATCH 19/23] lib/crypto: port PKCS7 parser on MbedTLS

2024-04-16 Thread Raymond Mao
Integrate PKCS7 parser on top of MbedTLS PKCS7 library.

Signed-off-by: Raymond Mao 
---
 include/crypto/pkcs7_parser.h |  56 
 lib/crypto/pkcs7_parser.c | 482 --
 2 files changed, 510 insertions(+), 28 deletions(-)

diff --git a/include/crypto/pkcs7_parser.h b/include/crypto/pkcs7_parser.h
index 2c45cce523..9f4549871f 100644
--- a/include/crypto/pkcs7_parser.h
+++ b/include/crypto/pkcs7_parser.h
@@ -11,6 +11,12 @@
 #include 
 #include 
 #include 
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+#include 
+#include 
+#include 
+#include 
+#endif
 #include 
 
 #define kenter(FMT, ...) \
@@ -18,7 +24,54 @@
 #define kleave(FMT, ...) \
pr_devel("<== %s()"FMT"\n", __func__, ##__VA_ARGS__)
 
+/* Backup the parsed MedTLS context that we need */
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+struct pkcs7_mbedtls_ctx {
+   void *content_data;
+};
+
+struct pkcs7_sinfo_mbedtls_ctx {
+   void *authattrs_data;
+   void *content_data_digest;
+};
+#endif
+
+/*
+ * MbedTLS integration Notes:
+ *
+ * MbedTLS PKCS#7 library does not originally support parsing MicroSoft
+ * Authentication Code which is used for verifying the PE image digest.
+ *
+ * 1.  Authenticated Attributes (authenticatedAttributes)
+ * MbedTLS assumes unauthenticatedAttributes and authenticatedAttributes
+ * fields not exist.
+ * See MbedTLS function 'pkcs7_get_signer_info' for details.
+ *
+ * 2.  MicroSoft Authentication Code (mscode)
+ * MbedTLS only supports Content Data type defined as 1.2.840.113549.1.7.1
+ * (MBEDTLS_OID_PKCS7_DATA, aka OID_data).
+ * 1.3.6.1.4.1.311.2.1.4 (MicroSoft Authentication Code, aka
+ * OID_msIndirectData) is not supported.
+ * See MbedTLS function 'pkcs7_get_content_info_type' for details.
+ *
+ * But the EFI loader assumes that a PKCS#7 message with an EFI image always
+ * contains MicroSoft Authentication Code as Content Data (msg->data is NOT
+ * NULL), see function 'efi_signature_verify'.
+ *
+ * MbedTLS patch 
"0002-support-MicroSoft-authentication-code-in-PKCS7-lib.patch"
+ * is to support both above features by parsing the Content Data and
+ * Authenticate Attributes from a given PKCS#7 message.
+ *
+ * Other fields we don't need to populate from MbedTLS, which are used
+ * internally by pkcs7_verify:
+ * 'signer', 'unsupported_crypto', 'blacklisted'
+ * 'sig->digest' is used internally by pkcs7_digest to calculate the hash of
+ * Content Data or Authenticate Attributes.
+ */
 struct pkcs7_signed_info {
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+   struct pkcs7_sinfo_mbedtls_ctx *mbedtls_ctx;
+#endif
struct pkcs7_signed_info *next;
struct x509_certificate *signer; /* Signing certificate (in msg->certs) 
*/
unsignedindex;
@@ -55,6 +108,9 @@ struct pkcs7_signed_info {
 };
 
 struct pkcs7_message {
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+   struct pkcs7_mbedtls_ctx *mbedtls_ctx;
+#endif
struct x509_certificate *certs; /* Certificate list */
struct x509_certificate *crl;   /* Revocation list */
struct pkcs7_signed_info *signed_infos;
diff --git a/lib/crypto/pkcs7_parser.c b/lib/crypto/pkcs7_parser.c
index d5efa828d6..3c819d934e 100644
--- a/lib/crypto/pkcs7_parser.c
+++ b/lib/crypto/pkcs7_parser.c
@@ -27,7 +27,9 @@
 #else
 #include "pkcs7_parser.h"
 #endif
+#if !CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
 #include "pkcs7.asn1.h"
+#endif
 
 MODULE_DESCRIPTION("PKCS#7 parser");
 MODULE_AUTHOR("Red Hat, Inc.");
@@ -52,6 +54,352 @@ struct pkcs7_parse_context {
boolexpect_skid;
 };
 
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+
+static void pkcs7_free_mbedtls_ctx(struct pkcs7_mbedtls_ctx *ctx)
+{
+   if (ctx) {
+   kfree(ctx->content_data);
+   kfree(ctx);
+   }
+}
+
+static void pkcs7_free_sinfo_mbedtls_ctx(struct pkcs7_sinfo_mbedtls_ctx *ctx)
+{
+   if (ctx) {
+   kfree(ctx->authattrs_data);
+   kfree(ctx->content_data_digest);
+   kfree(ctx);
+   }
+}
+
+/*
+ * Parse Authenticate Attributes
+ * TODO: Shall we consider to integrate decoding of authenticate attribute into
+ *  MbedTLS library?
+ *
+ * Structure of the data:
+ *
+ * [C.P.0] {
+ *U.P.SEQUENCE {
+ *   U.P.OBJECTIDENTIFIER 
+ *   U.P.SET {
+ *  U.P.OBJECTIDENTIFIER 
+ *   }
+ *}
+ *U.P.SEQUENCE {
+ *   U.P.OBJECTIDENTIFIER 
+ *   U.P.SET {
+ *  U.P.UTCTime 
+ *   }
+ *}
+ *U.P.SEQUENCE {
+ *   U.P.OBJECTIDENTIFIER 
+ *   U.P.SET {
+ *  U.P.OCTETSTRING 
+ *   }
+ *}
+ *U.P.SEQUENCE {
+ *   U.P.OBJECTIDENTIFIER 
+ *   U.P.SET {
+ *  U.P.SEQUENCE {
+ * [...]
+ *  }
+ *   }
+ *}
+ * }
+ */
+static int authattrs_parse(struct pkcs7_message *msg, void *aa, size_t aa_len,
+  struct pkcs7_signed_info *sinfo)
+{
+   unsigned char *p = (unsigned char *)aa;
+   unsigned char *

[PATCH 21/23] lib/crypto: remove dependence on ASN1 decoder

2024-04-16 Thread Raymond Mao
When building with MbedTLS,  we are using MbedTLS to decode ASN1 data
for x509, pkcs7 and mscode. So we can remove the dependence on ASN1
decoder when MBEDTLS_LIB_X509 is enabled.

Signed-off-by: Raymond Mao 
---
 lib/crypto/Makefile | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/lib/crypto/Makefile b/lib/crypto/Makefile
index bec1bc95a6..00fbda05ae 100644
--- a/lib/crypto/Makefile
+++ b/lib/crypto/Makefile
@@ -31,6 +31,11 @@ endif
 # X.509 Certificate handling
 #
 obj-$(CONFIG_$(SPL_)X509_CERTIFICATE_PARSER) += x509_key_parser.o
+ifdef CONFIG_MBEDTLS_LIB_X509
+x509_key_parser-y := \
+   x509_cert_parser.o \
+   x509_public_key.o
+else
 x509_key_parser-y := \
x509.asn1.o \
x509_akid.asn1.o \
@@ -43,27 +48,37 @@ $(obj)/x509_cert_parser.o: \
 
 $(obj)/x509.asn1.o: $(obj)/x509.asn1.c $(obj)/x509.asn1.h
 $(obj)/x509_akid.asn1.o: $(obj)/x509_akid.asn1.c $(obj)/x509_akid.asn1.h
+endif
 
 #
 # PKCS#7 message handling
 #
 obj-$(CONFIG_$(SPL_)PKCS7_MESSAGE_PARSER) += pkcs7_message.o
+ifdef CONFIG_MBEDTLS_LIB_X509
+pkcs7_message-y := \
+   pkcs7_parser.o
+else
 pkcs7_message-y := \
pkcs7.asn1.o \
pkcs7_parser.o
-obj-$(CONFIG_$(SPL_)PKCS7_VERIFY) += pkcs7_verify.o
 
 $(obj)/pkcs7_parser.o: $(obj)/pkcs7.asn1.h
 $(obj)/pkcs7.asn1.o: $(obj)/pkcs7.asn1.c $(obj)/pkcs7.asn1.h
+endif
+obj-$(CONFIG_$(SPL_)PKCS7_VERIFY) += pkcs7_verify.o
 
 #
 # Signed PE binary-wrapped key handling
 #
 obj-$(CONFIG_$(SPL_)MSCODE_PARSER) += mscode.o
-
+ifdef CONFIG_MBEDTLS_LIB_X509
+mscode-y := \
+   mscode_parser.o
+else
 mscode-y := \
mscode_parser.o \
mscode.asn1.o
 
 $(obj)/mscode_parser.o: $(obj)/mscode.asn1.h $(obj)/mscode.asn1.h
 $(obj)/mscode.asn1.o: $(obj)/mscode.asn1.c $(obj)/mscode.asn1.h
+endif
-- 
2.25.1



[PATCH 15/23] mbedtls/external: support decoding multiple signer's cert

2024-04-16 Thread Raymond Mao
Support decoding multiple signer's cert in the signed data within
a PKCS7 message.

Signed-off-by: Raymond Mao 
---
 lib/mbedtls/external/mbedtls/library/pkcs7.c | 75 
 1 file changed, 47 insertions(+), 28 deletions(-)

diff --git a/lib/mbedtls/external/mbedtls/library/pkcs7.c 
b/lib/mbedtls/external/mbedtls/library/pkcs7.c
index da73fb341d..01105227d7 100644
--- a/lib/mbedtls/external/mbedtls/library/pkcs7.c
+++ b/lib/mbedtls/external/mbedtls/library/pkcs7.c
@@ -61,6 +61,36 @@ static int pkcs7_get_next_content_len(unsigned char **p, 
unsigned char *end,
 return ret;
 }
 
+/**
+ * Get and decode one cert from a sequence.
+ * Return 0 for success,
+ * Return negative error code for failure.
+ **/
+static int pkcs7_get_one_cert(unsigned char **p, unsigned char *end,
+  mbedtls_x509_crt *certs)
+{
+int ret = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED;
+size_t len = 0;
+unsigned char *start = *p;
+unsigned char *end_cert;
+
+ret = mbedtls_asn1_get_tag(p, end, &len, MBEDTLS_ASN1_CONSTRUCTED
+   | MBEDTLS_ASN1_SEQUENCE);
+if (ret != 0) {
+return MBEDTLS_ERROR_ADD(MBEDTLS_ERR_PKCS7_INVALID_CERT, ret);
+}
+
+end_cert = *p + len;
+
+if ((ret = mbedtls_x509_crt_parse_der(certs, start, end_cert - start)) < 
0) {
+return MBEDTLS_ERR_PKCS7_INVALID_CERT;
+}
+
+*p = end_cert;
+
+return 0;
+}
+
 /**
  * version Version
  * Version ::= INTEGER
@@ -178,11 +208,12 @@ static int pkcs7_get_certificates(unsigned char **p, 
unsigned char *end,
   mbedtls_x509_crt *certs)
 {
 int ret = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED;
-size_t len1 = 0;
-size_t len2 = 0;
-unsigned char *end_set, *end_cert, *start;
+size_t len = 0;
+unsigned char *end_set;
+int num_of_certs = 0;
 
-ret = mbedtls_asn1_get_tag(p, end, &len1, MBEDTLS_ASN1_CONSTRUCTED
+/* Get the set of certs */
+ret = mbedtls_asn1_get_tag(p, end, &len, MBEDTLS_ASN1_CONSTRUCTED
| MBEDTLS_ASN1_CONTEXT_SPECIFIC);
 if (ret == MBEDTLS_ERR_ASN1_UNEXPECTED_TAG) {
 return 0;
@@ -190,38 +221,26 @@ static int pkcs7_get_certificates(unsigned char **p, 
unsigned char *end,
 if (ret != 0) {
 return MBEDTLS_ERROR_ADD(MBEDTLS_ERR_PKCS7_INVALID_FORMAT, ret);
 }
-start = *p;
-end_set = *p + len1;
+end_set = *p + len;
 
-ret = mbedtls_asn1_get_tag(p, end_set, &len2, MBEDTLS_ASN1_CONSTRUCTED
-   | MBEDTLS_ASN1_SEQUENCE);
+ret = pkcs7_get_one_cert(p, end_set, certs);
 if (ret != 0) {
-return MBEDTLS_ERROR_ADD(MBEDTLS_ERR_PKCS7_INVALID_CERT, ret);
+return ret;
 }
 
-end_cert = *p + len2;
+num_of_certs++;
 
-/*
- * This is to verify that there is only one signer certificate. It seems 
it is
- * not easy to differentiate between the chain vs different signer's 
certificate.
- * So, we support only the root certificate and the single signer.
- * The behaviour would be improved with addition of multiple signer 
support.
- */
-if (end_cert != end_set) {
-return MBEDTLS_ERR_PKCS7_FEATURE_UNAVAILABLE;
-}
-
-if ((ret = mbedtls_x509_crt_parse_der(certs, start, len1)) < 0) {
-return MBEDTLS_ERR_PKCS7_INVALID_CERT;
+while (*p != end_set) {
+ret = pkcs7_get_one_cert(p, end_set, certs);
+if (ret != 0) {
+return ret;
+}
+num_of_certs++;
 }
 
-*p = end_cert;
+*p = end_set;
 
-/*
- * Since in this version we strictly support single certificate, and 
reaching
- * here implies we have parsed successfully, we return 1.
- */
-return 1;
+return num_of_certs;
 }
 
 /**
-- 
2.25.1



[PATCH 17/23] lib/crypto: Port public_key on MbedTLS

2024-04-16 Thread Raymond Mao
Integrate function public_key_verify_signature on top of MbedTLS
pk library.

Signed-off-by: Raymond Mao 
---
 include/crypto/public_key.h  |  6 +++
 lib/crypto/asymmetric_type.c |  2 +-
 lib/crypto/public_key.c  | 75 
 3 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 3ba90fcc34..55cd4c2b01 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -12,6 +12,12 @@
 
 #ifdef __UBOOT__
 #include 
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+#include 
+#include 
+#include 
+#include 
+#endif
 #else
 #include 
 #endif
diff --git a/lib/crypto/asymmetric_type.c b/lib/crypto/asymmetric_type.c
index 24c2d15ef9..95b82cd8e8 100644
--- a/lib/crypto/asymmetric_type.c
+++ b/lib/crypto/asymmetric_type.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #endif
-#include 
 #ifdef __UBOOT__
 #include 
 #include 
@@ -26,6 +25,7 @@
 #include 
 #include 
 #endif
+#include 
 #ifdef __UBOOT__
 #include 
 #else
diff --git a/lib/crypto/public_key.c b/lib/crypto/public_key.c
index 6efe951c05..29576684f1 100644
--- a/lib/crypto/public_key.c
+++ b/lib/crypto/public_key.c
@@ -94,6 +94,80 @@ EXPORT_SYMBOL_GPL(public_key_signature_free);
  *
  * Return: 0 - verified, non-zero error code - otherwise
  */
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_X509)
+int public_key_verify_signature(const struct public_key *pkey,
+   const struct public_key_signature *sig)
+{
+   mbedtls_md_type_t mb_hash_algo;
+   mbedtls_pk_context pk_ctx;
+   int ret;
+
+   if (!pkey || !sig || pkey->key_is_private)
+   return -EINVAL;
+
+   /*
+* ECRDSA (Elliptic Curve RedDSA) from Red Hat is not supported by
+* MbedTLS
+*/
+   if (strcmp(pkey->pkey_algo, "rsa")) {
+   pr_err("Encryption is not RSA: %s\n", sig->pkey_algo);
+   return -EINVAL;
+   }
+
+   /*
+* Can be pkcs1 or raw, but pkcs1 is expected.
+* This is just for argument checking, not necessarily passed to 
MbedTLS,
+* For RSA signatures, MbedTLS typically supports the PKCS#1 v1.5
+* (aka. pkcs1) encoding by default.
+* The library internally handles the details of decoding and verifying
+* the signature according to the expected encoding for the specified 
algorithm.
+*/
+   if (strcmp(sig->encoding, "pkcs1")) {
+   pr_err("Encoding %s is not supported, only supports pkcs1\n",
+  sig->encoding);
+   return -EINVAL;
+   }
+
+   if (!strcmp(sig->hash_algo, "sha1"))
+   mb_hash_algo = MBEDTLS_MD_SHA1;
+   else if (!strcmp(sig->hash_algo, "sha224"))
+   mb_hash_algo = MBEDTLS_MD_SHA224;
+   else if (!strcmp(sig->hash_algo, "sha256"))
+   mb_hash_algo = MBEDTLS_MD_SHA256;
+   else if (!strcmp(sig->hash_algo, "sha384"))
+   mb_hash_algo = MBEDTLS_MD_SHA384;
+   else if (!strcmp(sig->hash_algo, "sha512"))
+   mb_hash_algo = MBEDTLS_MD_SHA512;
+   else/* Unknown or unsupported hash algorithm */
+   return -EINVAL;
+   /* Initialize the mbedtls_pk_context with RSA key type */
+   mbedtls_pk_init(&pk_ctx);
+
+   /* Parse the DER-encoded public key */
+   ret = mbedtls_pk_parse_public_key(&pk_ctx, pkey->key, pkey->keylen);
+   if (ret) {
+   pr_err("Failed to parse public key, ret:-0x%04x\n",
+  (unsigned int)-ret);
+   ret = -EINVAL;
+   goto err_key;
+   }
+
+   /* Ensure that it is a RSA key */
+   if (mbedtls_pk_get_type(&pk_ctx) != MBEDTLS_PK_RSA) {
+   pr_err("Only RSA keys are supported\n");
+   ret = -EKEYREJECTED;
+   goto err_key;
+   }
+
+   /* Verify the hash */
+   ret = mbedtls_pk_verify(&pk_ctx, mb_hash_algo, sig->digest,
+   sig->digest_size, sig->s, sig->s_size);
+
+err_key:
+   mbedtls_pk_free(&pk_ctx);
+   return ret;
+}
+#else  /* !CONFIG_IS_ENABLED(MBEDTLS_LIB_X509) */
 int public_key_verify_signature(const struct public_key *pkey,
const struct public_key_signature *sig)
 {
@@ -142,6 +216,7 @@ int public_key_verify_signature(const struct public_key 
*pkey,
pr_devel("<==%s() = %d\n", __func__, ret);
return ret;
 }
+#endif /* CONFIG_IS_ENABLED(MBEDTLS_LIB_X509) */
 #else
 /*
  * Destroy a public key algorithm key.
-- 
2.25.1



[PATCH 16/23] mbedtls/external: update MbedTLS PKCS7 test suites

2024-04-16 Thread Raymond Mao
Update the PKCS7 test suites for multiple certs.

Signed-off-by: Raymond Mao 
---
 .../external/mbedtls/tests/suites/test_suite_pkcs7.data   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/mbedtls/external/mbedtls/tests/suites/test_suite_pkcs7.data 
b/lib/mbedtls/external/mbedtls/tests/suites/test_suite_pkcs7.data
index d3b83cdf0a..2dd1c56109 100644
--- a/lib/mbedtls/external/mbedtls/tests/suites/test_suite_pkcs7.data
+++ b/lib/mbedtls/external/mbedtls/tests/suites/test_suite_pkcs7.data
@@ -14,9 +14,9 @@ PKCS7 Signed Data Parse with zero signers
 depends_on:MBEDTLS_MD_CAN_SHA256
 pkcs7_parse:"data_files/pkcs7_data_no_signers.der":MBEDTLS_PKCS7_SIGNED_DATA
 
-PKCS7 Signed Data Parse Fail with multiple certs #4
+PKCS7 Signed Data Parse Pass with multiple certs #4
 depends_on:MBEDTLS_MD_CAN_SHA256:MBEDTLS_RSA_C
-pkcs7_parse:"data_files/pkcs7_data_multiple_certs_signed.der":MBEDTLS_ERR_PKCS7_FEATURE_UNAVAILABLE
+pkcs7_parse:"data_files/pkcs7_data_multiple_certs_signed.der":MBEDTLS_PKCS7_SIGNED_DATA
 
 PKCS7 Signed Data Parse Fail with corrupted cert #5.0
 depends_on:MBEDTLS_MD_CAN_SHA256:MBEDTLS_RSA_C
-- 
2.25.1



[PATCH 14/23] mbedtls/external: support PKCS9 Authenticate Attributes

2024-04-16 Thread Raymond Mao
Populate PKCS9 Authenticate Attributes from signer info if it exists
in a PKCS7 message.
Add OIDs for describing objects using for Authenticate Attributes.

Signed-off-by: Raymond Mao 
---
 .../external/mbedtls/include/mbedtls/oid.h|  5 +
 .../external/mbedtls/include/mbedtls/pkcs7.h  | 11 +++
 lib/mbedtls/external/mbedtls/library/pkcs7.c  | 19 ++-
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/lib/mbedtls/external/mbedtls/include/mbedtls/oid.h 
b/lib/mbedtls/external/mbedtls/include/mbedtls/oid.h
index 2ee982808f..43cef99f1e 100644
--- a/lib/mbedtls/external/mbedtls/include/mbedtls/oid.h
+++ b/lib/mbedtls/external/mbedtls/include/mbedtls/oid.h
@@ -238,6 +238,11 @@
 #define MBEDTLS_OID_RSA_SHA_OBS "\x2B\x0E\x03\x02\x1D"
 
 #define MBEDTLS_OID_PKCS9_EMAIL MBEDTLS_OID_PKCS9 "\x01" /**< 
emailAddress AttributeType ::= { pkcs-9 1 } */
+#define MBEDTLS_OID_PKCS9_CONTENTTYPE   MBEDTLS_OID_PKCS9 "\x03" /**< 
contentType AttributeType ::= { pkcs-9 3 } */
+#define MBEDTLS_OID_PKCS9_MESSAGEDIGEST MBEDTLS_OID_PKCS9 "\x04" /**< 
messageDigest AttributeType ::= { pkcs-9 4 } */
+#define MBEDTLS_OID_PKCS9_SIGNINGTIME   MBEDTLS_OID_PKCS9 "\x05" /**< 
signingTime AttributeType ::= { pkcs-9 5 } */
+#define MBEDTLS_OID_PKCS9_SMIMECAP  MBEDTLS_OID_PKCS9 "\x0f" /**< 
smimeCapabilites AttributeType ::= { pkcs-9 15 } */
+#define MBEDTLS_OID_PKCS9_SMIMEAA   MBEDTLS_OID_PKCS9 "\x10\x02\x0b" /**< 
smimeCapabilites AttributeType ::= { pkcs-9 16 2 11} */
 
 /* RFC 4055 */
 #define MBEDTLS_OID_RSASSA_PSS  MBEDTLS_OID_PKCS1 "\x0a" /**< 
id-RSASSA-PSS ::= { pkcs-1 10 } */
diff --git a/lib/mbedtls/external/mbedtls/include/mbedtls/pkcs7.h 
b/lib/mbedtls/external/mbedtls/include/mbedtls/pkcs7.h
index 9e29b74af7..a88a5e858f 100644
--- a/lib/mbedtls/external/mbedtls/include/mbedtls/pkcs7.h
+++ b/lib/mbedtls/external/mbedtls/include/mbedtls/pkcs7.h
@@ -102,6 +102,16 @@ typedef enum {
 }
 mbedtls_pkcs7_type;
 
+/*
+ * Authenticate Attributes for MicroSoft Authentication Code using in U-Boot
+ * Secure Boot
+ */
+typedef struct mbedtls_pkcs7_authattrs {
+size_t data_len;
+void *data;
+}
+mbedtls_pkcs7_authattrs;
+
 /**
  * Structure holding PKCS #7 signer info
  */
@@ -113,6 +123,7 @@ typedef struct mbedtls_pkcs7_signer_info {
 mbedtls_x509_buf MBEDTLS_PRIVATE(alg_identifier);
 mbedtls_x509_buf MBEDTLS_PRIVATE(sig_alg_identifier);
 mbedtls_x509_buf MBEDTLS_PRIVATE(sig);
+mbedtls_pkcs7_authattrs authattrs;
 struct mbedtls_pkcs7_signer_info *MBEDTLS_PRIVATE(next);
 }
 mbedtls_pkcs7_signer_info;
diff --git a/lib/mbedtls/external/mbedtls/library/pkcs7.c 
b/lib/mbedtls/external/mbedtls/library/pkcs7.c
index 0c2436b56b..da73fb341d 100644
--- a/lib/mbedtls/external/mbedtls/library/pkcs7.c
+++ b/lib/mbedtls/external/mbedtls/library/pkcs7.c
@@ -288,6 +288,7 @@ static int pkcs7_get_signer_info(unsigned char **p, 
unsigned char *end,
 unsigned char *end_signer, *end_issuer_and_sn;
 int asn1_ret = 0, ret = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED;
 size_t len = 0;
+unsigned char *tmp_p;
 
 asn1_ret = mbedtls_asn1_get_tag(p, end, &len, MBEDTLS_ASN1_CONSTRUCTED
 | MBEDTLS_ASN1_SEQUENCE);
@@ -349,7 +350,23 @@ static int pkcs7_get_signer_info(unsigned char **p, 
unsigned char *end,
 goto out;
 }
 
-/* Assume authenticatedAttributes is nonexistent */
+/* Save authenticatedAttributes if present */
+if (*p < end_signer &&
+**p == (MBEDTLS_ASN1_CONTEXT_SPECIFIC | MBEDTLS_ASN1_CONSTRUCTED | 0)) 
{
+tmp_p = *p;
+
+ret = mbedtls_asn1_get_tag(p, end_signer, &len,
+   MBEDTLS_ASN1_CONTEXT_SPECIFIC |
+   MBEDTLS_ASN1_CONSTRUCTED | 0);
+if (ret != 0) {
+goto out;
+}
+
+signer->authattrs.data = tmp_p;
+signer->authattrs.data_len = len + *p - tmp_p;
+*p += len;
+}
+
 ret = pkcs7_get_digest_algorithm(p, end_signer, 
&signer->sig_alg_identifier);
 if (ret != 0) {
 goto out;
-- 
2.25.1



[PATCH 12/23] image: switch sha256 to mbedtls

2024-04-16 Thread Raymond Mao
When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from
hash shim layer instead.

Signed-off-by: Raymond Mao 
---
 boot/image-pre-load.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/boot/image-pre-load.c b/boot/image-pre-load.c
index b504ab42a5..85d5ff3ab7 100644
--- a/boot/image-pre-load.c
+++ b/boot/image-pre-load.c
@@ -8,8 +8,11 @@
 DECLARE_GLOBAL_DATA_PTR;
 #include 
 #include 
-
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO)
+#include 
+#else
 #include 
+#endif
 
 /*
  * Offset of the image
@@ -240,8 +243,13 @@ static int image_pre_load_sig_check_img_sig_sha256(struct 
image_sig_info *info,
goto out_sig_header;
}
 
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO)
+   sha256_csum_wd_mb(header + offset_img_sig, info->sig_size,
+ sha256_img_sig, CHUNKSZ_SHA256);
+#else
sha256_csum_wd(header + offset_img_sig, info->sig_size,
   sha256_img_sig, CHUNKSZ_SHA256);
+#endif
 
ret = memcmp(sig_header->sha256_img_sig, sha256_img_sig, 
SHA256_SUM_LEN);
if (ret) {
-- 
2.25.1



[PATCH 13/23] mbedtls/external: support MicroSoft Authentication Code

2024-04-16 Thread Raymond Mao
Populate MicroSoft Authentication Code from the content data
into PKCS7 decoding context if it exists in a PKCS7 message.
Add OIDs for describing objects using for MicroSoft Authentication
Code.

Signed-off-by: Raymond Mao 
---
 .../external/mbedtls/include/mbedtls/oid.h| 30 ++
 .../external/mbedtls/include/mbedtls/pkcs7.h  | 10 
 lib/mbedtls/external/mbedtls/library/pkcs7.c  | 60 +++
 3 files changed, 90 insertions(+), 10 deletions(-)

diff --git a/lib/mbedtls/external/mbedtls/include/mbedtls/oid.h 
b/lib/mbedtls/external/mbedtls/include/mbedtls/oid.h
index fdc25ebf88..2ee982808f 100644
--- a/lib/mbedtls/external/mbedtls/include/mbedtls/oid.h
+++ b/lib/mbedtls/external/mbedtls/include/mbedtls/oid.h
@@ -352,6 +352,36 @@
 #define MBEDTLS_OID_PKCS12_PBE_SHA1_RC2_128_CBC MBEDTLS_OID_PKCS12_PBE 
"\x05" /**< pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5} 
*/
 #define MBEDTLS_OID_PKCS12_PBE_SHA1_RC2_40_CBC  MBEDTLS_OID_PKCS12_PBE 
"\x06" /**< pbeWithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6} */
 
+/*
+ * MicroSoft Authenticate Code OIDs
+ */
+#define MBEDTLS_OID_PRIVATE_ENTERPRISE  MBEDTLS_OID_INTERNET 
"\x04\x01" /* {iso(1) identified-organization(3) dod(6) internet(1) private(4) 
enterprise(1) */
+#define MBEDTLS_OID_MICROSOFT   "\x82\x37"  /* 
{microsoft(311)} */
+/*
+ * OID_msIndirectData: (1.3.6.1.4.1.311.2.1.4)
+ * {iso(1) identified-organization(3) dod(6) internet(1) private(4) 
enterprise(1) microsoft(311) 2(2) 1(1) 4(4)}
+ */
+#define MBEDTLS_OID_MICROSOFT_INDIRECTDATA  MBEDTLS_OID_PRIVATE_ENTERPRISE 
MBEDTLS_OID_MICROSOFT \
+"\x02\x01\x04"
+/*
+ * OID_msStatementType: (1.3.6.1.4.1.311.2.1.11)
+ * {iso(1) identified-organization(3) dod(6) internet(1) private(4) 
enterprise(1) microsoft(311) 2(2) 1(1) 11(11)}
+ */
+#define MBEDTLS_OID_MICROSOFT_STATETYPE  MBEDTLS_OID_PRIVATE_ENTERPRISE 
MBEDTLS_OID_MICROSOFT \
+"\x02\x01\x0b"
+/*
+ * OID_msSpOpusInfo: (1.3.6.1.4.1.311.2.1.12)
+ * {iso(1) identified-organization(3) dod(6) internet(1) private(4) 
enterprise(1) microsoft(311) 2(2) 1(1) 12(12)}
+ */
+#define MBEDTLS_OID_MICROSOFT_SPOPUSINFO  MBEDTLS_OID_PRIVATE_ENTERPRISE 
MBEDTLS_OID_MICROSOFT \
+"\x02\x01\x0b"
+/*
+ * OID_msPeImageDataObjId: (1.3.6.1.4.1.311.2.1.15)
+ * {iso(1) identified-organization(3) dod(6) internet(1) private(4) 
enterprise(1) microsoft(311) 2(2) 1(1) 15(15)}
+ */
+#define MBEDTLS_OID_MICROSOFT_PEIMAGEDATA  MBEDTLS_OID_PRIVATE_ENTERPRISE 
MBEDTLS_OID_MICROSOFT \
+"\x02\x01\x0f"
+
 /*
  * EC key algorithms from RFC 5480
  */
diff --git a/lib/mbedtls/external/mbedtls/include/mbedtls/pkcs7.h 
b/lib/mbedtls/external/mbedtls/include/mbedtls/pkcs7.h
index e9b482208e..9e29b74af7 100644
--- a/lib/mbedtls/external/mbedtls/include/mbedtls/pkcs7.h
+++ b/lib/mbedtls/external/mbedtls/include/mbedtls/pkcs7.h
@@ -132,12 +132,22 @@ typedef struct mbedtls_pkcs7_signed_data {
 }
 mbedtls_pkcs7_signed_data;
 
+/* Content Data for MicroSoft Authentication Code using in U-Boot Secure Boot 
*/
+typedef struct mbedtls_pkcs7_conten_data {
+int data_type;  /* Type of Data */
+size_t data_len;/* Length of Data */
+size_t data_hdrlen; /* Length of Data ASN.1 header */
+void *data; /* Content Data */
+}
+mbedtls_pkcs7_conten_data;
+
 /**
  * Structure holding PKCS #7 structure, only signed data for now
  */
 typedef struct mbedtls_pkcs7 {
 mbedtls_pkcs7_buf MBEDTLS_PRIVATE(raw);
 mbedtls_pkcs7_signed_data MBEDTLS_PRIVATE(signed_data);
+mbedtls_pkcs7_conten_data content_data;
 }
 mbedtls_pkcs7;
 
diff --git a/lib/mbedtls/external/mbedtls/library/pkcs7.c 
b/lib/mbedtls/external/mbedtls/library/pkcs7.c
index 3aac662ba6..0c2436b56b 100644
--- a/lib/mbedtls/external/mbedtls/library/pkcs7.c
+++ b/lib/mbedtls/external/mbedtls/library/pkcs7.c
@@ -29,6 +29,13 @@
 #include 
 #endif
 
+enum OID {
+/* PKCS#7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-7(7)} 
*/
+MBEDTLS_OID_DATA = 13,  /* 1.2.840.113549.1.7.1 */
+/* Microsoft Authenticode & Software Publishing */
+MBEDTLS_OID_MS_INDIRECTDATA = 24,/* 1.3.6.1.4.1.311.2.1.4 */
+};
+
 /**
  * Initializes the mbedtls_pkcs7 structure.
  */
@@ -449,7 +456,7 @@ cleanup:
  *  signerInfos SignerInfos }
  */
 static int pkcs7_get_signed_data(unsigned char *buf, size_t buflen,
- mbedtls_pkcs7_signed_data *signed_data)
+ mbedtls_pkcs7 *pkcs7)
 {
 unsigned char *p = buf;
 unsigned char *end = buf + buflen;
@@ -457,6 +464,7 @@ static int pkcs7_get_signed_data(unsigned char *buf, size_t 
buflen,
 size_t len = 0;
 int ret = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED;
 mbedtls_md_type_t md_alg;
+mbedtls_pkcs7_signed_data *signed_data = &pkcs7->signed_data;
 
 ret = mbedtls_asn1_get_tag(&p, end, &len, MBEDTLS_ASN1_CONSTRUCTED
| MBEDTLS_ASN1_SEQUENCE);
@@ -493,25 +501,5

[PATCH 10/23] makefile: add mbedtls include directories

2024-04-16 Thread Raymond Mao
Add the mbedtls include directories into the build system.

Signed-off-by: Raymond Mao 
---
 Makefile | 13 +
 1 file changed, 13 insertions(+)

diff --git a/Makefile b/Makefile
index 7321fe1499..80db1dfd8e 100644
--- a/Makefile
+++ b/Makefile
@@ -829,6 +829,12 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
 UBOOTINCLUDE:= \
-Iinclude \
$(if $(KBUILD_SRC), -I$(srctree)/include) \
+   $(if $(KBUILD_SRC), \
+   $(if $(CONFIG_MBEDTLS_LIB), \
+   "-DMBEDTLS_CONFIG_FILE=\"mbedtls_def_config.h\"" \
+   -I$(srctree)/lib/mbedtls \
+   -I$(srctree)/lib/mbedtls/port \
+   -I$(srctree)/lib/mbedtls/external/mbedtls/include)) \
$(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \
$(if $(CONFIG_HAS_THUMB2), \
$(if $(CONFIG_CPU_V7M), \
@@ -840,6 +846,13 @@ UBOOTINCLUDE:= \
 
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 
+ifeq ($(CONFIG_MBEDTLS_LIB),y)
+PLATFORM_CPPFLAGS += "-DMBEDTLS_CONFIG_FILE=\"mbedtls_def_config.h\"" \
+   -I$(srctree)/lib/mbedtls \
+   -I$(srctree)/lib/mbedtls/port \
+   -I$(srctree)/lib/mbedtls/external/mbedtls/include
+endif
+
 # FIX ME
 cpp_flags := $(KBUILD_CPPFLAGS) $(PLATFORM_CPPFLAGS) $(UBOOTINCLUDE) \
$(NOSTDINC_FLAGS)
-- 
2.25.1



[PATCH 11/23] efi_loader: switch sha256 to mbedtls

2024-04-16 Thread Raymond Mao
When MBEDTLS_LIB_CRYPTO is enabled, use the APIs of sha256 from
hash shim layer instead.

Signed-off-by: Raymond Mao 
---
 lib/efi_loader/efi_tcg2.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index ac056dcfc5..3c356abc6e 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1321,12 +1321,21 @@ efi_status_t efi_tcg2_measure_dtb(void *dtb)
 
/* Measure populated areas of the DTB */
header = dtb;
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO)
+   sha256_starts_mb(&hash_ctx);
+   sha256_update_mb(&hash_ctx, (u8 *)header, sizeof(struct fdt_header));
+   sha256_update_mb(&hash_ctx, (u8 *)dtb + fdt_off_dt_struct(dtb), 
fdt_size_dt_strings(dtb));
+   sha256_update_mb(&hash_ctx, (u8 *)dtb + fdt_off_dt_strings(dtb), 
fdt_size_dt_struct(dtb));
+   sha256_update_mb(&hash_ctx, (u8 *)dtb + fdt_off_mem_rsvmap(dtb), 
rsvmap_size);
+   sha256_finish_mb(&hash_ctx, blob->data + blob->blob_description_size);
+#else
sha256_starts(&hash_ctx);
sha256_update(&hash_ctx, (u8 *)header, sizeof(struct fdt_header));
sha256_update(&hash_ctx, (u8 *)dtb + fdt_off_dt_struct(dtb), 
fdt_size_dt_strings(dtb));
sha256_update(&hash_ctx, (u8 *)dtb + fdt_off_dt_strings(dtb), 
fdt_size_dt_struct(dtb));
sha256_update(&hash_ctx, (u8 *)dtb + fdt_off_mem_rsvmap(dtb), 
rsvmap_size);
sha256_finish(&hash_ctx, blob->data + blob->blob_description_size);
+#endif
 
ret = measure_event(dev, 0, EV_POST_CODE, event_size, (u8 *)blob);
 
-- 
2.25.1



[PATCH 09/23] hash: integrate hash on mbedtls

2024-04-16 Thread Raymond Mao
Integrate common/hash.c on the hash shim layer so that hash APIs
from mbedtls can be leveraged by boot/image and efi_loader.

Signed-off-by: Raymond Mao 
---
 common/hash.c  | 161 +
 include/u-boot/hash-checksum.h |   6 ++
 2 files changed, 167 insertions(+)

diff --git a/common/hash.c b/common/hash.c
index 3d6b84de47..5352ba88e3 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -31,10 +31,143 @@
 #include 
 #include 
 #include 
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO)
+#include 
+#include 
+#include 
+#include 
+#else
 #include 
 #include 
 #include 
 #include 
+#endif
+
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO)
+
+static int hash_init_sha1(struct hash_algo *algo, void **ctxp)
+{
+   int ret;
+   mbedtls_sha1_context *ctx = malloc(sizeof(mbedtls_sha1_context));
+
+   mbedtls_sha1_init(ctx);
+   ret = mbedtls_sha1_starts(ctx);
+   if (!ret) {
+   *ctxp = ctx;
+   } else {
+   mbedtls_sha1_free(ctx);
+   free(ctx);
+   }
+
+   return ret;
+}
+
+static int hash_update_sha1(struct hash_algo *algo, void *ctx, const void *buf,
+   unsigned int size, int is_last)
+{
+   return mbedtls_sha1_update((mbedtls_sha1_context *)ctx, buf, size);
+}
+
+static int
+hash_finish_sha1(struct hash_algo *algo, void *ctx, void *dest_buf, int size)
+{
+   int ret;
+
+   if (size < algo->digest_size)
+   return -1;
+
+   ret = mbedtls_sha1_finish((mbedtls_sha1_context *)ctx, dest_buf);
+   if (!ret) {
+   mbedtls_sha1_free((mbedtls_sha1_context *)ctx);
+   free(ctx);
+   }
+
+   return ret;
+}
+
+static int hash_init_sha256(struct hash_algo *algo, void **ctxp)
+{
+   int ret;
+   int is224 = algo->digest_size == SHA224_SUM_LEN ? 1 : 0;
+   mbedtls_sha256_context *ctx = malloc(sizeof(mbedtls_sha256_context));
+
+   mbedtls_sha256_init(ctx);
+   ret = mbedtls_sha256_starts(ctx, is224);
+   if (!ret) {
+   *ctxp = ctx;
+   } else {
+   mbedtls_sha256_free(ctx);
+   free(ctx);
+   }
+
+   return ret;
+}
+
+static int hash_update_sha256(struct hash_algo *algo, void *ctx, const void 
*buf,
+ uint size, int is_last)
+{
+   return mbedtls_sha256_update((mbedtls_sha256_context *)ctx, buf, size);
+}
+
+static int
+hash_finish_sha256(struct hash_algo *algo, void *ctx, void *dest_buf, int size)
+{
+   int ret;
+
+   if (size < algo->digest_size)
+   return -1;
+
+   ret = mbedtls_sha256_finish((mbedtls_sha256_context *)ctx, dest_buf);
+   if (!ret) {
+   mbedtls_sha256_free((mbedtls_sha256_context *)ctx);
+   free(ctx);
+   }
+
+   return ret;
+}
+
+static int hash_init_sha512(struct hash_algo *algo, void **ctxp)
+{
+   int ret;
+   int is384 = algo->digest_size == SHA384_SUM_LEN ? 1 : 0;
+   mbedtls_sha512_context *ctx = malloc(sizeof(mbedtls_sha512_context));
+
+   mbedtls_sha512_init(ctx);
+   ret = mbedtls_sha512_starts(ctx, is384);
+   if (!ret) {
+   *ctxp = ctx;
+   } else {
+   mbedtls_sha512_free(ctx);
+   free(ctx);
+   }
+
+   return ret;
+}
+
+static int hash_update_sha512(struct hash_algo *algo, void *ctx, const void 
*buf,
+ uint size, int is_last)
+{
+   return mbedtls_sha512_update((mbedtls_sha512_context *)ctx, buf, size);
+}
+
+static int
+hash_finish_sha512(struct hash_algo *algo, void *ctx, void *dest_buf, int size)
+{
+   int ret;
+
+   if (size < algo->digest_size)
+   return -1;
+
+   ret = mbedtls_sha512_finish((mbedtls_sha512_context *)ctx, dest_buf);
+   if (!ret) {
+   mbedtls_sha512_free((mbedtls_sha512_context *)ctx);
+   free(ctx);
+   }
+
+   return ret;
+}
+
+#else /* CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO) */
 
 static int __maybe_unused hash_init_sha1(struct hash_algo *algo, void **ctxp)
 {
@@ -144,6 +277,8 @@ static int __maybe_unused hash_finish_sha512(struct 
hash_algo *algo, void *ctx,
return 0;
 }
 
+#endif /* CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO) */
+
 static int hash_init_crc16_ccitt(struct hash_algo *algo, void **ctxp)
 {
uint16_t *ctx = malloc(sizeof(uint16_t));
@@ -209,7 +344,11 @@ static struct hash_algo hash_algo[] = {
.name   = "md5",
.digest_size= MD5_SUM_LEN,
.chunk_size = CHUNKSZ_MD5,
+#if CONFIG_IS_ENABLED(MBEDTLS_LIB_CRYPTO)
+   .hash_func_ws   = md5_wd_mb,
+#else
.hash_func_ws   = md5_wd,
+#endif
},
 #endif
 #if CONFIG_IS_ENABLED(SHA1)
@@ -219,9 +358,13 @@ static struct hash_algo hash_algo[] = {
.chunk_size = CHUNKSZ_SHA1,
 #if CONFIG_IS_ENABLED(SHA_HW_ACCEL)
.hash_func_ws   = hw_sha1,
+#else
+#if CONFIG_IS_ENABLED(MBE

[PATCH 08/23] mbedtls: add hash shim layer

2024-04-16 Thread Raymond Mao
Create a hash shim layer on top of mbedtls crypto library.

Signed-off-by: Raymond Mao 
---
 include/mbedtls/md5.h|  18 ++
 include/mbedtls/sha1.h   |  27 +
 include/mbedtls/sha256.h |  31 ++
 include/mbedtls/sha512.h |  39 +
 lib/mbedtls/Makefile |   3 +
 lib/mbedtls/hash_shim.c  | 118 +++
 6 files changed, 236 insertions(+)
 create mode 100644 include/mbedtls/md5.h
 create mode 100644 include/mbedtls/sha1.h
 create mode 100644 include/mbedtls/sha256.h
 create mode 100644 include/mbedtls/sha512.h
 create mode 100644 lib/mbedtls/hash_shim.c

diff --git a/include/mbedtls/md5.h b/include/mbedtls/md5.h
new file mode 100644
index 00..e5a205efda
--- /dev/null
+++ b/include/mbedtls/md5.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 Linaro Limited
+ * Author: Raymond Mao 
+ */
+#include 
+
+#ifndef _MBEDTLS_MD5_H
+#define _MBEDTLS_MD5_H
+
+#define MD5_SUM_LEN16
+
+void
+md5_wd_mb(const unsigned char *input, unsigned int len,
+ unsigned char output[16],
+ unsigned int __always_unused chunk_sz);
+
+#endif /* _MBEDTLS_MD5_H */
diff --git a/include/mbedtls/sha1.h b/include/mbedtls/sha1.h
new file mode 100644
index 00..f7aff6f652
--- /dev/null
+++ b/include/mbedtls/sha1.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 Linaro Limited
+ * Author: Raymond Mao 
+ */
+#include 
+
+#ifndef _MBEDTLS_SHA1_H
+#define _MBEDTLS_SHA1_H
+
+#define SHA1_SUM_LEN   20
+#define SHA1_DER_LEN   15
+
+#define CHUNKSZ_SHA1   (64 * 1024)
+
+extern const u8 sha1_der_prefix[];
+
+typedef mbedtls_sha1_context sha1_context;
+
+void sha1_starts_mb(sha1_context *ctx);
+void sha1_update_mb(sha1_context *ctx, const unsigned char *input,
+   unsigned int length);
+void sha1_finish_mb(sha1_context *ctx, unsigned char output[SHA1_SUM_LEN]);
+void sha1_csum_wd_mb(const unsigned char *input, unsigned int length,
+unsigned char *output, unsigned int chunk_sz);
+
+#endif /* _MBEDTLS_SHA1_H */
diff --git a/include/mbedtls/sha256.h b/include/mbedtls/sha256.h
new file mode 100644
index 00..804f2ce8ab
--- /dev/null
+++ b/include/mbedtls/sha256.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 Linaro Limited
+ * Author: Raymond Mao 
+ */
+#include 
+
+#ifndef _MBEDTLS_SHA256_H
+#define _MBEDTLS_SHA256_H
+
+#define SHA224_SUM_LEN 28
+#define SHA256_SUM_LEN 32
+
+#define SHA224_DER_LEN 19
+#define SHA256_DER_LEN 19
+
+#define CHUNKSZ_SHA224 (64 * 1024)
+#define CHUNKSZ_SHA256 (64 * 1024)
+
+extern const u8 sha256_der_prefix[];
+
+typedef mbedtls_sha256_context sha256_context;
+
+void sha256_starts_mb(sha256_context *ctx);
+void
+sha256_update_mb(sha256_context *ctx, const uint8_t *input, uint32_t length);
+void sha256_finish_mb(sha256_context *ctx, uint8_t digest[SHA256_SUM_LEN]);
+void sha256_csum_wd_mb(const unsigned char *input, unsigned int length,
+  unsigned char *output, unsigned int chunk_sz);
+
+#endif /* _MBEDTLS_SHA256_H */
diff --git a/include/mbedtls/sha512.h b/include/mbedtls/sha512.h
new file mode 100644
index 00..bc7f2faa0d
--- /dev/null
+++ b/include/mbedtls/sha512.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 Linaro Limited
+ * Author: Raymond Mao 
+ */
+#include 
+
+#ifndef _MBEDTLS_SHA512_H
+#define _MBEDTLS_SHA512_H
+
+#define SHA384_SUM_LEN 48
+#define SHA512_SUM_LEN 64
+
+#define SHA384_DER_LEN 19
+#define SHA512_DER_LEN 19
+
+#define CHUNKSZ_SHA384 (16 * 1024)
+#define CHUNKSZ_SHA512 (16 * 1024)
+
+extern const u8 sha384_der_prefix[];
+extern const u8 sha512_der_prefix[];
+
+typedef mbedtls_sha512_context sha384_context;
+typedef mbedtls_sha512_context sha512_context;
+
+void sha384_starts_mb(sha512_context *ctx);
+void
+sha384_update_mb(sha512_context *ctx, const uint8_t *input, uint32_t length);
+void sha384_finish_mb(sha512_context *ctx, uint8_t digest[SHA384_SUM_LEN]);
+void sha384_csum_wd_mb(const unsigned char *input, unsigned int length,
+  unsigned char *output, unsigned int chunk_sz);
+void sha512_starts_mb(sha512_context *ctx);
+void
+sha512_update_mb(sha512_context *ctx, const uint8_t *input, uint32_t length);
+void sha512_finish_mb(sha512_context *ctx, uint8_t digest[SHA512_SUM_LEN]);
+void sha512_csum_wd_mb(const unsigned char *input, unsigned int length,
+  unsigned char *output, unsigned int chunk_sz);
+
+#endif /* _MBEDTLS_SHA512_H */
diff --git a/lib/mbedtls/Makefile b/lib/mbedtls/Makefile
index 85f0a3cfd0..5d41ddbd8d 100644
--- a/lib/mbedtls/Makefile
+++ b/lib/mbedtls/Makefile
@@ -14,6 +14,9 @@ ccflags-y += \
-I$(src)/external/mbedtls/library \
# This line is intentionally left blank
 
+# shim layer for hash
+obj-$(CONFIG_MBEDTLS_LIB_CRYPTO) += hash_shim.o
+
 obj-$(CONFIG_MBEDTLS_LIB_CRYPTO) += mbedtls_lib_crypto.o
 mbedtls_lib_cry

[PATCH 05/23] test: py: add sudo for virt-make-fs

2024-04-16 Thread Raymond Mao
Fix a permission issue when running virt-make-fs

Signed-off-by: Raymond Mao 
---
 test/py/tests/test_efi_secboot/conftest.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/py/tests/test_efi_secboot/conftest.py 
b/test/py/tests/test_efi_secboot/conftest.py
index ff7ac7c810..30357913f0 100644
--- a/test/py/tests/test_efi_secboot/conftest.py
+++ b/test/py/tests/test_efi_secboot/conftest.py
@@ -113,7 +113,7 @@ def efi_boot_env(request, u_boot_config):
% (mnt_point, EFITOOLS_PATH),
shell=True)
 
-check_call('virt-make-fs --partition=gpt --size=+1M --type=vfat {} 
{}'.format(
+check_call('sudo virt-make-fs --partition=gpt --size=+1M --type=vfat 
{} {}'.format(
 mnt_point, image_path), shell=True)
 check_call('rm -rf {}'.format(mnt_point), shell=True)
 
@@ -232,7 +232,7 @@ def efi_boot_env_intca(request, u_boot_config):
 check_call('cd %s; cat TestSub.crt TestRoot.crt > TestSubRoot.crt; 
%ssbsign --key TestCert.key --cert TestCert.crt --addcert TestSubRoot.crt --out 
helloworld.efi.signed_abc helloworld.efi'
% (mnt_point, SBSIGN_PATH), shell=True)
 
-check_call('virt-make-fs --partition=gpt --size=+1M --type=vfat {} 
{}'.format(mnt_point, image_path), shell=True)
+check_call('sudo virt-make-fs --partition=gpt --size=+1M --type=vfat 
{} {}'.format(mnt_point, image_path), shell=True)
 check_call('rm -rf {}'.format(mnt_point), shell=True)
 
 except CalledProcessError as e:
-- 
2.25.1



[PATCH 07/23] efi_loader: remove redundant hash includes

2024-04-16 Thread Raymond Mao
Remove the redundant includes of u-boot/sha1.h, u-boot/sha256.h
and u-boot/sha512.h

Signed-off-by: Raymond Mao 
---
 lib/efi_loader/efi_signature.c | 1 -
 lib/efi_loader/efi_tcg2.c  | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c
index f338e73275..184eac8cdd 100644
--- a/lib/efi_loader/efi_signature.c
+++ b/lib/efi_loader/efi_signature.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 
 const efi_guid_t efi_guid_sha256 = EFI_CERT_SHA256_GUID;
 const efi_guid_t efi_guid_cert_rsa2048 = EFI_CERT_RSA2048_GUID;
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index b07e0099c2..ac056dcfc5 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -19,9 +19,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-- 
2.25.1



[PATCH 04/23] arm: EFI linker script text section alignment

2024-04-16 Thread Raymond Mao
Add text section alignment to fix sbsign signing warning
'gaps in the section table may result in different checksums'
which causes a failure of efi_image_verify_diges()

Signed-off-by: Raymond Mao 
---
 arch/arm/lib/elf_aarch64_efi.lds | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/lib/elf_aarch64_efi.lds b/arch/arm/lib/elf_aarch64_efi.lds
index 5dd9809169..bffd9a0447 100644
--- a/arch/arm/lib/elf_aarch64_efi.lds
+++ b/arch/arm/lib/elf_aarch64_efi.lds
@@ -28,6 +28,7 @@ SECTIONS
*(.dynamic);
. = ALIGN(512);
}
+   . = ALIGN(4096);
.rela.dyn : { *(.rela.dyn) }
.rela.plt : { *(.rela.plt) }
.rela.got : { *(.rela.got) }
-- 
2.25.1



[PATCH 06/23] image: remove redundant hash includes

2024-04-16 Thread Raymond Mao
Remove the redundant includes of u-boot/md5.h, u-boot/sha1.h,
u-boot/sha256.h and u-boot/sha512.h

Signed-off-by: Raymond Mao 
---
 boot/image-fit.c | 4 
 boot/image.c | 2 --
 2 files changed, 6 deletions(-)

diff --git a/boot/image-fit.c b/boot/image-fit.c
index 89e377563c..1efc39f440 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -38,10 +38,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
 
 /*/
 /* New uImage format routines */
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a..e57d6eae52 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -26,8 +26,6 @@
 #endif
 
 #include 
-#include 
-#include 
 #include 
 #include 
 
-- 
2.25.1



Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 05:52:58PM +0530, Chintan Vankar wrote:
> 
> 
> On 12/04/24 03:37, Tom Rini wrote:
> > On Wed, Apr 03, 2024 at 06:18:01PM +0530, Chintan Vankar wrote:
> > > 
> > > 
> > > On 22/01/24 10:11, Siddharth Vadapalli wrote:
> > > > 
> > > > 
> > > > On 20/01/24 22:11, Tom Rini wrote:
> > > > > On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth Vadapalli wrote:
> > > > > > Hello Tom,
> > > > > > 
> > > > > > On 12/01/24 18:56, Tom Rini wrote:
> > > > 
> > > > ...
> > > > 
> > > > > > > The list of conditionals in common/spl/spl.c::board_init_r() 
> > > > > > > should be
> > > > > > > updated and probably use SPL_NET as the option to check for.
> > > > > > 
> > > > > > Thank you for reviewing the patch and pointing this out. I wasn't 
> > > > > > aware of it. I
> > > > > > assume that you are referring to the following change:
> > > > > > 
> > > > > >   if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || 
> > > > > > CONFIG_IS_ENABLED(HANDOFF) ||
> > > > > > -   IS_ENABLED(CONFIG_SPL_ATF))
> > > > > > +   IS_ENABLED(CONFIG_SPL_ATF) || 
> > > > > > IS_ENABLED(CONFIG_SPL_NET))
> > > > > >   dram_init_banksize();
> > > > > > 
> > > > > > I shall replace the current patch with the above change in the v2 
> > > > > > series. Since
> > > > > > this is in the common section, is there a generic reason I could 
> > > > > > provide in the
> > > > > > commit message rather than the existing commit message which seems 
> > > > > > to be board
> > > > > > specific? Also, I hope that the above change will not cause 
> > > > > > regressions for
> > > > > > other non-TI devices. Please let me know.
> > > > > 
> > > > > Yes, that's the area, and just note that networking also requires the
> > > > > DDR to be initialized.
> > > > > 
> > > > 
> > > > Thank you for confirming and providing your suggestion for the contents 
> > > > of the
> > > > commit message.
> > > > 
> > > Following Tom's Suggestion of adding CONFIG_SPL_NET in common/spl/spl.c
> > > "dram_init_banksize()", the issue of fetching a file at SPL stage seemed
> > > to be fixed. However the commit "ba20b2443c29", which sets gd->ram_top
> > > for the very first time in "spl_enable_cache()" results in
> > > "arch_lmb_reserve()" function reserving memory region from Stack pointer
> > > at "0x81FFB820" to gd->ram_top pointing to "0x1". Previously
> > > when gd->ram_top was zero "arch_lmb_reserve()" was noop. Now using TFTP
> > > to fetch U-Boot image at SPL stage results in "tftp_init_load_addr()"
> > > function call that invokes "arch_lmb_reserve()" function, which reserves
> > > entire memory starting from Stack Pointer to gd->ram_top leaving no
> > > space to load U-Boot image via TFTP since TFTP loads files at pre
> > > configured memory address at "0x8200".
> > > 
> > > As a workaround for this issue, one solution we can propose is to
> > > disable the checks "lmb_get_free_size()" at SPL and U-Boot stage. For
> > > that we can define a new config option for LMB reserve checks as
> > > "SPL_LMB". This config will be enable by default for the backword
> > > compatibility and disable for our use case at SPL and U-Boot stage.
> > 
> > The problem here is that we need LMB for booting an OS, which is
> > something we'll want in SPL in non-cortex-R cases too, which means this
> > platform, so that's a no-go. I think you need to dig harder and see if
> > you can correct the logic somewhere so that we don't over reserve?
> > 
> Since this issue is due to function call "lmb_init_and_reserve()"
> function invoked from "tftp_init_load_addr()" function. This function
> is defined by Simon in commit "a156c47e39ad", which fixes
> "CVE-2018-18439" to prevent overwriting reserved memory. Simon, can you
> explain why do we need to call "lmb_init_and_reserve()" function here ?

This is indeed a tricky area which is why Sughosh is looking in to
trying to re-work the LMB mechanic and we've had a few long threads
about it as well.

I've honestly forgotten the use case you have here, can you please
remind us?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/4] Kconfig: Make all Kconfig encoding ascii

2024-04-16 Thread Dragan Simic

On 2024-04-16 16:51, Francesco Dolcini wrote:

On Tue, Apr 16, 2024 at 03:18:08PM +0200, Dragan Simic wrote:

On 2024-04-16 08:59, Francesco Dolcini wrote:
> On Tue, Apr 16, 2024 at 02:36:12AM +0200, Tom Rini wrote:
> > On Mon, Apr 15, 2024 at 02:22:02PM +0200, Heinrich Schuchardt wrote:
> > > C is the sign for coulomb which is the unit of electric charge. How
> > > about 'deg C'?
> >
> > I'll note that in Linux there's seemingly nothing consistent, and I'm
> > fine with any of "deg C" or "degrees C" or "temperature range (-40 C to
> > +85 C)" as all of those should be clear in context.
>
> My 2 cents ... while I agree with Tom that the context will make it
> clear, it is not making it correct nor nice. Using just "C" for Celsius
> degrees is horrible ...

FWIW, I usually use "oC", which is far from perfect, but IMHO also
far from horrible. :)


"oC" is also horrible, "deg C" or "degrees C" that Heinrich proposed 
are the

way to go if you need something 7-bit ascii :-).


I agree, "deg C" or "degrees C" is the way to go, and my vote goes to
"degrees C".  Just to clarify, I use "oC" as some kind of a shorthand
when having less to type outweighs the correctness. :)


Re: [PATCH v2 5/5] common: Convert *.c/h from UTF-8 to ASCII enconfing

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 06:19:48PM +0200, Heinrich Schuchardt wrote:
> On 16.04.24 18:06, Tom Rini wrote:
> > On Tue, Apr 16, 2024 at 08:55:19AM +0200, Michal Simek wrote:
> > 
> > > Convert UTF-8 chars to ASCII in cases where make sense. No Copyright or
> > > names are converted.
> > > 
> > > Signed-off-by: Michal Simek 
> > > 
> > 
> > Reviewed-by: Tom Rini 
> > 
> > Now, how did you test / find these? Given names a CI test is unlikely
> > to be doable but if it's otherwise scriptable I can put it in my loops
> > and just fixup as needed (like I do today for adding  for
> > example).
> > 
> 
> There seem no to be too many non-ASCI strings outside of comments.
> Should we care about non-ASCII comments?
> 
> $ find . -name '*.h' -exec grep -P -Hn "[^\x00-\x7F]" {} \; | grep -v
> ':\s*[\/\*']
> ./include/configs/tec-ng.h:13:#define CFG_TEGRA_BOARD_STRING"Avionic
> Design Tamonten™ NG Evaluation Carrier"
> ./arch/mips/mach-octeon/include/mach/cvmx-pko3.h:369:   MEMALG_SUB = 9,
>  /* mem = mem – PKO_SEND_MEM_S[OFFSET] */
> 
> $ find . -name '*.c' -exec grep -P -Hn "[^\x00-\x7F]" {} \; | grep -v
> ':\s*[\/\*']
> ./drivers/mtd/nand/raw/nand_ids.c:65:   {"H27QCG8T2E5R‐BCF 64G 3.3V 8-bit",
> ./drivers/video/dw_mipi_dsi.c:861:MODULE_AUTHOR("Yannick Fertré
> ");
> ./board/bosch/acc/acc.c:440:.SRT = 0, // Set to 1 for temperatures
> above 85°C
> ./cmd/2048.c:65:printf("   ·   ");
> ./cmd/2048.c:79:printf("←, ↑, →, ↓ or q\n");

I think we need to keep the "2048" game ones as it's part of the reason
(can we display certain things properly) it exists but comments and
general strings should be fixed. And I think I can use the above
examples to put something in to my scripts to catch new additions.
Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] configs: am62px_evm_a53_defconfig: Enable MMC UHS config option

2024-04-16 Thread Judith Mendez

Hi all,

On 4/8/24 11:01 AM, Judith Mendez wrote:

Enable MMC UHS support for to allow to enter the UHS
modes for MMC0.



I have sent v2 for this patch since there was a typo in
the patch description.

~ Judith



Re: [PATCH v2 5/5] common: Convert *.c/h from UTF-8 to ASCII enconfing

2024-04-16 Thread Heinrich Schuchardt

On 16.04.24 18:06, Tom Rini wrote:

On Tue, Apr 16, 2024 at 08:55:19AM +0200, Michal Simek wrote:


Convert UTF-8 chars to ASCII in cases where make sense. No Copyright or
names are converted.

Signed-off-by: Michal Simek 



Reviewed-by: Tom Rini 

Now, how did you test / find these? Given names a CI test is unlikely
to be doable but if it's otherwise scriptable I can put it in my loops
and just fixup as needed (like I do today for adding  for
example).



There seem no to be too many non-ASCI strings outside of comments.
Should we care about non-ASCII comments?

$ find . -name '*.h' -exec grep -P -Hn "[^\x00-\x7F]" {} \; | grep -v
':\s*[\/\*']
./include/configs/tec-ng.h:13:#define CFG_TEGRA_BOARD_STRING"Avionic
Design Tamonten™ NG Evaluation Carrier"
./arch/mips/mach-octeon/include/mach/cvmx-pko3.h:369:   MEMALG_SUB = 9,
 /* mem = mem – PKO_SEND_MEM_S[OFFSET] */

$ find . -name '*.c' -exec grep -P -Hn "[^\x00-\x7F]" {} \; | grep -v
':\s*[\/\*']
./drivers/mtd/nand/raw/nand_ids.c:65:   {"H27QCG8T2E5R‐BCF 64G 3.3V 8-bit",
./drivers/video/dw_mipi_dsi.c:861:MODULE_AUTHOR("Yannick Fertré
");
./board/bosch/acc/acc.c:440:.SRT = 0, // Set to 1 for temperatures
above 85°C
./cmd/2048.c:65:printf("   ·   ");
./cmd/2048.c:79:printf("←, ↑, →, ↓ or q\n");

Best regards

Heinrich


[PATCH v2] configs: am62px_evm_a53_defconfig: Enable MMC UHS config option

2024-04-16 Thread Judith Mendez
Enable MMC UHS support for to allow to enter the UHS
modes for MMC1.

Signed-off-by: Judith Mendez 
---
Changes since v1:
- Fix typo in patch description
---

 configs/am62px_evm_a53_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am62px_evm_a53_defconfig b/configs/am62px_evm_a53_defconfig
index 2621abb8ce1..d1ae18bedf6 100644
--- a/configs/am62px_evm_a53_defconfig
+++ b/configs/am62px_evm_a53_defconfig
@@ -115,6 +115,8 @@ CONFIG_FS_LOADER=y
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_SPL_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_SPL_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_SPL_MMC_HS400_SUPPORT=y
 CONFIG_MMC_SDHCI=y

base-commit: bc39e06778168a34bb4e0a34fbee4edbde4414d8
-- 
2.43.2



Re: [PATCH v2 5/5] common: Convert *.c/h from UTF-8 to ASCII enconfing

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 08:55:19AM +0200, Michal Simek wrote:

> Convert UTF-8 chars to ASCII in cases where make sense. No Copyright or
> names are converted.
> 
> Signed-off-by: Michal Simek 
> 

Reviewed-by: Tom Rini 

Now, how did you test / find these? Given names a CI test is unlikely
to be doable but if it's otherwise scriptable I can put it in my loops
and just fixup as needed (like I do today for adding  for
example).

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 4/5] Kconfig: Make all Kconfig encoding ascii

2024-04-16 Thread Tom Rini
On Tue, Apr 16, 2024 at 08:55:18AM +0200, Michal Simek wrote:

> Some of Kconfigs are using utf-8 encoding because of used chars. Convert
> all of them to ascii enconging. Based on discussion ASCII should be used in
> general with the exception of names.
> 
> Signed-off-by: Michal Simek 
> 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] event: add an event for livetree fixups

2024-04-16 Thread Tom Rini
On Mon, Apr 15, 2024 at 11:45:29AM +0100, Caleb Connolly wrote:
> 
> 
> On 12/04/2024 20:45, Tom Rini wrote:
> > On Fri, Apr 12, 2024 at 08:04:02PM +0100, Caleb Connolly wrote:
> > 
> >> Introduce a new EVT_OF_LIVE event to allow for the livetree to be
> >> modified before dm_init_and_scan(). Boards can perform fixups here to
> >> handle incompatibilities between U-Boot drivers and upstream DT.
> >>
> >> This will be used by Qualcomm platforms in future patches to enable
> >> setting the dr_mode property if the board doesn't provide one. This has to 
> >> be
> >> set before dm_init_and_scan() is called as this property effects the 
> >> binding of
> >> drivers.
> > 
> > This doesn't quite explain why the answer isn't "fix the device tree
> > source" and instead "perform a live fixup". Thanks.
> 
> Hi Tom,
> 
> I think the specifics here that make this difficult is that on some
> Qualcomm boards there is only one USB controller, which can be muxed
> either to a type-c port or to a USB hub via a DIP switch (the state of
> which cannot easily be read out).
> 
> The DT should therefore either not set dr_mode or set it to OTG. This is
> what Linux expects (and it can do proper role detection).
> 
> The dwc3 driver in U-Boot currently doesn't have the ability to
> dynamically mode switch, this is something I'd like to add (as it would
> let us easily flash these boards from U-Boot as well as boot from USB or
> ethernet), but in the mean time the only way to get these boards into
> host mode (which is the preferred default) is to modify the DT in a way
> that breaks Linux.
> 
> Hence the proposal in this patch.
> 
> If this is ok for you then I'll re-send with this additional context in
> the commit description.

So this seems even more special cased than what I was thinking it was.
Would it really be so hard to just add a dummy driver for a few
compatibles in this case? I prefer having two or three real users of a
use case before designing the abstraction for it. Thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] fs/erofs: add DEFLATE algorithm support

2024-04-16 Thread Gao Xiang
Hi Jianan,

On Sun, Apr 14, 2024 at 11:04:14PM +0800, Jianan Huang wrote:
> This patch adds DEFLATE compression algorithm support. It's a good choice
> to trade off between compression ratios and performance compared to LZ4.
> Alternatively, DEFLATE could be used for some specific files since EROFS
> supports multiple compression algorithms in one image.
> 
> Signed-off-by: Jianan Huang 

Reviewed-by: Gao Xiang 

Thanks,
Gao Xiang


Re: [PATCH 4/4] Kconfig: Make all Kconfig encoding ascii

2024-04-16 Thread Francesco Dolcini
On Tue, Apr 16, 2024 at 03:18:08PM +0200, Dragan Simic wrote:
> On 2024-04-16 08:59, Francesco Dolcini wrote:
> > On Tue, Apr 16, 2024 at 02:36:12AM +0200, Tom Rini wrote:
> > > On Mon, Apr 15, 2024 at 02:22:02PM +0200, Heinrich Schuchardt wrote:
> > > > C is the sign for coulomb which is the unit of electric charge. How
> > > > about 'deg C'?
> > > 
> > > I'll note that in Linux there's seemingly nothing consistent, and I'm
> > > fine with any of "deg C" or "degrees C" or "temperature range (-40 C to
> > > +85 C)" as all of those should be clear in context.
> > 
> > My 2 cents ... while I agree with Tom that the context will make it
> > clear, it is not making it correct nor nice. Using just "C" for Celsius
> > degrees is horrible ...
> 
> FWIW, I usually use "oC", which is far from perfect, but IMHO also
> far from horrible. :)

"oC" is also horrible, "deg C" or "degrees C" that Heinrich proposed are the
way to go if you need something 7-bit ascii :-).


Francesco



Re: [PATCH] rockchip: px30-board-tpl: Use CONFIG_TPL_BANNER_PRINT flag

2024-04-16 Thread Quentin Schulz

Hi Lukasz,

Please use scripts/get_maintainer.pl to set the Cc and To recipients of 
your mail to make sure it reaches the appropriate people explicitly.


$ scripts/get_maintainer.pl arch/arm/mach-rockchip/px30-board-tpl.c
Tom Rini  (maintainer:ARM)
Simon Glass  (maintainer:ARM ROCKCHIP)
Philipp Tomsich  (maintainer:ARM ROCKCHIP)
Kever Yang  (maintainer:ARM ROCKCHIP)
u-boot@lists.denx.de (open list)

(one can use scripts/get_maintainer.pl on patches instead of files, and 
it'll return whatever is needed).


Plugging `b4` here as well, because it's a pretty nice tool to use:
https://git.kernel.org/pub/scm/utils/b4/b4.git/ One can install it with 
pip. I use it for Linux kernel and U-Boot contributions for a couple of 
years now and I'm not going back to manual workflow :)


b4 prep --auto-to-cc would set everything up properly for you.

On 4/16/24 14:47, Lukasz Czechowski wrote:

Display TPL init information message only when TPL_BANNER_PRINT
configuration entry is set. This allows to disable information
message in case logs on UART are unwanted.

Signed-off-by: Lukasz Czechowski 


This matches Rockchip's non-PX30 TPL, so:

Reviewed-by: Quentin Schulz 


---
  arch/arm/mach-rockchip/px30-board-tpl.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/px30-board-tpl.c 
b/arch/arm/mach-rockchip/px30-board-tpl.c
index 637a5e1b18..a660816db0 100644
--- a/arch/arm/mach-rockchip/px30-board-tpl.c
+++ b/arch/arm/mach-rockchip/px30-board-tpl.c
@@ -46,7 +46,9 @@ void board_init_f(ulong dummy)
 * printhex8(0x1234);
 * printascii("string");
 */
+#if CONFIG_TPL_BANNER_PRINT
printascii("U-Boot TPL board init\n");
+#endif


I'm wondering if we shouldn't have the parent ifdef also match the logic 
of the non-PX30 TPL?


#if defined(CONFIG_DEBUG_UART) && defined(CONFIG_TPL_SERIAL)

instead of

#if defined(CONFIG_DEBUG_UART)

?

Thanks,
Quentin


Re: [PATCH 4/4] Kconfig: Make all Kconfig encoding ascii

2024-04-16 Thread Dragan Simic

On 2024-04-16 08:59, Francesco Dolcini wrote:

On Tue, Apr 16, 2024 at 02:36:12AM +0200, Tom Rini wrote:

On Mon, Apr 15, 2024 at 02:22:02PM +0200, Heinrich Schuchardt wrote:
> On 15.04.24 13:35, Michal Simek wrote:
> > Some of Kconfigs are using utf-8 encoding because of used chars. Convert
> > all of them to ascii enconging.
> >
> > Signed-off-by: Michal Simek 
[snip]
> > diff --git a/arch/arm/mach-rockchip/rv1126/Kconfig 
b/arch/arm/mach-rockchip/rv1126/Kconfig
> > index ae323ee91235..64a70f61f894 100644
> > --- a/arch/arm/mach-rockchip/rv1126/Kconfig
> > +++ b/arch/arm/mach-rockchip/rv1126/Kconfig
> > @@ -6,8 +6,8 @@ config TARGET_RV1126_NEU2
> > Neu2:
> > Neural Compute Module 2(Neu2) is a 96boards SoM-CB compute module
> > based on Rockchip RV1126 from Edgeble AI.
> > -   Neu2 powered with Consumer grade (0 to +80 °C) RV1126 SoC.
> > -   Neu2k powered with Industrial grade (-40 °C to +85 °C) RV1126K SoC.
> > +   Neu2 powered with Consumer grade (0 to +80 C) RV1126 SoC.
> > +   Neu2k powered with Industrial grade (-40 C to +85 C) RV1126K SoC.
>
> C is the sign for coulomb which is the unit of electric charge. How
> about 'deg C'?

I'll note that in Linux there's seemingly nothing consistent, and I'm
fine with any of "deg C" or "degrees C" or "temperature range (-40 C 
to

+85 C)" as all of those should be clear in context.


My 2 cents ... while I agree with Tom that the context will make it
clear, it is not making it correct nor nice. Using just "C" for Celsius
degrees is horrible ...


FWIW, I usually use "oC", which is far from perfect, but IMHO also
far from horrible. :)


Re: [PATCH] Kconfig: Remove all default n options

2024-04-16 Thread Ilias Apalodimas
On Mon, 15 Apr 2024 at 11:20, Michal Simek  wrote:
>
> default n doesn't need to be specified. It is default option anyway.
> Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all
> default n/no options").
>
> Signed-off-by: Michal Simek 
> ---
>
>  boot/Kconfig | 1 -
>  cmd/Kconfig  | 2 --
>  2 files changed, 3 deletions(-)
>
> diff --git a/boot/Kconfig b/boot/Kconfig
> index 777e408e2438..bb61e8b24f1c 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -816,7 +816,6 @@ if MEASURED_BOOT
>
> 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
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 8eeb99eea5ed..6c8ad1b87e87 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -444,7 +444,6 @@ config CMD_ELF
>
>  config CMD_ELF_FDT_SETUP
> bool "Flattened Device Tree setup in bootelf cmd"
> -   default n
> depends on CMD_ELF
> select LIB_LIBFDT
> select LMB
> @@ -2573,7 +2572,6 @@ config CMD_CROS_EC
>  config CMD_SCMI
> bool "Enable scmi command"
> depends on SCMI_FIRMWARE
> -   default n
> help
>   This command provides user interfaces to several SCMI (System
>   Control and Management Interface) protocols available on Arm
> --
> 2.44.0
>

Reviewed-by: Ilias Apalodimas 


Re: [PATCH] Kconfig: Remove all default n options

2024-04-16 Thread Mattijs Korpershoek
Hi Michal,

Thank you for the patch.

On lun., avril 15, 2024 at 10:20, Michal Simek  wrote:

> default n doesn't need to be specified. It is default option anyway.
> Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all
> default n/no options").
>
> Signed-off-by: Michal Simek 

Reviewed-by: Mattijs Korpershoek 

> ---
>
>  boot/Kconfig | 1 -
>  cmd/Kconfig  | 2 --
>  2 files changed, 3 deletions(-)
>
> diff --git a/boot/Kconfig b/boot/Kconfig
> index 777e408e2438..bb61e8b24f1c 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -816,7 +816,6 @@ if MEASURED_BOOT
>  
>   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
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 8eeb99eea5ed..6c8ad1b87e87 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -444,7 +444,6 @@ config CMD_ELF
>  
>  config CMD_ELF_FDT_SETUP
>   bool "Flattened Device Tree setup in bootelf cmd"
> - default n
>   depends on CMD_ELF
>   select LIB_LIBFDT
>   select LMB
> @@ -2573,7 +2572,6 @@ config CMD_CROS_EC
>  config CMD_SCMI
>   bool "Enable scmi command"
>   depends on SCMI_FIRMWARE
> - default n
>   help
> This command provides user interfaces to several SCMI (System
> Control and Management Interface) protocols available on Arm
> -- 
> 2.44.0


Re: [PATCH 2/4] board: add support for Milk-V Mars CM

2024-04-16 Thread E Shattow
On Mon, Apr 15, 2024 at 4:50 AM Heinrich Schuchardt
 wrote:
>
> We already support the VisionFive 2 and the Milk-V Mars board by
> patching the VisionFive 2 device tree. With this patch the same
> is done for the Milk-V Mars CM.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  board/starfive/visionfive2/spl.c  | 27 ++-
>  .../visionfive2/starfive_visionfive2.c| 11 +++-
>  2 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/board/starfive/visionfive2/spl.c 
> b/board/starfive/visionfive2/spl.c
> index 45848db6d8b..bb0f28d7aad 100644
> --- a/board/starfive/visionfive2/spl.c
> +++ b/board/starfive/visionfive2/spl.c
> @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt)
> }
>  }
>
> +void spl_fdt_fixup_marc(void *fdt)
> +{
> +   const char *compat;
> +   const char *model;
> +
> +   spl_fdt_fixup_mars(fdt);
> +
> +   if (!get_mmc_size_from_eeprom()) {
> +   int offset;
> +
> +   model = "Milk-V Mars CM SDCard";
> +   compat = "milkv,mars-cm-sdcard\0starfive,jh7110";
> +
> +   offset = fdt_path_offset(fdt, 
> "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");
> +   fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);

Note this is:

- pinmux = https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f72ecf1e2947dfeb2c66e5035fce90

But the GPIOMUX macro here (for code readability) would bring in
another header to include. Add a comment of what the magic number is
for.

Does anyone have a better explanation of why this is needed than the
vendor "u-boot: configure sdio0 as mars-cm sdcard version" commit
message?

> +   } else {
> +   model = "Milk-V Mars CM eMMC";
> +   compat = "milkv,mars-cm-emmc\0starfive,jh7110";
> +   }
> +   fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, 
> sizeof(compat));
> +   fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);
> +}
> +
>  void spl_fdt_fixup_version_a(void *fdt)
>  {
> static const char compat[] = 
> "starfive,visionfive-2-v1.2a\0starfive,jh7110";
> @@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
> pr_err("Can't read EEPROM\n");
> return;
> }
> -   if (!strncmp(product_id, "MARS", 4)) {
> +   if (!strncmp(product_id, "MARC", 4)) {
> +   spl_fdt_fixup_marc(spl_image->fdt_addr);
> +   } else if (!strncmp(product_id, "MARS", 4)) {
> spl_fdt_fixup_mars(spl_image->fdt_addr);
> } else if (!strncmp(product_id, "VF7110", 6)) {
> version = get_pcb_revision_from_eeprom();
> diff --git a/board/starfive/visionfive2/starfive_visionfive2.c 
> b/board/starfive/visionfive2/starfive_visionfive2.c
> index a86bca533b2..be6ca85b030 100644
> --- a/board/starfive/visionfive2/starfive_visionfive2.c
> +++ b/board/starfive/visionfive2/starfive_visionfive2.c
> @@ -17,6 +17,10 @@
>  DECLARE_GLOBAL_DATA_PTR;
>  #define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
>  #define JH7110_L2_PREFETCHER_HART_OFFSET   0x2000
> +#define FDTFILE_MILK_V_MARC_SD \
> +   "starfive/jh7110-milkv-mars-cm-sdcard.dtb"
> +#define FDTFILE_MILK_V_MARC_MMC \
> +   "starfive/jh7110-milkv-mars-cm-emmc.dtb"
>  #define FDTFILE_MILK_V_MARS \
> "starfive/jh7110-milkv-mars.dtb"
>  #define FDTFILE_VISIONFIVE2_1_2A \
> @@ -61,7 +65,12 @@ static void set_fdtfile(void)
> log_err("Can't read EEPROM\n");
> return;
> }
> -   if (!strncmp(product_id, "MARS", 4)) {
> +   if (!strncmp(product_id, "MARC", 4)) {
> +   if (get_mmc_size_from_eeprom())
> +   fdtfile = FDTFILE_MILK_V_MARC_MMC;
> +   else
> +   fdtfile = FDTFILE_MILK_V_MARC_SD;
> +   } else if (!strncmp(product_id, "MARS", 4)) {
> fdtfile = FDTFILE_MILK_V_MARS;
> } else if (!strncmp(product_id, "VF7110", 6)) {
> version = get_pcb_revision_from_eeprom();
> --
> 2.43.0
>


[PATCH] rockchip: px30-board-tpl: Use CONFIG_TPL_BANNER_PRINT flag

2024-04-16 Thread Lukasz Czechowski
Display TPL init information message only when TPL_BANNER_PRINT
configuration entry is set. This allows to disable information
message in case logs on UART are unwanted.

Signed-off-by: Lukasz Czechowski 
---
 arch/arm/mach-rockchip/px30-board-tpl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/px30-board-tpl.c 
b/arch/arm/mach-rockchip/px30-board-tpl.c
index 637a5e1b18..a660816db0 100644
--- a/arch/arm/mach-rockchip/px30-board-tpl.c
+++ b/arch/arm/mach-rockchip/px30-board-tpl.c
@@ -46,7 +46,9 @@ void board_init_f(ulong dummy)
 * printhex8(0x1234);
 * printascii("string");
 */
+#if CONFIG_TPL_BANNER_PRINT
printascii("U-Boot TPL board init\n");
+#endif
 #endif
 
secure_timer_init();
-- 
2.34.1



Re: [PATCH v2 5/5] common: Convert *.c/h from UTF-8 to ASCII enconfing

2024-04-16 Thread Marek Behún
Acked-by: Marek Behún 


[PATCH 3/3] configs: milkv_duo: Add sysreset configs

2024-04-16 Thread Kongyang Liu
Add sysreset configs as well as poweroff and reset commands for Sophgo
Milk-V Duo board.

Signed-off-by: Kongyang Liu 
---

 configs/milkv_duo_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/milkv_duo_defconfig b/configs/milkv_duo_defconfig
index e8413d7aa9..28bd4b53d3 100644
--- a/configs/milkv_duo_defconfig
+++ b/configs/milkv_duo_defconfig
@@ -19,6 +19,7 @@ CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="milkv_duo# "
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
+CONFIG_CMD_POWEROFF=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ENV_OVERWRITE=y
@@ -30,3 +31,5 @@ CONFIG_MMC_SDHCI_ADMA=y
 CONFIG_MMC_SDHCI_CV1800B=y
 CONFIG_SYS_NS16550=y
 CONFIG_SYS_NS16550_MEM32=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_CV1800B=y
-- 
2.41.0



[PATCH 2/3] board: sophgo: milkv_duo: Bind sysreset driver

2024-04-16 Thread Kongyang Liu
Bind cv1800b sysreset driver for Sophgo Milk-V Duo board in board_init
function.

Signed-off-by: Kongyang Liu 
---

 board/sophgo/milkv_duo/board.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/sophgo/milkv_duo/board.c b/board/sophgo/milkv_duo/board.c
index eaa47be173..e7e28fe248 100644
--- a/board/sophgo/milkv_duo/board.c
+++ b/board/sophgo/milkv_duo/board.c
@@ -3,7 +3,11 @@
  * Copyright (c) 2024, Kongyang Liu 
  */
 
+ #include 
+
 int board_init(void)
 {
+   if (IS_ENABLED(CONFIG_SYSRESET_CV1800B))
+   device_bind_driver(gd->dm_root, "cv1800b_sysreset", "sysreset", 
NULL);
return 0;
 }
-- 
2.41.0



[PATCH 1/3] sysreset: cv1800b: Add sysreset driver for cv1800b SoC

2024-04-16 Thread Kongyang Liu
Add sysreset driver for cv1800b SoC

Signed-off-by: Kongyang Liu 

---

 drivers/sysreset/Kconfig|  5 +++
 drivers/sysreset/Makefile   |  1 +
 drivers/sysreset/sysreset_cv1800b.c | 64 +
 3 files changed, 70 insertions(+)
 create mode 100644 drivers/sysreset/sysreset_cv1800b.c

diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 49c0787b26..b64bfadb20 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -59,6 +59,11 @@ config SYSRESET_CMD_POWEROFF
 
 endif
 
+config SYSRESET_CV1800B
+   bool "Enable support for Sophgo cv1800b System Reset"
+   help
+ Enable system reset support for Sophgo cv1800b SoC.
+
 config POWEROFF_GPIO
bool "Enable support for GPIO poweroff driver"
depends on DM_GPIO
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index e0e732205d..d59299aa31 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_ASPEED) += sysreset_ast.o
 obj-$(CONFIG_ARCH_ROCKCHIP) += sysreset_rockchip.o
 obj-$(CONFIG_ARCH_STI) += sysreset_sti.o
 obj-$(CONFIG_SANDBOX) += sysreset_sandbox.o
+obj-$(CONFIG_SYSRESET_CV1800B) += sysreset_cv1800b.o
 obj-$(CONFIG_POWEROFF_GPIO) += poweroff_gpio.o
 obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
 obj-$(CONFIG_$(SPL_TPL_)SYSRESET_MAX77663) += sysreset_max77663.o
diff --git a/drivers/sysreset/sysreset_cv1800b.c 
b/drivers/sysreset/sysreset_cv1800b.c
new file mode 100644
index 00..9cd62772ef
--- /dev/null
+++ b/drivers/sysreset/sysreset_cv1800b.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024, Kongyang Liu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_RTC_BASE (void *)0x05026000
+#define REG_RTC_CTRL_BASE(void *)0x05025000
+#define REG_RTC_EN_SHDN_REQ  (REG_RTC_BASE + 0xc0)
+#define REG_RTC_EN_PWR_CYC_REQ   (REG_RTC_BASE + 0xc8)
+#define REG_RTC_EN_WARM_RST_REQ  (REG_RTC_BASE + 0xcc)
+#define REG_RTC_CTRL_UNLOCKKEY   (REG_RTC_CTRL_BASE + 0x4)
+#define REG_RTC_CTRL (REG_RTC_CTRL_BASE + 0x8)
+
+#define CTRL_UNLOCKKEY_MAGIC 0xAB18
+
+/* REG_RTC_CTRL */
+#define BIT_REQ_SHDN   BIT(0)
+#define BIT_REQ_PWR_CYCBIT(3)
+#define BIT_REQ_WARM_RST   BIT(4)
+
+static struct {
+   void *pre_req_reg;
+   u32 req_bit;
+} reset_info[SYSRESET_COUNT] = {
+   [SYSRESET_WARM]  = { REG_RTC_EN_WARM_RST_REQ, BIT_REQ_WARM_RST },
+   [SYSRESET_COLD]  = { REG_RTC_EN_WARM_RST_REQ, BIT_REQ_WARM_RST },
+   [SYSRESET_POWER] = { REG_RTC_EN_PWR_CYC_REQ, BIT_REQ_PWR_CYC },
+   [SYSRESET_POWER_OFF] = { REG_RTC_EN_SHDN_REQ, BIT_REQ_SHDN },
+};
+
+static int cv1800b_sysreset_request(struct udevice *dev, enum sysreset_t type)
+{
+   u32 reg;
+
+   writel(1, reset_info[type].pre_req_reg);
+   writel(CTRL_UNLOCKKEY_MAGIC, REG_RTC_CTRL_UNLOCKKEY);
+   reg = readl(REG_RTC_CTRL);
+   writel(0x0800 | reset_info[type].req_bit, REG_RTC_CTRL);
+
+   return -EINPROGRESS;
+}
+
+static struct sysreset_ops cv1800b_sysreset = {
+   .request = cv1800b_sysreset_request,
+};
+
+static const struct udevice_id cv1800b_sysreset_ids[] = {
+   { .compatible = "sophgo,cv1800b-sysreset", },
+   {},
+};
+
+U_BOOT_DRIVER(sysreset_cv1800b) = {
+   .name = "cv1800b_sysreset",
+   .id   = UCLASS_SYSRESET,
+   .ops  = &cv1800b_sysreset,
+   .of_match = cv1800b_sysreset_ids
+};
-- 
2.41.0



[PATCH 0/3] sysreset: sophgo: milkv_duo: Add sysreset support for Milk-V Duo board

2024-04-16 Thread Kongyang Liu
This series add sysreset driver for cv1800b SoC and enable poweroff and
reset commands for Sophgo Milk-V Duo board.


Kongyang Liu (3):
  sysreset: cv1800b: Add sysreset driver for cv1800b SoC
  board: sophgo: milkv_duo: Bind sysreset driver
  configs: milkv_duo: Add sysreset configs

 board/sophgo/milkv_duo/board.c  |  4 ++
 configs/milkv_duo_defconfig |  3 ++
 drivers/sysreset/Kconfig|  5 +++
 drivers/sysreset/Makefile   |  1 +
 drivers/sysreset/sysreset_cv1800b.c | 64 +
 5 files changed, 77 insertions(+)
 create mode 100644 drivers/sysreset/sysreset_cv1800b.c

-- 
2.41.0



[PATCH] mmc: cv1800b: Add transmit tap delay config to fix write error

2024-04-16 Thread Kongyang Liu
Currently, only the receive delay is configured while the transmit delay
is not set, which may result in errors when writing to the file. This issue
can be resolved by setting PHY_TX_SRC_INVERT to SDHCI_PHY_TX_RX_DLY.

Signed-off-by: Kongyang Liu 
---

 drivers/mmc/cv1800b_sdhci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c
index 2275c53777..a50f4cff0d 100644
--- a/drivers/mmc/cv1800b_sdhci.c
+++ b/drivers/mmc/cv1800b_sdhci.c
@@ -12,6 +12,8 @@
 #define MMC_MAX_CLOCK37500
 #define TUNE_MAX_PHCODE  128
 
+#define PHY_TX_SRC_INVERT  BIT(8)
+
 struct cv1800b_sdhci_plat {
struct mmc_config cfg;
struct mmc mmc;
@@ -19,7 +21,7 @@ struct cv1800b_sdhci_plat {
 
 static void cv1800b_set_tap_delay(struct sdhci_host *host, u16 tap)
 {
-   sdhci_writel(host, tap << 16, SDHCI_PHY_TX_RX_DLY);
+   sdhci_writel(host, PHY_TX_SRC_INVERT | tap << 16, SDHCI_PHY_TX_RX_DLY);
 }
 
 static void cv1800b_sdhci_reset(struct sdhci_host *host, u8 mask)
-- 
2.41.0



[PATCH v2 5/5] common: Convert *.c/h from UTF-8 to ASCII enconfing

2024-04-16 Thread Michal Simek
Convert UTF-8 chars to ASCII in cases where make sense. No Copyright or
names are converted.

Signed-off-by: Michal Simek 

---

Changes in v2:
- New patch in series

 .../armv8/fsl-layerscape/fsl_lsch2_serdes.c   |  2 +-
 .../armv8/fsl-layerscape/fsl_lsch3_serdes.c   |  2 +-
 arch/arm/mach-imx/ddrmc-vf610-calibration.c   | 12 +-
 arch/arm/mach-imx/mx6/clock.c |  8 +++
 arch/arm/mach-imx/mx7/psci-mx7.c  |  4 ++--
 arch/mips/mach-mscc/include/mach/ddr.h|  2 +-
 .../include/mach/cvmx-helper-pki.h|  2 +-
 arch/mips/mach-octeon/include/mach/cvmx-pki.h |  6 ++---
 .../mips/mach-octeon/include/mach/cvmx-pko3.h |  2 +-
 board/CZ.NIC/turris_mox/turris_mox.c  |  2 +-
 board/amlogic/vim3/vim3.c |  2 +-
 board/bosch/acc/acc.c |  2 +-
 board/bosch/shc/board.c   |  2 +-
 board/bosch/shc/board.h   |  2 +-
 board/congatec/cgtqmx8/cgtqmx8.c  |  4 ++--
 board/freescale/common/i2c_mux.c  |  2 +-
 board/siemens/capricorn/board.c   |  8 +++
 board/st/common/cmd_stboard.c |  2 +-
 .../visionfive2/visionfive2-i2c-eeprom.c  |  4 ++--
 drivers/clk/renesas/rzg2l-cpg.c   |  6 ++---
 drivers/clk/stm32/clk-stm32-core.h| 22 +--
 drivers/led/led_lp5562.c  |  4 ++--
 drivers/mtd/nand/raw/nand_ids.c   |  2 +-
 drivers/rng/stm32_rng.c   |  6 ++---
 drivers/soc/ti/k3-navss-ringacc.c |  2 +-
 drivers/thermal/thermal_sandbox.c |  2 +-
 drivers/video/renesas-r61307.c|  2 +-
 drivers/video/renesas-r69328.c|  2 +-
 drivers/xen/pvblock.c |  2 +-
 include/acpi/acpigen.h|  6 ++---
 include/linux/mtd/mtd.h   |  2 +-
 lib/crypto/x509_cert_parser.c |  2 +-
 32 files changed, 65 insertions(+), 65 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
index 1541dfb3ec47..b1bb29bcaf55 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
@@ -258,7 +258,7 @@ int setup_serdes_volt(u32 svdd)
/* Wait for SVDD to stabilize */
udelay(100);
 
-   /* For each PLL that’s not disabled via RCW */
+   /* For each PLL that's not disabled via RCW */
 #ifdef CONFIG_SYS_FSL_SRDS_1
cfg_tmp = (cfg_rcw5 >> 22) & 0x3;
for (i = 0; i < 2 && !(cfg_tmp & (0x1 << (1 - i))); i++) {
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
index c0efc341afc1..fbd5fd7d433b 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
@@ -483,7 +483,7 @@ int setup_serdes_volt(u32 svdd)
ret = -1;
}
 
-   /* For each PLL that’s not disabled via RCW enable the SERDES */
+   /* For each PLL that's not disabled via RCW enable the SERDES */
 #ifdef CONFIG_SYS_FSL_SRDS_1
cfg_tmp = cfg_rcwsrds1 & 0x3;
do_serdes_enable(cfg_tmp, serdes1_base);
diff --git a/arch/arm/mach-imx/ddrmc-vf610-calibration.c 
b/arch/arm/mach-imx/ddrmc-vf610-calibration.c
index cd7e95e61d00..7d787d045980 100644
--- a/arch/arm/mach-imx/ddrmc-vf610-calibration.c
+++ b/arch/arm/mach-imx/ddrmc-vf610-calibration.c
@@ -45,7 +45,7 @@
  * based on trace length differences from their
  * layout.
  * Mismatches up to 25% or tCK (clock period) are
- * allowed, so the value in the filed doesn’t have
+ * allowed, so the value in the filed doesn't have
  * to be very accurate.
  *
  * - 0x2 (b'10) - RDLVL_DL_0/1 - refers to adjusting the DQS strobe in relation
@@ -184,14 +184,14 @@ static int ddrmc_cal_dqs_to_dq(struct ddrmr_regs *ddrmr)
debug("RDLVL: PHY_RDLVL_EDGE:\t 0x%x\n",
  (tmp >> DDRMC_CR101_PHY_RDLVL_EDGE_OFF) & 0x1); //set 0
 
-   /* Program Leveling mode - CR93[SW_LVL_MODE] to ’b10 */
+   /* Program Leveling mode - CR93[SW_LVL_MODE] to 'b10 */
clrsetbits_le32(&ddrmr->cr[93], DDRMC_CR93_SW_LVL_MODE(0x3),
DDRMC_CR93_SW_LVL_MODE(0x2));
tmp = readl(&ddrmr->cr[93]);
debug("RDLVL: SW_LVL_MODE:\t 0x%x\n",
  (tmp >> DDRMC_CR93_SW_LVL_MODE_OFF) & 0x3);
 
-   /* Start procedure - CR93[SWLVL_START] to ’b1 */
+   /* Start procedure - CR93[SWLVL_START] to 'b1 */
sw_leveling_start;
 
/* Poll CR94[SWLVL_OP_DONE] */
@@ -211,7 +211,7 @@ static int ddrmc_cal_dqs_to_dq(struct ddrmr_regs *ddrmr)
0x << DDRMC_CR105_RDLVL_DL_0_OFF,
  

[PATCH v2 0/5] Kconfig: some cleanups

2024-04-16 Thread Michal Simek
I looked as cleaning up some dependencies and I found that qconfig is
reporting some issues. This series is fixing some of them. But there are
still some other pending. That's why please go and fix them if they are
related to your board.

UTF-8: I am using uni2ascii -B < file to do conversion. When you run it in
a loop you will find some other issue with copyright chars or some issues
in files taken from the Linux kernel like DTs. They should be likely fixed
in the kernel first.
Based on discussion I am ignoring names too.

Thanks,
Michal

drivers/pinctrl/intel/Kconfig:12: warning: style: quotes recommended around 'n' 
in 'bool n'
warning: the choice symbol CPU_ARCEM6 (defined at arch/arc/Kconfig:46) is 
selected by the following symbols, but select/imply has no effect on choice 
symbols
 - TARGET_EMSDP (defined at arch/arc/Kconfig:173)
 - TARGET_IOT_DEVKIT (defined at arch/arc/Kconfig:180)
warning: the choice symbol ARC_MMU_ABSENT (defined at arch/arc/Kconfig:77) is 
selected by the following symbols, but select/imply has no effect on choice 
symbols
 - CPU_ARCEM6 (defined at arch/arc/Kconfig:46)
 - CPU_ARCHS36 (defined at arch/arc/Kconfig:53)
warning: the choice symbol ARC_MMU_V2 (defined at arch/arc/Kconfig:82) is 
selected by the following symbols, but select/imply has no effect on choice 
symbols
 - CPU_ARC750D (defined at arch/arc/Kconfig:32)
warning: the choice symbol ARC_MMU_V3 (defined at arch/arc/Kconfig:89) is 
selected by the following symbols, but select/imply has no effect on choice 
symbols
 - CPU_ARC770D (defined at arch/arc/Kconfig:39)
warning: the choice symbol ARC_MMU_V4 (defined at arch/arc/Kconfig:97) is 
selected by the following symbols, but select/imply has no effect on choice 
symbols
 - CPU_ARCHS38 (defined at arch/arc/Kconfig:60)
warning: the choice symbol FSP_VERSION2 (defined at arch/x86/Kconfig:396) is 
selected by the following symbols, but select/imply has no effect on choice 
symbols
 - INTEL_APOLLOLAKE (defined at arch/x86/cpu/apollolake/Kconfig:6)
warning: the choice symbol SPL_RISCV_MMODE (defined at arch/riscv/Kconfig:184) 
is implied by the following symbols, but select/imply has no effect on choice 
symbols
 - BOARD_SPECIFIC_OPTIONS (defined at board/bsh/imx8mn_smm_s2/Kconfig:21, 
board/bsh/imx8mn_smm_s2/Kconfig:41, board/engicam/px30_core/Kconfig:12, 
board/theobroma-systems/ringneck_px30/Kconfig:12, 
board/radxa/rockpi4-rk3399/Kconfig:12, 
board/theobroma-systems/puma_rk3399/Kconfig:12, 
board/theobroma-systems/jaguar_rk3588/Kconfig:12, 
board/edgeble/neural-compute-module-2/Kconfig:12, 
board/itead/sonoff-ihost/Kconfig:12, board/emulation/qemu-arm/Kconfig:6, 
board/emulation/qemu-arm/Kconfig:22, board/freescale/ls1012aqds/Kconfig:27, 
board/freescale/ls1012ardb/Kconfig:27, board/freescale/ls1012ardb/Kconfig:76, 
board/freescale/ls1012afrdm/Kconfig:27, 
board/advantech/som-db5800-som-6867/Kconfig:18, 
board/congatec/conga-qeval20-qa3-e3845/Kconfig:17, 
board/coreboot/coreboot/Kconfig:15, board/dfi/dfi-bt700/Kconfig:17, 
board/efi/efi-x86_app/Kconfig:12, board/efi/efi-x86_payload/Kconfig:15, 
board/emulation/qemu-x86/Kconfig:16, board/google/chromebook_coral/Kconfig:18, 
board/google/chromebook_link/Kconfig:19, 
board/google/chromebox_panther/Kconfig:19, 
board/google/chromebook_samus/Kconfig:19, board/intel/bayleybay/Kconfig:15, 
board/intel/cherryhill/Kconfig:15, board/intel/cougarcanyon2/Kconfig:15, 
board/intel/crownbay/Kconfig:15, board/intel/edison/Kconfig:24, 
board/intel/galileo/Kconfig:15, board/intel/minnowmax/Kconfig:15, 
board/intel/slimbootloader/Kconfig:19, board/AndesTech/ae350/Kconfig:34, 
board/emulation/qemu-riscv/Kconfig:32, board/microchip/mpfs_icicle/Kconfig:19, 
board/openpiton/riscv64/Kconfig:26, board/sifive/unleashed/Kconfig:26, 
board/sifive/unmatched/Kconfig:26, board/sipeed/maix/Kconfig:30, 
board/sophgo/milkv_duo/Kconfig:24, board/starfive/visionfive2/Kconfig:26, 
board/thead/th1520_lpi4a/Kconfig:30, board/xilinx/mbv/Kconfig:22, 
board/keymile/km83xx/Kconfig:34, board/keymile/km83xx/Kconfig:54, 
board/keymile/km83xx/Kconfig:74, board/keymile/km83xx/Kconfig:93, 
board/keymile/km83xx/Kconfig:112, board/keymile/km83xx/Kconfig:131, 
board/keymile/km83xx/Kconfig:150, board/keymile/kmcent2/Kconfig:12, 
board/keymile/pg-wcom-ls102xa/Kconfig:15, 
board/keymile/pg-wcom-ls102xa/Kconfig:35)
warning: the choice symbol SYS_BIG_ENDIAN (defined at arch/Kconfig:528) is 
selected by the following symbols, but select/imply has no effect on choice 
symbols
 - ARC (defined at arch/Kconfig:53)
warning: the choice symbol SYS_LITTLE_ENDIAN (defined at arch/Kconfig:532) is 
selected by the following symbols, but select/imply has no effect on choice 
symbols
 - ARC (defined at arch/Kconfig:53)
warning: the choice symbol OF_SEPARATE (defined at dts/Kconfig:108) is selected 
by the following symbols, but select/imply has no effect on choice symbols
 - ARCH_MVEBU (defined at arch/arm/Kconfig:620)
 - ARCH_SNAPDRAGON (defined at arch/arm/Kconfig:1074)
 - ARCH_SUNXI (d

Re: [PATCH v2 0/2] sunxi, usb: UDC/DM gadget model support

2024-04-16 Thread John Watts
On Thu, Jun 08, 2023 at 01:56:29PM -0600, Sam Edwards wrote:
> Happy Thursday, U-Boot list!
> 
> Here is attempt 2 at making this USB controller driver compatible with
> DM's gadget model, following what most of the other musb variants do.
> 
> v2 removes the unwanted printfs in the probe func, per feedback from Marek.
> I received no other feedback against v1 of this patch.

Hi Sam,

I did some more testing and I believe my USB issues mentioned in the
other subthread are unrelated to this patch.

As such, here's my reviewed-by and tested-by. :)

John.

Reviewed-by: John Watts 
Tested-by: John Watts 

> 
> Cheers,
> Sam
> 
> Sam Edwards (2):
>   usb: musb-new: sunxi: remove unwanted printfs
>   usb: musb-new: sunxi: make compatible with UDC/DM gadget model
> 
>  drivers/usb/musb-new/sunxi.c | 52 +---
>  1 file changed, 31 insertions(+), 21 deletions(-)
> 
> -- 
> 2.39.2
> 


Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL

2024-04-16 Thread Chintan Vankar




On 12/04/24 03:37, Tom Rini wrote:

On Wed, Apr 03, 2024 at 06:18:01PM +0530, Chintan Vankar wrote:



On 22/01/24 10:11, Siddharth Vadapalli wrote:



On 20/01/24 22:11, Tom Rini wrote:

On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth Vadapalli wrote:

Hello Tom,

On 12/01/24 18:56, Tom Rini wrote:


...


The list of conditionals in common/spl/spl.c::board_init_r() should be
updated and probably use SPL_NET as the option to check for.


Thank you for reviewing the patch and pointing this out. I wasn't aware of it. I
assume that you are referring to the following change:

  if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) ||
-   IS_ENABLED(CONFIG_SPL_ATF))
+   IS_ENABLED(CONFIG_SPL_ATF) || IS_ENABLED(CONFIG_SPL_NET))
  dram_init_banksize();

I shall replace the current patch with the above change in the v2 series. Since
this is in the common section, is there a generic reason I could provide in the
commit message rather than the existing commit message which seems to be board
specific? Also, I hope that the above change will not cause regressions for
other non-TI devices. Please let me know.


Yes, that's the area, and just note that networking also requires the
DDR to be initialized.



Thank you for confirming and providing your suggestion for the contents of the
commit message.


Following Tom's Suggestion of adding CONFIG_SPL_NET in common/spl/spl.c
"dram_init_banksize()", the issue of fetching a file at SPL stage seemed
to be fixed. However the commit "ba20b2443c29", which sets gd->ram_top
for the very first time in "spl_enable_cache()" results in
"arch_lmb_reserve()" function reserving memory region from Stack pointer
at "0x81FFB820" to gd->ram_top pointing to "0x1". Previously
when gd->ram_top was zero "arch_lmb_reserve()" was noop. Now using TFTP
to fetch U-Boot image at SPL stage results in "tftp_init_load_addr()"
function call that invokes "arch_lmb_reserve()" function, which reserves
entire memory starting from Stack Pointer to gd->ram_top leaving no
space to load U-Boot image via TFTP since TFTP loads files at pre
configured memory address at "0x8200".

As a workaround for this issue, one solution we can propose is to
disable the checks "lmb_get_free_size()" at SPL and U-Boot stage. For
that we can define a new config option for LMB reserve checks as
"SPL_LMB". This config will be enable by default for the backword
compatibility and disable for our use case at SPL and U-Boot stage.


The problem here is that we need LMB for booting an OS, which is
something we'll want in SPL in non-cortex-R cases too, which means this
platform, so that's a no-go. I think you need to dig harder and see if
you can correct the logic somewhere so that we don't over reserve?


Since this issue is due to function call "lmb_init_and_reserve()"
function invoked from "tftp_init_load_addr()" function. This function
is defined by Simon in commit "a156c47e39ad", which fixes
"CVE-2018-18439" to prevent overwriting reserved memory. Simon, can you
explain why do we need to call "lmb_init_and_reserve()" function here ?


Re: [PATCH 1/4] arm: davinci: Migrate da850-evm to OF_UPSTREAM

2024-04-16 Thread Adam Ford
On Thu, Apr 11, 2024 at 7:05 PM Tom Rini  wrote:
>
> On Wed, Apr 03, 2024 at 10:00:09PM -0500, Adam Ford wrote:
>
> > The da850-evm can remove the U-Boot device trees if migrated
> > to OF_UPSTREAM.  This means pointing the device trees to the
> > ti/davinci directory.
> >
> > Signed-off-by: Adam Ford 
>
> This series leads to failure to build for omapl138_lcdk and lego_ev3 or
> was I supposed to bring in something else first? Thanks.

I just got back from 10 days in Europe for the Embedded World
Conference.  It should have been based on [1], but I haven't checked
to see if it was applied.  I (maybe wrongly) assumed [1] would have
been applied before this patch was.

Once I get caught up, I'll look to see what's going one.

adam

[1] - https://www.mail-archive.com/u-boot@lists.denx.de/msg505123.html



>
> --
> Tom


Re: [PATCH] imx93: Move SoC and lifeclycle information to debug level

2024-04-16 Thread Mathieu Othacehe


Hello,

> The following information printed on every boot is not very
> helpful for the users:
>
> SOC: 0xa0009300
> LC: 0x40040
>
> Move them to debug() level.
>
> Signed-off-by: Fabio Estevam 

Reviewed-by: Mathieu Othacehe 

Thanks,

Mathieu


Re: [PATCH u-boot-mvebu 00/10] Turris Omnia DDR training changes

2024-04-16 Thread Marek Behún
Hi Tony,

hmm no I did not change the version number.

The changes are only relevant for debug messages, there is no
functional changes in how the DDR training is done, unless I made a
mistake.

I am not sure that changing the version is a good idea unless this is
also done for the upstream where I sent the PR. But who knows if
Marvell will have some people assigned to merge the PR.

Since U-Boot prints its own version, people can easily reproduce the
code for a given binary from U-Boot version string.

Marek

On Mon, 15 Apr 2024 15:20:49 -0700
Tony Dinh  wrote:

> Hi Marek,
> 
> I'm running a regression test with this patch on another Armada 385
> board (Synology DS116). And
> it is running without problem.
> 
> I noticed that there is no version bump. Is this still 14.0.0? It's kind of
> hard to see which version we are using without a minor revision such as 
> 14.0.1.
> 
> All the best,
> Tony
> 
> On Mon, Apr 15, 2024 at 9:39 AM Marek Behún  wrote:
> >
> > Hi Stefan,
> >
> > this series adds some changes to DDR3 training for Armada 38x and
> > Turris Omnia.
> >
> > - patches 1-4 are meant to allow for reducing another 10 KiB in the
> >   SPL binary. They were also sent to mv-ddr-marvell, via PR on github,
> >   https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/45/
> >   but I am told that Armada team has left Marvell, so who knows if this
> >   will ever be merged there
> > - patch 5 enables this reduction for Turris Omnia
> > - patches 6-8 import old DDR3 training code and make some changes so
> >   that it works with U-Boot. The reason why this is being done is
> >   explained in patch 6
> > - patch 9 glues the old DDR3 training code to current U-Boot
> > - patch 10 allows for dynamic selection of old DDR3 training code on
> >   Turris Omnia, via an U-Boot environment variable
> >
> > Marek
> >
> > Marek Behún (10):
> >   ddr: marvell: a38x: debug: return from ddr3_tip_print_log() early if
> > we won't print anything
> >   ddr: marvell: a38x: debug: Remove unused variables
> >   ddr: marvell: a38x: debug: Define DDR_VIEWER_TOOL variables only if
> > needed, and make them static
> >   ddr: marvell: a38x: debug: Allow compiling with immutable debug
> > settings to reduce binary size
> >   arm: mvebu: turris_omnia: Enable immutable debug settings in DDR3
> > training by default
> >   ddr: marvell: a38x: Import old DDR training code from 2017 version of
> > U-Boot
> >   ddr: marvell: a38x: old: Fix some compiler warning of the old code
> >   ddr: marvell: a38x: old: Backport immutable debug settings
> >   arm: mvebu: a38x: Add optional support for using old DDR3 training
> > code
> >   arm: mvebu: turris_omnia: Support old DDR3 training, selectable via
> > env var
> >
> >  arch/arm/mach-mvebu/Kconfig   |   15 +
> >  arch/arm/mach-mvebu/include/mach/cpu.h|1 +
> >  arch/arm/mach-mvebu/spl.c |   37 +-
> >  board/CZ.NIC/turris_omnia/Makefile|1 +
> >  board/CZ.NIC/turris_omnia/old_ddr3_training.c |   79 +
> >  board/CZ.NIC/turris_omnia/turris_omnia.c  |2 +-
> >  configs/turris_omnia_defconfig|1 +
> >  drivers/ddr/marvell/a38x/Makefile |2 +
> >  drivers/ddr/marvell/a38x/ddr3_debug.c |   30 +-
> >  drivers/ddr/marvell/a38x/ddr3_init.c  |3 +-
> >  drivers/ddr/marvell/a38x/ddr3_init.h  |   43 +-
> >  drivers/ddr/marvell/a38x/old/Makefile |   29 +
> >  drivers/ddr/marvell/a38x/old/ddr3_a38x.c  |  738 +
> >  drivers/ddr/marvell/a38x/old/ddr3_a38x.h  |   93 +
> >  .../marvell/a38x/old/ddr3_a38x_mc_static.h|  226 ++
> >  .../ddr/marvell/a38x/old/ddr3_a38x_topology.h |   22 +
> >  .../ddr/marvell/a38x/old/ddr3_a38x_training.c |   40 +
> >  drivers/ddr/marvell/a38x/old/ddr3_debug.c | 1545 ++
> >  .../marvell/a38x/old/ddr3_hws_hw_training.c   |  148 +
> >  .../marvell/a38x/old/ddr3_hws_hw_training.h   |   49 +
> >  .../a38x/old/ddr3_hws_hw_training_def.h   |  464 +++
> >  .../marvell/a38x/old/ddr3_hws_sil_training.h  |   17 +
> >  drivers/ddr/marvell/a38x/old/ddr3_init.c  |  770 +
> >  drivers/ddr/marvell/a38x/old/ddr3_init.h  |  405 +++
> >  .../ddr/marvell/a38x/old/ddr3_logging_def.h   |  101 +
> >  .../marvell/a38x/old/ddr3_patterns_64bit.h|  924 ++
> >  .../ddr/marvell/a38x/old/ddr3_topology_def.h  |   76 +
> >  drivers/ddr/marvell/a38x/old/ddr3_training.c  | 2651 +
> >  .../ddr/marvell/a38x/old/ddr3_training_bist.c |  289 ++
> >  .../a38x/old/ddr3_training_centralization.c   |  712 +
> >  .../ddr/marvell/a38x/old/ddr3_training_db.c   |  652 
> >  .../marvell/a38x/old/ddr3_training_hw_algo.c  |  686 +
> >  .../marvell/a38x/old/ddr3_training_hw_algo.h  |   14 +
> >  .../ddr/marvell/a38x/old/ddr3_training_ip.h   |  178 ++
> >  .../marvell/a38x/old/ddr3_training_ip_bist.h  |   54 +
> >  .../old/ddr3_training_ip_centralization.h |   15 +
> >  .../marvell

Re: [PATCH 4/4] Kconfig: Make all Kconfig encoding ascii

2024-04-16 Thread Michal Simek




On 4/16/24 08:59, Francesco Dolcini wrote:

On Tue, Apr 16, 2024 at 02:36:12AM +0200, Tom Rini wrote:

On Mon, Apr 15, 2024 at 02:22:02PM +0200, Heinrich Schuchardt wrote:

On 15.04.24 13:35, Michal Simek wrote:

Some of Kconfigs are using utf-8 encoding because of used chars. Convert
all of them to ascii enconging.

Signed-off-by: Michal Simek 

[snip]

diff --git a/arch/arm/mach-rockchip/rv1126/Kconfig 
b/arch/arm/mach-rockchip/rv1126/Kconfig
index ae323ee91235..64a70f61f894 100644
--- a/arch/arm/mach-rockchip/rv1126/Kconfig
+++ b/arch/arm/mach-rockchip/rv1126/Kconfig
@@ -6,8 +6,8 @@ config TARGET_RV1126_NEU2
  Neu2:
  Neural Compute Module 2(Neu2) is a 96boards SoM-CB compute module
  based on Rockchip RV1126 from Edgeble AI.
- Neu2 powered with Consumer grade (0 to +80 °C) RV1126 SoC.
- Neu2k powered with Industrial grade (-40 °C to +85 °C) RV1126K SoC.
+ Neu2 powered with Consumer grade (0 to +80 C) RV1126 SoC.
+ Neu2k powered with Industrial grade (-40 C to +85 C) RV1126K SoC.


C is the sign for coulomb which is the unit of electric charge. How
about 'deg C'?


I'll note that in Linux there's seemingly nothing consistent, and I'm
fine with any of "deg C" or "degrees C" or "temperature range (-40 C to
+85 C)" as all of those should be clear in context.


My 2 cents ... while I agree with Tom that the context will make it
clear, it is not making it correct nor nice. Using just "C" for Celsius
degrees is horrible ...


I used deg C in v2 version.

Thanks,
Michal


Re: [PATCH] usb: musb-new: sunxi: support usage with DM_USB_GADGET

2024-04-16 Thread Mattijs Korpershoek
Hi,

On ven., avril 12, 2024 at 18:54, Aren  wrote:

> On Thu, Apr 11, 2024 at 04:46:17PM +1000, John Watts wrote:
>> On Sun, Dec 31, 2023 at 03:38:37PM -0500, Aren Moynihan wrote:
>> > Add support for building the sunxi-musb driver with DM_USB_GADGET
>> > including adding a separate IRQ handling function and registering the
>> > driver with the musb system differently.
>> 
>> Hi there,
>> 
>> Were you aware of this similar patch?
>> 
>> https://lore.kernel.org/u-boot/20230608195631.55364-1-cfswo...@gmail.com/
>> 
>> If not you might want to test it and compare it.
>> 
>> John.
>
> I was not aware of that patch, it looks like it does the same thing as
> this one, but without some of the bugs. When comparing with it I
> realized that my dm_usb_gadget_handle_interrupts function is just plain
> wrong.
>
> I'll try to find time to test it soon.

Please keep me in the loop for both progress on this one and on testing:

https://lore.kernel.org/u-boot/20230608195631.55364-1-cfswo...@gmail.com/

>
> Thanks for the link
>  - Aren
>
>> > The implementation of usb_gadget_register_driver from
>> > musb-new/musb_uboot.c only works when the gadget driver for the device
>> > has already been probed and has called musb_register. On the pinephone
>> > (using a allwinner a64 processor) this causes issues when trying to use
>> > usb gadget mode (such as from the ums command) and CONFIG_USB_ETHER is
>> > disabled.
>> > 
>> > The implementation of usb_gadget_register_driver provided when
>> > DM_USB_GADGET is enabled will probe the necessary drivers when it's
>> > called.
>> > 
>> > Without the patch, this is what the error condition looks like:
>> > => ums 0 mmc 1
>> > UMS: LUN 0, dev mmc 1, hwpart 0, sector 0x0, count 0x3a3e000
>> > Controller uninitialized
>> > g_dnl_register: failed!, error: -6
>> > g_dnl_register failed
>> > 
>> > based on:
>> > commit 2e4865bc6486 ("musb-new: omap2430: fix compiling in DM_USB_GADGET 
>> > config")
>> > 
>> > Signed-off-by: Aren Moynihan 


Re: [PATCH v2 12/16] arm: dts: k3-am625-sk-u-boot: Add sysreset-controller node

2024-04-16 Thread Mattijs Korpershoek
Hi Jon,

On jeu., avril 11, 2024 at 15:30, Jon Humphreys  wrote:

> Mattijs Korpershoek  writes:
>
>> Hi Jonathan,
>>
>> Thank you for the patch.
>>
>> On lun., avril 08, 2024 at 17:31, Jonathan Humphreys  
>> wrote:
>>
>>> Signed-off-by: Jonathan Humphreys 
>>
>> Please consider adding a commit message body.
>
> Got it.  thanks.
>
> BTW, the next version of this series will drop this patch as Andrew has
> submitted another patch removing the need for this one.  See
> https://lore.kernel.org/r/20240402160908.508974-1-...@ti.com.

I was not aware of that one. thank you for pointing it out. That seems
indeed a better solution.

>
>>
>> On the TI vendor tree, there is a similar patch with a commit message:
>> https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.04&id=c5296d943c2c84dd6dcb3b91305d006ac46f3157
>>
>> Before patch:
>> => reset
>> resetting ...
>> System reset not supported on this platform
>> ### ERROR ### Please RESET the board ###
>>
>> With patch applied:
>> => reset
>> resetting ...
>>
>> Tested-by: Mattijs Korpershoek  # on am62x sk evm
>>
>> Andrew also suggested to me that if we are interested by A53 reset only,
>> we can PSCI reset instead for all k3 architecture:
>>
>>  --- a/arch/arm/Kconfig
>>  +++ b/arch/arm/Kconfig
>>  @@ -784,6 +784,9 @@ config ARCH_K3
>>   bool "Texas Instruments' K3 Architecture"
>>   select SPL
>>   select SUPPORT_SPL
>>  +   select PSCI_RESET if ARM64
>>  +   select SYSRESET if ARM64
>>  +   select SYSRESET_PSCI if ARM64
>>   select FIT
>>   select REGEX
>>   select FIT_SIGNATURE if ARM64
>>
>> Has the above been considered?
>
> I am not aware.  I would think that you want full reset, unless you are
> thinking about specifying a reset level?

On my end, I was mostly interested in resetting from the A53 core, but
the solution you linked previously should work for me.

>
> Jon
>
>>
>>
>>> ---
>>>  arch/arm/dts/k3-am625-sk-u-boot.dtsi | 9 +
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi 
>>> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> index fa778b0ff4c..35bfeae75a0 100644
>>> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> @@ -46,3 +46,12 @@
>>>  &cpsw_port2 {
>>> status = "disabled";
>>>  };
>>> +
>>> +&dmsc {
>>> +   bootph-pre-ram;
>>> +
>>> +   k3_sysreset: sysreset-controller {
>>> +   compatible = "ti,sci-sysreset";
>>> +   bootph-pre-ram;
>>> +   };
>>> +};
>>> -- 
>>> 2.34.1


Re: [PATCH] usb: dwc3: support USB 3.1 controllers

2024-04-16 Thread Mattijs Korpershoek
Hi Caleb,;

Thank you for the patch.

On jeu., avril 11, 2024 at 18:05, Caleb Connolly  
wrote:

> The revision is different for these, add the additional check as in
> xhci-dwc3 core_init code.
>
> Signed-off-by: Caleb Connolly 

Reviewed-by: Mattijs Korpershoek 

> ---
>  drivers/usb/dwc3/core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 96e850b7170f..db045f5822d4 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -594,9 +594,10 @@ static int dwc3_core_init(struct dwc3 *dwc)
>   int ret;
>  
>   reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
>   /* This should read as U3 followed by revision number */
> - if ((reg & DWC3_GSNPSID_MASK) != 0x5533) {
> + if ((reg & DWC3_GSNPSID_MASK) != 0x5533 &&
> + (reg & DWC3_GSNPSID_MASK) != 0x3331) {
>   dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
>   ret = -ENODEV;
>   goto err0;
>   }
> -- 
> 2.44.0


Re: [PATCH 2/2] disk: expose partition type flags

2024-04-16 Thread Mattijs Korpershoek
Hi Caleb,

Thank you for the patch.

On mar., avril 09, 2024 at 15:55, Caleb Connolly  
wrote:

> GPT partition tables include two bytes worth of vendor defined
> attributes, per partition. ChromeOS and Qualcomm both use these (with
> different encoding!) to handle A/B slot switching with a retry counter.
>
> Expose these via the disk_partition struct so that they can be parsed by
> the relevant board code.
>
> This will be used on Qualcomm boards to determine which slot we're
> booting on so that we can flash capsule updates to the correct one.
>
> Signed-off-by: Caleb Connolly 

Reviewed-by: Mattijs Korpershoek 

> ---
>  disk/part_efi.c | 1 +
>  include/part.h  | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index 4ce9243ef25c..d3ce4dd01dcd 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -292,8 +292,9 @@ int part_get_info_efi(struct blk_desc *desc, int part,
>   snprintf((char *)info->name, sizeof(info->name), "%s",
>print_efiname(&gpt_pte[part - 1]));
>   strcpy((char *)info->type, "U-Boot");
>   info->bootable = get_bootable(&gpt_pte[part - 1]);
> + info->type_flags = gpt_pte[part - 
> 1].attributes.fields.type_guid_specific;
>   if (CONFIG_IS_ENABLED(PARTITION_UUIDS)) {
>   uuid_bin_to_str(gpt_pte[part - 1].unique_partition_guid.b,
>   (char *)disk_partition_uuid(info),
>   UUID_STR_FORMAT_GUID);
> diff --git a/include/part.h b/include/part.h
> index 32ee40488563..afae51f1b933 100644
> --- a/include/part.h
> +++ b/include/part.h
> @@ -68,8 +68,9 @@ struct disk_partition {
>* PART_BOOTABLEthe MBR bootable flag is set
>* PART_EFI_SYSTEM_PARTITIONthe partition is an EFI system partition
>*/
>   int bootable;
> + u16 type_flags; /* top 16 bits of GPT partition attributes  
> */
>  #if CONFIG_IS_ENABLED(PARTITION_UUIDS)
>   charuuid[UUID_STR_LEN + 1]; /* filesystem UUID as string, if exists 
> */
>  #endif
>  #ifdef CONFIG_PARTITION_TYPE_GUID
>
> -- 
> 2.44.0


Re: [PATCH 1/2] dfu: add scsi backend

2024-04-16 Thread Mattijs Korpershoek
Hi Caleb,

Thank you for the patch.

On mar., avril 09, 2024 at 15:55, Caleb Connolly  
wrote:

> This is extremely similar to the MMC backend, but there are some notable
> differences.
>
> Works with a DFU string like
>
> scsi 4=u-boot-bin part 11
>
> Where "4" is the SCSI dev number (sequential LUN across all SCSI devices)
> and "11" is the partition number.
>
> Signed-off-by: Caleb Connolly 
> ---
>  doc/usage/dfu.rst  |  31 
>  drivers/dfu/Kconfig|   7 +
>  drivers/dfu/Makefile   |   1 +
>  drivers/dfu/dfu.c  |   5 +-
>  drivers/dfu/dfu_scsi.c | 437 
> +
>  include/dfu.h  |  26 +++
>  6 files changed, 506 insertions(+), 1 deletion(-)
>
> diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst
> index 8cc09c308d82..dc4f8d672f99 100644
> --- a/doc/usage/dfu.rst
> +++ b/doc/usage/dfu.rst
> @@ -166,8 +166,38 @@ mmc

Can we also add this to the summary list at line 22?
"Today the supported DFU backends are:"

Also, please add CONFIG_DFU_SCSI in "Configuration Options" section at
the beginning of this document.

>  
>  Please note that this means the user will be able to execute any
>  arbitrary commands just like in the u-boot's shell.
>  
> +scsi
> +for UFS storage::
> +
> +dfu 0 scsi 
> +
> +each element in *dfu_alt_info* being
> +
> +*  raw   raw access to SCSI LUN
> +*  part   raw access to partition
> +*  fatfile in FAT partition
> +*  ext4   file in EXT4 partition
> +*  skip 0 0ignore flashed data
> +*  script 0 0  execute commands in shell
> +
> +with
> +
> +size
> +is the size of the access area (hexadecimal without "0x")
> +or 0 which means whole device
> +partid
> +is the GPT or DOS partition index.
> +dev
> +is the SCSI LU (Logical Unit) index (decimal only)
> +
> +A value of environment variable *dfu_alt_info* for UFS could be::
> +
> +u-boot part 4;bl2 raw 0x1e 0x1d
> +
> +See mmc section above for details on the skip and script types.
> +
>  nand
>  raw slc nand device::
>  
>   dfu 0 nand 
> @@ -277,8 +307,9 @@ alternate list separated by '&' with the same format for 
> each ::
>  
>  mmc =;;
>  nand =;;
>  ram =;;
> +scsi =;;
>  sf =;;
>  mtd =;;
>  virt =;;
>  
> diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
> index 0360d9da1427..158c660e6c4e 100644
> --- a/drivers/dfu/Kconfig
> +++ b/drivers/dfu/Kconfig
> @@ -86,8 +86,15 @@ config DFU_VIRT
> This option enables using DFU to read and write to VIRTUAL device
> used at board level to manage specific behavior
> (OTP update for example).
>  
> +config DFU_SCSI
> + bool "SCSI flash back end for DFU"
> + help
> +   This option enables using DFU to read and write to SCSI devices
> +   used at board level to manage specific behavior
> +   (OTP update for example).
> +
>  config SET_DFU_ALT_INFO
>   bool "Dynamic set of DFU alternate information"
>   help
> This option allows to call the function set_dfu_alt_info to
> diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
> index dfbf64da6677..3b3ba0994b3a 100644
> --- a/drivers/dfu/Makefile
> +++ b/drivers/dfu/Makefile
> @@ -10,4 +10,5 @@ obj-$(CONFIG_$(SPL_)DFU_NAND) += dfu_nand.o
>  obj-$(CONFIG_$(SPL_)DFU_RAM) += dfu_ram.o
>  obj-$(CONFIG_$(SPL_)DFU_SF) += dfu_sf.o
>  obj-$(CONFIG_$(SPL_)DFU_WRITE_ALT) += dfu_alt.o
>  obj-$(CONFIG_$(SPL_)DFU_VIRT) += dfu_virt.o
> +obj-$(CONFIG_$(SPL_)DFU_SCSI) += dfu_scsi.o
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index 2adf26e2fe24..8024ad98a7dc 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -548,8 +548,11 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char 
> *s, int alt,
>   return -1;
>   } else if (strcmp(interface, "virt") == 0) {
>   if (dfu_fill_entity_virt(dfu, devstr, argv, argc))
>   return -1;
> + } else if (strcmp(interface, "scsi") == 0) {
> + if (dfu_fill_entity_scsi(dfu, devstr, argv, argc))
> + return -1;
>   } else {
>   printf("%s: Device %s not (yet) supported!\n",
>  __func__,  interface);
>   return -1;
> @@ -644,9 +647,9 @@ int dfu_config_entities(char *env, char *interface, char 
> *devstr)
>  
>  const char *dfu_get_dev_type(enum dfu_device_type t)
>  {
>   const char *const dev_t[] = {NULL, "eMMC", "OneNAND", "NAND", "RAM",
> -  "SF", "MTD", "VIRT"};
> +  "SF", "MTD", "VIRT", "SCSI"};
>   return dev_t[t];
>  }
>  
>  const char *dfu_get_layout(enum dfu_layout l)
> diff --git a/drivers/dfu/dfu_scsi.c b/drivers/dfu/dfu_scsi.c
> new file mode 100644
> index ..63c3bcffe769
> --- /dev/null
> +++ b/drivers/dfu/

[PATCH v4 5/6] board: ti: am65x: Add check for k3-am654-icssg2 in board_fit_config_match()

2024-04-16 Thread MD Danish Anwar
When CONFIG_TI_ICSSG_PRUETH is enabled, add config name check for the
icssg2 overlay in board_fit_config_match() API.

Signed-off-by: MD Danish Anwar 
---
 board/ti/am65x/evm.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index 3109c9a2ac..07073a5940 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -91,10 +91,13 @@ int dram_init_banksize(void)
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
-#ifdef CONFIG_TARGET_AM654_A53_EVM
-   if (!strcmp(name, "k3-am654-base-board"))
+   if (IS_ENABLED(CONFIG_TI_ICSSG_PRUETH) &&
+   strcmp(name, "k3-am654-icssg2") == 0)
+   return 0;
+
+   if (IS_ENABLED(CONFIG_TARGET_AM654_A53_EVM) &&
+   strcmp(name, "k3-am654-base-board") == 0)
return 0;
-#endif
 
return -1;
 }
-- 
2.34.1



[PATCH v4 3/6] configs: am65x_evm_a53: Enable ICSSG Driver

2024-04-16 Thread MD Danish Anwar
Enable ICSSG driver in am65x_evm_a53_defconfig

Signed-off-by: MD Danish Anwar 
---
 configs/am65x_evm_a53_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 3afa80f45a..f06186ed8d 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -129,6 +129,7 @@ CONFIG_PHY_FIXED=y
 CONFIG_E1000=y
 CONFIG_CMD_E1000=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_TI_ICSSG_PRUETH=y
 CONFIG_PCI_KEYSTONE=y
 CONFIG_PHY=y
 CONFIG_SPL_PHY=y
-- 
2.34.1



[PATCH v4 6/6] board: ti: am65x: Set fw_storage_interface and fw_dev_part ENVs

2024-04-16 Thread MD Danish Anwar
When ICSSG driver is enabled (CONFIG_TI_ICSSG_PRUETH=y) set
storage_interface and fw_dev_part env variables.

These variables need be set appropriately in order to load differnet
ICSSG firmwares needed for ICSSG driver. By default the storage
interface is mmc and the partition is 1:2. User can modify this based on
their needs.

Signed-off-by: MD Danish Anwar 
---
 board/ti/am65x/am65x.env | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 814374d68c..631997e4c9 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -27,3 +27,7 @@ get_fdt_ubi=ubifsload ${fdtaddr} ${bootdir}/${name_fdt}
 args_ubi=setenv bootargs console=${console} ${optargs}
 rootfstype=ubifs root=ubi0:rootfs rw ubi.mtd=ospi.rootfs
 
+#if CONFIG_TI_ICSSG_PRUETH
+storage_interface=mmc
+fw_dev_part=1:2
+#endif
-- 
2.34.1



[PATCH v4 1/6] arm: dts: k3-am654-base-board: Add ICSSG2 Ethernet support

2024-04-16 Thread MD Danish Anwar
ICSSG2 provides dual Gigabit Ethernet support.
Add ICSSG2 ethernet node to an overlay k3-am654-icssg2.dtso

Signed-off-by: MD Danish Anwar 
---
 arch/arm/dts/Makefile |   4 +-
 arch/arm/dts/k3-am654-icssg2.dtso | 145 ++
 2 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/k3-am654-icssg2.dtso

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 08dfbdd557..a58e700bf7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1326,7 +1326,9 @@ dtb-$(CONFIG_SOC_K3_AM654) += \
k3-am6548-iot2050-advanced-pg2.dtb \
k3-am6548-iot2050-advanced-m2.dtb \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo \
-   k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo
+   k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo \
+   k3-am654-icssg2.dtbo
+
 dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
  k3-j721e-r5-common-proc-board.dtb \
  k3-j7200-common-proc-board.dtb \
diff --git a/arch/arm/dts/k3-am654-icssg2.dtso 
b/arch/arm/dts/k3-am654-icssg2.dtso
new file mode 100644
index 00..faefa2febc
--- /dev/null
+++ b/arch/arm/dts/k3-am654-icssg2.dtso
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * DT overlay for enabling ICSSG2 on AM654 EVM
+ *
+ * Copyright (C) 2018-2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include 
+#include "k3-pinctrl.h"
+
+&{/} {
+   aliases {
+   ethernet1 = "/icssg2-eth/ethernet-ports/port@0";
+   ethernet2 = "/icssg2-eth/ethernet-ports/port@1";
+   };
+
+   /* Ethernet node on PRU-ICSSG2 */
+   icssg2_eth: icssg2-eth {
+   compatible = "ti,am654-icssg-prueth";
+   pinctrl-names = "default";
+   pinctrl-0 = <&icssg2_rgmii_pins_default>;
+   sram = <&msmc_ram>;
+   ti,prus = <&pru2_0>, <&rtu2_0>, <&tx_pru2_0>,
+   <&pru2_1>, <&rtu2_1>, <&tx_pru2_1>;
+   firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
+   "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
+   "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
+   "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
+   "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
+   "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
+
+   ti,pruss-gp-mux-sel = <2>,  /* MII mode */
+ <2>,
+ <2>,
+ <2>,  /* MII mode */
+ <2>,
+ <2>;
+
+   ti,mii-g-rt = <&icssg2_mii_g_rt>;
+   ti,mii-rt = <&icssg2_mii_rt>;
+   ti,iep = <&icssg2_iep0>, <&icssg2_iep1>;
+
+   interrupt-parent = <&icssg2_intc>;
+   interrupts = <24 0 2>, <25 1 3>;
+   interrupt-names = "tx_ts0", "tx_ts1";
+
+   dmas = <&main_udmap 0xc300>, /* egress slice 0 */
+  <&main_udmap 0xc301>, /* egress slice 0 */
+  <&main_udmap 0xc302>, /* egress slice 0 */
+  <&main_udmap 0xc303>, /* egress slice 0 */
+  <&main_udmap 0xc304>, /* egress slice 1 */
+  <&main_udmap 0xc305>, /* egress slice 1 */
+  <&main_udmap 0xc306>, /* egress slice 1 */
+  <&main_udmap 0xc307>, /* egress slice 1 */
+  <&main_udmap 0x4300>, /* ingress slice 0 */
+  <&main_udmap 0x4301>; /* ingress slice 1 */
+
+   dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
+   "tx1-0", "tx1-1", "tx1-2", "tx1-3",
+   "rx0", "rx1";
+   ethernet-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   icssg2_emac0: port@0 {
+   reg = <0>;
+   phy-handle = <&icssg2_phy0>;
+   phy-mode = "rgmii-id";
+   ti,syscon-rgmii-delay = <&scm_conf 0x4120>;
+   /* Filled in by bootloader */
+   local-mac-address = [00 00 00 00 00 00];
+   };
+   icssg2_emac1: port@1 {
+   reg = <1>;
+   phy-handle = <&icssg2_phy1>;
+   phy-mode = "rgmii-id";
+   ti,syscon-rgmii-delay = <&scm_conf 0x4124>;
+   /* Filled in by bootloader */
+   local-mac-address = [00 00 00 00 00 00];
+   };
+   

[PATCH v4 4/6] configs: am65x_evm_a53: add SPL_LOAD_FIT_APPLY_OVERLAY

2024-04-16 Thread MD Danish Anwar
We want SPL to apply DTB overlays (e.g. ICSSG2 overlay) so enable
SPL_LOAD_FIT_APPLY_OVERLAY.

Signed-off-by: MD Danish Anwar 
---
 configs/am65x_evm_a53_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index f06186ed8d..d2f35dc2fb 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -68,6 +68,7 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_REMOTEPROC=y
+CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_TIME=y
 CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"
-- 
2.34.1



[PATCH v4 0/6] Enable ICSSG Ethernet Driver for AM65x

2024-04-16 Thread MD Danish Anwar
The series introduces device tree and config changes and AM65x
to enable ICSSG driver. The series also enables SPL_LOAD_FIT_APPLY_OVERLAY
for AM65x in order to load overlay over spl.

The ICSSG2 node is added in device tree overlay so that it remains in
sync with linux kernel.

This series has been tested on AM65x SR2.0, and the ICSSG interface is
able to ping / dhcp and boot kernel using tftp in uboot.

The users need to set env variables fw_storage_interface, fw_dev_part,
fw_ubi_mtdpart, fw_ubi_volume to indicate which storage medium and
partition they want to use to load firmware files from. By default the env
fw_storage_interface=mmc and fw_dev_part=1:2 but users can modify these
envs as per their requirements.

This is the v4 of the series [1]. The series doesn't depend on any patch
and can be applied cleanly on u-boot/master

Changes from v3 to v4:
*) Separated the device tree and board specific changes into this series
   from the main series [1].
*) Added check for TARGET_AM654_A53_EVM config in board file as suggested
   by Dan Carpenter 
*) Rebased on latest u-boot/master.

[1] https://lore.kernel.org/all/20240124064930.1787929-1-danishan...@ti.com/

MD Danish Anwar (6):
  arm: dts: k3-am654-base-board: Add ICSSG2 Ethernet support
  arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration
  configs: am65x_evm_a53: Enable ICSSG Driver
  configs: am65x_evm_a53: add SPL_LOAD_FIT_APPLY_OVERLAY
  board: ti: am65x: Add check for k3-am654-icssg2 in
board_fit_config_match()
  board: ti: am65x: Set fw_storage_interface and fw_dev_part ENVs

 arch/arm/dts/Makefile |   4 +-
 arch/arm/dts/k3-am654-icssg2.dtso | 145 ++
 arch/arm/dts/k3-am65x-binman.dtsi |  65 +-
 board/ti/am65x/am65x.env  |   4 +
 board/ti/am65x/evm.c  |   9 +-
 configs/am65x_evm_a53_defconfig   |   2 +
 6 files changed, 221 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/dts/k3-am654-icssg2.dtso


base-commit: 6e316e3f397b5e01e98c5dd56cdbaab961daeedf
-- 
2.34.1



[PATCH v4 2/6] arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration

2024-04-16 Thread MD Danish Anwar
Add ICSSG2 overlay and configuration to tispl and u-boot images.

Signed-off-by: MD Danish Anwar 
---
 arch/arm/dts/k3-am65x-binman.dtsi | 65 +--
 1 file changed, 61 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/k3-am65x-binman.dtsi 
b/arch/arm/dts/k3-am65x-binman.dtsi
index 8cc24da1f3..d0cd4889cd 100644
--- a/arch/arm/dts/k3-am65x-binman.dtsi
+++ b/arch/arm/dts/k3-am65x-binman.dtsi
@@ -98,6 +98,8 @@
 #define SPL_AM654_EVM_DTB "spl/dts/k3-am654-base-board.dtb"
 #define AM654_EVM_DTB "u-boot.dtb"
 
+#define AM654_EVM_ICSSG2_DTBO "arch/arm/dts/k3-am654-icssg2.dtbo"
+
 &binman {
ti-spl {
insert-template = <&ti_spl_template>;
@@ -124,6 +126,20 @@
filename = SPL_AM654_EVM_DTB;
};
};
+
+   fdt-1 {
+   description = "k3-am654-icssg2 overlay";
+   type = "flat_dt";
+   arch = "arm";
+   compression = "none";
+   ti-secure {
+   content = 
<&spl_am65x_evm_icssg2_dtb>;
+   keyfile = "custMpk.pem";
+   };
+   spl_am65x_evm_icssg2_dtb: blob-ext {
+   filename = 
AM654_EVM_ICSSG2_DTBO;
+   };
+   };
};
 
configurations {
@@ -133,7 +149,7 @@
description = "k3-am654-base-board";
firmware = "atf";
loadables = "tee", "dm", "spl";
-   fdt = "fdt-0";
+   fdt = "fdt-0", "fdt-1";
};
};
};
@@ -168,6 +184,24 @@
};
};
 
+   fdt-1 {
+   description = "k3-am654-icssg2 overlay";
+   type = "flat_dt";
+   arch = "arm";
+   compression = "none";
+   ti-secure {
+   content = 
<&am65x_evm_icssg2_dtb>;
+   keyfile = "custMpk.pem";
+
+   };
+   am65x_evm_icssg2_dtb: blob-ext {
+   filename = 
AM654_EVM_ICSSG2_DTBO;
+   };
+   hash {
+   algo = "crc32";
+   };
+   };
+
};
 
configurations {
@@ -177,7 +211,7 @@
description = "k3-am654-base-board";
firmware = "uboot";
loadables = "uboot";
-   fdt = "fdt-0";
+   fdt = "fdt-0", "fdt-1";
};
};
};
@@ -205,6 +239,16 @@
filename = SPL_AM654_EVM_DTB;
};
};
+
+   fdt-1 {
+   description = "k3-am654-icssg2 overlay";
+   type = "flat_dt";
+   arch = "arm";
+   compression = "none";
+   blob {
+   filename = 
AM654_EVM_ICSSG2_DTBO;
+   };
+   };
};
 
configurations {
@@ -214,7 +258,7 @@
description = "k3-am654-base-board";
firmware = "atf";
loadables = "tee", "dm", "spl";
-   fdt = "fdt-0";
+   fdt = "fdt-0", "fdt-1";
};
};
};
@@ -243,6 +287,19 @@
algo = "crc32";
};
  

Re: [PATCH] usb: dwc2: Add in version 4xx compatibility

2024-04-16 Thread Mattijs Korpershoek
Hi Greg,

Thank you for the contribution.

On mar., mars 26, 2024 at 11:36, Greg Malysa  wrote:

Please avoid top-posting when replying, it makes following the
discussion more difficult:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions

> I'd be happy with that change. Does anyone have access to the
> associated designware databook (I do not)? We could also check to see
> if those four bits are all always allocated to the 2/3/4/x version
> number. I can submit v2 with that change instead once we know.

I don't have access to the databooks either. I usually refer to the
linux kernel code since it's a more up to date version of this driver.

Looking at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65dc2e725286106f99c6f6b78e3d9c52c15f3a9c

we can see that the following is added:
#define DWC2_CORE_REV_MASK  0x

This makes me believe that the versioning follows a well known pattern.

>
> On Tue, Mar 26, 2024 at 7:50 AM Marek Vasut  wrote:
>>
>> On 3/26/24 3:32 AM, Greg Malysa wrote:
>> > From: Nathan Barrett-Morrison 
>> >
>> > This adds the Synopsys device id for version 4xx of the designware
>> > IP block and extends the version check to include it to permit
>> > new hardware to run. It does not add any 4xx-specific features.
>> >
>> > Signed-off-by: Ian Roberts 
>> > Signed-off-by: Greg Malysa 
>> > Signed-off-by: Nathan Barrett-Morrison 
>> >
>> > ---
>> >
>> >
>> > ---
>> >   drivers/usb/host/dwc2.c | 3 ++-
>> >   drivers/usb/host/dwc2.h | 1 +
>> >   2 files changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
>> > index 637eb2dd06..6fdde6a9a7 100644
>> > --- a/drivers/usb/host/dwc2.c
>> > +++ b/drivers/usb/host/dwc2.c
>> > @@ -1180,7 +1180,8 @@ static int dwc2_init_common(struct udevice *dev, 
>> > struct dwc2_priv *priv)
>> >snpsid >> 12 & 0xf, snpsid & 0xfff);
>> >
>> >   if ((snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_2xx &&
>> > - (snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_3xx) {
>> > + (snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_3xx &&
>> > + (snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_4xx) {

Note that this change is also part of:
https://lore.kernel.org/all/20240328131811.94559-1-seashell11234...@gmail.com/

>> >   dev_info(dev, "SNPSID invalid (not DWC2 OTG device): %08x\n",
>> >snpsid);
>> >   return -ENODEV;
>> > diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
>> > index 6f022e33a1..f202d55eb2 100644
>> > --- a/drivers/usb/host/dwc2.h
>> > +++ b/drivers/usb/host/dwc2.h
>> > @@ -739,6 +739,7 @@ struct dwc2_core_regs {
>> >   #define DWC2_PCGCCTL_DEEP_SLEEP_OFFSET  7
>> >   #define DWC2_SNPSID_DEVID_VER_2xx   (0x4f542 << 12)
>> >   #define DWC2_SNPSID_DEVID_VER_3xx   (0x4f543 << 12)
>> > +#define DWC2_SNPSID_DEVID_VER_4xx(0x4f544 << 12)
>> >   #define DWC2_SNPSID_DEVID_MASK  (0xf << 
>> > 12)
>> >   #define DWC2_SNPSID_DEVID_OFFSET12
>>
>> Maybe it would be better/easier/futureproof to simply check if (snpsid &
>> 0x0 == 0x4f540) ?
>
>
>
> -- 
> Greg Malysa
> Timesys Corporation


Re: [PATCH] usb: dwc2: update reset method for host and device mode

2024-04-16 Thread Mattijs Korpershoek
On mar., avril 16, 2024 at 10:50, Mattijs Korpershoek 
 wrote:

> Hi Kongyang,
>
> Thank you for the patch.
>
> On jeu., mars 28, 2024 at 21:14, Kongyang Liu  
> wrote:
>
>> Starting from version 4.20a, there has been a change in the reset method.
>> A new bit, GRSTCTL_CSFTRST_DONE, has been introduced in the GRSTCTL
>> register to indicate whether the reset has been completed.
>>
>> Signed-off-by: Kongyang Liu 
>
> I've compared this with the equivalent Linux patch found here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65dc2e725286106f99c6f6b78e3d9c52c15f3a9c
>
> Reviewed-by: Mattijs Korpershoek 
>
> Also tested on VIM3 that I could use fastboot.
>
> Tested-by: Mattijs Korpershoek  # on vim3
>
> I will add the linux link in the commit message when applying. Please
> consider adding it yourself if you receive review comments that require
> sending a v2.

Just noticed that this also touches the host part of the driver.

Marek, do you want to review/pick this up, or can this go through
u-boot-dfu ?

>
> Thanks
> Mattijs
>
>> ---
>>
>>  drivers/usb/gadget/dwc2_udc_otg.c  | 18 --
>>  drivers/usb/gadget/dwc2_udc_otg_regs.h | 19 +--
>>  drivers/usb/host/dwc2.c| 19 ---
>>  drivers/usb/host/dwc2.h|  6 ++
>>  4 files changed, 51 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
>> b/drivers/usb/gadget/dwc2_udc_otg.c
>> index 27082f5152..d1dd469a0f 100644
>> --- a/drivers/usb/gadget/dwc2_udc_otg.c
>> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
>> @@ -42,7 +42,7 @@
>>  #include 
>>  #include 
>>  
>> -#include 
>> +#include 
>>  
>>  #include 
>>  
>> @@ -464,12 +464,26 @@ static void reconfig_usbd(struct dwc2_udc *dev)
>>  {
>>  /* 2. Soft-reset OTG Core and then unreset again. */
>>  int i;
>> -unsigned int uTemp = writel(CORE_SOFT_RESET, ®->grstctl);
>> +unsigned int uTemp;
>>  uint32_t dflt_gusbcfg;
>>  uint32_t rx_fifo_sz, tx_fifo_sz, np_tx_fifo_sz;
>>  u32 max_hw_ep;
>>  int pdata_hw_ep;
>>  
>> +u32 snpsid, greset;
>> +
>> +snpsid = readl(®->gsnpsid);
>> +writel(CORE_SOFT_RESET, ®->grstctl);
>> +if ((snpsid & SNPSID_VER_MASK) < (SNPSID_VER_420a & SNPSID_VER_MASK)) {
>> +wait_for_bit_le32(®->grstctl, CORE_SOFT_RESET, false, 1000, 
>> false);
>> +} else {
>> +wait_for_bit_le32(®->grstctl, CORE_SOFT_RESET_DONE, true, 
>> 1000, false);
>> +greset = readl(®->grstctl);
>> +greset &= ~CORE_SOFT_RESET;
>> +greset |= CORE_SOFT_RESET_DONE;
>> +writel(greset, ®->grstctl);
>> +}
>> +
>>  debug("Resetting OTG controller\n");
>>  
>>  dflt_gusbcfg =
>> diff --git a/drivers/usb/gadget/dwc2_udc_otg_regs.h 
>> b/drivers/usb/gadget/dwc2_udc_otg_regs.h
>> index 9ca6f42375..b3d9117033 100644
>> --- a/drivers/usb/gadget/dwc2_udc_otg_regs.h
>> +++ b/drivers/usb/gadget/dwc2_udc_otg_regs.h
>> @@ -63,24 +63,26 @@ struct dwc2_usbotg_reg {
>>  u32 gnptxfsiz; /* Non-Periodic Transmit FIFO Size */
>>  u8  res0[12];
>>  u32 ggpio; /* 0x038 */
>> -u8  res1[20];
>> +u8  res1[4];
>> +u32 gsnpsid;
>> +u8  res2[12];
>>  u32 ghwcfg4; /* User HW Config4 */
>> -u8  res2[176];
>> +u8  res3[176];
>>  u32 dieptxf[15]; /* Device Periodic Transmit FIFO size register */
>> -u8  res3[1728];
>> +u8  res4[1728];
>>  /* Device Configuration */
>>  u32 dcfg; /* Device Configuration Register */
>>  u32 dctl; /* Device Control */
>>  u32 dsts; /* Device Status */
>> -u8  res4[4];
>> +u8  res5[4];
>>  u32 diepmsk; /* Device IN Endpoint Common Interrupt Mask */
>>  u32 doepmsk; /* Device OUT Endpoint Common Interrupt Mask */
>>  u32 daint; /* Device All Endpoints Interrupt */
>>  u32 daintmsk; /* Device All Endpoints Interrupt Mask */
>> -u8  res5[224];
>> +u8  res6[224];
>>  struct dwc2_dev_in_endp in_endp[16];
>>  struct dwc2_dev_out_endp out_endp[16];
>> -u8  res6[768];
>> +u8  res7[768];
>>  struct ep_fifo ep[16];
>>  };
>>  
>> @@ -118,6 +120,7 @@ struct dwc2_usbotg_reg {
>>  /* DWC2_UDC_OTG_GRSTCTL */
>>  #define AHB_MASTER_IDLE (1u<<31)
>>  #define CORE_SOFT_RESET (0x1<<0)
>> +#define CORE_SOFT_RESET_DONE(0x1<<29)
>>  
>>  /* DWC2_UDC_OTG_GINTSTS/DWC2_UDC_OTG_GINTMSK core interrupt register */
>>  #define INT_RESUME  (1u<<31)
>> @@ -285,6 +288,10 @@ struct dwc2_usbotg_reg {
>>  #define DAINT_IN_EP_INT(x)(x << 0)
>>  #define DAINT_OUT_EP_INT(x)   (x << 16)
>>  
>> +/* DWC2_UDC_OTG_GSNPSID */
>> +#define SNPSID_VER_420a 0x4f54420a
>> +#define SNPSID_VER_MASK 0x
>> +
>>  /* User HW Config4 */
>>  #define GHWCFG4_NUM_IN_EPS_MASK (0xf << 26)
>>  #define GHWCFG4_NUM_IN

Re: [PATCH] usb: dwc2: update reset method for host and device mode

2024-04-16 Thread Mattijs Korpershoek
Hi Kongyang,

Thank you for the patch.

On jeu., mars 28, 2024 at 21:14, Kongyang Liu  
wrote:

> Starting from version 4.20a, there has been a change in the reset method.
> A new bit, GRSTCTL_CSFTRST_DONE, has been introduced in the GRSTCTL
> register to indicate whether the reset has been completed.
>
> Signed-off-by: Kongyang Liu 

I've compared this with the equivalent Linux patch found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65dc2e725286106f99c6f6b78e3d9c52c15f3a9c

Reviewed-by: Mattijs Korpershoek 

Also tested on VIM3 that I could use fastboot.

Tested-by: Mattijs Korpershoek  # on vim3

I will add the linux link in the commit message when applying. Please
consider adding it yourself if you receive review comments that require
sending a v2.

Thanks
Mattijs

> ---
>
>  drivers/usb/gadget/dwc2_udc_otg.c  | 18 --
>  drivers/usb/gadget/dwc2_udc_otg_regs.h | 19 +--
>  drivers/usb/host/dwc2.c| 19 ---
>  drivers/usb/host/dwc2.h|  6 ++
>  4 files changed, 51 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
> b/drivers/usb/gadget/dwc2_udc_otg.c
> index 27082f5152..d1dd469a0f 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
> @@ -42,7 +42,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include 
>  
> @@ -464,12 +464,26 @@ static void reconfig_usbd(struct dwc2_udc *dev)
>  {
>   /* 2. Soft-reset OTG Core and then unreset again. */
>   int i;
> - unsigned int uTemp = writel(CORE_SOFT_RESET, ®->grstctl);
> + unsigned int uTemp;
>   uint32_t dflt_gusbcfg;
>   uint32_t rx_fifo_sz, tx_fifo_sz, np_tx_fifo_sz;
>   u32 max_hw_ep;
>   int pdata_hw_ep;
>  
> + u32 snpsid, greset;
> +
> + snpsid = readl(®->gsnpsid);
> + writel(CORE_SOFT_RESET, ®->grstctl);
> + if ((snpsid & SNPSID_VER_MASK) < (SNPSID_VER_420a & SNPSID_VER_MASK)) {
> + wait_for_bit_le32(®->grstctl, CORE_SOFT_RESET, false, 1000, 
> false);
> + } else {
> + wait_for_bit_le32(®->grstctl, CORE_SOFT_RESET_DONE, true, 
> 1000, false);
> + greset = readl(®->grstctl);
> + greset &= ~CORE_SOFT_RESET;
> + greset |= CORE_SOFT_RESET_DONE;
> + writel(greset, ®->grstctl);
> + }
> +
>   debug("Resetting OTG controller\n");
>  
>   dflt_gusbcfg =
> diff --git a/drivers/usb/gadget/dwc2_udc_otg_regs.h 
> b/drivers/usb/gadget/dwc2_udc_otg_regs.h
> index 9ca6f42375..b3d9117033 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg_regs.h
> +++ b/drivers/usb/gadget/dwc2_udc_otg_regs.h
> @@ -63,24 +63,26 @@ struct dwc2_usbotg_reg {
>   u32 gnptxfsiz; /* Non-Periodic Transmit FIFO Size */
>   u8  res0[12];
>   u32 ggpio; /* 0x038 */
> - u8  res1[20];
> + u8  res1[4];
> + u32 gsnpsid;
> + u8  res2[12];
>   u32 ghwcfg4; /* User HW Config4 */
> - u8  res2[176];
> + u8  res3[176];
>   u32 dieptxf[15]; /* Device Periodic Transmit FIFO size register */
> - u8  res3[1728];
> + u8  res4[1728];
>   /* Device Configuration */
>   u32 dcfg; /* Device Configuration Register */
>   u32 dctl; /* Device Control */
>   u32 dsts; /* Device Status */
> - u8  res4[4];
> + u8  res5[4];
>   u32 diepmsk; /* Device IN Endpoint Common Interrupt Mask */
>   u32 doepmsk; /* Device OUT Endpoint Common Interrupt Mask */
>   u32 daint; /* Device All Endpoints Interrupt */
>   u32 daintmsk; /* Device All Endpoints Interrupt Mask */
> - u8  res5[224];
> + u8  res6[224];
>   struct dwc2_dev_in_endp in_endp[16];
>   struct dwc2_dev_out_endp out_endp[16];
> - u8  res6[768];
> + u8  res7[768];
>   struct ep_fifo ep[16];
>  };
>  
> @@ -118,6 +120,7 @@ struct dwc2_usbotg_reg {
>  /* DWC2_UDC_OTG_GRSTCTL */
>  #define AHB_MASTER_IDLE  (1u<<31)
>  #define CORE_SOFT_RESET  (0x1<<0)
> +#define CORE_SOFT_RESET_DONE (0x1<<29)
>  
>  /* DWC2_UDC_OTG_GINTSTS/DWC2_UDC_OTG_GINTMSK core interrupt register */
>  #define INT_RESUME   (1u<<31)
> @@ -285,6 +288,10 @@ struct dwc2_usbotg_reg {
>  #define DAINT_IN_EP_INT(x)(x << 0)
>  #define DAINT_OUT_EP_INT(x)   (x << 16)
>  
> +/* DWC2_UDC_OTG_GSNPSID */
> +#define SNPSID_VER_420a  0x4f54420a
> +#define SNPSID_VER_MASK  0x
> +
>  /* User HW Config4 */
>  #define GHWCFG4_NUM_IN_EPS_MASK  (0xf << 26)
>  #define GHWCFG4_NUM_IN_EPS_SHIFT 26
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index 637eb2dd06..1baeff96ee 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -159,6 +159,7 @@ static void dwc_otg_core_reset(struct udevice *dev,
>  struct dwc2_core_regs 

[PATCH] clk: zynq: Fix EMIO clock use detection for gem0

2024-04-16 Thread Ondřej Jirman
From: Ondrej Jirman 

According to TRM, the bit that differentiates between MIO and EMIO
clocks is bit 6. This resolves failure to set clock when using EMIO
clock for ethernet.

Signed-off-by: Ondrej Jirman 
---
 drivers/clk/clk_zynq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk_zynq.c b/drivers/clk/clk_zynq.c
index e3cefe2e0c72..78e6886a000c 100644
--- a/drivers/clk/clk_zynq.c
+++ b/drivers/clk/clk_zynq.c
@@ -42,6 +42,8 @@
 #define CLK_CTRL_DIV3X_SHIFT   20
 #define CLK_CTRL_DIV3X_MASK(ZYNQ_CLK_MAXDIV << CLK_CTRL_DIV3X_SHIFT)
 
+#define CLK_CTRL_GEM_EMIO  (1u << 6)
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #ifndef CONFIG_SPL_BUILD
@@ -161,7 +163,7 @@ static enum zynq_clk_rclk zynq_clk_get_gem_rclk(enum 
zynq_clk id)
else
clk_ctrl = readl(&slcr_base->gem1_rclk_ctrl);
 
-   srcsel = (clk_ctrl & CLK_CTRL_SRCSEL_MASK) >> CLK_CTRL_SRCSEL_SHIFT;
+   srcsel = (clk_ctrl & CLK_CTRL_GEM_EMIO);
if (srcsel)
return emio_clk;
else
-- 
2.44.0



  1   2   >