Re: [PATCH v6] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

2024-03-19 Thread MD Danish Anwar
Hi Tom,

On 20/03/24 4:10 am, Tom Rini wrote:
> On Wed, Feb 28, 2024 at 05:36:45PM +0530, MD Danish Anwar wrote:
> 
>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>> same firmware.
>>
>> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
>> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
>> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
>> load the firmware file to the remote processor and start the remote
>> processor.
>>
>> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
>> Kconfig so that we can call request_firmware_into_buf() from remoteproc
>> driver.
>>
>> Signed-off-by: MD Danish Anwar 
>> Acked-by: Ravi Gunasekaran 
>> Reviewed-by: Roger Quadros 
>> ---
>> Changes from v5 to v6:
>> *) Collected Acked-by tag from Ravi Gunasekaran 
>> *) Fixed few typos as pointed out by Roger Quadros 
>> *) Added if condition to check if uc_pdata->fw_name exists and free it
>>before the strndup as suggested by Roger Quadros 
>>
>> Changes from v4 to v5:
>> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>>that can be loaded to a rproc.
>> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
>> *) Allocating the address at a later point in rproc_boot()
>> *) Rebased on latest u-boot/master [commit 
>>9e00b6993f724da9699ef12573307afea8c19284]
>>
>> Changes from v3 to v4:
>> *) No functional change. Splitted the patch out of the series as suggested
>>by Nishant.
>> *) Droppped the RFC tag.
>>
>> v5: https://lore.kernel.org/all/20240217122602.3402774-1-danishan...@ti.com/
>> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
>> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>>
>>  drivers/remoteproc/Kconfig|   8 +++
>>  drivers/remoteproc/rproc-uclass.c | 102 ++
>>  include/remoteproc.h  |  34 ++
>>  3 files changed, 144 insertions(+)
>>
>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>> index 781de530af..9f9877931c 100644
>> --- a/drivers/remoteproc/Kconfig
>> +++ b/drivers/remoteproc/Kconfig
>> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>>  # All users should depend on DM
>>  config REMOTEPROC
>>  bool
>> +select FS_LOADER
>>  depends on DM
>>  
>>  # Please keep the configuration alphabetically sorted.
> 
> Can we not make the FS_LOADER portion optional? I didn't realize how
> many non-TI platforms this impacted. And even then it's possible I
> assume that custom designs will load the firmwares in other manners.
> 

Yes we can. We can wrap the remoteproc APIs using FS_LOADER in #ifdef
CONFIG_FS_LOADER. And instead of REMOTEPROC driver selecting FS_LOADER,
the clinet driver (ICSSG in this case) who is calling those remoteproc
APIs will select FS_LOADER and enable it.

This will make sure that other platforms (ti or non-ti) that doesn't
support ICSSG but enables Remoteproc, will not enable FS_LOADER. This
way we are not forcing other platforms using remoteproc to enable
FS_LOADER. In this case the APIs will not get built.

Now FS_LOADER will only be enabled when there is a client driver that
uses rproc_boot() APIs. It's upto the client driver to enable FS_LOADER

below is the diff,

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 9f9877931c..a49802c132 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -10,7 +10,6 @@ menu "Remote Processor drivers"
 # All users should depend on DM
 config REMOTEPROC
bool
-   select FS_LOADER
depends on DM

 # Please keep the configuration alphabetically sorted.
diff --git a/drivers/remoteproc/rproc-uclass.c
b/drivers/remoteproc/rproc-uclass.c
index f4f22a3851..a6a8be5009 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -994,6 +994,7 @@ int rproc_set_firmware(struct udevice *rproc_dev,
const char *fw_name)
return 0;
 }

+#ifdef CONFIG_FS_LOADER
 int rproc_boot(struct udevice *rproc_dev)
 {
struct dm_rproc_uclass_pdata *uc_pdata;
@@ -1063,3 +1064,4 @@ free_buffer:
free(addr);
return ret;
 }
+#endif

Let me know if this looks ok. If it's ok I will post v7 with this change.

-- 
Thanks and Regards,
Danish


Re: [PATCH v3 09/14] serial: msm-geni: support livetree

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> When using OF_LIVE, the debug UART driver won't be probed if it's a
> subnode of the geni-se-qup controller. Add a NOP driver for the
> controller to correctly discover its child nodes.
>
> Reviewed-by: Neil Armstrong 
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/serial/serial_msm_geni.c | 13 +
>  1 file changed, 13 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/drivers/serial/serial_msm_geni.c 
> b/drivers/serial/serial_msm_geni.c
> index 4aa0bc8c72bc..5260474fb9a4 100644
> --- a/drivers/serial/serial_msm_geni.c
> +++ b/drivers/serial/serial_msm_geni.c
> @@ -605,8 +605,21 @@ U_BOOT_DRIVER(serial_msm_geni) = {
> .ops = _serial_ops,
> .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
>  };
>
> +static const struct udevice_id geniqup_ids[] = {
> +   { .compatible = "qcom,geni-se-qup" },
> +   { }
> +};
> +
> +U_BOOT_DRIVER(geni_se_qup) = {
> +   .name = "geni-se-qup",
> +   .id = UCLASS_NOP,
> +   .of_match = geniqup_ids,
> +   .bind = dm_scan_fdt_dev,
> +   .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
> +};
> +
>  #ifdef CONFIG_DEBUG_UART_MSM_GENI
>
>  static struct msm_serial_data init_serial_data = {
> .base = CONFIG_VAL(DEBUG_UART_BASE)
>
> --
> 2.44.0
>


Re: [PATCH v3 08/14] gpio: msm_gpio: add .set_flags op

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> The .direction_input and .direction_output ops are deprecated, and don't
> seem to behave properly for us. Implement our own .set_flags op to
> handle this correctly.
>
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/gpio/msm_gpio.c | 27 +--
>  1 file changed, 21 insertions(+), 6 deletions(-)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/drivers/gpio/msm_gpio.c b/drivers/gpio/msm_gpio.c
> index 5e57b0cbde75..f5d9ab54e817 100644
> --- a/drivers/gpio/msm_gpio.c
> +++ b/drivers/gpio/msm_gpio.c
> @@ -34,21 +34,21 @@ struct msm_gpio_bank {
>
>  #define GPIO_IN_OUT_REG(dev, x) \
> (GPIO_CONFIG_REG(dev, x) + 0x4)
>
> -static int msm_gpio_direction_input(struct udevice *dev, unsigned int gpio)
> +static void msm_gpio_direction_input(struct udevice *dev, unsigned int gpio)
>  {
> struct msm_gpio_bank *priv = dev_get_priv(dev);
>
> /* Always NOP for special pins, assume they're in the correct state */
> if (qcom_is_special_pin(priv->pin_data, gpio))
> -   return 0;
> +   return;
>
> /* Disable OE bit */
> clrsetbits_le32(priv->base + GPIO_CONFIG_REG(dev, gpio),
> GPIO_OE_MASK, GPIO_OE_DISABLE);
>
> -   return 0;
> +   return;
>  }
>
>  static int msm_gpio_set_value(struct udevice *dev, unsigned int gpio, int 
> value)
>  {
> @@ -83,8 +83,25 @@ static int msm_gpio_direction_output(struct udevice *dev, 
> unsigned int gpio,
>
> return 0;
>  }
>
> +static int msm_gpio_set_flags(struct udevice *dev, unsigned int gpio, ulong 
> flags)
> +{
> +   if (flags & GPIOD_IS_OUT_ACTIVE) {
> +   return msm_gpio_direction_output(dev, gpio, 1);
> +   } else if (flags & GPIOD_IS_OUT) {
> +   return msm_gpio_direction_output(dev, gpio, 0);
> +   } else if (flags & GPIOD_IS_IN) {
> +   msm_gpio_direction_input(dev, gpio);
> +   if (flags & GPIOD_PULL_UP)
> +   return msm_gpio_set_value(dev, gpio, 1);
> +   else if (flags & GPIOD_PULL_DOWN)
> +   return msm_gpio_set_value(dev, gpio, 0);
> +   }
> +
> +   return 0;
> +}
> +
>  static int msm_gpio_get_value(struct udevice *dev, unsigned int gpio)
>  {
> struct msm_gpio_bank *priv = dev_get_priv(dev);
>
> @@ -109,12 +126,10 @@ static int msm_gpio_get_function(struct udevice *dev, 
> unsigned int gpio)
> return GPIOF_INPUT;
>  }
>
>  static const struct dm_gpio_ops gpio_msm_ops = {
> -   .direction_input= msm_gpio_direction_input,
> -   .direction_output   = msm_gpio_direction_output,
> +   .set_flags  = msm_gpio_set_flags,
> .get_value  = msm_gpio_get_value,
> -   .set_value  = msm_gpio_set_value,
> .get_function   = msm_gpio_get_function,
>  };
>
>  static int msm_gpio_probe(struct udevice *dev)
>
> --
> 2.44.0
>


Re: [PATCH v3 07/14] clk/qcom: sdm845: add USB clocks

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> Most devices only initialise the USB clocks for us if we boot via
> "fastboot boot", add the missing clock configuration to get both USB
> ports working regardless of the bootloader state.
>
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/clk/qcom/clock-sdm845.c | 25 +
>  1 file changed, 25 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
> index b7154360894a..e9c61eb480de 100644
> --- a/drivers/clk/qcom/clock-sdm845.c
> +++ b/drivers/clk/qcom/clock-sdm845.c
> @@ -20,8 +20,12 @@
>  #include "clock-qcom.h"
>
>  #define SE9_UART_APPS_CMD_RCGR 0x18148
>
> +#define USB30_PRIM_MASTER_CLK_CMD_RCGR 0xf018
> +#define USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR 0xf030
> +#define USB3_PRIM_PHY_AUX_CMD_RCGR 0xf05c
> +
>  static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
> F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
> F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
> F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> @@ -56,8 +60,10 @@ static ulong sdm845_clk_set_rate(struct clk *clk, ulong 
> rate)
> }
>  }
>
>  static const struct gate_clk sdm845_clks[] = {
> +   GATE_CLK(GCC_AGGRE_USB3_SEC_AXI_CLK,0x82020, 0x0001),
> +   GATE_CLK(GCC_CFG_NOC_USB3_SEC_AXI_CLK,  0x05030, 0x0001),
> GATE_CLK(GCC_QUPV3_WRAP0_S0_CLK,0x5200c, 0x0400),
> GATE_CLK(GCC_QUPV3_WRAP0_S1_CLK,0x5200c, 0x0800),
> GATE_CLK(GCC_QUPV3_WRAP0_S2_CLK,0x5200c, 0x1000),
> GATE_CLK(GCC_QUPV3_WRAP0_S3_CLK,0x5200c, 0x2000),
> @@ -120,8 +126,27 @@ static int sdm845_clk_enable(struct clk *clk)
> struct msm_clk_priv *priv = dev_get_priv(clk->dev);
>
> debug("%s: clk %s\n", __func__, sdm845_clks[clk->id].name);
>
> +   switch (clk->id) {
> +   case GCC_USB30_PRIM_MASTER_CLK:
> +   qcom_gate_clk_en(priv, GCC_USB_PHY_CFG_AHB2PHY_CLK);
> +   /* These numbers are just pulled from the frequency tables in 
> the Linux driver */
> +   clk_rcg_set_rate_mnd(priv->base, 
> USB30_PRIM_MASTER_CLK_CMD_RCGR,
> +(4.5 * 2) - 1, 0, 0, 1 << 8, 8);
> +   clk_rcg_set_rate_mnd(priv->base, 
> USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR,
> +1, 0, 0, 0, 8);
> +   clk_rcg_set_rate_mnd(priv->base, USB3_PRIM_PHY_AUX_CMD_RCGR,
> +1, 0, 0, 0, 8);
> +   break;
> +   case GCC_USB30_SEC_MASTER_CLK:
> +   qcom_gate_clk_en(priv, GCC_USB3_SEC_PHY_AUX_CLK);
> +
> +   qcom_gate_clk_en(priv, GCC_USB3_SEC_CLKREF_CLK);
> +   qcom_gate_clk_en(priv, GCC_USB3_SEC_PHY_COM_AUX_CLK);
> +   break;
> +   }
> +
> qcom_gate_clk_en(priv, clk->id);
>
> return 0;
>  }
>
> --
> 2.44.0
>


Re: [PATCH v3 06/14] clk/qcom: sdm845: add gdscs

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> Define the GDSC power domains for SDM845.
>
> Reviewed-by: Neil Armstrong 
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/clk/qcom/clock-sdm845.c | 18 ++
>  1 file changed, 18 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
> index ccb0cf245d33..b7154360894a 100644
> --- a/drivers/clk/qcom/clock-sdm845.c
> +++ b/drivers/clk/qcom/clock-sdm845.c
> @@ -145,13 +145,31 @@ static const struct qcom_reset_map sdm845_gcc_resets[] 
> = {
> [GCC_USB3_DP_PHY_SEC_BCR] = { 0x50014 },
> [GCC_USB_PHY_CFG_AHB2PHY_BCR] = { 0x6a000 },
>  };
>
> +static const struct qcom_power_map sdm845_gdscs[] = {
> +   [PCIE_0_GDSC] = { 0x6b004 },
> +   [PCIE_1_GDSC] = { 0x8d004 },
> +   [UFS_CARD_GDSC] = { 0x75004 },
> +   [UFS_PHY_GDSC] = { 0x77004 },
> +   [USB30_PRIM_GDSC] = { 0xf004 },
> +   [USB30_SEC_GDSC] = { 0x10004 },
> +   [HLOS1_VOTE_AGGRE_NOC_MMU_AUDIO_TBU_GDSC] = { 0x7d030 },
> +   [HLOS1_VOTE_AGGRE_NOC_MMU_PCIE_TBU_GDSC] = { 0x7d03c },
> +   [HLOS1_VOTE_AGGRE_NOC_MMU_TBU1_GDSC] = { 0x7d034 },
> +   [HLOS1_VOTE_AGGRE_NOC_MMU_TBU2_GDSC] = { 0x7d038 },
> +   [HLOS1_VOTE_MMNOC_MMU_TBU_HF0_GDSC] = { 0x7d040 },
> +   [HLOS1_VOTE_MMNOC_MMU_TBU_HF1_GDSC] = { 0x7d048 },
> +   [HLOS1_VOTE_MMNOC_MMU_TBU_SF_GDSC] = { 0x7d044 },
> +};
> +
>  static struct msm_clk_data sdm845_clk_data = {
> .resets = sdm845_gcc_resets,
> .num_resets = ARRAY_SIZE(sdm845_gcc_resets),
> .clks = sdm845_clks,
> .num_clks = ARRAY_SIZE(sdm845_clks),
> +   .power_domains = sdm845_gdscs,
> +   .num_power_domains = ARRAY_SIZE(sdm845_gdscs),
>
> .enable = sdm845_clk_enable,
> .set_rate = sdm845_clk_set_rate,
>  };
>
> --
> 2.44.0
>


Re: [PATCH v3 05/14] clk/qcom: use offsets for RCG registers

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> The RCG registers always have the same offsets, so only store the base
> CMD register address and calculate the others relative to that.
>
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/clk/qcom/clock-apq8016.c |  39 +
>  drivers/clk/qcom/clock-apq8096.c |  28 +
>  drivers/clk/qcom/clock-qcom.c|  22 +++
>  drivers/clk/qcom/clock-qcom.h|  16 +++---
>  drivers/clk/qcom/clock-qcs404.c  | 121 
> +--
>  drivers/clk/qcom/clock-sdm845.c  |  16 +-
>  6 files changed, 39 insertions(+), 203 deletions(-)
>
> diff --git a/drivers/clk/qcom/clock-apq8016.c 
> b/drivers/clk/qcom/clock-apq8016.c
> index e6647f7c41dd..5a5868169c89 100644
> --- a/drivers/clk/qcom/clock-apq8016.c
> +++ b/drivers/clk/qcom/clock-apq8016.c
> @@ -22,13 +22,9 @@
>  #define APCS_GPLL_ENA_VOTE (0x45000)
>  #define APCS_CLOCK_BRANCH_ENA_VOTE (0x45004)
>
>  #define SDCC_BCR(n)((n * 0x1000) + 0x41000)
> -#define SDCC_CMD_RCGR(n)   ((n * 0x1000) + 0x41004)
> -#define SDCC_CFG_RCGR(n)   ((n * 0x1000) + 0x41008)
> -#define SDCC_M(n)  ((n * 0x1000) + 0x4100C)
> -#define SDCC_N(n)  ((n * 0x1000) + 0x41010)
> -#define SDCC_D(n)  ((n * 0x1000) + 0x41014)
> +#define SDCC_CMD_RCGR(n)   (((n + 1) * 0x1000) + 0x41004)
>  #define SDCC_APPS_CBCR(n)  ((n * 0x1000) + 0x41018)
>  #define SDCC_AHB_CBCR(n)   ((n * 0x1000) + 0x4101C)
>
>  /* BLSP1 AHB clock (root clock for BLSP) */
> @@ -37,33 +33,12 @@
>  /* Uart clock control registers */
>  #define BLSP1_UART2_BCR(0x3028)
>  #define BLSP1_UART2_APPS_CBCR  (0x302C)
>  #define BLSP1_UART2_APPS_CMD_RCGR  (0x3034)
> -#define BLSP1_UART2_APPS_CFG_RCGR  (0x3038)
> -#define BLSP1_UART2_APPS_M (0x303C)
> -#define BLSP1_UART2_APPS_N (0x3040)
> -#define BLSP1_UART2_APPS_D (0x3044)
>
>  /* GPLL0 clock control registers */
>  #define GPLL0_STATUS_ACTIVE BIT(17)
>
> -static const struct bcr_regs sdc_regs[] = {
> -   {
> -   .cfg_rcgr = SDCC_CFG_RCGR(1),
> -   .cmd_rcgr = SDCC_CMD_RCGR(1),
> -   .M = SDCC_M(1),
> -   .N = SDCC_N(1),
> -   .D = SDCC_D(1),
> -   },
> -   {
> -   .cfg_rcgr = SDCC_CFG_RCGR(2),
> -   .cmd_rcgr = SDCC_CMD_RCGR(2),
> -   .M = SDCC_M(2),
> -   .N = SDCC_N(2),
> -   .D = SDCC_D(2),
> -   }
> -};
> -
>  static struct pll_vote_clk gpll0_vote_clk = {
> .status = GPLL0_STATUS,
> .status_bit = GPLL0_STATUS_ACTIVE,
> .ena_vote = APCS_GPLL_ENA_VOTE,
> @@ -85,32 +60,24 @@ static int clk_init_sdc(struct msm_clk_priv *priv, int 
> slot, uint rate)
> div = 4;
>
> clk_enable_cbc(priv->base + SDCC_AHB_CBCR(slot));
> /* 800Mhz/div, gpll0 */
> -   clk_rcg_set_rate_mnd(priv->base, _regs[slot], div, 0, 0,
> +   clk_rcg_set_rate_mnd(priv->base, SDCC_CMD_RCGR(slot), div, 0, 0,
>  CFG_CLK_SRC_GPLL0, 8);
> clk_enable_gpll0(priv->base, _vote_clk);
> clk_enable_cbc(priv->base + SDCC_APPS_CBCR(slot));
>
> return rate;
>  }
>
> -static const struct bcr_regs uart2_regs = {
> -   .cfg_rcgr = BLSP1_UART2_APPS_CFG_RCGR,
> -   .cmd_rcgr = BLSP1_UART2_APPS_CMD_RCGR,
> -   .M = BLSP1_UART2_APPS_M,
> -   .N = BLSP1_UART2_APPS_N,
> -   .D = BLSP1_UART2_APPS_D,
> -};
> -
>  /* UART: 115200 */
>  int apq8016_clk_init_uart(phys_addr_t base)
>  {
> /* Enable AHB clock */
> clk_enable_vote_clk(base, _blsp1_ahb_clk);
>
> /* 7372800 uart block clock @ GPLL0 */
> -   clk_rcg_set_rate_mnd(base, _regs, 1, 144, 15625,
> +   clk_rcg_set_rate_mnd(base, BLSP1_UART2_APPS_CMD_RCGR, 1, 144, 15625,
>  CFG_CLK_SRC_GPLL0, 16);
>
> /* Vote for gpll0 clock */
> clk_enable_gpll0(base, _vote_clk);
> diff --git a/drivers/clk/qcom/clock-apq8096.c 
> b/drivers/clk/qcom/clock-apq8096.c
> index a4731613c5e0..479f9771a464 100644
> --- a/drivers/clk/qcom/clock-apq8096.c
> +++ b/drivers/clk/qcom/clock-apq8096.c
> @@ -25,33 +25,17 @@
>  #define SDCC2_BCR  (0x14000) /* block reset */
>  #define SDCC2_APPS_CBCR(0x14004) /* branch control */
>  #define SDCC2_AHB_CBCR (0x14008)
>  #define SDCC2_CMD_RCGR (0x14010)
> -#define SDCC2_CFG_RCGR (0x14014)
> -#define SDCC2_M(0x14018)
> -#define SDCC2_N(0x1401C)
> -#define SDCC2_D(0x14020)
>
>  #define BLSP2_AHB_CBCR (0x25004)
>  #define BLSP2_UART2_APPS_CBCR  (0x29004)
>  #define BLSP2_UART2_APPS_CMD_RCGR  (0x2900C)
> -#define BLSP2_UART2_APPS_CFG_RCGR  (0x29010)
> -#define BLSP2_UART2_APPS_M  

Re: [PATCH v3 14/14] qcom_defconfig: enable USB

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> Enable support for the DWC3 USB controller and required dependencies for
> Qualcomm boards, specifically the DB845c:
> * IOMMU / SMMU
> * USB high-speed PHYs
> * Mass storage and ACM gadgets
>
> Signed-off-by: Caleb Connolly 
> ---
>  configs/qcom_defconfig | 49 ++---
>  1 file changed, 26 insertions(+), 23 deletions(-)
>
> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> index eebd0d74bd51..156c205284dd 100644
> --- a/configs/qcom_defconfig
> +++ b/configs/qcom_defconfig
> @@ -12,42 +12,63 @@ CONFIG_BOOTSTD_FULL=y
>  CONFIG_BOOTDELAY=1
>  CONFIG_USE_PREBOOT=y
>  CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR=y
>  CONFIG_SYS_CBSIZE=512
> +# CONFIG_SYS_DEVICE_NULLDEV is not set
>  CONFIG_LOG_MAX_LEVEL=9
>  CONFIG_LOG_DEFAULT_LEVEL=4
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_CMD_BOOTMENU=y
> +CONFIG_CMD_EEPROM=y
> +CONFIG_SYS_I2C_EEPROM_BUS=2
> +CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
> +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5
> +# CONFIG_CMD_BIND is not set
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_GPIO=y
> +CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
>  CONFIG_CMD_UFS=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_CAT=y
>  CONFIG_CMD_BMP=y
>  CONFIG_CMD_LOG=y
>  CONFIG_OF_LIVE=y
>  # CONFIG_NET is not set
> +CONFIG_DM_WARN=y
>  # CONFIG_OFNODE_MULTI_TREE is not set
>  CONFIG_BUTTON_QCOM_PMIC=y
>  CONFIG_CLK=y
>  CONFIG_CLK_QCOM_QCS404=y
>  CONFIG_CLK_QCOM_SDM845=y
>  CONFIG_MSM_GPIO=y
>  CONFIG_QCOM_PMIC_GPIO=y
> +CONFIG_DM_I2C=y
> +CONFIG_SYS_I2C_QUP=y
> +CONFIG_I2C_MUX=y
>  CONFIG_DM_KEYBOARD=y
>  CONFIG_BUTTON_KEYBOARD=y
> +CONFIG_IOMMU=y
> +CONFIG_QCOM_HYP_SMMU=y
> +CONFIG_MISC=y
> +CONFIG_NVMEM=y
> +CONFIG_I2C_EEPROM=y
>  CONFIG_MMC_HS200_SUPPORT=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_ADMA=y
>  CONFIG_MMC_SDHCI_MSM=y
> +CONFIG_DM_ETH_PHY=y
>  CONFIG_PHY=y
> +CONFIG_PHY_QCOM_QUSB2=y
> +CONFIG_PHY_QCOM_USB_HS_7NM=y
>  CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_QCOM_QCS404=y
>  CONFIG_PINCTRL_QCOM_SDM845=y
>  CONFIG_DM_PMIC=y
>  CONFIG_PMIC_QCOM=y
> +CONFIG_DM_REGULATOR=y
> +CONFIG_DM_REGULATOR_FIXED=y
>  CONFIG_SCSI=y
>  CONFIG_MSM_SERIAL=y
>  CONFIG_MSM_GENI_SERIAL=y
>  CONFIG_SPMI_MSM=y
> @@ -56,8 +77,13 @@ CONFIG_SYSINFO_SMBIOS=y
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_DWC3=y
> +CONFIG_USB_DWC3_GENERIC=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_USB_FUNCTION_MASS_STORAGE=y
> +CONFIG_USB_FUNCTION_ACM=y
>  CONFIG_UFS=y
>  CONFIG_VIDEO=y
>  # CONFIG_VIDEO_FONT_8X16 is not set
>  CONFIG_VIDEO_FONT_16X32=y
> @@ -66,27 +92,4 @@ CONFIG_NO_FB_CLEAR=y
>  CONFIG_VIDEO_SIMPLE=y
>  CONFIG_HEXDUMP=y
>  # CONFIG_GENERATE_SMBIOS_TABLE is not set
>  CONFIG_LMB_MAX_REGIONS=64
> -CONFIG_CMD_DHCP=y
> -CONFIG_CMD_EEPROM=y
> -CONFIG_CMD_I2C=y
> -CONFIG_CMD_PING=y
> -CONFIG_DM_ETH=y
> -CONFIG_DM_ETH_PHY=y
> -CONFIG_DM_MDIO=y
> -CONFIG_DWC_ETH_QOS=y
> -CONFIG_DWC_ETH_QOS_QCOM=y

Any particular reason to drop these?

-Sumit

> -CONFIG_RGMII=y
> -CONFIG_PHY_MICREL=y
> -CONFIG_PHY_MICREL_KSZ90X1=y
> -CONFIG_MISC=y
> -CONFIG_NVMEM=y
> -CONFIG_DM_I2C=y
> -CONFIG_I2C_SUPPORT=y
> -CONFIG_I2C_MUX=y
> -CONFIG_I2C_EEPROM=y
> -CONFIG_SYS_I2C=y
> -CONFIG_SYS_I2C_QUP=y
> -CONFIG_SYS_I2C_EEPROM_BUS=2
> -CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
> -CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5
>
> --
> 2.44.0
>


Re: [PATCH v3 03/14] phy: qcom: Add USB HS 7nm PHY driver

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> From: Bhupesh Sharma 
>
> Some Qualcomm SoCs newer than SDM845 feature a so-called "7nm phy"
> driver, notable the SM8250 SoC which will gain U-Boot support in
> upcoming patches.
>
> Introduce a driver based on the Linux driver.
>
> Signed-off-by: Bhupesh Sharma 
> [code cleanup, switch to clk/reset_bulk APIs]
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/phy/qcom/Kconfig   |   8 +
>  drivers/phy/qcom/Makefile  |   1 +
>  drivers/phy/qcom/phy-qcom-usb-hs-7nm.c | 295 
> +
>  3 files changed, 304 insertions(+)
>
> diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
> index 361dfb6e1126..3fc59dc65650 100644
> --- a/drivers/phy/qcom/Kconfig
> +++ b/drivers/phy/qcom/Kconfig
> @@ -18,8 +18,16 @@ config PHY_QCOM_QUSB2
> help
>   Enable this to support the Super-Speed USB transceiver on various
>   Qualcomm chipsets.
>
> +config PHY_QCOM_USB_HS_7NM
> +   tristate "Qualcomm 7nm High-Speed PHY"
> +   depends on PHY && ARCH_SNAPDRAGON
> +   help
> + Enable this to support the Qualcomm Synopsys DesignWare Core 7nm
> + High-Speed PHY driver. This driver supports the Hi-Speed PHY which
> + is usually paired with Synopsys DWC3 USB IPs on MSM SOCs.
> +
>  config PHY_QCOM_USB_HS_28NM
> tristate "Qualcomm 28nm High-Speed PHY"
> depends on PHY && ARCH_SNAPDRAGON
> help
> diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
> index f6af985666a4..39219ecd24aa 100644
> --- a/drivers/phy/qcom/Makefile
> +++ b/drivers/phy/qcom/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
>  obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
>  obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
> +obj-$(CONFIG_PHY_QCOM_USB_HS_7NM) += phy-qcom-usb-hs-7nm.o
>  obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
>  obj-$(CONFIG_PHY_QCOM_USB_SS) += phy-qcom-usb-ss.o
> diff --git a/drivers/phy/qcom/phy-qcom-usb-hs-7nm.c 
> b/drivers/phy/qcom/phy-qcom-usb-hs-7nm.c
> new file mode 100644
> index ..65128b45937b
> --- /dev/null
> +++ b/drivers/phy/qcom/phy-qcom-usb-hs-7nm.c
> @@ -0,0 +1,295 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Bhupesh Sharma 
> + *
> + * Based on Linux driver
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define USB2_PHY_USB_PHY_UTMI_CTRL0 (0x3c)
> +#define SLEEPM BIT(0)
> +#define OPMODE_MASK GENMASK(4, 3)
> +#define OPMODE_NORMAL (0x00)
> +#define OPMODE_NONDRIVING BIT(3)
> +#define TERMSEL BIT(5)
> +
> +#define USB2_PHY_USB_PHY_UTMI_CTRL1 (0x40)

Drop unused macros. Check other macros too below if all of them are being used.

> +#define XCVRSEL BIT(0)
> +
> +#define USB2_PHY_USB_PHY_UTMI_CTRL5 (0x50)
> +#define POR BIT(1)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0 (0x54)
> +#define SIDDQ BIT(2)
> +#define RETENABLEN BIT(3)
> +#define FSEL_MASK GENMASK(6, 4)
> +#define FSEL_DEFAULT (0x3 << 4)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON1 (0x58)
> +#define VBUSVLDEXTSEL0 BIT(4)
> +#define PLLBTUNE BIT(5)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON2 (0x5c)
> +#define VREGBYPASS BIT(0)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL1 (0x60)
> +#define VBUSVLDEXT0 BIT(0)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL2 (0x64)
> +#define USB2_AUTO_RESUME BIT(0)
> +#define USB2_SUSPEND_N BIT(2)
> +#define USB2_SUSPEND_N_SEL BIT(3)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X0 (0x6c)
> +#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X1 (0x70)
> +#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X2 (0x74)
> +#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X3 (0x78)
> +#define PARAM_OVRD_MASK 0xFF
> +
> +#define USB2_PHY_USB_PHY_CFG0 (0x94)
> +#define UTMI_PHY_DATAPATH_CTRL_OVERRIDE_EN BIT(0)
> +#define UTMI_PHY_CMN_CTRL_OVERRIDE_EN BIT(1)
> +
> +#define USB2_PHY_USB_PHY_REFCLK_CTRL (0xa0)
> +#define REFCLK_SEL_MASK GENMASK(1, 0)
> +#define REFCLK_SEL_DEFAULT (0x2 << 0)
> +
> +#define HS_DISCONNECT_MASK GENMASK(2, 0)
> +#define SQUELCH_DETECTOR_MASK GENMASK(7, 5)
> +
> +#define HS_AMPLITUDE_MASK GENMASK(3, 0)
> +#define PREEMPHASIS_DURATION_MASK BIT(5)
> +#define PREEMPHASIS_AMPLITUDE_MASK GENMASK(7, 6)
> +
> +#define HS_RISE_FALL_MASK GENMASK(1, 0)
> +#define HS_CROSSOVER_VOLTAGE_MASK GENMASK(3, 2)
> +#define HS_OUTPUT_IMPEDANCE_MASK GENMASK(5, 4)
> +
> +#define LS_FS_OUTPUT_IMPEDANCE_MASK GENMASK(3, 0)
> +
> +#define SNPS_HS_NUM_VREGS ARRAY_SIZE(hs_7nm_vreg_names)
> +
> +struct override_param {
> +   s32 value;
> +   u8 reg_val;
> +};
> +
> +struct override_param_map {
> +   const char *prop_name;
> +   const struct override_param *param_table;
> +   u8 table_size;
> +   u8 reg_offset;
> +   u8 param_mask;
> +};
> +
> +struct phy_override_seq {
> +

Re: [PATCH] board: amlogic: fix buffler overflow in serial & usid read

2024-03-19 Thread Dan Carpenter
On Tue, Mar 19, 2024 at 03:53:24PM +0100, Neil Armstrong wrote:
> While meson_sm_read_efuse() doesn't overflow, the string is not
> zero terminated and env_set() will buffer overflow and add random
> characters to environment.
> 

In the Linux kernel we would give this a CVE because it's information
disclosure bug...

> Signed-off-by: Neil Armstrong 
> ---
>  board/amlogic/jethub-j80/jethub-j80.c | 6 --
>  board/amlogic/p200/p200.c | 3 ++-
>  board/amlogic/p201/p201.c | 3 ++-
>  board/amlogic/p212/p212.c | 3 ++-
>  board/amlogic/q200/q200.c | 3 ++-
>  5 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/board/amlogic/jethub-j80/jethub-j80.c 
> b/board/amlogic/jethub-j80/jethub-j80.c
> index 185880de13..d10492cc46 100644
> --- a/board/amlogic/jethub-j80/jethub-j80.c
> +++ b/board/amlogic/jethub-j80/jethub-j80.c
> @@ -28,8 +28,8 @@
>  int misc_init_r(void)
>  {
>   u8 mac_addr[EFUSE_MAC_SIZE];
   

This one is also a problem.  You can't pass non-terminated strings to
eth_env_set_enetaddr().  We call strlen() on it in either hsearch_r() or
env_get_from_linear().

All the other functions had a mac_addr[] issue as well.

Btw, this kind of bug is a good candidate for a static checker warning.
I can create a Smatch check for this.  It would probably be easier in
Coccinelle even, but I'm the Smatch maintainer.

regards,
dan carpenter


> - char serial[EFUSE_SN_SIZE];
> - char usid[EFUSE_USID_SIZE];
> + char serial[EFUSE_SN_SIZE + 1];
> + char usid[EFUSE_USID_SIZE + 1];
>   ssize_t len;
>   unsigned int adcval;
>   int ret;
> @@ -46,6 +46,7 @@ int misc_init_r(void)
>   if (!env_get("serial")) {
>   len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,
> EFUSE_SN_SIZE);
> + serial[len] = '\0';
>   if (len == EFUSE_SN_SIZE)
>   env_set("serial", serial);



Re: [PATCH v3 04/14] mach-snapdragon: disable power-domains for pre-reloc drivers

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> Some devices like the UART and clock controller reference an RPM(h)
> power domain. We don't support this device in U-Boot, so add
> DM_FLAG_DEFAULT_PD_CTRL_OFF to tell DM core not to try and enable the
> power domain.
>
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/clk/qcom/clock-qcom.c| 2 ++
>  drivers/clk/qcom/clock-sdm845.c  | 2 +-
>  drivers/serial/serial_msm_geni.c | 2 +-
>  3 files changed, 4 insertions(+), 2 deletions(-)
>

Reviewed-by: Sumit Garg 


-Sumit

> diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c
> index 7a5938a06a34..6303dcbf8461 100644
> --- a/drivers/clk/qcom/clock-qcom.c
> +++ b/drivers/clk/qcom/clock-qcom.c
> @@ -226,8 +226,9 @@ U_BOOT_DRIVER(qcom_clk) = {
> .id = UCLASS_CLK,
> .ops= _clk_ops,
> .priv_auto  = sizeof(struct msm_clk_priv),
> .probe  = msm_clk_probe,
> +   .flags  = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
>  };
>
>  int qcom_cc_bind(struct udevice *parent)
>  {
> @@ -410,5 +411,6 @@ U_BOOT_DRIVER(qcom_power) = {
> .name = "qcom_power",
> .id = UCLASS_POWER_DOMAIN,
> .ops = _power_ops,
> .probe = qcom_power_probe,
> +   .flags = DM_FLAG_PRE_RELOC,
>  };
> diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
> index 36ffee79d966..babd83119e2c 100644
> --- a/drivers/clk/qcom/clock-sdm845.c
> +++ b/drivers/clk/qcom/clock-sdm845.c
> @@ -182,6 +182,6 @@ U_BOOT_DRIVER(gcc_sdm845) = {
> .name   = "gcc_sdm845",
> .id = UCLASS_NOP,
> .of_match   = gcc_sdm845_of_match,
> .bind   = qcom_cc_bind,
> -   .flags  = DM_FLAG_PRE_RELOC,
> +   .flags  = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
>  };
> diff --git a/drivers/serial/serial_msm_geni.c 
> b/drivers/serial/serial_msm_geni.c
> index e5c3dcffc1c6..4aa0bc8c72bc 100644
> --- a/drivers/serial/serial_msm_geni.c
> +++ b/drivers/serial/serial_msm_geni.c
> @@ -602,9 +602,9 @@ U_BOOT_DRIVER(serial_msm_geni) = {
> .of_to_plat = msm_serial_ofdata_to_platdata,
> .priv_auto = sizeof(struct msm_serial_data),
> .probe = msm_serial_probe,
> .ops = _serial_ops,
> -   .flags = DM_FLAG_PRE_RELOC,
> +   .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
>  };
>
>  #ifdef CONFIG_DEBUG_UART_MSM_GENI
>
>
> --
> 2.44.0
>


Re: [PATCH v3 02/14] phy: qcom: add Qualcomm QUSB2 USB PHY driver

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> From: Bhupesh Sharma 
>
> The Snapdragon 845 and several other Qualcomm SoCs feature this
> USB high-speed phy. Add a driver for it based on the Linux driver, with
> support for the SDM845, and the QCM2290 and SM6115 SoCs which will gain
> support in U-Boot in future patches.
>
> Signed-off-by: Bhupesh Sharma 
> [code cleanup, switch to clk_bulk]
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/phy/qcom/Kconfig  |   7 +
>  drivers/phy/qcom/Makefile |   1 +
>  drivers/phy/qcom/phy-qcom-qusb2.c | 468 
> ++
>  3 files changed, 476 insertions(+)
>
> diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
> index f4ca174805a4..361dfb6e1126 100644
> --- a/drivers/phy/qcom/Kconfig
> +++ b/drivers/phy/qcom/Kconfig
> @@ -11,8 +11,15 @@ config PHY_QCOM_IPQ4019_USB
> depends on PHY && ARCH_IPQ40XX
> help
>   Support for the USB PHY-s on Qualcomm IPQ40xx SoC-s.
>
> +config PHY_QCOM_QUSB2
> +   tristate "Qualcomm USB QUSB2 PHY driver"
> +   depends on PHY && ARCH_SNAPDRAGON
> +   help
> + Enable this to support the Super-Speed USB transceiver on various
> + Qualcomm chipsets.
> +
>  config PHY_QCOM_USB_HS_28NM
> tristate "Qualcomm 28nm High-Speed PHY"
> depends on PHY && ARCH_SNAPDRAGON
> help
> diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
> index 2113f178c0c7..f6af985666a4 100644
> --- a/drivers/phy/qcom/Makefile
> +++ b/drivers/phy/qcom/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
>  obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
> +obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
>  obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
>  obj-$(CONFIG_PHY_QCOM_USB_SS) += phy-qcom-usb-ss.o
> diff --git a/drivers/phy/qcom/phy-qcom-qusb2.c 
> b/drivers/phy/qcom/phy-qcom-qusb2.c
> new file mode 100644
> index ..5b654403a181
> --- /dev/null
> +++ b/drivers/phy/qcom/phy-qcom-qusb2.c
> @@ -0,0 +1,468 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Bhupesh Sharma 
> + *
> + * Based on Linux driver
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define QUSB2PHY_PLL 0x0
> +#define QUSB2PHY_PLL_TEST 0x04
> +#define CLK_REF_SEL BIT(7)
> +
> +#define QUSB2PHY_PLL_TUNE 0x08
> +#define QUSB2PHY_PLL_USER_CTL1 0x0c
> +#define QUSB2PHY_PLL_USER_CTL2 0x10
> +#define QUSB2PHY_PLL_AUTOPGM_CTL1 0x1c
> +#define QUSB2PHY_PLL_PWR_CTRL 0x18
> +
> +/* QUSB2PHY_PLL_STATUS register bits */
> +#define PLL_LOCKED BIT(5)
> +
> +/* QUSB2PHY_PLL_COMMON_STATUS_ONE register bits */
> +#define CORE_READY_STATUS BIT(0)
> +
> +/* QUSB2PHY_PORT_POWERDOWN register bits */
> +#define CLAMP_N_EN BIT(5)
> +#define FREEZIO_N BIT(1)
> +#define POWER_DOWN BIT(0)
> +
> +/* QUSB2PHY_PWR_CTRL1 register bits */
> +#define PWR_CTRL1_VREF_SUPPLY_TRIM BIT(5)
> +#define PWR_CTRL1_CLAMP_N_EN BIT(1)
> +
> +#define QUSB2PHY_REFCLK_ENABLE BIT(0)
> +
> +#define PHY_CLK_SCHEME_SEL BIT(0)
> +
> +/* QUSB2PHY_INTR_CTRL register bits */
> +#define DMSE_INTR_HIGH_SEL BIT(4)
> +#define DPSE_INTR_HIGH_SEL BIT(3)
> +#define CHG_DET_INTR_EN BIT(2)
> +#define DMSE_INTR_EN BIT(1)
> +#define DPSE_INTR_EN BIT(0)
> +
> +/* QUSB2PHY_PLL_CORE_INPUT_OVERRIDE register bits */
> +#define CORE_PLL_EN_FROM_RESET BIT(4)
> +#define CORE_RESET BIT(5)
> +#define CORE_RESET_MUX BIT(6)
> +
> +/* QUSB2PHY_IMP_CTRL1 register bits */
> +#define IMP_RES_OFFSET_MASK GENMASK(5, 0)
> +#define IMP_RES_OFFSET_SHIFT 0x0
> +
> +/* QUSB2PHY_PLL_BIAS_CONTROL_2 register bits */
> +#define BIAS_CTRL2_RES_OFFSET_MASK GENMASK(5, 0)
> +#define BIAS_CTRL2_RES_OFFSET_SHIFT 0x0
> +
> +/* QUSB2PHY_CHG_CONTROL_2 register bits */
> +#define CHG_CTRL2_OFFSET_MASK GENMASK(5, 4)
> +#define CHG_CTRL2_OFFSET_SHIFT 0x4
> +
> +/* QUSB2PHY_PORT_TUNE1 register bits */
> +#define HSTX_TRIM_MASK GENMASK(7, 4)
> +#define HSTX_TRIM_SHIFT 0x4
> +#define PREEMPH_WIDTH_HALF_BIT BIT(2)
> +#define PREEMPHASIS_EN_MASK GENMASK(1, 0)
> +#define PREEMPHASIS_EN_SHIFT 0x0
> +
> +/* QUSB2PHY_PORT_TUNE2 register bits */
> +#define HSDISC_TRIM_MASK GENMASK(1, 0)
> +#define HSDISC_TRIM_SHIFT 0x0
> +
> +#define QUSB2PHY_PLL_ANALOG_CONTROLS_TWO 0x04
> +#define QUSB2PHY_PLL_CLOCK_INVERTERS 0x18c
> +#define QUSB2PHY_PLL_CMODE 0x2c
> +#define QUSB2PHY_PLL_LOCK_DELAY 0x184
> +#define QUSB2PHY_PLL_DIGITAL_TIMERS_TWO 0xb4
> +#define QUSB2PHY_PLL_BIAS_CONTROL_1 0x194
> +#define QUSB2PHY_PLL_BIAS_CONTROL_2 0x198
> +#define QUSB2PHY_PWR_CTRL2 0x214
> +#define QUSB2PHY_IMP_CTRL1 0x220
> +#define QUSB2PHY_IMP_CTRL2 0x224
> +#define QUSB2PHY_CHG_CTRL2 0x23c
> +
> +struct qusb2_phy_init_tbl {
> +   unsigned int offset;
> +   unsigned int val;
> +   /*
> +* register part of layout ?
> +* if yes, then offset gives index in the reg-layout
> +*/
> +   

Re: [PATCH 0/4] arm: meson: Switch to using upstream DT for GXL, GXM, AXG, G12A, G12B & SM1 SoCs

2024-03-19 Thread Sumit Garg
gt;  arch/arm/dts/meson-sm1-odroid-hc4.dts  |  140 --
>  arch/arm/dts/meson-sm1-odroid.dtsi |  449 
>  arch/arm/dts/meson-sm1-sei610.dts  |  616 -
>  arch/arm/dts/meson-sm1.dtsi|  550 -
>  arch/arm/mach-meson/Kconfig|4 +
>  configs/bananapi-cm4-cm4io_defconfig   |2 +-
>  configs/bananapi-m2-pro_defconfig  |2 +-
>  configs/bananapi-m2s_defconfig |2 +-
>  configs/bananapi-m5_defconfig  |2 +-
>  configs/beelink-gsking-x_defconfig |2 +-
>  configs/beelink-gt1-ultimate_defconfig |2 +-
>  configs/beelink-gtking_defconfig   |2 +-
>  configs/beelink-gtkingpro_defconfig|2 +-
>  configs/jethub_j100_defconfig  |2 +-
>  configs/jethub_j80_defconfig   |2 +-
>  configs/khadas-vim2_defconfig  |2 +-
>  configs/khadas-vim3_android_ab_defconfig   |2 +-
>  configs/khadas-vim3_android_defconfig  |2 +-
>  configs/khadas-vim3_defconfig  |2 +-
>  configs/khadas-vim3l_android_ab_defconfig  |2 +-
>  configs/khadas-vim3l_android_defconfig |2 +-
>  configs/khadas-vim3l_defconfig |2 +-
>  configs/khadas-vim_defconfig   |2 +-
>  configs/libretech-ac_defconfig |2 +-
>  configs/libretech-cc_defconfig |2 +-
>  configs/libretech-cc_v2_defconfig  |2 +-
>  configs/libretech-s905d-pc_defconfig   |2 +-
>  configs/libretech-s912-pc_defconfig|2 +-
>  configs/odroid-c4_defconfig|2 +-
>  configs/odroid-go-ultra_defconfig  |2 +-
>  configs/odroid-hc4_defconfig   |2 +-
>  configs/odroid-n2_defconfig|2 +-
>  configs/odroid-n2l_defconfig   |2 +-
>  configs/p212_defconfig |2 +-
>  configs/radxa-zero2_defconfig  |2 +-
>  configs/radxa-zero_defconfig   |2 +-
>  configs/s400_defconfig |2 +-
>  configs/sei510_defconfig   |2 +-
>  configs/sei610_defconfig   |2 +-
>  configs/u200_defconfig |2 +-
>  configs/wetek-core2_defconfig  |2 +-
>  include/dt-bindings/gpio/meson-axg-gpio.h  |  116 -
>  include/dt-bindings/gpio/meson-g12a-gpio.h |  114 -
>  include/dt-bindings/gpio/meson-gxbb-gpio.h |  148 --
>  include/dt-bindings/gpio/meson-gxl-gpio.h  |  125 -
>  include/dt-bindings/power/meson-axg-power.h|   14 -
>  include/dt-bindings/power/meson-g12a-power.h   |   13 -
>  include/dt-bindings/power/meson-gxbb-power.h   |   13 -
>  include/dt-bindings/power/meson-sm1-power.h|   18 -
>  .../reset/amlogic,meson-axg-audio-arb.h|   19 -
>  .../dt-bindings/reset/amlogic,meson-axg-reset.h|  123 -
>  .../reset/amlogic,meson-g12a-audio-reset.h |   53 -
>  .../dt-bindings/reset/amlogic,meson-g12a-reset.h   |  137 --
>  .../dt-bindings/reset/amlogic,meson-gxbb-reset.h   |  161 --
>  include/dt-bindings/sound/meson-aiu.h  |   18 -
>  include/dt-bindings/sound/meson-g12a-toacodec.h|   10 -
>  include/dt-bindings/sound/meson-g12a-tohdmitx.h|   13 -
>  116 files changed, 42 insertions(+), 21511 deletions(-)

Glad to see these diff stats, FWIW:

Reviewed-by: Sumit Garg 

-Sumit

> ---
> base-commit: b145877c22b391a4872c875145a8f86f6ffebaba
> change-id: 20240319-u-boot-of-upstream-46454fded5ea
>
> Best regards,
> --
> Neil Armstrong 
>


Re: [PATCH v3 10/14] mach-snapdragon: fixup USB nodes

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 20:15, Caleb Connolly  wrote:
>
> Hi Sumit,
>
> On 19/03/2024 13:49, Sumit Garg wrote:
> > Hi Caleb,
> >
> > On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  
> > wrote:
> >>
> >> We don't support USB super-speed in U-Boot yet, we lack the SS PHY
> >> drivers, however from my testing even with a PHY driver there seem to be
> >> other issues when talking to super-speed peripherals.
> >>
> >> In pursuit of maintaining upstream DT compatibility,
> >
> > I can understand the reasoning behind this but since we enable these
> > fixups for every Qcom platform it may turn out to be counter
> > productive. There can be embedded use-cases where bootup times have
> > stringent requirements. Also, depending upon CPU speed/freq the add-on
> > times due to these can be significant.
>
> I have measured this on a few different boards:
>
> On DB410c, the slowest board we currently support
> * of_live_build took 7228us
> * Fixing up USB nodes took 131us
> * Fixing up power domains took 88us
>
> On RB1 (the slowest new platform with a QCM2290 SoC)
> * of_live_build took 2078us
> * Fixing up USB nodes took 39us
> * Fixing up power domains took 27us
>
> The time taken initially to build the livetree is likely made back as it
> is much much faster to query than the flat tree (as you can see, walking
> every single node takes <100us on db410c). I took some rough
> measurements of the boot-to-console time on sdm845 (see the "enable
> livetree" patch) and basically concluded that the delta between live and
> flat trees is within the margin of error.
>
> If a specific board for whatever reason wants to avoid using OF_LIVE
> then I'm fine with that, db410c isn't using it for example.

Okay that's fair. Let's try this approach and see if it pans out well.

-Sumit


[PATCH v2] build: Revive and update LDR format support

2024-03-19 Thread Greg Malysa
LDR format files are used primarily by Analog Devices processors but may
be of interest to other vendors. Previously support existed for this
format as part of the U-Boot build, but it has been unmaintained and
unused for a long time. In preparation for adding support for modern ADI
processors that use LDR, modernize the LDR support:

- Introduce CONFIG_LDR_CPU as the CPU string recognized by the LDR tool
  may not be the same as CONFIG_CPU
- Add an SPL target that repackages u-boot-spl inside an LDR file

An almost identical target for packaging u-boot into an LDR file already
exists and did not need to be created.

Co-developed-by: Nathan Barrett-Morrison 
Signed-off-by: Nathan Barrett-Morrison 
Signed-off-by: Ian Roberts 
Signed-off-by: Greg Malysa 

---

Changes in v2:
 - Add HAS_LDR prerequisite to avoid prompting for LDR_CPU on unrelated
   platforms
 - Fixed accidentally moving 'source "api/Kconfig"' which is unrelated
   to this patch


---
 Kconfig  | 14 ++
 Makefile |  2 +-
 scripts/Makefile.spl |  5 +
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Kconfig b/Kconfig
index 5710934000..bccacb773a 100644
--- a/Kconfig
+++ b/Kconfig
@@ -715,6 +715,20 @@ config SYS_CLK_FREQ
  A static value for the CPU frequency.  Note that if not required
  for a given SoC, this can be left at 0.
 
+config HAS_LDR
+   bool
+   help
+ Enables building .ldr targets for U-Boot and SPL. This does not
+ automatically build any additional targets with make or buildman.
+
+config LDR_CPU
+   string "CPU name to be passed to LDR utility."
+   depends on HAS_LDR
+   help
+ Set the CPU name for the -T parameter in the LDR utility.  This is
+ generally used on processors from Analog Devices, but may be also
+ be useful for other vendors.
+
 source "api/Kconfig"
 
 endmenu# General setup
diff --git a/Makefile b/Makefile
index a2bc9d5903..db3272a439 100644
--- a/Makefile
+++ b/Makefile
@@ -1328,7 +1328,7 @@ u-boot-nodtb.bin: u-boot FORCE
 
 u-boot.ldr:u-boot
$(CREATE_LDR_ENV)
-   $(LDR) -T $(CONFIG_CPU) -c $@ $< $(LDR_FLAGS)
+   $(LDR) -T $(CONFIG_LDR_CPU) -c $@ $< $(LDR_FLAGS)
$(BOARD_SIZE_CHECK)
 
 # binman
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 407fc52376..58d6a452e5 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -381,6 +381,11 @@ $(obj)/$(BOARD)-spl.bin: $(obj)/u-boot-spl.bin
$(objtree)/tools/mkexynosspl) $(VAR_SIZE_PARAM) $< $@
 endif
 
+$(obj)/u-boot-spl.ldr: $(obj)/u-boot-spl
+   $(CREATE_LDR_ENV)
+   $(LDR) -T $(CONFIG_LDR_CPU) -c $@ $< $(LDR_FLAGS)
+   $(BOARD_SIZE_CHECK)
+
 quiet_cmd_objcopy = OBJCOPY $@
 cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@
 
-- 
2.38.2



Re: [PATCH] build: Revive and update LDR format support

2024-03-19 Thread Tom Rini
On Tue, Mar 19, 2024 at 09:09:22PM -0400, Greg Malysa wrote:

> LDR format files are used primarily by Analog Devices processors but may
> be of interest to other vendors. Previously support existed for this
> format as part of the U-Boot build, but it has been unmaintained and
> unused for a long time. In preparation for adding support for modern ADI
> processors that use LDR, modernize the LDR support:
> 
> - Introduce CONFIG_LDR_CPU as the CPU string recognized by the LDR tool
>   may not be the same as CONFIG_CPU
> - Add an SPL target that repackages u-boot-spl inside an LDR file
> 
> An almost identical target for packaging u-boot into an LDR file already
> exists and did not need to be updated
> 
> Co-developed-by: Nathan Barrett-Morrison 
> Signed-off-by: Nathan Barrett-Morrison 
> Signed-off-by: Ian Roberts 
> Signed-off-by: Greg Malysa 
> 
> ---
> 
>  Kconfig  | 9 -
>  Makefile | 2 +-
>  scripts/Makefile.spl | 5 +
>  3 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/Kconfig b/Kconfig
> index 5710934000..3f3ce6054e 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -715,10 +715,17 @@ config SYS_CLK_FREQ
> A static value for the CPU frequency.  Note that if not required
> for a given SoC, this can be left at 0.
>  
> -source "api/Kconfig"
> +config LDR_CPU
> + string "CPU name to be passed to LDR utility."
> + help
> +   Set the CPU name for the -T parameter in the LDR utility.  This is
> +   generally used on processors from Analog Devices, but may be also
> +   be useful for other vendors.
>  
>  endmenu  # General setup

This looks like a new prompted option, without a default, for every
platform. If so, as is it will cause everything in CI to fail to build.
This should "depend on" some relevant LDR symbol, once that's been
added, rather than as a ground-work patch. This rest seems fine, FWIW.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] build: Revive and update LDR format support

2024-03-19 Thread Greg Malysa
LDR format files are used primarily by Analog Devices processors but may
be of interest to other vendors. Previously support existed for this
format as part of the U-Boot build, but it has been unmaintained and
unused for a long time. In preparation for adding support for modern ADI
processors that use LDR, modernize the LDR support:

- Introduce CONFIG_LDR_CPU as the CPU string recognized by the LDR tool
  may not be the same as CONFIG_CPU
- Add an SPL target that repackages u-boot-spl inside an LDR file

An almost identical target for packaging u-boot into an LDR file already
exists and did not need to be updated

Co-developed-by: Nathan Barrett-Morrison 
Signed-off-by: Nathan Barrett-Morrison 
Signed-off-by: Ian Roberts 
Signed-off-by: Greg Malysa 

---

 Kconfig  | 9 -
 Makefile | 2 +-
 scripts/Makefile.spl | 5 +
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Kconfig b/Kconfig
index 5710934000..3f3ce6054e 100644
--- a/Kconfig
+++ b/Kconfig
@@ -715,10 +715,17 @@ config SYS_CLK_FREQ
  A static value for the CPU frequency.  Note that if not required
  for a given SoC, this can be left at 0.
 
-source "api/Kconfig"
+config LDR_CPU
+   string "CPU name to be passed to LDR utility."
+   help
+ Set the CPU name for the -T parameter in the LDR utility.  This is
+ generally used on processors from Analog Devices, but may be also
+ be useful for other vendors.
 
 endmenu# General setup
 
+source "api/Kconfig"
+
 source "boot/Kconfig"
 
 source "common/Kconfig"
diff --git a/Makefile b/Makefile
index a2bc9d5903..db3272a439 100644
--- a/Makefile
+++ b/Makefile
@@ -1328,7 +1328,7 @@ u-boot-nodtb.bin: u-boot FORCE
 
 u-boot.ldr:u-boot
$(CREATE_LDR_ENV)
-   $(LDR) -T $(CONFIG_CPU) -c $@ $< $(LDR_FLAGS)
+   $(LDR) -T $(CONFIG_LDR_CPU) -c $@ $< $(LDR_FLAGS)
$(BOARD_SIZE_CHECK)
 
 # binman
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 407fc52376..58d6a452e5 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -381,6 +381,11 @@ $(obj)/$(BOARD)-spl.bin: $(obj)/u-boot-spl.bin
$(objtree)/tools/mkexynosspl) $(VAR_SIZE_PARAM) $< $@
 endif
 
+$(obj)/u-boot-spl.ldr: $(obj)/u-boot-spl
+   $(CREATE_LDR_ENV)
+   $(LDR) -T $(CONFIG_LDR_CPU) -c $@ $< $(LDR_FLAGS)
+   $(BOARD_SIZE_CHECK)
+
 quiet_cmd_objcopy = OBJCOPY $@
 cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@
 
-- 
2.38.2



Re: [PATCH v6] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

2024-03-19 Thread Tom Rini
On Wed, Feb 28, 2024 at 05:36:45PM +0530, MD Danish Anwar wrote:

> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
> 
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
> 
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
> 
> Signed-off-by: MD Danish Anwar 
> Acked-by: Ravi Gunasekaran 
> Reviewed-by: Roger Quadros 
> ---
> Changes from v5 to v6:
> *) Collected Acked-by tag from Ravi Gunasekaran 
> *) Fixed few typos as pointed out by Roger Quadros 
> *) Added if condition to check if uc_pdata->fw_name exists and free it
>before the strndup as suggested by Roger Quadros 
> 
> Changes from v4 to v5:
> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>that can be loaded to a rproc.
> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
> *) Allocating the address at a later point in rproc_boot()
> *) Rebased on latest u-boot/master [commit 
>9e00b6993f724da9699ef12573307afea8c19284]
> 
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
> *) Droppped the RFC tag.
> 
> v5: https://lore.kernel.org/all/20240217122602.3402774-1-danishan...@ti.com/
> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
> 
>  drivers/remoteproc/Kconfig|   8 +++
>  drivers/remoteproc/rproc-uclass.c | 102 ++
>  include/remoteproc.h  |  34 ++
>  3 files changed, 144 insertions(+)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 781de530af..9f9877931c 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>  # All users should depend on DM
>  config REMOTEPROC
>   bool
> + select FS_LOADER
>   depends on DM
>  
>  # Please keep the configuration alphabetically sorted.

Can we not make the FS_LOADER portion optional? I didn't realize how
many non-TI platforms this impacted. And even then it's possible I
assume that custom designs will load the firmwares in other manners.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] rpi: Copy eth MAC address from fw DT to loaded DT

2024-03-19 Thread Martin Wetterwald
I reworked the commit message because I noticed the upstream Linux kernel has a
difference with the Raspberry Pi fork of the kernel regarding the algorithm
used to determine the MAC address of the smsc95xx.
There is no smsc95xx.macaddr in the upstream kernel, and using the upstream
kernel is actually the real use case for the patch.

I'm now wondering whether some users are using the module parameter
smsc95xx.macaddr of the Raspberry Pi fork of the kernel to try to change the
MAC, and put one which is not the factory default?
Does this use case exists? If this is the case, the current algorithm in the
forked kernel would mean that, the FDT-provided MAC would have priority over
anything set in the module parameter.
This is already the case anyway when people give to the forked kernel the
firmware-provided FDT (smsc95xx.macaddr is ignored). So this patch aligns
behaviors.
But we should be aware that applying this patch would change the behavior in
the following situation (all conditions need to be true):
- Forked kernel is used
- Fresh FDT (not firmware one) is provided to the kernel
- Custom (not factory) MAC was set in smsc95xx.macaddr parameter

Martin


[PATCH v2] rpi: Copy eth MAC address from fw DT to loaded DT

2024-03-19 Thread Martin Wetterwald
Raspberry Pi B models before model 4 don't have an EEPROM nor an OTP to
store the permanent factory MAC address of the NIC.
So the firmware that runs initially computes the factory MAC address of
the board and patches the DTB to give that information to the next
stage.
The MAC is put in the standard property `local-mac-address` which is
inserted in the `ethernet0` node of the firmware-provided FDT.

Here is the algo used by Linux to determine the MAC address (applies for
all models with smsc95xx). It stops as soon as we find a valid MAC.
1) Look at the FDT (mac-address, local-mac-address, address)
2) Try to fetch MAC from EEPROM (always fails on those Raspberry Pis)
[ 3) Check module parameter smsc95xx.macaddr ]
4) Generate a random MAC if we didn't find anything

Note that step 3) only applies in the Raspberry Pi fork of the Linux
kernel. The upstream kernel doesn't have that step, as that module
variable doesn't exist.

When CONFIG_MISC_INIT_R=y, U-Boot requests directly the MAC from the
running firmware in the GPU through the Raspberry Pi Mailbox. It then
stores it in ${usbethaddr} environment variable.
In U-Boot, the MAC is then often given to Linux like this:

> setenv bootargs [...] smsc95xx.macaddr="${usbethaddr}" [...]

This works in the Raspberry Pi fork of the kernel, because that module
parameter exists. But it doesn't work in the upstream kernel.
With the upstream kernel: if we make U-Boot forward the firmware-patched
FDT directly to the kernel, the MAC will be correct, because
`local-mac-addr` will be present. But if we configure U-Boot to give a
fresh FDT to the kernel, the MAC will be randomly generated because the
`local-mac-addr` property set by the firmware was not copied by U-Boot
to the loaded FDT.

This patch extends commit 6d0642494993 ("rpi: Copy properties from
firmware dtb to the loaded dtb") by making U-Boot copy the
`local-mac-address` property from the firmware FDT to the loaded FDT.
It makes it then possible to use the upstream kernel and to give it a
fresh FDT (not the firmware-provided one) without having the kernel
generate a random MAC address.

Note that this is only possible if CONFIG_OF_BOARD_SETUP=y and
ft_board_setup() is called.

Cc: Matthias Brugger 
Cc: Peter Robinson 
Cc: Antoine Mazeas 
Signed-off-by: Martin Wetterwald 
---

Changes in v2:
- Clarify the commit message by pointing out that smsc95xx.macaddr
  module param only exists in the Raspberry Pi fork of the Linux kernel
  and not upstream
- Make the intent of the patch clearer in the commit message (booting
  upstream kernel + fresh FDT without having a random-generated MAC)

 board/raspberrypi/rpi/rpi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 2851ebc985..b36a893047 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -566,6 +566,9 @@ void  update_fdt_from_fw(void *fdt, void *fw_fdt)
 
/* address of the PHY device as provided by the firmware  */
copy_property(fdt, fw_fdt, "ethernet0/mdio@e14/ethernet-phy@1", "reg");
+
+   /* MAC address of the NIC as provided by the firmware */
+   copy_property(fdt, fw_fdt, "ethernet0", "local-mac-address");
 }
 
 int ft_board_setup(void *blob, struct bd_info *bd)
-- 
2.44.0



Re: [PATCH v3 4/7] efi_selftest: Add international characters test

2024-03-19 Thread Janne Grunau
On Sun, Mar 17, 2024 at 10:24:13AM +0100, Heinrich Schuchardt wrote:
> On 3/16/24 22:50, Janne Grunau via B4 Relay wrote:
> > From: Andre Przywara 
> >
> > UEFI relies entirely on unicode output, which actual fonts displayed on
> > the screen might not be ready for.
> >
> > Add a test displaying some international characters, to reveal missing
> > glyphs, especially in our builtin fonts.
> > This would be needed to be manually checked on the screen for
> > correctness.
> >
> > Signed-off-by: Andre Przywara 
> > Suggested-by: Heinrich Schuchardt 
> > Signed-off-by: Janne Grunau 
> > ---
> >   lib/efi_selftest/efi_selftest_textoutput.c | 21 +
> >   1 file changed, 21 insertions(+)
> >
> > diff --git a/lib/efi_selftest/efi_selftest_textoutput.c 
> > b/lib/efi_selftest/efi_selftest_textoutput.c
> > index cc44b38bc2..917903473d 100644
> > --- a/lib/efi_selftest/efi_selftest_textoutput.c
> > +++ b/lib/efi_selftest/efi_selftest_textoutput.c
> > @@ -31,6 +31,21 @@ static int execute(void)
> > 0xD804, 0xDC22,
> > 0};
> >
> > +   const u16 text[] =
> > +u"This should render international characters as described\n"
> > +u"U+00D6 \u00D6 - Latin capital letter O with diaresis\n"
> > +u"U+00DF \u00DF - Latin small letter sharp s\n"
> > +u"U+00E5 \u00E5 - Latin small letter a with ring above\n"
> > +u"U+00E9 \u00E9 - Latin small letter e with acute\n"
> > +u"U+00F1 \u00F1 - Latin small letter n with tilde\n"
> > +u"U+00F6 \u00F6 - Latin small letter o with diaresis\n"
> > +u"The following characters will render as '?' with bitmap fonts\n"
> > +u"U+00F8 \u00F8 - Latin small letter o with stroke\n"
> > +u"U+03AC \u03AC - Greek small letter alpha with tonus\n"
> > +u"U+03BB \u03BB - Greek small letter lambda\n"
> > +u"U+03C2 \u03C2 - Greek small letter final sigma\n"
> > +u"U+1F19 \u1F19 - Greek capital letter epsilon with dasia\n";
> 
> The strings should be indented by two tabs.

done locally for all selftests, I'm waiting on fedback for Patch 2 and 3
before resending.

thanks

Janne


Re: [PATCH v2 8/8] board: add support for Qualcomm SA8155P-ADP board

2024-03-19 Thread Volodymyr Babchuk


Hi,

Volodymyr Babchuk  writes:

> Caleb Connolly  writes:
>
>> On 11/03/2024 18:23, Volodymyr Babchuk wrote:
>>> Hi Caleb,
>>> Caleb Connolly  writes:
>>> 
 On 06/03/2024 21:24, Volodymyr Babchuk wrote:
>
> Hi Caleb,
>
> Caleb Connolly  writes:
>
> [...]
> +};
> +
> + {
> +   /* U-Boot pinctrl driver does not understand multiple tiles */
> +   reg = <0x0 0x0300 0x0 0x100>;
> +   /delete-property/ reg-names;

 This won't be needed if we can make the tiles offset in the pinctrl
 driver compatible:

 #define WEST   0x
 #define EAST   0x0040
 #define NORTH  0x0080
 #define SOUTH  0x00C0
>>>
>>> Hmm, I assume that in this case pinctrl driver should map all the four
>>> tiles independently? Are there guarantees in U-Boot that four separate
>>> memory regions will be mapped into virtual memory with the same relative
>>> positions? Linux clearly don't make such guarantees.
>>
>> U-Boot doesn't use virtual addresses on arm platforms, it only goes as
>> far as reading the address from DT, nothing else, so this is totally
>> fine and is how the other SoCs do it.
>
> For me it looks like we are depending on implementation details
> knowledge. I.e MMU API does not provide such guarantees, but drivers
> know how ARM MMU code is working internally and drivers depend on
> exactly this behavior. But if you are saying that it is totally fine,
> I'll rework the patch. No big deal. Actually, I already tried this and
> it is working fine.
>
> +
> +   /* U-Boot ethernet driver wants to drive reset as GPIO */
> +   /delete-node/ phy-reset-pins;

 I suppose this is not needed as phy-reset-pins also configures the pin
 as GPIO only.

>>> Well, yes. This also puzzles me up, but for some reason it stops working
>>> if I leave this node intact. Looks like I need to look at this deeper
>>> before posting the next version.
>>
>> Possibly the pinconf defined in the phy-reset-pins node causes U-Boot to
>> misbehave, can you check if this patch fixes it (there is a bug in the
>> line "return msm_gpio_direction_input(dev, gpio);", it should become
>> just "msm_gpio_direction_input(dev, gpio);").
>>
>> I had the exact same issue with the gpio-regulator driver and this was
>> the solution I ended up going with.
>>
>> https://urldefense.com/v3/__https://lore.kernel.org/u-boot/20240131-b4-qcom-livetree-v1-7-4071c0787...@linaro.org/__;!!GF_29dbcQIUBPA!xFhZe7DKgRbr63sirEJLuH-B0AnGs7jvx8tdJPKLTgFuZ3I3_zpVml7l23G-_vJO_JiUR-wUO4GMPJFcE-8p50H3pf7nbxit$
>> [lore[.]kernel[.]org]
>
> It is exactly this. With your patch I don't need to /delete-node/
> anymore. I'll add a comment in the cover message that this series are
> depended on your patch.

 Please can you split the power domain and clock patches into a separate
 series? As I'd like to depend on them for the next revision of my
 series, and we'd otherwise have a cyclical dependency.
>>> Of course.
>>> As I understood, you are interested in "clk: qcom: clear div mask
>>> before
>>> assigning a new divider" and "clk: qcom: add support for power domains
>>> uclass", correct?
>>
>> Yes.
>
> Okay, I'll send it today.
>
>> I tried the power domain stuff out on SMD845 today and ran into
>> quite a few issues. Specifically as a lot of the devices reference the
>> rpmhpd power domain which we don't support (and don't *need* to
>> support) in U-Boot. I'm not sure what the best way forward will be for
>> this. Maybe a "nop" power domain driver?
>
> Are you sure that they are not required?
>
> "nop" power domain always is the option. Especially if it prints some
> warning about an unknown device. I had quite a lot of issues with clock and
> pin drivers that silently ignore unknown devices...
>
>> Do you have the same issues on sm8150?
>
> Yes and no. No, because I was lucky so far and devices I tried to use in
> U-Boot does not require rpmhpd. Looking at DTS, I may only encounter
> issues with sdhc_2, which requires rpmhpd for some reason. Also UFS
> requires clock from rpmhcc.
>
> And "yes", because I have found root cause for my troubles with UFS in
> Linux kernel, when I am skipping hyp.mbn. This is not strictly related
> to U-Boot, but you may be interested in this: apparently Qualcomm's
> hypervisor enables access to RPM (maybe brings it out of reset?). cmd-db
> shared memory region can't be accessed if I skip the hypervisor and try
> to boot directly into Linux. So now I am looking for ways to enable it.

I want to share the solution, in case if someone got the same
problem. It all boiled down to correct memory attributes. Qualcomm's
hypervisor mapped cmd-db shared memory as non-cached in Stage 2

Re: [PATCH v2 4/6] usb: Add environment based device blocklist

2024-03-19 Thread Janne Grunau
On Mon, Mar 18, 2024 at 03:17:33PM +0100, Marek Vasut wrote:
> On 3/18/24 8:33 AM, Janne Grunau wrote:
> 
> > +static int usb_blocklist_parse_error(const char *blocklist, size_t pos)
> > +{
> > +   printf("usb_blocklist parse error at char %zu in \"%s\"\n", pos,
> > +  blocklist);
> > +   return 0;
> 
>  This could be static void without return 0 at the end.
> >>>
> >>> the return is there to break out of the while loop on parsing errors in a 
> >>> single statement. This probably won't be necessary after using strsep and 
> >>> sscanf in the parsing function but see below.
> >>
> >> Ahh, now I see it. But then, shouldn't this return -ENODEV here already ?
> > 
> > It returns 0 so that parsing errors in the blocklist do not result
> > in blocking every USB device. That looked to me like the
> > less bad error behavior to me.
> 
> In unix , 0 is considered success and non-zero failure .
> 
> How about this:
> 
> - Return -EINVAL here (parsing failed)

If we return 0 / negated errors we do not need this function and we can
simply report the parsing error when usb_device_is_blocked() return
-EINVAL.

> - Instead of 'return 1' in usb_device_is_blocked() return -ENODEV
> - In usb_select_config(), check
>if usb_device_is_blocked returned 0, no device blocked OK
>if usb_device_is_blocked returned -ENODEV, device blocked,
>  return -ENODEV
>if usb_device_is_blocked returned any other error, parsing error
>  return that error

I think the preferable option is to ignore parsing errors. If we
would propagate the error the result would be that every USB device is
ignored. 
 
> What do you think ?

Fine by me, -EINVAL makes the parsing error reporting less awkward. Only
open question is what should happen on parsing errors.

locally modified and ready to resend once we agree on the behavior on
parsing errors

Janne


Re: [PATCH] Makefile: Add missing OF_UPSTREAM Makefile for 32bit ARM

2024-03-19 Thread Tony Dinh
Thanks, Sumit!

On Tue, Mar 19, 2024 at 6:02 AM Adam Ford  wrote:
>
> On Mon, Mar 18, 2024 at 10:03 AM Marek Vasut
>  wrote:
> >
> > Copy dts/upstream/src/arm64/Makefile into dts/upstream/src/arm/Makefile
> > and create a commit. This makes 32bit ARM buildable with OF_UPSTREAM .
> >
> > Signed-off-by: Marek Vasut 
>
> Tested-by: Adam Ford  #am3517-evm

Tested-by: Tony Dinh 

All the best,
Tony

>
> > ---
> > Cc: Adam Ford 
> > Cc: Biju Das 
> > Cc: Lad Prabhakar 
> > Cc: Paul Barker 
> > Cc: Ralph Siemsen 
> > Cc: Tom Rini 
> > ---
> >  dts/upstream/src/arm/Makefile | 14 ++
> >  1 file changed, 14 insertions(+)
> >  create mode 100644 dts/upstream/src/arm/Makefile
> >
> > diff --git a/dts/upstream/src/arm/Makefile b/dts/upstream/src/arm/Makefile
> > new file mode 100644
> > index 000..9a8f6aa3584
> > --- /dev/null
> > +++ b/dts/upstream/src/arm/Makefile
> > @@ -0,0 +1,14 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +include $(srctree)/scripts/Makefile.dts
> > +
> > +targets += $(dtb-y)
> > +
> > +# Add any required device tree compiler flags here
> > +DTC_FLAGS += -a 0x8
> > +
> > +PHONY += dtbs
> > +dtbs: $(addprefix $(obj)/, $(dtb-y))
> > +   @:
> > +
> > +clean-files := */*.dtb */*.dtbo
> > --
> > 2.43.0
> >


Re: [PATCH] arm: dts: k3-am625-verdin-r5: Change CPU frequency to 800MHz

2024-03-19 Thread Tom Rini
On Tue, Mar 19, 2024 at 04:05:31PM +0100, Francesco Dolcini wrote:
> Hello Tom,
> 
> On Tue, Mar 19, 2024 at 11:04:27AM -0300, Joao Paulo Goncalves wrote:
> > From: Joao Paulo Goncalves 
> > 
> > The lowest speed grade of Toradex AM62 SoMs is K speed, resulting in a
> > max value of 800MHz for the CPU operating frequency. A solution with
> > runtime selection of the CPU frequency is already planned to avoid these
> > kinds of problems in the future.
> > 
> > Fixes: 8fb8a6d49977 ("arm: dts: k3-am625-verdin-r5:Change CPU
> > frequency to 1000MHz")
> > Signed-off-by: Joao Paulo Goncalves 
> 
> We have a patch ready to make the frequency adjusted at runtime that
> should be on the mailing list in a day or so, as suggested by Vignesh,
> targetting uboot-next, this one fix should go into master however.

OK, noted, thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/2] clk: clk-imx8qxp: Add LPUART IPG entries

2024-03-19 Thread Tom Rini
On Mon, Mar 18, 2024 at 09:14:53PM -0300, Fabio Estevam wrote:
> Hi Tom and Sean,
> 
> On Fri, Mar 8, 2024 at 5:13 PM Fabio Estevam  wrote:
> >
> > Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
> > the colibri-imx8qxp board no longer boots.
> >
> > The reason is that the imx8qxp clock driver does not handle the
> > LPUART IPG clocks inside get_rate(), set_rate() and enable() functions.
> >
> > Fix the boot regression by adding the LPUART IPG entries.
> >
> > Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
> > Reported-by: Marcel Ziswiler 
> > Signed-off-by: Fabio Estevam 
> 
> Please consider applying this series to 2024.04.
> 
> It fixes a boot regression on imx8qxp and imx8qm.

Fine with me, Sean?

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull Request: Please pull u-boot-socfpga-next-20240319

2024-03-19 Thread Tom Rini
On Tue, Mar 19, 2024 at 06:14:54AM +, Chee, Tien Fong wrote:

> Dear Tom,
> 
> Please pull the SoCFPGA changes for next from u-boot-socfpga, containing:
> 
>   1.  A new driver in the misc to register setting from device tree. This 
> also provides user a clean interface and all register
> 
> settings are centralized in one place, device tree.
> 
>   1.  Enable Agilex5 platform for Intel product. Changes, modification and 
> new files are created for board, dts, configs and
> 
> makefile to create the base for Agilex5.
> 
>   Build-tested on SoC64 boards, boot tested on some of them.
> 
> Best regards,
> Tien Fong
> 
> The following changes since commit 86fd291a7990af84e96808f48eff2219dd4ef496:
> 
>   Merge tag 'efi-2024-04-rc5' of 
> https://source.denx.de/u-boot/custodians/u-boot-efi (2024-03-13 20:39:46 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-socfpga.git 
> tags/u-boot-socfpga-next-20240319
> 
> for you to fetch changes up to 386fca68960994ece0d9da8a69a14495b5f1aedf:
> 
>   arch: arm: Agilex5 enablement (2024-03-18 14:45:47 +0800)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] configs: am6*_evm_a53_defconfig: Enable config to support mmc rescan

2024-03-19 Thread Judith Mendez
Enable MMC_SPEED_MODE_SET config option in defconfig to enable
mmc rescan for various Sitara devices.

Signed-off-by: Judith Mendez 
---
 configs/am62px_evm_a53_defconfig | 1 +
 configs/am62x_evm_a53_defconfig  | 1 +
 configs/am64x_evm_a53_defconfig  | 1 +
 configs/am65x_evm_a53_defconfig  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/am62px_evm_a53_defconfig b/configs/am62px_evm_a53_defconfig
index 2621abb8ce..6dbdd427ec 100644
--- a/configs/am62px_evm_a53_defconfig
+++ b/configs/am62px_evm_a53_defconfig
@@ -73,6 +73,7 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_CMD_UBI=y
+CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_MULTI_DTB_FIT=y
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 4c1e4d7cc4..a25f7b2223 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -50,6 +50,7 @@ CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
 CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_CMD_MMC=y
+CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_MULTI_DTB_FIT=y
diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index b7057be3d6..179c42a544 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -72,6 +72,7 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
+CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="ti/k3-am642-evm ti/k3-am642-sk"
diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 500335f7e6..3afa80f45a 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -73,6 +73,7 @@ CONFIG_CMD_TIME=y
 CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=4704.spi.0:512k(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),128k(ospi.env),128k(ospi.env.backup),1m(ospi.sysfw),-@8m(ospi.rootfs)"
 CONFIG_CMD_UBI=y
+CONFIG_MMC_SPEED_MODE_SET=y
 # CONFIG_ISO_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y

base-commit: b145877c22b391a4872c875145a8f86f6ffebaba
-- 
2.43.2



Re: [PATCH] clk: Propagate clk_set_rate() if CLK_SET_PARENT_RATE present

2024-03-19 Thread Sam Protsenko
On Thu, Mar 7, 2024 at 6:04 PM Sam Protsenko  wrote:
>
> Sometimes clocks provided to a consumer might not have .set_rate
> operation (like gate or mux clocks), but have CLK_SET_PARENT_RATE flag
> set. In that case it's usually possible to find a parent up the tree
> which is capable of setting the rate (div, pll, etc). Implement a simple
> lookup procedure for such cases, to traverse the clock tree until
> .set_rate capable parent is found, and use that parent to actually
> change the rate. The search will stop once the first .set_rate capable
> clock is found, which is usually enough to handle most cases.
>
> Signed-off-by: Sam Protsenko 
> ---

Hi Lukasz, Sean, Tom,

If this patch looks good to you and there are no outstanding comments,
can you please apply it? It's needed as a part of eMMC enablement for
E850-96 board, as eMMC gate (leaf) clock is specified as ciu clock in
dts, which requires further clock rate change propagation up to
divider clock.

Thanks!

>  drivers/clk/clk-uclass.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index ed6e60bc4841..755f05f34669 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -571,8 +571,20 @@ ulong clk_set_rate(struct clk *clk, ulong rate)
> return 0;
> ops = clk_dev_ops(clk->dev);
>
> -   if (!ops->set_rate)
> -   return -ENOSYS;
> +   /* Try to find parents which can set rate */
> +   while (!ops->set_rate) {
> +   struct clk *parent;
> +
> +   if (!(clk->flags & CLK_SET_RATE_PARENT))
> +   return -ENOSYS;
> +
> +   parent = clk_get_parent(clk);
> +   if (IS_ERR_OR_NULL(parent) || !clk_valid(parent))
> +   return -ENODEV;
> +
> +   clk = parent;
> +   ops = clk_dev_ops(clk->dev);
> +   }
>
> /* get private clock struct used for cache */
> clk_get_priv(clk, );
> --
> 2.39.2
>


Re: [PATCH 0/4] clk: exynos: Prepare clocks for eMMC enablement

2024-03-19 Thread Sam Protsenko
Hi Lukasz, Sean, Tom,

If there are no comments on this series, can you please apply it?

Thanks!

On Thu, Mar 7, 2024 at 8:18 PM Sam Protsenko  wrote:
>
> This short series features a couple of Exynos850 clock driver fixes and
> adds new clocks needed for further eMMC and SD card enablement.
>
> Sam Protsenko (4):
>   clk: exynos: Re-arrange clocks in Exynos850 CMU_TOP
>   clk: exynos: Don't expose prototypes for not used functions
>   clk: exynos: Fix incorrect clock lookup for non-top CMUs
>   clk: exynos: Add CMU_CORE and CMU_HSI for Exynos850
>
>  drivers/clk/exynos/clk-exynos850.c | 326 ++---
>  drivers/clk/exynos/clk-pll.c   |   6 +-
>  drivers/clk/exynos/clk-pll.h   |   6 +
>  drivers/clk/exynos/clk.c   |  47 +++--
>  drivers/clk/exynos/clk.h   |  70 +--
>  5 files changed, 384 insertions(+), 71 deletions(-)
>
> --
> 2.39.2
>


Re: [PATCH v2 1/2] arm: socfpga: arria10: add option to reprogram the FPGA every reboot

2024-03-19 Thread Michał Barnaś
On Fri, Mar 8, 2024 at 8:01 PM Marek Vasut  wrote:
>
> On 3/8/24 6:12 PM, Michał Barnaś wrote:
> > Add Kconfig that enables FPGA reprogramming with warm boot on Arria 10.
> > This option allows to change the bitstream on the filesystem and apply
> > changes with warm reboot without the need for a power cycle.
> >
> > Signed-off-by: Michał Barnaś 
> > ---
> >
> > Changes in v2:
> > - Rebase on current master branch
> >
> >   arch/arm/mach-socfpga/Kconfig   | 8 
> >   arch/arm/mach-socfpga/spl_a10.c | 8 
> >   2 files changed, 16 insertions(+)
> >
> > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
> > index 114d243812..89303f1f16 100644
> > --- a/arch/arm/mach-socfpga/Kconfig
> > +++ b/arch/arm/mach-socfpga/Kconfig
> > @@ -80,6 +80,14 @@ config TARGET_SOCFPGA_ARRIA10
> >   imply FPGA_SOCFPGA
> >   imply SPL_USE_TINY_PRINTF
> >
> > +config TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
>
> This is not TARGET (as in SoC), but a regular config option, so please
> drop the TARGET_ prefix .
>
> > + bool "Always reprogram Arria 10 FPGA"
> > + depends on TARGET_SOCFPGA_ARRIA10
> > + help
> > +   Arria 10 FPGA is only programmed during the cold boot.
> > +   This option forces the FPGA to be reprogrammed every reboot,
> > +   allowing to change the bitstream and apply it with warm reboot.
> > +
> >   config TARGET_SOCFPGA_CYCLONE5
> >   bool
> >   select TARGET_SOCFPGA_GEN5
> > diff --git a/arch/arm/mach-socfpga/spl_a10.c 
> > b/arch/arm/mach-socfpga/spl_a10.c
> > index 9edbbf4a29..d5d3327a42 100644
> > --- a/arch/arm/mach-socfpga/spl_a10.c
> > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > @@ -122,7 +122,11 @@ void spl_board_init(void)
> >   arch_early_init_r();
> >
> >   /* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins 
> > */
> > +#ifdef CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
> > + if (is_regular_boot_valid()) {
> > +#else
> >   if (is_fpgamgr_user_mode()) {
> > +#endif
>
> Use CONFIG_IS_ENABLED() or IS_ENABLED() macro please .

I used the ifdefs because I thought that it would be more readable,
but changed as you requested.
Thank you for your response.


[PATCH v3 2/2] chameleonv3: set in defconfig for FPGA to reprogram every reboot

2024-03-19 Thread Michał Barnaś
Set CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM as enabled in
chameleon v3 board's defconfig.

Signed-off-by: Michał Barnaś 
---

Changes in v3:
- Update defconfig to use renamed Kconfig

 configs/socfpga_chameleonv3_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_chameleonv3_defconfig 
b/configs/socfpga_chameleonv3_defconfig
index 6ea61ca6ea..7506aa8d32 100644
--- a/configs/socfpga_chameleonv3_defconfig
+++ b/configs/socfpga_chameleonv3_defconfig
@@ -7,6 +7,7 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_chameleonv3_480_2"
 CONFIG_SPL_TEXT_BASE=0xFFE0
 CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_TARGET_SOCFPGA_CHAMELEONV3=y
+CONFIG_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM=y
 CONFIG_SPL_FS_FAT=y
 CONFIG_FIT=y
 CONFIG_SPL_FIT=y
-- 
2.44.0.291.gc1ea87d7ee-goog



[PATCH v3 1/2] arm: socfpga: arria10: add option to reprogram the FPGA every reboot

2024-03-19 Thread Michał Barnaś
Add Kconfig that enables FPGA reprogramming with warm boot on Arria 10.
This option allows to change the bitstream on the filesystem and apply
changes with warm reboot without the need for a power cycle.

Signed-off-by: Michał Barnaś 
---

Changes in v3:
- Rebase on current master branch
- Drop the TARGET_ prefix in Kconfig
- Remove #ifdefs and use IS_ENABLED

Changes in v2:
- Rebase on current master branch

 arch/arm/mach-socfpga/Kconfig   | 8 
 arch/arm/mach-socfpga/spl_a10.c | 8 ++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 114d243812..a89bd8ca58 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -80,6 +80,14 @@ config TARGET_SOCFPGA_ARRIA10
imply FPGA_SOCFPGA
imply SPL_USE_TINY_PRINTF
 
+config SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
+   bool "Always reprogram Arria 10 FPGA"
+   depends on TARGET_SOCFPGA_ARRIA10
+   help
+ Arria 10 FPGA is only programmed during the cold boot.
+ This option forces the FPGA to be reprogrammed every reboot,
+ allowing to change the bitstream and apply it with warm reboot.
+
 config TARGET_SOCFPGA_CYCLONE5
bool
select TARGET_SOCFPGA_GEN5
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index 9edbbf4a29..3981d2d4f1 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -122,7 +122,10 @@ void spl_board_init(void)
arch_early_init_r();
 
/* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins */
-   if (is_fpgamgr_user_mode()) {
+   if ((IS_ENABLED(CONFIG_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM) &&
+is_regular_boot_valid()) ||
+   (!IS_ENABLED(CONFIG_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM) &&
+is_fpgamgr_user_mode())) {
ret = config_pins(gd->fdt_blob, "shared");
if (ret)
return;
@@ -130,7 +133,8 @@ void spl_board_init(void)
ret = config_pins(gd->fdt_blob, "fpga");
if (ret)
return;
-   } else if (!is_fpgamgr_early_user_mode()) {
+   } else if (IS_ENABLED(CONFIG_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM) ||
+  !is_fpgamgr_early_user_mode()) {
/* Program IOSSM(early IO release) or full FPGA */
fpgamgr_program(buf, FPGA_BUFSIZ, 0);
 
-- 
2.44.0.291.gc1ea87d7ee-goog



[PATCH v3 0/2] arm: socfpga: arria10: allow to reprogram FPGA with warm reboot

2024-03-19 Thread Michał Barnaś


By default, the board requires power cycle (cold boot) to program the
FPGA with bitstream. This change adds Kconfig that allows to enable
reprogramming the FPGA with every boot. This makes the update process
of the bitstream on the filesystem to be applied with simple system
reboot.

Changes in v3:
- Rebase on current master branch
- Drop the TARGET_ prefix in Kconfig
- Remove #ifdefs and use IS_ENABLED
- Update defconfig to use renamed Kconfig

Changes in v2:
- Rebase on current master branch

Michał Barnaś (2):
  arm: socfpga: arria10: add option to reprogram the FPGA every reboot
  chameleonv3: set in defconfig for FPGA to reprogram every reboot

 arch/arm/mach-socfpga/Kconfig | 8 
 arch/arm/mach-socfpga/spl_a10.c   | 8 ++--
 configs/socfpga_chameleonv3_defconfig | 1 +
 3 files changed, 15 insertions(+), 2 deletions(-)

-- 
2.44.0.291.gc1ea87d7ee-goog



Re: [PATCH] rockchip: spl: Cache boot source id for later use

2024-03-19 Thread Jonas Karlman
Hi Quentin,

On 2024-03-19 11:19, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 3/15/24 18:34, Jonas Karlman wrote:
>> Rockchip BROM write a boot source id at CFG_IRAM_BASE + 0x10, the id
>> indicate from what storage media TPL/SPL was loaded from.
>>
>> SPL use this value to determine what device "same-as-spl" represent when
>> determining from where FIT should be loaded. This works as long as the
>> boot_devices array contain a matching id <-> node path entry.
>>
>> However, SPL typically load a small part of TF-A into SRAM and on RK3399
>> this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.
>>
>> Here boot source id is 3 before FIT images is loaded, and 0 after:
>>
>>U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +)
>>board_spl_was_booted_from: brom_bootdevice_id 3 maps to 
>> '/spi@ff1d/flash@0'
>>Trying to boot from SPI
>>## Checking hash(es) for config config-1 ... OK
>>## Checking hash(es) for Image atf-1 ... sha256+ OK
>>## Checking hash(es) for Image u-boot ... sha256+ OK
>>## Checking hash(es) for Image fdt-1 ... sha256+ OK
>>## Checking hash(es) for Image atf-2 ... sha256+ OK
>>## Checking hash(es) for Image atf-3 ... sha256+ OK
>>board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
>>spl_decode_boot_device: could not find udevice for /mmc@fe33
>>spl_decode_boot_device: could not find udevice for /mmc@fe32
>>spl_perform_fixups: could not map boot_device to ofpath: -19
>>
>> Use a static bootdevice_brom_id to cache the boot source id after an
>> initial read from SRAM to fix this, this allow spl_perform_fixups() to
>> resolve correct boot source path for "same-as-spl" after SPL have loaded
>> TF-A related FIT images into memory.
>>
>> With this the spl-boot-device prop can correctly be resolved to the
>> SPI flash node in the control FDT:
>>
>>=> fdt addr ${fdtcontroladdr}
>>Working FDT set to f1ee6710
>>=> fdt list /chosen
>>chosen {
>>u-boot,spl-boot-device = "/spi@ff1d/flash@0";
>>stdout-path = "serial2:150n8";
>>u-boot,spl-boot-order = "same-as-spl", "/mmc@fe33", 
>> "/mmc@fe32";
>>};
>>
> 
> I'm perplexed. We make use of this spl-boot-device DT property on Puma 
> (RK3399) and Ringneck (PX30) and I am pretty sure I tested it does what 
> it's supposed to do. So that is a bit surprising this seems to not work 
> anymore. Is this related to the BSS/stack memory address location 
> changes you made recently by any chance? Or did I manage to be very 
> lucky for a very long time for our boards?

As you figured out below, this is currently only an issue with SPI flash
because it was only the SPI flash code path that re-used boot source id
after FIT images have been loaded into memory.

> 
> """
> U-Boot SPL 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 
> +0100)
> board_spl_was_booted_from: brom_bootdevice_id 5 maps to '/mmc@fe32'
> Trying to boot from MMC2
> load_simple_fit: Skip load 'atf-5': image size is 0!
> NOTICE:  BL31: v2.9(release):v2.9.0
> NOTICE:  BL31: Built : 17:47:58, Jun 21 2023
> 
> 
> U-Boot 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 +0100)
> [...]
> => fdt addr ${fdtcontroladdr}
> Working FDT set to f1f13d10
> => fdt list /chosen
> chosen {
>   u-boot,spl-boot-device = "/mmc@fe32";
>   stdout-path = "serial0:115200n8";
>   u-boot,spl-boot-order = "same-as-spl", "/spi@ff1d/flash@0", 
> "/mmc@fe33", "/mmc@fe32";
> };
> """
> 
> for Puma when booting from SD card... I don't see 
> board_spl_was_booted_from being called a second time after BL31 is loaded?
> 
> mmm
> 
> Very interestingly, when booting from SPI-NOR flash:
> 
> """
> U-Boot SPL 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 
> +0100)
> board_spl_was_booted_from: brom_bootdevice_id 3 maps to 
> '/spi@ff1d/flash@0'
> Trying to boot from SPI
> load_simple_fit: Skip load 'atf-5': image size is 0!
> board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
> NOTICE:  BL31: v2.9(release):v2.9.0
> NOTICE:  BL31: Built : 17:47:58, Jun 21 2023
> 
> 
> U-Boot 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 +0100)
> [...]
> => fdt addr ${fdtcontroladdr}
> Working FDT set to f1f13d10
> => fdt list /chosen
> chosen {
>   u-boot,spl-boot-device = "/spi@ff1d/flash@0";
>   stdout-path = "serial0:115200n8";
>   u-boot,spl-boot-order = "same-as-spl", "/spi@ff1d/flash@0", 
> "/mmc@fe33", "/mmc@fe32";
> };
> """
> 
> but the DT is properly written...
> 
> Ahah! This is because of one of my commits where I added support for 
> SPI-NOR flashes to spl_perform_fixups. So I think this worked for me 
> because the SPI-NOR flash is explicitly listed in spl-boot-order for 
> Puma, so when same-as-spl fails to resolve, the device is still found in 
> spl-boot-order DT property which means spl_perform_fixup will still be 
> able to write that spl-boot-device 

[PATCH] scripts/Makefile.spl: Use 'sort' in SHRUNK_ARCH_DTB rule

2024-03-19 Thread Tom Rini
With configs such as "am64x_evm_a53" or "imx8mp_venice" which list
multiple device trees to build we get a warning such as:
scripts/Makefile.spl:578: target 'spl/dts/freescale/' given more than once in 
the same rule

If we sort this list first the warning goes away.

Signed-off-by: Tom Rini 
---
 scripts/Makefile.spl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index d074ba235006..60db38d5bddd 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -575,7 +575,7 @@ endif
 
 SPL_OF_LIST_TARGETS = $(patsubst %,dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST)))
 SHRUNK_ARCH_DTB = $(addprefix $(obj)/,$(SPL_OF_LIST_TARGETS))
-$(dir $(SHRUNK_ARCH_DTB)):
+$(sort $(dir $(SHRUNK_ARCH_DTB))):
$(shell [ -d $@ ] || mkdir -p $@)
 
 .SECONDEXPANSION:
-- 
2.34.1



Re: [PATCH] cmd: bootm: add ELF file support

2024-03-19 Thread Maxim M. Moskalets

Hi Sean

On 19.03.2024 19:15, Sean Anderson wrote:

Hi Maxim,

On 3/19/24 12:10, Maxim Moskalets wrote:

[You don't often get email from maximmo...@gmail.com. Learn why this is important at 
https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2faka.ms%2fLearnAboutSenderIdentification=d3728a4f-0e7b-4ded-94bc-5bd133b6deef=d807158c60b7d2502abde8a2fc01f40662980862-7a67d937c0016d0d3292f79af55f0ce3d78f480b
 ]

Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.

Why not use objcopy to create a binary?

--Sean
When expanding ELF to binary, the size can grow significantly due to the 
layout of the file.
ELF is also more convenient for debugging due to its clear structure and 
ease of getting symbols and other debugging information.


--Maxim

Signed-off-by: Maxim Moskalets 
---
  boot/bootm_os.c  | 21 +
  boot/image-fit.c |  3 ++-
  boot/image.c |  3 +++
  include/image.h  |  1 +
  4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index ccde72d22c..71bfb34926 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -395,6 +395,24 @@ static int do_bootm_qnxelf(int flag, struct bootm_info 
*bmi)
  }
  #endif

+#if defined(CONFIG_CMD_ELF)
+static int do_bootm_elf(int flag, struct bootm_info *bmi)
+{
+   struct bootm_headers *images = bmi->images;
+   char *local_args[2] = {NULL};
+   char str[19] = ""; /* "0x" + 16 digits + "\0" */
+
+   sprintf(str, "0x%lx", images->ep); /* write entry-point into string */
+   str[18] = '\0';
+   local_args[0] = bmi->argv[0];
+   local_args[1] = str;/* and provide it via the arguments */
+
+   do_bootelf(NULL, 0, 2, local_args);
+
+   return 1;
+}
+#endif
+
  #ifdef CONFIG_INTEGRITY
  static int do_bootm_integrity(int flag, struct bootm_info *bmi)
  {
@@ -536,6 +554,9 @@ static boot_os_fn *boot_os[] = {
  #ifdef CONFIG_BOOTM_EFI
 [IH_OS_EFI] = do_bootm_efi,
  #endif
+#if defined(CONFIG_CMD_ELF)
+   [IH_OS_ELF] = do_bootm_elf,
+#endif
  };

  /* Allow for arch specific config before we boot */
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 89e377563c..0419bef6d2 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -2180,7 +2180,8 @@ int fit_image_load(struct bootm_headers *images, ulong 
addr,
 fit_image_check_os(fit, noffset, IH_OS_TEE) ||
 fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
 fit_image_check_os(fit, noffset, IH_OS_EFI) ||
-   fit_image_check_os(fit, noffset, IH_OS_VXWORKS);
+   fit_image_check_os(fit, noffset, IH_OS_VXWORKS) ||
+   fit_image_check_os(fit, noffset, IH_OS_ELF);

 /*
  * If either of the checks fail, we should report an error, but
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a..5b88d6808c 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -134,6 +134,9 @@ static const table_entry_t uimage_os[] = {
  #endif
 {   IH_OS_OPENSBI,  "opensbi",  "RISC-V OpenSBI",   },
 {   IH_OS_EFI,  "efi",  "EFI Firmware" },
+#ifdef CONFIG_CMD_ELF
+   {   IH_OS_ELF,  "elf",  "ELF Image" },
+#endif

 {   -1, "", "", },
  };
diff --git a/include/image.h b/include/image.h
index 21de70f0c9..9a40bca22c 100644
--- a/include/image.h
+++ b/include/image.h
@@ -100,6 +100,7 @@ enum {
 IH_OS_TEE,  /* Trusted Execution Environment */
 IH_OS_OPENSBI,  /* RISC-V OpenSBI */
 IH_OS_EFI,  /* EFI Firmware (e.g. GRUB2) */
+   IH_OS_ELF,  /* ELF Image (e.g. seL4) */

 IH_OS_COUNT,
  };
--
2.39.2



[Embedded World 2024, SECO 
SpA]




Re: [PATCH] cmd: bootm: add ELF file support

2024-03-19 Thread Sean Anderson
Hi Maxim,

On 3/19/24 12:10, Maxim Moskalets wrote:
> [You don't often get email from maximmo...@gmail.com. Learn why this is 
> important at 
> https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2faka.ms%2fLearnAboutSenderIdentification=d3728a4f-0e7b-4ded-94bc-5bd133b6deef=d807158c60b7d2502abde8a2fc01f40662980862-7a67d937c0016d0d3292f79af55f0ce3d78f480b
>  ]
>
> Some operating systems (e.g. seL4) and embedded applications are ELF
> images. It is convenient to use FIT-images to implement trusted boot.
> Added "elf" image type for booting using bootm command.

Why not use objcopy to create a binary?

--Sean

> Signed-off-by: Maxim Moskalets 
> ---
>  boot/bootm_os.c  | 21 +
>  boot/image-fit.c |  3 ++-
>  boot/image.c |  3 +++
>  include/image.h  |  1 +
>  4 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/boot/bootm_os.c b/boot/bootm_os.c
> index ccde72d22c..71bfb34926 100644
> --- a/boot/bootm_os.c
> +++ b/boot/bootm_os.c
> @@ -395,6 +395,24 @@ static int do_bootm_qnxelf(int flag, struct bootm_info 
> *bmi)
>  }
>  #endif
>
> +#if defined(CONFIG_CMD_ELF)
> +static int do_bootm_elf(int flag, struct bootm_info *bmi)
> +{
> +   struct bootm_headers *images = bmi->images;
> +   char *local_args[2] = {NULL};
> +   char str[19] = ""; /* "0x" + 16 digits + "\0" */
> +
> +   sprintf(str, "0x%lx", images->ep); /* write entry-point into string */
> +   str[18] = '\0';
> +   local_args[0] = bmi->argv[0];
> +   local_args[1] = str;/* and provide it via the arguments */
> +
> +   do_bootelf(NULL, 0, 2, local_args);
> +
> +   return 1;
> +}
> +#endif
> +
>  #ifdef CONFIG_INTEGRITY
>  static int do_bootm_integrity(int flag, struct bootm_info *bmi)
>  {
> @@ -536,6 +554,9 @@ static boot_os_fn *boot_os[] = {
>  #ifdef CONFIG_BOOTM_EFI
> [IH_OS_EFI] = do_bootm_efi,
>  #endif
> +#if defined(CONFIG_CMD_ELF)
> +   [IH_OS_ELF] = do_bootm_elf,
> +#endif
>  };
>
>  /* Allow for arch specific config before we boot */
> diff --git a/boot/image-fit.c b/boot/image-fit.c
> index 89e377563c..0419bef6d2 100644
> --- a/boot/image-fit.c
> +++ b/boot/image-fit.c
> @@ -2180,7 +2180,8 @@ int fit_image_load(struct bootm_headers *images, ulong 
> addr,
> fit_image_check_os(fit, noffset, IH_OS_TEE) ||
> fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
> fit_image_check_os(fit, noffset, IH_OS_EFI) ||
> -   fit_image_check_os(fit, noffset, IH_OS_VXWORKS);
> +   fit_image_check_os(fit, noffset, IH_OS_VXWORKS) ||
> +   fit_image_check_os(fit, noffset, IH_OS_ELF);
>
> /*
>  * If either of the checks fail, we should report an error, but
> diff --git a/boot/image.c b/boot/image.c
> index 073931cd7a..5b88d6808c 100644
> --- a/boot/image.c
> +++ b/boot/image.c
> @@ -134,6 +134,9 @@ static const table_entry_t uimage_os[] = {
>  #endif
> {   IH_OS_OPENSBI,  "opensbi",  "RISC-V OpenSBI",   },
> {   IH_OS_EFI,  "efi",  "EFI Firmware" },
> +#ifdef CONFIG_CMD_ELF
> +   {   IH_OS_ELF,  "elf",  "ELF Image" },
> +#endif
>
> {   -1, "", "", },
>  };
> diff --git a/include/image.h b/include/image.h
> index 21de70f0c9..9a40bca22c 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -100,6 +100,7 @@ enum {
> IH_OS_TEE,  /* Trusted Execution Environment */
> IH_OS_OPENSBI,  /* RISC-V OpenSBI */
> IH_OS_EFI,  /* EFI Firmware (e.g. GRUB2) */
> +   IH_OS_ELF,  /* ELF Image (e.g. seL4) */
>
> IH_OS_COUNT,
>  };
> --
> 2.39.2
>


[Embedded World 2024, SECO 
SpA]


[PATCH] cmd: bootm: add ELF file support

2024-03-19 Thread Maxim Moskalets
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.

Signed-off-by: Maxim Moskalets 
---
 boot/bootm_os.c  | 21 +
 boot/image-fit.c |  3 ++-
 boot/image.c |  3 +++
 include/image.h  |  1 +
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index ccde72d22c..71bfb34926 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -395,6 +395,24 @@ static int do_bootm_qnxelf(int flag, struct bootm_info 
*bmi)
 }
 #endif
 
+#if defined(CONFIG_CMD_ELF)
+static int do_bootm_elf(int flag, struct bootm_info *bmi)
+{
+   struct bootm_headers *images = bmi->images;
+   char *local_args[2] = {NULL};
+   char str[19] = ""; /* "0x" + 16 digits + "\0" */
+
+   sprintf(str, "0x%lx", images->ep); /* write entry-point into string */
+   str[18] = '\0';
+   local_args[0] = bmi->argv[0];
+   local_args[1] = str;/* and provide it via the arguments */
+
+   do_bootelf(NULL, 0, 2, local_args);
+
+   return 1;
+}
+#endif
+
 #ifdef CONFIG_INTEGRITY
 static int do_bootm_integrity(int flag, struct bootm_info *bmi)
 {
@@ -536,6 +554,9 @@ static boot_os_fn *boot_os[] = {
 #ifdef CONFIG_BOOTM_EFI
[IH_OS_EFI] = do_bootm_efi,
 #endif
+#if defined(CONFIG_CMD_ELF)
+   [IH_OS_ELF] = do_bootm_elf,
+#endif
 };
 
 /* Allow for arch specific config before we boot */
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 89e377563c..0419bef6d2 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -2180,7 +2180,8 @@ int fit_image_load(struct bootm_headers *images, ulong 
addr,
fit_image_check_os(fit, noffset, IH_OS_TEE) ||
fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
fit_image_check_os(fit, noffset, IH_OS_EFI) ||
-   fit_image_check_os(fit, noffset, IH_OS_VXWORKS);
+   fit_image_check_os(fit, noffset, IH_OS_VXWORKS) ||
+   fit_image_check_os(fit, noffset, IH_OS_ELF);
 
/*
 * If either of the checks fail, we should report an error, but
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a..5b88d6808c 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -134,6 +134,9 @@ static const table_entry_t uimage_os[] = {
 #endif
{   IH_OS_OPENSBI,  "opensbi",  "RISC-V OpenSBI",   },
{   IH_OS_EFI,  "efi",  "EFI Firmware" },
+#ifdef CONFIG_CMD_ELF
+   {   IH_OS_ELF,  "elf",  "ELF Image" },
+#endif
 
{   -1, "", "", },
 };
diff --git a/include/image.h b/include/image.h
index 21de70f0c9..9a40bca22c 100644
--- a/include/image.h
+++ b/include/image.h
@@ -100,6 +100,7 @@ enum {
IH_OS_TEE,  /* Trusted Execution Environment */
IH_OS_OPENSBI,  /* RISC-V OpenSBI */
IH_OS_EFI,  /* EFI Firmware (e.g. GRUB2) */
+   IH_OS_ELF,  /* ELF Image (e.g. seL4) */
 
IH_OS_COUNT,
 };
-- 
2.39.2



Re: [PATCH] rockchip: spl: Cache boot source id for later use

2024-03-19 Thread Dragan Simic

On 2024-03-19 16:59, Jonas Karlman wrote:

On 2024-03-19 10:44, Dragan Simic wrote:

On 2024-03-15 18:34, Jonas Karlman wrote:

diff --git a/arch/arm/mach-rockchip/spl.c
b/arch/arm/mach-rockchip/spl.c
index 1586a093fc37..27e996b504e7 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -32,9 +32,17 @@ __weak const char * const
boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

 const char *board_spl_was_booted_from(void)
 {
-   u32  bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+   static u32 bootdevice_brom_id;
const char *bootdevice_ofpath = NULL;

+   if (!bootdevice_brom_id)
+   bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+   if (!bootdevice_brom_id) {
+   debug("%s: unknown brom_bootdevice_id %x\n",
+ __func__, bootdevice_brom_id);
+   return NULL;
+   }
+


Maybe it would be better to execute readl(BROM_BOOTSOURCE_ID_ADDR)
only once, i.e. to have something like this instead:

 +  static u32 bootdevice_brom_id = -1;

 +  if (bootdevice_brom_id == -1) {
 +  bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
 +  if (!bootdevice_brom_id)
 +  debug("%s: unknown brom_bootdevice_id %x\n",
 +__func__, bootdevice_brom_id);
 +  }
 +
 +  if (!bootdevice_brom_id)/* fail on subsequent tries */
 +  return NULL;
 +

The logic behind such an approach would be to try only once and fail
on subsequent (re)tries.  That way, it would also serve as some kind 
of

a runtime canary test, because the first try should succeed, which may
prove useful in the field.


If we initialize the static variable to a value it will be stored in 
the

.data section and takes up binary size. With a static variable like in
this patch this is instead stored in .bss section and gets initialized
to 0 by runtime. 0 is also not a valid boot source id value and the
reset value for the reg.


Is it mandatory that this static variable ends up in the .bss section?

I do not see any point in making the code more complex than it has to 
be.

The reg will contain a known boot source id, 1 - 10, set by BROM or
something has gone wrong and the value is not usable any way.


As I already described, making the code more complex would intentionally
introduce a failure point, which would be triggered in case obtaining
valid value from readl() fails the first time.  Something like that is
usually known as a canary, which I'm sure you already know about.


Re: [PATCH] rockchip: spl: Cache boot source id for later use

2024-03-19 Thread Jonas Karlman
Hi Dragan,

On 2024-03-19 10:44, Dragan Simic wrote:
> Hello Jonas,
> 
> Please see a few comments below.
> 
> On 2024-03-15 18:34, Jonas Karlman wrote:
>> Rockchip BROM write a boot source id at CFG_IRAM_BASE + 0x10, the id
>> indicate from what storage media TPL/SPL was loaded from.
> 
> s/write/writes/
> s/indicate/indicates/
> 
> There are also a few more similar small grammar issues in the rest
> of the patch descroption below.

Thanks, will try to incorporate the grammatical fixes in a v2.

> 
>> SPL use this value to determine what device "same-as-spl" represent 
>> when
>> determining from where FIT should be loaded. This works as long as the
>> boot_devices array contain a matching id <-> node path entry.
> 
> s/use/uses/
> etc.
> 
>> However, SPL typically load a small part of TF-A into SRAM and on 
>> RK3399
>> this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.
>>
>> Here boot source id is 3 before FIT images is loaded, and 0 after:
>>
>>   U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +)
>>   board_spl_was_booted_from: brom_bootdevice_id 3 maps to
>> '/spi@ff1d/flash@0'
>>   Trying to boot from SPI
>>   ## Checking hash(es) for config config-1 ... OK
>>   ## Checking hash(es) for Image atf-1 ... sha256+ OK
>>   ## Checking hash(es) for Image u-boot ... sha256+ OK
>>   ## Checking hash(es) for Image fdt-1 ... sha256+ OK
>>   ## Checking hash(es) for Image atf-2 ... sha256+ OK
>>   ## Checking hash(es) for Image atf-3 ... sha256+ OK
>>   board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
>>   spl_decode_boot_device: could not find udevice for /mmc@fe33
>>   spl_decode_boot_device: could not find udevice for /mmc@fe32
>>   spl_perform_fixups: could not map boot_device to ofpath: -19
>>
>> Use a static bootdevice_brom_id to cache the boot source id after an
>> initial read from SRAM to fix this, this allow spl_perform_fixups() to
>> resolve correct boot source path for "same-as-spl" after SPL have 
>> loaded
>> TF-A related FIT images into memory.
>>
>> With this the spl-boot-device prop can correctly be resolved to the
>> SPI flash node in the control FDT:
>>
>>   => fdt addr ${fdtcontroladdr}
>>   Working FDT set to f1ee6710
>>   => fdt list /chosen
>>   chosen {
>>   u-boot,spl-boot-device = "/spi@ff1d/flash@0";
>>   stdout-path = "serial2:150n8";
>>   u-boot,spl-boot-order = "same-as-spl", "/mmc@fe33", 
>> "/mmc@fe32";
>>   };
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>>  arch/arm/mach-rockchip/spl.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-rockchip/spl.c 
>> b/arch/arm/mach-rockchip/spl.c
>> index 1586a093fc37..27e996b504e7 100644
>> --- a/arch/arm/mach-rockchip/spl.c
>> +++ b/arch/arm/mach-rockchip/spl.c
>> @@ -32,9 +32,17 @@ __weak const char * const
>> boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
>>
>>  const char *board_spl_was_booted_from(void)
>>  {
>> -u32  bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
>> +static u32 bootdevice_brom_id;
>>  const char *bootdevice_ofpath = NULL;
>>
>> +if (!bootdevice_brom_id)
>> +bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
>> +if (!bootdevice_brom_id) {
>> +debug("%s: unknown brom_bootdevice_id %x\n",
>> +  __func__, bootdevice_brom_id);
>> +return NULL;
>> +}
>> +
> 
> Maybe it would be better to execute readl(BROM_BOOTSOURCE_ID_ADDR)
> only once, i.e. to have something like this instead:
> 
>  +static u32 bootdevice_brom_id = -1;
> 
>  +if (bootdevice_brom_id == -1) {
>  +bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
>  +if (!bootdevice_brom_id)
>  +debug("%s: unknown brom_bootdevice_id %x\n",
>  +  __func__, bootdevice_brom_id);
>  +}
>  +
>  +if (!bootdevice_brom_id)/* fail on subsequent tries */
>  +return NULL;
>  +
> 
> The logic behind such an approach would be to try only once and fail
> on subsequent (re)tries.  That way, it would also serve as some kind of
> a runtime canary test, because the first try should succeed, which may
> prove useful in the field.

If we initialize the static variable to a value it will be stored in the
.data section and takes up binary size. With a static variable like in
this patch this is instead stored in .bss section and gets initialized
to 0 by runtime. 0 is also not a valid boot source id value and the
reset value for the reg.

I do not see any point in making the code more complex than it has to be.
The reg will contain a known boot source id, 1 - 10, set by BROM or
something has gone wrong and the value is not usable any way.

Regards,
Jonas

> 
>>  if (bootdevice_brom_id < ARRAY_SIZE(boot_devices))
>>  bootdevice_ofpath = boot_devices[bootdevice_brom_id];



Re: [PATCH] arm: dts: k3-am625-verdin-r5: Change CPU frequency to 800MHz

2024-03-19 Thread Francesco Dolcini
Hello Tom,

On Tue, Mar 19, 2024 at 11:04:27AM -0300, Joao Paulo Goncalves wrote:
> From: Joao Paulo Goncalves 
> 
> The lowest speed grade of Toradex AM62 SoMs is K speed, resulting in a
> max value of 800MHz for the CPU operating frequency. A solution with
> runtime selection of the CPU frequency is already planned to avoid these
> kinds of problems in the future.
> 
> Fixes: 8fb8a6d49977 ("arm: dts: k3-am625-verdin-r5:Change CPU
> frequency to 1000MHz")
> Signed-off-by: Joao Paulo Goncalves 

We have a patch ready to make the frequency adjusted at runtime that
should be on the mailing list in a day or so, as suggested by Vignesh,
targetting uboot-next, this one fix should go into master however.

Thanks,
Francesco




[PATCH] board: amlogic: fix buffler overflow in serial & usid read

2024-03-19 Thread Neil Armstrong
While meson_sm_read_efuse() doesn't overflow, the string is not
zero terminated and env_set() will buffer overflow and add random
characters to environment.

Signed-off-by: Neil Armstrong 
---
 board/amlogic/jethub-j80/jethub-j80.c | 6 --
 board/amlogic/p200/p200.c | 3 ++-
 board/amlogic/p201/p201.c | 3 ++-
 board/amlogic/p212/p212.c | 3 ++-
 board/amlogic/q200/q200.c | 3 ++-
 5 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/board/amlogic/jethub-j80/jethub-j80.c 
b/board/amlogic/jethub-j80/jethub-j80.c
index 185880de13..d10492cc46 100644
--- a/board/amlogic/jethub-j80/jethub-j80.c
+++ b/board/amlogic/jethub-j80/jethub-j80.c
@@ -28,8 +28,8 @@
 int misc_init_r(void)
 {
u8 mac_addr[EFUSE_MAC_SIZE];
-   char serial[EFUSE_SN_SIZE];
-   char usid[EFUSE_USID_SIZE];
+   char serial[EFUSE_SN_SIZE + 1];
+   char usid[EFUSE_USID_SIZE + 1];
ssize_t len;
unsigned int adcval;
int ret;
@@ -46,6 +46,7 @@ int misc_init_r(void)
if (!env_get("serial")) {
len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,
  EFUSE_SN_SIZE);
+   serial[len] = '\0';
if (len == EFUSE_SN_SIZE)
env_set("serial", serial);
}
@@ -53,6 +54,7 @@ int misc_init_r(void)
if (!env_get("usid")) {
len = meson_sm_read_efuse(EFUSE_USID_OFFSET, usid,
  EFUSE_USID_SIZE);
+   usid[len] = '\0';
if (len == EFUSE_USID_SIZE)
env_set("usid", usid);
}
diff --git a/board/amlogic/p200/p200.c b/board/amlogic/p200/p200.c
index 7c432f9d28..37a54e715c 100644
--- a/board/amlogic/p200/p200.c
+++ b/board/amlogic/p200/p200.c
@@ -22,7 +22,7 @@
 int misc_init_r(void)
 {
u8 mac_addr[EFUSE_MAC_SIZE];
-   char serial[EFUSE_SN_SIZE];
+   char serial[EFUSE_SN_SIZE + 1];
ssize_t len;
 
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
@@ -35,6 +35,7 @@ int misc_init_r(void)
if (!env_get("serial#")) {
len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,
EFUSE_SN_SIZE);
+   serial[len] = '\0';
if (len == EFUSE_SN_SIZE)
env_set("serial#", serial);
}
diff --git a/board/amlogic/p201/p201.c b/board/amlogic/p201/p201.c
index 7c432f9d28..37a54e715c 100644
--- a/board/amlogic/p201/p201.c
+++ b/board/amlogic/p201/p201.c
@@ -22,7 +22,7 @@
 int misc_init_r(void)
 {
u8 mac_addr[EFUSE_MAC_SIZE];
-   char serial[EFUSE_SN_SIZE];
+   char serial[EFUSE_SN_SIZE + 1];
ssize_t len;
 
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
@@ -35,6 +35,7 @@ int misc_init_r(void)
if (!env_get("serial#")) {
len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,
EFUSE_SN_SIZE);
+   serial[len] = '\0';
if (len == EFUSE_SN_SIZE)
env_set("serial#", serial);
}
diff --git a/board/amlogic/p212/p212.c b/board/amlogic/p212/p212.c
index fcef90bce5..90ac9f885d 100644
--- a/board/amlogic/p212/p212.c
+++ b/board/amlogic/p212/p212.c
@@ -23,7 +23,7 @@
 int misc_init_r(void)
 {
u8 mac_addr[EFUSE_MAC_SIZE];
-   char serial[EFUSE_SN_SIZE];
+   char serial[EFUSE_SN_SIZE + 1];
ssize_t len;
 
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
@@ -38,6 +38,7 @@ int misc_init_r(void)
if (!env_get("serial#")) {
len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,
EFUSE_SN_SIZE);
+   serial[len] = '\0';
if (len == EFUSE_SN_SIZE)
env_set("serial#", serial);
}
diff --git a/board/amlogic/q200/q200.c b/board/amlogic/q200/q200.c
index 3aa6d8f200..1c47f4645f 100644
--- a/board/amlogic/q200/q200.c
+++ b/board/amlogic/q200/q200.c
@@ -23,7 +23,7 @@
 int misc_init_r(void)
 {
u8 mac_addr[EFUSE_MAC_SIZE];
-   char serial[EFUSE_SN_SIZE];
+   char serial[EFUSE_SN_SIZE + 1];
ssize_t len;
 
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
@@ -38,6 +38,7 @@ int misc_init_r(void)
if (!env_get("serial#")) {
len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,
  EFUSE_SN_SIZE);
+   serial[len] = '\0';
if (len == EFUSE_SN_SIZE)
env_set("serial#", serial);
}

---
base-commit: b145877c22b391a4872c875145a8f86f6ffebaba
change-id: 20240319-u-boot-fix-p200-serial-a017f57caf88

Best regards,
-- 
Neil Armstrong 



Re: [PATCH v3 10/14] mach-snapdragon: fixup USB nodes

2024-03-19 Thread Caleb Connolly
Hi Sumit,

On 19/03/2024 13:49, Sumit Garg wrote:
> Hi Caleb,
> 
> On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  
> wrote:
>>
>> We don't support USB super-speed in U-Boot yet, we lack the SS PHY
>> drivers, however from my testing even with a PHY driver there seem to be
>> other issues when talking to super-speed peripherals.
>>
>> In pursuit of maintaining upstream DT compatibility,
> 
> I can understand the reasoning behind this but since we enable these
> fixups for every Qcom platform it may turn out to be counter
> productive. There can be embedded use-cases where bootup times have
> stringent requirements. Also, depending upon CPU speed/freq the add-on
> times due to these can be significant.

I have measured this on a few different boards:

On DB410c, the slowest board we currently support
* of_live_build took 7228us
* Fixing up USB nodes took 131us
* Fixing up power domains took 88us

On RB1 (the slowest new platform with a QCM2290 SoC)
* of_live_build took 2078us
* Fixing up USB nodes took 39us
* Fixing up power domains took 27us

The time taken initially to build the livetree is likely made back as it
is much much faster to query than the flat tree (as you can see, walking
every single node takes <100us on db410c). I took some rough
measurements of the boot-to-console time on sdm845 (see the "enable
livetree" patch) and basically concluded that the delta between live and
flat trees is within the margin of error.

If a specific board for whatever reason wants to avoid using OF_LIVE
then I'm fine with that, db410c isn't using it for example.
> 
> I would suggest we rather solve these USB issues either via a common
> Qcom *-u-boot.dtsi file which can be included for every board.
> 
> -Sumit
> 
>> and simplifying
>> porting for new devices, let's implement the DT fixups necessary to
>> configure USB in high-speed only mode at runtime. The pattern is
>> identical for all Qualcomm boards that use the Synaptics DWC3
>> controller:
>>
>> * Add an additional property on the Qualcomm wrapper node
>> * Remove the super-speed phy phandle and phy-name entries.
>>
>> Signed-off-by: Caleb Connolly 
>> ---
>>  arch/arm/mach-snapdragon/Makefile|   1 +
>>  arch/arm/mach-snapdragon/board.c |   3 +
>>  arch/arm/mach-snapdragon/of_fixup.c  | 115 
>> +++
>>  arch/arm/mach-snapdragon/qcom-priv.h |  19 ++
>>  4 files changed, 138 insertions(+)
>>
>> diff --git a/arch/arm/mach-snapdragon/Makefile 
>> b/arch/arm/mach-snapdragon/Makefile
>> index 857171e593da..7a4495c8108f 100644
>> --- a/arch/arm/mach-snapdragon/Makefile
>> +++ b/arch/arm/mach-snapdragon/Makefile
>> @@ -2,4 +2,5 @@
>>  #
>>  # (C) Copyright 2015 Mateusz Kulikowski 
>>
>>  obj-y += board.o
>> +obj-$(CONFIG_OF_LIVE) += of_fixup.o
>> diff --git a/arch/arm/mach-snapdragon/board.c 
>> b/arch/arm/mach-snapdragon/board.c
>> index 6f762fc948bf..65e4c61e866a 100644
>> --- a/arch/arm/mach-snapdragon/board.c
>> +++ b/arch/arm/mach-snapdragon/board.c
>> @@ -27,8 +27,10 @@
>>  #include 
>>  #include 
>>  #include 
>>
>> +#include "qcom-priv.h"
>> +
>>  DECLARE_GLOBAL_DATA_PTR;
>>
>>  static struct mm_region rbx_mem_map[CONFIG_NR_DRAM_BANKS + 2] = { { 0 } };
>>
>> @@ -159,8 +161,9 @@ void __weak qcom_board_init(void)
>>
>>  int board_init(void)
>>  {
>> show_psci_version();
>> +   qcom_of_fixup_nodes();
>> qcom_board_init();
>> return 0;
>>  }
>>
>> diff --git a/arch/arm/mach-snapdragon/of_fixup.c 
>> b/arch/arm/mach-snapdragon/of_fixup.c
>> new file mode 100644
>> index ..6810c8617cc0
>> --- /dev/null
>> +++ b/arch/arm/mach-snapdragon/of_fixup.c
>> @@ -0,0 +1,115 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * OF_LIVE devicetree fixup.
>> + *
>> + * This file implements runtime fixups for Qualcomm DT to improve
>> + * compatibility with U-Boot. This includes adjusting the USB nodes
>> + * to only use USB high-speed, as well as remapping volume buttons
>> + * to behave as up/down for navigating U-Boot.
>> + *
>> + * We use OF_LIVE for this rather than early FDT fixup for a couple
>> + * of reasons: it has a much nicer API, is most likely more efficient,
>> + * and our changes are only applied to U-Boot. This allows us to use a
>> + * DT designed for Linux, run U-Boot with a modified version, and then
>> + * boot Linux with the original FDT.
>> + *
>> + * Copyright (c) 2024 Linaro Ltd.
>> + *   Author: Caleb Connolly 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
>> + * USB controllers. Rather than requiring source level DT changes, we fix up
>> + * DT here. This improves compatibility with upstream DT and simplifies the
>> + * porting process for new devices.
>> + */
>> +static int fixup_qcom_dwc3(struct device_node *glue_np)
>> +{
>> +   struct device_node *dwc3;
>> +   int ret, len, hsphy_idx = 1;
>> +   const __be32 *phandles;
>> +   

[PATCH 3/4] dts: meson-g12a: Switch to using upstream DT

2024-03-19 Thread Neil Armstrong
Enable OF_UPSTREAM to use upstream DT and add amlogic/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.

Cc: Sumit Garg 
Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-meson/Kconfig   | 1 +
 configs/bananapi-cm4-cm4io_defconfig  | 2 +-
 configs/bananapi-m2-pro_defconfig | 2 +-
 configs/bananapi-m2s_defconfig| 2 +-
 configs/bananapi-m5_defconfig | 2 +-
 configs/beelink-gsking-x_defconfig| 2 +-
 configs/beelink-gtking_defconfig  | 2 +-
 configs/beelink-gtkingpro_defconfig   | 2 +-
 configs/khadas-vim3_android_ab_defconfig  | 2 +-
 configs/khadas-vim3_android_defconfig | 2 +-
 configs/khadas-vim3_defconfig | 2 +-
 configs/khadas-vim3l_android_ab_defconfig | 2 +-
 configs/khadas-vim3l_android_defconfig| 2 +-
 configs/khadas-vim3l_defconfig| 2 +-
 configs/odroid-c4_defconfig   | 2 +-
 configs/odroid-go-ultra_defconfig | 2 +-
 configs/odroid-hc4_defconfig  | 2 +-
 configs/odroid-n2_defconfig   | 2 +-
 configs/odroid-n2l_defconfig  | 2 +-
 configs/radxa-zero2_defconfig | 2 +-
 configs/radxa-zero_defconfig  | 2 +-
 configs/sei510_defconfig  | 2 +-
 configs/sei610_defconfig  | 2 +-
 configs/u200_defconfig| 2 +-
 24 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index 1d837ae0f3..7570f48e25 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -53,6 +53,7 @@ config MESON_AXG
 config MESON_G12A
bool "G12A"
select MESON64_COMMON
+   imply OF_UPSTREAM
help
  Select this if your SoC is an S905X/D2
 
diff --git a/configs/bananapi-cm4-cm4io_defconfig 
b/configs/bananapi-cm4-cm4io_defconfig
index 116147fc9a..cb78dabc13 100644
--- a/configs/bananapi-cm4-cm4io_defconfig
+++ b/configs/bananapi-cm4-cm4io_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-g12b-bananapi-cm4-cm4io"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-g12b-bananapi-cm4-cm4io"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_G12A=y
diff --git a/configs/bananapi-m2-pro_defconfig 
b/configs/bananapi-m2-pro_defconfig
index 755bccb4a7..196bc4077d 100644
--- a/configs/bananapi-m2-pro_defconfig
+++ b/configs/bananapi-m2-pro_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-sm1-bananapi-m2-pro"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-sm1-bananapi-m2-pro"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_G12A=y
diff --git a/configs/bananapi-m2s_defconfig b/configs/bananapi-m2s_defconfig
index af8daced62..7b137d5e1c 100644
--- a/configs/bananapi-m2s_defconfig
+++ b/configs/bananapi-m2s_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-g12b-a311d-bananapi-m2s"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-g12b-a311d-bananapi-m2s"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_G12A=y
diff --git a/configs/bananapi-m5_defconfig b/configs/bananapi-m5_defconfig
index 6de5d5fe7b..99ed7c9669 100644
--- a/configs/bananapi-m5_defconfig
+++ b/configs/bananapi-m5_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-sm1-bananapi-m5"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-sm1-bananapi-m5"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_G12A=y
diff --git a/configs/beelink-gsking-x_defconfig 
b/configs/beelink-gsking-x_defconfig
index 99e36e970a..c1e60ede4a 100644
--- a/configs/beelink-gsking-x_defconfig
+++ b/configs/beelink-gsking-x_defconfig
@@ -7,7 +7,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-g12b-gsking-x"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-g12b-gsking-x"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_G12A=y
diff --git a/configs/beelink-gtking_defconfig b/configs/beelink-gtking_defconfig
index 5c21d8eeab..0b644f0e34 100644
--- a/configs/beelink-gtking_defconfig
+++ b/configs/beelink-gtking_defconfig
@@ -7,7 +7,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-g12b-gtking"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-g12b-gtking"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_G12A=y

[PATCH 1/4] dts: meson: Switch GXL, GXM & AXG to using upstream DT

2024-03-19 Thread Neil Armstrong
Enable OF_UPSTREAM to use upstream DT and add amlogic/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.

Cc: Sumit Garg 
Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-meson/Kconfig| 3 +++
 configs/beelink-gt1-ultimate_defconfig | 2 +-
 configs/jethub_j100_defconfig  | 2 +-
 configs/jethub_j80_defconfig   | 2 +-
 configs/khadas-vim2_defconfig  | 2 +-
 configs/khadas-vim_defconfig   | 2 +-
 configs/libretech-ac_defconfig | 2 +-
 configs/libretech-cc_defconfig | 2 +-
 configs/libretech-cc_v2_defconfig  | 2 +-
 configs/libretech-s905d-pc_defconfig   | 2 +-
 configs/libretech-s912-pc_defconfig| 2 +-
 configs/p212_defconfig | 2 +-
 configs/s400_defconfig | 2 +-
 configs/wetek-core2_defconfig  | 2 +-
 14 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index 95e7b019ce..1d837ae0f3 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -32,18 +32,21 @@ config MESON_GXBB
 config MESON_GXL
bool "GXL"
select MESON_GX
+   imply OF_UPSTREAM
help
  Select this if your SoC is an S905X/D or S805X
 
 config MESON_GXM
bool "GXM"
select MESON_GX
+   imply OF_UPSTREAM
help
  Select this if your SoC is an S912
 
 config MESON_AXG
bool "AXG"
select MESON64_COMMON
+   imply OF_UPSTREAM
help
  Select this if your SoC is an A113X/D
 
diff --git a/configs/beelink-gt1-ultimate_defconfig 
b/configs/beelink-gt1-ultimate_defconfig
index 00fdad8544..0e30e13c82 100644
--- a/configs/beelink-gt1-ultimate_defconfig
+++ b/configs/beelink-gt1-ultimate_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxm-gt1-ultimate"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxm-gt1-ultimate"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_GXM=y
diff --git a/configs/jethub_j100_defconfig b/configs/jethub_j100_defconfig
index 863245430a..9de6b4b44d 100644
--- a/configs/jethub_j100_defconfig
+++ b/configs/jethub_j100_defconfig
@@ -8,7 +8,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-axg-jethome-jethub-j100"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-axg-jethome-jethub-j100"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_AXG=y
diff --git a/configs/jethub_j80_defconfig b/configs/jethub_j80_defconfig
index ca0808f712..85306872f9 100644
--- a/configs/jethub_j80_defconfig
+++ b/configs/jethub_j80_defconfig
@@ -8,7 +8,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxl-s905w-jethome-jethub-j80"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxl-s905w-jethome-jethub-j80"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_GXL=y
diff --git a/configs/khadas-vim2_defconfig b/configs/khadas-vim2_defconfig
index 59ef33723e..50f8b30650 100644
--- a/configs/khadas-vim2_defconfig
+++ b/configs/khadas-vim2_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxm-khadas-vim2"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxm-khadas-vim2"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_GXM=y
diff --git a/configs/khadas-vim_defconfig b/configs/khadas-vim_defconfig
index 5ed7c1a408..ac00e8975e 100644
--- a/configs/khadas-vim_defconfig
+++ b/configs/khadas-vim_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxl-s905x-khadas-vim"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxl-s905x-khadas-vim"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_GXL=y
diff --git a/configs/libretech-ac_defconfig b/configs/libretech-ac_defconfig
index f0ab19580c..6ad0457002 100644
--- a/configs/libretech-ac_defconfig
+++ b/configs/libretech-ac_defconfig
@@ -9,7 +9,7 @@ CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x
 CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxl-s805x-libretech-ac"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxl-s805x-libretech-ac"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_MESON_GXL=y
diff --git a/configs/libretech-cc_defconfig b/configs/libretech-cc_defconfig
index bb1a37a0cd..beb919ca6e 100644
--- a/configs/libretech-cc_defconfig
+++ b/configs/libretech-cc_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 

[PATCH 0/4] arm: meson: Switch to using upstream DT for GXL, GXM, AXG, G12A, G12B & SM1 SoCs

2024-03-19 Thread Neil Armstrong
pi-m2s_defconfig |2 +-
 configs/bananapi-m5_defconfig  |2 +-
 configs/beelink-gsking-x_defconfig |2 +-
 configs/beelink-gt1-ultimate_defconfig |2 +-
 configs/beelink-gtking_defconfig   |2 +-
 configs/beelink-gtkingpro_defconfig|2 +-
 configs/jethub_j100_defconfig  |2 +-
 configs/jethub_j80_defconfig   |2 +-
 configs/khadas-vim2_defconfig  |2 +-
 configs/khadas-vim3_android_ab_defconfig   |2 +-
 configs/khadas-vim3_android_defconfig  |2 +-
 configs/khadas-vim3_defconfig  |2 +-
 configs/khadas-vim3l_android_ab_defconfig  |2 +-
 configs/khadas-vim3l_android_defconfig |2 +-
 configs/khadas-vim3l_defconfig |2 +-
 configs/khadas-vim_defconfig   |2 +-
 configs/libretech-ac_defconfig |2 +-
 configs/libretech-cc_defconfig |2 +-
 configs/libretech-cc_v2_defconfig  |2 +-
 configs/libretech-s905d-pc_defconfig   |2 +-
 configs/libretech-s912-pc_defconfig|2 +-
 configs/odroid-c4_defconfig|2 +-
 configs/odroid-go-ultra_defconfig  |2 +-
 configs/odroid-hc4_defconfig   |2 +-
 configs/odroid-n2_defconfig|2 +-
 configs/odroid-n2l_defconfig   |2 +-
 configs/p212_defconfig |2 +-
 configs/radxa-zero2_defconfig  |2 +-
 configs/radxa-zero_defconfig   |2 +-
 configs/s400_defconfig |2 +-
 configs/sei510_defconfig   |2 +-
 configs/sei610_defconfig   |2 +-
 configs/u200_defconfig |2 +-
 configs/wetek-core2_defconfig  |2 +-
 include/dt-bindings/gpio/meson-axg-gpio.h  |  116 -
 include/dt-bindings/gpio/meson-g12a-gpio.h |  114 -
 include/dt-bindings/gpio/meson-gxbb-gpio.h |  148 --
 include/dt-bindings/gpio/meson-gxl-gpio.h  |  125 -
 include/dt-bindings/power/meson-axg-power.h|   14 -
 include/dt-bindings/power/meson-g12a-power.h   |   13 -
 include/dt-bindings/power/meson-gxbb-power.h   |   13 -
 include/dt-bindings/power/meson-sm1-power.h|   18 -
 .../reset/amlogic,meson-axg-audio-arb.h|   19 -
 .../dt-bindings/reset/amlogic,meson-axg-reset.h|  123 -
 .../reset/amlogic,meson-g12a-audio-reset.h |   53 -
 .../dt-bindings/reset/amlogic,meson-g12a-reset.h   |  137 --
 .../dt-bindings/reset/amlogic,meson-gxbb-reset.h   |  161 --
 include/dt-bindings/sound/meson-aiu.h  |   18 -
 include/dt-bindings/sound/meson-g12a-toacodec.h|   10 -
 include/dt-bindings/sound/meson-g12a-tohdmitx.h|   13 -
 116 files changed, 42 insertions(+), 21511 deletions(-)
---
base-commit: b145877c22b391a4872c875145a8f86f6ffebaba
change-id: 20240319-u-boot-of-upstream-46454fded5ea

Best regards,
-- 
Neil Armstrong 



Re: [PATCH 2/3] configs: imx93-phyboard-segin: Add USB support.

2024-03-19 Thread Marek Vasut

On 3/19/24 9:39 AM, Wadim Egorov wrote:


Am 18.03.24 um 22:48 schrieb Marek Vasut:

On 3/18/24 6:16 PM, Mathieu Othacehe wrote:

Enable the `usb` command and some USB drivers.

Signed-off-by: Mathieu Othacehe 
---
  configs/imx93-phyboard-segin_defconfig | 8 
  1 file changed, 8 insertions(+)

diff --git a/configs/imx93-phyboard-segin_defconfig 
b/configs/imx93-phyboard-segin_defconfig

index 24f9bd553aa..5acb987b817 100644
--- a/configs/imx93-phyboard-segin_defconfig
+++ b/configs/imx93-phyboard-segin_defconfig
@@ -23,6 +23,7 @@ CONFIG_SPL_STACK=0x20519dd0
  CONFIG_SPL=y
  CONFIG_ENV_OFFSET_REDUND=0x72
  CONFIG_CMD_DEKBLOB=y
+CONFIG_CMD_USB=y
  CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x8800
  CONFIG_SYS_LOAD_ADDR=0x8040
  CONFIG_SYS_MEMTEST_START=0x8000
@@ -132,6 +133,13 @@ CONFIG_SPL_SYSRESET=y
  CONFIG_SYSRESET_WATCHDOG=y
  CONFIG_DM_THERMAL=y
  CONFIG_IMX_TMU=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x1fc9
+CONFIG_USB_GADGET_PRODUCT_NUM=0x0152


Shouldn't this by Phytec or similar USB IDs ?
AFAIK, PHYTEC does not have its own IDs registered yet. So the freescale 
IDs should be fine.


Manufacturer can still be Phytec , can it not ?


Re: [PATCH 1/3] arm: dts: imx93-phyboard-segin: Add USB support.

2024-03-19 Thread Marek Vasut

On 3/19/24 9:26 AM, Primoz Fiser wrote:

Hi Marek,

On 18. 03. 24 22:48, Marek Vasut wrote:

On 3/18/24 6:16 PM, Mathieu Othacehe wrote:

Enable both usbotg1 and usbotg2 ports.


Drop fullstop from $subject end.


Signed-off-by: Mathieu Othacehe 
---
   arch/arm/dts/imx93-phyboard-segin.dts | 13 +
   1 file changed, 13 insertions(+)

diff --git a/arch/arm/dts/imx93-phyboard-segin.dts
b/arch/arm/dts/imx93-phyboard-segin.dts
index 85fb188b057..acf307a3192 100644
--- a/arch/arm/dts/imx93-phyboard-segin.dts
+++ b/arch/arm/dts/imx93-phyboard-segin.dts
@@ -40,6 +40,19 @@
   status = "okay";
   };
   +/* USB  */
+ {
+    disable-over-current;


Why is this needed ?


OC pins are not connected to the SoC thus disable OC to avoid warnings
(c/p from kernel dts).


Please add it to the commit message for posterity, thanks.


[PATCH] arm: dts: k3-am625-verdin-r5: Change CPU frequency to 800MHz

2024-03-19 Thread Joao Paulo Goncalves
From: Joao Paulo Goncalves 

The lowest speed grade of Toradex AM62 SoMs is K speed, resulting in a
max value of 800MHz for the CPU operating frequency. A solution with
runtime selection of the CPU frequency is already planned to avoid these
kinds of problems in the future.

Fixes: 8fb8a6d49977 ("arm: dts: k3-am625-verdin-r5:Change CPU
frequency to 1000MHz")
Signed-off-by: Joao Paulo Goncalves 
---
 arch/arm/dts/k3-am625-verdin-r5.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/k3-am625-verdin-r5.dts 
b/arch/arm/dts/k3-am625-verdin-r5.dts
index 6b03e7405af..2b333e70f5c 100644
--- a/arch/arm/dts/k3-am625-verdin-r5.dts
+++ b/arch/arm/dts/k3-am625-verdin-r5.dts
@@ -23,7 +23,7 @@
 */
assigned-clocks = <_clks 61 0>, <_clks 135 0>, <_clks 
157 20>;
assigned-clock-parents = <_clks 61 2>, <0>, <_clks 157 
22>;
-   assigned-clock-rates = <2>, <10>, <2500>;
+   assigned-clock-rates = <2>, <8>, <2500>;
clocks = <_clks 61 0>;
power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
<_pds 135 TI_SCI_PD_EXCLUSIVE>,
-- 
2.34.1



Re: [PATCH v3] arm: dts: armada-37xx: update devicetrees from linux

2024-03-19 Thread Tom Rini
On Mon, Mar 18, 2024 at 04:44:48PM -0700, Benjamin Schneider wrote:

> Update existing armada-37xx DTS files with those in linux
> and add devicetree for ESPRESSObin Ultra device.
> 
> Signed-off-by: Benjamin Schneider 

Please depend on:
https://patchwork.ozlabs.org/project/uboot/patch/20240318150318.8292-1-marek.vasut+rene...@mailbox.org/
and rebase using OF_UPSTREAM (and a -u-boot.dtsi for now if needed
still).

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 12/14] dts: sdm845-db845c: add u-boot fixups

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> The USB VBUS supply for the type-A port is enabled via a GPIO regulator.
> This is incorrectly modelled in Linux where only the PCIe dependency is
> expressed.

Can we send a fix for the Linux kernel DTS to correctly model it? We
can then later get rid of this modification once that is accepted.

-Sumit

> Add a U-Boot specific dtsi snippet so that this supply will
> get enabled when initialising USB.
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/dts/sdm845-db845c-u-boot.dtsi | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/sdm845-db845c-u-boot.dtsi 
> b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
> new file mode 100644
> index ..3c83e21251c4
> --- /dev/null
> +++ b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
> @@ -0,0 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/* This GPIO must be turned on to enable the 5v VBUS
> + * supply on the USB port.
> + */
> +_2_dwc3 {
> +   vbus-supply = <_3p3v_dual>;
> +};
>
> --
> 2.44.0
>


Re: [PATCH v3 11/14] mach-snapdragon: fixup power-domains

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> We don't support the RPM(h)PD power domains in U-Boot, and we don't need
> to - the necessary resources are on, and we aren't going to enter any
> low power modes.
>
> We could try using a no-op device, but this requires adding a compatible
> for every platform, and just pollutes the driver model. So instead let's
> just remove every "power-domains" property that references the RPM(h)pd
> power controller. This takes <1ms as we're using OF_LIVE.

Similar reasoning here as on patch #10, it would be better if we can
handle it via a no-op device.

-Sumit

>
> Of note, this only applies to drivers which are loading post-relocation.
> Drivers loaded pre-reloc that reference the rpm(h)pd still need
> DM_FLAG_DEFAULT_PD_CTRL_OFF in their flags.
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/mach-snapdragon/of_fixup.c | 32 
>  1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/mach-snapdragon/of_fixup.c 
> b/arch/arm/mach-snapdragon/of_fixup.c
> index 6810c8617cc0..49f1fc1948f3 100644
> --- a/arch/arm/mach-snapdragon/of_fixup.c
> +++ b/arch/arm/mach-snapdragon/of_fixup.c
> @@ -21,8 +21,9 @@
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
>   * USB controllers. Rather than requiring source level DT changes, we fix up
>   * DT here. This improves compatibility with upstream DT and simplifies the
> @@ -108,8 +109,39 @@ static void fixup_usb_nodes(void)
> log_warning("Failed to fixup node %s: %d\n", 
> glue_np->name, ret);
> }
>  }
>
> +/* Remove all references to the rpmhpd device */
> +static void fixup_power_domains(void)
> +{
> +   struct device_node *pd = NULL, *np = NULL;
> +   struct property *prop;
> +   const __be32 *val;
> +
> +   /* All Qualcomm platforms name the rpm(h)pd "power-controller" */
> +   for_each_of_allnodes(pd) {
> +   if (pd->name && !strcmp("power-controller", pd->name))
> +   break;
> +   }
> +
> +   /* Sanity check that this is indeed a power domain controller */
> +   if (!of_find_property(pd, "#power-domain-cells", NULL)) {
> +   log_err("Found power-controller but it doesn't have 
> #power-domain-cells\n");
> +   return;
> +   }
> +
> +   /* Remove all references to the power domain controller */
> +   for_each_of_allnodes(np) {
> +   if (!(prop = of_find_property(np, "power-domains", NULL)))
> +   continue;
> +
> +   val = prop->value;
> +   if (val[0] == cpu_to_fdt32(pd->phandle))
> +   of_remove_property(np, prop);
> +   }
> +}
> +
>  void qcom_of_fixup_nodes(void)
>  {
> fixup_usb_nodes();
> +   fixup_power_domains();
>  }
>
> --
> 2.44.0
>


Re: [PATCH v3 10/14] mach-snapdragon: fixup USB nodes

2024-03-19 Thread Sumit Garg
Hi Caleb,

On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> We don't support USB super-speed in U-Boot yet, we lack the SS PHY
> drivers, however from my testing even with a PHY driver there seem to be
> other issues when talking to super-speed peripherals.
>
> In pursuit of maintaining upstream DT compatibility,

I can understand the reasoning behind this but since we enable these
fixups for every Qcom platform it may turn out to be counter
productive. There can be embedded use-cases where bootup times have
stringent requirements. Also, depending upon CPU speed/freq the add-on
times due to these can be significant.

I would suggest we rather solve these USB issues either via a common
Qcom *-u-boot.dtsi file which can be included for every board.

-Sumit

> and simplifying
> porting for new devices, let's implement the DT fixups necessary to
> configure USB in high-speed only mode at runtime. The pattern is
> identical for all Qualcomm boards that use the Synaptics DWC3
> controller:
>
> * Add an additional property on the Qualcomm wrapper node
> * Remove the super-speed phy phandle and phy-name entries.
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/mach-snapdragon/Makefile|   1 +
>  arch/arm/mach-snapdragon/board.c |   3 +
>  arch/arm/mach-snapdragon/of_fixup.c  | 115 
> +++
>  arch/arm/mach-snapdragon/qcom-priv.h |  19 ++
>  4 files changed, 138 insertions(+)
>
> diff --git a/arch/arm/mach-snapdragon/Makefile 
> b/arch/arm/mach-snapdragon/Makefile
> index 857171e593da..7a4495c8108f 100644
> --- a/arch/arm/mach-snapdragon/Makefile
> +++ b/arch/arm/mach-snapdragon/Makefile
> @@ -2,4 +2,5 @@
>  #
>  # (C) Copyright 2015 Mateusz Kulikowski 
>
>  obj-y += board.o
> +obj-$(CONFIG_OF_LIVE) += of_fixup.o
> diff --git a/arch/arm/mach-snapdragon/board.c 
> b/arch/arm/mach-snapdragon/board.c
> index 6f762fc948bf..65e4c61e866a 100644
> --- a/arch/arm/mach-snapdragon/board.c
> +++ b/arch/arm/mach-snapdragon/board.c
> @@ -27,8 +27,10 @@
>  #include 
>  #include 
>  #include 
>
> +#include "qcom-priv.h"
> +
>  DECLARE_GLOBAL_DATA_PTR;
>
>  static struct mm_region rbx_mem_map[CONFIG_NR_DRAM_BANKS + 2] = { { 0 } };
>
> @@ -159,8 +161,9 @@ void __weak qcom_board_init(void)
>
>  int board_init(void)
>  {
> show_psci_version();
> +   qcom_of_fixup_nodes();
> qcom_board_init();
> return 0;
>  }
>
> diff --git a/arch/arm/mach-snapdragon/of_fixup.c 
> b/arch/arm/mach-snapdragon/of_fixup.c
> new file mode 100644
> index ..6810c8617cc0
> --- /dev/null
> +++ b/arch/arm/mach-snapdragon/of_fixup.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * OF_LIVE devicetree fixup.
> + *
> + * This file implements runtime fixups for Qualcomm DT to improve
> + * compatibility with U-Boot. This includes adjusting the USB nodes
> + * to only use USB high-speed, as well as remapping volume buttons
> + * to behave as up/down for navigating U-Boot.
> + *
> + * We use OF_LIVE for this rather than early FDT fixup for a couple
> + * of reasons: it has a much nicer API, is most likely more efficient,
> + * and our changes are only applied to U-Boot. This allows us to use a
> + * DT designed for Linux, run U-Boot with a modified version, and then
> + * boot Linux with the original FDT.
> + *
> + * Copyright (c) 2024 Linaro Ltd.
> + *   Author: Caleb Connolly 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
> + * USB controllers. Rather than requiring source level DT changes, we fix up
> + * DT here. This improves compatibility with upstream DT and simplifies the
> + * porting process for new devices.
> + */
> +static int fixup_qcom_dwc3(struct device_node *glue_np)
> +{
> +   struct device_node *dwc3;
> +   int ret, len, hsphy_idx = 1;
> +   const __be32 *phandles;
> +   const char *second_phy_name;
> +
> +   debug("Fixing up %s\n", glue_np->name);
> +
> +   /* Tell the glue driver to configure the wrapper for high-speed only 
> operation */
> +   ret = of_write_prop(glue_np, "qcom,select-utmi-as-pipe-clk", 0, NULL);
> +   if (ret) {
> +   log_err("Failed to add property 
> 'qcom,select-utmi-as-pipe-clk': %d\n", ret);
> +   return ret;
> +   }
> +
> +   /* Find the DWC3 node itself */
> +   dwc3 = of_find_compatible_node(glue_np, NULL, "snps,dwc3");
> +   if (!dwc3) {
> +   log_err("Failed to find dwc3 node\n");
> +   return -ENOENT;
> +   }
> +
> +   phandles = of_get_property(dwc3, "phys", );
> +   len /= sizeof(*phandles);
> +   if (len == 1) {
> +   log_debug("Only one phy, not a superspeed controller\n");
> +   return 0;
> +   }
> +
> +   /* Figure out if the superspeed phy is present and if so then which 
> phy is it? */
> +   ret = of_property_read_string_index(dwc3, 

Re: [PATCH v3 13/14] qcom_defconfig: enable livetree

2024-03-19 Thread Sumit Garg
On Tue, 19 Mar 2024 at 17:52, Caleb Connolly  wrote:
>
> Qualcomm FDTs are on the larger size, and with the addition of DT
> modifications during board_init() it makes sense to enable OF_LIVE
> globally. The cost of building the tree should be offset by the
> increased efficiency at which we can walk it.
>
> Some rough measurements with CONFIG_BOOTSTAGE suggests that this might
> add 0.1-0.2ms to the boot-to-console time. However the reset-to-reset
> timer difference is in the range of 0.5ms so this could just be noise.
>
> Suffice to say, no significant slow down.
>
> Reviewed-by: Neil Armstrong 
> Signed-off-by: Caleb Connolly 
> ---
>  configs/qcom_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> index cbc612b44bd9..eebd0d74bd51 100644
> --- a/configs/qcom_defconfig
> +++ b/configs/qcom_defconfig
> @@ -25,8 +25,11 @@ CONFIG_CMD_UFS=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_CAT=y
>  CONFIG_CMD_BMP=y
>  CONFIG_CMD_LOG=y
> +CONFIG_OF_LIVE=y
> +# CONFIG_NET is not set

Is there any reason to disable CONFIG_NET here? We already support
networking on QCS404 based devices?

-Sumit

> +# CONFIG_OFNODE_MULTI_TREE is not set
>  CONFIG_BUTTON_QCOM_PMIC=y
>  CONFIG_CLK=y
>  CONFIG_CLK_QCOM_QCS404=y
>  CONFIG_CLK_QCOM_SDM845=y
>
> --
> 2.44.0
>


[PATCH v3] test: dm: add button_cmd test

2024-03-19 Thread Caleb Connolly
Add a test for the button_cmd feature. This validates that commands can
be mapped to two buttons, that the correct command runs based on which
button is pressed, that only 1 command is run, and that no command runs
if button_cmd_0_name is wrong or unset.

Additionally, fix a potential uninitialised variable use caught by these
tests, the btn variable in get_button_cmd() is assumed to be null if
button_get_by_label() fails, but it's actually used uninitialised in
that case.

CONFIG_BUTTON is now enabled automatically and was removed when running
save_defconfig.

Fixes: e761035b6423 ("boot: add support for button commands")
Signed-off-by: Caleb Connolly 
---
Pipeline: 
https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/pipelines/19995
Changes in v3:
- Enable CONFIG_BUTTON_CMD for sandbox_flattree as well.
- Link to v2: 
https://lore.kernel.org/u-boot/20240305145111.1391645-1-caleb.conno...@linaro.org

Changes in v2:
- Explicitly assign btn as NULL in get_button_cmd(). This fixes a
  bug where if the undefined variable is non-zero the
  button_get_by_label() check would fail and result in invalid memory
  being accessed.
- Enable CONFIG_BUTTON_CMD for sandbox64 as well as sandbox.
- Link to v1: 
https://lore.kernel.org/u-boot/20240214170357.4091708-1-caleb.conno...@linaro.org/
---
 common/button_cmd.c|  2 +-
 configs/sandbox64_defconfig|  1 +
 configs/sandbox_defconfig  |  1 +
 configs/sandbox_flattree_defconfig |  1 +
 test/dm/button.c   | 96 ++
 5 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/common/button_cmd.c b/common/button_cmd.c
index b6a8434d6f29..8642c26735cc 100644
--- a/common/button_cmd.c
+++ b/common/button_cmd.c
@@ -32,9 +32,9 @@ struct button_cmd {
  */
 static int get_button_cmd(int n, struct button_cmd *cmd)
 {
const char *cmd_str;
-   struct udevice *btn;
+   struct udevice *btn = NULL;
char buf[24];
 
snprintf(buf, sizeof(buf), "button_cmd_%d_name", n);
cmd->btn_name = env_get(buf);
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 3be9a00a8575..a62faf772482 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -10,8 +10,9 @@ CONFIG_PCI=y
 CONFIG_SANDBOX64=y
 CONFIG_DEBUG_UART=y
 CONFIG_SYS_MEMTEST_START=0x0010
 CONFIG_SYS_MEMTEST_END=0x00101000
+CONFIG_BUTTON_CMD=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_LEGACY_IMAGE_FORMAT=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 4ad10363e91b..93b52f2de5cf 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -9,8 +9,9 @@ CONFIG_SYS_LOAD_ADDR=0x0
 CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 CONFIG_SYS_MEMTEST_START=0x0010
 CONFIG_SYS_MEMTEST_END=0x00101000
+CONFIG_BUTTON_CMD=y
 CONFIG_FIT=y
 CONFIG_FIT_RSASSA_PSS=y
 CONFIG_FIT_CIPHER=y
 CONFIG_FIT_VERBOSE=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index 039018627527..6bf8874e722e 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -7,8 +7,9 @@ CONFIG_SYS_LOAD_ADDR=0x0
 CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 CONFIG_SYS_MEMTEST_START=0x0010
 CONFIG_SYS_MEMTEST_END=0x00101000
+CONFIG_BUTTON_CMD=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_LEGACY_IMAGE_FORMAT=y
diff --git a/test/dm/button.c b/test/dm/button.c
index 3318668df25a..830d96fbef34 100644
--- a/test/dm/button.c
+++ b/test/dm/button.c
@@ -130,4 +130,100 @@ static int dm_test_button_keys_adc(struct unit_test_state 
*uts)
 
return 0;
 }
 DM_TEST(dm_test_button_keys_adc, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
+/* Test of the button uclass using the button_gpio driver */
+static int dm_test_button_cmd(struct unit_test_state *uts)
+{
+   struct udevice *btn1_dev, *btn2_dev, *gpio;
+   const char *envstr;
+
+#define BTN1_GPIO 3
+#define BTN2_GPIO 4
+#define BTN1_PASS_VAR "test_button_cmds_0"
+#define BTN2_PASS_VAR "test_button_cmds_1"
+
+   /*
+* Buttons 1 and 2 are connected to gpio_a gpios 3 and 4 respectively.
+* set the GPIOs to known values and then check that the appropriate
+* commands are run when invoking process_button_cmds().
+*/
+   ut_assertok(uclass_get_device(UCLASS_BUTTON, 1, _dev));
+   ut_assertok(uclass_get_device(UCLASS_BUTTON, 2, _dev));
+   ut_assertok(uclass_get_device(UCLASS_GPIO, 1, ));
+
+   /*
+* Map a command to button 1 and check that it process_button_cmds()
+* runs it if called with button 1 pressed.
+*/
+   ut_assertok(env_set("button_cmd_0_name", "button1"));
+   ut_assertok(env_set("button_cmd_0", "env set " BTN1_PASS_VAR " PASS"));
+   ut_assertok(sandbox_gpio_set_value(gpio, BTN1_GPIO, 1));
+   /* Sanity check that the button is actually pressed */
+   ut_asserteq(BUTTON_ON, button_get_state(btn1_dev));
+   

Re: [PATCH v3 1/5] usb: dwc3-generic: implement Qualcomm wrapper

2024-03-19 Thread Caleb Connolly


> +static void dwc3_qcom_glue_configure(struct udevice *dev, int index,
> +  enum usb_dr_mode mode)
> +{
> + struct dwc3_glue_data *glue = dev_get_plat(dev);
> + void __iomem *qscratch_base = (void __iomem *)glue->regs;
CI is not happy with this, it fails on 32-bit builds with
"cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]"

Instead this should probably call map_physmem(glue->regs, 0x400,
MAP_NOCACHE);

I'll leave it a day in case there's any more feedback and then send a
new revision.
> + if (IS_ERR_OR_NULL(qscratch_base)) {
> + log_err("%s: Invalid qscratch base address\n", dev->name);
> + return;
> + }
> +
> + if (dev_read_bool(dev, "qcom,select-utmi-as-pipe-clk"))
> + dwc3_qcom_select_utmi_clk(qscratch_base);
> +

-- 
// Caleb (they/them)


Re: [PATCH] Makefile: Add missing OF_UPSTREAM Makefile for 32bit ARM

2024-03-19 Thread Adam Ford
On Mon, Mar 18, 2024 at 10:03 AM Marek Vasut
 wrote:
>
> Copy dts/upstream/src/arm64/Makefile into dts/upstream/src/arm/Makefile
> and create a commit. This makes 32bit ARM buildable with OF_UPSTREAM .
>
> Signed-off-by: Marek Vasut 

Tested-by: Adam Ford  #am3517-evm

> ---
> Cc: Adam Ford 
> Cc: Biju Das 
> Cc: Lad Prabhakar 
> Cc: Paul Barker 
> Cc: Ralph Siemsen 
> Cc: Tom Rini 
> ---
>  dts/upstream/src/arm/Makefile | 14 ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 dts/upstream/src/arm/Makefile
>
> diff --git a/dts/upstream/src/arm/Makefile b/dts/upstream/src/arm/Makefile
> new file mode 100644
> index 000..9a8f6aa3584
> --- /dev/null
> +++ b/dts/upstream/src/arm/Makefile
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +include $(srctree)/scripts/Makefile.dts
> +
> +targets += $(dtb-y)
> +
> +# Add any required device tree compiler flags here
> +DTC_FLAGS += -a 0x8
> +
> +PHONY += dtbs
> +dtbs: $(addprefix $(obj)/, $(dtb-y))
> +   @:
> +
> +clean-files := */*.dtb */*.dtbo
> --
> 2.43.0
>


How to handle multiple boot scripts within boot partition?

2024-03-19 Thread Sourabh Hegde Ramu
Hello,

I have a question regarding the loading of boot.scr file by u-boot. I am
working on Raspberry pi-u-boot setup and would like to store multiple boot
scripts in the boot partition. For example, what happens when I have
multiple files like boot-rpi4.scr, boot-rpi3.scr in the boot partition? How
can I specify within u-boot to load a specific boot script? Can I set the
load address for different boot scripts?

I am working on Raspbian OS and I am trying to use the conditional filters
within config.txt config.txt conditional filters

to
load different boot scripts & kernel files based on different hardware
models.

Please let me know if this could be possible in u-boot.

Thanks in advance.


Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks

2024-03-19 Thread Pierre-Clément Tosi
Hi Fabio,

On Tue, Mar 19, 2024 at 09:13:12AM -0300, Fabio Estevam wrote:
> Hi Pierre,
> 
> On Tue, Mar 19, 2024 at 8:39 AM Pierre-Clément Tosi  wrote:
> 
> > This means gd->arch.tlb_addr pointing to the live PTs during 
> > setup_pgtables().
> >
> > In arch/arm/cpu/armv8, setup_all_pgtables() runs with SCTLR_ELx.M unset.
> >
> > In arch/arm/cpu/armv8/fsl-layerscape, setup_pgtables() is called twice:
> >
> >  - early_mmu_setup() calls it with SCTLR_ELx.M unset;
> >  - final_mmu_setup() overwrites gd->arch.tlb_addr before calling it iff
> >CFG_SYS_MEM_RESERVE_SECURE is defined i.e. if 
> > CONFIG_SYS_SOC="fsl-layerscape"
> >so that  gets auto-included through
> >.
> >
> > So can CONFIG_FSL_LAYERSCAPE be set while CONFIG_SYS_SOC != 
> > "fsl-layerscape"?
> 
> No, this cannot happen.

Thanks for confirming.

For clarity, it might then make sense to drop that #ifdef in final_mmu_setup().

> Only the following Layerscape SoCs select CONFIG_FSL_LAYERSCAPE
> in arch/arm/cpu/armv8/fsl-layerscape/Kconfig:
> LS1012A, LS1028A, LS1043A, LS1046A, LS1088A, LS2080A, LX2162A and LX2160A
> 
> I saw the original boot problem with the i.MX8QX.
> 
> The i.MX8QX is part of the i.MX family, not the Layerscape family.

Sure.

To be clear, the concern here was that split_block() doesn't perform what the
CPU architecture requires when modifying page tables that the MMU is using and
the question therefore was: can setup_pgtables() be called on such live PTs?

For most AArch64 U-Boot ports (including the i.MX family), the answer is trivial
because they use the arch code i.e. setup_all_pgtables(). However, as
fsl-layerscape re-implements mmu_setup(), it had to be looked at separately,
hence my question, which you answered above.

HTH,

-- 
Pierre


Re: [PATCH v3 0/4]

2024-03-19 Thread Caleb Connolly


On Mon, 11 Mar 2024 21:33:44 +, Volodymyr Babchuk wrote:
> Set of pre-req patches for Qualcomm SA8155P-ADP board support.
> 
> This path series consist of generic qcom changes that may benefit
> different boards. It is the part of the bigger series that adds
> SA8155P-ADP support, but I am posting this limited set because there
> are other developers who depend on those changes and I am not ready to
> post other patches of the bigger series.
> 
> [...]

Applied, thanks!

[1/4] qcom: board: validate fdt before trying to use it
  commit: a1ecfa2371efc68671c66d3e186743f82926a640
[2/4] clk: qcom: clear div mask before assigning a new divider
  commit: 10f402108a9063d5bc4d517e2a1197afcfabc3a4
[3/4] clk: qcom: add support for power domains uclass
  commit: 95d76bf4e9a912ee458726a59b1045ecb2eff0cc
[4/4] pinctrl: qcom: pass pin number to get_function_mux callback
  commit: 018b8ab702ce38f79e7d276186565478513880a6

Best regards,
-- 
// Caleb (they/them)



[PATCH v3 13/14] qcom_defconfig: enable livetree

2024-03-19 Thread Caleb Connolly
Qualcomm FDTs are on the larger size, and with the addition of DT
modifications during board_init() it makes sense to enable OF_LIVE
globally. The cost of building the tree should be offset by the
increased efficiency at which we can walk it.

Some rough measurements with CONFIG_BOOTSTAGE suggests that this might
add 0.1-0.2ms to the boot-to-console time. However the reset-to-reset
timer difference is in the range of 0.5ms so this could just be noise.

Suffice to say, no significant slow down.

Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---
 configs/qcom_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index cbc612b44bd9..eebd0d74bd51 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -25,8 +25,11 @@ CONFIG_CMD_UFS=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_CAT=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_LOG=y
+CONFIG_OF_LIVE=y
+# CONFIG_NET is not set
+# CONFIG_OFNODE_MULTI_TREE is not set
 CONFIG_BUTTON_QCOM_PMIC=y
 CONFIG_CLK=y
 CONFIG_CLK_QCOM_QCS404=y
 CONFIG_CLK_QCOM_SDM845=y

-- 
2.44.0



[PATCH v3 14/14] qcom_defconfig: enable USB

2024-03-19 Thread Caleb Connolly
Enable support for the DWC3 USB controller and required dependencies for
Qualcomm boards, specifically the DB845c:
* IOMMU / SMMU
* USB high-speed PHYs
* Mass storage and ACM gadgets

Signed-off-by: Caleb Connolly 
---
 configs/qcom_defconfig | 49 ++---
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index eebd0d74bd51..156c205284dd 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -12,42 +12,63 @@ CONFIG_BOOTSTD_FULL=y
 CONFIG_BOOTDELAY=1
 CONFIG_USE_PREBOOT=y
 CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR=y
 CONFIG_SYS_CBSIZE=512
+# CONFIG_SYS_DEVICE_NULLDEV is not set
 CONFIG_LOG_MAX_LEVEL=9
 CONFIG_LOG_DEFAULT_LEVEL=4
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_CMD_BOOTMENU=y
+CONFIG_CMD_EEPROM=y
+CONFIG_SYS_I2C_EEPROM_BUS=2
+CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
+CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5
+# CONFIG_CMD_BIND is not set
 CONFIG_CMD_CLK=y
 CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_UFS=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_CAT=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_LOG=y
 CONFIG_OF_LIVE=y
 # CONFIG_NET is not set
+CONFIG_DM_WARN=y
 # CONFIG_OFNODE_MULTI_TREE is not set
 CONFIG_BUTTON_QCOM_PMIC=y
 CONFIG_CLK=y
 CONFIG_CLK_QCOM_QCS404=y
 CONFIG_CLK_QCOM_SDM845=y
 CONFIG_MSM_GPIO=y
 CONFIG_QCOM_PMIC_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_QUP=y
+CONFIG_I2C_MUX=y
 CONFIG_DM_KEYBOARD=y
 CONFIG_BUTTON_KEYBOARD=y
+CONFIG_IOMMU=y
+CONFIG_QCOM_HYP_SMMU=y
+CONFIG_MISC=y
+CONFIG_NVMEM=y
+CONFIG_I2C_EEPROM=y
 CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ADMA=y
 CONFIG_MMC_SDHCI_MSM=y
+CONFIG_DM_ETH_PHY=y
 CONFIG_PHY=y
+CONFIG_PHY_QCOM_QUSB2=y
+CONFIG_PHY_QCOM_USB_HS_7NM=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_QCOM_QCS404=y
 CONFIG_PINCTRL_QCOM_SDM845=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_QCOM=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_SCSI=y
 CONFIG_MSM_SERIAL=y
 CONFIG_MSM_GENI_SERIAL=y
 CONFIG_SPMI_MSM=y
@@ -56,8 +77,13 @@ CONFIG_SYSINFO_SMBIOS=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_FUNCTION_MASS_STORAGE=y
+CONFIG_USB_FUNCTION_ACM=y
 CONFIG_UFS=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_FONT_8X16 is not set
 CONFIG_VIDEO_FONT_16X32=y
@@ -66,27 +92,4 @@ CONFIG_NO_FB_CLEAR=y
 CONFIG_VIDEO_SIMPLE=y
 CONFIG_HEXDUMP=y
 # CONFIG_GENERATE_SMBIOS_TABLE is not set
 CONFIG_LMB_MAX_REGIONS=64
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_EEPROM=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_PING=y
-CONFIG_DM_ETH=y
-CONFIG_DM_ETH_PHY=y
-CONFIG_DM_MDIO=y
-CONFIG_DWC_ETH_QOS=y
-CONFIG_DWC_ETH_QOS_QCOM=y
-CONFIG_RGMII=y
-CONFIG_PHY_MICREL=y
-CONFIG_PHY_MICREL_KSZ90X1=y
-CONFIG_MISC=y
-CONFIG_NVMEM=y
-CONFIG_DM_I2C=y
-CONFIG_I2C_SUPPORT=y
-CONFIG_I2C_MUX=y
-CONFIG_I2C_EEPROM=y
-CONFIG_SYS_I2C=y
-CONFIG_SYS_I2C_QUP=y
-CONFIG_SYS_I2C_EEPROM_BUS=2
-CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
-CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5

-- 
2.44.0



[PATCH v3 12/14] dts: sdm845-db845c: add u-boot fixups

2024-03-19 Thread Caleb Connolly
The USB VBUS supply for the type-A port is enabled via a GPIO regulator.
This is incorrectly modelled in Linux where only the PCIe dependency is
expressed. Add a U-Boot specific dtsi snippet so that this supply will
get enabled when initialising USB.

Signed-off-by: Caleb Connolly 
---
 arch/arm/dts/sdm845-db845c-u-boot.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/sdm845-db845c-u-boot.dtsi 
b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
new file mode 100644
index ..3c83e21251c4
--- /dev/null
+++ b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* This GPIO must be turned on to enable the 5v VBUS
+ * supply on the USB port.
+ */
+_2_dwc3 {
+   vbus-supply = <_3p3v_dual>;
+};

-- 
2.44.0



[PATCH v3 11/14] mach-snapdragon: fixup power-domains

2024-03-19 Thread Caleb Connolly
We don't support the RPM(h)PD power domains in U-Boot, and we don't need
to - the necessary resources are on, and we aren't going to enter any
low power modes.

We could try using a no-op device, but this requires adding a compatible
for every platform, and just pollutes the driver model. So instead let's
just remove every "power-domains" property that references the RPM(h)pd
power controller. This takes <1ms as we're using OF_LIVE.

Of note, this only applies to drivers which are loading post-relocation.
Drivers loaded pre-reloc that reference the rpm(h)pd still need
DM_FLAG_DEFAULT_PD_CTRL_OFF in their flags.

Signed-off-by: Caleb Connolly 
---
 arch/arm/mach-snapdragon/of_fixup.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/mach-snapdragon/of_fixup.c 
b/arch/arm/mach-snapdragon/of_fixup.c
index 6810c8617cc0..49f1fc1948f3 100644
--- a/arch/arm/mach-snapdragon/of_fixup.c
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -21,8 +21,9 @@
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
  * USB controllers. Rather than requiring source level DT changes, we fix up
  * DT here. This improves compatibility with upstream DT and simplifies the
@@ -108,8 +109,39 @@ static void fixup_usb_nodes(void)
log_warning("Failed to fixup node %s: %d\n", 
glue_np->name, ret);
}
 }
 
+/* Remove all references to the rpmhpd device */
+static void fixup_power_domains(void)
+{
+   struct device_node *pd = NULL, *np = NULL;
+   struct property *prop;
+   const __be32 *val;
+
+   /* All Qualcomm platforms name the rpm(h)pd "power-controller" */
+   for_each_of_allnodes(pd) {
+   if (pd->name && !strcmp("power-controller", pd->name))
+   break;
+   }
+
+   /* Sanity check that this is indeed a power domain controller */
+   if (!of_find_property(pd, "#power-domain-cells", NULL)) {
+   log_err("Found power-controller but it doesn't have 
#power-domain-cells\n");
+   return;
+   }
+
+   /* Remove all references to the power domain controller */
+   for_each_of_allnodes(np) {
+   if (!(prop = of_find_property(np, "power-domains", NULL)))
+   continue;
+
+   val = prop->value;
+   if (val[0] == cpu_to_fdt32(pd->phandle))
+   of_remove_property(np, prop);
+   }
+}
+
 void qcom_of_fixup_nodes(void)
 {
fixup_usb_nodes();
+   fixup_power_domains();
 }

-- 
2.44.0



[PATCH v3 10/14] mach-snapdragon: fixup USB nodes

2024-03-19 Thread Caleb Connolly
We don't support USB super-speed in U-Boot yet, we lack the SS PHY
drivers, however from my testing even with a PHY driver there seem to be
other issues when talking to super-speed peripherals.

In pursuit of maintaining upstream DT compatibility, and simplifying
porting for new devices, let's implement the DT fixups necessary to
configure USB in high-speed only mode at runtime. The pattern is
identical for all Qualcomm boards that use the Synaptics DWC3
controller:

* Add an additional property on the Qualcomm wrapper node
* Remove the super-speed phy phandle and phy-name entries.

Signed-off-by: Caleb Connolly 
---
 arch/arm/mach-snapdragon/Makefile|   1 +
 arch/arm/mach-snapdragon/board.c |   3 +
 arch/arm/mach-snapdragon/of_fixup.c  | 115 +++
 arch/arm/mach-snapdragon/qcom-priv.h |  19 ++
 4 files changed, 138 insertions(+)

diff --git a/arch/arm/mach-snapdragon/Makefile 
b/arch/arm/mach-snapdragon/Makefile
index 857171e593da..7a4495c8108f 100644
--- a/arch/arm/mach-snapdragon/Makefile
+++ b/arch/arm/mach-snapdragon/Makefile
@@ -2,4 +2,5 @@
 #
 # (C) Copyright 2015 Mateusz Kulikowski 
 
 obj-y += board.o
+obj-$(CONFIG_OF_LIVE) += of_fixup.o
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index 6f762fc948bf..65e4c61e866a 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -27,8 +27,10 @@
 #include 
 #include 
 #include 
 
+#include "qcom-priv.h"
+
 DECLARE_GLOBAL_DATA_PTR;
 
 static struct mm_region rbx_mem_map[CONFIG_NR_DRAM_BANKS + 2] = { { 0 } };
 
@@ -159,8 +161,9 @@ void __weak qcom_board_init(void)
 
 int board_init(void)
 {
show_psci_version();
+   qcom_of_fixup_nodes();
qcom_board_init();
return 0;
 }
 
diff --git a/arch/arm/mach-snapdragon/of_fixup.c 
b/arch/arm/mach-snapdragon/of_fixup.c
new file mode 100644
index ..6810c8617cc0
--- /dev/null
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * OF_LIVE devicetree fixup.
+ *
+ * This file implements runtime fixups for Qualcomm DT to improve
+ * compatibility with U-Boot. This includes adjusting the USB nodes
+ * to only use USB high-speed, as well as remapping volume buttons
+ * to behave as up/down for navigating U-Boot.
+ *
+ * We use OF_LIVE for this rather than early FDT fixup for a couple
+ * of reasons: it has a much nicer API, is most likely more efficient,
+ * and our changes are only applied to U-Boot. This allows us to use a
+ * DT designed for Linux, run U-Boot with a modified version, and then
+ * boot Linux with the original FDT.
+ *
+ * Copyright (c) 2024 Linaro Ltd.
+ *   Author: Caleb Connolly 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
+ * USB controllers. Rather than requiring source level DT changes, we fix up
+ * DT here. This improves compatibility with upstream DT and simplifies the
+ * porting process for new devices.
+ */
+static int fixup_qcom_dwc3(struct device_node *glue_np)
+{
+   struct device_node *dwc3;
+   int ret, len, hsphy_idx = 1;
+   const __be32 *phandles;
+   const char *second_phy_name;
+
+   debug("Fixing up %s\n", glue_np->name);
+
+   /* Tell the glue driver to configure the wrapper for high-speed only 
operation */
+   ret = of_write_prop(glue_np, "qcom,select-utmi-as-pipe-clk", 0, NULL);
+   if (ret) {
+   log_err("Failed to add property 'qcom,select-utmi-as-pipe-clk': 
%d\n", ret);
+   return ret;
+   }
+
+   /* Find the DWC3 node itself */
+   dwc3 = of_find_compatible_node(glue_np, NULL, "snps,dwc3");
+   if (!dwc3) {
+   log_err("Failed to find dwc3 node\n");
+   return -ENOENT;
+   }
+
+   phandles = of_get_property(dwc3, "phys", );
+   len /= sizeof(*phandles);
+   if (len == 1) {
+   log_debug("Only one phy, not a superspeed controller\n");
+   return 0;
+   }
+
+   /* Figure out if the superspeed phy is present and if so then which phy 
is it? */
+   ret = of_property_read_string_index(dwc3, "phy-names", 1, 
_phy_name);
+   if (ret == -ENODATA) {
+   log_debug("Only one phy, not a super-speed controller\n");
+   return 0;
+   } else if (ret) {
+   log_err("Failed to read second phy name: %d\n", ret);
+   return ret;
+   }
+
+   if (!strncmp("usb3-phy", second_phy_name, strlen("usb3-phy"))) {
+   log_debug("Second phy isn't superspeed (is '%s') assuming first 
phy is SS\n",
+ second_phy_name);
+   hsphy_idx = 0;
+   }
+
+   /* Overwrite the "phys" property to only contain the high-speed phy */
+   ret = of_write_prop(dwc3, "phys", sizeof(*phandles), phandles + 
hsphy_idx);
+   if (ret) {
+   log_err("Failed to 

[PATCH v3 08/14] gpio: msm_gpio: add .set_flags op

2024-03-19 Thread Caleb Connolly
The .direction_input and .direction_output ops are deprecated, and don't
seem to behave properly for us. Implement our own .set_flags op to
handle this correctly.

Signed-off-by: Caleb Connolly 
---
 drivers/gpio/msm_gpio.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/msm_gpio.c b/drivers/gpio/msm_gpio.c
index 5e57b0cbde75..f5d9ab54e817 100644
--- a/drivers/gpio/msm_gpio.c
+++ b/drivers/gpio/msm_gpio.c
@@ -34,21 +34,21 @@ struct msm_gpio_bank {
 
 #define GPIO_IN_OUT_REG(dev, x) \
(GPIO_CONFIG_REG(dev, x) + 0x4)
 
-static int msm_gpio_direction_input(struct udevice *dev, unsigned int gpio)
+static void msm_gpio_direction_input(struct udevice *dev, unsigned int gpio)
 {
struct msm_gpio_bank *priv = dev_get_priv(dev);
 
/* Always NOP for special pins, assume they're in the correct state */
if (qcom_is_special_pin(priv->pin_data, gpio))
-   return 0;
+   return;
 
/* Disable OE bit */
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(dev, gpio),
GPIO_OE_MASK, GPIO_OE_DISABLE);
 
-   return 0;
+   return;
 }
 
 static int msm_gpio_set_value(struct udevice *dev, unsigned int gpio, int 
value)
 {
@@ -83,8 +83,25 @@ static int msm_gpio_direction_output(struct udevice *dev, 
unsigned int gpio,
 
return 0;
 }
 
+static int msm_gpio_set_flags(struct udevice *dev, unsigned int gpio, ulong 
flags)
+{
+   if (flags & GPIOD_IS_OUT_ACTIVE) {
+   return msm_gpio_direction_output(dev, gpio, 1);
+   } else if (flags & GPIOD_IS_OUT) {
+   return msm_gpio_direction_output(dev, gpio, 0);
+   } else if (flags & GPIOD_IS_IN) {
+   msm_gpio_direction_input(dev, gpio);
+   if (flags & GPIOD_PULL_UP)
+   return msm_gpio_set_value(dev, gpio, 1);
+   else if (flags & GPIOD_PULL_DOWN)
+   return msm_gpio_set_value(dev, gpio, 0);
+   }
+
+   return 0;
+}
+
 static int msm_gpio_get_value(struct udevice *dev, unsigned int gpio)
 {
struct msm_gpio_bank *priv = dev_get_priv(dev);
 
@@ -109,12 +126,10 @@ static int msm_gpio_get_function(struct udevice *dev, 
unsigned int gpio)
return GPIOF_INPUT;
 }
 
 static const struct dm_gpio_ops gpio_msm_ops = {
-   .direction_input= msm_gpio_direction_input,
-   .direction_output   = msm_gpio_direction_output,
+   .set_flags  = msm_gpio_set_flags,
.get_value  = msm_gpio_get_value,
-   .set_value  = msm_gpio_set_value,
.get_function   = msm_gpio_get_function,
 };
 
 static int msm_gpio_probe(struct udevice *dev)

-- 
2.44.0



[PATCH v3 09/14] serial: msm-geni: support livetree

2024-03-19 Thread Caleb Connolly
When using OF_LIVE, the debug UART driver won't be probed if it's a
subnode of the geni-se-qup controller. Add a NOP driver for the
controller to correctly discover its child nodes.

Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---
 drivers/serial/serial_msm_geni.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/serial/serial_msm_geni.c b/drivers/serial/serial_msm_geni.c
index 4aa0bc8c72bc..5260474fb9a4 100644
--- a/drivers/serial/serial_msm_geni.c
+++ b/drivers/serial/serial_msm_geni.c
@@ -605,8 +605,21 @@ U_BOOT_DRIVER(serial_msm_geni) = {
.ops = _serial_ops,
.flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
 };
 
+static const struct udevice_id geniqup_ids[] = {
+   { .compatible = "qcom,geni-se-qup" },
+   { }
+};
+
+U_BOOT_DRIVER(geni_se_qup) = {
+   .name = "geni-se-qup",
+   .id = UCLASS_NOP,
+   .of_match = geniqup_ids,
+   .bind = dm_scan_fdt_dev,
+   .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
+};
+
 #ifdef CONFIG_DEBUG_UART_MSM_GENI
 
 static struct msm_serial_data init_serial_data = {
.base = CONFIG_VAL(DEBUG_UART_BASE)

-- 
2.44.0



[PATCH v3 07/14] clk/qcom: sdm845: add USB clocks

2024-03-19 Thread Caleb Connolly
Most devices only initialise the USB clocks for us if we boot via
"fastboot boot", add the missing clock configuration to get both USB
ports working regardless of the bootloader state.

Signed-off-by: Caleb Connolly 
---
 drivers/clk/qcom/clock-sdm845.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
index b7154360894a..e9c61eb480de 100644
--- a/drivers/clk/qcom/clock-sdm845.c
+++ b/drivers/clk/qcom/clock-sdm845.c
@@ -20,8 +20,12 @@
 #include "clock-qcom.h"
 
 #define SE9_UART_APPS_CMD_RCGR 0x18148
 
+#define USB30_PRIM_MASTER_CLK_CMD_RCGR 0xf018
+#define USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR 0xf030
+#define USB3_PRIM_PHY_AUX_CMD_RCGR 0xf05c
+
 static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
@@ -56,8 +60,10 @@ static ulong sdm845_clk_set_rate(struct clk *clk, ulong rate)
}
 }
 
 static const struct gate_clk sdm845_clks[] = {
+   GATE_CLK(GCC_AGGRE_USB3_SEC_AXI_CLK,0x82020, 0x0001),
+   GATE_CLK(GCC_CFG_NOC_USB3_SEC_AXI_CLK,  0x05030, 0x0001),
GATE_CLK(GCC_QUPV3_WRAP0_S0_CLK,0x5200c, 0x0400),
GATE_CLK(GCC_QUPV3_WRAP0_S1_CLK,0x5200c, 0x0800),
GATE_CLK(GCC_QUPV3_WRAP0_S2_CLK,0x5200c, 0x1000),
GATE_CLK(GCC_QUPV3_WRAP0_S3_CLK,0x5200c, 0x2000),
@@ -120,8 +126,27 @@ static int sdm845_clk_enable(struct clk *clk)
struct msm_clk_priv *priv = dev_get_priv(clk->dev);
 
debug("%s: clk %s\n", __func__, sdm845_clks[clk->id].name);
 
+   switch (clk->id) {
+   case GCC_USB30_PRIM_MASTER_CLK:
+   qcom_gate_clk_en(priv, GCC_USB_PHY_CFG_AHB2PHY_CLK);
+   /* These numbers are just pulled from the frequency tables in 
the Linux driver */
+   clk_rcg_set_rate_mnd(priv->base, USB30_PRIM_MASTER_CLK_CMD_RCGR,
+(4.5 * 2) - 1, 0, 0, 1 << 8, 8);
+   clk_rcg_set_rate_mnd(priv->base, 
USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR,
+1, 0, 0, 0, 8);
+   clk_rcg_set_rate_mnd(priv->base, USB3_PRIM_PHY_AUX_CMD_RCGR,
+1, 0, 0, 0, 8);
+   break;
+   case GCC_USB30_SEC_MASTER_CLK:
+   qcom_gate_clk_en(priv, GCC_USB3_SEC_PHY_AUX_CLK);
+
+   qcom_gate_clk_en(priv, GCC_USB3_SEC_CLKREF_CLK);
+   qcom_gate_clk_en(priv, GCC_USB3_SEC_PHY_COM_AUX_CLK);
+   break;
+   }
+
qcom_gate_clk_en(priv, clk->id);
 
return 0;
 }

-- 
2.44.0



[PATCH v3 06/14] clk/qcom: sdm845: add gdscs

2024-03-19 Thread Caleb Connolly
Define the GDSC power domains for SDM845.

Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---
 drivers/clk/qcom/clock-sdm845.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
index ccb0cf245d33..b7154360894a 100644
--- a/drivers/clk/qcom/clock-sdm845.c
+++ b/drivers/clk/qcom/clock-sdm845.c
@@ -145,13 +145,31 @@ static const struct qcom_reset_map sdm845_gcc_resets[] = {
[GCC_USB3_DP_PHY_SEC_BCR] = { 0x50014 },
[GCC_USB_PHY_CFG_AHB2PHY_BCR] = { 0x6a000 },
 };
 
+static const struct qcom_power_map sdm845_gdscs[] = {
+   [PCIE_0_GDSC] = { 0x6b004 },
+   [PCIE_1_GDSC] = { 0x8d004 },
+   [UFS_CARD_GDSC] = { 0x75004 },
+   [UFS_PHY_GDSC] = { 0x77004 },
+   [USB30_PRIM_GDSC] = { 0xf004 },
+   [USB30_SEC_GDSC] = { 0x10004 },
+   [HLOS1_VOTE_AGGRE_NOC_MMU_AUDIO_TBU_GDSC] = { 0x7d030 },
+   [HLOS1_VOTE_AGGRE_NOC_MMU_PCIE_TBU_GDSC] = { 0x7d03c },
+   [HLOS1_VOTE_AGGRE_NOC_MMU_TBU1_GDSC] = { 0x7d034 },
+   [HLOS1_VOTE_AGGRE_NOC_MMU_TBU2_GDSC] = { 0x7d038 },
+   [HLOS1_VOTE_MMNOC_MMU_TBU_HF0_GDSC] = { 0x7d040 },
+   [HLOS1_VOTE_MMNOC_MMU_TBU_HF1_GDSC] = { 0x7d048 },
+   [HLOS1_VOTE_MMNOC_MMU_TBU_SF_GDSC] = { 0x7d044 },
+};
+
 static struct msm_clk_data sdm845_clk_data = {
.resets = sdm845_gcc_resets,
.num_resets = ARRAY_SIZE(sdm845_gcc_resets),
.clks = sdm845_clks,
.num_clks = ARRAY_SIZE(sdm845_clks),
+   .power_domains = sdm845_gdscs,
+   .num_power_domains = ARRAY_SIZE(sdm845_gdscs),
 
.enable = sdm845_clk_enable,
.set_rate = sdm845_clk_set_rate,
 };

-- 
2.44.0



[PATCH v3 05/14] clk/qcom: use offsets for RCG registers

2024-03-19 Thread Caleb Connolly
The RCG registers always have the same offsets, so only store the base
CMD register address and calculate the others relative to that.

Signed-off-by: Caleb Connolly 
---
 drivers/clk/qcom/clock-apq8016.c |  39 +
 drivers/clk/qcom/clock-apq8096.c |  28 +
 drivers/clk/qcom/clock-qcom.c|  22 +++
 drivers/clk/qcom/clock-qcom.h|  16 +++---
 drivers/clk/qcom/clock-qcs404.c  | 121 +--
 drivers/clk/qcom/clock-sdm845.c  |  16 +-
 6 files changed, 39 insertions(+), 203 deletions(-)

diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index e6647f7c41dd..5a5868169c89 100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -22,13 +22,9 @@
 #define APCS_GPLL_ENA_VOTE (0x45000)
 #define APCS_CLOCK_BRANCH_ENA_VOTE (0x45004)
 
 #define SDCC_BCR(n)((n * 0x1000) + 0x41000)
-#define SDCC_CMD_RCGR(n)   ((n * 0x1000) + 0x41004)
-#define SDCC_CFG_RCGR(n)   ((n * 0x1000) + 0x41008)
-#define SDCC_M(n)  ((n * 0x1000) + 0x4100C)
-#define SDCC_N(n)  ((n * 0x1000) + 0x41010)
-#define SDCC_D(n)  ((n * 0x1000) + 0x41014)
+#define SDCC_CMD_RCGR(n)   (((n + 1) * 0x1000) + 0x41004)
 #define SDCC_APPS_CBCR(n)  ((n * 0x1000) + 0x41018)
 #define SDCC_AHB_CBCR(n)   ((n * 0x1000) + 0x4101C)
 
 /* BLSP1 AHB clock (root clock for BLSP) */
@@ -37,33 +33,12 @@
 /* Uart clock control registers */
 #define BLSP1_UART2_BCR(0x3028)
 #define BLSP1_UART2_APPS_CBCR  (0x302C)
 #define BLSP1_UART2_APPS_CMD_RCGR  (0x3034)
-#define BLSP1_UART2_APPS_CFG_RCGR  (0x3038)
-#define BLSP1_UART2_APPS_M (0x303C)
-#define BLSP1_UART2_APPS_N (0x3040)
-#define BLSP1_UART2_APPS_D (0x3044)
 
 /* GPLL0 clock control registers */
 #define GPLL0_STATUS_ACTIVE BIT(17)
 
-static const struct bcr_regs sdc_regs[] = {
-   {
-   .cfg_rcgr = SDCC_CFG_RCGR(1),
-   .cmd_rcgr = SDCC_CMD_RCGR(1),
-   .M = SDCC_M(1),
-   .N = SDCC_N(1),
-   .D = SDCC_D(1),
-   },
-   {
-   .cfg_rcgr = SDCC_CFG_RCGR(2),
-   .cmd_rcgr = SDCC_CMD_RCGR(2),
-   .M = SDCC_M(2),
-   .N = SDCC_N(2),
-   .D = SDCC_D(2),
-   }
-};
-
 static struct pll_vote_clk gpll0_vote_clk = {
.status = GPLL0_STATUS,
.status_bit = GPLL0_STATUS_ACTIVE,
.ena_vote = APCS_GPLL_ENA_VOTE,
@@ -85,32 +60,24 @@ static int clk_init_sdc(struct msm_clk_priv *priv, int 
slot, uint rate)
div = 4;
 
clk_enable_cbc(priv->base + SDCC_AHB_CBCR(slot));
/* 800Mhz/div, gpll0 */
-   clk_rcg_set_rate_mnd(priv->base, _regs[slot], div, 0, 0,
+   clk_rcg_set_rate_mnd(priv->base, SDCC_CMD_RCGR(slot), div, 0, 0,
 CFG_CLK_SRC_GPLL0, 8);
clk_enable_gpll0(priv->base, _vote_clk);
clk_enable_cbc(priv->base + SDCC_APPS_CBCR(slot));
 
return rate;
 }
 
-static const struct bcr_regs uart2_regs = {
-   .cfg_rcgr = BLSP1_UART2_APPS_CFG_RCGR,
-   .cmd_rcgr = BLSP1_UART2_APPS_CMD_RCGR,
-   .M = BLSP1_UART2_APPS_M,
-   .N = BLSP1_UART2_APPS_N,
-   .D = BLSP1_UART2_APPS_D,
-};
-
 /* UART: 115200 */
 int apq8016_clk_init_uart(phys_addr_t base)
 {
/* Enable AHB clock */
clk_enable_vote_clk(base, _blsp1_ahb_clk);
 
/* 7372800 uart block clock @ GPLL0 */
-   clk_rcg_set_rate_mnd(base, _regs, 1, 144, 15625,
+   clk_rcg_set_rate_mnd(base, BLSP1_UART2_APPS_CMD_RCGR, 1, 144, 15625,
 CFG_CLK_SRC_GPLL0, 16);
 
/* Vote for gpll0 clock */
clk_enable_gpll0(base, _vote_clk);
diff --git a/drivers/clk/qcom/clock-apq8096.c b/drivers/clk/qcom/clock-apq8096.c
index a4731613c5e0..479f9771a464 100644
--- a/drivers/clk/qcom/clock-apq8096.c
+++ b/drivers/clk/qcom/clock-apq8096.c
@@ -25,33 +25,17 @@
 #define SDCC2_BCR  (0x14000) /* block reset */
 #define SDCC2_APPS_CBCR(0x14004) /* branch control */
 #define SDCC2_AHB_CBCR (0x14008)
 #define SDCC2_CMD_RCGR (0x14010)
-#define SDCC2_CFG_RCGR (0x14014)
-#define SDCC2_M(0x14018)
-#define SDCC2_N(0x1401C)
-#define SDCC2_D(0x14020)
 
 #define BLSP2_AHB_CBCR (0x25004)
 #define BLSP2_UART2_APPS_CBCR  (0x29004)
 #define BLSP2_UART2_APPS_CMD_RCGR  (0x2900C)
-#define BLSP2_UART2_APPS_CFG_RCGR  (0x29010)
-#define BLSP2_UART2_APPS_M (0x29014)
-#define BLSP2_UART2_APPS_N (0x29018)
-#define BLSP2_UART2_APPS_D (0x2901C)
 
 /* GPLL0 clock control registers */
 #define GPLL0_STATUS_ACTIVEBIT(30)
 #define APCS_GPLL_ENA_VOTE_GPLL0   BIT(0)
 
-static const struct bcr_regs 

[PATCH v3 04/14] mach-snapdragon: disable power-domains for pre-reloc drivers

2024-03-19 Thread Caleb Connolly
Some devices like the UART and clock controller reference an RPM(h)
power domain. We don't support this device in U-Boot, so add
DM_FLAG_DEFAULT_PD_CTRL_OFF to tell DM core not to try and enable the
power domain.

Signed-off-by: Caleb Connolly 
---
 drivers/clk/qcom/clock-qcom.c| 2 ++
 drivers/clk/qcom/clock-sdm845.c  | 2 +-
 drivers/serial/serial_msm_geni.c | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c
index 7a5938a06a34..6303dcbf8461 100644
--- a/drivers/clk/qcom/clock-qcom.c
+++ b/drivers/clk/qcom/clock-qcom.c
@@ -226,8 +226,9 @@ U_BOOT_DRIVER(qcom_clk) = {
.id = UCLASS_CLK,
.ops= _clk_ops,
.priv_auto  = sizeof(struct msm_clk_priv),
.probe  = msm_clk_probe,
+   .flags  = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
 };
 
 int qcom_cc_bind(struct udevice *parent)
 {
@@ -410,5 +411,6 @@ U_BOOT_DRIVER(qcom_power) = {
.name = "qcom_power",
.id = UCLASS_POWER_DOMAIN,
.ops = _power_ops,
.probe = qcom_power_probe,
+   .flags = DM_FLAG_PRE_RELOC,
 };
diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
index 36ffee79d966..babd83119e2c 100644
--- a/drivers/clk/qcom/clock-sdm845.c
+++ b/drivers/clk/qcom/clock-sdm845.c
@@ -182,6 +182,6 @@ U_BOOT_DRIVER(gcc_sdm845) = {
.name   = "gcc_sdm845",
.id = UCLASS_NOP,
.of_match   = gcc_sdm845_of_match,
.bind   = qcom_cc_bind,
-   .flags  = DM_FLAG_PRE_RELOC,
+   .flags  = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
 };
diff --git a/drivers/serial/serial_msm_geni.c b/drivers/serial/serial_msm_geni.c
index e5c3dcffc1c6..4aa0bc8c72bc 100644
--- a/drivers/serial/serial_msm_geni.c
+++ b/drivers/serial/serial_msm_geni.c
@@ -602,9 +602,9 @@ U_BOOT_DRIVER(serial_msm_geni) = {
.of_to_plat = msm_serial_ofdata_to_platdata,
.priv_auto = sizeof(struct msm_serial_data),
.probe = msm_serial_probe,
.ops = _serial_ops,
-   .flags = DM_FLAG_PRE_RELOC,
+   .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
 };
 
 #ifdef CONFIG_DEBUG_UART_MSM_GENI
 

-- 
2.44.0



[PATCH v3 03/14] phy: qcom: Add USB HS 7nm PHY driver

2024-03-19 Thread Caleb Connolly
From: Bhupesh Sharma 

Some Qualcomm SoCs newer than SDM845 feature a so-called "7nm phy"
driver, notable the SM8250 SoC which will gain U-Boot support in
upcoming patches.

Introduce a driver based on the Linux driver.

Signed-off-by: Bhupesh Sharma 
[code cleanup, switch to clk/reset_bulk APIs]
Signed-off-by: Caleb Connolly 
---
 drivers/phy/qcom/Kconfig   |   8 +
 drivers/phy/qcom/Makefile  |   1 +
 drivers/phy/qcom/phy-qcom-usb-hs-7nm.c | 295 +
 3 files changed, 304 insertions(+)

diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
index 361dfb6e1126..3fc59dc65650 100644
--- a/drivers/phy/qcom/Kconfig
+++ b/drivers/phy/qcom/Kconfig
@@ -18,8 +18,16 @@ config PHY_QCOM_QUSB2
help
  Enable this to support the Super-Speed USB transceiver on various
  Qualcomm chipsets.
 
+config PHY_QCOM_USB_HS_7NM
+   tristate "Qualcomm 7nm High-Speed PHY"
+   depends on PHY && ARCH_SNAPDRAGON
+   help
+ Enable this to support the Qualcomm Synopsys DesignWare Core 7nm
+ High-Speed PHY driver. This driver supports the Hi-Speed PHY which
+ is usually paired with Synopsys DWC3 USB IPs on MSM SOCs.
+
 config PHY_QCOM_USB_HS_28NM
tristate "Qualcomm 28nm High-Speed PHY"
depends on PHY && ARCH_SNAPDRAGON
help
diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
index f6af985666a4..39219ecd24aa 100644
--- a/drivers/phy/qcom/Makefile
+++ b/drivers/phy/qcom/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
 obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
 obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
+obj-$(CONFIG_PHY_QCOM_USB_HS_7NM) += phy-qcom-usb-hs-7nm.o
 obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
 obj-$(CONFIG_PHY_QCOM_USB_SS) += phy-qcom-usb-ss.o
diff --git a/drivers/phy/qcom/phy-qcom-usb-hs-7nm.c 
b/drivers/phy/qcom/phy-qcom-usb-hs-7nm.c
new file mode 100644
index ..65128b45937b
--- /dev/null
+++ b/drivers/phy/qcom/phy-qcom-usb-hs-7nm.c
@@ -0,0 +1,295 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Bhupesh Sharma 
+ *
+ * Based on Linux driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL0 (0x3c)
+#define SLEEPM BIT(0)
+#define OPMODE_MASK GENMASK(4, 3)
+#define OPMODE_NORMAL (0x00)
+#define OPMODE_NONDRIVING BIT(3)
+#define TERMSEL BIT(5)
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL1 (0x40)
+#define XCVRSEL BIT(0)
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL5 (0x50)
+#define POR BIT(1)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0 (0x54)
+#define SIDDQ BIT(2)
+#define RETENABLEN BIT(3)
+#define FSEL_MASK GENMASK(6, 4)
+#define FSEL_DEFAULT (0x3 << 4)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON1 (0x58)
+#define VBUSVLDEXTSEL0 BIT(4)
+#define PLLBTUNE BIT(5)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON2 (0x5c)
+#define VREGBYPASS BIT(0)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL1 (0x60)
+#define VBUSVLDEXT0 BIT(0)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL2 (0x64)
+#define USB2_AUTO_RESUME BIT(0)
+#define USB2_SUSPEND_N BIT(2)
+#define USB2_SUSPEND_N_SEL BIT(3)
+
+#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X0 (0x6c)
+#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X1 (0x70)
+#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X2 (0x74)
+#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X3 (0x78)
+#define PARAM_OVRD_MASK 0xFF
+
+#define USB2_PHY_USB_PHY_CFG0 (0x94)
+#define UTMI_PHY_DATAPATH_CTRL_OVERRIDE_EN BIT(0)
+#define UTMI_PHY_CMN_CTRL_OVERRIDE_EN BIT(1)
+
+#define USB2_PHY_USB_PHY_REFCLK_CTRL (0xa0)
+#define REFCLK_SEL_MASK GENMASK(1, 0)
+#define REFCLK_SEL_DEFAULT (0x2 << 0)
+
+#define HS_DISCONNECT_MASK GENMASK(2, 0)
+#define SQUELCH_DETECTOR_MASK GENMASK(7, 5)
+
+#define HS_AMPLITUDE_MASK GENMASK(3, 0)
+#define PREEMPHASIS_DURATION_MASK BIT(5)
+#define PREEMPHASIS_AMPLITUDE_MASK GENMASK(7, 6)
+
+#define HS_RISE_FALL_MASK GENMASK(1, 0)
+#define HS_CROSSOVER_VOLTAGE_MASK GENMASK(3, 2)
+#define HS_OUTPUT_IMPEDANCE_MASK GENMASK(5, 4)
+
+#define LS_FS_OUTPUT_IMPEDANCE_MASK GENMASK(3, 0)
+
+#define SNPS_HS_NUM_VREGS ARRAY_SIZE(hs_7nm_vreg_names)
+
+struct override_param {
+   s32 value;
+   u8 reg_val;
+};
+
+struct override_param_map {
+   const char *prop_name;
+   const struct override_param *param_table;
+   u8 table_size;
+   u8 reg_offset;
+   u8 param_mask;
+};
+
+struct phy_override_seq {
+   bool need_update;
+   u8 offset;
+   u8 value;
+   u8 mask;
+};
+
+#define NUM_HSPHY_TUNING_PARAMS (9)
+
+/* struct hs_7nm_phy_cfg - per-PHY initialization config */
+struct hs_7nm_phy_cfg {
+   /* resets to be requested */
+   struct reset_ctl *resets;
+   int num_resets;
+
+   struct override_param_map *map_cfg;
+   struct phy_override_seq update_seq_cfg[NUM_HSPHY_TUNING_PARAMS];
+};
+
+/**
+ * struct 

[PATCH v3 01/14] mailmap: update Bhupesh's email address

2024-03-19 Thread Caleb Connolly
Update Bhupesh's email to his new one.

Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---

Cc: Bhupesh Sharma 
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index d1f08f3eca8a..f6e0847b2168 100644
--- a/.mailmap
+++ b/.mailmap
@@ -29,8 +29,9 @@ Ashok Reddy Soma  

 Atish Patra  
 Bharat Kumar Gogada  

 Bharat Kumar Gogada  
 Bhargava Sreekantappa Gayathri  

+Bhupesh Sharma  
 Bin Meng  
 Boris Brezillon  
 Boris Brezillon  
 Christian Kohn  

-- 
2.44.0



[PATCH v3 02/14] phy: qcom: add Qualcomm QUSB2 USB PHY driver

2024-03-19 Thread Caleb Connolly
From: Bhupesh Sharma 

The Snapdragon 845 and several other Qualcomm SoCs feature this
USB high-speed phy. Add a driver for it based on the Linux driver, with
support for the SDM845, and the QCM2290 and SM6115 SoCs which will gain
support in U-Boot in future patches.

Signed-off-by: Bhupesh Sharma 
[code cleanup, switch to clk_bulk]
Signed-off-by: Caleb Connolly 
---
 drivers/phy/qcom/Kconfig  |   7 +
 drivers/phy/qcom/Makefile |   1 +
 drivers/phy/qcom/phy-qcom-qusb2.c | 468 ++
 3 files changed, 476 insertions(+)

diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
index f4ca174805a4..361dfb6e1126 100644
--- a/drivers/phy/qcom/Kconfig
+++ b/drivers/phy/qcom/Kconfig
@@ -11,8 +11,15 @@ config PHY_QCOM_IPQ4019_USB
depends on PHY && ARCH_IPQ40XX
help
  Support for the USB PHY-s on Qualcomm IPQ40xx SoC-s.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm USB QUSB2 PHY driver"
+   depends on PHY && ARCH_SNAPDRAGON
+   help
+ Enable this to support the Super-Speed USB transceiver on various
+ Qualcomm chipsets.
+
 config PHY_QCOM_USB_HS_28NM
tristate "Qualcomm 28nm High-Speed PHY"
depends on PHY && ARCH_SNAPDRAGON
help
diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
index 2113f178c0c7..f6af985666a4 100644
--- a/drivers/phy/qcom/Makefile
+++ b/drivers/phy/qcom/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
 obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
+obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
 obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
 obj-$(CONFIG_PHY_QCOM_USB_SS) += phy-qcom-usb-ss.o
diff --git a/drivers/phy/qcom/phy-qcom-qusb2.c 
b/drivers/phy/qcom/phy-qcom-qusb2.c
new file mode 100644
index ..5b654403a181
--- /dev/null
+++ b/drivers/phy/qcom/phy-qcom-qusb2.c
@@ -0,0 +1,468 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Bhupesh Sharma 
+ *
+ * Based on Linux driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define QUSB2PHY_PLL 0x0
+#define QUSB2PHY_PLL_TEST 0x04
+#define CLK_REF_SEL BIT(7)
+
+#define QUSB2PHY_PLL_TUNE 0x08
+#define QUSB2PHY_PLL_USER_CTL1 0x0c
+#define QUSB2PHY_PLL_USER_CTL2 0x10
+#define QUSB2PHY_PLL_AUTOPGM_CTL1 0x1c
+#define QUSB2PHY_PLL_PWR_CTRL 0x18
+
+/* QUSB2PHY_PLL_STATUS register bits */
+#define PLL_LOCKED BIT(5)
+
+/* QUSB2PHY_PLL_COMMON_STATUS_ONE register bits */
+#define CORE_READY_STATUS BIT(0)
+
+/* QUSB2PHY_PORT_POWERDOWN register bits */
+#define CLAMP_N_EN BIT(5)
+#define FREEZIO_N BIT(1)
+#define POWER_DOWN BIT(0)
+
+/* QUSB2PHY_PWR_CTRL1 register bits */
+#define PWR_CTRL1_VREF_SUPPLY_TRIM BIT(5)
+#define PWR_CTRL1_CLAMP_N_EN BIT(1)
+
+#define QUSB2PHY_REFCLK_ENABLE BIT(0)
+
+#define PHY_CLK_SCHEME_SEL BIT(0)
+
+/* QUSB2PHY_INTR_CTRL register bits */
+#define DMSE_INTR_HIGH_SEL BIT(4)
+#define DPSE_INTR_HIGH_SEL BIT(3)
+#define CHG_DET_INTR_EN BIT(2)
+#define DMSE_INTR_EN BIT(1)
+#define DPSE_INTR_EN BIT(0)
+
+/* QUSB2PHY_PLL_CORE_INPUT_OVERRIDE register bits */
+#define CORE_PLL_EN_FROM_RESET BIT(4)
+#define CORE_RESET BIT(5)
+#define CORE_RESET_MUX BIT(6)
+
+/* QUSB2PHY_IMP_CTRL1 register bits */
+#define IMP_RES_OFFSET_MASK GENMASK(5, 0)
+#define IMP_RES_OFFSET_SHIFT 0x0
+
+/* QUSB2PHY_PLL_BIAS_CONTROL_2 register bits */
+#define BIAS_CTRL2_RES_OFFSET_MASK GENMASK(5, 0)
+#define BIAS_CTRL2_RES_OFFSET_SHIFT 0x0
+
+/* QUSB2PHY_CHG_CONTROL_2 register bits */
+#define CHG_CTRL2_OFFSET_MASK GENMASK(5, 4)
+#define CHG_CTRL2_OFFSET_SHIFT 0x4
+
+/* QUSB2PHY_PORT_TUNE1 register bits */
+#define HSTX_TRIM_MASK GENMASK(7, 4)
+#define HSTX_TRIM_SHIFT 0x4
+#define PREEMPH_WIDTH_HALF_BIT BIT(2)
+#define PREEMPHASIS_EN_MASK GENMASK(1, 0)
+#define PREEMPHASIS_EN_SHIFT 0x0
+
+/* QUSB2PHY_PORT_TUNE2 register bits */
+#define HSDISC_TRIM_MASK GENMASK(1, 0)
+#define HSDISC_TRIM_SHIFT 0x0
+
+#define QUSB2PHY_PLL_ANALOG_CONTROLS_TWO 0x04
+#define QUSB2PHY_PLL_CLOCK_INVERTERS 0x18c
+#define QUSB2PHY_PLL_CMODE 0x2c
+#define QUSB2PHY_PLL_LOCK_DELAY 0x184
+#define QUSB2PHY_PLL_DIGITAL_TIMERS_TWO 0xb4
+#define QUSB2PHY_PLL_BIAS_CONTROL_1 0x194
+#define QUSB2PHY_PLL_BIAS_CONTROL_2 0x198
+#define QUSB2PHY_PWR_CTRL2 0x214
+#define QUSB2PHY_IMP_CTRL1 0x220
+#define QUSB2PHY_IMP_CTRL2 0x224
+#define QUSB2PHY_CHG_CTRL2 0x23c
+
+struct qusb2_phy_init_tbl {
+   unsigned int offset;
+   unsigned int val;
+   /*
+* register part of layout ?
+* if yes, then offset gives index in the reg-layout
+*/
+   int in_layout;
+};
+
+struct qusb2_phy_cfg {
+   const struct qusb2_phy_init_tbl *tbl;
+   /* number of entries in the table */
+   unsigned int tbl_num;
+   /* offset to PHY_CLK_SCHEME register in TCSR map */
+   unsigned int clk_scheme_offset;
+
+   /* array of registers with different offsets */
+   const unsigned int 

[PATCH v3 00/14] Qualcomm platform USB support

2024-03-19 Thread Caleb Connolly
This series enables USB on Qualcomm SDM845 platforms and lays the
foundation for future SoCs as well.

It introduces two new high-speed PHY drivers, one for SDM845 and one for
an upcoming platform. The SDM845 clock driver gains support for
configuring the USB clocks, and the GPIO driver is updated to use .set_flags
which fixes a strange bug where GPIOs would also be configured as input.

Support for super-speed USB modes is not currently available, however
configuring the device to be high-speed only requires modifications to
DT.

To improve compatibility with upstream DT, we switch Qualcomm platforms
over to OF_LIVE and apply fixups to the tree to remove references to the
super-speed phy, as well as configure the Qualcomm glue for high-speed
only mode.

The db845c requires a vbus-supply to be hooked up for its usb type-A
port. A U-Boot dtsi file is added to configure this.

With these patches, it is now also possible to run U-Boot on some SDM845
phones like the OnePlus 6 using a dtb from Linux, and access the U-Boot
shell via the CDC ACM USB serial gadget.

This series depends on the ("Qualcomm DWC3 USB support") series [1], as
well as Volodymyrs patches enabling power domain support [2].
A feature branch based on qcom-next with the necessary dependencies
for testing the Dragonboard845c can be found at [3].

[1]: 
https://lore.kernel.org/u-boot/20240319-b4-qcom-usb-v3-0-09ba1f86d...@linaro.org
[2]: 
https://lore.kernel.org/u-boot/20240311213334.3567389-1-volodymyr_babc...@epam.com
[3]: https://git.codelinaro.org/linaro/qcomlt/u-boot/-/tree/b4/qcom-livetree

---
Changes in v3:
- Add back missing gadget options to qcom_defconfig (thanks Neil)
- Link to v2: 
https://lore.kernel.org/r/20240315-b4-qcom-livetree-v2-0-ab635774b...@linaro.org

Changes in v2:
- Fix incorrect order of NULL/0 parameters to of_write_prob() in
  fixup_qcom_dwc3()
- Move fixup_usb_nodes() to a separate file in preparation for future
  additions.
- Add missing break to switch case in sdm845_clk_enable()
- Remove rogue return statement in msm_gpio_set_flags()
- Rebase on Volodymyrs power domain patches.
- Link to v1: 
https://lore.kernel.org/r/20240131-b4-qcom-livetree-v1-0-4071c0787...@linaro.org

---
Bhupesh Sharma (2):
  phy: qcom: add Qualcomm QUSB2 USB PHY driver
  phy: qcom: Add USB HS 7nm PHY driver

Caleb Connolly (12):
  mailmap: update Bhupesh's email address
  mach-snapdragon: disable power-domains for pre-reloc drivers
  clk/qcom: use offsets for RCG registers
  clk/qcom: sdm845: add gdscs
  clk/qcom: sdm845: add USB clocks
  gpio: msm_gpio: add .set_flags op
  serial: msm-geni: support livetree
  mach-snapdragon: fixup USB nodes
  mach-snapdragon: fixup power-domains
  dts: sdm845-db845c: add u-boot fixups
  qcom_defconfig: enable livetree
  qcom_defconfig: enable USB

 .mailmap   |   1 +
 arch/arm/dts/sdm845-db845c-u-boot.dtsi |   8 +
 arch/arm/mach-snapdragon/Makefile  |   1 +
 arch/arm/mach-snapdragon/board.c   |   3 +
 arch/arm/mach-snapdragon/of_fixup.c| 147 +++
 arch/arm/mach-snapdragon/qcom-priv.h   |  19 ++
 configs/qcom_defconfig |  52 ++--
 drivers/clk/qcom/clock-apq8016.c   |  39 +--
 drivers/clk/qcom/clock-apq8096.c   |  28 +-
 drivers/clk/qcom/clock-qcom.c  |  24 +-
 drivers/clk/qcom/clock-qcom.h  |  16 +-
 drivers/clk/qcom/clock-qcs404.c| 121 ++---
 drivers/clk/qcom/clock-sdm845.c|  61 +++--
 drivers/gpio/msm_gpio.c|  27 +-
 drivers/phy/qcom/Kconfig   |  15 ++
 drivers/phy/qcom/Makefile  |   2 +
 drivers/phy/qcom/phy-qcom-qusb2.c  | 468 +
 drivers/phy/qcom/phy-qcom-usb-hs-7nm.c | 295 +
 drivers/serial/serial_msm_geni.c   |  15 +-
 19 files changed, 1108 insertions(+), 234 deletions(-)
---
base-commit: 7194c72d0eef33d9b76555a281d808a0afe54ab5

// Caleb (they/them)



[PATCH v3 5/5] iommu: qcom-smmu: fix debugging

2024-03-19 Thread Caleb Connolly
The priv struct was wrong in dump_boot_mappings(). Causing errors when
compiling with -DDEBUG. Fix this.

Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---
 drivers/iommu/qcom-hyp-smmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/qcom-hyp-smmu.c b/drivers/iommu/qcom-hyp-smmu.c
index 8e5cdb581550..f2b39de56f4a 100644
--- a/drivers/iommu/qcom-hyp-smmu.c
+++ b/drivers/iommu/qcom-hyp-smmu.c
@@ -318,9 +318,9 @@ static int qcom_smmu_connect(struct udevice *dev)
return 0;
 }
 
 #ifdef DEBUG
-static inline void dump_boot_mappings(struct arm_smmu_priv *priv)
+static inline void dump_boot_mappings(struct qcom_smmu_priv *priv)
 {
u32 val;
int i;
 

-- 
2.44.0



[PATCH v3 4/5] usb: gadget: UMS: support multiple sector sizes

2024-03-19 Thread Caleb Connolly
UFS storage often uses a 4096-byte sector size, add support for dynamic
sector sizes based loosely on the Linux implementation.

Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---
 cmd/usb_mass_storage.c  |   4 --
 drivers/usb/gadget/f_mass_storage.c | 101 
 drivers/usb/gadget/storage_common.c |  12 +++--
 include/usb_mass_storage.h  |   1 -
 4 files changed, 65 insertions(+), 53 deletions(-)

diff --git a/cmd/usb_mass_storage.c b/cmd/usb_mass_storage.c
index a8ddeb494628..751701fe73af 100644
--- a/cmd/usb_mass_storage.c
+++ b/cmd/usb_mass_storage.c
@@ -87,12 +87,8 @@ static int ums_init(const char *devtype, const char 
*devnums_part_str)
 */
if (!strchr(devnum_part_str, ':'))
partnum = 0;
 
-   /* f_mass_storage.c assumes SECTOR_SIZE sectors */
-   if (block_dev->blksz != SECTOR_SIZE)
-   goto cleanup;
-
ums_new = realloc(ums, (ums_count + 1) * sizeof(*ums));
if (!ums_new)
goto cleanup;
ums = ums_new;
diff --git a/drivers/usb/gadget/f_mass_storage.c 
b/drivers/usb/gadget/f_mass_storage.c
index c725aed3f626..d880928044f4 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -723,14 +723,15 @@ static int do_read(struct fsg_common *common)
if (lba >= curlun->num_sectors) {
curlun->sense_data = SS_LOGICAL_BLOCK_ADDRESS_OUT_OF_RANGE;
return -EINVAL;
}
-   file_offset = ((loff_t) lba) << 9;
+   file_offset = ((loff_t)lba) << curlun->blkbits;
 
/* Carry out the file reads */
amount_left = common->data_size_from_cmnd;
-   if (unlikely(amount_left == 0))
+   if (unlikely(amount_left == 0)) {
return -EIO;/* No default reply */
+   }
 
for (;;) {
 
/* Figure out how much we need to read:
@@ -767,15 +768,15 @@ static int do_read(struct fsg_common *common)
}
 
/* Perform the read */
rc = ums[common->lun].read_sector([common->lun],
- file_offset / SECTOR_SIZE,
- amount / SECTOR_SIZE,
+ file_offset / curlun->blksize,
+ amount / curlun->blksize,
  (char __user *)bh->buf);
if (!rc)
return -EIO;
 
-   nread = rc * SECTOR_SIZE;
+   nread = rc * curlun->blksize;
 
VLDBG(curlun, "file read %u @ %llu -> %d\n", amount,
(unsigned long long) file_offset,
(int) nread);
@@ -786,9 +787,9 @@ static int do_read(struct fsg_common *common)
nread = 0;
} else if (nread < amount) {
LDBG(curlun, "partial file read: %d/%u\n",
(int) nread, amount);
-   nread -= (nread & 511); /* Round down to a block */
+   nread -= (nread & (curlun->blksize - 1));   /* 
Round down to a block */
}
file_offset  += nread;
amount_left  -= nread;
common->residue -= nread;
@@ -860,9 +861,9 @@ static int do_write(struct fsg_common *common)
}
 
/* Carry out the file writes */
get_some_more = 1;
-   file_offset = usb_offset = ((loff_t) lba) << 9;
+   file_offset = usb_offset = ((loff_t)lba) << curlun->blkbits;
amount_left_to_req = common->data_size_from_cmnd;
amount_left_to_write = common->data_size_from_cmnd;
 
while (amount_left_to_write > 0) {
@@ -892,9 +893,9 @@ static int do_write(struct fsg_common *common)
SS_LOGICAL_BLOCK_ADDRESS_OUT_OF_RANGE;
curlun->info_valid = 1;
continue;
}
-   amount -= (amount & 511);
+   amount -= (amount & (curlun->blksize - 1));
if (amount == 0) {
 
/* Why were we were asked to transfer a
 * partial block? */
@@ -941,14 +942,14 @@ static int do_write(struct fsg_common *common)
amount = bh->outreq->actual;
 
/* Perform the write */
rc = ums[common->lun].write_sector([common->lun],
-  file_offset / SECTOR_SIZE,
-  amount / SECTOR_SIZE,
+  file_offset / curlun->blksize,
+ 

[PATCH v3 3/5] usb: gadget: CDC ACM: call usb_gadget_initialize

2024-03-19 Thread Caleb Connolly
To actually use the gadget the peripheral driver must be probed and we
must call g_dnl_clear_detach(). Otherwise acm_stdio_start() will always
fail to find a UDC on DT platforms.

Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---
 drivers/usb/gadget/f_acm.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/f_acm.c b/drivers/usb/gadget/f_acm.c
index de42e0189e8d..ba216128ab27 100644
--- a/drivers/usb/gadget/f_acm.c
+++ b/drivers/usb/gadget/f_acm.c
@@ -622,14 +622,23 @@ static void acm_stdio_puts(struct stdio_dev *dev, const 
char *str)
 }
 
 static int acm_stdio_start(struct stdio_dev *dev)
 {
+   struct udevice *udc;
int ret;
 
if (dev->priv) { /* function already exist */
return 0;
}
 
+   ret = udc_device_get_by_index(0, );
+   if (ret) {
+   pr_err("USB init failed: %d\n", ret);
+   return ret;
+   }
+
+   g_dnl_clear_detach();
+
ret = g_dnl_register("usb_serial_acm");
if (ret)
return ret;
 

-- 
2.44.0



[PATCH v3 0/5] Qualcomm DWC3 USB support

2024-03-19 Thread Caleb Connolly
This series enables support for Qualcomm platforms in the DWC3 driver,
adds support for arbitrary sector sizes to the USB mass storage gadget,
and fixes an issue with the CDC ACM driver where it wouldn't initialise
the USB device.

Additionally, it fixes a syntax bug in the Qualcomm SMMU driver, and
makes USB_DWC3_GADGET select DM_USB_GADGET to fix compilation with
gadget mode.

This is part of a larger series enabling DWC3 USB support on Qualcomm
platforms, a feature branch with all patches can be found at [1].

[1]: 
https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/tree/b4/qcom-livetree

---
Changes in v3:
- Fix ordering of QSCRATCH registers in qcom dwc3 glue.
- Link to v2: 
https://lore.kernel.org/r/20240315-b4-qcom-usb-v2-0-5467ec27c...@linaro.org

Changes in v2:
- Drop custom set/clrbits implementation in qcom dwc3 glue.
- Additional minor cleanup based on Marek's comments.
- Link to v1: 
https://lore.kernel.org/r/20240131-b4-qcom-usb-v1-0-6438b2a22...@linaro.org

---
Caleb Connolly (5):
  usb: dwc3-generic: implement Qualcomm wrapper
  usb: dwc3: select DM_USB_GADGET
  usb: gadget: CDC ACM: call usb_gadget_initialize
  usb: gadget: UMS: support multiple sector sizes
  iommu: qcom-smmu: fix debugging

 cmd/usb_mass_storage.c  |   4 --
 drivers/iommu/qcom-hyp-smmu.c   |   2 +-
 drivers/usb/dwc3/Kconfig|   1 +
 drivers/usb/dwc3/dwc3-generic.c |  81 -
 drivers/usb/gadget/f_acm.c  |   9 
 drivers/usb/gadget/f_mass_storage.c | 101 
 drivers/usb/gadget/storage_common.c |  12 +++--
 include/usb_mass_storage.h  |   1 -
 8 files changed, 156 insertions(+), 55 deletions(-)
---
base-commit: e03a71b2cefd86ba58df166d4ea820a215ebb655

// Caleb (they/them)



[PATCH v3 1/5] usb: dwc3-generic: implement Qualcomm wrapper

2024-03-19 Thread Caleb Connolly
The Qualcomm specific dwc3 wrapper isn't hugely complicated, implemented
the missing initialisation for host and gadget mode.

Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Marek Vasut 
Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---
 drivers/usb/dwc3/dwc3-generic.c | 81 -
 1 file changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index a379a0002e77..36b6c5306d64 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -424,8 +424,79 @@ enum dwc3_omap_utmi_mode {
 struct dwc3_glue_ops ti_ops = {
.glue_configure = dwc3_ti_glue_configure,
 };
 
+/* USB QSCRATCH Hardware registers */
+#define QSCRATCH_GENERAL_CFG 0x08
+#define PIPE_UTMI_CLK_SEL BIT(0)
+#define PIPE3_PHYSTATUS_SW BIT(3)
+#define PIPE_UTMI_CLK_DIS BIT(8)
+
+#define QSCRATCH_HS_PHY_CTRL 0x10
+#define UTMI_OTG_VBUS_VALID BIT(20)
+#define SW_SESSVLD_SEL BIT(28)
+
+#define QSCRATCH_SS_PHY_CTRL 0x30
+#define LANE0_PWR_PRESENT BIT(24)
+
+#define PWR_EVNT_IRQ_STAT_REG 0x58
+#define PWR_EVNT_LPM_IN_L2_MASK BIT(4)
+#define PWR_EVNT_LPM_OUT_L2_MASK BIT(5)
+
+#define SDM845_QSCRATCH_BASE_OFFSET 0xf8800
+#define SDM845_QSCRATCH_SIZE 0x400
+#define SDM845_DWC3_CORE_SIZE 0xcd00
+
+static void dwc3_qcom_vbus_override_enable(void __iomem *qscratch_base, bool 
enable)
+{
+   if (enable) {
+   setbits_le32(qscratch_base + QSCRATCH_SS_PHY_CTRL,
+ LANE0_PWR_PRESENT);
+   setbits_le32(qscratch_base + QSCRATCH_HS_PHY_CTRL,
+ UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
+   } else {
+   clrbits_le32(qscratch_base + QSCRATCH_SS_PHY_CTRL,
+ LANE0_PWR_PRESENT);
+   clrbits_le32(qscratch_base + QSCRATCH_HS_PHY_CTRL,
+ UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
+   }
+}
+
+/* For controllers running without superspeed PHYs */
+static void dwc3_qcom_select_utmi_clk(void __iomem *qscratch_base)
+{
+   /* Configure dwc3 to use UTMI clock as PIPE clock not present */
+   setbits_le32(qscratch_base + QSCRATCH_GENERAL_CFG,
+ PIPE_UTMI_CLK_DIS);
+
+   setbits_le32(qscratch_base + QSCRATCH_GENERAL_CFG,
+ PIPE_UTMI_CLK_SEL | PIPE3_PHYSTATUS_SW);
+
+   clrbits_le32(qscratch_base + QSCRATCH_GENERAL_CFG,
+ PIPE_UTMI_CLK_DIS);
+}
+
+static void dwc3_qcom_glue_configure(struct udevice *dev, int index,
+enum usb_dr_mode mode)
+{
+   struct dwc3_glue_data *glue = dev_get_plat(dev);
+   void __iomem *qscratch_base = (void __iomem *)glue->regs;
+   if (IS_ERR_OR_NULL(qscratch_base)) {
+   log_err("%s: Invalid qscratch base address\n", dev->name);
+   return;
+   }
+
+   if (dev_read_bool(dev, "qcom,select-utmi-as-pipe-clk"))
+   dwc3_qcom_select_utmi_clk(qscratch_base);
+
+   if (mode != USB_DR_MODE_HOST)
+   dwc3_qcom_vbus_override_enable(qscratch_base, true);
+}
+
+struct dwc3_glue_ops qcom_ops = {
+   .glue_configure = dwc3_qcom_glue_configure,
+};
+
 static int dwc3_rk_glue_get_ctrl_dev(struct udevice *dev, ofnode *node)
 {
*node = dev_ofnode(dev);
if (!ofnode_valid(*node))
@@ -511,8 +582,16 @@ static int dwc3_glue_reset_init(struct udevice *dev,
return 0;
else if (ret)
return ret;
 
+   if (device_is_compatible(dev, "qcom,dwc3")) {
+   reset_assert_bulk(>resets);
+   /* We should wait at least 6 sleep clock cycles, that's
+* (6 / 32764) * 100 ~= 200us. But some platforms
+* have slower sleep clocks so we'll play it safe.
+*/
+   udelay(500);
+   }
ret = reset_deassert_bulk(>resets);
if (ret) {
reset_release_bulk(>resets);
return ret;
@@ -628,9 +707,9 @@ static const struct udevice_id dwc3_glue_ids[] = {
{ .compatible = "rockchip,rk3328-dwc3", .data = (ulong)_ops },
{ .compatible = "rockchip,rk3399-dwc3" },
{ .compatible = "rockchip,rk3568-dwc3", .data = (ulong)_ops },
{ .compatible = "rockchip,rk3588-dwc3", .data = (ulong)_ops },
-   { .compatible = "qcom,dwc3" },
+   { .compatible = "qcom,dwc3", .data = (ulong)_ops },
{ .compatible = "fsl,imx8mp-dwc3", .data = (ulong)_ops },
{ .compatible = "fsl,imx8mq-dwc3" },
{ .compatible = "intel,tangier-dwc3" },
{ }

-- 
2.44.0



[PATCH v3 2/5] usb: dwc3: select DM_USB_GADGET

2024-03-19 Thread Caleb Connolly
DWC3 platforms depend on DM_USB_GADGET for gadget drivers to work,
otherwise compilation fails due to no implementation of
dm_usb_gadget_handle_interrupts().

Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Neil Armstrong 
Signed-off-by: Caleb Connolly 
---
 drivers/usb/dwc3/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index c0c8c16fd9c2..8a70bc682322 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -10,8 +10,9 @@ if USB_DWC3
 config USB_DWC3_GADGET
bool "USB Gadget support for DWC3"
default y
depends on USB_GADGET
+   select DM_USB_GADGET
select USB_GADGET_DUALSPEED
 
 comment "Platform Glue Driver Support"
 

-- 
2.44.0



Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks

2024-03-19 Thread Fabio Estevam
Hi Pierre,

On Tue, Mar 19, 2024 at 8:39 AM Pierre-Clément Tosi  wrote:

> This means gd->arch.tlb_addr pointing to the live PTs during setup_pgtables().
>
> In arch/arm/cpu/armv8, setup_all_pgtables() runs with SCTLR_ELx.M unset.
>
> In arch/arm/cpu/armv8/fsl-layerscape, setup_pgtables() is called twice:
>
>  - early_mmu_setup() calls it with SCTLR_ELx.M unset;
>  - final_mmu_setup() overwrites gd->arch.tlb_addr before calling it iff
>CFG_SYS_MEM_RESERVE_SECURE is defined i.e. if 
> CONFIG_SYS_SOC="fsl-layerscape"
>so that  gets auto-included through
>.
>
> So can CONFIG_FSL_LAYERSCAPE be set while CONFIG_SYS_SOC != "fsl-layerscape"?

No, this cannot happen.

Only the following Layerscape SoCs select CONFIG_FSL_LAYERSCAPE
in arch/arm/cpu/armv8/fsl-layerscape/Kconfig:
LS1012A, LS1028A, LS1043A, LS1046A, LS1088A, LS2080A, LX2162A and LX2160A

I saw the original boot problem with the i.MX8QX.

The i.MX8QX is part of the i.MX family, not the Layerscape family.

> I suppose Fabio and Stefano can answer this and/or help with ensuring that
> setup_pgtables() is never called on live PTs.

Let me know if you need any clarification.

Thanks,

Fabio Estevam


[PATCH] fs: ext4: Change the Settings of file permissions

2024-03-19 Thread Jixiong Hu
When a file is created in the linux and corresponding file permission
is set, if the file needs to be modified in uboot during the startup
process, the modified file permission will be reset to 755. Therefore,
when the ext4fs_write() function is called, if the file already exists,
the file permission of the new file is equal to the file permission of
the existing file.
---
 fs/ext4/ext4_write.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c
index ea4c5d4157..c0b4803700 100644
--- a/fs/ext4/ext4_write.c
+++ b/fs/ext4/ext4_write.c
@@ -847,6 +847,7 @@ int ext4fs_write(const char *fname, const char *buffer,
 {
int ret = 0;
struct ext2_inode *file_inode = NULL;
+   struct ext2_inode *existing_file_inode = NULL;
unsigned char *inode_buffer = NULL;
int parent_inodeno;
int inodeno;
@@ -900,6 +901,16 @@ int ext4fs_write(const char *fname, const char *buffer,
/* check if the filename is already present in root */
existing_file_inodeno = ext4fs_filename_unlink(filename);
if (existing_file_inodeno != -1) {
+   existing_file_inode = (struct ext2_inode *)zalloc(fs->inodesz);
+   if (!existing_file_inode)
+   goto fail;
+   ret = ext4fs_iget(existing_file_inodeno, existing_file_inode);
+   if (ret)
+   {
+   free(existing_file_inode);
+   goto fail;
+   }
+
ret = ext4fs_delete_file(existing_file_inodeno);
fs->first_pass_bbmap = 0;
fs->curr_blkno = 0;
@@ -948,9 +959,15 @@ int ext4fs_write(const char *fname, const char *buffer,
sizebytes = 0;
}
} else {
-   file_inode->mode = cpu_to_le16(S_IFREG | S_IRWXU | S_IRGRP |
-  S_IROTH | S_IXGRP | S_IXOTH);
+   if(existing_file_inode) {
+   file_inode->mode = existing_file_inode->mode;
+   } else {
+   file_inode->mode = cpu_to_le16(S_IFREG | S_IRWXU | 
S_IRGRP |
+  S_IROTH | S_IXGRP | 
S_IXOTH);
+   }
}
+   if(existing_file_inode)
+   free(existing_file_inode);
/* ToDo: Update correct time */
file_inode->mtime = cpu_to_le32(timestamp);
file_inode->atime = cpu_to_le32(timestamp);
-- 
2.18.0



Re: [PATCH v1 0/6] Introduce UBI block device

2024-03-19 Thread Alexey Romanov
Hello! Ping.

On Wed, Mar 06, 2024 at 04:49:00PM +0300, Alexey Romanov wrote:
> Hello!
> 
> This series adds support for the UBI block device, which
> allows to read/write data block by block. For example,
> it can now be used for BCB or Android AB command:
> 
>   $ bcb load ubi 0 part_name
> 
> Tested only on SPI NAND, so bind is made only for
> SPI NAND drivers. Can be used with mtdblock device [1].
> 
> - Links:
> 
>   [1] 
> https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
> 
> Alexey Romanov (6):
>   ubi: allow to read from volume with offset
>   ubi: allow to write to volume with offset
>   drivers: introduce UBI block abstraction
>   disk: don't try search for partition type if already set
>   disk: support UBI partitions
>   spinand: bind UBI block
> 
>  cmd/ubi.c   |  77 +++--
>  disk/part.c |   7 ++
>  drivers/block/blk-uclass.c  |   1 +
>  drivers/mtd/nand/spi/core.c |   9 ++-
>  drivers/mtd/ubi/Makefile|   2 +
>  drivers/mtd/ubi/block.c | 130 
>  drivers/mtd/ubi/part.c  |  99 +++
>  env/ubi.c   |  16 ++---
>  include/part.h  |   2 +
>  include/ubi_uboot.h |   8 ++-
>  10 files changed, 334 insertions(+), 17 deletions(-)
>  create mode 100644 drivers/mtd/ubi/block.c
>  create mode 100644 drivers/mtd/ubi/part.c
> 
> -- 
> 2.34.1
> 

-- 
Thank you,
Alexey

Re: [PATCH v2 0/3] Introduce mtdblock device

2024-03-19 Thread Alexey Romanov
Hello! Ping.

On Thu, Mar 07, 2024 at 04:07:23PM +0300, Alexey Romanov wrote:
> Hello!
> 
> This series adds support for the mtdblock device, which
> allows to read/write data block by block. For example,
> it can now be used for BCB or Android AB command:
> 
>   $ bcb load mtd 0 part_name
> 
> Tested only on SPI NAND, so bind is made only for
> SPI NAND drivers.
> 
> ---
> 
> Changes V1 -> V2 [1]:
> 
>   - Drop patch [2].
>   - Add warning if bind NAND mtdblock device.
>   - Move documentation of mtdblock implementation
> from commit message to the source code.
>   - Remove __maybe_unused from mtd partition functions
> description.
>   - Use blk_enabled() instead of #ifdefs.
> 
> Links:
> 
>   - [1] 
> https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
>   - [2] 
> https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/
> 
> Alexey Romanov (3):
>   disk: support MTD partitions
>   drivers: introduce mtdblock abstraction
>   spinand: bind mtdblock
> 
>  disk/part.c |   5 +-
>  drivers/block/blk-uclass.c  |   1 +
>  drivers/mtd/Kconfig |   1 +
>  drivers/mtd/Makefile|   1 +
>  drivers/mtd/mtdblock.c  | 227 
>  drivers/mtd/mtdpart.c   |  69 +++
>  drivers/mtd/nand/spi/core.c |  20 
>  include/linux/mtd/mtd.h |  12 ++
>  include/part.h  |   2 +
>  9 files changed, 337 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mtd/mtdblock.c
> 
> -- 
> 2.34.1
> 

-- 
Thank you,
Alexey

[PATCH u-boot v2019.04-aspeed-openbmc] ARM: dts: aspeed: Add Ampere's BMC platform (AST2600)

2024-03-19 Thread Chanh Nguyen
Add the initial version of the device tree for the Ampere BMC
platform, which is equipped with the Aspeed AST2600 BMC SoC.

Signed-off-by: Chanh Nguyen 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/ast2600-ampere.dts | 113 
 2 files changed, 114 insertions(+)
 create mode 100644 arch/arm/dts/ast2600-ampere.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 37675a3277..3642d59c89 100755
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -691,6 +691,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
ast2600-greatlakes.dtb \
ast2600-intel.dtb \
ast2600-ncsi.dtb \
+   ast2600-ampere.dtb \
ast2600-p10bmc.dtb \
ast2600-pfr.dtb \
ast2600-qcom-dc-scm-v1.dtb \
diff --git a/arch/arm/dts/ast2600-ampere.dts b/arch/arm/dts/ast2600-ampere.dts
new file mode 100644
index 00..63088703a7
--- /dev/null
+++ b/arch/arm/dts/ast2600-ampere.dts
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2022, Ampere Computing LLC
+/dts-v1/;
+
+#include "ast2600-u-boot.dtsi"
+
+/ {
+   model = "AST2600 Ampere BMC";
+   compatible = "aspeed,ast2600-ampere", "aspeed,ast2600";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;
+   };
+
+   chosen {
+   stdout-path = 
+   };
+
+   aliases {
+   spi0 = 
+   ethernet0 = 
+   };
+
+   cpus {
+   cpu@0 {
+   clock-frequency = <8>;
+   };
+   cpu@1 {
+   clock-frequency = <8>;
+   };
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <4>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_mdio1_default>;
+
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii-rxid";
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii1_default>;
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_fmcquad_default>;
+
+   flash@0 {
+   status = "okay";
+   spi-max-frequency = <5000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   };
+
+   flash@1 {
+   status = "okay";
+   spi-max-frequency = <5000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   };
+};
+
+ {
+   mac0-clk-delay = <0x10 0x0a
+ 0x10 0x10
+ 0x10 0x10>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.17.1



Re: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands

2024-03-19 Thread Alexander Dahl
Hello everyone,

Am Mon, Mar 18, 2024 at 11:15:18AM + schrieb mihai.s...@microchip.com:
> 
> > The command is very useful.
> > I would like to have also the ONFI timing mode printed for nand-flash 
> > 
> 
> As far as I can see the actually set mode is not stored anywhere.  One could 
> print it after it was successfully set, but that would be in nand base, not 
> in the atmel driver.
> 
>   OK. Understood.
>   Thanks.
> 
> > Also I recommend to print the master clock in MHz, and to print the master 
> > clock name/label from ccf driver:
> > https://github.com/u-boot/u-boot/blob/master/drivers/clk/at91/sama7g5.
> > c#L410
> 
> Should be possible.  I could do this and send a v2?
> 
>   Yes Please 
>   Also please note that older SAM9/SAMA5 series have no ccf drivers ☹
>   Only SAM9X6+ and SAMA7 series have ccf 

Okay I thought this would be easy, but it seems not.  This is what I
came up with:

-printf("mck clock rate: %lu\n", clk_get_rate(nc->mck));
+printf("%s rate: %lu MHz\n",
+   nc->mck->dev->name ? nc->mck->dev->name : "mck clock",
+   clk_get_rate(nc->mck) / 100);

And this is the output on sam9x60 with CONFIG_CLK_CCF enabled:

pmc@fc00 rate: 200 MHz

The corresponding line from `clk dump` is:

 25|   |   |   `-- mck_div

That name, I don't get it where to get that one.

Greets
Alex

>   Thanks.
> 
> 
> Greets
> Alex
> 
> >
> > Tested-by: Mihai Sain 
> >
> > Best regards,
> > Mihai Sain


Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks

2024-03-19 Thread Pierre-Clément Tosi
Hi Marc,

On Tue, Mar 19, 2024 at 09:43:03AM +, Marc Zyngier wrote:
> This seems pretty reasonable, thanks for looking into this. However, I
> can't help but notice that this is done without any BBM, and no TLBI
> either.
> 
> Are we guaranteed that the updated page tables are not live at the
> point of update?

This means gd->arch.tlb_addr pointing to the live PTs during setup_pgtables().

In arch/arm/cpu/armv8, setup_all_pgtables() runs with SCTLR_ELx.M unset.

In arch/arm/cpu/armv8/fsl-layerscape, setup_pgtables() is called twice:

 - early_mmu_setup() calls it with SCTLR_ELx.M unset;
 - final_mmu_setup() overwrites gd->arch.tlb_addr before calling it iff
   CFG_SYS_MEM_RESERVE_SECURE is defined i.e. if CONFIG_SYS_SOC="fsl-layerscape"
   so that  gets auto-included through
   .

So can CONFIG_FSL_LAYERSCAPE be set while CONFIG_SYS_SOC != "fsl-layerscape"?

I suppose Fabio and Stefano can answer this and/or help with ensuring that
setup_pgtables() is never called on live PTs.

Thanks,

-- 
Pierre


[PATCH] arm64: zynqmp: dts: Add required properties for rs485 support for KD240

2024-03-19 Thread Michal Simek
From: Manikanta Guntupalli 

Add "rts-gpios" and "linux,rs485-enabled-at-boot-time" properties
to uartps node to support RS485 on KD240.

Signed-off-by: Manikanta Guntupalli 
Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-sck-kd-g-revA.dtso | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso 
b/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
index 5202b7c48198..1727a1cc15c1 100644
--- a/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
+++ b/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
@@ -356,6 +356,8 @@
 
  {
status = "okay";
+   rts-gpios = < 72 GPIO_ACTIVE_HIGH>;
+   linux,rs485-enabled-at-boot-time;
pinctrl-names = "default";
pinctrl-0 = <_uart0_default>;
assigned-clock-rates = <1>;
-- 
2.36.1



Re: [PATCH] rockchip: spl: Cache boot source id for later use

2024-03-19 Thread Dragan Simic

Hello Quentin,

On 2024-03-19 11:19, Quentin Schulz wrote:

On 3/15/24 18:34, Jonas Karlman wrote:

Rockchip BROM write a boot source id at CFG_IRAM_BASE + 0x10, the id
indicate from what storage media TPL/SPL was loaded from.

SPL use this value to determine what device "same-as-spl" represent 
when

determining from where FIT should be loaded. This works as long as the
boot_devices array contain a matching id <-> node path entry.

However, SPL typically load a small part of TF-A into SRAM and on 
RK3399

this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.

Here boot source id is 3 before FIT images is loaded, and 0 after:

   U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +)
   board_spl_was_booted_from: brom_bootdevice_id 3 maps to 
'/spi@ff1d/flash@0'

   Trying to boot from SPI
   ## Checking hash(es) for config config-1 ... OK
   ## Checking hash(es) for Image atf-1 ... sha256+ OK
   ## Checking hash(es) for Image u-boot ... sha256+ OK
   ## Checking hash(es) for Image fdt-1 ... sha256+ OK
   ## Checking hash(es) for Image atf-2 ... sha256+ OK
   ## Checking hash(es) for Image atf-3 ... sha256+ OK
   board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
   spl_decode_boot_device: could not find udevice for /mmc@fe33
   spl_decode_boot_device: could not find udevice for /mmc@fe32
   spl_perform_fixups: could not map boot_device to ofpath: -19

Use a static bootdevice_brom_id to cache the boot source id after an
initial read from SRAM to fix this, this allow spl_perform_fixups() to
resolve correct boot source path for "same-as-spl" after SPL have 
loaded

TF-A related FIT images into memory.

With this the spl-boot-device prop can correctly be resolved to the
SPI flash node in the control FDT:

   => fdt addr ${fdtcontroladdr}
   Working FDT set to f1ee6710
   => fdt list /chosen
   chosen {
   u-boot,spl-boot-device = "/spi@ff1d/flash@0";
   stdout-path = "serial2:150n8";
   u-boot,spl-boot-order = "same-as-spl", "/mmc@fe33", 
"/mmc@fe32";

   };



I'm perplexed. We make use of this spl-boot-device DT property on Puma
(RK3399) and Ringneck (PX30) and I am pretty sure I tested it does
what it's supposed to do. So that is a bit surprising this seems to
not work anymore. Is this related to the BSS/stack memory address
location changes you made recently by any chance? Or did I manage to
be very lucky for a very long time for our boards?

"""
U-Boot SPL 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 
+0100)

board_spl_was_booted_from: brom_bootdevice_id 5 maps to '/mmc@fe32'
Trying to boot from MMC2
load_simple_fit: Skip load 'atf-5': image size is 0!
NOTICE:  BL31: v2.9(release):v2.9.0
NOTICE:  BL31: Built : 17:47:58, Jun 21 2023


U-Boot 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 
+0100)

[...]
=> fdt addr ${fdtcontroladdr}
Working FDT set to f1f13d10
=> fdt list /chosen
chosen {
u-boot,spl-boot-device = "/mmc@fe32";
stdout-path = "serial0:115200n8";
u-boot,spl-boot-order = "same-as-spl", "/spi@ff1d/flash@0",
"/mmc@fe33", "/mmc@fe32";
};
"""

for Puma when booting from SD card... I don't see
board_spl_was_booted_from being called a second time after BL31 is
loaded?

mmm

Very interestingly, when booting from SPI-NOR flash:

"""
U-Boot SPL 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 
+0100)
board_spl_was_booted_from: brom_bootdevice_id 3 maps to 
'/spi@ff1d/flash@0'

Trying to boot from SPI
load_simple_fit: Skip load 'atf-5': image size is 0!
board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
NOTICE:  BL31: v2.9(release):v2.9.0
NOTICE:  BL31: Built : 17:47:58, Jun 21 2023


U-Boot 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 
+0100)

[...]
=> fdt addr ${fdtcontroladdr}
Working FDT set to f1f13d10
=> fdt list /chosen
chosen {
u-boot,spl-boot-device = "/spi@ff1d/flash@0";
stdout-path = "serial0:115200n8";
u-boot,spl-boot-order = "same-as-spl", "/spi@ff1d/flash@0",
"/mmc@fe33", "/mmc@fe32";
};
"""

but the DT is properly written...

Ahah! This is because of one of my commits where I added support for
SPI-NOR flashes to spl_perform_fixups. So I think this worked for me
because the SPI-NOR flash is explicitly listed in spl-boot-order for
Puma, so when same-as-spl fails to resolve, the device is still found
in spl-boot-order DT property which means spl_perform_fixup will still
be able to write that spl-boot-device DT property. So basically, the
issue is related to SPI-NOR flash NOT being explicitly listed in
spl-boot-order or/and that the order isn't actually respected because
same-as-spl is basically skipped right now (but it works for Puma
because the next medium in the list is SPI, so skipping same-as-spl
for SPI, would result in checking SPI again :) ).


This was a very nice read, thanks for writing it down in detail! :)


Can you please add:

Fixes: 

Re: [PATCH] ARM: stm32: Default dfu_alt_info for STM32MP13xx SPI NOR

2024-03-19 Thread Patrice CHOTARD



On 3/19/24 03:44, Marek Vasut wrote:
> Define dfu_alt_info with SPI NOR layout to make it easy to
> install or update bootloader in the SPI NOR using dfu-util.
> 
> Use the following U-Boot commands to start DFU mode:
> "
> => sf probe && dfu 0 mtd
> "
> 
> Use the following dfu-util invocation on Host PC to install binaries:
> "
> $ dfu-util -w -a 0 -D 
> build/stm32mp1/release/tf-a-stm32mp135f-dhcor-dhsbc.stm32
> $ dfu-util -w -a 1 -D 
> build/stm32mp1/release/tf-a-stm32mp135f-dhcor-dhsbc.stm32
> $ dfu-util -w -a 2 -D build/stm32mp1/release/fip.bin
> "
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Tom Rini 
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
>  include/configs/stm32mp13_common.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/stm32mp13_common.h 
> b/include/configs/stm32mp13_common.h
> index 5b0658ced92..d6e4f8fd915 100644
> --- a/include/configs/stm32mp13_common.h
> +++ b/include/configs/stm32mp13_common.h
> @@ -63,6 +63,7 @@
>   "fi;\0"
>  
>  #define STM32MP_EXTRA \
> + "dfu_alt_info=mtd nor0=fsbl1 raw 0x0 0x4;fsbl2 raw 0x4 
> 0x4;uboot raw 0x8 0x16\0" \
>   "env_check=if env info -p -d -q; then env save; fi\0" \
>   "boot_net_usb_start=true\0"
>  


Hi Marek

On our STM32 board, the dfu_alt_info is build dynamically, we have 
CONFIG_SET_DFU_ALT_INFO enable 
Can you add the dfu_alt_info in a specific stm32mp13_dhxx.common.h instead ?

Thanks
Patrice



Re: [PATCH] rockchip: spl: Cache boot source id for later use

2024-03-19 Thread Quentin Schulz

Hi Jonas,

On 3/15/24 18:34, Jonas Karlman wrote:

Rockchip BROM write a boot source id at CFG_IRAM_BASE + 0x10, the id
indicate from what storage media TPL/SPL was loaded from.

SPL use this value to determine what device "same-as-spl" represent when
determining from where FIT should be loaded. This works as long as the
boot_devices array contain a matching id <-> node path entry.

However, SPL typically load a small part of TF-A into SRAM and on RK3399
this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.

Here boot source id is 3 before FIT images is loaded, and 0 after:

   U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +)
   board_spl_was_booted_from: brom_bootdevice_id 3 maps to 
'/spi@ff1d/flash@0'
   Trying to boot from SPI
   ## Checking hash(es) for config config-1 ... OK
   ## Checking hash(es) for Image atf-1 ... sha256+ OK
   ## Checking hash(es) for Image u-boot ... sha256+ OK
   ## Checking hash(es) for Image fdt-1 ... sha256+ OK
   ## Checking hash(es) for Image atf-2 ... sha256+ OK
   ## Checking hash(es) for Image atf-3 ... sha256+ OK
   board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
   spl_decode_boot_device: could not find udevice for /mmc@fe33
   spl_decode_boot_device: could not find udevice for /mmc@fe32
   spl_perform_fixups: could not map boot_device to ofpath: -19

Use a static bootdevice_brom_id to cache the boot source id after an
initial read from SRAM to fix this, this allow spl_perform_fixups() to
resolve correct boot source path for "same-as-spl" after SPL have loaded
TF-A related FIT images into memory.

With this the spl-boot-device prop can correctly be resolved to the
SPI flash node in the control FDT:

   => fdt addr ${fdtcontroladdr}
   Working FDT set to f1ee6710
   => fdt list /chosen
   chosen {
   u-boot,spl-boot-device = "/spi@ff1d/flash@0";
   stdout-path = "serial2:150n8";
   u-boot,spl-boot-order = "same-as-spl", "/mmc@fe33", "/mmc@fe32";
   };



I'm perplexed. We make use of this spl-boot-device DT property on Puma 
(RK3399) and Ringneck (PX30) and I am pretty sure I tested it does what 
it's supposed to do. So that is a bit surprising this seems to not work 
anymore. Is this related to the BSS/stack memory address location 
changes you made recently by any chance? Or did I manage to be very 
lucky for a very long time for our boards?


"""
U-Boot SPL 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 
+0100)

board_spl_was_booted_from: brom_bootdevice_id 5 maps to '/mmc@fe32'
Trying to boot from MMC2
load_simple_fit: Skip load 'atf-5': image size is 0!
NOTICE:  BL31: v2.9(release):v2.9.0
NOTICE:  BL31: Built : 17:47:58, Jun 21 2023


U-Boot 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 +0100)
[...]
=> fdt addr ${fdtcontroladdr}
Working FDT set to f1f13d10
=> fdt list /chosen
chosen {
u-boot,spl-boot-device = "/mmc@fe32";
stdout-path = "serial0:115200n8";
	u-boot,spl-boot-order = "same-as-spl", "/spi@ff1d/flash@0", 
"/mmc@fe33", "/mmc@fe32";

};
"""

for Puma when booting from SD card... I don't see 
board_spl_was_booted_from being called a second time after BL31 is loaded?


mmm

Very interestingly, when booting from SPI-NOR flash:

"""
U-Boot SPL 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 
+0100)
board_spl_was_booted_from: brom_bootdevice_id 3 maps to 
'/spi@ff1d/flash@0'

Trying to boot from SPI
load_simple_fit: Skip load 'atf-5': image size is 0!
board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
NOTICE:  BL31: v2.9(release):v2.9.0
NOTICE:  BL31: Built : 17:47:58, Jun 21 2023


U-Boot 2024.04-rc4-00026-g6ec096a7116-dirty (Mar 19 2024 - 10:50:03 +0100)
[...]
=> fdt addr ${fdtcontroladdr}
Working FDT set to f1f13d10
=> fdt list /chosen
chosen {
u-boot,spl-boot-device = "/spi@ff1d/flash@0";
stdout-path = "serial0:115200n8";
	u-boot,spl-boot-order = "same-as-spl", "/spi@ff1d/flash@0", 
"/mmc@fe33", "/mmc@fe32";

};
"""

but the DT is properly written...

Ahah! This is because of one of my commits where I added support for 
SPI-NOR flashes to spl_perform_fixups. So I think this worked for me 
because the SPI-NOR flash is explicitly listed in spl-boot-order for 
Puma, so when same-as-spl fails to resolve, the device is still found in 
spl-boot-order DT property which means spl_perform_fixup will still be 
able to write that spl-boot-device DT property. So basically, the issue 
is related to SPI-NOR flash NOT being explicitly listed in 
spl-boot-order or/and that the order isn't actually respected because 
same-as-spl is basically skipped right now (but it works for Puma 
because the next medium in the list is SPI, so skipping same-as-spl for 
SPI, would result in checking SPI again :) ).


Can you please add:

Fixes: d57e16c7e712 ("rockchip: find U-boot proper boot device by 
inverting the logic that sets it")


to the commit log regardless of the 

Re: [PATCH] rockchip: spl: Cache boot source id for later use

2024-03-19 Thread Dragan Simic

Hello Jonas,

Please see a few comments below.

On 2024-03-15 18:34, Jonas Karlman wrote:

Rockchip BROM write a boot source id at CFG_IRAM_BASE + 0x10, the id
indicate from what storage media TPL/SPL was loaded from.


s/write/writes/
s/indicate/indicates/

There are also a few more similar small grammar issues in the rest
of the patch descroption below.

SPL use this value to determine what device "same-as-spl" represent 
when

determining from where FIT should be loaded. This works as long as the
boot_devices array contain a matching id <-> node path entry.


s/use/uses/
etc.

However, SPL typically load a small part of TF-A into SRAM and on 
RK3399

this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.

Here boot source id is 3 before FIT images is loaded, and 0 after:

  U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +)
  board_spl_was_booted_from: brom_bootdevice_id 3 maps to
'/spi@ff1d/flash@0'
  Trying to boot from SPI
  ## Checking hash(es) for config config-1 ... OK
  ## Checking hash(es) for Image atf-1 ... sha256+ OK
  ## Checking hash(es) for Image u-boot ... sha256+ OK
  ## Checking hash(es) for Image fdt-1 ... sha256+ OK
  ## Checking hash(es) for Image atf-2 ... sha256+ OK
  ## Checking hash(es) for Image atf-3 ... sha256+ OK
  board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
  spl_decode_boot_device: could not find udevice for /mmc@fe33
  spl_decode_boot_device: could not find udevice for /mmc@fe32
  spl_perform_fixups: could not map boot_device to ofpath: -19

Use a static bootdevice_brom_id to cache the boot source id after an
initial read from SRAM to fix this, this allow spl_perform_fixups() to
resolve correct boot source path for "same-as-spl" after SPL have 
loaded

TF-A related FIT images into memory.

With this the spl-boot-device prop can correctly be resolved to the
SPI flash node in the control FDT:

  => fdt addr ${fdtcontroladdr}
  Working FDT set to f1ee6710
  => fdt list /chosen
  chosen {
  u-boot,spl-boot-device = "/spi@ff1d/flash@0";
  stdout-path = "serial2:150n8";
  u-boot,spl-boot-order = "same-as-spl", "/mmc@fe33", 
"/mmc@fe32";

  };

Signed-off-by: Jonas Karlman 
---
 arch/arm/mach-rockchip/spl.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/spl.c 
b/arch/arm/mach-rockchip/spl.c

index 1586a093fc37..27e996b504e7 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -32,9 +32,17 @@ __weak const char * const
boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

 const char *board_spl_was_booted_from(void)
 {
-   u32  bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+   static u32 bootdevice_brom_id;
const char *bootdevice_ofpath = NULL;

+   if (!bootdevice_brom_id)
+   bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+   if (!bootdevice_brom_id) {
+   debug("%s: unknown brom_bootdevice_id %x\n",
+ __func__, bootdevice_brom_id);
+   return NULL;
+   }
+


Maybe it would be better to execute readl(BROM_BOOTSOURCE_ID_ADDR)
only once, i.e. to have something like this instead:

+   static u32 bootdevice_brom_id = -1;

+   if (bootdevice_brom_id == -1) {
+   bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+   if (!bootdevice_brom_id)
+   debug("%s: unknown brom_bootdevice_id %x\n",
+ __func__, bootdevice_brom_id);
+   }
+
+   if (!bootdevice_brom_id)/* fail on subsequent tries */
+   return NULL;
+

The logic behind such an approach would be to try only once and fail
on subsequent (re)tries.  That way, it would also serve as some kind of
a runtime canary test, because the first try should succeed, which may
prove useful in the field.


if (bootdevice_brom_id < ARRAY_SIZE(boot_devices))
bootdevice_ofpath = boot_devices[bootdevice_brom_id];


Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks

2024-03-19 Thread Marc Zyngier
On Mon, 18 Mar 2024 19:35:49 +,
Pierre-Clément Tosi  wrote:
> 
> The implementation of map_range() creates the requested mapping by
> walking the page tables, iterating over multiple PTEs and/or descending
> into existing table mappings as needed. When doing so, it assumes any
> pre-existing valid PTE to be a table mapping. This assumption is wrong
> if the platform code attempts to successively map two overlapping ranges
> where the latter intersects a block mapping created for the former.
> 
> As a result, map_range() treats the existing block mapping as a table
> mapping and descends into it i.e. starts interpreting the
> previously-mapped range as an array of PTEs, writing to them and
> potentially even descending further (extra fun with MMIO ranges!).
> 
> Instead, pass any valid non-table mapping to split_block(), which
> ensures that it actually was a block mapping (calls panic() otherwise)
> before splitting it.
> 
> Fixes: 41e2787f5ec4 ("arm64: Reduce add_map() complexity")
> Signed-off-by: Pierre-Clément Tosi 
> ---
>  arch/arm/cpu/armv8/cache_v8.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index 697334086f..57d06f0575 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -326,6 +326,8 @@ static void map_range(u64 virt, u64 phys, u64 size, int 
> level,
>   /* Going one level down */
>   if (pte_type([i]) == PTE_TYPE_FAULT)
>   set_pte_table([i], create_table());
> + else if (pte_type([i]) != PTE_TYPE_TABLE)
> + split_block([i], level);
>  
>   next_table = (u64 *)(table[i] & GENMASK_ULL(47, PAGE_SHIFT));
>   next_size = min(map_size - (virt & (map_size - 1)), size);

This seems pretty reasonable, thanks for looking into this. However, I
can't help but notice that this is done without any BBM, and no TLBI
either.

Are we guaranteed that the updated page tables are not live at the
point of update?

Thanks,

M.

-- 
Without deviation from the norm, progress is not possible.


Re: [PATCH v2 3/3] spinand: bind mtdblock

2024-03-19 Thread Frieder Schrempf
On 07.03.24 14:07, Alexey Romanov wrote:
> Bind SPI-NAND driver to MTD block driver.
> 
> Signed-off-by: Alexey Romanov 

Reviewed-by: Frieder Schrempf 

> ---
>  drivers/mtd/nand/spi/core.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 2a3dbcfcb4..dd880adf31 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -36,6 +36,10 @@
>  #include 
>  #endif
>  
> +struct spinand_plat {
> + struct mtd_info *mtd;
> +};
> +
>  /* SPI NAND index visible in MTD names */
>  static int spi_nand_idx;
>  
> @@ -1174,12 +1178,24 @@ static void spinand_cleanup(struct spinand_device 
> *spinand)
>   kfree(spinand->scratchbuf);
>  }
>  
> +static int spinand_bind(struct udevice *dev)
> +{
> + if (blk_enabled()) {
> + struct spinand_plat *plat = dev_get_plat(dev);
> +
> + return mtd_bind(dev, >mtd);
> + }
> +
> + return 0;
> +}
> +
>  static int spinand_probe(struct udevice *dev)
>  {
>   struct spinand_device *spinand = dev_get_priv(dev);
>   struct spi_slave *slave = dev_get_parent_priv(dev);
>   struct mtd_info *mtd = dev_get_uclass_priv(dev);
>   struct nand_device *nand = spinand_to_nand(spinand);
> + struct spinand_plat *plat = dev_get_plat(dev);
>   int ret;
>  
>  #ifndef __UBOOT__
> @@ -1219,6 +1235,8 @@ static int spinand_probe(struct udevice *dev)
>   if (ret)
>   goto err_spinand_cleanup;
>  
> + plat->mtd = mtd;
> +
>   return 0;
>  
>  err_spinand_cleanup:
> @@ -1288,6 +1306,8 @@ U_BOOT_DRIVER(spinand) = {
>   .of_match = spinand_ids,
>   .priv_auto  = sizeof(struct spinand_device),
>   .probe = spinand_probe,
> + .bind = spinand_bind,
> + .plat_auto = sizeof(struct spinand_plat),
>  };
>  
>  void board_nand_init(void)


Re: [PATCH] rockchip: spl: Cache boot source id for later use

2024-03-19 Thread Kever Yang



On 2024/3/16 01:34, Jonas Karlman wrote:

Rockchip BROM write a boot source id at CFG_IRAM_BASE + 0x10, the id
indicate from what storage media TPL/SPL was loaded from.

SPL use this value to determine what device "same-as-spl" represent when
determining from where FIT should be loaded. This works as long as the
boot_devices array contain a matching id <-> node path entry.

However, SPL typically load a small part of TF-A into SRAM and on RK3399
this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.

Here boot source id is 3 before FIT images is loaded, and 0 after:

   U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +)
   board_spl_was_booted_from: brom_bootdevice_id 3 maps to 
'/spi@ff1d/flash@0'
   Trying to boot from SPI
   ## Checking hash(es) for config config-1 ... OK
   ## Checking hash(es) for Image atf-1 ... sha256+ OK
   ## Checking hash(es) for Image u-boot ... sha256+ OK
   ## Checking hash(es) for Image fdt-1 ... sha256+ OK
   ## Checking hash(es) for Image atf-2 ... sha256+ OK
   ## Checking hash(es) for Image atf-3 ... sha256+ OK
   board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
   spl_decode_boot_device: could not find udevice for /mmc@fe33
   spl_decode_boot_device: could not find udevice for /mmc@fe32
   spl_perform_fixups: could not map boot_device to ofpath: -19

Use a static bootdevice_brom_id to cache the boot source id after an
initial read from SRAM to fix this, this allow spl_perform_fixups() to
resolve correct boot source path for "same-as-spl" after SPL have loaded
TF-A related FIT images into memory.

With this the spl-boot-device prop can correctly be resolved to the
SPI flash node in the control FDT:

   => fdt addr ${fdtcontroladdr}
   Working FDT set to f1ee6710
   => fdt list /chosen
   chosen {
   u-boot,spl-boot-device = "/spi@ff1d/flash@0";
   stdout-path = "serial2:150n8";
   u-boot,spl-boot-order = "same-as-spl", "/mmc@fe33", "/mmc@fe32";
   };

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/mach-rockchip/spl.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 1586a093fc37..27e996b504e7 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -32,9 +32,17 @@ __weak const char * const boot_devices[BROM_LAST_BOOTSOURCE 
+ 1] = {
  
  const char *board_spl_was_booted_from(void)

  {
-   u32  bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+   static u32 bootdevice_brom_id;
const char *bootdevice_ofpath = NULL;
  
+	if (!bootdevice_brom_id)

+   bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+   if (!bootdevice_brom_id) {
+   debug("%s: unknown brom_bootdevice_id %x\n",
+ __func__, bootdevice_brom_id);
+   return NULL;
+   }
+
if (bootdevice_brom_id < ARRAY_SIZE(boot_devices))
bootdevice_ofpath = boot_devices[bootdevice_brom_id];
  


Re: [PATCH] riscv: Repeat virtio scan

2024-03-19 Thread Leo Liang
Hi Łukasz,

On Mon, Feb 19, 2024 at 01:41:39PM +0100, Łukasz Stelmach wrote:
> The first time virtio_init() gets called from board_init() PCI isn't
> ready. Thus any virtio-over-PCI (e.g. network interfaces) devices can't
> be detected and used without additional `virtio scan` scan in the shell
> or a script.
> 
> Signed-off-by: Łukasz Stelmach 
> ---
> The patch works for my but:
> 
> a) maybe virtio_init() should called only from board_init() the same
>way as on ARM?
> b) can a repeated virtio_init() break already detected/initialized
>devices?
> 

A repeated virtio_init() call would not break the already probed devices.
But we should prevent this redundancy by moving the virtio_init() call to
board_late_init() like what this commit[1] does for ARM.

Could you send a v2 to move the virtio_init() into board_late_init() ?

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20201230135712.5289-3-sughosh.g...@linaro.org/
e1ee06dde7 ("qemu: arm: Initialise virtio devices in board_late_init")

Best regards,
Leo

>  board/emulation/qemu-riscv/qemu-riscv.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/board/emulation/qemu-riscv/qemu-riscv.c 
> b/board/emulation/qemu-riscv/qemu-riscv.c
> index 181abbbf97d..567b9dc6170 100644
> --- a/board/emulation/qemu-riscv/qemu-riscv.c
> +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> @@ -46,6 +46,9 @@ int board_late_init(void)
>   if (CONFIG_IS_ENABLED(USB_KEYBOARD))
>   usb_init();
>  
> + /* Repeat virtio scan to detect PCI attached virtio devices. */
> + virtio_init();
> +
>   return 0;
>  }
>  


Re: [PATCH 2/3] configs: imx93-phyboard-segin: Add USB support.

2024-03-19 Thread Wadim Egorov



Am 18.03.24 um 22:48 schrieb Marek Vasut:

On 3/18/24 6:16 PM, Mathieu Othacehe wrote:

Enable the `usb` command and some USB drivers.

Signed-off-by: Mathieu Othacehe 
---
  configs/imx93-phyboard-segin_defconfig | 8 
  1 file changed, 8 insertions(+)

diff --git a/configs/imx93-phyboard-segin_defconfig 
b/configs/imx93-phyboard-segin_defconfig

index 24f9bd553aa..5acb987b817 100644
--- a/configs/imx93-phyboard-segin_defconfig
+++ b/configs/imx93-phyboard-segin_defconfig
@@ -23,6 +23,7 @@ CONFIG_SPL_STACK=0x20519dd0
  CONFIG_SPL=y
  CONFIG_ENV_OFFSET_REDUND=0x72
  CONFIG_CMD_DEKBLOB=y
+CONFIG_CMD_USB=y
  CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x8800
  CONFIG_SYS_LOAD_ADDR=0x8040
  CONFIG_SYS_MEMTEST_START=0x8000
@@ -132,6 +133,13 @@ CONFIG_SPL_SYSRESET=y
  CONFIG_SYSRESET_WATCHDOG=y
  CONFIG_DM_THERMAL=y
  CONFIG_IMX_TMU=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x1fc9
+CONFIG_USB_GADGET_PRODUCT_NUM=0x0152


Shouldn't this by Phytec or similar USB IDs ?
AFAIK, PHYTEC does not have its own IDs registered yet. So the freescale 
IDs should be fine.


Re: [PATCH 1/3] arm: dts: imx93-phyboard-segin: Add USB support.

2024-03-19 Thread Primoz Fiser
Hi Marek,

On 18. 03. 24 22:48, Marek Vasut wrote:
> On 3/18/24 6:16 PM, Mathieu Othacehe wrote:
>> Enable both usbotg1 and usbotg2 ports.
> 
> Drop fullstop from $subject end.
> 
>> Signed-off-by: Mathieu Othacehe 
>> ---
>>   arch/arm/dts/imx93-phyboard-segin.dts | 13 +
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/arm/dts/imx93-phyboard-segin.dts
>> b/arch/arm/dts/imx93-phyboard-segin.dts
>> index 85fb188b057..acf307a3192 100644
>> --- a/arch/arm/dts/imx93-phyboard-segin.dts
>> +++ b/arch/arm/dts/imx93-phyboard-segin.dts
>> @@ -40,6 +40,19 @@
>>   status = "okay";
>>   };
>>   +/* USB  */
>> + {
>> +    disable-over-current;
> 
> Why is this needed ?

OC pins are not connected to the SoC thus disable OC to avoid warnings
(c/p from kernel dts).

BR,
Primoz




Re: [PATCH 2/3] configs: imx93-phyboard-segin: Add USB support.

2024-03-19 Thread Primoz Fiser
Hi Mathieu,

On 18. 03. 24 18:16, Mathieu Othacehe wrote:
> Enable the `usb` command and some USB drivers.
> 

I would rephrase commit msg to something like this:

Add USB support by enabling `usb` command and required USB drivers.


> Signed-off-by: Mathieu Othacehe 
> ---
>  configs/imx93-phyboard-segin_defconfig | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/configs/imx93-phyboard-segin_defconfig 
> b/configs/imx93-phyboard-segin_defconfig
> index 24f9bd553aa..5acb987b817 100644
> --- a/configs/imx93-phyboard-segin_defconfig
> +++ b/configs/imx93-phyboard-segin_defconfig
> @@ -23,6 +23,7 @@ CONFIG_SPL_STACK=0x20519dd0
>  CONFIG_SPL=y
>  CONFIG_ENV_OFFSET_REDUND=0x72
>  CONFIG_CMD_DEKBLOB=y
> +CONFIG_CMD_USB=y

Can you run

$ make savedefconfig && cp defconfig configs/imx93-phyboard-segin_defconfig

to re-order CONFIG_CMD_USB please?


>  CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x8800
>  CONFIG_SYS_LOAD_ADDR=0x8040
>  CONFIG_SYS_MEMTEST_START=0x8000
> @@ -132,6 +133,13 @@ CONFIG_SPL_SYSRESET=y
>  CONFIG_SYSRESET_WATCHDOG=y
>  CONFIG_DM_THERMAL=y
>  CONFIG_IMX_TMU=y
> +CONFIG_USB=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_GADGET_MANUFACTURER="FSL"
> +CONFIG_USB_GADGET_VENDOR_NUM=0x1fc9
> +CONFIG_USB_GADGET_PRODUCT_NUM=0x0152
> +CONFIG_CI_UDC=y
>  CONFIG_ULP_WATCHDOG=y
>  CONFIG_LZO=y
>  CONFIG_BZIP2=y


-- 
Primoz Fiser| phone: +386-41-540-545
 |
-|
Norik systems d.o.o.| https://www.norik.com
  |
Your embedded software partner  | email: i...@norik.com
 |
Slovenia, EU| phone: +386-41-540-545
 |



  1   2   >